Use CMMI in software engineering to organise evidence about how work is performed and where improvement would help a business objective. Start with a recurring delivery problem, examine the records behind it and choose a manageable improvement. Keep that internal exercise separate from claiming a formal capability or maturity result.
A team does not need to begin with an impressive process diagram. It needs an answer to a concrete question: what problem are we trying to reduce, which work shows it and what evidence would indicate a better process? That sequence keeps documentation connected to engineering decisions rather than treating additional paperwork as the outcome.
What does CMMI organise, and which domain matters?
CMMI presents itself as one model with multiple domains. The CMMI Development domain concerns capability to develop products and services meeting customer and user needs. The CMMI overview makes the Development domain a relevant starting point for software product work. Choose the domain through the work under review. Record the product, service or process boundary before discussing a wider organisational programme.
The CMMI Services domain addresses capability to deliver service offerings. Development and service delivery can raise different improvement questions even within the same business. A software change workflow might focus on requirements, tests and release decisions; an ongoing service workflow might focus on demand, handover and response ownership. These are proposed discussion examples, not a substitute for the model’s actual practices.
CMMI describes an integrated solution containing five components. The overview lists the model alongside training, appraisal, adoption guidance and systems or tools. This helps explain why reading a summary page is not the same activity as carrying out a formal appraisal. Decide whether the immediate need is internal improvement, learning the model or preparing for a formal engagement.
CMMI includes adoption guidance for model transitions and new adopters. Use the official adoption route when the organisation needs model-specific guidance. Keep the scope and intended outcome of that engagement explicit. Do not label an internal checklist as an authorised appraisal method or describe a team as holding a level on the strength of a self-authored worksheet.
How do capability and maturity levels differ?
CMMI capability levels apply to individual practice areas. CMMI capability practice groups run from Level 0 to Level 3. The official levels explanation places capability discussion at practice-area level. A team investigating one part of its workflow should preserve that scope. Evidence about one review step does not describe every process in a business.
CMMI maturity levels use predefined sets of practice areas. This is a different framing from evaluating an isolated practice. Keep the terms separate in management presentations and improvement notes. If a stakeholder asks for “CMMI Level 3”, clarify the actual objective and formal scope through the appropriate official route before turning the phrase into a project commitment.
CMMI describes maturity Level 2 as management at project level. CMMI describes maturity Level 3 through organisation-wide standards. These level descriptions are useful for understanding the distinction between project management and organisation-wide guidance. They do not authorise the reader to assign a level after recognising a familiar practice. Use the terminology accurately while building a separate, practical record of observed work.
| Improvement question | Evidence to collect | Useful decision |
|---|---|---|
| What repeatedly goes wrong? | Specific work items and outcomes | Define one problem clearly |
| Where is the decision made? | Review notes and named owner | Clarify responsibility |
| What instruction applies? | Current procedure and actual use | Resolve an instruction gap |
| How is completion checked? | Test evidence and acceptance record | Improve the completion condition |
| How will learning be retained? | Agreed change and follow-up review | Update a shared working practice |
What process evidence is useful for software teams?
Choose records that let another person reconstruct a decision. A requirement change should have a recognisable request, its scope and an acceptance decision. A completed defect should have the relevant evidence for its resolution. These are proposed evidence questions; their purpose is to expose gaps in the team’s actual workflow before selecting an improvement.
Avoid judging a process solely by the existence of a template. Compare an instruction with a small, representative set of completed work and an exception. Ask the people doing the work to explain how they use it. A document can be current yet ambiguous, and a team can follow a sensible practice without recording the evidence needed for later review.
Keep the enquiry respectful and specific. Replace “developers do not follow process” with an observable statement such as “the selected records do not identify who accepted the changed requirement”. The latter gives the team something concrete to improve and avoids claiming more than the inspected evidence supports.
Original improvement worksheet: why are resolved defects reopened?
This hypothetical example concerns a team that wants to understand reopened defects. It does not state a real defect rate or represent a formal CMMI assessment. The worksheet is an original method for connecting a business objective to process evidence and a bounded improvement decision.
Objective field. Write the desired business outcome: accepted fixes should address the intended problem and remain understandable to the next reviewer. Choose a meaningful observation period through the team’s planning process. Keep the definition stable enough that later comparisons describe the same kind of work.
Selection field. List the records chosen for examination and why they are relevant. Include a reopened item and an accepted item where available. Preserve each item’s identity, reported symptom and acceptance evidence. Do not quietly remove an awkward example because it makes the process look less tidy.
Decision trail field. For each item, identify the original request, clarified requirement, implementation reference, test evidence and acceptance decision. Mark missing or contradictory links. Ask the responsible person to explain the gap before classifying it. A missing link may indicate an unclear procedure, an unavailable record or a misunderstood expectation.
Cause hypothesis field. Write a narrow proposed explanation, such as “the completion check does not require comparison with the reported symptom”. Keep it labelled as a hypothesis until the records and team discussion support it. Avoid moving directly from one reopened defect to a claim about the organisation’s maturity.
Improvement field. Propose one change that addresses the supported gap. For example, the team may require a short acceptance note linking the symptom and the verification result. Identify the owner, affected workflow and any exception route. Explain how the change should help the objective, rather than counting the new document as success.
Follow-up field. Inspect later work using the same definitions. Ask whether the new evidence is present and whether it helps a reviewer understand completion. Record unexpected burden or new ambiguity as well as improvements. Revise the approach when its practical effect differs from the team’s original expectation.
How should improvement priorities be selected?
Rank candidate improvements by their connection to a business problem, the evidence behind the proposed cause and the team’s ability to carry out a bounded change. Keep a short backlog with an owner and a next review decision. An unresolved fact should remain a research task rather than becoming a confident process diagnosis.
Use official model materials for model-specific interpretation and formal appraisal planning. Keep the team’s evidence worksheet useful in its own right: it should help engineers and managers decide what to change and how to inspect the result. A formal label is not required for an internal record to improve a concrete conversation.
Connect the worksheet to your software development requirements and wider business systems planning. You can get started with the business objective, selected work records and proposed improvement. That provides a clear brief without inventing an appraisal outcome or performance commitment.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.