It’s most critical that stakeholders closely follow up this stage and quickly remove any roadblock that appeared. This was achieved by face-to-face or remotely frequent status reports with the project sponsor and customer’s project manager. Close to Solution Release stage, these status should cover the acceptance tests, the roll out plan and any other subject that can influence the go live date or system adoption.

The roll out plan should be jointly defined with the customer, both business and technical, as most often it involves several actions on the their side. Without their commitment the roll out won’t be possible. Additionally every roll out has associated risks and it is critical that the customer is aware of them. This is to ensure any actions in the roll plan designed to mitigate them are effectively executed.

Customer acceptance is mandatory before the solution is pushed to production, this acceptance has no specific format, but at least must be a written email clear stating that the solution can be promoted to production. The goal is to ensure there is a joint commitment on what is being released and any associated risks. It is also a pressure point to push the customer to dedicate the quality time required to actually evaluate the solution to be released. If the customer made any constraint for this acceptance (conditional acceptance) make sure you communicate the appropriate follow up plan.

After going live there is typically procedure with a set of people from the customer organization handling help desk duties, to guide end-users and perform a first level of troubleshooting. Work with the customer in order to be clear to everyone how users feedback, bugs and questions will be handle.

If maintenance (both development and operation) team is not the same as the development team it’s important to make sure that the knowledge transfer occurs. Depending on the scenario this can be done through a set of handover sessions, by the two teams working jointly for a set period of time or through team rotation.

To ensure a smooth adoption some proactive tuning is required, like performance and usability tuning. Usually the warranty period occurs during post-production phase. During this period the project team is in charge of monitoring the solution and fixing defects that may arise. Do not lose focus on the tuning activities in favor of warranty activities.

Make sure you propose and discuss with the customer any follow up actions to the project that might make sense. This can include a new release for not-implemented requirements, evolutionary maintenance from an internal team or external team or other offer that best suits the customer without losing the focus on the customer autonomy. Training activities like Support Bootcamps, Ux workshops and handover sessions are examples to help the customer autonomy.

You should continuously validate your team alignment with your customer team by requesting their feedback throughout the project delivery, ideally every sprint after the demo. This way you will be able to act and improve on the delivery process when and where needed for a final great delivery experience. Use the Customer Satisfaction app for feedback request and analysis.

Observe users while testing the application as they will use it in production, with real data and real scenarios. Collect usability quick wins and prioritize them. Also, if any major drawback was found, consider solving it in order to ensure application adoption.

Making sure final users will be able to use the system on their own after go-live is something you need to take into account. Actual training or workshops may or may not be required depending on the specific situation. Who actually delivers the training is something you need to agree with the customer.

At this stage you should have a highly usable application. To recognize this achievement you should ask for a certification to be done by the Auditor. It should be a moment to celebrate the work the team accomplished.

Prior to acceptance tests, the team must test end-to-end, at least the top user stories, and confirm that it is working correctly. If integrations or migration are involved they must also be tested.

We should ensure that the customer actually tests the system, to minimize application adoption difficulties and production issues before the customer accept the solution. In case of migration is part of your solution, ensure that migration was executed and validated by the customer in acceptance tests. To enable the customer to do so, the team must setup an environment with realistic sample data. Be sure the testers are aware of how to report issues, and of issues status.