CMMI and Project Management – Scope Management

The PMBOK refers to the business of managing the requirements of a project as Scope Management while SEI refers to it as Requirements Management. This is partly because the SEI narrows its focus on the software requirements of the system or application being built while the PMBOK uses the term Scope to refer to all the work of the project. This includes administrative activities such as producing and communicating the project progress reports and conducting status review meetings.

The CMMI refers to the group responsible for capturing and recording requirements as the "software engineering group”. This is an entity that the CMMI states should comprise a part of the organizational structure. This group will be responsible for managing software requirements outside of the project, but for the purposes of the project the person or group responsible for gathering the requirements can be someone outside the software engineering group. CMMI organizes its Key Process Areas (KPA, Requirements Management is one of these KPAs for Level 2) into Goals, Commitment to Perform, Ability to Perform, Activities Performed, Measurement and Analysis, and Verifying Implementation. Requirements Management has 2 goals:

1. Systems requirements allocated to software are controlled to establish a baseline for software engineering and management use.
2. Software plans, products and activities are kept consistent with the system requirements allocated to software

Goal #1 should be satisfied by a Business Requirements Document (BRD), commercial specification, or other document which captures and identifies the requirements for the system or application being built. The PMBOK refers to this document by the generic name of Requirements Documentation (keep in mind that the PMBOK was not written specifically for software projects). The first process in the Scope Management knowledge area is Collect Requirements and this is the process that will deliver the Requirements Document. The people who are responsible for identifying the customer or client’s needs are identified in the Stakeholder Register and the requirements gathered using the various tools and techniques described will be captured in the BRD. They should be uniquely identified as well, so as to establish traceability. Goal #2 is chiefly satisfied by the breakdown of the work required to produce the software which is described in the Create the WBS (Work Breakdown Structure) process.

Your organization is required to govern requirements management with a "written organizational policy”. Since this policy is outside the scope of any single project, it is not part of your responsibilities as project manager to create it. The PMBOK does make reference to such a document however; mention is made in the input section of many processes, including scope management processes, of "organizational assets”. A policy that standardizes the activities that must be performed when a software system or application is built will influence the activities in your project plan and may even provide a template for the requirements management portion of your project plan. Always keep in mind that your responsibility covers all the project work, including administrative work, not just the work of building the software system.

The policy should state that requirements are documented and reviewed by "software managers and other affected groups”. These people are the project stakeholders referred to in the Stakeholder Register. The policy also states that the plans, work products, and project activities must change to be consistent with changes in requirements. Your project should have a Change Management Plan that describes how any changes, including changes to requirements, will be handled by the project. This Change Management Plan is described in the Integration Management knowledge area and is what will ensure that appropriate plans, work products, and activities are updated when a change to requirements is approved. The Verify Scope and Control Scope processes describe how activities called for by these processes might produce a change request.

The abilities that Requirements Management calls for are:

1. Analyzing the system requirements and allocating them to hardware, software, and other system components. This ability is provided to the project by the Business Analysts, or Systems Analysts who translate the business requirements (allocated requirements) into system requirements. The PMBOK does not address this activity directly; remember that it is not focused on any specific industry, so your plan must speak to this ability. Simply identify the work to produce the functional specification from the business requirements in the WBS.
2. Documentation of the requirements. The documents referred to will be the Business Requirements Document, the Functional Specification, and the Detail Design Document. The BRD should uniquely identify each requirement. Each function in the Functional Specification should support one or more requirements and each requirement should be supported by one or more functions. The same rule applies to the Detail Design Document. This supports tracing requirements through to the finished products. This ability also specifies that acceptance criteria for the products must be specified.
3. Adequate resources and budget must be provided for managing the allocated requirements. This refers to your project funding for human resources such as business analysts, systems analysts, programmers, software librarians, etc. It also refers to funding for any tools required to manage requirements such as configuration management tools.
4. Project team members are trained to perform their requirements management duties. This refers to the work of analyzing the requirements, managing the requirements, building the software, and managing the configuration.

The first activity called for by the CMMI is the review of requirements by the "software engineering group”. Your Verify Scope process describes the various methods for doing this and they include audits, walk-throughs, and reviews by the appropriate stakeholders. This activity also calls for resources to be allocated for the work of estimating costs, building the system, testing the system, configuration management, QA, contract management/Procurement Management, and documentation support. These activities will be identified by the Create WBS process.

Activity 2 calls for the engineering group to create the plan and build the deliverables. This is simply the execution of the project plans. Activity 3 calls for changes to the requirements to be reviewed and incorporated into the project. This activity is covered by the Control Scope process. Control Scope describes how the Integrated Change Control System manages changes and implements approved changes. CMMI describes the process in somewhat more depth and calls for changes to be identified, evaluated, assessed for risk, documented, planned, communicated to affected stakeholders, and tracked to completion. Your Change Management Plan should describe these activities.

CMMI calls for the work performed to be measured so that the measurements can be used to determine the status of the requirements. The Control Scope process describes how work performance information is analyzed (variance analysis) against the plan and any variances discovered are corrected.

CMMI calls for the verification of requirements management activities. The requirements management activities should be reviewed with senior management periodically. The Verify Scope process does not specifically refer to senior management in describing how this process is to be executed so the project manager will have to improvise here. I advise holding gate meetings, phase exit reviews, or business decision point meetings to review project status with senior management who are represented by the project’s business sponsor and/or the steering committee. CMMI also calls for progress reviews with the project manager. The project manager will attend the gate reviews and will run status review meetings with the team on a regular basis.

The CMMI also calls for the Quality Assurance group to review or audit the work. Your organization may or may not have a QA group. If it does, the group may be responsible for project audits which would cover this requirement. CMMI is specific as to who must undertake these reviews and audits so your organization either has this covered or it does not; there is no opportunity for you to cover it yourself. CMMI describes what should be audited at a minimum. This includes requirements reviews, problem resolution, updating of work products and plans when requirements change, and the proper process for deciding on change and implementing the changes.