Pattern of the Month: Controlled Failure

There’s an old joke, or perhaps more of a cynical maxim, about why projects so often fail. Known as The Six Phases of a Big Project, it argues that the true project management life cycle runs like this:

1. Initial Enthusiasm

2. Dawn of Reality

3. Panic

4. Blame of the Innocent

5. Rewards for the Uninvolved

You may be more familiar with the following canonical representation:

1. Conception

2. Analysis

3. Design

4. Construction

5. Servicing

Because of linear flow, the above undoubtedly invites comparison with the Waterfall Model. However, it is also possible for similar structures to feature in round-trip methods. Disciplined Agile Delivery and DSDM, for example, are two fairly well-known approaches which position iterative development within a wider narrative context such as Inception, Construction, and Transition, or Feasibility, Foundations, Exploration, and Engineering. It can provide a sense of continuity and reassurance which might otherwise be lacking for stakeholders.

The risks which are incurred by expressing a narrative destiny are political rather than technical. One of the defining characteristics of Agile development is that stakeholders should be engaged frequently on a collaborative basis. They are expected to provide input in the form of business specialists, analysts, and visionaries, and to ensure that these interests are represented through effective product ownership. A good Product Owner can be thought of as a “value maximizer” who inspects progress regularly and uses the empirical evidence of ongoing delivery to decide whether or not it is worth making a further investment. A cozy narrative will count for nothing; what matters is the empirical proof of value through incremental delivery. Should such proof be lacking or inadequate, a Product Owner will not be afraid to stop investing in further Sprints. Although it would be irregular and potentially traumatic to do so, he or she would also be within their rights to cancel a Sprint once it is underway, if it is clear that it cannot meet its goal. That's why cultivating a sense of narrative can be dangerous. It can create the impression that all stakeholders have to do is "push a button" and the development process will trundle along without intervention, with nice reports being generated at major stage gates. The case for effective product ownership, where value must be empirically evidenced and continued investment justified, is consequently weakened.

It’s therefore very important to make it quite clear that strong product ownership is needed throughout an initiative. If sponsorship for this role is absent, then it may be best to suspend or cancel a project until the proper commitment is there.

This technique of preserving resources is often known as Fail Early Fail Fast, Fail Often Fail Cheap, or by similar terms. For the purpose of pattern identification, it can be referred to as Controlled Failure. It’s the avoidance of the “Death March” anti-pattern where, due to an ongoing escalation of commitment, stakeholders become afraid to cancel a project even when failure seems to be inevitable.

A refusal to evaluate progress in terms of empirical evidence leads to the encroachment of a waterfall project by stealth. If that happens, here is how you can expect the “project narrative” - and in effect, a “death march” - to work out:

• Step 1 can be thought of as the canapé and white wine stage. It's when the ink is on a contract between the stakeholders who have stated their vision, and the contractor who (very often) put in the lowest bid. All that is left is for the technical types to push the button and make it all happen.
• Step 2 is when the problem is scoped out in some kind of realistic way. Projections will be made and exploratory prototypes may be developed to firm out requirements. The first noises are heard about the scope needing to be slashed or resources and/or time increased.
• Step 3 is when the big-wigs start to hear about the problems. The evangelists will start to distance themselves from the project so as not to be tainted by association.
• Step 4 is when the big-wigs who never made the jump must salvage their political reputations by blaming others. Morale will plummet and technical types will leave in droves, lowering morale and productivity yet further. This is the death march stage of the project.
• Step 5 is when the failed product has been "delivered." The initial scope will be revised to match the reality of what has been produced. The project will be declared a success, and the politically connected rewarded accordingly.

Canapé and white wine, anyone?

Controlled Failure

Intent: Terminate a project once it becomes clear that it is not viable. Accrued value is retained and project resources are freed for other activities.

Proverbs:

• Don’t throw good money after bad.
• If you’re in a hole, stop digging.
• Failure breeds success.

Also Known As:

• Fail Early, Fail Fast.
• Fail Fast, Fail Often.
• Fail Fast, Fail Cheap.

Motivation: It is important to avoid a continued project investment if it is unlikely to deliver sufficient value.

Structure: A transparent project will support inspection and adaptation. The Product Owner and the Development Team must be able to inspect and adapt the process. At the conclusion of each iteration, a potentially releasable increment must be delivered by the team to the Product Owner (PO). This increment will then be reviewed, the development process considered in retrospect and improved, and future work planned. If the PO is not satisfied that sufficient value is likely to be delivered then he or she may terminate the project.

Applicability: Controlled Failure should always be an option on an Agile project. It may be used when an inspect and adapt opportunity indicates further work will not prove valuable.

Consequences: When a controlled failure is done well, the losses incurred by a failing project should not exceed those resources consumed in the current iteration. However, any failure - controlled or otherwise - may have political repercussions.

Implementation: All projects should be evaluated by the Product Owner with regard to whether or not the intended value is still likely to be delivered. Reviews, Retrospectives, and Planning sessions all represent suitable points at which a controlled failure may be initiated. It is irregular to implement a Controlled Failure before the current iteration has terminated and an increment is available for evaluation. The implementation of controlled failure requires courage. It can be tempting to continue with an unprofitable venture when resources have already been invested in it (see Death March). A controlled failure should secure the release of any value accrued to date, including as much as possible from the final iteration, identify and harness the lessons that must be learned, and free project resources for other more profitable activities.

See Also:

• Pivot
• Forecast
• Fail Fast, Fail Often: How Losing Can Help You Win, by Ryan Babineaux
• Fail often, fail well, The Economist
• The new #Fail: Fail fast, fail early and fail often, The Washington Post
• Fail Fast, Fail Cheap, Business Week