Na dan go-livea prestaje kontrolirano projektno okruženje i počinje stvarni rad s rokovima, novim kombinacijama podataka i korisnicima koji moraju završiti posao. Testni scenariji više nisu dovoljni: sustav se susreće s djelomičnim isporukama, naknadnim promjenama, pogrešnim unosom, bolovanjem ključne osobe i odlukama koje nisu bile zapisane u projektu.
Zato stabilizacija nije produženo testiranje niti znak loše implementacije. To je planirana faza u kojoj se razlikuje pogreška sustava od nedostatka podatka, nejasnog pravila, potrebe za obukom ili nove poslovne situacije. Bez te discipline svaki problem postaje hitan zahtjev za razvoj, a projekt brzo gubi prioritet i trag odluke.
Nakon prvog vala tim treba grupirati incidente prema uzroku. Deset prijava može biti jedna pogrešna šifra, nejasna ovlast ili nedovoljno razumljiv korak. Popravak uzroka smanjuje buduće prijave; pojedinačno zatvaranje tiketa samo skriva ponavljanje. U ovoj fazi posebno pratite gdje se korisnici vraćaju u Excel, privatne bilješke ili e-poštu.
Ne dopuštajte da svaki odjel vodi vlastitu listu prioriteta. Ne vraćajte trajno stare alate bez odluke o roku gašenja. Ne pretvarajte svaku korisničku nelagodu u custom funkciju prije nego što se provjeri proces i obuka. I ne proglašavajte sustav stabilnim samo zato što je broj prijava pao — korisnici možda više ne prijavljuju, nego rade mimo sustava.
Go-live završava pripremu. Stabilizacija dokazuje da proces, podaci i ljudi mogu zajedno izdržati stvaran rad.