Four approaches to staff reallocation in project management
published on February 18, 2003
You've aligned your roster of IT projects to the company's goals, your managers have assigned the appropriate development staff, and this year's projects are rolling forward. Suddenly, there are complications. Perhaps your company needs to match a product or service a competitor recently unveiled, and that urgent effort takes priority over all others. The inevitable follows— you have to reallocate the IT staff for project coverage. It's a scenario many CIOs grapple with— but only once in a while, if you're prepared.
"If you've got a good planning process, you shouldn't have to go through that kind of process very often," said Ed Setar, director of IT at the Project Management Institute (PMI). Yet, Setar and a project manager interviewed for this story concede that while annual planning processes should reduce the need to realign project teams, emergencies do happen. When they do, you have several choices for reallocating resources— each with advantages and disadvantages. You can do one or a combination of the following:
- Reprioritize the project list, cut scope, adjust timelines, and then reallocate staff.
- Kill a project to make room for a new one, reassigning staff in the process.
- Bring on a consultant or outside vendor.
- Push staff to the limit to do what's necessary.
Of course, each approach is not without its risks.
Option 1: Shift priorities and resources
In an effort to squeeze in a new project, you could choose to shift project priorities or reduce the scope of projects to make it happen, but doing so may put other projects at risk.
What can go wrong: You pull a resource at the wrong time and scuttle another project.
Catherine Stier, a Minneapolis-based project manager at a behavioral healthcare institution, explained that when one recent project slipped from top priority to second, she lost a crucial quality assurance resource. Thankfully, the shift came early in the project's conception, design, and requirements phase. "At that time, it wasn't so costly to lose a person," said Stier.
Had the change occurred midway through project development, the scenario could have changed completely. The new person would have had to do more work to catch up. Also, the task of breaking in the person could slow down project development significantly.
Option 2: Kill a project and reassign the free resourcesIn this scenario, you simply kill one project and reassign the resources.
What can go wrong: You put the wrong people on the new teams and poor communication leaves everyone disgruntled.
"Some people are going to be no problem," said Setar, adding that others will need a bit more talking to.
For that reason, you must consider the best way to communicate the changes to the project team. The worst approach is to go directly to the resources and tell them they're on a new project.
"It really stinks when that happens," said Stier. "It makes you feel like you're not in control of your project." It can also intimidate the IT staff, she noted.
The best approach is to go to the frontline managers to communicate the shift of project priorities. These managers best understand their workers' skill sets and can make informed decisions about who the best people are for the tasks at hand.
"Having a VP say, 'I heard Frank so-and-so is really great, let's put him on it,' isn't always best," said Stier, because the chief doesn't always know the capabilities of the full team.
When PMI had to implement an unplanned project to collect taxes on the sale of its products and services, Setar talked to the senior team first. Then, as a group, he and his managers met with staff members about the change in project priorities and the impact on resources. The approach kept the staff motivated and helped match the right people to the necessary roles and responsibilities.
Option 3: Bring in a consultant
You might choose to bring on a consultant, but in a tight economy, doing so isn't always feasible due to funding restraints. That's where thorough planning can save the day.
What can go wrong: You bring in a consultant too late in the project and don't have anyone to mentor him.
First, every project should have contingency funding built into it. A figure of 15 percent is often a safe bet. Contingency can be used to offset extra expenses— such as a consultant.
In the case of a major project initiative, however, if the money's not available and all the projects must move forward, you have little recourse other than to go to the company's executive committee for additional funding. The choice before them is simple: The projects either need more money, or other projects have to be canceled.
Another successful strategy is to have a consultancy on call. It sounds deceptively simple, but Setar said that having pre-evaluated and trusted professional services vendors at the ready can be a boon if you need to marshal the troops.
Timing is of vital importance. At her behavioral health organization, Stier was able to leverage a QA consultant to replace her missing QA resource. Having the person enter the project early and having a mentor available to bring the consultant up to speed helped make the transition a success.
Option 4: Just get it done
If additional resources aren't available and competing projects can't be delayed or reprioritized, you face the unpalatable task of getting everything completed anyway.
What can go wrong: The staff mutinies and your best people walk out the door.
"I know of situations where you take on the added work but the expectation is that project A is going to get done in the original time frame, and that project B is going to get done, too," said Setar. "That will cause a mutiny."
But if you've done proper resource planning in the first place, it's not a scenario you'll have to face, added Setar. He asks his project managers to allocate project staff at 75 percent, which builds contingency into the resource pool. The staff can use the extra time to train, do maintenance, or to jump on other initiatives in a crunch.
The goal is to ask staff to commit extra hours as an exception, not a rule.
You can get people to work 80-hour weeks on occasion, but on a regular basis, that requirement will kill productivity or make staff leave.
"Most competent and reasonable technical IT people aren't going to put up with that kind of environment for long," said Setar. "If they're worth their salt, their resume is going to be out there on the street."
The truth is that any of these staff reallocation methods have the risk of creating a disgruntled workforce. That's why it's vital to consider your actions carefully and follow through meticulously. Otherwise, you may be left with a mediocre staff instead of all-stars— exactly the opposite of what should happen in a tight job market.