To be successful, project teams must do many things well, such as enabling strong communication, provide well-documented objectives, and ensure clearly defined roles and responsiblities exist. Similarly, there are dozens of reasons leading to project failure (Young, 2021). Undoubtedly, poor change control is one of them. This scientific essay is volume one in a 4-part series of articles providing a detailed analysis of why projects continue to fail miserably. Accordingly, this article studies change management and control within the project management context. It will be argued that implementing best-in-class change management processes is one of the best defences against repeated project failures. Conversely, failure of the project team to deploy and follow sound change control principles is a direct link to project collapse.
Research question: In What Way Is Poor Change Management A Primary Reason Projects Fail?
This scholarly article provides an analysis of why projects fail in relation to poor change management. It is assumed the reader already possesses at least a basic understanding of projects and project management; therefore, no background discussion on defining what is a project or what constitutes project failure is presented.
With respect to change management and control, this paper asserts that it is an under-appreciated component of project success or failure. That is, a project that has rigorous change control practices in place significantly reduces the risk of project failure; conversely, those projects that take change control for granted, or otherwise minimize its importance, do so at their own peril, risking project failure. Therefore, this article demonstrates conclusively that poor change management is tantamount to project failure.
Change is inevitable in life. It is the only constant. Of course, project management is no exception. In fact, given the complexities involved in many projects, it is not only prudent to incorporate a good change management process, but it can often mean the difference between project success and failure. Project change management is a specific process whereby changes are identified, proposed, reviewed, and scheduled in order to meet the requirements of the project. As Jason Westland from ProjectManager.com eloquently asserts, ’…change management is a methodology used to manage any change requests that impact the baseline of the project. It’s a way to capture that change from the point where it’s been identified through every step of the project lifecycle. That includes evaluating the request and then approving, rejecting or deferring it.‘ (Westland, 2020). In other words, when a change is needed within the project, the best way to minimize any potential negative consequences of the change on the organization, or its customers, is to control its development and implementation – hence, change control.
A common, real-world example is a change in project scope. For instance, if the initial, approved scope (or set of deliverables) of a project is to produce 10 widgets, but half-way through the project‘s execution a key stakeholder requests 14 widgets instead of the original baseline of 10. This is not an insignificant alteration to the original intent, or scope, of the project – known as scope creep. It, therefore, requires the project team to review and assess the impact of this scope change upon the project’s budget, its human resources, the schedule, and the quality of the widgets produced. Upon presenting the impact analysis of the scope change to the project sponsor, a decision is made to either accept, reject or defer the change to a later date. This simple illustration highlights the reason for a strong change management process, because the absence of which is disastrous for the project. Notice, for example, the close relationship scope has with schedule, time, quality and cost (among others). A significant change in one of these attributes necessarily forces a change to the others. This is because more work is now being asked of the project team to deliver, which was not part of the forecast or estimates when the project was originally created.
Moreover, imagine if poor change management practices existed in this scenario. It is conceivable that the project manager would merely accept the request of the scope change, doing her best to implement the change without going through the necessary guardrails to protect the project against failure, in a desperate attempt to please the stakeholder. But doing so has severe consequences.
Below is a table of likely potential negative ramifications of poor change control when scope creep arises – potentially leading to project failure.
Table 1 (Young, 2022)
Impact of scope creep where poor change management practices exist
# | Change to… | Impact of scope change |
1 | budget | If the project team proceeds with the change without proper change controls, there is no way to know if there is sufficient funds to cover the cost of the extra work required |
2 | schedule | If the project team proceeds with the change without proper change controls, there is no way to know if the project will still be delivered on time |
3 | quality | If the project team proceeds with the change without proper change controls, there is no way to know if the widgets produced will meet the testing and quality standards expected by the stakeholders and consumers |
4 | resources | If the project team proceeds with the change without proper change controls, there is no way to know if there are sufficient human or material resources to excute the additional work |
5 | enterprise | If the project team proceeds with the change without proper change controls and approval by an enterprise change advisory board (CAB), there is no way to know if the extra work negatively impacts other areas or departments within the organization |
6 | morale | If the project team proceeds with the change without proper change controls, there is no way to know the potential harmful impact upon the psychology or mental health of the project team members, such as stress, de-motivation, overwork, anxiety, and other behavioral considerations |
Note: any one of these impacts can cause a project to fail
As table 1 makes clear, the inability of the project team to manage one simple change in scope from 10 widgets to 14, can have wide-spread, disastrous implications, easily leading to complete project failure – hence demonstrating the importance of a good change management process. In the next section, a detailed analysis of project change management is performed.
When projects need to make changes, this is referred to as a request for change (RFC), or simply change request (CR). There are two types of change requests, an emergency change or a normal change. An emergency change is required when the urgency or severity associated with the change is high, or when the impact upon the business is significant if the change is not made. It is not uncommon that an issue (or emergency) will occur as a result of the action of the project itself.
A good example of an emergency change is when the project implements a software upgrade; but the impact of the upgrade caused an unexpected outage on the entire enterprise and, more importantly, negatively affected the external customer. Consider this scenario within a bank, whereby a presumably simple, planned annual software upgrade causes all automatic teller machines (ATMs) across the country to malfunction, such that no consumer can withdraw money from their bank machine. Clearly, the impact to the consumer, the bank‘s reputation and credibility, including potential legal exposure, is massive. This calls for an emergency change to fix the software bug issue immediately, as every second that goes by where bank customers cannot access their funds poses a significant risk to the bank for many reasons.
A normal change, on the other hand, is usually planned and scheduled well ahead of time (could be weeks or even months) in order to mitigate any potential negative impact to the business. An example of a normal change by a project occurs during the regular process of promoting newly developed code to the production environment. That is, as part of the project quality control process, once the code is developed it must be tested in the quality assurance (QA) environment. When the code passes QA and is deemed of sufficiently good quality, it is then promoted to the production environment, whereby it is released and available to the end-user customer. Therefore, a normal change is requested and scheduled that must approve the promotion of the code from QA to production.
The purpose of these two types of changes, therefore, is ultimately to manage, control and mitigate any potential negative repercussions to the business, and especially to the external consumer. To be sure, a poorly managed change control process, that causes huge enterprise or customer impact, can kill a project. A project sponsor will think twice about continuing to fund a project that regularly requests emergency changes because this signals poor planning and poor project management by the project leader. No executive will tolerate for long the existence of significant risks to the consumer and the enterprise due to poor project change control measures. The following section describes the 5-step process projects typically use to mitigate any potential negative consequences of their changes.
Organizations serious about controlling their changes to reduce enterprise and customer risk apply rigorous change management practices. A company that fails to take change management seriously is flirting with danger, and is a leading cause of why projects fail (Young, 2022). Typically, depending on the sophistication of the organization, a good change control system includes 5 steps, to be executed in order, and discussed below.
Step 1: Request for Change
Once a reason has been identified that a change is required, the project manager submits a formal request for change (RFC). This is a form commonly submitted online through a ticketing system, such as ServiceNow. The purpose is to record the project’s request that a change is asked, and assign a ticket number for tracking and monitoring.
Step 2: Plan & Document the Change
Upon submission of the RFC, the project team must prepare the details of the proposed change for formal review and approval. A typical change request plan includes many details such as, but not limited to, the proposed date of the change, why it is needed, who is executing the change, what the risk is to the business if the change in not done, how long will the change take (change window), what’s the backout plan if the change fails, and so on. This level of rigour is a strong mitigation against any negative impacts the change might have on the enterprise.
Step 3: Evaluate & Review the Change Request
At this stage of the change control process, the details of the change plan submitted by the project manager are reviewed and scrutinized by a panel of change and business unit subject matter experts, the purpose of which is to assign a severity and risk impact assessment of the change – high, medium, or low – and to either approve, reject, or defer the change to a later, less risky date. This panel is referred to as the change advisory board (CAB). Certainly, a high risk, high impact change will undergo a much more severe vetting than a low impact, low risk change, in order to protect the company from the impact of a failed change.
Step 4: Implement the Change
If the change is rejected for any number of reasons, such as being too risky, no further action can be taken by the project team. The change request is dead. If the change request is approved, however, the project team may proceed to deploy the scheduled change, as per the implementation plan. All the necessary resources are assigned and trained to ensure a successful change.
Step 5: Monitor the Change
Indeed, deploying the change does not mean the change was successful. In fact, it’s very possible to execute the change as per the implementation plan, yet still be a failed change. It does not guarantee the change plan is without flaws, possibly impacting the business in unforeseen ways. Hence, the results of the deployment must be monitored and verified by the business as meeting their expectations and not impacting their operations. This is commonly known as post-implementation validation. Depending on the complexity and impact of the change, this monitoring period may be days or weeks. Often the best determination of a successful change is the call volumes to the help desk after the change is made. In other words, if the change was executed on the weekend, the effects of the change won’t be truly realized until users login on Monday morning. If there is no spike in calls to the help desk after the change, it is a good indicator that all went as planned. Figure 1 below illustrates a strong change control process typically used by organizations.
Figure 1
5-Step Change Control Process (Young, 2022)
Note: 5-Step change control process designed to mitigate organizational risk
To be sure, this 5-step change control process is designed to accomplish a couple important organizational objectives. The first is to reduce, mitigate, and preferably eliminate any negative risk to the business as a result of the change, such as an unintended outage. But at the project level, a failed change is a stain on the project team. It may suggest the project is struggling meeting its goals without hurting the business. Moreover, too many changes, especially emergency changes, may imply too much project complexity, poor planning, poor leadership or poor execution. These are all reasons that projects fail.
The best executed projects utilize a good change control system because of the numerous benefits associated with it, such as enhanced communication, increased productivity, and improved teamwork and collaboration. The most important benefit, however, is risk mitigation.
As the research data makes clear (Young, 2021), one of the leading reasons projects fail is due to poor communication, both within the project team itself, and across the enterprise. A vigorous change management process forces good communication. This is due to the fact that the project team must formally present its request for change to CAB experts who come from different parts of the organization and therefore are aware of the change and the potential impact it may have – not just on the project, but other essential departments within the company. A common pain point associated with project management is that the project team exists in a silo, not considering the effect it has on the wider organizational community. Insufficient communication by the project team with other key partners across the organization can easily lead to project failure as these other departments may not be aware of the project’s change request, and the impact it may have on them. A good change management process, therefore, significantly improves project communication, and ultimately project success.
The same holds true for project productivity. That is, when all project-related changes must adhere to a strict change control process (reviewed, assessed for impact, planned, scheduled, communicated, and formally approved by key stakeholders) productivity is enhanced. This is so because such a process facilitates a smooth, orderly execution of changes, as opposed to an ad hoc, unplanned, haphazard approach to change management, which is both inefficient and wastefull. In short, a poor change control process is unproductive, error prone, leaving process gaps that may be missed by the project team, forcing it to duplicate work, repeat effort, wasting valuable time and resources fixing problems that would have otherwise been avoided had there been a change control system in place.
Improved teamwork and collaboration is another benefit of a strong change control process. As is well known and documented, poor teamwork is a key driver of project collapse (Young, 2021). By instituting a good change control system, the organization is forcing teams to collaborate. Certainly the project team members must come together to identify that a change is needed and why, must explain the change to project stakeholders, and most importantly, must work with all relevant partners to implement the change. An example of this type of collaboration is found in a change to user desktop software across the enterprise. In this case, the technology department must partner with all affected stakeholder communities, from human resources and marketing, to accounting and finance. The point is, change control facilitates multi-departmental collaboration, ensuring the project team doesn’t exist within its own bubble, but reaches out to sister teams within the organization.
The most important benefit provided by a strong change control system, however, is risk mitigation.
The risk of a failed change can be significant, especially if the change has a high impact across the entire enterprise, causing a massive outage for example. This type of outage affects not just the project, but presents legal, reputational, financial and consumer ramifications as well for the organization – and must be avoided at all costs. To be sure, the risk of something going terribly wrong during, or because of, a change still exists, despite the best planning. With human beings, the opportunity that a mistake is made is always present because humans are imperfect. Having said that, when there is rigour around who can make a change, when it can be made, what the impact of the change is, who else may be affected by the change, and formal approval of the change is required based on a review of a detailed implementation plan – it is clear that such strong measures are in place to reduce the risk of a failed change. Therefore, the benefits of an organization establishing and investing in a strong change management process cannot be underestimated. On the contrary, the absence of good change control can lead inexorably to project failure.
Projects fail for many reasons. A poor change management and control system is among the leading reasons projects go astray (Young, 2021). This article discusses the two types of project changes, normal and emergency, where an emergency change arises last-minute and requires an urgent remediation. The 5-step change control process is also presented, emphasizing the orderly nature and progression a change request follows, from identification to implementation. This article concludes by outlining some of the important benefits organizations realize by establishing strong change control rules, such as increased collaboration.
Arguably the most significant reason for the establishment of change controls on projects is to mitigate and, to the extent possible, prevent negative risks to the organization. As has been discussed, the risk of a failed change to the company can be serious – and the legal, financial and reputational risk involved is more than worth the investment in strong change control. To be sure then, poor change control negatively affects not just the project, but the entire enterprise.
Author: Ricardo Young
Asana, T. (June 9, 2021). What is a Change Control Process & How Do You Use It? Retrieved January 21, 2022 from https://asana.com/resources/change-control-process
Millhollan, C. (October 19, 2008). Scope Change Control: Control Your Projects Or Your Projects Will Control You! Paper presented at PMI Global Congress 2008-North America, Denver, CO. Newton Square, PA: Project Management Institute.
Project Management Institute. (2013) 3rd Edition. The Standard for Portfolio Management. Newton Square, PA.
Project Management Institute. 2013. 5th Edition. A Guide to the Project Management Body of Knowledge. Newton Square, PA.
Portfolio Strategic Management. Project Management Institute. (2013) 3rd Edition. The Standard for Portfolio Management. Newton Square, PA.
Program Strategy Alignment. Project Management Institute. (2013) 3rd Edition. The Standard for Program Management. Newton Square, PA.
Westland, J. (Oct 14, 2020). What is Change Control in Project Management? ProjectManager.com. Retrieved January 21, 2022 from https://www.projectmanager.com/blog/what-is-change-control-in-project-management
What is Change Control? (n.d.) Association for Project Management. Retrieved January 21, 2022 from https://www.apm.org.uk/resources/what-is-project-management/what-is-change-control/
What is Change Control in Project Management. (April 26, 2021). Panorama Consulting Group. Retrieved January 21, 2022 from https://www.panorama-consulting.com/change-control-in-project-management/
Young, R. (December, 2021). Why Projects Fail, Project Management in Crisis. A Comprehensive Examination of the Causes of Project Failure. Seminar Paper. LIGS University.
# | Acronym | Description |
1 | PMI | Project Management Institute |
2 | Ph.D. | Doctor of Philosophy |
3 | CAB | Change Advisory Board |
4 | PMBOK | Project Management Body of Knowledge |
5 | BAU | Business As Usual |
6 | RFC | Request For Change |
7 | CR | Change Request |
8 | CAB | Change Advisory Board |
9 | RFC | Request For Change |
10 | ATM | Automatic Teller Machine |
11 | QA | Quality Assurance |
Great insights! This blog provides wonderful strategies for keeping teams connected. I’ve also explored related themes in an ultimate guide on IT staff augmentation on my site, which might add depth to this discussion. I’d appreciate your thoughts!
https://medium.com/@mukesh.ram/how-to-overcome-laravel-remote-team-disconnection-38addf8285c9