Voices on Project Management

> Back to Voices Home

More posts in Project Requirements

Decomposing Requirements for Tangible Project Outcomes

| | Comments (1)
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:

  1. 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.
  2. 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.
  3. 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. 
  4. 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.
  5. 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?

Learn about the basics of project work planning, including the four main steps of planning.

The Scoop on Requirements Scoping

| | Comments (1)
We've all been there. When a project's scope isn't properly managed, it can lead to schedule delays, budget overruns or not meeting project goals.

Requirements scoping can help keep projects under control by establishing what criteria — such as prioritization — will drive decisions. The process also clearly details what the project will deliver, and perhaps just as importantly, what it won't.

Depending on a project's complexity, goals and project management approaches, there are various ways to manage requirements scoping. Here are three of the most common.

1. Early scoping assumes all scoping is done as part of the project charter or during the scope definition. The approach relies on precise estimations of required resources, budget and time. It discourages scope creep and requirements changes.

The advantage of early scoping is that it facilitates starting project work ahead of time. On the other hand, poorly estimated efforts can translate into budget or schedule overruns, resources bottlenecks or missed project goals. 

Early scoping is recommended for projects where the main focus is on the scope, and on ones with no, or minimal, budget and schedule constraints. For example, early scoping works well on consolidation or integration projects, where the constraints on the scope (budget limitations, for instance) impact objectives.

2. Late scoping is performed after collecting, analyzing and even designing the requirements. At such late stages, efforts estimates are much easier to assess and generally more accurate.

Although late scoping can keep a project within budget and schedule boundaries, this approach has a considerable downside: Efforts spent for out-of-scope requirements are wasted or deferred. Consequently, this leaves less time, budget and resources for addressing in-scope requirements — the ones that matter.

Late scoping is recommended for projects addressing requirements that have similar (and not critical) relevance for the project's outcome — for example, regular maintenance projects.

3. Iterative scoping is a balanced, incremental approach. The entire scope is broken down and prioritized by items that have the highest relevance. These will be addressed in the first scoping round. The rest of the requirements, as well as potential changes or rework, are subject to scoping in subsequent iterations. 

The requirements scoping and the project work advance in a rolling wave approach. Iterative scoping is especially useful for IT and agile projects.

How do you manage requirements scoping on your projects?

Gain Executive Buy-In for Project Requirements

| | Comments (1)
No matter what industry you work in, chances are you've had to build a long list of specific requirements to help define project success and to identify project risks.

In many cases, you're required to align with your primary stakeholders on these requirements before you can move to the next project phase. These stakeholders are likely high-level executives who come from the sales or marketing side of business, or who are senior enough to have bypassed getting into the fundamentals of a project.

Whatever the case, you're now left with the challenge of presenting them with these requirements. If they don't agree or understand your direction, you can't proceed on the project.
 
If you're lucky, your stakeholders believe they hired you and your team because you're the experts. In this case, the presentation is more about showing them you've done the work and the next steps, instead of actually having to get their buy-in.
 
Conversely, you may find yourself in a situation where many of the requirements need to be discussed and debated among the stakeholders.

No matter which of these situations you're in, I've found that this three-step approach works best when presenting requirements to executives:
 
1. Divide the requirements into categories that will vary depending on the type of project. For example, if you're producing a software solution, your categories may be "security," "user interface," "connectivity," and "primary functionality."

2. When you have determined your categories, summarize the high-level direction being defined by each of the micro-requirements under each category.

If there is a particularly divisive requirement and you anticipate debate, you should pull that requirement out and highlight it with its own slide. For instance, if you have decided to develop using Java and this needs to be discussed, or specifically approved, make sure that item is highlighted.

3. For all categories of requirements, create a list of pros and cons for the recommendation, and provide justification for the choice the team made. For documentation purposes, I would also include a check box that indicates agreement or disagreement from the stakeholders.

Presenting detailed requirements to executives, especially in a limited time frame, is always a delicate operation. In my experience, following this approach will ultimately help you get the support you need to move forward in your project's next phase -- without risking a drawn-out approval process.

What techniques have you used successfully to gain executive-level buy-in on project requirements?

About This Blog

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.

All posts represent the opinions of the bloggers.

Follow PMvoices on Twitter

About Bloggers

Keep checking back because the voices for this blog will continue to grow and change to represent a variety of regions, industries and opinions.

Read blogger profiles

Voices Poll