Go-live starts a stabilisation period rather than ending the project. Real usage surfaces things testing does not: edge cases in your own data, habits that do not match the designed process, and reports people want once they see the real numbers. That period is worked through with you before the engagement formally closes.

The first few weeks

Expect three kinds of item to come up, and expect them to be normal rather than a sign something went wrong.

• Genuine defects. Something behaves differently under real conditions than it did in testing. These are fixed as part of the engagement.
• Adoption friction. A step feels slower than the old way, or a field nobody understands is being skipped. Usually resolved by adjusting the design or the training rather than by insisting people comply.
• New requests. Once people use the system they think of things they want. These are triaged into what is in scope, what is a small addition, and what belongs in a later phase.

What determines whether it goes well

The strongest predictor is whether someone internal owns the system from day one. Where an internal owner is named and given time, adoption holds. Where the system is treated as delivered and then left alone, usage decays within a few months regardless of how well it was built.

What this means for you

Plan for a period of adjustment rather than treating go-live as a finish line, and name your internal owner before go-live rather than after. That single decision does more for the outcome than most of the configuration choices.

Next step

For what you receive when the engagement closes, read How does Cirro hand over the system to our team?

Related articles

• How does Cirro hand over the system to our team?
• What training does our team get, and who gets it?
• What ongoing support options exist after the project ends?