Organizational impacts of EPM tools

These tools have the potential to improve efficiency and add to the financial bottom line, but they are not for everyone!

Several excellent articles on enterprise project management (EPM) tools have been published within the last couple of years—many in this publication. The ones I've read covered features and functions, how they support project portfolio management, how they measure-up against each other, and how to capture the data required. They all echo a common theme—EPM tools alone will not cure a firm's project management deficiencies. Many also have stressed that EPM tool implementations should be managed like any other complex project; that is, by exercising sound project management disciplines. Unfortunately, few articles have covered to a sufficient depth the organizational infrastructure issues that inevitably surface, that if not satisfactorily addressed can kill an EPM implementation.

These days, many software vendors offer EPM tools. Several of these tools are very slick, powerful, sophisticated, and have the potential for enormous benefits to the organization. Centralized databases are typically found in the higher-end tools, which store composite project, resource, and organizational breakdown structure (OBS) information. They can “slice and dice” the data into a plethora of statistical graphs and status reports by project, department, program, project sponsor, project manager, project type, client, and so forth. Several work in concert with low-end tools like Microsoft Project. Some tools are now web-enabled, which allows geographically disbursed organizations to use these products more easily than ever before. EPM tools allow project managers, functional managers, and executive managers alike, at the click of the mouse, to view statistical metrics and status information, view resource utilization and availability across the enterprise, track project progress and cost more effectively, and run “what if” scenarios for future planning purposes.

Because almost everyone wants these benefits, EPM tools can have a gravitational pull at the planetary scale on unwary managers—almost like attracting unsuspecting moths to an open flame! While some companies can take advantage of the benefits, not all can or will. To find out if your company is a good candidate for an EPM tool, you should objectively and accurately answer the questions in the “EPM readiness test” (see sidebar).

The Issues

I've had the responsibility of managing EPM tool implementations for two companies over the last four years. While the vendors (and thus the software packages) were different in each case, there were common organizational issues that both companies struggled mightily with, during and immediately after the implementations were completed. The issues, and each question in the “test,” fall essentially into four issue categories: executive management buy-in; corporate culture; project management maturity; and resources and capabilities.

These issues have very little to do with product features and functions, yet have far more impact on the success or failure of the EPM tool deployment. Whichever area your company is weakest in will become the weakest link in the EPM deployment chain. Your company can be strong in three out of four areas, but the weak one will still limit the effectiveness of the EPM tool to that level.

Executive Management Buy-in. There is more to this than just convincing executive management to spend the money to buy the tool—in my experiences, getting budgetary approval was the easy part.

Cost/Benefit Justification. Executives almost always want to know what the payback will be on any significant undertaking. Given the relatively high cost of EPM tools, you can expect to have to demonstrate how the tool will pay for itself, if not more. Doing a cost/benefit analysis for an EPM tool can be very subjective, especially if your company doesn't have good project metrics in place today. Since EPM tools don't generate any revenue (except for the EPM software vendors, of course), you'll need to focus on expected cost savings and performance improvements. Some benefit items to consider include:

D. Allen Young, PMP, works as a managing consultant for a multinational information systems service provider headquartered in Plano, Texas. He has 23 years of experience in the financial information systems industry, with the last 11 years primarily focused on running project office groups, managing project teams, building project management infrastructures, and teaching project management. He is a member of the PMI Dallas Chapter.

Opportunity to cancel unprofitable projects early, before too much money is spent on them

Reduction of redundant work

Reduction of rework

Reduced “fire fighting”

Improved communications

Reduction in time spent in status meetings

Optimization of resource deployment on projects, including less need to hire contract help

Better matching of resource skills with specific project needs

Better metrics history for forecasting future events

Better predictability, which leads to higher customer satisfaction

Replacement of existing project management tools.

Clearly, some of these benefits are easier to quantify than others. In some cases, you may only need to accurately forecast one or two major benefits. Say your company historically has taken on and finished projects despite the fact that they ran way over budget and/or the product wasn't profitable—the opportunity to cancel “loser” projects early in the project life cycle may result in enough savings to more than pay for the EPM tool.

If you are unable to successfully navigate the cost/benefit justification waters, you should stop here—it means you do not have executive management buy-in at all! If you're fairly certain ahead of time that you won't be able to justify the cost, it may be tempting to “sneak it in the back door” (for example, try to bring it in as part of another project's budget). Not only is this probably unethical, it can also be very dangerous. Sooner or later, people in the accounting department or executive management are going to see the bills for the software, hardware, and consulting services, and wonder what's going on. Assuming you're still permitted to use the EPM tool in a limited capacity, you'll have spent a lot of money on very little benefit. The key letter in EPM is the “E”—these tools are designed for enterprise use, and are priced accordingly.

Business Processes. Do your executives believe that your company's processes are in place and working, when in fact you know there is substantial room for improvement? If this is the case, you may have some political sensitivities and/or rude awakenings to deal with. If improvements need to be made to support an EPM tool, will your executives give you the time to create and implement them? I can tell you from firsthand experience that establishing processes in a world where few existed in the first place, while concurrently implementing an EPM tool, is an enormous challenge and not an approach I'd recommend. It's almost analogous to pouring the concrete foundation and erecting the framing for your house simultaneously! Not only is this extremely tough for the EPM tool users—they have to learn the processes and the tool at the same time—it's also a sure formula for burnout for the EPM implementation team.

Project Priorities. Many EPM tools allow you to run “what if” scenarios to determine the impact of proposed or future projects on current work and resources. In order to do that successfully, the enterprise not only needs to have a complete project portfolio, but also needs to understand the relative importance of each project. Do your executives meet on a periodic basis—hopefully, more than once a year at annual department budget planning time—to review and assign project priorities, or is everything “Priority No. 1”? Priority designation should also help determine how resources are assigned to projects. When everything is “Priority No. 1,” resources are often assigned inefficiently (on a first-come/first-served basis, on the negotiating skill of the project manager, on the whims of the functional managers.

Active Support. You will need active support from executive management to help overcome any of the other three issue categories—corporate culture, project management maturity, and resources and capabilities. It's really tough to “push that boulder up the hill” without it!

Corporate Culture. If your company is used to operating with little formal process or structure, it will take much longer for everyone—from executive managers down to the rank-and-file employees—to embrace and use an EPM tool on a consistent basis:

Accountability. If personal accountability for project success or failure is low and/or poor metrics are available to determine it, some project sponsors, functional managers, and project managers may be uncomfortable with the sudden high visibility of their work. In the “old world,” it may have been easy to hide mistakes, cost overruns, or poor planning; in the “EPM world,” there's no place to hide!

Business Processes. If the people in your company are used to some structure, including essential processes, standards, and procedures, it will be much easier to bring in an EPM tool. Companies without much structure or ones with disparate processes in multiple locations will have a hard time adapting to new or uniform business processes, never mind the EPM tool itself. Some key processes and standards that are absolutely essential to work with the EPM tool include:

Project directories: Where to store project plans and other project documentation. In many cases, project plans, templates, and so on, are stored in a specific location on the company LAN or WAN infrastructure so they can be mapped to or opened by the EPM tool.

Project schedules: Need to define the minimum requirements to work in concert with the EPM tool.

Project requests: How projects are started and how they are added to the EPM tool.

Project cost management: How project budgets and actuals are tracked by the EPM tool.

Project priority determination: How management determines the relative priority ranking of the project portfolio, to allow for the most efficient deployment of available resources, as indicated by the EPM tool.

Time tracking: The minimum standards for project team members to record the hours they spend on the projects.

Project team formation: EPM tools track resource availability; project managers and functional managers need to understand how resources are assigned to new projects and who has the authority to do it.

Project estimating: Once the EPM tool gathers enough statistics over time, how that information will be used to produce better estimates on future projects.

A word of caution here: If processes and structure are relatively new to the organization, keep them simple. The last thing you want to do is introduce complicated concepts (for example, Net Present Value, Earned Value) right out of the gate. You can work up to the more advanced processes later, after you've demonstrated some success and refined your simpler processes.

Time Tracking. If time is already being reported as a routine event each week, you'll need to understand to what level of detail. Does it cover project and nonproject time? If project time is logged only at the project level, be aware that many EPM tools allow time to be reported at the detail task level. This allows for more precise metrics, resource utilization, and availability tracking. The downside to that precision is that the individual time data entry screens may become quite large (for example, if someone was assigned to five tasks each within five projects, 25 time reporting entries would be required). Some data entry screens are designed to require time entries for each day of the week or month. If your people aren't used to this much granularity, resistance is sure to follow. One tactic I've used to reduce the granularity is to ask project managers to assign resources to higher-level summary tasks (for example, at the project phase level). The downside to this is that it clouds the resource availability picture. If most people aren't responsible for tracking hours worked, and this is a key component of the EPM tool, be aware that the “big brother is watching them” fear may surface.

Additional Duties to Perform. If most people are already under high stress or have heavy workloads, bringing in an EPM tool (with the additional administration work that comes with it) will be about as welcome as a tornado dropping down during a hurricane. You will need to demonstrate how the tool will eventually help reduce their stress and workload levels, and that the extra they are being asked to do (log hours worked, follow project planning standards, and so forth) will pay off. Help them see the bigger picture so that they won't be as likely to get caught up in what's immediately in front of them.

Project Management Maturity. Much has been written lately concerning this hot topic. While there are still arguments over the single best way to measure project management maturity, some basic tenets apply universally that will have a profound impact on any EPM tool deployment:

Project Management Discipline. Are managers in your company, at most levels, advocates of basic project management disciplines, or do they view it as administrative overhead? If it's the former, you're way ahead of the game. If it's the latter, you'll either need to convince them of the benefits or give up the idea of using an EPM tool entirely.

Project Management Knowledge. Does your company have a PMI^® group membership? Are senior project managers PMP® certified? Do other people beyond the project managers have any basic understanding of project management practices? Is there a formal project management training program in place, either in-house or externally? If your answers slant more toward “no” than “yes,” the learning curve for the EPM tool will be significantly extended.

Methodologies. EPM tools generally are easier to use if templates exist, especially for project plans. The existence of templates generally implies that some sort of standard project methodology is in place. If your company has neither, you will need to do some work in this area. The minimum requirements will be to create a basic project life cycle model and create some generalized project plan templates for the types of projects that are most frequently performed. Keep this first set of templates simple “small,” “medium,” and “large” project plans should suffice in the early going. You can add more for repeatable types of projects later.

Project Planning and Scheduling. Many EPM vendors will assume that your project managers already know how to create basic project plans. Presumably, this would include prior experience with lower-end tools such as Microsoft Project. If this is not the case, you will need to invest time training staff in the basics. You may have a significant conversion effort to do, including scrubbing existing project plans to interface properly with the EPM tool and/or the creation of new project plans for active projects. If your company is sophisticated enough that subproject plans are frequently linked to master plans, be sure that the EPM product can support this.

Estimating, Budgeting, and Cost Tracking. Surprisingly, there are still many companies that do not track costs at the project level. They rely on traditional general ledger systems, which track costs at the department or profit center level. Costs for individual projects are often “imputed,” meaning that no exact figures are available—the Accounting department will do an averaged allocation for labor hours, and must retrieve specific invoices from the accounts payable files to determine non-labor costs. EPM tools are usually designed to track costs at the project level, which can make integration with existing department-based cost tracking systems difficult. The benefits to tracking project costs are obvious—they help with more accurate estimating and budgeting for future projects—but if you aren't doing project cost management today, you have your work cut out for you.

Resources and Capabilities. EPM tool implementations should be managed like a mission-critical, high-visibility client-based project:

Vendor Selection. Your selection team should go through a formal Request for Proposal (RFP) process. You'll want to solicit feedback from all affected areas of the company. You want to match the product as closely as you can to your organization, from feature, function, capacity, compatibility, and cost perspectives. Just because “Brand X” works for one company doesn't mean it'll work just as well or better for yours. Ask for product literature and demos. Ask for references, and check them. Don't agree to be the “guinea pig” on the beta product or the newest release of the software—go with the version that has been successfully used at other companies for six months or more.

Contract Agreement Considerations. As most software engineers will say, “All software has bugs.” Be sure to include remedies for your company in the contract, should the vendor's product not deliver what was advertised or fail to perform. Unless you're buying enough licenses to cover the entire enterprise up front, ask for a discount for additional licenses purchased by a certain date in the future.

Product Cost. High-end EPM products cost well into six figures (or more), depending on the number of user licenses required, and consulting services, plus the hardware platform to run it on. And, don't forget about ongoing software maintenance and product upgrade costs.

Project Team. Once you've chosen a vendor, you'll need a project manager and a team consisting of trainers, business process developers, database administrators, software installers, and vendor consultants. Ideally, the project manager and other key resources should be fully dedicated to the effort—anything less will extend the project timeline. The other project team members need not be fully dedicated throughout the project life cycle, but will need to be fully engaged at the proper times. Be sure to schedule vendor consultants’ time well in advance—they are often tough to get on short notice (this also means that the project manager will need to keep a fairly tight project schedule—critical path slippage may force rescheduling of consultants, which can extend the timeline significantly).

Documentation. The project manager will need to create the usual assortment of project documents for the EPM implementation, including a project charter, project plan, project budget, issues log, rollout plan, and to report progress regularly to the project sponsor. Other deliverables from the project include training materials and user manuals.

Hardware and Communications. You'll need PCs that have enough processor speed and memory to run the software, and servers with sufficient horsepower and capacity. You'll need to have enough data communications bandwidth to handle the message and data traffic (pay special attention to geographic sites outside of the home server site). If you buy the EPM tool without evaluating your hardware and communications capacity beforehand, you may be faced with having to upgrade or hurriedly replace underpowered components. Once the EPM tool has been purchased, it isn't of much value sitting on the shelf, waiting for the capacity to be upgraded. Also be aware that this area can be a big-ticket item. If your capacity needs an overhaul, the costs here can exceed the costs of the EPM tool itself!

Additional Software. You'll need a compatible operating system (such as Windows 95, Windows 2000, Windows NT) if you don't already have one. You'll most likely need a database engine (Oracle and SQL are the most common). Make sure that the versions of the operating system you have are compatible with the product you are buying. If the EPM product is web-enabled, you'll need a web browser. You may also need to purchase report writer software. For example, Microsoft Access and Crystal Reports are commonly used to create customized reports.

Data Storage Capacity. Some EPM tools will archive project data for an almost indefinite period of time. You will need to determine how much data needs to be stored and for how long. This will need to be converted into a data storage estimate, which will then be used to determine how much storage capacity you should buy. Don't forget to plan for future growth, as well.

Training. You'll need training facilities, with PCs connected to a training database. If your company is geographically disbursed, determine the most efficient way to conduct the training, to try to keep expenses (travel, equipment, facilities) to an acceptable level.

Ongoing Administration. You'll need a full-time EPM administrator for the tool, both during and after the implementation. This person is a key resource: he or she will be responsible for running daily jobs, producing and distributing reports, adding new people to the system, maintaining the OBS, managing security/access permissions, ensuring time reporting is done every week, handling questions from users, and resolving system outages. Additionally, once the EPM implementation is complete and the vendor consultants are gone, someone in the company will have to be fluent in the report writer tools (and fully understand the database structures behind them) so that additional reports can be created or modified.

Interfaces to Other Systems. To help maintain resource and OBS information more efficiently, it may be desirable to have the EPM tool interface with the corporate human resource management system. Cost information captured in the EPM tool may need to be exchanged with the corporate accounting system.

Some Final Pearls of Wisdom

Ideally, high-end EPM tools should be introduced toward the end of the project management maturity scale, not at the beginning. In a perfect setting, key prerequisites are done first, including basic project management training, process implementation, and methodology and template creation. It's also helpful to have the technology infrastructure in place ahead of time. I'm not saying that it's impossible to deploy an EPM tool without the prerequisites, but it's far more difficult and stressful for everyone affected and has a much higher risk of abandonment and failure in the organization.

Unless your company is very small, EPM deployments are much easier if they are done in a phased approach. Start with a pilot group of projects and users, or with one key department. When you've completed that successfully, conduct a post-implementation review, identify lessons learned, and make any necessary adjustments or repairs before you move on to the next level. Work your way up to the full enterprise gradually. If the tool you are considering will only deliver value if the entire organization uses it out of the gate, look for another one that will allow you to work toward that goal over time.

HOW DID YOU FARE on the test? While I am offering no guarantees here, this should at least give you a rough idea of your organization's state of EPM tool readiness. Before you embark down the EPM path, do your organizational homework! ■