Framework

In their paper A model for diagnosing organizational behavior, Nadler and Tushman define a process for implementing their change model. In that spirit, Figure 3 shows an overview of the process for using Agile Congruence to implement a software driven organizational change process. While I use these steps when implementing technology changes, I don’t go through a formal documentation process. This process can be accomplished with a whiteboard or two, an Excel spreadsheet, a PowerPoint, or whatever tools you use to best organize your thoughts. Many organizations use tools like Jira or Gitlab Issues to manage their backlogs, but other tools like Post-It notes or Excel spreadsheets work fine as well. I would be very sad if I saw an organization produce a binder of documentation formally documenting this process. ...

1. Identify Symptoms There is some reason that your organization wants to change and make an investment in technology. In the past when I have assumed that all stakeholders were on the same page with the problem that we were solving I was usually wrong. Taking the time to identify and understand the symptoms and ensure that there is agreement among stakeholders on the problem statement is a key first step to scoping your change process. ...

4. Analyze Gaps and Build your Backlog In the process laid out by Nadler and Tushman this phase was labeled Identify Problems. In the world of agile software development these problems are captured using tools like User Stories. Modern UX techniques can also be used to help with this Analysis. At Chatham, when facing some complex organizational changes, we use the concept of a Design Sprint to guide users through a problem identification process and capture the gaps in the current organization. Each organization typically has a different process for accomplishing this and there is a wealth of information in the software world on various processes that your organization could implement. ...

8. Decide to Continue or Re-Evaluate At this point on any iteration you may find that there are no changes that can be made where the value of the change justifies the cost. There are times early in the process where we have found that we should delay development and wait for other organizational changes to complete before we make the investment in software, and other times late in the process where we have a set of nice to have features that are expensive to implement and provide lower value. In either case, at this point you should delay or cancel further development on this project, as more software will not deliver more business value. ...