Maturity’s Impact on Organizational Change

July 27, 2012 | by Allen Young

Maturity doesn’t always come up as a significant factor in Organizational Change Management (OCM) discussion circles, but in my experience, you ignore it at your peril! I became aware of this issue while setting up Project Management Offices (PMOs) and doing enterprise Project Portfolio Management (PPM) tool implementations for two of the firms I worked for in the late 1990s. Ever since, I have made sure I took maturity into account on every major change initiative for which I’ve been responsible. Unlike assessing sponsorship and employing tactics to deal with cultural resistance, determining maturity’s impact on a change initiative is more art than science. Even after the scientific assessment work is done, it still takes experience and expertise to judge how much a lack of maturity will slow the change process, and thus just how much change you can introduce and how quickly it is likely to be absorbed. Too much change too fast causes severe organizational heartburn, and at worst can stop the change in its tracks almost as fast as lack of sponsorship.

Let me clarify that I’m not referring to an Organizational Change Management Maturity Model, which would rank the organization’s capabilities of managing significant changes on a recurring basis—typically on a 1 to 5 scale. Even if your firm is at the highest level of such a model, indicating that it has mastered the change management process, the maturity of the business function or operation being changed may still be low.

Some Examples
In PM Solutions’ line of business, we are often hired to help improve an organization’s project management maturity. Before we start building and deploying any of the components, we first assess the organization’s current level of maturity on a 1-to-5 scale, using our proprietary model. The composite assessment score tells us two things: (1) what the organization is lacking in terms of methodology, process, governance, tools and so forth, and (2) how fast it is likely to absorb and apply the new material we will be introducing. Our Project Management Maturity Model (PMMM) isn’t advertised as an OCM tool per se, but it certainly provides a significant contribution to it. Level 1 organizations will clearly need more time to adopt and institutionalize our solution than one that is already at level 3 or 4.

Here are some real-life examples of how maturity impacted the speed of implementation—or in some cases stopped the project before it even got off the ground:

A major hardware retailer wanted to implement Earned Value (EV), which they believed would help them get a better grip on their projects in terms of time and cost overruns, and give them the ability to make course corrections sooner and faster. While EV can certainly do that, I was initially concerned with whether or not the company had the foundational components in place.  EV is a more advanced concept for most companies, especially in the private sector. I soon learned that their basic project scheduling practices—including a WBS, resource and cost-loaded tasks, baselining, consistent application of actuals, rescheduling, and formal scope change control—were very immature, which meant they had no concept of schedule or cost variance, never mind more sophisticated EV measures such as Schedule or Cost Performance Indices (SPI/CPI). While they had solid sponsorship and a “burning platform” for change, their current project management maturity level was too low for us in good conscience to recommend moving forward with an EV implementation. I suggested to them that they’d gain significant improvements from putting some of the foundational components in place, such as a project management methodology and some key metrics, run with that for a few months, and then see how they were doing. They might still want EV, but I strongly urged them to consider it as a release 2 or release 3 component.

As the PMO Manager for a point-of-sale network provider in the early 2000s. I came aboard knowing up front that their project management maturity was low, and that portfolio management was nonexistent. I started out by introducing a basic methodology then, towards the end of my first year,  tried to implement some relatively straightforward portfolio management governance. I knew I had to keep it simple out of the gate—in spite of the fact that the lack of it was causing all sorts of resource capacity issues and gnashing of teeth between the resource managers and project sponsors—because it had never been tried before. I proposed that a portfolio steering committee of key executives be formed which would meet once a month to review the project portfolio; a simple spreadsheet to track the portfolio; and a scorecard to rank the projects by. The division president gave it his blessing; the steering committee was formed; and I assembled a proposed project scorecard which was largely based on strategic importance as priority #1, net present value (NPV) as priority #2, and with legal/regulatory compliance trumping both. The sole agenda of our first steering committee meeting was to review and approve the scorecard.

That first meeting ended as a fiasco, since every executive department head had his/her own vision of how to rank projects. Everyone wanted to satisfy their own personal agendas, because that was their level of maturity. By the second monthly meeting, one of the technology vice presidents proposed that we modify the scorecard to simply say that all proposed new projects be brought to the table with the desired finish dates and enough detail to be able to make reasonable educated guesses as to duration and resource requirements, and that the next lower level of management—largely the resource directors and managers—make up the steering committee going forward. Unless the affected resource directors and managers voiced any concerns about being able to meet the date on a proposed new project, the motion would pass to add the new project to the portfolio. If any resource conflicts arose, the division president would be the final arbiter and decision-maker. Everyone nodded approval at the new approach, and gave it a try. The revised scorecard was a hit. I was still concerned that the company was working on projects that were not aligned with the corporate strategy, and wasn’t always working on the most important things first, but at least we had cleared a simple first hurdle. Things like NPV and strategic alignment would have to wait for another day. In a land that from a project and portfolio management perspective had been dry as the Sahara, I realized that even one small oasis with water was a major victory.

The Tools Mirage. Many firms make the plunge into enterprise PPM tools without considering their PM maturity level or the organizational change impact such tools usually have. So many times I’ve seen these tools rolled out, only to find that:

  • the majority of the project managers didn’t understand project scheduling fundamentals (and had to be hastily trained after the fact)
  • the organization had never done timekeeping before, but was expected to use it for capturing actuals on projects (timekeeping is also a potential cultural resistance issue, especially in high-tech outfits that hire primarily younger engineering types, who don’t like “big brother watching them”)
  • there was no governance in place to be able to effectively take advantage of the tool’s portfolio management capabilities (no project scorecard, no project list, no steering committee, no portfolio management process, etc.)
  • the EV functionality was activated right away and top management started beating up all of the project managers whose projects lit up on the executive dashboards with yellow or red SPI and CPI indicators.

In almost every case, the sponsors who made the decision to buy the tool did so believing that their project management problems could largely be solved by a technical solution—a “silver bullet”—only to realize afterwards that things got worse instead of better, blame the tool, throw it out in favor of another vendor’s tool, and repeat the same mistakes all over again!

I did a PPM tool implementation for a small federal government agency several years ago that was in exactly this position. My implementation was to be their third and final attempt. Fortunately I had learned about OCM practices by then. I employed several tactics to help make the implementation a success, including a PM maturity assessment, an assessment of the history of the two prior failed implementations, a sponsorship assessment, an OCM Chart, a communications plan with a marketing plan built in, and a training plan that included educating everyone affected by the tool at every level. At first they didn’t see the value in what I was doing (“this isn’t project planning…we don’t want to pay you for this!”), but it became apparent to them as the project moved forward the value that OCM added.

The PM maturity assessment showed me that we needed to deploy the tool’s functionality in four releases: (1) basic scheduling and timekeeping; (2) advanced scheduling and reporting; (3) portfolio management; and lastly (4) EV—which was what prompted them to buy the tool in the first place. I then had to convince their executives that my four-step release plan—with EV in release 4 instead of release 1—was the best way to go. They initially weren’t thrilled, but conceded that they couldn’t afford a third failure so agreed to proceed as planned. Had we not taken the maturity of the organization into account, we would have surely failed as the two preceding vendors had; three strikes and you’re out!

On my next and last post of this OCM series, I’ll cover how the capacity of the organization affects the adoption rate of organizational change in much the same manner as maturity does.

Share your maturity impact war stories with me!

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

(13 votes. Average: 2.6 out of 5)

Rating:
2 Comments on Maturity’s Impact on Organizational Change

Arash Momeni says:

Very interesting article and thoughtful observation indeed! Many organizations initiate PPM and ePMO transformations without performing upfront assessments on processes and people. I have been dealing with the executives’ “early morning shower ideas” driving some of these strategic transformation activities that left the mid-level management with no clear direction on how to manage the changes and of course technology is always to blame!

Posted on December 22, 2012 at 4:12 pm

Allen Young says:

Hi Arash,
At its core, maturity level has a significant influence on how fast an organization can embrace the change, and to what depth/extent over time—even if all other factors are positive. You wouldn’t give the keys to a Cadillac to a young child and expect him/her to drive without incident on day one—even if you could afford the car and had trained the child on how it works—yet that analogy still occurs in organizations on a regular basis. Why? Because top management wants change to happen quickly but doesn’t always think things through. I’ve seen countless organizations buy technical solutions such as ERP, CRM and/or PPM systems to solve what are primarily business problems without taking into account the maturity levels of the people and process sides of the house, and then when things don’t work out, they blame the tool! Same idea with implementing a PMO—especially at the enterprise level. Technology is a terrific enabler, provided the people and process aspects are adjusted/improved accordingly to accommodate the new toys. In terms of feature/function adoption and utilization, I’ve found that the “roll-over, crawl, walk and then run” approach is usually the best way to go. I have yet to see the “boil the ocean” approach on anything attempted at the enterprise level work successfully anywhere.

Posted on January 2, 2013 at 9:58 am

Leave a Comment