Jan 21, 2014

Four Rules to Change By

Posted by Allen Young in Culture & Change Management, Project & Program Management, Project Failure & Recovery, Project Management Office (PMO) | 0 Comments

"Are we learning yet?"

Continuing my “wish list” of issues I would like to see covered in more depth in PMI’s new Practice Standard for Change Management (see the first post in the series here), today I’m giving a quick overview of the four top issues that Organizational Change Management practitioners encounter. (If you haven’t read my blog series on OCM, I invite you to do so: in it, I covered all these areas in greater detail. You can request a pdf of the full set of posts by emailing me at ayoung@pmsolutions.com.)

  1. Sponsorship, Always, Comes First

To implement organizational change, you need authorizing sponsorship at the proper level; without it, you may as well cancel the project now, because you will have a much lower likelihood of success. Sponsorship also needs to be cascading (all managers below the authorizing sponsor need to be fully on board) and sustaining (sticks with the project, and beyond once the product or service is implemented)., I’ve seen these and other shortcomings throughout my lengthy career, but the one that I’ve seen occur most frequently—and is a project killer when it’s not right—is having an authorizing sponsor at a level that is too low to properly effect change.

When we do a sponsor assessment for a client, we engage not only the person or people who brought us in (even if they are the ones funding the initiative), but the extended organization, including higher and lower management levels, and the project team members. What we strive to confirm is what kind of formal and informal power the authorizing sponsor has, does he/she have a track record of ensuring adoption and utilization of changes, and if resistance surfaces, will the authorizing sponsor be in a position to effectively deal with it? If not, we then determine what should be done to improve the situation. More often than not, we’ll recommend reassigning the role of authorizing sponsor to someone who is at a high enough level in the line organization to make decisions that people will respect and follow—and not just because of the reporting relationships, but because there will be repercussions if the people don’t get on board. Sometimes it’s a capability issue, where the designated authorizing sponsor is at the right level, but isn’t strong enough of a leader to affect change and overcome resistance. In those cases, we have to look closely at the individual, and determine if it’s something that can easily be taught and/or coached, or if someone else should fill the role.

Back in the Y2K days during the late 1990s, I ran a software development “center of excellence” PMO for a financial services firm. Not only was the company working on its Y2K initiative, but it also had a huge program going on concurrently to migrate about a dozen core systems from mainframes to client server technology—including brand new application software packages and custom development as well as new IT platforms. None of the mainframe-based systems were Y2K compliant; the plan was to make all of the replacement systems handle 4-digit years while they were being designed and constructed, thereby eliminating the additional labor time and cost that otherwise would have been needed to remediate any code in the older systems.  There was just one not-so-little problem: several projects within the program were running late, yet no one in charge of those projects or the program was willing to admit that they would not be fully operational prior to January 1, 2000—even if they already knew they wouldn’t be, primarily because it was against cultural norms and political survival to admit such failure. The challenge was that the project managers reported to application owner managers, not the PMO, whereas the Y2K project manager reported to me. The Y2K project manager wanted to conduct audits of each project to determine just how “on track” they really were. Since no one wanted to admit any of their projects were at risk of missing the Y2K date, the requests for conducting audits were met with severe resistance. We tried to escalate the issue through the software development director, and then to the operations vice president, but to no avail. The root of the problem was that the real authorizing sponsor for Y2K had been the software development director; it really should have been the chief operating officer.  Long story short, the Y2K project effectively ground to a halt, until federal regulators injected themselves into the fray. With two years still to go, it was fortunate for this company that this upheaval was resolved before it was too late. The Y2K project got back on track, and was successfully completed on time. If the sponsorship issue hadn’t been resolved quickly, we might have been reading about this company in the press as one of the few that crashed and burned from Y2K!

  1. When Change Challenges Culture, Culture Always Wins

…unless you have sufficient sponsorship, employing appropriate change strategies, to change the culture!

Our culture-based assessment questions are deigned to uncover the unwritten norms for the organization (as opposed to company-written mission or vision statements), and understand just how intensely the norms are practiced. Sometimes we don’t even get a chance to start the OCM assessment work before culture issues surface. Such was the case with a global biomedical firm where we recently assessed the organization in preparation for implementing an enterprise-level PMO. We were advised upfront that, based on multiple past experiences with consulting firms who had put their own interests before their clients’, it was not politically correct for us to lead the charge. Their PMO champion, who had been called upon many times in the past to lead mission-critical, cross-functional initiatives, and would soon be promoted to the head of the new PMO, had to be at the front of the assessment. We could operate behind the scenes, but had to remain essentially invisible to all other key stakeholders. Only the PMO head’s supervisor and the president of the company would have any direct contact with us. To make this work, we effectively had to train the PMO head to conduct interview sessions, distribute surveys and collect the results. We spent the first two weeks doing the training, and then turned the PMO head loose on the organization. Once we received the data, we were able to analyze it, and prepare recommendations over multiple deployment phases, along with an implementation plan. The PMO head subsequently presented this to all key stakeholders, and it was well-received. One of the early phase recommendations was project management training—probably the only time where their employees would become aware of PM Solutions. In this case, a wise leadership understood the best way to present change within the company culture.

  1. Resistance is Futile—But Sometimes Works in the Short Run

A PMO head from a prospective client contacted us in early 2012 about helping him roll-out a project management methodology to the IT organization. Since our normal practice is to only deploy what we build in concert with our clients, and not someone else’s work sight unseen, our initial reaction was that we’d need to conduct some minimal assessment of the content first. The PMO head wasn’t keen on spending extra time doing any further assessment work, saying he had already assessed what the IT organization needed, and that his primary interest was in deployment. After further probing, I learned that the PMO head, with approval from the VP of IT, had created the methodology on his own—without any involvement from the rest of the department, and that the methodology had in fact already been deployed, but had zero adoption and utilization. This was a classic case of resistance to organizational change! I tried to explain the dynamics of the situation to the PMO head, but he (ironically) resisted my prescription for what was needed—an assessment of what he’d built by us and key IT stakeholders before any re-deployment could occur, and that some re-building might be necessary. I further explained that the only other way the PMO head was going to get adoption and utilization of his methodology as-is would be if his boss took a hardline approach and made not using it grounds for substandard performance and/or dismissal from project teams. That approach might solve the immediate problem of methodology compliance, but might not solve the original problems that the methodology was designed for in the first place.

As I often tell my wife, “Some people just can’t be helped!” I wished the PMO head good luck in finding a resource for what he wanted, which he may have found in the short run, though I already knew what the long run picture would look like.

When we assess resistance, what we generally see is a pocket or pattern of resistance, which allows us to focus on it and decide how to best mitigate it. It often makes sense to include the resistors in crafting the change, which ends up with a better result more often than not. Either way, the bottom line is to add teeth to the change by encouraging the desirable behaviors, and discouraging the undesirable ones.

  1. Those Who Don’t Learn from History are Doomed to Repeat It … Over and Over Again

My teenage son and I love action/adventure movies, and one of our favorites is Terminator 2 – Judgment Day. T2 has some great lines in it. In the banter between John Connor and the “good” terminator (played by Arnold Schwarzenegger), the “good” terminator tells John that he has a built-in learning computer, and that the more contact with humans he has, the more he learns. The “good” terminator then continues to smash the steering column of every getaway car he needs so he can hotwire them, until John shows the terminator a set of keys tucked under a sun visor, saying sarcastically, “Are we learning yet?” [I use that line on my son whenever he does something stupid more than once.]

Sadly, many companies don’t follow this continuous learning approach and thus don’t learn from past mistakes on their projects—many of which have OCM roots.

Before my PM Solutions tenure began, I worked for Primavera Systems, initially as an Engagement Manager, and later as the Director of Training—from 2002 until just after the acquisition by Oracle in 2009. Once of my last consulting engagements included implementation of Primavera’s P5 (now P6) enterprise PPM product for the IT department of a small federal agency in Washington DC. When I arrived on site, I was informed by the IT PMO head that they had tried implementing comparable products twice before.  Primavera was their third—and final—attempt to implement such a tool. No pressure, but three strikes and we’d be out! I subsequently informed the client that I wanted to conduct an implementation history assessment. When I was challenged as to why, my first gut impulse was to blurt, “Are we learning yet?” butI thought better of it and explained that I needed to find out why past implementations had failed so we wouldn’t make the same mistakes. The client reluctantly agreed to allow me to proceed. After the results were in, it became clear what had happened in the past: lack of inclusion of all affected stakeholders, no development of associated processes to work in concert with tool functionality, out-of-the-box training for users that only gave them a general idea of what the tool could do and not how they would specifically use it in their jobs, no tie-in with their software development/IT methodology, and no contractual requirement that any of the agency’s multiple subcontractor vendors had to use it. I made sure that we mitigated those risks up front—even working with Procurement to help modify the contract language that would be used for all new and renewal subcontracts. The implementation was a success, in large part because of the history assessment, and became a feature in Primavera magazine.

I hope these pointers and anecdotes shed some light on the thorny people-and-process issues surrounding projects that introduce change to the workplace.

Next up in this series: Change Agents and Champions


(No ratings yet)


No comments yet. Be the first one!

Leave a Comment

search blog:

RSS Feed

Subscribe to our RSS Feed

Most Recent Posts
Blog Authors

view all authors

Blog Archives

Other project management blog sources: