Nov 6, 2014

EPPM and Decisionmaking: The Impact of Tools on Culture

Posted by Allen Young | 0 Comments

EPPM tools profoundly change the way companies get work done, which means human behaviors must change.

In part 1 of this 5-part series, I highlighted several key points that companies should consider as part of the EPPM tool selection process that relate to organizational change readiness, including sponsorship and cultural factors.  Having helped several clients with the tool selection process as well as the implementations themselves, I can say with 100% certainty that organizational change management activities should consume at least half—and in the majority of cases more than half—of the total work effort of a successful outcome. Implementing an EPPM tool is really no different from an organizational impact perspective than standing-up a PMO, implementing an ERP system, imbedding Six Sigma into the product development process, and so on. These things profoundly change the way companies get work done, which means human behaviors must change in order for broad adoption and utilization to occur.

With EPPM tools, the fact that they are designed to operate at an enterprise level implies that just broad adoption and utilization isn’t enough: EVERYONE must be on board in order for the benefits of the tool to be fully realized. The primary reason for this is that they are designed to capture project and resource data at the lowest levels, and roll-up/summarize that data into programs and portfolios for top management. Their job is to examine the summarized data on dashboards and reports produced by the tool, and make informed decisions—for example:

  • Program X has is now 6 months behind the original baseline schedule target end date, and our market analysts are now telling us that demand for our new product being produced by it may quickly decline because the technology for competing products in the marketplace is changing as we speak. If we can’t find a way to get it out the door in the next 2 months, we should consider aborting the program before we invest any more time and money into a potentially losing proposition.
  • Of all the projects and programs in our IT portfolio for the upcoming year, 2 fall below our resource capacity threshold waterline, based on our standard prioritization scheme, but we still believe they are important enough to get done. Do we want to alter the scheme to push them above the line, defer them to the following year, make exceptions, or hire additional staff to increase our resource bandwidth?
  • We’ve noticed a pattern of internal projects generally getting done on time but exceeding the budget baseline by 25% on average. Does that mean our cost estimation process is flawed, or are there other factors at play? Let’s do some drill-down into the types of typical activities within our biggest internal projects to see which ones typically give us the most trouble and have the biggest cost impact.
  • Our portfolio of projects in the local government sector are routinely missing our profit targets by a considerable margin. Perhaps we should consider getting out of the state government business entirely, and focus our efforts on more profitable sectors.
  • Program Y’s SPI index has now dipped below 1.0 and gone from green to amber on the Earned Value performance dashboard. After drilling down into the 12 projects within it, we see that 3 of them are causing the slippage. Let’s work with the project managers on those 3 projects to do some further root cause analysis to determine what steps we all need to take to get them back on track.

Of course, there are countless other decision points that top management may consider related to the overall project portfolio on an ongoing basis. Now, imagine what would happen if the detail data that feeds the roll-ups was inaccurate—garbage in yields garbage out, and top management would be basing decisions on erroneous information, which could be disastrous! The #1 goal of any EPPM tool deployment is data consistency at the lowest levels. Without it, you’ve built a house the way the Three Stooges did, and it won’t take long before it comes crashing down on top of everyone! Of course, when that happens, the tool almost always gets the majority of the blame. While no software product is 100% bug-free (even the common desktop office tools we use every day have some), it’s rarely the technology that failed—it was a fatal flaw in the implementation. The areas I’ve seen fail most often included a poor job on the process side, and organizational readiness that was either given short shrift or was ignored completely.

Next week: OCM Activities for EPPM Tool Implementations

Tags:
54321

(1 votes. Average: 5.0 out of 5)

Rating:

No comments yet. Be the first one!

Leave a Comment


search blog:

RSS Feed

Subscribe to our RSS Feed

Most Recent Posts
Categories
Blog Authors

view all authors

 
Blog Archives
 
Blogroll

Other project management blog sources: