One of my favorite diagrams on building a strong team is the pyramid from the book 'The Five Dysfunctions of a Team' by Patrick Lencioni (see below).
What I want to do is discuss this chart as it relates to project management and from a positive point of view. Instead of looking at this from five dysfunctions, the author also listed 5 functions of a cohesive team. This consists of the following:
- They trust one another
- They engage in unfiltered conflict around ideas
- They commit to decisions and plans of action
- They hold one another accountable for delivering against those plans
- They focus on the achievement of collective results
1. Trust one another
When working on a project you often have people from different functional groups and providing different levels of production support so you don't have 100% of their resource time for the project. Building trust in this can prove to be a difficult task. Great things happen when the team trusts each other. I start off with first building trust between me and the team. You can't ever hope to improve the trust in a team if they first do not trust you.
2. Engage in unfiltered conflict around ideas
You have a better chance of having a good idea from a pool of five than you do with just one. I find some of the best ideas come from those on the team that talk the least. Getting them to give you those ideas can be tough if they feel the idea will automatically be rejected or you have others on the team with an alpha personality. To overcome this I'll sometimes just walk over to that person's desk and have a casual conversation. It is amazing what you can get from a 10 minute conversation where the person is in a comfortable environment. Once they start to see their ideas are valued you see them open up.
3. Commit to decisions and plans of action
When you have people on a team who do not believe in a decision, or plan of action, they will drag their heels to the very end. Of course this can really hurt a project. To overcome this I divide and conquer the major decisions. I break the project up into deliverables and give people ownership of those deliverables. When they are the ones making the decisions I find they will work hard to prove the decision they took and they also get much more satisfaction from the results. Every so often you will get someone who simply does not believe in the project at all and this is where you need to move them off the project, so they can do something they do believe in, or you escalate up the chain of command. Both options need to be done early.
4. Hold one another accountable for delivering against those plans
This goes hand in hand with the ownership. The more the person feels they own a deliverable, on the project, the more accountability they will take for it. And it is not enough to tell them they own it, you need to trust and accept the decisions they make. When they see this trust they know you are serious, or else it will just be a lot of hot air to them.
5. Focus on the achievement of collective results
You can have a team that works great together and produces a great product only to find they build something different from what the customer needed. This is where the team must never lose site of the objectives of the project from the customer. The results from the team need keep razor focused on what the customer needs and with all the parts of the project. If you do not keep on top of this you will find a bunch of requirements that the customer never asked for because some on the team will start to add to the scoping thinking it is good for the customer without ever validating this is true.