The way in which projects are delivered today can make it feel like resource management is stuck in the dark ages. With the rise of Agile, where teams are split into squads and work is spliced into sprints, there is a tendency to revert to very rudimentary resource planning and management. However, this need not be the case.
Yes, you can still have your squads and your sprints, all whilst maintaining a finger on the pulse of your resource throughput. Let’s face it, the biggest expenses (and assets) on almost any project are your resources. But before we delve into this modern era of squads and sprints, let’s consider what made the traditional waterfall model so compatible and complimentary with resource management.
Key integration for resource management into a traditional waterfall model are (just to name a few):
- Resources linked to known tasks / activities,
- Tasks / activities with pre-determined duration and effort,
- Fixed scope,
- Historical reference (to past projects of similar endeavours), and
- Specialist roles / subject matter experts.
Now, if we look at the points above with an abstract lens, they are not too dissimilar to what we would find in an Agile project. So, let’s consider each of the points raised for an Agile world.
- Resources linked to known tasks/activities…
Individual resources are grouped together, unified with a common purpose and tasked with a delivery of a sprint. The “known tasks/activities” is that defined by the sprint. The resources assigned to the sprint are implicitly linked to that sprint.
- Tasks/activities with pre-determined duration and effort…
Each sprint is time bound. The effort is the accumulation of the resources dedicated to the sprint, for the duration of the sprint.
- Fixed scope…
A sprint has a fixed, achievable, smaller scale scope.
- Historical reference (to past projects of similar endeavours) …
For a lot of organisation starting out in the world of Agile, there may not be any historical data. But that doesn’t mean you can’t use historical data from traditional delivery models, after all what better way to demonstrate a cost advantage than comparing an Agile delivery to its predecessor’s way of delivery?
- Specialist roles / subject matter experts…
These are the heroes of just about any project. More often than not, their sheer knowledge of a specialist domain, can often help shape and guide delivery strategy, development and ultimately outcome.
So, armed with all these commonalities between what still stands true for the traditional project methodology and the Agile world of today, we know that it doesn’t take a giant leap to maintain a solid steady read of the pulse of your Agile project’s resource monitoring and forecasting. Strip it back to basic, standard resource management stuff (an article for another time).
Yes, you might need to rethink how to overlay / integrate an Agile structure across your workflow management register or resource plan, but these alignments can be achieved with minor tweaks; like adding half a dozen fields to allow setup of flags to align to your Agile structure. Of course, make sure the one field you don’t forget to allow for is the almighty avatar.