FAILING YOUR WAY TO SUCCESS

How good is “good enough”? For a lot of project managers, the answer is to reject the question: “‘Good enough’ isn’t!” By rejecting the very concept of “good enough,” they strive to take projects to a higher order of excellence, to bring the ideas of quality front and center into the discipline of project management, and to motivate people to achieve their absolute best. These are noble goals, and we salute them.

But the question still lurks in the bosom of the project, and it demands an answer. How good is “good enough”? In this project, three lives are riding on a performance outcome, and the clock is ticking. If perfect performance takes too long, can we afford it? What level of performance will be satisfactory as long as we can achieve it by our deadline?

This doesn’t imply that we intend to squeeze by with minimum performance—not at all. We plan to do our absolute best. But every golfer wants to know what par is, even if he happens to be Tiger Woods.

DEFINING QUALITY

Pontius Pilate asked, “What is truth?” and arguments still rage among philosophers. The project manager’s equivalent question is, “What is quality?” The PMBOK^® Guide definition, taken from the International Organization for Standardization (ISO), is “the totality of characteristics of an entity that bear on its ability to satisfy stated or implied needs.” ¹ In other words, quality is to some extent in the eye of the beholder, and different eyes see and value different things under different circumstances.

In general, ideas about quality are classified as:

• Judgmental—synonymous with superiority or excellence, also known as a transcendent view of quality.

• Product-based—linked to specific and measurable variables, such as the chip speed of a computer.

• User-based—determined by what the customer wants, or fitness for intended use. (If you’re off-roading, a Jeep is superior to a Cadillac, but if you plan to run a luxury limousine service, the Cadillac is more appropriate.)

• Value-based—the ratio of usefulness/satisfaction/other quality criteria to price.

• Manufacturing-based—conforming to requirements or specifications, six sigma defect rates, low allowable variation. ²

Each of these definitions has value and legitimacy depending on context, so definitions of “good enough” and quality must be reached through an understanding of the individual project environment.

Performance Criteria

Our CO₂ filter project, like all projects, is bounded by the triple constraints. It is always vital at the beginning of the project to ensure that you have a good understanding of the project goal and the project context. The initial mission statement, as you’ll recall, is “[I]nvent a way to put a square peg in a round hole—rapidly.” In other words, take the square CO₂ scrubber and figure out a way to make it do its job adequately in the round socket of the LEM. That’s the performance criterion, one of the three triple constraints.

Why “adequately”? Why not “perfectly”? In defining the performance criteria for triple constraints purposes, you should specify the minimum acceptable, not the best possible. We need to know what par is. Once we’ve defined par, we can then define superior performance. Superior performance—quality—is superior only if it adds value.

Let’s look at some “quality” metrics that won’t add value in this particular situation:

• Standardization. In general, having parts conform to standard designs, templates, and toolings is good practice. Here, it adds no value. This is a one-shot effort.

• Durability. Making it good enough to last ten years adds no value. If it breaks ten minutes after splashdown, no harm is done.

• Industrial design. Its attractiveness, visual design, and aesthetic qualities add no value. If it keeps them alive, it’ll be beautiful enough in the eyes of the beholders.

On the other hand, some quality elements would add value and might be worth a bit of extra time if there is some to spare:

• Ensure ease of assembly. Especially as CO₂ levels build up and the astronauts begin to suffer mental impairment, an easy-to-assemble design would lower risk.

• Use fewer parts. Given the possibility of other breakdowns and needs to improvise, consuming fewer scarce resources would be superior.

• Work more efficiently. If the CO₂ filter does a better filtering job or consumes less power, this would add real value.

Time Constraint

We don’t know what the deadline is, but the deadline is nevertheless absolute. The clock is ticking and the CO₂ is accumulating. The astronauts will begin to suffer from impaired judgment followed eventually by unconsciousness and death. We can only approximate how long we have, but it isn’t long and it isn’t subject to negotiation.

If there is a tradeoff to be made between the time constraint and the performance criteria, we know that ultimate failure—the death of the Apollo 13 astronauts—comes from failure to meet the time constraint. That is, if we build a perfect CO₂ filter, but we finish it too late, we’ve still failed. Perfect performance does not compensate for a missed deadline.

But wait! Isn’t the reverse equally true? If you fail to meet the performance criteria, isn’t it irrelevant how quickly you fail to do so? Well, it actually depends on the extent of the failure.

To illustrate, let’s look at this scenario: You’ve managed to come up with an inefficient partial solution that will last only half as long as it’s going to take to get the astronauts back home, but you’ve done so within the original time constraint. Do you take this solution? Absolutely! Even though you have failed to make the performance goal for the project within the original time constraint, you’ve reset the game clock and given yourself a whole new window of time in which to attack the problem anew. With a day or more to work instead of mere hours, your chance of coming up with a solution for the remainder of the problem has become that much better.

In other words, the right kind of failure is not only an option, but sometimes it is a desirable one! We can’t accept a failure in the time constraint, but we can live with a partial performance failure and stay in the game.

Cost Constraint

This project has a zero dollar budget, but it has a budget nevertheless, and it’s a highly restrictive one. It’s a resource availability budget, and it’s highly constrained. It’s the junk on the table—everything that’s loose on the spacecraft that you can adapt to make the filter work.

The problem with the cost constraint is that it’s also an absolute. We have what we have—whether it turns out to be adequate or not. It has nothing to do with how much we value the astronauts or how much it’s worth to us to bring them home; it’s that we don’t have the option to send up as much as a gram extra.

The first issue in analyzing our cost constraint is this: have we found everything we can possibly use? (The final resource tally to build the CO₂ filter included someone’s sock.) Second, have we been as creative as possible in thinking of all possible uses for each item? (Can the cover of the flight plan be used as a stiffener board to hold filter material in place?) Third, can we make do without some component that we don’t have? (Even if it’s customary to screw the device to the wall for security, can we hold it on with a bungee cord instead?)

THE HIERARCHY OF FAILURE

All pigs are equal, George Orwell told us in Animal Farm, but some pigs are more equal than others. All three of the triple constraints are constraining—they limit our options and there are consequences for violating or exceeding the constraints placed on the project. But those constraints are not equal, and we can choose strategically among our ways to fail. We can exploit the constraints that are more flexible and even accept the failures that are less damaging to ensure that we do not fail where failure is not an option.

What is the order of acceptable failure for our CO₂ filter project? Interestingly, the widest options for failure lie within the performance criteria. We can accept something as marginal as partial performance as long as it extends the time constraint. Second in exploitability is the cost constraint. We can exercise our creativity to the utmost and improvise within the constraint. A pair of socks, a report cover, a bungee cord—anything we can draft into service—becomes a resource. But failure is not an option where time is concerned. We solve the problem before they run out of breathable air. Period.

In other words, we define the project by listing the triple constraints in the order of flexibility, from least to most. We must succeed with the driver to call the project a success, and may exploit the flexibility within the other constraints—however much flexibility there may be—to do so. The weak constraint is the one with the greatest capacity for exploitation or flexibility, and the middle, well, is the one in the middle.

Triple Constraints for CO₂ Filter Project

NOTES

1. Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK^® Guide), 2000 Edition (Newtown Square, Pennsylvania: Project Management Institute, 2000). Copyright © 2000, Project Management Institute.

2. James R. Evans and William M. Lindsay, The Management and Control of Quality, Fifth Edition (Cincinnati: South-Western, 2002), pp. 11–13. Copyright © 2002, South-Western.