E-Mail
Embracing Metrics: Accurate Cost and Schedule Estimation
by Michael C. Mah, Senior Consultant, Cutter Consortium
Many IT managers are seeking to reliably forecast and estimate projects.
In these instances, a typical scenario involves a client organization (i.e., the marketing department or an internal business unit) that specifies a set of business requirements, user requests, or the like. Oftentimes, the level of specificity of the requirements varies tremendously, anywhere from a set of e-mails or memoranda to a complete product or requirements specification. In either case, and everywhere in between, the development manager must provide "the estimate" for budget and staff purposes. In perhaps 95% of the cases, the deadline is mandated by decree.
"Estimation of resources, cost, and schedule for a software project requires experience, access to good historical information, and the courage to commit to quantitative measures when qualitative data are all that exist."
-- Roger Pressman
In nearly all IT organizations with which I've worked for nearly two decades, the default technique of project estimation goes something like this: given the nature of the unknowns, or because of the lack of a reliable requirements gathering process, requirements are fuzzy at best. The manager must estimate, with excruciating detail, all tasks including the effort and duration of the project.
The tasks are tallied in a spreadsheet with their associated estimates for headcount and duration. Each is described in terms of effort-hours or effort-days. For example, 20 person-hours for high-level design, 32 person-hours for detailed design, and another 40 for coding and unit testing of a given requirement. Fudge factors may be assigned for areas described as complex or somewhat unknown or to team members who may have less experience in new areas.
The spreadsheet is totaled for an estimate of the sum total of the person-hours, and another 30% or so might be added for integration testing. For a large project, a grand total across multiple groups might tally to, say, 34,000 person-hours, which converts to an average of 8,500 person-days, or 200 person-months. It's perceived that this answer, which the manager worked long and hard to produce over what was possibly an arduous two-week period, is the answer for the work effort. (Note: at this point, the requirements may still be unstable.)
Now here is where the ugly part begins. The mandated deadline by senior management is, say, 10 months. The manager looks at this deadline and must come up with a staffing plan to expend the 200 person-months of effort in a 10-month period. In nearly all cases, she will submit a staff request for 20 people (20 staff per month x 10 months expends 200 person-months of effort). Also note that a problem may reside in the fact that not all 20 people may report to this manager, such as testers. They might "belong" to one of her peers.
The project might be approved and budgets are locked down for this project and dozens of others, which are then tallied in a single massive fiscal-year planning exercise performed excruciatingly over a two-month period. The manager is somewhat nervous right now, because any number of things might happen, and she is stuck with whatever budget she has managed to negotiate. Possible occurrences include the following:
A compression of the deadline
A serious change in the scope of the project (e.g., a dramatic increase)
A loss of staff the manager assumed would be available
Hardware resources or software tools that don't show up or are not up to the task
A closer look at the project, revealing a massive increase in complexity
All of the above, all at once (and three weeks after budgets are locked down)
The overburdened manager is in an impossible position. Her fate has been sealed, and her bosses are holding her to her commitments. The difficulty exists because of a labor-intensive and cumbersome manual estimation approach that can't respond quickly enough to the fast pace of changing project demands in a dynamic IT environment.
In this environment, computers running software estimation tools can help.
"Work (resulting from additional functionality) expands to fill the ... (perceived) available (volume and then some)."
-- Parkinson's Law adapted to software project management
I welcome your comments on this issue of the Cutter Edge and encourage you to send your insights on the market in general to me at mmah@cutter.com.
-- Michael C. Mah, Senior Consultant, Cutter Consortium