CMMI-Prinzipien und -Werte

Von David J. Anderson. David J. Anderson ist Autor von zwei Büchern, „Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results“ [1], veröffentlicht im Jahre 2003, und „Kanban: Evolutionäres Change Management für IT-Organisationen“ [2], deutsche Veröffentlichung in 2011. Er war Mitglied eines Teams in Singapur, das von 1997 bis 1999 im Rahmen der agilen Softwareentwicklung die Methode „Feature-Driven Development“ (FDD) entwickelt hat. In der sogenannten „Declaration of Interdependence“ hat er 2005 die Grundsätze des agilen Projektmanagements definiert. Anderson entwickelte MSF for CMMI Process Improvement und ist Mitverfasser der Technical Note vom Software Engineering Institute: „CMMI or Agile: Why Not Embrace Both.“ [3] Er ist Vice President von Lean Software & Systems Consortium (http://www.leanssc.org) und leitet die internationale Firma für Managementtraining & Consulting, David J. Anderson & Associates Inc. (http://www.agilemanagement.net), die Technologieunternehmen hilft, ihre Performance mithilfe von verbesserten Management- und Entscheidungsstrategien zu optimieren.

Januar 2012

Anderson beschreibt, wie das Betrachten von Organisationen aus CMMI-Perspektive wertvolle Einblicke für Manager, Prozessingenieure sowie alle externen Projektbeteiligten einschließlich Kunden, Investoren, Governance-Einrichtungen und Auditoren bietet.

Betrifft

Application Lifecycle Management, CMMI

Introduction

Bedeutung der Organisationsreife

Inspiration für das CMMI-Modell

CMMI ist ein Modell

Einfaches Verständnis der CMMI

CMMI-Bewertungen

Das ursprüngliche Capability Maturity Model (CMM, Fähigkeits- und Reifegradmodell) wurde im Jahre 1991 vorgestellt. Es entwickelte sich zehn Jahre später zur Capability Maturity Model Integration (CMMI). Heute umfasst die CMMI-Familie drei bekannte Konstellationen („Constellations“), und dieser Artikel beschäftigt sich in erster Linie mit der Konstellation „CMMI for Development“ (kurz CMMI-DEV). Das CMM wurde entwickelt, um dem amerikanischen Verteidigungsministerium ein besseres Verständnis der kostspieligen Fehlschläge bei Softwareprojekten im Rahmen umfangreicher Beschaffungsprogramme der Regierung zu ermöglichen. Um die „Eignung“ für Regierungsverträge zu ermitteln, wurde eine Bewertung auf CMM-Grundlage vorgenommen. Später entwickelte sich dies zu einem definierten Bewertungsschema auf Grundlage der CMMI.

Das Konzept der Organisationsreife bleibt umstritten. Wie kann beispielsweise der Reifegrad einer Organisation bewertet werden? Und verfügt eine Organisation wirklich über Verhaltensweisen, die sich von den Verhaltensweisen und Aktionen der Einzelpersonen in dieser Organisation unterscheiden? Das Konzept, dass eine Organisation auf einen bestimmten Reifegrad eingewertet wird und dieser als Indikator für die Fähigkeit gilt, zuverlässige Arbeit gegenüber der Regierung zu leisten, ist weiterhin Thema aktueller Debatten. Ich bin nach wie vor ein Verfechter und Unterstützer der CMMI, denn meiner Ansicht nach bietet das Betrachten von Organisationen aus CMMI-Perspektive wertvolle Einblicke für Manager, Prozessingenieure sowie alle externen Projektbeteiligten einschließlich Kunden, Investoren, Governance-Einrichtungen und Auditoren.

Bedeutung der Organisationsreife

Die „Maturity“ (Reife) im CMMI-System soll eine Methode und eine Möglichkeit bieten, um das Risiko und die Beurteilung bei der Entscheidungsfindung zu bewerten und zu verwalten. Der Begriff „Reife“ wird tatsächlich im Sinne der allgemeinen Verwendung in Bezug auf Einzelpersonen verwendet. Beispielsweise sagen uns die Versicherer, dass die Wahrscheinlichkeit eines Autounfalls bei Männern im Alter von 18 Jahren höher ist als bei Frauen im Alter von 55. Der 18-jährige Mann weist wahrscheinlich ein deutlich schlechteres Urteilsvermögen beim Umgang mit einem Fahrzeug auf, außerdem hat er wahrscheinlich nicht genügend Erfahrung, um die Risiken in einer bestimmten Situation angemessen zu bewerten. Dies kann zu Unfällen führen, die von einer 55-jährigen Frau möglicherweise vermieden worden wären. Versicherungsunternehmen sind besonders gut in der Risikobewertung, da sie statistische Daten sammeln und Anhaltspunkte in Beziehung setzen.

Ein Schwerpunkt bei der CMMI ist die abwertend wahrgenommene Art des Begriffs „Reife“. Es wird immer angenommen, dass mehr Reife besser ist als ein niedriger Reifegrad. Und dieser höhere Reifegrad sollte immer angestrebt werden. Wenn wir uns dies bei Einzelpersonen vorstellen, ist es nicht immer sinnvoll. Ein Versicherungsunternehmen kann die Autoversicherung für eine reifere Person sicherlich günstiger anbieten – ein Open-Wheel-Racing-Team jedoch wird den Übermut und die Risikobereitschaft der jüngeren Generation sehr zu schätzen wissen. Für das Racing-Team gehören Unfälle mit dem Rennwagen zum Job. In der Tat würden Fahrer, die nie einen Unfall mit dem Rennwagen gebaut haben, gefeuert werden.

Die Botschaft hier lautet, dass der erforderliche Reifegrad jeweils den Umständen und dem Kontext entsprechen sollte. Ein höherer Reifegrad ist nicht unbedingt besser, aber das korrekte Erkennen und Bewerten der Organisationsreife hilft bei der Einschätzung, ob eine Firma in Bezug auf Projekt- und Produktentscheidungen über ein gutes Risikomanagement und Urteilsvermögen verfügt.

Zwischen dem Reifegrad und der Wahrscheinlichkeit, das gewünschte Ergebnis zu erzielen oder zu liefern, sollte es einen deutlichen Zusammenhang geben. Eine Organisation mit hohem Reifegrad sollte eine sehr reelle Chance haben, ein Ergebnis zu liefern, das dem gewünschten Ergebnis überwiegend entspricht. Das schließt die Reife sowie die Fähigkeit, mögliche, wahrscheinliche und erreichbare Ergebnisse zu ermitteln und die Ziele entsprechend zu setzen, ein. Bei einer Organisation mit niedrigerem Reifegrad ist die Wahrscheinlichkeit geringer, dass erreichbare Ziele festgelegt werden. Zudem ist weniger wahrscheinlich, dass das gelieferte Ergebnis den Erwartungen entspricht. Die Kehrseite dieser Medaille besteht darin, dass eine Organisation mit hohem Reifegrad möglicherweise risikoscheu wird und nur noch leicht erreichbare Ziele festlegt. Eine „übermütige“ Organisation mit niedrigerem Reifegrad hingegen kann vielleicht durch eine Mischung aus Glück und harter Arbeit eine außergewöhnliche Leistung erzielen.

Inspiration für das CMMI-Modell

Das ursprüngliche CMM wurde von Watts Humphrey entwickelt und zuerst (ohne die Bezeichnung CMM) in seinem Buch „Managing the Software Process“[4] genannt. Das Werk wurde durch die im 20. Jahrhundert aufgekommene Bewegung für Qualitätssicherung in der Produktion sowie durch die Arbeit von Joseph Juran, W. Edwards Deming und Philip Crosby beeinflusst. Der Begriff „Reifemodell“ und die fünf enthaltenen Reifegrade sind vom „Manufacturing Maturity Model“ (Produktionsreifemodell) von Crosby inspiriert. Das CMM muss jedoch als echte Synthese verschiedener Konzepte betrachtet werden. Der Begriff „Capability“ (Fähigkeit) basiert nahezu zweifelsfrei auf Deming.

Deming verwendete diesen Begriff mit einer spezifischen Bedeutung, die viel tiefer geht als das normale Sprachverständnis dieses Worts. Genauer gesagt kann eine Fähigkeit als natürliche Philosophie eines Systems oder Vorgangs innerhalb des Systems betrachtet werden. Deming ermutigte Manager, sich mit der Fähigkeit zu beschäftigen und sie statistisch zu analysieren. Er entwickelte sein „System of Profound Knowledge“[5], und dieses System tiefen Verständnisses ist als Entscheidungsrahmen gedacht und soll Managern helfen, geeignete Maßnahmen am Systemdesign vorzunehmen. Deming war ein wahrer Systemdenker. In diesem Fall meint die Bezeichnung „System“ einen von Menschen ausgeführten Prozess. Sein Konzept sah nicht vor, eine Technologie oder Automatisierung einzubeziehen.

Deming glaubte – und hatte Beweise dafür zusammengetragen –, dass 95 % der Leistung eines Systems auf dem Systemdesign, und nicht auf den Fähigkeiten der einzelnen Menschen, die mit diesem System arbeiten, basieren. Mit anderen Worten: Um eine Verbesserung zu schaffen, muss die Veränderung des Prozesses in den Mittelpunkt rücken, also des Systems, mit dem die Menschen arbeiten, und nicht die Verbesserung der einzelnen Leistung dieser Menschen. Folglich glaubte er nicht an Targets, Management auf Basis von Zielen, Motivationsposter oder die Abstrafung von Mitarbeitern wegen schlechter Leistungen.

Aus diesem Grunde erstellte Deming im Rahmen seines „System of Profound Knowledge“ ein „Capability“-Modell (Fähigkeitsmodell), und Crosby lieferte das „Maturity“-Modell (Reifemodell) dazu. Humphrey wollte diese Konzepte miteinander in Einklang bringen und auf den Bereich Softwareengineering anwenden, das Ergebnis war das CMM, das Capability Maturity Model.

Da der Schwerpunkt auf die Bewertung und die Befolgung von Reifegraden zur Qualifizierung für Regierungsaufträge gelegt wurde, verschwanden das Fähigkeitsmodell und der Einfluss von Deming größtenteils aus der Literatur zum Thema CMM und CMMI. Allerdings lässt sich Demings Einfluss deutlich in den Prozessbereichen erkennen, die in den höheren Reifegraden definiert sind.

Laut Konzept sollte die CMMI als Rahmengeflecht dienen, um das Entstehen einer Kultur der kontinuierlichen Verbesserung in einer Organisation zu fördern, und die CMMI sollte immer ein auf Systemdenken basierter Ansatz sein. Die Parallelen zum Lean-Modell sind in den CMMI-Wurzeln offensichtlich.

CMMI ist ein Modell

Die CMMI ist ein Modell zum Verständnis der Reife und Fähigkeit einer Organisation. Es handelt sich dabei weder um einen Standard noch eine Softwareentwicklung oder Definition für einen Projektmanagementprozess. Die in diesem Artikel beschriebenen generischen Verfahren beziehen sich auf die Prozessfähigkeit, nicht auf ein bestimmtes Projekt oder Produkt in der Entwicklung. Wenn beispielsweise in der folgenden Tabelle auf die Planung verwiesen wird, meint das die Planung für die Prozessimplementierung, nicht die Planung für ein Projekt oder eine Produktlieferung.

Das CMMI-Modell besteht aus 22 Prozessbereichen und drei generischen Zielsetzungen, deren Verfolgung von allen Organisationen erwartet wird.

Im Folgenden werden die drei generischen Ziele beschrieben:

Die 22 Prozessbereiche sind in vier Kategorien untergliedert: Engineering, Projektmanagement, Prozessverwaltung und Support. Jeder Prozessbereich umfasst ein bis drei spezifische Zielsetzungen sowie alle drei generischen Ziele. Für jedes Ziel werden im Allgemeinen mehrere Methoden erwartet, mit denen diese Zielsetzung realisiert werden kann. Innerhalb einer Methode kann es vorgeschlagene untergeordnete Methoden geben. Die CMMI erfordert die Ziele oder schreibt diese vor. Die in den Zielsetzungen des CMMI-Modells definierten Methoden werden erwartet, sind aber nicht zwingend nötig. Sind sie nicht vorhanden, müssen sie durch eine geeignete Ersatzmethode ersetzt werden. In der folgenden Tabelle wird die Gruppierung der Prozessbereiche dargelegt:

Organisationsschwerpunkt	Prozessbereich
Engineering	Anforderungsentwicklung Technische Lösung Produktintegration Überprüfung Validierung
Projektverwaltung	Projektplanung Projektüberwachung und -steuerung Integriertes Projektmanagement Lieferantenvertragsmanagement Anforderungsmanagement Risikomanagement Quantitatives Projektmanagement
Prozessverwaltung	Organisatorischer Prozessfokus Organisatorische Prozessdefinition Organisatorische Schulung Organisatorische Prozessleistung Organisatorische Innovation und Bereitstellung
Unterstützung	Konfigurationsverwaltung Prozess- und Produktqualitätssicherung Messung und Analyse Entscheidungsanalyse und -auflösung Ursachenanalyse und -auflösung

Das Prinzip ist einfach: Wenn eine Organisation die Fähigkeit zum Erreichen der Ziele in den einzelnen Prozessbereichen aufweist, kann von ihr gesagt werden, dass sie in diesem Prozessbereich über eine Fähigkeit verfügt.

Die Prozessbereiche werden auch in Reifegrade gruppiert, die eine schnelle Methode zur Reifebeschreibung darstellen. Obwohl die Gruppierung von Prozessbereichen in Reifegrade in vielerlei Hinsicht umstritten bleibt, habe ich in den letzten 20 Jahren bei meinen Unternehmensbeobachtungen festgestellt, dass die aktuelle Modellversion 1.3 (wenn die CMMI effektiv als Version 2 des CMM angesehen wird) im Großen und Ganzen zutreffend ist. Unstrukturierte Organisationen mit geringem Reifegrad tendieren dazu, zuerst eine Fähigkeit in den Prozessbereichen mit Reifegrad 2 zu entwickeln, bevor sie eine in den Prozessbereichen mit höheren Reifegraden erreichen.

In der folgenden Tabelle werden die Prozessbereiche in Reifegraden gruppiert.

Reifegrad	Prozessbereiche
5	CAR – Ursachenanalyse und -auflösung OPM – Organisationsleistungsverwaltung
4	OPP – Organisationsprozessleistung QPM – Quantitatives Projektmanagement
3	RD – Anforderungsentwicklung TS – Technische Lösung PI – Produktintegration VER – Verifizierung VAL – Validierung IPM – Integriertes Projektmanagement RSKM – Risikomanagement OPF – Organisationsprozessschwerpunkt OPD – Organisationsprozessdefinition OT – Organisationsschulung DAR – Entscheidungsanalyse und -auflösung Prozess- und Produktqualitätssicherung
2	CM – Konfigurationsverwaltung MA – Messung und Analyse SAM – Lieferantenvertragsverwaltung PP – Projektplanung PMC – Projektüberwachung und -steuerung RM – Anforderungsmanagement
1	Es gibt keine Prozessbereiche im Reifegrad 1 des Modells. Reifegrad 1 stellt einen undefinierten Prozess ohne Selbstbeobachtung oder die Fähigkeit dar, einen Prozess zu definieren oder ein Ergebnis aufgrund der Kenntnis des Prozesses, durch den es erzeugt wurde, zu wiederholen. Technisch gesehen wird bei einer CMMI-Bewertung eine Organisation, die nicht die Ziele für die Prozessbereiche gemäß Reifegrad 2 des Modells erfüllt, noch im Reifegrad 1 des Modells geführt. Deshalb werden Organisationen mit in der Entwicklung befindlichen Prozessen technisch gesehen weiterhin mit Reifegrad 1 des Modells angegeben, obwohl sie bereits einen langen Reifeweg (weg vom undefinierten Chaos) hinter sich gebracht haben.

Die folgende Tabelle enthält eine Übersicht auf Basis des Gebiets oder des Zwecks der einzelnen Prozessbereiche:

Prozessbereich	Zweck
CAR – Ursachenanalyse und -auflösung	Untersuchen Sie die zugrunde liegende Ursache von ungewöhnlichen Prozessproblemen (besondere Ursachenvariationen, um den Begriff von W. Edwards Deming zu verwenden), und Unterbreiten und Implementieren Sie Prozessänderungen, um Wiederholungen dieser Probleme zu unterbinden. Die Aufmerksamkeit wird auf ungewöhnliches Verhalten von quantitativ erfassten, stabilen Prozessen gerichtet. Die täglich auftretenden Unwägbarkeiten würden wohl eher in den Bereich des Risikomanagements (RSKM) als unter CAR fallen.
CM – Konfigurationsverwaltung	Dieser Prozessbereich ist mehr als nur eine Quellcode-Versionskontrolle, er deckt die gesamte Verwaltung in Bezug auf Systemumgebungen, Komponentenkonfigurationen, Plattformen, Middleware, Anwendungen und Dokumentation ab. Die Fähigkeit, ausführbaren Code erfolgreich zu erstellen und bereitzustellen, fällt ebenfalls in diesen Prozessbereich.
DAR – Entscheidungsanalyse und -auflösung	Bei allen wichtigen Entscheidungen innerhalb einer Projekt- oder Produktentwicklung sollten Sie zeigen, dass eine Reihe von Alternativen oder Optionen bedacht und die Eignung verschiedener Optionen anhand von kontextbedingten Elementen ermittelt wurde. Zeichnen Sie die Entscheidung und die Gründe für die Wahl auf.
IPM – Integriertes Projektmanagement	Diese zweite Stufe des Projektmanagements innerhalb des CMMI-Modells bedeutet, dass eine Organisation mehrere potenziell abhängige Projekte gleichzeitig verwalten kann. Dies wird häufig durch den Einsatz eines Programm- oder Portfoliomanagementbüros erreicht.
MA – Messung und Analyse	Sammeln von Daten zur Prozess-, Projekt- und Produktleistung. Erstellen Sie Metriken und Indikatoren in Form von Berichten basierend auf den Daten.
OPD – Organisationsprozessdefinition	Die Organisation sollte mindestens eine Prozessdefinition aufweisen, die in einem Kontext definiert ist. Ein Kontext beschreibt ein Risikoprofil. Für jedes Projekt kann eine Risikobewertung vorgenommen, eine Prozessdefinition aus dem Organisationskatalog ausgewählt und entsprechend angepasst werden.
OPF – Organisationsprozessschwerpunkt	Die Organisation sollte die Ansicht vertreten, dass eine Prozessdefinition die Fähigkeit definiert und beeinflusst, und dass diese in erster Linie durch verbesserte Prozesse gefördert wird. Folglich wird die Organisation ihre Prozessdefinitionen umsichtig verwalten und überwachen (mithilfe des PPQA-Prozessbereichs), um eine Befolgung dieser Definitionen sicherzustellen.
OPM – Organisationsleistungsverwaltung	Dieser Prozessbereich enthält das Konzept eines statistischen Verständnisses dafür, wie gut ein Prozess im Vergleich mit seiner erwarteten Fähigkeit abschneidet. Sollten die beobachteten Ergebnisse nach einer Änderung der Prozessdefinition nicht die gemäß zugrunde liegendem Prozessmodell erwarteten Ergebnisse widerspiegeln, können diese Änderungen am Prozess, mit denen die Fähigkeit optimiert werden sollte, ausgewertet und das dem Prozess zugrunde liegende Modell überprüft werden. Die Organisation verwaltet ihre Leistung über die Prozesse, um den Geschäftsanforderungen gerecht zu werden.
OPP – Organisationsprozessleistung	Dieser Prozessbereich umfasst das Konzept des Leistungsvergleichs, das häufig auch als „Benchmarking“ bezeichnet wird. Für den Leistungsvergleich erstellt der OPP-Bereich Prozessmodelle anhand von Basisliniendaten. Damit erhält eine Organisation die Möglichkeit, Fragen wie „Welches unserer drei Produktteams sollten wir mit [diesem spezifischen Projekt] beauftragen?“ zu beantworten.
Organisatorische Schulung	Die Fähigkeit des einzelnen bei bestimmten Tätigkeiten ist wichtig für Prozessleistung und Systemfunktion. Ein System mit gutem Verhalten und starker Leistung erfordert eine gute Schulung, um Varianzen der Fähigkeit auf Ebene der lokalen Umsetzung zu reduzieren.
Produktintegration	Das Vermögen, mehrere Komponenten zur Schaffung eines Gesamtprodukts zu integrieren und die Elemente zu verwalten, die dafür nötig sind.
Projektüberwachung und -steuerung	Erfassen von Daten über laufende Projekte, Vergleich mit Plänen, Projektionen und Simulationen sowie Durchführen geeigneter Maßnahmen auf Basis dieser Daten.
Projektplanung	Planen der Projekte auf Grundlage von Schätzungen, Simulationen und Analysen der Anforderungen.
Prozess- und Produktqualitätssicherung	In erster Linie handelt es sich um eine Prüffunktion für die Prozesskonformität. Sie soll veranschaulichen, dass das System wie geplant funktioniert. Dieser Prozessbereich hilft dabei, potenzielle Verwaltungsfehler beim Ändern eines Prozesses zur Problembehebung zu vermeiden, falls der aktuelle Prozess nicht wie beabsichtigt befolgt wird.
Quantitatives Projektmanagement	Dies ist die dritte und damit höchste Stufe des Projektmanagements innerhalb des CMMI-Modells. Sie besagt, dass statistisch profunde, quantitative Methoden zur Planung, Überwachung und Verwaltung von Projekten verwendet werden.
Anforderungsentwicklung	Es gibt einen definierten wiederholbaren Prozess, um Anforderungen anzubieten, auszuhandeln, zu analysieren und zu dokumentieren.
Anforderungsmanagement	Anforderungen werden während des Projektlebenszyklus nachverfolgt. Im Idealfall liegt eine End-to-End-Rückverfolgbarkeit zwischen der gelieferten Konfiguration und der ursprünglich geforderten Anforderung vor.
Risikomanagement	Obwohl das gesamte CMMI-Modell als Framework für das Risikomanagement betrachtet werden kann, beschäftigt sich dieser Prozessbereich insbesondere mit dem „ereignisgesteuerten Risiko“ oder der Wahrscheinlichkeit von besonderen Ursachenvariationen und täglichen Unwägbarkeiten sowie deren Auswirkungen. Er erfordert eine Risikoreduzierung und -minderung sowie Notfallplanung, Problemverwaltung und -auflösung.
Lieferantenvertragsmanagement	Die Möglichkeit, externe Anbieter zu verwalten, Verträge zu definieren, den Vertrag zu verwalten und die Lieferung des gewünschten Produkts oder des Diensts in Empfang zu nehmen.
Technische Lösung	Alle nötigen Kompetenzen in Bezug auf die Architektur, das Design und die Programmierung von Software.
Validierung	Akzeptanztests für Kundenanforderungen.
Überprüfung	Tests für einen Entwurf (von der technischen Lösung). Dieser Bereich dient der Sicherstellung, dass das entwickelte Produkt mit den Vorstellungen übereinstimmt und so entworfen und zusammengestellt ist, dass es den Anforderungen der Benutzer entspricht und in ihrer Umgebung funktioniert.

Für jeden Prozessbereich kann ein Fähigkeitsgrad zugewiesen werden. Vier Fähigkeitsgrade werden in der CMMI-Version v1.3 definiert:

0. Unvollständig

1. Ausgeführt

2. Verwaltet

3. Definiert

Wenn eine bestimmte Zielsetzung und einige der allgemeinen Ziele erreicht sind, wird für einen bestimmten Prozessbereich mindestens der Fähigkeitsgrad „1 – Ausgeführt“ angegeben. Fähigkeitsgrad 1 bedeutet, dass die Teammitglieder wissen, welche Schritte erforderlich sind und diese auch ausführen. Die spezifische Methode weist jedoch wahrscheinlich bei einer statistischen Analyse keinerlei Stabilität auf. Methoden werden befolgt, dennoch liegt weiterhin einen Mangel an Kontinuität vor. Fähigkeitsgrad 2 bedeutet, dass das Team versteht, wie etwas funktioniert. Außerdem verfügt es über die nötigen Kompetenzen, sodass die erbrachte Methodenleistung vorhersehbar wird und mit hoher Wahrscheinlichkeit eine statistische Steuerung aufweist. Es ist wahrscheinlich, dass Schulungen oder gemeinsame Arbeitsmethoden vorhanden sind, um eine höhere Kontinuität unter den Teammitgliedern zu schaffen. Fähigkeitsgrad 3 bedeutet eine ausgezeichnete Beherrschung der Kompetenzen sowie das Vermögen, neue und verbesserte Techniken zu entwickeln, mit denen die Zielsetzung realisiert wird. Eine Fähigkeit mit Fähigkeitsgrad 3 heißt auch, dass für jede statistische Analyse nach einer expliziten Änderung in der zugrunde liegenden Technik oder Methode eine erneute Basislinienerstellung erforderlich wäre.

Einfaches Verständnis der CMMI

Das CMMI-Modell besagt im Prinzip, dass neue und „unreife“ Organisationen sich zunächst Fähigkeiten bei den Methoden zum Verwalten von Konfigurationen und Quellsteuerung, Sammeln von Daten zu Projekten und ausgeführten Tätigkeiten, Planen von Projekten, Nachverfolgen von Anforderungen, Überwachen des Projektfortschritts und Ergreifen von Maßnahmen auf Basis des Vergleichs von Istdaten mit Plandaten aneignen müssen. Das sind die grundlegenden Aspekte von Reifegrad 2.

Bei Vorhandensein von Fähigkeiten des Reifegrads 2 richten die Organisation und ihre Mitarbeiter ihre Aufmerksamkeit auf andere Aspekte, woraufhin sich die Fähigkeit zum Definieren von Anforderungen, Tests, Architektur und Entwurf, Integration und Definieren von Prozessen, sodass diese wiederholbar werden, entwickelt. Wenn sich die Dinge zunehmend stabilisieren, entsteht ein Verständnis davon, wie sich Kultur und Führungsstil auf die Leistung auswirken. Im besten Falle folgt daraus die Erkenntnis, dass ein auf dem Systemdenken basierender Ansatz erforderlich ist, um eine weitere Leistungsverbesserung zu erreichen. Nachdem alles mehr und mehr stabilisiert ist, und die täglichen Aufgaben wie Planung und Projektüberwachung zur zweiten Natur werden, bleibt genügend Zeit, das Risikomanagement zu berücksichtigen und vor einer Entscheidung Alternativen und Optionen durchzugehen. Womöglich kommt es vor, dass mehrere abhängige Projekte koordiniert werden, und sich die Governance von gemeinsam genutzten Ressourcen verbessert. Vielleicht wird ein Schulungskurs, ein Mentoring-Programm, ein Tutorprogramm nach dem Schüler-Lehrer-Prinzip eingeführt, oder es entstehen einfach ritualisierte Formen der Zusammenarbeit, mit denen der Fähigkeitsgrad verbessert und das allgemeine Leistungsniveau gehoben wird. Falls notwendig, wird eine interne Prüfungsfunktion oder Funktion zur Prozessqualitätssicherung eingeführt. Das sind die grundlegenden Aspekte von Reifegrad 3.

Wenn eine Organisation mit dem soliden Reifegrad 3 arbeitet, läuft alles wie am Schnürchen. Die Organisation hält ihre Zusagen ein und gilt als sehr zuverlässig. In Beziehungen mit Kunden herrscht ein hohes Maß an Vertrauen vor. Die Senior Manager fangen an, Fragen wie „Wo soll ich in weitere Verbesserungen investieren?“ und „Welches Team liefert die wirtschaftlich beste Leistung?“ zu stellen. Die Manager beginnen, tiefere und umfassendere Einblicke in Fähigkeit und Leistung zu bekommen. Sie erkennen, dass sie anhand von Simulationen und statistischen Analysen die Produktqualität, Kundenauslieferung und -zufriedenheit verbessern können. Die Entscheidungen des Managements sind nun vollständig objektiv und lassen sich mit Statistikdaten untermauern. Das sind die grundlegenden Aspekte einer Organisation mit Reifegrad 4. Für die meisten Senior Manager stellt Reifegrad 4 den idealen Zustand dar. Alles läuft wie ein Uhrwerk, ihnen liegen vergleichende Leistungsdaten vor, und sie können Zusagen mit hoher Genauigkeit einhalten. Die wirtschaftliche Leistung ist erheblich besser, und die Organisationsleistung ist sehr vorhersehbar.

Das Verhalten gemäß Reifegrad 5 tritt häufig auf, bevor eine Organisation tatsächlich diesen Reifegrad 5 erreicht. Die Fehlerursachenanalyse findet häufig bei Organisationen mit Reifegrad 3 statt. Damit daraus eine Fähigkeit mit Reifegrad 5 wird, muss diese Fehlerursachenanalyse mithilfe von quantitativen Daten ausgeführt werden und statistisch belegbar sein. Die Entwicklung eines formelles Verfahrens für die Prozessinnovation sowie die Umsetzung von Verbesserungen sollten ebenfalls stattfinden, bevor die Organisation als wahrhaftige Reifegrad-5-Organisation gilt. Bei Reifegrad 5 ist die Prozessverbesserung institutionalisiert und in die Kultur der Organisation eingeprägt. Die Kultur basiert darauf, ständig den Status Quo herauszufordern und immer nach verbesserter Fähigkeit, verbesserter Produktqualität und verbesserter wirtschaftlicher Leistung zu streben.

CMMI-Bewertungen

Eine CMMI-Reifegradeinstufung wird durch eine Bewertung festgelegt. Die Standardmethode für die Bewertungsausführung heißt SCAMPI (Standard CMMI Appraisal Method for Process Improvement, CMMI-Standardbewertungsmethode für Prozessverbesserung). Sie wurde eingeführt, um die Wiederholbarkeit des Prozesses zu gewährleisten und Vertrauen in dessen Ergebnis zu etablieren. Es gibt bei den Bewertungen drei Härtestufen, die als Klassen A, B und C bezeichnet werden, wobei Klasse A die strikteste ist. Bewertungen der Klasse A sind für eine Reifegradeinstufung gemäß Modell erforderlich, die den Anforderungen von Staatsarchiven oder dem US-Verteidigungsministerium entspricht.

Sämtliche Bewertungen der Klasse A sowie die meisten Bewertungen der Klassen B und C werden von sogenannten CMMI Lead Appraisers durchgeführt, die vom SEI (Software Engineering Institute) dafür autorisiert sind. Diese Berater haben ein umfangreiches Schulungsprogramm absolviert, bevor sie eine Lizenz für die praktische Durchführung erhielten. Einige der Appraiser haben sich durch zusätzliche Schulungen die Bezeichnung „CMMI High Maturity Lead Appraiser“ erworben. Organisationen, die den Reifegrad 4 oder 5 gemäß Modell anstreben, müssen mit einem High Maturity Lead Appraiser zusammenarbeiten.

Die Bewertungen sollen nachweisen, dass Methoden zur Erreichung der Ziele innerhalb der CMMI-Prozessbereiche ausgeführt worden sind. Bei einer Organisation mit zahlreichen Projekten und möglicherweise mehreren Geschäftsbereichen wird eine komplexe Formel herangezogen, um zu ermitteln, wie viele Projekte mit welchem Umfang bewertet werden müssen. Das Ziel besteht darin, eine angemessene Abdeckung durch einen Samplesatz an Projekten zu gewährleisten, der veranschaulicht, dass die Organisation eine institutionalisierte Fähigkeit in jedem der erforderlichen Prozessbereiche aufweist. Der Lead Appraiser benennt die zu bewertenden Projekte auf Basis dieser Formel.

Bei jedem Projekt, für das eine Bewertung vorgenommen wird, sind Nachweise zusammenzustellen. Diese müssen belegen, dass Methoden ausgeführt worden sind, die eine ausreichende Fähigkeit innerhalb des Prozessbereichs aufzeigen. Bei jeder Methode sucht der Appraiser nach greifbaren und konkreten Beweisen, die als Artefakte bezeichnet werden und häufig in dokumentarischen Belegen wie Plänen, Quellcode, Entwürfen und Architekturdokumenten aufzufinden sind. Außerdem suchen sie nach Bekräftigungen. Eine Bekräftigung basiert im Allgemeinen auf Hörensagen, wie z. B. Mitarbeiter, die über die Ausführung einer Methode sprechen, oder Anekdoten, die auf eine Teilnahme an einer Planungsbesprechung verweisen. Diese Bekräftigungen werden durch Gespräche mit Mitarbeitern, die an den zu bewertenden Projekten beteiligt waren, gesammelt. Bekräftigungen können die dokumentarischen Belege verstärken oder widerlegen, was möglicherweise dazu führt, dass der Appraiser die Gültigkeit der Dokumentation anzweifelt.

CMMI-Bewertungen sind nicht erforderlich, damit das CMMI-Modell sinnvoll ist. Die CMMI hilft Organisationen im Bereich der Softwareentwicklung, ihre Fähigkeit und ihren Reifegrad zu erkennen und mit den Erwartungen von ihren Kunden und anderen externen Beteiligten zu vergleichen. Die ungefähre Vorstellung davon, wo die Organisation im CMMI-Modell angesiedelt ist, bietet eine Möglichkeit der Bewertung, wie sie unter Belastung reagiert und ob sie die Erwartungen erfüllen kann. Organisationen, die Aktivitäten höheren Reifegrads ausführten, obwohl sie keine solide Grundlage für das Verhalten von niedrigeren Reifegraden aufwiesen, stellten sich häufig als nicht vorhersehbar heraus. Das liegt daran, dass Verhalten von höheren Reifegraden vorhanden ist – und das ist löblich –, dass aber diese Methoden für höhere Reifegrade unzuverlässig sind, da sie nicht auf eine solide Grundlage aufbauen.

CMMI-Bewertungen werden häufig als Möglichkeit angesehen, eine organisationsweite Initiative zur Prozessverbesserung zu validieren. Damit entsteht der Druck, einen „Test“ bestehen zu müssen. Die Konzentration verlagert sich dahin, zu zeigen und auch zu beweisen, dass jede Methode in jedem Prozessbereich befolgt wird. Dadurch wird leicht aus dem Blick verloren, was wirklich wichtig ist: Die Fähigkeit im Bereich Kundenerwartungen unter Beweis zu stellen, und diese Fähigkeit durch explizite Managementaktionen zu verbessern. Dieser auf das Bestehen des „Tests“ gerichtete Schwerpunkt hat schon oftmals zu massiven Nebeneffekten und Funktionsstörungen in Organisationen geführt. Deshalb gibt es in der Branche zahlreiche CMMI-Kritiker. Das ist sehr schade, denn ich bin fest davon überzeugt, dass das CMMI-Modell überzeugend ist und wertvolle Einblicke für die Manager einer Organisation bietet – Einblicke, die zu einer besseren Fähigkeit, besserer Leistung und höherer Kundenzufriedenheit führen können.

[1] Anderson, David J., Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results, Prentice Hall PTR, 2003

[2] Anderson, David J., Kanban: Evolutionäres Change Management für IT-Organisationen, dpunkt, 2011

[3] Glazer, Hillel, und Jeff Dalton, David J. Anderson, Michael D. Konrad, Sandra Shrum, CMMI or Agile: Why not embrace both!, Software Engineering Institute, November 2008

[4] Humphrey, Watts S., Managing the Software Process, Addison Wesley Professional, 1989

[5] Deming, W. Edwards, The New Economics for Industry, Government, Education, 2. Edition, The MIT Press, 2000