“We need to improve our resource management,” is a phrase I’ve often heard yet answer it requires finding out exactly what the person meant when they said it. When we look at the resource aspect of project management, there are multiple perspectives.
I would put resource management loosely into three main categories:
- Can we do it?
- How do we do it?
- Who will do it?
Let’s take a look at each of these in turn.
1: Strategic Resource Capacity Planning
In the category of “Can we do it?”, at the top level of the organization, management must make decisions in the long, medium and short term about projects. It must perform high-level resource capacity planning sometimes at just the manpower or budgetary level with little thought of skills and almost no thought of individuals.
In the short term, management must consider projects that are underway and those already committed to that are about to start at some level of analysis to determine if the value expected from those projects still serves the best interest of the organization. Remember that “value” doesn’t necessarily mean money although it certainly could be measured that way.
In the medium term, management has to look at projects that are expected to be activated in the near future and determine if the business metrics that were used to approve those projects still makes sense. Have their been competitive projects that have been launched or completed since approval for example. Or, have some current projects had to be extended or delayed and might this affect how and when the already-approved projects might start.
In the long term, management must look into the future to determine what kinds of projects would be best suited to the organization. This might depend on innovation exercises or on competitive analysis. The organization might have to choose between extending existing product lines or starting new ones and might have to contend with projections of revenue and profit before deciding on what to invest in which of these future projects.
Strategic Resource Capacity Planning is definitely heavily dependent on analysis but the exercise might not even be done at the skill level. In many organizations it is done solely at a cost level with the total availability of resources represented on a grid as the total resource cost allocated to this type of work. There must also be allowances for the load of non-project work.
2: Operational Resource Scheduling
At an operational level, a project manager, resource manager or both must look at “How do we do it?”, how the project work will get accomplished. They have the approval of management to move a project forward and now must look deeper than just a budget in order to make that project a reality. The project manager looks at a schedule for the first time, trying to fit it into the parameters that were authorized in the Strategic Plan. They then must look deeper on the resource capacity plan to do skill scheduling. They too must look at the projects already underway with a view to how resources are already, or will become, available. The project manager has only a passing thought for future projects that may be arriving in the future. Their focus is on determining how to get this project completed.
This operational level is heavily analytic. It includes critical path scheduling, resource leveling and forward looking forecasting. When the project manager is collaborating with others in a Project Management Office, there is often centralized data management to best determine what skills will be required and will be available to complete the work. In some organizations, this may be done at the individual level but that is rarely effective. At an operational level, naming a particular resource is almost begging to have to go back and change that name later. The exception is when there are resources so skilled or with such a particular combination of experience that they are the only person possible to complete a particular task. Otherwise, resources are grouped into categories or skills so that analysis can be done that makes sense.
The resulting project and resource analysis will be updated as projects are progressed and in this case the actual names of resources will be recorded against the projects. More importantly, the projected completion of tasks will inform the forecast of what is expected. It is here that project managers can do what they do best: looking for alternate scheduling sequences, looking for how to adjust or change work to fit into the skill availabilities and looking for how to get the right skills to the right work. It is at this level that decisions such as outsourcing might be made for certain work, extending the resource capability to overcome gaps or insufficiencies in resources for a particular task or group of tasks.
3: Tactical Resource Allocation
In day-to-day operations, to determine “Who will do it?”, there is work to be completed and workers who need to complete it. This is a very tactical situation and resource management is about getting the right individuals onto the right tasks. We see concepts like Agile being applied very successfully at this level and Resource Allocation and task management is the primary focus.
Team Leaders or Scrum Masters (for Agile) or group leaders meet on a regular basis (weekly is popular, but daily is also possible) to hand out tasks. These tasks might be on a screen or on post-its on a white board but the idea is to take tasks and hand them to people. The Team Leader knows the description of the task and the skill expected from the already-completed analysis of the project manager but the Team Leader also knows their people and who is best able to complete the work described. Their role is to best align what work can be most effectively completed by which person.
This tactical perspective is not at all analytical in nature. This is a commitment based paradigm. Questions like, “Can you get both these tasks done by Friday?” and statements like “I can get all three of these done this week,” are common.
Bringing it all together… or not
You might think that bringing this all together into one massive compendium of data would be by far the most effective plan. You might be quite wrong about that.
Software publishers would love for you to think that the data looks the same so it should really be the same and go to great pains to create demonstrations of multiple levels of resource management all integrated together. At the management level, where such systems are sold, the idea that an executive could drill down from their strategic plan all the way into an individual’s daily schedule is compelling. But the notion that this gives that executive more control is mostly an illusion. Sure it’s great to have access to lots of data, but in the end, this data has to resolve to decisions. At the tactical level, knowing that a particular individual is available to work on a particular task gives rise to the decision to associate the two together. What does this information do for the executive?
Probably nothing.
So the idea of looking integrated may be better than actually being integrated. It is useful for project managers to know the parameters of the project as they design how to make it work, but this is a small amount of data, not worth the work of integrating the two levels and keeping them synchronized. It is useful for the tactical team leader to know what tasks need to be accomplished and what the general sequence of those tasks are so they can think about them in order. But the level at which this data is given down to the tactical team leaders and the level at which it can be summarized back up into a project system may not be worthy of integrating the data together either except at the most summary level. It might be worthwhile to think of project systems giving their data in one direction to tactical to-do or Agile systems and then having progress at a much more summary level go back to the project systems from a weekly timesheet. But this is loose integration, not a complete top-to-bottom architecture. There is a cost to integrating all these levels together and keeping them integrated and the main cost is in time, effort and overhead. If you’ve ever been involved in a company-wide project integration exercise, you know how challenging it can be from a culture and change-management perspective.
We also see desires for other concepts like “Real Time Project Resource Management”. But when you look at the different perspectives of Resource Management that we’ve just outlined, only the tactical level has any interest in anything close to real-time. As a team-leader, knowing that one of your team is about to finish their tasks a day early and is about to have a whole day of unexpected extra project time might be significant news. There is no sense waiting until the end of the week for that data. It’s far too late. So, at this level, keeping track of things more or less as they’re happening makes perfect sense.
What does this same data do for an analytical project manager in the PMO? Close to nothing. How about at the executive level? Nothing. So, the notion of integrating real-time data for all of these levels isn’t only ineffective, it can be a massive distraction for people at the executive level who should be focusing on other things. I’ve often asked executives who are interested in such things at what frequency they would be committed to make decisions about the project? Daily? Hourly? Needless to say, they are not. It’s more common to find they expect to talk about a project weekly or monthly at an analytical level.
Wrap up
All of this leads us to start thinking of resource management exercises distinctly for each level. It doesn’t mean that you can’t use the same tool or same tool provider for the different levels, but each of these levels has different goals and requirements and when you think of each of them on their own merits, it’s entirely likely that you will end up looking at tools that can be loosely tied together instead of the illusion that working from top to bottom brings tremendous benefits.
As always, I recommend you look to the business problems you’re trying to solve before you look for the solutions to solve them. Starting from the solution tools first and trying to squeeze your business problems into those tools rarely results in success.
