PPM: Everyone Gets To Play (Part 2)

In continuation to my previous blog post, this one will explain how the PPM needs of organizations drive the overall implementation process. At the enterprise level, we all recognize that different types of businesses execute different types of projects. The project portfolio for an investment bank is going to look a lot different from the portfolio at a company that designs and builds computer products, or a hospital, or a university. Even when we look at similar enterprises, we find differences in strategy, culture, and approach. Since many of these differences are the fuel for competitive advantage and operational excellence they require processes and practices which support those unique attributes.

Likewise, we need to recognize significant differences between functional areas  within the same enterprise due to the nature of the work being executed and the varying ways in which that work is done. The PPM needs for the product engineering groups are not exactly the same as those in HR.

Let’s take scope management as an example. For a company that is building something under a contract for another company, control over the scope of the project may be critical to assuring company profitability and in the most extreme cases the financial viability of the supplier organization. In this case, one would expect a much more structured, formalized set of processes for reviewing and approving scope changes and making changes to supporting contracts, payment schedules, etc. By contrast, when a department in one organization needs to communicate and manage expectations around delivery dates and costs for a sponsoring department within the same company – especially when the sponsoring department has requested the change — they may adopt a less formalized, lighter weight scope change process. In both situations changes the “what” of scope management is the same – scope changes need to be recognized, communicated and approved – but the “how” may be radically different.

We must also take into account that the approaches, tools and techniques used, even within a discipline may change over time. For many years, the construction industry used the Design/Bid/Build phases in their projects where each successive phase was substantially completed prior to the commencement of the next and each phase was executed by different organizations. Unfortunately, as a consequence of this approach many projects were plagued by a fourth phase, “litigation”, with finger-pointing and lawsuits between the parties to establish whether something was a defect in design or a defect in construction. Now many construction projects are using an approach called “Design/Build” where the work is performed and managed as a single, integrated effort. Similar changes have occurred in information technology, where new development tools and approaches have facilitated iterative and agile development of applications and business systems outside of the lockstep waterfall techniques of the past. Each of these has required new techniques for how the projects using them are planned and managed without losing the visibility needed for oversight and control of the outcome.

The most successful PMO’s and ePMO’s are those that understand the underlying goals and objectives of PPM while implementing supporting processes that are adapted  to the unique, changing needs of the enterprise, and the functional groups and disciplines within that enterprise. While this requires open-mindedness and creativity the adoption of PPM across multiple disciplines in thousands of companies is proof positive of the feasibility and be benefit to be derived from the effort. In short, despite the declaration of that gentleman at my first PMI meeting – PPM is relevant to Information Technology. And  to Finance, Marketing,  Professional Services,  New Product Development, Manufacturing, Supply Chain Management, Education and any other discipline or organization that invests in and executes projects. It also still applies to Construction and Engineering…

As a post-script I would add that since that first meeting I have belonged to PMI for many years and attended numerous meetings in a variety of other locations and chapters which were well attended by individuals from a wide variety of organizations and disciplines.

Improving Adoption and Usage of PPM in Your Enterprise

What makes a Project Portfolio Management solution deployment successful?  A great deal of hard work?  Definitely.  But there are some other ingredients in that “special sauce” that makes your PPM deployment succeed.  Let’s explore.

A few years ago Jack Welsh of GE fame led a keynote speech on large programs.  He was presenting to the business leaders of some of the largest enterprises in the world.  The speech began something like this:

“If you can’t get top management to support your program, don’t even bother.  Don’t even waste your time.”

Why did Jack say that?  Because to him, adoption of the program and solution is so important that a both are doomed to fail without that top level support – all the way from the top to the bottom.  You can spend an extraordinary amount of time, effort and financial resources around setting up a program, developing a methodology and implementing your PPM solution but without the team being ‘on board’ with your solution you will have a very difficult time succeeding.

Once we can secure an executive sponsor, and have them attend the kick-off, and elaborate why the initiative is so important, what’s next?  The next step is to make sure your solution takes advantage of a very simple setting – allowing project managers to ‘align’ their project with one of a limited number of corporate initiatives.  This simple step will serve two purposes;  it will enable the project manager to understand where their project fits (and more importantly, how it contributes) to the company’s goals as well as act as an indicator to tell the PMO and executive committee which projects are going “rogue” – those which are not aligned to any goals or objective.  One of the best examples that come to mind comes from the early 1960’s, before man landed on the moon, when President John F. Kennedy was touring the NASA Manned Spacecraft Center.  A humble and down to earth leader, JFK encountered a janitor as he was being guided through the facility.  He stopped the entourage and approached the janitor and asked him what he does there.  The janitor replied: “I’m putting a man on the moon.”  Surely he knew he wasn’t directly flying an astronaut to the moon, nor did the director of the space agency tell him to answer that way if the president asks.  No.  The mission of the center was so clear from the very top to the very bottom that every single person knew what their contributions were working towards.

Next idea has to do with appreciation for the stakeholders and user community.  A solution’s adoption is most successful when everyone is able to contribute to its design and change.  It is essential for the PPM Steering Committee (the team who manages the solution’s use and configuration) needs to capture end user feedback in order for the solution to evolve and grow with the program.  Why is this so essential?  Simply because when we set out to design the program, we may not have taken everyone’s perspective into account.  We may also not have thought about how each role would interact.  But more importantly, you increase the chances of success by casting your feedback “net” as broadly as possible.  There’s an old story that helps demonstrate this idea.  On some highway, a trucker is driving his semi.  He approaches a bridge with a sign that warns of 13’ of clearance.  Thinking he can fit, he continues onward only to hear the sound of crushing metal and his truck quickly stopped.  He gets out of his rig and finds his trailer wedged under the overpass with no easy way to get out.  The state police are called followed by the civil engineer.  Bridge plans are reviewed and a crowd starts to gather.  A little girl walks up to the engineer and says “mister, why don’t you just take the air out of the truck’s tires?”  The truck is lowered and is now able to roll out.  Sometimes the best ideas come from the strangest places.  But even more important, one of the people in the community was able to share an idea that had a direct impact on solving a problem, creating a positive environment across the entire community.

Of course, there are many other aspects to user adoption of your PPM solution, but getting the support from the entire organization, from the top to the bottom, is essential to the success of your continued deployment.

The Adoption Paradox

We’ve all heard this before: “It’s really important that everyone starts using this (tool/process/system) right away so that we will be more efficient and have all the information we need to run our business.  But remember, everyone here is very busy and we really can’t let this change interfere with their everyday work.”In other words – this change is important, but not important enough to invest the time and attention to ensure its success.   Even worse, when efforts fail, the blame gets laid at the feet of the implementers or whatever is being implemented.  Then the effort begins again, with a different set of players only to suffer the same fate.In contrast, organizations that are successful at change recognize that implementation and adoption are neither instantaneous nor automatic.  They recognize that the investment goes beyond the cost of the new system or the labor to implement it; there is also a significant investment of time and attention required from those stakeholders who need to adopt the new process, tools, etc.

Successful implementers and adopters know that that additional time is filled with activities focused on making a successful transition.  While training is important, practice makes permanent as the adopter adjusts their work practices and builds expertise in the new way.  Open recognition by leaders of the additional effort is also key; it reinforces the importance of adoption, helps the adopter balance their priorities between getting work done the old way and learning the new and, it helps reinforce new behaviors.

Last, but not least, the transition from old to new is always eased by strong advocates and proficient guides.  These are the people on the ground during the transition – answering questions and helping the adopters be successful.  Ideally these people have strong first-hand knowledge of both the old and the new and are comfortable recognizing and addressing objections and resistance.   And, most importantly, they have the time.

So, even though whatever is being implemented may ultimately save time, up-front time is required  to ensure adoption.   A couple of years ago I was in a meeting where a customer was sharing lessons learned on adoption from the implementation of a new ERP system that had been introduced two years prior.  As he reflected back on the adoption over the past two years he observed:  “The first year we worked for the new system and then the second year it worked for us.”   We can always wonder how much pain could have been avoided with just a little bit of extra time.