Wenn alle begriffen haben, dass das Projekt in Schieflage geraten ist, ist es meistens zu spät. Und dann wird zumeist hektisch mit den falschen Maßnahmen reagiert. Aber Überstunden und Durchhalte-Strategien helfen nicht – genau so wenig wie es sinnvoll ist, in einer Sackgasse immer schneller zu rennen.
Wer Softwareprojekte auch in schwierigem Umfeld zum Erfolg führen will, muss zweierlei klären:
- Wie bemerke ich frühzeitig, dass etwas schief läuft?
- Was ist zu tun, wenn relativ spät gravierende Probleme erkannt werden?
Dummerweise kann man den Fortschritt eines Softwareprojektes nicht sehen wie den Baufortschritt beim Eigenheim. Aus der Menge des erstellten Codes lässt sich selten auf den Fertigstellungsgrad schließen. Erst wenn die Software in den Test geht, fällt auf, dass manches noch fehlt oder nicht richtig funktioniert, dass Anforderungen falsch verstanden wurden oder die Performance der Routinen nicht den Anforderungen des Alltags genügt.
Fortschritt muss man sehen
Eins ist klar: der beste Projektplan nützt nichts, wenn man die Fortschrittsmeldungen der Analysten, Designer und Entwickler nicht nachprüfen kann. Da hilft nur, von Anfang an eine parallele Qualitätskontrolle zu implementieren. Schon die Spezifikations- und Designdokumente können während ihrer Erstellung einem regelmäßigen Review unterzogen werden. Die Qualitätssicherung dieser Dokumente erst kurz vor der geplanten Fertigstellung vorzusehen, führt oft nur dazu, dass sie ganz weggelassen wird und dass in den Entwicklungsprozess dann mit unfertigen Vorgaben gestartet wird. Mancher mag das „agile Entwicklungmethodik“ nennen – meist ist es nur ein Zeichen dafür, dass schon am Anfang des Projekts vieles falsch gelaufen ist.
Die Implementierung sollte so geplant werden, dass schon früh Teile des Systems in die Testumgebung ausgeliefert werden können. Darauf ist die Erstellung der Testfallkataloge zu synchronisieren. Entwickelertests müssen nachvollziehbar dokumentiert werden – und im Zweifel sollten sie auch nachvollzogen werden. So kann man zumindest ein Gefühl dafür bekommen, wie es um den Projektfortschritt wirklich bestellt ist.
Kein Vertrauen?
Mancher meint, solche Maßnahmen schaffen eine Atmosphäre des Misstrauens. Aber das Gegenteil ist der Fall. Wenn keine Zwischenergebnisse vorweisbar sind und für Qualitätssicherung und Tests nichts zur Verfügung steht, dann entsteht Misstrauen – zu Recht.
Was aber ist zu tun, wenn Verzögerungen und Qualitätsmängel auftreten, die nicht mehr ausgeglichen werden können, und der Terminplan des Projektes ernsthaft in Gefahr gerät?
Oft meint man, durch erhöhten Ressourceneinsatz (Überstunden, zusätzliches Personal) das Projekt auf Kurs halten, gegensteuern, zu können. So hofft man, irgendwie in der geplanten Zeit doch noch das Projekt zum Erfolg zu bringen. Aber mit den Überstunden steigt die Fehlerquote, die Produktivität sinkt. Und zusätzliche Entwickler verkürzen selten die Entwicklungszeit, wenn sie noch eingearbeitet werden müssen. Außerdem steigt der Koordinationsaufwand.
Gegensteuern oder neuer Kurs?
Gegensteuern bedeutet, das Schiff auf Kurs zu halten, auch wenn die Umstände sich ändern. Das ist lobenswert, kostet aber zusätzliche Kraft und funktioniert immer nur begrenzte Zeit. Frühzeitig muss man sich deshalb fragen, ob ein anderer Kurs gewählt werden sollte, oder ob ein neues Ziel angesteuert werden kann.
Neuer Kurs, das heißt, das Vorgehensmodell im Projekt wird überarbeitet. Getaktetes Liefern von Zwischenergebnissen, Umorganisieren der Teams, das sind mögliche Maßnahmen.
Ein neues Ziel ansteuern, das bedeutet, über Prioritäten bei den Projektzielen zu sprechen. Dazu ist ein offensives Anforderungsmanagement notwendig: Anforderungen müssen von Anfang an zerlegt und unterschiedlich priorisiert werden, Umsetzungsalternativen müssen bekannt und bewertet sein. Dann kann auch während des Projektes noch neu bestimmt werden, was zu welchem Termin auszuliefern ist, damit die Fachseite ihre Geschäftsziele erreicht.
Externe Unterstützung, etwa durch die INDAL-TaskForce, wird in solchen Situationen vor allem gebraucht, um effektiv die Möglichkeiten des Umsteuerns zu prüfen und umzusetzen. Externe Entwicklerressourcen, die dann zusätzlich zum Einsatz kommen können, unterstützen zielgerichtet diese Schritte. Nicht einfach mehr Ressourcen, sondern an den richtigen Stellen die richtigen Kompetenzen, dass ist die Methode, das „Ruder herumzureißen“ – So wie bei einer Erkrankung manchmal eben akut nicht mehr Obst und Gemüse, sondern eine kleine Dosis bittere Medizin hilft.