Build an AI Implementation Roadmap Around Dependencies and Capacity

Several approved projects can still exceed the team's capacity

Imagine a growing service business with three approved AI initiatives. Proposal assistance would help staff draft responses from approved service information. Content assistance would help turn the same expertise into website drafts. Lead summaries would help the sales team review enquiries arriving through its website and CRM.

All three initiatives need the same service expert to review their outputs. Which can the team start and support together?

This is an Off Piste hypothetical planning example. The people, workload estimates, budgets and outcomes throughout this guide are invented assumptions to demonstrate the scheduling decision. They aren't client results, forecasts or recommended staffing levels.

If your candidates still need assessment, first prioritise viable AI use cases. We'll turn the approved shortlist into a sequence with named dependencies, confirmed capacity and evidence that unlocks the next commitment.

Carry the approved shortlist into a dependency register

Bring forward the intended outcome, accountable owner, approved intervention and unresolved assumptions for each initiative. Carry forward the readiness findings and confirm the delivery model before allocating implementation work. An unresolved supplier decision can change both the delivery effort and the people needed.

The Digital Transformation Agency's Standard 4 planning guidance connects initiative milestones with funding and dependencies. It also includes staged commitments and points where work can pause, stop or change direction. This is Australian Government guidance. We're adapting its planning concepts to a growing business, without importing its agency obligations or long planning horizon.

For each initiative, record what must exist before work starts and what evidence proves it's ready. Distinguish hard predecessors, shared foundations and resource conflicts so each constraint enters the schedule.

In our example, an approved service-source library is a hard predecessor for proposal and content pilots. Both depend on the same foundation. The lead-summary pilot instead needs repaired CRM fields and an agreed sales handoff. Morgan, the service expert, is a shared reviewer across all three. Morgan's availability creates a resource conflict even when the technical prerequisites are complete.

Give every prerequisite a named owner and an observable completion condition. “Improve the CRM” is too open-ended to release dependent work. “Priya confirms that representative website enquiries reach the correct CRM fields and named sales owner” gives the team something it can check.

Record preferred ordering separately. The team may prefer proposal assistance first because a tender is approaching. That preference can change. The requirement for approved service claims remains until the team changes the workflow or its acceptance conditions.

Give shared foundations their own owners and commitments

Shared preparation needs a place in the roadmap with its own capacity allocation. Otherwise, several project owners can assume someone else will supply it.

In the hypothetical business, Casey owns the service-source library. Casey has four delivery hours available each week and estimates eight hours to assemble, reconcile and version the initial material. That's two weeks of preparation if the estimate holds. Morgan must then approve the service claims before either dependent pilot starts. Casey also owns subsequent source corrections and maintenance.

Use the knowledge preparation guide to prepare and maintain approved source knowledge. The roadmap records the owner, completion evidence and initiatives waiting for that work.

Priya owns the separate CRM repair. She confirms three integration hours a week, with six hours initially estimated for field mapping and handoff checks. Her completion evidence is a set of representative enquiries reaching the agreed records and sales owner. If she discovers that a check requires Morgan, that review must enter Morgan's allocation before it can happen.

Governance and procurement can also create shared dependencies. Have the operations lead assign governance ownership and approvals, including who can authorise data access and accept operating responsibility. Where a supplier is involved, complete supplier due diligence before the relevant purchase or data transfer. Give unresolved checks an owner and a decision date.

Gartner's AI Roadmap: How to Build and Scale AI advises starting with a resourcing plan and developing portfolio management as adoption grows. That's supplementary analyst guidance with an enterprise framing. For this small team, the useful implication is to make shared work and people visible before promising concurrent delivery.

Schedule delivery and review as separate resources

A project can have delivery capacity available while its reviewer is fully occupied. Keep both allocations in the roadmap and confirm them with the people doing the work.

In our hypothetical model, Alex has six delivery hours a week available to configure proposal assistance and manage corrections. Casey's four hours support source preparation first. Priya's three integration hours support the CRM work. Each person has confirmed this allocation alongside their normal responsibilities.

Morgan confirms four reviewer hours a week after normal service delivery. Proposal assistance is estimated to need three hours of review each week. Content assistance needs two, and lead-summary review needs two. Concurrent demand would be seven hours against four available, leaving a three-hour shortfall. These workload estimates are illustrative.

During preparation, reserve Morgan's time for source approval and exception handling. Once that gate passes, schedule the proposal pilot alone. Allocate three hours to its planned review and reserve the remaining hour for unexpected questions or corrections. Both other pilots wait for reviewer capacity. An apparently spare hour doesn't cover either pilot's assumed two-hour requirement.

CRM repair can proceed while proposal work runs because Priya has separately confirmed capacity and its checks don't require Morgan under the current plan. The lead-summary pilot still requires accepted CRM evidence and an available reviewer.

Include setup, correction, monitoring and ongoing review when estimating capacity. After proposal acceptance, Morgan may still need time to supervise live outputs. Measure that operating load before treating any hours as released. If Morgan's ongoing proposal work consumes two hours, only two of the original four remain before allowing for exceptions. Re-estimate the next pilot and its support needs before making a new commitment.

Fund the next decision and define its evidence gate

Each stage needs an authorised spending limit, a decision owner, the evidence required and the next commitment that evidence could unlock. A forecast for the whole portfolio can remain provisional while the next stage has a firm boundary.

The DTA's guidance for moving AI proof of concept to scale describes progression through proof of concept, pilot and production, with evaluation at each stage and integration into business operations. We're adapting government guidance on staged evaluation. It provides no guaranteed delivery schedule for your business.

For the fictional proposal initiative, operations lead Sam authorises preparation first. The boundary is Casey's eight source-preparation hours, up to four Morgan review hours and an AUD 500 cash-spend ceiling. The cash ceiling includes applicable GST and excludes internal staff time, which is bounded separately. Unused authority doesn't automatically transfer to another stage.

Source approval allows Sam to consider a bounded pilot. In this model, that next decision could authorise up to 12 Alex delivery hours, eight Morgan review and exception hours, and AUD 1,000 of additional cash spending including applicable GST. Those are illustrative ceilings for a proposed tranche. They become commitments only when Sam approves them. Any unfinished work returns for a decision when a ceiling is reached.

Test the workflow before release against agreed acceptance conditions. For proposal assistance, the gate includes supported service claims, appropriate handling of missing information and a workable correction path. Sam needs recorded test evidence and Morgan's acceptance before authorising operational use.

After launch, use the live workflow scorecard to review reliability, full operating cost and the business outcome. The roadmap consumes that evidence when Sam decides whether to continue, change or expand the commitment. It also records who owns support and how much ongoing review remains booked.

Resequence the portfolio when a gate fails

Suppose proposal testing finds unsupported service claims. In this hypothetical outcome, the draft is drawing on conflicting material in the source library. Morgan declines acceptance, so expansion pauses and Sam withholds operational approval.

The failed gate changes a dependency assumption. The previously approved library needs repair and fresh evidence. Content assistance remains blocked because it uses the same material. Starting its pilot would carry the unresolved source problem into another initiative and create extra review demand.

Sam allocates Morgan's next four-hour weekly block to the problem. Two hours support source reconciliation with Casey, one hour covers retesting, and one remains reserved for exceptions. Casey uses their confirmed delivery allocation for corrections. Alex uses their delivery allocation to adjust the proposal workflow and prepare fresh tests. If these tasks exceed the authorised preparation or pilot limits, Sam must approve a revised boundary before more work proceeds.

Priya can continue CRM repair within her separate capacity and approval. That work doesn't depend on the service library under the current design. The lead-summary pilot still waits for Morgan's capacity and accepted CRM evidence.

After repair, Morgan reviews the new evidence. Sam then decides whether another bounded test is justified, whether the workflow needs redesign or whether it should stop. Before resuming the wider sequence, update the source status, remaining spend, reviewer allocation and expected operating load. Give the next project a conditional start based on those revised facts.

Complete a roadmap record for each initiative

Copy these prompts into your planning document and complete one record for each initiative. Update the answers when evidence changes. A conditional start such as “after source acceptance and reviewer allocation” is useful while a calendar date remains uncertain.

1. Name the initiative, intended business outcome and accountable owner.
2. Record each hard predecessor and the evidence that will confirm completion.
3. Identify shared foundations and every other initiative that depends on them.
4. Name each prerequisite owner and confirm the capacity they've accepted.
5. Estimate delivery effort, name its owner and record confirmed availability after normal work.
6. Estimate reviewer demand separately and record confirmed availability, exception allowance and existing operating commitments.
7. Set the earliest conditional start and identify which assumptions could move it.
8. Record the authorised cash-spend ceiling and staff-time allocation for the current stage, plus anything still awaiting approval.
9. Define the evidence gate, who accepts the evidence and who authorises the next commitment.
10. Assign ongoing support, monitoring, source maintenance and review load after launch.
11. Record the next decision, its owner and the trigger for revisiting the sequence.

Here's a completed initial record from the same hypothetical model. Proposal assistance aims to support proposal drafting from approved service claims, with Sam accountable for the business outcome. Its hard predecessor is the service-source library, owned by Casey. Completion requires a versioned source set with conflicting claims resolved and Morgan's recorded approval. Content assistance shares that foundation and waits for its approval.

Casey has four hours a week confirmed for the eight-hour preparation estimate. Morgan can supply up to four preparation-review hours within the authorised stage. Alex has six delivery hours a week available for the later pilot, with up to 12 hours proposed for configuration and corrections. Morgan's pilot demand is three review hours a week plus one exception hour, within four confirmed available hours. Morgan's full allocation is available because live AI review hasn't started. The earliest pilot start is after source approval, Sam's pilot authorisation and reconfirmation of those allocations.

The current preparation authority is AUD 500 cash including applicable GST, Casey's eight hours and Morgan's four hours. The proposed pilot boundary of AUD 1,000 additional cash, 12 Alex hours and eight Morgan hours awaits Sam's decision. Source acceptance is the first gate. The later operational gate requires recorded proposal tests meeting the agreed conditions and Morgan's acceptance, followed by Sam's release decision.

Alex would own workflow support, Casey would maintain sources and Morgan would review live outputs. Their ongoing load must be estimated and accepted before release, then checked against operating evidence. Sam's next decision is whether to fund the bounded pilot after source acceptance. A failed claim check, an exceeded allocation or changed reviewer availability triggers a revised record before further commitment.

Agree the next commitment and the conditions for changing it

Bring the records together and check the same person's hours across every initiative. Agree which prerequisite can be completed now, which pilot has both delivery and review capacity, and what stays waiting. Put an owner against each unresolved condition.

If the binding constraint is poor website enquiry data or an unreliable CRM handoff, use the completed record to scope the website intake and system handoff. Identify the fields, routing and ownership that need repair, along with the evidence that would release dependent work.

In our example, Sam can authorise source preparation while Priya progresses the separately resourced CRM repair. Proposal testing follows only after the source gate and capacity check. The other pilots wait for their dependencies and reviewer allocation. Record the next commitment's owner, limit and evidence gate before another initiative starts.