John McGrath, speaking at the Pharma PPM Toolbox in London, said that there is simply no excuse for not having enough resources on a project.
Now I know many of you will be disturbed by this statement, but I think he's more-or-less correct.
It's like when a bridge collapses. Bridges don't just collapse, you see (not that I'm a bridge expert, but work with me here.) There is always a reason for the collapse; you designed it wrong, you used the wrong material, you allowed too many trucks on at once, etc.
It’s the same way with projects. There's always a reason when you run out of resources and it's almost always avoidable. Let's look at some of those reasons and work out what can be done about them.
Why do we run out of resources?
The obvious answer is that you're trying to squeeze too many projects through the pipe, but dig a little deeper and you start to get actionable insight. Each of the following items is quite capable of destroying your ability to effectively marry up projects and resources, and there are things you can do to address each one.
Project prioritization & buy-in
Let' s start at the beginning: picking projects.
I've lost count of the number of times I've heard the cry, "our executives always want more projects than we have capacity to deliver." Well yes, of course they do.
Your job, I would suggest, is to make sure there is a good process not only to prioritize projects, but also to select projects in a way that ensures key stakeholders buy in to the decision. If they don't buy in, they will find ways to do an end-run around the process and you're back to "square one". This is something Greg Gomel (PMO par excelence) talked about this in a recent podcast.
A good process lets you pick the portfolio that delivers the most value for a given set of resources, but it also helps you make better resource allocation decisions when projects collide because you have clarity over which projects have priority... (WE PROBABLY HAVE A BLOG ON THIS)
Of course, if your estimates for the resources needed for a project are off, you will still run out.
There are tools out there that can help. Some of our partners (e.g. Optiim, PMO in a Box, etc.) do a nice job of this. The key is to have good templates that help you estimate the different phases of your project more quickly and with fewer omissions.
With a little discipline you can refine these templates to make them even more accurate/useful.
Many organizations, of course, do this in Excel. If you do, be diligent: think about project phases and the different tasks and skillsets each needs. Collect feedback on "actuals" to make improvements to your templates, working out what you’ve missed off your list.
Resource planning and scheduling projects
One good reason to invest in tools that support estimation is that they are often the same ones you'd use to schedule your projects... but there's a problem here. Most tools do "bottom-up" planning. You schedule projects, allocate resources and only then can you see if the whole plan hangs together.
And of course, this makes it very unlikely that you'll live long enough to do a good job of optimizing your project / resource mix. It just takes to long.
There is good news. There are now tools out there that essentially do automated resourced-based scheduling. They typically run some kind of simulation linked to an optimisation algorithm. At TransparentChoice we built a prototype using the Genetic Atogrithm, for example, and it works well. Our partners , Optiim (two name-checks in this blog and counting!) are good at tying together estimation and scheduling. Meister Plan does something similar I believe (without the fancy algorithm).
The point is simply this: if you have a mid-size-or-larger portfolio, it's really hard to create a good master plan without a specialist tool. Don’t skimp. You’ll save yourself a fortune in failed projects, blown budgets and overruns.
Velocity of tasks
As I mentioned at the beginning, resource clashes really slow down execution.
The flip side of this is that slow execution increases resource collisions. If you can accelerate the execution of tasks, you’re effectively giving yourself more capacity and so get fewer collisions.
One of the assumptions that many PMOs make is that the resource pool you have is…. well, it’s the resource pool you’ve always had, but I know a man who would beg to differ.
Mike Hannan did a couple of webinars for us recently in which he discussed a number of techniques to accelerate your task completion. Some of them are just stupidly simple.
But what I want to get across in this blog is the message that you can take immediate action to increase the velocity of execution … and that reduces the chances of running out of resources.
My final “root cause” for this blog is the “fire and forget” plan.
We’ve all done it at some point. In fact, in my experience, most organizations do it most of the time. It takes so long to create a plan that you never revisit the plan.
But of course, things change. New project risks emerge. Key stakeholders leave. Project estimates get revised as you learn more…. so what we need is a quick way to revisit the portfolio and to make sure we still have a deliverable portfolio.
And that’s where those real time prioritization tools like ours and simulation tools like Optiim (third and final mention!) come in. They let you quickly revamp the plan as part of your normal governance process. That means you can continually add or remove projects or tweak resources (take on a contractor, etc.) to keep things moving smoothly.
John McGrath’s initial comment about there being no excuse… it was based on the following logic.
If you’ve run out of resources, you’ve got one of two conditions.
1)You’re trying to do too many projects without sufficient resource (I think we’ve covered that)
2)Your exec sponsor isn’t fighting hard enough for the resources
I would argue that John's “Exec mud-wrestling” is not needed (though we could suggest it for ESPN). If you’re taking care of the items set out in this blog, there should be no resource clash.
In fact, sending your execs out to fight for resources, for in-flight projects is a little like sending the engineers out to repair your bridge after it had collapsed.