Project Management

What, how, who or where - how do you divide work between multiple teams?

From the Easy in theory, difficult in practice Blog
by
My musings on project management, project portfolio management and change management. I'm a firm believer that a pragmatic approach to organizational change that addresses process & technology, but primarily, people will maximize chances for success. This blog contains articles which I've previously written and published as well as new content.

About this Blog

RSS

Recent Posts

Who makes the rules for your team?

All constraints are important but some are more important than others

How current are your risks?

How are you allocating and returning contingency reserves?

How are learnings shared between project teams?


Categories: Agile, Project Management


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.

Posted on: May 22, 2022 07:00 AM | Permalink

Comments (4)

Please login or join to subscribe to this item
Dear Kiron
The topic you brought to our reflection and debate was very interesting.

Thank you for sharing, for your opinions and for sharing the results of your weekly poll.

I prefer the approach of dividing the features or capabilities making up the scope of the project

I didn't have the opportunity to see your question, here in our community, on this topic

Thanks Luis - I'd followed your advice for this poll of posting in the Project Management Central discussion group requesting feedback.

Dear Kiron
I didn't have the opportunity to see your post asking for our opinion
Like me, how many people haven't seen it?

I've used all these approaches. As you surmised, each one creates its own set of "silos" that then require integration.

Please Login/Register to leave a comment.

ADVERTISEMENTS

"Why is it that people rejoice at a birth and grieve at a funeral? It is because we are not the people involved."

- Mark Twain

ADVERTISEMENT

Sponsors