Divergent-Convergent Paths Process For Conflict Management

By Luigi Morsa, Aerospace Engineer and Project Manager, SII Engineering & IT

Managing a team is complex and challenging at the same time. Team members naturally have different perceptions, personalities, characters, ideas, and they may be from different cultures. Getting along or minimizing conflict within a team is not easy. 

In managing conflict in teams, we consider two possible relationships: one where the leader interacts with team members, and one where team members interact among themselves and the leader is a “spectator”, but with a task to bring calm in difficult situations. 

Managing Conflicts in Projects

At first glance, conflict management could be perceived as distant from the project management environment, but managing conflict can be extremely useful to better understand and appreciate the diverse thinking of people in a team. 

All this leads to the well-known Conflict Management Techniques laid out in the PMBOK® Guide. The PMBOK® Guide recommends five techniques that project managers can use to manage or eliminate conflict in project teams: 

  • Withdraw / Avoid 
  • Smooth / Accommodate 
  • Compromise / Reconcile 
  • Force / Direct 
  • Collaborate / Problem Solve 

In the same project management guidance, the project manager is also described as a conflict manager. Among the critical skills needed to succeed as a project manager is the ability to manage and mitigate the frictions that are counterproductive and can lead to undesired sources of inefficiencies within a team. 

Regardless the details of the techniques, it’s worth pondering why people develop different ways of thinking and how they arrive at different conclusions and therefore divergent opinions. To address this complex question, we may consider a treatise of psychology or sociology concepts, or we can look at some parallels of how a mathematical theory is built. 

Our perspective draws parallels with a math theory which has no space for opinions. A math theory relies on a set of assumptions (called axioms[1]) accepted by all (or stakeholders, in a project management context) and considered as conventional truth. Through a logical process, other truths are obtained until no one questions the deductions or results. 

The only way to have divergence is to change the initial set of assumptions and the derived theory will then be different. A limpid example of two mathematical theories both valid, but with results and applicability much different, are the Euclidean and Non-Euclidean geometries. 

We can deduce that two people can have different opinions because their starting points are not exactly the same. On the other hand, when people define common starting points, the deductions, obtained by using logic, must converge toward the same results.

Dealing with Divergence

A possible strategy to resolving divergences can be based on the following sequential steps:

  • Understand by a backwards process why the deductions diverge
  • Identify common and different starting points
  • Perform a deep analysis aimed at defining a good set of common points
  • Convince the involved parties to sacrifice some starting points or “source” of disagreement

The following diagram exemplifies a Divergent-Convergent Paths Process that represents a way to obtain convergence by starting with divergent opinions. 

Diagram 1: Divergent-Convergent Paths Process

We need to consider that the leader has not only the task to analyze the facts and passively identify a way to reach compromise as described and shown above. Today, those who lead need to have a vision for a team or for a company. Therefore, it is possible that the agreement reached represents only an intermediate step to go in a different direction. 

We can also say that the compromise is, in most cases, only a short-term decision that has the benefit of mitigating the contrast and quieting the nerves. The compromise is not likely the best solution from a strategic long-term perspective. 

In other words, as soon as a conflict emerges, a compromise based on the analysis described above is applied (temporary solution); while at a later time, the ultimate and most visionary solution is cleverly reached and applied. The following picture gives an idea of the whole process.

Diagram 2: Divergent-Convergent Compromise Paths Process with Project Manager´s Visionary Solution 

The power of the hybrid approach relies on two main facts:

✓ Thanks to analysis and synthesis ways of thinking, the project manager is likely to understand better the varied working styles, personalities, and the ways the concerned parties think.

✓ By applying a temporary solution (compromise) as an intermediate step, it is more probable that the long term and visionary solution identified by the Project Manager will be better embraced or accepted by the team, instead of imposing this last one since the beginning.

Conclusion

Managing conflict and dealing with divergent viewpoints are unavoidable aspects of projects. Successfully navigating convergent and divergent viewpoints require strong communications skills, sound judgment, and an ability to compromise. The process described above together with continuous practice can help project managers mitigate, manage and resolve conflict.


[1] An axiom, postulate or assumption is a statement that is taken to be true, to serve as a premise or starting point for further reasoning and arguments.


About the Author

Luigi Morsa (Ph.D.) is an Aerospace Engineer and Project Manager working in Germany at the consultant company SII engineering & IT. Luigi’s passion for project management has led him to contribute to two books by Dr. Harold Kerzner, the pioneer and globally recognized expert in project management. Luigi wrote two case studies for Project Management Case Studies, Fifth and Sixth Editions (Wiley, 2017, 2022) and the chapter on “Innovation Management Software” for Innovation Project Management (Wiley, 2019).

In 2018, Luigi was a speaker at the Project Management Institute (PMI®) EMEA Congress to discuss the complexity of the aircraft industry market, with particular emphasis on the relationship between product and customer needs. He is the author of two other blogs—“People Innovation: A New Vision to Innovate” (2019) and “Chess and Business Strategy” (2020).

 


What's In a Name?

By Alan Ferguson   |   Approved Trainer for PRINCE2®, MSP®, M_o_R®, MoP®, P3O®, Change Management™, Managing Benefits™, AgilePM™, APM IC & APMP

In a portfolio, programme or project office we do much more than provide administrative support.

But how can we describe our work in a compelling and accurate way?

When I first came across an “office” (See? I’m already having problems describing who we are and what we do) it was called a Project Support Office – PSO. A colleague of mine had been drafted in to set it up at the same time as I arrived in the organization and frankly neither of us knew very much about project management. Mind you, that was the 1980s and I don’t think anybody really knew much about project management then. He ended up with a couple of admin assistants working for him.

If I recall correctly one was, frankly, not very helpful. The other was best described as a velvet hammer. Her job was to make sure us project managers did a weekly progress report. Of course we were all far too busy and important to do that. But she would arrive in my office at the same time every week and it didn’t matter what else I was doing, by the time she left she had the information to type up a progress report.

Things have moved on enormously since then and the range of names of offices has grown exponentially: PPSO, PMO, EPMO, even Change Delivery Office. I’ve seen them all.

I’ve been heavily involved with a publication called P3O – portfolio, programme and project offices. I’ll use the title of this guidance manual to help us think about naming and describing what we do.

What does “P” stand for?

When I meet someone from a PMO, I ask them what the “P” stands for. That often tell me that it stands for, say, project and programme. My response is: “Well isn’t that two ‘P’s?” There is our first hurdle. We have to understand the difference between a portfolio, programme and project, as defined in the organization, and take a view on which if any of those change delivery practices we are supporting.

“M”. Really?

OK, we do a lot more than support – that’s agreed. But are we really managing? Surely if the project manager manages the project, what does the project management office manage? In some circumstances the PMO is genuinely a decision-making body. That’s a very centralized model. In other circumstances there is a balance of power between the PMO and project managers. However, at times the PMO is suffering from “grade inflation”. It’s really a support office but it calls itself a management office.

I don’t mind if the organization is using a centralized or a decentralized model; there are pros and cons to both. Although I do think there needs to be clarity about who does what.

What do I do? I Office!

Most job titles link to a verb. Going back to my old friend the project manager, he or she manages. A portfolio director…well, directs. Someone who works in an office….offices? Oh, we don’t have a verb for what we do in our office.

Here’s my elevator pitch.

It would be wrong of me to share these problems with you if I didn’t have a solution. The elevator pitch I’ve come up with is:

 “My team and I enable and restrain change.”

 

How do you describe your work?

[trx_infobox style=”regular” closeable=”no” icon=”icon-desktop”]Visit our website to learn more about IIL’s P3O certification courses. [/trx_infobox]

Alan Ferguson is a consultant and trainer in Agile Project Management, PRINCE2, MSP, P30, M_o_R, MoP and Project, Programme and Portfolio Management with hands on knowledge of managing in governmental, IT and engineering fields as well as extensive experience in training, consulting and coaching.


Do You Feel Lucky?

By Alan Ferguson – Approved Trainer for PRINCE2®, MSP®, M_o_R®, MoP®, P3O®, Change Management™, Managing Benefits™, AgilePM™, APM IC & APMP

Mature risk management is about culture as well as process.

In the 1971 movie, Dirty Harry, Clint Eastwood says the following lines:

“Uh uh. I know what you’re thinking. ‘Did he fire six shots or only five?’ Well to tell you the truth in all this excitement I kinda lost track myself. But being this is a .44 Magnum, the most powerful handgun in the world and would blow your head clean off, you’ve gotta ask yourself one question: ‘Do I feel lucky?’ Well, do ya, punk?”

Although this is a rather violent film, this is a perfect illustration of risk appetite. When the police officer, Harry Callahan, asked the bad guy if he felt lucky, he was only assessing that individual’s risk appetite.

So what’s your risk appetite? Are you risk averse – avoiding risks if at all possible? Or you could be risk seeking – looking for risks, thrills, when they are available. Then of course the balance in the middle would be risk neutral.

Now it’s interesting to think about one’s personal risk appetite but the concept also applies to an organization. Risk appetite can be defined as ‘the amount and type of risk that an organization is willing to take in order to meet their strategic objectives.’

Like everything else there are stereotypes – the risk averse local authority that goes from striving to provide us with services reliably, every day to failing to innovate or the financial institution that goes from sensible speculation to taking unwarranted investment risks.

When implementing, assessing, or improving risk management across an organization we can all too easily focus on the process. We put in place more precise guidance or more sophisticated risk management tools.

We often overlook the culture of risk management.

We fail to properly understand the organization’s risk appetite. Very often the organization’s risk appetite is either not written down, or if it is written down the words on paper do not truly reflect the behaviors of the people in the organization. We need to understand the organization’s risk appetite and reflect it in the way the organization manages risk.

But I think you can take this discussion a little further. If we’re talking about changing an organization’s behaviors, its culture, then we are moving into the world of change management. We can’t simply alter behaviors across your organization by publishing a new set of procedures, guidelines, or standards. If the organization is resistant to change, it is likely to have a low risk appetite. This type of organization has a very deep-seated reluctance to change.

I can play this linkage in both directions. If as a change manager, I see there is a risk averse culture, then I’m going to have to work more slowly, carefully, and sensitively on my change management initiatives.

On the other hand if as a risk manager I see that there is a low risk appetite, then I may have to use change management techniques in order to improve risk management in the organization.