The Change Control Myth

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 that new project managers receive is increasing, and I am glad that they are learning that change can derail a project; however, new PMs 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 behaviors.

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 organization 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 realizing that the product or service that 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, realizing that we cannot “control” most of these types of changes, we need to find a way to make sure that 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 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 prioritized list of project scope items that can be easily updated and reprioritized 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 signoff 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 project managed with empirical methods. Empirical methods recognize 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 www.AgilePM.com.