Braucht es Projektmanagement?

Unser Gastautor Heinrich Drügemöller, Geschäftsführer des Projektdienstleisters iatrocon GmbH, eröffnet auch seinen dritten Beitrag für den Can Do Blog mit einer provokanten Frage. Und obwohl sich die Antwort bereits erahnen lässt – besonders spannend und interessant an diesem Beitrag sind die Fallbeispiele und Herleitungen, die nur zu einem "Ja!" aus tiefer Überzeugung führen können.

Grundsätzliches

Bevor die Frage beantwortet werden kann, sollten sich die Leserinnen und Leser nochmals vergegenwärtigen, was ein Projekt ist. Passende Definitionen sind: 

• Ein Projekt ist ein individuelles, einmaliges, komplexes sowie zeitlich, sachlich und räumlich begrenztes Vorhaben mit einer spezifischen personellen Organisation sowie klar definierter Verantwortung und Aufgabenstellung mit einer realistischen Ziel- und Ergebnisdefinition.  
• Ein Projekt ist nach DIN 69901 ein Vorhaben, bei dem innerhalb einer definierten Zeitspanne ein definiertes Ziel erreicht werden soll, und das sich dadurch auszeichnet, dass es im Wesentlichen ein einmaliges Vorhaben ist. 
• Ein Projekt kann groß oder klein sein, in jedem Fall ist es einmalig und einzigartig, zeitlich begrenzt und bedingt ein klar definiertes Ergebnis. Es hat grundsätzlich eine oder mehrere Veränderungen zum Ziel. Projekte benötigen in der Regel Ressourcen. An einem Projekt sind immer Menschen - in beliebiger Anzahl - beteiligt (reine Maschinenarbeit ist demnach kein Projekt). Ein Projekt hat einen "Lebenszyklus" mit folgenden Phasen: Konzeption, Entstehung und Entwicklung, Durchführung, Ausklang und Ende. 

 
Deutlich wird, dass Projekte nicht in die Regelprozesse eines Unternehmens passen. Sie müssen parallel oder separat organisiert werden. Damit sind wir beim Projektmanagement. In den letzten Jahrzehnten sind hierfür verschiedene Methoden entwickelt worden:

• IPMA, Gesellschaft für Projektmanagement 

• Prince2, (Projects in Controlled Enviroments) / gilt auch für Produktentwicklung 

• PMI, Project Management Book of Knowledge 

• Scrum 

• SAFe 

• V-Modell 

Die Aufzählung ist nicht vollständig, und die Methoden haben unterschiedliche Schwerpunkte. Sie bedienen aber alle – wenn auch leicht unterschiedlich – die für mich grundsätzlichen Anforderungen ans Projektmanagement, die ich wie folgt kurz zusammengefasst habe: 

Anforderungen an das Projektmanagement 

1. Sicherstellen des Scopes  
2. Budget überwachen
3. Termine verfolgen 
4. Qualität verfolgen
5. Risiken identifizieren und überwachen
6. Ressourcen managen  

Das Beachten der genannten 6 Themen reicht jedoch noch nicht aus. Besonders wichtig ist das 7. Thema: „Informationsmanagement“. Dies bedeutet, Informationen zu allen Themen des Projektes für alle Stakeholder Adressaten-gerecht bereitzustellen. Aus meiner Sicht zeigen diese 7 Themen, dass die Durchführung eines konsequenten Projektmanagements – ganz gleich nach welcher Methode – erforderlich ist. In meiner beruflichen Praxis sind mir zu dieser Notwendigkeit mehrere Beispiele begegnet; zwei davon möchte ich gerne näher erläutern: 

Beispiel 1

Das Projektmanagement wird durch einen fachlichen Experten durchgeführt 

Ein erfahrener fachlicher Experte ohne besondere Erfahrung im Projektmanagement und PM-Training bekommt die Aufgabe, ein größeres Projekt durchzuführen. Es sind mehrere Abteilungen des Unternehmens beteiligt. Arbeiten sollen außerdem an 2 externe Dienstleister vergeben werden.

Nach einem guten Start fällt das Projekt hinter den Zeitplan zurück. Es häufen sich kritische Besprechungen. Beide Dienstleister kündigen erhöhten Aufwand an. Das Management ordnete eine neutrale Bewertung des Projektes an, die folgendes ergab: 

 Negative Punkte: 

Der Projektauftrag ist nicht vollständig:

• Risiken sind nicht aufgeführt 
• Ziele nicht „SMART“ definiert
  
  

Die Projektstruktur ist unklar: 

• Berichts – und Entscheidungsinstanzen nicht festgelegt 

• Verantwortlichkeiten nicht eindeutig geregelt

Die Kommunikation ist nicht transparent:

• Stakeholder nicht identifiziert 
• Management nur teilweise eingebunden 
• Betroffene Team nicht vollständig informiert 

• Projektleiter berichtet nur an Teamleitung
  
  

Das Budget ist unklar:

• Externe Aufträge ohne konkrete Aufgabenstellung, Fristen, Liefergegenstände 
• Internes Budget (Aufwand) nicht konkret gefasst („eh da Kosten“) 
• Keine Aufwandserfassung

Die Ressourcen sind nicht ausreichend:

• Keine Ressourcenvereinbarungen intern abgeschlossen 
• Investitionen nicht bewertet und terminiert 
• Festgelegter Projektleiter permanent überlastet
  
  

Die Terminplanung ist unvollständig:

• Terminplan ohne Meilensteine und Ressourcen 
• Termine nicht aktuell gepflegt

Das Qualitäts- und Testmanagement ist nur teilweise eingeführt 

Positive Punkte: 

Projektgegenstand / Projektinhalt 

• Fachlich gut beschrieben 
• Betroffene Prozesse gut erfasst 

Qualifikation der Ressourcen

• Mitarbeiter qualifiziert und motiviert 

• Investitionen lassen sich zeitnah einsteuern 

Die Schlussfolgerung aus der Bewertung macht deutlich, dass die kritische Punkte fast ausschließlich den Bereichen Organisation und Management zuzuordnen sind. Fachliche Defizite wurden dagegen nicht identifiziert. Das Management hat sich der Empfehlung angeschlossen und die Einführung eines konsequenten Projektmanagements beschlossen. Eine Berichtsstruktur sowie Entscheidungsebenen wurden festgelegt. Das Reporting des Aufwands und die Dokumentation der Ergebnisse wurden vereinbart.

Gleichzeitig wurde festgestellt, dass im Unternehmen keine Projektkultur vorhanden ist. Veränderungen wurden in der Vergangenheit mehrheitlich in sehr kleinen Schritten durchgeführt, welche die Mängel im Projektmanagement nicht aufgezeigt haben.

Lessons learned

Fachliche ExpertInnenen sollten nicht in die Rolle der Projektleitung gedrängt werden. Sie sind zwar unentbehrlich für ein Projekt, verfügen aber oft nicht über die Ausbildung oder Erfahrung als ProjektleiterIn. Sie neigen dazu, die fachlichen Dinge im Vordergrund zu sehen. Das Projektmanagement und die ganzen Prozesse, die damit verbunden sind, sind eher lästig für sie.  

Das Management ist in solchen Situationen besonders gefordert. Projektmanagement erfordert Zeit- und Budget-Vorgaben, damit qualifiziert gearbeitet werden kann. Drängt man Fach-ExpertInnen in die Rolle der Projektleitung, kommt entweder das Projektmanagement oder die fachliche Arbeit zu kurz. Den fachlichen ExpertInnen kann man an dieser Stelle nur den Rat geben, auf diese Zusammenhänge konsequent hinzuweisen. 

Aufgrund der zeitlichen Anforderung wurde in diesem Beispiel übrigens beschlossen, die Dokumentation mit Office-Tools durchzuführen. Die Einführung eines PM-Tools wurde in Aussicht gestellt.

Beispiel 2

Ein Unternehmen beschließt, die in der gesamten Fertigung eingesetzten Softwaretools zu ertüchtigen. Ziel ist es, die über 30 Jahre selbst entwickelte Software der eigenen IT-Abteilung abzulösen. In einem ersten Schritt sondiert man den Markt. Ein für die eigene Produktion geeignetes System kann aber nicht gefunden werden.

Ein renommiertes Consulting Unternehmen wird eingebunden. Nach vielen Abstimmungen fällt die Entscheidung, ein vollständiges Lastenheft zu erstellen, in dem auch die Erfahrungen des Consulting Unternehmens einfließen sollen.

Die Betriebssituation zum Entscheidungszeitpunkt ist wie folgt zu beschreiben: 

• Ressourcenmangel in den IT-Bereichen 
• Finanzielle Ausstattung der IT ist mangelhaft 
• Fachabteilungen können nur in geringem Umfang Ressourcen für ein Lastenheft bereitstellen 
• Eine sehr große Zahl von IT-Projekten mit Priorität 1 ist in Bearbeitung – zum Teil bereits mit Verzug 
• Das IT Portfolio enthält fast 100 Prio 1-Projekte (auch ein Grund für das generelle Update der Fertigungssoftware) 

• Hohe Auslastung der Produktion 
• Die zum Start des Projektes definierten Ziele garantieren beim Erreichen eine unwahrscheinlich hohe Wirtschaftlichkeit des neuen Systems 
• Projektmanagement Tools sind nicht im Einsatz 
• Projektmanagement Methoden werden nicht angewendet 
• Das Tool der Wahl ist Excel^®

Man beschließt, das Projekt-Lastenheft mit dem Consulting Unternehmen und einem kleinen internen Team – 2 Personen – zu starten. Die eigene IT wird nicht eingebunden. Ein externer Projektleiter wird eingesetzt.  Seine Aufgabe ist die Leitung des Projektes.

In einem Zeitraum von etwas mehr als einem Jahr entsteht ein Lastenheft mit mehr als 600 Seiten und entsprechenden Anlagen. Die interne Abstimmung aller Teams fand statt. Es gab nur wenige Rückmeldungen – was verwunderlich ist. 600 Seiten Lastenheft zum Teil in Stichworten und Aufzählungen geschrieben benötigen viel Zeit, die Aufgrund der Ressourcenengpässe und des Termindrucks eigentlich nicht vorhanden war. Die eingebundenen Teams haben dies auch geäußert.

Das Ergebnis der internen Abstimmung wurde der Geschäftsleitung vorgelegt. Vereinbart wurde, das Lastenheft als verbindliche Grundlage anzusehen, auf der weitere Maßnahmen aufsetzen sollten.  

Die "Make or Buy" Entscheidung wurde diskutiert und zugunsten von "Make" entschieden. Ein Gesamtprojekt wurde aufgesetzt. Für die Umsetzung wurde ein Konzept erstellt. Geplante Dauer: 5 Jahre. Das Budget im zweistelligen Millionen-Bereich wurde aufgestellt und Ressourcen eingeplant. Eine agile Umsetzung mit Iterationszeiträumen von jeweils 6 Monaten sollte erfolgen.

Das eingebundene Consulting Unternehmen bekam den Auftrag für die Umsetzung. Die IT-Abteilung wurde nur für das Thema "Schnittstellen" eingebunden. Konkrete nutzbare Ergebnisse wurden nach etwa 2 Jahren erwartet.

3 Monate nach Start der 1. Iteration erhob das Management die Forderung, Nutzen schneller zu erreichen. Ein Proof of Concept wurde beschlossen. Umplanung und Verzug der 1. Iteration waren die Folge. Das Umsetzungskonzept wurde vollständig verlassen. Es kam zu erhöhtem Aufwand für die 1. Iteration. Testumgebungen für den Proof of Concept waren nicht verfügbar und mussten nachgearbeitet werden. Zu diesem Zeitpunkt betrug die Projektlaufzeit 2 Jahre.

Lessons learned

Nach 2 Jahren Projektlaufzeit sind die Erfahrungen umfangreich. Ich gliedere sie in zwei Bereiche, die das Projekt selbst bzw. das Management betreffen:

Management

Das Unternehmen hatte keine Erfahrung in der Umsetzung großer IT-Projekte. Eine transparente Steuerung der bisher durchgeführten kleineren IT-Maßnahmen war nicht gegeben. Ein Portfolio von nahezu 100 Projekten der Priorität 1 ist nicht sinnvoll. Es wurden keine Tools – außer Excel^® – im Einsatz für Portfoliomanagement und Projektmanagement eingesetzt. Es wurde keine Projektmanagement Methode implementiert. Change Management war nicht geplant.

Maßnahmen

• Keine strategischen Entscheidungen innerhalb einer laufenden Iteration mit Auswirkungen auf die laufende Iteration treffen 
• Implementieren einer PM-Methode 
• Einführen eines effektiven Portfolio Managements mit Toolunterstützung 

• Risikomanagement implementieren 
• Vereinbaren eines Standards für das Reporting 
• Einführung eines PM-Tools 
• Projekte durch Change Management begleiten

Projekt

6 Monate für eine Iteration sind zu lang. Nutzbare Ergebnisse waren erst nach 4 Iterationen (2 Jahre) geplant. Die Projektvorbereitung im Unternehmen war mangelhaft. Es stand keine Entwicklungsumgebung, wie vereinbart, beim Start zur Verfügung. Produktivsetzungen wurde nicht durch Regelprozesse unterstützt. Testumgebungen standen nicht bereit. Die nötige IT-Infrastruktur war nicht ausreichend vorhanden. Da die IT-Abteilung nicht aktiv eingebunden war, entstanden viele Missverständnisse. Das Ressourcen-Engagement für das Projekt war nicht verbindlich, die Produktion war übergeordnet.

Maßnahmen

• IT-Abteilung vollständig in das Projekt integrieren 
• Priorisierung des Projektes klären 
• Ressourcen verbindlich zuweisen 

• IT-Infrastruktur parallel zum Projekt einrichten 
• Test- und Produktivsetzungen planen 
• Entwicklungsumgebungen bereitstellen vor Projektstart

Fazit

Projektmanagement kann nur erfolgreich sein, wenn im Unternehmen dies entsprechend eingeführt und verstanden wird. Methodisch sollte das Projektmanagement klar ausgerichtet sein. Effektiv wird Projektmanagement erst dann, wenn Tools dieses unterstützen. Diese entlasten alle Beteiligten und sorgen für Transparenz. Can Do ist hierfür ein hervorragendes Beispiel. 

Über den Autor

Heinrich Drügemöller ist Senior Projektmanager und Geschäftsführer des Projektdienstleisters iatrocon GmbH. Er besitzt mehr als 35 Jahre Expertise in Projekten und über 20 Jahre Erfahrung in der Geschäftsführung von Unternehmen. Seine Branchenkenntnisse umfassen Versicherungen und Banken, Versorgungs- und Energiewirtschaft, Chemie, Pharmazie, Petrochemie und Verkehrslogistik. Er verfügt über die Zertifizierungen PRINCE2 (Projects in Controlled Environment), PRINCE2 Practitioner sowie PMI (Project Management Institute), PMP (Project Management Professional). Heinrich Drügemöller ist Gastautor für Can Do.