Cone of uncertainty - how could we delay commitment to estimates in real life?

Question

I am reading a book from Steve McConnell dealing with software project estimations and I do not understand the following statement (my translation, I got the book in German):

An effective organization postpones its commitments until the work to narrow the cone has been done. .. Reasonable commitments can be given in the initial part of the middle phase (approx. in 30% of project progress).

How this can be ever achieved in reality? I mean, in the company, we cannot start working on the project until the contract is in place. The contact is signed with an effort estimated and price, therefore we are already committed to it.

How is this applicable in practice then?

Answer 1

The cone of uncertainty has a few uses, but is most useful when used in conjunction with some other practices. So let's start with the uses in the circumstances you describe.

Cone of Uncertainty when a Commitment is Made

Obviously, you can't delay a commitment that is already made, that's a simple matter of physics (time). Most organizations I've worked with that work in the fixed scope and deadline model who are successful do two things. First, they pad their estimates severely.They are always promising the tail end of the cone of uncertainty. Secondly, they retain some control over the effort they can apply, adding teams and people to the team. It's this second part where the cone of uncertainty comes in helpful for them. You may have heard the adage "adding people to a late project makes it later". This comes from ramp-up time. Adding people to a team or teams to a project slows the project down for a while before it speeds it up, so in traditional project management you usually don't know a project is late until you're too close to the deadline to overcome that slow down. Effectively leveraging burn-up charts and a cone of uncertainty allows you to see that your project is late much sooner - maybe in time to effectively add people or teams.

It is also worth noting that I've never known a successful organization go into a project (and estimate) cold. They either invest a fair amount of Architecture and Design time (I don't know if it's 30%, but it's usually substantial), or they're selling an out-of-the-box solution where they're leveraging past work for this same purpose. In other words, they're investing time and money they hope to recoup later.

Cone of Uncertainty Without a Fixed Scope / Fixed Deadline

This is probably the most common approach I've seen with companies that do contract work. Instead of one big commitment, there are a series of small commitments, like working for 2 - 3 sprints, or, if you aren't using Scrum, maybe a month at a time. I've worked with a number of real companies that do this. The plan might be for an 8 month project, but there are regular checkins and the customer can pull out whenever they like because the teams are delivering usable working software, so it's never a matter of cutting losses. Here, the Cone of Uncertainty sees huge value as you can make forcasts about when certain work might be done and also use those forcasts to pivot on which work is more important.

Cone of Uncertainty with No Commitments

This approach is far more common where the team doing the work is internal to the organization, but I have worked with groups where they are basically on retainer to the client and can use this model. In this approach, the teams have a few measures of success like uptime, reduced manual work, etc that they use to prioritize work. They work with the client to move the needle on those measures. This completely abandons the project model and therefor you don't see burn-up charts and cones of uncertainty coming into conversations as much. However, they do pop up from time to time especially on long-term efforts. For example, I might think that a platform upgrade is going to boost all of those measures a lot, but it will take a few months. Three weeks in, I can use this cone of uncertainty to see if that three months is panning out the way I thought. Maybe it'll take a lot longer because the new version of the platform is just a mess, and choosing to table it while the vendor works the bugs out is a better business decision.

Finally, Your Circumstance

Of course, I don't know what your circumstances are, the type of work you do, or how you write your contracts. These are ways other companies have leveraged this model, but different markets in different countries are more or less open. Further, even if the market runs a certain way, different customers in that market will be all over the place on their tolerance for commitment. When companies try to shift to this approach, I see the most success when they find a customer who is open to try it rather than force it onto a customer and look for a team that volunteers to work this way rather than force the team into it.

Answer 2

I speculate that "commitment" is being used in an indeterminate/ambiguous sense.

We can't postpone commitment - but we can control the resources committed. Most organizations have some gateways that projects have to pass, and those gateways are highly dependent on the "cone of uncertainty". In my organization there is a gateway at the end of the requirements process and a second gateway at the end of the design process. Each of these serves to control how much uncertainty remains in the project. We don't commit full resources until the third gateway; up to that point we've only made tentative commitment. (Our numbers suggest that 2/3 of the cost is after that third gateway).

This also has the effect of "postponing work" until the cone of uncertainty is narrower. We don't begin production until we've completed development.

Taken in that light, the statement is ... kind of obvious...

Our projects are internal; we're not working to a contract, but to an internal stakeholder/obligation. That said, I believe some organizations do similar things - e.g. contract to complete design, with the expectation of a development contract if the design contract is successful, etc.

Answer 3

BLUF

^{Bottom Line Up Front}

how could we delay commitment to estimates in real life?

If an end-to-end estimate up front is required, then one can't delay. If the approach can be changed to an iterative and collaborative way of working, then each iteration is a delay and more estimable.

How is this applicable in practice then?

It's value is in understanding that the less one knows, especially about complex work, the less certain one can be about the future; certainty increases as the work nears completion. Its application varies by approach.

History

Traditional project management is rooted in manufacturing procedures based on Fredrick Taylor and his disciple Gantt. The idea is that by working in phases, where one group of specialists creates deliverables to pass to the next group of specialists, various aspects of the project (especially cost, scope, schedule) can be controlled more effectively. It is very successful in simple domains and has had success in complicated domains. (For domain definitions see Cynefin.)

These ideas have been misapplied to software development resulting in the advent of waterfall due to the misread of Royce's paper Managing the Development of Large Software Systems. Many of the issues have been documented including Fred Brooks' candid retrospective book The Mythical Man-Month, the complexity of a single phase is highlighted in Software Requirements: Are They Really A Problem by Bell & Thayer, and the annual CHAOS Report.

Several approaches were developed in the 1990s to attempt to address these issues: Scrum and eXtreme Prgramming being two of the most recognized. Seventeen people behind these approaches gathered in 2001 to discuss what they were learning and doing. They result was the creation of the Manifesto for Agile Software Development. That resulting philosophy of four values and twelve principles is a summation and general guideline for success.

Traditional versus Modern

When applied in the traditional manufacturing model, the cone of uncertainty acknowledges reality: any initial estimates are very inaccurate. This is why estimate padding is so commonly used; ranged estimates would be more honest and be supported by the cone, but are not seen often as they are not concrete enough for most project management systems or traditional business contracts. Once accepted, emphasis is placed on attempting to document and design everything completely in order to attempt to meet the now contracted expectation or validate the initial estimates. As the project approaches the deadline, projections are usually more accurate as described by the cone. Staffing may be added, requirement (scope) change processes are enforced, and addendum for additional time might be negotiated.

When using modern software product development approaches, each iteration can be viewed as its own project with more predictability. Having a vision and not a rigid plan, the customer and producer working together daily, creating small increments of high-quality and usable software, and continuously reevaluating the customer needs and the effectiveness of the solution are fundamental. These practices result in risks being reduced and estimation becoming more accurate and precise because the cone of uncertainty remains narrow for each short iteration of effort. The cone of uncertainty then becomes a forecasting tool once a relatively consistent pace has been established. The further forward one looks, the less accurate and precise that estimate is.

Answer 4

Dealing with probabilistic results well in any organization requires a high degree of project maturity within that organization. I believe it is very hard to get to a high degree of maturity and then to sustain it once you're there. In my experience, and even with my company that has an intense focus on PM, I have witnessed few, really mature PM capabilities in a company.

Then, you have normal human biases at play that drive us to sort of dismiss or downplay risk in our world, where we end up very optimistic about our future and where we believe we have far more control over the infinite number of work variables that affect outcomes than we really do. So even with a very mature PM organization, these biases never go away.

Finally, in a buyer-seller arrangement, we have other business drivers at play that dictate firm commitments being agreed upon even though it is inconsistent with good PM practices. After all, schedule slips and project overruns typically benefit the seller's revenue, except when you have the right contract to prevent that. That typically means, commitments long before a project starts.