Das Projekt ist abgeschlossen, die Software läuft beim Kunden. Aber war das Projekt erfolgreich? In diesem Artikel über kleine Projekte stellt Ihnen Olaf Clausen einen Vorschlag zur Erfolgsmessung von Projekten vor. Er geht außerdem auf die Behandlung von Bugfixes, Updates und Supportanfragen ein.
Das Projekt ist abgeschlossen, die Software läuft beim Kunden. Aber war das Projekt erfolgreich? In diesem Artikel über kleine Projekte stellt Ihnen Olaf Clausen einen Vorschlag zur Erfolgsmessung von Projekten vor. Er geht außerdem auf die Behandlung von Bugfixes, Updates und Supportanfragen ein.
Projektabschlüsse haben etwas Schönes an sich. Der Kopf ist wieder frei, das kommende Wochenende ist der Familie versprochen und in den nächsten Tagen können wir (hoffentlich) mit einem Geldeingang auf unserem Konto rechnen. Wir denken noch einmal über das durchgeführte Projekt nach und werden uns an positive und negative Situationen erinnern. Intuitiv stufen wir das Projekt dann als erfolgreich oder vielleicht auch nicht so erfolgreich ein und legen es zu den Akten.
Leider trügt der Schein häufig. Auch wenn wir meinen, ein Projekt sei gut verlaufen, sagt das noch nichts darüber aus, ob wir es auch profitabel abschließen konnten. Insbesondere wenn mehrere Mitarbeiter an einem Projekt gearbeitet haben oder sich das Projekt über einen längeren Zeitraum erstreckte, reicht ein subjektiver Eindruck nicht. Gleichzeitig wird die objektive Einschätzung schwieriger. Wir benötigen ein System, dass uns bei der Beurteilung hilft und einen Vergleich mit anderen Projekten zulässt. Wir brauchen also ein Kennzahlensystem, das sich auf eine Projekt-Gesamtnote verdichten lässt.
Wir können natürlich nur Kennzahlen verwenden, zu denen wir auch Daten erhoben haben bzw. die wir beurteilen können. Die Anzahl der Kundenanrufe könnte z.B. nur als Kennzahl dienen, wenn die Telefonanlage diese auch eindeutig erfasst.
Während des Projektverlaufs hat jeder Mitarbeiter seine Stunden erfasst. Ebenso wurden alle Kosten, die durch das Projekt direkt verursacht wurden, notiert. Es bietet sich also an, den Zeitaufwand und die Kosten als Kennzahlen zu verwenden. Welche Aspekte bei der Projektdurchführung könnten noch den Erfolg des Projekts beeinflussen? Die Stabilität und Zuverlässigkeit unser Software, ausgedrückt durch die Kennzahl Qualität erscheint noch sinnvoll. Ebenso ist die Kundenzufriedenheit ein wichtiger Aspekt. Vielleicht interessiert uns aber auch der Zuwachs an Know-how, den wir durch dieses Projekt erlangen konnten. Dann sollten wir diese Kennzahl ebenfalls in unser System aufnehmen.
Den Zeitaufwand und die Kosten können wir zahlenmäßig genau erfassen. Wir bezeichnen diese Kennzahlen daher als kardinale Kennzahlen. Den Know-how-Gewinn exakt zu messen ist dagegen unmöglich. Wir können höchstens Aussagen wie z.B. "nichts Neues" oder "Einarbeitung in ein neues Thema (zukunftsweisend)" treffen. Diese Aussagen versehen wir mit Nummern. Wir sprechen dann von nominalen Kennzahlen. Jede Aussage wird also einer Nummer zugeordnet. In der Regel lässt sich mit kardinalen Kennzahlen besser arbeiten, da diese einfacher zu handhaben sind. Wichtig ist allerdings, dass ein System von Kennzahlen verwendet wird, das verschiedene Bereiche der Softwareentwicklung abdeckt. Wird z.B. nur die Kennzahl "Kosten" verwendet, so kann ich zwar eine Aussage darüber treffen, ob das Projekt sich finanziell gerechnet hat, berücksichtige aber überhaupt nicht, dass das Projekt beispielweise einen deutlichen Know-how-Gewinn gebracht hat, der uns in anderen Projekten zu Gute kommt.
Welche Kennzahlen für welches Unternehmen relevant sind, kann jedes Unternehmen nur selbst unter Berücksichtigung seiner Besonderheiten bestimmen.
Aus diesen Kennzahlen wollen wir dann eine Gesamtprojektbeurteilung ableiten.
Den Zeitaufwand zu messen stellt für uns kein Problem dar, denn wir haben die angefallenen Arbeitsstunden während des Projekts erfasst. Es bietet sich an, den tatsächlichen Zeitaufwand (Ist-Stunden) und den geplanten Zeitaufwand (Soll-Stunden) zu vergleichen. Den geplanten Zeitaufwand können wir aus dem Angebot entnehmen. Die Differenz dieser beiden ist allerdings keine aussagekräftige Größe, da eine Differenz von 10 Stunden bei einem Projektvolumen von 1.000 Stunden sicherlich unproblematisch, bei einem Projektvolumen von 20 Stunden allerdings außerordentlich kritisch sein kann. Wir können also nur mit relativen Größen arbeiten. Jede Kennzahl soll daher auf einer Skala von -1 bis 1 skaliert werden. Andere Skalen, wie die Schulnotenskala, sind natürlich ebenfalls denkbar. Wir arbeiten mit einem Vorzeichenwechsel, da das Vorzeichen uns automatisch anzeigt, ob die Kennzahl positiv oder negativ zu bewerten ist. Bei der Kennzahl Zeitaufwand bedeutet eine "0", dass genauso viele Stunden wie geplant benötigt wurden. Eine "1" bedeutet, wir haben das Projekt ohne Zeitaufwand durchgeführt und eine "-1", dass wir unendlich viel Zeit für das Projekt aufwenden mussten.
Bild 1: Definition des Zeitaufwands (Aufwandsfaktor = AF)
Zur Berechnung der Kennzahl verwenden wir nur die Kernprojektstunden, also nicht die Zeit für den Supportaufwand. Den Support werden wir bei der Kennzahl Qualität getrennt berücksichtigen.
