Phil Jackson, Bill Phifer and I wrote a white paper a while back titled Agile-Iterative Development and the Cone of Uncertainty, where we discussed the issues of project management and minimizing risk. In that paper we stated:

The Cone of Uncertainty for a project describes the uncertainty estimating software development project cost, effort and duration, throughout the lifecycle of a project. The degree of uncertainty is very large at the beginning of the project, which is often when decisions are made about project pricing and contracts. For some projects, this uncertainty can last until much later in the development process, even after working code is available.



The diagram above is also ‘best case' and ‘ideal' in two ways:

The diagram does not show the fact that if an estimate is produced at the outset which is greatly below the actual needed project duration, then the timeframe for all project milestones will shift outward; it will take longer than estimated to perform product definition, identify requirements, etc. At the outset of the project, there is substantial uncertainty about the duration and the timing of events during the project.
The diagram also shows how uncertainty would be reduced in an ideal waterfall project lifecycle, where requirements are understood and finalized early in the schedule (before user design is complete, etc.). However, we all know that the requirements are rarely understood at this early stage, especially for large, complex, novel systems. Quite often, requirements are clarified or new requirements are identified, late in projects, typically only after users are able to interact with a functioning version of the system. We've all run into the "I'll know it when I see It" phenomenon. The one development exception should be in the case of SOA, where the services should be well understood and test cases created before coding beings.

Within EDS we've known since at least the early 90s that waterfall techniques are much higher risk than an iterative approach. Yet it's very difficult to get managers (project or otherwise) to internalize iterative development. It may be because it is difficult to create effective contracting mechanisms, or a reason could be something I saw in article Jim Highsmith from Cutter wrote that stated:

"The perception remains, however, that projects are, or should be, on track early and "off track" late. Agile projects flip that perception since they are often off track early and on track late. This flip is disconcerting because it is different from prior experience. Even though rationally it seems better to uncover problems earlier, the variation from historical norms is still disconcerting, and it takes time to adjust ones thinking. There is an old project management adage that "problems get worse with age," which may be true, but many managers view early problem identification as a "problem" by labeling the project team/manager as making excuses or not "getting with the program."

With well designed agile techniques, you should be trying to focus on the unknowns or long lead time items early, essentially trying to bring problems to light as soon as possible. Looking for projects with little or no issues or risks is likely a pointer to projects without effective project management and leadership oversight. You can use this indicator to coach the team on how to actually mitigate risk.

Charlie Bess
EDS' Next Big Thing Blog