This is part deux of Celedon Partners’ series: Why Do Projects Fail? In my first blog, I focused on the criticality of proper project planning in ensuring project success. You can find that post here. The current blog will focus on how (im)proper change management can make or break your project. A couple of statistics:
Software specialists admit 40-50% of their work is avoidable rework rather than “value-added work.”1
On average, large IT projects run 45% over budget2
17% of IT projects progress so poorly that they “threaten the very existence of the company.”2
Project change is almost unavoidable. Projects change because of shifting business needs, political pressure, missed requirements, identified defects, etc. Managing this inevitable change and its impact is a critical part of project success. Change is not a ‘bad’ thing in itself, but improper management of that change is a common failure point. The management of change is defined, during, gulp, proper project planning – curses – planning strikes again! When suggested changes to scope, cost, quality, etc. arise, they must be assessed according to the plans established during planning. Changes can be denied or accepted and baselines are updated accordingly.
Successful projects don’t react to change, they address change according to their plan.
Large IT projects fail due to unclear objectives, shifting requirements, unrealistic schedule, and reactive planning five times more often than due to project team or technical skill issues.
Stated differently – incomplete planning and poor change management impede project success far more often than team dynamic or technical obstacles.
Author Paul Gibbons states, “Most businesses would profit greatly from just applying Change Management 101 well.” Often when people hear the phrase ‘change management’ they think traditional project management and waterfall development. The waterfall SDLC is often bashed as “antiquated” and “outdated.” But even in the “evolved” agile SDLC, change management occurs constantly. If it doesn’t, the project’s success is at risk.
Regardless of the development approach, successful projects identify:
- Who can offer change ideas (informally and formally)
- Who assesses the impact of the proposed change (yes, the impact must be understood!)
- Who reviews the proposed change and its impact for approval (Change Control Board? Product Owner?)
- How is the change implemented (this is where the SLDC becomes most relevant)
- Documentation of the outcome (memories fade, staff changes. Why go through this twice?)
Projects are made of people, and people resist change. It’s in our nature. Change means something different is going to happen. And even if that something is good, it is unknown and therefore a possible threat. Sticking with what we know, even if it is not working well, is less stressful than the unknown. Resistance to change occurs in our personal lives, at corporate levels, and in our projects.
A resistant project team can harm a project if change is not explained, agreed upon or understood. Merely having a change management plan, reduces resistance to change. Actually using the plan increases the likelihood your project will succeed. That is, investigating a proposed change and explaining its impact on the project’s schedule, budget, scope, etc. significantly increases understanding of a change and the project team’s acceptance of it.
Mature project management recognizes change management is essential to project success. There are several maturity models that describe the degree of maturity of an organization or project with regard to the formality and optimization of its project management processes. The Berkeley PM Process Maturity Model defines an organization’s maturity and helps them gain higher maturity and more sophisticated project management by a systematic and incremental approach.
Similarly, the Capability Maturity Model (CMM) is a model based on data collected specifically from software development DoD-contracted organizations. While it originated in information technology, the CMM, like the Berkeley Model, can be used to describe maturity across industries.
Gibson, et al (2006) found a clear correlation between the maturity level of an organization and the amount of time it spent on project rework (see table below). Another study done at Raytheon (adapted from Haley, 1996) found as much as 41% of a project’s cost is attributable to rework done by a CMM level 1 company, as opposed to 18% at level 2, 11% at level 3, and 6% at level 4.
It’s clear from these data that customers should demand high quality project management and procedurally-mature organizations as they choose their consulting partners.
This is an important step in keeping change, and therefore, costs, schedule, and quality, in check, all of which are necessary to achieve project success.
Please leave comments, we’d love to hear from you. And look for my next post in this series focusing on why Engaging Stakeholders throughout a project is crucial to project success.
1: Charette, RN (2005) Why software fails. IEEE Spectrum, Vol 42 Issue 9.
2: Bloch, M, Blumberg, S, and Laartz, J (Fall 2012) Delivering large-scale IT projects on time, on budget, and on value. McKinsey on Business Technology, Number 27.
3: Gibson, DL, Goldenson, DR, and Kost, K (2006). Performance results of CMMI-based process improvement. Technical Report (Carnegie Mellon University/Software Engineering Institute 2006-TR-004. ESC-TR-2006-004).