Working with customers on improving their Software Development practices we have to manage change, at all levels of the organization, and on various aspects: people, practices, processes and tools.
We also often realize that they tried changing before, but had limited or no success at all. Why?
The Deloitte CIO study shows that change management initiatives fail because:
This shows that to ensure success, we must manage change, and related change initiatives, adequately. So, which model is good?
Well as George E P Box said, all models are wrong but some are useful, and if you Bing “change management models” you’ll get a fewmillion hits: Kotter, ADKAR, 7-S or Galbraith (ok this one is on designing your organization but still very applicable for change management) are typically the top results.
Kotter:
ADKAR (Change Management Learning Center):
· Awarenessof the need to change
· Desireto participate and support the change
· Knowledgeof how to change (and what the change looks like)
· Abilityto implement the change on a day-to-day basis
· Reinforcementto keep the change in place
Galbright (star model):
7-S (McKinsey):
Or the version by Mike Cohn for Agile adoption, ADAPT:
One thing to keep in mind, back to George E P Box’s motto, is that change will impact different people, differently. Not all people will agree with the rationale, not all people will believe in the initiatives put forward.
One critical component that is not obvious in the steps from the above models is culture; it is step 8 of Kotter’s process, but it looks like something to consider at the end, implying that you should mare change part of your culture. However, your culture will have an impact on the steps, the process and the initiatives to put in place. Keep that in mind.
Now, should change be a top to bottom (leadership driving changes) or bottom-up (the need for change coming organically from the lower levels of the organization) approach?
Models advocate sponsorship and commitment from the top for the initiatives to succeed, but at the same time they also prescribe to make sure participants contribute and buy-in to the change. It implies that change can be driven from the top but for it to be successful you need all participants to contribute. It also implies that change can come from the bottom but it needs the support and sponsorship of the leaders to be sustained and broader (organization vs. team). Therefore, change has to be both top to bottom and bottom-up and everyone needs to understand what’s in it for them.
Regardless of the model you decide to use, the organization need to:
- Understand why it needs to change (so they can align specific initiatives and measure progress), the rationale
- Understand how the current culture will affect the change process and initiatives
- Participate, at all levels
- Have their key people to want to change
- Be specific about what has to be changed, and why
- Communicate, including on what’s in it for everyone, specifically (motivation)
- Empower people to make decisions to get them to buy-in
- Promote (quick) wins
- Apply better practices and use experts
- Implement continuous improvement
- Align all initiatives
Following is a generic version of an implementation model we created for customers some time ago:
Those principles apply regardless if you change the overall organization or the software development organization.
In conclusion, remember:
- Current culture will have an impact on how change will have to be implemented
- To involve everyone impacted
- Build the case for change and communicate
- Be specific about what you want to change and why
- People first
- What’s in it for them?
- Skills and competencies required
- Some of our customers even had to change job descriptions, career path, remuneration models, personal objectives, etc.
- Train, coach and support them to limit resistance to change
- Processes and tools will be impacted too
- Be pragmatic about what you put in place, it’s about your challenges in your context, not about a book you read. Best practices don’t exist really, there are only better practices. A better does not have a finish line
- Manage and measure
- Sponsorship and buy-in of all levels
- Plan, manage scope and priorities
- Align initiatives and measure progress (“we get what we measure”)
Personally, I also recommend that metrics are not only related to progress (after the fact, lagging) but are also forecasting, leading metrics, and that those metrics are reviewed and analyzed periodically as part of the continuous improvement plan. Looking at trends, not just the data, is also critical.
Finally, automate as much as you can, as close as real-time as possible, so you get the information you need to make decisions faster.
Stay tuned for part II of this post (A goal without a plan is just a whish) for specific path to change for Software Development organizations, including tools you can leverage to automate the change process.
