ProjectManagementOER

What is Scope?

One of the main activities in the Project Planning is determining and documenting the project scope.

Scope is a description of the end result or mission of your project: the product or service for your client/customer. It defines the results to be achieved in specific, tangible, and measurable terms, explicitly describing what aspects of the work are in and what aspects are out, and outlining the boundaries of the project. Determining the scope is a key piece of being able to prepare a plan, because the resources required and the activities that need to be completed are determined by the scope.

In most projects, you actually interact with two scopes:

In simple projects, both of these may be managed by the project manager, while in more technical projects the project manager manages the project scope and a product manager or systems engineer may manage the product scope.

Project boundaries are the area where the project management processes are taking place. It encompasses the team, and the work relevant to the project. The project sponsor shared business documents about the project with the team (one side of the boundary), whom uses the project management processes to create an outcome at the other end of the boundary, delivering deliverables to the end-users and project records to the organization to maintain as part of its organizational process assets.

Scope Management Planning

The first process in scope management is determining and documenting how you are going to complete Scope Management Planning. At this step, your aim is to answer questions such as what terms do you use to describe the scope, what information from the project charter currently describes scope, what information do you need to complete the description, what templates you will use in your description, etc.

The Plan Scope Management has the following elements:

Requirements Management Process

The aim of the requirements management process is to collect requirements for the project and the product/service. In most cases, a preliminary set of requirements are available in the project charter. The team would then analyze these alongside assumptions and stakeholders to delineate and create more specific requirements for the project.

It has the following elements:

Requirements

A requirement is a condition or capability that must be met or possessed by a system, product, service, result, or component to satisfy a contract, standard, specification, or other formally imposed document. Requirements include the quantified and documented needs, wants, and expectation of the sponsor, customer, and other stakeholders. Project requirements may also tie to things like the organization’s strategic plan and business objectives.

Requirements characterize the project’s end product, and in most cases are not just the realm of the project manager, but also the system engineer or technical lead on the project.

Determining requirements leads to:

Requirements Management

Requirements management throughout the project follows the steps below:

  1. Identify: This is done through brainstorming, stakeholder analysis and discussion with domain experts. What is important is that requirements need to meet the SMART description and describe what shall, will or should happen
  2. Document: Requirements are usually documented in a requirement’s register. Documentation should:
    • Be accessible by all stakeholders
    • Present information clearly
    • Keep information securely
    • Maintain versions
    • Record links between items
    • Provide clear reporting
    • Be easy to use For each requirement:
    • Assign a requirement ID which allows for traceability to its parent and child requirements
    • Requirement statements:
      • Are usually written using shall (must have), should (we would like it to have), or will (fact)
      • are stated positively (“shall not” is not allowed)
      • are preferably quantified, meaning they include a measure and the method of measurement
      • May include “To Be Determined” (TBD) if something is unknown. However, the use of TBD should be minimized. Alternatively, use a best estimate for a value marked with “To Be Resolved” (TBR) with the rationale along with what should be done to eliminate the TBR, who is responsible for its elimination, and by when it should be eliminated.
    • Rationale/justification: Including any assumptions and the reason why the requirement is needed/included
    • Categorize: Common categories include Functional, Non-functional, Performance, Development, Technical, Business, User, Regulatory, Quality
    • Requirement Owner: Assign a person or a team who is in charge of it
    • Link to work breakdown structure
    • Link to Business Needs, Opportunities, Goals, Objectives
    • Test case
  3. Prioritize: Are the requirements of the same level of importance? Which ones will you monitor more closely?
  4. Monitor and control: If during the project a new requirement needs to be added or we learn that a requirement cannot be met, then we would need to rely on change management process to change the scope of the project.

Scope Definition Process

The scope definition process tries to clarify and document project scope. It has the following elements:

Project Scope Statement

The project scope statement is the main outcome of the scope definition process. It is a short, one- to two-page summary of key elements of the scope, followed by extended documentation of each element. In some cases, the scope statement takes the form of “statements of work (SOW)”.

The purpose of the scope statement is to:

Examples of questions answered by the scope statement include:

As you describe the scope, you may notice that it is too big or small. If you have a very big scope, then you may decide to break your project into smaller subprojects (managed perhaps as a program). While projects with large scope are possible, they include additional complexity and the need for simultaneous management of various elements.

Project Scope Statement - Common Content

While there is no single standard or outline for the project scope statement, the scope statement will address the following topics:

  1. Problem statement or business case
  2. Project goals and objective
  3. Project scope + product/service scope description OR scope summary with boundary conditions (progressively elaborated)
  4. Justification
  5. Technical requirements
  6. Project requirements
  7. Deliverables
  8. Milestones
  9. Limits and exclusions (In Scope, out of Scope)
  10. Constraints and assumptions
  11. Acceptance criteria

Scope Creep

Scope creep is the tendency for the project scope to expand over time — usually by changing requirements, specifications, and priorities. When you add work to a project, little by little, insidiously, until the original schedule and cost estimates are completely blown and meaningless, you’ve attained scope creep.

Common causes of scope creep include:

To control scope creep, make sure any changes in either the statement of work or project plan is agreed to in writing, along with the resulting budget and schedule changes.

Pentagon Wars is a good example of how scope creep can break projects.

Work Breakdown Structure

The Work Breakdown Structure (WBS) is a deliverable-oriented hierarchical decomposition of work with different levels of detail. It is essentially a list of all activities/work required to create all the deliverables in the scope and deliver them to the client, broken down into smaller tasks, in a hierarchical pattern. The WBS organizes and defines the total scope of the project by identifying the products and work elements involved in a project, defines the relationship of the final deliverable (the project) to its sub-deliverables, and, in turn, their relationships to work packages, and serves as a framework for tracking cost and work performance.

The WBS can be represented graphically (a hierarchy) or in list form. WBS elements are assigned a numeric id, with the numbering indicating0 the “parent child relationship”. WBS-list.png WBS-graphic.png

The create WBS process has the following elements:

The WBS has several uses:

A Good WBS

Creating the WBS

Decomposition is the process used to break the project scope of work into the deliverables, sub-deliverables, and work packages involved in completing the project. The process of decomposition begins with identifying the highest-level deliverables. These deliverables are then broken into sub-deliverables. Many layers of sub-deliverables may be needed for a project.

To create a deliverable-based WBS:

  1. Start with the project
  2. List all the project outputs (deliverables and other direct results)
    • Deliverables and sub-deliverables are things such as physical objects, software code, or events. They are usually represented by nouns.
  3. Identify of all the activities required to deliver the outputs
  4. Subdivide the activities into sub-activities and tasks
    • Remember the 100% Rule: The combination of the boxes on each level represent 100% of the parent box.
    • At the lowest level you will reach work packages which are assignable units of work that will be performed to create the related deliverable. Work packages are action oriented and may be represented by phrases containing verbs.
    • Note that you want to break down all deliverables to the same level of details. This is a common issue, whereby if the project manager is more familiar with a particular task, they may break it down more than others, leading to issues when trying to assign the work.
  5. Identify the deliverable and milestone(s) of each task At this point, the focus is not in the sequence of activities or their dependencies; instead, our goal is only to identify all activities that describe the full scope of the project.

The process above starts with deliverables as the basis for creating the WBS, making this a scope-driven WBS. There are other methods:

The lowest level you reach in your WBS depends on the amount of control you want. The general rule is to go down to the lowest level that needs to be monitored and communicated, or to the lowest level you can delegate. Generally speaking, you should create a master plan for every project, with detailed plans only for the next 3-4 months for monitoring and resource planning, and with workpackages that take approximately 2 weeks to complete or 8-80 hours of effort.

A Work Package

The smallest elements (lowest level) in the WBS are work packages. They are typically a short-duration task that has a definite start and stop point, consumes resources, and represents cost. These work packages usually involve work by a specific team or person (as such are focused on a specific domain of work) and are assigned to one organizational unit, individual or contractor for ownership. They may in turn be further broken down into activities or tasks by the project team or the experts who will perform that work and planned in detail.

Work packages are the basic unit used for planning, scheduling, and controlling the project. They should be as independent of other work packages of the project as possible and be easily assigned. Depending on your organization and the level of planning required, the size of a workpackage may be different. Generally speaking, a workpackage with a project should not exceed 10 workdays or one reporting period

Workpackages should:

Workpackage Information

Each Work Package in the WBS will have the following information recorded in a document called the WBS dictionary:

Keep in mind that at this stage, you only know the name and its relationship to deliverables. The rest of this information is going to be completed as you go through other planning processes. Also note that some organizations only track a subset of these at workpackage level.

Workpackages and Human Resources

While not formally required, at this point a responsibility assignment matrix (also called a linear responsibility chart, responsibility matrix or RACI matrix) may be developed to identify high level responsibilities of workpackages. This chart who has responsibilities with respect to the work package. Particularly, who is:

At a minimum, each work package should have one responsible. Multiple approvers are possible, but keep in mind that this may delay approvals and decision making. The RACI matrix should collaboratively be completed to ensure buy-in.

This will provide a means for all participants in a project to view their responsibilities and agree on their assignments, and clarify interfaces between units and individuals that require coordination. The RACI matrix may include the project team, organization members outside the project team and even other stakeholders.

In addition, the WBS should be integrated with the organization’s resource consideration. An Organization Breakdown Structure (OBS) is used to depict departments, teams and individuals responsible for specific areas of work within the organization. Linking the OBS elements with the WBS will allow us to identify the organization units responsible for work packages. As most resource costs are realized in organizational units, this will also ties the project to cost control accounts within the organization.

We will expand on this topic in resource management.

Relationship Between Work Packages

The Design Structure Matrix (DSM) can address the issue of information flow as well as precedence relationships of work packages. The first step in developing a DSM is to identify all the project’s workpackages and list them in the order in which they are typically carried out. Next, moving across one row at a time, all tasks that supply information to the task being evaluated are noted. This information can then be helpful when creating the schedule.

Summary

Practice

Bibliography

The following sources were also consulted in creating this resource: