Challenges, Best Practices & checklist for application "go Live"

Whether an application or software product is ready to go live, is a very simple question difficult to answer. It is mostly towards the deadline that all the final development and testing is squeezed in. Most important functionalities are prioritized and the product is declared complete based on a certain self determined quality level. Generally, everyone depends on the tester to speak about the quality, but actually it needs to involve all the people in the process. 

Deciding if an application is ready to go live is different from the regular testing process. It is the phase after testing has already been done. As projects grew bigger, they became more complicated and the development timeline shorter. With more development in less time, bugs filled in and quality degraded. Testers were hence introduced at the end of the development phase to detect bugs for rectification. With Agilemethodologies in practice, testing now runs parallel to the development process. 

It is only after testing the product that it is the time to determine the readiness of the product for release, that it is technically complete and ready for use by the customers. While testing, several defects will be found, which need to be managed as necessary for the organization. These bugs can be classified as per their level of severity.

-   Critical bugs that can impede the software operation.
-      High priority bugs that hinder the operation of a product and have no workaround. 
-      Mid level bugs that cause user inconvenience, but have an alternative workaround. 
-      Low level bugs which do not affect the system 

The utmost effort is to release a product which has no bugs, but this rarely happens. Hence, the application is released as such it has no critical, high priority and mid level bugs. Setting a goal of delivering a bug free application may delay delivery date and alter revenue projections. Hence, to manage all aspects, bugs need to be placed in priority order making necessary trade offs.

Once the development is complete, the development  environment needs to freeze. Here no development is done unless it is bug rectification. Once this triage with bugs is complete, it is considered ready to go live. Here the product is considered to be stable, bug free and ready for customer use. However, an organization still faces operational disruption at the time to go-live which most often are self inflicted and can be mitigated easily. Finally, it comes down to the following which indicates an imminent go-live.

-      All the new processes and functionalities of the application has been accepted by the users.

-      Users understand the new business transactions.

-      Everyone understands how to use the system.

-      There is adequate support ready.

-      There is a good contingency plan.

Once all the above points are addressed, the application can go live.

Conclusion:

Making a software product live is not a smooth process. Many technical and administrative hiccups occur during this process. However, it must be noted that this entire process depends on the testing process and proper test planning.