Change Management in the Project Lifecycle: Pre-project Phase

In my last post, I provided an overview of the eight basic phases that make up the project lifecycle.  Now it's time to dive in and look at how Change Management fits into each of these phases.  Please note that I won't be able to include every single Change activity that could happen in a phase.  That would turn this into a text book rather than a blog post.  I will cover the major activities, though, and if you include them in your plan you will be off to a great start.

Let's get detailed.

Practical Change Management Activities in the Pre-Project Phase

Unfortunately, I often see Change Management - and Change Managers - left out of the Pre-project phase.  Because many people think of Change Management as just communications and training, they assume that they don't need to worry about it until later in the project.  This is a great way to doom the Change program before it even begins.

If you're going to be the Change Manager, now is the time to speak up and jump into the fray.  You need to ensure that the following items are given serious consideration by your organization's leadership...and included in the overall scope of the project:

• If you're partnering with a consulting firm, at least one consultant should be a Change Manager.
• Just because they agree to have a Change Management consultant doesn't mean they can remove you from the project.  At least one person from the organization needs to be a full-time Change Manager, as well.
• Change Management needs its own budget.  Activities involved in communications, training, Super User Networks, etc. can add up.  While there are lots of ways to do it on the cheap, for the most part, you get what you pay for.  If leadership hesitates, show them this fact from IBM's Making Change Work study: "Our study found that project success rates were 23% higher when the amount invested in change was greater than 11% of the project budget."
• If it's a technology project, training should be included in the technology budget.  Training development uses a lot of server space, and you need to consider if your company has a Learning Management System (LMS) available to host any computer-based training courses.
• Make sure that the number of Change Management team members is commensurate with the amount of Change Management work.  Very few change programs can be fully executed by one person.

If you're brought onto a project in a later phase and discover that these items weren't taken into consideration, never fear.  There are ways to address this, which I'll cover in a future post.

Let me know: In your experience, is Change Management adequately addressed in the Pre-project phase?

Change Management in the Project Lifecycle: Project Phase Overview

Forgive me, readers, for my extended absence.  I'm going to start the new year by getting extremely practical.  The next series of posts will focus on the nitty-gritty of preforming fundamental Change Management activities.  If you've been assigned to run a Change Management program but don't know where to start, these next few posts are for you.

Let's start by talking about how Change Management fits in with the overall project lifecycle (I'm assuming here that you are working on a project of some kind - technical, business process, organizational re-design etc.  I'll note that Change Management doesn't always happen in the context of a project, but for the record, I consider change for the sake of change to be a losing battle.)

Most projects have eight basic phases: Pre-project, Plan, Analyze, Design, Build, Test, Implement, and Post-project.  Different companies will use different names for the phases, and you often won't see Pre-project, Plan, or Post-project on the official project work plan, but in general, these are pretty standard.

For anyone who hasn't worked on a project before, I'll begin by providing:

A Practical Understanding of Project Phases

Pre-project: The Pre-project phase typically doesn't appear on the project work plan because, as its name suggests, it occurs before the project begins.  The team is typically very small at this phase.  They are focused on building the business case for the project, which explains the business reasons for doing the project (why do we need to do the project, what are the benefits of doing it, what are the risks of not doing it, etc.), and is often used to get approval from senior leadership to move forward with the project.  For technical projects, this phase also consists of selecting a technology and vendor.  Many companies also choose to partner with a consulting firm, which is chosen during this phase.  Usually, by the end of this phase you will have permission to do the project, vendors and partners selected, a budget, and a general time frame for the project.

Plan: As you may have guessed, during the Plan phase you create a project plan (also commonly referred to as a work plan).  This plan lays out what activities need to happen, when they need to occur, how long each activity will take, and how many people are needed to compete the activities.  Developing this plan allows you to determine how many people you will need on the team at any given time, as well as the skill sets you will need over the course of the project.  This is also the time when the general project time frame you determined during the Pre-project phase becomes more precise.  For technology projects, you will also be able to use the plan to figure out when you will need to procure physical assets, such as system licenses and extra servers.

Analyze: During the Analyze phase you will dive into requirements gathering.  This is your chance to determine exactly what your organization needs from the project.  This phase helps to ensure that the finished product meets your technology, process, and cultural needs.  Once you've gathered the requirements, this is also the time when you will do a gap analysis.  How well does your project as currently planned meet your requirements?  Any gaps will need to be addressed as part of the project, which means you will need to go back and re-assess your project plan, including budget, timing, and people resources.

Design: Now that you know your requirements, it's time to design your project to meet those needs.  For technology projects, this means designing the system.  For an organizational redesign, this means designing the new organization.  A business process project will design new processes.  (A quick note - I talk about different types of projects, but it's very common for one project to contain aspects of each of these project types.  In fact, it's best if your project has at least two of these types.)  The Design phase is often called the Blueprint phase because by the end you will have the blueprint of the project you need to create.

Build:  With your design in place, you're ready to begin the Build phase.  This is the phase where you make your design a reality.

Test:  Once you've built your project, whether it's a computer system, new business processes, or an improved organizational design, it's important to test it before rolling it out to the entire organization.  There are a number of steps involved in the Test phase, but to make it simple, by the end of this phase you should feel confident that the product you built works the way you designed it and meets the requirements you gathered.

Implement:  This is the exciting phase.  During the Implement phase you roll your project out to the organization, letting everyone see/use/participate in/experience the finished product.  By the end of this phase, most of the consultants will leave and many of the people from the organization will go back to their day-to-day jobs.  And, if you did your job well, you'll be receiving positive feedback about the product you created.

Post-project:  This phase often isn't on the project plan mostly because it often gets forgotten.  Just because the project has been implemented doesn't mean the work is done.  There are short-term activities, such as officially closing down the project, closing the budget, and immediate end-user support.  You may also have long-term activities, such as follow-up analysis of how successfully the new product is being used by the organization and continuous improvement cycles.

Now that you understand the project lifecycle, the next question is, "How does Change Management fit into each of these phases?"  In upcoming posts I'll address this question, explaining the Change Management activities typically completed in each project phase.

Let me know: