Projektmanagement

Hartwig Thomas, 19. Mai 1997

Vorgehen EDV-Projekte (allgemeine Empfehlungen)

Wir werden immer wieder gebeten, Projekte von anderen zu begutachten. Wir empfehlen jeweils ein einfaches und nützliches Vorgehen, das die Wahrscheinlichkeit der erfolgreichen Projektdurchführung stark verbessert. Wir arbeiten selber gerne für Projektleiter, die sich an diese Empfehlungen halten. Die Empfehlungen sind keine weltbewegenden Neuheiten, sondern etabliertes "Software-Engineering", das sich für uns in der Praxis bestätigt hat.

Möglichst kleiner Projektumfang
Es ist äusserst gefährlich, ein "umfassendes" EDV-Projekt durchzuführen, das viele Bestandteile hat und dessen Entwicklung lange dauert. Ein "gesundes" EDV-Projekt sollte in wenigen Monaten realisiert sein. Oft lassen sich grosse Projekte in eine Folge von eigenständigen kleinen Teilprojekten zerlegen, die einen Sinn haben, selbst wenn das gesamte Projekt nicht in der ursprünglich geplanten Form realisiert wird.
Überprüfbare, vollständige Anforderungen
Die allermeisten EDV-Projekte scheitern daran, dass den Entwicklern die Anforderungen nicht bekannt sind. Sobald ein Programm neben dem Entwickler auch nur einen weiteren Benutzer hat, müssen die Anforderungen schriftlich festgehalten werden, bevor die Entwicklung anfängt. Zu den Anforderungen gehören das technische (und ökonomische) Umfeld, die Reaktionsgeschwindigkeiten der Software, Kernfunktionalitäten, Sicherheitsanforderungen, etc. Anforderungen müssen in der Benutzersprache verfasst sein. Sie dürfen kein Computerchinesisch enthalten, das der Auftraggeber nicht versteht.
Überprüfbare, vollständige Spezifikationen
Basierend auf den Anforderungen sind die Spezifikationen des zu entwickelnden Systems von den Entwicklern zu erarbeiten. Diese beinhalten die Wahl der Entwicklungsumgebung, genaue Darstellung der Datenflüsse, genauer Design der Benutzeroberfläche, Strukturierung der Datenbank, etc. Diese Spezifikationen dürfen zwar in einer etwas technischen Sprache abgefasst sein, sollten aber möglichst wenige Implementationsentscheide vorwegnehmen. Die Projektleitung darf keine Zweifel haben, wie das System aussehen wird, wenn es gemäss den Spezifikationen entwickelt ist. Die Spezifikationen müssen in den entscheidenden Punkten genügend konkret und genau sein, dass das Endprodukt daraufhin geprüft werden kann, ob es die Spezifikationen erfüllt.
Aufwandschätzungen durch Entwickler
Es ist bei vielen Softwarefirmen üblich, dass Aufwände und Preise von Verkäufern mit den Kunden "ausgehandelt" werden. Die Frage, wie gross der zeitliche Aufwand (Arbeitsstunden und verflossene Zeit sind separat zu beziffern) ist, kann nicht Gegenstand von Verhandlungen sein. Die Erfahrung zeigt, dass Entwickler diese Aufwände relativ realistisch einschätzen, bevor sie von Managern (oder Kunden) "heruntergehandelt" werden. Der einzige Punkt, wo ein Verhandlungsspielraum besteht, ist der Preis pro Arbeitsstunde, nicht aber die Anzahl Arbeitsstunden.
Meilensteine zur Überprüfbarkeit des Fortschritts
Auch Entwickler machen manchmal trotzdem Schätzfehler - je unerfahrener sie sind, desto häufiger. Um diese möglichst früh zu entdecken und damit die Projektleitung einen guten Einblick in den Fortschritt der Entwicklung hat, empfiehlt es sich, überprüfbare Zwischenstationen ("Meilensteine") der Entwicklung zu definieren. Von der Erreichung solcher Meilensteine sollten allfällige Zahlungen abhängig gemacht werden. Wenn die zeitliche Planung eines Meilensteins stark von der Realität abzuweichen droht, sind von der Projektleitung Massnahmen ins Auge zu fassen.
Unabhängigkeit vom ursprünglichen Hersteller
Der Auftraggeber sollte im allgemeinen eine minimale Unabhängigkeit vom ursprünglichen Hersteller sicherstellen. Das heisst, dass er auf der Übergabe des vollständigen Quellcodes und auf Entwicklerdokumentation bestehen sollte, die es einem anderen Entwickler ermöglichen, die Anwendung weiterzuentwickeln. Im Allgemeinen ist es für den Auftraggeber trotzdem lohnend, allfällige Weiterentwicklungen wieder beim ursprünglichen Hersteller zu bestellen, da in diesem Fall beträchtlicher Einarbeitungsaufwand wegfällt. Sollte der ursprüngliche Entwickler aber nicht mehr greifbar sein oder sollte sich die Beziehung zu diesem sehr stark verschlechtert haben, ist der Zugriff auf den Quellcode für den Auftraggeber wenigstens ein minimaler Investitionsschutz.
Die Forderung nach Offenlegung des Quellcodes gilt natürlich nicht für "Standardsoftware", die in grossen Mengen zu kleinen Preisen gehandelt wird. Als Alternative zur Übergabe des Quellcodes an den Auftraggeber kann auch eine Hinterlegung an einem sicheren Ort vereinbart werden, zusammen mit einer Regelung, in welchen Fällen der Auftraggeber darauf zugreifen kann.
Abnahme, Überprüfung der Resultate
Die Entwicklung einer Software ist ein "Werkauftrag". Um zu beurteilen, ob die Arbeit ihren Preis wert war, ist es entscheidend, dass das Produkt mit den Spezifikationen verglichen wird. Abweichungen von den Spezifikationen haben entweder Preisreduktionen oder Nachbesserungspflichten zur Folge.

Für Punkte 2., 3. und 7. empfiehlt es sich eventuell, eine unabhängige zweite Beurteilungsinstanz mit EDV-Erfahrung beizuziehen.

Dieses Vorgehen ist selbst dann empfehlenswert, wenn es sich um eine kleine Entwicklung handelt, bzw. wenn die Entwicklung intern durchgeführt wird und keinen "offiziellen" Projektstatus hat. Es hat sich bei einer Unzahl von EDV-Projekten bewährt, da es Zeit- und Budgetüberschreitungen weitgehend vermeiden hilft, bzw. wenigstens die Kostenfolgen einer solchen negativen Entwicklung vom Kunden weg auf die Entwickler verschiebt.