De Re Productivity, the “Requirements Effort After Baseline” Parameter, and Staffing Constraints

Published on Author Dan Galorath

For SEER-SEM users accustomed to examining the Productivity metric, you may be interested to know that when staffing constraints are in place, productivity will change, and in differing ways, when requirements effort after baseline is specified, i.e., the parameter is set to YES. Without staffing constraints, productivity will not change with or without requirements effort specified after the baseline.

First, we should note that productivity is defined as effective size divided by non-requirements development effort. We will use pictures to explain why estimated productivity behaves differently with and without staffing constraints.

When Productivity Does Not Change

Below is a staffing plan with ideal staffing and with Requirements Effort After Baseline set to YES. The horizontal lines within the staffing bars delineate requirements effort from following project activities. Note how there is a gradual handoff between requirements and other effort.

Idel Staffin, Requirements After Baseline Set to YES
Ideal Staffing, Requirements After Baseline Set to YES

 

Below is another ideal staffing plan, this time with Requirements Effort After Baseline set to NO. Setting this to NO decreases the amount of requirements work to be done, and places all requirements work at the beginning of the project, before the so-called “baseline” has been established, and thus separate from other project activities.

Ideal Staffing, Requirements Effort After Baseline Set to NO
Ideal Staffing, Requirements Effort After Baseline Set to NO

The first chart shown includes requirements effort after baseline, the second chart shows the same estimate only with requirements effort after baseline turned off. Using the productivity definition of effective size divided by non-requirements development, both scenarios will have the same productivity. This is because the development effort does not change when you turn off requirements after baseline.

Staffing Constraints and Their Various Effects on Productivity

The dynamic changes when staffing constraints are imposed. What happens with productivity depends on the shape of the optimal project staffing curve, and the type and timing of constraint. Let’s use the curve featured above and see how productivity changes under a few scenarios.

How Moving Staff Constraints May Not Change Productivity

In this example, requirements effort after baseline is always set to YES. Everything else aside, if we impose a maximum staffing constraint, productivity will rise as fewer developers are work longer and so get smarter and more efficient doing so. Note that the maximum staff constraint does not change the staffing profile in the early months.

Constrained Staffing After 7 Months, Requirements Effort After Baseline Set to YES
Constrained Staffing After 7 Months, Requirements Effort After Baseline Set to YES

Let’s say that on the very same project, we impose a fixed staff of 7 from the beginning of the project:

Constr
Constrained Staffing Throughout, Requirements Effort After Baseline Set to YES

Productivity still does not change, since the development effort is not scaled up any faster, and thus project learning remains the same. Note however that different staffing constraints could have a different effect on productivity, if the rate at which developers can be meaningfully allocated is positively or negatively affected.

Staff Constraints + Requirements Included/Excluded = Changes in Productivity

Now let’s try a new scenario.  As in the last example, a staffing level of 7 persons is imposed on the project from the start.  Here I am going to mostly paraphrase some words from my colleague Karen, “Once requirements are base lined, development can start. Since you are including requirements effort after baseline, the requirements staff can absorb most of the 7 bodies available from the start. At the same time, the development activity can efficiently ramp up. In this way, the development effort is slowing adding resources till they are able to absorb everyone allocated.”

sdfsdf
Constrained Staffing Throughout, Requirements Effort After Baseline Set to YES

Removing requirements activity after the baseline, as shown in the chart below, will decrease productivity. (In the chart, you can see that the requirements activity ends at the dip in the bars in month 6.) Karen again, “Since you are NOT including requirements effort after baseline, the development staff must absorb all 7 bodies from the start. This over staffing is generally wasted effort as all those people won’t be totally productive right away. This wasted effort can be roughly equivalent to the effort that would have been spent on requirements after the baseline.”

    Constrained Staffing Throughout, Requirements Effort After Baseline Set to NO
Constrained Staffing Throughout, Requirements Effort After Baseline Set to NO

“Basic Estimate” Report

This report is a great way to explore the numbers behind the Productivity estimate. In the image below, have a look at the effort column. The effort figure factoring into the productivity calculation is taken from the “S/W Design Thru Program Test Complete” line. Productivity calculation does not include Requirements Before Design, Requirements During Design thru Test nor System Integrate thru OT&E (Initial fielding).

Basic Estimate Report Showing Effort Within Project Phases
Basic Estimate Report Showing Effort Within Project Phases

Summary

Discussing productivity and the effect on it from requirements and various staffing constraints, lies at the heart of software development dynamics. The SEER-SEM model embodies these complex dynamics in sometimes nonlinear ways. Keep in mind changes in more than one dimension – constraint level, minimum or maximum, timing, the optimal staffing curve, requirements effort after baseline – can have conflicting effects. To explore the dynamics, therefore, it’s best to make one change at a time, examining the effect of each.

About the Title

“De Re” is a Latin phrase which, translated, means “of (the) thing”. In the software world, it was famously applied to the epoch tome “De Re Atari”, a full and deep guide to the technology of the Atari computer.  Darn, I’ve dated myself.