Change Management Checklists: Organization Design

Back when I was part of the Human Performance team at Accenture, getting an Org. Design role was the holy grail of Change Management projects.  This was largely because they were rare.  And they were rare because many companies simply don't want to tackle this messy topic while going through an already difficult change.  I would argue, however, that Org. Design is part of ensuring that the change sticks.

Instead of detailing here a checklist of top 10 Org. Design activities, for the last Pillar of Change I'm going to list instead 10 questions you should ask yourself about Org. Design when your company is undergoing a change.

Top Ten Organization Design Questions

• Do I have the right number of people to perform the work after the change is implemented?
• Do my people have the right skills to work in the new world?
• If not, can I upskill them?
• If they can't be upskilled, can I move them into a different role in the organization, or do they need to be moved out of the organization?
• Do the current job descriptions need to be revised based on new job and role responsibilities?
• Do we need to do a remuneration review to ensure compensation is still appropriate for new responsibilities?
• Does the overall organization structure still make sense?
• Do the new and/or existing teams need to change the way they interact?
• Does the reporting structure support the change?
• Have you reviewed the positions you are currently hiring for to ensure they are still required/appropriate in the new world?

Let me know: Does your organization address Org. Design as part of Change Management?

Change Management Checklists: Training

Training is a huge topic.  It encompasses training analysis, training development, training delivery, training evaluation, and infinite variations on those topics.  Narrowing this down to 10 major activities is difficult, but I think I'm up to the challenge.

Training Activities

• Collaborate with the corporate Learning & Development department (if your organization has one)
• If you think something is self explanatory and doesn't require training, think again.  Never assume that people will be able to "figure it out."
• Conduct a training needs analysis
• Remember that training comes in many shapes and forms.  The best approach to training is often blended learning.  Learn it, love it, use it.
• Create a training curriculum
• Training development takes a lot of time.  A LOT.  In the words of scuba divers everywhere, "Plan the dive.  Dive the plan."
• Develop the training
• Deliver the training
• Create a sustainable training plan that will allow you to deliver training on an ongoing basis to people who may have missed the initial training (e.g., people on vacation or maternity leave, new hires) or who need an occasional reminder
• Evaluate the training...and improve it, as appropriate

Let me know: What are the main activities you consider when planning a training program?

Change Management Checklists: Communication

You could write an entire blog dedicated to communication (in fact, I believe there may be one or two out there).  I'm going to try to condense all of that information into my top 10 communication activities. Read on...

Communication Activities

• Collaborate with the Corporate Communications department (if your organization has one)
• Conduct a vehicle analysis
• Conduct an audience analysis
• Determine the review process for various types of communications and vehicles
• Create a detailed communication plan
• Write communications - keep them short, simple, and relevant
• Spell check, grammar check, and have someone else do a second review
• Develop and monitor feedback channels - remember...communication is a two-way activity!
• Update your communication plan based on feedback you receive
• When you think you've communicated enough, communicate more

Let me know: What is the most effective communication you have ever received at work?

Change Management Checklists: Stakeholder Management

I'll get right to it.

Stakeholder Management Activities

• Conduct a Stakeholder Analysis
• Develop a checklist of behaviors stakeholders should demonstrate by the end of each project phase
• Identify how far along the change curve you want each stakeholder group to be at specific points throughout the project
• Create a Stakeholder Management plan
• Conduct a Change Impact Assessment
• Create a plan to involve stakeholders in the project
• Remember that project team members are stakeholders, too
• Prepare to help stakeholders through the inevitable performance dip that accompanies a change
• Work with Human Resources and your organization's leadership to identify ways to motivate your stakeholders to adopt the change
• Celebrate every time a stakeholder group successfully adopts the change

Let me know: Do you agree with this list?  What else would you add?

Change Management Checklists: Sponsorship

My apologies, Readers.  I have slacked the last two months with updating this blog.  Keep your reading glasses handy, though, because I plan to become much more prolific.

In my last post, I listed what I consider the Five Pillars of Change.  Here, I'll provide a list of activities to keep in mind as you create the Sponsorship portion of your Change Management program.

Note that not every Change program needs to include every item on the list.  Based on the size of your organization, the complexity of the change, and your company's culture, you can pick and choose the activities that will provide the greatest value in helping people adopt the change.

Although it is important to have a comprehensive Change program, and skimping on necessary activities can adversely impact the adoption of the change, including too many activities just for the sake of checking them off a list can be harmful, too.  Carrying out activities that don't add value:

1. Causes people to question the value of all Change Management activities - even those that are essential for success
2. Overwhelms your stakeholders and can lead to burn out
3. Pulls resources - both time and money - from activities that deserve the most focus

With that said, I hereby present a list of Sponsorship activities for your consideration.  This list is not 100% comprehensive, but it will give you a good start in developing a Sponsorship plan.

Sponsorship Activities

• Identify project Sponsors
• Establish project Governance
• Build a Steering Committee
• Develop a Change Agent plan
• Create a Change Agent/Super User Network
• Involve all sponsorship groups in relevant areas of the project early and often...gather and incorporate their feedback, as appropriate
• Develop consistent communications to keep Sponsors and Change Agents informed
• Provide early training for members of all sponsorship groups
• Say, "Thank you" - often and with sincerity
• Be available to help and support all sponsorship groups as they carry out their sponsorship activities

Let Me Know:  Do you agree with this list?  Is there anything else you would add?

The Five Pillars of Change

While I thoroughly enjoyed writing the last few posts as part of the Virtual Book Club, I'm now feeling the need to get super practical.  So, my next set of posts will focus on the actual activities that make up a Change Management program.  I won't be able to include every activity (it's a very long list), but I will provide a fairly comprehensive set of check lists that will get you started in creating your Change Management plan.

I'll be breaking the check lists down based on what I call the "Pillars of Change."  They are:

• Sponsorship (about which I have very strong feelings)
• Stakeholder Management
• Communication
• Training
• Organization Design

As far as I'm concerned, all Change Management activities fall into one of these five pillars.  When you create your plan, you pick and choose a set of activities from each pillar based on the needs of your project and organization.  You then create a timeline based on when each activity is due (based on the larger  project plan) and how long it will take to complete, and voila!  You have the beginning of a Change Management plan.

Coming up first: Sponsorship activities

Let Me Know: Do you think these five pillars cover all Change Management activities?

And Then a Miracle Happened

Welcome to the last installment of Practical Change Management's Virtual Book Club (VBC).  The discussion question I posed in my last post was:

The Question
On page 36, Chip and Dan discuss solution-focused therapy and begin to talk about the Miracle Question: "Suppose that you go to bed tonight and sleep well.  Sometime, in the middle of the night, while you are sleeping, a miracle happens and all the troubles that brought you here are resolved.  When you wake up in the morning, what's the first small sign you'd see that would make you think, 'Well, something must have happened - the problem is gone!'?"  How can the Miracle Question be used to improve overall projects and Change Management programs?

My Answer
Have you ever seen a presentation where someone describes the problem in great detail, lays out all of the wonderful benefits you'll see when they solve the problem, then in the middle where the actual solution should be they just have a big cloud with the words, "And then a miracle happened?"

I certainly have, and I find that people typically aren't very impressed with this image.  I think, though, that this slide relates back to the Miracle Question posed in solution-focused therapy, and I believe there is a legitimate place for it in projects.

I have seen so many projects grind to a halt because of "Analysis Paralysis."  The team faces a complex, overwhelming problem.  They want to make sure they develop a comprehensive, well-designed solution that will completely resolve the problem in a way that makes everyone happy.  To do this, they start doing research.  They begin to design the solution, but they aren't sure it's the best solution.  So, they do more research.  They tweak their design.  They're still not sure it's perfect.  So, they do more research.  They make some more updates.  They still have some doubts about the solution.  So, they do more research...

The cycle can continue indefinitely.  Eventually, they just give up, and instead of at least having a good solution, they're just left with the original problem.

This is where miracles come into play.

By posing the Miracle Question, "What's the first small sign you'd see that would make you think...'The  problem is gone!'?", the team can move from trying to solve a complex problem in one fell blow to focusing on the most visible, important part of the solution that they want to achieve.  All they have to do is create a solution that will bring about that "first small sign."

Focusing on this one piece of the solution will:

• Narrow the scope of the problem they're addressing
• Reduce the feeling of being overwhelmed, increasing their confidence in their ability to successfully tackle the problem
• Focus their research and development efforts
• Break the Analysis Paralysis cycle

Once the team has achieved the "first small sign," they can go back and ask the Miracle Question again, deciding what the next "small sign" would be.  

They are once again in a cycle, but now, instead of being in a research cycle that leads to the ultimate demise of their project, they have entered a "doing" cycle that will lead them step-by-step to a full and successful solution.

Let Me Know: How would you use the Miracle Question to make your project successful?  Do you think it could help your team break out of the Analysis Paralysis trap?

Looking for Bright Spots: A Case Study

Welcome back to Practical Change Management's Virtual Book Club (VBC).  The discussion question I posed in my last post was:

The Question
Beginning on page 27, Chip and Dan use the story of fighting malnutrition in Vietnam to highlight the concept of bright spots, defined as "successful efforts worth emulating."  How would you use "bright spots" in a difficult situation or project to help bring about change?

My Answer

I promised you a real-life case study from one of my past projects.  To protect the innocent (and myself), I have changed all names and will not be disclosing any details that might identify the client.

The Situation
Many years ago, I was working on a software implementation at a large company.  Over the years, this company had acquired smaller companies that they now considered "business units."  Each business unit (BU) kept it's unique software, business processes, and culture.  Perhaps just as important, each BU kept its own budget, and the parent company was not in the habit of telling them how to spend their money, or forcing changes on them.

The project I was on was implementing new software across seven of the BUs.  Because each BU was so unique, we had set up Change teams at each BU made up of employees who could help us navigate the culture and implement the change.  It quickly became apparent, however, that not all of the BUs were equally committed to the change.  Their commitment ranged from full, enthusiastic support to grudging participation.  Because they had so much independence in deciding whether to participate in and provide budget to the project, we had to find a way to get and keep everyone on board.

What We Did
We appealed to their riders: One of the first things we did was an analysis of how the new system would impact each BU.  What we found was that some BUs were getting a huge benefit from the implementation, while some were breaking even and others were actually losing some functionality and autonomy.  Using this information, we created charts and graphs, did some data analysis, and basically explained that the organization as a whole would see a net gain in benefits, even if some BUs were feeling a bit of a loss.

We appealed to their elephants: In an effort to build some positive peer pressure and appeal to everyone's competitive nature, we set up a competition.  Each BU could earn points by implementing Change activities and by sharing success stories that could be scaled and used to help other BUs achieve success.

We cleared the path: We recognized that many people weren't sure how to support a change effort, so we produced a monthly toolkit that explained what needed to be done that month, provided step-by-step directions on how to do it, and included any necessary templates.

Doing It Differently with Bright Spots
While all of our efforts certainly helped drive the change, we still found ourselves faced with a BU that really resisted the implementation.  Looking back, I would have spent less time focusing on why that BU was so negative about the change (they told us on a regular basis - it wasn't a secret), and spent more time focusing on why one of the BUs was so positive and so proactive in supporting the change.  This BU was our bright spot.  I think that if we had better understood why our main change agent there was putting so much effort into driving the change, and understood how he was in turn spreading this positive attitude throughout his BU, we could have used this information to help turn around our resistor.

As it was, despite the success of our change program, I think I missed an opportunity to learn from this bright spot and gain a better understanding of why some people support change.  This understanding could have informed all of my future change programs.

Let Me Know:  In the comments section, tell me about a time that you were able to identify a bright spot and use it to improve your change program.  Or, if your story is more like mine, tell me how you would better harness the power of bright spots if you could do it again.

Next Discussion Question:  On page 36, Chip and Dan discuss solutions-focused therapy and begin to talk about the Miracle Question: "Suppose that you go to bed tonight and sleep well.  Sometime, in the middle of the night, while you are sleeping, a miracle happens and all the troubles that brought you here are resolved.  When you wake up in the morning, what's the first small sign you'd see that would make you think, 'Well, something must have happened - the problem is gone!'?"  How can the Miracle Question be used to improve overall projects and Change Management programs?

The Elephant in the Room: Making a Boring Project Emotional

Welcome to the first meeting of Practical Change Management's virtual book club (VBC).  Hopefully, a few of you had a chance to pick up the book Switch: How to Change Things When Change is Hard, by Chip and Dan Heath.

As mentioned last week, our first discussion question centers around the "Glove Story" that is told on page 12.  In this story, a company has a huge opportunity to save costs by streamlining their purchasing processes.  The man advocating for the change does all of the sensible things.  He gathers data showing how much money they can save.  He creates graphs and presentations.  He makes sure the powers that be understand the opportunity.  He puts in all of this time and effort, and the executives nod in agreement, but the change never moves forward.

Finally, as a last resort, the employee has a summer intern gather a sample of a glove used in every facility, along with the price paid for it.  He ends up with a pile of hundreds of gloves that have been bought separately by different departments.  Despite being identical gloves, the cost of the gloves ranged from less than $5 to more than $15!  When he invites the executives in for another meeting, he piles the gloves on a table, each tagged with the department that bought it and the price paid.  Suddenly, confronted with a startling visual of the money being wasted by ineffective purchasing, the executives throw themselves behind the need for process change.

The Question
This brings me to our first discussion question: How would you create an "elephant presentation," which is a presentation designed to work on people's emotions, for a relatively boring project?

I decided to look at this question for a project type that I'm very familiar with: an Oracle ERP system implementation.  Really, it just doesn't get much less sexy than that.  Having worked on this type of project for years, I can assure you that very few people get excited about big system implementations.  And outside of the IT department, there is often very little sense of urgency around the need to do the project.  So how, exactly, could I create a presentation that would get your average person fired up about a project that will be long, hard, expensive, and boring?

My Answer
I would create a video that follows the current process, focusing not just on the steps in the process, but also on the impact it has on employees along the way.  Consider, for example, the purchasing process.  Let's take a company that has a computer-based, but not ERP-style automated system.  Executives might think the current process works just fine.  The purchasing department might think the process could be a bit faster, but feel that overall it fits the company's needs.  Meanwhile, the average user is pulling his hair out.  The video would look like this:

Open with a shot of someone (we'll call him John) filling in an online form.  Once he finishes it, he e-mails it to his boss for approval.  We see John on the video the next day knocking on his boss's door.  John wasn't sure if his boss had seen the e-mail, and wanted to make sure the purchasing request got reviewed.  John's boss hadn't noticed the e-mail, but promises to look at it before the day is done.

Another day goes by, and we see John back at his boss's office checking on the purchasing request.  John's boss informs him that he wasn't sure if he had the approval authority for such a large request, so he forwarded the form to the next level of management, just in case.  The video follows John as he goes to see his boss's boss.  There he meets the administrative assistant, who informs John that her boss insists that the forms be printed out so that she can review them on paper, rather than in an e-mail.  The admin points to John's printed purchase request at the bottom of a large inbox pile.

Another day goes by.  It's now day four, and John still doesn't know if his purchase request has been approved.  We watch him go back to the administrative assistant, who informs John that her boss has left for a four-day weekend.  John asks if there's someone else who can approve his request, but unfortunately, the boss didn't leave a delegate.  The video ends with John walking back to his office in defeat, resigned to at least four more days of waiting for his request to be reviewed and approved. 

Every issue John ran into in the video could be addressed by the implementation of an ERP system.  This is something that people know going into the implementation at an intellectual level, but creating a video that shows one of their actual colleagues suffering through a common problem - a problem they have probably encountered themselves - drives at their sense of empathy and helps build a sense that this is an urgent problem that needs to be addressed.

Let Me Know: Do you think this presentation would work to build an emotional response to a "boring" intellectual problem?  What presentation did you come up with for a "boring"project?  Let me know in the comments section below.

Next Discussion Question:   Beginning on page 27, Chip and Dan use the story of fighting malnutrition in Vietnam to highlight the concept of bright spots, defined as "successful efforts worth emulating."  How would you use "bright spots" in a difficult situation or project to help bring about change?  I'll be sharing a real-life case study from one of my past projects.

Change Management Virtual Book Club Starting Next Week - Join Now!

I recently finished reading Switch: How to Change Things When Change is Hard, by Chip and Dan Heath.  As I read, I made a list of topics that hit home for me that I wanted to discuss on this blog.  The more I thought about it, though, the more I realized that I didn't just want to analyze the book and put out a one-sided article.  What I really wanted was to have a dynamic conversation with other professionals about ideas that can impact the way we approach Change Management.

With that in mind, I am kicking off Practical Change Management's first ever Virtual Book Club (VBC).  There are no fees to join, no mandatory conference calls, and if you don't keep up with the reading, I promise not to send a note home to your parents.  All you have to do is pick up a copy of the book and start reading.  Check back here regularly to find the current topic of discussion, read your peers' ideas, and add your own.  If you're not good at remembering to check back, you can click here to "officially" sign up.  Send me your e-mail address, and I'll send you a reminder each time a new post is added (And don't worry, I won't sell your e-mail address to anyone.  I wouldn't even know who to sell it to.).

In each post, I will include the discussion topic for the next post so that you have time to read that part of the book and think through how you would handle the situation I'm discussing.

I look forward to discussing this book with you!  Please feel free to invite others to join the conversation, as well.  Expertise in Change Management is not required...just a passion for reading and discussing excellent books.

Many thanks,
Emily

First Discussion Topic: Chip and Dan use the concept of the rider, elephant, and path as the core theme of their book.  On page 12, they give the "glove" example as a classic elephant appeal (Look!  You only have to read a few pages to join the first discussion.).  This made me think: How would I create an elephant presentation for a "boring" project, such as an IT system implementation?  What would your elephant presentation be for a "boring" project?

In the next post, I'll let you know what I came up with for an elephant presentation around an Oracle ERP implementation.

Building Your Trusted Advisor Reputation: A Research Proposal

In my last post, I talked about how your sales approach could be hurting your bottom line, and discussed a few ways to address this issue.  One of the recommendations I made was to mine your company's historical bid vs. actuals data to help ensure that you're not underbidding on projects.  Today, I want to look more closely at what this research would entail.

The Sample
While this research would be especially fun if you could get your hands on data across multiple firms, it's more realistic to assume this would be an intra-company study.  Start by selecting which segment(s) of your business you want to study.  You could do it by monetary size, industry, software type, etc.  For this example, let's say we're going to look at all ERP implementations.

Gathering the Data
Once you have selected the projects you want to study, you can begin to gather data.  For each project, you would gather the following data twice.  First, you would gather it based on the bid.  Second, you would gather it based on the completed project actuals.

1. Budget
1. Overall project budget
2. Budget by team
3. Budget by customization
4. Contingency
5. Initial bid vs. final negotiated bid
2. Timeline
1. Overall timeline
2. Timeline for each project phase
3. Major milestone dates
4. Adjustments to timeline based on client request
3. Resources
1. Total number of resources
2. Number of resources per team
3. Number of client vs. consultant resources
4. Proposed level of each resource

The Findings
So, what do I expect to find using this data?

1. Budget
1. Looking at the bid vs. actuals for the overall project budget, you will be able to see how accurate your bids are to what the projects actually cost.  Are you off by 5%?  20%?  50%?  This will give you an idea of how much your future bids will need to change.
1. To set the new baseline for future bids, you can look at the aggregated results of your actual data to determine what would be a more accurate bid that will save your client from potential budget overruns.
2. Comparing bid and actual amounts for budget by team and budget by customization will also help you pinpoint if there are certain areas where your sales team is really having a hard time coming up with accurate figures.  You can use this data to adjust your pricing model.
1. For example, you might find that you are always running way over budget on form customizations.  Armed with this knowledge, you can work with the developers to determine what you should really be bidding for customized forms based on their level of difficulty.
3. Are you using up all of your contingency?  How early in the project do you need to tap it?  Many clients are uneasy about the concept of contingency, but having data can help support your argument for including it in your bid.
4. Finally, looking at your initial bid vs. what you finally agreed to after negotiations will help you determine if clients are consistently haggling you down from an appropriate bid to a budget that won't cover the full cost of the project.  This data should help your sales team adjust their negotiating tactics.
2. Timeline
1. In my experience, clients always want the project done faster.  Use your overall timeline comparison to show them how long it truly takes to complete the type of project they want to implement.  This will set realistic expectations.
2. Breaking your timeline data down by phase and milestone will also help you determine if there are certain parts of the projects that are taking longer than conventional wisdom would suggest.  Your methodology might say the test phase should take a month, but if it consistently takes two months, it's best to bid based on the actual time required.
3. Resources
1. Clients often see cutting resources (and by resources, I'm talking people) as a quick way to save on costs.  You don't really need 3 people to develop training, do you?  Use the data on actual number of resource per project by team as a baseline for how many people you need to complete the project on time.
2. This data should also help you find the right resource mix.  Look at the projects that came in closest to their timeline and budget.  What allocation of client vs. consultant, junior vs. senior, on shore vs. off shore did they use?  Find the winning combination, then replicate it as appropriate.

Using the Data
So, how does all of this data actually help you during the sales pitch?  Imagine being able to walk into a client and saying, "I know our bid is 10% higher than everyone else's.  We have the data, though, that shows that our budget and timeline are accurate for this type of project.  Not only does this mean that we are most likely to come in on time and on budget, but this also means that three months from now, you won't be standing in front of the steering committee asking for more money and a schedule extension.  Instead, you'll be standing in front of them each month with a status report that shows the project on track."

This helps move your people from being just a sales team to becoming trusted advisors.  And as word spreads that your company provides accurate bids that save companies from overruns, and individuals from embarrassing meetings with Executives, more and more clients should see the benefit of a higher up-front cost versus lots of hidden surprise costs along the way.

Caveats
The one main caveat I want to include here is that if your consulting firm has a culture of ghosting hours, your actuals will be off.  The research is still worth doing, and should still improve your bid process, but don't be surprised if your bids are still lower than the reality.


Let Me Know: Do you know of any firms that have done this kind of research?  How has it improved their bidding process?

How Your Sales Approach is Hurting Your Business

Every consultant has experienced it: You walk onto a client site, and within minutes you can tell.  The project was underbid.  There aren't enough people, the timeline is too short, and you have about 2/3 of the budget you need to do the work properly.

Now, I understand that sometimes companies purposely underbid on a project just to get their foot in the door.  It's part of a strategic plan where they assume that the money they lose on the initial project will be made up for on future projects that they will surely win once the client sees what an outstanding job they can do.  As long as the consulting firm is willing to provide the necessary resources to do the job right and write off the loss, I'm fine with this approach.

Where I see a major problem is when consulting firms consistently underbid work as their main sales strategy.  They go in with a good feeling of what the client is willing to spend on a project.  Even if this budget isn't enough to cover the work the firm is proposing, the sales team will still enter a bid that fits the budget just to win the work.  The rationale I often hear is that this lets them get on the ground.  Then, once they've started the project, they'll work with the client to adjust the budget, resources, and timeline to be more realistic.

The Consequences

1. First, and foremost, this approach decimates client trust.  Many clients start large-scale projects without any idea of what they entail.  They are relying on the consultants they hire to provide them with advice and guidance.  When the very first interaction between the client and the consulting firm is based on underbidding that will lead to delays, budget overruns, and upset bosses, any future advice will be viewed with caution.  Consider, as well, the long-term trust implications.  If word begins to spread that your firm consistently underbids, you stand a good chance of losing future clients. 
2. Another consequence is the development of a major rift between your salespeople and your consultants.  Often, once the sales team has sold a project, they have nothing else to do with it.  This means that by the time your consultants are on the ground and in the throes of suffering through an underbid project, the sales team has already moved on.  These situations can quickly lead to an "us" vs. "them" mentality, which can cause a divide in your workforce.
3. The last main consequence I want to talk about is consultant burnout.  When a project is underbid, the firm has three options.  They can ask the client for more time, money, and resources.  They can eat the lost cost.  Or, they can work their consultants harder to get more work done in less time with less people.  When the firm chooses the third option, they burn out their consultants, leading to poor work quality, disgruntled employees, and high turnover.

All of these consequences of rampant underbidding can directly impact your firm's bottom line, as well as its ability to win new work, and obtain and retain top-rate consultants.

Practical Steps to Take
Even if underbidding is already a part of your selling culture, you can still take steps to change it.

1. Adjust your compensation model: A lot of salespeople I have met receive their pay when the work is sold.  What if, instead, they only received a portion of their pay at this time?  Consider a phased approach that would have a second payout when the consulting team hit the ground and verified that the budget, resources, and timeline that were sold are appropriate for the project.  It could even be possible to have a third payout partway through the project, when the consultants are achieving successful results.  This model gives the sales team some skin in the game.  I can already hear the argument, "What if the consulting team doesn't do a good job and that's why they don't meet deadlines or need more money?  Why should the sales team have to risk their pay based on whether the consultants do a good job?"  But consider that this is already what the consultants are doing.  Every time they walk onto a project, they are risking their reputations based on how well the sales team bid the work.  These two groups need to become a cohesive team.  Which leads me to my second point...
2. Involve consultants in the sales process: I'm not talking here about having them just show up at orals to give a presentation and answer some questions.  Rather, when drawing up the bid, ask the functional experts how long it will take to do blueprint based on the scope of the project.  Ask the technical people how difficult it will be to code the customizations the client is requesting.  Making the consultants an intimate part of the sales process should drastically increase the accuracy of the bid.  Leading us to...
3. Stay facts based:  Every firm should be able to look at historical data for comparable projects to use as a baseline when bidding on new projects.  If past projects of similar scope cost $5 million, but this client says they only have a $3 million budget, instead of bidding $3 million just to win the work, consider having a serious conversation with the client to ensure they understand what they're getting into and the risks they're facing by not setting aside enough budget.  If they really want to do the work right, they should thank you for the honest discussion.  Which brings me to my final recommendation...
4. Become a trusted advisor: I was always taught that the main goal of anyone in the consulting industry is to become a trusted advisor to the client.  By taking the opportunity during the sales process to have the hard conversations with the client; by choosing long-term success over short-term payouts; and by becoming known as a best-in-class team that delivers spot-on bids that reduce schedule and budget overruns, your team has the ability to change from being a sales team to being trusted advisors.  And when they're the first impression a client has of your firm, isn't that goal even more important?

Research Proposal
In my third recommendation, I suggest that firms stay facts based in the sales process.  This has led me to thinking about the type of research that could really help the sales team provide accurate bids every time.  In my next post, I'll lay out a research proposal that can mine data you already have to increase your future success at both sales and becoming a trusted advisor.

Let Me Know: How does your company handle the sales process?  How does the approach impact the every day project work?

Keep it Simple: The Art of Making Difficult Concepts Easy to Understand

Recently, I heard of a web-based tool called The Up-Goer Five Text Editor.  It is designed to help you turn difficult concepts into easy-to-understand language.  Basically, you type a sentence into the editor, and the tool compares each word to its list of the one thousand most used words in the English language.  Any word that is not on the list is underlined in red.  It's then up to you to find a substitute word.

It sounds easy.

It is very, very hard.

I decided to try it out on Change Management.  I started by using the definition of Change Management, as defined by ProSci on their website.  It reads:

Change management is the application of a structured process and tools to enable individuals or groups to transition from a current state to a future state, such that a desired outcome is achieved.

There are 33 words in that definition.  Thirteen of them did not make the cut.  That meant I had to find a way to change 42% of the words in order to meet the tool's criteria, without substantially changing the definition.  This was going to be especially difficult given that the word "management" isn't on the list.

The definition I came up with is below.  Before you read it, though, I challenge you to go to the site and try to come up with your own version of the definition.

My Definition
Try as I might, I just couldn't get rid of the word "tools."  That said, here is the revised definition I created:

The business of the Change team is to use a carefully considered set of steps and tools to help people or groups to change from the present state to a new state, such that a wanted end state is realized.

Let me know:  Did you use the tool to create your own version of the definition?  Share it by posting it in the comments section.

My attempt at using The Up-Goer Five Text Editor to simplify the definition of Change Management.

Who Moved My Cheese: A Practical Application for Change Managers

As I read through Dr. Spencer Johnson's book, Who Moved My Cheese?, I understood why people either seem to love it or hate it.  Depending on your reasons for picking up this book, it can hold all of the answers you're looking for, or it can seem as if it doesn't address any of your questions.

Today I want to look at how we can take some of the concepts in Who Moved My Cheese? and apply them in a practical manner to the development and execution of a Change Management program in a corporate setting.

Below are five key lessons we can take away from the book, as well as a response to the one major question Dr. Johnson left unanswered.

Know your Stakeholders
Who Moved My Cheese? focuses on four main characters.  There are two mice, Sniff and Scurry.  "Sniff would smell out the general direction of the cheese...and Scurry would race ahead." (p. 27)  There were also two littlepeople.  Haw eventually learns to move with the cheese, while Hem remains locked in the old way of doing things, waiting fruitlessly for his cheese to be returned to him.

While these four characters in no way illustrate the full range of "change personalities" you will meet during a corporate change, they do highlight the fact that in order to build a successful Change Management program, you have to know and understand your stakeholders.

The methods that will help a "Haw" adopt a change are very different from the methods that will help a "Hem" make the adjustment.  If you walk blindly onto a project and put together a Change program based solely on a standard methodology or research, without first analyzing the personalities of your stakeholders, you are likely to find that your Change Management activities only meet the needs of a small portion of your audience.  If this happens, many people will never move on to the "New Cheese" that awaits them at the end of the project.

Burn the Platform
Although the impending loss of cheese was described as a gradual change in the book, only two of the characters realized it was coming, and none of them made a change until they considered it absolutely necessary.  This is why, in Change Management books and methodologies, you'll often hear the term "Burning Platform."

The burning platform provides the reason why the change is necessary.  As Who Moved My Cheese? illustrates, it's important to burn the platform early and mercilessly.  Most people will not change unless the need to change is compelling and imminent.  Consider these two examples that could be used for the same IT system implementation:

1. We need to change our sales systems because IT says the new system is better.
2. We need to change our sales systems because our current system is out-of-date, and will no longer be supported as of next month.  Using an unsupported system will slow our ability to find and attain new customers, allowing our competitors to take away business and overshadow our best-in-class products.

Which statement is more likely to make people run after that New Cheese?  As long as there is an old platform left to stand on, there will be some people who just refuse to move.

Paint a Picture
One of the main points highlighted in the book is, "Imagining myself enjoying New Cheese even before I find it, leads me to it." (p. 58)  This is an excellent strategy for individuals trying to make a change.

Your job as a Change Manager is to paint the picture that individuals imagine.  Help them picture what the New Cheese looks like, whether that means providing demonstrations of the new system, holding role-playing sessions of new business processes, or simply sending communications describing the end state of the change.

If you don't paint the picture for them, people will create their own picture.  If they create their own picture, you can't be sure that what they're imagining matches the reality of the change that is coming.  This can lead to:

1. People imagining a New Cheese that is so wonderful, the real thing will disappoint them.
2. People imagining the New Cheese will taste awful, causing them to fight the change.
3. People having no imagination at all and ignoring the need for change.

Once you've painted the picture, make sure that anyone else who talks about the change is describing the same picture.  And don't be afraid to add details to the picture as they become available.

Provide Quick Wins
As Haw navigates the maze looking for his New Cheese, he finds himself getting weak.  He hasn't had any cheese since he left the Cheeseless Station, and as his hunger grows, his commitment to finding New Cheese diminishes.  Luckily, as Haw is reaching the end of his resolve, "He found little bits of Cheese here and there and began to regain his strength and confidence." (p. 67)  This leads him to make the statement, "When you see that you can find and enjoy New Cheese, you change course." (p. 66)

This revelation is the concept behind building "quick wins" into your project.  The theory is that as people trudge along on the path to change, a path that can take months or years to complete, they will get overwhelmed and discouraged.  This can cause them to eventually walk slower, stop walking, or even turn around and go back.  To help keep people motivated, you need to break the path into smaller increments and celebrate each time you successfully navigate a portion.  This helps people see that they can be successful and encourages them to tackle the next part of the change in a positive manner.

These quick wins should be:

1. Close together: Don't expect people to go a year between success and encouragement.
2. Manageable: If people fail at the small pieces of the change, they will be convinced the larger change will fail, as well.
3. Real achievements: Don't create a win just for the sake of having a win.  It must be a real and meaningful accomplishment.
4. Celebrated: Allow people to celebrate their achievement in making a small change, so that they have positive reinforcement for making the larger change.

Reward the Right Behavior
I often see rewards and recognition programs at organizations that actually reward people for stubbornly staying with the Old Cheese, rather than encouraging them to embrace the New Cheese.  In effect, the Haws of the organization, who work to find New Cheese, get to the new Cheese Station and find it empty.  Meanwhile, the Hems of the organization remain in the Cheeseless Station (often making loud and belligerent comments about the futility of the New Cheese to anyone who will listen) and the organization eventually gives in and hands them some more cheese.

Not only does this derail the current change effort, it also discourages people from embracing future changes.  They have seen that if they just wait long enough they can be rewarded for maintaining the status quo.  Here are a few reward and recognition Do's and Don'ts based on my project experience:

• Do guarantee that anyone who joins a special project will still have their old job to return to when the project is done.
• Don't pay out project bonuses based on hitting deadlines.  This only encourages people to do things fast, not right.
• Do recognize that people are going above and beyond their normal duties and are gaining new skills that can position them for better jobs and promotions.
• Don't cause people to miss out on the benefits of their old job.  If you ask a commission-based sales person to join a project, but don't supplement their income to make up for the commissions they'll lose, they have no incentive to become a member of the team.

And the unanswered question...Who moved my cheese?
Dr. Johnson never answers this question in the book.  The point he seems to make is, it doesn't matter who moved your cheese.  Just get up and start looking for New Cheese.  I would argue, however, that in a corporate Change Management program, answering this question is very important.  Are we making the change because the customer is asking for it?  Is the CEO decreeing the change?  Is this based on a grass roots effort among employees?

Understanding who moved the cheese can greatly impact people's emotional reaction to a change, which in turn will influence the type of Change Management program you create.

Let me know: Have you read Who Moved My Cheese?  What did you think of it?

Change Management in the Project Lifecycle: Post-Project Phase

The system has been implemented, your changes have gone live, and you give a sigh of relief.  You're done.

Wrong.

Although many companies skip it, there is still one phase left: the post-project phase.  This is the time when you kick-off sustainable activities, evaluate the success of the project, and complete any shut-down activities.  Luckily, this phase is typically less frantic than those leading up to the implementation, but it is no less important.

Sustainable Activities
There are a number of activities that should continue to occur after a project has gone live.  The one you need to focus on as a change manager is on-going training.  In the short term, there will be people who missed the training roll out and need to receive training in order to use the new system.  There will also be people who need supplemental training.  A day, a week, a month after Go Live, people will discover new areas of training that they need, as well as existing areas that they've forgotten.

In the long term, you need to have a sustainable plan in place to:

• Provide training to new hires and people who switch positions
• Update training materials as the system evolves (and it will, I guarantee it)
• Offer refresher training on activities that only occur occasionally (e.g., year-end close activities for the finance department)

Whether on-going training is an activity that is handled by a company-wide training department or the project run team, your job isn't done until you have a plan in place to address these needs.

Adoption Evaluation
I have been at a number of clients where they tell me that their past projects have failed.  When I ask them what failed, they admit it wasn't the technology.  The new system was put in place without a hitch.  The real problem is that people simply refused to use it.  Once the system has gone live, you need to evaluate whether the organization has adopted it.  Are they using it when they should?  Are they using it the way they should?  Is there an influential group that refuses to use it, thus causing other groups to avoid it as well (ahem, I'm talking about you, Management)?

If the change has been adopted, congratulations!  Now, put in place a plan to ensure the organization continues to use it.  If the change has not been adopted, start doing some analysis on why this has occurred, and put a plan in place to address the issues.

Key Performance Indicators and Achieving Business Objectives
Key Performance Indicators (KPIs) may or may not be part of the Change Management team's responsibilities.  Even if it isn't, this is an area where you may want to partner with the responsible team.  If the organization is not meeting its KPIs and achieving the business objectives that were part of the project, the Change Management team will likely need to be part of the solution.  Whether there's a need for additional training, more communication, or other Change activities, you can help provide the "people perspective" that goes with the statistics.

Project shut down
Finally, when you have completed the last of your responsibilities, developed plans for sustainable activities, and handed over on-going tasks to the run team, you need to shut down the project Change Management team.  If your company has a system for knowledge transfer, ensure that you have submitted relevant work materials and feedback.  Make sure your consultants and contractors are paid and have had their access to the company shut down.  Check off the last boxes on your work plan.  Celebrate with your team.  This is the time to make sure your "t"s are crossed and your "i"s are dotted.

Congratulations!  The project is complete and you're ready to move on to your next Change Management adventure.

Let me know: How many projects have you been on that had a "Post-Project" or "Shut-Down" phase?

Change Management in the Project Lifecycle: Implement Phase

I love the Implement phase.  This is the phase where all of your hard work comes to fruition.  Training is delivered.  Exciting communications are sent.  The change/new system goes live and everyone celebrates.

This can also be a very stressful time, so remember to follow the plan, be prepared to put in some extra hours, and keep an eye on your team's morale.

Communications
In the last phase, you put together a Go-live communications plan.  Now is the time to implement it.  A few items you'll need to communicate:

• Cut-off dates and black-out periods: Often when implementing an new system, there is a period of time where new data cannot be entered into the existing system.  It is important to communicate all black-out periods well in advance of the actual event.  You will also need to communicate detailed instructions on alternative actions people should take to capture data during the black-out period.  I have found that these system-free times, whether they last weeks, days, or hours, can cause significant panic.  Communicate early and communicate often.
• Go-live success: Don't forget to let everyone know that the change was successfully implemented!  This is exciting news.  Play it up.  Have someone important communicate it.  And remind people what this implementation means to them and their day-to-day activities.
• Help and support: No matter how good your training was, people will have questions about the new system.  Make it easy for them to get help by communicating support information, such as help desk phone numbers and e-mail addresses, the names of Super Users in each department, and any special support services, such as a short-term project-staffed "war room."
• Thank you: A lot of hard work went in to implementing the change.  Don't forget to thank everyone who was involved in making the project a success.  This message should come from someone meaningful to the recipient.  

Training
It is finally time to deliver all of the training your team developed.  Once again, I could write an entire book on this topic alone, but for now, here are a few key tips:

• Be organized: There are a lot of moving parts in training delivery.  You have rooms to arrange, trainers to support, materials to deliver, and completion to track.  The more organized you are, the smoother delivery will go.  Pick the method that works best for you, but make sure everyone involved understands what they need to do, where they need to be, and how to get help if they need it.
• Use the buddy system: Very few organizations do this, but I always recommend the buddy system.  This involves partnering your trainers so that in every classroom you have one person who is an expert in the system, and one person who is an expert in the business process.  Too often, the trainer has a deep understanding of one, and only a superficial understanding of the other.  This has two major consequences: 1) your trainer will inevitably be asked questions he cannot answer, reducing end-user confidence in the training, and 2) the trainer will be nervous anticipating difficult questions and will not perform at his best.
• Be flexible: Unexpected things will happen during training delivery.  Trainers will get sick.  Technology will fail.  The system will change at the last minute.  It is important to be flexible enough to deal with these kinds of surprises on the fly.
• Provide support: Having delivered hundreds of hours of training myself, I can tell you that there are few things more frustrating than trying to get support during a training course, and not being able to reach anyone.  Ensure that there is always someone on standby ready to support your trainers.  Whether it's technical support when the conference call stops working, administrative support to print more materials when extra people show up, or simple moral support when a participant is especially difficult, your responsiveness to a call for help can greatly impact the success of training.

Super User Network
Now is the time to deploy your Super User Network in force.  What activities they participate in will vary based on their role, but consider having them do some of the following: deliver training, walk the floor providing front-line support, sit with the help desk to deliver second-tier support, and funnel information about how people are using the system back to the project.

This time can be especially stressful for Super Users.  Don't forget to thank them.

War Room/Help Desk Support - FAQ Capture and Dissemination
The initial period after the system is implemented can be extremely difficult on end users.  Often, no matter how much information is available to them on line and in supplemental materials, they will want to talk to a real person if they have questions.  To address this need, I recommend setting up a war room or providing additional help desk support.  The war room can be staffed with project team members, Super Users, trainers, and anyone else with in-depth knowledge of the new system.  They have two parts to their job:

1. First, they are responsible for answering end-user questions via the phone, e-mail, instant message, or any other means available to the end users.
2. Second, they are responsible for logging the topics of the questions.  This will allow you to compile and disseminate a list of frequently asked questions (FAQs).  Creating FAQs will help you determine what information needs to be sent to end users to improve their use of the system.

Evaluate and address issues
Be sure to leave time in your day to evaluate and address issues that arise.  You may need to send out communications to address questions and clarify items the end users find unclear.  You may need to hold quick re-training sessions if a group is having an especially difficult time with the system.  You may find yourself filling in for trainers, Super Users, and other roles on the projects that need help.  If you can arrange a team meeting at the beginning of each day, around mid-day, and again in the evening to discuss status with the team and identify issues, that will help you stay on top of issues before they create serious problems.  Even with these meetings, though, you will still need to be prepared to address new issues immediately as they arise.

Develop post-Go live plans for run team
One area that often gets neglected is the development of a run team.  Remember that once the project is complete, most of the project team members will either move on to new projects or go back to their normal day jobs.  It is important to think about who will support the system on a day-to-day basis after the system is live.  Who will make updates to the system?  Who will address technical issues and support standard maintenance?  Who will update business process and training materials when the system changes?  Who will be responsible for help desk support?  These are just a few of the questions you need to think about while determining whether you have people who can be re-purposed to address these needs, or whether you need to hire new employees.  If you do not have a run team in place, the system and its supporting documentation can quickly fall into disarray.

Let me know: Have you participated in a system Go-live?  What was the most difficult part of the implementation?