Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with--or even disagree with--leave a comment.
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.
"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. " - I agree with whole-heartedly with this. I think one of the problems many organizations experience is a focusing on delivering a project and not what it is going to contribute to the organization's purpose or goals, and this lack of consideration impacts resource allocations and leads to mis-prioritization in the project portfolio. Having a review process in place, so that proposed projects are vetted by decision makers for their value, is critical to the health of an organization.
"We are ashamed of everything that is real about us; ashamed of ourselves, of our relatives, of our incomes, of our accents, of our opinions, of our experience, just as we are ashamed of our naked skins."