This new entry replaces an earlier one Sometimes I just get it wrong. Here is an attempt to get it right second time around. This is a supplement to the content of Chapter 4 - Dealing with Uncertainty. The diagram reflects the 4-types of variation identified by De Meyer et al in their article from Winter 2002 edition of MIT Sloan Management Review, Managing Project Uncertainty from Variation to Chaos [PDF].

We can use this model to better understand a system for software engineering in a given market.  Variation is where assigned cause has been eliminated and only chance cause exists within a known and understood system. Foreseen Uncertainty is where there are identifiable risks and understood issues which affect the delivery of the project but the basic market for the deliverable is understood and the business model or go-to-market strategy is understood. However, there is sufficient uncertainty that assignable cause variation will be observed and must be dealt with through aggressive issue log management.  Unforeseen Uncertainty will feel out of control most of the time and what gets delivered won't be exactly what the customer wanted or when they wanted it. This could be because the software development is happening with a new paradigm of tools or method - when teams start using MDA or DSLs for example - but it may also occur in new markets where the business model is not understood and the degree of variation cannot be predicted. The answer is to iterate frequently and plan adaptively. It is primarily this class of project which Doug DeCarlo addresses with his Extreme Project Management method. Finally, there is Chaos, the land where we don't know what we don't know and we are trying to find out - neither the market, the business model, the customer base, the product features, or the technology are understood. It's the land of research projects.

From a project management perspective, knowing where our project lies in this continuum is important for setting expectations. With Variation we can simply create a common cause buffer based on existing process control limits. With Foreseen Uncertainty, we create a risk management plan which may contain some mitigation approaches which amount to further buffer. In some industries this is called insurance. Insurance works just like common cause buffering but the aggregation is at a higher level. Say for example, a risk mitigation was to bring on more staff to a project, then those staff must be coming from a pool of people elsewhere in the organization. In other words, the wider organization is underwriting the insurance for the project. Unforeseen Uncertainty is a land of high risk - we don't know what we know, or our system is not understood. Playing in this categorycould also be called gambling. As every gambler will tell you - you win some and you lose some. Many VC's will tell you that they lose up to 19 for every one they win. The Unforeseen Uncertainty category is the land of venture capital. Finally, Chaos is a land where only the research budget should venture. It's extreme gambling. It's adventure rather than merely venture. It's a world where you assume you lost your money and nothing got delivered. Delivery is a bonus. It's like winning the lottery. The project management objectives for Unforeseen Uncertainty are simple - try to move the project into the Foreseen Uncertainty quadrant before the money runs out - then ask for more. With Chaos it is similar - try to move the project into either the Unforeseen Uncertainty or Foreseen Uncertainty quadrants before the money runs out. It is unreasonable to buffer a plan in the lower half of the diagram - a not understood market. It simply costs too much. Better not to buffer, but to get as far as you can with what you've got and demonstrate that you've moved to a world of greater certainty before asking for more resources. Iterative projects with adaptive planning is the name of the game.

It's easy to see from this chart that the more uncertain, the greater agility is needed to react to change. In the lower half, the iteration cycle must be short, the feedback loop very tight. By understanding where our project lies in this uncertainty continuum we can make decisions about what represents the best iteration cycle and make informed guesses about how much we want to invest in requirements and analysis versus code, test and refactor.