Transformation Initiatives: The Fastest Way to Become AI-Native

Step OneDefine the Objectives

The first step is to document the goals. That sounds obvious enough to skip, which is exactly why it gets done halfheartedly. The inner circle knows what the initiative is for. The people who actually have to work differently frequently don’t, and nobody finds out until adoption stalls eight months later.

Goals don’t need to be exact at the early stages of a transformation. If you can be specific, you should be, but broad-stroke goals — percentage increases in revenue, reductions in cost, achieving compliance, boosting morale — are all legitimate. They provide direction on where to focus, and that’s enough to start.

There are different frameworks for goal-setting worth knowing here. SMART goals — SpecificClearly define what you’re trying to accomplish, leaving no room for ambiguity., MeasurableAttach a number or metric so progress can be tracked objectively., AchievableSet a target that’s ambitious but realistically within reach given your resources., RelevantMake sure the goal actually ladders up to the broader transformation objective., and Time-boundGive it a deadline, so it drives action instead of sitting indefinitely. — are the standard for turning a vague aspiration into something a team can actually execute against and track. BHAGs (Big Hairy Audacious Goals) sit at the other end of the spectrum: intentionally bold, long-range targets meant to galvanize an organization around a single ambitious vision rather than a precise metric. In between, OKRs (Objectives and Key Results) pair a qualitative, inspirational objective with a handful of measurable key results that define what achieving it actually looks like — the framework popularized by Intel and Google, and now a default operating rhythm at many transformation-stage companies.

None of these frameworks is “correct” on its own. BHAGs give an organization direction and motivation. SMART goals give it discipline and accountability. OKRs sit in between, giving teams a cadence — usually quarterly — for translating big ambitions into trackable progress. Most transformation efforts benefit from using all three together: a BHAG at the top (the why), OKRs as the connective tissue (the near-term focus), and SMART goals underneath, adding the specificity and timelines that make the whole thing executable.

The AI layer. The goals file is the first artefact in your intelligence layer, and everything downstream inherits it. That makes it the highest-consequence document in the program. Say the target is a $30M cost reduction by end of 2027, written into the Markdown. Six people now use that file to automate slide preparation, communications, value models, project plans, critical paths. Then the goal moves to $32M by February 2028. Unless the source of truth is updated, all six are automating against a number the steering committee abandoned a month ago — and because the output looks polished, nobody catches it until someone senior asks where the figure came from. Decide now who owns that file and how a change propagates. It’s a five-minute decision in month one and an expensive one in month nine.

Here’s what that looks like across a few common transformation types:

Step TwoMap the Process Landscape

Once goals are defined, the next step is to map the process landscape and build process blueprints. That means creating swimlane maps and documenting business rules and logic thoroughly enough that you actually understand the mechanics of what gets done — not just at a high level, but in practice. This can vary by product, by department, by geography. There can be an infinite number of variations to a single process, and an infinite number of processes to map in the first place.

Given that, it’s important to break the process landscape into parts so you can move quickly rather than trying to boil the ocean. In the startup world, this is what you’d call a beachhead — getting a foothold in one market and using it as a stronghold to expand into adjacencies. The same logic applies to business transformation: focus on a narrow process or technology area, establish a beachhead, and use it to build momentum before expanding outward. That’s the way this has traditionally been done, and it still holds.

What’s changed is a new requirement layered on top of the old one: these artifacts — the process maps, business rules, logic tables — need to be consumable in the usual formats (PowerPoint, Google Slides, Excel, Word, memos), but they also need to exist as Markdown files. It’s the Markdown versions that you feed into your enterprise AI tool to support tasks like:

• Prioritization
• Building a critical path
• Identifying dependencies
• Understanding a tech stack
• And more

Yes, you can copy-paste or upload your process maps, business rules, logic tables, technology stack diagrams, and system architecture diagrams in their human-consumable state. But it’s far better to put them into a format AI can absorb cleanly. A PowerPoint slide or a swimlane diagram is built for the human eye — visual layout, color, position on the page all carry meaning that a slide’s underlying text doesn’t capture. Markdown strips that away and leaves structure: headers, hierarchy, plain logic. That’s the format AI parses fastest and most accurately, which frees it to do what it does best — connect dots, surface insights, and reveal blind spots that would otherwise stay buried in a slide deck.

This is the step where the second deliverable actually gets built, so it’s worth being deliberate about three things.

Everything gets recorded, because what you don’t capture can’t be turned into AI-enabled work later. The temptation in a blueprinting exercise is to document what’s interesting. Document what’s there.

Be careful not to let AI invent the process. Models will happily document the steps they think make sense rather than the steps your team actually performs, and those are rarely the same. Someone who does the work has to read it before it’s committed.

And capture the baseline while you’re in here — what the process costs today, how long it takes, how often it’s run. You’ll need it in Step Seven to prove anything improved, and six months after go-live nobody remembers what it used to take. The number you end up using will be whatever the most confident person in the room asserts.

Step ThreeBuild the Opportunity Backlog

With the process landscape mapped, you now have visibility into what actually happens, where the friction lives, and where the gaps are. That visibility needs a home. The next step is to turn it into an opportunity backlog — a single, structured list of every improvement worth considering, so decisions about what to tackle first are made deliberately rather than by whoever shouted loudest in the last steering committee meeting.

Every entry in the backlog should carry the same fields, no exceptions:

A few best practices worth calling out:

As with the process artifacts in Step Two, the opportunity backlog needs to exist in multiple formats for multiple audiences. The working version lives in Excel, where prioritization, filtering, and sorting actually happen. A summary slide distills the top opportunities — typically the highest-impact, highest-priority items — for steering committee and leadership audiences who don’t need the full 200-row list. And a Markdown version exists specifically for your enterprise AI tool, so it can help with tasks like clustering similar opportunities, flagging duplicates across departments, or surfacing opportunities that quietly support multiple goals at once.

One more rule, and it’s the one that keeps this from splitting into two programs. AI-enabled opportunities go in the same backlog as everything else. Not a separate AI backlog, not an AI workstream running in parallel with its own governance. The moment AI opportunities get their own list, they get their own success criteria, and you’re back to running pilots nobody can compare to anything. An opportunity to automate invoice matching with AI competes for the same resource, on the same fields, against an opportunity to renegotiate a vendor contract. If it can’t win on those terms, it shouldn’t be funded.

Step FourPrioritize the Backlog

Once the opportunity backlog exists, the temptation is to prioritize by instinct — tackle whatever feels most urgent, or whatever the loudest stakeholder is pushing for. That’s how backlogs turn into whack-a-mole. A framework forces the same criteria to be applied to every opportunity, which is what actually makes prioritization defensible when someone asks why their pet project didn’t make the cut.

There’s no single “correct” framework — the right one depends on how much rigor your organization has appetite for and how much data you actually have at the early stages. Here are a few worth knowing:

In practice, most transformations end up using two: something fast and visual (like value vs. effort) for early triage and stakeholder workshops, and something more rigorous (like RICE or a custom weighted model) once the backlog has been narrowed down and the remaining opportunities need a finer-grained ranking.

The AI layer. Two things change here.

The first is a use for the Markdown files you built in Step Two. Point your AI tool at the backlog alongside the goals file and ask it to flag every opportunity whose score doesn’t match how it was tagged against the goals. Scoring drifts — the same reviewer is harsher on a Friday than a Tuesday — and inconsistency across 200 rows is far easier to catch mechanically than by reading.

The second is a category problem that will distort your portfolio if you don’t name it. Bets fall into three buckets, and only two of them can be scored. Efficiency bets save cost or time, and they model cleanly. Innovation bets create new revenue or capability, they’re high variance, and most will fail by design. Infrastructure bets — the intelligence layer itself, access, logging, data plumbing — have no standalone payback case at all, and you should stop pretending otherwise.

Run any scoring framework across all three and efficiency wins every time, because it’s the only one finance can model with a straight face. Infrastructure scores worst and is the thing everything else depends on. So carve it out and fund it as a fixed cost of operating, outside the scoring exercise. Then set an explicit split between efficiency and innovation and be prepared to defend it every quarter. That split is a governance decision, not a finance one — it belongs to whoever owns the program.

Step FiveBuild the Critical Path

Once the backlog is prioritized, the question shifts from “what should we do” to “in what order, and by when.” That’s what a critical path answers. It’s a timeline view that plots the major milestones across the highest-priority opportunities — not every single backlog item, just the ones that actually determine how long the overall transformation takes.

The critical path matters because opportunities aren’t independent. Some can run in parallel; others depend on something upstream being finished first. A quick win that takes one day is meaningless to the overall timeline if it’s sitting behind a six-month dependency. The critical path exists to surface that sequencing so leadership isn’t just looking at a prioritized list — they’re looking at a realistic timeline, with the bottlenecks visible.

A few things worth keeping in mind when building one:

Here’s what that looks like using the opportunities from the backlog:

Three views of the same six opportunities, answering different questions. Milestones is the board update — it says when things land. Durations shows overlap and load, which is what you need when the argument is about whether the team can carry all of it at once. Phases is the funding view, because it lets you ask for tranche two once tranche one has proven itself.

Whichever you use, the point isn’t to capture everything happening across the transformation. It’s to give leadership one glance that answers when this actually finishes, and what’s on the critical chain to get there.

The AI layer. Dependency detection is where the Step Two artefacts pay off hardest. Feed the backlog and the system architecture Markdown in together and ask which opportunities can’t start until another one closes. It won’t get all of them right, but it surfaces the dependencies nobody thought to ask about, which is the exact failure mode a critical path exists to prevent.

And sequence the infrastructure first. The intelligence layer is a dependency for a large share of what follows, and it’s the least visible item on the path — which means it’s the one most likely to slip without anyone escalating. Put it on the critical path explicitly, with a date, so that slipping is visible.

Step SixMobilize Workstreams and Standardize Reporting

With the backlog prioritized and the critical path mapped, the opportunities need to be organized into workstreams — clusters of related opportunities that a single team can own end to end, rather than a flat list of 50 individual initiatives with no clear home. Grouping by process area, department, or system usually works well, since it keeps ownership clean and avoids the same team getting pulled into five unrelated efforts at once.

Each workstream needs a single accountable owner — the same principle from the backlog itself, applied at a higher level. That owner is responsible not just for delivery, but for reporting status in a way that’s consistent across every workstream, so leadership can compare progress apples-to-apples instead of parsing five different formats from five different teams.

That consistency is the part organizations skip, and it’s the part that matters most. A standardized status update should always answer the same handful of questions: Where do things stand? What’s blocking progress? What’s coming next? Without a standard format, status updates become narrative and inconsistent — one team reports in paragraphs, another in a spreadsheet, a third only when asked — and leadership loses the ability to actually compare workstreams against each other.

Here’s what that looks like as a standard template:

Every workstream owner fills out the same six fields on the same cadence — the format above is the template, filled in with a working example. When a dozen workstreams all report this way, leadership can scan status across the entire transformation in minutes instead of chasing down five different formats.

One workstream that isn’t about the work. Get the program team onto a working AI harness early, with enough knowledge to use it properly — strengths, weaknesses, how different tools behave. This isn’t primarily about productivity. It’s about who spots the opportunities. Someone who uses these tools daily recognises a candidate for automation inside their own workflow. Someone who has read a memo about AI does not. Your program cannot find the opportunities on its own, and it shouldn’t try.

Two things the template doesn’t solve, and both are where programs quietly die.

The first is adoption. Progress measures whether the work got done. It says nothing about whether anyone changed what they do, and a workstream can report 100% complete while the process it replaced still runs in parallel because forty people never switched. Add an adoption measure next to progress — transactions running through the new path, users active in the new system, however it’s counted for you — and hold owners to both. A green progress bar next to a flat adoption number is the most important signal in the whole program, and the default template hides it.

The second is what happens when a report doesn’t arrive, or arrives amber six weeks running. Decide it before you need it. Who chases, and by when. What triggers escalation rather than another polite reminder. And what leadership is actually empowered to do about a stalled workstream — reallocate, cut scope, or stop it. A reporting cadence with no consequence attached becomes optional within two months, and you’ll be the last to know.

The AI layer. Once the cadence is running, status updates are a good candidate for drafting from the underlying data rather than written from scratch on a Friday afternoon. The owner still reviews and signs off. The difference between a template filled in properly and one that’s rushed is usually just how long it takes.

Step SevenValue Capture

Every prior step has been about getting the work identified, prioritized, and moving. Value capture is where you prove it actually mattered. It’s the discipline of tracking the financial and non-financial impact of the transformation as it happens — not projected value, not the estimate from the backlog, but value that’s actually landed.

Getting this right requires being precise about a few distinctions that are easy to blur together.

A few best practices for running this well:

Here’s what that tracking looks like visualized:

In its default state, the chart shows cumulative value as white bars — dotted for months that have already closed, open for months still ahead. Toggling to “this period” shows the incremental value captured each month rather than the running total, and flipping on “show breakdown by opportunity” splits each bar into segments so you can see exactly which opportunities are driving the number, rather than treating value capture as one undifferentiated total. The dashed marker on each column is that period’s forecast — the original baseline, held still so you can see whether actuals landed ahead or behind.

What Cascades

Three things leave the program, and they’re the reason this beats buying licences.

The people. Secondees return to their functions with a changed default about how work gets produced. That’s thirty distribution points you didn’t have to create, carrying a way of working rather than a tool recommendation.

The layer. The next program starts from a populated intelligence layer instead of a blank page, which compresses its first three months into roughly three weeks. This only happens if someone owns the layer after the program closes — name them in the charter, not in the wind-down.

The governance. The prioritisation criteria, the reporting cadence and the value capture standard are reusable. By the second program, Legal, HR and IT have run the pattern once and stopped treating every request as novel.

That last point deserves a note of its own, because it’s where speed is usually lost. Put a named person from Legal, HR and IT inside the program with a standing slot rather than a ticket queue, accountable for the program moving and not only for the risk of it moving. Then pre-clear categories instead of reviewing case by case: internal data with a human reviewing the output goes self-serve against a published standard; anything involving personal or client data gets a light review measured in days; anything customer-facing, regulated, or making a decision about a person gets a full review every time. The great majority of what you do falls in the first bucket, and the entire point of tiering is that the small number which genuinely matter get real attention.

Where this breaks. Four honest failure modes. The intelligence layer isn’t a charter deliverable, so it dies with the program and you’ve run an expensive pilot. Your consultants have the wrong incentive, because AI compresses exactly the billable hours that process documentation and deck production represent — put the layer in the statement of work with an acceptance standard, and make the Markdown yours on day one rather than at close. You pick a beachhead that’s politically contested or mid-reorganisation, and produce a result you can’t cascade. Or you don’t have a transformation program at all, in which case this is a function-level play with the same sequence and a smaller blast radius.