Projekte sind mehr als nur Frameworks – Teil 2

Im 1. Teil von Projekte sind mehr als nur Frameworks hast Du bereits erfahren, dass Projekte gute Strukturen und geringe Abhängigkeiten benötigen, um erfolgreich zu sein und wie sich die Teamdynamik auf den Projektfortschritt auswirkt. Im 2. Teil lernst Du mehr zu Methoden, wie der Aufwandsschätzungen und wie die Psychologie Projekte beeinflussen kann.

3. Methodische Grenzen, die es in jedem Modell gibt

Eine besonders spannende und interessante Lektüre ist “12 Halbwahrheiten über IT-Projekte“ von Gerhard Friedrich, der sowohl für agile als auch Wasserfallprojekte methodische Trugschlüsse aufdeckt und es mit Beispielen aus seiner Projekterfahrung widerlegt.

Zeit- und platzbedingt will ich hier zwei dieser 12 Halbwahrheiten herausgreifen, welche in meinen Projekten bisher besonders große Aufwandsmultiplikatoren dargestellt haben:

1. Halbwahrheit: Detaillierte Anforderungsdefinition führt zu zuverlässigen Aufwandsschätzungen

Kaum war das Lastenheft und Konzepte der konventionellen Projekte durch das Agile Manifesto in ‚Working Product over Comprehensive Documentation’ in User Stories umgewandelt, schon gab es den Drang diese User Stories in Epics für die Umsetzung zu unterteilen.
In meinem großen Projekt nach SAFe-Vorgehensweise sind die Epic-Beschreibungen und -Pflege in Jira für Aufwandsschätzungen und Arbeitsverteilung so ausgeartet, dass

• Zusammenhänge immer unklarer wurden
• Epics weniger gepflegt waren
• der Aufwand ein Vielfaches als die eigentliche Umsetzung darstellte.

2. Halbwahrheit: Projektcontrolling führt zu mehr Kontrolle

Oder auch liebevoll mit einer Management-Maxime aufgegriffen “you get what you measure” führt zu vielen (teils aufwändig detaillierten) Auswertungen. Dieser neue Fokus auf KPIs führt indirekt eine Projekt(-um-)priorisierung ein, welche widersprüchlich zum eigentlichen Projektziel sein kann.

Beispielsweise wird portfolioübergreifend das Projektbudget getrackt. Aber auch wenn dort alles im ‘grünen’ Bereich ist, können der tatsächliche Fortschritt und die Qualität immer noch schlecht sein und die Projektrisiken können unerträglich wirken. Das Berichtswesen zeigt bei Abweichungen zudem nur Symptome auf.
Maßnahmen zur Beseitigung der dahinter liegenden Ursachen sollten nach sorgfältigen Analysen erfolgen. Sie kosten zusätzlich Aufwand und es besteht ein zeitlicher Versatz bis die Maßnahmen endlich greifen.

Mein Tipp: Am besten wird auch hier Auswertungsaufwand dem Nutzen- und Projektziel gegenübergestellt.

4. Psychologische Effekte

Neben den Teamdynamiken und Halbwahrheiten von Methodiken, können auch psychologische Effekte jedes Einzelnen ein Projekt stark beeinflussen. Rolf Dobelli hat mit seinen zwei Büchern “Die Kunst des klaren Denkens: 52 Denkfehler, die Sie besser anderen überlassen” und “Die Kunst des klugen Handelns: 52 Irrwege, die Sie besser anderen überlassen” zahlreiche dieser Effekte aufgezeigt:

In 2016 wurden diese beiden Bücher von zwei it-economics Kollegen vorstellt. Seither spiegeln sich für mich die dort beschriebenen Effekte bei der Aufnahme von Anforderungen, Schätzungen und in der Gruppendynamik wider. Als Teil eines Teams kann somit jede*r von uns im Projekt zu mehr Erfolg beitragen, indem er/sie durch Selbstreflektion diese Effekte erkennt und ihnen bewusst entgegensteuert.

Um ein Beispiel zu Authority Bias zu nennen, zu Deutsch: nur wer über Autorität verfügt, bekommt Recht.
Das kann ein Lenkungsschuss, Programmleiter*innen oder Product Owner/Scrum Master sein, die eine Aufwandsschätzung für eine IT-Lösung Top-Down vorgeben. Oftmals sind sehr erfahrene Mitarbeitende in den Teams, die aufgrund ihrer Erfahrung und Nähe zum Team und System realistischere Aufwandseinschätzungen geben könnten.
In einem solchen Fall könnte man Methodiken wie Planning-Poker für Bottom-Up-Schätzungen oder Erfahrungswerte aus ähnlichen Projekten nutzen. Zugegebenermaßen dauert eine Bottom-Up initial deutlich länger als eine Top-Down-Schätzung, aber sie ist zum einen realistischer und zum anderen bringt sie das Team-Committment mit sich mit.

Realistische Pläne führen langfristig zu mehr Klarheit und weniger Missverständnissen, Abstimmungsbedarf im Projekt selber und somit zu einer größeren Chance auf Projekterfolg und glücklicheren Projektmitarbeitenden.

Um die Authority Bias zu umgehen,

• kann jede*r Einzelne die Vorgaben mit seinen Erfahrungswerten abgleichen;
• Projektmanager/Scrum Master Bottom-Up Methodiken etablieren;
• Investoren hinterfragen, durch wen die Schätzung oder Konzeption zu Stande gekommen ist. Wurden fachspezifische Expert*innen, die später im Team mitarbeiten können, gefragt? Haben diejenigen ähnliche Referenzprojekte umgesetzt? Kennen diejenigen das Projektumfeld gut genug, um eine realistische Schätzung abgeben zu können?

Neue Projekte, die über ein Ausschreibungsverfahren mit Kostenfokus, gestartet werden, unterliegen Anfangs meist unrealistischen Plänen und dort ist es besonders wichtig auf den Authority Bias zu achten.
Wenn die Aufwandsschätzung nach der Ausschreibung deutlich steigt, weil man an Erfahrung gewinnt und die Schätzungen der Projektarbeitenden mit einfließen lässt, so ist es wichtig, dass ein realistischer Plan schnellstmöglich etabliert wird. Ein Projekt, das nicht bereit ist, realistische Pläne zu etablieren, ist ein Projekt das noch nicht bereit ist, zu lernen. Unrealistische Pläne jedoch bremsen den Projektfortschritt aus. Das bekannteste Beispiel ist wohl der BER Flughafenbau.

Als Fazit kann jeder mitnehmen, dass die stark diskutierten Frameworks nur ein Teil eines Projektes darstellen. Grundlegend sind die Unternehmensstrukturen und Projektabhängigkeiten, die Anerkennung von methodischen Grenzen sowie die psychologischen Effekte jedes Einzelnen und der Gruppe. Das macht Projekte zwar zu einem komplexen System, bei Berücksichtigung bringt es jedoch den Projekt- und somit auch den Unternehmenserfolg viel näher.

Autorin

Julia Radick
Managing Consultant