Please note that this blog is no longer active. For the most recent insights on Change Management, strategy, and people, please go to www.parkourconsulting.com.

Tuesday, February 7, 2012

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?

No comments:

Post a Comment