Category Archives: Project Management

Pre-Mortem: Anthropic’s Wall Street Agentic AI Suite

Posted on by

 

Thirteen of the world’s largest financial institutions just deployed ten autonomous AI agents into the most regulated workflows in finance. None of them has publicly named who is accountable when the agents are wrong. Not the banks. Not the vendor. Not the regulators. The launch on 5 May reads like a milestone. Read closer and it reads like a stress test of every governance assumption the financial services industry operates on.

A post-mortem tells you why something failed once it already has. A pre-mortem asks the same questions before failure is possible. Same five questions, every time, applied to a current programme, announcement, or initiative. This is the first in the series, and the subject is not chosen by accident. The Anthropic Wall Street launch is the clearest example I have seen this year of capability racing ahead of the architecture meant to hold it to account. If you are a CIO, a CRO, or a transformation lead in a regulated industry, the lessons here apply to you whether you are deploying Claude or not.

 

The Bet

Anthropic and the deploying banks are betting that ten autonomous agents can land in the most regulated workflows in finance, underwriting, KYC, credit memos, statement audits, faster than the regulatory architecture can constrain them. The technical bet rides on Claude Opus 4.7’s 64.37% on the Vals AI Finance Agent benchmark and AIG’s quoted 88% accuracy on insurance claims out of the box. The strategic bet is that being first at this footprint, including JPMorgan Chase, Goldman Sachs, Citi, AIG, BNY, Carlyle, Mizuho, and Visa, outweighs whatever comes back from regulators in the next twelve months. Reasoned bets, made by an extraordinarily capable vendor and the most sophisticated buyers in the world. But they are bets, not certainties, and the launch reads as certainty. The CIO of any one of those banks is taking on operational, regulatory, and reputational risk for which the vendor has accepted no published share. That is the bet they should be examining most carefully.

 

The Assumption

One belief is doing all the work: that bank operating models can absorb ten simultaneously deployed agents without the human-in-the-loop quietly thinning where the agents prove reliable. Anthropic’s own commitment depends on it, from the primary announcement: “Users stay firmly in the loop, reviewing, iterating on, and approving Claude’s work before it goes to a client, gets filed, or is acted on.” The history of automation in regulated environments tells a different story. Algorithmic trading kill switches were not triggered because the system was performing. Automated underwriting reviews became rubber stamps once approval rates looked normal. Every automation failure in regulated finance follows the same arc: human oversight erodes invisibly as the system proves itself, and the erosion is only visible after the failure. JPMorgan CIO Lori Beer said it directly at the launch: “The technology can do so much. It’s the actual organization’s ability to digest and absorb it.” That ability is the load-bearing assumption. If it holds, the launch is a milestone. If it does not, the launch is a slow-moving incident.

 

The Sequence

Capability shipped. Ten named agents, Microsoft 365 generally available, Moody’s embedded, more than a dozen banks in production. What was committed before the operational governance for vendor-supplied agentic decisioning was published: all of it. Three weeks earlier, the Fed and the OCC revised Model Risk Management guidance and explicitly excluded agentic AI as “novel and rapidly evolving.” A Request for Information is planned, with no committed timeline. The EU AI Act’s high-risk financial-sector requirements take effect 2 August, twelve weeks after launch. The FCA and PRA decided against creating a dedicated AI Senior Management Function and instead mapped accountability onto existing SMFs that were never designed with autonomous agents in mind. Three jurisdictions. Three different gaps. One vendor launch landing in all of them at once. This is not a regulator being slow. This is a regulator explicitly stating that the rules do not yet apply, while the systems the rules are meant to govern are already in production.

 

The Pager

The banks have named regulatory accountability at the firm level. SMF24 (Chief Operations), SMF4 (Chief Risk Officer), SMF16 (Compliance Oversight) at FCA and PRA-regulated firms hold statutory responsibility for technology, risk, and compliance. Model risk owners at US firm level cover the same ground. Real, senior, public. That deserves credit. However, none of them have been publicly named for the deployment of these specific agents. Inheriting accountability through a job description is not the same as being named as the accountable owner of a programme. The first is the regulatory default. The second is what serious AI governance actually requires. Anthropic has no published vendor accountability commitment for autonomous regulated decisioning. The asymmetry is the entire story. When a Claude-built agent denies a loan that should have been approved, or approves a KYC file that should have been escalated, the pager rings at the bank, with consequences for the bank, while the vendor’s exposure is contractual and capped. The clearest demonstration came six days before the launch itself. On 29 April, Goldman Sachs removed Claude access for its Hong Kong bankers over contractual, regulatory, and geopolitical factors. The bank pulled the product. The vendor did not pull itself out. Whoever absorbs the cost when regulatory fit fails, absorbs it alone. Until vendor accountability is publicly framed, every bank deploying these agents is underwriting risk the vendor will not.

 

The Proof

Two outcome measures have been published. 64.37% on Vals AI. 88% on AIG insurance claims out of the box. Both are useful. Neither measures regulated-decision accuracy at scale. There is no committed measure for customer-detriment rate, near-miss frequency, incident reporting cadence to regulators, or the rate at which human reviewers actually amend agent outputs versus rubber-stamp them. The banks deploying these agents do not yet have public outcome commitments either, and that absence is its own answer. Former CFO Alyona Mysko captured what is at stake: “In finance, 99% correct is still wrong.” In eighteen months, the question “did this work?” will be answered by whoever owns the platform to define what work means. Right now, that platform is the vendor’s marketing. The banks need to claim that platform back, in their own outcome language, before the metric is set by a third party with no skin in their game.

 

Verdict

The launch is genuinely significant. More than a dozen named banks in production, industry-leading benchmark performance, audit logs in the Claude Console, the deepest Microsoft and Moody’s integrations any AI vendor has shipped. None of that is in dispute.

What is in dispute is whether the deploying banks have done the work to fill the accountability gap that the vendor has not closed and the regulators have not yet defined. The lesson generalises beyond Anthropic and beyond banking. Any CIO buying agentic AI in a regulated industry, healthcare, insurance, energy, the public sector, is operating in the same gap, and most have not yet noticed.

The action is concrete. Name the human in your organisation who carries the pager when the agent is wrong. Demand a vendor accountability schedule before you sign, not after. Define your own regulated-decision outcome measure and publish it, so the standard your performance is judged against is one you helped set.

If Anthropic publishes a vendor accountability commitment in the next six months, and a major bank commits to a public regulated-decision outcome measure tied to a named owner, this becomes a case study other industries will study for years. Without both, it becomes the most expensive procurement lesson the industry buys this decade.

The UAE Leads the World in AI Adoption. That Is the Easy Part

Posted on by

 

The UAE’s 70% AI adoption figure is everywhere. Conference keynotes open with it. Board papers cite it. Technology leaders in the region are being measured against it.

It is an impressive number. The UAE leads the world, ahead of a global average of just 17.8%. Government entities are reporting 97% AI tool adoption. Investment in AI infrastructure exceeded AED 543 billion across 2024 and 2025. The commitment is real, it is visible, and it is serious.

But a figure that measures how many people are using AI tools does not tell you whether those tools are being used well, safely, or in ways that will actually compound into competitive advantage. Right now, across the region, adoption has outpaced governance, capability, and leadership readiness by a significant margin.

That is the conversation worth having.

 

The Gap Between Using and Doing Well

A Fast Company Middle East report found that skills gaps, governance issues, and resource shortages are actively hindering AI projects across the UAE and Saudi Arabia. McKinsey found 88% of organisations globally now use AI in at least one business function. In a separate McKinsey study, only 1% of leaders called their own AI deployment mature.

Read that again. 88% usage. 1% maturity.

Most of the adoption conversation is measuring the first number. Almost nobody, anywhere, is meaningfully achieving the second.

This is not a reason for pessimism. It is a reason for precision. Because the organisations that close that gap are the ones that will extract genuine long-term value from the investments being made. The ones that do not will have impressive statistics and quietly disappointing outcomes.

 

What the 70% Figure Actually Measures

Adoption, in most surveys, means someone in the organisation is using an AI tool. It does not mean:

  • Those tools are connected to meaningful business outcomes
  • There is a governance framework determining how AI agents operate, with what access, and under what oversight
  • Leaders understand the capability well enough to ask the right questions of it
  • The organisation has redesigned workflows around AI rather than simply layered it on top of existing ones
  • There is a plan for what happens when something goes wrong

“Adoption measures presence, not performance. A Copilot licence in every seat is not a transformation. It is a starting point.”

 

 

What Sits Underneath the Headline Number

The organisations that will genuinely lead in this environment are not the ones chasing the adoption number. They are the ones building what sits underneath it.

Three things separate the organisations that will compound this investment from the ones that will stall.

  • Governance before scale. As AI agents take on more autonomous tasks, the permission architecture, oversight mechanisms, and human confirmation requirements need to be established before deployment at scale, not retrofitted after something goes wrong. Look at the incidents of the last eighteen months. Production databases deleted. Cloud environments wiped in seconds. All of it the consequence of deploying capability ahead of governance.
  • Leadership readiness, not just technology literacy. Most AI adoption programs focus on upskilling employees to use tools. Far fewer focus on equipping leaders to make good decisions about AI: what to deploy, what oversight to maintain, what risks to accept, and what questions to ask the vendors selling them the infrastructure. “Technology literacy and leadership readiness are not the same thing.” Confusing the two is one of the most common and costly mistakes being made right now.
  • Workflow redesign, not workflow overlay. The organisations getting lasting value are not the ones that added AI to existing processes. They are the ones that redesigned the process around what AI can actually do. That requires change management discipline, not just technology deployment.

 

The Region Has the Ambition. Now It Needs the Architecture.

The UAE’s strategic commitment to AI is not in question. A 543AED billion investment, a world-first framework to deploy agentic AI across government, a national curriculum introducing AI literacy from school level. These are not the moves of an economy dabbling. This is a serious long-term play.

That is exactly why the governance and capability conversation matters so much right now. The investment is in place. The infrastructure is being built. The adoption numbers are world-leading.

The question is not whether the UAE is committed to AI leadership. It clearly is. The question is whether the organisations operating within that environment are building the internal foundations to convert the headline numbers into durable, compounding advantage.

A 70% adoption rate is the beginning of the story, not the destination.

 

The Organisations That Will Lead Are Already Asking Different Questions

They are not asking how to get their adoption rate up.

They are asking what good looks like once they get there. Who is accountable for how their AI agents behave. What their governance architecture looks like for the autonomous systems they are deploying. What they are actually measuring to know this is working.

Those organisations will not be the loudest voices at the next conference. They will be the ones with something real to show for it in three years.

The UAE’s 70% AI adoption figure is everywhere right now. It is genuinely world-leading, and it is not the number that should be keeping leaders awake at night.

Globally, 88% of organisations use AI. 1% have reached actual maturity. That is the gap worth talking about, and the organisations closing it are not the ones chasing higher adoption rates.

The question I keep coming back to: if your organisation is sitting in that 70%, who is actually accountable for how your AI agents behave once they are deployed?

The Architecture Is the Problem, Not the Agent

Posted on by

 

Every time an AI agent causes a catastrophe, the conversation goes to the same place. What did the AI do wrong? Can these systems be trusted? How do we stop it happening again?

Those are the wrong questions. And the wrong questions lead to the wrong fixes.

The better question, the one that actually leads somewhere useful, is this: who built the environment where it could happen?

 

Three Incidents. The Same Root Cause.

PocketOS, April 2026. An AI coding agent found an unscoped API token sitting in an unrelated file. It used that token to delete a storage volume on Railway, their infrastructure provider. It did not check whether the volume was shared across environments. It was. Production database and every backup, gone in nine seconds.

Replit, July 2025. An AI agent deleted over a thousand executive records during an explicit code freeze. Nothing stopped it because nothing had been configured to stop it.

Amazon Kiro, December 2025. An AI agent inherited a senior engineer’s elevated permissions, the kind that would normally require two people to sign off on a destructive action. It deleted and recreated an entire cloud environment. Thirteen-hour outage.

In every case, the agent did something it was technically permitted to do. Not something it was asked to do. Something it could do, because the architecture said it could.

That is not an AI failure. That is a design failure.

 

We Are Asking Questions About the Wrong Moment

The instinct to interrogate the AI is understandable. These systems are new, they are powerful, and when they cause damage the natural response is to look at the machine.

But that framing lets the actual problem off the hook. In each of these incidents, someone made decisions about credential storage, access scopes, permission inheritance, and whether destructive actions should require human confirmation before execution. Those decisions created the conditions. The agent had the speed and autonomy to find the gap before anyone noticed it was there.

“The incident is never the origin.” Every one of these failures has a human design decision sitting upstream of it.

 

CIOs and CTOs Own This

This is where the conversation needs to land, and where it rarely does.

CIOs and CTOs set access models. They decide, or delegate the decision about, what credentials AI agents can reach, what permissions they inherit, and whether irreversible actions require a human confirmation step. These are not AI product decisions. They are infrastructure and governance decisions of the kind that technology leadership has been making for years.

The least-privilege principle has been a security standard since the 1970s. Every process should have only the access it needs and nothing more. We have applied it carefully to service accounts, automated pipelines, and human users for decades. We are not applying it with the same rigour to AI agents. The gap is showing up in production.

 

Three Questions That Determine Your Exposure

If you are deploying AI agents and cannot answer these clearly, you have a governance problem. It is a matter of when, not if.

  • Are your AI agents operating on minimum permissions? Or are they inheriting ambient credentials that happen to be accessible in the environment? Unscoped tokens stored in accessible files are a credential hygiene problem. AI agents now have the speed to exploit them in ways a human operator simply would not.
  • Do irreversible actions require human confirmation before execution? Not a log entry after the fact. A genuine gate, before the command runs. Deletion, overwrites, production deployments. These should not be single-step autonomous operations regardless of how capable the agent is.
  • What is the blast radius? Before any AI agent is deployed, you should be able to answer: what is the worst thing this agent could do with the access it currently has? If that question gives you pause, the deployment is not ready.

These are not new questions. They are the questions we have always asked about automated systems. The difference is that AI agents are faster, more capable of creative problem-solving, and more likely to find an unintended path that nobody anticipated during design.

 

Governance Does Not Require a New Platform

Much of the current enterprise AI governance conversation focuses on model behaviour: hallucination, bias, output quality. Those are real concerns. They are not the ones that will delete your production database.

The vendors now selling AI governance infrastructure are not wrong about the problem. But executives should make their own assessment of what their environment actually needs. “Governance does not require a new platform. It requires applying principles you already know to systems you are now deploying.” When vendors know the renewal depends on value delivered rather than fear managed, the conversation changes quickly.

 

The Agent Did Not Design the Environment

The uncomfortable fact sitting underneath every one of these incidents is that the AI agents involved were, in a narrow technical sense, doing their jobs. They identified a problem and attempted to fix it. They used the access they had. They executed what was permitted.

The humans who made the architectural decisions upstream of those moments are the ones who need to answer for the outcomes.

You cannot fix an architecture problem by retraining the model.

Your Project Isn’t Behind Schedule….Your Culture Is

Posted on by

Every project has two timelines.

The first one lives in the plan. It has milestones, dependencies, resource allocations, and a go-live date that everyone has committed to in the presence of leadership. It is colour-coded, regularly updated, and presented with confidence at every steering committee.

The second one is invisible. It is being negotiated silently, every day, by the culture surrounding the project. It moves at the speed of trust. It stalls at the friction points of unresolved conflict, political caution, and the gap between what people say in a workshop and what they actually do when they return to their desks.

The first timeline is managed with precision. The second one is almost never managed at all.

And yet, in almost every failing project I have witnessed across 20 years of complex programme delivery, it was the second timeline that determined the outcome.

“The project was a symptom. The culture was the condition. And we spent the entire time treating the symptom.”

The Invisible Force Shaping Every Project

Culture is not a soft concept. It is not the values statement on the intranet or the tone of the all-hands presentation. It is the accumulated weight of how decisions actually get made, how conflict actually gets handled, and how safe people actually feel when they need to say something that the room does not want to hear.

When that culture is aligned, transparent, and psychologically safe, the effect on project velocity is extraordinary. Decisions happen faster because people trust the process. Problems surface earlier because raising them feels safer than absorbing them. Teams move with a coherence that no methodology can engineer, because the invisible conditions that enable collaboration have been built into the environment.

When the culture is misaligned, fragmented, or fear-driven, the opposite is true. And the destruction is systematic. It operates in every layer of the project simultaneously, and it is almost impossible to diagnose from a status report.

How Culture Creates the Ebbs and Flows

If you have delivered a complex project, you will recognise the pattern even if you have never named it in cultural terms.

The project starts well. There is energy in the kick-off. Stakeholders attend. Leadership is visible. The novelty of the initiative creates a temporary social cohesion that feels like alignment but is actually closer to politeness. People show up. The culture cooperates, at least on the surface.

Then comes the middle phase. The novelty fades. The real work begins to create friction with existing priorities, existing reporting lines, and the existing distribution of power within the organisation. This is where the culture stops pretending and starts expressing itself.

  • The stakeholder who supported the project in principle begins finding reasons why each individual decision needs further review.
  • The team that attended every workshop begins quietly reverting to the processes the project was designed to replace.
  • The escalation that should have reached the steering committee disappears somewhere in the middle management layer, because the culture has an unspoken norm that problems travel upward only when they are already solved.
  • The two departments that were supposed to collaborate begin protecting their own interests, because the project has started to expose a territorial conflict that existed long before any of this began.

None of these dynamics appear on a risk register. They do not generate a red status in the weekly report. They show up instead as decisions that take longer than expected, deliverables that require more rework than they should, and a general sense that the project is moving through something viscous, that progress requires more energy than the plan anticipated.

This is not a project management problem. It is a cultural one. And the distinction matters enormously, because the tools you use to fix a project management problem will not address a cultural one. More governance does not resolve a territorial conflict. More reporting frequency does not create psychological safety. A revised timeline does not fix a leadership vacuum.

“Culture doesn’t self-correct. It calcifies. And it takes your project with it.”

The Myth of Self-Correction

One of the most expensive assumptions in organisational life is that cultural problems, if managed carefully and given enough time, will eventually resolve themselves. That the tension between two departments will settle once both sides see the project delivering results. That the resistant stakeholder will come around once the early wins become visible. That the team will find its rhythm.

I have never seen this happen. Not once, across 20 years and dozens of complex programmes.

What I have seen, repeatedly, is this: cultural dynamics are self-reinforcing. The silo that existed before the project started will be deeper after it ends, unless a leader has actively and deliberately intervened. The resistance that began as scepticism will harden into obstruction unless someone with sufficient authority named it, engaged with it, and changed the conditions around it.

Choosing to wait and see on a cultural problem is not a neutral decision. It is an active choice to allow the problem to compound. And at some point in every project timeline,  often somewhere in that difficult middle phase, a compounding cultural problem crosses a threshold beyond which recovery becomes genuinely unlikely, regardless of what the project plan says.

Why Top Leadership Cannot Afford to Delegate This

This is where the responsibility conversation becomes uncomfortable.

Most senior leaders understand, intellectually, that culture matters. They have read the research. They can quote the statistics. They believe, in principle, that cultural alignment is a prerequisite for successful delivery.

And then they appoint a capable programme manager, approve the governance framework, set the reporting cadence, and quietly exit from the environment that will determine whether the project succeeds.

They remain present for the milestone reviews. They sign off on phase completions. But the cultural conditions that are either enabling or strangling delivery, the political dynamics, the unresolved departmental conflicts, the leadership behaviours creating drag at every level, those remain unaddressed. Because they are harder to put on a slide than a RAG status.

The problem is that no programme manager in the world has the authority to fix what only senior leadership can. A project manager can flag a cultural risk. They cannot resolve a conflict between two executive stakeholders. They can surface a pattern of passive resistance. They cannot change the norm that makes resistance feel safer than engagement. They can manage the process. They cannot change the environment.

“The culture of a project is a direct reflection of the culture of the organisation. And the culture of the organisation is set, every day, by the behaviours of its most senior leaders.”

When leadership is genuinely present in a project, not just at steering committees, but in the informal conversations, the moments of ambiguity, the points where the culture is deciding how to respond to a challenge, the trajectory changes. Not because of any specific intervention, but because the culture takes its signal from what leadership pays attention to, tolerates, and rewards.

When leadership is absent from those moments, the culture fills the vacuum with its own defaults. And the defaults are almost always conservative, territorial, and risk-averse. Exactly the opposite of what a complex change project requires.

What Active Cultural Leadership Looks Like in Practice

This is not an argument for leaders to become project managers. It is an argument for leaders to understand that sponsoring a project and leading its cultural environment are two different responsibilities, and that only one of them can be delegated.

Active cultural leadership in a project context looks like this:

  • Naming the cultural dynamics that are creating drag,  not as project risks, but as organisational behaviours that leadership is choosing to address.
  • Creating visible and consistent accountability for the behaviours the project requires, not just the deliverables it produces.
  • Being present at the moments when the culture is deciding how to respond to difficulty, and modelling the response you need it to make.
  • Making it safe for the people closest to the work to surface the real picture, not the managed version of it.
  • Understanding that alignment at the top does not automatically produce alignment throughout, and actively working to close that gap.

None of this is comfortable. It requires a kind of candour about the organisation’s own cultural health that many leadership teams find easier to defer than to confront. It requires treating the cultural environment of a project as a leadership responsibility rather than an HR consideration. And it requires accepting that the most powerful variable in project delivery is not the methodology, the technology, or the talent. It is the environment in which all three are being asked to operate.

The Question Worth Asking

The next time a project in your organisation begins to slow, when the milestones start slipping, when the energy in the team shifts, when the steering committee updates start sounding more optimistic than the reality on the ground, resist the instinct to look first at the plan.

Ask instead: what is the culture around this project telling us?

Is it telling you that people feel safe enough to surface the real problems? Or that the real problems are being managed privately, because surfacing them carries too high a risk?

Is it telling you that the organisation is genuinely aligned behind this change? Or that the alignment is a performance, present in the steering committee and absent in the daily decisions of the people who actually have to deliver it?

Is it telling you that the conditions for this project to succeed have been built into the environment? Or that the project has been launched into a culture that was never prepared for what it requires?

The answers will tell you more about where your project is actually heading than any Gantt chart you have ever reviewed. And they will tell you something else, something harder to hear but more important to act on:

“The project is not behind. The culture is. And that is a leadership problem, not a project management one.”

If this resonated, explore more at scottz.com or connect with me on LinkedIn.

What 20 Years of High-Stakes Delivery Taught Me About Execution, and the Difference Between Programme Management and Programme Leadership

Posted on by

 

I have stepped into programmes where every governance box was ticked, every RAG status was green, and delivery was quietly failing. The plan looked solid. The reporting was clean. The steering committee meetings ran on time. And yet nothing was really moving.

That pattern, visible control with invisible dysfunction, is what two decades of high-stakes delivery teaches you to recognise. And it almost always comes back to the same root cause. We confuse programme management with programme leadership.

 

Programme Management Keeps Things Moving. Programme Leadership Makes Them Work.

Most organisations lean heavily into programme management, and it is easy to see why. Detailed plans, governance frameworks, status reports, risk logs, and steering committees all create a sense of order and control. On paper, everything looks under control.

The problem is that I have stepped into too many programmes where all of that existed and delivery was still failing. Because structure creates visibility, not outcomes. Programme management is fundamentally about control, while programme leadership is about direction, alignment, and energy. One tracks progress while the other makes progress possible. That distinction is where most organisations fall short, not because they lack process, but because they mistake process for leadership.

 

Context Shapes Execution

Here is something that even experienced delivery professionals often underestimate. Execution does not happen in a vacuum. It happens inside a specific organisation, a specific culture, and a specific set of relationships and unwritten rules that no governance framework will ever fully capture.

I have watched highly capable teams arrive with world-class frameworks and strong delivery disciplines and still struggle to get real traction, not because their methodology was wrong, but because the environment was not properly understood. They received agreement in meetings but silence where there should have been challenge. Risks that everyone privately knew about went unsurfaced because the conditions for honest conversation had not been established.

Delivering across the Middle East over the past decade has made this especially clear to me. Execution here is not just operational, it is relational. How trust is built, how decisions are really made, the importance of respect and hierarchy, and the pace at which genuine alignment actually happens are not soft considerations. They are delivery requirements. When you get them right, conversations become honest, decisions become clearer, and alignment becomes real. When you ignore them, execution becomes performative, with activity replacing progress.

The same principle applies in any environment where you are leading in unfamiliar territory. Understanding context is not optional at this level. It is the difference between a programme that moves and one that stalls.

 

The Biggest Mistake: Managing Metrics Instead of People

When delivery starts slipping, most organisations respond in a predictable way. More reporting, more tracking, and more pressure. It feels like a logical response, but it is usually the wrong one, because metrics do not deliver programmes. People do.

I have seen programmes sitting on green dashboards right up until the moment they fail, not because the data was falsified, but because what was not being measured was what actually mattered. Team fatigue, misalignment between stakeholders, lack of psychological safety, and quiet disengagement do not show up in a status report. When people are treated like a line item, engagement drops, ownership fades, and quality begins to slip long before the timeline does. Burn a team out and you do not just lose pace. You lose the judgment, initiative, and honesty that high-stakes delivery fundamentally depends on. No dashboard captures that, but every experienced programme leader eventually learns to recognise it.

 

The Gap Between Manager and Leader Is Where Execution Breaks

This is the gap that most organisations do not even realise they have. They promote strong managers and expect leadership to follow, but the two are not the same thing and they do not produce the same results.

Managers tend to focus on tasks, deadlines, and maintaining control over the plan. Leaders focus on clarity, alignment, and removing the obstacles that prevent capable people from doing their best work. A manager’s primary question is whether the programme is on track. A leader’s primary question is what is getting in the way. That difference sounds subtle, but in practice it determines whether a programme survives pressure or collapses under it.

The best delivery environments I have worked in were not the most heavily governed. They were the most honest. When people feel clear about what success looks like, trusted to make decisions, safe enough to surface problems early, and genuinely supported when things get difficult, they perform at a level that no governance framework can manufacture. When those conditions are absent, no amount of process or reporting will compensate for it.

 

Execution Is a Human System, Not a Delivery Framework

After 20 years, this is the conclusion that becomes impossible to argue against, even if it takes time to fully accept. Execution is not primarily a technical problem. It is a human one.

You can have the right tools, the right frameworks, and the right governance model in place and still fail to deliver if you do not have trust, alignment, cultural awareness, and a team that still has the energy and conviction to push through difficulty. The principles that have held true across every programme I have led, recovered, or stepped into under pressure are consistent. Clarity beats complexity, because people cannot deliver what they do not fully understand. Context and culture are not optional, because they shape how work actually gets done regardless of what the plan says. Sustainable pace matters more than most organisations are willing to admit, because the cost of burning people out shows up in quality long before it shows up in a timeline. And leadership has to be visible not just at the top, but across the programme at every level where real decisions are made and real obstacles are felt.

 

Closing Thought

You can manage a programme perfectly and still fail to deliver it. Execution is not about control. It is about people, and the environment you create around them. The organisations that understand this tend to deliver. The ones that do not keep searching for a better framework when the answer was never in the framework to begin with.

Process Mining in Healthcare: Turning Complexity into Clarity

Posted on by

Healthcare is perhaps the most complex ecosystem on the planet. Unlike banking or retail, where processes are mostly transactional and predictable, healthcare is built on human lives, high-stakes clinical decisions, and layers of regulation.

Every patient journey generates a massive trail of data across admissions, diagnostics, treatment, and billing.

The problem is that most healthcare organizations are drowning in that data but starving for actual visibility. They know the data exists, but they lack a cohesive view of how work actually happens on the ground. This leads to bottlenecks and delays that do more than just drive up costs. They undermine the patient experience.

This is where process mining, comes in. It is a discipline that takes raw data and turns it into a living map of your operations, showing you the reality of your workflows rather than the idealized versions found in your policy manuals.

 

The Traffic Control Problem
Think of a large hospital as a city. Every department is a different neighborhood: pharmacy, radiology, surgery, finance. The patients are the citizens moving through the intersections. If the traffic signals do not sync or if shortcuts are hidden, the result is total chaos.

Process mining acts as the traffic control system for this “city.” It uncovers the hidden routes and signals exactly where the blockages are happening. Unlike a manual audit or a staff survey, process mining relies on the actual digital footprints left in your systems. It moves you away from assumptions and toward a factual, end-to-end view of the patient journey.

 

The Structural Barriers to Change
Digital transformation in healthcare is never just a technology play. It is a cultural and structural battle. You are often dealing with legacy systems that do not talk to each other, creating silos where information goes to die.

You also have to consider the human element. Clinicians are already stretched to their limit. If you ask them to adopt a new tool without showing them how it actually makes their lives easier, you will face immediate resistance. Then there are the stakes. Patient data is incredibly sensitive, making security and compliance a constant, necessary drag on speed. These are the reasons why so many expensive digital projects fail. They layer new technology over broken processes.

 

Where the Real Value Hidden When you apply process mining thoughtfully, you start to see opportunities where there was previously only frustration.

  • Fixing Patient Flow: You can identify exactly why a discharge is delayed or why a lab result is sitting in a queue. If there is a bottleneck, process mining tells you if it is a staffing issue, a system lag, or a procedural flaw.
  • Optimizing the High-Cost Areas: Operating theatres are some of the most expensive hospital assets. In radiation oncology, process mining revealed planning delays that, when fixed, significantly improved throughput and reduced time-to-treatment for patients.
  • Safety and Compliance: In clinical pathways, deviations can be a matter of life or death. Process mining allows for real-time monitoring of treatment protocols, reducing risks for both the patient and the organization.
  • Cutting Administrative Bloat: Claims and procurement processes are often riddled with waste. Research combining Kaizen with process mining has shown how these inefficiencies can be wiped out to create sustainable improvements.
  • Better Outcomes for Patients: Every efficiency gain translates to faster, safer care. Work done on older adult patient journeys shows how identifying systemic choke points can free up capacity across the entire system.

The Foundation for the Future Many leaders see process mining as a “fix-it” tool for inefficiencies. It is actually much more than that. It creates a digital twin of your operations. This provides a foundation for everything that comes next, including AI-driven analytics and automation. You cannot automate a process that you do not fully understand.

The Bottom Line Healthcare is at a crossroads. Costs are rising and resources are thinner than ever. Digital transformation is no longer a luxury, but without clear visibility, your technology investments are just expensive guesswork.

Process mining does not just show you where the cracks are. It gives you the data you need to repair them and the ability to monitor the progress in real time. The result is a hospital that runs like a coordinated ecosystem, giving clinicians more time to do what they do best: care for patients.

How to Ensure Product and Project Teams Work Well Together

Posted on by

Product vs. Project Teams: How to Stop the Friction and Start Delivering

In many organizations, there is a quiet but constant tension between product and project teams.

It is a classic tug-of-war. Product managers are focused on the “what” and the “why,” obsessing over user value and long-term vision. Project managers are focused on the “how” and the “when,” managing timelines, resources, and the reality of deadlines.

When these two forces are out of sync, the results are predictable: missed milestones, feature creep, and a team that is burnt out from trying to serve two different masters. But when they work in harmony, they create a high-velocity engine for innovation.

If you want to move beyond the friction, you have to stop treating these as competing functions and start treating them as two sides of the same coin. Here is how to align your product and project teams for maximum impact.

 

1. Define the Boundaries of Responsibility
The biggest source of conflict is overlapping territory. If the product manager is trying to manage the sprint schedule and the project manager is trying to prioritize the backlog, everyone gets frustrated.

You need clear roles. Product is the guardian of the strategy and the customer voice. Project is the guardian of the execution and the operational flow. When leadership sets the tone for these roles, it removes the guesswork and allows each professional to focus on what they do best.

2. Align on the “North Star” Metric
Friction often happens because teams are being measured by different metrics. Project teams might be rewarded for hitting a specific date, while product teams are rewarded for adoption rates.

To bridge the gap, you need a shared definition of success. Both teams should be anchored in the broader business strategy. If a deadline must be missed to ensure a feature actually solves a customer problem, that should be a collaborative decision based on value, not a battle between “delivery” and “discovery.”

3. Build a Culture of Continuous Communication
Silos are where transformation goes to die. If your product and project leads only talk during formal status meetings, you have already lost.

Effective teams build “radical transparency” into their daily rhythm. This means project managers are involved in discovery sessions to understand the “why” behind a feature, and product managers are involved in resource planning to understand the constraints of the “how.” This shared context prevents the “vision gap” that derails so many digital projects.

4. Manage the “Dependency Dragon” Together
Technical debt and complex system dependencies are not just IT problems. They are the primary obstacles to both product innovation and project delivery.

When product and project teams ignore these hidden issues, they end up with a roadmap that is impossible to execute. By treating technical debt as a shared priority, you can allocate time for “foundational” work that makes future delivery faster and more reliable. This is where augmentation, using tools to simplify these complexities, becomes a strategic advantage.

5. Focus on Outcome, Not Output
A project is “done” when the code is shipped. A product is never really “done.”

Shifting the mindset from output (shipping features) to outcome (solving problems) changes the dynamic between the teams. It moves the conversation away from “Did we hit the date?” to “Did we achieve the impact?” This shift requires leadership to value adaptability over rigid adherence to a plan.

 

The Bottom Line The most successful organizations do not have “product vs. project” cultures. They have “delivery” cultures.

When you stop fighting over who owns the roadmap and start focusing on how to serve the customer better, the friction disappears. You stop being a collection of silos and start being a unified team that is capable of building things that actually matter.

Why Deadlines Aren’t Enough: The Case for Purpose-Driven Project Goals

Posted on by

Why Deadlines are the Wrong Scoreboard for Project Success

For decades, the corporate world has worshipped at the altar of the deadline. Success has been reduced to a single, binary question: did you ship on the date you promised? This obsession with the calendar has created a generation of project managers who are experts at checking boxes but often fail to deliver actual business value.

While timelines are necessary, they are not a guarantee of success. A project delivered exactly on time that fails to solve a customer problem or align with the company’s mission is, by definition, a failure. Worse yet, a deadline-first culture breeds burnout and kills creativity. When the only goal is speed, teams stop thinking about impact and start thinking about survival.

True success is measured by the value you create, not by the date you finished.

 

The Trap of the “Done” List
In many organizations, teams move in a constant state of pressure. They rush through deliverables and overlook user experience just to hit a milestone. This “output over outcome” mindset is exactly how companies end up with digital transformation projects that fail to achieve their intended results.

When you prioritize the date over the purpose, you incentivize people to cut corners. You might get the software out the door by Friday, but if no one uses it because it doesn’t fit the workflow, you have wasted your most valuable resources.

 

The Power of Purpose-Driven Goals
Shifting to a purpose-driven approach means anchoring every task in a clear vision. When a team understands the “why” behind their work, their entire perspective changes. They move from being order-takers to being problem-solvers.

Take a digital transformation initiative as an example. If the goal is simply to “launch the system by Q3,” the team will focus on technical checkboxes. But if the goal is to “reduce patient wait times by twenty percent,” the team will make better strategic decisions about user interface and data flow. They will prioritize what actually moves the needle.

In this model, deadlines do not disappear. Instead, they become milestones that guide progress rather than rigid constraints that stifle innovation.

 

How to Lead with Purpose
Transitioning away from a clock-watching culture requires a deliberate shift in leadership. It involves moving from managing tasks to managing impact.

  1. Define the Problem First: Before you set a date, define the impact. What is the one thing this project must achieve to be considered a success? If the team understands the problem, they will find the most efficient way to solve it.
  2. Align Every Stakeholder: A purpose-driven project requires radical transparency between product and project teams. Everyone from the executive level to the front-line staff needs to be bought into the “why.”
  3. Measure Value, Not Velocity: Tracking points or dates is easy, but it is often misleading. Measure success by tangible improvements. Are users more engaged? Is the workflow smoother? Is the chaos turning into clarity?
  4. Reward Adaptability: Markets move faster than project plans. If a project needs to pivot to stay aligned with its purpose, that should be celebrated as a win, not punished as a delay.
  5. Celebrate the “So What”: When you reach a milestone, don’t just celebrate the completion. Celebrate the result. Show the team how their work actually changed the business.

 

The Bottom Line
The most impactful projects are not just completed on time. They are completed with a purpose that survives long after the launch date.

Ask yourself: is your team racing toward a date on a calendar, or are they moving toward something that actually matters? If you want to build a high-performance culture, you have to stop managing the clock and start managing the mission.

The Value of a PMO in Healthcare

Posted on by

Why the PMO is the Strategic Nerve Center of Modern Healthcare

In most industries, a poorly executed project means a missed deadline or a wasted budget. In healthcare, the stakes are far higher. A botched system rollout or a failed digital transformation does not just hurt the bottom line. It threatens patient safety, compromises regulatory compliance, and erodes the trust that patients place in the system.

This is why a Project Management Office (PMO) in healthcare is not an operational luxury. It is a strategic necessity. A high-performing PMO acts as the bridge between high-level clinical strategy and the boots-on-the-ground execution that keeps a hospital running.

 

Beyond the Checklist: The Core Value of a Healthcare PMO
A PMO provides the structured framework required to navigate one of the most complex environments in the world. It ensures that every initiative, from EHR modernization to telehealth expansion, actually moves the needle on patient care.

  • Strategic Alignment: Healthcare organizations face constant, competing demands. A PMO ensures that resources are not wasted on “vanity projects” but are instead focused on initiatives that align with the mission of the hospital.
  • Rigorous Governance: In an industry defined by HIPAA, GDPR, and local health mandates, compliance must be baked into the project life cycle. A PMO reduces risk by embedding these requirements from day one.
  • Resource Optimization: Clinical staff and budgets are finite. A PMO provides the visibility needed to ensure that the highest-priority projects get the attention they deserve.
  • Managing the High-Stakes Risks: Whether it is cybersecurity or system downtime, the risks in healthcare are massive. A PMO identifies these pitfalls early, preventing small issues from becoming clinical crises.

 

The Cultural Challenge: Winning Over the Clinicians
One of the unique hurdles in healthcare is the perceived friction between administrative discipline and clinical freedom. Many clinicians see a PMO as a source of “red tape.”

Research from a health network in Montréal found that PMOs only succeed when they balance discipline with flexibility. You cannot force a rigid framework onto a clinical environment. Instead, you have to show how the PMO reduces the administrative burden on doctors and nurses, allowing them to focus more on their patients and less on broken processes.

 

Lessons from the Field: Why Some PMOs Fail
We can learn as much from failure as we can from success. The VA’s EHR Modernization program is a prime example of what happens when scheduling is unreliable and user feedback is ignored. Costs escalate and trust evaporates.

Conversely, look at the Mayo Clinic’s model for AI success. They treat their project and data teams as enablers rather than gatekeepers. They foster a culture of safe, transparent experimentation. This proves that the maturity of your PMO is what determines whether your digital transformation actually delivers value.

 

Building a PMO That Delivers
If you are leading or building a PMO in a healthcare setting, success depends on moving beyond “admin.”

  1. Purpose over Process: Every metric you track should eventually lead back to patient outcomes. If a process doesn’t improve care or safety, question why it exists.
  2. Hybrid Methodologies: Use Agile for digital innovation and Waterfall for heavy compliance projects. One size does not fit all.
  3. Executive Sponsorship: A PMO without leadership backing is just a group of people making spreadsheets. You need champions at the board level.
  4. Invest in Data: Use dashboards and real-time analytics to provide accountability. Stronger organizational competence leads directly to better project outcomes.

 

The Future: The Enabler PMO
As we move further into the age of AI and clinical automation, the PMO is evolving. It is shifting from being a “controller” that slows things down to an “enabler” that accelerates innovation safely.

The ultimate success of a healthcare PMO lies in merging process with purpose. In this sector, purpose always starts and ends with the patient. When you get the project management right, you aren’t just shipping software. You are saving lives.

 

How Digital Evolution Fits Into Project and Program Management

Posted on by

Digital Evolution: Why Program Management No Longer Has a Finish Line

In the old world of Project and Program Management (PPM), success was defined by a fixed destination. You had a scope, a budget, and a deadline. If you hit all three, you won. But in an era where digital change moves at breakneck speed, that rigid model is no longer enough.

Today, we are moving away from “transformation”, which implies a one-time shift from state A to state B, and toward digital evolution. This is a continuous process where the target is always moving. In this landscape, PPM is not just about execution. It is about adaptability. It is the backbone that allows an organization to iterate, pivot, and grow in real time.

 

The Shift from Rigid Plans to Agile Iteration
Digital evolution demands that we stop treating projects like high-speed trains on a single track. Instead, we must treat them like adaptive ecosystems. This requires a fundamental shift in how we approach delivery.

  • From Projects to Sprints:
    Instead of long-term “big bang” launches, each project should deliver meaningful improvements in short bursts. These sprints provide early ROI and allow for constant refinement, ensuring the final product actually meets the market’s needs.
  • From Finite Programs to Adaptive Ecosystems:
    A program is no longer a collection of tasks with a clear end date. It is a living entity that evolves alongside the organization’s strategic objectives.

 

The Rise of Adaptive Governance
Traditional governance is often seen as a bottleneck that slows down innovation. However, digital evolution requires governance that is proactive rather than reactive.

Success now depends on adaptive governance, which focuses on outcomes rather than just outputs. This means moving toward real-time monitoring and embedding feedback loops into every phase of the project. A modern Agile Management Office blends structure with flexibility, allowing the organization to stay compliant without losing its speed.

 

Dynamic Portfolios: Moving Beyond Static Roadmaps
In an evolving environment, a roadmap that is set in stone for twelve months is a liability. Your portfolio management must be as dynamic as the market itself.

Strategic prioritization means focusing on high-impact initiatives that deliver immediate value. Adaptive project management ensures that your execution always remains aligned with your strategic direction, even when that direction needs to shift due to emerging technology or new competitors.

 

Continuous Risk Management in the Age of AI
Static risk registers are dead. In a world shaped by AI and decentralized tools, risks emerge in real time.

Modern PPM requires constant scanning of the landscape to detect threats early. By mitigating risks incrementally through small-scale, iterative safeguards, you prevent the catastrophic failures that often plague massive, traditional IT projects.

 

The New Role of the Program Manager
This shift transforms the role of the program manager from a taskmaster to a strategic orchestrator. To succeed in this new era, leaders need a specific set of skills:

  • Change Facilitation: You are no longer just managing timelines; you are stewarding a cultural transformation.
  • Technological Fluency: You must be the bridge that connects evolving technology with human capability.
  • Data-Driven Decisions: You lead with real-time analytics and hard evidence, not assumptions or “how we’ve always done it.”

 

The Bottom Line
Digital evolution does not replace PPM. It elevates it. As research in Digital Transformation in Project Management suggests, the integrated role of technology and governance is now the foundation of corporate resilience.

When you lead with adaptability, your project management office stops being a constraint and starts being a catalyst. You aren’t just delivering change; you are shaping an organization that is built to thrive in a state of constant evolution.