Fortschrittskontrolle von Softwareentwicklungsprojekten. Eine Wirkungsanalyse von Gestaltungsmaßnahmen

Inhaltsverzeichnis

Abkürzungsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

1. Einleitung
1.1 Problemstellung
1.2 Ziel der Arbeit
1.3 Vorgehensweise

2. Grundlagen
2.1 Definitionen zentraler Begriffe
2.1.1 Softwareentwicklungsprojekt
2.1.2 Projekterfolg
2.1.2.1 Planungstreue
2.1.2.2 Gebrauchsgerechtigkeit
2.1.2.3 Effizienz
2.1.3 Rahmenbedingungen von Softwareentwicklungsprojekten
2.2 Klassifizierung von Arten der Kontrolle
2.2.1 Formale Arten der Kontrolle
2.2.1.1 Verhaltenskontrolle
2.2.1.2 Fortschrittskontrolle
2.2.2 Informale Arten der Kontrolle
2.2.2.1 Gruppenkontrolle
2.2.2.2 Selbstkontrolle

3. Charakteristika der Fortschrittskontrolle in der SW-Entwicklung

3.1 Ziele der Fortschrittskontrolle
3.2 Voraussetzungen der Fortschrittskontrolle
3.3 Probleme der Fortschrittskontrolle
3.4 Gestaltung der Fortschrittskontrolle

4. Art der Abgrenzung von Kontrolleinheiten
4.1 Output- bzw. produktorientierte Abgrenzung der Kontrolleinheiten
4.2 Input- bzw. prozessorientierte Abgrenzung der Kontrolleinheiten
4.3 Wirkungshypothesen im Hinblick auf Projekterfolg

5. Terminierung der Fortschrittskontrolle
5.1 Häufigkeit
5.2 Regelmäßigkeit
5.3 Wirkungshypothesen im Hinblick auf Projekterfolg

6. Methoden zur Bestimmung des Fortschrittsgrades
6.1 Aufgabenorientierte Methoden
6.2 Aufwandsorientierte Methoden
6.3 Outputorientierte Methoden
6.4 Wirkungshypothesen im Hinblick auf Projekterfolg

7. Methoden zum Vergleich der Plan-/Istwerte
7.1 Terminorientierter Plan-/Ist-Vergleich
7.2 Kostenorientierter Plan-/Ist-Vergleich
7.3 Wirkungshypothesen im Hinblick auf Projekterfolg

8. Methoden der Fortschrittsprognose
8.1 Restkostenbestimmung
8.2 Restzeitbestimmung
8.3 Wirkungshypothese im Hinblick auf Projekterfolg

9. Kontrollorgane
9.1 Zentralisierte Fortschrittskontrolle
9.2 Dezentralisierte Fortschrittskontrolle
9.3 Wirkungshypothesen im Hinblick auf Projekterfolg

10.Fazit

Literaturverzeichnis

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abb. 2-1: Regelkreismodell eines Softwareentwicklungsprojekts

Abb. 2-2: Projekterfolgsfaktoren

Abb. 2-3 : Das Magische Dreieck

Abb. 2-4 : Modell der zielorientierten Gestaltung

Abb. 3-1: Integrierte Betrachtung von Planung, Kontrolle und Steuerung

Abb. 3-2 : Der Fertigstellungsgrad zu verschiedenen Zeitpunkten

Abb. 3-3 : Die Gestaltung der Fortschrittskontrolle

Abb. 4-1 : Die Gestaltung der Fortschrittskontrolle: Art der Abgrenzung von Kontrolleinheiten

Abb. 5-1 : Die Gestaltung der Fortschrittskontrolle: Terminierung der Fortschrittskontrolle

Abb. 5-2: Kontrollkosten

Abb. 6-1 : Die Gestaltung der Fortschrittskontrolle: Methoden zur Bestimmung des Fortschrittsgrades

Abb. 6-2: Earned-Value-Analyse

Abb. 7-1: Die Gestaltung der Fortschrittskontrolle: Methoden zum Vergleich der Plan-/Istwerte

Abb. 7-2 : Der prinzipielle Kontrollprozess

Abb. 7-3 : Kostenorientierte Methoden zum Plan-/Ist-Vergleich

Abb. 8-1 : Die Gestaltung der Fortschrittskontrolle: Methoden der Fortschrittsprognose

Abb. 8-2: Meilenstein-Trendanalyse

Abb. 9-1 : Die Gestaltung der Fortschrittskontrolle: Kontrollorgane

Tabellenverzeichnis

Tab. 6-1: Die wichtigsten Kennzahlen der Earned-Value-Analyse

1. Einleitung

1.1 Problemstellung

Seit 20 Jahren existiert der Begriff der „Softwarekrise“.¹ Dieser Begriff bezeichnet u. a. den Umstand, dass die Produktivität von Software in den letzten 20 Jahren nur margina- le Verbesserungen erreichte. Der Produktionsprozess dauert häufig wesentlich länger als geplant und die geplanten Kosten werden oft überschritten. Wenn das Produkt dann fertig ist, entspricht es nicht den gestellten Anforderungen hinsichtlich Funktionalität oder Qualität.

Laut einer Studie der Standish Group von 2002 sind 66 % aller durchgeführten Soft- wareentwicklungsprojekte nicht erfolgreich gewesen.² Auch wenn sich nach dieser Stu- die der Anteil der erfolgreichen Softwareentwicklungsprojekte zwischen 1994 und 2002 bereits von 16 % auf 34 % mehr als verdoppelt hat,³ wächst auch künftig die Bedeutung des Projekterfolges für die Beziehung zwischen Auftraggeber und Auftragnehmer.⁴

Eskalation⁵ kommt bei Softwareentwicklungsprojekten häufig vor. Eine empirische Studie von Keil, Mann und Rai bestätigt diese Behauptung mit dem Ergebnis, dass 30-40 % aller untersuchten Softwareentwicklungsprojekte in einem gewissen Umfang eskalierten.⁶ Diese Studie stellt auch einen Bezug zwischen Eskalation und Misserfolg her. Mehr als 75 % der nicht-eskalierten Projekte wurden erfolgreich abgeschlossen, dagegen lag der Anteil der erfolgreich abgeschlossenen Projekte, die eskaliert waren, unter 25 %. Die Abweichung von dem Budget- und Terminplan lag bei eskalierten Pro- jekten bei ca. 100 %, bei nicht-eskalierten Projekten dagegen nur bei ca. 20 %.

Die Entwickler zu fragen, wie weit sie sind, ist vergebene Mühe, da die Antwort stets so vage wie die Frage ist.⁷ Ein Softwareentwickler wird sich so viel Zeit und Geld nehmen, wie ihm gegeben wird.⁸ Deswegen ist Kontrolle ein wichtiger aber in vielen Fällen ver- nachlässigter Aspekt der Softwareentwicklung.⁹ Die Leistung und das Verhalten der Mitarbeiter wurde bereits im Altertum kontrolliert. Schon bei den Aufzeichnungen über wirtschaftliche Vorgänge der Sumerer, Babylonier, Ägypter, Phönezier, Karthager, Griechen und Römer wurden Merkmale gefunden, die Rückschlüsse auf eine Kontroll- funktion zulassen.¹⁰

Kontrolle wird als Teil des institutionellen Projektmanagements oft als unwichtig und nebensächlich betrachtet und deshalb nicht konsequent durchgeführt.¹¹ Durch sie kön- nen Planabweichungen frühzeitig während der Projektlaufzeit erkannt werden. Es gibt verschiedene Formen der Kontrolle. Sie lassen sich in formale und informale Arten der Kontrolle klassifizieren.¹² Eine der formalen Kontrollarten ist die Fortschrittskontrolle, deren Schwerpunkt die Bewertung von (Teil-)Ergebnissen ist.¹³ Da Kontrollieren ein informationelles Rückkoppeln von den am Arbeitsprozess Beteiligten bis hin zur Füh- rungskraft bedeutet,¹⁴ besteht die Notwendigkeit, übergeordneten Ebenen Informationen leicht zugänglich zu machen. Diese können mit den Methoden der Fortschrittskontrolle leicht verständlich dargestellt werden. Fortschrittskontrolle ist bei Softwareentwick- lungsprojekten zwar eine komplexe Aktivität, da der Auftraggeber mehrere Ziele ver- folgt, die teilweise untereinander in Konflikt stehen,¹⁵ ohne sie ist aber ein zielorientier- tes Vorgehen nicht möglich.¹⁶

Der Erfolg eines Projektes kann nur selten wiederholt werden, da die erfolgsbeeinflus- senden Faktoren nicht bekannt oder nicht systematisch analysiert werden.¹⁷ Wie bei jeder Aktivität eines Softwareentwicklungsprojektes gilt es bei der Fortschrittskontrolle die Gestaltungsdimensionen im Hinblick auf den Projekterfolg zu analysieren. Empi- risch gesicherte Studien über die Wirkung verschiedener Gestaltungsmaßnahmen der Fortschrittskontrolle im Hinblick auf Projekterfolg existieren jedoch bisher nur verein- zelt.¹⁸

1.2 Ziel der Arbeit

Das Ziel dieser Arbeit ist die Erarbeitung begründeter Hypothesen zur Gestaltung der Fortschrittskontrolle bei Softwareentwicklungsprojekten im Hinblick auf eine Erhöhung des Projekterfolges.

Ein weiteres Ziel bildet die Systematisierung der für den Projekterfolg relevanten Gestaltungsbereiche. Durch eine systematische Analyse der einzelnen Gestaltungsbereiche soll die Komplexität der Fortschrittskontrolle reduziert werden.

1.3 Vorgehensweise

In Kapitel 2 wird zunächst eine begriffliche Basis geschaffen. Wichtige Begriffe und Konzepte, wie z. B. die Klassifizierung der Kontrollmaßnahmen oder die im Weiteren Verlauf dieser Arbeit benötigten Rahmenbedingungen eines Softwareentwicklungsprojektes, werden geklärt.

In Kapitel 3 wird zunächst auf die Fortschrittskontrolle als Ganzes näher eingegangen. Hierfür werden deren Ziele, Voraussetzungen und Probleme beschrieben. Den Abschluss dieses Kapitels bildet eine Systematisierung der Gestaltungsdimensionen der Fortschrittskontrolle.

Der Hauptteil dieser Arbeit findet sich in den Kapiteln 4-9 wieder. Diese Kapitel befas- sen sich jeweils mit einer der Gestaltungsdimensionen Art der Abgrenzung der Kon- trolleinheiten, Terminierung der Fortschrittskontrolle, Methoden zur Bestimmung des Fortschrittsgrades, Methoden zum Vergleich der Plan-/Istwerte, Methoden der Fort- schrittsprognose und Kontrollorgane. In jedem dieser Kapitel werden zunächst die mög- lichen Gestaltungsausprägungen beschrieben. Abschließend werden Wirkungshypothe- sen aufgestellt, die die Ausprägungen der jeweiligen Gestaltungsdimensionen unter be- stimmten Rahmenbedingungen in Bezug zu dem erzielbaren Projekterfolg setzen. Diese Wirkungshypothesen werden entweder durch publizierte empirische Erkenntnisse oder auf Basis von Teilerkenntnissen bzw. sachlogischen Argumenten begründet.

Im abschließenden zehnten Kapitel wird eine kurze Zusammenfassung der Ergebnisse ausgearbeitet und eine Empfehlung im Hinblick auf die Gestaltung der Fortschrittskon- trolle gegeben.

2. Grundlagen

In diesem Kapitel wird die Basis für das Verständnis der Arbeit geschaffen. In Abschnitt 2.1 werden die grundlegenden Begriffe definiert. In Abschnitt 2.2 folgt eine Klassifizierung der verschiedenen Formen der Kontrolle.

2.1 Definitionen zentraler Begriffe

2.1.1 Softwareentwicklungsprojekt

Die beiden Komponenten des Begriffes Softwareentwicklungsprojekt werden von dem Deutschen Institut für Normung e. V. (DIN) im Rahmen der Qualitätsmanagement- und Qualitätssicherungsnormen wie folgt definiert.

Softwareentwicklung umfasst alle Tätigkeiten, die zur Erzeugung eines Softwarepro- duktes¹⁹ ausgeführt werden müssen.²⁰ In der Regel finden diese Aktivitäten im Rahmen eines Projektes statt. Dabei bezeichnet ein Projekt ein Vorhaben, „das im Wesentlichen durch die Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist, wie z. B. Zielvorgabe, zeitliche, finanzielle oder andere Begrenzungen, Abgrenzungen ge- genüber anderen Vorhaben und projektspezifische Organisation“.²¹ Das Project Management Institute (PMI) versteht unter einem Projekt „a temporary endeavor undertaken to create a unique product, service, or result“.²² In der Literatur wird ein Projekt durch folgende Eigenschaften ausgezeichnet: Bedeutung, Komplexität, Umfang, Interdisziplinarität, Einmaligkeit, Neuartigkeit, Endlichkeit, finanzieller Rahmen und Risiko.²³ Bei allen Definitionen des Begriffes Projekt wird besonders betont, dass eine Einmaligkeit gegeben sein muss.²⁴ Ebenfalls wichtig ist die zeitliche Befristung. Diese zwei Merkmale tauchen in nahezu allen Definitionen des Begriffes Projekt auf.²⁵

Der Gegenstand eines Softwareentwicklungsprojektes ist demzufolge die Erzeugung von Softwareprodukten.

Um einen systematischen Ablauf der Softwareentwicklung sicherzustellen, werden die Aktivitäten innerhalb eines Softwareentwicklungsprojektes²⁶ und ihr Zusammenhang²⁷ in einem Regelkreismodell dargestellt. Schwerpunkt der vorliegenden Arbeit ist die Projektkontrolle.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2-1: Regelkreismodell eines Softwareentwicklungsprojekts²⁸

2.1.2 Projekterfolg

Im Duden wird der Begriff Erfolg als das positive Ergebnis einer Bemühung bzw. das Eintreten einer beabsichtigten und erstrebten Wirkung definiert.²⁹ Der Begriff Projekter- folg bezeichnet das Erreichen der vorgegebenen Ziele, ohne den festgelegten Zeit- und Kostenrahmen zu überschreiten.³⁰ Projekterfolg erschöpft sich jedoch nicht in der Pla- nungstreue.³¹ In Abbildung 2-2 ist dargestellt, dass für einen vollkommenen Projekter- folg auch eine hohe Gebrauchsgerechtigkeit des Produktes und eine hohe Effizienz des Prozesses notwendig sind.³² Diese drei Projekterfolgsfaktoren stehen in der Praxis im Konflikt zueinander, d. h. eine übermäßige Konzentration auf nur einen dieser Aspekte wirkt sich negativ auf die anderen aus.³³

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2-2: Projekterfolgsfaktoren³⁴

Die Gewichtung der Bedeutungen von Planungstreue, Gebrauchsgerechtigkeit und Effizienz im Hinblick auf den Projekterfolg ist abhängig von den Merkmalsausprägungen des jeweiligen Projektes.

Diese drei Projekterfolgsfaktoren werden in den nachfolgenden Abschnitten näher er- läutert.

2.1.2.1 Planungstreue

Planungstreue bezieht sich auf das Ausmaß der Abweichung der tatsächlichen Entwicklungskosten, Entwicklungszeit und Qualität von der Planung.³⁵

Die Planungstreue steht für die Umsetzung der Projektziele, die als nachzuweisende Ergebnisse und vorgegebene Realisierungsbedingungen der Gesamtaufgabe eines Projektes definiert werden.³⁶ Diese sollen aus betriebswirtschaftlicher Sicht real erfassbar sein und durch den Einsatz geeigneter Mittel angestrebt werden. Diese Sollzustände sind in Plänen festzuhalten.

In der Literatur werden Projektdauer, Projektkosten und Anforderungserfüllung als die drei wichtigsten Merkmale eines Projektes angegeben.³⁷ Dies wird durch eine empiri- sche Studie von George bestätigt. Dort wurden die Kosten (100 %), die Zeit (88 %) und die Leistungen (69 %) auf die Frage nach projektbezogenen Kennzahlen am häufigsten genannt.³⁸

In Abbildung 2-3 wird das Magische Dreieck dargestellt, welches den Zusammenhang dieser drei Merkmale beschreibt. Keins dieser drei Merkmale kann verändert werden, ohne dass es nicht mindestens ein anderes beeinflusst.³⁹

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2-3 : Das Magische Dreieck⁴⁰

Dementsprechend gliedert sich die Planungstreue in die drei Teilaspekte Termintreue, Budgettreue und Anforderungserfüllung.

Termintreue

Termintreue beschreibt das Ausmaß der Abweichung der tatsächlichen von der geplan- ten Entwicklungszeit.⁴¹ Sie kann durch das Verhältnis zwischen benötigter und geplan- ter Projektdauer beschrieben werden.⁴² Eine hohe Termintreue ist von großer strategi- scher Bedeutung für Softwareentwicklungsunternehmen,⁴³ da es bei niedriger Termintreue zu Strafkosten bzw. zu Verzögerungen von anderen Projekten kommen kann.

Dies wurde in den letzten Jahren durch empirische Studien bekräftigt. So hat eine Studie von Dölle ergeben, dass der häufigste Grund für den Einsatz von objektiven Metriken⁴⁴ die Termintreue ist.⁴⁵ Walter Dölle führt dies auf die hohe Quantifizierbarkeit dieses Kriteriums zurück.⁴⁶

Choudhury und Sabherwal haben im Jahre 2003 in einer empirischen Studie festgestellt, dass bei allen untersuchten Projekten die Einhaltung der geforderten Termine überprüft wurde.⁴⁷

Budgettreue

Analog zu der Termintreue bezeichnet die Budgettreue das Ausmaß der Abweichung der tatsächlichen von den geplanten Entwicklungskosten.⁴⁸ Sie kann durch das Verhält- nis zwischen entstandenen und geplanten Kosten beschrieben werden. Insbesondere bei Festpreisprojekten hat die Bedeutung der Budgettreue in den letzten Jahren zugenom- men, da die entstehenden Mehrkosten von dem Auftragnehmer selbst übernommen werden müssen.⁴⁹

Anforderungserfüllung

Die Anforderungserfüllung bezeichnet die Abweichung der tatsächlichen von der ge- planten Qualität und umfasst sowohl die Funktionstreue als auch die Qualitätstreue.

Die Funktionstreue beschreibt das Ausmaß der Abweichung der tatsächlich realisierten von den geplanten Funktionen der Software.⁵⁰ Sie steht also für die Erfüllung der funk- tionalen Anforderungen. Die Qualitätstreue beschreibt das Ausmaß der tatsächlich realisierten von den geplanten nicht-funktionalen Anforderungen.

Diese zwei Aspekte der Anforderungserfüllung werden in der Literatur nicht klar voneinander getrennt. So wird teilweise Qualität als Erfüllung von funktionalen Anforderungen beschrieben.⁵¹

In der empirischen Studie von Choudhury und Sabherwal hat sich herausgestellt, dass bei allen untersuchten Projekten die Anforderungserfüllung überprüft worden ist.⁵²

2.1.2.2 Gebrauchsgerechtigkeit

Die unter Planungstreue zusammengefassten Erfolgsfaktoren Zeit, Kosten und Leistung beschreiben die objektiven Aspekte eines Softwareentwicklungsprojektes.⁵³ Zusätzlich dazu wird der Projekterfolg von subjektiven Faktoren der Auftraggeber, die nicht objektiv messbar sind, beeinflusst.⁵⁴

Der Auftraggeber ist an einem Produkt interessiert, das den beabsichtigten Zweck erfüllt, ihn also bei der Lösung seiner Aufgaben unterstützt.⁵⁵ Das Ausmaß der Erfüllung dieser subjektiven Anforderung wird als Gebrauchsgerechtigkeit bezeichnet. Dieses Ausmaß ist hoch, wenn die erlebte Bedürfnisbefriedigung dem eigenen Anspruchsniveau, also den Erwartungen, entspricht.⁵⁶

Die Gebrauchsgerechtigkeit hat einen großen Einfluss auf die Erfolgsbewertung eines Softwareentwicklungsprojektes, auch wenn er nicht bewusst wahrgenommen wird.⁵⁷ Eine als hoch empfundene Gebrauchsgerechtigkeit schafft einen positiven Eindruck beim Auftraggeber und ist damit die Voraussetzung für weitere Projekte ist.⁵⁸

2.1.2.3 Effizienz

Der Duden setzt die Effizienz mit der Wirtschaftlichkeit gleich.⁵⁹ Die Effizienz definiert sich aus dem Verhältnis zwischen dem erzielten Ergebnis und den eingesetzten Mitteln.⁶⁰ Es ist also das Verhältnis zwischen Input und Output.

In der Literatur wird Effizienz oft mit den Worten „die Dinge richtig tun“ beschrieben.⁶¹ Dies steht im Gegensatz zu der Gebrauchsgerechtigkeit, wobei „die richtigen Dinge getan“ werden sollen.

2.1.3 Rahmenbedingungen von Softwareentwicklungsprojekten

Gestaltungsempfehlungen, -wirkungen und -ziele für Projekte i. Allg. werden von Rahmenbedingungen beeinflusst, die nicht unmittelbar verändert werden können (siehe Abbildung 2-4).⁶² Softwareentwicklungsprojekte finden meist in einer turbulenten Umgebung statt, d. h. in einer Umgebung in der u. a. die Kundennachfrage, das Konkurrenzverhalten und die Technologieentwicklung nicht stabil sind.⁶³

Im Folgenden werden die für die Hypothesen im Hauptteil der Arbeit relevanten Rahmenbedingungen beschrieben. Sie lassen sich in zwei Kategorien einteilen, nämlich in die Rahmenbedingungen bzgl. des Umfeldes eines Softwareentwicklungsunternehmens und die Rahmenbedingungen bzgl. der Entwicklungsaufgabe.⁶⁴

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2-4 : Modell der zielorientierten Gestaltung⁶⁵

Merkmale zur Charakterisierung des Umfeldes

Die Elemente des Umfeldes sind die Kunden, die Lieferanten, die Wettbewerber sowie Kooperationspartner, die Technologie und die rechtlichen Rahmenbedingungen.⁶⁶ Zwei der Rahmenbedingungen bzgl. des Umfeldes sind die Dynamik und die Unsicherheit des Unternehmensumfeldes.

Unter Dynamik ist die Geschwindigkeit sowie das Ausmaß der Veränderungen des Umfeldes zu verstehen.⁶⁷ Bei der Softwareentwicklung weist das Umfeld in der Regel eine hohe Dynamik auf.⁶⁸ Einerseits spielt bei Standardsoftwareherstellern die Weiterentwicklung von Wettbewerbsprodukten und die Entwicklung der Nachfrage eine wichtige Rolle. Andererseits fallen bei Individualsoftwareherstellern die häufigen Veränderungen der Kundenanforderungen ins Gewicht.

Die Unsicherheit ist ein Maß für die Verfügbarkeit von Informationen über das Umfeld.⁶⁹ Die Unsicherheit des Umfeldes ist hoch, wenn sich z. B. die Prognostizierbarkeit der technologischen Entwicklung als schwierig erweist.

Merkmale zur Charakterisierung der Entwicklungsaufgabe

Die hier relevanten Charakteristika der Entwicklungsaufgabe sind die Komplexität, die Unsicherheit und Dynamik ebendieser.

Die Komplexität der Entwicklungsaufgabe beschreibt die Anzahl der zu berücksichti- genden Elemente sowie deren Interdependenzen untereinander.⁷⁰ Hierzu gehören die zu entwickelnden Einheiten, die zu treffenden Entscheidungen über die Gestaltung des Softwareproduktes und die dabei zu berücksichtigenden Informationen.⁷¹ Bei Software- entwicklungsprojekten ist in der Regel von einer hohen Komplexität auszugehen.

Die Unsicherheit einer Entwicklungsaufgabe beschreibt die Präzisierbarkeit der an das zu entwickelnde Softwareprodukt gestellten funktionalen und nicht-funktionalen Anfor- derungen.⁷² Eine geringe Unsicherheit bedeutet, dass die festgelegten Anforderungen nicht nur leicht präzisierbar sondern auch vollständig sind. Softwareentwicklungspro- jekte können eine hohe Unsicherheit, z. B. bei der Entwicklung von Software für neuar- tige Anwendungen, aber auch eine geringe Unsicherheit, z. B. bei der Entwicklung von Software zur Automatisierung von gegebenen geschäftlichen Prozessen, aufweisen.

Eine Entwicklungsaufgabe weist eine hohe Dynamik auf, wenn während der Projekt- laufzeit oft starke Veränderungen der, an das zu entwickelnde Softwareprodukt, funkti- onalen und nicht-funktionalen Anforderungen auftreten.⁷³ Die Ursachen können z. B. fehlende Anforderungen, Änderungen des zu unterstützenden Prozesses oder Gesetzes- änderungen sein.

2.2 Klassifizierung von Arten der Kontrolle

Kontrolle ist ein Lehnwort aus dem Französischen, abgeleitet von „contre rôle“ und bedeutet wörtlich übersetzt „Gegenprobe“.⁷⁴ Ein Projekt ist unter Kontrolle, wenn während des Projektverlaufes gewährleistet werden kann, dass die Abweichungen von den Plänen so minimal wie möglich gehalten werden.⁷⁵

In der Literatur wird zum Teil unter dem Begriff Kontrolle nur die Fortschrittskontrolle verstanden.⁷⁶ In diesem Abschnitt werden vier Kontrollarten voneinander abgegrenzt, wobei die Fortschrittskontrolle nur eine davon ist. Diese vier Arten der Kontrolle werden in formale und informale Arten der Kontrolle eingeordnet.⁷⁷ In der Literatur existieren auch andere Klassifikationen, wie z. B. die Klassifikation von Henderson und Lee in managerial und team member control.⁷⁸

Ravichandran und Rai arbeiteten 1994 heraus, dass die Wahl der Kontrollart den Pro- jekterfolg beeinflusst.⁷⁹ Nach Eisenhardt bestimmen die Eigenschaften eines Projektes, welche Art der Kontrolle angemessen ist.⁸⁰ In dieser Arbeit wird davon ausgehend die Gestaltung einer bestimmten Art der Kontrolle, nämlich der Fortschrittskontrolle analy- siert. Dabei wird der Standpunkt vertreten, dass eine Festlegung auf eine einzelne Art der Kontrolle nicht zwingend notwendig ist. Eine Kombination verschiedener Arten der Kontrolle ist möglich,⁸¹ wobei die Gewichtung der einzelnen Kontrollarten abhängig von den Eigenschaften des jeweiligen Projektes zu bestimmen ist.⁸² Haslinger, Meßerer und Wolters haben 1975 die Behauptung aufgestellt, dass Kontrolle, ebenso wie Pla- nung und Organisation, flexibel gehalten werden muss, um wirkungsvoll zu sein.⁸³ In den empirischen Studien von Kirsch bzw. von Choudhury und Sabherwal hat sich dar- über hinaus herausgestellt, dass in der Praxis die gewählten Arten der Kontrolle wäh- rend des Projektverlaufes häufig verändert werden.⁸⁴

Zu jeder Kontrollart gehört auch ein entsprechendes Vergütungssystem.⁸⁵ Hierbei entscheidet der Kontrollierende, abhängig von der gewählten Art der Kontrolle, wie der Kontrollierte für seine Leistung honoriert werden soll. Der Kontrollierende ist in der Regel der Projektleiter, da er der Hauptaufgabenträger des Projektes ist.⁸⁶

2.2.1 Formale Arten der Kontrolle

Die formalen Kontrollarten sind die behavior control bzw. Verhaltenskontrolle und die outcome control bzw. Fortschrittskontrolle.⁸⁷ Diese beiden formalen Kontrollarten wer- den bei Nidumolu und Subramani unter dem Begriff „process approach“ zusammenge- fasst.⁸⁸

Der Einsatz von formalen Arten der Kontrolle gewährleistet, dass Fehlentscheidungen von verantwortlichen Personen, die nur auf deren persönliche Urteile und Erfahrungs- werte zurückzuführen sind, vermieden werden.⁸⁹ In der Literatur werden die formalen Arten der Kontrolle auch als Strategien zur Leistungsbewertung beschrieben.⁹⁰

2.2.1.1 Verhaltenskontrolle

In der Verhaltenskontrolle werden bestimmte Regeln und Vorgehensweisen definiert, deren Einhaltung zu höherem Projekterfolg führt.⁹¹ Beispielsweise stellt die Vorschrift, sich an eine konkrete methodische Vorgehensweise zur Softwareentwicklung zu halten, eine Möglichkeit dar, Verhaltenskontrolle einzusetzen.⁹² Durch diese Kontrollart wird ein direkter Einfluss auf den Entwicklungsprozess ausgeübt.⁹³ Die Mitarbeiter werden

durch entsprechende Vergütung dazu gebracht, diese Regeln und Vorgehensweisen einzuhalten.⁹⁴ Die Vergütung ist bei dieser Art der Kontrolle besonders wichtig, da Verhaltensregeln bei den Mitarbeitern nicht sehr beliebt sind.⁹⁵

Je öfter ein bestimmtes Aufgabemuster wiederholt wird, desto leichter können Regeln und Vorgehensweisen bestimmt werden, die zu einen höheren Projekterfolg führen.⁹⁶ Die Schwierigkeit das Verhalten auf Einhaltung der Regeln zu prüfen sinkt entsprechend dem Grad der Definierbarkeit des Verhaltens.⁹⁷

Eine empirische Studie, bei der Eisenhardt 54 Unternehmen untersucht hat, ergab, dass bei

- hoher Programmierbarkeit der Aufgabe und/oder
- hoher Messbarkeit des Verhaltens und/oder
- hohen Kosten der Messung des Fortschritts und/oder
- hoher Ungewissheit des Ergebnisses

die Verhaltenskontrolle als eingesetzte Kontrollart zu empfehlen ist.⁹⁸

2.2.1.2 Fortschrittskontrolle

Bei der Fortschrittskontrolle werden die gewünschten Projektziele bzw. -ergebnisse definiert und kontrolliert.⁹⁹ Sie ist dann anzuwenden, wenn die Erfüllung der Projektzie- le bzw. -ergebnisse leicht bewertet werden kann.¹⁰⁰ Fortschrittskontrolle ist ein Kom- promiss zwischen der reinen Ergebnisüberwachung und der permanenten Überwa- chung.¹⁰¹ Hierbei werden die (Zwischen-)Ergebnisse betrachtet ohne den jeweiligen

Entwicklungsprozess zu berücksichtigen.¹⁰² Die Vergütung der Mitarbeiter erfolgt hier entsprechend dem Grad der Erreichung der gesetzten Ziele.¹⁰³

Die Charakteristika dieser Art der Kontrolle werden in Kapitel 3 näher erläutert.

2.2.2 Informale Arten der Kontrolle

Informale Arten der Kontrolle basieren auf sozialpsychologischen Aspekten.¹⁰⁴ Zu ih- nen gehören die clan control bzw. Gruppenkontrolle und die self control bzw. Selbst- kontrolle.¹⁰⁵

2.2.2.1 Gruppenkontrolle

Bei dieser Kontrollart findet die Kontrolle innerhalb einer Gruppe von Einzelpersonen statt.¹⁰⁶ D. h. Kontrollierender und Kontrollierter sind Mitglieder derselben Gruppe. Gemeinsame Projektziele und -ergebnisse werden gruppenintern besprochen. Vorgehensweisen, die aufgrund von gemeinsamen Erfahrungen als zweckmäßig erscheinen, werden unterstützt.¹⁰⁷ Die Differenzen zwischen den Zielen der Kontrollierenden und denen der Kontrollierten schwinden damit.¹⁰⁸

Die Mitglieder dieser Gruppe sind aufeinander angewiesen, um die Gruppenziele zu erreichen.¹⁰⁹ Daher ist eine explizite Vergütung bei der Gruppenkontrolle nicht zwingend notwendig.¹¹⁰

Gruppenkontrolle ist von Nutzen, wenn alle Mitglieder der Gruppe bereit sind, sich zu integrieren und die gemeinsam gesetzten Ziele zu verfolgen.¹¹¹ Dabei ist von einer Anpassung des Verhaltens der Gruppenmitglieder auszugehen.¹¹²

2.2.2.2 Selbstkontrolle

In der Selbstkontrolle werden sowohl die Projektziele und -ergebnisse als auch die Ver- haltensregeln, mit denen sie erreicht werden sollen, vom Kontrollierten selbst defi- niert.¹¹³ Die Erreichung dieser Ziele und die Einhaltung des vordefinierten Verhaltens werden vom Kontrollierten selbst überwacht,¹¹⁴ d. h. Kontrollierender und Kontrollier- ter sind dieselbe Person. Voraussetzungen für die Selbstkontrolle sind die Fähigkeiten, Emotionen unter Kontrolle zu halten und negative Aktivitäten zu vermeiden, beispiels- weise wenn unter Stress gearbeitet werden muss oder mit Anfeindungen von anderen zu rechnen ist.¹¹⁵

Mitarbeiter, die diese Art der Kontrolle verwenden, sind durch das ihnen geschenkte Vertrauen motivierter ihre Ziele zu erreichen.¹¹⁶

Diese Art der Kontrolle ähnelt den beiden formalen Kontrollarten.¹¹⁷ Die Erreichung der Projektziele und -ergebnisse sowie die Einhaltung der Verhaltensregeln werden hierbei auch kontrolliert. Dies geschieht jedoch informal von dem Kontrollierten selbst und nicht formal von einem Außenstehenden. Hinzu kommt, dass die Vergütung von dem Kontrollierten selbst erfolgen muss.¹¹⁸

3. Charakteristika der Fortschrittskontrolle in der SW-Entwicklung

Ziel dieses Kapitels ist es, die Charakteristika der Fortschrittskontrolle zu beschreiben und daraus eine Systematik der Gestaltungsbereiche zu entwickeln.

3.1 Ziele der Fortschrittskontrolle

Das Ziel der Fortschrittskontrolle ist es, den realisierten Leistungsfortschritt, d. h. den Fortschrittsgrad, zu bestimmen, ihn mit dem geplanten Leistungsfortschritt zu vergleichen und Abweichungen zwischen den beiden Größen aufzudecken.¹¹⁹ Die Fortschrittskontrolle soll während der gesamten Projektlaufzeit erforderliche Steuerungsmaßnahmen unterstützen und die Entscheidungsfindung über die Fortführung des Projektes erleichtern, um Eskalation zu verhindern.¹²⁰

Außerdem gehört zu den Aufgaben der Fortschrittskontrolle die fortlaufende Überprüfung der operationalisierten Teilziele des Projektes und der Planungsprämissen auf Validität überprüfen.¹²¹ Hierzu sollen Kosten-, Termin- und Anforderungsabweichungen festgestellt werden.¹²² Fortschrittskontrolle ist also im Hinblick auf Projekterfolg primär für den Aspekt der Planungstreue relevant.

Aus dem regelmäßigen Vergleich der tatsächlichen mit den geplanten Werten entstehen bei der Fortschrittskontrolle zudem Informationen, die sowohl zu vorbeugenden als auch zu korrigierenden Maßnahmen für das weitere Vorgehen führen.¹²³ Das heißt die Ziele der Fortschrittskontrolle sind nicht nur vergangenheitsbezogen, also zur Prüfung der erledigten Aktivitäten und zur frühzeitigen Erkennung von Abweichungen, sondern auch zukunftsbezogen, also zum Verhindern von unnötigen Kosten und zur Erkennung von voraussehbaren Abweichungstendenzen.¹²⁴

[...]

---

¹ Vgl. zu diesem Absatz Campagna /Projektmanagement/ 1

² Vgl. Larkowski /Standish/ 1

³ Vgl. Larkowski /Standish/ 1

⁴ Vgl. Blume /Kostenmanagement/ 607

⁵ Eskalation liegt vor, wenn ein Plan weiterhin verfolgt wird, obwohl es negative Informationen, wie Abweichungen von dem Plan bzgl. Kosten, Zeit und/oder Leistung, über den aktuellen Status des Softwareentwicklungsprojektes gibt. Dies kommt bei Softwareentwicklungsprojekten häufig vor. Vgl. Juliusson /Escalation/ 1, Keil, Mann, Rai /SW-Projects/ 634 und Mellis /Projektmanagement/ 233

⁶ Vgl. zu diesem Absatz Keil, Mann, Rai /SW-Projects/ 648-649

⁷ Vgl. Sneed /Software Management/ 223

⁸ Vgl. Parkinson /Law/ 2

⁹ Vgl. Choudhury, Sabherwal /Portfolios/ 291, Eisenhardt /Control/ 134 und Henderson, Lee /Control/ 757

¹⁰ Vgl. Littkemann, Schewe /Interne Kontrollsysteme/ 1

¹¹ Vgl. Jenny /Projektmanagement/ 1 und 62

¹² Vgl. Kirsch /Control Modes/ 217

¹³ Vgl. Kirsch /Control Modes/ 217

¹⁴ Vgl. Balzert /Software-Management/ 220 und Dworatschek /Management/ 16

¹⁵ Vgl. Kirsch /Systems Development/ 1-2

¹⁶ Vgl. Burghardt /Projektmanagement/ 327

¹⁷ Vgl. Mellis, Stelzer /Rätsel/ 31

¹⁸ Vgl. Kirsch /Systems Development/ 6 und Nidumolu, Subramani /Control/ 170-172

¹⁹ Softwareprodukt wird ebenfalls von dem DIN definiert als „Software, die für die Auslieferung an einen Anwender bestimmt ist“, wobei Software „Programme, Prozeduren, Regeln und jede zugehörige Dokumentation, die sich auf den Betrieb eines Rechners bezieht“ umfasst. Vgl. DIN /DIN 66272/ 3

²⁰ Vgl. DIN, ISO /ISO 9000-3/ 8

²¹ Vgl. DIN /DIN 69901/ 1

²² Vgl. PMI /PMBOK guide/ 4

²³ Vgl. zu den Merkmalen von Projekten Dülfer /Projekte/ 4-16, Frese /HWO/ 2090, Hayek /Projektmanagement-Software/ 6-7, Metzger /Software-Projekte/ 55-60 und Steinbuch /Projektorganisation/ 24-25

²⁴ Die Einmaligkeit spielt in Abschnitt 3.4 eine große Rolle, in dem es um die Empfehlung zur Auswahl der Gestaltungsmaßnahmen geht. Vgl. dazu Balzert /Software-Systeme/ 475, Burghardt /Projektmanagement/ 21 und Metzger /Software-Projekte/ 56

²⁵ Vgl. Campagna /Projektmanagement/ 20, Frühauf, Ludewig und Sandmayr /Software- Projektmanagement/ 10

²⁶ Die Begriffe Softwareentwicklungsprojekt und Projekt werden im weiteren Verlauf dieser Arbeit syn- onym behandelt.

²⁷ Auf die Zusammenhänge zwischen Planung, Kontrolle und Steuerung wird in Abschnitt 3.2 näher eingegangen.

²⁸ Vgl. Felske /Integrierte Projektsteuerung/ 726, Frühauf, Ludewig, Sandmayr /Software- Projektmanagement/ 68, Jenny /Karriere/ 129 und Jenny /Projektmanagement/ 302

²⁹ Vgl. o. V. /Duden/ 480

³⁰ Vgl. Jenny /Projektmanagement/ 1

³¹ Vgl. Angermeier /Projekterfolg/ 1 und Blume /Kostenmanagement/ 609

³² Vgl. Campagna /Projektmanagement/ 188, Frühauf, Ludewig, Sandmayr /Software- Projektmanagement/ 63 und Mellis /Projektmanagement/ 19

³³ Vgl. Boehm /Software Engineering/ 20

³⁴ Vgl. Jenny /Projektmanagement/ 84

³⁵ Vgl. Kerzner, Cleland /Management/ 383-384, Mellis /Projektmanagement/ 354 und Metzger /Software-Projekte/ 308

³⁶ Vgl. DIN /DIN 69901/ 3

³⁷ Vgl. Frühauf, Ludewig, Sandmayr /Software-Projektmanagement/ 21

³⁸ Vgl. George /Empirische Untersuchung/ 6

³⁹ Vgl. Fiedler /Controlling/ 6 und Jenny /Projektmanagement/ 60

⁴⁰ Vgl. Angermeier /Magisches Dreieck/ 1, Blume /Kostenmanagement/ 609, Felske /Integrierte Pro- jektsteuerung/ 722, Jenny /Projektmanagement/ 60-61, Motzel /Leistungsbewertung/ 689 und Raasch /Systementwicklung/ 2

⁴¹ Vgl. Mellis /Projektmanagement/ 354

⁴² Vgl. Burghardt /Projektmanagement/ 336 und Jenny /Projektmanagement/ 314

⁴³ Vgl. Mellis /PSQM/ 10

⁴⁴ Metriken sind Größen, die zur Messung einer bestimmten Eigenschaft eines Software-Moduls einge- setzt werden. Vgl. Balzert /Software- Management/ 225 und Liggesmeyer /Modultest/ 304

⁴⁵ Vgl. Dölle /Operatives IV-Controlling/ 27

⁴⁶ Vgl. Dölle /Operatives IV-Controlling/ 27

⁴⁷ In dieser Studie wurden 5 Projekte untersucht, die extern entwickelt worden sind. Vgl. Choudhury, Sabherwal /Portfolios/ 304-305

⁴⁸ Vgl. Balzert /Software-Systeme/ 7 und Mellis /Projektmanagement/ 354

⁴⁹ Vgl. Mellis /PSQM/ 10

⁵⁰ Vgl. Raasch /Systementwicklung/ 22

⁵¹ Vgl. Bundschuh, Fabry /Aufwandschätzung/ 53, Campagna /Projektmanagement/ 190, Crosby /Qualität/ 14 und Ottmann /Qualitätsmanagement/ 917

⁵² Vgl. Choudhury, Sabherwal /Portfolios/ 304

⁵³ Vgl. Campagna /Projektmanagement/ 193

⁵⁴ Vgl. Campagna /Projektmanagement/ 193

⁵⁵ Vgl. Raasch /Systementwicklung/ 23

⁵⁶ Vgl. Campagna /Projektmanagement/ 193

⁵⁷ Vgl. Frühauf, Ludewig, Sandmayr /Software-Projektmanagement/ 15

⁵⁸ Vgl. Frühauf, Ludewig, Sandmayr /Software-Projektmanagement/ 23

⁵⁹ Vgl. o. V. /Duden/ 420

⁶⁰ Vgl. DIN, ISO /ISO 9000:2000/ 36

⁶¹ Vgl. zu diesem Absatz 4managers.de /Effizienz/

⁶² Vgl. Mellis /Projektmanagement/ 39-41

⁶³ Vgl. Mellis /Turbulent Times/ 277

⁶⁴ Vgl. Mellis /Projektmanagement/ 41

⁶⁵ Vgl. Mellis /Projektmanagement/ 40

⁶⁶ Vgl. Mellis /Projektmanagement/ 42-43

⁶⁷ Vgl. Jenny /Projektmanagement/ 81 und Mellis /Projektmanagement/ 39

⁶⁸ Vgl. zu diesem Absatz Mellis /Projektmanagement/ 39

⁶⁹ Vgl. zu diesem Absatz Mellis /Projektmanagement/ 40

⁷⁰ Vgl. Jenny /Projektmanagement/ 82 und Mellis /Projektmanagement/ 45

⁷¹ Vgl. zu diesem Absatz Mellis /Projektmanagement/ 45

⁷² Vgl. zu diesem Absatz Mellis /Projektmanagement/ 46

⁷³ Vgl. Jenny /Projektmanagement/ 82 und Mellis /Projektmanagement/ 46

⁷⁴ Vgl. Littkemann, Schewe /Interne Kontrollsysteme/ 2

⁷⁵ Vgl. DeMarco /Projektmanagement/ 7

⁷⁶ Vgl. Jenny /Karriere/ 130 und Mellis /Projektmanagement/ 230

⁷⁷ Vgl. Kirsch /Control Modes/ 217, Kirsch, Sambamurthy, Dong-Gil, Purvis /Client/ 485 und Mähring /Managerial Control/ 337

⁷⁸ Bei dieser Klassifizierung kann die managerial control als behavior oder outcome control realisiert

werden (d.h. managerial behavior control und managerial outcome control). Die team member control wird dabei in die zwei Methoden team member outcome control und self control unterteilt. Vgl. Henderson, Lee /Control/ 761 und Santana, Robey /Control/ 21-22

⁷⁹ Vgl. Ravichandran, Rai /Quality/ 279-280

⁸⁰ Vgl. Eisenhardt /Control/ 136

⁸¹ Vgl. Choudhury, Sabherwal /Portfolios/ 294, Jenny /Karriere/ 132 und Kirsch /Control Modes/ 236

⁸² Unter Gewichtung wird hier die Höhe des Aufwandes verstanden, der in die jeweilige Art der Kontrol- le investiert wird.

⁸³ Vgl. Haslinger, Meßerer, Wolters /EDV-Projekte/ 598

⁸⁴ Vgl. Choudhury, Sabherwal /Portfolios/ 297-298 und Kirsch /Control Modes/ 237. Eine empirische Studie zu den Gründen für eine Änderung der Kontrollmethoden siehe auch Kirsch /Dynamics of Control/ 374-395

⁸⁵ Vgl. Choudhury, Sabherwal /Portfolios/ 294

⁸⁶ Vgl. Jenny /Projektmanagement/ 123 und Patzak, Rattay /Projektmanagement/ 111

⁸⁷ Die Begriffe behavior control und Verhaltenskontrolle sowie outcome control und Fortschrittskontrolle werden in der weiteren Arbeit synonym verwendet. Vgl. Eisenhardt /Control/ 135-136 und Kirsch /Control Modes/ 217

⁸⁸ Vgl. Nidumolu, Subramani /Control/ 161

⁸⁹ Vgl. Cusumano, Selby /Microsoft/ 316

⁹⁰ Vgl. Eisenhardt /Control/ 135 und Kirsch /Control Modes/ 217

⁹¹ Vgl. zu diesem Abschnitt Kirsch /Control Modes/ 217

⁹² Vgl. zu diesem Abschnitt Kirsch /Control Modes/ 217

⁹³ Vgl. Choudhury, Sabherwal /Portfolios/ 293

⁹⁴ Vgl. Choudhury, Sabherwal /Portfolios/ 294

⁹⁵ Vgl. Jenny /Projektmanagement/ 47

⁹⁶ Vgl. Gong /Staffing/ 729

⁹⁷ Vgl. Eisenhardt /Control/ 135

⁹⁸ Vgl. Eisenhardt /Control/ 140

⁹⁹ Vgl. Kirsch /Control Modes/ 217

¹⁰⁰ Vgl. Eisenhardt /Control/ 136 und Gong /Staffing/ 729

¹⁰¹ Vgl. Campagna /Projektmanagement/ 165

¹⁰² Vgl. Choudhury, Sabherwal /Portfolios/ 293

¹⁰³ Vgl. Choudhury, Sabherwal /Portfolios/ 294 und Kirsch /Control Modes/ 217

¹⁰⁴ Vgl. Eisenhardt /Control/ 136 und Kirsch /Control Modes/ 217

¹⁰⁵ Die Begriffe clan control und Gruppenkontrolle sowie self control und Selbstkontrolle werden in der weiteren Arbeit synonym verwendet. Vgl. Kirsch /Control Modes/ 217

¹⁰⁶ Vgl. Kirsch /Control Modes/ 217

¹⁰⁷ Vgl. Kirsch /Control Modes/ 217

¹⁰⁸ Vgl. Choudhury, Sabherwal /Portfolios/ 293

¹⁰⁹ Vgl. Kirsch /Control Modes/ 217

¹¹⁰ Vgl. Choudhury, Sabherwal /Portfolios/ 294 und Kirsch, Sambamurthy, Dong-Gil, Purvis /Client/ 486

¹¹¹ Vgl. Kirsch, Sambamurthy, Dong-Gil, Purvis /Client/ 486

¹¹² Vgl. Littkemann, Schewe /Interne Kontrollsysteme/ 6

¹¹³ Vgl. Choudhury, Sabherwal /Portfolios/ 293

¹¹⁴ Vgl. Kirsch /Systems Development/ 3 und Kirsch, Sambamurthy, Dong-Gil, Purvis /Client/ 486

¹¹⁵ Vgl. Cheng, Dainty /Project Manager/ 38

¹¹⁶ Vgl. Kirsch /Systems Development/ 3

¹¹⁷ Vgl. zu diesem Absatz Choudhury, Sabherwal /Portfolios/ 294

¹¹⁸ Vgl. Kirsch /Systems Development/ 3

¹¹⁹ Vgl. Burghardt /Projektmanagement/ 327 und Horváth, Reichmann /Controllinglexikon/ 643

¹²⁰ Vgl. Walenta /Messbarer Projekterfolg/ 1

¹²¹ Vgl. Metzger /Software-Projekte/ 307-308

¹²² Vgl. Jenny /Projektmanagement/ 302

¹²³ Vgl. Jenny /Karriere/ 130

¹²⁴ Vgl. Burghardt /Projektmanagement/ 327 und Horváth, Reichmann /Controllinglexikon/ 643