A modernization program does not fail on the day it is declared failed. It fails months earlier, quietly, while the status report is still green, and the gap between when it actually failed and when it was admitted is filled with spending that could have been stopped. The reason boards miss it is not lack of attention. It is that the signals are visible from the boardroom but do not look like failure. They look like normal program friction, right up until they do not.
This is part five of a six-part series on technology modernization for executives. The earlier parts covered whether to modernize, what it costs, how to choose, and who to buy from. This part covers oversight, specifically the small number of signals a non-technical board member can read without being briefed by the people whose program it is.
Failure is almost never technical
The instinct is to assume a failed program failed because the technology did not work. It is rarely that. The technology usually works, eventually, in a lab. Programs fail on data migration that was harder than anyone admitted, on scope that grew while the date did not move, on governance that performed oversight without exercising it, and on a status that stayed green because going red had a political cost. None of those are engineering problems. All of them are visible from the board if you know the shape they make.
The four signals
These are deliberately few, because a board does not need a dashboard. It needs four questions it can ask in any steering session, and the discipline to act on uncomfortable answers.
1. The status has been green every period, then it is suddenly red. Real programs degrade gradually. A status that is green, green, green, red did not just go red. It was red for a while and reported green, because the people reporting it believed they could recover before anyone noticed. The pattern, not the final red, is the signal. Ask to see the trend, not the current state, and be suspicious of stability that is too clean.
2. Scope is growing but the date is not moving. When new requirements keep being absorbed and the go-live date does not change, the program is not absorbing them. It is deferring the cost of them to a quarter past the date, usually into the "second year" from part two. A date that holds while scope rises is not strength. It is debt being hidden in the schedule.
3. Data migration keeps moving to "later." Data migration is the hardest part of most programs and the part everyone wants to do last. Each time it slips, ask why specifically, not whether it is on track. "We are sequencing it appropriately" is not an answer. A program that cannot show you migrated data working in the new system with six weeks to go is a program that will go live on hope.
4. Nobody can state what is explicitly out of scope. Ask the simple question: what is this program deliberately not doing. If the answer is vague, scope is undefined, and an undefined scope cannot be delivered, only declared finished. The ability to name exclusions crisply is the single best proxy for whether a program is actually under control.
What to do when you see one
The board's job here is not to fix the program. It is to refuse to accept the comfortable answer. When you see one of the four, the correct move is not to demand a recovery plan, because a recovery plan is just the next green report. The correct move is to ask for the thing the signal is hiding: the trend behind the status, the deferred work behind the held date, the migrated data behind the reassurance, the exclusions behind the scope. You are not auditing the technology. You are testing whether the people running the program can answer in specifics or only in comfort. Comfort is the failure mode.
The honest part
I have watched capable teams run programs into the ground while every report said green, and the failure was almost always knowable two quarters early by someone who asked the four questions and did not accept the soothing version of the answer. The technology was not the problem. The unwillingness to hear a red status was the problem, and that unwillingness usually started above the program, not inside it. Oversight that only wants good news manufactures programs that only report it.
If you sit on a board or run a leadership team overseeing a modernization program and want an independent read on whether the green is real, that is a conversation I have without the program team in the room.
This is part five of a six-part series. Part six is the capstone: whether your technology is actually ready for the AI agents every executive is now being asked about.
Frequently asked questions
Why do digital transformation and modernization projects fail?
Rarely for technical reasons. They fail on underestimated data migration, scope that grows while the date holds, oversight that performs rather than exercises control, and status reporting that stays green because red has a political cost. These are management failures, and they are visible from the board.
What are the warning signs an IT project is in trouble?
A status that is stable then suddenly red, scope rising while the date does not move, data migration repeatedly deferred, and an inability to state crisply what is out of scope. Any one of these warrants pressing for specifics.
How can a non-technical board member oversee a technology program?
By asking four questions: show me the status trend not the current state, what has been deferred to hold this date, show me migrated data working, and what is explicitly out of scope. The board's role is to refuse comfortable answers, not to fix the technology.
When is a modernization program actually in trouble?
Usually one to two quarters before it is reported as such. The signals are present early and visible from the boardroom, but they resemble normal friction until acknowledged, which is why oversight that only accepts good news fails to catch them.