5 common mistakes

The goal of the inception during a cloud migration is to define the content of the work required to get there as well as planning the steps to get there. Cases where the inception was carried out in "economic" mode due to lack of time or alignment with priorities have always made the rest of the project complicated. It is essential to take the time to release the people with knowledge within the organization. The level of precision and estimation of the work is directly proportional to the effort invested in the inception. When we carry out these activities without bringing in the right players with the right level of preparation, we add unknowns and therefore a greater risk to the success of the project. The inception should be planned tightly with Guidewire to define the objectives and the expectations so the workshops are planned to help achieve these conditions.

Migrating to the cloud is a structuring technological change that involves major challenges. A cloud migration project is far from being a smooth ride, there will be surprises that arise and it is in these most critical moments that players with the knowledge and experience with Guidewire systems will make the difference. The requirements for training levels in project teams are far from eccentric. Certified players will be able to share their knowledge with their colleagues and let the teams benefit from it. They will also be able carry out key tasks in the project. Their distribution within teams is obviously a key factor to consider. If included in the project scope, subjects such as digital and analytics often have particularities that require more specialized expertise. With a cycle of 3 releases per year, things evolve quickly, and the initial investment can seem significant and difficult in terms of time, it is therefore possible to obtain support of a consulting partner such as GFT.

For the DevOps team, the move to the cloud represents a major change in their daily life because in addition to new tools, processes are expected to change drastically. The first change is mainly seen in the sharing of responsibilities with the Guidewire teams, particularly in terms of production support. The Guidewire cloud platform offers several tools for DevOps and it evolves on a monthly basis. Problems and disruptions in daily CI/CD operations severely slow down development teams and their morale. Not including at least a few DevOps people from the first phase of the cloud transition project in order to participate in the implementation of the new CI/CD and to test the tools would be an obvious mistake. Deployment in production represents a great victory, but if the production support is not quite as much the project could be perceived as a failure. The upstream involvement of players who will provide production support so that they become familiar with the procedures will be a "game changer" to reduce the burden of incident resolution, especially for the resolution time.

We call “Dry-runs” the practices for executing go-live operations. Dry runs represent an important activity in the stabilization and deployment preparation phase. Generally, 2 to 4 depending on the size of the project and the scope. When the sequence of dry runs starts, things come together quickly, which is why it is essential to arrive with a game plan that is already well thought out from the first time. It is then easy to make adjustments and improvements. Setting up a complete and accurate schedule takes time and often requires gathering information from multiple sources and locations. The success of dry runs always influences the level of confidence of the management team and can become insecure when the results are negative. This discomfort can lead to postponements and additional delays, and therefore additional costs.

One of the most frequent and also the costliest mistakes is to underestimate the scope of the tests that will be carried out during the stabilization. This goes beyond Guidewire applications which will be migrated to the cloud platform. It is particularly important to take into account all the integration points with the systems that communicate with Guidewire to avoid collateral effects following go live. The reflection and definition of the testing strategy should begin in the inception phase and crystallize during the development phase. Sufficient time must be allowed for the execution of these integrated tests, but above all to investigate and fix potential anomalies that could be discovered. The establishment of a clear and effective process for prioritizing, resolving and redeploying fixes must be shared and known to all. When the testing phase begins, there is no time for discovering, you have to be efficient from the start and as this happens at the very end of the project, there is no margin for slippages.