The Negative Impact of Ghosting Hours

Forgive me, Readers, I'm about to get on my soapbox.  Over the years, dozens of new consultants have listened to my speech about the dangers of ghosting hours.  Today, I'll share the speech one more time.

First, let me describe the phrase "ghosting hours."  Unlike the legal profession, where new associates are encouraged to work as many hours as possible and bill them all to a client, in the consulting profession, consultants are often encouraged to work as many hours as necessary, then only record 40 hours at the end of the week.  The hours that were worked but not recorded are "ghosted."

Even on projects where ghosting is never explicitly discussed (and most managers know better than to directly tell their team to ghost), it is implied.  Too many weeks with too many hours recorded generates frowning leaders and hard discussions.  The expectation, however, is that the work still get done...usually without any additional resources.

The benefits of ghosting are obvious.  Keeping (recorded) hours under control helps projects make their margins.  It makes the client happy.  It makes the consulting organization believe that the project is running smoothly - on time and on budget.

These are only short-term benefits, though.  In the long-term, ghosting has a negative impact on the organization, the team, and the individual.  And I firmly believe that the long-term negative impacts far outweigh any short-term benefits.

Five Dangers of Ghosting Hours

• Estimating - Many consulting firms have an estimating model they use to determine how long a project should take, how many resources are required to do the work, and how much they should charge the client.  These estimating models are typically based on extensive review of past projects.  Even firms that don't have a set estimating model will look back on their projects and use them as a guideline for bidding on new projects.  Despite these estimating models, projects consistently run over budget and miss deadline after deadline.  Teams are constantly asking for more resources.  It has gotten to the point where many consultants assume from the start that every project they're on will be extended.  There are a hundred reasons why this might happen, but one of the root causes is ghosting.  When team members hide the true number of hours they are working, the historical record of the effort required to complete a project is wrong.  This leads to inaccurate estimating models, which leads to low-ball bids and project timelines that can never be achieved.  It might not seem to matter if a low-level testing resource shaves 10 hours a week off of his time report.  But if every tester does the same, you are quickly looking at enough hidden hours to support an extra full-time resource.  Multiply this across all of the teams on a project, and it's easy to see how a "little ghosting" can lead to a grossly under-estimated project and a large time and money over-run.
• Finances - The short-term financial benefits of ghosting are obvious.  Recorded overtime eats into a project's hours and budget.  The Partner can either choose to eat these hours, which kills his margin, or he can pass the hours along to the client, which leads to a very unhappy client.  When you consider the cost of missed deadlines, project extensions, and budget over-runs discussed above, however, one or two projects that miss their margins in the short-term are a small price to pay for better estimating models and more accurate bids that lead to consistently more successful projects across the organization.  What would your consulting firm save if it could reduce the number of projects that required an extension?  What would you gain in repeat business from clients who were happy to finally work with a consulting firm that met all of its deadlines? 
• Quality of Work - I'll keep this one brief.  No one does their best work after 5 straight months of working 60 hours a week.  On many occasions, consultants will ghost hours without letting their managers know.  They don't want anyone to think they can't handle the job.  Or they've received the cultural signals that overtime is frowned upon, so they hide it.  Whatever the reason is, let me pass on this advice I once received from a very good manager, "No one can help you if you don't let them know you need help."  Clients pay a lot of money for consultants.  They expect top notch work.  Ghosting degrades the quality of work.  This upsets clients and makes them less likely to pay for your company's work in the future.
• Trust - Many companies have policies against ghosting.  When the company policy states that ghosting is not allowed, but a project is asking team members to ghost, the consultants are put in a tricky situation.  Do they ghost, and go against company policy?  Or do they record all of their hours and risk the wrath of their immediate leadership?  This situation degrades the trust between consultants and their leadership, and reduces the team's ability to work together as a cohesive unit.  When a team can't work together, it takes longer to produce lower quality work.  I direct you again to the cost of missed deadlines and poor output.
• Burn Out - Consultants burn out at an alarming rate.  When I tell people I stayed at one firm for five years, they're usually surprised.  That's a long time to stay at a consulting firm.  Studies have shown over and over, though, that there's a huge cost associated with losing an employee.  Not only are you losing all of the time and money you have invested in that person - think training and mentoring - but now you have to spend time and money to find a replacement and get that person ramped up to a comparable level.  Ghosting directly contributes to burn out, which directly hurts your organization.

The short-term benefits of ghosting may help an individual project, but the long-term negative impacts affect the entire consulting organization.  It becomes a cycle that amplifies the damage over time and is increasingly hard to break.  Considering the cost of ghosting, though, the question isn't whether your company can endure the immediate pains of breaking the cycle...it's whether it can afford not to.

Change Management for Non-Profits: Motivating Volunteers

Two years ago, I helped develop and deliver Project Management and Change Management training for non-profit organizations.  It was the most fulfilling work activity in which I have ever participated.  Not only were the participants truly grateful for the training, but I knew that they would put it to good use helping their organizations better achieve their goals of reaching out to those in need.

As I talked to different organizations, I noticed some key themes.  One major question was, "How do we motivate our volunteers to stay actively engaged with our organization?"  Non-profit organizations don't have at their disposal many of the traditional levers that companies use with their employees.  Volunteers don't receive a salary, which means there's no hope of a bonus or raise for going above and beyond the call of duty.  There are no performance reviews and no fear of being fired. 

Add to that the fact that many volunteers are giving their time on top of commitments to family, friends, and a full-time job, and you can see why non-profits experience high volunteer turn-over, absenteeism, and loss of motivation.

What can you do to motivate volunteers when many of the common corporate methods just aren't an option?

Three Practical Tips for Motivating Volunteers

1. Renew their sense of purpose: With the possible exception of high school students forced to volunteer, people typically give their time because they are passionate about the cause.  Whether it's finding a cure for breast cancer, helping the homeless get back on their feet, or finding shelter for abused animals, volunteers come to their role with a sense of purpose and a drive to help the non-profit achieve its goals.  When volunteers lose this purpose and drive, it's your job to help them find it again.  Remind them of the people who are being helped.  Show them solid examples of how your organization has helped your target group.  Share with them your plans for delivering more benefits in the future.  Basically, remind them why they care, and pump them up to continue contributing to all of the good your organization is doing. 
2. Show them their value: Volunteer work isn't always particularly glamorous.  After stuffing and licking hundreds of envelopes, answering phones for hours, or filing mountains of papers, it can be easy for volunteers to lose sight of how the tasks they are doing contribute to the greater cause.  You need to help them connect the dots.  Did the hundreds of envelopes they stuffed lead to thousands of dollars in donations?  Tell them!  Show them how even the most menial tasks help the organization achieve its goals.  If you receive positive feedback from people who have benefited from your services, share that with your volunteers, and explain how that person was directly affected by the work they did.  Everyone wants to feel like their small piece of the puzzle is important to the big picture.  It's your responsibility to help them see where they fit and why their work is important.
3. Focus on "total compensation": Many corporations these days don't just talk about an employee's salary.  Instead, they talk about "total compensation."  This can include vacation time, training opportunities, and other perks the employee receives that can't necessarily be quantified as part of their pay check.  Since volunteers aren't getting paid, it's especially important for non-profits to think about the "total compensation" they can provide to their team.  If you have the money, small items like a branded t-shirt or hat can be a fun surprise for a volunteer, and everyone always loves a free lunch.  Even if you don't have any budget for your volunteers, though, that doesn't mean you can't provide compensation.  Remember to thank your volunteers for their time and hard work.  If you can, encourage the people who benefit from your organization to provide thanks.  There's nothing better than a thank you note from a group of kids whose school was painted by volunteers!  Recognize your volunteers publicly at events they've helped to stage.  And remember, for many volunteers, the best compensation is the great feeling they get from helping others. 

Readers - If you work at a non-profit organization, how do you motivate your volunteers?

Volunteers - What could non-profit organizations do to help you stay motivated?

Lessons Ignored, Part 2: Applying the AAR to Corporate Projects

In my last post, I provided an overview of the 2005 Harvard Business Review article, "Learning in the Thick of It." (Darling, et al)  This article took an in-depth look at the Army's After-Action Review (AAR) cycle, the military version of the popular lessons learned sessions that so many corporate projects conduct as one of their wrap-up activities.  Unlike most corporate lessons learned, however, AARs actually produce on-going learning and tangible results.

As many of you finished reading about the AAR, I imagine your initial reaction was, "That sounds great, and I wish we could implement it, but my team just doesn't have the time or money to invest in such an involved process."  I can understand that reaction.  When timelines and budgets are tight, it's hard to come up for air longer than the time it takes to run to the nearest vending machine for your dinner.  The reality is, though, that when it comes to learning from our successes and failures, you pay now, or you pay later.  And I have always found that when you pay later, the price is much higher.

That being said, here I discuss:

5 Practical Tips for Implementing the After-Action Review

1. Build it into the plan: Six Sigma experts will tell you that the things that get measured, get done.  I'll modify that a bit to say that on projects, the things that get planned, get done.  Build the entire AAR cycle into your project work plan from the start.  Make the initial set of activities (e.g., the discussion of the objectives, the brief backs, etc.) part of each phase's kick-off activities.  Make the discussion of lessons learned a mandatory step in the sign-off criteria for each phase.  Set aside time in the plan for teams to discuss how they can incorporate learning and implement new strategies in each major project activity.  If you build the process into the plan from the beginning, you won't find yourself trying to find a place to squeeze it in later.
2. Remember the house rules: The Army has 5 house rules for AAR sessions - Participate, No thin skins, Leave your stripes at the door, Take notes, Focus on our issues. (4)  I would argue that the willingness of people to participate hinges on the willingness of leadership to "leave their stripes at the door" (i.e., forget your title - in these sessions, you're not the Project Manager or VP, you're a member of the team) and of the team as a whole to have a thick skin.  If leaders pull rank and colleagues leave the meeting in a huff, the team will either stop participating or the whole process will become a show where everyone compliments everyone else.  I would add one more house rule: forget your pride.  It's hard to take negative feedback.  The point of the AAR, however, isn't to focus on what you did wrong.  The point is to figure out how to move forward and be even more successful with each new phase. 
3. Focus on "We":  Most people have sat through a lessons learned session that was more about placing (or deflecting) blame than it was about learning.  Remove "you" and "them" from your vocabulary.  This isn't about figuring out which team did what activity wrong.  The point isn't to find a scapegoat for the timeline extension or budget overrun.  AARs are about "us" and "we".  What have we learned from the activity we just completed, and how can we incorporate this learning into the next activity we have to tackle?  We are a team, and we are jointly responsible for the success or failure of this project.
4. Make it visible: Once you've decided on the few major lessons you can learn, and figured out a way to incorporate them into the project, make sure everyone is aware of them.  Now is not the time to hoard information among a small group.  Let everyone on the team, from the top Sponsor to the most junior assistant, know what steps the group will be taking to improve the next cycle of activity.  If they're steps that are difficult or that people are likely to forget, post them someplace visible.  Learning takes time and repetition.  Sending out one e-mail at the beginning of a project phase is unlikely to do the trick.  If you're implementing new house rules for running efficient meetings, for the first few weeks make the first agenda item a reminder of the rules.  If you're asking people to follow new guidelines for system development, post the guidelines in the major work areas so people can refer to them without having to dig through their notes.  The easier it is for people to remember the learning, the more likely they are to incorporate it into their daily activities.
5. Highlight the results: Did the AAR generate lessons learned that led to new strategies that resulted in process improvements and project success?  Let everyone know!  Showing a direct connection between the learning process and improved results encourages everyone to continue the AAR process.  Did some of the new strategies not pan out the way you expected?  Don't hide these results.  AARs are a cyclical process for a reason, and a little trial-and-error is not considered failure.  Instead, when you don't achieve the expected results, look at this as another learning opportunity.  Discuss why the strategy didn't work and figure out how to tweak it so that next time it is more successful.  If you hide mistakes and treat them as a cause for embarrassment or fear, your team will do the same.  Instead of creating an open, learning environment where people look for ways to constantly improve, you'll create a closed and secretive project environment where people stick with the status quo, whether it works or not, to avoid making mistakes.  That's not how the Army's Opposing Force wins, and it's not how project teams achieve success.

Has your project team successfully built lessons learned into the project?  What strategies led to an open environment where people were encouraged to learn from both their successes and failures?

References

Darling, M., Parry, C., & Moore, J. (2005, July-August). Learning in the Thick of It. Harvard Business Review, 1-8.

Lessons Ignored: What Corporate Projects can Learn from the Military

Anyone who has spent time around corporate projects has sat through a project wrap-up that included a lessons learned session.  The first time you're excited.  "I can offer insight and feedback that will help the next team avoid our mistakes!"  The second time you still hold out some hope.  "Maybe this group will use our input and build on our lessons learned."  A few projects later, you're resigned.  "Why bother?  They're just going to write my advice on a piece of paper, stick it in a folder, then never look at it again."

In 2005, Harvard Business Review published "Learning in the Thick of It" (Darling, et al).  This article looked at After-Action Reviews, the Army's version of lessons learned.  The found that instead of the typical post-mortem report generation that most companies slog through, the U.S. Army's Opposing Force had developed a dynamic, cyclical process that generated genuine learning and improved results.

If you want to read the article yourself (and I highly recommend that you do), the citation is located at the bottom of this post.  For those who don't, I offer a brief summary of highlights from the article.

The Process

1. Despite their name, After-Action Reviews (AAR) do not begin after a task is completed.  Instead, they begin during the planning phase.  Before any action is taken, the senior leader develops operational orders.  These orders have four parts: the task, the purpose, the commander's intent, and the end state.
2. The commander then shares these orders with his subordinates.
3. Each subordinate is responsible for providing a brief back - "a verbal description of the unit's understanding of the mission and its role" (3).
4. Soon after, the team holds a dress rehearsal.
5. Finally, the team begins the mission.  After-Action Reviews are conducted throughout the mission, not just at the end.

The Meeting

The After-Action meetings consist of three main parts that address four questions.  The first step is a reiteration of the AAR rules (4):

1. Participate.
2. No thin skins.
3. Leave your stripes at the door.
4. Take notes.
5. Focus on our issues, not the issues of those above us.

The team then conducts a comparison of the actual results versus the intended results.  To help focus this conversation, they answer four questions (4):

1. What were our intended results?
2. What were our actual results?
3. What caused our results?
4. And what will we sustain or improve?

Once the team has addressed these questions, the senior commander provides his assessment of the lessons learned and the lessons that will be relevant in the immediate future.  When the meeting ends, participants immediately hold AARs with their own teams, to continue the process through all levels of the unit. (7)

The Deliverable

What do these meetings produce?  Unlike most corporate lessons learned sessions, the Army's AARs aren't focused on creating a report or a presentation.  They are focused on generating lessons, theories, and plans that can be applied immediately to the on-going mission.  They avoid blame and instead focus on identifying ways to learn and improve.  Rather than producing a post-mortem, they produce results. 

AARs "focus on improving a unit's own learning and, as a result, its own performance." (4)  In fact, "the group does not consider a lesson to be truly learned until it is successfully applied and validated." (2)

If this sounds like a far cry from the lessons learned sessions you've sat through, you're not alone.  How does your organization conduct lessons learned?  Do they actually result in learning? 

Next up: Applying the principles of the AAR to the corporate project environment.

References

Darling, M., Parry, C., & Moore, J. (2005, July-August). Learning in the Thick of It. Harvard Business Review, 1-8.

Training and the One Minute Manager: The Ultimate Test

Reference note: The full citation for Leadership and the One Minute Manager can be found at the end of this blog post.

Years ago a friend let me borrow her apartment for a week.  One night I picked up her copy of The One Minute Manager by Ken Blanchard and Spencer Johnson.  At the time I was 23, out of college for less than a year, and not managing anyone.  Whatever wisdom the book had to offer was lost on me.

Then last week I picked up Leadership and the One Minute Manager.  The thing that most captured my interest was that, although the book is focused on leadership, it makes numerous references to training.  In fact, the more I read, the more I became convinced that the title could easily be changed to Training and the One Minute Manager.

Let me start my discussion with my favorite quote from the book.  Toward the end of the book, the discussion turns to performance evaluation, and one of the characters shares this anecdote:

...I think of my favorite college teacher.  He was always getting into trouble with the dean and other faculty members because on the first day of class he would hand out the final examination.  The rest of the faculty would say, 'What are you doing?'  He'd say, 'I'm confused.'  They would say, 'You act it.'  He'd say, 'I thought we were supposed to teach these people.'  They'd say, 'You are, but don't give them the questions for the final exam.'  He'd say, 'Not only am I going to give them the questions for the exam, but what do you think I'm going to do all semester?' (Blanchard 87)

Have you guessed his response?  "Teach them the answers."

This anecdote was meant to illustrate the proper way to conduct performance evaluations.  It can just as easily be applied, though, to corporate training.  It addresses some of the fundamental issues of training:

• What is the objective of corporate training?
• How do we measure success?
• What is the role of the trainer and the trainees?

These are questions most trainers have thought about throughout their careers.  Here I set forth my answers, with Leadership and the One Minute Manager on my mind.

Practical Answers to 3 Training Questions

1. What is the objective of corporate training?  Let's be practical.  Training, both development and delivery, costs money.  And these days, money is tight.  Most often the objective of corporate training is to teach people to do their jobs better, faster, more efficiently, etc.  We want them to use new software, manage their people more effectively, and follow new policies.  All of which is designed to help them help the organization meet its overall business goals.  Compare this to the goal so many educational institutions state of teaching students how to learn, how to reason, etc.  With such different objectives, it doesn't make sense to use the same training methods for employees that we would for students.  Which brings me to the next question...
2. How do we measure success?  A student's success is often measured by his ability to memorize enough information from a course that he can answer questions on a test without advance knowledge of those questions.  Like the students in the anecdote, however, employees already know the questions on the test.  In fact, there's only one question: Can you successfully perform your day-to-day job activities?  And there's only one acceptable answer.  As trainers, we often get caught up in measuring success based on trainee feedback on course evaluations.  Or we administer end-of-course tests and count a course successful if the trainees can pass.  Sometimes we include pre-tests and post-tests and measure the level of improvement.  The list goes on.  Yet, even when these tests involve real-life simulations, correctly completing a simulation in class is very different from successfully completing your job.  At the end, the only true measure of success is whether an employee consistently and accurately can apply the skills learned in the training sessions to their daily activities.  This measurement of success raises the question...
3. What is the role of the trainer and the trainees?  This view of training demands a partnership between the trainer and the trainee.  When the only question on the final exam is the ability of the trainee to apply the training to her job, who knows better how to write the exam than the trainee herself?  While the trainer is traditionally the one responsible for putting together the training curriculum and the evaluations, in reality, without the input of the trainee, the potential for the course to succeed is greatly reduced.  In this model, the trainee can't abdicate responsibility for her learning to the trainer.  And the trainer can't work in a vacuum deciding what information is important.  Instead, it's a symbiotic relationship. 

Not only does this model of training increase the chance of success from a content perspective, but it also addresses one of the fundamental concepts of Change Management: People are more invested in the success of endeavors that they have helped to shape and create.  The last time you were forced to attend corporate training, I imagine you did a bit (or a lot) of grumbling.  It's a waste of time.  You have more important things to do.  These courses never teach you what you need to know.

What if you had helped to design the course?  What if you had decided what questions would be on the final exam, and knew that the entire course would be dedicated to teaching you the answers?  What if you knew the training would directly contribute to your success?

Trainers: How much do you collaborate with trainees in developing training?

Works Cited



Blanchard, Ken, Patricia Zigarmi, and Drea Zigarmi. Leadership and the One Minute Manager: Increasing Effectiveness Through Situational Leadership. New York: William Morrow, 1985.

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?

Better Skills, Better Change: Not What You're Expecting

Reminder: All of the numbers used in this post continue to come from IBM's 2008 Global Making Change Work study.

So far, I have been a huge fan of IBM's Making Change Work study.  It provides solid quantitative research in a field that is sorely lacking in scientific study.  They have also drawn some outstanding conclusions from this research.  When I got to the "Better Skills, Better Change" section, though, they threw me for a loop.

If you're like me, when you read the third headline from the study, you were expecting a discussion around training and ensuring your people have the right skills to implement the change.  Instead, the study focuses on having a skilled Change Manager.  In fact, IBM found that, "Projects with a professional Change Manager had a 43 percent success rate, compared to a 36 percent success rate for projects without one." 

What "better skills" should a professional Change Manager possess?  Oddly, the study doesn't say.  It provides excellent advice about ensuring Executive Sponsorship, involving employees in the change, communicating across the organization, and building sustainable change.  None of these topics, however, tell you what skills are necessary for a good Change Manager.  Which leads me to today's practical advice:

Skills Every Good Change Manager Should Possess

As with any position, there are a number of qualities a good Change Manager should possess.  Below are the top three skills I recommend.  If you're hiring a Change Manager, look for these skills.  If your goal is to become a Change Manager, look for training and hands-on opportunities to develop these qualities.

1. Foundational Skills:  A Change Manager should be able to jump in to any aspect of Change Management and actually do work.  If your Change Manager can't a) write a coherent communication, b) plan, develop, and deliver training, c) create and execute a Stakeholder Management plan, and d) explain the methodology he or she is following, it's time to find a new Change Manager.
2. Patience and Diplomacy: Because Change Managers deal with the people impacted by a project, they are often the face of the project.  They are the ones delivering communications and training, responding to inquiries, and, quite often, dealing with upset employees.  I've had clients and end users cry in my office, yell at me in person, over the phone, and via e-mail, and tell me how stupid they think the project is.  It is extremely important that in any of these situations your Change Manger is able to take a deep breath and respond in a calm, professional manner.
3. Professional Polish: Change Managers often work with senior clients much earlier than their counterparts.  It's more common for a Change Manager to interact with C-suite clients than, for example, the testing lead.  As a result, professional polish is mandatory for anyone involved in Change Management. 

Do you agree?  Are there other skills that you feel are more important?

Solid Methods, Solid Benefits: Solid Tips

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

Now that you're all fired up to gain insight into the changes a project will bring to your organization, IBM's study lays out recommendation number two for implementing a successful project: "Solid Methods, Solid Benefits."  According to the study,

Practitioners who always follow specific and formal change management procedures had a 52 percent project success rate, compared to a 36 percent success rate for practitioners who improvise according to the situation.

That's a 16 percent difference in success rates.

How is the average person supposed to put this advice into practice?  Unless you're a Change Manager, or work for a large organization that has a Change Management department you can tap into, the chances that you just happen to have a solid Change Management methodology on hand is pretty slim.

Don't let this stop you from realizing the full potential for "Solid Benefits."

Practical Tips

If You're Hiring Outside Help:

Many projects will bring in outside consultants to help with implementation.  If your company is doing this, here are some questions I recommend asking about their Change Management methodology during the sales process.

1. Q: Have you included Change Management in your proposal?  A: If the answer is, "No," that's a very bad sign.  Ask them why not, and follow-up by finding out what it would cost to add to the proposal.  If the answer is, "Yes," continue on to the next question.
2. Q: Do you have a Change Management methodology that all of your practitioners follow?  A: If the answer is, "No," I recommend looking at another firm.  If the answer is, "Yes," ask question 3.
3. Q: Do your Project Managers support Change Management and its integration into the project?  Do they understand the Change Management methodology?  A:  I've been on more than one project where a Project Manager said to me, "I don't really understand what you Change people do, and I'm really busy, so I won't be able to provide any support to the work you're doing."  That is never a good sign.  If the Project Manager doesn't understand and support the Change Management methodology, there's a good chance that many of the vital Change activities will be under-resourced or cut from the project entirely.
4. Q: Can your methodology be adjusted to fit our particular culture, project, resources, and needs?  A: Although the IBM study stresses that benefits are achieved as a result of consistently following a structured methodology, it is also important that a methodology has flexibility built into its design.  Not every activity in a methodology is relevant to every project.  To make sure you get the most bang for your buck, work with the consultants to figure out which aspects of the methodology will provide the most value.  This is especially essential if you have a limited budget.

If You're Doing It Yourself

Sometimes hiring consultants just isn't an option.  Sometimes you're the technology guy who is told to "figure out some Change stuff."  Sometimes an organization that has always flown by the seat of its pants suddenly realizes the benefit of having a Change Management methodology and wants you to set one up.  Now what?

1. Read the Experts: If you only have time to read one book, I'd recommend something by John Kotter.  He has a number of books available, but Leading Change is probably his best known.  If you have time for two books, check out Managing at the Speed of Change, by Daryl Conner.  And if you have lots of time, the "Harvard Business Review" has published a number of interesting, thought-provoking articles on Change Management over the years.
2. Online Resources: For overall Change Management information, check out Prosci's Change Management Learning Center.  For in-depth information about training, go to the American Society for Training and Development.
3. Take Some Training: Training options, either in the classroom or on-line, abound.  Since they're always changing and I can't attend them all, I won't recommend any here.  Ask around for recommendations of courses people have attended.
4. Buy It: I know that a few years ago, one of the major consulting firms would sell its methodology to companies for a price.  I have also heard of Change gurus who will come to your organization and put in place a personalized Change Management methodology.  If you have the money, this can be a fast way to put a methodology in place.

You've reaped rewards.  You've garnered benefits.  Up next: "Better Skills, Better Change."

Real Insights, Real Actions: What It Means to You

Reminder: The facts and figures used in this post come from IBM's 2008 Global Making Change Work Study.

Now that you're completely scared that your project will be part of the 59% that fail, let's take a look at the factors that typically cause it to fail, as well as IBM's first finding on how to succeed: Real Insights, Real Actions.

IBM's study found that the three most significant implementation challenges are:

1. Changing Mindsets and Attitudes (58%)
2. Corporate Culture (49%)
3. Complexity is Underestimated (35%)

These are all "soft" people-oriented challenges that can be addressed through a strong Change Management program.

In contrast, the three challenges at the bottom of the list are:

1. Change of Process (15%)
2. Change of IT Systems (12%)
3. Technology Barriers (8%)

These all fall into the "hard" category.  Despite being seen as less of a challenge to success, I have found that these are the areas that people spend the most time and money addressing.

How do we stop focusing all of our resources on the least challenging factors and start addressing the challenges most likely to cause our projects to fail?  IBM's first suggestion is "Real Insights, Real Actions," which they describe as getting a "full, realistic understanding of the upcoming challenges and complexities, followed by specific actions to address them."

Let's Get Practical

"Real Insights, Real Actions" is a great suggestion, but how do you take it from theory to practice?  Here are
five suggestions on how to build this insight into your project plan:

1. Don't wait until it's too late: Many projects don't have a Change Manager join the team until they are finished with the plan and design phases.  The reasoning behind this is that the Change Manager won't have enough work to keep them busy during these phases, so their presence is a waste of time and money.  I've also heard people say that the work a Change Manager does during this phase will just distract the other team members from focusing on their primary work.  Bringing the Change Manger on early, however, allows you to capitalize on the "Real Insights" IBM advocates.  It also ensures that the Change Program is integrated into the overall project plan, reducing future conflicts around resource delegation.  Can't afford to have a full-time Change Manager this early in the project?  Consider bringing them on part time.  A little integration now goes a long way toward ensuring the future success of the project.
2. Conduct an Impact Assessment: Impact Assessments allow you to discover how people, processes, and tools will be impacted (i.e., changed) by your project.  I've often heard clients say they don't need to complete this activity - they already know what the impacts will be.  Maybe they do, but this knowledge doesn't help the project if it only resides in their heads.  Gather this information and put it on paper.  It's also good to remember that what employees at one level of the organization "know" is often very different from what employees at another level of the organization "know."
3. Conduct an Executive Change Readiness Assessment: Executive Sponsorship is one of the most important factors in a project's success.  Just because an Executive sits on the project Steering Committee, however, doesn't mean he or she is ready to support and drive the change.  Interview, survey, chat at the water cooler, but somehow find out how ready the Executives are to make this project a success.  I find that guaranteeing anonymity is often very helpful in making this activity a reality.  I've also found that Executives are more likely to really believe in the anonymity if you have an outside consultant conduct the interviews and surveys.
4. Plan, Plan, Plan: Here's where the "Real Actions" come in.  Now that you've gathered all of this information, it's important to use it.  Change Management isn't about creating pretty PowerPoint presentations.  Take the data you've collected and start building a strong Change Management program.  How will the impacts you've uncovered influence the training and communications you need to create?  If your Executive Sponsors don't really support the project, what actions can you take to help them fulfill their roles?  What unexpected findings could derail the project, and what plans can you put in place to mitigate their impact?  Some consultants will tell you that Change Management is an art that doesn't require planning.  I disagree.  It's like SCUBA diving.  Gather the facts.  Plan the dive.  Dive the plan.
5. Integrate: Integration needs to occur in two forms.  First, once you've created your Change Management Program, make sure that your plan is integrated into the overall project plan.  Change Managers can't work in a vacuum, and if you want time from SMEs (Subject Matter Experts), Business Analysts, Executives, etc., you need to lay claim to that time now.  This is especially important when planning for training development and delivery.  Second, Change Managers need to integrate with other team leads early and often.  Project members often don't understand the role of a Change Manager, so they ignore them.  This leads to duplicated work, missed opportunities, and a Change Program that isn't rooted in the most up-to-date information.  Although functional leads who are heads-down working on design documents may think that helping the Change Manager identify project impacts is a waste of time that distracts them from their primary focus, having integration among the teams is the only way to ensure the Change Program addresses the full range of client needs.

Coming up next: How to put "Solid Methods, Solid Benefits" into practice.

I'm Running a Business Here

No matter how many examples I can give about projects that failed due to a lack of strong Change Management, at the end of the day Executives are trying to run a business.  Anecdotal evidence isn't enough to prove the value of Change Management.  They need hard numbers.

In 2008, IBM once again conducted their Global CEO Study, which identified the ability to deal with change as a top C-suite concern.  On the heels of this finding, IBM followed-up with the Global Making Change Work Study.  This study involved 1,500 practitioners worldwide and delivered a set of findings that demonstrated the value Change Management can bring to a project.  All of the numbers I discuss in the rest of this post come from that study.

Perhaps the most frightening finding was that only "41 percent of projects were considered successful in meeting project objectives within planned time, budget, and quality constraints."  If you and your main competitor are both implementing a project that can give you a substantial competitive edge, only one of you is going to succeed.  The question becomes, how do you ensure that your organization doesn't become part of the 59% failure rate?

Luckily, the study goes on to reveal four elements that can significantly increase a project's chance of success:

• Real Insights, Real Actions
• Solid Methods, Solid Benefits
• Better Skills, Better Change
• Right Investment, Right Impact

In each of my next four posts, we'll look at the numbers that support these findings, as well as practical ways to incorporate these success factors into your next project.

Do We Really Need Change Management?

There is a great deal of skepticism among consultants and clients alike as to the necessity of Change Management.  Often they don't know exactly what Change Management is or what value it will provide, but they do know that it costs money.  Who can blame them for being reluctant to spend money without a clear understanding of the results they'll get for that investment?

Let's start this conversation with an exercise I use with my clients.  First, raise your hand if you've ever been at a company where they were implementing a new project (e.g., a new computer system, new business processes, organizational redesign).  Now, put your hand down if you've ever seen one of the projects fail.

I've never seen more than one or two hands stay up.

I finish by asking the group to share some of the reasons these projects have failed.  I consistently hear the same reasons over and over again, regardless of the size of the company, the industry, or the type of project.

1. Management didn't support the project.  If my boss wasn't going to make the change, why should I?
2. We didn't receive adequate training.  I didn't know how to use the new system/processes, so I continued doing things the old way.
3. I didn't even know there was a project!  No one told us about the upcoming changes until right before the new system/processes were implemented.
4. I didn't understand why we were making the change.  Taking the time to learn the new way of doing things didn't seem as important as focusing on my day-to-day job.
5. Past projects have either failed or been abandoned.  This project will probably be the same.  Why should I waste my time learning about something we won't be using in a month?

It's unusual to hear someone say a project failed because the technology didn't work.  Instead, it becomes apparent very quickly that when projects fail, it is typically because they ignore the people who are impacted by the change. 

Each one of the reasons for failure listed above can be addressed with a strong Change Management program.  Whether it's a plan to increase Executive Sponsorship, a reminder that employees can't learn a new system through osmosis, or the generation of clear communications, Change Management brings the people-side of a project to the forefront.

Have you seen a project fail?  What was the main reason the project didn't succeed?

First Things First...

Before we begin looking at Change Management topics in detail, it's important to understand what exactly we're here to discuss.  What is Change Management? 

First, if you're reading this because you think "Change Management" and "Change Control" are the same thing, you're in the wrong place.  As a Change Manager, I am not the person who decides what changes can be made to a system after design freeze.  Sorry, tech. guys.  That's a different blog.

I also do not define Change Management as "that touchy-feely stuff" or "the team that arranges parties." 

Some people will define Change Management by listing its most common components: Communications, Training, Executive Sponsorship, Stakeholder Management, Organizational Design, and, in some cases, Project Management, and Continuous Improvement.  That's the equivalent, however, of defining a car as four tires, a steering wheel, and a motor. 

If you read books and articles on Change Management, each one will provide a slightly different definition.  They are interesting and well worth reading, but for the purposes of this blog, here is the official Emily Carr definition, "Change Management is the set of processes and activities used to help organizations, teams, and individuals accept, adopt, and master a change to behaviors, processes, and/or technology." 

Do you agree?  What's your definition of Change Management?  Post your definition in the comments section below this post.