Der Projekt-Manager trägt ein hohes Risiko, weil der Erfolg oder Mißerfolg direkt mit seinem Namen und seiner Reputation verbunden ist: Führt er das Projekt zum Erfolg, liefert er ein Produkt hoher Qualität innerhalb des gesteckten zeitlichen Rahmens und des geplanten Budgets aus, ist sein Aufstieg im Unternehmen oft vorprogrammiert. Scheitert das Ganze jedoch, ist es in vielen Fällen der Projekt-Manager, der als Sündenbock herhalten muß. Er oder sie mag Fehler gemacht haben, häufig ließ sich die Software unter den gegebenen Umständen nicht termingerecht fertigstellen. Von den drei Forderungen: Einhaltung des Termins, des Kostenrahmens und hohe Qualität des Softwareprodukts lassen sich zwei relativ leicht quantifizieren: Termin und Preis (siehe Abbildung 1).
Die Produktqualität ist zunächst nicht quantifizierbar. Wenn sich im Laufe des Projekts herausstellen sollte, daß der Termin für die Auslieferung der Software nicht eingehalten werden kann, daß hohe Kostenüberschreitungen drohen, ist man noch am ehesten bereit, Abstriche an die Qualität des Produkts zu machen.
Gewiß ist dies eine sehr kurzfristige Sicht der Dinge: Der Anwender merkt schnell, daß er nicht das bekommen hat, wofür er bezahlt hat. Die Folgen sind ein angeschlagenes Image, teure Nachbesserungen, eine aufgeblähte Wartungsphase und so manches Mal der Verlust des Kunden.
Dabei müßte das alles nicht sein, wenn sowohl auf seiten des Anbieters als auch auf der des Kunden Realismus herrschen würde: Projekte lassen sich kalkulieren und planen.
Die Planung: Der erfolgreiche Projekt-Manager geht zwar begrenzte Risiken ein, er ist aber kein Hasardeur. Deshalb wird er den Aufwand für das Projekt planen. Im Hintergrund dieser Berechnungen steht immer die Frage, ob das Vorhaben mit den zur Verfügung stehenden Ressourcen überhaupt zu verwirklichen ist. Für eine Grobabschätzung kann die folgende Gleichung dienen: MM = 5,2 KLOC 0,91 wobei MM: Aufwand in Mannmonaten KLOC: Programmumfang in tausend Lines of Code ist.
Besser allerdings ist eine Planung, die verschiedene Einflußfaktoren auf das Projekt erfaßt, etwa die Art der Applikation sowie die entsprechenden Randbedingungen. Hier bietet Barry Boehm mit dem Cocomo-Verfahren 1) eine geeignete Rechenmethode an. Für eine Applikation mittleren Schwierigkeitsgrads kann die folgende Formel verwendet werden: MM = 3,0 KLOC 1,12
Der Aufwand wird korrigiert
Bei diesem Verfahren wird der Aufwand noch korrigiert, indem man verschiedene Einflußfaktoren berücksichtigt, die von der Zuverlässigkeit, Komplexität und den Eigenschaften der Hardware über die Mitarbeiter bis hin zu den Anforderungen an den zeitlichen Rahmen reichen. Also: MMeff = MM f1 f2 ... fn wobei MMeff: effektiverAufwand f1 f2 ... fn: Korrekturfaktoren sind.
Die Korrekturfaktoren liegen typischerweise im Bereich zwischen 0,7 und 1,5 und verursachen in ihrer Summe bei vielen Projekten eine Korrektur des ursprünglich errechneten Aufwands um den Faktor 3 bis 4. Bezüglich Tools reicht die Spannweite zum Beispiel vom Faktor 0,83 bei einem intensiven Einsatz von Werkzeugen bis zu 1,24 bei deren Vernachlässigung. Mit dem korrigierten Aufwand läßt sich die Projektdauer relativ leicht errechnen: TDEV = 2,5 MMeff 0,35 wobei TDEV: Projektdauer in Monaten ist.
Hier erkennt der erfahrene Projekt-Manager sofort, daß zwischen Projektdauer und Aufwand ein starrer Zusammenhang besteht. Der Terminplan läßt sich nicht beliebig verkürzen, auch nicht durch mehr Mitarbeiter. Manipulieren läßt sich bei diesem Verfahren allenfalls an den Korrekturfaktoren, und auch da nur in begrenztem Umfang.
Wenn sich bei Anwendung der Gleichungen herausstellt, daß das Projekt innerhalb des gesteckten zeitlichen Rahmens zu schaffen ist, um so besser für den Projekt-Manager. Ergibt die Kalkulation allerdings, daß bei einem Projekt mit einer Dauer von vier Jahren nach drei Jahren Software ausgeliefert werden soll, so ist guter Rat teuer.
Forderungen versus Realität
Es setzt sich auch im Bereich der Software immer mehr die Erkenntnis durch, daß der Kunde nicht einfach ein Produkt kaufen will, sondern eine Lösung für ein akutes Problem seiner Organisation sucht. Kommt nun der Projekt-Manager nach seinen Berechnungen zu dem Ergebnis, daß er die Software nicht zum vereinbarten Termin ausliefern kann, hat er zwei Möglichkeiten:
-Er versucht, das Unmögliche zu schaffen. Das führt zum Chaos am Projektende.
-Er schenkt seinem eigenen Management und dem Kunden reinen Wein ein und bietet alternative Lösungen an.
In unserem Fall wäre der Kunde möglicherweise auch zufrieden, wenn ihm nach zwei bis drei Jahren Software ausgeliefert wird, die nur 60 bis 80 Prozent der in der Spezifikation verlangten Funktionen enthält. Diese Lösung, Incremental Delivery genannt, erfüllt zwar zunächst nicht alle seine Wünsche, ist aber die weitaus bessere, wenn man bedenkt, daß Software niedriger Qualität im Betrieb nur Probleme verursachen würde. Im Sinne der anfangs genannten Forderungen paßt man hier die quantifizierbaren Ziele Termin und Preis an - die Produktqualität wird nicht geopfert.
Blicken wir an den Anfang des Entwicklungsprojekts zurück: Hier ist die klare Erfassung der Forderungen des Kunden und der Anwender von eminenter Wichtigkeit. Die Spezifikation der Software ist die Basis, auf der Auftraggeber und Auftragnehmer das Projekt gründen. Gibt es Schwierigkeiten bei der Erfassung der Anforderungen an die Software, könnte der Projekt-Manager etwa vorschlagen, bestimmte Teile der Software mit Rapid Prototyping vorab zu entwickeln.
Eine Gefahr im Projektverlauf stellen sogenannte Creeping Requirements dar, also nachträglich erhöhte Anforderungen an die Software. Hier tut der Projekt-Manager gut daran, derartige Forderungen nach dem Festschreiben der Spezifikation rigoros zu erfassen, also immer die Auswirkungen auf Kosten und Zeitplan darzustellen. Als Instrument kann ein Software Change Control Board (SCCB) dienen.
Prozeßmodell: Leitlinie oder Behinderung?
Selbst wenn das Wasserfallmodell aus der Mode zu kommen scheint, die Gründe für seine Einführung sind nach wie vor aktuell: Man wollte damit erreichen, Produkte zu einem frühen Zeitpunkt der Entwicklung in die Hand zu bekommen, letztlich also die Kontrolle durch das Management fördern.
Das muß ein Ziel des Projekt-Managers sein. Aus diesem Grund liegt die Verwendung eines Prozeßmodells in seinem ureigensten Interesse. Ob dieses ein V-Modell, ein modifiziertes Wasserfall- oder ein firmeneigenes Modell ist, sollte zweitrangig sein.
Allerdings bleibt festzuhalten, daß DIN ISO 9000, Teil 3, zwar kein bestimmtes Modell zur Software-Entwicklung vorschreibt, wohl aber ein Modell und Phasen mit definiertem Input und Output.
So manche Firmenleitung sieht den Vorteil von Projekten darin, daß sie klare Ziele setzen kann und die entsprechenden Produkte zu einem bestimmten Zeitpunkt abgeliefert werden müssen. Würde man kein Projekt ins Leben rufen, würden derartige Vorhaben möglicherweise in der ein oder anderen Abteilung versanden. Andererseits finden sich aber gerade in den Fachabteilungen hochqualifizierte Mitarbeiter.
Sie sind die Ressourcen, die sich ein Projektleiter für seine Arbeit heranziehen sollte. Er wird für Monate und Jahre bestimmte Mitarbeiter aus den Fachabteilungen benötigen. Diese Vorgehensweise ist in Abbildung 2 dargestellt.
Teams können erfolgreich sein, wenn die Rahmenbedingungen stimmen und es für sie nur ein Ziel gibt: ein qualitativ hochwertiges Produkt im festgesetzten zeitlichen Rahmen unter Einhaltung der Kosten abzuliefern. Aus diesem Grund sollte ein Mitarbeiter, der dem Projekt zugeordnet wurde, diesem Team voll zur Verfügung stehen, und nicht nur halbtags oder mit einem Drittel seiner Arbeitskraft - auch wenn es dabei um Monate oder gar Jahre geht. Die Fachabteilung bleibt seine organisatorische Heimat, konkret bringt er sein spezifisches Know-how aber in das Projekt ein.
Komplexität zeigt sich im Projekt in zweierlei Form: Zum einen erfordern große Vorhaben Hunderte von Programmierern, zum zweiten kristallisieren sich im Design oft eine Vielzahl von Modulen heraus. Tabelle 1 zeigt, wie mit der Anzahl der Mitarbeiter auch die Zahl der Schnittstellen wächst:
Jeder erfahrene Manager weiß, daß Besprechungen mit einer großen Zahl von Mitarbeitern schnell ineffektiv werden. Aus der Umsetzung der Forderungen in der Spezifikation ergibt sich wahrscheinlich ein Design, das Hunderte von Modulen enthält, die miteinander kommunizieren müssen. Ein Grundsatz guten Designs lautet, die Zahl der Schnittstellen und der übergebenen Parameter zu minimieren. Hier treffen sich Ziele des Software-Engineering und des Projekt- Managements: Man sollte versuchen, den Mitarbeitern die fachlichen Aufgaben so zuzuweisen, daß ihre Schnittstellen zu anderen Mitgliedern des Teams minimiert werden. So läßt sich die Komplexität wirksam bekämpfen.
Bei der oben beschriebenen Organisationsform sind die Mitarbeiter in den Fachabteilungen zu Hause und werden für Projekte quasi ausgeliehen. Niemand ist stärker motiviert, die drei Ziele Termineinhaltung, Preis und Qualität zu erreichen, als der Projektleiter. Er wird sich nicht einfach darauf verlassen können, daß Produkte wie Dokumente oder Quellcode zum versprochenen Zeitpunkt - der noch ein Jahr in der Zukunft liegen mag - abgeliefert werden. Vielmehr sollte er sich ein einfaches Instrumentarium2) schaffen, um diesen Vorgang zu überwachen.
Wählt man als Beispiel die Implementierungsphase, könnte sich eine Metrik wie in Abbildung 3 darstellen:
Man stelle sich vor, daß insgesamt 400 Module erstellt werden müssen. Dazu stehen 200 Arbeitstage zur Verfügung, also etwa ein Jahr. Das würde bedeuten, daß nach 50 Arbeitstagen 100 Module fertig sein müßten, nach der Hälfte der Zeit 200 Module.
Diese Idealvorstellung ist mit der Kurve A dargestellt. In der Praxis wird es eher dazu kommen, daß am Anfang weniger Module abgeliefert werden, im dritten Quadranten allerdings um so mehr. Dies zeigt Kurve B.
Schlimm wird es, wenn der Projekt-Manager nicht mit dem nötigen Nachdruck dafür sorgt, daß die Programmierer auch Teilprodukte abliefern. Bei Kurve C ist am Ende der Implementierungsphase erst gut die Hälfte der Module fertig. Es kommt also unweigerlich zu einer Terminverzögerung.
Der Nutzen einer solch einfachen Metrik für den Projekt-Manager liegt in der Möglichkeit, die Kontrolle zu behalten. Er kann nach 100 Arbeitstagen durchaus noch gegensteuern, etwa durch eine Urlaubssperre.
Wenn hier von fertigen Modulen die Rede ist, so sind damit getestete und von der Qualitätssicherung abgenommene Module gemeint. Deswegen werden auch Tester in das Projektteam aufgenommen.
Der Projektleiter ist im Idealfall ein erfahrener Fachmann, dessen Realitätssinn ihn nicht davon abhält, kalkulierbare Risiken einzugehen. Er oder sie kann mit sensitiven Mitarbeitern umgehen und scheut sich nicht, gegenüber dem eigenen Management und dem Kunden die Karten auf den Tisch zu legen.
ANGEKLICKT
Projektkontrolle muß ein wesentliches Ziel des Projekt-Managers sein die Verwendung eines Prozeßmodells muß deshalb in seinem Interesse liegen. Ob ein Wasserfall-, ein V-, ein modifiziertes Wasserfall- oder ein firmeninternes Modell, sollte zweitrangig sein.
Hier ist das Instrumentarium der Softwaremetriken zugrunde gelegt, mit dem der Projektleiter die Ablieferung der Produkte überwacht.
*Diplomingenieur Georg Erwin Taller ist Unternehmensberater auf dem Gebiet der Softwarequalität sowie Journalist und Autor zahlreicher Fachbücher. Er lebt in Nürnberg.