Looking at the kind of conversations one can have in a project context.  The ones I have been involved in can be categorized in three groups:

1. Polite discussions: interactions on a level of political correctness. No harm done, but nothing gained either on the level of creativity or relationship.

2. Passionate discussions: Above and beyond the exchange of information and facts. These moments can be filled with joy, sadness, fear, but most of the times they are guided by anger and frustration (Yep: such is life on large scal projects). The point is that there is a counterpart in these conversations acknowledging the feeling you are expressing. Relationship matters. I have learned that when people connect at this level, that they are capable of innovative and very high quality work.

3. Powerplay: ‘Mine is bigger than yours’  and command and control discussions where one party needs to win on the other’s expense. I have learned that these suck the last drop of motivation and commitment out of people in the long run. The result is only as good as the IQ of the winner (which, most of the times resembles Rambo’s instead of Einstein’s).

For the sake of simplifying reality so that it fits into my brain, I have plotted the categories on the chart below:

The moral of the story: you need an optimal level of conflict for a good solution, for conflict is what ensures contact. So don’t be afraid to show some guts from time to time.  Just one big warning sign so you don’t tilt to the complete righthand side: if you loose your vulnerability in the conflict, you loose your dignity and you fall into powerplay mode.

Related articles:
- A conflict isn’t always a bad thing – Part 5 – January 12th, 2009
- A conflict isn’t always a bad thing – Part 4 – December 14th, 2008
- A conflict isn’t always a bad thing – Part 3 – December 7th, 2008
- A conflict isn’t always a bad thing – Part 2 – November 29th, 2008
- A conflict isn’t always a bad thing – Part 1 – November 22nd, 2008
- Forming – Storming – Norming – Performing  – September 12th, 2008

"Implementation is the last 99%" – Tom Peters

Finally – the GSD perspective (GSD = ‘Getting Stuff Done’). When we have a closer look at the workplace dynamics that are in play when projects and departments are getting work done (aka: ‘implementation’), there is a remarkable phenomenon: conflict and tension seem to be part of the job whenever we approach a milestone or a deadline.

Like a law of nature, conflict is inherent to implementation because people with different assumptions are about to deliver the exact same piece of work. As long as that piece of work is a verbal reality (i.e.: an idea, a project plan or a blueprint) consensus is abundant. So far the honeymoon phase.

The next project step is to build a tangible prototype or to launch a pilot. After that, it gets worse in terms of conflicts and clashes because gradually more people get involved in order to test the stuff, in order to be trained or just in order to allow the members of the team they are leading to free up time for participating to your project. And these people come from different backgrounds; they did not travel the same road as you did over the past months… so the next thing you know is that they start asking silly, annoying and (seemingly) irrelevant questions.

Basically, people in projects clash on two levels:
1. first, as things get tangible, people clash on the concrete level ("What does the solution look like and how will it work?"): the path from abstract to concrete is a bumpy road to the same extent as expectations, assumptions and interpretation of the project mismatch. This is exactly the bumpy road that Tuckman describes in the "forming – storming – norming – performing" model.

2. Second, as things move forward, people clash on the alpha level (i.e.: in the biological sense). The basic concern here is: "How do I contribute to this solution? / What is my role?" Here as well, expectations, assumptions and interpretations of the project hierarchy are often mismatching. Mind you: this has very little to do with the project organization chart on paper - I am talking hormones here: testosterone and estrogens to be precise.

To summarize, here is a simple example of a project setting:
- Mr. and Mrs. Smith (the project team) are about to purchase a ball (the project goal);
- They carefully and successfully planned the purchasing process (going to the store together before closing time);
- They may even be managing a budget.

So far, the project is a verbal reality and they are about to find out the mismatch on the concrete level as soon as they see one another heading for a different part of the store (the basketball department versus the softball department): "Hey, this is not what I meant!". On the alpha level, the other one may respond: "Who’s in charge here anyway?"

The point to remember here is that this conflict is not a bad thing. It is just an indication that people are delivering concrete things on that project. And the opposite is also true: beware of conflict-free projects; chances are that they score poorly on the implementation level.

Dr Bruce Tuckman published his Forming Storming Norming Performing model in 1965. He added a fifth stage, Adjourning, in the 1970s. It is one of the few ‘evergreen’ theories on group dynamics that I know. And I am struck by its predictive validity each time I am involved in a largescale project.

The biggest challenge of large-scale projects is that the end result is depending on the joint effort of a lot of people at the same time; To make things worse, most projects are staffed with people who are regarded as ’skilled’ or ‘expert’ in their domain. The good news is that these people bring solutions to complex problems. The bad news is that that experts and specialists are among the worst listeners on the planet.

Tuckman’s theory describes and predicts with fair accuracy what happens when these people need to meet deadlines and deliver 1 joint deliverable. In a nutshell, here’s what happens time and again:

Stage 1 – Forming: the undeveloped team

• Uncertainty
• Feelings not dealt with
• Poor listening
• Weaknesses covered up
• Unclear objectives
• Low involvement in planning
• Boss takes most decisions

Stage 2 – Storming: the experimenting team

• Experimentation
• Risky issues debated
• Wider options considered
• Personal feelings raised
• Intragroup conflicts
• More listening

Stage 3 – Norming: the consolidating team

• Methodical working
• Agreed procedures
• Established groundrules
• Close relationships start to develop

Stage 4 – Performing: the mature team

• High flexibility/ability to lead process
• Maximum use of energy & ability
• Needs of all met
• Development is a priority
• High commitment, balanced team roles & shared leadership

In short: as you are approaching a deadline, a milestone or any delivery due date it becomes clear how much you have been assuming things and taking other things for granted. The pressure mounts and molecules move in all directions: a storm which results in new norms, agreements and rules of the game. Norming mostly results in statements such as: “Next time we have to deliver this we will pay extra attention to XYZ“. “From now on all the communication about ABC will be centralized by me“.

After these settlements the team is a step closer to better collaboration until the next conflict arises. Slowly but surely people start to know the boundaries of their performance an that of the team and they start to perform as they should. Unfortunately, to my experience the so-called ‘performing teams’ only exist at the end of a project…and then they adjourn… duh!

—————-
Tuckman, B. (1965), Development Sequences in Small Groups, Psychological Bulletin, 63, pp 384-99.