Unter Wasser...

Grund Nr. 1: Unklare Absicht und fehlende Entscheide

d.h. unklare Ziele auf jeder Ebene.

• Das Gesamtziel, die Teilziele der Teilprojekte und die eigentlichen Ziele der Meilensteine sind nicht dem ganzen Team klar.
• Die Ziele des Projektes, der Teams und der einzelnen Entwickler sind nicht aufeinander ausgerichtet.
• Es werden zu viele Ziele gleichzeitig verfolgt, jedes Ziel hat noch drei Optionen, es gibt keine klaren Entscheide für oder wider.
• Es werden unnötige Ziele erreicht, da das Entwicklungsprojekt Technologie-getrieben statt Kunden-getrieben ist.

Lösung: Klare operationalisierte Ziele aufschreiben

• Operationalisierte Ziele heisst, dass es klar ist was das Produkt beim Erreichen des Ziels macht, oder zumindest was der Stand welcher Dokumente und sonstigen Artefakte im Projekt ist.
  • Es heisst auch klarzustellen, was das Produkt nicht macht, was die Nicht-Ziele sind.
  • Wir finden es am effizientesten, mit Absichten zu arbeiten:
    • Wie sieht Erfolg aus?
    • Was wollen wir hier erreichen?
• Aufschreiben heisst, dass die Ziele in einem jedem zugänglichen Dokument oder noch besser auf einer Team-Wiki Seite formuliert sind.
  • Achtung Falle: in vielen Teams gibt es einen sehr digitalen Umgang mit Zielen: entweder wird nichts aufgeschrieben, oder dann entsteht gerade ein riesiger "Requirement-Management" Formalismus. Auch hier liegt der Weg in der Mitte, ein paar Bullet-Points auf einer Wiki Seite sind am Anfang besser als nichts, aber auch besser als formal richtige Anforderungen, welche erst am Ende des Projektes fertig werden...
• Was nicht heisst, dass es ohne Requirements geht: Anforderungen sind als Detail-Ziele unverzichtbar.
  • Unverzichtbar ist auch die Einsicht, dass Änderungen der Anforderungen Bestandteil jedes Projektes sind.
  • Sobald Anforderungen aufgeschrieben sind, können sie diskutiert werden. Wenn diese Diskussionen mit allen Betroffenen von Produktmanagement bis Entwicklern gut geführt werden, dann werden die Anforderungen "automatisch" den richtigen Detaillierungsgrad erreichen.
• Entscheide: einfach entscheiden und die Resultate schriftlich festhalten.
  • Wir schauen Entscheide als Experimente an, dann fallen sie leichter: Wir stellen mit dem Entscheid eine Hypothese auf. Dann überprüfen wir diese Hypothese in der Praxis, in einem Experiment. Sobald wir sehen, dass wir die falsche Hypothese genommen haben, passen wir diese an. Wenn wir die richtige genommen haben, müssen wir nichts anpassen.
  • Wenn Termine eingehalten werden sollen, ist es besser, zu entscheiden statt noch auf zusätzliche Informationen zu warten ("Paralysis by Analyis").
• Änderungsmanagement: Was nicht den Zielen entspricht, ist eine Änderung, diese im Projekt klar ausweisen und ihre Auswirkungen abschätzen ("Impact Management"). Diese Abschätzung dient als Entscheidungshilfe dafür, ob sich der Aufwand in Zeit und Geld für die Änderung lohnt.

Übrigens entkräftet die klare Formulierung von Zielen und Anforderungen das Argument "interne Mitarbeiter und Freelancer sind einfacher zu führen als ein externes (Teil-)Projekt, da wir nichts spezifizieren müssen": auch Interne müssen wissen, was sie zu tun haben!

Grund Nr. 2: Keine realistische Schätzung

• In vielen Organistionen fehlen die Werkzeuge, um eine sinnvolle Schätzung zu machen, es wird aus dem Bauch heraus eine Zahl hingeschrieben.
• Es sind häufig weder Zeit noch Mitarbeiter für eine belastbare Schätzung eingeplant.
• Manchmal will auch niemand den realen Aufwand wissen, denn das Projekt ist schon zu dem Preis verkauft, das Budget wurde ohne Schätzung geplant...
• Mit einer realistischen Schätzung am Anfang bekommt man kein Projekt bewilligt.

Lösung: Realistische Schätzung durchführen

• Realistische Schätzung heisst
  • eine Expertenschätzung durchführen, am bestem mit Planning Poker
  • Zwei-Punkt Schätzung (siehe z.B. Schätzwerkzeuge) 
  • wenn immer möglich Attribut-basierte Schätzung (z.B. kann die Implementation von den meisten Entwicklern gut geschätzt werden, die Aufwände für Design, Testing, Integration... werden besser als Faktoren ("Attribute") dazumultipliziert). Wenn eine Organisation sehr stabile Prozesse hat, sind auch komplett Attribut-basierte Schätzungen möglich, z.B. Entwicklungszeit pro Seiten Lastenheft.
• Wenn es aus internen Gründen nötig sein sollte, ist es sinnvoll, das "Tuning" auf einen Zielwert erst nach der realistischen Schätzung durchzuführen, man kann dann immer auf die erste Schätzung zurückgreifen.
• Der im Projekt wirklich gebrauchte Aufwand muss dokumentiert werden, so dass die Schätzung nach dem Projektende überprüft werden kann und die Faktoren für nächste Schätzungen aus dem Projekt extrahiert werden können.
• Ein einfaches Risikomanagement mit Schäden und Eintreffenswahrscheinlichkeiten wird durchgeführt.
  • Das resultierende Risiko gehört zur Schätzung dazugezählt: Wenn 10 Risiken von 500 Stunden Aufwand mit 10% Eintretenswahrscheinlichkeit geschätzt werden (d.h. eine Risikosumme von 500 Stunden), dann kann das Eintreten eines der Risiken erwartet werden. Das heisst, das Projekt wird dazu 500 Stunden aufwenden müssen. Woher soll es die 500 Stunden nehmen, wenn sie nicht geplant sind?
  • Die Risiken, Schäden und Wahrscheinlichkeiten müssen über das Projekt z.B. monatlich nachgeführt werden. Und es ist ein ziemlich guter Indikator für eine Intervention, wenn das Gesamtrisiko über das Projekt nicht abnimmt...

Grund Nr. 3: Keine klare Arbeitsweise

• Jedes Projekt wird von jedem Projektleiter anders geführt, jedes Teammitglied setzt die Werkzeuge anders ein und versteht unter den Prozessen und Begriffen etwas anderes.
  • Offiziell haben alle ISO 9001, machen alle Scrum... In Realität macht jeder das, was er gut findet. Und "agil" ist zu häufig die Ausrede für "chaotisch".
  • Daraus folgt, dass kein Projekt vom anderen lernen kann. Es gibt in einzelnen Projekten gute Arbeitsweisen (auch Prozesse genannt). Von denen, weil sie nie aufgeschrieben wurden, die anderen Projekte nicht profitieren können.
  • Prozesse und deren Optimierung ist die Aufgabe einer Qualitätsabteilung. Die Ingenieure und vor allem die Führung fühlen sich dafür nicht zuständig.
• Fehlende Verantwortung/ "Ownership": Es ist nicht für jedes Erzeugnis des Projektes klar, wer für dessen Fertigstellung verantwortlich ist.

Lösung: Prozesse durchsetzen und optimieren

• Welche Grundlage, ob agil, V-Modell, Stage-Gate oder Wasserfall, die Projektmanagement-Prozesse müssen eingefordert werden.
  • Erst dann kann man feststellen, ob sie überhaupt lebbar sind und man kann sie lebbar machen, anpassen, optimieren.
• Projekt vorbereiten: technisch (Architektur und Design), organisatorisch und zeitlich (Planung).
  • Sonst kommt es so, wie wenn alle (Maurer, Sanitär, Schreiner, Elektriker ...) miteinander anfangen das Haus zu Bauen (ohne Fundament, ohne Plan, nur mit einer vagen Idee)...
• Verantwortliche schriftlich definieren: für alles was im Projekt entstehen soll.
• Begriffe schriftlich definieren, ein Glossar erstellen.
  • Es kann im Nachhinein vortrefflich gestritten werden, was denn nun eigentlich eine Package-Test und was ein Modul-Test sei. Wenn es definiert ist, dann ist es jedem im Projekt von Anfang an klar.

Grund Nr. 4: Keine verlässliche Information über den Projektstatus

• Öfters gibt es während eines Projektes im Management keine Idee über den Zielerreichungsgrad.
• Es gibt viel Controlling im Rückspiegel über aufgelaufene Aufwände und Kosten im Projektmanagement-System, jedoch keine Information über den realen Projektstand und die Probleme (z.B. aufgetretene und identifizierte Risiken).

Lösung: Zwischenziele definieren und mit dem Team sprechen

• Iterative Lieferung, Zwischenziele planen und nachverfolgen.
  • Am besten hat sich hier die agile Idee bewährt, sobald möglich alle z.B. vier Wochen eine Untermenge der Funktion auszuliefern.
• Schätzung und vor allem Risikoliste regelmässig nachführen, z.B. alle vier Wochen.
• Fragen Sie mal ein Team-Mitglied nach dem Status.
  • Wenn die Kultur eine ungefilterte Antwort zulässt....

Grund Nr. 5: Kein wirkungsvolles Management

• Akzeptanz des "Fakts", dass Entwicklung nicht planbar sei, Vogel-Strauss Verhalten bei Überschreitungen.
• "Salamitaktik" ist implizit akzeptiert, jedes Projekt wird zu tief budgetiert und dann nachfinanziert.
• Glaube an Parkinsons Law: Wir müssen die Zeit und das Budget möglichst beschränken, sonst hat das Team zu wenig Druck.

Lösung: Vorhersagbarkeit einfordern

• Schätzungen und Pläne vom Entwicklerteam verlangen, Verbesserung der Erreichung der geplanten Ziele einfordern.
• Wenn Salamitaktik nötig ist, diese gerade richtig nutzen, um Zwischenziele zu definieren: Jede Scheibe richtig geschätzt und mit klaren Zielen.
• Keine Überschreitungen um Faktoren akzeptieren.
  • Das heisst aber häufig auch, dass höhere Anfangsschätzungen akzeptiert werden müssen. Was wiederum den Vorteil hat, dass finanzielle Entscheide über Produktentwicklungen auf einer realistischen Basis gefällt werden.

Und der Aufwand für das alles? Ist nach unserer Erfahrung ziemlich genau 10% des Projektaufwandes, also viel weniger als die 200 bis 1000%  ohne diese Massnahmen...

Und: das oben gesagte gilt auch für viele andere technische Projekte (Digitalisierung, IoT, IT...).

Andreas Stucki

Haben Sie zusätzliche Fragen? Haben Sie eine andere Meinung? Wenn ja, mailen Sie mir oder kommentieren Sie Ihre Gedanken unten!