AI Integration Timeline

An AI integration timeline becomes credible when every major activity has a predecessor, an owner and evidence of completion. A promise of a fixed number of weeks is weak if nobody has confirmed source access, representative data or the destination's release window. The schedule should show what must happen before the next step can start and what changes when a prerequisite slips.

This guide helps project sponsors, delivery managers and application owners plan AI integration and delivery. The worked network uses explicit illustrative working-day assumptions. It is not a standard duration, a supplier commitment or a promise about an OpenForAI engagement.

Distinguish effort, duration and waiting

Effort is the amount of work, often expressed in person-days. Duration is the elapsed working time required by an activity with its available resources. Waiting is time spent before a dependency, decision or permitted window becomes available. They interact but should not be treated as the same quantity.

Eight person-days of connector work do not necessarily become four elapsed days when a second engineer is added. Some tasks can run in parallel; others depend on a shared environment, a single system owner or sequential discovery. Conversely, a six-day wait for a sandbox may require little engineering effort while still delaying the critical path.

The GAO Schedule Assessment Guide connects credible integrated schedules with understanding the consequences of slippage. It is a general scheduling reference, not a Saudi delivery rule. The practical network here makes those consequences visible for a bounded integration.

Define readiness before starting the clock

List the initial conditions: an agreed outcome, named application owners, permitted sample data, a supported interface route, available specialists and an identified test environment. If these are not ready, include the work to obtain them in the schedule. Do not omit discovery and later describe its unresolved questions as unexpected delay.

The integration project brief should state the scope and customer inputs. The statement of work should define their delivery dates, acceptance responsibilities and change process. A dependency owned by the customer is still a dependency of the project; assigning it externally does not make its elapsed time disappear.

Document working calendars, holidays, business closures and allowed change windows for the actual organisation. Do not assume all suppliers, reviewers and system owners share the same working days. Use the agreed calendar to turn the logical sequence into dates only after resource and access assumptions are known.

A worked dependency network

Assume a bounded bilingual workflow with one source and one destination. A masked reference sample and an evaluation environment are available independently of the destination sandbox. This allows reference preparation and model evaluation to run while application access and connector work progress. All durations below are illustrative elapsed working days, measured from a day-zero start.

Illustrative schedule with parallel branches

Activity	Duration	Predecessor	Earliest finish
A: scope and interface contract	4	Initial readiness	Day 4
B: sandbox access preparation	6	A	Day 10
C: reviewed reference cases	5	A	Day 9
D: connector implementation	8	B	Day 18
E: AI task evaluation	6	C	Day 15
F: integrated testing and correction	5	D and E	Day 23
G: release-readiness review	2	F	Day 25
H: wait for permitted window	3	G	Day 28
I: release and observation allowance	3	H	Day 31

The longer branch reaches integrated testing through A, B and D: 4 + 6 + 8 = 18 days. The reference-and-evaluation branch takes 4 + 5 + 6 = 15 days. Testing starts at the later finish, day 18. The illustrative total is 18 + 5 + 2 + 3 + 3 = 31 elapsed working days, not the sum of every row and not 31 person-days of labour.

The evaluation branch has three days of timing flexibility before it delays the start of testing, assuming resources and other dependencies remain unchanged. A four-day delay on that branch moves its finish to day 19 and delays testing by one day before considering the release-window effect. The same delay on a different branch may have a different consequence.

Release windows can magnify a small slip

The three-day wait in the example is an assumed allowance, not a reusable rule. In a real calendar, a missed change window may push release to the next permitted date. A one-day technical slip can therefore create a longer operational delay. Model the actual windows and the latest readiness decision needed to use them.

Do not book a release on the assumption that reviewers will waive a failed gate. Agree a go/no-go cutoff and the evidence required at that point. The deployment plan should identify rollback authority, in-flight work handling and support availability. A calendar slot is not proof of readiness.

Observation after release also needs an evidence definition. Three days in an example may not expose rare events or representative business cycles. Decide what cases and outcomes must be observed and what support remains during that period. Extend or restrict exposure when evidence is insufficient rather than declaring success because the planned time elapsed.

Turn milestones into evidence, not activity reports

“Connector complete” should mean an accepted set of operations works against the intended interface with agreed permission and failure behaviour. “Evaluation complete” should mean the reviewed cases, rubric, results and unresolved issues are available. “Testing complete” should refer to the acceptance evidence, including recovery and business-owner decisions.

Give each milestone an owner and an acceptance reviewer. A percentage-complete report can hide a final unresolved issue that blocks every downstream task. Prefer concrete remaining work: a missing destination permission, an unreviewed Arabic case class or a failed lost-response test. Those statements support a scheduling decision.

Record assumptions that allow work to overlap. If evaluation needs the same engineer or environment as connector development, the branches cannot be treated as fully parallel. Resource constraints can change the critical path even when the technical dependencies stay the same. Recalculate the plan using actual allocations.

Manage uncertainty without inventing precision

For uncertain activities, record a plausible range and the facts that would narrow it. A legacy interface may require exploration before a defensible estimate exists. A reviewed dataset may depend on the availability of subject experts. Use an initial discovery decision to replace assumptions with evidence, then update the remaining forecast.

Keep reserve time visible and explain its purpose. Hiding contingency inside every activity makes it difficult to see what risk the schedule covers. A project may need an explicit allowance for a known uncertain interface, while another dependency has a fixed external date. Treat these differently rather than adding one arbitrary percentage to all work.

Separate scope change from execution variance. A new destination or approval route changes the network; it is not merely slower coding. Record the added deliverable, affected predecessors, resources and release impact. Connect the consequence to the cost model and the overrun diagnosis without assuming that every day of delay incurs the same charge.

A weekly scheduling conversation that resolves blockers

Review the next irreversible commitment, not just tasks that were busy last week. Ask which prerequisite can prevent it, who owns that prerequisite and what evidence is due next. Update actual starts and finishes, remaining durations and the current critical path. Keep the original baseline so changes remain understandable.

Use a short blocker record: affected activity, missing input, responsible owner, required decision date, consequence and available alternative. For example, unavailable write permissions may allow read-only contract validation to continue, but they do not prove the write path. State what the alternative advances and what remains blocked.

Escalate a decision with options. The sponsor may narrow the first release, move the window or supply additional review capacity. More developers are useful only when the constrained work can be divided and the required access exists. A dependency-led conversation makes that distinction visible.

Check the resource assumption behind the parallel branch

Revisit the worked example if one specialist must perform both connector implementation and AI evaluation. Suppose that person completes D first, from day 10 to day 18, then performs E for six days, finishing at day 24. The reference cases were ready at day 9, but they could not create parallel progress without an available evaluator.

Under the same illustrative downstream allowances, testing finishes at day 29, readiness at day 31, the assumed wait at day 34 and release observation at day 37. The six-day difference from the original 31-day plan comes from the explicit resource constraint. Actual calendar windows could change the result further.

The sponsor can now assess a meaningful option: supply a qualified independent evaluator, change the sequence or accept the revised forecast. Adding an unrelated engineer would not remove the constraint. This is why a dependency diagram needs named resource availability before it becomes a credible delivery commitment.

Plan operational handover and closure

Include the receiving team's availability, runbook exercise, access transfer and unresolved-case review. The monitoring plan must be operational before the delivery team steps back. A project is not complete merely because the application was deployed if nobody has accepted its ongoing service responsibilities.

Bring the interface inventory, current access status, reviewer availability and permitted change windows to a project enquiry. Discuss a dependency-based timeline for your AI integration to turn duration expectations into a plan with measurable readiness, explicit uncertainty and accountable decisions.