Project Scope Control – Part 1: Definition & Boundaries

Project Scope Control – Part 1: Definition & Boundaries (#1 in the series Project Scope Control)
By Samuel T. Brown, III, PMP, Global Knowledge Course Director and Instructor

Project scope is the fundamental for project planning and execution. Without clarity of scope projects encounter a myriad of difficulties including scope creep, lack of support, inability to satisfy customer needs, inability to reach conclusion, etc. The keys to controlling project scope rest on three foundational pillars of support: clarity of definition, precision of boundaries, and reliability of change management.

Clarity of Definition

Scope is defined in the Guide to the Project Management Body of Knowledge, Third Edition (PMBOK Guide®) as “the sum of the products, services, and results to be provided as a project.” The PMBOK Guide® also defines Project Scope Management as “the processes required to ensure that the project includes all the work required, and only the work required to complete the project successfully.” The first step in controlling project scope is to establish clarity of definition, that is, to clearly describe what the project is supposed to accomplish. Projects are selected, through both formal and informal processes, on the basis of their alignment with the strategic plans, magnitude of expected returns, and ability to provide continuous improvements to existing organization process and product.

Obviously, if the project purpose, business need and benefit, objectives, and criteria for success are not clearly established early on then waste and rework are the likely results. To establish the clearest possible foundation for the project the project manager should ask, and must be able to answer the following basic questions about the project:

  • Why is the project needed?
  • What is the purpose of the project?
  • What is the intended or ideal end result of the project? (What is the project goal?)
  • How will success be recognized?
  • Who will benefit from the project’s outcome?
  • Who will own the project’s results upon completion?

Without answers to these basic questions it will be difficult, if not impossible, to define project boundaries and objectives with precision or clarity. These questions, however, only begin the wide-ranging stakeholder dialog necessary to establish the project charter and ultimately the scope of the project.

So, the establishment of, and agreement to the project charter is the first step toward scope control. The content of a project charter can vary, but from a practical standpoint, it needs to at least document the business needs, project justification, current understanding of the customer requirements, and the new product, result or service intended to satisfy those requirements.

Precision of Boundaries

The next step toward scope control is the establishment of the project boundaries. The scope statement is not the project plan, but contains adequate detail to clearly establish all of the work required for the successful completion of the project. The project scope statement may be a standalone document or a section within another project document like the charter, but it is crucial to the definition of the project as the basis of support for the development and validation of the work breakdown structure.

Obviously, effective definition of scope boundaries cannot be accomplished without the involvement of project stakeholders. The population of stakeholders is often broad and varied, frequently including competing expectations. Even though the stakeholders are unique to each project, all projects will have stakeholders from five fundamental categories including management, project sponsor, project manager, project team, and customer. A stakeholder is a role, not necessarily an individual; therefore a given human being with a stake in the project may fulfill multiple stakeholder roles. For example, with internal projects, it is not unusual for the project sponsor, management, and the customer to be the same person. The three basic steps in the identification and analysis of project stakeholders are as follows:

  1. Identify the full range of stakeholders
  2. Analyze stakeholder expectations, needs, and support
  3. Segment attention to stakeholders

The PMBOK Guide® says that another of the key outputs from scope planning is a WBS (work breakdown schedule), “a list of the summary level subproducts, whose full and satisfactory delivery marks completion of the project.” The WBS is the foundation for defining the work required to successfully meet the project objectives. It defines the project scope of work in deliverable terms, which in turn, provides the basis for decomposition into activities, the estimation of effort and cost, and the assignment of responsibility for coordinating and doing the work of the project. The PMBOK Guide® urges the inclusion of a project management deliverable in any WBS. This helps to keep attention on the importance of planning the management activities into the project; not just the technical activities.

The Practice Standard for Work Breakdown Structures defines two principles of WBS quality:

  • WBS Quality Principle 1 states: “A quality WBS is a WBS constructed in such a way that it satisfies all of the requirements for its use in a project.” Inherent within this principle are both core characteristics and use-related characteristics.
  • WBS Quality Principle 2 states simply, “WBS quality characteristics apply at all levels of scope definition.”

Concluding this discussion of the importance and role of the work breakdown structure in effective scope definition and control it is helpful to again quote the Practice Standard for Work Breakdown Structures:

“The WBS is an important tool used in the planning and execution of a successful project. Many project cost, schedule, and quality failures can be traced directly to the flaws in the development of the project’s WBS. It is less likely that a project will be successful without the existence of a quality WBS. In contrast, developing and applying a high quality WBS will significantly increase the likelihood of successful project completion.”

Summary

Scope control is one of the fundamental processes defined in the PMBOK Guide®, and remains among the most challenging processes faced by practicing project managers. Establishing practical scope control requires constant attention to the three pillars of support; clarity of definition, precision of boundaries, and reliability of change management. Given the often complex nature of many projects of a technical or development nature, in which the entirety of requirements are unknown or indefinable in a detailed fashion, scope control can be enhanced through the use of planning techniques that provide structure for systematic progressive elaboration as ongoing project work reveals new details for use in the next near term planning cycle.

This article continues to discuss Project Scope Control in: Project Scope Control – Part 2: Change Management.

References

  • Guide to the Project Management Body of Knowledge®, Third Edition, Project Management Institute, 2006
  • The Practice Standard for Work Breakdown Structures, Second Edition, Project Management Institute, 2006

About the Author

Samuel Brown, PMP, is a course developer and instructor for Global Knowledge with 25 years experience teaching. In addition, he has provided project management consulting services for a variety of clients including GE, Glaxo Smith-Klein, Bristol-Myers Squibb, Michelin Tire, and IBM.

This article was originally published in Global Knowledge’s Business Brief e-newsletter. Global Knowledge delivers comprehensive hands-on project management, business process, and professional skills training. Visit our online Knowledge Center at www.globalknowledge.com/business for free white papers, webinars, and more.

© Copyright 2008, Global Knowledge. All rights reserved.

PMHut Team

PMHut Team

PMHut.com is a website dedicated to providing PM articles, detailed project management software reviews, and the latest news for the most popular web-based collaboration tools.

1 Response

  1. March 6, 2008

    […] This article continues from the discussion of defining and setting boundaries for scope in Part 1. […]

Leave a Reply