Workstream Delivery Risk Predictor

The job is to surface workstreams that, on the board you already run, will miss the next named date. Ticket velocity, aging issues, and milestone dates are the inputs. The engagement manager still decides what to do.

A red flag is a conversation. It is not an auto-replan, not a silent restaff, and not a score of how well the team is performing. Status slides lag. By the time a workstream is amber in the steering pack, the date is often already gone. Do not ask the model for a hit rate. There is no honest percentage to publish.

This is not a staffing forecast. A utilization and bench risk predictor answers who is over and who is empty in four to eight weeks. This file answers whether this engagement's named dates still hold. If a miss will extend end dates, tell staffing after you have a plan.

Read three signals from the same tools the team already updates. Project boards in the Jira, Asana, and monday.com class hold tickets. Plans in the Smartsheet and Kantata class often hold the named dates. Use whichever system is the source of truth on this engagement. Do not stand up a second board for the model.

Ticket velocity. Count tickets moved to done per week, by workstream, over recent weeks. A falling close rate against a date that has not moved is the usual tell. Percent complete is a snapshot. If the board is updated in a Friday batch, velocity is a weekly fiction. Fix the habit or do not score that workstream.

Aging issues. Open tickets past your age threshold, especially blocked or waiting on the client. A pile of old issues with the same named blocker is a date risk even when new tickets still close. A pile with no comments is more often hygiene.

Milestone dates. The next named date on the plan: design freeze, baseline workshop, steering pack. Flag against that date, not against project end. End dates absorb every miss. Named dates do not.

The output is a workstream, the date at risk, and the driver in plain language: velocity down, issues aging on a named blocker, or the date moved without the remaining work moving with it. If the model cannot name a driver, it is not a flag. It is a color.

Actions that never reach the board will understate remaining work. If you use a meeting-to-action-item agent, keep the review step. Unreviewed dumps inflate in-progress. Incoming asks that were never in the SOW show up as extra tickets or stalled design. Check them with a scope creep detector before you treat the stall as a delivery miss.

This is a worked example with made-up names, not a case study with results.

Calder & Voss is seven weeks into a 12-week warehouse operating-model engagement with Helion Rail. Three workstreams: current-state diagnostic, future-state design, 90-day implementation plan. The next named date is design freeze on 19 September. Elena is the engagement manager. Tickets live in Jira. Named dates live in the Smartsheet plan the PMO already runs. On the Thursday status slide, all three workstreams are green. The predictor flags two.

Future-state design, miss 19 September, driver: aging issues plus falling velocity. Tickets closed per week have dropped for three weeks. Six issues have sat in waiting-on-client past ten days, all on the same network-planning SME. The freeze date has not moved.

Implementation plan, red, driver: board hygiene. Forty tickets sit in progress. Nothing has closed in two weeks. The lead keeps a personal spreadsheet and copies titles into Jira on Fridays. The plan date is not at risk. The board is.

Elena does not restaff, change the Smartsheet dates overnight, or put team underperformance in the steering pack.

She talks to the design lead first. The aging issues are a client dependency, not a failing team. They get a call with Helion's SME and a written decision: either the SME is in the room twice this week, or two design options come off the freeze pack. The flag named the date and the blocker.

She talks to the implementation lead second. That conversation is about updating the board as work happens, not about missing 19 September. Until the board reflects reality, that workstream stays out of the delivery-risk list.

What they almost did is the usual failure. PMO saw two red tiles, pulled two people from diagnostic onto design overnight, and told the partner the team was slipping. Diagnostic then missed its own date. The implementation lead started closing tickets in a Friday batch so the tile went green. The signal died.

If tickets are created at planning and closed in a batch before steering, velocity is a performance, not information. Consultants will manage the signal once they know a partner watches the tile. Ticket hygiene becomes the job. Short engagements often do not have enough weeks of history to show a trend. On a four-week diagnostic, talk to the leads. Do not wait for a model.

Before you trust a flag, check four things. Is the workstream using the board as the work system, or as a reporting layer? Are in-progress tickets moving, or parked? Do aging issues have a named blocker and an owner, or are they leftovers from kickoff? Was the named date changed in Smartsheet or Kantata without the remaining tickets changing?

If the board is the reporting layer, fix that first. The predictor will otherwise train the PMO to intervene on hygiene. You can look at a slipped engagement and ask whether velocity and aging issues were visible two weeks earlier. That is a sanity check on the inputs, not a published hit rate.

The worst use of a red tile is as evidence in a performance conversation. Velocity falls when the client SME disappears, when scope grew, when a key person was on leave, when the remaining tickets are harder than the first ones. None of those proves the team is failing until a human says so.

Treat every flag as a prompt to talk to the workstream lead, with the driver attached. The value is a shared, dated artifact: this workstream, this date, this driver, this week. That is the conversation you take to the client if the blocker is theirs.

Client cooling sometimes shows up as stalled reviews and unanswered blockers. If the relationship may be the cause, read it next to a client satisfaction sentiment monitor. Do not call the team slow when the client has stopped showing up.

A flag can become a candidate on the live risk register. It does not become a row by itself. After kickoff, the owned list from a risk register bootstrapper is a habit: keep, merge, or cut. Automatic rows from every red tile recreate a file nobody manages.

Do not wire a red tile to a replan. Do not let a script move people, change dates, or email the client. The engagement manager chooses among a short list: unblock the named dependency, cut scope, move the named date, add capacity, or decide the flag was hygiene.

Adding capacity is a staffing question, answered after that choice. Silent restaff from a red tile punishes the workstream that was on track, blindsides the people who moved, and teaches leads to hide tickets. If you need people, take the conversation to the staffing huddle with a plan, not a color.

Show flags to the workstream lead before they appear in a partner pack. A lead who sees the tile for the first time in steering will fight the signal instead of the date.

Trial this on one live engagement whose board is already the work system. Run it in parallel with the Thursday status. The test is whether conversations happened before the named date, whether hygiene flags were separated from date flags, and whether anyone restaffed from a tile. If the only change is a new dashboard in Jira, Asana, monday.com, Smartsheet, or Kantata, you have relabeled status. The job is the named date plus the driver, with a human still on the hook for the call.