Using the ADKAR Model with IT Change
Using the ADKAR Model with IT Change
Zone Leader, John Vester, provides an example of how the ADKAR change management model can be applied to change within Information Technology
Join the DZone community and get the full member experience.Join For Free
The Agile Zone is brought to you in partnership with Techtown Training. Learn how DevOps and SAFe® can be used either separately or in unison as a way to make your organization more efficient, more effective, and more successful in our SAFe® vs DevOps eBook.
I recently attended a session for Leading Change, where a portion of the training focused on the ADKAR change management model by Prosci. While the session was focused on reaching those at manager levels (and above), I left the session knowing that I could apply the ADKAR philosophy toward handling change within Information Technology (IT).
What is ADKAR?
Jeff Hiatt, the founder of Prosci, created ADKAR as a mechanism to drive individual change, which in turn will drive organizational results. As you might expect, ADKAR is an acronym:
Awareness - Understanding the reason for the change.
Desire - Ability to participate in the change.
Knowledge - Figuring out how to change.
Ability - The ability to adjust or implement the change.
Reinforcement - Actions/measures to increase successful adoption rate.
Prosci provides the below graphic, which aligns the "people side of change" with the phases of change for a given project:
Example of Applying ADKAR
An example of an organizational change that had a heavy impact on the people involved is the transition from Waterfall development to Agile/Scrum adoption. The result of this change, especially years ago when the concept of Agile/Scrum was new, had a significant impact on those involved (developers, business analysts, project managers, etc). ADKAR could have been utilized in the following manner:
Awareness - Communication on how Waterfall wasn't a great fit and how an Agile/Scrum's ability to wrap work into 2- or 3-week Sprints would improve the process and end product.
Desire - Demonstrate how prior projects were not successful due to requirements changing. Those involved with past efforts could understand how frustrating Waterfall development turned out to be when a large portion of the work had to be discarded due to changing needs.
Knowledge - Training on how Agile/Scrum differs from Waterfall development and use of new tooling can help one understand the new application lifecycle that is being embraced by the teams. Seeing the corporation back this new approach, by inserting product owners/managers on the teams to provide quick feedback from the business, certainly, provides a positive change over the prior Waterfall approach.
Ability - Once an understanding of the Agile/Scrum methodology is in place, technical team members would begin to see the benefits of the new methodology. The focus on the team concept and the short development cycles provides quick feedback loops in order to minimize issues when compared to Waterfall development.
Reinforcement - Using Agile/Scrum (rather than Waterfall development) needs less reinforcement than other changes might require. However, the retrospective portion of Agile/Scrum is truly a mechanism for reinforcement in its own - discussing and figuring out how to resolve issues that have occurred, which could include the development methodology itself.
The ADKAR method is a method I would recommend understanding when dealing with change management. While the emphasis of ADKAR in this article has been focused on Information Technology, there is no limit to the number of situations to which ADKAR can be applied. In fact, ADKAR can provide significant value when dealing with change on a personal level.
Prosci has an eBook called "The Prosci ADKAR Model" which dives far deeper into the concepts discussed here. If you are interested in learning more about the ADKAR method, the eBook is certainly a good next step.
Have a really great day!
Opinions expressed by DZone contributors are their own.