From the project management systems perspective, there is good news and bad. On the good side, almost every solution on the market speaks to multiple project management scenarios and has functionality to support it. On the bad news side, however, there is little consensus about what this means.
Let’s tackle this issue from a couple of perspectives:
Scheduling
There are a couple of big issues here. First, you need to look at the simple aggregation of the data. If you can’t get the data into one place, it is impossible to even think about analyzing or reporting on all projects at once. To group this data together, you’ll need also to think about common coding. For example, if one project manager is using the first user-defined code for an accounting code in their projects and another project manager is using the first user-defined code for a location code, the merging of this data will present a problem. Coding standards and naming standards will have to be defined. Also, if data is no longer going to be secured by each project manager on their own PC, then defining the security of the global data and rights to access this data will have to be on our deployment agenda.
Also in the Scheduling category is the hierarchical definition of these projects. Are they grouped into sub-projects and into sub-sub-projects? How will these definitions be supported in the global system.
Resource Management
Next, let’s talk about the resource management aspect of this data. Resource management was an afterthought for many of the older Critical Path Methodology scheduling systems. In the days of the mega-project, resources were considered to be unlimited and resources leveling in these older systems were often tacked onto the original CPM scheduling functionality. These days, however, resource management is often the raison d’etre of a project system. Many systems I’ve seen have very different thinking about the role of the resource manager in a multi-project scenario.
The most common definition of what a resource manager should be responsible for in today’s pm systems is to manage the availability, skills inventory and possibly the allocation of team members to the defined tasks. In this paradigm, the idea is that the project manager or scheduler will define the work to be done and schedule that work with skills requirements or discipline descriptions. The work will be sequenced and a theoretical schedule will be determined by the critical path scheduling engine. Next, a resource manager will examine available resources and allocate the most appropriate resource to the task. Running the resource leveling engine will then be done by the project manager or the resource manager and will determine the best possible schedule of the defined resources. Once approved, all resources will be informed of their new schedule and work will commence. If this is the way your organization is defined, most of the existing pm tools will suit you out of the box. Unfortunately, not everyone works this way.
Matrix Management
In a structure where there are many projects, many project managers and multiple resource managers we end up with the classic Matrix organization. You can imagine this organization as a grid of resource categories at the top and task categories along the left and at every intersection, work to be done by someone.
In this classic matrix, however, organizations give varying levels of authority to one axis or another. In many organizations, the resource manager is attempting to level not a particular project, but the workload across all tasks for their own department. This requires locking down the sub-sections of each project for their category of work.
The project manager is simultaneously trying to optimize the schedule for their project across all departments. This generates an inherent conflict between the resource and project managers which (while sometimes irritating) is considered one of the benefits of matrix management as it serves as a check and balance in the system.
This is, however, colossally problematic for any project system. Who owns the part of the schedule being examined at any given time? In a multi-user system, might we end up with a user trying to pull a task one way while another is trying to push it in another? This is the fundamental dilemma for pm software developers.
The problem is compounded in a matrix organization which is not weighted towards the project side. In some situations, resource managers act as a type of sub-project manager. This often happens in high-tech where an element of the project is so complex that only the resource department itself can properly define it. This means that the tasks that will make up a particular sub-project must be defined by the resource manager or someone in that capacity. Now who owns that data?
There’s no obvious answer in terms of functionality for how to make this work. As I said, the Matrix Organization has inherent conflict by definition. The resoulution of this push and pull from the project to the resource side is supposed to balance out the interests of both sides of the organization. Without the work of the resource managers, project managers would burn staff out and would never invest in skills training. Without the guidance of the project managers, resource managers might have very happy resources but they would have no pressure to produce results; to get the job done.
So – what should you do? It’s fair to say this problem, while not universal, is very, very common. The first step to deploying a working project system that will deliver more efficiency is to stop focusing on features to solve every problem and to put some time into defining what information you require in order to make better business decisions. Virtually all of these conflicts are resolvable through process management rather than feature management. First, you must ensure that your project process is adapted to support multi-project management.
Start with your biggest and simplest issue and that is compliance. Getting 100% of project managers to use a particular system is usually the biggest challenge and much tougher than ensuring the ultimate algorithm for resolving resource conflict. If all the data is in one place then you’ll have the most difficult part of the deployment complete and you’ll be able to at least see the aggregate resource data. While this doesn’t automatically resolve resource conflict, it at least defines the problem so it can be dealt with. Make sure you include some human-to-human interaction in your multi-project resource management process. If the data is all centralized and easily reported, 99% of these conflicts can be resolved that way.
Originally published October 2003 in PM Times