Today's paper:

Sloot, R. N., Troje, D., Voordijk, J. T., & Volker, L. (2024). Change in a project-based organization: the mutual shaping of institutional logics and change programs. The full text is here.

What is this all about?

Imagine: you need to make a joint decision in your team on how to develop a service/product for your stakeholders. One person/group wants X, and another wants Y. 
X: "We had a plan but it does not reflect all the needs of our stakeholders. We should collect as much information about their needs as possible before we take any steps".

Y:  "We can implement additional features later.  Now we cannot afford trial and error; we should follow our plan and the strict timelines".
I bet you intuitively took the side in this argument already :) 

 Why is this important?

This company implemented several infrastructure projects simultaneously. To minimise the bureaucracy they separated two big chunks of work - one related to the resources of the whole network (asset management), and another one - related to individual projects (project management).

(Can you already guess who wants X and who wants Y?)

As you see, the two "lines" have very different aims, and need to think and act differently to achieve these aims (have different "institutional logics"). This is exactly the reason why this separation works so well.  

Why it was a problem then?

Although this division works great 99% of the time, it can get tricky when you need people from both groups to perform the same tasks, such as time tracking, reporting, or using the same IT systems.

This happens because different organizational units operate according to different institutional logics: some are accustomed to highly structured processes, while others are not. It's a matter of functional necessity, not personal preference.

When people want X or Y, it's because their daily work demands it, not because they are being difficult. Remember, both groups have a vested interest in moving forward, and nobody expected such challenges to arise unexpectedly.

How to prevent it?

By establishing clear procedures for decision-making. Remember the decision-making cheat sheet? Here, we need facilitated discussion. The organization made a mistake by opting for a group discussion instead.

What else should we keep in mind?

It is very unlikely that your partner is a stubborn idiot. He or she wants this project to succeed as much as you do but has different means in mind. Every personal trait and behaviour is a mixed blessing and has two sides. Think about flexibility/inconsistency, confidence/arrogance, optimism/naivety and so on. 

How can we use this information right away?

Try this:

1. List your partners' annoying behaviour (insisting on collecting feedback from literally everyone, raising a million concerns and postponing the decision, etc).
   

2. Think about the flip side of these behaviours. How do they help your partners to successfully deal with problems in their departments? (making better decisions by including wide viewpoints, being good at risk assessment, etc).
   

3. Start your next talk by acknowledging these concerns. Try something like this: 'I see that your daily job requires you to collect feedback from as many people as possible, which is crucial for identifying problems early on. When I propose [your idea], it indeed comes with the risk of missing out on something important. Can we discuss the acceptable trade-off between highlighting the risks and making swift decisions? 

Do you have other tips for working with people who seem to sabotage your work? Send them to info@r2p.solutions, we would be glad to share them!