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:
No comments:
Post a Comment