Focusing the Project Vision

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 clearly define the project without ambiguity, so that everyone involved is talking about the same project, the same expectations, and the same results. Defining the vision clearly at the beginning prevents redirection (and the attendant wasted effort) in the middle of the project or disappointment 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 get their project expectations. You might have to reconcile conflicting views and opposing agendas . Throughout this process, you'll identify the goals of the project as well as their measurable objectives. You'll identify project assumptions, spell out potential risks, and make contingency plans for those risks. You'll 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 will know exactly what they're signing up for.

Defining Scope

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 is your guideline for whether or not the direction you're considering is really the job of this project or not. If you don't stay focused on the scope, 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 make it necessary to change project scope midway through. Nonetheless, your scope document helps you manage those changes so that you change in the proper direction ”in line with your organization's overall strategy, the product's reason for being, and the project's goals.

Understanding Product Scope and Project Scope

There are two types of scope: product scope and project scope. First, you define the product scope, unless it has already 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, deployment of a new computer system or implementation of 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 there will be multiple phases of product development, 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.

Developing the Scope Statement

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've been 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.

Product description.         The scope 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 should include any limiting factors to the project. Factors that can limit a project's options include a specific budget, contractual provisions, a precise end date, and so on.

Note  

Because we use the term constraints throughout this book to mean task constraints, in this chapter we're using the term limitations to refer to overall project constraints.

Project assumptions.       The scope should list any elements considered to be true, real, or certain ”even when they might not be ”for the sake of being able to continue developing the project plan and moving 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 the project justification and product description are typically broad statements that 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 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 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, in terms of a specific dollar amount, a specific timeframe, a specific value, or a specific level of quality.

Note  

Your scope statement might also address other project planning issues such as communications, quality assurance, and risk management. The scope statement can define the reporting requirements and the collaboration tools to be implemented. 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. Likewise, 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 flush 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.