CHAPTER 25

Enterprise Project Management

Elements and Deployment Issues

CHRIS VANDERSLUIS, HMS SOFTWARE

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

Both senior management and the project management office (PMO)—or, in its absence, a centralized project management group of professional project schedulers and project managers—is highly interested in getting access to all levels of data regarding project management. The most common scenario we find in organizations today is ad hoc project management, where each project is managed in whatever way each individual project manager decides to do it. A PMO cannot function without project data, and if everyone is doing something different, the consistent collection of project management data gathered at the lowest level of detail is very attractive.

Enterprise project management can also be of great interest to individual team leaders who want to see the inter-project impact of different project groups, and who must resolve resource conflicts between teams. Even team members will find the prospect of less “management by emergency” a worthy path to bring order to chaos.

But before you embark on your own EPM deployment, it is important to know that EPM isn’t for everyone.

WHAT IS ENTERPRISE PROJECT MANAGEMENT?

Enterprise project management is the integration of project and resource data, practices, and analysis into a single process. For organizations that manage more than one project at a time or that have projects so large they must be broken down into component subprojects, the management of 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 from other areas of the organization is a fundamental goal of EPM.

Second is the management of restricted resources. There is virtually no effective project management environment in the world where resources are in excess. It is more likely 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.

PROJECT MANAGEMENT MATURITY

A project management maturity (PMM) model can help identify whether migrating to an EPM model is right for your organization. There are several popular PMM models including the OPM³ from the Project Management Institute (PMI), but the underlying concepts are the same.¹ All models show ad hoc project management, with the least mature way being that project managers manage the project in whatever way they decide to do it. The most mature would be a fully integrated enterprise with all project management being managed in a consistent, centrally managed structure.

It is an interesting concept, but the central premise—that the more integrated the project management environment of an organization is, the more mature it is—is not necessarily accurate. In some organizations, it is more effective to eschew the concepts of EPM altogether and to let individual project managers use whatever systems they wish.

The potential benefits to management of EPM seem obvious but they come with costs that are not all obvious. A centralized structure implicates several levels of management in project decisions. This may give management better visibility and serve to level the playing field, but it can hamper more experienced and connected project managers who know how to navigate their project through the corporate structure. Before accepting that the top level of the project management maturity model you are using is ideal for your organization, you must ask if that is the right level for you or if you would be better served being less centralized.

If EPM is right for you, then let’s look at how you can create your own EPM environment.

ELEMENTS OF ENTERPRISE PROJECT MANAGEMENT

The following subsections describe the five basic elements of an EPM environment.

Storage of All Project Data in a Single Location

Any EPM deployment must start with gathering data into a single location and, as the first element, it is often highly contentious. Gathering data does not mean focusing only on software; in fact, 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.

In today’s modern organization, many managers equate control of data with 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. For make an enterprise system possible, all project data must be stored in the same place and managed consistently. This may require negotiating access and control of some of these data.

Once you have access to the project data, there is still 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 how to name resources, when the data are brought together, we will find janitors, mechanical engineers, and the CEO all grouped together.

To bring these data together, standards must 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. You also need to agree on the frequency of the data collection and the level of detail that makes sense for your projects.

The use of the word standards 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 the standards required for managing projects together will ever be agreed upon, and if they are, they’ll never be enforced.

Along with naming conventions, you also must agree on the repository for the data. If you are implementing an EPM software package, then this part of your design may have been decided for you. 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 have to decide is where that data will reside. Different groups may argue that their project management needs are so unique that it is absolutely impossible for them to comply with a single repository for their data that is located somewhere else. These various interest groups must 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 analyses possible, so it really needs to be dealt with early in your design. 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 your data can be gathered in one place, project coding is your next challenge.

Coding comes in a variety of flavors. It is easy to think of grouping by project, by task, and by resource. The easiest way to think of what coding will be required is to think of the outputs of your EPM system either as reports or views of the data. If you need a report by department, you will need a department code. If you need a report by location, location will have to become a code.

You can further think of coding 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.

Here are some examples of coding:

• 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, and 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 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 is a simple method of determining 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 business decisions that will be made using the resulting analysis or reports from the EPM system. An example might be the decision of selecting priorities for each project. Think of this business decision as the output from your EPM process. From each decision, work your way on the board from right to left. To the left of the decision, show the final report or reports that would berequired 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. To the 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, you will quickly determine which data and coding requirements are critical to getting the business output required from the system.

Resolving Conflicts Such as Use of Resources

For many managers, an excessive amount of time is spent trying to figure out how to respond to resource capacity conflicts. These conflicts are exacerbated when there is no portfolio prioritization in place.

Resolving resource conflicts entails comparing resource availability with resource requirements. This may seem obvious, but remember that we are referring to all the resource availability and all the requirements. This means that all project and non-project loads, as well as all availability, must be defined in similar ways. There are several issues to deal with here. First, you need to decide on the level of detail of the data. In some organizations, one group wants to manage resources at a category level (e.g., engineers) and another wants to work at the individual level. There is no hard-and-fast rule that says which one is better, but you’ll need to be consistent.

Next, you’ve got to define resource requirements in a common 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 might not do this, and the result may be an unfair allocation of key resources.

Should you allow staff members to be switched from a project they’ve already started work on? Analysis might show that resources are available between tasks on one project, and it might look attractive to put them on other work, but simple analysis usually does not allow for the impact of changing from one team to another. Just the time it takes to change gears from one project 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 whether this kind of change makes sense in your environment. Studies have shown that interruptions of any kind can take as long as twenty-five minutes to recover from.³

Finally, projects must be prioritized. This can often be a highly contentious issue for the most senior levels of management. Managers tend to request that their projects carry the highest priority so as not to lose access to resources. Prioritizing projects based on empirical analysis can help align key resources to those projects that are best for the organization. The rules for determining the level of priority of a project are much easier to get agreement on prior to deployment of your EPM environment than afterward.

Regardless of the process you create for resolving resource priorities, you need to set up some kind of referee to arbiter disagreements. This should be a person or committee that does not have a vested interest in the result and that 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 a method of project approvals from the earliest concept to final completion, such as “stage-gating.”⁴

Key aspects in portfolio management include the ability to code projects so that 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 proposed project can be assessed instantly. The old practice where a client, department, or manager invents a delivery date based on a hoped-for schedule can be eliminated in favor of a promise based on actual capacity.

When you have this type of portfolio process, seeing the impact of a proposed project on all other work can usually be determined in seconds. The impact on management of such a process can be significant.

The Ability for Project Team Members to Interrelate

Collaboration

Collaboration has spawned an entire category of project management tools—“collaborative” project management. It is 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. Project managers never work in a vacuum; they communicate with team members, sponsors, clients, and others.

Collaboration can play a key role in an EPM environment. Collaboration functions include chatting with team members, notifying team members of events in the EPM system through their regular email, or using instant messaging or a mobile device. It may also include the ability to create elements such as mini-websites, 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. We now see more new courses in “soft skills” than in critical path calculations and more new software functions that are communications oriented than in high-end analysis. The rapid expansion of smart phone use and of a ubiquitous Internet means that project managers, team members, clients, and sponsors have an unprecedented ability to communicate in near-real time. Need a picture? It now arrives instantly. Need to see a video of that new problem? It can be sent from your phone to a computer screen on the other side of the world in seconds.

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 is worthwhile to ask why team members don’t collaborate already.

Here are some questions that you can ask to determine 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 the executives use the data to punish them?

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

• If staff members detail all their work on a single integrated timesheet, will they be concerned that the data will be used to unfairly evaluate them?

If project team members are not collaborating now, the reasons are almost always cultural 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.

ENTERPRISE PROJECT MANAGEMENT SYSTEMS

Given the interest in bringing all project data 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—too many to discuss here. Also, 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 multi-project 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 toward 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.

What functionality should you be looking for in an EPM system? The following subsections discuss some fundamentals.

Single Data Repository

The system should provide for storing data from all projects in a single repository. For large-scale deployments, you 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 important is the ability to prioritize projects for resource management purposes.

On Premises or Online?

Many systems are now available online as a subscription service, accessible from anywhere you can access the Internet. For some, this will be very attractive, as the hardware and technical hurdles are managed by the vendor. For others this type of service is unattractive either because they must work in a highly secure environment and are prohibited from storing project data outside the office network or because they have users who will not be able to access the Internet. So ask if the system is available for installation on your premises or as a subscription service or both.

Enterprise Coding

When all data must come together, they need to be coded. In an enterprise project system, the first priority is 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 that exist and that 100 percent of the work is coded. Can the system impose this on all tasks?

Collaboration

Look for the basic building blocks of collaboration and communication. Does the system enable project management personnel to interact? 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 procedures that must occur in a particular order can be of great benefit. 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.

SELECTING YOUR ENTERPRISE PROJECT MANAGEMENT SYSTEM

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. When you look at vendors’ websites, look at the client lists to see if you know any of them. 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. With so many vendors on the market, references are often a critical tool in system selection.

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 is really no such thing. Given that each organization has a different environment, a different maturity level, and different requirements, it is perhaps better to ask what the most appropriate tool for your particular situation would be.

Don’t be too enthralled with or concerned about functionality that you haven’t identified in your list of requirements. Virtually every system includes functionality that 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.” If these systems are the solution, then you should put some time into thinking about what problem they are to solve for you.

Some organizations get caught up too quickly in making a list of functions to be responded to. This is the worst way to look for a new system. Start instead with the business challenges you wish to address, and then ask the vendors to respond with how they will enable you to address those challenges. The responses you get show you not only which vendors understand your problem but also which vendors are imaginative in addressing your situation.

DEPLOYING YOUR ENTERPRISE PROJECT MANAGEMENT SYSTEM

Deployment is where all of this theory moves into practice. There are many pitfalls 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 mistakenly believes that an EPM deployment is only a technology project. 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 is not going very far.

Whichever executive is sponsoring the project has to commit for the duration, and that is longer than the installation of some software. A typical deployment of EPM from the initial concept to final deployment can take anywhere from several months to a couple of years.

If you’ve overcome these challenges, the next is to pick a deployment methodology. A “phased approach” where the concepts and technology are rolled out to the organization over a period of time is almost always the most effective. Start your deployment with a small group that is committed to the success of the deployment. Plan to have these group members 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.

Finally, if you are deploying EPM, 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

¹ Suhail Iqbal, “Organizational Maturity: Managing Programs Better,” in Ginger Levin (editor), Program Management: A Life Cycle Approach (Boca Raton, FL: CRC Press, 2012).

² For more about the resource breakdown structure, consult a project management glossary, such as http://www.maxwideman.com/pmglossary/PMG_R03.htm.

³ Clive Thompson, “Meet the life hackers,” New York Times Magazine, October 16, 2005, www.nytimes.com/2005/10/16/magazine/16guru.html?pagewanted=all&_r=0.

⁴ Robert G. Cooper and Scott J. Edgett, “Best Practices in the Idea-to-Launch Process and Its Governance,” www.stage-gate.com.