Project Manager's Spotlight on Change Management

Claudia M. Baca

• Publisher: Jossey-Bass
• Year: 2010
• Print ISBN: 9780782144109
• eBook ISBN: 9781118000212
• Edition: 1
• Topic: Business
• Subtopic: Management
• Index: Business

Clear-Cut Ways to Manage Inevitable Project Changes

If you're a typical project manager, you're probably aware of the importance of change management but may not have the time or expertise to develop a full-blown plan. Here's a quick and practical guide to applying the disciplines of proven change management practices without the rigor of complex processes.

Part of the Project Manager's Spotlight series from Harbor Light Press, this straightforward book offers solutions to real-life project change scenarios. Author Claudia Baca highlights critical components of change control and equips you with tools, techniques, checklists, and templates you can put to use immediately. By following a realistic case study from start to finish, you'll see how a project manager deals with each concept. Ultimately, this book will help you establish effective guidelines for dealing with change and provide you the flexibility to minimize disruptions and derailments.

Project Manager's Spotlight on Change Management teaches you how to:

• Define roles and responsibilities of the change management team
• Build a process flow one step at a time
• Design your own change management system
• Process exceptions and escalations
• Create the necessary documentation

CHAPTER 1

Managing Project Change

A mysterious element affects every project and yet it is not often planned for. What is this phenomenon? Some call it Murphy’s Law. Some call it scope creep. Some call it change. Whatever you call it, you can employ tools and techniques to help you manage it to the benefit of your project. This book provides you with the ins and outs of successful change management.

I start this chapter by relating the basics of change management. I then cover the definition of and the purpose of change management. Following this, I explain some of the common terms used in change management as well as how change management is referenced in generally accepted project management principles. Lastly, I talk about project and product lifecycles.

At the conclusion of this chapter, I introduce a case study that you can follow throughout the book. You’ll get a chance to witness a project manager deal with the concepts I introduce in each chapter.

Change Management Defined

Change is inevitable and most of us project managers deal with more than our share of it on our projects. Most of us tend to think of change in terms of problems or negative consequences. Although it’s true that change can be bad, it can also be good.

For example, think of a project at a major manufacturing plant. This plant hires a consulting firm to help design a new product. Halfway through the construction process, the plant requests a set of changes, but because they just asked for more product functionality, they are willing to spend more money. In this case, I bet the consulting company loves change.

Right now, you might be asking yourself why this last example constituted a change. It’s time to clarify what I mean when I refer to change management and get clear about what change management is or, as it’s sometimes called, change control.

How would you define change management? First let me explain that there are really three different elements to change management.

1. The first element of change management deals with the authority level of the project manager. You need to make sure that you have the authority to approve and deny changes that impact your project.

2. The second element of change management involves setting up an environment that fosters good change management. You need to communicate with the entire project team to set expectations on how changes on the project are to be handled.

3. The third element of change management involves setting up a system that helps you determine that a change has been requested. This system also helps you decide if you should make the change and allows you to track the change regardless of whether it is approved or denied. This system should also be comprehensive enough allow for exceptions like the following: What do you do with escalations? How do you handle people who won’t follow the rules? and so on.

If you take these three elements into account, you could define change management as the proactive identification and management of modifications to your project.

Why Bother with Change Management?

I’ve known a couple of project managers who did not bother to set up a change management system on their projects. The first was barraged with requests from the client organization. She accepted all of the requests believing that she was keeping the client happy. Her good intentions actually kept her from delivering on time and within budget—she was about six months late and well over budget. When the project was complete, she had to review all of the project’s problems in a project review meeting. This turned out to be grueling. It was determined by her senior management that her project management style was too loose and amiable. She was banned from managing projects of that magnitude again until she improved her results. Instead of being a hero, she ended up with a letter of reprimand in her personnel file.

The other project manager also decided that he did not need a change management process. Instead he just said no to every change that came his way. He was about four months into his project before the company replaced him. The clients and team members found him hard to work with and thought he was more concerned with finishing the project than making sure that the project he delivered was the right product for the company.

I know these examples really depict the ultimate extremes of the change management spectrum—there are millions of situations in between these. What typically happens to a project manager may simply be the result of not taking a change seriously. For instance, the project manager may approve a small change that ends up slipping the end date of the project. Without good change management in place, you are depending on luck, overtime, and your own personal power to deliver the project. In the end, you may end up drawing on all of these anyway, but you only want to use them when you have an emergency, not because you failed to plan for changes.

The bottom line then is that change is one of those necessary evils you must manage and manage well if you want to deliver on time, on budget, and with the quality defined by the client. Now let’s move on and talk some more about change management definitions.

NOTE Managing project changes well leads to projects that are on time, on budget, and within defined quality guidelines.

Let’s Set Some Context

You may not be familiar with the term change management. Instead, you may have seen the terms change control, change management system, and so on. Well, they all mean the same thing—the process that is used to control project changes.

Change management is an integral part of the generally accepted principles covered in the PMBOK Guide . If you need a refresher on the project management processes and knowledge areas, refer to Appendix A of this book.

If you check the glossary of this guide you will not find the term change management. This is because change management is a widely known term in the project management field that refers to the overarching system that manages change (system here means an assemblage of processes, forms, and possibly software). You will, however, find the term control used throughout the PMBOK Guide and defined in its glossary. You’ll also find the term change control in the five major project management process groups as well as mentioned in several of the project management knowledge areas.

Table 1.1 shows the intersection between processes and the knowledge areas; this highlights the areas concerned with change management. You’ll also find this diagram in Appendix B for your future use.

You’ll notice that Table 1.1 shows the abbreviation T&T. This stands for Tool and Technique. That phrase is used in the PMBOK Guide to denote a commonly accepted practice that is used in a process to get the results you are expecting. Change management is just that—a tool that you use to manage change.

NOTE In case you are new to project management, check out the ANSI standard on project management, A Guide to the Project Management Body of Knowledge, 2000 Edition, by the Project Management Institute. www.pmi.org

TABLE 1.1: Project processes, knowledge areas, the emphasis on change management

The Controlling Processes

After reviewing Appendix A, you know that there are five major process groups executed during a project. In real life, Project Managers use these process groups to successfully start a project, plot the project activities, direct the project activities while they are being performed, and finally, complete the project. We undertake projects to satisfy the goals that the stakeholders determined during the project initiation.

That fourth process group, controlling processes, relates directly to our work here in change management. This controlling process group is concerned with monitoring and regulating the activities of the project to ensure that the goals of the project are met. This monitoring and regulating produces information that you can measure to see what variances have occurred. Once you understand that variances have occurred, you can take corrective action to keep your project on track to meet the project’s objectives. We will set up our change management system in this book using these fundamentals of the controlling process group.

Within the controlling process group, you’ll find four specific processes that each touch on a subject area concerning change management. Let’s look at each of these subject areas:

Scope When you are determining the scope of the project, you take the goals and objectives the stakeholders determine and transform them into a scope document.

The word transform is sometimes used interchangeably with the term progressive elaboration. Basically you take a concept and build upon it to create a project that delivers what the client requested.

At the beginning of the project, you take the objectives of the clients and build upon those objectives to create a scope statement. This scope statement should lay out exactly what the point of the project is. Most of the time, this statement is created in broad terms that can act as a litmus test for those creating the product of the project. The scope statement also sets the basis for future project decisions—a place to compare back to so you can determine what is in scope and out of scope.

An effective way to determine the scope is to define both what is included and what is excluded in your project. Imagine that you are on a project where a handheld device is being created to speed appointment information to a telephone installer. Your scope statement might say, “The device must weigh less than two pounds.” This is an inclusive statement. Another way to be clear about the intention of the handheld device might be an exclusion statement such as this: “The handheld device cannot have wires connecting it to any device or power source.” In this statement, you make it clear that the product must be lightweight and completely portable.

When creating the scope of the project, you need a process to control the scope once it has been set. Its purpose is to manage any changes to the project’s scope. This process is really what I spend the rest of this book talking about. In essence, I am referring to the change management of the scope statement.

NOTE A scope statement documents what is included in the project and sets the basis for future project decisions.

Time When you are determining how long a project will take, you are working with the subject area of time. This area concerns the processes that ensures that the project is completed in the agreed-upon timeframe.

In this set of processes, you determine what tasks need to be completed and in what sequence. You then determine what the duration is for each task of the project. If you add up the duration for each task along the critical path, you can then determine the schedule for the project. The schedule sets the basis for future project decisions regarding the timing of the project. It provides you with a place to compare back to to determine where the project should be at any point in time.

When the schedule is set, you need to cont...

Table of contents

• About the Author
• Title Page
• Copyright Page
• Dedication
• Foreword
• Acknowledgments
• Introduction
• CHAPTER 1 - Managing Project Change
• CHAPTER 2 - Setting Up for Success
• CHAPTER 3 - The Process of Change Management
• CHAPTER 4 - The Output of Change Management
• CHAPTER 5 - The Incremental Effect
• CHAPTER 6 - Change Tracking
• APPENDIX A - Nine Knowledge Areas Refresher
• APPENDIX B - Change Management Templates
• APPENDIX C - Calculating the Critical Path
• Glossary
• Index