Menu

Some organizations are risk averse which often means they avoid change to reduce risk. This is a false economy, in my opinion. Sometimes, clients ask Imaginet to help them with failed and delayed projects, and for us to be successful, often we need to facilitate cultural change within the organization. When we have the right support in the organization, adapting to change can happen.  

When an organization avoids change, especially in software projects, they keep the same code and ignore technical debt, and continue using older versions of components, along with whatever workarounds (hacks) that have been put in place. At some point, they are forced to make changes by some external force or constraint, like a vendor discontinuing support for older versions of their operating system or software components. When they are forced into upgrading, the timeline for upgrades may not be under their control, and the upgrades may be so different that users need to be trained to understand and use the new system. Users become resistant to changes because they have a reputation for difficulty and failure. Users may not want to adopt changes that may even benefit them. 

Big Bang Change

In such organizations, when a new version of a system is rolled out to users, it may not have had enough time for thorough testing, or it may not be possible to release it incrementally across the organization, so all the change comes at once. This is Big Bang change and is inherently risky – it’s a lot of change in a short period of time, it’s complex to release, and probably even more complex to rollback.

Users are wary of Big Bang change, and rightly so – many times it does not go well, and users experience a lot of pain and inconvenience when it occurs. It can be costly too: in lost productivity, lowered morale, lost revenue, and lost customer confidence. When organizations avoid and delay change, then every change they make is massive, complex, risky, and feared by users.

Incremental Change 

Releasing smaller changes much more frequently is a much better way to implement changes. These changes are easier to accomplish, much less complex to implement and to roll back from, and much more subtle. In many cases, your users may not need training to adopt the change. Some organizations choose to release small changes to a subset of users and may even do A:B testing with sets of users to see which changes users prefer, before rolling out changes to all users.  

Users get accustomed to small successful changes and may even look forward to future changes because they see the benefits without experiencing the stress of Big Bang changes. When users are involved in the decisions about changes, as they are in many Agile projects, they become champions of the change, rather than fearful of them.  

Changing Culture 

Can an organization remain risk averse and still embrace incremental change? The reality is that avoiding change doesn’t reduce risk. Organizations that are risk averse are good at identifying risks and that should continue. Risk mitigation is not only trying to avoid a risk from occurring, but also knowing how to reduce the impact of it. Things that haven’t changed for a long time become brittle – this is true for software (and data) engineering too. This means in some cases, it’s good to focus on the brittle parts and fix or replace them before they break or break them on your own schedule.  

How can an organization go from avoiding change to embracing change? At the risk of sounding meta, this is done by initiating incremental change within the organization. Someone just decides to change, starts small, and continues from there. Leadership is also a key factor – if the leadership of the organization doesn’t believe in change, then the organization won’t believe in it either.  

My Change Experience 

Many years ago, I worked on a project for a government agency that wanted to establish a Business Intelligence unit. They had an IT division that supported their corporate networks and a software development department that built their own internal line-of-business applications. They were very risk averse, and hadn’t upgraded their desktop operating systems for years, and their corporate email used commercial software that had been obsolete for years.  

The newly minted Director of Innovation wanted to establish a Business Intelligence unit that was agile and would build a data analytics ecosystem exposing internal data from the line-of-business systems to the internal data analysts and scientists that needed it. I was tasked to help him build this practice from the ground up. 

Because the current corporate standards for desktop operating system and development software were very outdated, I told him we needed to carve out our “island of sanity” within the existing, rather brittle standards. As a result, we were given new workstations with the current version of Windows, and the latest edition of Visual Studio for us to begin building this system. We adopted true Agile Analytics team processes and technology – at the time it was Team Foundation Services, a cloud-based predecessor of Azure DevOps.  

When I laid out the requirements, the manager asked her IT team if it was possible to just do it as requested. Was there a reason why they couldn’t? Their only answer was it wasn’t how they had done it previously, and she refused to accept that as a valid reason. So, her support and willingness to adapt to change was also key to the success of this project.  

In the course of about 18 months, I was able to lead a team to build a data warehouse, analysis cube, and ETL packages that were fully source-code controlled. The deployment of those assets was fully automated to beta, test, and production environments. The team learned to practice Agile Analytics and respond positively when changes were requested by the users.

The data analysts and scientists were involved throughout the project as subject matter experts and in the decisions about features and priorities. They were invested in the project and as we rolled out features, early and often, their confidence grew, and their adoption of the new system was critical to its success. I didn’t change the whole agency’s culture, but we did build a successful data analytics ecosystem and changed the mindsets of the data engineers who formed the development team, as well as the business users who used it. Adapting to change became a reality for those who initially rejected it.

Thank you for reading! At Imaginet, we believe agility, change, and effectively adapting to change are essential to the success of an organization. Technology changes quickly and adaptability is important. If you want to make changes within your organization, get in touch. And make sure to subscribe to our blog for more helpful content.  

Discover More