How to Accomplish an Impossible Project

In my upcoming book Project: Impossible, part of Multi-Media's Lessons from History series, I lay out a methodology for dealing with a project that appears to be operationally impossible (that is, it can’t be accomplished within the initial boundaries of time, cost, and performance).

Other questions matter, too:

1. What are the consequences of failure to meet the original requirements?
2. Are there unacceptable negative consequences if we succeed?
3. Could trying make things worse?
4. How much risk should we be willing to take in achieving our goals?
5. What are all the things that have to happen to allow us to call it success?
6. How can we prepare our organization or team to be ready when the impossible project appears?

Except for number 6, the other questions can’t effectively be asked until you have the project (or hot potato as the case may be). And as we’ve seen time and time again on our historical journey, it’s what you do beforehand that often spells the difference between success and failure.

To do the impossible, it helps to be prepared. Preparation starts long before the impossible project swims into your field of view. Whether you and your organization will be able to rise to the challenge often depends on the strength and quality of your preparation.

In the television (and movie) series Mission: Impossible, the Impossible Missions Force (IMF, not to be confused with the International Monetary Fund) takes on challenges far beyond the capability of lesser organizations. How does it do that? First, it selects highly skilled people and provides training in the specifics of espionage. Second, it promotes a high degree of morale and esprit de corps. Members of the IMF see themselves as the best of the best.

Third, and possibly most important, the IMF enjoys a high degree of political support and cover for its operations — at least in the television series. In the case of the movies, it’s more often the case that the problem lies in their own management, and as a result, the movie plots normally involve the IMF team acting without the support of its covering organization. This makes the situation far more perilous, and if it weren’t for the magic of the motion picture experience, those projects more likely would turn out to be actually impossible.

Sometimes a project is impossible for a good reason. In other cases, the project isn’t what it seems. Practice looking at the situation through someone else’s eyes. Play the “what if” game. Look around you. Question the constraints.

And always accept that you don’t know everything.

A New Approach to Qualitative Risk Management

This week’s Sidewise Thinking post is hardcore project management, for those of you who are interested in that sort of thing. The chart and approach to qualitative risk analysis comes from my recent AMACOM self-study sourcebook, Project Risk and Cost Analysis, but the words are original to this blog piece.

Qualitative risk analysis as expressed in the PMBOK® Guide has always given me a headache. The definition is confusing and badly written. That’s not just my opinion, it’s the common experience of lots of people taking project management seminars. (Certainly it's true of my seminars, but I’ve seen many other trainers struggle with this as well.) The problem isn’t with the individual tools. They are easy enough to understand and apply, and the utility is reasonably obvious. But when you look at the similarities and difference between qualitative and quantitative risk analysis using the official PMBOK® (11.3, 11.4) definitions, some problems arise.

·      Qualitative risk analysis is the process of prioritizing risks for further analysis by assessing and combining their probability of occurrence and impact.

·      Quantitative risk analysis is the process of numerically analyzing the effect of identified risks on overall project objectives.

When people first encounter this, the response is a great big "Huh?" I don't really blame them. Here's why.

To see the problem in PMBOK, start with the most obvious difference between the two types: quantitative risk analysis uses numbers and qualitative risk analysis uses "prioritization." In practice, these amount to the very same thing.

How do you value a risk? According to the book, you multiply its probability of occurrence by the impact should it occur, expressed by the formula R = P x I. For example, a ten percent risk of losing a thousand dollars turns into 0.1 x $1,000, or $100. If the cost of dealing with that risk is less than $100, it’s clearly a good investment. (It’s always worth noting that the reverse isn’t necessarily true. Spending more than $100 may well be a good idea, but you may have to prove it.) That's the quantitative way.

In the qualitative approach, according to PMBOK, you might say the probability is LOW and the impact is, say, MEDIUM (depends on the size of the project). You look on a grid to see where the terms intersect (usually LOW). But that's the same thing as saying LOW x MEDIUM = LOW, or P x I again.

In other words, the “numerical analysis of effect” and “combined probability and impact” are, for all practical purposes, synonyms — the very definition of risk says so. That creates a lot of blurring between the two processes, especially in terms of their utility. No matter which technique you use, you end up with a priority ranking of your project’s risks. (You also get analytical data about those risks.) Then you move on to risk response planning.

Prioritizing risks gives you only a two-dimensional sort: higher or lower. That’s quantitative risk analysis — whether you use actual dollars and percents, or whether you use a scale of high, medium, and low. You rank the risks into a numerical hierarchy. And that's it.

Prioritizing risks isn't nearly all you need to be doing. In this post, I want to give you a new way to think the two kinds of risk analysis.

You need to organize your list of identified risks in three dimensions, based on the initial choices you must make. Some risks require more rapid response than others, severity notwithstanding. Some risks affect the project but aren’t yours: they may belong to the customer, your boss, or other departments in the organization. If you’re running an IT project and you identify legal risks, you probably should route those risks to the general counsel rather than deal with them yourself. Some risks have solutions — and others have no solution at all.

Using the accompanying chart, let’s look at those choices.

IMPACT: The first gateway is to examine a risk’s impact. Forget probability: if the impact is low enough, you’re done with the risk. If the cost of the risk if $50 and the project is $5 billion, it’s irrelevant whether it happens or not. Granted, first impressions can be deceiving and the impact of a given risk can change over the lifespan of the project, so you don’t want to throw this list away.

PROBABILITY: Only then should you think about the probability of occurrence. If you are lucky enough to have real numbers, good for you. More often, you’ve got a vague idea (it’s pretty likely to happen, or maybe it’s very unlikely) or you don’t have any idea at all about the probability.

Here’s where you deal with the R = P x I formula, whether you’re using 0.1 x $1000 or a high, medium, and low scale from a table (Low x Medium = Low). And yes, when determining impact, you have to extend your vision from the impact on the work package to the impact on the project as a whole, and from there to the impact on outside people and organizations.

At the end, you put more risks on the parking lot. Perhaps the impact is serious enough to be noticed, but the probability is ridiculously remote. You make sure that the risks that get further action are the ones with the highest net value.

According to PMBOK, you're done — but you aren't.

URGENCY: Risk responses follow the Godzilla Principle: baby problems are easier to deal with than full-grown problems. The available set of responses to a given risk tends to deteriorate over time. Even if some risks have higher value, you need to move urgent risks to the front of the queue. It’s less important whether the risk event is coming up soon; the key question is when your solutions expire. So we’ve already violated the priority order we established in the previous step — another tip-off that prioritizing risks by probability and impact isn’t nearly enough to do the job.

OWNERSHIP: If there’s no reason for a risk to jump to the head of the line, we go back to the prioritized list of risks, but with another question: do these risks fall under the jurisdiction of the project manager or team? As we noted, legal risks usually belong to the legal department, rather than, say, IT. Other risks may fall generally into our project, but if the impact is great enough, higher levels of the chain of command usually get the final say-so.

Transferring risk, in other words, often doesn’t wait until risk response planning — when we need to pass the buck, we pass it early in the process. Of course, we’re often responsible for providing information and options to the people who own the decision, and sometimes responsible for implementing the solutions they devise, but the key question of ownership has already been settled.

ACTIONABLE: Our remaining pile of risks shrinks with each step, but before we start on the process of planning our risk responses, there’s still one more sort that needs to be done. Do these risks have answers? In other words, can we find a potential proportionate and cost-effective response to the risk that doesn’t create serious negative consequences as a side effect?

If the answer is yes, we have our tentative risk solution. We accept the risk and move forward to risk response planning.

ACCEPTABLE: If the answer is no, we have a decision to make. We can decide to accept the risk

Maybe we add something to the contingency allowance for dollars or time. Maybe we come up with a recovery plan. But either way, we move forward.

But if the risk is too serious, moving forward may be a very bad idea indeed. We have to re-think the project. Maybe we modify it. Maybe we cancel it. Either way, we’re no longer going ahead with the original vision.

* * *

No matter what approach we use, we plan risk responses for some risks, but not all of them. In the PMBOK model, we plan risk responses based on the priority of the risk. As you’ve seen, however, that’s not enough. Think of qualitative risk analysis as the overall process of sorting risks not merely by P x I, but by the nature of the initial actions you should take.

     Is it SERIOUS? If not, accept it.

     Is it LIKELY? If not, accept it.

     Is it URGENT? If it is, act on it now.

     Is it MINE? If not, transfer it.

     Is it ACTIONABLE? If so, act on it.

     If not, is it ACCEPTABLE? If not, rethink the project.

In re Zimmerman

Stages of a Project

In project management, we frequently say that the stages of a project go like this:

1. Enthusiasm
2. Disillusionment
3. Despair
4. Panic
5. Search for the Guilty
6. Punishment of the Innocent
7. Praise for Non-Participants

The key problem comes in Step 5, “Search for the Guilty,” as opposed to the alternative, “Fix the Problem.” The overwhelming need to punish the offender outweighs the need to fix the problem.

In re Zimmerman

These days, I’ve mostly sworn off political topics. I hate that I’ve lost friends that way. But the shooting of Trayvon Martin by George Zimmerman also raises issues relevant to project management, cognitive bias, and fallacies of logic, all of which are legitimate subjects of this blog.

As is too often the case in any sensational media matter, the professional outrage machinery is in full swing. The most extreme and definite opinions on both sides receive the majority of coverage, even though they are a minority of the population, and in response, both defenders and accusers try to delegitimize the comments and opinions of those who disagree.

My goal in writing this is not to start an argument about the relative culpability of either Zimmerman or Martin — and in fact, I’d vastly prefer not to have one. There are many other places you can go to have that argument. Right now, let's look at the nature of those opinions.

In the case of Zimmerman — or, for that matter, any criminal suspect — there are four separate questions:

1. Should Zimmerman be suspected?
2. Should Zimmerman have been arrested?
3. Should Zimmerman be put on trial?
4. Should Zimmerman be convicted?

The Decision Hierarchy

Decision-making processes are normally hierarchical. There are earlier, tentative decisions we make before we reach our final conclusion. Should we, for example, do a particular project? The initial decision may be to do a feasibility study, or a pilot test. Only when those results are in will we make our final choice and commit resources to the solution.

The legal concept of level of proof is particularly meaningful. Depending on the stage of the process, different levels of proof are required to support a given decision.

Should Zimmerman be suspected? The legal standard for suspecting someone of a crime is a low bar: reasonable suspicion. This standard is based on "specific and articulable facts", "taken together with rational inferences from those facts," to distinguish it from an "unparticularized suspicion" or a hunch. In Zimmerman's case, there's no real doubt that Zimmerman shot Martin. Even Zimmerman admits as much.

In project management, a related question is whether the environment contains opportunities or problems worthy of addressing. Coming up with a target list doesn't mean you've made a final decision, so the burden of proof is low.

Should Zimmerman have been arrested? The standard for an arrest is probable cause. That standard is higher than "reasonable suspicion," but much lower than the standard required for a criminal conviction. The best-known definition of probable cause is "a reasonable belief that a person has committed a crime." Another common definition is "a reasonable amount of suspicion, supported by circumstances sufficiently strong to justify a prudent and cautious person's belief that certain facts are probably true." 

This question, not the question of whether Zimmerman is ultimately found guilty, is the core of the current controversy. Frankly, had Zimmerman been charged and tried at the time — even if he were subsequently acquitted — it’s hard to believe that this case would have ever achieved national prominence. It’s not exactly as if shootings are an uncommon occurrence in the United States.

"Probable cause" also has a role in project management. Feasibility studies aren't free, so you have to pick your shots. Establishing a proof level equivalent to "probable cause" helps you focus on the issues that matter most.

Should Zimmerman be put on trial? Prosecutors can bring charges based on no more than probable cause, but a grand jury, which reviews the case prior to trial, is supposed to make its judgment based on the preponderance of the evidence, that is, whether is charge is more likely to be true than not true. Prosecutors also have the benefit of a more comprehensive investigation than is normally performed at the time an arrest is made. The additional information may well alter an initial determination.

A full-fledged project is the equivalent of a trial, because you have to do all the work, and in the process, you may discover surprises and risks not part of the initial process. The initial project plan rests not on final determinations, but rather on the preponderance of the evidence available in the initiating and planning stages.

Should Zimmerman be convicted? Depending on the charge, two standards may apply: clear and convincing evidence, or proof beyond reasonable doubt. The first standard applies in some civil cases; the second in criminal cases. Zimmerman clearly falls into the second category. Our adversarial legal system is designed to put the strongest burden on the shoulders of those who would convict someone of a crime.

There is a final standard of proof, proof beyond a shadow of a doubt, but that is often an impossible burden to meet, so that standard doesn't apply in a criminal case. Indeed, given that there are only two people with full knowledge, and one of them is dead, the "shadow of doubt" may never be completely eliminated.

At the end of the project, the results must necessarily speak for themselves. Did you solve the issue that led to the project? Perhaps clear and convincing evidence is all you need, but sometimes a higher burden of proof rests on the project manager.

Justified and Unjustified Opinions

If there's one fundamental American right, it's the right to an opinion, but not all opinions are equal. To have a legitimate, justified opinion, you need to have some actual facts and apply an appropriate standard of proof. As long as you're clear about what stage of the decision is currently on the table, saying "yes" to one level doesn't necessarily equate to a final determination.

In an imperfect world, armed with imperfect knowledge, we cannot escape the reality that we must necessarily make some decisions and hold some opinions in advance of all the facts. And that raises the question about what makes an opinion justified and legitimate.

It's often argued that [insert side of the argument] has already convicted [Zimmerman] [Martin], rather than wait for the judicial machinery to work its course. And, of course, some extremists have already rushed to final judgment on the matter. But the vast majority of us have not.

That doesn't mean judgments, even in preliminary stages, are inappropriate. As noted, there's no reasonable doubt of the basic fact that Zimmerman shot Martin. It's hard for anyone to argue that the police should not have looked into the matter.

Can a "prudent and cautious person" reasonably conclude, at this stage of the investigation, that Zimmerman should be arrested? Clearly, the answer is yes. Even without the discredited claim of a racial slur, the 911 call, in which Zimmerman disregarded the recommendation of the dispatcher not to get out of his car, casts a "reasonable amount of suspicion" on Zimmerman's actions.

Does the preponderance of the evidence lean in favor of putting Zimmerman on trial? The Florida prosecutor assigned to the case has determined the answer to be yes, so it's not unreasonable or unjustified for an outsider to agree with it.

It's possible, and even legitimate, to have a definite opinion on the questions of arrest and trial. It's much less justified to have a definite and final opinion about Zimmerman's ultimate guilt. The standard of "reasonable doubt" has not yet been overcome, and will not be until all the evidence — including evidence presented by the defense — is out in the open.

The claim is often made that Trayvon Martin's supporters have already convicted Zimmerman, but that's an exaggeration. It's true that Martin's supporters have generally concluded that Zimmerman should be arrested and tried, but those opinions are valid at a much lower standard of proof. It's not "convicting" Zimmerman to argue that the evidence supports arrest and trial.

Bias and Judgment

When it comes to the final decision, a prudent person should be cautious. You not only need evidence, but the evidence itself often needs to be challenged and validated. But that doesn't mean you can't hold a preliminary opinion, as long as you're willing to modify it in the face of persuasive information to the contrary.

If you rate opinions about Zimmerman on a scale of 10 (certain he's guilty) to 0 (certain he's innocent), people with scores of 10 or 0 are clearly making decisions ahead of the facts. For such people, the outcome of a trial will mean nothing: if the verdict goes their way, they knew it all along, but if the verdict goes against their opinions, it will mean that the trial was rigged and thus invalid. People who are unwilling to revise their opinions in the face of new facts aren't reasonable. Fortunately, their number isn't large.

More common is people whose opinions are 8-2, strongly convinced of Zimmerman's guilt or innocence, but not so locked into their positions that persuasive contrary evidence is incapable of changing their minds. People in this category need to be extremely careful of the actions of cognitive bias in their information processing and decision process. Even if you are trying to be open-minded, once a mind's made up, inertia takes hold. Change is difficult.

People with opinions in the 4-6 range are in less danger from cognitive bias, because their opinions are inherently more tentative. In my case, I am not paying detailed attention to the story, because of the general unreliability of most of what's published at this point. That's not the same as saying I have no opinion, or that I don't lean toward one side, but I'm fully aware that the eventual factual record may not support my tentative ideas. Even so, cognitive bias can have its effects even on people of more moderate opinion, so it's important to stay on one's guard.

But that's opinions about Zimmerman's guilt. Opinions about arrest or trial fall into different standards of proof.

The Process of Proof

After watching innumerable crime shows, we all should have a pretty good idea how the police and trial process is supposed to work. When it goes according to plan, it does a reasonably good job of establishing a factual record in support of a decision. Of course, your mileage may vary.

Even if the story seems straightforward at first glance, investigators still go through the process of reconstructing the story, gathering physical evidence, and taking initial testimony. Raw evidence, of course, is of little use until it’s processed — the body examined, witnesses interviewed in detail, a timeline reconstructed, DNA tests performed, etc. In processing evidence, investigators create a story, a timeline of events and people that ideally reveals the truth of a situation.

Stories, of course, always begin as outlines, and as they take shape and form, you can fill in greater detail. Sometimes, stories surprise you, and you find yourself in an unexpected place. Minor characters (“persons of interest”) become suspects — people with motive, means, and opportunity. Some suspects are ruled out as the process moves forward; other suspects are eventually charged with a crime.

But all that assumes police and prosecutors are doing their jobs properly. To me, the most important question is not whether George Zimmerman committed second degree murder in the shooting of Trayvon Martin, but whether he should have been arrested in the first place.

What's the Real Problem?

Questions about the process will probably not be part of the trial, because it’s Zimmerman, not the police department, who is its subject. One hopes that the Justice Department investigation will address these matters. Again, I don’t claim to know the right answers. But as a management consultant, my job is to ask the right questions. Here are some things I'd like to know.

First, was the behavior of the Sanford Police Department appropriate? To measure "appropriate," consider the following: Did the department follow established protocols? Were those protocols adequate to the situation? Did any special circumstances make it more difficult to follow the protocols? What can we do about that in the future?

If protocols were not followed, why not? Are there management or organizational issues, problems with internal culture, changes in the environment, or other factors? And if so, what can we do to address those issues? Even if the more serious allegations of political interference by Zimmerman’s father (a retired Virginia magistrate) or charges of institutional racism turn out to be true, the reflexive “search for the guilty” is a much less effective response than fix the problem.

Wasting a Crisis

I have a stronger opinion about process in this case than I have about guilt. One of the facts of management consulting is that if you have a really bad outcome, you need to adjust your process as necessary to keep it from happening again.

The Sanford police were, no doubt, shocked at the public response and degree of national interest. Regardless of the assignment of fault or blame, they have to adapt to the new reality that their work will receive increasing scrutiny in the future. The 1982 Chicago Tylenol murders were clearly not the fault of the manufacturer, but the ubiquitous tamper-evident seals on all that we eat or drink date from that crime. And if they truly are at fault, then there’s all the more reason to work harder and better in the future.

Too much emphasis on determining guilt can, unfortunately, detract from the more important matter of change. In the cognitive biases series, I covered my version of the “Semmelweis Effect," the reality that peoples’ views harden when you accuse them of terrible crimes. Moral indignation can backfire, and that does no one any good.

Because it’s so easy to identify the most inflammatory and outrageous pieces on either side, it’s equally easy to miss the large amount of reasonable, proportionate commentary—also on both sides. A crisis, as has been noted, is a terrible thing to waste. That doesn’t mean we want a crisis or welcome it when it comes, but if we waste the crisis, we’re often doomed to experience it again. That’s the worst possible outcome.

It’s clear that something went terribly wrong in the Trayvon Martin case. Less clear is what went wrong, and the purpose of trial and investigation is to establish the narrative in an authoritative manner. Whether the trial and investigation accomplish that goal remains to be seen.

But it’s truly the most important part of the matter. Because once we answer that question, we can move forward to the two questions that matter in the long run:

• Why did it happen?

• And how can we keep it from happening again?

Why Projects Fail

The following piece is from my book with Ted Leemann, Creative Project Management, published in 2010.

 * * *

If project management is so good, why do 70% of all projects, including those led by experienced and capable project managers, fail to get done within the Triple Constraints of time, cost, and performance — or in layman’s language, on time, on budget, and to spec?

Here are a few instructive examples.

• In 2006, a $400 million purchasing system for Ford Motor Company was simply abandoned.

• Software errors in a UK Inland Revenue system resulted in a $3.45 billion tax-credit overpayment.

• The infamous automated baggage system at Denver International Airport burned through $250 million before being abandoned as unworkable.

• The Department of Defense’s $6 billion Kinetic Energy Interceptor program was terminated in 2009 after it was determined that it would not achieve its goals.

That’s not all. Let’s look at some numbers on project performance.

The Standish Group has tracked project performance since 1994. Every two years, it issues the CHAOS Report. In the 2009 CHAOS Report, they reported these abysmal numbers:

• 32% of projects were delivered on time, on budget, and with the required features and functions.

• 44% were finished either late, overbudget, or only partially completed

• 24% failed altogether, and were cancelled or abandoned.

There’s good news and bad news here. The good news is that in 1994, when the Standish Group began tracking, only 16% of projects succeeded in meeting the trifecta of the Triple Constraints (on time, on budget, to spec). On the other hand, the 2009 report shows that there’s been a downtick in success (34% to 32%) and a significant uptick in failure (from a low of 15% to today’s 24%).

For challenged projects, those that succeed in some elements and fail in others, the good news is that average budget overrun has dropped from 180% to only 43%. On the less positive side, time overruns have gone up 30%, and the percentage of features that made it into the final product has dropped from 67% to 52%.

During this time, nearly 260,000 project managers earned the prestigious Project Management Professional (PMP®) designation from the Project Management Institute (PMI). But the track record of improved project performance is lackluster at best.

What’s going on?

A significant amount of study and reporting has attempted to discover the reasons for these failures.

• The 1998 Bull Survey, conducted by the French computer company of the same name, identified the major causes of IT project failure as a breakdown of communications, a lack of planning, and poor quality control. 

• KPMG Canada, in 1997, identified the core issues as poor planning, weak business case, and a lack of top management involvement and support. 

• The Standish 1995’s Chaos Report named incomplete requirements and lack of user involvement. 

• The OASIG Study, also published in 1995, cited lack of attention to the human and organizational aspects, poor project management, and poor articulation of user requirements.

But poor planning, weak business case, and inattention to human and organizational aspects aren’t causes, but rather symptoms of a much large systemic shortcoming.

Treating the symptoms isn’t the same as treating the underlying medical conditions. We know some of the root causes. People with poor interpersonal or team leadership skills and stakeholder conflict create friction in the project environment, and friction increases inefficiency and waste. The mass and complexity of the organization increases its moment of inertia, and getting anything to move takes enormous effort. People come and go, missions mutate, information goes missing, and that increases entropy, the tendency to move from order toward chaos.

Things fall apart.

It’s been said that there are only two reasons for project failure:

1. Things that happened that nobody thought of and that they accordingly didn’t prepare for.
2. Things that happened that everybody knew was going to happen, but nobody did anything about.

How often have you experienced project problems because something came along halfway through your project and they had to pull two people off the team ? How about someone wanting a major change in one or more of the triple constraints when the project is  three-quarters completed? Somewhere in your project environment, there’s probably some recurrent problem that happens every single time. Things take longer than you expected. Not everybody is really on board. There’s always a layer of technical complexity no one expected. Important people don’t really know what they want, or expect you to figure it out magically.

But do you account for these situations in your project planning? For a few outstanding project managers, the answer is at least a partial “yes.” For most of us, the answer rests somewhere between seldom and never.

Maybe it’s something you can’t afford to recognize officially because the organization’s in denial. But maybe it’s something in your project management blind spot.

If you take the list of reasons from the studies above, you can boil them down into the following four (seven, if you count clauses) often unasked and unanswered questions:

• Why are we doing this? (Business case)

• Who has an interest in what we’re doing, and what do they each want and need? (Human and organizational aspects)

• What do we have to do, and how are we going to do it? (Project management, including planning and quality control)

• Who needs to be involved, and in what way? (Top management and user involvement and support)

The official standards of professional project management are designed to make sure these issues get appropriate consideration. But let’s face it — these are pretty obvious. It shouldn’t take a PMP to grasp these concepts.

And all too often, having a PMP doesn’t mean someone does.

Project: Impossible — The Savior of Mothers

Dr. Ignaz Semmelweis

My 26th book will be Project: Impossible, an exploration of how people achieved goals any reasonable person would have thought impossible. This week, the story of the Doctor's Plague.

Childbed Fever

The advent of hospitals and the establishment of obstetrics as a medical discipline had an unanticipated side effect: a dramatic increase in cases of puerperal fever, commonly known as childbed fever.

It was a horrific disease. Death rates for all women giving birth in hospitals ranged from 20-25%. From time to time, there were epidemics of the disease, with death rates approaching 100%. Famous victims included the mother and two wives of Henry VIII and famous feminist and mother of the author of Frankenstein, Mary Wollstonecraft. (Today, puerperal fever is known to be a collection of several different diseases, including endometriosis, routinely treated with antibiotics, though it still occasionally results in death.)

The advent of pathological anatomy as a medical practice correlated strongly with the increase in cases of puerperal fever, though this link did not become clear until much later.

Childbed fever deaths spiked at the Vienna hospital, where pathological anatomy was performed, but not at the Dublin hospital, which did not practice it.

Paging Dr. Semmelweis

As the 19th century opened, the crown jewel, the largest hospital in the world, the center of medical practice in 18th Century Europe was the Allgemeines Krankenhaus der Stadt Wien, the Vienna General Hospital. Ignaz Semmelweis, newly admitted to the practice of obstetrics, spurred by the recent death of his mother, became obsessed with childbed fever.

The obstetrics department had two clinics: the First Clinic, staffed by doctors, and the Second Clinic, staffed by midwives.  Women often pleaded to be admitted to the Second Clinic rather than submit themselves to the care of doctors. Their fear was well founded, as there was a dramatic difference in mortality rates between the two clinics.

The First Clinic, staffed by doctors, had a death rate from childbed fever as high as 16%, but the Second Clinic, staffed by midwives, had a corresponding rate as low as 2%.

The most common theory was that the disease was simply a general miasma, just one of those things. It was nobody’s fault. Especially not the doctors.

An unhappy accident pointed Semmelweis to the answer, when his friend and mentor Professor Jakob Kolletschka died suddenly. The symptoms and progress of his disease were identical to childbed fever. It turned out that Kolletschka’s finger had been nicked by a student with the same knife that was being used in the autopsy. Somehow, contact with the corpse during the autopsy had led to the disease.

And it was in the performance of autopsies that the doctors of the First Clinic differed from the midwives of the Second Clinic.

Cadaver Particles

Ignorant of microscopes, microbes, and the germ theory of disease, Semmelweis could only observe one fact: that there was a connection of some sort between the cadaver and the death of Kolletschka, and by extension, between the cadavers used in pathology to the deaths of the childbed fever victims. What the agency of infection was, Semmelweis did not know and had at the time no way of finding out. He referred to them as “cadaver particles,” although he could not see them, measure them, or learn much about them directly.

But that didn’t mean he couldn’t come up with a treatment. What distinguished cadavers was the putrid smell, and what got rid of the putrid smell was a solution of chloride. In May 1847, Semmelweis embarked on a clinical experiment by placing a dilute concentration of chlorine at the entrance to the obstetrics ward and insisting that everyone who would touch a patient washed in it.

Today, of course, cleanliness for physicians is a matter of routine, but at the time, this was a radical break with traditional practice. Most Europeans at the time felt that a few baths a year were sufficient, and doctors were no exception. In fact, the blood-stained frock was a sign that a physician was hard working and professional. If doctors scrubbed themselves, who would know how hard they worked?

Against the criticism, however, the statistics spoke loudly and clearly. Semmelweis began his handwashing process in May, and by June the drop in puerperal fever was dramatic. First Clinic death rates fell to Second Clinic levels.

Change in death rates from childbed fever following the introduction of handwashing.

You’d expect that to be conclusive, but that turned out not to be the case.

The Semmelweis Reflex

Elsewhere in this blog, I’ve written about the Semmelweis Reflex, originally defined as “the automatic rejection of the obvious, without thought, inspection, or experiment.” As I've argued, what triggers the Semmelweis Reflex, however, isn't new knowledge per se,  but the implied criticism of previous behavior that results.

To accept the Semmelweis approach, doctors had to also accept the idea that they themselves had been responsible for the deaths of thousands of women. Who wants to think of himself or herself as a killer, however inadvertent? It’s not surprising that there is a human tendency to reject or challenge scientific or other factual information that portrays us in a negative light.

You don’t have to look far to find contemporary illustrations, from tobacco executives aghast someone dared accuse them of making a deadly product to the notorious Ford Motor Company indifference to safety in designing the Ford Pinto. The people involved weren’t trying to be unethical or immoral; they were in the grips of denial triggered by the Semmelweis Reflex. This denial was strong enough to make them ignore or trivialize evidence that in retrospect appears conclusive.

There was a dramatic reaction against Semmelweis and his theory by the medical establishment, both in Vienna and elsewhere. Puerperal fever is now known as the “Doctor’s Plague,” because it was a case in which medical treatment made things worse — a lot worse. Semmelweis himself was terribly shocked and depressed to realize that it was his own actions that had resulted in the deaths of many women. And if Semmelweis was shocked, one can only imagine the reaction of other healers to being told that they were in practice, if not in intent, killers.

 Semmelweis continued to make things worse by attacking those who criticized his work. He accused his fellow physicians of murder and worse, and his own behavior became increasingly erratic. Showing increasing signs of mental illness and breakdown, his wife committed him to an asylum in 1857, where he died under mysterious circumstances.

Rembrandt, The Anatomy Lesson

Managing the Impossible Project: Inertia and Friction

Semmelweis succeeded in his “impossible project” to determine the basic cause and treatment of childbed fever, but failed to win widespread support for his ideas at the time. It would not be until the latter part of the 19th Century that the germ theory of disease became widely accepted.

If we consider Semmelweis’s project to be identifying the cause and treatment of childbed fever, he was a remarkable success. As noted, he was much less effective in gaining widespread acceptance for his ideas.

The natural human resistance to new ideas and the role of persuasion and influence management in achieving change are a constant source of frustration — and sometimes despair — for leaders of all stripes. It may help to extend our scientific metaphor and describe the obstacles in light of physics: people and organization, no less than other objects in the real world, are subject to inertia and friction.

Whatever the etiology of the Semmelweis Reflex, the idea of resistance to change is well established in management literature, and it’s just inertia under another name. A body at rest tends to stay at rest until acted upon by an outside force. The good news is that if you can just get the motion started, inertia changes from your enemy to your friend and helps sustain the motion.

Friction, of course, is one of those “outside forces” that hamper inertia. Moving parts have friction, and friction results in the degradation of useful energy. In the human sphere, we’ve all witnessed the results of friction in every human encounter. In mechanics, one way to lessen the effects of friction is through lubrication. The discipline of emotional intelligence, good manners, politeness, and office politics all work to lessen the friction in organizational interaction. It’s just as much a part of the job as the technical work, and leaders ignore it at their peril.

Project: Impossible — Lindbergh Wins the Orteig Prize

My 26th book will be Project: Impossible, an exploration of how people achieved goals any reasonable person would have thought impossible. Here’s a summary of some of the cases covered in the book.

Charles Lindbergh's Flight

What’s impossible about Lindbergh’s famous flight is not that he made it from New York to Paris. That was going to happen within a few weeks anyway. No, what’s impossible is that the underfunded and unknown Lindbergh jumped ahead of highly qualified and lavishly funded competitors.

The Orteig Prize

Crossing the Atlantic by air wasn’t new. The Curtiss NC-4 flying boat did it in 19 days back in 1919, hopping in 50-mile jumps between pre-positioned ships. The following month, British aviators Alcock and Brown flew nonstop from Newfoundland to Ireland. A month after that, the British airship R-34, carrying a crew of 31, made the first lighter-than-air round-trip crossing.

In 1919, French-born New York hotelier Raymond Orteig decided to offer a $25,000 prize the first aviators to fly non-stop from New York to Paris, in either direction.

The first serious attempt at the prize came in 1926, when Frenchman René Fonck crashed on takeoff, killing two. Admiral Richard E. Byrd, famous polar explorer, announced his entry in late 1926. Clarence Chamberlin, practicing for the attempt, set a world endurance record by circling New York City for over 50 hours. From the other side of the Atlantic, Nungesser and Coli readied their Levasseur biplane L'Oiseau Blanc (The White Bird).

By early May 1927, the Chamberlain and Byrd groups were ensconced at adjoining airfields on Long Island, and Nungesser and Coli were getting ready in Paris.

Anyone who thought they’d come in and beat that field was surely a fool.

The Flying Fool

Charles Lindbergh had many nicknames, but the one he despised was given him by the New York Sun: “The Flying Fool.”

He responded, “I take no foolish risks and study out everything I do in the air. I don’t think I am a flying fool.” It is, however, not difficult to understand how the Sun — and others — could have reached that conclusion. Most entries were multi-engine aircraft; Lindbergh flew a single-engine. All the other entrants planned for a crew of at least two to handle the 30+ hour flight. Lindbergh was the only solo entry. Finally, all the other entrants did extensive test flying. Total test flying time for the Spirit of St. Louis amounted to a paltry five and a half hours!

Then there was his safety record. He had only been a pilot for four years, and was famous for only one thing — the most emergency parachute bailouts. In 1924, he collided in mid-air with another Army flying cadet. In his first job post-graduation, he bailed out a second time while serving as test pilot. As an airmail pilot on the St. Louis-Chicago route in 1926, Lindbergh bailed out of not one but two DH-4s when he became lost in storms and ran out of fuel.

The Spirit of Charles Lindbergh

It took ego to enter the race. “Why shouldn’t I fly from New York to Paris?” he wrote in his autobiography. He raised funds from the St. Louis Chamber of Commerce, but had trouble finding a plane. Finally, a small San Diego company, Ryan, offered to build one for him. The Ryan NYP (New York to Paris) had no radio, no parachute, no gas gauges, and no navigation lights. Lindbergh even replaced the leather pilot’s seat with a wicker chair. It was built in record time, only two months.

Two days before Lindbergh was scheduled to leave San Diego for New York, Nungesser and Coli took off from Paris. All the other competitors stopped and waited to see if the Frenchmen would succeed — except for Lindbergh, who set off immediately for New York, setting a speed record en route.

When he reached New York, he learned for the first time that L'Oiseau Blanc had vanished. Charles Lindbergh was back in the race.

The Spirit of Long Island

A lawsuit delayed the Chamberlin group, and Byrd’s America crashed during a practice flight. All the teams were hampered by bad weather, which began to clear on May 19, a few days after Lindbergh finally arrived in New York. Unfortunately, paved runways weren’t yet common in aviation. The field was muddy — too muddy to allow a heavily-laden plane to take off.

But on the morning of May 20, 1927, at 7:52 AM, Charles Lindbergh loaded his plane with four sandwiches, two canteens of water, and 451 gallons of gasoline, and took off. The Spirit of St. Louis barely managed to clear the telephone wires at the end of the runway.

Thirty-three and a half hours later, Charles Lindbergh and the Spirit of St. Louis landed safely in Paris.

Managing the Impossible Project: The Role of Risk

The difference between a possible project and an impossible project is the constraints, the factors that restrict the options available to the leader and team. If the constraints are different, the options are different.

All the teams competing for the Orteig Prize consisted of talented, experienced aviators, engineers, and designers. What distinguishes Lindbergh is the nature and level of risk he was willing to assume.

The technical equation for risk is R = P x I; that is, the price of a risk is the probability of it happening times the impact if it does happen. If there’s a ten percent chance of a $1,000 negative event, the value of the risk is $100, meaning that if you can get rid of the risk for less than $100, it’s a good investment.

What if it costs more than $100 to get rid of the risk? Well, it may still be a good investment depending on other factors. What’s the value of getting into the history books? What’s the value of being acclaimed the world’s best pilot? The price of a risk and the value of a risk aren't necessarily the same thing.

Accepting an elevated level of risk doesn’t automatically make you a “flying fool.” Sometimes it’s exactly what allows you and your team to achieve the impossible.

Project: Impossible — Easter Island

Moai

 My 26th book will be Project: Impossible, an exploration of how people achieved goals any reasonable person would have thought impossible. This week, the strange statues of Easter Island.

The European Discovery

On Easter Sunday 1722, a Dutch West India Company commanded by Jacob Roggeveen, seventeen days out of Chile, sighted a low, flat island, which he named after the day of his discovery: Easter Island.

Easter Island a windy place, flat and treeless. At the time of Roggeveen’s visit, he judged the population to be between 2,000 and 3,000 people. The poverty and barrenness of the island stood in remarkable contrast to what makes Easter Island famous: the monolithic rock carvings known as moai, the giant head-statues that dominate the landscape. The tallest of the moai towers a remarkable 33 feet in height; the heaviest weighs 86 tons.

About half the statues that have been discovered are still in the main quarry where they were all created. Many are only partially completed, as if the workers suddenly left their jobs, never to return. One thing, however, was abundantly clear: the sculpting, transporting, and installing of these statues was a remarkable feat — and clearly, one utterly beyond the capabilities and resources of the poor islanders.

Theories

Of the various theories on the creation, transportation, and erection of the moai of Easter Island, the most fanciful was advanced by Erich von Däniken, that they were designed and built by extraterrestrial visitors. Von Däniken was not alone in marveling about the Easter Island statues. Tribal folklore on Easter Island itself claimed that mana, or divine power, allowed the moai to walk from the quarry to their assigned locations.

A more serious theory was advanced by explorer Thor Heyerdahl, who actually moved a 10-ton moai using a sledge drawn by 180 islanders. Scaling up, it would have required approximately 1,500 people to move the largest moai. Anthropologist William Mulloy developed a complex engineering technique using huge trees for support, but later studies suggested that the necks of the moai couldn’t absorb the excessive stress the method would create.  Czechoslovakian scholar Pavel Pavel and Wyoming archeologist Charles Love attempted to move moai in a semi-upright position, but caused noticeable damage.

Moving the moai was difficult enough, but then came the problem of setting them upright on their ahu platforms. In 1994, archeologist Claudio Cristino could barely re-erect an 88-ton moai using a modern crane!

Of course, ancient civilizations (most famously the Egyptians) moved massive stones — all you need is lots of thick long ropes (traditionally made from tree bark in Polynesia) and lots of large trees. You also need a large labor force, and that also requires a generous amount of surplus food.

But on Easter Island, there are hardly any trees worthy of the name. Worse, the island is unable to support a large population.

Well, today, in any event.

A display of Easter Island moai atop an ahu platform. The ahu are an engineering feat in themselves.

How It Was Done (and Why It Shouldn't Have Been)

Although today Easter Island is relatively barren, botanical surveys have revealed that at the time of human settlement the island was heavily forested, with the dominant tree similar to the Chilean wine palm.
Chilean wine palms are prized for their nuts, for a sweet sap that can be fermented into wine or turned into honey, for fronds capable of being turned into a variety of useful products, and, of course, for the wood of their immense trunks. The trees were extremely important to human civilization on the island — and, of course, they were essential to the transport of the moai.

The imposing and majestic moai were built at the unwitting cost of the civilization that created them, triggering an ecological disaster. By the arrival of famous British explorer Captain James Cook in 1774, the islanders were, in his words, “small, lean, timid, and miserable.” The destruction was so complete that in the end, the people of Easter Island turned to the largest remaining source of protein — each other.

Map of Easter Island Showing Location of Moai

Managing the Impossible Project: The Consequences of Success

Every leader has to face the consequences of potential failure, but it’s important not to overlook the consequences of success as well. Too much focus on getting today’s job done can compromise — sometimes fatally — your future capabilities as well.

Even if you can do the impossible, it’s not necessarily always a good idea.

Project: Impossible — Julius Caesar at the Siege of Alesia, 52 BCE

Gaius Julius Caesar

My 26th book will be Project: Impossible, an exploration of how people achieved goals any reasonable person would have thought impossible. Here’s a summary of some of the cases covered in the book.

The Rise of Vercengetorix

Until the rise of Vercengetorix, Gaius Julius Caesar had been able to fight the tribes of Gaul one at a time. But in 52 BCE, they united under a single leader: Vercingetorix, chieftain of the Arverni tribe.

Caesar’s military and political situation at the time was deteriorating badly. Caesar’s political enemies, known as the boni, threatened him in Rome, and this new uprising compromised his plans for Gaul.

Vercingetorix conducted one of the first known uses of a scorched earth policy, destroying crops to keep them from falling into the hands of the Romans. He also dopted a hit and run strategy. In addition, he raised an army many times larger than the Romans who opposed him — by some counts, as large as 500,000.

Caesar, distracted with events in Rome, was in the settled Roman province of Cisalpine Gaul when Vercingetorix opened his campaign, but quickly crossed the Alps with eight understrength legions to find the scorched earth policy beginning to bite. Although Vercingetorix had burned twenty settlements, he had spared one, the fortress town of Avaricum, thought to be impregnable. In a 27-day siege, plagued by poor supplies and surrounded by hostile Gauls, Caesar took the town — and the food.

Vercingetorix, in response, captured a food convoy bound for Caesar. Still determined to avoid a decisive battle until the odds favored him, he retreated his cavalry into the fortress town of Alesia.

Vercingetorix had every reason to believe that his situation was still advantageous. His forces outnumbered Caesar’s. He had the advantage of high ground. Most importantly, the defending forces inside Alesia were only a small part of the Gallic forces. Soon, Caesar would not only have to contend with the forces inside Alesia, but also the remainder of the army of united Gaul — a relief army of between 125,000 and 250,000. Caesar would shortly find himself trapped in a doughnut, with enemies both inside and outside.

Caesar’s response was to launch one of the most ambitious and astounding feats in the history of military engineering.

The Impossible Project

First, Caesar’s men built a circumvallation, an eleven-mile long fortification of earth piled thirteen feet high, enclosing the entire town. Behind the earthen rampart his soldiers dug two ditches, each about fifteen feet wide. If that wasn’t enough, Caesar’s men built 23 fortlets, one every 80 feet, along the entire route — and did it in only three weeks!

Of course, Caesar also had the Gallic relief forces to worry about, so now he had to do it all over again. The Roman forces built a contravallation, an external set of defenses similar to the circumvallation, but this one extending for thirteen miles!

This immense engineering feat took thirty days, slowed by the need for Caesar’s men to collect supplies to feed the army. But it was all done before the huge relief army arrived.

A reconstruction of Caesar's fortifications around Alesia

The Battle of Alesia

After skirmishing and small battles, the main attack began at midnight, with Vercingetorix’s men crossing the treacherous fortifications Caesar’s soldiers had built. Caesar’s legates Marc Antony and Gaius Trebonius (later one of Caesar’s assassins) were able to repulse the attacks from both sides.

Meanwhile, the leaders of the relief army scouted Caesar’s fortifications and found a weak spot, a Roman camp to the northwest that had not been included in the contravallation because of the hilly terrain. Two legions (around 8,000 soldiers) occupied the camp, and the Gauls sent an attacking force of nearly 60,000 against it, starting with diversionary attacks before the major assault began. Vercingetorix, seeing some of the preparations, launched an attack on the inner lines.

Vercingetorix Surrenders to Caesar

Caesar himself waded into the thick of the battle, and the Romans carried the day. The next day, Vercingetorix surrendered. His men were sold into slavery.

Managing the Impossible Project: Maximizing Resource Quality

The performance of the Roman legionary is legendary, and it’s not surprising that 30,000 Romans could defeat a force arguably ten times as large. But even a cursory reading of Roman military history will make it abundantly clear that not all Roman generals enjoyed equal success.

Of course, Caesar’s military and engineering genius had a lot to do with his success, but it’s the superior performance of his legions, even by already high Roman standards, that is the key to understanding Alesia. The staggering magnitude of the earth-moving alone is a testament to backbreaking, unromantic work. It’s one thing to convince soldiers to fight; it’s another thing to convince them to dig.

If there is a mismatch between what you want people to do and what they actually are doing, you can either modify the process or modify the people. Modifying the process may mean improving the tools and equipment, or it may involve changing methodologies. Modifying the people can involve motivation, or changing the rewards and punishments for performance.

When people are well trained, motivated, and led effectively, they can achieve results that would otherwise be impossible.

The Ol' Yeller Maneuver (Managing Impossible Projects, Part 6 of 6)

The following series is adapted from a keynote I delivered at the Washington, DC, chapter of the Project Management Institute back in August. Parts also come from my book Creative Project Management (with Ted Leemann), published by McGraw-Hill. 

If You Build It, Will They Come?

Earlier, we discussed the story of the infamous automated baggage handling system at Denver International Airport (DIA), which burned through $250 million before being abandoned as unworkable.

There’s nothing inherently impossible about the concept of an automated baggage handling system, though obviously the implementation is tougher than it appears. No, this is the kind of project in which impossibility is situational: a function of the constraints. While we’ve focused on the Triple Constraints because of their universal application in project management, individual projects have other constraints as well.

The airlines themselves, oddly, had little initial involvement in the airport planning. This gave them substantial leverage later in the process. “If you build it, they will come” often carries a hefty price tag. In order to keep its costs down, United Airlines needed the baggage transfer system to take no longer than 45 minutes to route luggage among its flights.

In 1992, the automated baggage handling system was shoehorned into existing construction in what amounted to a “Hail Mary” play. In terms of project scope, the engineering involved amounted to a great leap forward from third-generation to sixth-generation technology.

Performance, obviously, was the project driver, with budget unavoidably the weak constraint. Significant cost and schedule overruns were guaranteed, and to a large extent acceptable — as long as performance goals were achieved.

So far, we have a very challenging project, but there’s no reason for a project manager to propose killing it. It’s not operationally impossible, and the value of closing the gap justifies a very high level of effort.

The Second Frog

The BAE project team officially recognized these key risks:

• Very large scale of the project. 
• Enormous complexity. 
• Newness of the technology. 
• Large number of entities to be served by the system. 
• The high degree of technical and project definition uncertainty. 

The most important risk, however, was not mentioned: the complex stakeholder environment. The initial project was simply to serve United. DIA management expanded the contract to cover all terminals. DIA rejected the BAE proposal to build a 50,000 square foot prototype. Scheduling issues with other construction activities caused huge conflict.

There’s the old joke about the two frogs who fell into pots of water. One pot had hot water, and the frog immediately jumped in. The other pot was warming slowly, so the other frog felt no urgency about escaping until it was too late.

BAE was the second frog.

Politically Impossible

Because the project was not impossible from an engineering perspective, the fact that it became operationally impossible because of the constraints of the stakeholder environment tended to escape notice until it’s too late.

On the other hand, political problems aren’t exactly unheard of. Project managers are supposed to perform a stakeholder analysis. This isn’t just about figuring out your customers — it’s about analyzing the political landscape.

The earlier we identify a risk or problem, the more options are available. If you accompany the sales team when bidding on a job, don’t confine yourself to a study of the technical issues. As project manager, you’re going to have to spend your days dealing with the people, and you can’t tell the players without a scorecard. If you detect political dangers, they need to be part of your risk analysis for the job. This need to affect pricing and schedule, not just for your sake as project manager, but for the sake of the entire job.

If you get into the job and find that these issues are getting out of control, you likely don’t have the power to get out of the problem by yourself. You need allies, and you need them to figure out the problem for themselves. Most project managers see reporting (no matter how necessary) as something that takes time away from doing the work. Reporting, however, is a strategic tool to lay the information groundwork with your stakeholder community to bring them toward the correct understanding of the real situation.

The Ol' Yeller Maneuver

The best way to kill a project is to help the key stakeholders and decision makers reach the conclusion on their own, rather than you telling them. Remember that “operationally impossible” means you can’t figure out an answer. Leave open the possibility that someone else might have an answer you’ve missed. Sometimes they do have an answer for you. And if they don’t, they’re more likely to agree with your assessment.

Sometimes canceling a project is peaceful, sometimes bloody. This one ended with mutual lawsuits. That’s a powerful argument for acting early when the project is likely to be operationally impossible.

So let’s wrap up. A project is operationally impossible if you can’t do it within the stated constraints. There might be too little time, insufficient or wrong resources, or unrealistic or wrong performance criteria.

Sometimes the constraints can be changed, be made more flexible, or in some cases ignored altogether. If the constraints can’t be changed, perhaps you can work around them or accomplish the project in spite of its barriers. 

If the project’s still impossible — well, earlier I mentioned the idea of an American Movie Classics film festival of great project management movies. Apollo 13 is one candidate…but another is Ol’ Yeller. Sometimes a project manager’s job is to kill his own dog.

If the dog won’t hunt, and can’t be killed, the last solution is self-preservation. While captains are supposed to go down with their ships, we project managers are better off living to fight another day. 

The Three Envelopes

There’s the old joke about the outgoing project manager who left three numbered envelopes in a drawer, and told his successor that those envelopes contained the answers to the next three crises the project would face.

Inside the first envelope was a note that read, “Blame your predecessor.” The new person often has flexibility denied to the person previously holding the bag. You may have better luck challenging project assumptions and constraints.

Inside the second envelope, the note read, “Reorganize the department,” because — let’s face it — shuffling deck chairs on the Titanic is a long, noble tradition.

And in the third envelope, the note read, “Prepare three envelopes.” If in the final analysis the project really is impossible, it’s time to get while the getting is still good.

And that’s how to manage an impossible project.

The End.

Getting Around the Constraints (Managing Impossible Projects, Part 5)

The following series is adapted from a keynote I delivered at the Washington, DC, chapter of the Project Management Institute back in August. Parts also come from my book Creative Project Management (with Ted Leemann), published by McGraw-Hill. (Art by Baker and Hill Graphic Design.)



Managing Constraints

Constraints, operationally, are what stand between you and the completion of a successful project. If you think a given project may be impossible, it’s a function of the constraints you perceive. If the constraints (defined as the borders of the perceived box) can be modified, or if parts of it are optical illusions, then you may have new options available. The game has changed.

How can we change the envelope defined by our constraints?  Logic suggests two possibilities. If the constraints are real and have flexibility, you can modify them. If the constraints are imaginary, or have elements in them that are not real, you can get around them.  Multiple strategies exist for attacking each area, but they basically boil down to two: change the constraints or get around them.

(There is no "try.")

Change the Constraints

Analysis. Why is it your preferred option best (or sometimes least worst) for the organization? Does your preferred option cause collateral damage elsewhere in the project’s environment?  How much of this is political? How do other people view this concern? You have to understand the complete picture to see all the options, and just as importantly, to see all the dangers. 

Negotiation. Some constraints are subject to negotiation. If you’re bidding on a contract, there’s a price at which you can’t afford the business. On the other hand, sometimes our organization makes the choice on our behalf. “We’ve already got the contract, this is the scope of work, and this is how much we can spend to get it done.” Probe the constraints to see which are negotiable and which are fixed by circumstances.  

Internally, negotiation is the process of making the business case. If you have force majeure to settle the argument, it’s not really negotiation. In negotiation, forcing is not an option. You can only win if you are able to help other people recognize and accept a victory of their own. 

Problem solving. Sometimes constraints are decided, other times they simply are. When an organization prepares a budget, they necessarily make decisions among desirable objectives. They could give you more (or less) money; they choose not to. But sometimes the money isn’t there. They would choose to give you more money; they can’t. You can argue with decisions; you can’t argue (though many try) with facts. That’s a problem. Some problems can be solved. In the Apollo 13 case we discussed earlier, they needed a particular resource (a filter cover), but there was nothing at hand to do the job. Then someone remembered the astronauts wore socks. 

Requirements management.  There is an unfortunate sense in which written requirements too easily turn into holy writ. The purpose of requirements is to define operationally and specifically what the customer wants and wishes to pay for.  There’s always a delicate balance between imposing the detail necessary for control and allowing the flexibility necessary for exceptional achievement. 

Watch out for requirements that have outlived their usefulness, or had even become unproductive to the mission. A small change in a requirement may be of little consequence to the project’s quality, and still spell the difference between success and failure.

Get Around the Constraints

Creativity.  Here is where positive brainstorming rejoins the flow. Systematic creativity – inspiration on time, on budget, and on spec – seems like a contradiction in terms, but professionals in many areas do it as a matter of course. The secret goes back to Thomas Edison’s famous ratio of one percent inspiration and 99% perspiration: creativity is something you can work at. Artists do rough sketches; writers do rough drafts; lightbulb inventors test filament after filament. It’s a process of discovery. As the old joke goes, Michelangelo created David by taking a big block of marble and chipping away all the pieces that didn’t look like David. 

Exploiting holes.  One of the tricks of structured creativity is understanding that some places are more likely to contain insights than others, and look there first. The flexibility of the weak constraint is one good source of insight. So is available slack or float on non-critical tasks. Weaknesses and cracks in the structure of constraints may be exploitable. 

Different approaches. Insanity, Ross Perot famously observed, is doing the same thing over and over again and keep expecting different results. Is there a way around your current obstacle if you switch approaches? 

Rethink assumptions.  Assumptions can err on the side of optimism or pessimism. Conduct a sensitivity analysis of your assumptions: if it turns out to be true or false, how much impact will it have on your project? Investigate the assumptions with the most potential.

But sometimes a project really needs to die, and the project manager is often the one dispatched to do the dirty deed. There’s a skill to this, as well.


Next Week: The Ol' Yeller Maneuver