Manage Learn to apply best practices and optimize your operations.

How to improve software project requirements estimates tutorial

Overcoming management constraints on softgware projects is often thought be impossible. Expert Robin Goldsmith shows ways to more efficiently estimate projects in this multiple step tip.

Even the greatest project manager cannot deliver a quality project on time and in budget when senior management has top-down dictated an impossibly inadequate budget and schedule, which is the main reason projects overrun.

A recent article really provoked me by saying that management is all-wise and must dictate top-down project budgets and schedules in order to overcome project managers' inherent inclination to delay delivery and increase costs by padding bottom-up estimates. I won't dignify this article with a link!

It's too bad that management often blindly believes this drivel. I just don't believe that all project managers intentionally delay projects.

Likewise, I don't think that all senior management decisions are nonsensical. Although tempered by extensive hands-on technical real work, for many years I've taken mainly a management perspective. I believe managing well is important, in fact, essential for organizational and project success.

In this tip, I offer some practical advice on finding and eliminating the main causes of project overrun and moving toward accurate project requirements estimates.

Estimating concepts

Project budgets and schedules represent estimates. All estimates are based on relating the thing to be estimated to some known reference. Three factors determine the estimate's accuracy:

  1. The extent of similarity between the reference and the thing being estimated.
  2. Scaling accuracy; that is, how well we tell their relative sizes.
  3. The accuracy of our data concerning what it took to create the reference.

Top-down estimates make a single estimate for the whole thing and then allocate that estimate among the key pieces. They are quick. Management tends to assume, too often fallaciously, that their position at the top of the organization thereby enables them to make accurate top-down estimates. Bottom-up estimates identify the key pieces, make estimates for each, and then roll them up into an estimate for the full thing. This takes longer. Project managers need to know the pieces that must be done and thus estimate them. Theoretically, both ways should give similar results. In practice, they seldom do.

Overlooking things

Overlooking things is the biggest cause of inaccurate estimates. Our estimates won't provide for anything that's been overlooked. Overlooking things means that we have a less accurate basis for telling how similar what we're estimating is to our reference, for sizing them, and for knowing what the reference actually took.

People with experience in a job make more accurate estimates of it because they are less likely to overlook deliverables, tasks and, especially, the subtasks of which less-experienced people often are unaware. Likely obstacles, contingencies, and changes frequently also are overlooked; invariably by overly-optimistic "best-case" estimates which assume everything will go well.

Intrinsic duration is the essential elapsed time to do something. Extrinsic factors affect when it can be started or finished. Most tasks' intrinsic duration equals their effort. However, tasks whose intrinsic duration greatly exceeds their often nominal effort are easily overlooked. For instance, ordering a book online may take three minutes; but you can't read the book until it arrives three days later.

Practicalities affecting the estimates also often are overlooked. For instance, delivery of that ordered book may be delayed because of a weekend and/or holiday; or maybe you'll be in training, on vacation or at a client site and won't get the book until days after it arrives. It's common to overlook differences attributable to factors affecting task difficulty and productivity due to personal skill of the person doing the task. Regardless of their skill, another commonly-overlooked practicality is how much productive time they actually have in a work day. Most of us are lucky to get six hours of productive work in an eight-hour workday, and the amount declines as our level rises.

Estimates further suffer because many of us overlook the need to measure what actually happens, compare it to our estimates, analyze and correct for causes of discrepancies. Such feedback and adjustment should occur within a project to catch ongoing problems as well as post-implementation where the benefits only accrue to the next project, if then.

Bottom-up estimating often is criticized as being too easily affected by overlooking tasks, which is especially likely early in a project when less is known about the tasks that need to be done. In fact, breaking down the work for bottom-up estimates reduces both the number and impact of overlooked tasks. Mistakes with estimates of the individual pieces tend to be smaller and balance out, thereby reducing the overall variance.

In contrast, mistakes with the single top-down estimate are more likely to create very large discrepancies, which almost always represent gross underestimation. In my experience, top-down estimates are far more likely to overlook significant contributors to effort and duration; and top-down estimators are far less likely to become aware of what they're overlooking.

Requirements role in responsible estimating

Responsible estimating involves accurately identifying (1) what needs to be done, (2) how to do it, and (3) what it will take. The quantified estimate for accomplishing what needs to done actually is calculated based only on the third part: what it will take to do it in the prescribed manner. However, parts 1 and 2 must first be done correctly for the estimate of part 3 to be accurate.

Business requirements are what must be done in business terms in order to provide value. For example, a retailer's business requirements may include accurately, securely and confidentially identifying their customer who wants to buy something.

Product/system/software requirements describe how it will be done. Effort, cost, and time are incurred in implementing the how. The how provides value if and only if it satisfies the business what.

In the seller's brick and mortar store, a government-issued photo ID could be how to identify the customer; whereas online a Login User ID and Password could be how. In the store, it might have taken a single five-minute session to train a cashier how to check an ID; and then each ID could take five seconds to check. For the online seller, it first takes a certain amount of time for a programmer to develop a login routine and associated database elements; then additional time for it to be tested by the programmer, QA/Testing, and users; and finally further time to install the routine and train users how to use it.

Trouble sources

Unfortunately, many projects' budgets and schedules are set top-down by management without benefit of meaningfully performing the three steps of responsible estimating. As discussed in my article, Defining requirements during software project feasibility analysis, management frequently initiates projects with dictated budgets and schedules that are so inadequate they make failure almost certain.

I find that these situations are repeated over and over in many organizations. My informal analysis indicates that the offending management usually sets project constraints without considering involving the affected project managers, let alone consciously trying to outflank them.

Rather, senior management tends to drink their own Kool-Aid, unconsciously acting on the premise that their organizational position demands and enables them unilaterally to dictate top-down project budgets and schedules. They, often mistakenly, assume they know what is needed and how long it should take to accomplish. They usually are unaware that they probably don't know the real business requirements' deliverable whats, which must be identified before it's reasonable to estimate time and effort to create a product/system/software how that will satisfy the whats.

Consequently, management also is likely to be unaware that they should be involving project managers and business analysts during project initiation to help them define the business and product requirements needed to make supportable budgets and schedules that can be met successfully.

Basing budgets and schedules on reliable estimates

To participate productively, project managers and business analysts have to develop and demonstrate the necessary skills and attitudes. They have to recognize that it is possible to make more reliable estimates early in a project and that it is not acceptable to ignore deadlines once set, since other people then start relying upon even arbitrary deadlines.

Moreover, they need to appreciate the differences between real business requirements and product/system/software requirements; and they need to learn how to first discover the high-level business requirements before selectively driving them down to detail.

The key to reliably estimating project budgets and schedules is to ground them in value by starting with high-level real business requirements that provide value when met. This is relatively quick but not instantaneous. It takes some digging and analysis, along with review to gain agreement that the requirements are right. I guide this process with a powerful tool called a Problem Pyramid™ which I'll discuss in a future article.

Business requirements do not themselves have a cost or duration. Rather, the time and cost come from creating a product, system, and/or software that satisfies the business requirements. Therefore, developing reliable estimates is a multi-step process. Step 1, as we said, is to discover the high-level business requirements.

Step 2 involves developing a high-level design of a product, system and/or software that will satisfy the business requirements. Step 3 is to define a high-level description of the pieces that must be created to form the product, system, and/or software. Step 4 defines the high-level work breakdown structure (WBS) of tasks necessary to implement the pieces.

A WBS hierarchically decomposes tasks, ordinarily all the way down into small lowest-level "work packet" sub-tasks, for which estimates are made of effort and intrinsic duration that a resource of defined skill and level needs to perform the task. Early in a project, when only high-level information is known, the WBS task decomposition stays fairly high-level.

To make up for the unknowns and limited detail, it is quite appropriate to apply various uncertainty reduction techniques. One such approach is to realize that because the high-level WBS decomposition yields relatively few still quite large tasks, estimating each one actually involves essentially a set of top-down estimates, but for somewhat smaller projects. Multiple estimates of somewhat smaller pieces reduces the risk compared to making only a single top-down estimate for the larger entire project.

Another proven technique involves adding buffer or contingency tasks that reflect the degree of uncertainty. To the extent possible, these should be based on historical experience regarding the relative number and size of additional tasks which typically become recognized as projects progress to completion. Organizations that track projects systematically often find fairly consistent uncertainty factor relationships between actuals and estimates relative to the point at which estimates are made and the level of WBS detail.

Some people might think that such uncertainty factors are the same as padding, but their historical measurement basis makes them much different. Padding is another "we's dumb" defensive technique that project managers employ in response to estimates they suspect are woefully low. Padding is prevalent when there has been a tradition of blaming project managers for failing to meet impossibly-low dictated top-down budgets and schedules. Padding generally adds a somewhat arbitrary percentage, typically doubling, to an often unfounded estimate. Two times nonsense is still nonsense. Moreover, management knows the trick and often cuts project managers' estimates in half.

Increasingly reliable estimates come from applying these techniques, as well as tracking, analyzing and adjusting appropriately for variances between estimates and actuals. Basing project budgets and schedules on such more reliable estimates can dramatically reduce the main cause of project overruns.

Dig Deeper on Topics Archive

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

I'd argue that not everything can be just improved. If the original approach has inherent limitations not much can be done. Estimation is one of such things. While some factors can be taken into account others can be only assumed, and yet others can't be even imagined. Consider things like technology breakthroughs or political impacts, like Brexit.
The only things that can’t be improved are ones that are already perfect; and for most of us, perfection is not a limiting issue. Then the questions relate to extent of improvement balance against ease and cost of achieving the improvements. Evolutionary or kaizen improvements are small, easier to accomplish, but may have to add up over time to be meaningful. That’s like the baseball team that concentrates on singles, walks, and avoiding errors to win games.
The other improvement approach is revolutionary and goes for big changes, like the baseball teams that depend on home runs to win. Such improvement is harder and far less likely to pay off but tends to be the preferred approach. Everyone wants the big score, which is why casinos continued to prosper. Most revolutionary improvement efforts are based on guesses that turn out not to pay off. Generally the more reliable way to make big improvements is to understand the REAL process sufficiently to identify otherwise unrecognized ways to improve it significantly; but few people seem to have the patience, awareness, or skill to do it.
@Robin - can you clarify?

You say - "The only things that can’t be improved are ones that are already perfect".

Is perfection an absolute or a relative category to you?
In order to form a more perfect union…” notwithstanding, perfect is perfect and cannot be improved. Perhaps the portion that’s perfect could be expanded; but for the perfect part, it’s as good as it gets. It seems to me that obsessing over theoretical possibility of improving perfect is not a worthwhile topic to spend time on but maybe in some convoluted irrationality seems like an excuse not to focus on all the imperfections that actually are candidates for improvement.
A lot regarding improvement also depends on the maturity of processes, flexibility or rigidity of management, kind of projects, geographic location, customer, etc. As a matter of fact, there is always a scope of improvement.