• AI is reducing project timelines and costs 50–80% by speeding up analysis, funding cases, testing, and documentation.

• Integration and automation that once took months can now happen in weeks.

• Less time on setup and more on impact—AI lets nonprofit teams move fast and deliver sooner.

Accelerating the case for funding

Securing funding can take months of effort, especially in nonprofits where every dollar must be justified with clear outcomes. Drafting a compelling business case is traditionally a slow and manual process. But this is changing.

AI tools are helping us move faster by:

• Assembling impact data and cost-benefit analyses quickly.

• Drafting tailored proposals that speak directly to funders’ priorities.

• Running "what-if" scenarios that model different outcomes in minutes.

What previously took weeks or months can now be accomplished in a few days, allowing us to reach decision points faster and act on opportunities while they're still relevant.

Faster, deeper analysis

AI accelerates research and analysis, helping us surface insights without getting buried in raw data. For example:

• It links data across systems—like connecting donor activity with financial results—without hours of manual spreadsheet work.

• It summarises surveys and interviews to identify key patterns.

• It spots issues or trends that may be easy to overlook.

This allows our people to focus on judgement and decision-making, not on data wrangling.

Smarter system integration

Bringing systems together used to mean lengthy custom builds and deep technical skills. AI is streamlining that process:

• It can recommend and generate automations to connect platforms.

• It empowers teams to build working tools without advanced coding.

For example, syncing volunteer rosters from a CRM into a scheduling tool or connecting a donor database to an email platform can now be done in days, not weeks.

Lightweight, scalable hosting

Launching new digital tools no longer requires large infrastructure investments. With today’s cloud and AI platforms, we can:

• Use out-of-the-box platforms to develop and deploy solutions.

• Combine cloud services—like databases, analytics, and AI—without building from scratch.

• Deliver usable tools with minimal IT overhead.

This shifts our time and budget from setup to service delivery.

Confident, reliable testing

AI helps ensure our tools work before they go live:

• It can generate comprehensive test cases based on project documentation.

• It assists in writing code to automate system testing.

This helps us catch issues early and avoid disruptions during rollout, giving stakeholders greater confidence in the outcome.

Clearer, faster documentation

Keeping documentation current is often a burden. AI is making this easier to manage:

• It can automatically produce meeting notes, technical descriptions, and project summaries.

• It transforms rough notes into clear, shareable documents.

This speeds up onboarding, reduces rework, and improves knowledge transfer across teams.

The real delay: project lead-up

Many of our projects take just as long to plan and approve as they do to build. It's not unusual to spend 12 to 18 months on lead-up activities alone.

AI helps compress this front end by accelerating everything from the business case to analysis and design. The result:

• 50% to 80% reduction in time and cost.

• Faster delivery of value to our teams and communities.

• Less waiting, more doing.

The sooner we begin delivering impact, the sooner we strengthen our funding cases, improve our services, and engage our teams in meaningful progress.

When you're ready, here's how I can help:

Andrew Walker 
10 years AI strategy & implementation for executives in staff-heavy organisations, often with mobile workforces.

Did someone forward this email to you? Want your own subscription? Head over here and sign yourself right up!

Back issues available here.

• AI is already embedded in Microsoft 365 and Google Workspace — no new purchases needed.

• Start with integrated, systemic use-cases to get faster ROI and avoid security or procurement delays.

• Buying bundled AI adds complexity — use built-in tools now to deliver value immediately.

AI isn’t something we need to buy from our app vendor

We often think of AI as something we need to acquire—typically bundled into a major new application from a vendor like Salesforce or ServiceNow. But that mindset can slow us down, introduce complexity, and lead to unnecessary spending.

The truth is, we already have AI.

It’s built into the office platforms our teams use every day. Email, documents and shared drives are now part of environments with powerful AI capabilities—readily available through built-in tools and APIs. These aren’t theoretical futures; they’re operational services ready to use today, without buying anything new.

Personal AI vs systemic AI

In our approach to AI, it’s useful to distinguish two modes of adoption:

Personal AI helps individuals. Tools like Copilot in Word or Gemini in Docs assist with summarising, drafting and reducing repetitive tasks.

Systemic AI delivers organisational impact. It integrates across systems using APIs, automates workflows, analyses data and streamlines processes at scale.

The real opportunity lies in systemic use cases—where AI improves how we work across existing systems, rather than adding more tools and complexity.

Start with what we've already vetted

When we start with the office suite we’re already using—Microsoft 365 or Google Workspace—we gain two major advantages:

1. Information security

We’ve already done the heavy lifting. These environments are where sensitive data lives. They are vetted for compliance, privacy and security. Using built-in AI avoids re-running procurement, legal or risk processes for every new service.

2. Budget simplicity

AI capabilities in Microsoft and Google platforms are mostly consumption-based. We don't need to make large up-front decisions. We can activate AI for a specific use case, assess its value and expand as needed.

Immediate action, immediate value

Because there's no need to buy or integrate a new platform, we can move quickly. That accelerates outcomes:

• Reduce manual admin to boost morale and retention

• Increase efficiency and free up team capacity

• Deliver outcomes sooner with fewer blockers

AI adoption doesn’t need to start with a major transformation. It starts with the tools we already have.

Final thought

We don’t need to buy AI. We already have it.

Let’s start with our email and document platforms. Use what’s built in. Test what’s possible. Begin unlocking value now.

And beyond individual use cases, AI is reducing the cost and complexity of implementation projects. What once took three to six months can now be done in one or two. That means faster delivery, more manageable budgets and stronger ROI.

Which makes starting not only easier, but smarter.

When you're ready, here's how I can help:

Andrew Walker 
10 years AI strategy & implementation for executives in staff-heavy organisations, often with mobile workforces.

Did someone forward this email to you? Want your own subscription? Head over here and sign yourself right up!

Back issues available here.

• Incremental delivery means incremental release to real users—not just internal sprints or builds.

• No release, no user adoption; no users, no business benefit—period.

• True incremental delivery is rare but critical, and the best place to start your shift toward benefits-based governance.

Why Benefits-Based Governance Makes Sense

The idea behind benefits-based governance is straightforward. Most executives would naturally prefer a tech change that begins delivering business value from day one, rather than one where benefits are deferred until well after the project concludes.

Rather than interpreting a flurry of secondary outputs — project plans, scope documents, and so on — we can hold teams accountable for the real outcome: the business benefit we’ve committed to deliver.

As with any form of governance, the way we hold our teams accountable is closely tied to how those teams operate day-to-day.

How Delivery Needs to Change

To support benefits-based governance, we need to rethink how delivery works. While there are several important techniques, one stands out: incremental delivery.

This means breaking large, complex projects into smaller, manageable parts and delivering them one at a time.

Why Agile Isn’t Enough

This shift is easy to overlook because many IT teams believe they're already doing this through their agile practices. But in reality, agile has often promoted incremental build, not incremental release.

Agile teams typically work in “sprints” that produce working components. These are usually batched and sent for “user acceptance testing”, before being released all at once toward the end of the project.

The Critical Distinction: Release vs Build

This distinction is critical for benefits-based governance. We can’t unlock any real business value until users are engaging with the new system in their actual work.

What’s commonly referred to as “incremental delivery” in IT would be more accurately called “incremental release”. Unless something is reaching real users, it doesn’t matter — from a benefits perspective — how iteratively we’re building behind the scenes.

No users means no benefit.

The Misconception of Incremental Delivery

The idea of assembling and releasing new technology in small, usable increments is surprisingly rare — despite being widely believed to be the norm.

As executives, it’s important we understand the difference by asking one simple question: how frequently are we releasing into production or live environments?

The answer is often: “Well, that’s impossible, of course we don’t do that.” What follows is usually a long list of reasons why true incremental delivery is seen as unrealistic.

Yes, It Is Possible

Let me be clear: genuine incremental delivery — releasing usable components to a subset of users — is not only possible, it’s better, faster, and more cost-effective.

I’ve seen this approach succeed in more than 200 projects, including some of the most complex corporate environments.

Start Here, Not There

Because incremental delivery is foundational to benefits-based governance, I often recommend starting here first — even before changing the governance model. From a change management perspective, it’s a gentler starting point, allowing us to shift culture one layer at a time.

Even within incremental delivery itself, there are phased procedural and cultural changes we can introduce to improve outcomes step by step.

What’s Next

In future articles, I’ll explore common objections to incremental delivery, along with practical ways to embed the practice into our delivery teams.

When you're ready, here's how I can help:

Andrew Walker 
10 years AI strategy & implementation for executives in staff-heavy organisations, often with mobile .

Did someone forward this email to you? Want your own subscription? Head over here and sign yourself right up!

Back issues available here.

• AI Agents aren't apps—they're capabilities we already have, waiting to be connected.

• The "buy vs build" question is a distraction—vendors push it to sell add-ons.

• All we need is lightweight integration work to link existing systems with existing AI tools.

What Are AI Agents?

AI Agents—sometimes called the digital workforce—are similar to personal AI tools like copilots, with one crucial distinction: they’re directly connected to our systems and can take action on our behalf.

The Common Question: Build or Buy?

A common question is whether we should build or buy our AI Agents.

It’s understandable—we’re used to approaching applications this way. Build or buy is the standard choice when we think about new capabilities.

But with AI Agents, that framing leads us in the wrong direction.

The Real Answer: Neither

The real answer isn’t “build” or “buy.” It’s “connect.”

We don’t need to build bespoke agents or purchase new AI add-ons. We already have what we need—our existing systems and the pay-as-you-go AI tools from our current vendors.

The confusion comes from application vendors trying to package AI as a product. But AI isn’t a product. It’s a capability—like the cloud. We wouldn’t ask, “Should we build or buy the cloud?” We simply work out how best to use it and connect it.

We Already Have What We Need

This same thinking applies to AI Agents embedded in systems. The two essentials are already in place:

• Our existing systems, where the agent will act or add information

• The “systems” version of personal AI assistants, available from the same vendors we already use

How to Make It Work

What’s needed is a connection between the two.

This is classic systems integration—using pre-built APIs (application programming interfaces) that allow software systems to talk to each other.

These integrations are small, targeted pieces of technical work, aligned to our specific mix of processes and systems.

A Better Cost/Benefit Model

So let’s avoid the “build vs buy” trap—it’s a distraction.

Instead, we can focus a small technical team on linking our AI copilot to the systems where it can add value.

The upfront investment is minimal, and the return is disproportionately high—far better than the economics of most traditional application projects.

When you're ready, here's how I can help:

Andrew Walker 
10 years AI strategy & implementation for executives in staff-heavy organisations, often with mobile workforces.

Did someone forward this email to you? Want your own subscription? Head over here and sign yourself right up!

Back issues available here.

We've investigated how to govern IT projects based on the benefits delivered, rather than traditional document-based measures in the traditional model. We've also looked at the cost advantages of this approach.

But there are also a host of additional upsides to benefits-based governance from the perspective of team morale and motivation.

The big morale benefits stem from unique aspects of the approach:

• Tangible results

• Feedback in the first month

• Autonomy

Let's look at each of these.

Tangible Results

In a traditional project our progress is measured by the delivery of documents. We call these deliverables. They range from architecture and requirements to project plans.

But these artefacts are synthetic, even if we print them out on paper. They have no real meaning in a physical or financial sense. We can't internalise them in any meaningful way.

So the extended project team ticks these deliverables off one by one, but they have no emotional connection with them because documents have no inherent meaning.

With each gate ticked, we feel a sense of relief rather than excitement. We steel ourselves for the next document.

In a benefits-based scenario, it's easy for the whole team (business and technical delivery folks) to relate to something like "Wow, we've taken all these calls in half the time thanks to what we've delivered so far". These are real customers calling in to real call centre agents. We can take out a stopwatch if we want and see how much quicker the calls have been.

The whole team immediately has a sense of achievement because we've seen the link between "what" we're doing and the "why". Simon Sinek explains the research behind this in his "Start With Why" TED talk.

Feedback in the First Month

It's concerning that the traditional approach to governance actually never provides the extended team with any feedback at all on what business benefits they've delivered. Even in theory, we don't deliver any benefits until after "user acceptance testing" has concluded at the end of the project and we've deployed the new solution to all and sundry.

In practice I've never seen a business that measures this; they just pack up after the project team has gone home and they move on. Often it's taken so long to approve and deliver the project that the original sponsor isn't around anymore. At best this is demoralising; at worst (most commonly) it's subconsciously depressing and demotivating.

In contrast, benefits-based governance requires us to demonstrate real progress within a month.

It's one of the most satisfying aspects of helping teams work this way, to watch the reaction on the team's faces when they first realise that they've actually made a difference within the first month. Business people are as excited as the IT team, maybe even more so. And once a team has worked this way they find it hard to give it up because of the addictive, uplifting feeling of achieving something real.

It doesn't matter if the team has improved the life of just one call centre agent out of 2,500 - it's still real. They can talk to James, find out how he's feeling about the results and then widen the net to tens, then hundreds of other users as time goes by.

Fast feedback is a well-documented foundation in motivating teams. Benefits-based governance ticks this box where traditional governance fails.

Autonomy

The relationship between autonomy and motivation is well documented with a slew of studies and models developed as far back as the 1980s.

Yet in the traditional governance model the delivery team has no remit to make any choices at all. All aspects of the project are pre-dictated, from architecture and scope through to products, tools and programming languages. They're preset because they're the only proxy available for measuring progress. It's almost as though the delivery team is expected to be a bunch of robots, mindlessly following the instructions of those who came before them.

In the benefits-based approach, the team is given a goal, or a North Star, and they have reasonable autonomy on how to achieve that goal. Indeed, the team will likely try a few different ways to achieve the business goal early in the project and gradually settle on what gives the best "bang for buck". In a traditional project this type of iteration is seen as wasteful because we're using a different measuring stick. In a benefits-based world, iteration and experimentation is not only allowed, it's seen as necessary and efficient.

This choice gives the team a real purpose, a real problem to solve.

I've seen the effects of this autonomy first-hand on hundreds of projects and to this day it's a rewarding experience. Teams don't need coercion to work harder; they do what they need to do because they've taken ownership of the goal. I've seen a team voluntarily do a release on Sunday evening after dinner with the family, just because they were excited to see the reaction on Monday morning.

It's hard for me to overstate how motivating it is to work toward a benefits-based goal compared with the traditional governance approach - it really is transformational from a morale perspective.

When you're ready, here's how I can help:

Andrew Walker
Consulting to for-purpose CEOs to deliver more impact with existing teams and systems - by freeing humans up from admin.
https://www.linkedin.com/in/andrew-walker-the-impatient-futurist/

Did someone forward this email to you? Want your own subscription? Head over here and sign yourself right up!

Back issues available here.

• "Digital workforce" means using AI agents to ditch low-value tasks, not replace humans.

• Expect small, specialized agents that boost productivity by freeing up your team’s time.

• Success depends on smart governance, cultural support, and keeping implementation lean.

Like AI “Agents”, we’re going to be hearing a great deal about the “digital workforce” from vendors this year.

The idea is that instead of hiring more people, we’ll be deploying AI Agents to supplement our workforce.

The result is no different from any other IT project

As always, this is about automating any low-value administrivia or rekey activity we’re currently doing manually. It’s just “digital workforce” and “agents” are a specialised version of that automation.

The difference is that, thanks to AI, creating each agent in our digital workforce is a much quicker and cost-effective affair. The barrier to solution has dropped so low it’s hard to notice any more. Most of us will talk about setting up these agents for far longer than it will take to implement. I’ve already seen evidence of this, many times.

To the executive team, this is a very compelling proposition if we can make it work because even the least effective and most expensive agents (the ones our CRM and other app vendors will be pushing) will be a tiny fraction of the cost of a new hire.

There are already some themes and best practices emerging

Our digital workforce will be integrated into our existing systems and given some degree of autonomy for each task, rather than our primary focus today being on personal AI assistants and copilots that are directed by us in a fine-grained manner.

There’s a productivity correlation here... the more loosely directed our digital team is, the more time they free up for us.

Staff are the ultimate winners

I’m not expecting the digital workforce to replace any one full human role any time soon.

It’s not a 1:1 replacement. It’s more likely that one person’s easy-to-automate tasks (which are typically the more mundane ones anyway) will be picked up by multiple specialist agents (hence “workforce”).

Still, freeing up say 20% of someone’s time is a huge win, particularly if it can be done for most people in the organisation.

Based on my experiences to date I believe that our staff will be the biggest winners of the digital workforce revolution. Staff will finally get to drop the mind-numbing, mundane tasks that IT still struggles to iron out and focus instead on satisfying work.

The challenge for management

The challenge for management will be in supporting staff through this transition with flexibility, training and coaching. Just like any other cultural or IT change.

Setting up each agent in a digital workforce is still going to be a human-heavy activity, so we’ll still need IT prioritisation and governance – albeit these activities will be much lighter weight for agentic initiatives. We’ll have to adapt to a much higher volume of initiatives, with the cost of each being lower than their non-AI equivalents today. This will put pressure on the efficiency of IT governance because we don’t want the cost of governance to be 10 times the implementation cost.

When you're ready, here's how I can help:

Andrew Walker
Consulting to for-purpose CEOs to deliver more impact with existing teams and systems - by freeing humans up from admin.
https://www.linkedin.com/in/andrew-walker-the-impatient-futurist/

Did someone forward this email to you? Want your own subscription? Head over here and sign yourself right up!

Back issues available here.

• Stop buying tools you don’t need—use what you have and integrate smartly.

• Kill the busywork—ditch documents that exist just to impress governance committees.

• Ruthlessly prioritize—only build what delivers measurable business value.

It wasn't until I was routinely delivering projects with a benefits-based governance model that I realised just how wasteful our traditional governance and delivery models are.

I would often be pulled in to turn around a failing project at the point where half the budget was spent, only to find that I could take a fresh start. Often I'd win a project that had previously been budgeted using the traditional model, only to find that I could deliver expected business benefit for way less than 50% of the forecast spend.

As extreme as this sounds, it’s actually perfectly logical.

While there are numerous levers for this cost reduction, three big ones stand out, because in a benefits-driven model:

• We tend more toward getting extra value from existing systems than we do buying or building new ones.

• We avoid a huge amount of unnecessary work generating traditional governance documents.

• We avoid delivering capabilities that have little or no impact in delivering the business benefit.

Less focus on buy and build

In a traditional governance model, the project's focus is almost always on buying or building a new system. This is natural because we're working in an information vacuum; we don't have a benefits-based "north star," so in its absence, we shift to "we need a new xyz system."

The problem is that once we shift focus to "system xyz" instead of "benefit xyz," we've ruled out anything but a new system.

An example of this is the most dramatic turnaround I've worked on, which was a 10-year failure. For 10 years, various attempts had been made to get funding for and deliver a project. Each time this project was positioned as "xyz system replacement" rather than being a benefit-based target. Once it was called "publishing system replacement," another was "call centre replacement system," and so on.

Without exception, I've found that it's faster and more cost-effective to use existing systems as a base and provide better integrations and user experiences around these systems to make data entry more efficient.

Buying new systems is more costly for several reasons:

• Buying applications involves initial and ongoing licence costs, whereas integrating or wrapping existing systems with new user experiences can be done with ubiquitous, cost-free technologies.

• For a purchase, the process of funding, selection, negotiation, provisioning, and customisation takes at least a year, with the associated resource and licensing costs. This time also represents an opportunity cost because it delays the benefits we're hoping to achieve with the project. Avoiding a purchase decision means we can start immediately.

• Resources with certifications in a particular vendor product are always more expensive than their "open" counterparts who use ubiquitous skills and licences.

Avoiding governance-centric documentation

When we analyse the documentation we're required to generate in a traditional governance model, we realise how little of it is necessary for the solution we're delivering. Most project documentation is actually only required to demonstrate progress.

By adopting a simpler and more relevant progress metric (business benefits delivered), we avoid the need for most of these documents.

Most architecture and design documents are not necessary because we can easily fit within existing standards by using the integration and user experience technologies already approved in the organisation. We don't need infrastructure architecture documents because we're not introducing any infrastructure—we're using services already hosted by our existing email and drive vendor.

We don't need to map current and future states or specify our system upfront because we don't need to evaluate a vendor product. We're just on the hook to deliver outcomes. Because we deliver these gradually, sponsors have ample time to correct our course of action in the rare event that our initial capability in one area misses the mark.

Avoiding delivering low-value capabilities

No solution is perfect, and no solution will deliver every feature imagined by our intended audience.

The problem with the traditional governance model is that we don't have any yardstick to measure or qualify high value from low value.

This leads to a "kitchen sink" approach to managing scope. If "the business" requests a feature, we're on the hook for it.

In reality, this is hugely wasteful. We end up configuring and building things that have no impact on the business benefits we're intending to deliver.

In contrast, a project team focused on delivering business benefits will continually ask the question, "Is this the most valuable thing we can be implementing next?"

This means two things:

• We build the most valuable things first.

• The things we don't address by the end of the project are, by definition, of marginal value—when measured against the yardstick of business benefits.

Close

Like many of the best things in the world, benefits-based governance and delivery is super simple and yet very powerful.

Dramatic cost reduction is only one of the profound benefits of this model. In my next instalment on this model, we'll investigate the positive benefits of improved morale and motivation.

When you're ready, here's how I can help:

Andrew Walker
Consulting to for-purpose CEOs to deliver more impact with existing teams and systems - by freeing humans up from admin.
https://www.linkedin.com/in/andrew-walker-the-impatient-futurist/

Did someone forward this email to you? Want your own subscription? Head over here and sign yourself right up!

Back issues available here.

• System-to-system AI beats personal AI on ROI, speed, and risk reduction.

• No new vendors, no infrastructure—just integrate with tools you already use (like Microsoft or Google).

• Avoid the AI hype trap—real value comes from seamless automation, not chatty assistants.

Today, much of the AI chatter centres around the initial wave of generative AI capabilities—what I call personal AI. These include the AI assistants, chat products, and copilots we're all becoming familiar with.

But do these general productivity tools offer the biggest or the fastest return on investment (ROI)? Is this really where our attention should focus if we want the maximum impact from our investment of time and resources?

Well, no, actually.

Now, I'm not suggesting we slow our adoption of AI chat products and copilots. As an early adopter, I can attest to the massive productivity gains achievable by integrating these tools into our daily workflows. We should absolutely continue with this adoption to ensure we're not made personally irrelevant by the end of 2025.

However, human-centric AI tools like these won't offer the largest or fastest return on investment.

Effective implementation and adoption of chat and copilots inevitably take time. It takes considerable effort to develop information security policies, implement controls, conduct training, and provide ongoing support so that staff genuinely gain value from these tools. The reputational risks are significant because it's challenging to predict how staff might use these tools or establish sufficient guardrails around human interactions. The impact of inadvertent misuse could be disastrous, making careful planning essential.

Consider a health organisation, for example. Getting all carers to use a copilot to summarise case notes requires widespread training. Some staff will embrace this technology, while others will feel overwhelmed. Furthermore, manually transferring information back and forth from personal AI products dilutes the potential business benefits. Internal teams must also invest significant time assessing risks and approving case note sharing through the copilot.

From personal experience, it's significantly faster and more effective to integrate AI directly into our existing systems.

This system-to-system integration is being termed the "digital workforce" because it creates AI agents that operate seamlessly within existing systems, effectively becoming extensions of your team.

Returning to our care example, imagine integrating a systemic version of a copilot directly into your care management system. This approach ensures a summary of past case notes is automatically available to the appropriate carer, within a familiar interface, removing manual tasks entirely.

This approach is superior for several strategic reasons:

• Greater ROI: The solution is accessible through familiar user interfaces and fully automated, eliminating manual tasks such as copy-pasting required by personal copilots.

• Faster ROI: Immediate start-up is possible because no vendor selection is required. Your existing email provider (usually Microsoft or Google) already offers AI services tailored for system-to-system integrations, alongside human-centric copilots. These services are consumption-based with no upfront commitment and require no new infrastructure.

• Reduced Vendor Security Concerns: There's no need for additional vendor vetting. Your major providers (e.g., Microsoft or Google) already securely manage your sensitive data such as emails, attachments, and cloud-based files stored in OneDrive or Google Drive.

• Minimal System-Centric Security Risk: Integrating AI into existing systems allows complete control over data provided to AI services, avoiding unrestricted data access.

• No New User Security Concerns: Security remains managed within existing systems, eliminating additional complexity or risk from new integrations.

Implementing AI services system-to-system (your "digital workforce") isn't about buying or building new infrastructure—it's simply integration. Consequently, these projects are lightweight, cost-effective, and fast. I've yet to encounter a use case taking longer than a couple of months—most can be completed within a single month.

However, be cautious of the "application vendor AI trap." I'm specifically recommending integration with your established email and drive vendors rather than relying on vendors of individual applications like your CRM or accounting systems. I'll explore this further in another article.

When you're ready, here's how I can help:

Andrew Walker
Consulting to for-purpose CEOs to deliver more impact with existing teams and systems - by freeing humans up from admin.
https://www.linkedin.com/in/andrew-walker-the-impatient-futurist/

Did someone forward this email to you? Want your own subscription? Head over here and sign yourself right up!

Back issues available here.

• Deliver real business value within the first month—no excuses, no waiting.

• Traditional governance delays and dilutes impact; benefits-based governance builds proof early and often.

• You don’t need full systems, full rollouts, or full specs—just the guts to deliver value incrementally.

In Why Project Governance is Fundamentally Flawed, I highlight how traditional governance fails to hold teams accountable for the business benefits promised when funding is first sought.

But is measuring progress based on business benefits actually possible?

Yes, it is.

I'm speaking from experience across about 200 projects in Australia, the UK, and the US since 2012. These projects range from 2 months at $300k to 18 months at $4m.

Regardless of size, each project realised tangible business benefits within the first month.

Achieving this requires breaking the traditional delivery model, which typically delivers a system to all users only at the project's end—even in most agile projects, where incremental builds aren't rolled out until a final acceptance testing phase.

For benefits-based governance, we must deliver benefits right from the project's start. Progress can then be tracked directly against our goals.

This means delivering a fraction of the solution to a small audience soon after commencement, then expanding incrementally.

Consider a real-world example: rolling out a new call centre solution to 2,500 agents over 18 months, aiming to halve call handling time for 80% of calls. Our initial rollout was to just one agent, delivered 16 business days after project kickoff. Many capabilities weren't built yet: no credit card processing, calls were taken only from account holders, and only one of more than 30 eventual system integrations was in place. Orders were manually rekeyed into downstream systems. However, we successfully reduced call times for this agent by 80%, significantly surpassing expectations.

Every two weeks, we added integrations and expanded system capabilities, progressively managing more edge cases until project completion. Remarkably, by month four, the savings in call handling costs had fully covered the project budget—impossible with traditional delivery methods.

Initially, incremental delivery often meets scepticism from IT teams, who carry decades of traditional assumptions. But questioning these assumptions and addressing their underlying needs differently can overcome these objections:

• Full documentation and upfront sign-off: Required only if governance is scope, time, and cost-based. Benefits-based management removes the need for these interim deliverables, reducing waste.

• Complete system design before release: Driven by concerns about scalability. Incremental rollout enables risk identification and mitigation at minimal impact and cost.

• Upfront infrastructure provisioning: Outdated with current cloud infrastructure, which immediately scales without upfront investment, eliminating associated risks.

These objections share a pattern: they originate from valid risk management concerns but can be effectively managed or avoided using modern approaches.

Initially, benefits-based governance might subconsciously feel riskier—an evolutionary reaction. Ironically, it's actually far more effective in managing financial risk, as project spending is continuously justified by incremental benefits. Traditional governance risks 100% of the project budget before any benefit measurement is even possible—and often overlooked when eventually implemented.

I haven't used traditional governance since 2011 and highly recommend benefits-based governance—it’s more enjoyable, less stressful, and ultimately more satisfying.

When you're ready, here's how I can help:

Andrew Walker
Consulting to for-purpose CEOs to deliver more impact with existing teams and systems - by freeing humans up from admin.
https://www.linkedin.com/in/andrew-walker-the-impatient-futurist/

Did someone forward this email to you? Want your own subscription? Head over here and sign yourself right up!

Back issues available here.

• Agents don't just advise—they act, triggering real processes like refunds, emails, or system updates.

• Human oversight is critical—for now—but agents are quickly moving toward autonomy, personalisation, and full enterprise integration.

• Directors must prepare now or risk falling behind in the most important software shift since the internet.

If you haven't heard about "agents" already, I'll be surprised—I think we'll remember 2025 as "the year of agents".

As happened previously with the internet wave, major software vendors like Salesforce and ServiceNow are busy re-organising their products around the generative AI wave—and more specifically around "agents" and the concept of a "digital workforce".

So what exactly are these agents, and how are they different from the generative AI tools we've been using for the past couple of years?

For a deeper understanding of the broader generative AI context, you can read my previous article on that topic.

Let's briefly review the evolution and current landscape of generative AI:

Phase 1: Chat / Copilots (2022)

The first true wave of generative AI adoption in business came through chatbots and copilots.

These tools excel at drafting documents, answering questions, summarising information, and coding. They're accessible through simple, human-like conversational interactions that anyone can use without technical expertise.

Products like ChatGPT, Microsoft Copilot, and GitHub Copilot demonstrated how AI could quickly assist in writing emails, generating code, and creating content.

Early adopters gained significant productivity advantages, with non-technical teams reporting time savings of several hours per day.

This phase can be characterised simply as: [prompt] → [response]

Phase 2: Reasoning

As AI models became more sophisticated, capabilities extended beyond simple text generation toward structured reasoning. These systems can now break down complex instructions into logical steps, follow multi-turn conversations, and solve layered problems.

The AI's "chain-of-thought" reasoning is often displayed in real time, improving transparency and reliability.

Reasoning broadened AI's application into more complex and abstract business areas, significantly enhancing tasks like research and notably reducing inaccuracies or "hallucinations".

This phase can be described (somewhat simplistically) as: [prompt] → [chain of thought] → [response]

Phase 3: Agents

Agents combine the capabilities of previous phases—but crucially, they add the ability to take action.

For example, with earlier chat-based or reasoning-based AI, a developer might receive suggestions for multiple code changes but would then manually apply these changes. By contrast, an agent could directly implement these code changes without further human prompting.

Initially, the types of actions that agents can perform have been deliberately limited, primarily for security reasons. For instance, in the coding example, an agent might be restricted to changing files within a single predefined folder, limiting potential risks.

However, as confidence grows, agents are progressively gaining broader access to organisational actions, including tasks such as:

• Sending emails on your behalf

• Updating customer records with relevant notes

• Raising refund requests within internal systems

• Draft-approving a recruit's application to study law

Given the significant implications, businesses are being advised to incorporate human oversight into agent-initiated workflows, particularly where substantial resources or money are at stake. For example, while an AI agent might initiate a refund request, a human supervisor should review and approve the final transaction. This cautious approach is strongly recommended to mitigate potential risks.

What's Coming Next?

The next phase of AI development will unlock further strategic opportunities:

• Autonomy: Agents will not only respond to direct prompts but will actively and independently look for tasks to complete. Initially, this might involve proactively identifying issues and opportunities, but eventually, agents could operate largely independent of explicit human instructions.

• World Modelling: AI will gain the ability to internalise representations of tasks or broader business goals. This capability will significantly enhance planning effectiveness, resilience in complex situations, and reduce errors.

• Retrieval Augmentation: AI's access to information will extend beyond immediate prompts to include internal databases and external sources. While current copilots already perform web searches, future agents will retrieve and integrate insights from a wide variety of organisational knowledge bases and internal systems.

• Personalisation: AI agents will become tailored to individual and departmental needs. They will remember and adapt to user preferences, work styles, workflows, and adhere strictly to personalised security rules.

• Enterprise-grade Security: Robust security measures will be essential to safely integrate agents into organisational operations. No business will grant unrestricted system access; thus, enterprise-grade safeguards will be vital to unlocking agents' strategic potential without compromising data integrity.

As directors and executives in Australian care organisations and charities, understanding and strategically deploying AI agents can significantly enhance your operational efficiency, reduce overheads, and amplify your organisation's community impact.

To strategically leverage these advancements, consider engaging with trusted advisors who can guide your organisation through adopting agents securely and effectively.

When you're ready, here's how I can help:

Andrew Walker
Consulting to for-purpose CEOs to deliver more impact with existing teams and systems - by freeing humans up from admin.
https://www.linkedin.com/in/andrew-walker-the-impatient-futurist/

Did someone forward this email to you? Want your own subscription? Head over here and sign yourself right up!

Back issues available here.

• IT projects are judged on delivery, not on whether they actually deliver the promised business impact.

• No one is held accountable for business benefits after funding is approved—this is seen as normal, but it's insane.

• A benefits-based governance model is not only possible, it's easier, smarter, and long overdue.

With normal IT project governance, we are not held accountable to deliver the business outcome that we promised when we applied for the funds.

I find this totally crazy, and I'm somewhat disappointed with myself for not realising it earlier in my career. It wasn't until the middle phase of my career, when I began specialising in project rescues/turnarounds, that this dawned on me. It was through repetition that the silliness of traditional governance dawned on me.

Think about it.

For any significant IT project to be approved for funding, we need to build a business case. The business case demonstrates to the funding body that our project will change the business in such a way as to recoup more money than we spend on the project.

The "recoup" bit is what we refer to as the "business benefits". Typically, this comes from reducing our operating costs or increasing our revenue.

So typically, if we want to spend $1m on a project, we will need to demonstrate that we'll recoup at least $500k per year. The idea is that such a project would pay for itself within two years, and after that, we are making a profit as it were. Actually, these days, most IT investment boards are looking for a one-year payback, so the same project would be expected to pay back $1m per year.

But under traditional project governance, this is the last time that benefits are discussed—even after the project is finished and everyone has gone home.

Let's use an analogy to demonstrate the disconnect.

Imagine I offered to fit a gadget to your car for $500 that will double your mileage, so you can go twice as far for the same cost of petrol or halve your fuel cost for the same distance. So I say your annual fuel bill will come down from $3,000 to $1,500. I say the gadget will be supplied and installed in less than a week.

Sweet deal, right? So you go for it. You hand me $500 expecting me to give you something in return.

But what are you expecting from me in return for your $500:

1. A gadget supplied and installed in a week for $500, or

2. Half your yearly spend on petrol?

I'm hoping you went for option 2; it's the correct answer. Having a gadget in your car is irrelevant if it doesn't deliver the benefit I promised you, right?

And yet in IT, we measure our success according to option #1. Did I install the system in the time I promised, for the budget you gave me?

Worse still, in IT, I can ask anyone on the delivery team what business benefits we're expected to deliver, and no one will be able to provide a sensible answer. I know this because I've spent over a decade asking the question in the context of project turnarounds—and I've never been given a practical answer. Not once.

This isn't the delivery team's fault; it's a by-product of a governance model which was invented in the '50s when building computer systems cost as much as building a building. Whilst the IT world has been flipped on its head in economic terms, we've stuck to a governance model that no longer works.

It's worth noting that the various flavours of agile since the 1990s have not offered up an alternative (agile) governance model either. In my opinion, this is why agile has had limited success—it's been constrained by a traditional non-agile governance model that can't cope with incremental delivery.

In our car analogy, we use a benefits-based governance model—I expect a result, not a gadget. In IT, we use scope, cost and time instead. We're deemed successful if we deliver the system we promised, in the time we predicted, and for the budget we asked for. It matters not whether we deliver even a fraction of the business benefit we promised. No one is held accountable.

In almost 40 years of projects, I've never worked for an organisation that routinely evaluates the business benefits actually delivered by a project.

But is it even possible to use benefits-based governance in IT?

Absolutely—and benefits-based governance turns out to be far simpler, effective, efficient and satisfying than the traditional model.

More on benefits-based governance next week.

When you're ready, here's how I can help:

Andrew Walker
Consulting to for-purpose CEOs to deliver more impact with existing teams and systems - by freeing humans up from admin.
https://www.linkedin.com/in/andrew-walker-the-impatient-futurist/

Did someone forward this email to you? Want your own subscription? Head over here and sign yourself right up!

Back issues available here.

• Generative AI is real magic: machines are creating beyond their programming, and experts don’t fully understand it.

• The article breaks down three key breakthroughs that unleashed today's AI explosion.

• Leaders who ignore generative AI now risk being left behind by 2025.

Let's take a simplified walkthrough of the "generative AI" surge so you can hold the high ground at your next drinks party.

Here's a simple visual map of the key advances:

What's the big deal?

You've probably noticed more hype around this AI craze compared to previous tech fads—even compared to the last AI wave. The excitement is justified because generative AI is truly magical.

Let's quickly explore three key advances that sparked modern "generative" AI.

AI has been around since the '50s

Modern AI, synonymous with "machine learning," dates back to the 1950s when IBM engineer Arthur Samuel coined the term. After early promise, AI experienced a lengthy quiet period known as the "AI winter," limited by insufficient computing power and data availability. More background on this era can be found in this article.

Jump #1: Deep Learning (2015)

By the 2000s, advancements in computing and data sets allowed significant progress in machine learning, initially used behind the scenes for speech recognition, recommendations, ad targeting, and spam filtering.

However, early machine learning wasn't truly "learning"—it relied on scientists creating models based on complex maths for computers to make predictions.

This changed with deep learning, where computers could independently identify patterns and "learn" from data.

In 2015, major cloud vendors made deep learning widely accessible, fueling consumer products such as voice assistants (Alexa, Siri, Google), translation services, self-driving cars, and image recognition apps.

Yet, the initial hype waned when businesses realised deep learning required significant human input to label data—a method known as "supervised learning." For instance, a fraud detection system my team built required manual review of thousands of advertisements to train the AI, ensuring accuracy but demanding substantial human effort.

Jump #2: Self-Supervised Learning (2018)

In 2018, breakthroughs allowed computers to generate their own data labels, dramatically reducing human effort. Tech giants like Google, Facebook, and OpenAI quietly integrated this "self-supervised learning" into existing products.

However, widespread adoption remained limited due to prohibitively high computational costs.

Jump #3: Generative AI—the Magic (2022)

As researchers advanced self-supervised learning, they made a remarkable discovery: AI models started exhibiting behaviours beyond their explicit programming.

In 2019, OpenAI found their models unexpectedly generating original content. This unplanned phenomenon marked the birth of generative AI.

By 2022, Anthropic's research revealed these capabilities emerged suddenly at critical points of scale, rather than gradually. These emergent behaviours include:

• Few-shot learning: Learning new tasks from just a few examples.

• Basic reasoning: Solving logic problems and performing abstract thinking without explicit training.

• Compositional generalisation: Combining unrelated concepts into new, creative ideas.

In late 2022, OpenAI introduced ChatGPT, explicitly harnessing these magical new capabilities.

Looking forward

Generative AI is genuine magic: even leading researchers at OpenAI, Anthropic, Google DeepMind, or Meta can't fully explain it.

It's also transformative: adoption is outpacing any previous tech innovation, including the internet. I firmly believe that leaders who aren't actively exploring and applying generative AI now will find themselves struggling to keep up by the end of 2025. Neither fear nor ignorance will provide protection.

When you're ready, here's how I can help:

Andrew Walker
Consulting to for-purpose CEOs to deliver more impact with existing teams and systems - by freeing humans up from admin.
https://www.linkedin.com/in/andrew-walker-the-impatient-futurist/

Did someone forward this email to you? Want your own subscription? Head over here and sign yourself right up!

Back issues available here.

• You can't copy a tech unicorn's structure and expect it to work—especially if you skip the culture part.

• The Spotify model isn't a model—it's a mindset rooted in trust, purpose, and autonomy.

• If you're focused on squads and ceremonies instead of clarity and team ownership, you're doing it wrong.

When Spotify shared their engineering culture in 2012, it was a revelation on how to do agile at scale. Except… 10 years later, CIOs are just as frustrated with agile as they have ever been.

It all started about a decade ago, when Henrik Kniberg posted a two-part explainer on Spotify's "engineering culture" (note "culture" vs "model" here for later).

Within a year the corporate world was scrambling to copy "the model," as they had previously attempted with Facebook's "move fast and break things" and Amazon's "two-pizza-teams."

And yet, as with previous crazes, corporations failed to make a significant dent in the value they were delivering, or their efficiency.

I'm sure there are one or two success stories, but in the two dozen organisations I've come across, there was no noticeable difference in the impact these teams were making (as judged by their internal customers). I would argue that most of them went backwards, if you count how much effort and time was put into "adopting the model."

What I noticed when I looked under the covers in these organisations, is they were doing exactly the opposite of what Kniberg stressed in his videos.

These days when someone tells me "we're adopting the Spotify model," I know they've not watched the video because I've realised "model" means "structure." You'll notice that Kniberg describes it as "culture" not "model."

For over half of his first video, Kniberg urged viewers to ignore the Spotify structure as an ephemeral thing (even with Spotify). He stressed instead that people should focus on trust, community, respect, motivation, and autonomy.

Organisations did the opposite. They spent months or years restructuring their teams into squads, guilds, chapters, and so on. They spent no time at all with the emotionally harder task of asking "what's our team's purpose, how do we measure success?" Rarely did they make the tough decision to allow teams to make their own choices on technology, architecture, and process.

What I realised eventually is that very few people actually watched the video.

Like Scrum, Lean, eXtreme Programming, and SAFe before it, this fad focused on processes and tools instead of focusing on the humans.

And what does this remind us of?

The first credo of the Agile Manifesto urges us to focus on individuals and the way they interact, rather than on processes and tools. And yet the first thing teams do when adopting any agile practice is to focus on processes and tools. They talk about chickens, pigs, t-shirt sizing, burndown charts, stand-ups, retrospectives, and so on. They don't answer the simple question "what are we trying to do here, what's our purpose?"

I find it really naive that a corporation offering (non-tech) products and services to its customers would imagine they can successfully copy the structure of a massive tech unicorn like Facebook, Amazon, or Spotify. The organisational structure in these organisations is, by necessity, totally different from non-tech corporations. Conway's Law suggests that two organisations with different outputs (tech vs non-tech) must have different communication lines—aka structure.

Ironically, adopting the Spotify culture is as intellectually simple as it is emotionally difficult:

Watch the video, make sure everyone in the team watches it.

Do as Henrik suggests:

• Don't focus on structure.

• First, figure out a way of describing the team's purpose, in a way that the whole team can easily tell if they're succeeding or failing on a given day.

• Remove policies that interfere with the team's ability to make its own choices.

• Let the team figure out the rest, manage them to their purpose rather than breaking their work down into tasks for them.

• At every turn, allow them to do their own thing (as long as they're delivering their stated objective)—this is the ONLY way to foster community, trust, and motivation.

If you're serious about tackling culture instead of structure to maximise productivity and motivation, I would recommend Team Topologies, which is a really practical guide to creating loosely coupled teams with clear purpose. A shout-out to the team at Service NSW for introducing me to this book. I would say they're the best Australian example I've come across, in terms of genuinely addressing the things Henrik espouses in his videos. I notice a similar humility in their language to Kniberg's: "we're never perfect, things often don't work." And yet they've subconsciously adopted the Spotify culture more successfully than most corporations.

Even if you can't adopt the Spotify culture, I'd highly recommend watching the first of the two videos; there are some proper pearls of wisdom in there:

• "We'd grown into quite a few teams and found that some of the Scrum practices were actually getting in the way."

• "We decided that agile mattered more than scrum and that agile principles mattered more than any specific practice."

• "Agile at scale requires trust at scale."

• "If you want to know exactly who is making decisions, you're in the wrong place."

When you're ready, here's how I can help:

Andrew Walker
Consulting to for-purpose CEOs to deliver more impact with existing teams and systems - by freeing humans up from admin.
https://www.linkedin.com/in/andrew-walker-the-impatient-futurist/

Did someone forward this email to you? Want your own subscription? Head over here and sign yourself right up!

Back issues available here.