Mitigate resistance to change during a release of a new IT system
I want to share a painful story I witnessed while working as a proxy Project Manager at a company. From this experience, I’ve extracted some valuable lessons. The story revolves around developers, much like Sisyphus, working tirelessly on a product that never saw the light of day. Despite assembling a highly talented software development team, the company failed to release anything for two years. With a budget of roughly $6 million USD annually for the team, this doesn’t even account for the cost of delay or the countless missed opportunities.
How could a company go two years without releasing a product?
The main culprit was fear—specifically, the fear of breaking something in the existing environment, combined with the overwhelming pace of change within the company. IT management preferred clinging to an outdated, but functioning, legacy system rather than keeping up with competitors. This resulted in a political struggle between those who wanted to preserve the old way of working and the developers eager to see their software used by customers.
There was also a bottleneck in the release process: a single, overburdened IT administrator. This individual was tasked with a mountain of responsibilities, including patch fixes, technical support, infrastructure monitoring, and more. As the only one responsible for releases, this admin had no incentive to complicate an already complex system. We certainly can’t blame a lone IT admin for being buried under such a workload, can we?
So, how do we mitigate resistance to transitioning to a new IT system?
One key solution lies in properly migrating the legacy system to the cloud and implementing effective release management. This approach can help reassure stakeholders—including our overworked IT admin—and reduce resistance to change.
Cloud Migration and Creating a Test Environment
My recommendation would be to create a cloud-based test environment that mirrors the legacy system. While it’s faster to simply replicate the legacy environment with the same architecture, this approach is less scalable and hinders knowledge sharing. After all, control over the system would still rest solely in the hands of the IT admin and their team.
Even a “small” migration like this is a significant project that requires a dedicated team, a clear approach, a budget, and a sponsor. If it’s treated as just another task, it risks being indefinitely delayed. For the purpose of this discussion, I’ll focus on considerations for creating a Stage environment in the cloud.
While setting up the Stage environment, we can also start thinking about the Production environment. This includes selecting a cloud provider and considering technologies like containerized services with gRPC or GraphQL. The project brief should be transparent, outlining business goals, roles, potential new hires, a high-level roadmap, and budget.
This migration can follow a hybrid approach—both waterfall and agile. Waterfall for tasks like analyzing the current system, assessing dependencies, and performing a cloud readiness evaluation. Agile for building an MVP version of the Stage environment, focusing only on what’s necessary without overcomplicating security, performance, or storage. This also allows for trial and error as you adapt the architecture without too much risk.
Release Management
Release management is critical because the release is the first step that delivers tangible value to the business. It marks the moment your product enters the market, opening the door for valuable customer feedback that drives further improvements. In our case, the lack of any release only deepened the fear of releasing.
Release management involves planning and overseeing the development, testing, and deployment of software or updates, ensuring they’re delivered smoothly and efficiently. This process involves coordinating teams, managing risks, and deploying changes in a controlled and systematic way to minimize disruptions.
To overcome the fear of releasing software, I’ve identified four key steps:
Planning and Communication: Effective release management starts with clear planning and communication across the IT department. The release period is crucial and should be agreed upon by all affected teams. Releases are often scheduled during low-activity periods, such as after major sales cycles, and usually occur at the beginning of the week. Publicly announcing release objectives, timelines, and detailed plans ensures the entire IT department is aligned and reduces uncertainty.
Incremental Releases: Gradual rollouts help ease resistance to change. Start by migrating a subset of users or running a pilot program, then gradually expand the rollout to other services. Breaking down the migration into phases allows teams to address issues early on without affecting the entire user base. Additionally, this approach keeps the legacy system operational while the new test environment is progressively integrated and mastered before transitioning to Production.
Rollback and Contingency Plans: A solid rollback plan is essential in case something goes wrong. By establishing and documenting robust rollback procedures, you ensure systems can be restored if needed. Having a backup plan brings peace of mind.
Automated Testing and Continuous Integration: These practices ensure the new services function as expected. Once tests are completed, test management systems (TMS) generate reports and visuals that provide insights into the product’s stability. This data helps build confidence within the IT department, reassuring them that the release is safe.
These steps help build a safer, more predictable release environment and create practical documentation and plans that can be used for effective communication with the IT department.
Sebastian Zelechowski