– See All Project Management Key Concepts –
Decomposition
What is decomposition in your project? It’s a technique that’s used for dividing and subdividing the project scope and project deliverables into smaller, more manageable parts. You’re taking something high level and turning it into more manageable pieces, and then maybe those pieces are turned into more manageable pieces as well – that’s decomposing, we’re breaking down that item into smaller pieces.
The level of decomposition is often guided by the degree of control needed to effectively manage that project. For some projects maybe that high level description is enough, and someone can go away and work on that. But in other cases you will need to break it down so that multiple teams will work on these different items and deliver those separate pieces.
Here’s where a work breakdown structure comes into it, and decomposing from a work breakdown structure. Basically we’ve got some branches of the WBS decomposed down through the work package level. We start with the first high level idea, we’ve got a value management system project and then we have the needs assessment, we’ve got standards development, systems engineering, project management as well. As part of that needs assessment we might have a current system ordered, we’ve got requirements determination and we’ve got alternatives development. All of these things need to be done as part of that needs assessment – we’re breaking it down into smaller and smaller parts, pieces that people can actually work on.
Now of course you could do this for an organizational structure as well. You might have an executive and they might have managers at their different levels and then they might have team leaders at levels further down, and you need you might need to know this as part of your stakeholder mapping for your project.
So decomposing things and breaking things down is a very useful way to do your work as a project manager.
Decomposition of the total project work into work packages generally involves the following activities. First of all, we’re identifying and analyzing those deliverables and the related work to those deliverables. We’re structuring and organizing the work breakdown structure, breaking things down into smaller pieces. We’re decomposing those upper layers and levels into the lower detailed components, then we’re developing and assigning identification codes to the WBS components similar to our requirements traceability matrix.
We need a code just to identify that – is it 101, or is it R55? Whatever the code is that makes sense or that you have assigned to these particular items and deliverables. Then we need to continue on as part of our WBS or work breakdown structure. As we’re breaking it down, we need to verify that the degree of decomposition for those deliverables is appropriate. We do that by either assigning it to the appropriate team and making sure that they have enough information to be able to work on this. If we’re using an agile methodology then we would break it down to enough work that could be done usually during a two-week sprint, and we might have multiple two-week sprints. Can they get that done? If not then maybe we need to break it down into smaller pieces of work that we know we can get done in that two-week sprint, so that we’ve got something to deliver at the end of that iteration.
And that is the idea of Decomposition.
– David McLachlan