Einfache Projektplanung am Whiteboard

Tim Themann

vor 12 Jahren

Projektmanagement wird meiner Erfahrung nach gerade im Bereich der IT-Infrastruktur oftmals erstaunlich halbherzig betrieben. Der Ablauf folgt häufig einem einfachen Schema: Derjenige, der sich im jeweiligen Projektteam technisch/inhaltlich am besten mit dem Thema auskennt, wird explizit oder implizit zum Projektmanager „ernannt“. Dies wäre fatal, nähme sie oder er die Herausforderung auch tatsächlich an: Das Expertenwissen wäre der Nutzung weitgehend entzogen – der Experte wäre nicht mehr Bestandteil des Produktionsprozesses, sondern (Projekt‑)Manager. Ein technischer Experte ist allerdings nicht zwingend ein Projektmanagement-Experte. Expertenwissen kommt nicht von ungefähr, sondern entsteht typischerweise durch hohe Spezialisierung auf wenige (in diesem Fall technische) Themen – und Projektmanagement gehört oftmals eben nicht dazu. Zum Glück (?) bleibt uns zumindest dieses dann auch meist erspart: Dennoch als „Projektmanager“ für den Erfolg des IT-Projekts verantwortlich gemacht, bleibt dem Experten nichts anderes übrig, als seine wahren Fähigkeiten einzubringen – die bestmögliche Arbeit an den Projektinhalten zu leisten. Das Projekt bleibt faktisch ungemanagt und womöglich lehnen sich auch noch alle anderen Beteiligten gemütlich zurück: Der Experte/Projektmanager tut ja schon alles für den Erfolg!

Eine Doppelrolle wie sie geschildert wurde wirklich sinnvoll „unter einen Hut zu bringen“, erfordert viel Erfahrung und einen extrem reflexiven Umgang mit wechselnden „Hüten“¹. Ein Minimum an strukturiertem Projektvorgehen in die Projektorganisation eines nicht zu großen Projekts einzubringen, ist jedoch gar nicht schwer – auch nicht für IT-Spezialisten. Letztere neigen dazu, als allererstes nach der zu verwendenden Software zu fragen² – ich persönlich bevorzuge und empfehle zumindest für kleinere Projekte einfach verwendbare „Hardware“: Whiteboard und Haftnotizen³.

Projektplanung am Whiteboard

Projektplanung folgt in der Regel einem einfachen Schema⁴:

In einem ersten Schritt werden die Arbeitspakete gesammelt …
… und anschließend zu einem Projektstrukturplan quasi geclustert.
Ist man sich sicher – die strukturierte Darstellung des Projektstrukturplans hilft hier ungemein –, die notwendigen Tätigkeiten einigermaßen vollständig erfasst zu haben, gilt es, die Abhängigkeiten zu modellieren. Hierfür eignet sich z. B. ein extrem vereinfachter Netzplan. Neben den Arbeitspaketen werden in diesem Schritt auch weitere Voraussetzungen modelliert. Zudem ist zu hoffen, dass einem spätestens jetzt auffällt, welche Tätigkeiten man zuvor übersehen hat und in Form weiterer Arbeitspakete nachtragen muss.
Nun gilt es, die Aufwände für die Durchführung der einzelnen Tätigkeiten möglichst genau zu schätzen⁵ – die Grundlage u. a. für die Zeit- und Ressourcenplanung.
Anschließend können die Arbeitspakete auf die Teammitglieder verteilt und mit Terminen versehen werden.

Dies alles lässt sich extrem einfach allein oder (meines Erachtens besser) in der Gruppe zusammen mit allen Beteiligten – dem kompletten Projektteam – mit Haftnotizen am Whiteboard erledigen:

Arbeitspakete sammeln

Diese Phase als „Brainstorming“ zu bezeichnen, ist methodisch nicht einmal einigermaßen korrekt – auch, wenn es oft so aussieht: In der Regel haben die Mitglieder des Projektteams eine gute Vorstellung davon, welche Tätigkeiten zur Erreichung des Projektziels notwendig sind. Deswegen ist es meist zweckmäßig, die einzelnen Arbeitspakete ähnlich wie beim Brainstorming „auf Zuruf“ auf Haftnotizen (oder Moderationskarten⁶ oder z. B. wie im Falle der beispielhaften Abbildungen im Text auf Stattys Notes) aufzuschreiben und sofort (meist noch eher unsortiert) für alle sichtbar aufzuhängen.

Durch die gemeinsame Sicht auf die Sammlung wird jeder Teilnehmer animiert, Fehlendes zu suchen und beizutragen – die „innere Dynamik“ der Situation führt meist bereits jetzt auf eine sehr pragmatisch-einfache Weise zu annähernder Vollständigkeit. Sollte man zu diesem Zeitpunkt bereits zeitliche Aufwände auf den Haftnotizen vermerken wollen, sind alle an der Aufwandsschätzung beteiligt – die Güte der Schätzung dürfte steigen und die Partizipation am Prozess die Akzeptanz erhöhen.

Update 07.10.2019: Bitte keine Haftnotizen aufs Whiteboard kleben, sie hinterlassen Klebstoffreste. Verwenden Sie am besten elektrostatisch haftende Karten oder aber „normale“ Moderationskarten in Verbindung mit Magneten – Ihr Whiteboard wird es Ihnen danken!

Einen Projektstrukturplan erstellen

Nun gilt es, die Arbeitspakete sinnvoll zu strukturieren. Ergebnis ist ein mehr oder minder übersichtlicher Projektstrukturplan – gegliedert beispielsweise nach Projektphasen⁷:

Die Haftnotizen (lies: Arbeitspakete) werden so zu Teilaufgaben gruppiert und diese – z. B. mit Haftnotizen einer anderen Farbe oder direkt am Whiteboard – mit Bezeichnungen versehen. Fällt eine Tätigkeit auf, die zur Erreichung des Projektziels fehlt, wird sie ergänzt.

Da der erstellte Projektstrukturplan im nächsten Schritt der dem Whiteboard eigenen⁸ Vergänglichkeit zum Opfer fällt – die Haftnotizen neu und anders strukturiert werden – empfiehlt es sich, den Zustand jetzt durch ein Foto zu dokumentieren (vgl. das Kapitel „Dokumentieren“ ab S. 107 in den „Computermalern“).

Einen einfachen Netzplan erstellen

Entscheidend, jedoch selbst in kleineren IT-Projekten nur schwer zu überblicken sind die Abhängigkeiten der Arbeitspakete untereinander: In aller Regel sind fast immer unterschiedliche Experten am Projekt beteiligt – und deren Spezialisierungsgrad ist ob der komplexen Anforderungen moderner Unternehmens-IT oft so hoch, dass sie oft nur noch ihr Fachgebiet, nicht jedoch die Abhängigkeiten an den „Rändern“ oder gar außerhalb dieses Gebietes zu überblicken vermögen. Ein Netzplan stellt alle Abhängigkeiten innerhalb des Projektes kompakt dar:

Die vorhandenen Haftnotizen gemeinsam am Whiteboard zu einem (stark vereinfachten) Netzplan umzugruppieren und die Abhängigkeiten einzuzeichnen (vgl. „Die Computermaler“, S. 34 – 35), hilft, das gesammelte Wissen aller Experten im Projektteam zusammenzufassen und verständlich dargestellt zu „speichern“⁹.

Aufwände, Termine und Personen

Spätestens zu diesem Zeitpunkt sollten auch die zeitlichen Aufwände geschätzt worden sein – oft empfiehlt es sich, dies bereits früher im Prozess zu tun, da nicht alle Mitglieder des Projektteams bis zum Ende der Besprechung bleiben können oder wollen¹⁰. Da die geschätzten Aufwände eine (hoffentlich) recht konstante Eigenschaft des Arbeitspakets sind, können sie auf die Haftnotizen geschrieben werden (im Beispiel grün). Eine Zuordnung von Terminen und Personen zu den einzelnen Arbeitspaketen erfolgt am besten nicht auf, sondern neben den Haftnotizen am Whiteboard. Beide Informationen sind im Vergleich zur Bezeichnung des Arbeitspaketes wenig konstant.

Projektcontrolling am Whiteboard

Verfügt man über mehr als ein Whiteboard oder hat man z. B. die Möglichkeit, den Netzplan Haftnotiz für Haftnotiz auf eine Moderationswand „umzuziehen“, kann man die Visualisierung auch für ein sehr einfaches, für alle jederzeit sichtbares „Controlling“ des Projekts verwenden: Haken Sie Erledigtes ab und kennzeichnen Sie relevante Abweichungen. Falls der Projektumfang erweitert wird und durch „Changes“ neue Arbeitspakete hinzukommen, sollten Sie diese der Transparenz halber mit andersfarbigen Haftnotizen ergänzen.

Da Sie auf diese Weise mit „Zeit“ und „Qualität“¹¹ lediglich zwei der drei Ecken des „Magischen Dreiecks“ im Blick haben¹², ist diese Visualisierung natürlich nur ergänzend zu einem „echten“ Projektcontrolling¹³ zu verstehen – dafür aber für jeden verständlich und sichtbar: Das Whiteboard mit dem Netzplan könnte so zum Identifikation stiftenden Markenzeichen Ihres Projektteams werden.

Footnotes:

↑ Die Metapher vom „Hut“ ist hier bei Waldefried Pechtl entliehen, vgl. Pechtl, W.: Organismus und Organisation. Wegweiser und Modelle für Berater und Führungskräfte. Linz: Veritas 1995.
↑ Eine Variante von Abraham Maslows Hammer bzw. des „Law of the instrument“. An dieser Stelle sei insbesondere darauf hingewiesen, dass einschlägige Softwareprodukte zum Projektmanagement alles andere als trivial und ohne Schulung o. ä. kaum sinnvoll nutzbar sind – und vor allem (auch mit Schulung) keine Methodenkenntnisse zu ersetzen vermögen.
↑ Deutlich elaborierter findet sich ein ähnlicher Ansatz übrigens in Seifert, Josef W.: Projekt-Moderation. Projekte sicher leiten, Projektteams effizient moderieren. Offenbach: Gabal Verlag GmbH 2004.
↑ Diese Darstellung erhebt nicht den Anspruch, lege artis zu sein – Ziel ist vielmehr, trotz der eingangs geschilderten Problematik eine einigermaßen sinnvolle Projektorganisation anzuregen.
↑ Die Güte der Schätzung steigt, wenn man alle Beteiligten anhält, erst einmal ohne „Puffer“ zu schätzen. Den „Puffer“ kann man später immer noch dem Gesamtaufwand hinzufügen. Zur Problematik des „Puffers“ vgl. Goldratt, Eliyahu M.: Die kritische Kette: Das neue Konzept im Projektmanagement. Frankfurt: Campus, 2002. – ein Werk, das zu lesen auch für den „nebenberuflichen“ Projektmanager auf jeden Fall lohnend ist.
↑ Vgl. „Die Computermaler“, S. 30 ff.
↑ Alternativ z. B. objektorientiert am in seine Komponenten zerlegten Produkt – dem Projektgegenstand und seinen Teilen.
↑ Sieht man einmal z. B. von der versehentlichen Verwendung von Permanent-Markern ab.
↑ Vergessen Sie also nicht, das Ergebnis durch ein Foto zu dokumentieren. Whiteboard-Fotos lassen sich übrigens sehr schön mittels eines GIMP-Scripts aufbereiten, vgl. „Saubere Whiteboard-Fotos“.
↑ …, man jedoch auf ihre Expertise angewiesen ist oder sie beteiligen und damit „mit in’s Boot holen“ möchte.
↑ Mir sind eigentlich die Begriffe „Leistung“ oder „Inhalt“ lieber, „Qualität“ ist jedoch einschlägig.
↑ Böse Zungen behaupten, dass in IT-Projekten meist niemand die dritte Ecke – die Kosten, das Budget – im Blick hat, vor allem kein IT-Spezialist. Bitte helfen Sie dabei, mit diesem Vorurteil aufzuräumen.
↑ Zum Beispiel mit Microsoft Project – den bereits visuell festgehaltenen groben Netzplan in Microsoft Project zu übertragen, ist vor allem noch Fleißarbeit.