This month's Sky and Telescope's "Mission Update" column describes the Vision for Space Exploration project components, one of which is Crew Exploration Vehicle. The total estimated cost of the Crew, Cargo and Launch vehicle comes in around $104B of 13 years.
The estimating process for this integrated system is based on many processes and techniques, which is guided by the NASA Cost Estimating Handbook. The granularity of these cost and accompanying schedule estimates varies depending on the system and subsystem, but most "work activities" are in the $100,000 range. For work in progress tasks, the durations are defined from 10 to 40 days. In an activity rolling wave, tasks should not cross more than one accounting period is a pretty good rule of thumb.
In a previous set of posts here, I've commented on how David Anderson suggested we should not estimate software development. Turns out when you get all the way through is "suggestion" the granularity of the "stalking horse" was in single digit days that consumed 40% of the capacity of the team. This of course was not only muda it was down right silly management.
But it does bring up the question - at what granularity should estimates be made for work in the future and how far in the future should these estimates forecast cost. Given David's solution to the estimating problem of having a fixed budget for the development team and scheduling work on a priority basis, the 40% absorption went away. This is called "time box scheduling" and requires no fancy TOC processes other than to sequence the work in the customers priority and expand the accounting period to a year - the the customers permission of course.
But for projects that want to have a bit more flexibility in terms of staff assignments, visibility into the forecasts of cost and the associated value, some form of estimate of effort on fined grained boundaries will be needed. Here's some guidelines for large projects that might be useful across a broad scale of granularity:
- Keep the estimating costs in proportion to the deliverable's value. The needs to be a risk adjusted value, since the investments needs to have a risk adjusted return. If I SWAGed the Crew Exploration Vehicle to within +/- 30% on a $3B program that's some real money. +/- 30% on a 7 day task is "lunch money" for the team.
- Let the customer define the "value" of the estimate. Have this discussion upfront. "At what degree of confidence (notice confidence does mean accuracy) do you want our estimates to be?"
- Continuously update the "adjustment" factors for these estimates from real data. If the estimate was 47 days and the team came in at 54 day for a collection of tasks (not just one task) then include this knowledge in the overall estimate at completion (EAC).
- Have some measure of performance other than the passage of time. Earned Value is one. EV is rarely used in the IT world for many reasons - all of which poor reasons, bit that's another story. Have some performance measure tied to delivered value that includes the productivity of the team (EV does this very well). BTW the GAO is now requiring EV be used on IT projects, so the commerical sector will be felling this "need" soon.
In the end having a time boxed approach "may be useful" but the customer has to agree that the budget and the time boxes are in fact fixed in the business sense. A maintenance project might work this way, but scaling the staff up or down is now locked in as is the capacity for work. If that works then that approach could be used.
If not then some estimating process that connects effort with delivered value will be needed.
