Wenn Druck in ein Projekt reinkommt: Trotzdem Dinge richtig tun

In meiner Projektpraxis kommt es immer wieder vor, dass trotz großer Anstrengungen die Ergebnisse weit hinter den Plänen oder Erwartungen nachhinken. Nachfolgend finden Sie einige Empfehlungen, die in der Praxis helfen.

Die Ausgangslage: Alle im Projekt arbeiten mit großem Einsatz und dennoch sind Ziele, selbst wenn sie realistisch dimensioniert sind, was nicht immer der Fall ist J, nicht und nicht erreichbar. Die Projektleitung bzw. der Auftraggeber werden immer unzufriedener, wesentliche Entwicklungsziele werden re-priorisiert, Überstunden und Urlaubsverzicht eingefordert, die Projektmitarbeiter verlieren das Vertrauen an die Zielerreichung und die Projektleitung, … die Spirale dreht sich steil und eng nach unten.

Hier ist es wichtig, sich nicht vollständig vom Panik-Modus diktieren zu lassen und aktionistisch Maßnahmen zu setzen, die lediglich eine hektische Betriebsamkeit nach außen (zum Auftraggeber) vermitteln. Es gilt durch eine klare und strukturierte Vorgehensweise Maßnahmen in der richtigen Reihenfolge zu setzen.

In meiner Praxis haben sich folgende Prioritäten und Reihenfolgen als richtig herausgestellt:

  1. Abgestimmte Vorgehensweise der Entscheider
  2. Fokus auf Qualität
  3. Work in Progress-Limits einführen und einhalten
  4. Häufige Lieferungen
  5. Nachfrage und Durchsatz balancieren
  6. Das Richtige priorisieren
  7. Vorhersagbarkeit erhöhen

Wenn Sie nun „Work in Progress-Limits einführen“ oder „Häufige Lieferungen“ lesen, so ist das ein Indikator für agiles Vorgehen. Aber gleich an dieser Stelle der Widerruf: Nein, auch in der traditionellen Vorgehensweise kann man die Anzahl der gleichzeitig durchzuführenden Arbeiten sinnvoll dimensionieren und Zwischenergebnisse in Form von in sich abgeschlossenen Artefakten liefern und mit den betroffenen Stakeholdern bzw. Projektleitern, Fachbereich, Analysten, Programmierer und Testern besprechen.

Trotz Druck die richtigen Dinge tun

Trotz Druck die richtigen Dinge tun

1. Abgestimmte Vorgehensweise der Entscheider

Neben den klassischen Rollen, wie beispielsweise dem Projektleiter, gibt es eine Vielzahl von steuernden Personen im Projekt. Product Owner, Featureteam-Leiter, Release Manager, Delivery Manager, usw. Oft genug verfolgen alle Beteiligten unterschiedliche Prioritäten, ein gemeinsamer Plan existiert nicht.

Ein enger Schulterschluss der „Entscheider“ ist in solchen Situationen dringend notwendig. Es gilt, den Kreis der Entscheider zu identifizieren und zu einer engen, zyklischen Abstimmung auf Basis eines abgestimmten Plans zu bringen. Aus dieser Gruppe kommen die wesentlichen Impulse und next steps für das gesamte Projekt. Es empfiehlt sich, den Kreis der Entscheider klein zu halten (max. 5-6 Personen), sich mindestens 1 x pro Woche ernsthaft zu einer Abstimmung zu treffen – pünktlich, ohne Störungen, ohne überboardender Dominanz des Tagesgeschäfts (sonst kommen strategische Punkte zu kurz!), usw.

In meiner Praxis hat sich auch eine 70-100-Regel bei Entscheidungen als günstig erwiesen: Wenn im Entscheiderteam jeder zumindest zu 70% hinter einer Entscheidungen stehen kann, dann wird diese Entscheidung zu 100% getragen. Politisches Kleingeld á la „Ich will das ja auch nicht, aber die da haben so entschieden“ zu machen schwächt das Entscheiderteam nachhaltig.

2. Fokus auf Qualität

„Wir nehmen uns gerne die Zeit, Dinge immer wieder zu machen – statt sie einmal richtig zu tun.“ Natürlich ist bei fehlender Qualität (Defects, nicht erfüllte Requirements, usw.) ein deutlicher Mehraufwand, der durch Korrektur, neuerlicher Q-Sicherung, Deployment, Einführung, usw. entsteht, mehr Zeit in die Entwicklung eines Features gelaufen. Auch das Vertrauen in die Akteure sinkt („Die produzieren nur Mist“). Gerne unterschätzt wird auch, dass alle an der Korrektur beteiligten Personen immer wieder und wieder aus den laufenden Arbeiten herausgerissen werden um den oder die Fehler zu beseitigen. Dadurch kommt man in den gefährlichen Multitasking-Modus, mit dem daraus resultierenden Mehr an neuen Fehlern und deutlichem Mehr an Zeitbedarf für alles.

3. Work in Progress-Limits einführen und einhalten

Kommt ein Projekt unter Druck, wird durch schlechte Projektleitungen noch mehr Öl ins Feuer gegossen, indem noch mehr gleichzeitige Tasks beauftragt werden („Schlagzahl erhöhen“) oder der vorliegende Plan ohne Feedback aus den Ergebnissen des Projekts stumpfsinnig eingehalten wird. Die Projektleitung ist von außen oberflächlich betrachtet fein raus – sie hat ja alles getan, was möglich und geplant war („Alles ist im Laufen, jetzt müssen die Teams nur noch liefern“).

Eine professionelle Projektleitung konzentriert sich auf die optimale Aus- bzw. Belastung der Teams und die Beseitigung von Schwachstellen und Bottlenecks. Auch wenn es an dieser Stelle bedeutet, ein re-planning zu machen. Je früher klar ist, wie es um den Projektplan wirklich bestellt ist, desto mehr Zeit hat das Projekt Maßnahmen zur Zielerreichung zu ergreifen.

Zur Optimierung des Outputs hat sich die Einführung von Work in Progress-, kurz WiP-, Limits herauskristallisiert. Man belastet die Teams mit wenigen, gleichzeitigen Tasks, verkürzt aber damit substanziell die Durchlaufzeit der einzelnen Tasks, da Overheads durch Taskswitching vermieden werden und zwei weitere Super-Effekte entstehen: Es gibt für den Auftraggeber (Product Owner und Co) rascher Feedback (à häufige Lieferungen) und für neuerliche Tasks kann sich der Auftraggeber später entscheiden, was er genau haben will („late commitment“).

4. Häufige Lieferungen

Die Basisüberlegung dazu: Vertrauen in Akteure wird dann etabliert, wenn diese oft Zugesagtes einhalten. Im Gegensatz zu ein bis zwei Lieferungen pro Jahr hat man durch Lieferungen alle zwei bis vier Wochen öfters die Chance Vertrauen zu gewinnen.

In einem kritischen Projektverlauf ist es besser, öfters nachzuweisen, dass alles im Lot ist. Sich für 6 Monate wegzusperren und nichts zu liefern erhöht die Unsicherheit beim Auftraggeber.

Ein weiterer Vorteil, der sich durch häufige Lieferungen ergibt: Integration wird bei der Herstellung der einzelnen Artefakte im Rahmen der Definition-of-Done (DoD) erledigt und ein späteres Scheitern aus Integrationsproblemen, insbesondere wahrscheinlich bei großen Projekten, verhindert.

5. Nachfrage und Durchsatz balancieren

Gerade wenn unterschiedliche Auftraggeber, z.B. verschiedene Fachbereiche, Anforderungen an das Projekt stellen (können), ist ein Gatekeeping an der Eingangsseite des Projekts wichtig. Es ist notwendig, die eigene Kapazität als Kennzahl parat zu haben und im Zweifelsfalls die Auftraggeber selbst entscheiden zu lassen, welche Anforderung welche Priorität hat. Natürlich wird der Fachbereich damit argumentieren, dass wenn „Feature X nicht bis Datum Y fertig wird die Ziele des Fachbereichs nicht erreicht werden können“ und daran „die Projektleitung Schuld hat!“. Dieser Schlagabtausch ist normal und im Regelfall, wenn die Kapazitätsplanung fundiert vermittelt wird, schnell wieder vorbei. Schafft es die Projektleitung zwischen den einzelnen Gruppen der Anforderer ein wechselseitiges Geben-und-Nehmen zu etablieren, ist das perfekt. Jedoch fokussiert sich in der Praxis die Projektleitung leider zu sehr darauf eher mehr reinzunehmen und die eigene Mannschaft die sprichwörtliche Suppe auslöffeln zu lassen.

Schafft man es, Nachfrage und Durchsatz zu balancieren, wird das Projekt in Richtung optimaler Auslastung mehr Output schaffen. Durch kontinuierliche Verbesserung des projektinternen Wertschöpfungsprozesses, weniger Störungen durch Überlastung und etablierten Teams, die wissen, was sie wie leisten können, wird die Kapazität des Projekts kontinuierlich wachsen – was wiederum zu mehr Nachfragen führen wird.

6. Das Richtige priorisieren

Es gilt, die aus Sicht des Business Value hochwertigsten Features zu priorisieren. Hauptproblem: Oft ist die Bewertung des Werts durch die jahrelange Rechtfertigungspolitik in den Unternehmen wertlos geworden („Für jede Änderung lässt sich ein Business Case berechnen!“). Nach der Realisierung ist eine Total-Cost-of-Ownership (TCO) Berechnung für das Projekt ziemlich wertlos: Das Feature wurde ja bereits realisiert und hat das Projekt belastet. Oder es werden Listen mit Kriterien, wie „potentieller Gewinn“ und „potentieller Schaden“ geführt – allerdings ohne gemeinsames Spielverständnis.

Also, wie damit umgehen? Eine Möglichkeit ist das Schaffen einer klaren Business Value Bewertung, die die zugrundeliegenden Strategien (mehr Umsatz, mehr Kunden, mehr…) berücksichtigt und Änderungen der Strategie mitnehmen kann. Diese Bewertung ist mit den Auftraggebern und den planungsverantwortlichen im Projekt gemeinsam zu schaffen.

Weiteres Aspekte in Richtung das Richtige zu tun:

  • Durchstich-Strategie, d.h. zuerst das Feature in einer funktionalen Basis herzustellen und es erst in Folge zu „behübschen“; damit gibt es die Funktion in der Basis und falls letztendlich Ressourcen knapp werden, gibt es die Funktion zumindest in einer einfachen Variante
  • Risikobasierte Priorisierung, d.h. jene Features mit der größten Wahrscheinlichkeit zu Scheitern, zuerst schaffen: Zuerst Unbekanntes und Neues angehen, Bekanntes ist ja leichter herzustellen
  • Silobildung vermeiden, d.h. Prüfungen aus fachlicher oder technischer Architektur bei allen Anforderungen gewährleisten, insbesondere dann wichtig, wenn im Projekt in einzelnen Teams entwickelt wird

7. Vorhersagbarkeit erhöhen

Ein guter Witz basiert darauf, überraschend zu sein à ohne Überraschungsmoment gibt es keinen guten Witz. Aber: Ein Projekt ist jedoch kein Witz. Je vorhersagbarer Lieferungen des Projekts werden – und es geht hier im Kern um Termine, Kosten und Qualität – desto mehr Vertrauen werden alle Stakeholder in die Leistungen des Projekts haben. Abstimmungen zwischen Auftraggebern werden dadurch vereinfacht – diese brauchen keine überdimensionierten Sicherheiten in ihre Pläne einchecken und reduzieren daher die Anforderungen an das Projekt, das deshalb auch entspannter wird. Die mit der Umsetzung betrauten Projektmitarbeiter des Teams werden ebenfalls durch bessere Vorhersagbarkeit profitieren (Optimierungen der Arbeiten bis hin zu verlässlicheren Freizeiten, usw.) und sich besser auf die jeweilige Situation einstellen können.

Abhängig davon, in welchem Projektmanagement-Framework entwickelt wird (Scrum, DSDM, FDD, Kanban, Wasserfall, V-Modell, etc.) werden Schätzungen und Messungen dabei helfen, vorhersagbarer zu werden. Wichtig ist in allen Fällen, dass die Zielerreichung auch wirklich projektinterne Kultur ist.

Referenzen:

[Anderson-2012] – David Anderson, „Kanban – Evolutionäres Change Management für IT-Organisationen“, 2012

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: