Why is it important to know the technical go-live or soft go-live term?

When a new system is introduced, sooner or later the moment will come when we start using it live.

There are cases when Clients use the ‘Big bang’ method, which means from one day to another they discontinue the old system and start tracking everything in the new system. However, this holds several risks, therefore it is used by few. Such risks can be the discovery of bugs or other operational problems, in such cases, the development team needs to step in and correct these very quickly. Another cause of disruption in everyday work can be insufficient training with the new system, users can’t work at the right place. If in the meantime, it turns out that one of the modules needs to be reconfigured because it’s not effective enough in live mode, this can also bring additional difficulties and stress for everyone.

This is why the most typical approach for go-live is the Side-by-side method when the legacy system is being used parallel to the new system. In these cases, the go-live is divided into two parts: the so-called Soft or Technical go-live and the Final go-live.

Technical go-live means that the software vendor has concluded that all the conditions and project scopes have been met from a technical point of view. This doesn’t always coincide with the Client’s preparedness, therefore it’s quite possible that the Client isn’t prepared to start using the system in a live environment. This unpreparedness can have several reasons, perhaps they haven’t had enough time to test the system or to prepare their employees, but they also could be missing some integration.

The final go-live is the phase when we terminate the use of the old system (but perhaps still archive it to have access to historical data).

The Client’s concerns

The time between the Technical go-live and Final go-live, which is usually between 2 and 4 weeks, should be used to demolish the Client’s walls that they may have built because of their fears regarding the new system. What fears and concerns can Clients have?

• The system’s configuration still has minor details that don’t work well enough
• They haven’t done enough testing with the system, therefore they can only hope that it works as imagined
• They feel that the users haven’t been trained well enough and will have difficulties using the new system
• The users haven’t been prepared for the transition and there’s still resistance within the company, so the go-live keeps being postponed
• Bugs start to appear in the system

Soft go-lives are great for testing functionality with real-live scenarios. UAT “should” have accounted for all the use cases and test scripts for real live day-by-day job functions, but the reality is that nothing tests your new system or upgrade like the real thing. When rubber hits the road so to speak.

All these fears and concerns result in the Client not wanting to begin the technical go-live, even though this is exactly the point of this transition period: to get the last problems out of the way, get to know the system in a real-live environment and gather routing while doing so. At the same time, this it is key to a smooth Final go-live.

We, at PIRO, make sure that the project manager, who’s been assisting the Client during the setup, is still available in this delicate phase, and can be contacted at any point with questions about the entire process.

The best way for diminishing concerns

Let’s have a closer look at the fears and concerns mentioned above and see how these can be diminished:

• The system’s configuration still has minor details that don’t work well enough – with systems as complex as an ERP, we will always find minor details that don’t work perfectly. In truth, go-live doesn’t mean that everything works at 100%, but rather that the core functions work. A system can always be fine-tuned, and if the Client has a Service Level Agreement, then the Support team will gladly assist with this. It is quite often that Clients send us requests for fine-tuning, one and a half years after the go-live. The reason for this is that the work process and the work environment is not constant, it changes all the time, and the system needs to be adapted to these changes in many cases.
• They haven’t done enough testing with the system, therefore they can only hope that it works as imagined – this is usually a pretty big mistake and concern, because during the setup many Clients keep putting off the testing and, as result, in the last moments of the setup they cannot know, but only hope that the system works well. This causes insecurity. As a matter of fact, there is one antidote to this: take the project manager’s advice and when they tell us to test, actually start testing instead of putting it off. I like to use a very convenient example: how many times do we perform a quality check when making a ring? Usually about 4 times, in different phases. If we only check the ring in the last step and realize that the casting hasn’t been done properly, the diamond doesn’t reflect the light well because the polishing underneath is not perfect, then it’s a lost case: the ring has to be taken apart and the process starts over. Don’t make the same mistake when implementing a new system.
• They feel that the users haven’t been trained well enough and will have difficulties using the new system – to be honest, the best solution to this is to throw them into the deep water and see how well they swim. The Soft go-live period is perfect for this. We will see that the users who can handle themselves and quickly get a feel of the usage of the software will have a lot of questions, while other users will suffer and make mistakes rather than ask questions. This is where we find out which users require more training. People tend to just nod during the general training, everything is clear to everyone, but shortcomings start to appear when they finally start doing the operations themselves. But this is completely normal and should be treated as such. The users’ fears also need to be dismissed and that needs time.
• The users haven’t been prepared for the transition and there’s still resistance within the company, so the go-live keeps being postponed – if we keep fighting this very problem before the go-live over and over again, that’s a huge problem. Preparing the users ‘spiritually’ for the coming of the new system has to happen in the first phase of the project. We need to communicate the goals to them clearly, that way the introduction will be less problematic. Naturally, the resistance cannot be eliminated completely, there will always be people who are more comfortable with the old system and old methods, even if those are a lot less efficient or transparent for the company. But in such cases the company’s interests need to overwrite individual interests.
• Bugs start to appear in the system – the vendor team usually does their best to get rid of critical bugs before the technical go-live. Bugs are existent in all ERPs, or any other system, for that matter. They can occur in spite of all the internal automated and manual testing. There are bugs that only appear in very special circumstances and can stay hidden for 1-2 years even. You shouldn’t be alarmed by these, there’s a solid support team at PIRO and as soon as these issues are reported, they are always solved with the involvement of software developers.

The importance of the technical go-live from the vendor’s point of view

The technical go-live is usually a line in the sand that the vendor has completed the project scope, and therefore can rightfully ask the completion of any outstanding payments that can be tied to this milestone. We unequivocally encourage clients to manage and shed their fears and concerns and start the process of the soft go-live, because this is the only way they can take start taking advantage of the new system as soon as possible.

It is also important from the vendor’s point of view that they can only assign a project manager to the implementation project for a limited time only. If the technical go-live and the final go-live are postponed or delayed by several weeks (or even months), then the client will have to make ends meet with an unknown team member or support staff, instead of working with the already-known project manager in getting rid of the problems.

The period of technical go-live is important because in this phase we work with real data, in parallel with the old system, and this can bring to the surface situations that couldn’t be replicated at the time of testing.

As a conclusion, let’s summarize the undeniable advantages of the technical go-live:

• Valuable feedback from real, live situations
• Mitigate risk by gradually rolling out new features and processes, and allowing time to ‘fine-tune ‘, identify any requirement gaps, and quickly resolve technical issues and requirement changes
• Time to learn the new workflow and become familiar with the new system
• Train individual teams or groups gradually
• Meet commitments, build confidence, and gain momentum as features are gradually rolled out, and users, as well as support staff have time to adjust to the new system and workflows