Transformation - Information Management

Transformation: Unternehmensführung und IT 

Teil 5: Qualitätssicherung von Grossprojekten 

Prof. Thomas A. Gutzwiller 

17. Dezember 2006

Wie definieren wir Projektqualität? 

| 17. Dezember 2006 | Teil 5 

| Thomas Gutzwiller - Transformation 

Seite 2

Determinanten der Projektqualität - Das magische Dreieck 

Kosten des Projektes 

Zeit des Projektes 

Nutzen des Design- 

Produktes 

(Leistungsumfang) 

Es ist normal, dass jedes Projekt Qualitätsprobleme 

hat; d.h., dass Kosten, Zeit und oder Nutzen nicht 

vollumfänglich erreicht werden können. 

Dies muss eben entsprechend ‚gemanaged‘ werden. 



Seite 3

Was ist Qualitätssicherung? 



Seite 4

Grundsätzliche Zusammenhänge - Kategorien der Qualitätssicherung 

• Konstruktive Qualitätssicherung 

Konstruktive Qualitätssicherung bedeutet, dass der Projektprozess klar definiert ist, 

im Sinne 

– Eines Vorgehensmodells für das Projekt 

– Einer allgemeinen Projektmanagement-Methode zur übergreifenden Steuerung des 

Projektes 

• Analytische Qualitätssicherung 

Analytische Qualitätssicherung bedeutet Review und Testen des Designproduktes 

und Auditieren des Projektprozesses. 

Die Prozessqualität determiniert die Produktqualität 



Seite 5


Qualitätssicherung 

Konstruktiv 

Analytisch 

Vorgehens- 

Modelle 

(spez. Projekt- 

Prozess) 

allg. 

Projekt- 

Management- 

Prozess 

Review 

Test 

Audit 

Qualitätslenkung 

Qualitätsprüfung 



Seite 6


• Konstruktive Qualitätssicherung / Qualitätslenkung 

Qualitätslenkung steuert und überwacht den Projektentwicklungsprozess mit dem 

Ziel, die durch den Prozess vorgegebenen Anforderungen zu erfüllen (prospektiv). 

• Analytische Qualitätssicherung / Qualitätsprüfung 

Qualitätsprüfung stellt fest, inwieweit das Projekt resp. das Designprodukt 

die durch die Qualitätslenkung vorgegebenen Anforderungen erfüllt 

(retrospektiv). 

Die Prozessqualität determiniert die Produktqualität 



Seite 7

Erste Diagnosen in einem schlecht laufenden Projekt 

• Wenn das Projektteam das Vorgehen selbst erfinden muss oder über die richtige 

Vorgehensweise gestritten wird ... 

• Wenn es ‚Stars‘ in einem Projekt gibt, die das Projekt ‚reissen‘... 

• Wenn die Mitarbeiter permanent Überstunden machen... 

dann 

• ... hat das Projekt meistens kein definiertes, akzeptiertes und validiertes Vorgehen. 

Dass das Projekt sein Ziel erreicht, ist unwahrscheinlich. 

• Mit Projektmanagement alleine kann kein Projekt gesteuert werden, Es braucht 

zusätzlich ein spezifisches, auf die Problemstellung abgestimmtes 

Vorgehensmodell. 

Ohne definiertes Vorgehen kommt man meistens 

nicht an das Ziel. 



Seite 8

Eine kleine Geschichte in diesem Zusammenhang 

The miller and his son were taking their donkey to town to sell. 

They were walking alongside it when they passed a group of people who started 

laughing and said, 'Look at them walking alongside their donkey when they could be 

riding it.' The father then said to his son, 'You get up on the donkey and I will continue 

walking alongside.' 

Soon they passed a second group of people who began to scorn the son, 'What is 

the youth of today coming to? Why are you riding, you lazy bones, while your father 

walks?' The father and son swapped places. 

Shortly they came to a third group of people who scorned the father, 'Look at the 

man riding while his son, a mere child, walks.' The son's legs were getting weary, so 

the father suggested the son join him on the donkey. 

Soon they came to a fourth group of people who asked the miller and his son 

where they were riding the donkey to. 'We are taking it to market to sell' said the 

father. 'Well, you should better not ride it or you will tire it out and nobody will want to 

buy it. In fact, you should better now carry it the rest of the way,' responded the 

people. The miller and his son got off and started carrying the donkey. 

As they crossed the bridge coming into town, the town people started laughing at 

the sight of the man and his son carrying their donkey. They laughed so loudly that the 

donkey began to wriggle and the miller and his son dropped it over the edge of the 

bridge. The donkey was drowned. 



Seite 9

Eine kleine Geschichte in diesem Zusammenhang 

The miller and his son went home. The miller said, ‘I wish I had never left home this 

morning’. Then I had a donkey. I tried to please all those people and now I have 

nothing.' 

Das Ziel war für den Müller klar. 

Nur das Vorgehen nicht. 



Seite 10

Projekte in einer Zwei-Parteien-Vertragsbeziehung 

• Oft treffen wir Situationen in Gross-Projekten vor, in der die Unternehmung externe 

Lieferanten (z.B. Beratungshäuser oder die ausgelagerte IT) hinzuzieht. 

• In diesem Falle ist die Verantwortung zwischen den Parteien zu regeln. Die ISO 

9001 Norm bietet hier für eine entsprechende Handhabe. 

• Grundsätzlich lässt sich die Verantwortung wie folgt festlegen: 

– Auftraggeber: 

• „Produktverantwortung“ – hat Verantwortung für Kosten, Termine und Nutzen (Leistungsumfang) 

• Steuerung des Projektes auf der Ebene „Externes Projektmanagement“ 

– Auftragnehmer: 

• „Prozessverantwortung“ – hat Verantwortung für einen ‚State of the Art‘ Projektprozess 

(Vorgehensmodell), den er auch beherrscht (Repetierbarkeit) 

• Steuerung des Projektes auf der Ebene „Internes Projektmanagement“ 



Seite 11

Externe und interne Projektsteuerung 

• Externe Projektsteuerung (Auftraggeber) 

Plangrössen sind 

– Phasenbezogene Meilensteine (Termine) 

• Reviewfähige Unterlagen 

• Bereit für Anwendertest 

– Gesamtaufwendungen, Gesamtkosten des Projektes 

– Realisierbarer Nutzen (Leistungsumfang) 

– Risikofaktoren 

• Interne Projektsteuerung (Auftragnehmer) 

Plangrössen sind 

– Projektaufbau-Organisation 

– Projekt-Ablauforg. mit Feinplanung (pro Phase) und Aktivitäten-/Ergebnis-Abhängigkeiten 

– Projektdokumentation; Ergebnisstrukturierung 

– Zur Verfügung stehende Ressourcen (insb. Mitarbeiter Auftraggeber/Auftragnehmer) 

– Zuordnung von Mitarbeitern zu Aktivitäten/Ergebnissen mit Feinaufwandsplanung 

(Arbeitsaufträge) 



Seite 12

Auftraggeber-Organisation 

Auftraggeber 

Projekt-Aufsicht 

(Fach-Ausschuss durch 

Fachmanagement) 

Review-Team 

(Fachexperten) 

Auftraggeber- 

Projektleiter 

Die Auftraggeber-Organisation hat 

„Produkt“-Verantwortung 



Seite 13

Auftragnehmer-Organisation 

Auftragnehmer 

Auftragnehmer- 

Projektleiter 

Team 1 Team 2 

... 

Team n 

Die Auftragnehmer-Organisation hat 

„Prozess“-Verantwortung 



Seite 14

Auftragnehmer-Organisation 

• Die Teams variieren je nach Projekttyp. 

Typischerweise findet man folgende Teams in Projekten: 

– Project-Office Teams 

– Change-Management Teams 

– Analyse-Teams 

– Design-Teams 

– Front-End-Konstruktions-Teams 

– Komponentenentwicklungs-Teams 

– Querschnittsfunktionen 

• Methoden-Spezialisten-Teams 

• Werkzeug-Spezialisten-Teams 

• Datenbank-Administrations-Teams 

• Test-Teams 

• Technische Infrastruktur-Teams 

– Abnahme-Teams 

– Einführungs-Teams 



Seite 15

Team-Zusammensetzung in einer Zwei-Parteien-Vertragsbeziehung 

• Teams: 

– Project-Office Teams 

– Change-Management Teams 

– Analyse-Teams 

– Design-Teams 

– Front-End- Konstruktions-Teams 

– Komponentenentwicklungs-Teams 

– Querschnittsfunktionen 

• Methoden-Spezialisten-Teams 

• Werkzeug-Spezialisten-Teams 

• Datenbank-Administrations-Teams 

• Test-Teams 

• Technische Infrastruktur-Teams 

– Abnahme-Teams 

– Einführungs-Teams 

Einbezug von 

Mitarbeitern 

aus der 

Auftraggeber- 

Organisation 

X 

X 

X 

X 

X 

X 

X 

Einbezug von 

Mitarbeitern 

aus der 

Auftragnehmer- 

Organisation 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 



Seite 16

Organisation der Phasenfreigabe als zentrales Element der Zwei- 

Parteien-Vertragsbeziehung 

• Projekte werden in Phasen aufgeteilt. 

• Am Phasen-Ende zeichnet die Auftraggeber-Organisation die Ergebnisse an, so 

dass mit stabilen Voraussetzungen in die nächste Phase gegangen werden kann. 

• Die Phasen eines Projektes werden durch das Vorgehensmodell vordefiniert. Je 

nach Projekttyp gibt es ein unterschiedliches Vorgehensmodell und deshalb auch 

eine unterschiedliche Phasenstruktur. 

• Am Ende einer Phase kommt es zu einem Review resp. zu Tests (in der bzw. den 

Endphase[n]). 



Seite 17

Organisation der Phasenfreigabe als zentrales Element der Zwei- 

Parteien-Vertragsbeziehung 

• Der Auftraggeber-Projektleiter organisiert ein Review- (resp. Test-) Team. 

• Das Review (resp. Test-) Team (Fachexperten) überprüft das Design-Produkt und 

gibt seine Empfehlung der Projektaufsicht (Fachausschuss) ab. 

• Der Fachausschuss erteilt die Phasenfreigabe resp. ordnet an, was an dem 

Design-Produkt noch entsprechend nachzuarbeiten ist. 

Durch dieses Verfahren wird sichergestellt, 

dass der Nutzen des Design-Produktes von 

nicht tagtäglich im Projekt involvierten, 

unabhängigen Fachexperten überprüft wird. 



Seite 18

Organisation der Phasenfreigabe „Strategie-Entwicklungsprojekt“ 

Projektvorgehen planen 

Vision 

Interne Analyse 

Externe Analyse 

GAP-Analyse 

Review 

Erarbeitung strategischer Optionen 

Auswahl einer strategischen Option 

Review 

Umsetzungsplanung 

Review 

Umsetzungscontrolling 



Seite 19

Organisation der Phasenfreigabe „Prozessentwicklungs-Projekt“ 

Prozessentwurf 

Change Management Massnahmen 

Geschäftsstrategie 

prüfen und ergänzen 

Stakeholder ermitteln 

und analysieren 

Mikro - Entwurf Makro - Entwurf 

Vorstudie 

Prozessarchitektur 

entwerfen 

Prozessausschüsse und 

-manager bestimmen 

Prozessvision 

entwickeln 

Prozessleistungen 

prüfen und definieren 

Prozessablauf 

auf Makroebene 

neu entwerfen 

Mikro-Prozesse 

abgrenzen 

Prozessführung 

entwerfen 

Prozessabläufe auf 

Mikro-Ebene 

neu entwerfen 

Prozesszirkel 

einrichten 

Review 

Review 

Review 

Projekt-Umfeld 

analysieren 

Informations- 

Konzept erarbeiten 

Projektumfeld 

analysieren, 

Stakeholder 

überprüfen 

Massnahmen ableiten 



Seite 20

Organisation der Phasenfreigabe „Informationssystemplanung- 

Projekt“ 

IS/IT-Strategiegrundlagen 

IS/IT-Strategiegrundlagen 

Strategische Strategische 

IS-Planung IS-Planung 

Strategische Strategische 

IT-Planung IT-Planung 

Methoden Methoden und und 

Verfahren Verfahren 

Gestaltung Gestaltung der der Organisation Organisation Informatik Informatik 

Review 

Verteilung der IS/IT- Komponenten 

Verteilung der IS/IT- Komponenten 

Review 

Migrationsplanung 

Migrationsplanung 

Review 

Change Change 

Management 

Management 

Strategische System und Technologieplanung 

IS/IT- IS/IT- 

Portfoliomanagement 

Portfoliomanagement 



Seite 21

Organisation der Phasenfreigabe „Standardsoftware- 

Entwicklungsprojekt“ 

Grobkonzept 

(Design) 

Soll-Geschäftsprozesse 

Soll-Aufgaben 

Detailkonzept 

Review 

Parametrisierung 

Integrationstests 

Einführungsplan 

Verf. OrgKonzept 

Abschl. Parametr. 

Unternehmensstruktur 

Schnittstellenkonz. 

Datenübernahmekonzept 

Realisierung 

Review/Test 

Ausfallplanung 

OrgDokument. 

Schnittstellenprogramm 

e 

Datenerfassung u. - übernahme 

Systemdokument. 

Produktivbetrieb 

Test 

Entwi 

cklun 

gssys. 

Datenübernahme 

Review/Test 

Test Produktivsystem 

Einführung 

Systemumstellung 



Seite 22

Organisation der Phasenfreigabe „Prozess- und 

Systemintegrationsprojekt“ 

IT-Szenario 

Datenanforder. 

Funktionsanforder. 

Applikationsszen. 

Applikationsverz. 

Schnittstellenbe. 

Voruntersuchung 

Arbeitsschrittliste 

Workflowverz. 

Infrastrukturplan 

Umsetzungsplan 

Aktivitätenverz. 

Aktivitätenbeschr. 

Aktivitätenketten 

Konzeption 

Review 

Arbeitsschrittbeschr. 

Dialogflussdiagr. 

Programmentwurf 

M: Aktivität - Stelle 

WF-Steuerung 

Testplan 

Testfälle 

Review 

WF Client Applikation 

Test 

Realisierung 

Review/Test 



Seite 23

Organisation der Phasenfreigabe „Eigen-Entwicklungsprojekt“ 

IS-Projekt (Applikationsentwicklung) Rahmenbed. 

Unternehmensleitung/ 

Informatikleitung: 

Entwicklung des IS-Konzeptes 

( IS-Konzept). 

Unternehmensleitung/ 

Informatikleitung: 

Entwicklung der Informationssystem-Architektur 

( Informationssystem-Architektur). 

Organisator/ 

Fachbereich: 

Entwicklung der betrieblichen 

Strukturen und Abläufe 

( Prozessentwurf). 

Wirtschaftsinformatiker – Informationsrelevantes Modell des Soll-Geschäftssystem erstellen 

Modellierung der informationsrelevanten Aspekte, welche durch di e 

zu schaffenden Applikationen abgedeckt werden sollen (wesentliche Daten und Transaktionen). 

Review 

Wirtschaftsinformatiker – Externes Modell der Applikationen erstellen 

Spezifikation des EDV-Systems. Identifikation und Detailentwurf aller Transaktionen nkl. (i Dialog), 

welche die neuen Applikationen anbieten sollen. Identifikation und Detailentwurf der Datenbanken. 

Review 

Software-Ingenieur – Internes Modell der Applikationen erstellen 

Konstruktion des EDV-Systems zur Realisierung der Transaktionen und der Datenbanken mit 

konkreten Informationstechnologien. Test des Systems. 

Test 



Seite 24

Organisation der Phasenfreigabe - „Einführung“ 

Planung der Einführung 

Fall-back Plan 

Sachmittelkonzept 

Schulungskonzept Datenübern.konzept 

Vorproduktivsystem 

Set up preproduction 

einrichten 

system 

Syst. Parameter einst. 

Schnittstellenprog. erst. 

Datenmigr.prog. erst. 

Organisationskonzept 

finalisieren 

Prozesse 

Org.struktur/ 

Stellenplan 

Aufgaben 

Formularwesen 

Ausfallplan 

Batchjobs einricht. 

Berechtigungen einricht. 

Integrationstest 

im vorprod. Sys. Testfälle Testergebnisse 

Einführung vorbereiten 

Planung Stammdatenübern. 

Dokumentation finalisieren 

Systemdoku. 

Review 

Test 

Stammdatenerfassung 

Schulungen durchf. 

Organisationsdoku. 


final. 

Plan. Bewegungsdatenübern. Sachmittel inst. Backup-Konzept 



Seite 25

Organisation der Phasenfreigabe - „Einführung“ 

Kontrolle Einführungsplan 

Sachmittel 

Backup-Konzept 

Simulation Einführung 

Stammdatenübernahme 


Ausfallplan 

Beweg.datenübernahme 

Review 

Systemeinführung 

Produktivsystem 

ausprägen 

Schnittstellen 

Tabellen 

Berechtigungen 

Daten-Migration Integrationstest 

Bewegungsdaten 

Stammdaten 

Kontrolle 

Letzter Integrationstest im prod. Sys. 

Testfälle 

Testergebnisse 

Systemübergabe an Betrieb (RUN) 

Systemdoku. 

Organisationsdoku. 

Systemfreigabe 

Produktivbetrieb 

Operating/ 

Monitoring 

Review 

Hotline 

(Onsite)- 

Support 

Backup 

Weiterentwicklungsantrag 



Seite 26

Prüfmassnahmen im Rahmen der analytischen Qualitätssicherung 

Qualitätsprüfungsmassnahmen 

Review 

Test 

Audit 

internes 

Review 

externes 

Review 

interner 

Test 

externer 

Test 

externer 

Verfahrensaudit 

externer 

Führungsaudit 

AN AG AN AG AG AG 

AG = Auftraggeber; AN = Auftragnehmer 



Seite 27

Prüfmassnahmen im Rahmen der analytischen Qualitätssicherung – 

Auftragnehmer Review/Test 

• Hier geht es darum zu prüfen, 

– ob das Design-Produkt formal konsistent ist 

– ob das Design-Produkt inhaltlich bedürfnisgerecht ist 

• Die Überprüfung wird auf den Design-Produkten durchgeführt, die gemäss 

Vorgehensmodell für die jeweilige Projektphase vorgeschrieben sind 

• Vor jedem externen Review/Test (mit Auftraggeber) findet ein interner Review Test 

(auf Ebene Auftragnehmer) statt. 



Seite 28


Auftraggeber Review/Test 

• Hier geht es darum zu prüfen, 

– ob das Design-Produkt inhaltlich bedürfnisgerecht ist. 

Dies setzt formale Konsistenz voraus, für das der Auftragnehmer die Verantwortung 

übernimmt. 

• Die Überprüfung wird auf den Design-Produkten durchgeführt, die gemäss 

Vorgehensmodell für die jeweilige Projektphase für den externen Review 

vorgeschrieben sind 

• Die Überprüfung findet durch ein unabhängiges Review-Team statt, welches nicht 

im Projekt engagiert ist. Dieses Review Team wird vom Auftraggeber-Projektleiter 

organisiert. 



Seite 29


Generelle Teststufen 

6 

Abnahmetest 

(„Probebetrieb“) 

5 

Anwendertest 

(„Akzeptanztest“) 

4 

Systemtest 

(„Integrationstest“) 

3 

2 

Applikationstest 

(„Kettentest“) 

Transaktions-Einzeltest 

(„Einzeltest“ f. logische Transakt.) 

Programmierung 

läuft 

parallel 

1 

Komponenten-Einzeltest 

(„Einzeltest“ für Service-Funktion) 



Seite 30


Generelle Teststufen 

Teststufe 

1) 

Komponentenein 

zeltest 

2) 

Transaktionseinz 

eltest 

3) 



4) 

Systemtest 

(„Integrationstest 

“) 

5) 

Anwendertest 


6) 

Abnahmetest 


Testgegenstand 

Funktionieren 

einer 

Servicefunktion 

Funktionieren 

einer logischen 

Transaktion 

Funktionieren von 

Transaktionsablauf 

folgen 

Funktionieren des 

Gesamtsystems 

Konformität zur 

Spezifikation aus 

Systemdesign 

Bewährung im 

realen Betrieb 

Durchführender 

Komponentenentw 

ickler 

(Programmierer) 

Softwareentwickler 

(Programmierer) 

Testspezialist 


Anwender 

Anwender 

Dummies 

(„Stubs“) 

Erlaubt:: 

aufgerufene 

Servicefunktionen 

Erlaubt:: 

aufgerufene 


Erlaubt:: 

Aufgerufene 


und 

angesprungene 

Transaktionen 

Nicht erlaubt: die 

Programmierung 

muss vollständig 

abgeschlossen 

sein 

Nicht erlaubt: wie 

4) 

Nicht erlaubt: wie 

4) 

(Test-) 

Konfiguration 

Auf eine 

Komponente 

bezogen 

Auf eine logische 

Transaktion 

bezogen 

Auf eine 

Applikation (und 

die durch 

Transaktionssprün 

ge erreichbaren 

benachbarten log. 

Transaktionen) 

bezogen 

Auf alle 

Applikationen des 

Projektes bezogen 

Wie 4) 

(in produktiver 

Umgebung) 

Testfälle und - 

daten 

Durch 

Komponentenentw 

ickler 

Durch 

Softwareentwickler 

Durch 


aufbauend auf 2) 

Testfälle aus 2) 

und 3) werden 

abgefahren 

Durch Anwender 

(in produktiver 

Umgebung) 



Seite 31


Generelle Teststufen Fall Standardsoftware 

6 

Abnahmetest 


5 

4 

Anwendertest 


Systemtest 

(„Integrationstest“) 

Zuerst ohne 

Schnittstellen; 

Zuletzt mit allen 

Schnittstellen zu 

Fremdsystemen 

3 



2 

Transaktions-Einzeltest 

(„Einzeltest“ f. logische Transakt.) 

1 

Komponenten-Einzeltest 

(„Einzeltest“ für Service-Funktion) 



Seite 32


Auftraggeber Audit 

• Verfahrensaudit 

Spontane Überprüfung durch extern, die feststellt, ob im Projekt verfahrenskonform 

gemäss Vorgehensmodell gearbeitet wird. 

Gegenstand der Prüfung ist Prozesskonformität. 

• Projektführungsaudit 

Spontane Überprüfung durch extern, die feststellt, ob das Projekt seine Ziele im 

Spannungsfeld 

– Kosten 

– Termine 

– Nutzen (Leistungsumfang) 

– erreicht. 

Kosten des Projektes 

– Gegenstand der Prüfung ist die Zielerreichung. 

Zeit des Projektes 

Nutzen des Design- 

Produktes 

(Leistungsumfang) 



Seite 33


Auftraggeber Audit 

• Der Audit kommt üblicherweise unangekündet, d.h. spontan. 

• Er wird durch die Auftraggeber-Organisation initiiert. 

• Meistens wird er durch eine unabhängige dritte Partei (z.B. Beratungsfirma) 

durchgeführt. 

• Jedes grössere Projekt wird regelmässig auditiert (alle 6 bis 12 Monate). 

• Jeder Audit analysiert und bewertet die Projektsituation und schlägt konkrete 

Korrekturmassnahmen vor, die durch die Projektleitung umgesetzt werden. 

Kein Grossprojekt ohne Audits. 



Seite 34

Konstruktive Qualitätssicherung – ISO 9001 

• Die ISO 9000‘er Serie ist ein Qualitätssystem-Standard der International Standards 

Organisation, Genf, welche auf alle Produkte, Dienstleistungen oder Prozesse 

generell angewendet werden kann. 

• ISO 9001 regelt spezifisch die Produkt- resp. Dienstleistungserstellung in einer 

Zwei-Parteien-Vertragsbeziehung: 

„ISO 9001 defines the model for a quality system when a contractor demonstrates 

the capability to design, produce, and install products or services.“ 



Seite 35

Konstruktive Qualitätssicherung – ISO 9001 

Ziel: 

- Regelung des Auftraggeber-Auftragnehmerverhältnisses 

(Zwei-Parteien-Vertragsbeziehung) 

- „Selbst-Zwang“ des Auftragnehmers zur Qualitätsorientierung 

Vorgehen: 

Definition des 

Entwicklungsproz 

esses (Vorgehen, 

Ergebnisse, 

Rollen,...) 


Konfigurationsmanagements 

zwecks Nachweisführung 

(Verwaltung von Versionen 

und Änderungsanträgen an 

Ergebnissen) 


Qualitätsmanageme 

ntsystems 

(Institutionelle 

Verankerung in der 

Unternehmung) 

Zertifizierung nach der 

ISO 9000 Serie 

Offenlegung gegenüber 

Kunde 

Regelmässige 

Verfahrensaudits 



Seite 36

Konstruktive Qualitätssicherung – SEI-Process-Maturity-Schema* 

• Ziel: 

Bewertung der Leistungsfähigkeit von Auftragnehmern in der Informationssystem- 

Entwicklung 

• Vorgehen: 

Analyse und Klassifikation des Lieferanten in einen der folgenden 5 Reifegrade 

– 1: Chaotischer Prozess 

– 2: Wiederholbarer Prozess 

– 3: Definierter Prozess 

– 4: Kontrollierter Prozess 

– 5: Optimierter Prozess 

*Gem. Humphrey, SEI, Carnegie Mellon University 



Seite 37

Konstruktive Qualitätssicherung – SEI-Process-Maturity-Schema 

• Reifegrad 1 – „Chaotischer Prozess“: 

Chaotischer ‚ad hoc‘ Entwicklungsprozess; 

„Over-Commitment“ des Lieferanten; 

„Stars“ dominieren Projekte 

• Reifegrad 2 – „Wiederholbarer Prozess“: 

Wiederholbarer Entwicklungsprozess; 

nicht dokumentiert; Tradition; 

basiert auf Erfahrungswissen („... haben es schon immer so gemacht“). 

• Reifegrad 3 – „Definierter Prozess“: 

Entwicklungsprozess (i.S. eines Vorgehensmodells) ist voll und 

konsistent definiert und wird auch so entsprechend angewendet. 

Gem. Humphrey, SEI, Carnegie Mellon University 



Seite 38

Konstruktive Qualitätssicherung – SEI-Process-Maturity-Schema 

• Reifegrad 4 – „Kontrollierter Prozess“: 

Entwicklungsprozess wird permanent in Projekten gemessen, um 

quantitative Erfahrungszahlen zu ermitteln, die in nächsten Projekten 

als Grundlage für die Planung angewendet werden können. 

• Reifegrad 5 – „Optimierter Prozess“: 

Definierter, kontrollierter Entwicklungsprozess wird permanent 

(zwischen Projekten) optimiert und gemessen. 

Ob die Optimierung erfolgreich war, lässt sich an den gemessenen quantitativen 

Erfahrungszahlen ermitteln. 

Gem. Humphrey, SEI, Carnegie Mellon University 



Seite 39

Konstruktive Qualitätssicherung - Project Management Maturity Model 

(PMMM) 

Level 1 

Level 2 

Common 

Processes 

Level 3 

Singular 

Methodology 

Level 4 

Benchmarking 

Basic Knowledge Process Definition Process Control Process Improvement 

Level 5 

Continuous 

Improvement 

Feedback 

Common 

Language 

Quelle: Kerzner, Project Management 



Seite 40

Konstruktive Qualitätssicherung - Project Management Maturity 

Model (PMMM) 

• Level 1 - Common Language: 

In this level, the organization recognizes the importance of project management 

and the need for a good understanding of the basic knowledge on project 

management, along with the accompanying language/terminology 

• Level 2 - Common Processes: 

In this level, the organization recognizes that common processes need to be 

defined and developed such that successes on one project can be repeated on 

other projects. Also included in this level is the recognition that project management 

principles can be applied to and support other methodologies employed by the 

company. 

• Level 3 - Singular Methodology: 

In this level, the organization recognizes the synergistic effect of combining all 

corporate methodologies into a singular methodology, the center of which is project 

management. The synergistic effects also make process control easier with a 

single methodology than with multiple methodologies. 




Seite 41

Konstruktive Qualitätssicherung - Project Management Maturity Model 

(PMMM) 

• Level 4 - Benchmarking: 

This level contains the recognition that process improvement is necessary to 

maintain a competitive advantage. Benchmarking must be performed on a 

continuous basis. The company must decide whom to benchmark and what to 

benchmark. 

• Level 5 - Continuous Improvement: 

In this level, the organization evaluates the information obtained through 

benchmarking and must then decide whether or not this information will enhance 

the singular methodology. 




Seite 42

Transformation - Information Management

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?