Go-live requirements versus everything else

Ask a project team what must be finished before go-live and you will often get the entire issue list back. Every open item has an owner who believes it matters. Many of them are right — it does matter. Just not before go-live.

In stalled implementations, the most effective single intervention is often this: separating what operation genuinely requires from what would be good to have.

Three categories

Every open item falls into one of three groups:

1. Go-live requirements. Without these, the business cannot operate. Orders can’t be taken, stock can’t be moved, invoices can’t be sent, the books can’t be closed, the law can’t be complied with.
2. Improvements. These make the system better, faster or more pleasant. They are real, and they can follow after go-live.
3. Backlog. Ideas, wishes and edge cases that have attached themselves to the project over time. Some will never be built, and that is fine.

The discipline is to keep category one small and honest. “The users won’t like it” is not the same as “the business can’t operate”. Neither is “the old system did it this way”.

Why this is hard from the inside

Go-live scope grows for understandable reasons. Users fear that anything deferred will never be delivered. Suppliers accept extra items to keep the peace. Project managers don’t have the authority to say no to a department head. Over time, go-live becomes the moment when everything must be perfect — which means it never arrives.

Making the cut requires two things: someone with the standing to make it at executive level, and a credible promise that deferred items will actually be handled after go-live.

What changes

Once the go-live list is short and agreed, conversations change. The supplier knows what finished means. The customer knows what they are accepting. Testing has an end. Invoices have a basis. And management gets something it hasn’t had for a while: a date it can believe.

The fastest route to go-live is usually a smaller go-live.