The Magical Math of Project Management

Those of us who work with project documentation are very familiar with the common categories: Assumptions, Dependencies, Risks, Issues, and Constraints. In this article, I want to show you the “math” behind these terms and the special relationships between them.

Let us start with the intuitive definitions.

Risks are uncertainties. The term “risk” describes an event that may or may not happen. If the event is positive, the risk is called an opportunity. If the event is negative, it is called a risk. In simple words, any situation where you find yourself asking “what if” points to a risk.

Issues are negative events that are already happening. There is no uncertainty or probability involved - issues are real and present. And there are no positive issues.

Dependencies are interrelated events. Most often, dependencies occur between projects or project activities. They can be internal or external to your project, program, or even your entire organization. The simplest example is: “Activity A cannot start until…” - until something else happens. A dependency can often be expressed as “if… then…” - a phrase that feels natural to code developers.

Constraints are different from dependencies. A constraint is a given. No more “if” - a constraint describes reality. For example: “We cannot install this software because our server capacity is limited.” Constraints are usually tied to the word “because.”

Assumptions are used to fill in information gaps, typically leaning in our favor.

How these PM terms relate to each other?

The Magical Math of Project Management - Pmaid Consulting Group

Risks and Issues. Risks must be mitigated, while issues must be resolved. Risk mitigation is a preventive, proactive action, while issue resolution is a corrective, reactive action. By mitigating a risk, you prevent the corresponding issue from occurring. By resolving an issue effectively, you may also remove the risk that was connected to it in the first place.

Dependencies and Constraints. Constraints can sometimes be resolved, and the key to doing so often lies in a dependency. For example: “We cannot install this software because our server capacity is limited” (constraint) can be reframed as: “If we upgrade the server, then we can install this software” (dependency). From there, it becomes an action plan: “We will upgrade the server by this date, so that we can install the software by that date.”

The reverse can also happen. A dependency can become a constraint when the conditional event turns into a predictable reality. For instance: “Our server will not be upgraded anytime soon.”

Assumptions and Dependencies. Assumptions can eliminate dependencies, especially when they relate to requirements while the dependency refers to implementation. Using the same example: “If we upgrade our server, then we can install this software.” If we assume the new software is not required, the dependency no longer exists.

Assumptions and Risks. Assumptions can introduce risks. For example: assuming that the server capacity is sufficient for the new software creates uncertainty-and uncertainty is risk.

Assumptions and Issues. If not revisited, assumptions can turn into issues. Imagine assuming the server capacity is sufficient, never validating it, and later discovering that the new software crashes during installation.

Risks and Constraints. This is an interesting pair: uncertainty and certainty. A constraint can set the conditions for a risk. “Our server has limited capacity.” That is a definite constraint. If we ignore it and still plan to install the software, there is a risk of failure. On the other hand, defining a constraint can also be a way of mitigating risk. For example: “We will only install software that requires no more than our current server capacity.” In this case, the risk is eliminated-the uncertainty disappears.

Risks and Dependencies. Risks and dependencies are strongly connected. When a dependency exists, the dependent task is at risk if the condition is not met. “If… then…” can quickly become “what if… not?” At the same time, identifying the dependency behind a risk can help in creating a mitigation strategy. For instance: “There is a risk the software will crash on our server.” Why? Because it depends on server parameters. Mitigation options might include: 1) upgrading the server; 2) removing the software from scope; 3) validating server parameters in advance; or 4) choosing a different software solution.

These five standard project management terms are not just formal bullet points in a document. They are the variables in the equations of project management. Learning how to work with them is both practical and rewarding.

I love project management!