“Breakdown! Go ahead and give it to me!” Tom Petty sang those words many years ago in his song, Breakdown. That line applies to your project, too, as you need to provide a project breakdown to your sponsor and probably to the governance board. In the last post, you learned that you need to ask questions to understand schedule and budget constraints. What do you do next?

Consider the house you want built. We previously identified that the architect does not dictate needs, wants, or desires (i.e. requirements); the sponsor does that. Those high-level indications probably are not detailed enough to build the project, though. Outside the basics – those construction requirements that must be built to code – the sponsor (homebuyer) dictates how many bedrooms and bathrooms to build, whether the basement is finished or unfinished basement, etc. Even that is not detailed enough for the architect to break down (there we go!) the requirements so they can be dispatched to members of the project team to be created or delivered.

Before we align scope, schedule, and budget, we need to drill down into the requirements and define them to a detailed enough level that they can be documented, worked, and verified. For larger projects, a Business Analyst might be assigned to the project to elaborate on these requirements. If the project is not large enough, then the Project Manager usually does this, with assists from the project sponsor and their subject matter experts.

Break It Down

Where do you start? If you want all the details you can read the Business Analyst’s Body of Knowledge (BABOK). If you are assigned to this work – either because it is actually assigned to you or there is no one else to do it – you will use your best tool – asking questions.

There is a lot to this, so this following process is an oversimplification of the activity. But it is a fair start:

• From your scope document, take one of the listed requirements.
• Ask the sponsor (or their team) what it means to them.
• Document everything they say.
• Before accepting everything at face value and moving on, review what you wrote. Ask questions about everything you do not understand. You are searching for:
  • Why this requirement is important.
  • If the requirement is actually a bundle of smaller, bite-sized-chunk requirements.
  • If one person can work on fulfilling the requirement, or it requires a team.
  • If this requirement is fulfilled by one task or many.
  • If you can put a price point on it, or if it is still too general.
  • If you can put a time estimate on it, or if it is still too general.
• Exhaust all your questions the only way you can…by asking them. Take nothing for granted. Might the sponsor team get annoyed? Probably. Remember, they know what they do on a daily basis. You and your project team do not. Your intent is to document requirements to a detailed enough level for the team to understand and work with them.
• Repeat with every requirement that is in scope for the project.

Examples of Requirements Breakdowns

Here are two very oversimplified and not complete examples of a requirements breakdown. Neither is at a detailed enough level to estimate anything yet, and in some cases, activities that precede what I display have not been noted (e.g. building the foundation, installing water, gas, electric, etc.). In any event, these examples should give you a feel of the starting point for breaking down your requirements.

For the house example, labor (e.g. install insulation) and code regulations would be defined as requirements, too. For the system example, “Define Mapping Requirements” (B.1) may be composed of several different activities, each of which should be specified. Note that some of these items have nothing to do with what the user sees but are important in delivering what the user requested. This will be discussed more in the next post.

By the way, the fancy title for this output is a Work Breakdown Structure (WBS). This post has numerous examples and displays a variety of ways to visualize it.

Break Down to Build Up (Takeaways)

What have you done thus far?

You have documented, in bite size chunks, your project scope. You identified the requirements the sponsor wants at a detailed enough level that you can define the work activities, estimate them, price them, and assign them. Maybe the “go!” phase still seems far away, but you are getting closer. (Note, the “go! phase” is not a technical term in project management). In the next post, I will cover the different types of deliverables. After that, we can build your project budget and schedule from the requirements. Onward and upward!