2 Assuming

Assuming is taking for granted without proof, supposing, or postulating. We all need to make assumptions in order to simplify life and make decision-making more manageable. However, we must recognize that assuming is dangerous: We could assume something that turns out to be wrong. In project management, that wrong assumption could cause significant problems for our project.

The Sin

An assumption is a guess about the future (see guessing). No one knows the future with any useful degree of certainty, so we all make assumptions of various kinds to be able to make decisions about how to proceed. In daily life we make numerous hidden assumptions without realizing that we’re doing it, and most of the time that is a perfectly safe and sensible thing to do. Sometimes we also make explicit assumptions, usually about the big issues where it matters if we get things right or wrong.

Projects take place in the future, and when we plan them we have to think about how the future might turn out. Just as in many areas of “normal life,” there are lots of things we don’t know about what the future might hold for our projects, so we have to make assumptions, or guesses. Projects involve several important types of assumptions, including:

Scoping assumptions. For example, we may assume that our project includes the requirement to produce a full set of documentation, that it needs to be provided in English only, and that we can supply it in electronic format.

Planning assumptions. For example, we expect all named members of the project team to be available when we require them, to stay on the project for the full duration, and to have the skill set they need to perform their assigned tasks.

Estimating assumptions. For example, we assume that the cost of a novel task can be derived by multiplying the number of people on the task and a standard daily rate by the average number of days that this task has taken on previous similar projects.

Assuming takes place most often in the pre-project planning stages, when key parameters of the project are being determined, answering the questions of why, what, how, when, who, how much, and how long. It is common practice to record these assumptions in the project charter, business case, or statement of work, although in most cases this is not done well and the list of assumptions is usually incomplete.

Of course, in many cases it is quite safe to assume something about our project, particularly if the chance of our assumption turning out to be wrong is very small or if the consequence of a wrong assumption would be insignificant. But if we make an unsafe assumption about something important, our project could really be in trouble if it turns out that we guessed wrong.

A Case of Assuming

A well-known example where assuming caused a major problem is the case of the National Aeronautics and Space Administration (NASA) Mars Climate Orbiter mission in September 1999. NASA lost the $125 million orbiter because the contractor’s engineering team used English units of measurement (feet and inches) while the NASA team used the more conventional metric system (meters and centimeters) for a key spacecraft operation. This resulted in a navigation error that pushed the spacecraft too close to Mars, and it consequently broke up upon entry into the Martian atmosphere. Each team assumed that the other team was using the same units, and no one checked.

Solutions

Fortunately there is a simple way to avoid committing the sin of assuming, by using the technique of assumptions analysis and linking it to the risk management process. Assumptions analysis involves three steps:

1.List assumptions

2.Test assumptions

3.Identify risks.

The first step is to list all the assumptions that have been made about the project. This requires the ability to think reflectively and creatively, as well as to be able to challenge accepted thinking. It is often useful to get the help of a skilled facilitator to assist in exposing assumptions by asking a series of targeted questions. It is important to find hidden assumptions as well as the more obvious ones (which should be listed in the project charter).

Next, the identified assumptions should be tested by asking two questions:

1.Could this assumption be wrong? (yes or no)

2.If it were wrong, would that have a significant effect on the project? (yes or no)

Some assumptions are perfectly safe and very unlikely to prove false (for example, we assume that our organization will not go bankrupt before the project completes), whereas others are less certain (for example, we assume that a key supplier will continue to provide the components we need). Other assumptions might turn out to be wrong but would have no real impact on the project. We are looking for cases where we have assumed something that could be wrong and where that would matter.

The final step in assumptions analysis is to take the cases where the answer to both questions was “yes” and turn those assumptions into risks. This can be done at two levels. The simplest way is to write a risk statement that negates the assumption. For example, we might have assumed that “All key project team members will stay on the project from beginning to end.” If we determined that this assumption could be wrong and that losing a key team member would cause problems, we would write a simple risk statement saying “A key project team member might leave the project.”

Alternatively we might decide to produce more detailed risk statements exploring possible reasons why this assumption could be wrong, for example, “A key project team member might decide to leave the company” or “A key project team member might develop a long-term illness.” More detail is appropriate if the lower level risks have different probabilities or impacts, or if they require different response strategies. Otherwise, similar risks can be combined.

Tips for Avoiding Assuming

Perform a simple assumptions analysis to expose any risky assumptions.

Use the standard risk management process to deal with those assumptions.