Delivering scope or fulfilling needs on a project is not always equivalent with adding value. In my opinion, a project adds value to an organization if its deliverables add value.
Many project managers approach the project in a delivery-oriented fashion. They plan for, work against, and monitor and control the project's work through deliverables. Delivery-oriented project managers make the scope's outcome tangible in order to fulfill the project's goals.
The first step to incorporating this project planning technique is to understand what a "deliverable" is. "Deliverables" are concrete and discrete artifacts of a project's outcome, such as products, functionalities, features, documents and plans. They can be obtained by "decomposing," or breaking down, the project's requirements in smaller, more manageable components.
As you decompose requirements, keep in mind that you can structure and manage the project deliverables in various ways. Some of the most common approaches for different types of organizations include:
- Spreading deliverables across project phases. This is typical for projects conducted in a waterfall fashion and for schedule-oriented projects.
- Spreading deliverables across knowledge areas. Project teams organized by areas of expertise (such as operations, legal or finance) usually use this technique in their projects.
- Spreading deliverable across processes. This is typical for process-oriented projects.
- Spreading deliverables across sub-projects. This is most effective in big projects with added complexity, where deliverables are specific for parts of the project but not for the project as a whole.
- Organizing deliverables hierarchically, from major deliverables to sub-deliverables. This is best for product-oriented projects.
As a side note, in agile projects, where teams are action-oriented, the work decomposition is done slightly different. The focus then is on epics, user stories and on the functionality to be delivered.
To decompose requirements effectively, I recommend following these tips:
- Break down the work in deliverables and sub-deliverables by focusing on "what" to deliver. Remember that decomposing requirements happens during the early stages of the project. Don't ask "when" in the project phase it will be delivered or "who" is going to take care of it. Save these questions for later, when sequencing the project work and building the project schedule.
- Organize the deliverables based on their relation to each other. Use a graphical form, such as a hierarchical tree (i.e., work breakdown structure, or WBS), a relationship diagram or a mind map diagram.
- Avoid over-decomposition — that is, excessively breaking down or over-detailing work. This leads to micromanagement or inefficient work management. A good general rule is to decompose requirements to the point where you can estimate deliverables, costs and time, and verify and measure results.
- Since you are dealing with deliverables and not activities, use nouns to describe each deliverable. Don't use verbs, adverbs or other action-driven labels.
- Verify the accuracy of the decomposition at the end of each level. Each sub-deliverable should add up to 100 percent of the deliverable above it.
Focusing mainly and steadily on the "what" is a pragmatic and efficient planning approach as you set up the project.
How do you decompose requirements?