"Why?" Leads to "What?"
Establish the Scope of Deliverables of the Project
Accurately defining the scope of deliverables is a fundamental step of successful project management. When kicking off a project, we always start with Who and Why, but the serious detailed planning of a project begins with this Step 3: Defining the Deliverables.
In a sense, the deliverables are the "what’s" of a project: deliverables = scope = what will be created or provided by the project. Defining scope involves establishing the specific outputs, products, or services that we will generate and, ultimately, handover to our stakeholders (the “who’s”) to satisfy their needs (the “why’s”). By clearly articulating and documenting what will be created, project managers can establish a clear & shared understanding among the stakeholders and team members. This clarity helps to ensure that everyone knows what to focus on. It defines what is required for project success—and, just as importantly, what isn’t.
The importance of defining deliverables (in a work breakdown structure) cannot be overstated. Pre-defined scope serves—literally—as a definition for project success, guiding both planning and execution. As my friend and PM mentor Bill McVeigh of Dash360 likes to say, “The first thing I always ask a struggling project manager is to show me their WBS.”
You can’t plan a road trip without first knowing the destination. When deliverables are not clearly established, projects are at risk of failing to create the very thing the stakeholders want. Poorly defined deliverables can also lead to scope creep, where additional tasks and requirements continually emerge, leading to missteps, delays, and budget overruns. Unclear deliverables can cause misaligned expectations among stakeholders, ultimately jeopardizing the project's success and potentially damaging relationships with clients or sponsors.
To effectively manage the scope of deliverables, follow these steps:
First, engage with stakeholders to gather input on all potential deliverables. Begin with the Mission Statement, which addresses the fundamental “why” of the project. Review this and then gather the Key Stakeholders’ input in a written Scope Statement. Use this as a tool to facilitate discussions with them to define and agree upon what the project will produce. The Scope Statement is a high-level document that describes the big, broad brush deliverables that will satisfy the needs of the Stakeholders.
Next, break down, organize, and document the high-level deliverables into logical groupings and sub-deliverables in a formal Work Breakdown Structure, or WBS. It’s also helpful to create a complimentary document called a WBS Dictionary that describes what each deliverable entails—and what it doesn’t. Again, get your stakeholders to review, comment, and, ultimately, formally sign-off on the WBS and Dictionary.
After you’ve created a WBS, prioritize the deliverables by distinguishing between essential and optional. Ideally, this discussion started earlier in the Why talks with the Stakeholders. The purpose of doing this is to help you make more informed decisions and plans moving forward.
Finally, ensure these Scope documents (Scope Statement, WBS, and WBS Dictionary) are placed under formal configuration control. This doesn’t mean that they can’t be changed in the future—instead, it means that a formal review and a systematic process must be followed to address any proposed changes. The definition of scope on a project is fundamental to all other planning; making additions, subtractions, or alterations to the agreed-upon deliverables can and will have significant cost and schedule ramifications. One doesn’t simply decide to change scope without a principled reason to do so.
Whether our project is small and simple, or big and complex, we always, always, always need a complete, accurate, and configuration-controlled definition of scope before doing any other significant planning on a project. Start with Who and Why, but then focus all your attention on ensuring a complete and accurate accounting of the What.
.