A project rarely turns red on the day the dashboard changes colour. The evidence was usually there weeks earlier.
Every delivery leader knows the project.
It was green in the steering pack, amber in the conversations after the meeting and already red in the heads of the people doing the work.
Then, one Thursday, the dashboard finally caught up with reality. The milestone moved. The budget changed. An executive asked why nobody had raised the problem earlier.
Someone had. Usually several people had. The evidence was sitting in Jira, the risk register, a supplier email, a resource plan, a finance variance and three carefully worded meeting notes. What failed was not the absence of information. It was the organisation’s ability to connect it before optimism edited the story.
We have digitised the reporting, not fixed the truth
Delivery has spent decades buying better systems of record. We moved the plan into scheduling tools, the work into agile boards, the money into finance platforms, the risks into registers and the conversation into collaboration tools.
Each decision made sense. Together, they created an industry in which the truth is distributed across more systems than any leader has time to read.
The response has generally been another dashboard. But a dashboard can only display what somebody has already structured, reconciled and decided is safe enough to publish. It is excellent at showing the agreed version of reality. It is far less reliable at finding the contradiction between the plan and the evidence.
That contradiction is where projects fail.
The people closest to the work already know this
Program directors, PMO leads, test managers, architects, finance partners and workstream leads develop a kind of pattern recognition that is difficult to explain in a methodology.
They know that a dependency described as “being worked through” is sometimes a decision nobody wants to own. They notice when the same risk is rewritten for the fourth month instead of retired. They hear the change in language when confidence falls before the status does.
Until recently, that judgement stayed inside the operator. Turning it into software required funding, a product team and enough engineering capacity to survive the organisation’s other priorities.
AI has changed that equation.
The next delivery platforms may be built from the inside out
An experienced operator can now take the patterns they have accumulated across twenty years and begin turning them into a working product in weeks rather than years.
That does not mean typing “build me a PMO tool” into an AI assistant. Generic software creates generic answers. The value comes from knowing what evidence matters, which signals are misleading, how delivery language changes under pressure and where an automated conclusion would be irresponsible.
This is the territory in which I built Lighthouse.delivery.
Lighthouse does not begin with the status somebody selected. It begins with the underlying evidence. It joins signals across delivery, looks for contradictions, challenges optimism and helps a leader understand what is likely to happen next.
It is not an attempt to replace project managers or automate accountability. It is an attempt to give both a better starting point: less time collecting the story, more time testing whether the story is true.
AI makes experience deployable—not optional
The loudest AI narrative says knowledge work will be stripped of expertise. My experience building Lighthouse suggests almost the opposite.
When software becomes cheaper to produce, the relative value moves towards judgement: selecting the right problem, recognising a dangerous answer, knowing what “good” looks like and understanding the human consequences of being wrong.
A coding agent can generate a risk screen. It cannot give itself memories of a board meeting in which a perfectly green program suddenly required another $40 million. It cannot feel the difference between a team raising a healthy concern and a team that has stopped believing anyone is listening.
Those lessons belong to the operators. AI simply gives them a new way to express what they know.
This should make the delivery software industry uncomfortable
Traditional software companies have been protected by the cost of building. They could sell broad platforms and leave each customer to construct the judgement layer through process, consultants and heroic individuals.
That protection is weakening.
A PMO leader who understands one neglected decision better than a large vendor can now build narrowly around it. A test leader can productise the signal they have always seen before release failure. A benefits specialist can challenge the fiction that delivery and value are separate reporting streams.
They do not need to replace the enterprise stack. They can build the missing intelligence between the stack and the decision.
A challenge to the people who have lived the problem
If you have spent a career saying “the tool should really tell us this”, the cost of testing that belief has changed.
Start with the failure you understand unusually well. Find the evidence that existed before it happened. Identify the decision that would have changed the outcome. Then build the smallest useful mechanism that brings those things together.
Do not begin with features. Do not begin with AI. Begin with the truth your industry keeps discovering too late.
The next generation of delivery intelligence may not be invented in a software boardroom.
It may be built at 11:47pm on a kitchen table by someone who has already sat through the meeting where the dashboard was green and the project was not.