wbsIt’s become an almost universal desire – the holy grail of project management. Almost every week I’m asked by senior management of an organization “How can we get enterprise-wide, multi-project, resource capacity planning?”

A couple of weeks ago I had the opportunity to speak with a large telco here in Canada (no, once again I can’t reveal the guilty parties). They too are interested in resource capacity planning across the entire enterprise but when I asked how they now shared their data the answer was “not at all”.

If you are interested in brining data together for multi-project analysis, there are a few aspects you’ll need to deal with.

First of all, fundamental to moving from a single-project to a multi-project environment is the necessity of having all project data in one place. If the data is held in multiple systems, there still needs to be a “coming-together” of that data into one spot if there’s to be any hope of doing the analysis required for a multi-project environment. In some cases, the best way to achieve this is to standardize on one project management system. I’m not big on having systems being the answer to a problem but in this case, moving everyone into a particular system may serve to solve this problem by definition. You may face some resistance here from people who believe their project doesn’t warrant being in the central system or who wish to you their own home-built system to manage project data. You’ll need to decide how best to handle such people and their projects and in some cases it is possible to let projects “opt-out” of the central system if the people on those projects are not used elsewhere and if the project does not have any impact on other projects. You can set up a sort of “notwithstanding clause” procedure for having project managers request such a status.

Now, once the data is all in one place, here are a couple of areas to focus on in order to start establishing your multi-project environment.

Naming conventions

No, this does not involve a Las Vegas hotel trip. Naming conventions means having standards for naming things. For example, if you have 3 different managers who would all like to use different resource codes for the same resource, you are in for a colossal headache when you try to do resource levelling. If you have some project managers who use different terminology for the same thing you’ve got difficulties in store too. Setting up some simple rules for how to name projects, how to identify tasks, resources and codes will save you oodles of grief down the line.

Common coding

Somewhat related to the whole naming convention scenario is deciding on how user-defined fields and hierarchical code fields will be used. Deciding in advance that a particular code such as a WBS code will always be in code position one makes it possible to do reporting using this code across all projects down the line. If you want to do analysis of your legacy data, say by department or by project phase so you can see over time how one area performs across projects then organizing your coding in advance is critical.

Inter-project dependencies

In many organizations, some projects are dependant on the results of other projects in order to proceed. In some cases the design of a particular element of a project or the proof of a concept in a project will be the prerequisite for moving forward on another. In this case, you’ll need to establish links between activities in different projects. Most project management scheduling systems support this kind of link. When you establish a relationship between activities you’ll need to set up some procedures to make sure they are managed consistently. First of all, you’ll need to decide who owns that relationship. Also, under what conditions can the relationship be changed or deleted.

Imagine a scenario where a finish-to-start link exists between activities in two projects, each owned by a different project manager. The first project is the design of a key component to be used on a range of projects. The second project will use that component to move forward into a prototype of its product. Okay, so now the design project starts to run late. The later the design deliverable runs, the later project number two is slipping. There may be enormous pressure on the project manager of the second project to hold schedule yet he is being pushed by a project outside his control. The desire to alter the relationship that is slipping his schedule is huge yet, if it is deleted, the pressure on the first project manager will lessen dramatically. What should you do? Well, there’s no right answer of course, but setting up the ground rules on how to deal with this kind of scenario before it actually occurs will make a big difference.

Project prioritization

Prioritizing projects is a similar challenge. If you plan to resource manage you projects together as some kind of portfolio, one of the most obvious elements of data to deal with is determining which projects will get first call on those resources. Simply looking at the projects which are latest or which are most critical is insufficient reason to give them first call on the resources. This type of planning might result in a low importance maintenance type project superseding a mission-critical project to release the next new product in the company. Clearly that is not productive. So, who should set the project priorities and what criteria should be used to set them? Again, no right answer but it’s not always easy to find someone who’s willing to take on this responsibility. Setting the standards and criteria for everyone will make multi-project resource levelling possible.

Among other elements you should establish as part of your multi-project environment is determining who will control the resources. Are they managed by resource managers as you would in a matrix-type of organization or by the project managers themselves? How will you deal with resource conflicts when two projects need the same resource?

Also, it’s worthwhile to think about the reports and analysis that is desired by senior management that is probably driving the whole initiative in the first place. What will management need and what must you do in order to provide that analysis. Also, what will be the process once management receives that data? It’s good to lay out plans for senior executives on appropriate action under particular circumstances. After all, if project managers believe that they will be beaten with their own data, they will be reluctant to share it again.

All in all, the best advice is to establish as many standards and as much standardized process as possible while bringing your multi-project data together to ensure as smooth a transition as possible into your new way of doing business.