Some years ago, a college friend of mine, Mogens Frank Mikkelsen, wrote a book about project management and completing difficult projects.

The book should be a “must-read” for project managers with a few years or more of experience. Reviewers of the book praise it for taking up a current but difficult topic and then making it easy to understand with concrete suggestions for how to manage complicated projects. In short, project complexity is everything that falls outside the traditional project manager’s toolbox. The topic is not as difficult as the word “complex” might make it sound, and the book is very practically oriented.

Above all, managing complex projects is about understanding the current situation the project is in. Without this, project management becomes like “bull-riding”. A model of managing project complexity is induced that contains fundamentally different situations, depending on the degree of uncertainty and disagreement. From these, one can determine whether the project is “just” complicated – or whether it is complex and what type of complexity one is dealing with. Then, project management can be adapted to the actual circumstances. The book describes four different basic domains, which are plan-driven, agile and political project management, as well as what you as a project manager can do if chaos is approaching on the horizon. Let’s look at the four domains to understand how to create a strategy for executing different types of projects.

The secure domain

The secure domain of consensus and clarity is where a deliverable is pre-specified, the resources needed to produce that deliverable are estimated, and a deadline schedule is set. In other words, the project manager can specify the project triangle (comprising of scope, time, and cost) in advance for the entire project and later plan and realize it.

The project leaves the safe domain if there is plenty of uncertainty and/or great disagreement. If we cannot resolve the dispute using project management tools such as a communication plan, a risk register, or a project organization of interests, we will have to act politically and negotiate our way through the project.

If we can’t limit uncertainty through better estimation, slack in the plan, and risk planning, we must apply iterations and agile approaches in project execution.

There are reasons why the project may fall out of domain one and into domain 2, 3 or 4. The obvious is either a high degree of divergence (where stakeholders have conflicting views on the project’s direction) or great uncertainty about the goal or method. In addition, factors such as:

• Responsibility for business goals
• Not enough hours for project management
• Projects as mini-programmes
• Too long or too short a time horizon
• Disagreement about the project triangle

The uncertain domain

When a project’s uncertainty is above a certain level, it moves from a safe to an uncertain domain. The nature of the project changes from complicated to complex. The project subtopics can be distributed over both domains (just like over the other domains, which we will get to later).

The uncertainty can be about delivery uncertainty, unclear methods or unknown external events. There should be no uncertainty about the project’s purpose in this domain, if there is, the project may be in the divergent domain.

In the uncertain domain, project management must find a suitable project set-up that can manage uncertainty. In practice, it will often be the project manager who suggests to the project owner how this can be done. Here are four recommendations that can be taken into consideration:

• Communicate the uncertainty. Create a widespread understanding of the project’s uncertain elements and, thus, the complexity that needs to be overseen.
• Systematic iteration. To enable agility, divide time into intervals using sprints, time boxes, or stages. In these intervals, the future is evaluated and reconsidered.
• Feedback from the outside world. Establish regular outside-in assessments of the project’s sub-results, e.g., in the form of review meetings with stakeholders who can change the project’s direction.
• Focus on learning. Cultivate a learning culture that is willing to discuss and test one’s assumptions and where mistakes are perfectly fine when they lead to learning.

The divergent domain

Disagreement in a project consists of the stakeholders going in different directions. There can be agreement both within and outside the scope of the project. Disagreement can be an obvious conflict or hidden and unnoticed. Sometimes, it can hide in ambiguous language formulations, which is especially seen in a “culture of consensus.”

To deal with this divergence, you must engage in political project management – even if the word may have an unfortunate connotation. Recommendations to consider if the project is wholly or partially in the divergent domain are:

• Keep an eye on the game.
• Avoid becoming part of the game.
• Be ready to enter into negotiations.
• Be ready to walk away from negotiations.
• Cultivate powerful relationships.
• Hold political meetings.

Perhaps the most crucial thing is to set aside time to understand others and how their worldviews are connected. Perhaps there is more logic in the opponents’ points of view than was initially assumed.

Above all, it is essential to become proficient in communication. Not only to avoid conflicts and become better at cooperating but also to discover the many places where we talk fundamentally past each other. You know that there are many possible understandings of the word implementation.

The Chaotic Domain

It is chaotic when the situation is close to chaos. Chaos consists of divergence and uncertainty. When we experience this, plans must give way to the immediate restoration of our cooperation’s framework. Chaotic was defined as lacking a common framework for current events, and the chapter presented a framework model.

The essence of the framework is to reach agreement on what we consider to be conditions and problems. Next, it is about agreeing on which tasks the project will undertake. When choosing a task, you often have to accept that it may be uncertain whether the task solves the problem. Therefore, it may be necessary to work iteratively.

In other words, the framework model solves uncertainty and diversity, a double complexity called chaos. The framing model has a square frame and a control circle inside. Both are closely related to the general project manager toolbox.