Exploring trends and developments
in project management today.
The Change Control Myth
2010
You can always spot the project managers who have just received their PMP, they are eager, idealistic, and prone to proclaim at length the necessity for "Change Control" as if it were the cure for all project management evils. Don't get me wrong, I am glad that the level of training new project managers receive is increasing, and I am glad they are learning that change can derail a project; however, new PM's appear to have a naïve view of how projects work in the real world, and I would like to do my part to correct that.
To start with, there is no such thing as change control. Yes, you read that correctly. The idea that we can control change is a myth.
I'm well into my second decade of being a PMP, and I've taught project management for almost as long as that, so I am quite familiar with what PMI tells us in the PMBOK Guide. The book is filled with the words "change control" with the phrase appearing in most chapters. Yet, if you read the description of change control, say for example in section 4.3 (Overall Change Control), you'll see that what they are really talking about is change management.
Now, I know this sounds picky, but the distinction between the words control and management is very important, the word you use can affect your thinking and drive very different behaviours.
There are many sources of change, some generated from within the project, and some generated from outside of the project. Let's look at how we should respond to these under normal circumstances.
External changes come from stakeholders and others who are not part of the core project team. Some examples of external changes could be new government regulations with which we must comply by a certain date or else face severe penalties, new corporate leadership that has a different vision/strategy for the organisation that no longer includes our project, or a competitor beating us to the marketplace with a new product that has more features at a lower cost than the one being produced by our project. In each of these cases, the project manager (even the project sponsor) will have little control over these changes, the change just happens and we have to learn to adapt to it quickly.
Internal changes come from core project team members. Sometimes we have a small measure of control over these changes, but other times, we do not. Examples of internal changes to a project could be a core project team member having to take a sudden medical leave, team members realising that the product or service they are producing or modifying is much more complicated than they at first thought, the project sponsor asking for a new feature that was forgotten during the requirements gathering phase of the project, team members suggesting changes that would greatly improve the functionality or performance of the product or service being built, or even design defects uncovered during later testing stages in the project that require the team to go back and redesign a portion of the solution, then rebuild and retest to the solution to match the updated design. Each of these internal changes can also generate significant chaos on a project if they occur without any restraint.
So, realising that we cannot "control" most of these types of change, we need to find a way to make sure unrestricted change does not completely derail any chance of our project meeting its business case. If we cannot control then we at least must manage.
Change management can be done in a number of ways, and there are many tools that have been developed to help. Traditional approaches to change management are discussed in the PMBOK Guide, including having a system of formal, documented procedures that describe how a change will be assessed and approved within the project, usually by a "Change Control Board." Other approaches used in agile management methods include having a prioritised list of project scope items that can be easily updated and reprioritised before any iteration of the project, ensuring that the team is always working on the next most important outstanding pieces of work. Of course, there is usually still a formal sign-off of this modified scope list, but the underlying concept that scope will be fluid during the project, and providing formal mechanisms for managing the dynamic scope are quite useful on high-change projects.
Perhaps the most important difference between "change control" and "change management" is one of attitude. The term "change control" is often found on projects that are being managed using deterministic planning models such as the ubiquitous "Waterfall Method" - a sequential series of gated phases within which all work must be completed before we can move through the gate to the next phase. Deterministic models try to create a "perfect plan" and then the rest of the project is spent trying to adhere to the plan. In fact, most project tracking and control metrics found on these projects are measuring how well the project is doing in relation to the plan. For example, Earned Value metrics track our variance from plan and use these metrics to try and reforecast the impact of this variance on the project end date and financial spend.
Change management is the term found most often on projects managed with empirical methods. Empirical methods recognise that there are often too many variables on a project for a project manager to control them all. These methods allow for a tolerance range for these variables, and monitors them to ensure that they stay within acceptable boundaries. In essence, these methods are accepting that there will be ongoing and frequent changes within a project and that changes are allowed, even preferred, as change helps the project deliver the optimal level of business value. Examples of empirical management methods include the agile methods Scrum, Feature-Driven Development, and Lean Development.
Lastly, the attitude of a project manager may be affected by the terminology used. Change control sets up (at least in new or junior project managers) a confrontational mindset that tends to see project managers trying to stop or discourage change, often to the annoyance of business stakeholders who are trying to adapt to a changing business environment. More senior managers tend to take a more collaborative approach towards working with the project sponsor in determining how best the project can adapt to new changes, these managers understand that the real game is one of change management not control.
Change can be good, we need change to allow us to incorporate lessons learned from earlier stages in the project; and adapt the scope, timeline and budget of the project to match evolving business needs, ensuring that we are delivering the optimum level of value to the project sponsor within our project constraints. What we need to do is manage the process of how we adapt to the changes to ensure that we are always focused on delivering this optimal level of value. It is not a perfect science, there is a lot of uncertainty and predicting the perfect answer is not possible, however, there are change management techniques that will allow us to stay responsive to internal and external changes while still keeping the project performing within acceptable parameters. As professional managers, we need to understand the range of tools and techniques available to us for both deterministic and empirical project management environments, and to know which ones to use for a given situation. Our basic project management training, and even the PMBOK Guide, is lacking in some of this sophistication. We need to begin teaching the next generation of project managers about how we respond to change in the real world, a management paradigm that works collaboratively with project stakeholders, not confrontationally. Remember: without change, many projects will surely fail. 
Kevin Aguanno is the Vice-President and Director of Professional Development for the Project Management Association of Canada. He is also the author of many published books, audiobooks and DVDs on project management related topics. Find out more about him at AgilePM 
Related Articles
Three Myths About Organisational Change
Our beliefs about what change is and how it works can influence our willingness to take on the challenge appropriately. Change agents who believe these three myths might find their initiatives stuck in a rut. If you feel like your change initiative is getting stuck, challenge these myths and look at change from a new perspective.
Using Change Management and Change Control Within a Project
Setting up a systematic and common approach to change is vital, and this article outlines the approach and steps needed for change management and hence ultimate project success. The approach taken is central to the PRINCE2 Methodology and includes a general summary drawn from PRINCE2 and several project management bodies of knowledge.
Common Project Management Mistakes: Badly Handled Changes
No matter how well a project is planned and how well the requirements are defined, there will always be requests to change something about the project, usually the product being delivered. There are good reasons for this; business doesn't stand still while your project is going on so we expect that ongoing business will trigger the need for changes to the system being built to support that business. These changes are mission critical to the project in many cases. If the system isn't changed to reflect business needs as they will be when the system is implemented, your project will succeed in building a system to support business as it was done 6 months ago!
In Defence of the Project Management "Perfect World"
One of the most common challenge questions I get when teaching PMP Exam Preparation courses is "Why doesn't PMI make the test more real-world? Why do they insist on testing for a world that no-one really lives in?" Over the years, my response to that question has evolved, but the more the question comes along, the more I realise we don't insist on the perfect world often enough.
21 Ways to Excel at Project Management
The popular project management e-book now fully updated and available as a website for the first time.
The distinction discussed above between internal and external changes is important in understanding the difference between control and management. Your statement "controlling of the changes needed to adapt to the original change, that is not under our control" makes no sense. Changes are internal or external and PMs manage them as they are foreseen or just show up on the project. I would change 4.3 in the PMBOK to Change Management instead.
Also, the PMBOK has become to large and is getting beyond a certain comfort zone it was in in its earliest beginnings. It is trying to be all things to all PMs. This is not realistic. Many professional associations allow certification test taking without training for example. If you can pay the money and pass the test you are certified, many time for sales people. This does not make one experienced or capable in the least bit, as a PM.
The underlying problem here for new project managers is that one route people use to get into project management is to go on a course, and they then think they are a qualified project manager.
Courses can be useful if you have someone who can mentor you afterwards to turn course content into real life delivery.
I agree you often meet an idealist fresh from a course who is eager to tell you the 'correct' way of doing things. Its a big red flag that says 'beginner'.
Mentoring is essential for newly 'qualified' project managers so the impact of 'picky' issues can be fully understood.
Laura
PMBOK is my favorite - I don't think it lacks is some of that sophistication. As you said - the name of the chapter is "control", but it is about the management, so it is compatible with your thinking.
I think it is about understanding of the name. The term "Change Control" can be interpreted as "controlling of the changes needed to adapt to the original change, that is not under our control". Every example of yours is compatible with this approach. We need to have the adaptation process under the control. Example: a tightrope walker must control the body and the changes in positions of limbs/spine when there is an unexpected wind blow.