# AI implementation schedule worksheet

Use this for one defined workflow. Separate hands-on effort from elapsed time and waiting. Blank fields need a decision; they do not mean zero effort or no dependency.

- Workflow:
- Sponsor and decision owner:
- Delivery lead:
- Date prepared / next review:
- Current milestone: demonstration / operator trial / limited production / wider rollout
- Observable finish condition:
- Included case types, teams, and systems:
- Excluded scope:
- Proposed start date and what must be ready on that date:
- Required finish date and why:

## 1. Record dependencies and owners

Use named people, not departments. Add a row when a supplier, procurement step, or shared specialist affects the date. Record the basis of each estimate: confirmed appointment, prior measurement, supplier commitment, or assumption.

| ID  | Deliverable                             | Owner | Depends on | Hands-on effort | Elapsed business days | Estimate basis | Completion evidence |
| --- | --------------------------------------- | ----- | ---------- | --------------- | --------------------- | -------------- | ------------------- |
| A   | Scope and acceptance cases              |       |            |                 |                       |                |                     |
| B   | Approved data and working system access |       |            |                 |                       |                |                     |
| C   | Connected workflow                      |       |            |                 |                       |                |                     |
| D   | Acceptance and corrections              |       |            |                 |                       |                |                     |
| E   | Controlled rollout and support          |       |            |                 |                       |                |                     |
| F   | Additional dependency                   |       |            |                 |                       |                |                     |

For each row, confirm whether the required people are available. Two tasks that share one fully occupied owner cannot automatically run in parallel.

## 2. Build the calendar

| ID  | Earliest start | Planned finish | Reserved review slot | Dependency commitment confirmed by | What could move this date? |
| --- | -------------- | -------------- | -------------------- | ---------------------------------- | -------------------------- |
| A   |                |                |                      |                                    |                            |
| B   |                |                |                      |                                    |                            |
| C   |                |                |                      |                                    |                            |
| D   |                |                |                      |                                    |                            |
| E   |                |                |                      |                                    |                            |
| F   |                |                |                      |                                    |                            |

Account for weekends, holidays, people working part time, change windows, and supplier lead times. Include explicit allowance or scenarios for uncertain work, with a stated basis. Do not assume all acceptance cases pass the first time.

## 3. Check the longest dependency chain

For work that truly starts in parallel, use the latest prerequisite finish as the next step's earliest start. Add the subsequent work in sequence. Check resource conflicts separately.

Illustrative example only: scope preparation takes 5 business days and access takes 10, both starting together with separate owners. Build takes 10 after both finish, acceptance takes 5, and rollout takes 5. Duration: max(5, 10) + 10 + 5 + 5 = 30 business days. If access instead takes 15, the same sequence takes 35. These are hypothetical inputs, not delivery benchmarks.

- Dependency chain that determines our finish:
- Planned elapsed duration:
- Longer-duration scenario and assumptions:
- Unresolved commitments that prevent a reliable date:
- Decision that could shorten the chain:
- Scope that can be deferred while retaining a useful release:

## 4. Define acceptance and release

- Representative cases and expected outcomes:
- Failures that block release:
- Person authorized to accept the release:
- Operator review dates:
- Correction and retest allowance, and basis:
- Support owner and coverage:
- Manual fallback and evidence it works:
- Limits of the first live release:
- Evidence required before expansion:

## 5. Update the forecast

| Review date | Changed assumption or result | Remaining duration | Effect on finish | Decision / owner / due date |
| ----------- | ---------------------------- | ------------------ | ---------------- | --------------------------- |
|             |                              |                    |                  |                             |

Keep the original commitment and revised forecast visible. A dependency marked complete should link to evidence, such as a working connection or an accepted test result.

Prepared by PlatformBridge. Companion guide: https://www.platformbridge.ai/guides/ai-implementation-timeline