Running my own businesses for twenty years, I rarely had time or resources for elaborate project artifacts: no lengthy business cases, no thick status reports, no RAID logs reviewed in weekly governance meetings.
What I had instead was a very clear, constant focus on one thing: whether the customer was getting what they needed and whether it was making a difference to them. That sharpness of focus, born entirely out of necessity, meant the outcome was always at the forefront of my mind.
When I moved into large organisations, I noticed something interesting. The artifacts are all there. Business cases, project plans, risk registers, and status reports. Done well, these tools are genuinely useful. They exist to keep teams aligned, surface problems early, and maintain transparency.
But in many organisations, they become the focus rather than the means. Teams spend enormous time keeping documentation up to date and demonstrating compliance with the process. The artifact becomes the goal. The outcome becomes an afterthought.
How it happens
It usually starts with good intentions. Governance structures are put in place to create consistency and oversight. Templates are standardised. Reporting cycles are set. All of this is reasonable.
The problem is that over time, the process begins to consume the work. A project manager spends more time preparing for the weekly steering committee than they do understanding whether the programme is actually solving the right problem. A business analyst produces a requirements document that satisfies the sign-off checklist but does not reflect what the business actually needs. A risk register is updated on schedule, but nobody is genuinely engaging with whether the risks on it are the ones that matter.
The signals are usually there if you look for them when people talk more about the reporting cycle than the delivery. When the conversation in a governance meeting is about whether the RAG status is accurate, rather than what needs to happen next. When a programme is described as on track while everyone involved privately knows it is not heading anywhere useful.
In financial services, where governance requirements are substantial and audit trails matter, the pull toward artifact compliance is particularly strong. There is a real tension between the rigour that regulated environments legitimately require and the outcome focus that effective delivery demands. The organisations that manage this well are the ones that treat governance as a tool for informed decision-making, not as an end in itself.
Where scope comes in
Scope is often where this unravels. When it is not grounded in outcomes and value from the start, three things tend to happen.
Thinking is not done properly up front, so the scope is almost always the wrong size. Either it is too narrow and misses critical dependencies, or it is too broad and creates a programme that cannot be managed. In regulatory change delivery, even a slightly misdirected scope at the outset can mean months of rework and an impossible deadline.
Teams rush to deliver before the problem is properly understood. Pressure to show progress, to demonstrate that something is happening, leads to design and build work starting before the requirements are genuinely clear. In a business-as-usual project, this is expensive. In a regulated programme with a fixed deadline, it can be catastrophic. And when things go wrong, a lack of risk tolerance and no real permission to fail means decisions get syndicated endlessly rather than made. Nobody wants to own a call that turns out to be wrong. So the decision goes to a working group, then to a steering committee, and then to further analysis. By the time a decision is made, the window for acting on it may have passed.
What AI changes and what it does not
AI offers a real opportunity here. Automating routine documentation, drafting status reports from structured data, and flagging inconsistencies in plans all free up time that project managers and team members currently spend on artifact maintenance.
That time can be redirected toward the things that actually determine whether a programme succeeds: understanding stakeholder needs, making clear decisions, leading teams through complexity, and staying anchored to outcomes when the process is pulling in the other direction.
But AI will not replace judgment. It will not tell you whether you have defined the right scope. It will not spot that the governance structure is creating bottlenecks rather than resolving them. It will not notice that the programme has drifted from its original purpose. Those are human responsibilities, and they require the kind of clear thinking that is harder to maintain when your attention is consumed by documentation.
What good looks like
The best project managers hold both things in mind at once. A rigorous focus on delivery and a clear-eyed sense of purpose. They know what success looks like after the project closes, and they keep that in mind from day one.
They use the artifacts as tools. The business case is a reference point for decisions throughout delivery, not just a justification for starting. The risk register is a live conversation about what actually matters, not a compliance exercise. The status report is a signal to stakeholders, not a performance of control.
They also know when to push back. When the scope is creeping in ways that threaten the outcome. When governance adds delay without adding value. When a programme is described as healthy, when the evidence suggests otherwise.
The discipline of good project management and the instinct to keep the outcome front of mind are not in conflict. The organisations that deliver real value are the ones that manage to hold both at once.
Start every project by asking what needs to be different when it is done, not just what needs to be delivered.
This article is part of a series on programme and project delivery in financial services
