Wer kennt das nicht in Entwicklungsprojekten:
Situation:
Das Projekt hat erhebliche Schieflage.
Das Reporting nach oben vermeidet jegliches Problem.
Intern wird der Aufwand diese Nachrichten zu vermeiden immer schwieriger und aufwändiger.
Neuplanung reiht sich an Neuplanung in immer aufwändigeren Sitzungen und wachsendem Personenkreis.
Upper Management arbeitet bereits operativ mit (oder auch dagegen) und verlangt stündliche Statusmeldungen bzw. immer neue Reports.
Alle Tools zur Verbesserung werden zeitgleich angewandt und die (meist gleichen) Erkenntnisse werden mangels Zeit nicht umgesetzt.
Ressourcen springen zwischen Prio-Themen herum und die Prio 1-Themen haben bereits mehrere Subprioritäten.
Erkenntnis:
Viele Projekte kranken an einem klaren Exit-Kriterium auf den einzelnen Entscheidungsebenen und -kriterien und den Mut diese auch konsequent anzuwenden.
Dabei liegt das Hauptproblem oft am Projekt-Setup, Vorarbeiten und den Vorgaben der einzelnen Fachdisziplinen und weniger an den beteiligten Leuten.
Meilensteine werden oft mit (teilweise erheblichen Abweichungen) durchgewunken und technische Schulden stillschweigend akzeptiert.
Oft werden auch wichtige Fragestellungen kontinuierlich vertagt und andere (einfachere bzw. schnell lösbare) Themen vorgezogen.
Es ist oft unglaublich schwer, entgleiste Projekte in einem späten Stadium wieder einzufangen.
Das ursprüngliche Projektziel an sich kann dann oft schon gar nicht mehr erreicht werden.
Ob es jemals rentabel in den Markt gebracht werden kann ist ohnehin schwierig zu bestimmen. In einer solchen Situation praktisch unmöglich.
Nicht zu vergessen die dann oft schon riesige Mannschaft und das Problem, das eigene Halbwahrheiten klar erkennbar als falsch angenommen werden müssen.
Und niemand geht gerne zuerst mit seinem Kopf in die Schlinge, nicht wahr?
Um sich das (zumindest teilweise) zu ersparen lohnt es sich sehr Zeit in die Formulierung von (Zwischen-) Zielen zu stecken.
Entsprechend gilt dies für die jeweiligen Prozesse auf Projektebene.
Diese Rahmenbedingungen sind dann aber auch uneingeschränkt einzufordern bzw. umzusetzen.
Dabei ist es egal auf welcher Ebene im Projekt man tätig ist und des jeweils behandelten Artefakts, wie z.B.:
- Ebene Projekt: „Quality Gate“:
Meilenstein mit Kontrollfunktion: Definiert zu erreichende Ziele und erlaubt kein passieren ohne Zielerreichung. Nicht nur Marketing-Ziele, sondern beinharte Kriterien die auch konkret nachgewiesen werden können. - Ebene Projekt: „Exit Criteria“:
Überlegen Sie genau, wie weit Sie in einem Projekt zu gehen bereit sind.
Das startet mit dem Budget, dem Zeitrahmen oder auch Kriterien wie Kopfanzahl oder Bürofläche. Planen Sie Kriterien zum Beenden eines Projektes (z.B. wegen fehlender Wirtschaftlichkeit) und Szenarien mit unterschiedlichen Budgets.
Wichtige Termine können hier Kriterien sein (z.B. wenn nach einem Termin die Marktchancen erheblich absinken).
Dies kann aber durchaus auch für ungelöste Mindestanforderungen gelten (wenn z.B. nicht die erforderliche Anzahl an Fachkräften verfügbar gemacht werden kann oder wenn elementare Wissensträger nicht oder nicht mehr verfügbar sind). - Ebene Prozess: „Tailoring“:
Wie sieht der globale, allgemein formulierte Prozess im Projekt konkret aus?
Welche Tools werden wie verwendet?
Wie können die geforderten Ergebnisse erreicht und nachgewiesen werden? - Artefakt Feature: „Acceptance Criteria“, „Definition of Done“: Zielsetzung auf Ebene der Entwicklung eines Features; Definiert das Abschlusskriterium der Aufgabe.
Diese Ziele erfordern oft Vorarbeiten im Bereich Architektur, Risikobewertung, Requirement Engineering oder auch technische Studien.
Verwaschene Kriterien und Durchwinken sind hier aber schlechte Berater (wenn auch im Verlauf bequem). - Artefakt Abweichung: „Expected Result“: Wie soll sich das Produkt / der Prozess in der behandelten Situation richtig verhalten?
Hier zeigen sich oft Spezifikationslücken auf oder widersprüchliche Vorgaben. Wenn hier in der Klärung geschlampt wird kann man oft die nächste Abweichung garantieren. - Vorgang Review: „Scope“, „Criteria“: Wer soll welchen Sachverhalt (typischerweise entsprechend seiner Rolle) prüfen?
Ein oft gesehenes Problem bei Reviews ist das fehlende Rollenverständnis. Die Prüfung der Seitennummerierung kann für Quality-Rollen relevant sein, nicht für Entwickler.
Review können (je nach Definition) auch sehr umfangreich und damit teuer werden.
Es sollte daher immer klar definiert sein, wer für welche Aspekte zwingend Verantwortung zeigt. Ansonsten ist der Wert dieses wichtigen Instruments nur eingeschränkt erkennbar. - Artefakt Dokument: „Approval“: Wer gibt das Dokument frei? Ist eine Freigabe erforderlich? Wie werden Änderungen durchgeführt? Wer ist für Reviews verantwortlich?
Leider fast immer mit Klärungsbedarf versehen ist die Frage nach Freigabeaktivitäten. Oft zeigen sich hier Lücken im Prozessverständnis oder Lücken in der Definition.
Fast immer ist die Klärung nervig, manchmal auch teuer. - Artefakt Anforderung: „Requirement Maturity“: Erreichen die Anforderungen an das Produkt Best-Practice, zur Vermeidung späterer Aufwände zur Detailklärung?
Unklare oder sogar widersprüchliche Anforderungen erzeugen immer Aufwände und Kosten in der (späteren Klärung).
Wenn kein Akzeptanzkriterium definiert werden kann ist ein Nachweis der Erfüllung unmöglich und Änderungen zu sehr späten Projektphasen unumgänglich.
Sehr oft scheitert man an fehlenden Festlegungen und mangelnder Konsensfähigkeit der Projektteilnehmer.
Viele Nebenprozesse und offene Punkte führen zu unklaren Vorgaben und Vermutungsfestlegungen.
Die Folge daraus ist praktisch immer weiterer Verzug im Projekt zur Klärung von (oft auch einfachen) Sachverhalten und der Umsetzung der dann erst festgelegten Massnahmen.
Und das führt praktisch immer zu „cover your ass“, das hier weitere die Möglichkeiten im Projekt einschränkt.
Fazit:
Tun Sie sich selbst einen Gefallen und fragen Sie früh und beständig nach solchen Punkten. Klären Sie zeitnah und umfassend, oder Sie werden lange daran zu arbeiten haben. Und wenn es wirklich nicht mehr geht, haben Sie den Mut das Projekt (in der aktuellen Form) zu beenden und vielleicht mit den erarbeiteten Erfahrungen neu zu starten.
Tote Pferde reiten sich schlecht und Rennen lassen sich damit nie gewinnen.