When a project is bigger than can be delivered efficiently with a single large team, it is common practice to divide the work among a number of smaller teams. While the coordination overhead of managing multiple teams is introduced, doing so reduces the effort involved in keeping everyone within each team aligned towards a shared goal. It also reduces the potential for unhealthy conflict and could increase individual ownership for work items. It might also lead to better collaboration between team members.
But once the decision has been taken to split work across a number of teams, what options are available?
Three common methods are to:
- Divide the features or capabilities making up the scope of the project. This is splitting the “what”.
- Divide the project along solution/design or skill lines. This is splitting the “how” or “what”.
- A combination of the previous two approaches
If we decide to take a scope-centric approach to dividing work, the benefits are that it is possible for the team to work independently to deliver a complete feature end-to-end and be able to release it without waiting for other teams to complete their portions. This approach also enables a team and their “voice of the stakeholders” (e.g. Product Owner, Business Lead) to develop deep business expertise of a specific area of the overall product, service or result.
Disadvantages are that such teams could end up producing components which don’t fit together well to form a coherent whole unless there are frequent coordination checkpoints between the teams. There might also be inconsistencies in how similar aspects of the components (e.g. user experience) are handled, and redundancy when the same enabling capability is built by more than one team for their needs. Finally, if there is limited capacity of a skill set required by all teams, it might be difficult to construct “whole” teams with dedicated staffing.
When we divide the project along solution (e.g. database, middleware, user presentation) or skill-based lines, the advantages and disadvantages are the opposite of what they were for the scope-centric approach. This model works well when you have limited capacity of specific skills, it can also develop deep technical acumen within the team and reduces the likelihood of inconsistent or redundant outputs. However, it does significant increase intra-team coordination efforts and could delay the ability to get feedback from external stakeholders on completed features or capabilities.
To address this, some leaders will take the approach of starting with a solution or skill-based approach until sufficient enabling components and standards have been built to enable effective use of scope-centric teams.
As usual, I wanted to compare my experience with that of others. I ran a one week poll in both PMI’s LinkedIn Project, Program and Portfolio Management discussion group and the ProjectManagement.com community asking respondents to pick which of the three approaches they had used in their last large project. I also provide a fourth choice encouraging practitioners to share any alternative methods they had utilized instead of the three common choices.
The poll received only 41 responses and of those, 56% indicated both scope and solution or skills-centric approaches had been used. 24% indicated a solely scope-centric approach and 15% a solely solution or skills-centric approach. 5% picked the “other” choice, with one respondent providing a different method which was to distribute work based on a regional approach. This approach will work well when region-specific requirements can best be handled by having local teams and where there is expected to be little integration of outputs between the regions.
If there are other approaches which you have used in your recent projects, I’d encourage you to share those in the comments.
(If you liked this article, why not read my book Easy in Theory, Difficult in Practice which contains 100 other lessons on project leadership? It’s available on Amazon.com and on Amazon.ca as well as a number of other online book stores).
Easy in theory, difficult in practice 