Project Scope Management - #PMseries (1)

After project initiation, the next activity is the development of the project management plan.

The project management plan is essentially a comprehensive document that defines the basis of all project work and how the work will be performed. Specifically, it states the reason(s) and purpose for every activity and how it will evolve from point start to finish.

Normally, development of the project management plan begins with a collection of processes used to ensure that the project includes all the tasks required to complete the project while excluding all work which is out of scope i.e. project scope management.

The following activities comprise the process of project scope management

1. Plan scope management
2. Collect Work Requirements
3. Define Scope
4. Work Breakdown Structure (WBS)

It is important to note that there is a distinction between project scope and product scope, as is illustrated in the illustration below:

The scope statement for "Project PowerBus" reads as follows – produce a mobile charging system that supplies power from the vehicle alternator to individual seats in passenger buses of ZYX transport company.

During the collection of requirements, it is discovered that the charging system in the project requires a total of ‘27 Amperes’ from the vehicle alternator, and is expected to supply ‘1.5 Amperes’ to each passenger seat via USB extension cables.

These features (functional requirements) are part of the product scope, while the sequence of activities (e.g. design product, prototype product, and test product) needed to realize the features and functions of the charging system make up the project scope. But in most cases, product scope is mostly encapsulated in project scope.

Project Activity 3 – Plan Scope Management

Plan scope management is the first process in project scope management. It is performed once or at defined points during a project lifecycle, depending on the development approach – incremental or iterative (agile). In a simple analogy, plan scope management is the same as drawing up the rules of a game prior to kick-off.

Planning in any project management knowledge area is simply about writing the rules for managing processes in that particular knowledge area.

Using the incremental approach, project deliverables are defined beforehand, and scope is managed as the project unfolds. In an agile (iterative) setting, the project scope is defined at the beginning of a set of multiple iterations.

All things considered, plan scope management is performed in sequence with the collection of requirements, the definition of scope, and work breakdown structure to produce two important documents; scope management plan and requirements management plan.

1.   Scope Management Plan

This plan details how the project scope will be defined, developed, and verified i.e. it outlines a process for determining what will be and what will not be in the scope.

It clearly defines who is responsible for managing a project’s scope and contains details of the work breakdown structure.

NOTE: A complete scope management plan depends on the three other activities in project scope management process. After plan scope management, only the rules/approach of managing scope is written in the scope management plan.

Figure 1: Rules for managing scope produced after plan scope management activity

2.   Requirements Management Plan

The Requirements Management plan documents the necessary information needed to effectively manage project requirements from the definition, through traceability, to delivery.

It includes (but not limited to) information about:

1. Requirements gathering process e.g. kickoff meeting, interviews, brainstorming, user stories, and prototypes, depending on the project.
2. Requirements documentation and maintenance of the documents e.g. using word, excel, cloud solutions, etc.
3. Sharing of responsibilities among project shareholders.
4. Who is authorized to view or edit requirements documentation

For complex projects where several thousand requirements can be competing for the same resources, this plan includes a process for prioritization of requirements.

NOTE: A complete requirements management plan depends on the collection of all project requirements. After plan scope management, only the rules/approach of managing requirements is written in the requirements management plan.

Project Activity 4 – Collect Work Requirements

After laying down the rule for how the project scope will be defined, developed, monitored, controlled and validated; the project team can start to collect requirements from stakeholders.

As a rule, the stakeholder requirement should be SMART – Specific, Measurable, Achievable, Relevant, Time-bound; this makes it easy to define the product scope and project scope.

For the successful collection of a project’s requirements, the following documents are indispensable

1. Project Charter (drawn up during initiation)
2. Stakeholder Register (created during initiation)
3. Business Documents (e.g. business case, business requirements document, functional requirements document)

To meet all project objectives, the team must identify requirements, collectively discuss details associated with meeting each requirement, conduct interviews and follow-on discussion to clarify the requirements, and document the requirements in sufficient detail to measure them once the project execution phase begins.

Requirements become the foundation of the WBS. Likewise, cost, schedule, quality planning, and procurement are all based on these requirements.

Consider this example, if a project manager is asked to – Deliver a Fintech app, the project cannot proceed without understanding the requirements (e.g. technology, target audience, functional requirements, non-functional requirements, etc.) demanded by project stakeholders especially the sponsor(s). Successful fulfillment of project objectives hinges strongly on sufficient collation of requirements.

Suppose the Fintech app is required to be able to perform a minimum of 600 transactions per second, the project manager is expected to be able to translate the requirements in such a way to allow flawless design and coding execution.

Additionally, the collection of work requirements helps the project team to develop the requirements documentation and requirements traceability matrix (RTM). The former documentation serves as an input to the next step i.e. Definition of the project scope.

Requirements documentation ranges from a simple one-page document to a detailed document with an executive summary, detailed descriptions, and attachments.

1.   Requirements Traceability Matrix

The Requirements Traceability Matrix (RTM) is a document that connects product requirements from their origins to the deliverables that fulfill them. In a software development project, for example, the RTM document ensures that all the requirements are linked to test cases.

The RTM is normally presented in a tabular format and ensures that stakeholders are able to check each product requirement against final deliverables, as the project progresses. Eventually, it provides a structure for managing changes to the product scope.

An RTM document can range from a simple table of four rows and columns with information on the requirement, requirement description, test case, and status to a complex ten-page document. If an organization does not have an existing template for RTM, the project manager/team can usually decide how much information is to be captured and create it. This is a good guide to draw an Effective RTM

Project Activity 5 – Define Scope

Definition of project scope begins after gathering sufficient documentation on project/product requirements. Thus, we produce a detailed description of the project and product scope.

Defining scope is analogous to marking out the land area on which a building will be constructed. Or simply consider it like the earth’s orbit around the sun that must occur in a defined scope to sustain life on earth.

Figure 2: Earths’ distance from the sun, a defined scope (distance)

The key documents needed to define scope are the requirements documentation produced in project activity 4 (collect work requirements), as well as the assumption log, and the project charter both created during project initiation.

Granted, an ill-defined scope will eventually lead to conflict, rework and stakeholder discontentment; it is important to define and describe the project scope with great specificity, as more information about the project is collected during planning (i.e. using rolling wave planning technique)

In the Project PowerBus referenced earlier, some of the requirements that were collected from stakeholders with the aid of a prototype, a series of interviews and meetings include:

1. The maximum power that can be taken from each vehicle alternator is 27Amperes
2. Minimum required power at each output is 1.5A (2V)
3. USB Extension cable from charging system must be free from disturbance from human and vehicular load normally tucked under the bus seat

The Define Scope process can be highly iterative. In iterative life cycle projects, a high-level vision will be developed for the overall project, but the detailed scope is determined one iteration at a time, and the detailed planning for the next iteration is carried out as work progresses on the current project scope and deliverables.

Besides producing updates to assumption log, requirements documentation, stakeholder register, and requirements traceability matrix, a project scope statement (shown below) is produced from the process of defining the scope.

Figure 3: Sample Project Scope Statement for an Interactive Voice Response (IVR) Project

As seen above, the project scope statement is the description of the project scope, major deliverables, assumptions, and constraints. It expands the high-level scope statement in the project charter, highlights all project/product deliverables and lists project assumptions and constraints.

Project Activity 6 – Work Breakdown Structure

WBS involves breaking down the project or product requirements into smaller, manageable units of work. This decomposition of project work fosters team productivity, drives efficiency and promotes accountability for stakeholders involved at different levels of work.

Considering software projects (like the design of a Fintech app at Mobnia), the general form of work breakdown structure is depicted below.

Figure 4: WBS illustration for Software Development

In small and medium size companies with a single project manager, the work packages are sometimes broken down into smaller tasks and assigned to individual designers/developers/testers. While in bigger firms with a PMO, WBS is finished at the work package level. There is no hard and fast rule, only prioritize the best way to successfully fulfill stakeholder requirements.

In the next article, we shall consider project schedule management...

Reference

PMBoK, A. (2017). A guide to the project management body of knowledge (PMBOK? guide). Project Management Institute, Inc.