Why Projects Succeed: Organizational Change Management

Why Projects Succeed: Organizational Change Management
By Roger Kastner

Is change management or project management more critical to project success?

Before you answer, let me tell you about two examples that might impact your response.

Like many of you, I’ve been on a few projects where I was able to appropriately set and deliver on expectations on scope, schedule, and budget (“on time, on budget, high five!”), only to have the end product of the project be a big fat zero in the marketplace.

One project I successfully led to an on-time and on-budget release had to be turned off six hours after being launched. The features in the newly released product generated such negative reaction in the marketplace that our company experienced a huge spike in complaints to the call center. The call volume was so high that it triggered a rarely used company policy allowing our customer care team to remove the new release from production without conferring with our product owner. Ouch.

If the measurement of success was delivering on scope, schedule, and budget, i.e., the holy trinity of project management, we nailed it. However, if the success was measured by ROI—which it should be, by the way—it was an undeniable failure.

With this project and any other project where I had successfully delivered the project on time and on budget yet the end product landed flat, we obviously had not done enough (or any) work to validate that customers wanted the product, or prepared end users for the product of the project.

Contrast that experience with a project I worked on where I took over the project management duties several months after the previous project manager was “forced” into agreeing to unreasonable expectations for scope, schedule, and budget. By “forced,” I mean he was unsuccessful negotiating with the business owner who had unreasonable demands for project scope, schedule, and budget. To make matters worse, the project manager lacked sponsorship from his management to back him up in his attempts to appropriately set expectations.

Sure enough, by the time I had arrived, the budget had been blown out of the water and the target launch date was in serious jeopardy. The project was in such a bad place, my corrective action plan identified that we’d only be able to hit our schedule if we increased our team size, which meant a 50% increase in our budget and lowering our priority requirements into a future phase of development.

Even with all of these challenges and performance issues going on, the project team had done one thing extremely well from the start which would prove to be crucial to delivering success: getting customers involved in the project from day one. They ensured end users were involved in identifying why the new product was needed by engaging them to review prototypes, help test features, and even training other users in how to use the new product.

Once we launched, even though we needed 50% more money and had to defer some features that were originally promised, the products still landed with the target audience because end users had been involved since the project inception. And since the end users were successfully able to use the product to do their jobs, the product delivered on its expected benefits to the organization, maximizing its ROI even with budget issues.

Senior leadership and end users, forgetting any of the scope, schedule, and budget challenges, absolutely declared the project a big success. Now, if you asked the people on the project team (who had a vitriolic relationship with the business owner and had worked months of overtime) what their level of satisfaction with the project was, they’d say somewhere in between “low” and “couldn’t get any lower.” No one on the project team would declare the project a success nor would they want to duplicate that experience.

Let’s look at the scoreboard: in the first project, we nailed project management nirvana by delivering on scope, schedule, and budget; however, because we ignored change management, it was a failure. In the second project, we failed on project management, but, we nailed change management, and the project was deemed a huge success.

Now, back to the original question: which is more critical to project success, project management or change management?

I will borrow a principle from improvisational comedy and answer with a, “Yes, and…” Imagine if we nailed both disciplines of project management and change management on a project. That is a recipe for success.

Impact of Change Management on Project Success

Every project attempts to introduce a change for a target audience. Projects are approved and funded with the expectation of achieving an economic result, and that result requires a change, on some level, in behaviors and actions. Whether the project is implementing a new payroll system or producing a new aircraft, the project will introduce a change.

The discipline of change management is a systematic approach for cultivating leadership support and end user acceptance for the attainment of a successful change. Change management can target organizational behavior and performance; for instance, attempting to increase the amount of accountable behavior exhibited by management. Change management can also be applied to attain adoption of the end product of a project. In both instances, the framework and approach can be similar, just as project management is similar on small- and large-scale projects. And that’s not the only similarity between the two disciplines.

The Standish Group’s annual Chaos research, going on for almost two decades, shows that roughly 30% of IT projects are delivered on time and on budget. Not great results. The research on change initiative success rates, such as IBM’s Making Change Work and McKinsey Consulting’s Change Management research and others, point to an eerily similar 30% success rate.

I think those success rates are an indication of the performance of practitioners in both disciplines, but not an indication of our capabilities to execute the work. Instead, it starts earlier in the project when we allow for higher-than-reasonable stakeholder expectations to be set. Of course, there are poor-performing practitioners out there, but I believe the key word is “expected” in the statement “70% of initiatives achieve less than expected results.”

Now Project Managers Need to Do Project Management and Change Management?

The Why Project Succeed series has focused on the key things that contribute to successful projects, and when I share with project managers that we need to include a focus on change management, I usually get an exasperated look of, “What?!?! I need to do more than project management?!?!” My response is always no, you likely need to do less and focus more on what contributes to success. And since a successful project requires adoption of the end product, change management is one of those top-contributing success factors.

3 Principles of Change Management

So, how does the successful project manager adopt change management without doing two jobs or attempting to do too much?

Some initiatives will benefit from a dedicated change management approach that will be separate from the project management focus. That said, there will likely be projects where change management will not be a separate function, and in those instances, the successful project manager will adopt some of the change management principles to drive adoption of the end product.

Here are three principles that I recommend all project managers adopt to drive, um, adoption:

1) Change Impact Analysis

This analysis identifies in detail the changes that impact each role by identifying:

• the processes that are changing;

• the details of the change in the process;

• who is impacted by role and how much of an impact it is.

Once completed, then you can pivot on the role to see the aggregate amount and degree of change each role will experience.

This is a simple process, but the result is powerful. First, you will have created an inventory of change by process and role (always start with a documented list!). Second, you will see that not everyone is impacted by the change at the same level of degree. Being able to articulate who will be impacted and by what degree is very illuminating information, especially when you are planning your change management approach and leader focus. It also addresses resistance to the change.

2) Case for Change and Vision for Future

The first question people typically ask when a change is introduced is “why?” They yearn to understand first why the change is good for the organization, and then they ask “why is it good for me?”

The first answer needs to be articulated by the highest ranking leader possible, and no lower in the org chart than the project sponsor. The sponsor will need to articulate the Case for Change which captures the key circumstances and implications of the current-state challenges and rationale for why staying with the status quo is not acceptable. Just as important, the Vision for Future will set forth the target end state and the rationale of why that is preferable to alternatives and doing nothing.

Once the Case and Vision have been articulated, they need to be repeated. And repeated. And repeated. From the leader who first articulated the Case and Vision on down to the managers of the impacted individuals, the story needs to be consistent. Failure to have a consistent Case and Vision will raise doubts in the minds of the very people who need to accept that the change is good for the organization.

The fidelity and effectiveness of the Case and Vision can be measured both quantitatively and qualitatively and reported on to ensure the story is landing in the organization. If it isn’t landing in parts of the organization, more leader and sponsor attention is required to understand why. If it isn’t landing anywhere, there’s either a problem with the story, or the consistency in how leaders are telling the story.

The articulation and acceptance of Case and Vision are necessary to enable the second part of change dialogue, and that is setting the context for change from the perspective of the individual.

For effective change to occur, individuals need to accept that the change is good for the organization as well as for themselves. The only way for individuals to accept that change is good for them is to have the details and context of change to be laid out for them in a conversation with their manager. That conversation can be laid out as following:

• Ask the employee what he/she thinks about the reason for change and the vision of the future state. If the employee has questions, answer them. If he/she doesn’t think it’s good for the organization, ask why. If the employee does think it’s good, go to the next step.

• Share with the employee how the change will impact his/her role (e.g., providing the context for change), share the timetable for change, and then ask if he/she understands the change and thinks it will be good for his/her role. If there are questions, answer them. If the employee doesn’t think it’s good for him/her, ask why.

At this point, it will be clear if the employee is an advocate, neutral, or resistant to the change. This information can be tracked across the organization to provide metrics for adoption over the course of the initiative. At the very least, it will inform how much acceptance and resistance to the change exists in the organization.

3) Resistance Management

Project managers will be very familiar with this process, since Resistance Management follows the same approach as Risk Management, with the key difference being Resistance Management only focuses on the human risks to success.

Identifying resistance to the change will occur throughout the project, and assessing and identifying the appropriate responses to the resistance follows the same framework as Risk Management. The important distinction is that you need to ask the specific questions and look for the specific evidence for human resistance to the change.

When I perform the change management role on projects, these in fact are the first things I guide clients to focus on, with the addition of a stakeholder assessment. That stakeholder assessment is very similar to the stakeholder management approach within the project management discipline, with the possible difference of identifying if the stakeholder’s disposition toward the change and if the stakeholder is skilled in leading change. These two factors will inform the change management plan as to whether additional coaching or sponsor engagement is required.

How Change Management Benefits from Project Management

Combining change management and project management is just like the old Reese’s Peanut Butter Cup slogan: “Two great tastes that taste great together.” And it’s a symbiotic relationship; change management initiatives are more likely to succeed when project management best practices are applied, but that should be no surprise to this audience, right?

As an example, another project success factor that should be applied to change initiatives is Minimizing Scope & Requirements, as we should challenge and reduce the amount of change in order to make it more consumable. The paradox in reducing the amount of change for end users is that it usually requires more change on the part of leaders.

Both need to exist in order for both to succeed.

Summary

I have never been a fan of measuring project success, and therefore the value of a project manager, solely on the ability to deliver on time and on budget. Attainment of the targeted return, achieving desired benefits, happy stakeholders—these seem like crucial factors in the definition of success… or at least they should be.

And therefore, I believe the project manager of the future will need to evolve his/her focus from Scope, Schedule, and Budget to include a fourth member—Adoption.

In this vision, the project manager of the future is not responsible for performing the role of the change manager on the project, just as the project manager is not responsible for writing software, attaching the wing to the fuselage, or swinging a hammer. However, the project manager is responsible for scheduling the work, assigning the work, and ensuring the work gets done, and that definition of “work” will need to be expanded to include “ensuring adoption” in order for the project manager to increase the odds of the project achieving its target ROI.

Of course, one could argue that Adoption is included in Scope, and I’d be good with that once I start seeing Scope documents articulate the approach and measurements for Adoption. Until then, I’m a fan of the Four Horsemen of the Success-aclypse: Scope, Schedule, Budget, and Adoption.

Reprinted with permission from Slalom Consulting – © 2013 Slalom Consulting

Roger Kastner is a Business Architect with Slalom Consulting who is passionate about raising the caliber of project leadership within organizations to maximize the value of projects. You can read more articles from the series on “Why Projects Succeed” here.