Timeline Clarity
Evaluates whether there's a realistic, calendar-backed plan that accounts for the hard work of moving from demo to production.
AI demos often look "almost ready," but converting demos to production requires unglamorous work: policy reviews, data access approvals, security checks, staff training, and workflow integration. Without explicit timelines for these steps, pilots drift indefinitely burning time, budget, and community trust. Clear timelines with go/no-go checkpoints force teams to show evidence (reduced wait times, no widening equity gaps) before expanding, and protect communities from endless experiments that never deliver.
What Good Looks Like
✓ 30/60/90-day plans with specific calendar dates for start, mid-point check, and day-90 decision
✓ Pre-registered success criteria defining what "good enough to scale" means quantitatively
✓ Go/no-go checkpoints that compare results to targets and trigger rollbacks if not met
✓ Time budgeted for "plumbing": integration with real workflows, staff training, data access approvals, privacy/security reviews
✓ Scope limited to low-risk use (assist, draft, triage) until safety and equity metrics are stable
✓ Documented handoff plan to "steady state" including first 90 days of scale-up ownership
✓ Contingency buffers for common delays (policy approvals, data access)
✓ Sunset plan and user notice process in case pilot fails
What to Watch Out For
✗ No specific dates—just phases like "Q2" or "soon"
✗ Timeline ignores common blockers: policy approvals, data access, staff training, security reviews
✗ No go/no-go checkpoints to decide whether to continue, adjust, or stop
✗ Pilot phase is open-ended with no defined end date or success criteria
✗ Rushing to deploy in high-stakes contexts before proving safety and equity
✗ No documented handoff plan for who owns the system after pilot
✗ Timeline is purely aspirational with no evidence from similar projects
Tests To Apply
□ Are there specific calendar dates for: start, mid-point check, and day-90 decision?
□ Does timeline include time for: policy/compliance reviews, data access approvals, staff training, integration with real workflows?
□ Are there pre-defined success criteria that must be met to move forward?
□ Is the pilot limited to low-risk use cases (e.g., staff-facing, suggestion mode) until safety is proven?
□ Is there a documented handoff plan for "steady state" after pilot (who owns it, how monitoring continues)?
□ Are there contingency buffers for delays?
□ If pilot fails, is there a sunset plan that protects users?
□ Is timeline based on evidence from similar projects (not just optimistic guesses)?
Key Questions to Ask
-
What are the specific calendar dates for your pilot start, mid-point review, and go/no-go decision?
-
What would cause you to pause or stop the pilot?
-
What approvals or integrations need to happen before launch, and are those in your timeline?
-
After the pilot, who owns this system and how will ongoing monitoring work?
-
What evidence from similar projects validates this timeline is realistic?
Apply the Cross-Cutting Lenses
After evaluating the core criteria above, apply these two additional lenses to assess equity outcomes and evidence quality.
Equity & Safety Check
When evaluating Timeline Clarity through the equity and safety lens, assess whether rushing could bypass necessary safety testing or exclude harder-to-reach communities.
Gate Assessment:
🟢 CONTINUE: Adequate time for inclusive testing, clear go/no-go gates, safety prioritized over speed
🟡 ADJUST: Tight timeline but checkpoints exist, watching for pressure points
🔴 STOP: Timeline forces corner-cutting on safety or systematically excludes hard-to-reach groups
Check for:
□ Do timelines allow adequate testing with all relevant user subgroups (not just easy-to-reach populations)?
□ Are there explicit go/no-go checkpoints where equity metrics must be met before proceeding?
□ Could deadline pressure force skipping accessibility testing, language support, or community review?
□ Is there a named decision-maker who can delay launch if safety or equity concerns arise?
□ Are rollback triggers time-bound (e.g., "if X issue not resolved in Y days, we pause")?
□ Do timelines include buffer for responding to community feedback and making adjustments?
Evidence & Uncertainty Check
When evaluating Timeline Clarity through the evidence and uncertainty lens, assess whether timelines allow proper evaluation and whether uncertainty is acknowledged.
Quality Grade:
🅰️ A (Strong): Evidence-based timeline with checkpoints tied to metrics, contingency buffers, realistic based on similar projects
🅱️ B (Moderate): Reasonable timeline with some buffers, plan to adjust if needed
🅲 C (Weak): Arbitrary dates with no slack, optimistic assumptions, no decision criteria for delays, high risk of pilot purgatory
Check for:
□ Are go/no-go checkpoints tied to pre-defined success criteria (not arbitrary dates)?
□ Is there adequate time for causal testing (A/B tests, shadow deployments) to isolate AI's effect?
□ Do timelines account for common delays (policy approvals, data access, security reviews)?
□ Are there contingency buffers for when things take longer than expected?
□ Do they acknowledge uncertainty in timeline ("best case X, likely case Y, worst case Z")?
□ Are there documented decision criteria for extending vs. stopping if timeline slips?
□ Is there evidence from similar projects to validate timeline assumptions?