Getting the Scope Right: and Keeping It That Way

Getting the Scope Right and Keeping it That Way

By Thomas C. Belanger

Determining project scope and controlling that scope should be the first concern of most project managers. This white paper describes a dynamic flow that begins with the charter and concludes with the acceptance of the scope by the sponsor or customer. The paper will explain how you can help to ensure that you plan and manage the scope of a project while applying the recently published 4th edition of the Guide to Project Management Body of Knowledge^® (PMBOK^® Guide 2008). Further, the paper acknowledges the need for flexible project lifecycles. The flow begins with the project charter, continues with collect requirements, define scope, create WBS, verify scope, and control scope. The intended themes for this paper are:

Get complete and accurate requirements
Talk to the right stakeholders
Get the scope right
Show connections between scope management and other knowledge areas
Control scope creep
Be clear about what “acceptance” means

“The seeds of problems are laid down early. Initial planning is the most vital part of a project. The review of most failed projects or project problems indicate the disasters were well planned to happen from the start.” (Rule #15, One Hundred Rules for NASA Project Managers, Jerry Madden, 1995).

Initial planning is the most vital part of any project.

The Need for Standardization Evolved

In the 1970s and ‘80s, attempts were often made to estimate and manage projects at a very high level. Sizing tended to be an afterthought in most places. At that time, if you had a “rough order of magnitude” estimate of two years, that was sufficient granularity to get started for too many teams. In those days, a project that was thought to be a two-year project would often extend to three and even four years! Few of us were good enough to estimate adequately to be within the traditional “+ or – 10%” on any project. We have learned abundantly since then, that if you don’t get the project scope right during project planning—or do not control the scope; there is little or no chance of completing your project successfully.

Since the eighties, in part due to the explosion of PMI® membership, and significant efforts of PMI® and its volunteers and employees, we have learned to “chunk down” the work of projects in many application areas. Many organizations in the public and private sectors have learned to standardize project management practices. Most organizations now have developed standard phases and templates, and “how-to” best practices for project planning and control. The Project Office now typically maintains these standards. In some application areas, project durations are now limited to 6 months. We have learned about completion criteria, and some now use an assortment of life cycle models.

The Project Lifecycle and Project “Newness”

How much of the work of your new project has been done before by the team? Many know that the waterfall lifecycle was never intended to frame projects that have vague, distant goals. Instead, we need more flexible, expandable lifecycles. So, what are we supposed to do when we are unable to define the final project deliverable? Iterative prototyping is being used in new product development in many industries. Various lifecycle models have been used in IT, research and development and other application areas when the details of the final product are not known. These lifecycle models commonly use rolling wave planning, a “plan as you go” model.

We have learned to define what is known in small, near-term, incremental chunks, and to deliver iteratively, using progressive elaboration, and rolling wave planning. We define and refine scope as we go. The “chunks” may be called releases, sprints, time boxes, kernels or another name. Their timeframes generally vary between 3-5 weeks, during which a sub-lifecycle may include design, build, and test, for each increment or iteration. Many in the world of software development are now moving to an “agile” environment. The agile development process sometimes errs on the side of too little documentation, instead, striving for working software functions.

Some aerospace and construction projects have solid and substantially complete requirements early in the life cycle. Aircraft engines have their own requirements, specifications, standards, and phases. There are engine components, some of which are routine, while newer versions may have a slightly different configuration, or use a new alloy, part, or kit.

On a residential construction project, the homeowners to-be sign a contract with a construction company to build a one-story ranch house with three bedrooms and two baths, and an attached garage. For an experienced contractor, the scope of this project is in the neighborhood of 90% familiar. In this scenario, the contractor should be able to manage the budget within a +/- 10%, and maintain his profit margin.

Whether your project is an aircraft engine component, a new drug, software, or a move to another facility you must do everything you can think of, including collaboration with all stakeholders to get the requirements right.

New, Improved Edition

Now that the 4th edition of the PMBOK® Guide has been published it is time to revisit what our project managers and project teams are doing to define and manage scope. A significant change made in the new PMBOK® Guide is the improvement of consistency in the naming of processes. The new edition uses a verb and an object for each process name. Another change, in the Scope Management Knowledge Area is the replacement of “Scope Planning” in the 3rd edition, with “Collect Requirements” in the 4th edition. Scope Planning now resides in the project management plan.

The new scope management knowledge area is made up of five processes:

5.1 Collect Requirements
5.2 Define Scope
5.3 Create WBS
5.4 Verify Scope
5.5 Control Scope

The paper continues with “how-to” information about these processes together with related suggestions. Refer to the PMBOK® Guide, 4th edition for details. PMI® members can download the document free of charge at www.pmi.org.

Collect Requirements

“Collect Requirements” is the first process in the Scope Management Knowledge Area. If you don’t get the requirements right, there is little or no hope of getting the scope statement, WBS, schedule, and costs estimates right! It may iterate many times in a project, particularly when all requirements and specifications cannot be collected up front. It is arguably one of the most important processes in managing any project, perhaps number one! Work with your team and other stakeholders to determine the types of requirements needed as well as the techniques that will be used to collect them.

Think of the triple constraints: scope, schedule, cost. Try to understand if the project is scope-driven. If a project is scope driven, e.g. a new product or service to leapfrog a competitor action, this may constitute a scope-driven project. The highest priority is to deliver this scope. The cost and/or schedule constraints may be loosened under these conditions. Other knowledge areas may also need attention.

“Collect Requirements” is the process of defining and documenting stakeholders’ needs to meet the project objectives” (PMBOK® Guide 2008). Start with the business requirements. You are likely to get these from the sponsor(s), and perhaps others referred by the sponsor. What is the organization trying to do? Has a problem surfaced? Is there a significant opportunity?

Continue with product requirements, clarifying links with the business requirements. Interview subject matter experts and other stakeholders to determine product and project requirements. Other techniques such as group decision-making techniques, mind mapping, requirements workshops, focus groups, job shadowing, and surveys are among many for eliciting requirements.

Identify Stakeholders is now contained in the Project Communications Management Knowledge Area, and is done in parallel with creating the project scope. The Stakeholder Register, a new output from Project Communications Management, is a key input for collecting requirements, together with the Project Charter. Think broadly when defining stakeholders; this is not an exclusive club. Unfortunately, in some application areas, stakeholders are still thought to be the high-level managers who are funding the project; this is the sponsor(s) in PMI^® parlance.

When you finish collecting requirements you should have three outputs:

Requirements Documents, such as a Business Requirements Document (BRD)
A Requirements Management Plan that states how the requirements will be composed, analyzed, and managed
A Requirements Traceability Matrix connects the “voice of the customer” requirements with the WBS and finally with tested and accepted deliverables

With well-written requirements, you will be better prepared to write the scope statement, define resource requirements, clarify completion criteria for the project, develop a WBS, and define the exclusions or out-of-scope tasks. Some have called this excluded work the “anti-scope”.

Write the Scope Statement

A detailed charter and scope statement is the best foundation for a project plan. In some organizations, a statement of work can have a purpose and meaning similar to a scope statement. In my experience, the statement of work has become the contract in several instances.

Many organizations have found that by using standard templates for requirements and specifications, project focus is improved from the beginning. These standard documents help the team to reduce scope creep and in turn, facilitate customer acceptance. By verifying the clarity of specifications and requirements at appropriate intervals, and by using version control, a project manager and team will greatly improve their probability of success.

Include the following in a scope statement or in associated documents: (PMBOK^® Guide 2008)

Product scope description
Product acceptance criteria
Project deliverables
Project exclusions
Project constraints
Project assumptions

Create the Work Breakdown Structure (WBS)

Start by decomposing the deliverables listed in the scope statement. Stop decomposing when you feel confident that you can identify the resources needed and estimate the effort and duration necessary to schedule the deliverable.

It is nearly impossible to build a Work Breakdown Structure (WBS) without thinking of the resources required. If you are scoping a facility move, you may include employees, contractors and their trucks, facilities, trucks, and other resources. You may also want to identify potential resources and/or job titles while building the WBS. After you complete the WBS, you will formally move to the Project Time Management Knowledge Area to Define Activities and Estimate Activity Resources.

New vs. Familiar

While building the WBS, determine the approximate proportion of the scope that is familiar to the project team. Some projects could entail 75% or more of familiar work; others such as R&D and software development projects could include work that is 50% or more new work. Revisit this approximation when discussing the variance thresholds in the schedule and budget. In many, many projects the sacrosanct “10%” variance limit simply does not make sense.

If most of the work of the new project is similar to previous projects, say approximately 80% familiar, you can start planning from the top and expect good results or better. A project management office is likely to have templates available for familiar projects. Using the previous project or a template from similar projects, decompose the familiar and new work accordingly. Customize the template to fit the current project. If you do not have archives of past project files, begin to accumulate them. You should not have to start with a blank slate when planning a project that is mostly familiar.

On the other hand, if you do not have an appropriate template available, plan from the bottom up. Get the appropriate team members in a room for at least two hours to help develop the WBS, to the extent possible. These are the folks who know the most about the details of the product, service or result you will be asked to create. Of course, larger projects will require more time.

Ask the team to use brainstorming, mind-mapping, or another creative technique to develop a WBS using the “bottom up” method. Begin by thinking divergently, and ask them to individually write down their ideas of what needs to be accomplished. Then, ask the individuals to give you one idea at a time per person, and record them on a whiteboard where everyone present can see. (This process will help to prevent domination of the team by a more powerful or popular person.)

Decompose until you reach the Work Package level. You reach the work package level when you are able to define the work to be done, and feel you can develop duration and cost estimates, and determine resource requirements. Given the application area and nature of your project, you may only be able to decompose the WBS for one phase or stage; while subsequent phases are approximated at the deliverable level. When more is known about the next phase or stage, you can begin to decompose future deliverables.

Graphic Work Breakdown Structure (WBS)¹

There are two methods of displaying the WBS: Graphic and Outline.

The WBS is one of the tools that is helpful for a project of any size with very few exceptions. The graphic WBS, with boxes, appears much like an organization chart. It differs from an organization chart in that each box in a WBS contains a finite amount of work. In an organization chart, someone can fill a particular box for many years. The top level, or level 1, represents the final product, service or result. The project phases or deliverables normally make up level 2. Work packages may appear at level three for some deliverables. Activities (Time Management Knowledge Area) are located at the level beneath the work package. Continue decomposing until the team is confident that estimates of effort can be made, and that all resource needs can be determined, and then stop decomposing. In the example here for a small project, level 3 is used for deliverables.

Graphic WBS Sample

Work Breakdown Structure composition sample

Note: The Work Breakdown Structure composition ends with the work package. Activities for each work package will be decomposed in the Time Management Knowledge Area.

WBS Outline Display

The outline display shows decomposed levels of work, often with lower level work indented beneath its “parent”. Many project management software tools use this display. The best popular project management software packages aggregate lower level activities or tasks, schedules and costs to each higher level, ultimately to the deliverable and/or phase level.

Here is an excerpt of a WBS from a data conversion project that integrates the financial systems of two companies in a merger.

WBS Excerpt from a Data Conversion Project

Determine Conversion Requirements

1 Requirements Definition Phase
   1.1 Start
   1.2 Develop initial Project Description for the conversion
   1.3 Submit project request or proposal
   1.4 Identify conversion scope
      1.4.1 Determine affected systems
      1.4.2 Document existing systems mapping and architecture
      1.4.3 Analyze alternatives
      1.4.4 Document new systems mapping and architecture
      1.4.5 Identify project assumptions and risks
      1.4.6 Size the project
   1.5 Review Project Definition
   1.6 Develop conversion approach document
   1.7 Define the conversion organization and resource requirements
   1.8 Contact department managers
   1.9 Identify conversion team representatives
   1.10 Establish deadline for receipt of issues & requirements
   1.11 Distribute info packages to business & technical teams
   1.12 Establish deadline for receipt of Phase II issues & requirements
   1.13 Define testing and systems requirements
      1.13.1 Contact systems personnel
      1.13.2 Determine overall conversion timeline and target dates
      1.13.3 Schedule tests
      1.14 Define conversion impact

This is only an excerpt. Phases II, III, IV, and V are not shown. With a completed WBS, you can move to discussion of activity definition, completion criteria, resource requirements, effort, and duration estimating. Note that for an iterative/incremental project you will not have a completely decomposed WBS for the project at this point. You are likely to have only high-level summary for phases beyond the current phase when that phase begins.

On most projects, work begins while planning is occurring. Whenever project work begins, record lessons learned for each activity. You can record any data you wish as a note to any level of work such as activity or work package when using project management software. Accumulate lessons learned, potential risks, vendor performance, and other important information throughout the project lifecycle. Manage scope-related issues when they become known.

Consider Creating the Work Breakdown Structure Dictionary and/or Completion Criteria

When the WBS is complete (for the time being), determine the details of the work at every level. Large projects will often require a WBS Dictionary to accompany the WBS. For very small projects, however, this may be overkill. You may want to focus on the least familiar work instead. The WBS dictionary may be part of the contract and/or statement of work. The WBS dictionary describes each element in the WBS. This typically includes a description of the work to be done, responsible party, the organization responsible, and perhaps other information.

Clarify completion criteria (some may remember this as “doneness” criteria). Very few of us can say we have never had a misunderstanding about when an activity was complete. To avoid this happenstance, get it right the first time, define completion, and use version control. Define completion criteria for each level of work to the extent possible and necessary. Help your team. Connect them with those who have done similar work, such as a Business Analyst, or a subject matter expert (SME). If the project is composed of only 20-25 very familiar activities that will be accomplished by two people, writing completion criteria may only be necessary for the least familiar work. Simply ensure that you and your teammate understands the new and familiar work.

Scrutinize larger projects more rigorously, since they represent a larger investment for your organization. Describe the basis of estimates when estimating the resources, completion criteria, effort, duration, and cost. This will help with subsequent efforts to estimate duration and cost after the WBS is complete. Did your numbers come from previous projects? Do the projected human resources have a similar skill level to past projects? You will refine this thinking later.

Identify degrees of completion using increments, such as feet, function points, etceteras. It should be a clear binary choice. Either it is complete or not. Once you have defined completion criteria, you are better able to define or refine resource requirements. Think through the steps and details of what must be done. See the action steps for a deliverable below. The example shows the flow of work necessary to implement a standard system interface, a work package for a system upgrade project. The action steps shown will need to be decomposed further.

Implement Standard Interface (deliverable level)

Project sizing adds a degree of quantification to the project scope.

Determine Project Size

In most organizations, you will need at least a “rough order of magnitude” estimate of project size to initiate the project. Once the scope statement is written, the WBS is constructed, resource needs have been identified, and completion criteria has been described at each level, you will be better able to determine a more accurate approximation of the size of the project or project component. Project sizing adds a degree of quantification to the project scope. At this point projects can be sized by using the appropriate sizing variables, for example:

Number of resources required
Market size
Number of square feet
Amount of geography
Number of source files
Lines of code, function points, feature points
Distance
Number of units to produce
Number of business units affected
Number of activities

In IT, software development, and related enhancement projects, sizing the project can be helped by estimating the number of lines of code, function points, or feature points. The most common metric for many is lines of code. Of course, the numbers of lines of code that may be written in seven hours depend upon a number of factors, including the programming language and skill level of the programmer or developer.

Obtain Scope Sign-off

Once you have determined the estimated scope of the project, you need buy-in and sign-off from the sponsor(s). Most of us do this by either presenting the WBS to sponsors and/or others, or hold a formal review or walkthrough. Your job as project manager is to ensure that the documents—and the project itself—is understood from the beginning. It is often a good idea to present the key elements of the scope statement and the WBS to the project sponsor(s). Invite others such as functional managers who will provide the human resources.

The value of a sign-off from someone who hasn’t read the scope statement and the WBS isn’t worth the ink that was used to sign. By holding a review or walkthrough, you can ensure that the appropriate stakeholders have an opportunity to ask questions and clear up any misunderstandings. Send the document to the sponsor(s) and other participants in plenty of time to review for the meeting. This may mean a week or more for a 10-page document. Explain to each stakeholder the particular section(s) that should be read and understood. Avoid asking all participants to read every section of a voluminous document, unless you have a defensible reason.

Ensure Scope Control

Scope creep has led to blown budgets, failed projects, reduced market share, and, in some cases lost jobs! If you have defined the scope clearly and have obtained sign-off on the scope baseline from the sponsors and others who must understand the project, you are off to a good start. Ensure that the team knows the exclusions from scope, otherwise, some well-intentioned folks may do work that is not included. Now, after work begins, your job is to monitor the completed deliverables and work packages to ensure scope, schedule, and budget compliance.

Control scope by analyzing and managing the variances, and controlling scope changes. As deliverables are being produced, ask for information about work performance on the project. Is the work aligned with the business, product and other requirements? Is the scope being delivered as planned? If not, what are the reasons for the variances? Root causes for variances may be the novelty of the work or technology used. Your analysis of the variances should result in measurements of work performance.

Process all change requests, corrective actions, and preventive actions through the “Perform Integrated Change Control” process. Ensure that you communicate and employ a procedure to limit changes in the scope of the project, or increment. Describe the dollar limit and/or schedule limit above which a change request must be submitted. For example, any increase in schedule by three or more days, or an increase in cost about $5,000, requires a formal change request. Many organizations establish a point in the project known as “scope freeze”. No changes in scope are allowed after this point. Though this is simple to write, it is not doable to the same degree on every project. The point is to have the discussion. Do not allow unlimited changes unless you have a compelling reason, such as a “scope-driven project”, described earlier.

If your project is scope-driven, meaning that you are committed to making all requested changes in a new product being developed, then you and the sponsor, client, or customer must understand that the attempt to control the schedule and budget may be futile.

Verify Scope

Verify Scope is the process of formalizing acceptance of the completed project deliverables (PMBOK^® Guide 2008). To verify scope, you need to gain acceptance from the appropriate stakeholders. Again, a formal review or walkthrough is commonly used. This could also include a User Acceptance Test (UAT), or final walkthrough. These are inspection techniques. The sponsor and other stakeholders need to know that their business, product and other requirements have been met.

If you are managing a project under contract, you will have been referring to the contract as well as the change requests frequently, throughout the project lifecycle. Whether driven by a contract, project request, or an emergency project, circle back to the reason for the project as expressed in the project scope statement and/or the contract. Did we get there? When a construction project is substantially complete, inspectors walk through the site developing a “punch list” of items that need to be done to complete the project. Typically, some number of defects is found. When this work is completed, the client sends the final check for the “retainage” which is typically 10% of the contact.

Scope management begins and ends with requirements. Get them right from the beginning, and manage them—your success depends on it!

About the Author:

As CEO, Thomas C. Belanger has managed three programs: Training, Consulting, and Learning Products for six years. While Director at a state college, he managed three certificate programs for Business Analysis, Project Management, and the Dynamics of Management and Leadership for three years.

Tom has managed a variety of projects including publishing, course development, implementation of project management methodology, and software development, as part of a jet fighter program. To date, he has written four books on managing projects and teams, including "The Complete Planning Guide for Microsoft Project" in 1997. Tom's new book, "The Junto, Music, and Sport: Lessons in Team Dynamics" will be published in the spring of 2010.

¹ Belanger, Thomas C., How To Plan Any Project, DMSI, 1991.

For more information on this topic, as well as how Corporate Education Group can help power your organization’s performance, contact us via email or call 1.800.288.7246 (US only) or +1.978.649.8200. You can also use our Information Request Form!