INO-V AI Team - Initial Program Board — v1 Build ✎

Gantt

Task table

System map — INO-V AI Team - Initial Program Board

Status snapshot of every subsystem. Done = shipped, Partial = scaffolded with stubs, Todo = planned, Blocked = waiting on external. Click a ticket in the Gantt to drill into details.

Business logic flow — INO-V AI Team - Initial Program Board

How a use case is supposed to travel through this team, end to end. Steps 2–4 are the gate that does not exist yet (ticket OPS-6) — the first use-case batch was run without it, and Jared confirmed on 2026-07-27 that no mutually agreed scope of work is being produced today. Everything after step 5 is constrained by environments, not by code.

Step 1 — Intake: a business unit brings a use case

Requests arrive through the AI Champions workgroup and through direct exec approach. Most come from senior executives. Bilal runs the intake process and sets the sessions; Jared is on most of them at least at the start. Kado joins as observer first (Bilal has been asked to include him), speaking up on process, staying quiet on healthcare-adjacent ones until ramped.

Step 2 — Discovery (week 1): understand the lay of the land

Why are they bringing this to us, what is the current state, what are the risks, assumptions and dependencies. The real work of this session is hunting the branches: which other teams does this actually touch, who is on first, who has to be pulled in whether they want to be. Clinical is the worked example — discovery surfaced IT/Engineering (Yidu Wang, Scott Jubeck) and product engineering (Sonya Johnson) as unavoidable participants.

Step 3 — Spec hardening (week 2): pin it down

Current state documented by the business, future state drafted with them, the participant list hardened. Every party that has to weigh in is named here, not later. This is also where the permanent business owner is identified — the person who will inherit the solution, because if this team owns it, it owns it forever and has no capacity for that.

Step 4 — Signed scope (week 3): the gate

Specifications delivered, formalised and signed off by the named decision maker, with a timeline to MVP. In scope, explicitly out of scope, MVP definition, success measure. Anything raised after this becomes phase 2, in writing. Without this gate the final 25% of every project balloons as stakeholders see the build and start adding — the failure mode Jared and Kado both named independently.

Step 5 — Build to MVP

Mark and Gene carry most builds today. Some use cases are built entirely by this team; others are co-built with resources the requesting area supplies, deliberately, so ownership can transfer. Clinical is the first co-build test.

Step 6 — Merge to Dev and internal test

Gene merges the developer branch into main in the Dev environment. Internal test confirms it is locked and loaded before any business user sees it. This step, not the build, is where payer churn is currently sitting.

Step 7 — Business validation (in Dev, because there is no UAT)

No UAT environment exists, so named business testers are granted access to Dev and told plainly that is what they are on. Testers must be more than the requesting manager: for payer churn that means Rashad plus Mike plus Bruce Carver, AVP Customer Success, who gives unfiltered feedback. Green light here closes the use case at MVP from the team’s side.

Step 8 — Production release, then open the doors

Production environment release is the standing constraint across the whole portfolio. Once in production, access opens beyond the test slate. Every date on this board that lives past step 6 is really a bet on environment provisioning.

Step 9 — Handoff to the permanent owner

Train the trainer: the named business owner is exposed to the tooling during the build, gets the documentation, and owns it afterwards. The use case is not finished when it ships — it is finished when it sits with a respected owner in the respective business unit and this team has washed its hands of it.

PM next steps — by project

One numbered list per project, in the order to do them. Click any ticket ID to open it. Dates are the committed end dates from the board. Red text is a question that needs someone else's answer before the work can move.

Latest statuses — disabled

Disabled on this board. Status lives on the tickets themselves - there is no external feed and nothing is fetched.

RAID register

Risks, Assumptions, Issues, and Dependencies. Link entries to tickets by ID — chips open the ticket. Everything here persists with the board and flows through Download edits / auto-sync.

RACI matrix

Rows are activities/deliverables; columns are this board's users (Users button to manage). Click a cell to cycle blank → R → A → C → I. Each row wants exactly one A — the count badge goes red otherwise.

Scrum board — kanban by assignee

One lane per user, kanban columns by status with Blocked leading. Each card shows how many days since the ticket was last touched (green ≤2d, amber 3-5d, red 6d+). Cards open the ticket. Owner/status/phase/epic filters above apply here too.

Computed live from the board: flow (cycle time, throughput, WIP, aging), predictability (burndown, schedule variance, projected finish), risk (blockers + downstream impact, RAID), and quality (rework, acceptance coverage). "Copy status report" puts a ready-to-paste markdown standup summary on the clipboard.