It’s Expensive to “Feel” in Control
Millions lost in the abyss of governance and controls.
There’s a tax nobody puts on the balance sheet. An unnecessary waste and toil that permeates many large organizations.
You can see this happening at almost every large, regulated organisation. They’re running a big program (or a product line) that comes with enormous overhead. Governance. Tracking. Reporting. Risk logs. Status decks. It exists for two reasons that sound unquestionable: the need for regulatory adherence, and the need to feel like risk is under control.
The logic: the more processes I throw at it, the more we’ll know, and the better off we’ll be. Layer in extra people to do all that work, and the program should run like a well-oiled machine. Outcomes happen. Revenue falls from the sky.
If you’ve actually worked in these environments, you know it doesn’t play out that way. The process doesn’t deliver the control it promises. It mostly delivers the appearance of control and an invoice for everyone’s time. That’s the expensive part: you’re not paying for control, you’re paying to feel in control. Senior people spend more hours feeding the machine than steering the program. Every new regulation or product issue adds more process (and sometimes more people!). The firms that come in to “fix” it almost always arrive with the same instinct: a new operating model built on more process for risk mitigation, designed by people who don’t understand how the org works or needs to.
More process is not more control. It’s just more process.
The lean version
There are real ways to solve this. One is to fix the underlying problem, which is usually a blend of changing how you think about satisfying those requirements and discarding the old approach in favour of lean, proactive habits. The other is to automate everything that can be automated, so the requirements get satisfied as a byproduct of the work instead of as a second job.
So I took the leanest spine I could defend (and most common in big orgs):
Business objectives → OKRs → Epics → Stories.
That’s it. Everything traces back to an objective. Nothing exists because a template demanded it…and yes, a lot of it resides within JIRA. (but you can plug in whatever tool you want)
Then I built an agentic network around it called pgmIQ to automate the majority of the governance and overhead that normally sits on top of that spine.
What pgmIQ actually is
pgmIQ is a network of specialized AI agents, fifteen of them, each owning one slice of program management. Planning. Risk. Finance. Compliance. Reporting. Governance. Communications. My favourite is the memory agent that captures all of the tacit knowledge for use later on when you’ve already forgotten about it. A single orchestrator sits at the centre and routes each request to the agents that should handle it.
The mental model that matters: it’s not one AI trying to do everything. It’s a team of narrow ones that are structured work with each other, the way a well-run PMO actually divides labour, except it runs on demand. (note pgmIQ doesn’t replace PgM or PMs - it enables them to do more of their best work)
A few things it does, concretely:
Reporting is pulled, not produced. A program report that used to take days and a roomful of people is now generated on demand, straight from the live systems. Ask for it; it’s there.
The backlog builds itself. Set your OKRs for the quarter, and Jira (yes, Jira) gets auto-populated with epics and stories, giving you real traceability from requirement through to design and delivery, without the manual data entry that nobody enjoys and everybody half-does.
Risk runs continuously, not at gate time. Risks are identified and escalated on deterministic reasoning, as the program moves, not assembled in a scramble before a steering committee. (More on what that catches below.)
The one design decision everything hinges on
If you build this kind of thing for regulated finance, there’s exactly one principle you cannot get wrong:
The AI writes the narrative. The rules decide.
Risk levels, thresholds, classifications: those are deterministic. Hard-coded. Auditable. The AI explains why something is red; it never decides that it’s red. That separation is the whole game. It’s the difference between a tool you can put in front of a regulator and a tool you can’t. A model that “feels” like a risk is amber is a finding waiting to happen. A hard threshold with an AI-written explanation attached is something you can defend.
That’s not a technical footnote. It’s the reason the thing is allowed to exist in this industry at all.
No more PowerPoint
PowerPoints are the worst. I’ll say it. Unless they’re all images telling a story, they’re painful to make and painful to sit through. And worse, they’re stale the minute they’re published. You spend days building a status deck that describes a program as it was on Tuesday, and you present it on Friday to people making decisions for next month.
That staleness is the argument for the whole approach. When the report is generated on demand from live data, it’s never out of date, because it isn’t a manufactured artifact sitting on a shelf. It’s the current state of the program, on request. The deck was never the point. Knowing where things stand was.
The kind of thing that falls into the void
Let me be specific about what “risk surfaces late” actually means. In a program with months of discovering, designing, building and deploying, the most expensive failures aren’t dramatic. Some things quietly slip into a gap nobody was watching:
The architecture sign-off that never got reviewed. It clears without a real look, and the scalability and resiliency problem it would have caught surfaces later, in production or close to it. Now you’re doing rework you’d already paid to avoid, and the timeline slips to absorb it.
Work that had nothing to do with the strategy. Missing timelines, unclear outcomes, and no named deliverables, so a squad ends up busy doing work that isn’t the right work. They’re not idle. They’re heads-down on the wrong thing, which means the critical-path product work sits behind them and slips, and nobody outside that squad knows it was happening.
The change management gap, even a lightweight one. No one owns how the change lands, so it lands badly. The churn that follows (confusion, rework, people reacting to something they were never told was coming) is entirely self-inflicted and entirely invisible until it hits. (sound program management would bake this into the plan or the methodology agent would spring a risk to be like “hey what about this…?”
The security hole nobody closed. 50 findings get identified and then quietly never addressed, until the go-live plan turns out to be missing the CISO sign-off and you’re deciding if you can avoid contractual egg on your face.
These examples are damaging to your brand and customer trust. (as I’ve said before, trust is everything). They all fell into a blind spot and stayed invisible until it was expensive.
None of these are exotic. If you’ve run programs at scale, you’ve lived through these and figured it out with some heroics.
This is where the millions actually go. Not in a line item anyone approved, but in the rework after an architecture flaw ships, the critical-path slips, the churn from a change nobody managed or continuous reactive planning and management or the launch held hostage by a sign-off had been sitting open for months. The abyss isn’t dramatic. It’s a thousand small things nobody could see, each one cheap to catch early and brutal to catch late. This is compounded interest. This is death by a thousand cuts.
That’s the failure mode pgmIQ is built against. When every piece of work has to trace back to an OKR, the squad building something off-strategy shows up immediately instead of in a retro. When risk and compliance run continuously instead of at gate time, the privacy review that’s about to block you surfaces while there’s still room to move. When the report is the live state of the program rather than a manufactured snapshot, the gap doesn’t get a chance to hide. Traceability isn’t a governance nice-to-have…It’s what makes the invisible visible.
What changes on a normal Tuesday
The pgmIQ advantage isn’t really “faster reports.” It’s what the freed-up time and the early warning do:
People get hours back to think and to decide whether the next piece of work even makes sense to do. (discovery and idea generation…or just simply time to think!)
Risks show up weeks ahead, while you can still do something about them.
Everyone understands what’s going on across the program (and the portfolio)
An exec can walk into any meeting, board or C-suite, and be genuinely confident about where things stand, where they’re heading, and why.
The honest part
Is pgmIQ a band-aid over deeper organizational problems? Partially, yes. And do you need to fix your inputs before you get any value out of it? 100%. Garbage in, garbage out. It’s an old saying that never changes.
But here’s the thing I didn’t fully appreciate until it was running: that dependency isn’t a weakness, it’s the mechanism. The tool sets a new standard for how the work has to be structured (objectives, OKRs, clean traceability) and then it drags the team toward that standard, because the value only shows up when the inputs are clean. It doesn’t wait for you to become disciplined. It makes discipline the path of least resistance. Expectations are set for a new way of working, the team adopts it, and the tool becomes a force multiplier on top of that. The train is now going in this direction. Get on board.
The behaviour change and the tool aren’t sequential. They’re the same move.
What I took away from building it
Two things stuck with me.
The first is technical and frankly just fun: I learned how to build an agentic network end to end, and it turns out to solve a real problem, not a toy one. That combination is rarer than it should be.
The second is the one I keep coming back to: it is staggering how much time in regulated companies is spent on program and product governance rather than on the actual product. Once you can see that cost line by line (the reviews found late, the off-strategy work, the gaps nobody clocked), you can’t unsee it.
I’ll leave you with this final thought…
Conway's Law: Products reflect organizational communication channels.
If your org runs on mediocrity and admin overhead, plan for your products to carry the same. The way your teams grow and operate is one of the biggest levers you have, right up there with revenue and customers. Underinvest in it and you feel it everywhere: systems that don’t scale, risk exposure, stalled revenue, eroded trust in what you put out.
So the north star shouldn’t be operational efficiency. It should be growth, performance, and enabling your people to do their best work. Chase that, and the efficiencies come for free, because growth-minded people will eliminate toil. Chase efficiency alone and you will simply get a leaner version of the same overhead.
pgmIQ is one answer to that: a way to let teams do what they’re actually good at, instead of paying for the feeling of control every quarter.
pgmIQ is currently in early MVP phase. I’m open to demos, and to great conversations with people living the same problem. Let’s chat!
Thanks for reading.