Project Management Institute

Scoping out a scope statement

PM Industry

IN FOCOUS

SCOPING OUT A
SCOPE STATEMENT

William R. Duncan, PMP

Projects have a well-documented tendency to get out of control soon after they start and to get worse as the days go by. While no one action can keep a project off the shoals of disaster, a well-written scope statement can provide a rudder to keep the project headed in the right direction.

A scope statement is not just another piece of paper—it is the foundation for your project plan. A scope statement does not have to be long—most can be done well in a page or two. A scope statement should not be hard to develop—you can generally find the information you need either in your statement of work (if you are doing the project as a contractor) or in your project charter (if you are doing an internal project).

According to PMI's A Guide to the Project Management Body of Knowledge, a scope statement has three major parts: project justification, project deliverables, and project objectives.

PROJECT JUSTIFICATION

The project justification (or purpose) is an explanation, from the customer/client/owner perspective, of why the project has been undertaken. Documenting the justification is critical—it forms the basis for making both management decisions (e.g., cost/schedule tradeoffs) and technical decisions (e.g., performance/reliability tradeoffs).

The team's understanding can often be improved if the scope statement includes any measurable or observable factors that would demonstrate that the purpose has been achieved. For example, saying that the justification for a new plant is to “reduce unit costs by 20 percent within one year of start-up” is far more useful than just saying that the project's aim is to “reduce costs.”

When a project is done under contract, the buyer's justification may be obscure. But understanding it is no less important. It maybe useful here to recall the software contractor who defined the client's purpose as “to automate” a certain paper-handling process. The actual justification, which the contractor failed to discern, was “to reduce costs and processing time.” The contractor did, in fact, automate the process. The client, however, was less than pleased to discover that the new system involved increased costs and increased processing time.

The client is still handling their paper manually and looking for ways to reduce costs and processing time. The contractor is defending itself in court.

Some common project justifications (and observable factors) include:

  • Reduce cost or overhead (by some amount or percentage).
  • Increase efficiency or effectiveness (in which operations, by how much).
  • Increase revenue or market share (by how much, by when).
  • Meet regulatory requirements (and what happens if we don't).
  • Improve customer support (in what way, by what measures).
  • Provide more flexible system (to do what).

PROJECT DELIVERABLES

This section should identify the major, summary-level items whose full and satisfactory delivery marks completion of the project.

img

William R. Duncan, PMP is a Partner in Duncan • Nevison, a project management training and consulting firm headquartered in Lexington, Massachusetts. A member of PMI's Standards Committee since 1989, Bill has been Director of Standards since 1992. He has also served PMI as a member of the Editorial Review Board of the Project Management Journal and as chapter President for the Mass Bay PMI Chapter Bill has over 20 years of management and consulting experience. He has managed several major software development projects and spent five years with the consulting group of one of the Big Six accounting firms managing organizational change projects. Since founding Duncan Associates (now Duncan • Nevison) in 1981, he has trained project managers in a variety of application areas, including aerospace, architecture, biosciences, construction, electronics, and software development. He is a 1970 graduate of Brown University

These items will be defined in more detail in the work breakdown structure.

Every deliverable, even at this summary level, must have clearly defined completion criteria. For example, “clinical trials” is not sufficient. The deliverable would be better defined as “three Phase I trials completed according to the approved protocol.” In addition, it is often useful to develop an order of magnitude estimate of the size of each deliverable. For example, will an Environment Impact Statement be 15–20 pages in length or 150–200? These preliminary size estimates will provide a useful check later when you are developing detail cost and effort estimates.

In addition to the actual product of the project, common summary-level deliverables (and possible completion criteria) include:

  • Design documents (approved by a specific individual or group).
  • Test results (passes all tests in identified test plan).
  • Completed pilot (elapsed time in operation without errors, satisfactory performance per questionnaire completed by users).
  • Training (satisfactory instructor performance per questionnaire, satisfactory student results per testing).

PROJECT OBJECTIVES

This section should provide a list of additional measurable criteria that must be met for the project to be successful (achieving the project's purpose and producing the major deliverables are also required for success, but these items do not have to be repeated here). If there are no additional factors (always possible if somewhat improbable), state that there are none.

A Guide to the PMBOK says that “project objectives should have an attribute (e.g., cost), a yardstick (e.g., U.S. dollars), and a measure (e.g., 1.5 million).” It also notes, quite correctly, that unquantified objectives such as “customer satisfaction” entail high risk.

Project objectives will generally fall into one of the following categories:

  • Product characteristics. There are often one or two specific features or functions that absolutely cannot be compromised.
  • Cost and schedule constraints. Ideally, both cost and schedule would be outputs of the planning process. In reality, there are often inputs imposed by management or the customer. When such constraints exist, the scope statement is a good place to document them.
  • External constraints. For example, are there regulatory compliance requirements?

SUMMARY

“When there is poor scope definition, final project costs can be expected to be higher because of the inevitable changes which disrupt project rhythm, cause rework, increase project time and lower the productivity and morale of the workforce.”* A well-written scope statement is the start of proper project scope definition.

*Scope Definition and Control, Publication 6-2, p. 45. 1986 (July). Austin, TX: Construction Industry Institute. ❏

Organizational Profile

What do the best companies say? They say “we have the best project managers.” According to research published in the Harvard Business Review, the companies with the strongest financial performance over the past decade consistently attribute their success to having the best project managers, project managers who know how to get projects done on time and within budget without compromising either scope or quality.

Duncan • Nevison provides project management training, tools, and consulting to help develop the best project managers. All of our training programs are fully compatible with PMI's A Guide to the Project Management Body of Knowledge. Our premier offering is a Certificate in Project Management— a sustained developmental experience that includes 20 days of training on leadership, planning and control, team building, negotiating, risk management, decision making, conflict management, and systems thinking, as well as Project Management Professional (PMP) Exam preparation.

Our project management tools include the P7™ Planning Guide (customizable forms and checklists to improve your planning); The Project Manager's Toolkit (a subscription newsletter with practical ideas for full- and part-time project managers); our extensively research Project Thinking™ model (a dynamic model which predicts the likely result of your management decisions); The Game of Projects™ (a board game to improve both individual skills and teamwork without the high costs of on-the-job training); and the Estimating Whetstone™ (a reward matrix that promotes accuracy in estimating).

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI.

PMNETwork • December 1994

Advertisement

Advertisement

Related Content

  • PM Network

    Unexpected Lift

    By Thomas, Jen Rising 55 stories above Johannesburg, South Africa's financial district, the Leonardo is a rugged yet gleaming mixed-use skyscraper. But it wouldn't be the tallest building in Africa unless the…

  • PM Network

    Snap Precision

    By Fewell, Jesse If you've worked on agile projects, you've likely heard an agile champion make bizarre statements about estimating a budget and schedule. When you press further for estimates, you might get an even…

  • PM Network

    Scope Patrol

    By Elton, Catherine In today's hyper-competitive business environment, it seems everything needs to be done yesterday. But heightened project expectations and a quickening delivery pace can drive up the risk of scope…

  • PM Network

    Measure Of Respect

    By Khan, Zahid Are we measuring the right key performance indicators (KPIs)? Project success is usually measured by KPIs related to scope, schedule, budget and quality requirements.

  • PM Network

    Rebuffering

    By Cover, Lauren Well, that didn't go so well. After a few years of ballooning costs and missed deadlines, the Canadian government in July decided to reel in the scope of a major IT project to bring 1,500 separate…

Advertisement