Michael S. Dobson
We only ship to addresses in the USA. Live somewhere else? Please order from our international distributor. Click Here
Product added to carts.
Michael S. Dobson (Author)
Publication date: 07/01/2004
You probably won’t see American Movie Classics run a festival of “Great Project Management Movies” any time soon, but if they did, Ron Howard’s motion picture Apollo 13, based on the real-life story, would be a natural candidate. Faced with a potentially disastrous accident, project teams overcome one potentially fatal barrier after another to bring the crew safely back to the earth, guided by mission director Gene Kranz’ mantra, “Failure is not an option.”
But, of course, failure is an option. Sometimes, in fact, it looks like the most likely option of all. The odds in the actual Apollo 13 disaster were stacked against a happy outcome, and everyone—including Gene Kranz—had to be well aware of that fact. At the same time, letting the idea of failure into your mind can be a psychological trap that leads you to premature surrender.
Within the overall project “Get the astronauts home safely,” there are a number of subprojects, including:
Develop a power-up sequence that draws fewer than 20 amps.
Calculate a burn to get the reentry angle within tolerance using the earth in the capsule window as the sole reference point.
Design a way to fit the square command module CO2 scrubber filter into the round Lunar Excursion Module (LEM) filter socket.
That last subproject is vital, because the LEM’s CO2 scrubbers are meant to take care of the needs of two people for a day and a half, not three people for three days. And nobody ever imagined that the command module scrubbers would need to be used in the LEM, so they were not designed to be compatible. They’re square, and the necessary holes are round. Meanwhile, the CO2 levels have gone up past 8, and at 15 things become dangerous, and eventually deadly. Gene Kranz assigns a project team: “I suggest you gentlemen invent a way to put a square peg in a round hole—rapidly.”
As the engineers gather in a conference room, boxes of miscellaneous junk—everything that’s loose on board the spacecraft—are being dumped onto tables. The project engineer gestures at the stuff and says: “We have to make this [square filter] fit into the hole for this [cylindrical filter] using nothing but that [miscellaneous junk].” The engineers dive in with the right attitude, but for all they know, there isn’t even a solution present on the table. If they’re one 20¢ screw short of what they need, it might as well be a $20 million screw, because either way, they can’t have it.
We understand that a psychological commitment to success is a way to improve the likelihood of achieving it—giving up too easily increases the risk of failure—but that’s not quite enough. How else can we increase the odds of our success? Interestingly enough, when the stakes are high enough, there’s another way to look at “failure” and find an opportunity!
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.
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.” 1 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. 2
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.
Our CO2 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 CO2 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.
Superior performance—quality—is superior only if it adds value.
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 CO2 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 CO2 filter does a better filtering job or consumes less power, this would add real value.
We don’t know what the deadline is, but the deadline is nevertheless absolute. The clock is ticking and the CO2 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 CO2 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.
The right kind of failure is not only an option, but sometimes it is a desirable one.
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.
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 CO2 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?)
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 CO2 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.
PROJECT: Build CO2 filter adapter to allow square CM filters to be used in cylindrical LEM sockets.
—DRIVER: Time Constraint (before the CO2 levels overwhelm the astronauts)
—MIDDLE: Cost Constraint (using only what’s available on the spacecraft)
—WEAK: Performance Criteria (that works well enough to allow the astronauts to live and continue performing their duties for the mission duration)
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.
Explore how to assess a wide range of factors to determine which contract type will provide the government the best value...
Transform your workplace into a well of learning and employee potential fulfilled with the help of this book!
Use past performance to win contracts at the lowest risk and cost
Learn project management processes, tools, and techniques that are scalable and adaptable to small projects.