The time needed to write a process is usually a lot less than the time spent using it. For example, a project planning process of 1-2 pages may take a couple of days to develop and then be used numerous times. The benefit of using it outweighs the cost of developing it. For most process areas (PAs) of the CMMI, this is also the case. For example, a simple spreadsheet for risk management is a small effort to pay for managing numerous risks over months and years. However, in the CMMI for Services model, some PAs can take more effort to implement than their usage might warrant.

Requirements Management (REQM) in the Development model is a good example of where the effort in setting up the process is small in proportion to its benefit. A few days to determine how to manage requirements changes is small compared to the numerous requirements changes that are typically managed over the life of a project.

In the services model, REQM is used to define the basic services of a group. In many organizations, these service requirements don’t change much (or at all) over time. Any PA, however, still expects a process to be defined (at some level); a policy to be developed; a plan for defining the service requirements (which might be less than a 1-day event); resources to be defined, training in the process to be provided; and process monitoring and auditing.

These are, of course, the generic practices of the PA. They are reasonable expectations but need to be done in proportion to the benefit and usage of REQM. For example, if the event of defining the process takes a few days, and it is used one day per year, then that is a lot of process for low usage.

To reduce this overhead, consider using a checklist. A previous article (Tidbit #8), described two kinds of checklists: “Read-Do” checklists that state what steps to perform given specific situations; and “Do-Confirm” checklists where critical steps (that should have already been performed) are verified. Below is an example of a checklist used for REQM in the services model. A mapping to the practices has been added to show how the PA has been implemented.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Service Requirements Management Process

Purpose: A checklist used to understand, confirm and manage changes to service requirements.

Policy: All service changes are managed using this checklist [gp2.1]

Do

Plan the requirements definition/review event [gp2.2]:

• Date: _____
• Time / resources needed: (gp2.3) _____
• Responsibility: [gp2.4] _____
• Stakeholders [sp1.2, gp2.7]:
  • 1: Role = Agree to services: <Name>. Commitment _____
  • 2: Role = Agree to services: <Name> Commitment _____
  • 3: Role = Provide expertise: <Name> Commitment _____
  • 4: Role = Fund service: <Name> Commitment _____
  • 5: Role = Team member 1: <Name> Commitment _____
  • 6: Role = Team member 2: <Name> Commitment _____
  • 7: Role = Senior manager approval: [gp2.10] <Name> Commitment _____

Discuss new and changed service requirements with stakeholders to clarify understanding: [sp1.1, 1.3, 1.5]

• Review current service requirements
• Review proposed changes to service requirements
• Human resources needed to implement change _________________
• New materials/consumables/computers needed to implement change:_________________
• Current commitments and deadlines impacted:_________________
• Added risks and mitigation actions _________________
• Record stakeholder commitments next to name [sp1.2]

Record major issues/actions

Update traceability mapping [sp1.4]

• Label service requirement 1 thru N
• List impacted deliverables and documents for each requirement
• State test method (e.g., peer review, test case, pilot) for each service requirement

Save this document as service-roles-vN.doc on X drive with change history comments [gp2.6]

Check

Training has been provided to perform the steps above? [gp2.5]

• If not, training date / time / who _____

Check that all process steps above are performed [gp2.8]

• Team check done?
• Corrective actions needed/taken? _______________

Objective/independent check done [gp2.9]:

• Auditor name: _______________
• Audit date: _______________
• Pass/fail?: _______________
• If fail, corrective actions needed: _______________

Senior management aware of this service requirements event, results, issues? [gp2.10]

• Comments: _______________

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

If you are providing the services of an IT system (such as Amazon.com) or college admission service with 50,000 students, then your requirements management process might be more comprehensive than a simple checklist. However, in a small organization, or one where the services are straightforward and don’t change much, then a checklist might be adequate.

REQM Practice definition from CMMI

• SP 1.1 Develop an understanding with the requirements providers on the meaning of the requirements.
• SP 1.2 Obtain commitment to requirements from project participants.
• SP 1.3 Manage changes to requirements as they evolve during the project.
• SP 1.4 Maintain bidirectional traceability among requirements and work products.
• SP 1.5 Ensure that project plans and work products remain aligned with the requirements.
• GP 2.1 Establish and maintain an organizational policy for planning and performing the process.
• GP 2.2 Establish and maintain the plan for performing the process.
• GP 2.3 Provide adequate resources for performing the process, developing the work products, and providing the services of the process.
• GP 2.4 Assign responsibility and authority for performing the process, developing the work products, and providing the services of the process.
• GP 2.5 Train the people performing or supporting the process as needed.
• GP 2.6 Place selected work products of the process under appropriate levels of control.
• GP 2.7 Identify and involve the relevant stakeholders of the process as planned.
• GP 2.8 Monitor and control the process against the plan for performing the process and take appropriate corrective action.
• GP 2.9 Objectively evaluate adherence of the process and selected work products against the process description, standards, and procedures, and address noncompliance.
• GP 2.10 Review the activities, status, and results of the process with higher level management and resolve issues.