Effort Estimate Detail

One of the outputs of an estimation run is the effort needed to meet the given scope with the given level of quality in the time estimated. This can be summarized as "total effort" measured in (politically correct, though still mythical) person-months. But unlike "total schedule", there is more detail needed than just total effort for project initiation, for several reasons:

a) For the portfolio manager, the interest in "effort" is cost: the cost of the people trumps most other costs in software development. But "total effort" isn't detailed enough to translate to cost.

b) For the project manager, the interest in "effort" is finding the staff needed. Again, "total effort" isn't detailed enough.

All estimation tool vendors can submit each's "all encompassing, fully detailed" effort accounting. A super-set can then be derived which is capable of a bidirectional, lossless mapping with each's full effort accounting.

For Galorath, there are two ways to examine effort in totality:

- A 16x16 matrix of eight labor categories parsed into eight activities. This is a summary for the entire project. It is delivered given a specific probability setting, so capturing variance in this estimate would require the 'presentation' of multiple matrices, each produced at a given level of probability.

- For variations in effort over time (months), the contribution of effort at the labor category level can be given monthly, like this for three labor categories:

Mgmt Test Code Jul-09 1 0 1 Aug-09 0 0 3

Again, this is delivered at a specific probability level.

A note regarding "FTEs"... They actually are derived, a function of hours worked per month by each FTE. It usually may be better to deal in the common currency of effort hours and let the "client" compute FTEs based on its own calendaring knowledge. To provide for any estimation tool actually providing effort expressed in FTEs, a unit of measure (hours per month) could be provided in the effort estimate, or more detailed parameters allowing even more flexible manipulation by the client. Here are some of those parameters, which :

(This also ties into schedule estimation and may be appropriately referenced elsewhere in this wiki.)

Productive hours. The number of hours that an individual productively works on the project in a month. This figure will impact the estimated hours and schedule for a project. If you raise the number of productive hours per month, the schedule will be reduced; if you lower this setting, the schedule is lengthened. These hours should not include any time not directly charged to the project, such as vacation, holidays, or sick time. Although overtime can be factored in, make sure that the overtime hours are in fact productive. For example, a 65 hour work week may only be 80% effective, or equivalent to 52 productive hours per week.

Workdays per month. Sets the expected number of workdays per month. In MS Project, for instance, the expected working days per month average about 21.67 while in SEER-SEM the average is set to 19. You can change this setting if you know that your average days per month will regularly vary from the average in the target tool, although a better method is to leave this setting as-is and add requisite holidays, days off, modify resource constraints, etc. directly to that tool.

PHM_Effects. Determines how the Productive_hours setting is to be used, with possible settings being “effort”, “schedule” or “both.” This setting is fairly sophisticated, though for good reason, because there are different and equally acceptable variations on the interplay productive hours per month, work days per month, and other factors. If PHM_Effects is equal to:

Schedule: The duration estimate is multiplied by 152/Productive_hours

Effort: The effort estimate is multiplied by 152/Productive_hours

Both: Both duration and effort are affected, in the manner given above.

(Note: 152 hours per month is the standard used by SEER-SEM, which is the reason that Productive_hours are adjusted by this number.)

QSM Contribution:

1) 1st thing we need to know is what units the effort should be converted to such as person hours, person days, person months or person years. Along with this we need the effort accounting standard used by the organization in person hours per person month worked (usually backing unproductive time).

2) Next SLIM-Estimate allows you to configure the skill categories and labor rates. Once this is done labor by skill category can be allocated across tasks in the configurable work breakdown structure. Total effort can be broken down by any level in the WBS or alternatively also can be broken down by skill category. If the PM tool has a WBS and skill breakdown we could potentially read this in to configure these areas in SLIM-Estimate. Otherwise we could configure in SLIM-Estimate to match and export to the PM tool. We need to decide how much we want to bite off in the initial integration.

3) SLIM-Etimate will also produce a monthly FTE staffing plan. These can be level loaded or determined by various buildup, peak and ramp down functions. Peak staffing is what determines the magniture of the staffing curve.

4) Probabilitiy distributions are calculated at the total project level however that's defined (what phases are included). Usually the 50% solution is what the PM will use for detailed planning using the high assurance effort value as a commit to number.

Galorath Sample Data

• MetricsEffortEstimateDetailSamplesGalorath

QSM Sample Data

• MetricsEffortEstimateDatailSamplesQSM