Projektplanung

Grundvoraussetzung für jede Planung ist das Aufbrechen von Komplexität in verständliche, greifbare Teile. Projektpläne beschreiben dann alle notwendigen Aktivitäten zur Lösung der Teile und die Zusammenführung aller Teile zum Gesamtbild, dem Projektziel.

Dabei sind die Unterschiede zwischen einer plangetriebenen oder agilen Vorgehensweise von verschiedenen Faktoren, wie der Organisationsform, der verwendeten agilen Methode und dem Grad¹ der Agilität eines Unternehmens abhängig. Daher beziehen sich die Betrachtungen zur agilen Vorgehensweise jeweils auf den Einsatz in einem agilen Unternehmen. Hybride Ansätze liegen dann irgendwo zwischen der plangetriebenen beziehungsweise agilen Vorgehensweise.

Im Folgenden werden die aus meiner Sicht für ein erfolgreiches Projektmanagement benötigten Planungsaufgaben beschrieben. Jede einzelne Planungsaufgabe ist je nach Vorgehensmodell unterschiedlich ausgeprägt und kann eventuell auch ganz entfallen.

• Projektdefinition
• Anforderungsmanagement
• Budget- und Ressourcenmanagement
• Zeitmanagement
• Qualitätsmanagement
• Kommunikationsmanagement (Stakeholder)
• Risikomanagement

Projektmanagement ist natürlich mehr als Methoden, Prozesse und Planung, aber ohne Methoden, Prozesse und Planung findet kein Projektmanagement statt.
Wieviel Planung letztendlich für eine reale Umsetzung benötigt wird, ob eine A4 Seite ausreicht oder gar eine Dokumentenablage zur Verwaltung erforderlich wird, ist vom Projekt, der Methode und den Dokumentationsanforderungen abhängig.

Projektdefinition

Die Projektdefinition dient der Festlegung des Projektziels und den Rahmenbedingungen, unter denen ein Projekt durchgeführt wird.
Die Projektdefinition ist kein direkter Bestandteil der Planungsaufgaben, ist aber wesentlich für ein Projekt und definiert Was soll Wie und Wozu umgesetzt werden.

Was, zum Beispiel ein neues Produkt
Wie, zum Beispiel durch einen neuen oder veränderten Geschäftsprozess mit Software Unterstützung, Werbekampagnen, etc. sowie die Rahmenbedingungen, unter denen ein Projekt durchzuführen ist
Wozu, zum Beispiel für die Einführung eines neuen Produktes zur Umsatzsteigerung, für verbesserte Kundenbindung oder zur Effizienzsteigerung

Die Projektdefinition wird vermehrt durch die Verwendung von „Business Model Canvas“ abgeleiteten Versionen wie Project Canvas², „Agile Project Canvas“ oder Portfolio Canvas³ abgebildet. Diese Abbildungsform, ursprünglich für die Modellierung von Geschäftsmodellen konzipiert, fasst die Basisparameter auf einer Seite zusammen.

Durch den hohen Abstraktionsgrad eignet sich eine Projektdefinition jedoch nur bedingt für eine Projektplanung. Hierzu ist eine detailliertere Darstellung der umzusetzenden Anforderungen notwendig.
Jedoch kann aus einer Projektdefinition eine erste Version eines Projektstrukturplans oder auch Work Break down Structue hergeleitet werden. Der Projektstrukturplan ist dann in den folgenden Projektphasen zu detaillieren.

Anforderungs-management

Die Definition der Anforderungen ist ein grundlegender Schritt, auf dem Planungen, Schätzungen und der Business Case basieren.
Anforderungen müssen in sich stimmig und für alle Projektbeteiligten verständlich beschrieben sein.

Bei der klassischen Vorgehensweise nach dem „Wasserfall“ oder „V-Modell“ ist eine vollständige Anforderungsdefinition zu Beginn eines Projektes zwingend, da diese die Grundlage für die Schätzungen bildet.
Der Aufwand für eine abgestimmte und vollständige Anforderungsbeschreibung wird bei komplexen Vorhaben leicht unterschätzt. So kommt es auf Grund von Zeitdruck nicht selten zur Freigabe unvollständiger Versionen. Dies führt wiederum zu Mehraufwänden für Korrekturen bzw. Anpassungen in späteren Projektphasen.

Auch während der Umsetzung, insbesondere größerer Projekte, kommt es zu Änderungen. Jede Änderung muss hinsichtlich der Auswirkungen bewertet und entsprechend Dokumentiert werden. Hierbei ist es unerheblich, ob die Änderungen auf Grund veränderter Rahmenbedingungen, technischer Gegebenheiten oder aus sonstigen Gründen notwendig werden.
Je nach Bewertung kann eine Änderung im Rahmen des Projektes ohne weitere, mit nur geringen oder auch größeren Auswirkungen mit umgesetzt werden, oder eben nicht.
Die Auswirkungen können eine Budget Erhöhung, eine Verschiebung auf der Zeitachse oder auch beides bewirken. Dies ist in der Regel abhängig von den verfügbaren Ressourcen und der noch verbliebenen Zeit bis zur Fertigstellung.
Alternativ können zusätzliche Anforderungen in eine zweite Projektphase ausgegliedert werden. Handelt es sich jedoch um essenzielle Änderungen, ohne die eine grundlegende Funktion nicht gewährleistet ist, wird eine Neuplanung der betroffenen Projektteile notwendig.

Eine schleichende Erweiterung bzw. Änderung (engl. scope creep) von Projektanforderung sollte unbedingt vermieden werden. Das Projekt verliert ansonsten die Planungsgrundlage und wird voraussichtlich nicht im geplanten Rahmen von Zeit, Budget und Qualität abgeschlossen.

---

Die agile Entwicklungsmethodik erlaubt ein flexibleres Vorgehen im Umgang mit Anforderungen auf Kosten einer größeren Unsicherheit in Bezug auf Kosten und Zeit. Dies bedeutet aber nicht, dass die Kosten oder der Zeitbedarf größer ausfallen. Das Gegenteil kann der Fall sein, da durch die Prioritäten gesteuerte inkrementelle Vorgehensweise der Fokus stärker auf die wesentlichen Aspekte gelenkt wird. „Nice to have“ Anforderungen rücken in den Hintergrund. Auch können sehr komplexe Themen durch den iterativen Ansatz schneller begreifbar und damit besser umgesetzt werden.
Das Anforderungsmanagement ist zudem integraler Bestandteil des iterativen Ansatzes und verhindert so auch „Scope creep“.
Es wandert als Aufgabe vom klassischen Projektmanagement zum „Product Owner“ und dem agilen Team.
Mit jeder neuen Iteration werden die anstehenden Anforderungen in Form von „User Stories“, verwaltet in einem „Backlog“, neu bewertet. Anhand der Bewertung, wird dann ein Satz an „User Stories“ für die nächste Iteration ausgewählt.
Auf diese Weise werden die wertvollsten Anforderungen, ob neu oder alt, zuerst umgesetzt, und so schnellst möglich ein Nutzen erzeugt.

Budget und Ressourcenmanagement

Die Aufwandsschätzung bildet die Basis für eine detaillierte Planung.
Erst die Einschätzung der Anforderungen durch Experten im Hinblick auf Zeit und Ressourcen erzeugt verlässliche Daten.

Für komplexe und umfangreiche Anforderungen bietet sich die Durchführung von Schätz-Workshops an. Dies dient sowohl der Klärung einzelner Anforderungen, als auch einer ersten Abstimmung der Experten hinsichtlich Schnittstellen untereinander.

Als Ergebnis soll die Schätzung Daten zum zeitlichen Aufwand, sowie den Ressourcenbedarf liefern.
Der zeitliche Aufwand ist relativ zu einem vorgegebenen, oder noch zu vereinbarenden Starttermin zu sehen und bestimmt so die Dauer einzelner Tasks.
Der Ressourcenbedarf bestimmt die benötigten Expertenrollen, die jeweilige Anzahl an Personentagen bzw. Monaten, die Kosten pro Personentag und Rolle, sowie das Budget für Festpreisangebote und benötigte Hardware, Lizenzen oder sonstige Dienstleistungen.
Für ein Projekt können sowohl Kosten für, vom jeweiligen Unternehmen beschäftigte Mitarbeiter, als auch für extern hinzuzuziehende Berater erfasst werden. Damit erhöht sich die Kostentransparenz für ein Projekt.

Mit Freigabe einer Projektphase werden die benötigten Budgets üblicherweise in die Buchhaltungssysteme überführt. Dort werden dann Rechnungen und Aufwendungen interner Mitarbeiter auf das oder die Projektkonten gebucht.
Für größere Umsetzungen ist es sehr hilfreich, das Budget entsprechend der Aufwandsschätzung auf verschiedene Unterkonten zu verteilen. Wenn auch die Buchungen entsprechend erfolgen, ist so die Budgetnutzung im Kontext der erbrachten Leistung erkennbar. Angereichert mit einem „Budget Forecast“ entsteht eine transparente Sicht auf die Budget-Verwendung.

---

Der agile Entwicklungsansatz greift ebenfalls auf eine Aufwandsschätzung zurück. Es wird aber nur eine relative Aufwandsschätzung als Grundlage zur Priorisierung umzusetzender „User Stories“ benötigt. Die Schätzung umfasst damit nicht den Projektaufwand, sondern betrachtet isoliert den jeweiligen Aufwand zur Umsetzung einzelner „User Stories“. Die Aufwände einzelner „User Stories“ in Relation zueinander, bilden dann die Grundlage zur Priorisierung.
Schon bei der Umsetzung von Anforderungen in „User Stories“ wird die Aufteilung mit Blick auf den Aufwand vollzogen. Eine „User Story“ soll idealerweise innerhalb eines Sprints umgesetzt werden können.
Der Ressourcenbedarf wird durch die agilen Teams bestimmt. Ein agiles Team bündelt im Idealfall alle notwendigen Experten für die Umsetzung von Anforderungen bis hin zum Betrieb.
Die Zusammensetzung und Größe eines solchen „Cross-Domain“ Teams ergibt dann den zur Zeitachse linearen Aufwand für die Planung.
Die Notwendigkeit einer zusätzlichen Budgetplanung hängt von den Anforderungen, der Organisationsform und dem Bedarf an extern zu beziehenden Leistungen ab.

Zeitmanagement
Projektzeitplan

Der Projektzeitplan fasst die zeitliche Abfolge, die Dauer und die Abhängigkeiten der ermittelten Tasks zusammen und stellt diese in den Kontext definierter Meilensteine. Jede Task sollte ein dokumentiertes Ergebnis bereitstellen, welches geprüft und freigegeben werden kann.

Abhängig von der Größe eines Projektes entstehen oft mehrere voneinander abhängige Pläne, deren Gemeinsamkeiten mindestens die Basis-Meilensteine darstellen.

Die Kunst besteht darin, einen übersichtlichen Projektzeitplan zu gestalten, der neben den Basis-Meilensteinen alle wesentlichen Tasks enthält. Bei zu kleinteiliger Aufsplittung der Tasks entsteht leicht ein zu detaillierter Projektzeitplan, der unübersichtlich wirkt und einen immensen Aktualisierungsbedarf mit sich bringt.
Die Aufteilung in einen Master-Plan und untergeordnete Teilprojektpläne wirkt diesem Problem entgegen.
Zusätzlich kann ein Projektzeitplan um Planungsdaten, wie zum Beispiel einer Ressourcenplanung und einer Budgetplanung ergänzt werden. Die bekannten kommerziell vertriebenen Projektmanagement-Tools bieten entsprechende Funktionalitäten, auch um diverse zeitliche Abhängigkeiten zu definieren.

Eine simple Projektzeitplanung kann unter gegebenen Umständen auch auf Basis eines mit einer Tabellenkalkulation erzeugten Projektzeitplans erfolgen. Excel, Calc etc. haben den Vorteil, auf nahezu jedem Arbeitsplatz zur Verfügung zu stehen und keinen zusätzlichen Einarbeitungsaufwand zu benötigen.
Für komplexe Projekte sollte aber dringend die Einführung eines Projektmanagement-Tools in Erwägung gezogen werden.

---

Das agile Entwicklungsvorgehen nutzt an Stelle eines Projektzeitplans ein festes Zeitraster (Sprint), ohne dabei vorab die zu bearbeitenden Anforderungen zu planen. Dies würde dem flexiblen iterativen Ansatz entgegenstehen.
Der Ablauf ist dynamisch und wird jeweils nur für einen bzw. eine geringe Anzahl von Sprints fest geplant. Hierzu legt das agile Team zusammen mit dem „Product Owner“ die als nächstes zu bearbeitenden Anforderungen fest. Die Verwaltung noch offener Anforderungen in Form von „User Stories“ übernimmt ein Backlog. Idealerweise beschreibt eine „User Story“ Anforderungen in der Art, dass eine Umsetzung in einem Sprint erfolgen kann.
Zur Statuskontrolle dient häufig ein Scrum- oder Kanban Board, das die ausgewählten und umzusetzenden Anforderungen in dem jeweils entsprechenden Status und einer Ressourcenzuordnung darstellt.

Der reinen Lehre folgend, sollen alle zur Umsetzung einer „User Story“ benötigten Schritte parallel ablaufen. Das ausspezifizieren der „User Story“, die Kodierung und die Qualitätsprüfung, da ansonsten das Vorgehen wieder dem klassischen Wasserfallmodell auf Ebene der „User Story“ gleicht.
Einige Programmiersprachen unterstützen dieses Vorgehen, in dem spezielle Kommentare zur Dokumentation zur Verfügung stehen und Software-Test ebenfalls innerhalb der Implementierung zur Umsetzung einer „User Story“ verfasst werden können.
Die Testautomatisierung ist ohnehin ein wichtiger Schritt hin zu einer agilen Software-Entwicklung, um die Qualität der vermehrten Lieferungen überprüfen und nachweisen zu können.

Der iterative Ansatz der agilen Methodik ermöglicht schnell erste Ergebnisse zur Projektzielüberprüfung sichtbar zu machen. Dem Anforderer kann so der Projektfortschritt vermittelt werden, als auch die Möglichkeit Fehlentwicklungen frühzeitig zu erkennen und korrektiv einzugreifen.

Qualitätsmanagement

Qualitätsmanagement bezogen auf ein Projekt, wenn es sich nicht gerade um ein Qualitätsmanagement-Projekt handelt, bezieht sich im Wesentlichen auf den Aspekt Qualitätssicherung. Eingebettet in eine Organisation sind jedoch Qualitätsvorgaben zu erfüllen, ein Qualitäts-Reporting aufzusetzen und der Qualitätsverbesserungsprozess zu berücksichtigen.

Die Qualitätssicherung für ein Projekt kann, je nachdem welche Aspekte zu berücksichtigen sind, sehr umfangreich ausfallen. Vorgaben zur Einhaltung von Qualitätsnormen, Regularien wie die DSGVO und Vorgaben zu Systemsicherheit spielen hierbei eine große Rolle.
Alle diese Aspekte müssen in die klassischen qualitätssichernden Maßnahmen integriert werden, um mit einer projektspezifischen Qualitätssicherung die Konformität zu prüfen.
Zu den klassischen qualitätssichernden Maßnahmen zählen nicht funktionale Tests wie zum Beispiel Reviews und Code-Inspektion, und die Durchführung funktionaler Test in Form von Regression-Tests, Test der Neufunktionalität sowie Penetrationstests.

Kommunikations-management

Kommunikationsmanagement betrachtet Kommunikationsaspekte innerhalb und außerhalb eines Projektes. Hierzu zählt planbare Kommunikation in Form von Reports ebenso, wie Maßnahmen, die den direkten Austausch innerhalb von Projekt-Teams fördern. Eine geeignete Maßnahme für letzteres wäre, die Zusammenführung der physischen Arbeitsplätze auf einer Bürofläche, die dem Projekt dediziert zur Verfügung steht.
Planbare Kommunikation in der Form Was, Wie und Wozu kann ein Verzeichnis zur Planung der Projektkommunikation und zum Umgang mit den Stakeholdern abbilden.
Der Begriff Stakeholder ist sehr weit fassend. Damit werden nicht nur die unmittelbar in einem Projekt involvierten Personen erfasst, sondern darüber hinaus auch Personen, die in irgendeiner Weise Einfluss auf das Projekt nehmen können, oder mit den Auswirkungen des Projektes leben müssen. In größeren Organisationen werden hierzu Kontaktpersonen als „Single Point of Contact“ bestimmt, die dann als Mittler zwischen den Mitarbeitern der jeweiligen Organisationseinheit und dem Projekt fungieren. Zusätzlich sind die Entscheider auszumachen.

Bei dem Kommunikationsverzeichnis geht es zum einen darum, ein für alle im Projekt zugängliches Verzeichnis zur Verfügung zu stellen und zum Anderen darum, kenntlich zu machen, welche Personen in welche Kommunikationsabläufe einzubinden sind.
Also Was wird Wie und Wozu (an wen) kommuniziert, um alle Stakeholder mit den für sie relevanten Informationen zu versorgen.
Es handelt sich hierbei um die planbare, aktive Kommunikation und beinhaltet Reports, Meetings, Open-Issues, ToDo’s, und auch geplanten informellen Informationsaustausch.
Ergänzend stellt eine Projekt-Dokumentenablage alle erfassten Informationen zur Verfügung, um berechtigten Personen jederzeit Zugriff auf die Projekt-Dokumente zu gewährleisten.

Das Kommunikationsverzeichnis beinhaltet zweckgebunden personenbezogene Daten wie den Namen, die Rolle, die Organisationszugehörigkeit und Kontaktdaten. Wie in einer Organisation damit umzugehen ist, ist mit dem jeweiligen Datenschutz-Experten zu klären.

Risikomanagement

Der Begriff Risikomanagement umfasst die Themen Risiko-Identifikation, Risiko-Bewertung, Maßnahmen zur Schadensbegrenzung und den entsprechenden Prozess zur Risikoverwaltung.

Die Identifikation von Risiken ist dabei der schwierigste Teil, denn Risiken sind selten offensichtlich und nie planbar. Typische Risiken wären zum Beispiel:

Risiko – Beispiel I
Neue Regulierungsvorschriften, deren Entwurf angekündigt oder bekannt ist, die Ausgestaltung und letztendlich die zu berücksichtigen Fakten aber noch unklar sind

Risikoeintritts-wahrscheinlichkeit		hoch
Risiko-Auswirkung		von den Auswirkungen der Vorschriften auf das Projekt abhängig
	auf Budget	niedrig bis hoch
	auf Zeit	niedrig bis hoch
	auf Qualität	niedrig bis mittel
Risiko-Begrenzung		Flexibilität bezüglich Vorschriften einbauen, Abhängigkeiten in einem separaten Modul kapseln, enge Nachverfolgung neuer Versionen

Risiko – Beispiel II
Abhängigkeit von Experten, da Rollen nur einfach besetzt sind

Risikoeintritts-wahrscheinlichkeit		mittel
Risiko-Auswirkung		von der Expertenrolle und den Auswirkungen auf das Projekt abhängig
	auf Budget	niedrig (bei kleinen Projekten evt. auch hoch)
	auf Zeit	niedrig bis hoch
	auf Qualität	niedrig bis mittel
Risiko-Begrenzung		Marktsondierung, sind Experten verfügbar? Aufbau eines zweiten Experten

Risiko – Beispiel III
Abhängigkeit von externen Produkten oder anderen Projekten

Risikoeintritts-wahrscheinlichkeit		niedrig bis hoch
Risiko-Auswirkung		von der Abhängigkeit im Bezug auf die Auswirkungen auf das Projekt abhängig
	auf Budget	niedrig bis hoch
	auf Zeit	niedrig bis hoch
	auf Qualität	niedrig
Risiko-Begrenzung		Flexibilität bezüglich Abhängigkeit einbauen, Abhängigkeiten in einem separaten Modul kapseln, enge Nachverfolgung der Produkte / Projekte

Risiko – Beispiel IV
Abhängigkeiten vom Marktgeschehen, Konkurrent platziert ein ähnliches Produkt

Risikoeintritts-wahrscheinlichkeit		niedrig bis hoch, Einschätzung erfordert Marktkenntnisse
Risiko-Auswirkung		vom Konkurrenzprodukt abhängig
	auf Budget	niedrig bis hoch
	auf Zeit	niedrig bis hoch
	auf Qualität	niedrig bis hoch
Risiko-Begrenzung		Marktsondierung Alleinstellungsmerkmale

Neue oder geänderte Anforderungen hingegen stellen in der Regel kein Projektrisiko dar. In der Regel, weil neue Anforderungen aus einem Risiko heraus entstehen können, wobei die neuen Anforderungen aber nicht das Risiko darstellen, sondern dem Umgang mit einem Risiko geschuldet sind.
Der Prozess zum Umgang mit Anforderungsänderungen ist Bestandteil des Projektmanagements und an anderer Stelle beschrieben.

Zur Identifikation von Risiken eignet sich ein Brain-Storming im Projektteam, als Besprechung oder Workshop organisiert, um die Vielfalt der möglichen Einflussfaktoren Best möglichst abzudecken. Darüber hinaus ist die Kontinuität des Risikomanagements zu gewährleisten, in dem zum Beispiel ein fester Slot im regulären Statusmeeting reserviert wird.

Die Bewertung eines Risikos hinsichtlich der Eintrittswahrscheinlichkeit, den Auswirkungen auf Budget, Zeit und Qualität, erfordert projektspezifische Kenntnisse, Kenntnisse zu den relevanten Geschäftsprozessen und gegebenenfalls auch Marktkenntnisse. Diese Aufgabe eignet sich daher ebenfalls, in Form der Risiko-Identifizierung mit bearbeitet zu werden.
Eine Beschreibung der Risiko-Begrenzung (Risk Mitigation) hingegen kann deutlich mehr Zeit erfordern, als typischerweise in einer Besprechung dafür zur Verfügung steht. Auch ist dafür selten das ganze Projektteam notwendig. Die Aufgabe kann einzelnen Personen zugeordnet werden.

Die Verantwortung für ein Risiko sollte definiert sein. Die verantwortliche Person kümmert sich um die Maßnahmen zur Risiko-Begrenzung und Nachverfolgung. Ist keine Person benannt, fällt diese Aufgabe automatisch dem Projektmanager oder im agilen Umfeld, wenn kein Projektmanager eingesetzt wird, dem „Product Owner“ zu.

Risiken sind im Projektstatus-Report aufzuführen und die Risiko-Entwicklung so dem Projektteam und dem Lenkungskreis (SteerCo) bekannt zu machen. Ferner sind die Risiken im Lenkungskreis zu besprechen, und wenn notwendig Entscheidungen herbeizuführen.

Der Umgang mit Risiken gilt für eine agile Organisationsform entsprechend, wobei Risiken in der agilen Vorgehensweise anders bewertet werden, als unter der planbaren Vorgehensweise.
So wird das Risiko aus Beispiel I, unter der Annahme, dass das Risiko erst zur Projektlaufzeit bekannt wurde, in Form neuer Anforderungen in das „Backlog“ aufgenommen. Es wird so gesehen gar nicht als Risiko wahrgenommen.

---

1) PMI Köln Chapter: „How agile are companies in Germany?“
    https://www.pmicc.de/survey_agile_companies

2) Project Canvas
    https://overthefence.com.de/tools/

3) SAFe^® – Portfolio Canvas
    https://v46.scaledagileframework.com/portfolio-canvas/#