Art or Science? The Exciting Conclusion...

It turns out, Readers, that you are a quiet and moderate group.  The dominant refrain from reader response and conversations I've had with clients and colleagues is that Change Management must be a combination of art and science in order to be truly effective.

This is great progress from a few years back when many of the people at the firm I worked for had a tendency to interpret CMS - Change Management Strategy - as Chicks Making Slides.

I agree that Change Management requires a combination of the science of methodology and planning with the art of people management and flexibility.  Today, though, I'll focus on the science side.  Specifically, I'd like to call your attention to an area I feel has been greatly lacking in Change Management - the science of Return on Investment (ROI).

Heads up, all you Change Management grad students (does such a thing exist?), because I'm about to depart from my practical advice to lay out my Change Management ROI thesis proposal.

A (Theoretical) Approach to Measuring CM ROI 

Perhaps one of the most difficult questions I receive from clients is, "How can you prove the value add of Change Management?"  I can provide a large number of anecdotes.  I can point to surveys such as IBM's Making Change Work study.  I can list dozens of articles and books that discuss the value of Change Management.

What I cannot do is authoritatively say that if you invest X dollars in Change Management, you will receive X value in return.

What we are sorely missing is a comprehensive, quantitative study of the value Change Management brings to a project or organization.

The Subject

I propose a study that is undertaken using a large organization such as IBM, Accenture, or Johnson & Johnson as the subject.  IBM and Accenture have the benefit of having an extensive and diverse portfolio of projects that include Change Management.  A non-consulting firm such as Johnson & Johnson has the benefit not needing to get permission from other organizations to use their data.

Even better - study more than one organization.  This would help control for differences in methodology and execution.

The Data

The chosen organization would need to gather a few major pieces of data for each project they implemented:

• What was the total cost of the project?
• What was the total spend on Change Management activities, broken down by Change Management, Communications, Training, etc.?
• What were the project's objectives for itself (e.g., schedule, budget, team morale, etc.)?
• How well did the project meet these objectives throughout the project lifecycle?
• What were the project's business goals and/or Key Performance Indicators (KPIs) (e.g., save X amount of money, reduce process time by X minutes, increase customer satisfaction by X %)? 
• How well did the project meet these goals and or KPIs at go-live, one month post-Go-live, one year post-Go-live, etc.?

As a control group, they should gather the same data for projects where they did not have any Change Management, as well as for projects that only had training.

This data should allow them to compare how well a project with Change Management met its internal and business objectives versus projects that did not utilize Change Management.  It would also allow them to do a cost/benefit analysis of the money spent on Change Management as a percent of overall budget versus the level to which they achieved their objectives.

I would recommend projects where objectives are very concrete, making them easy to set and measure.  It's much easier to determine how much a procurement system implementation will save you by reducing maverick spend than it is to determine how much happier your employees are after implementing a culture change.

The Roadblocks

There are a number of hurdles a researcher would have to overcome to implement this type of study.  First, my experience tells me that many projects don't set clear business objectives or KPIs.  I've been on a number of projects where there was no defined business case for the system implementation.

Second, on projects where business objectives are clearly set, I believe it's relatively rare for consulting firms to go back to the client on a regular basis post-Go-live to determine how well those objectives have been met.

Third, there are a large number of variables.  Would different consulting companies have different results based on their methodology?  How much of an impact does the experience of the Change Manager have?  How exactly would we define Change Management for the study?  And the list goes on.

The are other challenges, but the final one I would point out (and this is completely personal opinion) is that I think many Change Managers have a nagging fear in the back of their minds that a study like this might not conclusively demonstrate a positive ROI. 

We shouldn't let that stop us, though.  I believe we would find a correlation between including Change Management on a project and the project's ability to help an organization meet its KPIs.  And if we don't, that at least would point out to us areas where we can improve our methodology and practice.

Do you think this type of study would work?  Have you seen any good, quantitative research on the value of Change Management?

Change Management: Art or Science?

Today I have a question for you, Readers.  It is one of the ongoing debates among Change Management practitioners: Is Change Management an Art or Science?

Please leave your comments in the comments section below this post, or feel free to e-mail me directly at emilycarrconsulting@gmail.com. 

I'll post my position on the question next week.  I look forward to the debate!

The Danger of Smiling Faces: Fostering Two-Way Communication

There is an on-going debate over how to measure success in Change Management.  Whether your focus is on user adoption, communications, or training, there is a constant stream of "new and improved" methods for determining if your Change program is a success.

Regardless of the formal method used, I've found that the overwhelming majority of people have one fundamental measure for Change Management success: The more people who are happy, the more successful the Change program.  Sometimes we see this explicitly, as with the "Smile Sheets" that so many trainers distribute after each training course.  These surveys ask people whether they liked the course, whether they thought the trainer was good at his job, and whether they thought they learned something.  What the surveys don't do is tell the trainer whether or not he was actually successful in training the end users on a new skill.  I'm not saying these surveys are bad - I use them myself.  They are not, however, a reliable measure of training success.

While Smile Sheets very explicitly show the correlation most people see between happy end users and successful Change Management, the gut-level belief that most people have in this correlation is more often implied.  How often have you heard (or said) these lines?

• I just got out of a meeting where everyone was really negative about the project.  We'd better change our Change Management approach.
• I was talking to some people in the lunch room and they weren't happy about the change.  Why isn't the Change program working?
• I'm getting a ton of calls from people who want don't like the decisions we're making.  You'd better figure out how to make them realize this project is great.

All of these statements imply that because stakeholders are unhappy with the changes you're implementing, the Change Management program is failing and in immediate need of re-work.  Assuming that these statements are coming during the life of the project, however, and not at Go-live or later, I would argue that statements of unhappiness, requests to discuss project decisions, and expressions of annoyance are a sign of success.

What they demonstrate is that people are engaged.  The first stop on the Change Curve is Awareness, and it's not possible to be unhappy with a change unless people are first aware of the change.  Unhappy stakeholders?  Congratulations!  You've successfully reached Awareness. 

The second stop on the Change Curve is Understanding.  People yelling that they don't like how the changes you're making will impact them?  Congratulations!  Your stakeholders understand the change, and you've successfully reached the second step to achieving change.

When I get half-way through a project and all I see are happy, smiling faces, I get worried.  100% happiness tells me that I'm failing miserably at Change Management because one of three things is happening:

1. People don't know a change is coming, which means my communications aren't reaching their intended audience.
2. People don't realize how they will be impacted by the change, which means they don't understand the communications I'm sending.
3. People are pretending to be happy, which means I haven't fostered good two-way communications.

For today, let's focus on the third option and look at:

Practical Tips for Building Two-Way Communications

1. Make it Easy - People are busy.  If you make it difficult to communicate with you or the project team, noone will bother.  If you have an e-mail address, make it easy to remember.  If you want people to respond via a web site, remember to include the link so that all they have to do is click.  The easier it is for people to tell you what's on their minds, the more likely they are to communicate.
2. Make it Confidential - How often have you sat in a meeting where noone offers an opinion, but as soon as you leave everyone hurries to someone else's office where they suddenly have lots to say?  Many people are more comfortable sharing their thoughts in a one-on-one setting than they are in a group.  Even more people are likely to communicate if they know that what they tell you will be anonymous when it's shared with others.  This not only requires that you provide people a safe, confidential forum for communicating, it also requires that they trust you to maintain the confidentiality.  Change Management often falls in the HR department for a reason.  Even if it doesn't, you should practice the same level of discretion as an HR professional.
3. Make it Matter - If you want people to communicate with you on an on-going basis, you have to demonstrate that what they tell you matters.  This means that you pay attention to what they say, take appropriate action based on the conversation, then follow-up to let them know the outcome.  Did they ask you a question?  Make sure you get back to them with the answer.  Did they make a suggestion?  Even if you can't guarantee that their suggestion will be implemented, let them know that it will be considered and tell them when they can expect to hear more.  Did they just want to vent?  Remember that even if you don't agree, everyone is entitled to have an opinion.  One of my major rules of communications: Never ask people for input if you have no intention of seriously considering it and taking appropriate action.

Do you think happy stakeholders is a good way to measure Change Management success?  What other tips do you have for building two-way communication? 

If I Could Have One Wish: Better Documentation

When the first star comes out each evening and I think about what I'd like to wish for, I close my eyes, concentrate really hard, and wish for better documentation on projects.  Unfortunately, many projects don't take the time to develop thorough, consistent documents.  Even worse, some projects don't produce any documentation at all. 

Why do I care?  Change Management is often seen as a separate team working in a little silo of happiness.  At first glance, functional and technical teams can't fathom why a Change Manager would get so upset when she hears that they've decided not to create test scripts or document major project decisions.  Because Change Management is a perpetual "down stream" team, though, almost every action that the project team takes impacts Change Management activities.

Consider these examples:

• Test scripts are often the foundation for training development.  With poor or non-existent scripts, the training developers are forced to re-create the wheel by either researching customizations to the system, trudging through a series of trial-and-error, or peppering the functional teams with endless questions.  All of these methods require extra time that could have been avoided with detailed scripts from which to work.
• Major decisions can occur on a daily basis on projects.  The Change Management team is expected to communicate this information both internally to the team and externally to end users.  If decisions are not documented, the communications person is often left to rely on second-hand notes and water-cooler chatter to figure out what message to send.  This can result in messages that are both inaccurate and late.
• A favorite phrase of many functional leads is, "That's a training issue."  While it very well may be, if there's no place to document issues and risks, the Change team has no way of knowing what concerns they're expected to address.  Three months later when it's time to prepare for Go-live, there's very little chance that all of the teams will remember all of the issues they thought would be handled by Change Management.

If you've never been on a project, or if you're a client who has listened to firms pitch their methodologies, you may be wondering how a lack of documentation could possibly be an issue.  Every firm will tell you about how they have tried and true document templates that will be used throughout the project lifecycle to capture important information about the system and then left behind for the client to reference in the future.  If you've been doing project work for awhile, though, you know that the reality is often very different.  The top 5 excuses I hear for why teams don't want to create documentation:

1. We don't have time.
2. We've done this 100 times.  We don't need to document.  We have all of the information in our heads.
3. The client/end user already understands the system.  We don't need to document it for them.
4. Documentation's a waste of time.  The system/processes are just going to change anyways.
5. We're communicating all of the information verbally.

While I'm tempted to jump in and talk about why none of those excuses are valid, instead I give you:

A Practical List of 5 Documents that Should NEVER Be Skipped

• A Project Work Plan - A project work plan is the backbone of your project.  It ensures that everyone is working toward the same dates, and provides an early warning system if tasks and time lines start to slip.  Without a strong project work plan, teams and individuals cannot properly plan their work and activities.  Many projects don't include Change Management activities in the work plan.  This isn't ideal, but I can live with it.  If a work plan is missing entirely, though, I recommend you pull the emergency cord and halt the project until you can figure out how to put a plan in place.  Whatever the cost of stopping for a week, it will be less than the cost of working for months without a plan, only to discover you're off track.
• Test Scripts - I addressed this above from a Change Management perspective.  Even without considering training development, though, test scripts are still important.  The client should be involved in testing the system, and it is nearly impossible for them to do this without solid test scripts.  Further, you need detailed test scripts to verify that you have built and tested all of the requirements you gathered.  Finally, if you're implementing a system that needs to be SOX compliant, you'll want to have test scripts in place when the auditors come to call.
• Issue/Risk Log - I'll keep it short.  Issues and risks that don't get documented typically don't get resolved.  The choice is yours.
• Decision Log - If you have never sat through a meeting where someone said, "Who made that decision?  I never agreed to that!", and then proceeded to spend the rest of the meeting talking about a decision that was finalized months ago, you're very lucky.  Aside from the benefits a decision log has for the Change team, which are mentioned above, the log assures that everyone has the opportunity to read decisions as they are made.  If they don't agree, they can speak up before work based on that decision proceeds, saving time and money by reducing potential re-work.  They didn't read the log and months later decide they don't like the decision?  Too bad.  The decision log is also extremely helpful when months later people's memories have become fuzzy and disagreement arises about what exactly the decision was. 
• Training Materials - Despite what college students everywhere like to believe, it really isn't possible to learn through osmosis.  If you want end users to understand and use the system you just spent countless hours and money implementing, you need to train them.  You've come this far.  Don't skimp now.

Is your project documenting?  If so, what benefits have you seen?  If not, why not?

Emily's Favorite...Training Development Tool: User Productivity Kit

Over the years, I have developed some favorites in the world of Change Management.  I'll occasionally highlight one of them in this blog.

Today, I'll share my favorite training development tool: Oracle's User Productivity Kit (UPK).

About seven years ago, I was on an SAP implementation.  The client was using a training development tool created especially for SAP, but decided to invite a company called Global Knowledge to demonstrate their training development software, OnDemand.  By the end of the demonstration, everyone in the room was drooling over the functionality this software provided, and the potential it had to improve training development.

After I left that project, I went to other clients where we used a number of the standard training development tools: Camtasia, Captivate, and SnagIt, to name a few.  Although they all have their uses, I still longed to get my hands on that OnDemand software.

So imagine my joy when three years ago I joined an Oracle implementation and discovered that Oracle had purchased Global Knowledge Software LLC and was now using the OnDemand software as their standard training development tool.  They had re-branded it, "User Productivity Kit" (UPK), but it was still the software I had dreamed about all those years.

I dove right in and learned everything I could about UPK, then proceeded to develop and teach courses on it, so that others could enjoy using it, too.  Before I embarrass myself with extreme amounts of gushing, though, let's look at:

5 Practical Benefits of UPK

1. More than a Training Tool - You'll notice that User Productivity Kit does not have the word "training" anywhere in the title.  That's because this is more than just a training development tool.  It is actually designed to be used throughout the project lifecycle.  Teams that are truly dedicated to getting the most out of UPK can begin using it early in the project to create process documentation and test scripts.  Not only does this help enforce consistency in documentation throughout the project, it also directly feeds in to training development efforts, reducing the amount of time required for the training development lifecycle.
2. One Input, Many Outputs - Training developers often dedicate a lot of time to reformatting the same information into different training tools.  For a single process, they may need to create a training manual, job aid, demonstration, and hands-on activity.  With UPK, you record the process once, then in one step publish the information in all of these formats, plus more.  It is a huge time saver.
3. Collaboration - UPK comes in two different versions.  The stand alone version sits on your computer, and no one can access the information other than the person working on that computer.  It also comes in a version that sits on a server, however, and this is a huge win for any project with multiple developers and/or a proper review process.  By putting UPK on a server, anyone with access can view and edit any of the training.  This removes the need to print or e-mail copies for review.  UPK also lets you assign people to each training topic and change the status of topics, which allows the project to see who is currently responsible for the topic and how close it is to being complete.  Anyone who has ever undertaken the complex task of running training development and review understands the benefit of having this level of collaboration.
4. Integration - If you use UPK with an Oracle product, it has an outstanding level of integration.  As you record your actions, it not only captures the steps you're taking, but it also fills in information.  Click on a button, and it will A) enter the name of the button directly into the training, so that the developer doesn't have to type it in later, and B) automatically insert any alternate ways of completing the action.  For example, if I use UPK to record pasting data into a field using the Paste button, UPK will not only enter the phrase, "Click the Paste button.", it will also have an alternative action that states, "Type CTRL-V."  UPK is also able to do this for some non-Oracle products.  They don't advertise it, but UPK works pretty well with other applications, such as the Microsoft suite of products.  The integration isn't as good as it is with Oracle products, but if you already own UPK, it doesn't become obsolete when your Oracle project is complete.
5. Ease of Use - I taught myself how to use UPK.  If you're not always on speaking terms with your computer, you may want to invest in a training course.  At the end of the day, though, UPK is an easy tool to use.

Have you used UPK?  What are the pros and cons of working with it?

My Number One Red Flag: Executive Sponsorship

Although everyone enjoys being on a great project team, there are benefits to being on more challenging projects.  They give you opportunities to build your interpersonal skills, practice the arts of negotiation and diplomacy, and force you to become more creative in finding solutions to both standard and unique issues.  One of the major benefits of being on multiple challenging projects, though, is that you become adept at quickly identifying project "red flags."

These red flags warn you that this is not going to be a smooth project.  If I see one red flag, I prepare to dig a little deeper into my bag of Change Management tricks.  If I see two, I start thinking about the overtime hours the project will require.  If I see three red flags, I mentally add months to the timeline and millions to the budget.

Red flags can take a number of forms across many areas of the project.  My top five red flags:

• A lack of structured Project Management
• Client team members who are expected to complete 100% of their day job on top of their project responsibilities
• ERP (or any complex system) implementations that are scheduled to take less than a year
• Disgruntled end users who talk about the project failing before it has even begun

And my number one red flag: A lack of Executive Sponsorship.

It's easy to think in these days of grass-roots movements that strong, centralized leadership is a thing of the past.  If change is being brought about on the global stage without the political equivalent of Executive Sponsorship, why is it so necessary for a project?  Ask yourself, though, "Have you ever seen a popular groundswell of employees demanding a new ERP system?"  Me neither.

I would argue that without Executive Sponsorship, a project team has no chance of implementing a quality product on-time and on-budget.  The problem is that Executive Sponsors often aren't sure what they can do to support the success of the project, and the project team often can't articulate what they need from their Sponsors. 

A Practical Look at the Role of Executive Sponsors

1. Create the Vision:  Projects have a lot of moving parts, and as the pace of the project speeds up, it's easy for each part to start moving in its own direction.  That's why it's crucial for the Sponsor to clearly articulate early and often: A) Why are we doing the project, B) What does the end state look like, and C) How do we define success?  If everyone has the same answers to these three questions, it will help them resolve inter-team conflicts, enable them to prioritize project activities, and ensure that everyone is working toward the same objective.  If the Sponsor doesn't create a shared vision, each person will create his own.
2. Be a Vocal, Visible Champion:  It's not enough for an Executive to agree to be a Sponsor, then sit in her office and send the occasional e-mail.  Sponsors need to be out in front of the organization on a regular basis reinforcing the project vision.  Remind other Executives why it's crucial to dedicate money and people to completing the project.  Explain to employees the benefits they'll realize by adopting the change.  Encourage the project team and show them that you appreciate their hard work.  Executive Sponsors need to be seen as the number one supporter of the project.  And they need to be seen often.
3. Remove Roadblocks: Projects are difficult.  No matter how well planned the work and how dedicated the team members, they will hit roadblocks.  It's the Sponsor's job to remove the roadblocks that the team can't remove for themselves.  This can include freeing up time from an essential Subject Matter Expert, working to resolve issues with a vendor that's not delivering on schedule, or helping to ensure the project team has the resources it needs.  By removing roadblocks, the Sponsor allows the project team to stay focused on their day-to-day project activities.
4. Empower Decision Making: One theory says that decisions should be made by the person or team at the lowest possible level that has the ability to make it.  This means that if a team member has the knowledge and ability to make a decision, he should make it, rather than requiring every decision to be escalated to the team lead, Project Manager, Executive Sponsor, and Steering Committee.  By empowering every person to make the decisions appropriate to their level, you free up people at higher levels to make more strategic decisions.  Does it really make sense for the Project Manager to spend her time deciding what color a web page should be, when what she really needs to focus on is creating an integrated project plan?  In addition, requiring too many decisions to be escalated for resolution creates a backlog that slows down the project.  If every decision has to go to the Executive Sponsor, they will quickly take over his day.  Not only will he not be able to make the decisions quickly enough, but focusing on these decisions will distract him from his real job - supporting the project's success.

Executive Sponsorship is a key success factor for any project.  Have you been on a project where the Executive Sponsor (or lack thereof) directly impacted the success or failure of the implementation?

Right Investment, Right Impact: Creating a Change Management Budget

Reminder: The statistics used in this post come from IBM's 2008 Global Making Change Work study.

The fourth and final finding in IBM's Making Change Work study is called, "Right Investment, Right Impact."  The study found that

Project success rates were 23% higher when the amount invested in change was greater than 11% of the project budget....Organizations that invested less than 11 percent in change had a 35% success rate; those that invested more than 11 percent had a 43% success rate.

Not only does investing this money in change increase your chance of success over competitors that don't invest the money, it also increases your chance of success above the average 41% of projects that succeed in general.

Let's convert this into dollars.  Based on these statistics, a project with a $1M budget must invest a minimum of $120,000 in Change Management (I'm using a 12% investment, since that's just more than 11%).  I've been on projects with much larger budgets that have invested much less in Change Management. 

Why is there such a lack of budget for Change Management?  I think the number one reason is that people don't understand what Change Management is and the value they'll receive on their investment.  I believe that the second most common reason, though, is that many projects don't know how to create a Change Management budget.  They can't figure out what the money would be spent on, so they see no reason to set any money aside.

Although it will vary a bit by project, I've listed the top 5 Change Management line items that require budget.

Budgeting for Change

1. Outside Help: Most companies are not equipped to handle the full range of Change Management activities internally.  We don't expect the finance guy to possess the skills required to do his own coding, so why do we expect he should be able to do his own Change Management?  Although many companies have the best intentions about having members of their project team deal with Change Management, it's a good idea to budget for outside consultants or contractors.  If you're still not convinced, I refer you back to my earlier post on the need for a professional Change Manager to increase your project's chance of success.
2. Training: Training is one of the most expensive activities covered by Change Management.  A one-hour computer-based training course with all the bells and whistles created by an external company can easily cost you anywhere from $15,000 - $45,000.  Even if you go with a more basic approach, good training development and delivery is still extremely costly.  In addition, most companies end up needing to hire contractors to help with the training development.  This cost can quickly add up.
3. Rewards and Recognition: In today's tight economy, with many companies operating with a skeleton crew, employees are being asked to take on more and more responsibility without necessarily receiving an increase in compensation.  Asking (or telling) your employees that they now need to work on a project in addition to completing their day-to-day jobs can result in revolt.  Setting aside a budget to do some simple Rewards and Recognition throughout the project, whether it's holding team dinners or providing small denomination "Thank You" gift cards, can help your employees feel appreciated and motivated.
4. Field Communications: This item won't apply to everyone, but if you have a large set of employees in the field (e.g., Sales People), it's a good idea to set aside budget for communicating with them.  Many companies prefer to meet with these groups in person, which can run up a hefty tab.  Even if all of the communications will be done through remote means, holding webinars and developing quality electronic communications carry a price tag.  I've also found that many companies feel the need to have "fancier" communications and events for their field departments.  If this is true at your organization, make sure to plan accordingly.
5. Sustainability: Many project plans end at Go-live.  A few continue for 2-4 weeks post Go-live.  Very few recognize that just because a change has been implemented, doesn't mean it has been adopted.  To really ensure that a change becomes embedded in your organization,  you need to consider the need for on-going Change Management activities.  What will you do about training new employees or those who were on leave during the project?  How will you communicate and train employees about on-going changes to a system?  What do you do if a month after go-live, you discover people aren't using the new tools and processes?  And who will be responsible for implementing any new Change activities that are required to deal with these issues?

And thus ends my analysis of IBM's Making Change Work study.  If you're not yet convinced that Change Management is a necessary part of any project, please leave a comment explaining why.  If you're a believer, what do you find to be the most compelling argument in favor of Change Management?