In Planungskreisen gibt es den Mythos, dass mehr Details besser und genauer sind. In der Ressourcenplanung sieht das aus wie riesige Tabellen mit den Namen von Mitarbeitern, die bestimmten Projekten über die Monate oder Wochen hinweg für mindestens ein Jahr zugewiesen sind. Wenn wir so viele Details planen können, muss es genau sein, oder? Nun, nicht so schnell. Es gibt drei Hauptprobleme bei diesem Ansatz:
- Es dauert lange, diese Tabellen zu erstellen und zu ändern.
Wenn Sie sehen wollen, was passiert, wenn Sie die Projekte A, B und D statt C, E und F abschließen, werden Sie wahrscheinlich bis spät in die Nacht arbeiten, um das Ziel zu erreichen. Und hoffen Sie lieber, dass Sie keine Formeln in der Tabelle durcheinander bringen, wenn Sie schon dabei sind. Und wenn mehr als eine Person auf die Tabelle zugreift, versuchen Sie, sich nicht gegenseitig auf die Füße (oder in die Zeilen) zu treten. Wenn Sie die Ressourcen für eine große Gruppe verwalten, wird dies schnell unhandlich und führt zu dem gefürchteten Syndrom der Lähmung durch Analyse. - Diese großen Tabellen machen es sehr schwer, den Wald vor lauter Bäumen zu sehen.
Es gibt zwar Registerkarten mit Zusammenfassungen in der Kalkulationstabelle, aber mit diesen Zusammenfassungen können Sie nicht spielen. Sie müssen zu dem Detail zurückgehen, aus dem sie aufgerollt wurden, um zu sehen, wie sich der Wald verändern könnte, wenn Sie einige dieser Bäume verändern. Nehmen wir an, die "Wald"-Ansicht zeigt Ihnen abteilungsspezifische Zusammenfassungen über Projekte hinweg. Damit haben Sie immer noch eine ganze Reihe von Zeilen in der Registerkarte Zusammenfassung, um zu dem Ergebnis zu gelangen, das zeigt, ob diese Abteilung oder Gruppe überlastet ist. Und wenn das der Fall ist, müssen Sie sich die Details ansehen, um herauszufinden, wie Sie sie ändern können. - Sie versuchen, das falsche Problem zu lösen!
Auf der Ebene "Wald" geht es vor allem darum, die richtigen Projekte zu genehmigen, die zu den verfügbaren Kapazitäten passen. Dies ist kein Problem der einzelnen Benutzer, sondern ein Kapazitätsproblem größeren Ausmaßes. Wenn Sie z.B. eine IT-Abteilung mit 500 Mitarbeitern haben, möchten Sie diese 500 Mitarbeiter in logische Gruppen einteilen und dann die Projekte auswählen, die zu diesen Gruppierungen passen.
Der Gastredner unseres kommenden Webcasts für Agile Enterprise-Kunden am 10. November, Dr. Klaus Leopold, hat in 2018 ein Buch mit dem Titel " Rethinking Agile: Why Agile Teams Have Nothing To Do With Business Agility " veröffentlicht, das diese Frage in einem etwas anderen Kontext sehr gut behandelt. Er beschrieb und gliederte verschiedene Arten der Planung und Ausführung in drei "Flight Levels". Diese Flight Levels können auch auf die Ressourcenplanung angewendet werden. Ich überlasse es Ihnen, das Buch zu lesen, um alles zu verstehen, aber hier ist, wie ich sie auf die Ressourcenplanung anwende.
Strategie. Koordinierung. Operation.
“Flight Level 3” is the Strategic level and analogous with an airplane cruising at 30.000 feet. If you are flying a plane at that altitude you don’t expect to see individuals on the ground. Mostly you see broad landscapes with cities, highways, and farms. You don’t need to see the individuals on the ground in order to figure out where to fly the plane, you really just need that broader landscape. In resource planning terms, this may equate to departments or large teams. More detail than the whole 500 person IT group as a whole, but certainly less than each of the 500 people. The key here is the problem we are solving – making sure we don’t overload the system’s capacity. That’s it! Not who will do the work, not what roles are involved – let’s just make sure we don’t overload the system.
“Flight Level 2” is Coordination at a more moderate altitude like 15.000 feet to stick with the airplane analogy. At this level we expect to see more detail, but still not the individuals on the ground. For resource planning, this might be roles such as Project Manager, Business Analyst, Engineer. Note that I do not include these role-based types at Flight Level 3. Here we are solving for critical resource availability. If we’ve done Flight Level 3 planning and the overall system isn’t overloaded, then we will already find far less contention for resources. Though, there may still be overloads for critical resources such as Project Managers or specific types of Engineers. I think of this level as finding the right types of people for the right projects.
“Flight Level 1” is Operational, a very low altitude of 5.000 feet and below where individual objects are clearly visible and distinguishable. Now we are looking at who will do the work. This is the purview of project managers who assign the work or product owners who prioritize stories for individuals to pull.
Planung der Ressourcenkapazität - Überlasten Sie das System nicht
Nachdem wir die Flugstufen umrissen haben, lassen Sie uns ein wenig tiefer in die Flugstufe 3 eintauchen - die Ressourcen-Kapazitätsplanung. Denken Sie daran, dass das Ziel hier einfach darin besteht, nicht das System mit Arbeit zu überladen und die strategischen Entscheidungen auf der Grundlage dessen, was in die Kapazitätsröhre passt, einzugrenzen.
Der erste Schritt, den Sie tun müssen, ist, herauszufinden, wie hoch die Kapazität Ihrer Leitungen wirklich ist. Wenn Sie die IT-Abteilung mit 500 Mitarbeitern zu einer einzigen Leitung machen würden, könnten Sie Projekte auswählen, die in ihre Kapazität von 20,000 Stunden pro Woche passen. Und vielleicht wählen Sie viel zu viele Webprojekte aus und lassen die Netzwerktechniker Däumchen drehen.
Wenn Sie ein agiles Unternehmen sind, wird dies viel einfacher sein. Sie verwenden bereits Teams. Wenn Sie groß sind, gibt es möglicherweise technische Abteilungen, die aus mehreren Teams bestehen, und Sie können entweder die Kapazität Teams oder die Kapazität Abteilung verwenden. Und das kann in Story Points, Personenmonaten, Tagen oder Sprints ausgedrückt werden. Das Schöne an agilen Teams ist, dass sie bereits ausgeglichen sind. Ein typisches Team besteht aus einem Scrum-Master, einem Tester und vier Ingenieuren. Wenn dieses Verhältnis nicht funktioniert, kann die Zusammensetzung des Teams so angepasst werden, dass die Geschichten reibungslos ablaufen und Sie Initiativen oder Projekte auf ein Team ausrichten können, von dem Sie wissen, wie viel in sein Rohr passen wird.
Agile Teams eignen sich hervorragend für reine Softwareprojekte, aber PMOs verwalten ein breites Spektrum an Aufgaben, für die oft Infrastrukturressourcen, Fachexperten (SMEs) und Projektmanagement erforderlich sind. Wie teilen wir nun diese 500-Personen-IT-Abteilung auf? Eine Möglichkeit besteht darin, virtuelle Kapazitätsteams zu entwickeln. In den meisten großen IT-Abteilungen sind die einzelnen Ressourcen in der Regel spezialisiert. So gibt es bei Infrastrukturprojekten PMs, die nur die Infrastruktur verwalten, spezialisierte Business-Analysten und natürlich Netzwerktechniker und Administratoren. Für die Wartung von Softwareanwendungen von Drittanbietern werden auch spezielle Ressourcen für Projektmanagement und Technik benötigt. Diese 500-Personen-Firma kann wahrscheinlich in ein Dutzend virtuelle Teams aufgeteilt werden, die sich nur minimal überschneiden.
Natürlich führen Sie heute wahrscheinlich sowohl Wasserfall- als auch Agile-Projekte durch, so dass eine Mischung aus beidem sehr wahrscheinlich ist.
Now that we have abstracted a true 30.000-foot planning view for capacity, we can select the work. Instead of selecting the top 20 projects out of 100 proposed, we can select the top 10 web projects, top five infrastructure projects, and so on. And, you can squeeze in a couple of small Web projects from the remaining capacity. Most likely, those top 20 projects become 30 when aligned with their capacity pipes. Of course, if you need to change the plan, it’s as easy as changing the makeup for the projects in each of a dozen capacity teams – not changing projects assigned to every one of those 500 people.
Letztendlich läuft alles darauf hinaus, das richtige Problem auf der richtigen Planungsebene zu lösen. Insgesamt sind Probleme mit der Ressourcenkapazität ein "Flight Level 3"-Problem. Es liegt nicht nur an den Details, sondern zu viele Details stehen der geschäftlichen Flexibilität und der soliden Entscheidungsfindung, die wir alle anstreben, im Wege. Sie werden mehr Zeit damit verbringen, die Details zu aktualisieren, als sich um den reibungslosen Ablauf der Projekte zu kümmern!
