CIO QUESTION OF THE WEEK
Martin Davis asks:Projects involving IT often fail due to lack of change management. What approaches have you used to ensure that a change resonates with the employees?
CIO Questions by Martin Davis, Mon, 01/28/2013 - 14:46
Joel
Dobbs
Martin, A very relevant question.
First, when you refer to “employees” I am assuming that we are talking about everyone involved including the IT staff developing the project and, most importantly, the group of people outside of IT who will use, and ultimately benefit, from the results.
It has always been my belief that a strategy and plan for managing change associated with any new initiative, whether an IT project or not, should be in integral part of the project plan. This component should be clearly owned by the project’s sponsor(s). Too often IT initiatives contain detailed plans for development, integration, testing and implementation but nothing to manage the cultural aspects of its implementation which are most often manifested as resistance to the changes needed for ultimate success.
I recommend, and use, John Kotter’s 8 step change process (Leading Change, Harvard Business School Press, 1996). Embed the 8 steps into the project plan and execute them throughout the project lifecycle. For instance, the first step, establishing a sense of urgency, is the role of the projects sponsors. They need to clearly articulate the rationale, the “burning platform, and the consequences of inaction. The second step, forming a guiding coalition, is really the interdisciplinary project team charged with making it happen. These people, from both the business and the IT side, must be chosen carefully and provided both incentives to succeed and consequences for failing to do so. The remaining steps can easily be integrated into a plan and should be treated with equal or greater importance than technical milestones.
Finally, everyone should be familiar with Kanter’s Law, “Everything looks like a failure in the middle.” One of the biggest hazards is abandoning the change agenda when problems arise and focusing only on technical things.
In all of my years in this business I have never seen an IT initiative fail because the technology didn’t work. The failure was always caused by human failure and failing to adequately plan for and manage change is one of the main culprits.
John
Gallant
This is a terrific question and one that’s always timely, sadly. For as long as there has been IT and IT has been working with employees and business leaders on projects, there have been issues regarding implementation of new systems and applications and, frankly, resistance to change. To me, the key is deep involvement and buy-in from the affected employee base. Unless business leaders and their teams are in full support of goals and initiatives – and they own the results of the change – problems likely loom ahead. IT can’t put itself in the position of being the single point of blame, when it’s really up to the business and employees to speak up for what they want/need, be active participants in the development process, and drive adoption on their end. Part of this is being really specific about the goals to be achieved and who owns the goals. Once that high-level commitment exists, there are a lot of ways to ensure adoption, from having very active team leaders on the employee side who are involved in rollout and training, to having specific plans in place to deal with the recalcitrant, let’s call them, folks along the way.
Common Sense Business Management Perspective: Focus on the Front End
Gartner published a statistic several years ago: something like "80% of all Incidents that impact production are caused by poorly managed infrastructure Changes". Wow! Expensive!
It seems common sensical from a business efficiency perspective, for CIOs to sponsor a change in the IT rewards and recognition culture, sufficient to drive a shift in focus from the back end of changes (reactive priorities on fixing things that didn't work right), to the front end of changes (planning projects, assessing potential impact, involving IT Operations in strategy and design phases and other proactive measures). This would help resolve the “shooting ourselves in the foot” situation described by the Gartner statistic. If we take a common sense historical perspective on what drives IT culture and values, the need for this change is obviously past due.*
A shift in focus to the front-end of changes to the production infrastructure would be accomplished in part, by establishing process discipline and effective process measurements in both Change Management and Incident Management. The goal would be to accurately (and honestly) track "Change Related Incidents" (Incidents caused by a Change Request).
However, true lasting change will not happen until CIOs, CEOs, all corporate leadership teams for that matter, stop visibly rewarding IT staff for being heroes (heroic efforts to resolve service-impacting Incidents). Instead, they should be asking why Incidents happened in the 1st place (e.g. holding the entire CAB accountable for Change Related Incidents). The organization as a whole must begin rewarding project teams and support groups for metrics around the reduction in change related Incidents.
Unfortunately, I am aware of only a few IT departments with both the requisites maturity level in the required processes (Change, Incident, Release and Project Management processes) and the process integration capability/maturity required to detect and measure Change Related Incidents. This I think is the real question we should be asking: What must CIOs do to be effective sponsors of change in IT department culture and values, ultimately to drive the adoption and continual improvement of effective, integrated service management process architectures?
So many attempts to embed integrated IT Service Management process have failed, and so few IT departments have had measureable success in changing the IT culture, it has become a topic to avoid in many IT Leadership venues. I picture an Ostrich with his/her head in the sand.
Change is inevitable. Where the current CIO will be in this change, depends on their capacity to drive/sponsor culture change.
* This new focus on adapting IT’s culture to support ‘technology dependence management’ is a logical maturity step for IT departments. From a historical perspective, the rush to automate all core business processes of the 2000s – 2010s has resulted in a near overwhelming increase in technology dependence. The IT culture and values that supported the “rush install, fix on the fly” period must be adapted to support the new requirement for reliable availability of technology dependent core business processes. The latter is much less sexy and 'heroic' for IT staff. This is fundamental to the challenge.
Martin,
Even though changes (whether it is IT or any business transformation related) are implemented to improve business functions, most of the time the users embrace them in different ways. As you all stated, managing the resistance is the key no matter what method is employed.
Typical example I can think of is with HBR article about Time Warner- "Jack Griffin's Ouster: Lessons from a Failed "Change Agent"". Style of leadership along with how to adapt to the nature of the change is the key to succeed. Leaders who drive these changes should be aware of and make sure they help reduce the barriers to succeed.
On the other hand, article below gives you a high-level approach to implement a change management philosophy. As the article clearly mentioned – “It is clear that a single-minded focus on today’s problems creates fatigue and resistance… But it is also clear that when it comes to behavioral change some anxiety is good”.
http://www.mckinsey.com/App_Media/Reports/Financial_Services/The_Inconvenient_Truth_About_Change_Management.pdf
John - totally agree, employee involvement as early as possible is key. Identifing the thought leaders and change agents, the people others go to for advice, and getting them bought in and involved early on acts as a major catalyst to change.
At one point in my career I had 100+ people under me with maybe 10 direct reports. Looking back, I could probably put them into three categories: the first and largest is a the category for whom change is welcomed and refreshing, so long as the parameters of the change and reasons for it are clearly articulated. The second and probably next largest category were those that were kind of on the fence - they liked the security of doing things as they had been done but fortunately we worked in an area (IT publishing) where there were numerous examples of the disasters that befall companies and individuals that just refused to change. Witness the minicomputer industry of the late 1980s and early 1990s. THe final category, and definitely the smallest, were the hopelessly change averse people. Eventually I just moved them along because they had the potential to really poison the well. It wasn't Draconian. It was just the right thing to do for the organization, for the rest of the staff, and ultimately for the change-resistant people too.
The interesting thing and the common fallacy is that people do not naturally resist change, they are scared of the unknown and resist losing things they feel comfortable with. That said there are always some who seem to never be happy regardless!
For example, I implemented a new system once that had major resistance from a certain long time member of staff, but finally we got the system launched. 3 months later due to some major issues we threatened to remove the new system and revert back to the old one. The same person was extremely vocal about the old system being useless etc..... !! it just goes to show that sometimes you just have to push forward.
I firmly believe the more employees understand and accept the need for business changes, the more positively they'll respond to the changes coming up. It’s key to make sure their jobs may contribute to their sense of purpose, self-confidence and professional development and doing so you will get a huge professional and personal impact and their full engagement and loyalty making them work eagerly and with plenty of energy to make changes happen with the project. Needless to say any project has a main purpose to produce some change so if this is the main goal everybody being part of the project team must embrace the change. Basically I’d sum up as the following
- Engage employees on the planning stage
- Involve them in changes affecting them
- Help them to understand they loss something but at the same time opportunities to gain more coming up
- Reasons for change must be clearly communicated from the beginning. You must understand why we move to the change and identify showstoppers in an early stage
- As a part of the project breakdown divide activities in smaller pieces of works which will cause change details will be even more evident for all
- Apply the PDCA Demming cycle of continuous improvement. It will help to ‘insert’ into employees a culture of improving/changing things and challenging status quo
As somone already mentioned PM and CM are complementary and must be come together during all the process of the change itself
Juan - excellent suggestions and inline with John Kotter's 8 step Leading Change approach.
IT used to mandate changes and whether end users like or not did not matter. That can no longer be the case given they have so many differents paths they can take, many on there own or ones that do not involve IT.
Joel - I could not agree more - lack of Change Management is a key reason projects fail (btw - there be no such thing as an IT project!). I fully subscribe to Kotter's model (see the link below to Part 2 of my series on Change Management). You might also be interested in Part 3a below which builds on Kotter's model.
Related articles:
Change Management (Part 1) – Cracking the Code of Change
Change Management (Part 2) – Step Models of Change
Change Management (Part 3a) – Change Capability
Change Management (Part 3b) – Success with IT Change
Change Management – What’s in a Name?
Why are IT projects Change Management time bombs?
The Importance of Change Leadership – Beyond “Step Models of Change”
I also mentioned some of your other change management posts in the weekly newsletter that goes out in two minutes.
I haven't seen too many empirical studies that isolate change management as the sole factor that causes project failure but project control, which includes change management in wider set of project planning and control factors, often is cited as a primary cause. Not understanding project requirements is one of the most cited causes of failure, which may be the cause of so many change requests.
Assuming we are talking about changes to software projects and not changes to operations and infrastructure I think the simple answer is you use some sort of formal change control process. However, that likely depends on the contractual nature of the project relationship between provider and stakeholder. The formal change control process would include steps such as classification of the change request, impact analysis, including impact to budget and project timelines, decision to adopt change or not and that sort of thing. If the contract is fixed price with a fixed time, one needs to be very stringent in implementing a formal process, so as not to be blamed for the overrun of either time or budget, even if a thousand changes are made. One needs proof of the changes. If it is a time and material relationship and one is just doing a prototype, then change doesn't have to be closely controlled. In my little corner of the world our business model has morphed into a software-as-service one. We are expected to include development changes in with the whole managed service or utility service package, which also includes operational support and hosting. Consequently, we receive a constant stream of change requests, that our clients expect to be done tomorrow, naturally, and the only formal aspect of it is internal to us, which is largely an impact analysis. The changes have no impact on the price of the services and the service is in a continual iterative cycle.
Doug - apologies for any confusion, but I was referring to Organisational Change Management (OCM), as opposed to managing a change within a project's scope, timeline etc.
From that standpoint there has been quite a lot of research that suggests that projects without proper (OCM) are highly likely to fail to deliver the expected results. Projects with good change management will be more readily accepted by the employees and will deliver better results.
Enjoy both insightful question as well as all good comments, true, project management and change management are two sides of coin, and complimentary Ying & Yang in mangement discipline.
1) PM should integrate with CM into the project planning.Make sure the business understands this, and that it is built into each of the plans and estimates. If it needs to be modified, then manage it under Risk Management. Changes in scope are inevitable on any project. In dealing with them effectively, Change management and Project management go hand in hand.
2) Change managers must select an appropriate project management process. At least they need two stages, plan and implement; Change management is the most important part of the overall project. This may be the physical, technical and is always the psychological/cultural changes that are required when any change is made in a business of those who will be at all affected from the results of the project. .
3) Consistency A well designed CM & PM system will ensure consistency in the use of established processes, ensure compliance with agreed policies and enable all reporting required for management of KPIs, SLAs and other audit related issues.
Thanks.
Pearl - good points, totally agree it must be a key part of the project planning, not just an after thought. Critical to success is involving key workers from the outset and get them involved in defining the final solution. The more this can happen the easier it will be.
Jerry, I think the bottom line of what you're saying is not having the will and discipline to see through the correct or original vision of what a project set out to do. People come and go during the duration of a project, visions and priorities change....which gets us right back to the Martin's question: what's the best way to do change management.
Not long ago I would have been right where Joel is. But no more. Now I am much more pragmatic, which may just be age but I hope if is due to experience and broader view of the issues.
Projects fail because success is not clearly defined and committed. When project success has a degree of fuzziness or is allowed to be fluid in the early stages of a project you get the issues this question raises.
Projects also fail because of what Jack Keen refers to as Value Leakage in his book Making Technology Investments Profitable. The value leaks are mostly from not pursuing all of the value available in the scope of a project and not realizing the committed value at the end of the project. But value leaks are also the result of not staying focused on delivering the committed value when no-value distractions (Changes) arise.
That does not mean there will always be unknowns. It means the unknowns tend to mostly on How to deliver the committed scope instead of the unknowns becoming what was committed.
And so this also applies to the organization change that often accompanies many projects.
Jerry - interesting thoughts. I would also argue that no matter how well a project is managed if change management has been ignored then you will implement a new process and technology that no one will want to use. Even worse than that, without the peoples buy-in the old ways of doing things will re-assert themselves and you will never achieve the value you forecast - no matter how well defined the project was.
Completely true -which is the biggest reason why projects should not use a pushing force (think rope) and should always have a pulling force behind them to be effective. Ideally the pull is from the top not the bottom.
Joel, I have seen plenty of failed technologies that sunk projects. Remember the baggage system at the new Denver Airport when it opened? Bags that were supposed to go to Dubuque went to DeKalb...
Perhaps, the failure of the Denver Airport baggage system was as much a people failure as it was technology, no?
Obviously, you need buy-in before a project launches. Let the users (employees) think they developed the system...that it fit their needs. I did a post on General Electric's new Proficy manufacturing execution software (link below) and the head of that program talks at length about how it got buy-in from plant managers and factory floor engineers. Anything short of that usually spells failure....
http://www.enterprisecioforum.com/en/blogs/jdodge/time-ripe-cios-influen...
John,
The Denver airport baggage system failure is a great example of what can go wrong with a large, leading edge initiative that isn’t managed well. The primary issues there were not technological but managerial, process and decision-making in nature. I am attaching a link below to a case study of the whole thing that outlines the points of failure. It makes for an interesting read. A lot of things went wrong. We have probably all seen projects, hopefully on a smaller scale, that contained several of these issues.
I have found that with most large project failures it is the failure to perform the basics well that ultimately mess things up. Failing to manage scope, timelines and cost will get you into trouble every time.
http://www5.in.tum.de/~huckle/DIABaggage.pdf
First, I would bet that projects in general - not just in IT - have an exceptionally high failure rate due to a lack of change management. But given that we are talking about the IT world, I think CIOs can learn so much from the experiences in the 1990s with attempts to deploy relatively monolithic, wooden, command-and-control ERP systems. At best they would take 18 months to plan and deploy, during which time any number of factors would and often did change. So maybe that is point 1 - don't plan any long-term projects that cannot be broken into logical phases, the components of which can flex to some degree. Second, go into every single project telling your staff that not only will things not work the way the staff has carefully planned, but in all liklihood WON'T work that way. So the default is something that does actually go exactly as planned, and if it does, fine. Third, no vision is as clear as hindsight, so it could be very beneficial to do some IT forensics on a project that was crashed or seriously wounded by a lack of change management. What within reason could have been done better? And given that some things and circumstances really could not have been anticipated - say a merger or major acquisition - what could or should have been done to re-adjust the deployment and get things back on track. Somehow though I keep thinking of that old Dilbert panel cartoon wherein the evil HR director intones, 'Change is your friend. You go first.'