Processes

What Are Documented Processes and Procedures?

If the Policy is a high-level commitment from management, the Procedure is the mandatory, step-by-step instruction for the people doing the work.

Your procedures are simply a description of the precise steps your practitioners must follow to get the job done. They are the direct, practical result of your policy statements.

• Policy focuses on Top Management Commitment: A high-level directive (e.g., Services shall be planned). Management is responsible for establishing and verifying the intent.

• Procedure is all about Execution: Specific steps of how the work is done now (e.g., The Project Manager documents the plan). Practitioners are responsible for following the procedures exactly.

Structure and Purpose

A procedure is always written in the present tense and details how things are done here, today. They typically take the form: "The <Group Name> does <Activity>" or "The <Action> is performed."

The procedure ensures the policy's intent is met by defining three critical things for the practitioner:

1. Mandatory Steps: The exact sequence of tasks required.

2. Required Tools: Which approved tools and templates to use.

3. Required Records: What evidence (plans, records, forms) must be created and kept to prove the work was done.

The quick answer is: As many as you need to cover every mandatory activity your team performs.

The Practical Starting Point

Don't start by counting CMMI Process Areas. Start by focusing on your business:

• Have your Business Analysts identify all the use cases, functional roles, and workflow steps involved in delivering your services. This gives you the real-world list of activities that require documented instruction.

While this isn't an exact science, it's the best guide. Every procedure must cover a clear activity and define who is accountable for the work.

Flexibility is Key

You have significant flexibility in designing your process documentation:

• Combine or Split: You can combine multiple related steps into one procedure (e.g., a single document for "Service Design and Planning") or split complex work into several procedures (e.g., separate documents for "Requirements Gathering" and "Requirements Baselining").

• Avoid the Model Trap: Do not feel obligated to write one procedure for every CMMI Process Area. This often leads to unnecessary paperwork and procedures that don't match your team's workflow.

Your procedures should be written as they suit your organization's workflow and design, making them easy for your teams to follow and easy for your QA function to check.