In einer aktuellen explorativen Studie zur Project Governance [10, 11] wurden Daten aus 144 Projekten oder Programmen in den deutschsprachigen Ländern ausgewertet. Governance-Gremien sind installiert: In 80 % der Fälle sind Projektauftraggeber*innen benannt, in vielen Fällen aus dem oberen Management. Lenkungsausschüsse sind in der Untersuchung bei ca. 60 % der Projekte implementiert und bei über 90 % der Programme. Sie bestehen dabei in der Regel aus 4 bis 8 Mitgliedern, die sich regelmäßig treffen. Eine Kundenvertretung ist etwa doppelt so oft in Lenkungsausschüssen integriert wie eine Lieferantenvertretung, obwohl beide Parteien ungefähr gleich häufig in die Projektorganisation eingegliedert sind.

Für Projekte mit externen Kund*innen sind der Business Case und die Verantwortlichkeiten in vielen Fällen ausdefiniert, wie es den Soll-Vorstellungen der Standards entspricht. Deutlich schwächer ist dies bei Projekten innerhalb einer Organisation der Fall – bei internen Projekten deuten sich folgende Verbesserungspotenziale an:

Es finden sich Lenkungsausschüsse ohne Personen mit Entscheidungsbefugnis. In fast einem Drittel der Fälle hat niemand eine dedizierte Letztentscheidungskompetenz im Lenkungsausschuss.

In jedem vierten Steuerungsgremium eines internen Projektes oder Programmes ist überhaupt niemand für die Leistung, den Nutzen oder den Business Case verantwortlich. Es scheint „geteilte Verantwortungslosigkeit“ zu bestehen, sodass niemand zur Rechenschaft gezogen werden kann.

Problematisch erscheint auch die mehrfach vorhandene geringe Korrelation zwischen Verantwortung und Entscheidungsbefugnis, sie weist auf die Gefahr einer Dysfunktionalität in der Arbeit des Lenkungsausschusses hin – dies muss allerdings genauer untersucht werden, da die Fallzahl hier nicht groß genug für eine seriöse Aussage ist.

Die meisten der internen Projekte in dieser Studie sind IT-Projekte (55 von 92 internen Projekten) und die Hinweise betreffen damit in erster Linie interne IT-Projekte. Es wird mehr reagiert und versucht die verschiedenen Interessensvertretungen zu „zähmen“, statt Governance proaktiv entsprechend der Empfehlungen und Rahmenwerke zu gestalten. Es liegt auf der Hand, dass die genannten Schwächen zu typischen Problemen in der Projektarbeit führen, wie sie von Projektteams und -leitungen immer wieder genannt werden: verschleppte Entscheidungen, unscharfer wachsender Projektumfang, ungenügende Ressourcen, das Projektteam wird allein gelassen und das Steuerungsgremium ist weit davon entfernt, als ein schlagkräftiges Team zu agieren. Aufgrund einer angemessenen Aufgabenverteilung dürfen Steuerungsgremien bzw. Projektteam wie in Bild 2 dargestellt folgende gegenseitige Erwartungen aneinander haben:

Was IT-Projektexpert*innen bewegt: Business Case und Governance

Project Governance ist das Thema einer Fachgruppe der GPM Deutsche Gesellschaft für Projektmanagement e.V. [12, 13], die Anfang 2021 eine Workshop-Serie zur Governance in internen IT-Projekten gestartet hat. Ziel ist es, mit Expert*innen, die IT-Projekte steuern, im geschlossenen Kreis Erfahrungen auszutauschen. Eine wichtige Randbedingung ist dabei ein vertraulicher Rahmen, sodass offen über Schwierigkeiten und Schwächen berichtet werden kann. Der Bericht über die zuvor genannte Studie bildete die Grundlage für den Key-Note-Vortrag des ersten Workshops und den Start der Diskussion in einer Folge von virtuellen Workshops.

Tatsächlich berichteten die Teilnehmenden aus der Praxis über Schwierigkeiten bei der Definition eines Business Case. Eine besondere Herausforderung für die Erstellung eines Business Case bildet der Umgang mit sogenannten Hype-Themen, bei denen ein neues Thema mit besonderer Erwartungshaltung in die Organisation gebracht wird. Auch wenn solch eine Situation sich voraussichtlich immer einmal wiederholen wird, gibt es positive Erfahrungen damit, den Nutzen eines Projektes im Sinne von Benefit Management regelmäßig zu überprüfen. Je einfacher und prägnanter – „Management-tauglicher“ – der Nutzen beschrieben ist, desto besser lässt sich dieser Prozess leben. 

Konkretes Beispiel aus einer Organisation: Es gibt zum Nutzen einen One-Pager, der vom Management des Unternehmens systematisch und regelmäßig für eine Viertelstunde betrachtet wird, auch die Benennung einer für den Nutzen verantwortlichen Person hat sich in der Praxis bewährt. Und bei sinkendem Nutzen ist die Projektfortführung infrage zu stellen – gute Governance.

In einer weiteren der Sitzungen wurde ein Showcase vorgestellt, bei dem in einem langjährigen Programm die Abgrenzung bzw. Übergang von Projekt zum Betrieb sich als problematisch erwies, der auch in anderen Organisationen nachempfunden werden konnte. Ein gut definierter Business Case bzw. die Steuerung über passende und separate Budgets hätte hier eine hilfreiche Wirkung gehabt.

Bei einem anderen Workshop beinhaltete der vorgestellte Showcase ein Projekt, das eigentlich ein permanentes Anliegen der Organisation repräsentierte und für das passende Governance-Strukturen erst erarbeitet werden mussten. Die anschließende Diskussion hatte Kriterien zur Bewertung und Priorisierung in Projektportfolien zum Thema – auch dies sind Themen einer gut gestalteten Governance.

Was IT-Projektexpert*innen bewegt: Klassisches, agiles oder hybrides Vorgehen?

Daneben bildete ein Thema in den Workshops bei den vertiefenden Diskussionen in Kleingruppen die häufig gestellte Aufgabe an die IT, agile Ansätze zu verfolgen und das Unternehmen bei seiner „Agile Journey“ zu begleiten.

Der Einsatz von agilen Ansätzen erscheint manchem IT-Verantwortlichen auch als Hype-Thema mit zum Teil unpassenden Erwartungen. Plangesteuerte – oft auch „klassisch“ genannte – Ansätze haben je nach Projektinhalt und -größe sowie Ausgangssituation in der Organisation weiterhin auch ihre Berechtigung. Das gekonnte hybride oder selektive Miteinander beider Ansätze sowohl in einem Projekt wie auch auf der Portfolioebene bereitet nach wie vor Schwierigkeiten. Es fehlt an „Entspanntheit“ wie auch an Erfahrungen dazu. In jedem Fall wird der Timeboxing-Ansatz aus der agilen Welt sehr positiv gesehen. Die Taktgebung und die Flexibilität agiler Ansätze hilft in vielen Fällen, Businessvertreter*innen in IT-Projekten einzubinden, besser als im plangesteuerten Vorgehen – so die Einschätzung der am Workshop Teilnehmenden. 

Bei ERP-Projekten wird zu Teilen weiterhin klassisch gearbeitet, wie es z. B. die Studie zum Status der S/4HANA-Umstellung zeigt – ca. ein Drittel klassisches Vorgehen wird hier berichtet, ca. zur Hälfte hybrides Vorgehen, vollständig agiles Vorgehen spielt eine untergeordnete Rolle [2]. 

Die Entscheidung über die Auswahl des angemessenen Vorgehens – plangesteuert, agil oder hybrid – ist auch eine Mitverantwortung der Steuerungsgremien und erfordert angemessenes Verständnis der verschiedenen Ansätze. Und auch in der Arbeit der Steuerungsgremien sollte sich der gewählte Ansatz widerspiegeln: agile Steuerungsarbeit ist anders, das betrifft Methoden- wie Kulturfragen. Auch ein Steuerungsgremium könnte Praktiken wie Stand-ups und Boards nutzen und selbstorganisiert arbeiten.