If you enjoy the blog, you'll love the book!

Dear readers,

I'm extremely excited to announce that my book, Practical Change Management for IT Projects, will be published next week and is now available for pre-order.  Just click here to order your copy now!

Like the blog, the book is focused on providing practical advice on implementing Change Management.  It's full of templates and exercises that will help you create a Change Management plan.  Based on the Five Pillars of Change, with chapters dedicated to Sponsorship, Stakeholder Management, Communication, Training, and a section on Organization Design, this book provides a comprehensive beginner's guide to Change.

And don't be fooled by the name.  Practical Change Management for IT Projects will be relevant for anyone implementing Change Management on organization, culture, or process projects, as well.

Thank you to all of my loyal readers for making this book possible, and I hope you enjoy the book as much as you do the blog!

Happy reading,
Emily

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?

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?

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?

Change Management in the Project Lifecycle: Test Phase

By now, your Change Management team should be fully staffed and ready to put in some serious hours.  The test phase is when the project team verifies that the system they built works the way it was designed.  Although the Change Management team is sometimes left out of testing activities, it is extremely beneficial for your team to participate in test.  This is especially true for training developers and deliverers, as this is the perfect opportunity for them to get extensive, hands-on interaction with the new system.

Training

The majority of your team's time during the test phase will likely be dedicated to training development.  Now that the system is built, your training developers can get into the system to figure out how it works and start to create training documentation.  If this is a packaged system, experienced developers may only need to figure out how the system was customized.  In the case of custom systems, developers may end up needing to learn the system from scratch.

I could write dozens of posts on training alone, but for now, here are just a few of my top tips for training development during the test phase:

• Functional team/SME access: No matter how experienced your developers are, they will have questions about the system.  Ensure they have access to members of the functional team, as well as Subject Matter Experts.
• Document, Document, Document: It is always easier to cut content from training than it is to try to add content that was missed.  Stress to your developers the importance of thorough training documentation.
• Standards: If you have more than one training developer, make sure to put in place documentation standards prior to the start of training development.  Then make sure all of the developers understand the standards.  This will help ensure consistency of training materials across all developers.
• Sign-off: Put in place a sign-off process.  Involve members of the team and the business.  No matter how busy people say they are, enforce the sign-off process.  Nothing will explode in your face faster than training materials that are delivered to the business without proper sign-off.

Communications

Now that you are getting closer to implementation, it's time to begin communicating details.  People will start to be very interested in information about training, especially when and how much.  They will also want to know when they will be expected to begin using the new system.  Everyone is busy, and it's best to give them plenty of time to begin planning their schedules around things like training delivery schedules and go-live activities.

This is also a critical time for keeping your ear to the ground.  As people hear more about the new system, complaints are likely to begin popping up.  This department doesn't like the screen layout.  That department feels like they're losing functionality that was provided by the old system.  Another team heard that the system won't go live on time.  Rumors will be swirling and you can only address them if you are aware of them.  Work your network, and remember: It's always better to address issues and concerns head-on.  If you don't tell the project's story, someone else will...and you might not like the story they tell.

Super User Training

The test phase is an excellent time to begin hands-on training with your Super Users.  Three easy ways to start their training:

1. Involve them in test activities.  This will give them lots of hands-on experience with the system, as well as the opportunity to ask questions of the functional teams.
2. Involve them in training development.  Super Users can provide valuable insight during the training development process about which activities are likely to be the most difficult for their peers.  This can help you focus the training materials on the most important topics.
3. Involve them in training pilots.  You will likely want to pilot your training materials with a small group before rolling them out to the entire organization.  Using the Super Users as your pilot group not only gives you a ready-made pilot group, but it also gives the Super Users an early round of training.

Keep in mind that the type of training you put your Super Users through will be highly dependent on their role in training and implementation.

Day-in-the-Life

Hopefully, by now, you have run a number of system demonstrations targeted at different audiences across the organization.  What most people really want to know, though, is, "How will this change impact the way I do my day-to-day job?"  Running special Day-in-the-Life demonstrations gives you the opportunity to address this question.

A Day-in-the-Life demo focuses on how a specific person/job/department will use the new system as they do their normal activities throughout the day.  It looks at:

• Where information comes from
• Where information is sent
• New tools and processes
• Integration with existing systems
• Specific activities required to perform a specific job/role

A word of warning.  If, during the test phase, the team discovers major bugs in the system, it is best to hold off on doing Day-in-the-Life presentations until the bugs are resolved.

Change Discussion Guides

Information that comes from a trusted and respected colleague is always received better than information that comes from an outside consultant.  This is why Change Discussion Guides are a great tool.  Change Discussion Guides are information packets that are given to managers.  The managers then use this information to hold discussions with their direct reports and teams to help them understand the changes that will come as a result of the new system.  Information you may want to include in a Change Discussion Guide includes:

• How jobs/roles will change
• Aspects of a person's job that will become easier or harder
• Required and optional training
• Implementation timeline
• Where to get help with the new system
• Frequently asked questions
• Department-specific changes

As part of the Change Discussion Guide, make sure to build in time to review the guide and the information in it with the managers, so that they are fully prepared to meet with their people.

Go-live Preparation

Now is the time to start making a Go-live plan.  Most of the plan will revolve around communications.  What information do you need to send out?  When does it need to be sent?  Who is the best person to do the communicating?

I would also recommend that you have a back-up plan.  The back-up plan should focus on what communications will need to be sent if the system does not go live as scheduled.  I know it sounds like a very negative step to take, but sometimes cutovers do not go as expected, and it's important to have a plan in place to address this scenario.

Only two phases left!  You're almost there.

Let me know: Have you ever served as a Super User?  What activities were most effective at keeping you engaged in the project?

Change Management in the Project Lifecycle: Build Phase

The Build Phase is when the new system comes to life.  Packaged systems are customized to meet the client's requirements and reflect the agreed-to design.  Custom systems are built from the ground up and can be viewed as a functioning program for the first time.

This is when the project really starts to get busy for Change Management.  Up until now, you may have been feeling relaxed.  You may even have felt guilty that you weren't working long hours like the rest of the team.  Never fear...you are about to ramp up.

Communications
You should already be in a groove when it comes to communicating with Sponsors, project team members, and Super Users/Change Agents.  Now is when you can begin end-user communications.  I'll write another post where I go into more detail about how to generate a detailed end-user communication plan, but for now, here are suggestions about topics you might want to communicate:

• The Final Design: Design phase is complete.  This is an excellent time to let people know what the new system will be capable of doing and what it will look like.  I like to have two sets of messages here.  First, I start with a high-level overview of the system design that explains how it will be used in an integrated fashion by the entire organization.  Second, I follow up with department-specific communications that go into more detail about how the part of the system each group will use has been designed.  Don't be afraid to name drop.  If someone from the department helped design the system, mention that so that future end-users will feel comfortable that their needs were represented and the system wasn't designed in a vacuum by the project team.
• Project Timeline: Start communicating a high-level project timeline.  I don't usually go into much detail at this point, because time lines change, but it doesn't hurt to let people know that training will be rolled out in Q2 and the Go-live will occur in Q3.  This helps to 1) re-assure end users that you haven't forgotten about important activities such as training, 2) allows them to understand when changes will occur, and 3) reduces the sense of panic about an unknown future that develops when people don't have a general time frame for major changes.
• Benefits: The project should have a list of benefits that the new system will bring to the organization.  Begin communicating these.  Once again, you can have two sets of messages: one set for the organization as a whole, and one set that is department-specific.  A word of warning: If there are no real benefits to the system implementation (and I've seen projects where this was the case), don't try to make them up.  People can see through fluffy corporate jargon in seconds, and will read any future communications you send with a skeptical filter.
• Bonus: If you have screen shots (or even real demos) of the system that you can share, start doing it!  People love pictures and demonstrations and they will get you a lot farther in building an understanding of the change than any e-mail or list of bullet points ever could.  Just make sure that the screen shots are unlikely to change, and that demos actually work before sending them out.

Training
Now that the system is designed, you are able to create the training analysis.  This is where you determine who needs to be trained on what parts of the system, when this training needs to occur, and how you will deliver the training.  This is a tedious and time-intensive activity, but it is crucial.  Not only will it allow you to create a detailed training curriculum, but it will also help you to determine the plan for creating all of the training, including how many training developers and deliverers you will need.

I strongly recommend that you get input from the functional teams, subject matter experts, and Super Users.

This is also a good time to have a meeting with the client's HR or training department.  Ask them about past training they've implemented.  What worked?  What didn't?  Are there certain unique aspects about the organization that could impact the timing or method of delivery?  Remember - things like shift work, unions, hourly employees, and location can greatly impact your training plan.

Change Impact Assessment (CIA)
There are many variations on the Change Impact Assessment.  The one I do has three components: people, process, and technology.  This is designed to help the project, the Change team, and the organization's leadership understand how the new system will affect the organization: the good, the bad, and the ugly.  You may find that the change will bring benefits to the organization across the board.  Or you may find that one department is gaining a lot of benefits from the change, while another department is losing something that they consider vital to their work.  Regardless of the results, it is important not to sugar coat the outcome.  A frank understanding and discussion of the impact of the change will allow you to capitalize on the positive and address the negative.

There is some disagreement over the best time to conduct the CIA.  Many projects will conduct it much earlier in the project.  My experience, though, is that until the design is complete, people don't understand the new system well enough to give good insight into how it will be different from their current way of doing things.

• People: In this portion of the CIA, you focus on the impact to people.  Will their day-to-day responsibilities change?  Will you need more or less people to do the same tasks?  Will they need to learn new skills?  Are they open to change?
• Process: New systems often lead to new or change business processes.  Is the organization moving from manual to automated processes?  Are steps being added or removed?  Will the roles involved in a process change?  Will the length of time required to complete a process be more or less?  Are new safeguards (e.g., authorizations, audit trails, etc.) being added to the process?
• Technology: This is a basic nuts-and-bolts comparison of existing technology against the new technology.  In an organization where different departments or business units were allowed to select their own technology, you may find very different impacts.  Especially in organizations where there are a lot of home-grown systems that were specifically designed for a department's individual needs, you are likely to find that people consider the new technology a step backward.

Organization Design
Now is a good time to start working with Human Resources to understand if there is an organization design component that is required as a result of the new technology.  If there are new skills that are required, job descriptions, compensation structures, and responsibilities may need to change.  Entire teams and departments and departments may need to be re-designed if the roles, responsibilities, and processes are changing drastically.  You may also find that positions need to be added or eliminated based on the new system's ability to increase or decrease workload.  Even if HR comes back and says they don't want to make any changes until they've seen the system in action for a few months (which is a response I've heard often), it's good to at least begin thinking about how the organization may need to adjust in response to the coming changes.


Let me know: How often is Organization Design part of the projects you work on?

Change Management in the Project Lifecycle: Design Phase

The Design Phase is where things really start to get fun.  As the functional teams work with end users to determine how to translate the requirements gathered during the Analyze Phase into useable system functionality, it's time for the Change Management team to ramp up.  If you've been a team of one up until now, Design Phase is an excellent time to bring on another team member.

Practical Design Phase Activities

Once again, the activities in this phase can be broken down by which team you partner with.  This time around, we'll add another team: Human Resources.

Activities Conducted by Change Management

Executive Change Readiness Assessment (ECRA):  The ECRA is designed for top-level Executives.  This will typically include your Sponsors, the Directors and/or Vice Presidents of impacted business units, and, depending on the organization, C-level Executives.  The focus of this assessment isn't whether the Executives are ready to change, but whether they are ready to direct and support the change.  You should plan on conducting this assessment multiple times throughout the project, depending on the project's length.  Use the first assessment during the Design Phase as a baseline against which to measure future iterations.

Change Readiness Assessment (CRA):  The CRA is designed for the future system end users.  Unlike the ECRA, the CRA does focus on whether end users are ready to adopt the change.  The assessment asks end users whether they feel they are receiving enough communications, adequate training, and sufficient management support.  Once again, plan on conducting the assessment multiple times during the project.  And remember that this first one is a baseline...your results will not be good, and that is to be expected.  You haven't rolled out any training, yet.  How can they give it high marks?

Super User/Change Agent Network:  There are many different names for this type of network, and many different uses.  Essentially, it is a group of future end users who are not full-time members of the project, but who are asked to participate in project activities.  Their role may be to act as Super Users who know the system better than your average end user and are expected to eventually serve as trainers and front-line support.  They may simply be Change Agents who are asked to vocally support the change among their peers and help others embrace the new way of doing things.  Or they may be some combination of the two.  Whatever their role, they are an integral part of helping the change be adopted throughout the organization, and should be selected with care.  Once you've created the network, manage them with care, show them lots of love, and you will see great returns on your investment.

Communications:  There still isn't a lot to communicate to the general end user population at this point, but you should be actively communicating with your Change Agent Network and Sponsors.

Training: The functional teams will likely be holding a large number of design workshops during this phase.  If at all possible, you should have your training developers attend as many of these workshops as possible.  This will help them develop a solid understanding of the system design that will help them build the training in future phases.

Partnering with the Functional Teams: If you have more than one person on the Change Management team, I recommend assigning each person to one or more functional teams.  This does two things.  First, this provides one point of contact for each functional team.  This way, they don't need to try to guess who on the Change team to contact when they have questions.  It also reduces the number of e-mails and phone calls the Change lead has to deal with each day.  Second, it helps ensure at least one person on the Change team will have a deep understanding of each functional area, which will come in very handy for developing communications and training.

Design Feedback Workshops: If the functional teams haven't planned these on their own, recommend they be added to the plan.  If they have planned these, volunteer to help.  Design Feedback Workshops are conducted with the end users who provided input into the system design.  Once the functional teams have incorporated these design suggestions into the system, hold a workshop where you show the completed design to the end users.  This gives them an opportunity to tell the team if the design meets their expectations.  You may also find that once they see the design, it helps them better understand the system and helps them identify new or better refined design points.


Partnering with Project Management
Phase Kick-off/Lessons Learned: In the Analyze Phase, I talked about the need for a project kick-off.  As the project continues, it's important to conduct phase kick-offs, as well.  These help ensure that everyone on the project team understands the timeline, objectives, and activities for the upcoming phase.  The kick-off is also a good time to conduct a lessons learned session.  For more details on connecting an effective lessons learned session, read this earlier post.

Sponsorship:  How involved Project Management wants to be in Sponsorship is something you'll need to work out on each project.  I have typically found, however, that working with the Sponsors tends to be a joint effort.  If your Sponsors haven't been overly involved up to this point, now is the time to help them become active.  Work with the Sponsors to determine how much direction they want/need, their expectations of their role as a Sponsor, and the project's expectations of their role.  It is important for them to understand that their commitment to providing active, visible sponsorship directly impacts the success of the project.

Partnering with Human Resources: Throughout the project, there will be activities that are best completed in partnership with Human Resources (HR).  These are activities that impact people's job descriptions, compensation, or team structures.  If you are ever in doubt, it's a wise idea to find out who is the project's HR representative and have a quick chat with them.

Rewards and Recognition:  If there are people on the project team who are not consultants, chances are that being on the project is requiring them to learn new skills, work longer hours, and take on additional responsibilities.  These are things that should be recognized and rewarded.  Work with HR to determine how the project team can do this within the appropriate guidelines of the organization.  I've seen programs as simple as a Thank You Box, and as complex as a new bonus structure.  Whichever path you take, make sure that you are rewarding behaviors you want to perpetuate, and providing rewards that are meaningful to the recipients and in-line with company policy.


The Design Phase is a busy one, but it's also very satisfying.  Don't forget to evaluate how successful the Change program is in achieving its goals, and don't be afraid to tweak the plan as you go to improve your results.

Let me know:  How many people have you typically had on the Change Management team during the Design Phase?

Change Management in the Project Lifecycle: Plan Phase

On to the Plan Phase.  This phase can be slightly frustrating for Change Managers, because so many of the activities we do are dependent on the activities conducted by the other project teams.  It's very difficult to plan when you'll conduct training if you don't know when the system will be built and stable.  Because of this, I typically recommend that Change Managers add their team's activities to the plan after the technical and functional teams.

There's also an ongoing debate as to how much of the Change Management plan should be included in the overall work plan.  I've met a number of Project Managers who don't want to see every single planned communication cluttering up their work plan.  

Here's my recommendation.  It's good to have as much of the Change plan in the overall project plan as possible, so that the integration between the teams is clearly visible.  The functional and technical teams should understand how changes and delays in their activities impact Change Management activities.  If that's not possible, however, the project work plan should at a minimum include Change Management milestones and the activities that are most impacted by other teams, such as training development.

If the Project Manager doesn't want any Change activities in the overall project work plan, you have bigger problems on your hands, and I suggest you set up a meeting immediately to discuss.

But enough of the introduction.  It's time to discuss:

Practical Steps to Develop a Change Management Plan

Training:  Training is perhaps the most critical Change activity to plan well.  You may not know exactly how many training courses you're going to develop or how many people you're going to train, but here are a few guidelines to get you started.  (A quick disclaimer that will apply to the rest of the post: Work plans are living documents.  You will constantly need to go back to update and refine your plan as you get new information. )

• Build some time for training into the Analyze, Design, and Build phases.  Training developers who spend some time in business requirement meetings, system demonstrations, and testing will be better prepared to develop training...and will reduce the amount of time required from Business Analysts.
• The industry standard for the time required to develop training is this: It takes 40 hours of development time to create 1 hour of classroom training.  It takes 200 hours of development time to create 1 hour of fully interactive computer-based training.  Everything else falls somewhere in between.
• The level of expertise of the people developing training impacts the amount of time they require for development.  Take this into consideration.
• During training development, Business Analysts should expect to devote 10% of their time to working with the training team.  This is extremely important and often overlooked.
• For training delivery, assume that for the first time someone delivers a course, they will need 1 hour of preparation time for every 1 hour of training they are delivering.
• During training delivery, the technical team needs to devote a portion of their time to addressing technical issues and performing activities such as training instance refreshes.
• Training doesn't end at Go-live.  There will be people who need to be trained in the 1 - 4 weeks after the system is implemented.  Plan to have one or two team members stay around to deliver this training.

Communications:  Although you might not know exactly what communications you need to send each week throughout the project, assume that you will be busiest starting about a month before training delivery and lasting until about a week after Go-live.  Also consider how many people will be impacted by the project and how geographically diverse they are.  Finally, talk to your leadership about their expectations for communications.  I had one client who wanted marching bands and giveaways.  I had another client who thought it was excessive when I wanted to send out training reminders.

Change Management:  Change Management is more than just training and communications.  As appropriate for your project, build into your plan activities such as Super User Networks, Executive Sponsorship activities, Stakeholder Management tasks, Change Readiness Assessments, and Change Impact Assessments.

Project Management:  Now is the time to have a frank conversation with the Project Manager about where you want to draw the line (or not) between Change Management and Project Management activities.  This is an ongoing debate that I won't address here.  Suffice it to say that you should determine what will work for your project and plan accordingly.  Discuss who will conduct activities such as project and phase kick-offs, lessons learned sessions, and presentation development and delivery for Sponsors.  These activities take a lot of time, and it's important to know who will be responsible for them.

Administrative Tasks:  Finally, if you've planned all of these activities and they will require every second of every day for every Change Management team member, you need to stop and re-evaluate.  First, remember that everyone needs a bathroom break at some point.  Second, keep in mind that unexpected activities will arise and you need the flexibility to absorb those that fall to Change Management.  Third, you need to build in time for administrative tasks.  They may not be high on your list of fun things to do, but you still need to take the time to update your work plan, review and approve work done by other people, and attend meetings.  If you forget to plan in time for these activities, you will quickly find yourself falling behind or working a lot of overtime.  I've heard people say that a good rule of thumb is to expect administrative tasks to consume 10% of your work hours.  Unfortunately, I find it tends to be more.

Contingency:  Most projects build some amount of contingency into their work plans.  It never hurts to build a little into your team's plan, as well.

A final note:  One of my favorite phrases comes from the world of SCUBA...Plan your dive.  Dive your plan.  Finding the right balance between this philosophy and being flexible enough to roll with the punches that are part of any project is the true test of anyone responsible for managing part of a project plan.

Let me know:  How much time do you devote to administrative tasks each week?

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.

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?