"[Starting a Project] without clearly defining what needs to be delivered is like embarking on a journey without a map—you might reach a destination, but it's unlikely to be the one you intended." — Anonymous
In the last couple of posts, I gave some examples of identifying stakeholders and establishing the project's mission. In today’s piece, I want to continue with some examples of establishing and documenting the deliverables, or scope, of a project. This step answers the question: "What exactly is the project supposed to create and/or provide?"
Defining—and, yes, documenting—the "what’s" of a project in a work breakdown structure is essential for its success. Project success literally begins with defining what success actually looks like. Without an approved WBS, no one can be certain what we’re building. A WBS provides clarity for the team, manages stakeholder expectations, and helps prevent future scope creep. Let's revisit our examples to illustrate how defining the "what’s" shapes an entire project:
Example A: Let's Bake a Cake
For a cake baking project, the "what" may go beyond just producing an edible dessert. It involves establishing what will and won’t accompany the cake. For instance, let’s imagine we’re baking a birthday cake for a child’s party at a local park. Do we also have to supply candles for the cake? What about paper plates and plastic forks? Napkins? Any other utensils we must provide, such as a knife to cut the cake and/or a serving spatula? Will we deliver the cake in a box or a plastic cake container? Will the cake go on a cake stand at the party? Do we have to supply any other decorations? And so on…
This WBS approach may seem like over-kill for such a simple project, but imagine showing up at the park without plates, forks, and napkins—and no one else brought those things either. Even on a simple project like this, a written list of what you will—and won’t—provide is essential for managing expectations—and therefore ensuring a successful birthday celebration.
Example B: Let's Write a Book
Like the cake example above, defining the "what’s" of a book project can extend far beyond just writing its text. What else are we responsible for? For example, as the author, are we also tasked with getting the book copy-edited before submission? What about cover art? Illustrations? Publishing formats? Front and back matter? Author bio’s, marketing information, book signing events & tours, and so on…
As most published authors will tell you (this one included!), writing the text is often only just half the battle. Before signing a book contract with a publisher, you need to ensure you and they are on the same page (pun intended) re: who is doing what.
Example C: Let's Design a House
The "what" of a house design project often, but not always, involves drawing and specifying all the elements and systems that will make up the completed structure. Your job as project manager is to ensure you’ve captured all elements that the project is required to provide. This may or may not include such things as A&E drawings, structural designs, electrical schematics, plumbing layouts, interior plans and specs, etc.
Further, each of these might include sub-deliverables. For instance, "Architectural plans" might break down into deliverables like site analysis, conceptual design, detailed design, and construction-ready documents. Are we supposed to provide some or all of these as part of the house design? The project may also be tasked with providing all the required documentation for obtaining building permits—and maybe even submitting and chasing those permits. Further, so-called “as-built” drawings and specs that are created and updated after construction may be your responsibility. Without a clear, documented, and agreed-upon WBS, we and our stakeholders are left assuming we each know what the other is thinking and expects.
Example D: Let's Go Nuclear!
The "what" of constructing a nuclear power plant is incredibly complex, involving many systems, structures, and components. I won’t attempt to create a complete WBS for this kind of project, but at a very high-level, it may look something like this:
Now, of course, each of these would be extensively subdivided and detailed. For example, "Reactor systems" might break down at the next level into components like the reactor vessel, fuel assemblies, control rods, primary coolant system, and so on. And each of those would likely be composed of even more sub-deliverables. A nuclear power plant isn’t a birthday cake, but they both need some kind of WBS to ensure a mutual understanding of what success looks like.
Bonus Example: Inertial Simulator
Reflecting on my botched inertial simulator project, a well-defined WBS could have prevented many of the missteps. Instead of just jumping in and making a hash of the project, taking the time to create a WBS would have helped me focus on the right things and in the right order.
If I had created a WBS back then, it probably would have included mechanical systems, electrical controls, safety systems, lifting and handling, documentation, and so on:
At a minimum, a detailed breakdown would have helped me understand the need to consult with various stakeholders, gather complete requirements, consider lab space and transportation constraints, and address safety concerns from the outset, rather than waste all the time I did.
The Bottom Line:
Establishing a clear and comprehensive WBS for your project is crucial for success. Whether you're designing a house or building an inertial simulator, starting with a well-defined and documented listing of the "what’s" sets the foundation for project success. It provides a roadmap for what needs to be delivered, helps in acquisitions planning, resource allocation, stakeholder interactions, and ensures that nothing important is overlooked. Without this critical document, you may eventually get to the project’s end only to discover the destination is one that nobody actually wanted.
(PS: And don’t forget a written WBS Dictionary to accompany the work breakdown structure; without this document, the WBS is just a list of things without proper context.)