Using Medical Checklists to Simplify CMMI Process Development – Keeping it Very Simple

Processes that describe how work is done can easily become long and cumbersome, making them difficult to read and use. To keep processes simple to write, review and update, consider using a checklist.

In a previous article (Tidbit #8), I 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.

A checklist can be used for one project task (e.g., requirements management), or cover many project tasks (e.g., project management, requirements, implementation and validation).

Here are two examples from that article that are a good foundation for developing checklists.  

Surgical checklist example (click on image to make larger)

Guidelines for creating checklists (click on image to make larger)

Below is an example draft checklist for Requirements Development and Management (RDM). A mapping to the practices has been added to show how the Practice Area has been implemented.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Requirements Development and Management Process

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

Policy: All new and changed requirements are managed using this checklist [GOV 2.1]

Do

Plan the requirements definition/review event:

• Date of the requirements event: _____
• Time / resources needed (II 2.1): _____
• Stakeholders [PLAN 2.4]:
  • Customer 1
  • Customer 2
  • Supplier 1
  • Team member 1
  • Team member 2
  • Senior manager approval

Discuss new and changed requirements with stakeholders to clarify understanding: [RDM 2.1, 2.2, 2.3]

• If there are no requirements, then use the ZZZ requirements gathering template
• If there are requirements changes:
  • Review proposed changes to the current requirements
  • Determine people resources needed to implement the changes
  • Determine the technical impact of requirements changes (e.g., GUI, database, materials, consumables, deliverables)
  • Look at current commitments and deadlines impacted by the changes
• Determine customer usage scenarios [RDM 3.2]
• Determine interfaces (e.g., user, data, hardware, and people interfaces) [RDM 3.4]
• Assess risks and develop mitigation actions [RSK]

 Establish requirement priorities [RDM 2.2]

Review requirements for errors, ambiguities, conflicts, constraints, and stakeholder needs [RDM 3.5, 3.6]

Conduct additional checks on high-risk requirements (e.g., prototypes, simulations, research, customer reviews) [RDM 3.7]

Record commitments and any issues/actions to resolve [RDM 2.4, PLAN 2.6]

Update traceability mapping (to parent requirements, and to downstream artifacts and deliverables) [RDM 2.5]

• Label requirement 1 thru N
• List impacted deliverables, features and documents for each requirement [RDM 3.3]
• State the test method for each requirement (e.g., peer review, test case, pilot) [VV 2.1]

Save the requirements as YYY on X drive with change history comments [RDM 3.1, CM]

Record stakeholder commitments [RDM 2.4]

Check

Check that all process steps above are performed [II 2.2, 3.1, 3.2, PQA 2.2]

• Objective check performed of this process?
• Corrective actions needed or lessons learned? [PQA 2.2, 3.1, II 3.2, 3,3]

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