Top Ten Reasons Why Projects Fail – Reason #2
Reason # 2 – Resources
In my first post on why projects fail, I talked about scope being the number one problem. And truthfully, I might just as well have said resources. These issues are typically number one and number two in companies I work with, not necessarily in that order. So what exactly is the issue with resources and why does it lead to project failure? In a nutshell, I see several things at work. Firstly, there are too few resources working on too many projects at the same time. And in conjunction with that, managers don’t seem to have a grip on what their resources are doing at any point in time, whether project work or their “real” job.
Now, in and of itself there’s nothing wrong with resources working on multiple projects at the same time. (As long as there’s enough of them which is another story). With proper supervision and prioritization, it can work just fine. But what often happens is that both of those things are lacking. And so resources are left to figure out for themselves what projects they should be working on and when. In this instance, the employees – not management – are making decisions on what to work on, mostly based on who yells the loudest or what they can accomplish first. Moreover, as mentioned, these same resources that are working on multiple projects are often also doing their “real” day-to-day job.
So in the beginning, teams will get together to create a schedule based on the tasks and deliverables and how much of each resource is needed for each task. And if the schedule end date comes in more or less where they wanted it to, they are happy and congratulate themselves. But if you look at the resources in, say, Microsoft Project, it will detail resource overallocation very clearly. Overallocated resources will show up in Project with the team member’s name in red. And if you look even more closely, say at the Resource Usage view, you can see exactly how much a team member is being used. So in the most recent schedule I helped create for a customer, one resource was planned to be used 32 hours on March 5th, 8 hours each on 4 separate tasks! This phenomenon is extremely common and a lot of people don’t use Project to level the resources. And even if you do level the resources in each schedule, recall that the team member is probably not only working on several projects but also doing non-project work. This doesn’t get accounted for in Project.
So what’s one possible resolution? Well, in one company I worked at, we came up with what I would call a low-tech solution. Basically, every Monday morning, the PM’s met and shared a spreadsheet that had been put together by a project coordinator. That spreadsheet tracked the usage of every resource in the organization. (This happened to be a consulting firm with a lot of ongoing projects). And so, managers could look at that spreadsheet and see that, for instance, Dave the architect was working at customer XYZ for the month of April. And further, they could see that he would be available by May 2nd. So the appropriate project manager could slot him in as needed for the next project. The end result was that everybody knew what every resource was working on and for how long, project-related or not. Was it perfect? No. Sometimes, for instance, Dave took longer at a customer than we anticipated. But once we understood that was going to happen, we could make allowances for it in his next project. And if that continued to occur? Maybe time to hire a second architect.
Bottom line? You must keep track of all your resources and know exactly what they are working on at all times. Otherwise, predictions of project completion are fatally flawed and you will deliver late and over budget. Now, there are softwares out there on the market such as Planisware, Planview and Clarity that purport to do resource allocation. But I personally have no background in these nor have I seen them anywhere. And they are expensive. But you may want to at least know that they are out there and explore them to see if they fit your resource planning needs.
(Stay tuned for part three)