Skip to main content

From the Sponsor’s Desk – Eight Steps to PPM Implementation Success

In my last post, The Offshoring Challenge, Part 2, we looked at the challenges a company faced when it chose to use an offshore developer to rebuild its core administrative systems. They ran into oodles of issues and exceeded targets on budget and schedule but, amazingly, all parties were pleased with the end result. We also looked at how a great PM would have helped avoid or minimize the issues encountered and deliver an even better outcome.

In this post, we’ll look at an organization’s attempt to deliver project portfolio management (PPM) capability. In this endeavor, the IT department took it upon themselves to implement a PPM solution to curb what they saw as excessive and conflicting business demands without engaging those same business units in the effort. The project was NOT a resounding success.

The Situation

This organization provided insurance products for individuals and businesses across the country. The business units prided themselves on their innovative product offerings and were constantly refining and developing products and services to serve their markets. Lacking any formal assessment or priority setting mechanism, the IT organization struggled to respond to the growing demands for faster delivery and improved and expanded services. That left the business units frustrated with their inability to compete effectively in the marketplace and very dissatisfied with IT performance.

The Goal

The IT organization saw PPM as the means of dealing with the business concerns. It would provide the platform for assessing multiple, competing business demands and establishing organizational priorities that would enable IT to respond in a rational and managed manner.

The Project

The CIO assigned the VP responsible for the PMO to address the growing business dissatisfaction with IT responsiveness. The VP launched an initiative to implement a project portfolio management solution in the belief that it would address the problem. The target date was the start of the annual corporate planning cycle, seven months away. Because of the limited time available before the start of the corporate planning process, he chose not to involve the business units in the development of the solution.

The project manager assigned was to draw his staff from the PMO pool, using project managers between and during project management assignments. He was also charged with implementing the design on the parent company’s chosen project and portfolio management technology platform.

The Results

The PM proceeded to secure what staff he could from the PMO pool and set them to work exploring the PPM processes. They identified the information they thought they would need to evaluate project requests and establish project priorities. They reviewed their designs with the PMO VP and other IT VP’s and incorporated the feedback as they proceeded. However, progress on the project was impeded by the lack of staff and the reassignment of staff to other projects. The design work that was expected to take three months took six months. They had one month to get the solution implemented on the provided PPM technology before the start of the corporate planning cycle. With no knowledge of the technology, they were woefully unprepared for the task. With no time left they decided to introduce the PPM process to the business and hope they could get the technology up and running in time to support the planning effort.

With the PPM capture form in hand, the IT Account Managers engaged with the business units just prior to the start of the corporate planning exercise. They informed the business unit heads that, henceforth, a new portfolio management process would be used to determine project priorities and allocations. No more could they demand IT resources and facilities for their own latest pet project with going through PPM. No more could they inject their new project at any time during the year without going through PPM. No more could they suddenly expand scope on an in-flight project and expect IT to respond immediately to the change, without going through PPM.

You can guess how those encounters turned out! The business unit heads were outraged. They harangued the CEO and urged him to quash this perceived intrusion on their ability to operate as they saw fit. The CIO was so besieged, he capitulated. The project was cancelled. The PMO VP and project manager were dismissed. Life returned to its unsatisfactory past with half a million dollars down the tube.

How a Great PM Would Have Helped

This was a very difficult situation for the project manager. The sponsor, the PMO VP, needed to be challenged! The sponsor imposed constraints on the project that dramatically increased the risks; no business unit involvement, staffing with PM’s who were either on the bench or running other projects and the target technology. It was decision time for the PM and he folded. The lesson – don’t take an assignment if you don’t have control over the critical success factors. Here’s what a great PM would have done:

  1. Identify and engage the stakeholders – A great PM would have insisted that the business units be brought into the project. Yes, that could have yielded all kinds of resistance. And that’s exactly what a great PM wants to bring to the surface and resolve early in the game. It may also have results in shifting the initiative from the IT realm to business ownership with the CEO as sponsor.
  2. Know what problem you’re trying to solve – In the aftermath of the PPM project cancellation, the CIO launched another initiative to improve IT responsiveness and what it discovered was revealing. Poor project management practices accounted for over half of the business unit complaints. Limited availability of certain IT skill sets was responsible for almost 40% of project delays. Lack of a comprehensive standard technology infrastructure resulted in significant custom work, increasing costs and risks and adding further delays. PPM would have contributed some value but it wasn’t even in the top ten action items identified.
  3. Staff appropriately – what chance did this project have when it had to beg, borrow and steal from an uncertain pool, where the incumbents had limited or no experience with PPM, process design and the PPM technology. A great PM would have insisted on getting the staff and skills needed to do the job right.
  4. Establish prioritization criteria early – There was an assumption from the start that IT would set and apply the prioritization criteria. Wrong! The prioritization criteria IT presented to the business unit heads became the factor that generated the most resistance. IT was looking for things that most concerned them, like resource demand, technology platform impact, required timing. The business would have been much more amenable to the project if it had focused on things of interest to them, like support for business strategies, impact on revenues, costs and the bottom line. A great PM would have seen this as a critical success factor and addressed it early in the game.
  5. Get agreement on roles and responsibilities – The assumption that IT would be the final decision-maker on the priorities set the project on the wrong course from the very beginning. This was an enterprise wide initiative! A great PM would have recognized that fact and dealt with the question of roles and responsibilities early on, at least at a high level.
  6. Understand demand, capacity and cultural impacts – The PPM project being run by IT focused primarily on quantifying demand, understandably. However, had they been successful in implementing and running their solution, they would have soon encountered difficulties with the capacity question and the need to understand and manage the allocation of resources and skill sets and the cultural influences (statutory holidays, vacation and education policies and other demands including advisory groups, standards teams, governance committees) that can consume 20% or more of available capacity.
  7. Take little steps – The PPM project consumed the majority of their available time in the design of their PPM process. They had little experience with and knowledge of PPM and no confirmation that they were on the right track outside of IT. A great PM would have recognized and mitigated these risks with a plan to test early and often. It would have also served to get the business engaged much earlier.
  8. Measure and communicate, early and often – This factor, or lack thereof, was actually at the heart of the IT/business conflict. IT lacked formal communication approaches and so the business and IT executives never were presented or saw the whole picture. They lacked metrics to assess ongoing performance of services that were important to the business so there was no context for business complaints. At a project level, communication was left up to the individual PM. There were no established reporting templates or distribution standards. A great PM would have understood that transparency and visibility are critical to project and organizational success. A great PM would have ensured that project targets were established, progress was measured, risks identified and mitigated, issues identified and managed and stakeholders informed in a form, medium and time frame suitable to their needs.

If you find yourself in a similar situation, put these points on your checklist of things to do so you too can be a great PM, and your sponsor’s best friend.

Next, we’ll look at a situation that I call Delivering Portfolio Management Light. The organization in question found itself in need of a decision- making framework as a result of a re-organization and managed to deliver a workable portfolio management solution in a little over three months.

In the interim, if you have a project experience, either good or bad, past or present, that you’d like to have examined through the Project Pre-Check lens and published in this blog, send me the details and we’ll have a go.

Don’t forget to leave your comments below.

Drew Davison

Drew Davison is the owner and principal consultant at Davison Consulting and a former system development executive. He is the developer of Project Pre-Check, an innovative framework for launching projects and guiding successful project delivery, the author of Project Pre-Check - The Stakeholder Practice for Successful Business and Technology Change and Project Pre-Check FastPath - The Project Manager’s Guide to Stakeholder Management. He works with organizations that are undergoing major business and technology change to implement the empowered stakeholder groups critical to project success. Drew can be reached at [email protected].

Comments (4)