Project Management/PMBOK/Scope Management

Scope refers to a project’s boundaries: it determines what work will be completed during the project lifecycle. This includes identifying the work that won’t be included in the current round of product/service development. During the planning process, outputs are created to capture and define the work that needs to be completed. The controlling and monitoring process is concerned with managing scope creep , documenting, tracking, and approving/disapproving project changes. Finally, the closing process includes an audit of project deliverables and assesses the outcomes against the original plan.

Scope is about product scope and project scope. Project scope includes business requirements, project requirements and delivery requirements. Product scope includes technological requirements, security requirements and performance requirements.

Planning

Henry Fayol rightly said that "an action without a plan leads to chaos" It's very much relevant when we try to understand the issue related to setting scope for any organisation so setting scope is one of the first project management processes completed during the planning phase as it defines outcomes and deliverables. It is part of creating a vision for the team and stakeholders alike.

Determining the scope of the project is a very challenging process. Many factors affect how scope is determined and how easy/difficult the process will be. For example, if a project is implementing new technology, or a relatively new type of service, the requirements gathering process may take longer to complete. Prototyping, focus groups, and proof-of-concept work may need to be done first to establish feasibility factors before scope can be set. On the other hand, a project with stable requirements and relatively well known technology/services can be much easier to plan. Additionally, depending on how well stakeholders communicate and plan their work environment, the process of gathering facts to set scope can be quite smooth or it can take many rounds of negotiation to arrive at a shared and detailed vision. These are just a few simple examples of how factors may determine the scope planning process.

Please note the example in Figure 4. This figure summarizes the scope planning process, using specific inputs, tools, and techniques, to create the scope planning document as the corresponding output.

Figure 4: Scope Management Inputs, Outputs, Tools and Techniques Example

Inputs

The project manager gathers initial project facts from the project charter. Moreover, background information on the stakeholder’s workplace, existing business model and rules etc. assists in creating the vision of the final product/service, and consequently, the project scope.

Techniques

Certainly being a seasoned project manager broadens the repertoire of one's scope planning techniques. They can draw on past experiences with like projects to determine the work that is realistically doable, given time and cost constraints, for a current project. Communication and negotiation skills are a “must-have” as well. Project managers need to educate stakeholders about the project impacts of some requirements. Adding complexity to a project may require more staff, time, and/or money. It may also have an impact on project quality. Some aspects of the project may be unfeasible – stakeholders need to know this so they can adjust their vision or prepare for future challenges.

Techniques to collect requirements

Gather requirements is part of scope definition, and it can be done using one or more of following techniques:

• Interviews
• Focus groups
• Facilitated groups - JAD and QFD
• Group creativity techniques: brainstorming, nominal groups, delphi, mind map, affinity diagnose
• Prototyping
• Observation
• Questions and surveys
• Group decision making techniques: unanimity, majority, plurality, dictatorship

Tools

Project Scope Management Key Terms, by Tipsographic.com

Two important tools for completing the scope management plan include Statement of Scope (SOS) and Work Breakdown Structure (WBS) templates. Of course, the most important template for completing this planning process is a template for the overall scope management plan. In this book, we outline what is typically covered in a SOS and WBS.

Statement of Scope (SOS)

The SOS usually opens with a problem statement. This statement captures a description of the catalysts which are related to the project’s rationale and a summary of the new product/service that is being created. This section of the SOS often reads like an executive summary of the entire project.

An important content area of the SOS is the list of product/service characteristics/ requirements and features. This section often reflects the shared vision that was negotiated between the project manager, stakeholders, and team members. Product services listed here not only reflect what is being included in the project, but how it will be implemented (i.e. level of complexity, functionality, depth etc.). This section can also include statements about the items that will not be addressed in the current scope of the project.

Other sections in a SOS may include a list of anticipated benefits and project success criteria. There may also be a section which summarizes the list of deliverables that will be included in the scope of the project.

Work Breakdown Structure (WBS)

As the name implies, a WBS lists all of the work that needs to be completed to address items listed in the SOS. It organizes the list of work by using a tree structure (chart or list). This means that the tool is hierarchical in nature. As mentioned previously in this book, IT projects will sometimes structure the WBS by SDLC phase. The phases often make up the “root nodes” or parent items, and underneath each phase all of its related tasks are listed (usually organized by deliverables).

Explaining better deliverable and work packages. Let's suppose that your WBS is a tree with three levels. First level is tree root and is about your project. Second level are project's deliverables, and third level are work packages. Work packages may be controlled, monitored, cost estimated and scheduled. They may have control accounts for performance management and earned value estimation.

When decomposing work that is needed don't forget to include all project management activities. This is known as 100% rule.

Do not forget WBS dictionary, that contains a textual explanation for WBS components - including deliverables and work packages. This dictionary may include:

• Code of account identifier
• Description of work
• Responsible organization
• List of schedule milestones
• Associated schedule activities
• Resources required
• Cost estimate
• Quality requirements
• Acceptance criteria
• Technical references
• Contract information

Monitoring & Controlling

The scope of a project can change from the work described in the scope baseline. A project manager controls and manages such changes using the Control Scope and Validate Scope processes, both part of Monitoring and Controlling process group.

Validate Scope

A project manager implements the Validate Scope process to obtain written confirmation—formal sign-off—from all of the stakeholders that the deliverables match the requirements and the Project Management plan—formal acceptance. The Validate Scope process formalizes the acceptance of the project scope by the stakeholders.

Validate Scope is usually the last Scope Management process that a project manager does in a project, as the product is delivered. Moreover, a project manager validates scope with the customer also at the end of each project phase, or whenever he/she needs the formal acceptance of any deliverable.

Control Scope

As a result of the Control Scope process, a project manager updates the scope, plan, baseline, and WBS info with any approved and documented modification to the project and product scope. The Control Scope process prevents uncontrolled changes to the project scope, i.e. scope creep, by measuring and assessing work performance data against the scope baseline.

A project manager performs Control Scope anytime scope changes are requested since the scope baseline has been created.

Summary

When scope is planned well, the project manager increases the likelihood of positive team morale and project quality. However, this does not mean that project scope will act as a static target overtime. Scope changes as new requirements are discovered during the execution phase. This often occurs as deliverables are rolled out to stakeholders, thus making product/service features more tangible. Sometimes organizational policies change during development, which leads to adding/removing features from the end product/service. What this means is this: no matter how well a project manager plans the scope of project, s/he will have to actively control, monitor, and adjust the plan as changes occur during the execution phase.