I reserve the right to get smarter.

Every decision on a program is made with the information available at the time. That is the best any of us can do.

Then the program matures. The mock loads run. The extracts come back dirtier than anyone modeled. The SME who authored the specification in March knows things in September that nobody could have known in March.

Most systems integrators handle that badly. They ask the SMEs to write perfect specs in the opening weeks — the exact window in which the team knows the least — and then treat those documents as settled. Revisiting one becomes a governance event. A change request. A quiet conversation about who was wrong.

Nobody was wrong. The team got smarter. That is what a competent program is supposed to do.

The only thing that makes this hard is ego.

I heard recently about a program communicating a ninety-day data freeze ahead of go-live. Ninety days. The best lessons on that program will come out of the final mock loads, and under a freeze that long not one of them reaches the data the business actually receives. The learning still happens. It just lands in a defect log instead of in the data.

That is not risk management. That is a sign the data team does not have a process trusted or agile enough to handle getting smarter. The business ends up as the dumping ground for bad data that should have been fixed before cutover.

Getting smarter is a habit in a leader. On a program it has to be a capability — built into the load-and-validate cycle, not negotiated around it. Fix the cycle and the freeze shortens on its own.

I reserve the right to get smarter. Update the spec. Change the data. Make the call.