Folge 007 // Der Projektplan – dein Weg zum Erfolg [On The Road]

von Benjamin Michels | Mai 9, 2018 | 0 Kommentare

In dieser Episode geht es um das spannende Thema: der Projektplan im Projektmanagement. Ich erkläre dir, wann du ihn erstellen solltest und ich zeige dir wie dich ein Projektplan zum Erfolg führen kann.

Hier findest du alle Episoden vom Podcast Projektmanagement leicht erklärt.

Shownotes

Weitere Informationen zum Ablaufplan (Gantt) findest du in diesen Blogbeiträgen:

Ich habe dir 3 Artikel zusammengestellt, wo du mehr zum Thema Projektstrukturplan erfährst.

_____
• Eine kostenlose Beratung kannst du hier buchen.
• Du möchtest mehr über Projektmanagement lernen? Hier geht es zu meinem Kurs.
• Unterstützung vom Projektmanagement-Profi: Kostenlose Projektmanagement Community
• Hier findest du meinen YouTube-Kanal.
• Folge mir auf Facebook.
• Werde Mitglieder in meiner Facebook-Gruppe “Projektmanagement leicht erklärt”.

Episode 007: Der Projektplan – dein Weg zum Erfolg

Hallo und herzlich willkommen zu dieser neuen Episode. Ich freue mich ganz besonders, dass du dabei bist. Heute reden wir über den Projektplan im Projektmanagement und wie dich ein Projektplan zum Erfolg bringen kann. Lass uns anfangen.

On the Road.

Das ist wieder ein Teil „On The Road“. Das heißt, ich sitze im Auto und nutze die Zeit sinnvoll, um dir das bestmögliche an Wissen mitzugeben. Der einzige Nachteil dabei ist natürlich, dass die Soundqualität ein kleines bisschen schlechter ist. Aber dafür werde ich mich bemühen, dass die Inhalte, die du bekommst, umso besser sind. Und natürlich halte ich kein Mikrofon in der Hand oder bin stark vom Autofahren abgelenkt. Nein, keine Sorge. Ich starte das Mikro, bevor die Fahrt beginnt. Und ich stoppe die Aufnahme auch erst, wenn die Fahrt endet.
Den Rest macht dann natürlich Janine, die das Ganze schneidet.

Der Projektplan.

Jetzt wollen wir aber direkt in die Thematik des Projektplans reingucken.
Ich habe ja im Titel verkündet, dass ein Projektplan dein Weg zum Erfolg ist. Davon bin ich wirklich überzeugt, weil ich immer und immer wieder im Projektplan lande. Wenn ich komplexe Zusammenhänge, komplexe Vorhaben oder auch einfache Vorhaben habe. Dann führt mich mein Weg fast automatisch auf den Projektplan. Das ist immer der nächste logische Schritt, um zu definieren, wie wir das Ganze angehen können. Und dabei muss einem einfach bewusst sein, wie Projekte grundsätzlich funktionieren – auch von der rein menschlichen Denklogik.
In der Regel haben wir als erstes den Schritt, dass wir uns überlegen: Wo wollen wir eigentlich hin? Wo soll unsere Reise hingehen? Das heißt, wir reden immer zuerst über die Ziele. Wir fragen uns: Was soll nach dem Projekt anders sein? Der Projektplan ist am Ende unser Navigationssystem. Er sagt uns deutlich, wie wir diesen Weg gehen können. Diese Information darüber stammt natürlich von uns selbst. Die fällt jetzt nicht einfach vom Himmel. Dieses Wissen ist in uns. Aber uns wird im Endeffekt durch die Methode des Projektplans dabei geholfen, das in eine strukturierte Darstellung zu bringen.

Und hierbei ist die Frage sehr angebracht: Was ist eigentlich ein Projektplan? Hier muss ich ganz ehrlich sagen: es ist nicht hundertprozentig eindeutig definiert. Es gibt nämlich unterschiedliche Formen von Projektplänen. Die beiden bekanntesten sind der sogenannte Projektstrukturplan und der Ablaufplan (auch Gantt-Diagramm genannt). Im Projektstrukturplan ist es so, dass wir in einer Art Baumdarstellung – manchmal auch in einer reinen Tabellendarstellung – alle Teilprojekte und alle Arbeitspakete aufgelistet sehen. Im Gantt-Plan haben wir dazu noch die Zeitachse. Das heißt, die Information, wann welches dieser Arbeitspakete stattfindet. Und je nachdem, wie du in deinen Projektteams arbeitest, ist beides notwendig, nur eines von beiden oder vielleicht auch nichts. Vielleicht hast du auch noch eine dritte Form von Projektplan. Aber das sind für mich die erfolgsträchtigen.

Wenn du dich mehr dafür interessierst: Ich werde ein paar Links unter die Shownotes packen. Wie erreichst du die? Ganz einfach. Du gibst benjamin-michels.de/007 ein. Und über diesen CodeSling kommst du dann zu den Shownotes und dort werden wir dir alles, was wir rund um Projektstrukturplan und um Gantt-Plan haben, mit reinpacken. Und du kannst es dir direkt angucken. Da sind viele praktische Tipps – unter anderem, wie du innerhalb von einer Stunde einen Ablaufplan für ein Projekt innerhalb von Excel erstellst. Also ich kann es nur empfehlen: Gucke in die Shownotes rein!

[thrive_leads id=’29658′]

Ein Praxisbeispiel.

Wie machen wir es bei uns?
In der Regel lege ich erst einmal einen Projektstrukturplan an. Das heißt, es gibt noch keine Zeitachse, sondern es gibt erst einmal nur die Arbeitspakete – also das, was zu tun ist. Die Zeitachse folgt dann später und in der Regel auch auf eine andere Art und Weise. Wir haben eine Vielzahl von Projekten gleichzeitig laufen. Und ich takte die Arbeitspakete der unterschiedlichen Projekte je nach Prioritäten und Abhängigkeiten. Nehmen wir zum Beispiel an, die Facebook Ads für ein neues Produkt können erst geschaltet werden, wenn die Wissensquelle – zum Beispiel in einem Projekt haben wir eine Ärztin – wenn sie die Videos aufgenommen hat. Dann genießen diese Videos unter Umständen eine höhere Priorität, einfach aufgrund der Abhängigkeit zu den Facebook-Werbeanzeigen. Und genauso kann das in anderen Projekten auch sein. Ich muss also immer einen Überblick über alle Arbeitspakete in allen Projekten haben. Und ich muss verstehen, wie die Abhängigkeiten zwischen den Projekten gestrickt sind und wie die Abhängigkeiten zwischen den Arbeitspaketen gestrickt sind. Das muss ich dann auf meine Teammitglieder verteilen, weil ich mich natürlich fragen muss: Wer kann was wann wie machen? Ich kann der Designerin nicht vier verschiedene Corporate Design Projekte geben, die alle in der gleichen Woche stattfinden. Das wäre viel zu schwierig für sie, sich da in diese ganzen unterschiedlichen Dinge reinzudenken. Das heißt, wir müssen dann eher versuchen, thematisch zu arbeiten und dafür sorgen, dass sie dann eins, zwei Wochen am Stück nach Möglichkeit in dem gleichen Projekt arbeitet.

In der Regel haben wir im Hintergrund einen Projektstrukturplan liegen, der als Orientierung dient, und ein sogenanntes Taskboard. Das ist ein cloudbasiertes Board, was in Kanbanflow abgebildet ist. In diesem Taskboard finden sich dann nach Kalenderwochen sortiert die Aufgaben für die einzelnen Teammitglieder. Und so decke ich auf der einen Seite den Projektstrukturplan ab, auf der anderen Seite decke ich den Ablaufplan damit ab und habe im Großen dann meinen Projektplan. Die nächste logische Frage ist natürlich, wann ich den Projektplan nutze. Denn es wird Projekte geben, die sind zu einfach, um ihn zu nutzen. Und es gibt Projekte, die sind so komplex, dass es ganz klar ist, dass ich ihn brauche. Doch gerade am Anfang, wenn du vielleicht auch noch nie mit einem Projektplan gearbeitet hast, macht es Sinn, so ein bisschen darüber nachzudenken: Wann brauche ich den denn eigentlich?

Es gibt eine Grundregel: wenn es sehr komplex ist, dann brauchst du auf jeden Fall einen Projektplan.

Das heißt, wenn die Dinge, die zu tun sind, für dich nicht wirklich überschaubar wirken, dann solltest du dich hinsetzen und einen Projektstrukturplan entwickeln. Dieses „überschaubar“ ist natürlich ein höchst subjektives Gefühl. Das ist auch normal. Denn das, was du auf methodischer Ebene brauchst, hängt im Grunde von zwei Komponenten ab: Einmal von deiner Erfahrung mit dieser Art von Projekten und von der Komplexität des Projektes selber. Und das hängt halt ganz stark zusammen. Also je mehr Erfahrung du hast, desto weniger komplex nimmst du Projekte natürlich auch wahr. Und hierbei geht es nicht zwangsweise um das Budget, das ein Projekt hat, sondern vielmehr um die Anzahl der Arbeitspakete – also das, was im Projekt zu tun ist – und die Abhängigkeit zwischen den Arbeitspaketen. Sehr viele Arbeitspakete mit hohen Abhängigkeiten oder zum Beispiel auch hohem Risiko können die Komplexität des Projektes massiv steigern. Und in dem Fall brauchst du dann auf jeden Fall einen Projektplan – gerade weil du ja die Komplexität reduzieren willst. Wir nutzen diese Methoden immer, um Komplexität zu reduzieren. Und ich kann es nur empfehlen. Ich nutze es nicht nur zur Strukturierung von komplexen Zusammenhängen, sondern ich nutze es auch als Sales Pitch.

Was heißt das? Das habe ich in einer vorherigen Podcast Episode schon mal erzählt. Es ging um den Projektleiter als Servicekraft. Es ist ja so, dass ich interne Projekte mache, die auf meiner Idee beruhen. Wir organisieren gerade eine größere Konferenz, die ausschließlich auf meiner Idee beruht. Wir machen aber auch Projekte für andere. Und die entstehen meistens auf die gleiche Art und Weise. Das heißt, ich komme mit Menschen in Kontakt durch Themen, für die ich mich interessiere, durch Themen, in denen ich gerade arbeite. Und meistens schreibe ich die dann an und frage, ob wir uns nicht einmal unterhalten wollen. Ich könnte ihnen ein paar Tipps mit auf den Weg geben. Dazu kommt es dann relativ oft. Also ich würde sagen, in neun von zehn Fällen reagieren die Menschen, denen ich sage, ich hätte ein paar Tipps für sie, wenn sie Interesse haben, sehr positiv darauf und wir kommen in das erste Gespräch. In dem ersten Gespräch höre ich mir an, wo denn ihre Probleme und Herausforderungen sind, wo ihre Ziele sind und wo die Reise hingehen soll. Und im Grunde genommen mache ich eine Zielabfrage. Das ist der anderen Seite meist nicht so bewusst, aber meinem Schemata nach ist es ganz klar eine Zielabfrage. Und darauf basierend überlege ich mir dann den besten Weg, wie man dieses Ziel erreichen kann. Das heißt, in meinem Kopf entwickelt sich dann schon automatisch – dagegen kann ich auch eigentlich gar nichts tun – der Projektplan. Nun ist dann der nächste Schritt, dass ich diesen Projektplan visualisiere. Das heißt, ich schreibe auf, welche Teilprojekte es gibt. Ich schreibe auf, welche Arbeitspakete es gibt. Und in der Regel sind die anderen von alleine schon dieser Struktur so beeindruckt, dass ich sie für mich gewonnen habe und dass sie sagen: „Benny,“ oder „Herr Michels,“ – je nachdem, wie sie mich nennen – „setze doch das Projekt für uns um. Oder anders gesagt: Was müssen wir tun, damit du dieses Projekt für uns umsetzt?“ Und da sieht man ganz deutlich, dass der Projektstrukturplan ein bewährtes Tool, eine bewährte Methode ist, um Projekte so zu visualisieren, dass andere sie verstehen. Denn wenn ich einfach nur die Gedanken in meinem Kopf formuliert hätte, dann wäre das schon ganz gut gewesen. Es wäre aber für den Sales Pitch definitiv nicht ausreichend. Es braucht für die meisten Menschen die visualisierte Komponente. So wirst du zum Beispiel in meinem Blog sehen, dass in jedem meiner Beiträge mindestens eine Abbildung ist, die den Zusammenhang dessen, was im Beitrag steht, erklärt. Visualisierungen sind unheimlich wichtig für die Menschen. Und das werde ich dir auch immer sagen. Wenn es zum Beispiel um Controlling-Berichte geht, dann brauchst du auch eine Visualisierung. Für die Leute muss klar sein, was sie sich da angucken. Und sie müssen es schnell erfassen können. Und dafür ist der Projektstrukturplan einfach eine ganz tolle Möglichkeit.

Agilität vs. Statik.

Ich könnte ja auch im Sales Pitch noch tiefer reingehen und sagen: „Legen wir es mal auf die Zeitachse. Gucken wir mal, wie wir es zeitlich gestalten können.“ Und dann lege ich für jedes Arbeitspaket einen Anfang und ein Ende fest – also einen Termin. Und daraus ergibt sich dann wiederum der Ablaufplan. Und dann habe ich die zwei großen Komponenten des Projektplans. Das heißt, wir nutzen den Projektplan für uns selber, um die Komplexität zu reduzieren. Wir nutzen den Projektplan aber auch für andere, um ihnen unser Projekt oder unsere Projektvorstellung verständlich zu machen. Jetzt ist es aber auch weiterhin so, dass wir zwischen Agilität und Statik gefangen sind.
Was meine ich damit? Es gibt agiles Projektmanagement und es gibt statisches Projektmanagement – auch bezeichnet als Wasserfall-Projektmanagement. Nehmen wir an, wir haben jetzt einen Ablaufplan. Wir können alles ziemlich genau vorher sagen. Wir wissen, wann was stattfindet. Dann sind wir ganz klar im statischen Projektmanagement, weil wir den Weg schon vorher kennen. Wir kennen das Problem und wir kennen die Lösung. Wir müssen es nur noch machen. Und unser Projektplan ist statisch. Er ist halt ein ganz klar vorgegebener Weg. Im agilen Projektmanagement haben wir noch mehr Unsicherheiten. Vor allem haben wir die Unsicherheit über den Weg. Das heißt, wir wissen nicht genau, welchen Weg wir am Ende nehmen werden. Wir kennen das Problem und wir haben eine Idee für den Lösungsansatz. Wir wissen aber nicht, ob es auch der Lösungsansatz ist, den wir am Ende nehmen werden. Und das führt wiederum dazu, dass wir immer nur in kleinen Schritten planen können. Das heißt, wir planen die nächsten drei, vier Schritte und entwickeln dann darauf basierend die darauffolgenden Schritte. Und dann gehen wir wieder ein paar Schritte und überlegen uns dann erneut, wie es jetzt weitergehen könnte. Das heißt, es kann sein, dass wir zu einer vollkommen anderen Lösung kommen als wir am Anfang gedacht haben, weil wir unseren Weg vorher noch nicht kennen. Und ich habe ja eben einleitend gesagt: Wir sind gefangen zwischen statischem und agilem Projektmanagement. Das heißt, wir müssen uns rein theoretisch entscheiden.

Hier mache ich in der Regel eine Mischlösung. Ich habe ja viele Projekte im Bereich Unternehmensaufbau oder Business Development – also Unternehmensentwicklung. Und da sind die Unsicherheiten unheimlich groß. Wir wissen oft nicht, wie die perfekte Lösung ist, und die stellt sich erst im Laufe des Projektes heraus. Das heißt aber nicht, dass ich nicht wenigstens eine grobe Idee vom Weg haben will. Ich lege also in der Regel einen Projektstrukturplan an, der mir als grobe erste Orientierung dient, wie der Weg durch ein Labyrinth. Wenn die Abzweigungen sich so zeigen, wie ich sie zum jetzigen Zeitpunkt vermute, dann werden wir diesen Weg gehen. Wenn sich die Abzweigungen anders zeigen, dann werden wir einen anderen Weg gehen. Das heißt, ich habe zwar auf der einen Seite den sehr statischen Projektstrukturplan, der mir konkret sagt, was ich zu tun habe. Ich bin aber auf der anderen Seite bereit, diesen ganz schnell über den Haufen zu werfen aufgrund von neuen Erkenntnissen und nochmal neu zu planen beziehungsweise noch einmal sehr stark anzupassen. Und ich bin in dem Zusammenhang sogar bereit, auch die Ziele nachträglich zu verändern – etwas, was ich im Projektmanagement normalerweise nicht empfehlen würde, muss ich ganz deutlich sagen, machen wir ganz viel und ganz aktiv. Das muss man aber können. Also das ist ja bei vielem so, dass man das können muss, aber hier nochmal ganz besonders, denn da kann man auch ganz schnell verloren gehen in der Unverbindlichkeit. Das heißt: „Naja, ich habe zwar einen Projektstrukturplan, aber ich halte mich nicht dran.“ Jeder macht irgendwie irgendwas. Keiner hat den Hut auf. Die Kosten werden dabei nicht im Blick behalten. Die Ressourcen wie Arbeitszeiten werden dabei nicht im Blick behalten. Das sind die Risiken, die damit einhergehen. Und davor muss ich mich natürlich schützen.
Bei uns ist es so: Ich habe natürlich weiterhin den Hut auf. Ich treffe diese Entscheidungen als Projektleiter, ob es zu den Veränderungen kommt oder nicht. Ich bin mir bewusst, welche Kosten dadurch entstehen. Ich bin mir bewusst, welche Verschiebungen auf der Zeitachse entstehen. Und ich bin mir bewusst, wie die Personal-Zeitressource sich dadurch verändert. Und dann darf ich auch diesen Weg gehen. Dann darf ich zwischen Statik und Agilität hin- und herpendeln. Das ist eines der erfolgreichsten Formate, das ich für mich gefunden habe, ganz konkret zu sagen: Wir planen eine Grundstatik voraus, sind aber jederzeit bereit, uns davon zu lösen, und wenn wir ein paar Schritte gemacht haben, einen erneuten Plan zu machen – das heißt, das Ganze agil immer wieder anzupassen und kleine inkrementelle Entwicklungen herbeizuführen, also kleine Ergebnisse auszuliefern. Ich denke, ich werde nochmal eine eigene Podcast Episode machen, die sich nur dieser Thematik der Agilität widmet und das gegenüber Statik stellt und sich mit der Frage befasst: Wie kann man damit eigentlich umgehen?

Ablauf-, Funktions- oder Objektorientierung?

Jetzt sind wir aber noch im Projektplan und da sei gesagt: Es gibt natürlich auch unterschiedliche Möglichkeiten, wie du das Ganze strukturieren kannst. Das heißt, du kannst natürlich ablaufstrukturiert machen, dir also überlegen: Was muss der Anfang sein? Was kommt dann, dann, dann und dann, bis wir zum letzten Arbeitspaket kommen?
Du kannst das aber auch zum Beispiel funktionsorientiert machen, wenn du mehrere Abteilungen hast, dass du dir die Frage stellst: Was hat welche Abteilung zu tun?
Und dann hast du noch die Möglichkeit, es objektorientiert zu machen. Das heißt, du richtest dich an dem aus, was du da entwickelst, herstellst, baust, umbaust – das wird meistens für Produkte genommen – und teilst das Produkt in seine Kleinstteile und machst dann Arbeitspakete für die jeweiligen Teile.
Gerade zum Anfang bei nicht allzu komplexen Projekten empfehle ich dir unbedingt eine Ablauforientierung. Du überlegst dir wirklich ganz konkret: Womit fangen wir an? Welcher Schritt folgt dann? Welcher Schritt folgt dann? Das macht es oft deutlich einfacher, macht es für dich in der Regel auch verständlicher. Einfach weil du dann schon den Ablauf grob im Kopf hast und vor allem über Abhängigkeiten schon mit nachdenken kannst. Werden Projektpläne komplexer, dann tendiert es in der Regel zu einer Funktions- oder Objektorientierung – meistens zu einer Funktionsorientierung. Das ist jedenfalls meine Erfahrung. Es kann auch zum Beispiel sein, dass du einen Projektstrukturplan nimmst, die Teilprojekte dann funktionsorientiert sind – also zum Beispiel Administration, Vertrieb, Marketing, Buchhaltung und so weiter. Das sind die Teilprojekte. Und die Arbeitspakete in den Teilprojekten sind dann wiederum ablauforientiert. Das wäre auch eine Möglichkeit, wie man das Ganze gestalten kann.

Hier vielleicht auch nochmal der Tipp aus der Praxis: Bei mir ist es so, dass ich die ganz oft ablauforientiert mache, weil ich damit einfach schon den Ablaufplan halb mit erschlage. Und dann gehen sie aber meistens in eine Funktionsorientierung über – nämlich dann, wenn sie ins Task-Management überführt werden. Das heißt, im Taskboard hat jeder Mitarbeiter seine Spalte. Und die Mitarbeiter führen natürlich einzelne Funktionen aus. Das heißt, ich strukturiere dann die Arbeitspakete nach Funktionen. Und gleichzeitig habe ich sie auch noch in der Zeitachse, weil wir ja in der zweiten Dimension immer in Kalenderwochen sind und die Arbeitspakete dann in die jeweiligen Kalenderwochen eingetaktet sind. Also du merkst, das Thema Projektplan ist durchaus ein bisschen komplexer, ein bisschen umfangreicher. Ich glaube, man kann unheimlich viel daraus mitnehmen, wenn man Projektpläne macht. Ich kann auch nur empfehlen, sie öfter mal im Kopf zu machen. Mit dem Rat muss man ein bisschen vorsichtig sein. Also wenn du es für ein echtes Projekt machst, dann mache sie bitte auf Papier. Nimm dir von mir aus ein Kanbanflow oder ein Trello. Nimm dir eine Excel-Datei oder mache es wirklich auf einem Blatt Papier. Verschriftliche es. Aber wenn du unterwegs bist und Dinge siehst – so geht es mir jedenfalls – nehmen wir an, wir wollen schon seit Längerem eine Kinderschaukel in den Garten bauen und ich sehe jetzt irgendwo eine Kinderschaukel stehen, dann frage ich mich: Wie könnte man diese Kinderschaukel bauen? Und in meinem Kopf entsteht dann ein Projektplan. Das ist für mich so eine Art Gedankenspiel, das ich immer wieder spiele. Also ich baue unter der Woche im Kopf zehn, fünfzehn Projektpläne, wo ich mich einfach nur frage: Wie könnte man das aufbauen? Und diese Vorgehensweise schult dein Denken rund um Projektmanagement. Diese Vorgehensweise schult dein Denken rund um Projektpläne. Und ich kann es unbedingt empfehlen, dass du anfängst, genau das zu machen.

Ich freue mich auf dein Feedback!

Wenn du mehr über Projektpläne wissen möchtest, wenn du mehr über Projektmanagement wissen möchtest, wenn du mehr Projekte machen willst und vor allem auch besser darin werden möchtest, dann abonniere unbedingt meinen Podcast. Denn ich werde dir ganz viele spannende Informationen liefern. Es werden auch immer wieder Interviews mit spannenden Leuten kommen wie zum Beispiel in Episode 006. Ich empfehle dir auch unbedingt, dass du mir eine E-Mail schreibst, wenn du sagst: „Ich möchte mehr darüber lernen. Ich möchte mit dir, Benjamin, in Kontakt kommen.“ Lass uns einfach miteinander sprechen. Ich gucke einfach mal rein, wie du dein Projektmanagement bisher machst und wo du noch Entwicklungspotential hast. Du kannst dich auch mit mir auf Facebook befreunden. Und wenn du sagst, die Episode hat dir etwas gebracht, dann bewerte mich auf allen Plattformen, die du finden kannst, mit fünf Sternen und sorge damit dafür, dass dieser super hochwertige, kostenlose Content weiter fortgeführt wird und du mehr von meinem Wissen partizipieren kannst.

Ich freue mich auf jeden Fall, dich in der nächsten Episode wieder zuhören. Und ich freue mich auch auf dein Feedback. Schreibe mir gerne auf Facebook. Schreibe mir unter meinen Blog, wie du die Episode gefunden hast und welche Themen du dir zukünftig wünschst. Dann bis zum nächsten Mal.

Unterstützung für dich

Du möchtest mehr über Projektmanagement lernen? Dann nutze jetzt die Möglichkeit für ein kostenloses Strategiegespräch und ich werde dir zeigen, wie du deine Projekte erfolgreicher leiten kannst.

[thrive_leads id=’29856′]