The CSMM Software Capability Maturity Guide

The Short Answer

If you only remember three sentences, remember these three:

One, CSMM and CMMI are "the same direction, two roads". Both look at an organisation's software development and delivery process capability: whether the process is defined, whether it is genuinely running, whether there is measurement data, and whether improvement is based on it; both also need evidence to support them, and neither is settled by handing in a set of documents. The difference is ownership — CMMI is an international system (ISACA / CMMI Institute, with appraisals carried out by authorised lead appraisers), while CSMM is a domestic system.

Two, the systems are independent and the certificates do not substitute for each other. This is the point easiest to misread in practice. A similar focus does not mean one can stand in for the other; each system issues its own conclusion, and there is no such usage as using one certificate to cover the other. Whichever one the tender document asks for, prepare that one.

Three, which road to take depends mainly on the tender document and on customer acceptance. Not on which one "sounds more advanced". Government and state-owned-enterprise projects have been adopting CSMM more in recent years, but the specific requirement is subject to the original text of the tender document; where the customer base is mainly overseas or foreign-invested, CMMI is more widely used. Read the tender document first and then set the direction — far more reliable than doing it first and looking for a buyer afterwards.

What CSMM Assesses: Process Capability, Not Document Volume

Companies meeting CSMM for the first time often read it as "writing another set of R&D process documents". That direction is off. What it assesses is whether the business of building software and delivering it out is repeatable, predictable and improvable — whether the same team, moved onto a different project, can still deliver the same quality.

Spelled out, the assessment follows a few main lines: whether the process is defined (is there a written R&D and delivery process that fits the actual business), whether the process is executed (are projects really run by that process, rather than the files being archived and never used), whether the process is measured (are there credible data on schedule, quality, defects and effort), and whether the process is improved (when the data comes out, is practice adjusted accordingly and a closed loop left behind). How the individual clauses are divided and how granular the requirements go is subject to the assessment of the assessing body.

Put more plainly: what assessors want to see is "how requirements come in, how they are broken down, how they are reviewed, how they are tested, how they are released, and how a problem is traced back". If any link in that chain has a rule but no record, the tier will not go up — because the assessment looks at operating traces, not at promises.

Relationship with and Difference from CMMI: Same Direction, Two Roads

This is one of the pairs we are asked about repeatedly, and one that is easy to get wrong in front of a customer. Both systems look at software development and delivery process capability, and the assessment logic is similar — both look at process definition, both look at project evidence, and both are judged by assessors. But they are two independent systems, with different ownership and different bodies carrying them out, and the certificates do not substitute for each other.

Who Assesses and How: The Process Is Plainer Than You Think

CSMM is assessed by assessing bodies within that system. When choosing a body, look at whether the accepted scope and the assessment experience match your business type (product R&D, bespoke projects and platform work differ considerably) and your target tier — not at the size of the name. The conclusion is decided jointly by the rules and the evidence, and the body does not manufacture capability for the organisation.

Difference from ITSS and DCMM: Three Directions, Do Not Mix Them Up

These four systems (ITSS, CMMI, CSMM, DCMM) are often squeezed into the same "software company qualification list", which leads many people to assume they can stand in for each other. The directions are in fact different, and mixing them up shows quickly in front of a customer.

The distinction in one sentence: CSMM / CMMI care about "how the software was built before it was delivered to you"; ITSS cares about "how well the system is operated once it has been handed over to you"; DCMM cares about "what level the data asset is managed at". One faces the build phase, one the operating phase, one data governance. Companies that do integration plus O&M may be asked for all of them; purely R&D-oriented companies usually need only the process capability one.

Further reading: the ITSS information technology service standards guide, DCMM data management capability maturity, and how to choose between ITSS / CMMI / DCMM / CSMM. The four systems have different objectives: rank them first by "what the customer asks for", then by "what foundation we have internally", and the answer is usually clear.

Key Information

When preparing bid material, check three documents side by side: the original tender document (clause wording and minimum tier), the local policy in force for the current period (applicable conditions and application window), and the assessing body's acceptance requirements (scope and material list). Where the three disagree, the original tender document takes precedence.