Use a Product Breakdown Structure for Complex Solutions

You probably use a Work Breakdown Structure (WBS) in your projects, but sometimes, it isn’t enough. A product breakdown structure is helpful when you need to deliver a complex solution. A Product Breakdown Structure (PBS) is like a WBS, except it shows product details and how its components fit together. Here are the benefits of using a PBS.

  • It creates a common vocabulary for discussing the product. A PBS uses nouns, versus a WBS with verb-based tasks. The PBS defines the pieces that make up your project’s product. Because projects create unique products or services, you probably need definitions for the solution components. The PBS is where you keep those definitions. It also shows how components fit together. This helps reduce errors due to misunderstandings about what the product is and how it will be assembled.
  • It helps clarify development assignments. The PBS defines the product components, so the skills needed to build the product are easier to understand. It also helps people come up with ideas for product improvements and refinements. A PBS helps your technical team members understand where their responsibilities begin and end. This saves time and potential confusion as the project progresses.
  • A PBS helps identify alternate approaches for building the product. The PBS clarifies what is being built. The process of creating the PBS will help team members come up with ideas for how to build the product, too. It provides different perspectives for how components can be assembled and tied together. It also helps visualize how stakeholders can use the product. Because it shows the tasks you need for construction, it helps you build your WBS as well!
  • It helps identify who builds and tests interfaces. The PBS defines how pieces fit together into larger components. Each component needs to be tested to ensure it works as intended. The PBS spells out component relationships, making testing tasks straightforward. And it’s easier to assign testing tasks to team members. The visual nature of the PBS helps prevent overlooking test activities. Those test activities translate to tasks, tying the PBS to your Work Breakdown Structure. This helps ensure you have a complete picture of the product or service, and how it will be built and tested.

Have you ever used a product breakdown structure? Did you receive other benefits? Wondering how to implement one in a project? Share your tips and questions in the comments section.

Bad Risk Response Habits to Avoid

Effective risk management is crucial to project success. Unfortunately, many project managers fall into traps when developing risk responses. Bob McGannon and Bonnie Biafore share some tips for avoiding common mistakes in risk response planning:

  • *Do not* base your risk response on using standard project management tools. Saying that you will address a potential stakeholder relationship issue through your communication plan isn’t helpful. Instead, develop a response that describes how you will work differently with the stakeholder: such as: inviting the stakeholder to your risk assessment meetings or increasing the frequency of status reports to that stakeholder. You can use PM tools as long as you describe in detail the difference from standard approaches.
  • *Do not* omit details. Specifics are helpful when crafting risk responses. They help you examine conditions you need to address. For example, a common risk response is “add more resources.” Sure, that could be exactly what you need, but you need to describe that action in more detail. Specify the resources you need, the skills and experience required, and where you will get them. If you will contract resources, identify the lead time needed to engage those resources.
  • *Do not* create overly generalized responses. Risk responses need to address the risk’s cause and impact. Let’s say you have a project task to transport parts. There’s a risk that the truck won’t show up on time to pick up the parts. Your response could be to keep an extra truck on standby. This would be appropriate if the risk event is a truck breakdown. But what if truck drivers go on strike! Instead, make sure your risk responses are complete by addressing the impact while considering the causes. In this example, the impact is a delay in delivering crucial parts, which requires two risk responses. One for potential truck breakdown and a second for a potential driver strike.
  • *Do not* use extra checking or verification as a risk response. Verification activities show if a risk may happen or is happening. They do not address what you will do if the risk occurs. Instead, create a response that describes the actions you will take to address the risk if it occurs.
  • *Do not* define certain, or near certain events, as a risk. In a 6-month construction project, it will rain at some point. So you need to build your schedule to handle that. Addressing flooding due to excess rain is different, because flooding isn’t a certainty. Likewise, a project team member might miss a few days of work. Your schedule needs to accommodate that. Address short resource absences with scheduled breaks or by including extra time to complete critical tasks. A team member resigning and joining another company is a risk and requires a specific risk response action.

For more about risk, check out Bob’s Project Management Foundations: Risk course. That course and my Project Management Foundations course are both unlocked through December 31, 2025, in the LinkedIn Learning path: Career Essentials in Project Management by Microsoft and LinkedIn to support you in gaining digital skills for tomorrow’s workforce. 

Coming Up:

Leading with Curiosity- How do you get better at asking questions? Natalie Nixon has invited me to join her on Wednesday December 14th at 12pm ET to explore what it means for a cognitively and experientially diverse team to be curious and creative and what you, as a leader can do to support that effort.

The Worst Mistakes PMs Make with Risk- Bob McGannon and Bonnie Biafore are holding a LinkedIn Office Hours on December 19, 2022, at 3:30PM MT (5:30 ET and 8:30 AM AEST December 20, 2022). Join us for an in-depth discussion about developing risk responses.

Have a big job? Use small projects!

photo by Anders J on Unsplash

In today’s complex world, projects can become quite large. The problem is large projects are often fraught with issues due to the amount of change they create and the complexity that comes with those changes. Here’s why a series of small projects usually outperform a single large initiative.

  • They deliver value earlier. Small projects finish faster, which means the business realizes value sooner. Organizational change also occurs in smaller bites, so stakeholders can digest new ways of working more easily.  
  • Changes are easier to handle. A series of small projects provides agile-like results. Learning from one project helps the team improve on the next one. Stakeholders learn from using the project’s products, so they create better requirements. And better requirements improve the value the business realizes.
  • Key staff members aren’t as much of a bottleneck. Project assignments often take key operational staff away from their day-to-day tasks. Assigning a critical staff member to a two year project is a challenge. Rolling on and off a series of shorter projects is easier to juggle. That way, you can use internal staff instead of expensive contractors. (And contractors don’t know your environment as well, which can lead to poorer project solutions.)
  • Small projects are less complex and less risky. Smaller projects mean smaller scope. Less scope means fewer new functions, fewer stakeholders, and fewer team members. All these mean less risk to the business. However, a series of smaller projects does introduce a different risk. Changing business priorities might mean later projects in the series could be cancelled so some of the original scope is lost.

Have you divided a big project into several smaller ones? What worked well? What didn’t? Share your experiences in the comments section.

For more about small projects, check out my Project Management Foundations: Small Projects course.

Coming up:

Leading with Curiosity

How do you get better at asking questions? Natalie Nixon has invited me to join her on Wednesday December 14th at 12pm ET to explore what it means for a cognitively and experientially diverse team to be curious and creative and what you, as a leader can do to support that effort.