Building High-functioning Teams

February 2017

While there is no magic recipe, and some teams are high-performing because the team members are brilliant and quickly strike up good chemistry, there are number of things a Project Manager can do to improve how well a team is functioning. The goal is to bring the team up to an acceptable level of performance. At some point, the law of diminishing returns kicks in, and additional effort will not have any measurable effect on team performance.

1. Set team objectives.

2. Define roles of each team member.

3. Practice.

4. Measure results. Good enough?….then stop.

5. Refine roles and return to Step 3.

1. Set Team Objectives

This activity should be done as soon as the team is assembled, and should be done together. The Project Manager should have a good idea of what the project objectives are, and what a successful outcome is (from the Charter), and is in a good position to convey that to the team. However, team buy-in is essential.

2. Define Roles for Each Team Member

As a team, the team should look at each of the roles on the team, and identify how they should interact and contribute to the team objectives. Key documents produced and methods of interaction are key outcomes from this activity. The roles should be written down and filed in the project repository, lest team members forget. The project manager’s role should be defined as well. Understanding these roles is a key input to planning, helping to identify the project tasks and assigning them to the right people.

3. Practice

Using the team objectives and roles, begin planning. Identify the first set of tasks, have them estimated and assigned. Let the team begin working on that. The project manager shifts into an observation role, providing guidance and feedback when slip-ups occur.

4. Measure Results

Track the hours spent on the tasks and look at the deliverables’ quality. Compare them to the plan. Meet with the team and let them know how they did. If you met the estimates, and completed the deliverables, may team improvement should take a back-burner to the delivery of the project.

5. Refine Roles

If the results weren’t as expected, review with the team what didn’t go well, and adjust the role definitions. Plan for the next piece of the plan. If there’s rework, then make sure to plan for that as well.

A Real-life Example

There is more art than science to this approach. It’s simple, but it works. In my younger days, I was a whitewater rafting guide. Each day, I would receive a brand new team of twelve “paddlers”. Some of them knew how to paddle, some of them knew each other, but often there would be small groups assembled together into a raft crew, with little experience. As a guide, it was my job to teach that what we needed to do, and how we would do it. Failure to properly execute put all of us, me included, at risk. Here is how I put this approach into practice:

1. Set Objectives: The overall goal is to safely navigate the river, having fun along the way, but most importantly, stay safe. To achieve that goal, the raft must be propelled faster than the current is flowing (about 5 mph), and must be manoevered around certain unsafe obstacles.

2. Define Team Roles: To propel the raft faster, all paddlers need to know how to paddle properly, in unison. Turning the raft requires that one side paddle in the opposite direction than the other side. Staying inside the raft is best done if the paddlers know how to sit in the raft. Paddlers in the front need to know how to brace their paddles against the raft so as not to be catapulted behind the raft. Paddlers in the rear need to be aware the raft may suddenly disappear beneath them, and they need to be ready to lower their centres of gravity and perhaps grab on to a rope. All paddlers need to listen for instructions, such as direction of paddling or to shift raft locations quickly (to avoid rocks).

3. Practice: Before the first rapid, I would explain everything in step 2, and we’d practice all of it. Only after the crew was taken through these paces, would I attempt the first rapid, which happened to be a Class 5 rapid (scale goes from 1-5). The crew would assume their paddling positions and being paddling. Going faster than the current, I could use my very sturdy paddle as a rudder, and start down the ascent. In the middle of the rapid, I would holler corrective actions, count the crew numbers after each big wave (in case I had to pull someone back in), and we’d proceed.

4. Measure Results: Below the 1st rapid, after the adrenalin resumed to normal levels, the crew and I would go over what went well, and what didn’t, in a friendly conversation. After a couple of rapids, there would be less room for improvement, and we’d generally stop tinkering.

5. Refine Roles: For the things that did not go well, we’d go over them again verbally, and then return to step 3 (Practice). Some people would come to the realization on their own that the front of the raft was not the place for them, and they’d ask someone to switch. Others were totally fine with sticking to their original role.

I followed the same approach over a hundred times per summer, for four summers. I never lost anyone (permanently), and other than a few nicks and bruises, all crew members successfully transported themselves through some sticky situations. As an added bonus, they appeared to have had a great time, and many came back as repeat customers. As a project manager, I instinctively follow the same approach, and, my teams have spent thousands of hours successfully navigating their way through challenging projects, having fun at the same time. Many of those team members have become repeat customers as well.