Before the Project Starts Part 2: Project Assumptions

In the previous article, I suggested that one of the key responsibilities of a project manager is to eliminate uncertainties. The first step to achieve that is to formulate project objectives and expected results, and also to collect and analyse project deliverables. The next step is to define project assumptions.

The project usually begins with an idea of a future product or deliverable. A lot of questions and hypotheses arise as this idea is being discussed – those issues should be tracked as the project goes on.

PMBOK gives the following definition:

• Project assumption is a factor in planning process that is considered to be true, real or certain often without any proof or demonstration.

The definition doesn’t seem clear enough to me. I took a different one from one of the articles I’ve read:

• Project assumption is a factor that is crucial to achieving project objectives and which cannot be influenced by the executive team.

This definition is by far more accurate, so I’ll be using it. When defining project assumptions, the following algorithm can be used:

1. Study project objectives and formulate hypotheses crucial to achieving those;
2. Study project deliverables and formulate hypotheses crucial to achieving those on time and on budget;
3. If by the time the discussion begins the requirements have already been defined, then study the requirements and formulate hypotheses crucial to achieving them.
4. When the hypotheses list has already been compiled, see if the project team can verify the hypothesis. If a hypothesis can only be verified during project execution, and the team cannot influence it, this hypothesis becomes an assumption.

Let’s see how assumptions can be formulated. As an example, let’s look at a company that’s implementing a CRM system.

Here are the objectives the customer set for the project:

1. Standardize how the employees work with the clients of the company
2. Reduce the expenses for some transactions
3. Enhance client data authenticity

To achieve those objectives, the following project results were defined:

1. Regulations describing how employees should work with the clients
2. A software product that automates those regulations
3. Employees that are trained to work with that software product
4. A functioning support service for software users

After studying project objectives and deliverables, the CRM project manager has formulated the following hypotheses:

Thus, any hypotheses that get a “no” become project assumptions.

You’ve probably noticed that it can be quite complicated to answer if it’s possible for the team to verify the hypothesis before the start of the project. If the hypothesis is linked to an external factor, then it’s usually quite simple: project team is unable to influence nature, economic or political conditions. Thus, all the hypotheses connected with those factors usually become project assumptions.

If we’re describing a factor that’s connected with project stakeholders – say, with the intentions of the Customer or company employees, we cannot be sure we understand their interest or intentions completely. If the intentions of the stakeholders are stated in the contract we can accept them as known and hard to change. In the rest of the cases their intentions stay vague. That’s why I consider the external stakeholder hypotheses to be assumptions.

As soon as we’ve formulated the assumptions, their credibility should be questioned and the risks involved should be evaluated.

Let’s see how it works based on the two assumptions taken from the table:

1. What happens if the employees spend much less than 10% of their working hours on the project?
2. In this case, we can formulate a risk statement:
3. “Allocating fewer resources than initially planned will cause missing the deadline on project tasks”.
4. What if the assumption that company management is aware of the processes included in the CRM system and has a unified point of view on the issue is wrong?

This will lead to a situation where the management doesn’t understand the CRM system boundaries while collecting software requirements – causing total misinterpretation of project boundaries.

Here’s the algorithm on how you further process the assumptions:

1. The project manager formulates project assumptions based on the above-described algorithm.
2. Assumptions are analyzed to find missed or incorrect ones.
3. Each assumption is questioned (“What happens if the assumption is proved wrong?”) and a list of risk statements is drawn up.
4. The risks get into the Risk Register which falls under risk treatment planning.

You probably know that risk management causes additional tasks to appear on the project, which most likely increases the budget and time constraints of the project plan version in which the risks haven’t been taken into consideration.

This way analyzing project assumptions helps identify project risks and specify the activity list to make the project schedule and budget more adequate and eliminate project uncertainties before the project starts. I hope I made the procedure of processing project assumptions clear.

If you have any comments or suggestions, feel free to discuss them in the comments below.