Project Smart ~ Exploring trends and developments in project management today

Calendar icon
Adobe PDF icon

The Change Control Myth

~ By Kevin Aguanno

Myth grunge rubber stamp on a white background

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


Comments

Be the first to comment on this article.

Add a comment



(never displayed)



 
2000
Enter the third letter of the word house.
Notify me of new comments via email.
Remember my form inputs on this computer.

Seven Key Principles of Project Management

Hand holding a key with success written on the fob

If you're looking for guidance to help you manage your project with added confidence, then this article will help you.

Project Plans: 10 Essential Elements

Four colourful tags spelling the word plan

A project plan is more than just a Gantt chart, but do you know what you must have in your plan? This article takes you through the ten essential elements.

How to Build a High-Performance Project Team

Business people and bar graph going upwards

What makes a winning project team? Why do some teams achieve greatness while others struggle? Let's look at the factors present on winning project teams.

12 Tips for Accurate Project Estimating

Money and a calculator

Using a set of proactive estimating techniques to scope, plan and constrain your project conditions can dramatically improve your estimating practices.

PROJECT SMART is the project management resource that helps managers at all levels improve their performance. We provide an important knowledge base for those involved in managing projects of all kinds. With weekly exclusive updates, we keep you in touch with the latest project management thinking.

WE ARE CONNECTED ~ Follow us on social media to get regular updates and opinion on what's happening in the world of project management.


Latest Comments

Joseph Marandus commented on…
How to Apply PRINCE2: Engaging Senior Management in Your Projects
- Tue 21 March 1:59pm

Janine Greene commented on…
The Role of the Project Manager
- Fri 17 March 1:30pm

Ben commented on…
The Role of the Project Manager
- Sun 12 March 12:30pm

Latest tweets

General Project Management • No Sponsor https://t.co/ii52CgAiCs #projectsmart #pmot about 7 days ago

General Project Management • Re: Software Product Delivery Plan for an Agile project https://t.co/v8ondVdaME #projectsmart #pmot about 7 days ago

General Project Management • Re: How do you track who from your human resources have related… https://t.co/QzAyOJ27cp #projectsmart #pmot about 8 days ago