How do you organise your project teams?
The majority of us will be required to work in a team at some point in their career, in fact it has become a valuable testing method both in education but also in recruitment and selection. But how can the stage of the project affect how the team is structured and your role in the team?
Traditionally, the person with the most expertise and experience is placed in charge i.e. a chief programmer, assuming they will make the best decisions about how to allocate tasks and responsibilities. You would expect teams that adopt this model to feature a rigid hierarchy, whereby final decisions are centralised through this single, formally designated individual. A predictable downside of this approach is that the person may become a bottle neck or particularly as projects increase in complexity and team size.
In contrast to this an alternative approach, which has become increasingly popular, is to allow teams to self-manage. The assumption of this model is that team members are best equipped to match skills with needs and to organise their own tasks accordingly. These teams share of expertise and decentralize decision making; this approach allows ideas to flow freely. However, it dramatically increases the number of people who need to frequently interact with each other, thus increasing coordination demands and reducing efficiency.
Recently, I came across an interesting piece of research (Kudaravalli, S. Faraj, S. Johnson, S. How to Get Experts to Work Together Effectively. Harvard Business Review. May 10, 2017) where they discovered that the traditional approach to setting up a project team isn’t always the most effective.
The study showed that the highest-performing teams were the ones that adopted a different configuration of expertise depending on the needs of the project phase. These findings suggest that different project phases require different ways of organising expertise and that teams should recognise that the design and implementation phases of a project deal with distinct kinds of knowledge.
The Project Life Cycle
The design phase with its complex knowledge work favours the creative exploration of a broad range of ideas. Here a decentralised configuration is appropriate because:
- eliciting and sharing expertise during the design phase allows teams to achieve a better understanding of ill-structured or poorly understood problems, and converge on and design an optimal solution;
- figuring out the scope using a decentralised approach reduces team conflict and leads to more effective solutions;
- broadly tapping into expertise reduces the risk of insular thinking that can occur in a more rigid hierarchy.
As the project moves into implementing a solution, centralising expertise among a few designated experts is appropriate because:
- building a solution favours convergent deep knowledge of how best to concretely implement a solution;
- centralising design expertise avoids the pitfalls of analysis paralysis! During implementation phase, a focus on building leads to increased efficiency;
- having centralized expertise and clearly defined roles and responsibilities reduces team conflict and reduces coordination requirements.
The research suggests that when managers are staffing, organising, and managing knowledge projects, they should embrace flexible organisation of expertise — based on the needs of the project phase — in order to maximise team performance.
Each one of us can take note of these findings and consider how we approach the next project or team exercise? Those teams that successfully do have achieved higher ratings on multiple measures of performance: higher coordination success, less team conflict, increased team effectiveness, and higher client satisfaction.
We at The Survey Initiative have over 20 years experience in employee research. If you would like any information or help with any aspect of employee research, and ways to boost engagement and productivity levels, then why not give us a call on +44 (0)1255 870735 or contact us via our website, we’re waiting to hear from you.