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: Analyze Phase

You've made your plan, now it's time to put it in motion.  During this phase, your activities will fall into three different categories:

1. Activities you do purely as a Change Management team
2. Activities you do in partnership with the Project Management team
3. Activities you do in partnership with the Functional teams

There may be some debate about which team actually owns each of these activities.  If so, I suggest you hash it out and develop a RACI.  This is a chart that clearly identifies for each activity who is Responsible, Accountable, Consulted, and Informed.  It will save you a lot of headache throughout the project.

Practical Activities in the Analyze Phase

• Change Management Activities: The Change Management Activities you complete in this phase set the stage for future phases.
• Project Branding - Branding your project makes it instantly recognizable to people in your organization.  This can include a catchy project name, logo, and tag line.  I've even been on projects that have colors, mascots, and songs.  Be as creative as you want...just make sure it fits with your company's culture.
• Communications Analysis - The Communications Analysis looks at what messages you need to send, who should send them, who should receive them, and what vehicles are currently available.  It also takes into account message timing, frequency, and high-level content.  Once you have this information, you can determine where there are gaps and work to fill them.
• Initial Training Analysis  - Training typically runs half a phase behind the project, which means that you won't begin your initial training analysis until the Analyze Phase is half-way over.  At this point you are simply determining basic facts, such as the number of people to be trained, their geographic location, and a rough feel for the amount and type of training that will be needed.
• Partner with Project Management: These activities address the internal workings of the project team. I have seen them completed by the Project Management team on some projects and by the Change Management team on others.  I have found, however, that you get the best results when the two teams collaborate.
• Project Governance and Escalation - Who has the right to make project decisions?  Who will weigh in on these decisions?  If the people assigned to make the decision are unwilling or unable to decide, to whom is the decision escalated?  Who is able to remove roadblocks and help the team overcome obstacles?  These are the types of questions that are answered as part of developing the Project Governance and Escalation plan.
• Project Standards - Most projects are made up of people from different departments, experience levels, backgrounds, and even companies.  To ensure that they project a united and professional image to the organization, you should set project standards.  These can include PowerPoint and Word templates, guidelines on how to run meetings, and processes for getting external communications approved.
• Project Kick-off - It is never safe to assume that everyone on the project is on the same page.  Use the project kick-off to acquaint everyone with the project's goals, team structure, timeline, near-term activities, and anything else for which you want them to have a shared understanding.
• Partner with the Functional Teams: The functional teams are the "business" teams.  They are the ones gathering business requirements, developing business processes, and generally working to ensure the new product meets the business' needs.  
• Requirements Gathering - Gathering business requirements often involves creating presentations and conducting workshops.  The functional teams are often happy to have the Change team lend a hand polishing presentations and facilitating workshops.  Facilitating the workshops, especially, frees up the functional team's resources to focus on what the end users are trying to explain about their business needs.
• External Communications - Working in partnership with the functional teams when they need to send communications outside of the project team helps to ensure consistent messages are being sent to the organization.  It also allows the Change team to understand which audiences have received which messages, reducing the likelihood of redundant communications.

Let me know: How have you effectively collaborated with the other project teams during the Analyze Phase?

The Negative Impact of Ghosting Hours

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

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

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

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

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

Five Dangers of Ghosting Hours

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

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