Building the Process Foundation for EPPM Tools

November 17, 2014 | by Allen Young

Tool vendors won't tell you not to buy their product because your foundational processes are weak.

Rarely do organizations have any of the second level processes in place unless they developed them to work with a prior vendor’s EPPM tool, and the company is simply dropping it in favor of another vendor’s product. That means in most cases that they have to be created as part of the tool implementation.

The trickier part is what to do when the first level processes are either not followed, are weak, or don’t exist at all. The tool vendors won’t tell you not to buy their product under those circumstances (again, they are in the business of selling software; the foundational processes are your problem), so in order for the implementation to be successful, both first and second level processes have to be created concurrently—which is like trying to build an airplane while it’s in the air (EDS did a famous commercial on exactly that theme in 2000). This is not an impossible task, but it does require more effort and it takes a lot longer. Not only must the processes be created, they also have to be rolled-out to the enterprise along with the tool. Accordingly, adoption and utilization take longer.

So who builds the processes? In my experience, the tool vendors can assist with the second level, but rarely the first level. Either the company does it themselves (typically via a PMO), or brings in an outside consultant who specializes in this area. No matter who builds them, they should be reviewed and blessed by the responsible managers before deploying them to the masses. Operational process owners should also be designated, because once the consultants and vendors leave, the company will almost assuredly have to make adjustments and improvements to them along the way.

A Release-based Approach to Implementation

The hardest part is knowing exactly how much EPPM tool functionality to deploy at any given point in time, and how fast it can be successfully rolled-out—in short, how many releases should be done over time. A knowledgeable consultant will use the OCM, project and portfolio management assessments to help gauge these factors.

For example, one of my first Primavera implementations was for a major financial institution based in New York City. They were so certain that they were mature enough and were routinely used to organizational change that they wanted to activate and use virtually every feature and function of the tool—including Earned Value graphs and reports. When I tried to convince them that they should least break up the implementation into multiple releases and not go with the “big bang” approach, they counter-argued that they were a CMM level 4 shop, all of their project managers were certified PMPs, they had sponsorship from the CIO, so they wanted to go full speed ahead. I finally managed to convince them that they need to do 2 releases at a minimum to help mitigate the risk of tool abandonment, so they reluctantly took my advice, though release 1 was overloaded with functionality by their choice. Only a few months after the implementation of release 1 was complete, their project manager admitted to me that “their eyes were bigger than their stomachs," to the point that we were called back in to do a “health check” and provide recommendations for improvement, which included more training with some coaching and mentoring, and bringing in some project controllers and schedulers to help take the tool administration burden off of their already overworked certified PMP project managers.

While PM Solutions does not sell EPPM tools or stand them up, and thus has no bias or preference for one tool over the other, we do assist our clients with tool selection, organizational change management, and process management—all crucial elements of a successful tool implementation—while working in concert with the tool vendor. We know what, in most cases, our clients don’t know regarding EPPM tools, including where the land mines are, and how to avoid stepping on them!

About the Author

Allen Young

Allen Young manages existing client account relationships and assists Business Development staff during presales and proposals with new prospects. He oversees all consulting engagements in his region, including formal program reviews and informal checkpoints with clients and consultants. Allen is a veteran project, program, PMO, and portfolio subject matter expert, covering the entire gamut from basic project scheduling to Earned Value. He has worked in multiple industries, including IT/software development, banking/financial services, insurance, government, retail, telecommunications, manufacturing, oil & gas, and construction.

Prior to PM Solutions, Allen held Director of Training and Consulting Engagement Manager positions at Primavera Systems (now part of Oracle). . Prior to that, he successfully established and operated PMOs for companies including Alliance Data Systems and Electronic Payment Services. He is also experienced in maturity advancement practices. As a Managing Consultant with Electronic Data Systems (EDS), his achievements included improving the maturity and project delivery capabilities of groups within the California State Automobile Association and the Navy & Marine Corps Intranet Program.

Allen holds a BBA (Business Administration) from the Wharton School, University of Pennsylvania. He has earned the designation Project Management Professional (PMP®) by the Project Management Institute (PMI®),. Allen has authored several project management and PMO-related articles for PMI’s PM Network magazine, and has presented numerous project, program, portfolio, and PMO subjects at various industry events.

View Posts by Allen Young

Tags:
21021

(6 votes. Average: 2.5 out of 5)

Rating:

No comments yet. Be the first one!

Leave a Comment