Changeover strategy: Better have one!

Once requirements analysis is completed, Business Analyst has all the information needed for a well-running function. Further actions for design, development, test and eventually roll-out are conduct accordingly. Usually and unfortunately, because of the rush of ongoing project execution no one thinks about the roll out activities until the end of the project plan and when the PM starts to drill down the roll out plan in details, project team face with the big nasty surprise of new requirements necessary for the selected software changeover (a.k.a. software adoption) strategy. Cost increase, delays, unmet deadlines create the nightmare one by one.  

So how can we avoid living the nightmare?

1. Talk about changeover strategy during elicitation! 

The way of project/demand roll out may have a significant effect on your work. It may need further analysis and development on your systems or further preparations such as configuration changes. Even worse, your applications may not support the changeover strategy requested by the customer when you asked them at the last moment.

For example

  • If your customer wants a soft transition between an old application to a new one, they can choose a parallel running. On the other hand your systems may require data synchronization and if you didn’t consider synchronization requirements at the beginning, you have to deal with new requirements about synchronization and their development at the end of the project or you may choose the risky way and try to persuade your customer to a big bang roll-out. Making the choice will cost you both the time and money or to an unhappy customer. Even further it may cause bad market reputation for your brand because of the possible problems caused by the roll-out.
  • If your customer wants to test the application on production you will go with pilot conversion which may not mean a parallel running. In order to make a pilot, a restriction on the functions or systems may be needed and making these restrictions per area/ dealer/agent/user etc. may cost you to new developments.

2. Determine the changeover technique and analyze related requirements.

In order to choose the methodology;

  • Consult your customer about their business strategy, so you will understand the original need and your possible options to make your customer happy.
  • Define abilities of the systems, this will define your technical constraints or additional budget increase necessity to make your systems support the selected technique.
  • Take into account the possible risks and the risk you are willing to take, according your brand recognition, market demand etc. Are you willing to face with a roll-back?
  • Think about quality, selected technique will affect the quality of the product at the end such as issues on production.
  • Consider your customers/users possible resistance to change
  • And of course be careful with project deadlines, budget limits and resource capacities.

Analyze the technique as if you analyze the business requirements and be sure all the business scenarios are analyzed also taking into consideration of effects of the selected technique.

3. Handshake with your customer (or business team). 

Don’t forget, well informed customer is a happy customer.

  • You will be able to get all the needed support during roll-out phase from your customer.
  • Informing them earlier will give them time for necessary preparations such as determining pilot users, dealers, adjusting legal necessities, releasing the pilot plan to field etc

4.    What should you know about changeover?

Knowing the general techniques of adoption will be enough for early stages. Once you understand what your customer has in his/her mind, you can detail requirements in analysis.

Always consult with your design/architecture/development units. They will guide you about your technical constraints and alternatives.

Common changeover techniques:

Following are most common techniques(1) to adopt your new functions or application and they range from an instant switch to a strategy where users start using the new system over a certain period of time or use both new and old system till it get stable.

  • Big bang adoption (a.k.a. Direct changeover or Direct cut-over): Involves complete and simultaneous implementation of the new system across an organization
  • Phased adoption (a.k.a. Phased changeover or Phased operation): Phased adoption means that the adoption happens in several phases, so that after each phase the system is a little closer to being fully adopted by the organization.
  • Parallel adoption (a.k.a. Parallel running or Parallel operation): Involves running both systems until implementation of the new system is considered to be complete and successful.

Pilot conversion (a.k.a. Pilot operation) is a strategy may be used with one of the adoption methods. It Involves system roll-out to a small group of users for evaluation and testing before implementation across the organization.

For example you can go with phased adoption and in each phase you may prefer to make a pilot first or you ca go with parallel adoption and new application may be opened to pilot users while the old application is still running to pilot users as well.

AuthorAylin Sen, Senior Business Analyst

Aylin Sen is a senior business analyst in Istanbul, Turkey. She is passionate in business analysis and the application of Information Technology for process improvement. She worked as Business Analyst, Business Process Analyst, System Analyst, Project Manager in different domains and companies for 8 years. She has experience in many large, complex software and multinational projects. 




Copyright 2006-2024 by Modern Analyst Media LLC