When is the best time to change?

My previous blogs touched on selecting the right solution when initiating a change. This blog focuses on the next step of ‘best time to implement a change’.

Time– and timing – are of the essence when an organisation has decided to pursue process change and implement new solutions. Now is almost always a better time than later.

Any planned change should be fit to address an identified problem, justifiable, and cost-effective, and selected to deliver value, as I have explained in previous blogs. When all of these boxes are ticked, the benefits of change should be significant, and therefore the sooner they are realised, the greater the reward. In addition, technology has a shelf-life, so postponement only shortens the time before the need to change arises yet again sometimes grown bigger than before. Finally, delays can lessen or eliminate first-mover advantages.

Implementation timing: If the time is now, what about the timing? It is probably never the wrong time to make a desirable change, but without doubt some times are more favourable than others. Clearly it is not sensible to plan major changes to underwriting processes during a key renewal period, for example.

A rule of thumb is that quicker is better. Change inevitably causes disruption, and while this can and must be managed, shorter implementation times help to minimise short-term impacts on productivity.

However, few organisations manage to activate change programmes within the intended timeframe. Change schedules are often found to have been unrealistic, sometimes because the staff members directly affected by process change can become process-driven, and are therefore unaccustomed to making small changes on a day-to-day basis. Earlier, constant, and incremental change will help to ensure that individuals slip out of their process-driven approach, and adopt a change mind-set. A regular schedule of minor changes has the further benefit of alleviating the need for periodic sweeping change. Companies that adapt as they go typically find even the largest changes much more tolerable.

One way to cut down on implementation time is to pare back the front end. Usually, too much time is spent on the planning phase. That mistake is a hangover from the era when developers designed, coded, compiled, and tested new systems from scratch, and did so in a relative vacuum. That is no longer the case. Outside the world of truly innovative insurTech, few companies today are likely to introduce completely new systems that are easy to develop and maintain overtime to add new features. The core architecture is almost always in place from the beginning.

We almost always see far greater interaction between developers and businesses, as programmers move outside their black boxes, and business executives and managers become increasingly technology-minded. However, this need not slow down the process. The introduction of rapid application methods, agile development, and low code techniques has considerably reduced the time required from initiation to launch. That helps the ultimate users of new technology get involved in its design, which always delivers better outcomes.

One option is the ‘fail fast’ approach. This technique focuses on rapid deployment of new technology to only a sub-section of the business. This allows a solution to be tested and refined before it is implemented organisation-wide. This swift approach avoids spending wasted time on the definition of non-critical aspects of the solution, which may bog down the entire process. Instead, companies get the bugs exterminated quickly, and the entire business can enjoy the benefits faster.

My next blog, will address the critical change question of ‘Can I deliver this change today?’.

By Parminder Kaur
Director Consulting