Due to an overreliance on scheduling tools, many project managers have unconsciously begun acting as if they can be on the job 24 hours a day. But are these PMs overcommitted or overallocated to their projects? The difference is in the definition: An individual can theoretically be overallocated to many projects; an individual can be overcommitted only to a specific body of work.
The reason for this distinction is that overcommitment and overallocation really are two separate problems. If an individual is assigned a task and the work on that task turns out to be twice the effort originally estimated—and the project duration isn’t moved out—the individual is overcommitted. If a person is allocated to multiple projects, then it’s an issue of overallocation. I believe that problems arise because of a failure to admit that a single person can’t be in two places at the same time.
Here’s how to avoid falling into the resource allocation trap.
Let’s look at the Xavier Toothbrush Company as an illustration. At Xavier, project managers keep their own project plans on their local drive, and a shared resource pool isn’t used. In this case, Karen Smith needs a DBA for three weeks beginning the December 9. Joe Green needs a DBA 25 percent of the time for his three-month project beginning November 15. Both project managers want to use Frank Kelly (who is the company’s best and brightest DBA). Karen drops by Frank’s desk and asks what he’s working on. He tells her that he’s doing normal fire fighting and supporting the CRM project in his “spare time”. Karen knows that the CRM project is scheduled to finish in November. Because this is the third time they’ve pushed out the date, Karen decides that the November end date should hold firm. Karen also believes that since her project is critically important, even if the CRM project slips it shouldn’t be too difficult to pull enough strings to get Frank out of fire fighting for the three weeks she needs him. Satisfied that she has a reasonable staffing solution, Karen sends an e-mail to Frank’s manager letting him know that she’s planning to use Frank in December and she’s confirmed that his schedule is clear.
At the same time, Joe is going through a similar process. He too knows that the CRM project should be completed in November. But even if the CRM project isn’t completed, Joe needs only about eight to 10 hours a week of Frank’s time. Joe is confident that Frank can fit in some time somewhere. As a good PM, he also drops a note to Frank’s boss saying that he’ll need Frank for a couple of hours a week starting November 15.
Frank’s boss receives both notes and sadly shakes his head muttering, “these people.” He knows that the CRM project is running late and that a couple of production systems are being persnickety (requiring a great deal of Frank’s time). But in the past he’s found that both Karen and Joe overestimate the amount of support they need. Frank’s boss also doesn’t want to join the fight, so he sends an e-mail to the PMs that reads: “Sure, things are a little dicey, but we’ll work it out somehow.”
So is Frank truly overallocated? It may appear that he is, but in reality he isn’t. Joe and Karen only think they have a commitment from Frank or from his boss. Because there isn’t any common resource scheduling pool, the PMs have no method in place for identifying the problem. When things really do start to go wrong in late November and December, the impact can quickly escalate to the point where multiple projects are put at risk.
The failure of resource pools
When organizations begin to realize the folly of this situation, many of them take the logical step of implementing a software tool designed to give them a view of their resource pool. If we replay the same scenario in a shop that uses a tool to track shared resources, the picture becomes clearer. Frank’s boss can now see that Frank is scheduled at 200 percent for a three-week period (100 percent with Karen, 75 percent on normal maintenance, and 25 percent for Joe). Ignoring the fact that the CRM project will probably slip again, adding another 25 percent to Frank’s workload, it should be obvious that the situation is fairly critical. So in our second scenario does the situation get resolved? My experience shows that in many cases the situation doesn’t get resolved but plays out much like the first scenario: No one has the mechanism for resolving the conflicts. Organizations have come to believe that overallocation of resources is standard operating procedure.
Now let’s play out the scenario for a third time in an organization that has embraced some level of workforce planning by looking at their projects at the portfolio level. In this case the visibility of the problem moves up a level, and management has accepted the role of decision maker and tiebreaker.
When Karen’s project was in the initial proposal stage, her requirement for a DBA for three weeks in the December timeframe showed up right away as a problem. With five projects scheduled to complete in December and with the holidays, Karen would be able to see from the start that she has two options: Bring in some outside help by hiring a contractor or delay the project start date by a month to move her project outside the congested period. At this point senior management decides that there’s no real reason to delay the project, and they accept Karen’s recommendation that the three weeks’ worth of work is perfect for a contractor. When Joe’s project was approved, there were no obvious conflicts in resources. Joe needed a DBA 25 percent of the time, and Frank has 25 percent left open on top of his maintenance and enhancement work.
In this scenario the problem comes to the surface when the CRM project slips for the fourth time. The project steering committee recommends to the portfolio management team that the project be extended yet again, and the impact of this decision can be evaluated against the other requirements in the organization. Reallocating DBAs isn’t really the job of the portfolio management committee, but what the committee can do is to see which projects would be affected if Joe’s project were given priority. In our example, the decision is made to transfer 25 percent of Frank’s troubleshooting work to a new DBA who has completed a number of training courses and to free up Frank for more project work like Joe’s. The other work the new DBA is scheduled to do is then postponed.
Building a culture of decision making
There are a few assumptions that are implicit in scenario number three. The first is that the organization has chosen to manage its portfolio of projects. This means that there is a commitment to review and allocate resources against a host of conflicting demands. It also means that the ostrich mentality has been rejected. This strategy takes guts and backbone to implement and agreement from the entire executive staff that the CIO and the CIO’s organization have been fully empowered to facilitate these discussions.
Another assumption buried in this scenario is the commitment by the organization to train and align its current resources with future demands. Most organizations go through a very difficult time when their resources have one set of skills and all their future projects require another set of skills. When money was no problem, contractors could always fill the gap. In today’s tight economic environment, however, it is actually much more cost effective to determine what skills will be needed in the future and who should be trained in those skills. Unfortunately, this strategy also requires a commitment on management’s part to objectively assess its staff and their skills and then train, transfer, or terminate employees as needed.
The final assumption buried in this scenario is that all project managers and all support managers have the discipline to document their resource requirements and that they have the skills and knowledge to make sure that these resource requirements are realistic based on either previous projects or their own experience. In order to ensure that this is true, a company needs to reinforce this behavior in its project teams and offer support through a Center of Excellence or engage a PMO to help where their own experience or knowledge is insufficient.
Creating change from the bottom up
In the last couple of years, every project-centered organization I’ve talked to has placed the issue of resource management at the top of their list of serious problems. Projects spin out of control because too few people are trying to handle too many projects without a clear way to make the pieces of the project puzzle fit. Some of the new tools on the market seem to offer a quick fix, but, as one of our scenarios illustrates, even with a resource management tool it’s still possible for a project to fail if the organization isn’t willing to admit that people can be overallocated only in theory rather than in fact.
Resource overallocation can be solved at the organizational level only by establishing clear project priorities and a clear process for mediating the inevitable conflict in priorities. So if the problem can be fully solved only at the organizational level, is there anything a nimble project manager can do to help the situation?
You should consider recruiting other project managers into a Community of Practice (CoP). Specific recommendations on how to set up a CoP can be found in the article “With a little help from my friends: Exploring communities of practice in project management”. The key is to get a group of PMs together and to establish a planning committee that would work to keep PMs from stepping all over one another. Simply making the decision to avoid letting the situation reach the crisis point and to open up the communication channels will begin to reduce the probability that resources are mythically overallocated.
Another tool we can use to reduce resource conflicts is risk management. As a general practice, I begin every project by identifying my critical resources and developing a contingency plan for replacement or substitution of those resources in the event of an emergency. In the example above, Frank was clearly a resource everyone counted on. While most organizations are only lucky enough to have one Frank, it is possible to identify consultants and upgrade the skills of other personnel to remove an overreliance on one person. By establishing nothing more than the most minimal practice of risk management, resource problems can be brought to light early in the project life cycle rather than later when the solutions are more limited and more expensive.
In the final analysis, resource overallocation is a failure of prioritization, a failure of planning, and a failure to accept that reality always imposes constraints. The nimble project manager understands that things will always change and that even in the best of systems there will be times when multiple projects are competing for the same resource. The only way to really solve this problem is by eliminating unnecessary conflicts in the initial planning stages through prioritization and project timing and by establishing the discipline to make conscious decisions about which projects slip and which stay on track when Murphy’s Law comes into play.