How Your Sales Approach is Hurting Your Business

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

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

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

The Consequences

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

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

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

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

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

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

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

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

It sounds easy.

It is very, very hard.

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

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

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

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

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

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

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

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

Who Moved My Cheese: A Practical Application for Change Managers

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

These quick wins should be:

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

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

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

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

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

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

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

Change Management in the Project Lifecycle: Post-Project Phase

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

Wrong.

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

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

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

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

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

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

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

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

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

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

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

Change Management in the Project Lifecycle: Implement Phase

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

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

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

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

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

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

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

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

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

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

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

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

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

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?