Open Project Management - Avoiding the "Us and Them" Syndrome

If you make the mistake of thinking that the team doesn't include the Client, then chances are you'll fall into the "Us and Them" syndrome. This typically happens when the developer has worked hard to deliver a feature, which the Project Manager then presents to the Client. The Client then changes their mind about what they really want, now that they can see that what they asked for isn't quite right. This happens all the time and is a naturally part of projects. Despite the best intentions, sometimes when a feature is delivered, the Client realizes their initial thoughts were wrong. So, the changes are worked out and the developer informed. The first time it's OK, the second time you might hear a few grumbles from the developer, the third time, be prepared for expletives!

What happens here is the Developer starts seeing the Client as one of "Them", "they" are causing all the problems because "they" can't work out what they want and it's "their" fault that weekend work is going to be needed to finish the job.

This type of mindset can happen between anyone who provides input into the project and even within the team, and it's insidious. People start to become difficult, push back on things, deliberately slow down, cause problems, and basically undermine the project. As professionals one would like to think we would rise above this but we are also human and prone to frustrations. The key is to be aware of this so that you can do whatever it takes to avoid this syndrome. Involve the Developer in meetings with the Client, try to make sure they see each other's point of view, and if that doesn't work, get someone to facilitate or change the people on the team to keep things moving.

I was working on one project where the Client and the Lead Developer, the two most influential people in the project, would no longer talk to each other, unless it was to abuse one another. It basically brought the project to a standstill until something was worked out. In the end, we had to replace the Lead Developer in order to move things forward. He was still working on the project but another Developer acted as the go-between to ensure the project was able to proceed. This situation was far more difficult to resolve than any technical issue the project raised.

On the other hand, if you are able to build an environment where there is trust and respect between everyone, things are much easier to resolve. If an issue arises, then everyone helps to solve it even if it's not directly their responsibility. The roles are there to help keep people focused but if there's a problem stopping production, then it's handy to have a team that's flexible and will help out if they can. That goes for the Client as well, e.g. allowing changes to the timeline to accommodate unexpected illness.

It's actually quite simple, either you're working together or not. If you're not working together, it's going to be a hell of a lot harder to get things done!