Next, epm almost always has some reference to resources. In particular, management usually expects that epm will result in gaining the ability for enterprise resource capacity planning. This means that new or prospective projects will be able to be analyzed within the context of existing workload and capacity and that management will be able to instantly determine the impact on other work and on the prospective project of all resources requirements. To front-line project managers, epm often means they will gain an enterprise-wide perspective on resource loads and resource availability. There is an implication that all resources are accounted for in the capacity side of the equation and that all forward looking resource requirements are stored in the work load side.
Finally, almost all users expect that epm will deliver an ability to determine the inter-project impact of project interdependencies of any kind – logical, or resource based so that any impact from anticipated changes in one project will be instantly recognized in all other projects.
Ok, that’s the goals. Now, let’s look at what we’d need to do to get there. There are several pre-requisites to implementing epm. They seem obvious once they’re listed, but may not be so evident if you haven’t thought of it before.
Store the data in one place.
First, you’re going to need to store all project task, resource and cost data in a centralized repository. That’s right, no more managing your own personal files on your hard disk. This also implies that all data will be coded in such a way that we can group it together and then use it later. For example, if we’re using code field #1 for task location, we really must do that across all projects. Also, the central repository must be a single central repository. That is, all data is in one format – almost always a co-located format. Another implication of a central repository is that that the practices and procedures for collecting and saving project data must be standardized so that we will be able to report and analyze the data later. For example, status dates for projects must be the same.
Identify which projects are most important
Next, we will need to establish a prioritizing structure to identify which projects are more important than others so that we can use our resource capacity planning analysis to allocate our resources where they will make the most difference.
Well, if that’s all there is to do, almost all organizations must have already implemented an enterprise project management structure. Not so. There are natural barriers to accomplishing these two simple pre-requisites.
First, project managers have gotten used to controlling their own data. The advent of low-cost, easy-to-use pm tools means that virtually anyone can produce 1st class project reporting with no help from a centralized authority and there’s no doubt that project managers like having the ability to do their own analysis before anyone in management sees it.
Also, as hard as it is to believe, management in some organizations may actually punish those who deliver bad news. This will make some project managers reluctant to share data if they think there is any possibility they may be beaten with there own work as soon as they deliver it! Even if they are not punished, management in some organizations may inundate a project manager with questions and concerns when they could see project data in real time. This will make some project managers (yes, you know who you are) reluctant to share their own working data as they may believe their productivity will suffer by having to spend too much time answering management’s questions.
As far as project prioritizing goes, problems usually stem from the fact that many managers may be involved in the process. It’s certain that no manager wishes to make their project a second priority. Everyone thinks their work is the most important possible. In real terms, there may also be a penalty in making a project a lower priority and in the delay due to lack of resources that this will imply. There may be upset clients or sponsors, or even monetary damages that are associated with a delay.
So, how can you get project managers to share their real data and managers to deliver real prioritization of projects? Well, if you’ve read this far, you’ve already identified that it’s a challenge and that’s a big first step. The most important aspect of overcoming these cultural barriers is to treat the implementation of epm as a change-management project.
When we think of different people playing different roles within the organization, it is important to realize that team members, team leaders, project schedulers, project managers, PMO personnel and executives all must put some investment of time and effort into the implementation and, for it to be successful, they must all experience some return on that investment. It’s worthwhile to ask yourself before the implementation begins, “What will this person or group of people get out of the system once it’s implementation is complete?”
If you’re looking for good tips on making things easier, start with practices and procedures and steer as clear as possible from internal politics. For project managers who will have to share their data, determine in advance how questions will be dealt with and what the policies will be for delayed projects. In some cases, project managers may be happily surprised by your procedures. You may, for example, make a practice of allocating extra stand-by resources to delayed projects. You might also consider a temporary amnesty for any project managers with under-performing projects. Anything like this that is an incentive to share current data and a disincentive to keep it to yourself is worthwhile pursuing.
Remember, any practice or procedure you determine in advance can be done in the relative safe isolation of the lab where people aren’t threatened by how it may affect a project the next day. Plan to publish your practices as long in advance of implementing them as possible so people can adjust and expect to do some evangelizing about the benefits end users can expect once the system’s in place.
For management, a bit of a guiding hand will be very welcome. You can make a process for prioritizing projects long before they’re implemented and get sign off on the rules in principle early. Projects might be assessed against a grid of factors such as return on investment, cash flow, delay penalties or early delivery bonuses. If managers can agree to the rules of the game before they start playing, you have a better chance of getting management acceptance once the heat is on.
In the end, plan to over-communicate. Plan internal seminars and workshops where you’ll be selling the benefits of the plan over and over. Even once the implementation is complete, you should expect to have to continue this effort as enterprise project management evolves within your organization.
Originally published in Project World Special edition – Summer 2003