CHAPTER 22
Enterprise Project Management: Elements and Deployment Issues

CHRIS VANDERSLUIS, HMS SOFTWARE

Enterprise project management (EPM) is the Holy Grail of project management: The idea that all project management information, reporting, and analysis will be part of an all-encompassing system where virtually every activity, every hour of time, and every dollar spent can be instantly identified.

It’s not just senior management that is interested in the subject, although at first glance, they seem to have the most to gain. The Project Management Office (PMO)—or in its absence, whatever centralized project management group available of professional project schedulers and project managers—is highly interested in getting access to all levels of data regarding project management. The antithesis of enterprise project management would be an ad-hoc process where everyone does his or her own thing. This is by far the most common scenario we find in organizations today. A PMO cannot function without project data and if everyone is doing something different, that data isn’t easy to come by. For the PMO, getting to see the lowest level of project data is very attractive.

Individual team leaders are interested in seeing the inter-project impact of different project groups, and the ability to resolve resource conflicts between teams is one of the most significant impacts on project performance.

Even team members are interested in the concept. Team members in organizations that manage “by emergency” or continuously in a reactive mode, see tremendous potential benefits in EPM, hoping that an integrated process might bring order to chaos.

What is this phenomenon we refer to as EPM? Like most three-letter acronyms, EPM is bandied about like a complex mysterious topic, but its basis will be familiar to anyone in management. Enterprise project management is essentially the integration into a single system of project and resource data, processes, and analysis for projects in the organization.

For any organization that manages more than one project at a time or that has projects so large they must be broken down into component subprojects, the management of the following two significant elements is critical.

First is the interrelation between projects. If any project is dependent on the completion or delivery of elements from another, the impact of changes in one project can have dramatic effects on the second. For example, one project might be to install a new database on which new software deployments will depend. If the database project is delayed for any reason, all dependent projects will be delayed. Having a process that allows the downstream projects to see potential impact on their projects is a fundamental goal of EPM.

Second is the management of restricted resources. There is virtually no project management environment in the world where resources are standing around, waiting for work to arrive. More likely is that workloads far exceed the availability of key resources to accomplish them. The prioritization of that work and the resolution of conflicts over those resources is a prevalent management concern in organizations around the world.

THE PROJECT MANAGEMENT MATURITY MODEL

There is much talk about a Project Management Maturity model (PMM) that would match the work done in the Manufacturing industry of a Capability Maturity Model. While it’s not the subject of this section, it’s worth taking a moment to see how the PMM model relates to Enterprise Project Management. While there are several popular versions PMM models, the root is the same. The notion is that the lowest level of maturity would be one where project management is done on an ad-hoc or casual basis with each project manager managing things their own way. A middle level of maturity would see these processes integrated across the organization and a top level would see a process by which the integrated process itself is self-sustaining through a formal change management and improvement structure.

It’s an interesting concept but it takes as its central premise that the more integrated the project management environment of an organization is, the more mature they are and this is not necessarily the case. There is an argument to be made that for some organizations, the most effective enterprise standard for project management is to have no centralized standard; to eschew the concepts of enterprise project management altogether and to let individual project managers use whatever systems they wish. It is a tradeoff to be sure but worth taking a moment to think about.

The potential benefits to management of EPM seem obvious but they come at a cost. A centralized structure will serve to implicate several levels of management in project decisions. This may give management better visibility but it will hamper the aggressive “high-flyer” project managers who have fought, connived and scrapped for the internal competitive advantage. Each organization should look at what level on the project management maturity model they should be striving for and there is a case to be made that the right level for your particular organization is any one of the levels displayed. PMM models are discussed in detail on the web in numerous sources, as well as in other chapters of this handbook.

ELEMENTS OF EPM

Let’s look at the five basic elements of an EPM environment.

Storage of All Project Data in a Single Location

This is the first thing that must be done in any EPM deployment and, as the first element, is often highly contentious. Lest we confuse this section as having to do only with software, it is certainly possible to create an EPM environment that is completely computerless. In such an environment, the basic requirement of getting all data together is still fundamental. What is most common is that different project data will be stored in different places.

In today’s modern organization, many managers equate control of data to power, and there are few managers who will willingly sacrifice what they consider power. Each aspect of project data may be jealously guarded by its incumbent owner. The budgets may, for example, be controlled by Finance. Individual teams of resources may be managed by department managers. Each project manager will have his or her own schedule data that he/she is used to controlling. For an enterprise system to be possible in any way, all project data must be stored in the same place and managed in the same way.

To bring data together, there is some work to be done. Let’s start off with naming conventions. For example, if we talk about project resources, let’s assume that one group refers to the CEO as “ME,” short for Mike Edwards. Another group uses the letters “ME” to refer to the discipline of Mechanical Engineers. Yet another uses “ME” to mean Maintenance Engineers (i.e., Janitors). If we don’t first come to some understanding of what coding we will use for resources, when the data is brought together, we will find Janitors, Mechanical Engineers, and the CEO will all be grouped together.

To bring this data together, standards will have to be agreed on to avoid this type of conflict. The same thing has to be done for project names, task names, department names, document names, change management issues, and so on.

Now, we’ve invoked a scary word: “standards.” This implies that someone will be the keeper and arbiter of those standards and that almost certainly means that if you are committed to EPM, there will have to be some kind of central office to be responsible for elements of your EPM environment, such as naming conventions. Without some kind of PMO, there is little hope that naming conventions will ever be agreed upon, and if they are, they’ll never be enforced.

Along with naming conventions, you’ll also have to agree on the repository for the data. If you’re implementing an EPM software package, then this part of the conversation is quite easy. The new system will have a set method of storing data, usually in a commercial database like Microsoft’s SQL Server or Oracle. Then all you’ll have to organize is choosing the single location for that data to reside. Different groups may lobby for why their need for project management is so unique that it’s absolutely impossible for them to comply with a single repository of “their” data somewhere else. These various interest groups will have to be dealt with one at a time. Your first mantra for deploying project management has to be “all project data, one location” until there is broad compliance.

Grouping Data by Different Criteria

The ability to group data by multiple criteria is an issue for reporting and analysis, so it is often spoken of last. However, the definition of the data structure makes all those reports and analysis possible, so it really needs to be dealt with first. If there is no coding of data at all, bundling all the project data together essentially will just give you one enormously long list of tasks with no method of subdivision. That’s not too useful. Once you are past the mantra of “all data, one location,” project coding is your next challenge.

Coding comes in a variety of flavors, but the easiest way to think about it is grouping by project, by task, and by resource. Coding further should be thought of in two large categories: codes that apply to the entire project data structure to which everyone must comply, and codes that can be personalized project by project.

Some examples of coding might be:

• A project-level code that identifies the client of this project. This would allow projects to be grouped and sorted by client. This is key for client billing purposes.

• A resource-level code that identifies the department a particular resource belongs to. This would allow resources to be grouped by department as well as by project.

• A task-level code that identifies the project phase. This might enable us to create a report of tasks in different categories, such as design, documentation, or deployment.

Coding can be a simple list of values, such as a list of possible locations for a project, or it can be a hierarchical tree of values such as would be used in a Work Breakdown Structure (WBS) or an organigram of resources often referred to as a Resource Breakdown Structure (RBS).¹

If you are wondering how to decide what coding is appropriate to your organization, here’s a simple method of analyzing 90 percent of all coding requirements.

First, put key personnel into a room with a large white board. At the far right of the board, start listing important decisions that will be made using the resulting analysis or reports from the EPM system. An example decision might be selecting priorities for each project. From each decision, work your way left from right. To the left of the decision, show the final report or reports that would be required in order to make that decision. An example might be a resource conflict report and a project priority report. Draw an arrow from the report(s) to the decision. Left of the report, show a box with the calculations or analysis that would have to be done by the system in order to create that report. An example of an analysis might be a resource leveling calculation of all projects. An arrow goes from the analysis or analyses to the report(s) that require it. To the left of the analysis you can now list the elements of data that the analysis requires. This list defines your key enterprise coding. Using this simple technique and involving a good representation (better yet, everyone) who makes decisions based on the EPM system, you will quickly determine which requirements are critical to the data being able to be grouped together in the manners you’ll require.

Resolving Conflicts Such As Use of Resources

For many managers, most of their project-oriented time is spent trying to figure out how to answer resource capacity planning conflicts. Avoiding these conflicts is not productive. It just makes every project a zero priority, and staff will end up working on whatever task is presented them next, or worse, on whatever interests them at that moment.

Resolving resource conflicts implies several things. First of all, you’ve got to be able to deal with both resource availability and resource requirements. Next you’ve got be able to compare them. It is the comparison of availability and requirements that displays any potential conflict. This may all seem obvious, but remember that we’re referring to all the resource availability and all the requirements. This means that all project loads, as well as all availability, must be defined in similar ways. Some of the issues you’ll need to deal with here include deciding on the resolution of the data. In some organizations, one group will wish to manage resources at a category level (e.g., engineers) and another will wish to work at the individual level. There is no hard and fast rule that says which one is better, but you’ll need to decide so that information is consistent across the system.

Next, you’ve got to make sure that project managers define resource requirements in a consistent manner. Some project managers may, for example, attempt to overestimate their resource requirements in order to lock their project team together for an extended period. Other project managers may not, and the result may be an unfair allocation of key resources.

There is a decision to be made as to how productive it is to remove a person from one project and put him on another project for a short period of time. His workload might show him available between tasks on one project, and it is therefore attractive to put on other work, but simple analysis usually doesn’t allow for the impact of changing thought processes. To make this point, think about an analysis that would indicate that you would be most productive to the organization if you worked on a task in sixteen separate projects today, each lasting thirty minutes. For most project environments, we’d know this would be impossible. Just the time it takes to change gears from one project team to another and to get the momentum required to do anything productive with that team can often take a lot longer than thirty minutes. There are exceptions of course, but you’ll have to decide what kind of resources and what kind of work can result in pulling people from one project to another. Studies have shown that interruptions of any kind can take as long as 25 minutes to recover from.² So, it’s easy to imagine making project resources terribly ineffective by having them change from one project to another too often.

Finally, the notion of prioritizing projects must occur. This can often be a highly contentious issue for the most senior levels of management. Any manager who elects that his or her project carry anything but the highest priority knows that can mean loss of resource allocation. We’ll talk about this more in a moment when discussing portfolio management. The idea of prioritizing projects should be part of an empirical analysis. The rules on what makes a project a high priority vs. a low priority are quite easy to get agreement on prior to deployment of your EPM system and just as hard to get afterward.

Regardless of the system you create for resolving resource priorities, you’ll need to set up some kind of referee to arbiter disagreements. This should a person or committee that doesn’t have a vested interest in the result or which can overcome personal bias.

Portfolio Management

For some, portfolio management is all about being able to group projects together for analysis and reporting. For others, it is mostly about the approval of projects from the earliest concept to final completion, such as “stage-gating.” Often the notion is combined with financial analysis or other management interests.

Key aspects in portfolio management include the ability to code projects so they can be grouped together for reporting or analysis. This is something you may have dealt with in your coding phase. The ability to organize the projects by priority from whatever perspectives are important to you is also key. Some examples include ranking projects by risk, by return on investment, by alignment to corporate strategy, by cost, by revenue, by manager, or by client.

One of the most interesting aspects of this kind of management is the ability to do forward-looking resource capacity planning. Given that all projects must now be stored in a central location, for the first time you may have the ability to see all resource loads simultaneously. This enables a “what-if?” analysis where the impact of a temporary addition of a proposed project can be assessed instantly. The old system where Marketing invents a delivery date based on a hoped-for schedule can be eliminated in favor of a promise based on actual capacity.

All that’s required to deliver this is to create a high-level project plan for the proposed project and then slot it into the existing system with a priority assigned. The impact on all other work when using an EPM system can usually be determined in seconds. Coding must be used to allow proposed work to be distinguished from existing work so that the two aren’t mixed up.

The Ability for Project Team Members to Interrelate

Collaboration. This single word has spawned a entire category of project management tools—“collaborative” project management. It’s an interesting notion because collaboration is something that can only be enabled by technology, not created by it.

Enabling collaboration would seem to be a natural aspect of project management. A project manager never works in a vacuum. The fundamental purpose of a project manager requires them to communicate with team members, sponsors, clients, and so on.

Collaboration can play a key role in an EPM environment. Fundamentally, any function of the EPM system can be considered a collaboration function. These usually include things like instant chatting with team members, the ability to notify team members of events in the EPM system through their regular email, instant messaging, or mobile device. It may also include the ability to create elements such as mini-Web sites, online surveys, or online update forms. When we think of the work required for many team members to interact on documents or the necessity of being alerted to change management issues in a timely fashion or when they exceed established thresholds, collaboration takes on a whole new level of significance.

This kind of functionality isn’t trivial. In the past ten years, the entire project management industry has focused more on having project team members communicate and work together than it has on the algorithmic nature of project scheduling. As interesting as it might be to create the ultimate theoretical schedule, actually managing a project has everything to do with communicating and only a little to do with calculations.

One of the pitfalls in looking at EPM systems is the tendency for some to believe that if they purchase an EPM system with collaborative functionality, project team members will automatically collaborate. This may not be the case. If this is one of your goals in deploying EPM, it’s worthwhile to ask why personnel don’t collaborate already.

Here are some questions that you can ask as a litmus test to see if you’ve got more work to do on the cultural side of deployment than the technical side in order to enable a collaborative environment:

• If project managers share their data with the organization, will managers use it to punish them?

• Does it concern you that if you share your data with other project managers, they may use it to take unfair advantage?

• If staff members enter an entire week of work on a single integrated timesheet, will they be concerned that the data will be used to unfairly evaluate them?

If project team members aren’t collaborating now, the reasons are almost always culture based rather than technical. You’ll need to do some work to evangelize the benefits of collaborating and even make changes in procedure to ensure you remove roadblocks to participation by team members.

EPM SYSTEMS

Given the interest in bringing project data all together, computer systems are ideally suited to showcase this kind of process, and numerous vendors are keen to show what they can do for you.

There’s no way in a few pages to show everything there is available on the market, and even if we did, these systems are being updated constantly, with new functionality being released on what sometimes seems to be a daily basis. The trend in the EPM systems industry is in itself interesting. In the late 1970s and early 1980s, we saw the first multiproject systems available as commercial packages. Their orientation was very algorithmic; focused on the calculation of the schedule and the calculation of resource requirements. More recently, there has been a major trend away from the algorithmic perspective and towards a more collaborative approach. This makes sense. While the theoretical best schedule is useful information, most project managers spend most of their time working on human issues and on dynamic decision making to resolve issues that arise on the fly.

That said, what functionality should you be looking for in an EPM system? Here are some fundamentals.

Single Repository

The system should provide for storing data from all projects in a single repository. For very large-scale deployments, you’ll need to look at functionality for amalgamating data from several large repositories into a single repository for reporting and analysis. Depending on your organization you may have to consider multinational access, access from slow communications connections, and other security and accessibility issues.

Portfolio Management

The system should have an ability to manage at a project level, allowing projects to be added or removed at will and to be grouped by multiple types of coding. A flexible coding structure should allow you to code the projects for use in a stage-gating approval and selection system. Also key is the ability to prioritize projects for resource management purposes.

Multiuser Access

If multiple users can’t access data at the same time to view current project data and do project updates, you haven’t got an enterprise system. The system has to be user friendly enough that nonprofessional users can access it with little training. End users can’t have their life become about servicing the EPM system. The system should be there to enable them to do their core work more effectively.

Enterprise Coding

What you’re looking for here is first of all a high degree of flexibility. No two organizations are the same and, therefore, no one can predict how you will need to group and analyze your project data. Ensure that the system you are looking at will be able to adapt to whatever coding you envision now and will have the capacity to extend to the grouping and coding you haven’t even imagined yet. Also, critical in this area is the ability to impose some coding as mandatory. Can the system ensure compliance with some critical code elements you have created? This is important when you are linking the EPM system to other corporate systems. For example, in a link with finance systems, you must ensure that work is only coded to accounts which exist and that 100 percent of the work is coded. Can the system impose this on all tasks?

Collaboration

Look for the simplest elements of collaboration. Does the system enable project management personnel to interrelate? Look for automatic notifications that can be integrated into your standard email or instant messaging systems. The ability to create communications areas such as project websites that are dynamically integrated with the project data can be of great benefit.

Document Control

Enterprise project management systems must also have the ability to integrate with or include functionality for document management, issue and change management, and other ancillary data that may not be schedule based.

Workflow

In larger organizations, the ability to define a sequence of events that must occur in a particular order can be of great interest. Workflow need not be a complicated affair. Can you list a series of steps and then identify when a step has been completed? This type of functionality is important when looking at phased project approvals or when considering any kind of change management, such as a change in project scope.

When looking at project software, the overwhelming number of products that purport to serve EPM requirements can be daunting. Start your analysis by looking around organizations you know already. Most project management associations will sponsor events where multiple software vendors can show their wares. Ask to speak to or even visit existing deployments where you can ask not only what has gone well but also what the most challenging aspects of the deployment were.

A simple search of the Internet will reveal numerous vendors, but don’t be fooled by claims or even independent analysis of who is “best.” There’s really no such thing. Given that each organization will have a different environment, be at a different maturity level, and have different requirements, it is perhaps more appropriate to ask what the most appropriate tool for your particular situation would be.

Don’t be too enthralled or concerned over functionality you haven’t identified in your list of requirements. Virtually every system will include functionality you can’t take advantage of right away. Focus on your key challenges.

One of the best things you can do when evaluating EPM software is to think of yourself as a “solution buyer.” There is much talk among software sales organizations to be solutions sellers but solution buyers are more rare. If these systems are the solution, then you should put some time into thinking about what problem they are to solve. Some organizations get caught up too quickly making a list of functions to be responded to. This list usually comes from a pre-supposed list of requirements amassed from existing systems. It’s the worst way to look for a new system. Start instead with the business challenges you wish to address then ask the vendors to respond with how they will enable you to overcome those particular challenges. The responses you’ll get will not only show you which vendors understand your problem but will also let the vendor respond in a much more imaginative way and to showcase how their particular product is appropriate for your situation.

If you’ve deployed an enterprise resource planning (ERP) system, you are likely to find EPM components either included or available as modules. The orientation of these systems will virtually always be more financial so there is a note of caution to take here. The standard sales mode of an ERP vendor is to focus on the integrated nature of the data and on the dangers of allowing disparate data systems to be supported. However, each management perspective will color how the system should be portrayed. If you have elected to deploy an ERP solution as your EPM product, make sure it will serve the needs at each level of your organization, not just for Finance.

DEPLOYING YOUR EPM SYSTEM

Deployment is where all of this conversation becomes real. There are many challenges in an EPM deployment, but you can avoid most of them by focusing on a few key factors.

By far, the most critical success factor is an appreciation by management of the nature of an EPM deployment. Too often senior management will believe an EPM deployment to be a technical project and it is mostly not. Thinking of deploying EPM as a change management project is the number one factor for success.

As with all change management projects, the next key element is ensuring you have sufficient management support for the duration of the project. This has to come from a senior-enough level to ensure compliance. There may be great interest in EPM from one level or another of the organization, but if it is not shared by an executive who can speak for everyone who would be affected, then the deployment isn’t going very far. Whichever executive is sponsoring the project has to commit for the duration and that’s longer than the installation of the EPM software. A typical deployment of EPM can take anywhere from several months to a couple of years from the initial concept to final deployment.

If you’ve overcome these challenges, the most significant decision you have left to make is whether to deploy in a “big bang” where everyone would stop managing in an ad-hoc manner on one day and start managing in an integrated fashion the next, or in a “phased-approach” where the concepts and technology would be rolled out to the organization over a period of time. Start your deployment with a small group who are committed to the success of the deployment. Plan to have these people become part of a core group of users who will assist the deployment effort. They will be able to work on evangelizing the deployment, on training, and on fine-tuning your project management processes.

If you are committed to deploying EPM, follow this advice: Treat your EPM deployment as a project with all the controls and structure you would use with any change management project, and your chances of success increase dramatically.

REFERENCES

¹ For more about the Resource Breakdown Structure, consult a project management glossary, such as http:www.maxwideman.com/pmglossary/PMG_R03.htm.

² Meet the Life Hackers, New York Times, October 16, 2005.