You might already have a clear picture in your mind of what your project is about and what it will be when it is complete. On the other hand, the project might still seem a little fuzzy, at least around the edges. It’s not uncommon for other stakeholders to have a clear vision when you’re not sure if you get it just yet.
And don’t be surprised if one stakeholder’s expectations seem clear enough, but another stakeholder’s expectations sound entirely contradictory.
The challenge at this important starting point is to define the project without ambiguity, so that everyone involved is talking about the same project, has the same expectations, and wants the same results. Defining the vision clearly at the beginning prevents redirection (and the attendant wasted effort) in the middle of the project. More importantly, a lucid articulation of the project vision prevents disappointment (which can often cost big bucks) at the end.
So how do you create a vision? You work with key stakeholders, such as the customers, potential users, sponsors, executives, and project team members, to collect their expectations of the project. You might have to reconcile conflicting views and opposing agendas. Throughout this process, you identify the goals of the project as well as their measurable objectives. You identify project assumptions, spell out potential risks, and make contingency plans for those risks. You also identify known limitations, such as budget, time, or resources.
By the time you finish this high-level project planning and get the necessary approval, everyone involved knows exactly what they’re signing up for.
A defined scope articulates the vision of the product you’re creating and the project that will create it. As your project is executed and issues arise, your defined scope can help you make decisions. The scope definition is your guideline for whether the direction you’re considering is really the job of this project. If you don’t stay focused on the agreed-upon scope of the project, you’re likely to experience “scope creep,” in which you end up spending time, money, and resources on tasks and deliverables that are not part of the original vision.
This is not to say that scope can’t change during the course of a project. Business conditions, design realities, budgets, time, resource availability, and many other factors can necessitate changing project scope midway through. In addition, as members of your project team work on their tasks, they are likely to generate great new ideas. Nonetheless, your scope document helps you make decisions and manage any changes so that you turn in the proper direction—in line with your organization’s overall strategy, the project’s reason for being, and the project’s goals.
There are two types of scope: product scope and project scope. First, you define the product scope, unless it has been defined for you. The product scope specifies the features and functions of the product that will be the outcome of the project. The product scope might well be part of the product description in your charter. The product can be tangible, such as the construction of a new office building or the design of a new aircraft. The product can also be the development of a service or event—for example, deploying a new computer system or implementing a new training initiative.
Regardless of the type of product, the product scope indicates the specifications and parameters that paint a detailed picture of the end result. For example, the product scope of the construction of a new office building might include square footage, number of stories, location, and architectural design elements.
The project scope specifies the work that must be done to complete the project successfully, according to the specifications of the associated product scope. The project scope defines and controls what will and will not be included in the project. If product development will have multiple phases, the project scope might specify which phase this project is handling. For example, a computer system deployment project might specify that its scope encompass the infrastructure development and installation of the new computer system, but not the documentation and training for new system users. Or it might specify that the project handle all aspects of the product, from concept through completion of the final stage.
To define the project scope and communicate it to other key stakeholders, you develop and record the scope statement. Depending on your organization’s planning methods, certain elements of the scope statement might be defined very early, sometimes even before you are assigned as project manager. Other elements might be defined just before you begin identifying and sequencing the project’s tasks. Your scope statement should include the following:
Project justification. The scope statement should define the business need or other stimulus for this project. This justification provides a sound basis for evaluating future decisions, including the inevitable tradeoffs. This information can come straight from the project proposal or business case that initiated the original formation of the project.
Product description. The scope statement should characterize the details of the product or service being created. The project justification and product description together should formulate the goals of the project.
Project constraints or limitations. The scope statement should include any factors limiting the project. Factors that can limit a project’s options include a specific budget, contractual provisions, the availability of certain key personnel, a precise end date, and so on.
Project assumptions. The scope statement should list any elements considered to be true, real, or certain—even when they might not be—for the purposes of continuing to develop the project plan and move forward. By their nature, assumptions usually carry a degree of risk. For example, if you don’t know whether the building for a commercial construction project will be 10,000 or 15,000 square feet, you have to assume one or the other for the sake of planning. The risk is that the other choice might end up being correct. You can adjust the plan after the facts are known, but other project dependencies might already be in place by then.
Note
Although certain aspects of your scope statement might remain unchanged through the iterative planning process, that’s not necessarily the case with project limitations and assumptions. As the scope becomes more tightly defined, the limitations and assumptions come to light and are better exposed. Likewise, as you continue down the road in the planning process, the entire project scope tends to become more and more focused.
Project deliverables. The scope statement should list the summary-level subproducts created throughout the duration of the project. The delivery of the final subproject deliverable marks the completion of the entire project. This list might bring into focus major project phases and milestones, which will be valuable when you start entering tasks into your project plan.
Project objectives. The scope statement should enumerate the measurable objectives to be satisfied for the project to be considered successful. The objectives map to the deliverables and are driven by the project goals, as described by the project justification and product description. To be meaningful, the project objectives must be quantifiable in some way; for example, a specific dollar amount, a specific timeframe, or a specific level of quality. In fact, think “SMART” when setting project objectives to ensure that they are Specific, Measureable, Attainable, Relevant, and Time-Bound.
Note
Your scope statement might also address other project planning issues, such as communications, quality assurance, and risk management. It can define the reporting requirements and the collaboration tools that the team will use. The scope statement can also specify the minimum level of quality acceptable, define the potential risks associated with the itemized limitations and assumptions, and stipulate methods of countering the risks.
Product scope and project scope are intricately linked. The project scope relies on a clear definition of the product scope. The project scope is fulfilled through the completion of work represented in the project plan. In the same way, product scope is fulfilled by meeting the specifications in the product requirements.
With the draft of the scope statement in hand, you have a document you can use to clearly communicate with other project stakeholders. This draft helps you ferret out any cross-purposes, mistaken assumptions, and misplaced requirements. As you continue to refine the scope statement, the project vision is honed to the point where all the stakeholders should have a common understanding of the project. And because all the stakeholders participated in the creation of the vision, you can feel confident that everyone understands exactly what they’re working toward when you begin to execute the project plan.