Oct 29, 2014

Don’t Be a “Fool with a Tool”: Lessons Learned from the EPPM Tool Trenches

Posted by Allen Young in Culture & Change Management, Demand Management, Portfolio Management, Project Failure & Recovery, Resource Optimization, Strategy Execution | 0 Comments

Rigorous tool selection processes prevent some of the worst problems with EPPM from occuring.

PC-based project management software tools arrived on the scene in the early to mid-1980s; the first ones had crude graphics and reporting that was limited by today’s standards. The real value-add was the relational database network used to track a project schedule. For the first time, project managers could create a series of activities or tasks, and link them together via dependency relationships. As work was completed on a project and entered into the tool, the schedule would automatically show revised planned finish dates for all of the work that was incomplete or hadn’t started yet, as well as for the project overall. Instead of trying to create a critical path Gantt chart or PERT diagram manually, the tool would produce them with just a few clicks. Back then, having a PC or laptop for everyone in the company was rare, so the information was shared by printing the chart or diagram onto a huge piece of continuously fed paper via a plotter printer, and wallpaper a conference or “war” room with it periodically.

Things sure have changed! Over the ensuing decades, desktop project management tools morphed from standalone PCs to networked PCs to LANs to WANs to the web and most recently to the cloud, and have grown in sophistication and complexity along the way. Once the exclusive domain of project managers, they are now used by project schedulers and controllers, project team members, functional managers, executives, and even ongoing operations staff. Enterprise-based project and portfolio management (EPPM) tools with central databases, which began to appear in the late 1990s, are reaching a critical mass in terms of popularity today. Once dominated by a few major players, EPPM tools are now being challenged by dozens of cloud/SaaS-based products. While not as robust from a feature/function standpoint as their established older siblings, cloud/SaaS EPPM tools typically require a smaller entry investment and can be stood up comparatively quickly. The business case for purchasing and implementing EPPM tools has become clearer over time as well. One of the biggest sources of pain for most companies is limited resource capacity vs. project demand, and these tools can help companies manage their resources much more effectively at the project and portfolio levels than can be done manually or with desktop tools. (A recent article on how PPM meets today's product development challeges sparked my revisit of this topic, one I wrote about in PM Network  in 2001.)

What hasn’t changed are the challenges most companies face during and immediately after the tool implementations—despite advances in the tools themselves. After going through two such implementations over a dozen years ago, I realized the biggest issues by far had nothing to do with the tools themselves—it was the organizational change readiness and management that caused most of the heartburn!

Two other significant challenges are having solid foundational processes in place for project management along with governance processes to work in concert with the tool, and how to go about selecting the right tool in the first place. I learned firsthand—as well from as watching others--that when an organization tries to do this work completely by themselves without any prior experience, it doesn’t know what it doesn’t know, steps on most of the land mines, and typically treats the tool implementation as a technical instead of a business solution. Companies spend big money on EPPM software and the requisite infrastructure, and the best they are able to do is track time with it at the project level—which makes top management wonder why they bought such an expensive time tracking tool!  Since I’m a ”Three Stooges” fan, this reminds me of the episode where Moe, Larry and Curly try to build a house for themselves and their new brides from a do-it-yourself kit. Amazingly enough, they finally get it “built,” but when Curly’s new bride pushes on a vertical wooden post left standing in the middle of the living room, the entire house collapses! (I’m not sure, but this TV show may be where the expression “a fool with a tool” originated!)

Selecting the Right EPPM Tool

To avoid the collapse of the house, a rigorous tool selection process takes into account things such as:

  • Do we have the necessary authorizing sponsorship, and is it at the right level in the organization? Are all of the affected departments and business units on board, and if not, what will we do about it? Will this project be supported by management long after the implementation is complete, and how?
  • What are the business problems we are trying to solve? Did we collect input from all affected areas? Do we have a list of prioritized requirements, or are we planning to utilize every function the tool has to offer?  (Hint: trying to “boil the ocean” is a really bad idea!) Have we thought this through from an output perspective (who needs to see what, in what format, and how often)? Do we fully understand the prerequisites in terms of tool feature/function we want? For example, we want Earned Value, but does anyone know how to build a fully resource and cost-loaded project schedule, with a baseline and actuals applied so we can track variance?
  • What’s our budget? It needs to include IT and database infrastructure (or a cloud provider) if we don’t already have it, plus the EPPM tool, plus supporting software the vendor just told us we need (e.g., web server, report writer), plus ongoing maintenance and support for everything.
  • Do we have a sufficient project and portfolio management discipline/foundation (processes, methodology, governance) in place, or will we have to build it concurrently while we’re implementing the tool? Do we even know what core processes we need to have? We’ll also need tool-specific processes and procedures. Can the tool vendor help us with these, can someone else help us, or do we have to figure this all out for ourselves? Do we realize that skipping this crucial step means all we’ll be doing with the tool is automating a mess?
  • Related to foundational project and portfolio management processes, are our people skilled and mature enough in those areas to utilize an EPPM tool—and how can we tell either way? If not, can they be trained? If so, do we know what training they will need, and who can deliver it?
  • Are we planning to integrate the EPPM tool with other internal applications such as ERP (Finance, Human Resources, etc.), document management, asset management and so forth? Do we need to have those integrations in place right away or can we wait for subsequent implementation releases? Do we understand that if we really need it immediately that the EPPM tool data quality probably won’t be very high initially, and that it generally takes several months (yes, months, not days) before the quality of it becomes sufficiently reliable such that integration exceptions will be reduced to a minimum and management can make informed decisions from it?
  • Do we understand that introducing an EPPM tool may affect our company culture (e.g., high visibility into project status; tracking project time)? Will we have to change our culture to adapt to the tool or can the tool be tailored to adapt to how we prefer to do things?
  • Do we realize that implementing the EPPM tool will require our existing resources to perform functions that until now they may not have been doing as part of their normal job (e.g., updating a project schedule every week with actuals and re-forecasting the end dates each week). If our project managers are already working overtime more often than not, how will they fit the additional tasks into their work week (more night and weekend work, right!?). Should we consider introducing of a pool of project schedulers/controllers to help ease their project administration burden, thereby allowing them to focus more acutely on managing the project, the team and expectations?
  • What resources do we need? A project manager and team are needed to execute the implementation, plus ongoing support resources to administer the tool, support the platform, provide training, create dashboards and reports, and so forth. Besides the vendor’s consultant(s), who can help us with tool installation, configuration and training? Do we have the right people internally already, or do we need to hire them and/or supplement with other vendors or contractors?

There are additional points to be sure, but these are the most critical ones. Keep in mind that comparing tool functionality and purchase cost between multiple vendors is the easy part of the selection process. The rest is much harder!

Part 2 of this series will cover the organizational change readiness aspects of EPPM tool implementations, which have by far the biggest impact in terms of success or failure, regardless of the product selected.


(11 votes. Average: 2.3 out of 5)


No comments yet. Be the first one!

Leave a Comment

search blog:

RSS Feed

Subscribe to our RSS Feed

Most Recent Posts
Blog Authors

view all authors

Blog Archives

Other project management blog sources: