Status Still Green? 8 Task Tracking Signals Your Portfolio Is Slipping17 min read

The status report said green right up until the milestone slipped. The decision that would have prevented the slip sat in the tracker a month earlier.

Nobody missed it for lack of data:

• An item open 3 times longer than anything similar your team had ever finished.
• Two owners pulled onto a launch, tasks still in their names.
• A checkpoint date moved for the 3rd time.
• A green status over tasks untouched for 5 weeks.

None of those signals showed up in a single task’s status field, which is where a status-only review looks. They lived in patterns across items and tasks.

A red flag earns its place only when it forces a decision (one that just turns amber becomes noise people learn to tune out).

Much of the data to catch slippage early is already in your tracker. What’s missing is the habit of reading it across tasks, against your own thresholds.

Why Milestones and RAG Status Report Slippage Late

A missed milestone records something that already happened. A late red status reports the same thing, from someone who had reasons to wait.

Status tends to arrive late for 3 documented reasons:

1. The signal starts faint. A partly PMI-funded study of complex projects found that “Emerging problems often start early in the project but display only weak signals.”
2. Professionals miss it, and act on it even less. The same group’s 2011 paper judged professionals “not very good at detecting early warning signs and even less good at acting on them.”
3. The messenger hesitates. Software project managers surveyed by Snow, Keil, and Wallace estimated other project managers biased status reports 60% of the time, twice as often optimistic as pessimistic. Fear that senior management “shoots the messenger” was among the reasons.

Those are perceptions gathered indirectly, not an audit of real reports. Smith, Keil, and Depledge’s work on “keeping mum” describes the same reluctance to pass on bad news.

The acting half of the 2011 finding matters most here. A signal nobody acts on is just an early version of the red status.

Ages, counts, and change history, though, skip the messenger. Nobody has to decide to report an item’s age.

And that’s where leading indicators earn their keep. They describe the queue while it’s forming and the status still reads green.

The 8 Flags at a Glance

Each flag below pairs a pull from the tracker with a threshold and a decision. The thresholds are starting points, to recalibrate from your own history.

Read the last column first. If your review can’t make those decisions, the flag has nowhere to go.

The threshold column holds defaults to replace. Your finished work sets better thresholds, and most flags below show where to find them.

Also, an item is a portfolio entry, and its tasks sit beneath it. Only flag 3 needs new fields: an awaiting-decision status, its start date, and a scheduled decision date.

Flags 4, 6, 7, and 8 also need a tracker that logs field history, since they compare today with past assignments, activity, and dates.

Flow Signals: What the Queue Is Telling You

Flow signals come from counts, ages, and status dates. That makes them hard to argue with in a review.

Tom Bellinson’s review of Donald Reinertsen’s book on flow sums up the problem: “Product development queues are more insidious because they tend to be invisible.”

These 3 flags make the queue visible.

Flag 1: Work Items Aging Past Your Usual Finish Time

Look at every started, unfinished item and compute its age, today’s date minus its start date. Then compare it with completed items of the same type.

Age and cycle time measure the same work at different points:

• Work Item Age is what The Kanban Guide calls “The elapsed time between when a work item started and the current date.” You can watch it while the item is still open.
• Cycle time only exists after the item finishes.

Working from an 85th percentile target, Dan Vacanti makes the case for acting early: “the older an item gets the larger the probability that it will get older.”

For a starting threshold, use your own 85th percentile cycle time. Benjamin Richards at ProKanban labels that line: “Crossing this threshold indicates unusual delay.”

He pairs it with the median, which “tells you how long work typically takes,” and notes some teams prefer 50th/80th/95th.

Crossing the line forces a call on whether to swarm the item, split it, or kill it. Letting it age quietly is a decision too, just an unrecorded one.

Flag 2: A Task List That Grows Faster Than It Closes

Each week, count tasks added, whether under new items or existing ones, and tasks finished. Scope growth counts as intake even when no new item appears.

At the same time, log cancellations separately, and keep task definitions consistent so splitting alone doesn’t inflate intake.

The arithmetic behind the flag runs in 3 steps:

1. Little’s Law relates the average number of items in a stable system to their average arrival rate and average time in the system.
2. With no new arrivals and a steady finish rate, open tasks divided by weekly finishes estimates the weeks to clear the pile.
3. If the pile keeps growing while finishes hold steady, expect that clearance time to stretch.

In PMI’s 2021 survey of 3,950 project professionals, respondents estimated 34% of completed projects saw scope creep.

PMI’s 2018 report defines scope creep as “the uncontrolled expansion of product or project scope without adjustments to time, cost, and resources.”

Bellinson also makes the cost point bluntly: “We often think of product development backlogs as free. They are not.”

With that in mind, a starting threshold is tasks added exceeding tasks finished for 3 weeks running. Check your history for how often that happened without trouble.

The decision is to stop starting new items until finishes catch up. If the added tasks sit under existing items, re-scope those items first.

Flag 3: Work Waiting on a Decision Longer Than One Review Cycle

Some items sit still for one reason: they’re waiting for someone with authority to say yes, no, or not yet.

So pull every item sitting in an awaiting-decision status. Then measure how long each one has waited.

A McKinsey survey of 1,259 respondents, published in 2019, offers useful context:

• Only 48% agreed their organizations make decisions quickly.
• Organizations that decide quickly were twice as likely to make high-quality decisions.
• 61% said most of their decision-making time is used ineffectively.

Those are self-reported perceptions of speed. They say nothing about how long an item sits in your tracker.

They do suggest that slow decisions and good decisions aren’t the same thing. Waiting doesn’t buy quality by default.

That’s why a starting threshold is one full review cycle with no scheduled decision date. Past that, ask why the item still has no date.

The decision it forces is an escalation to whoever owns the call. If nobody owns it, that’s the real finding.

People Signals: Who’s Actually Carrying the Work

People signals are harder to read because the tracker records assignments. Effort shows up only indirectly, in activity and in counts per person.

Kappelman, McKeeman, and Zhang had 55 experienced IT project managers rate 53 warning signs, and 3 of the 8 flags match items on their list.

Their “dominant dozen” reflects importance as rated by practitioners. It isn’t measured predictive power, but it’s a useful check on where to look.

Flag 4: Key Experts Spread Across Too Many Active Tasks

Count active tasks per person, and look hardest at the people other tasks depend on. Their load sets the pace for the work waiting on them.

Three lines of research bear on expert load:

1. Practitioner ratings. Kappelman’s dozen includes overscheduled subject matter experts, and calls SMEs denied adequate project time “a clear EWS,” or early warning sign, “of IT project failure.”
2. Project data. Colicev, Hakkarainen, and Pedersen found “an inverted U-shaped relationship” between multi-project work and performance across 9,649 project-month-employee observations in new product development. Performance was higher at moderate spread and lower at higher loads.
3. Finishing logic. Kellogg Insight’s coverage of a model by Coviello, Ichino, and Persico puts it plainly. In Persico’s words, if finishing has value, “the best thing you can do is to finish one before you start the next one.”

That said, expect the tipping point to differ by team, so don’t borrow someone else’s.

So set the threshold from history. Find the concurrent-task count at which an expert’s comparable tasks started taking longer, and flag loads above it.

The decision is to re-staff or to sequence. Pick which of the expert’s tasks waits, and say so out loud.

Flag 5: Owner Fields That Are Blank, Shared, or a Team Name

This flag takes a single filter. Pull items where the owner field is empty, lists 2 or more people, or names a team.

Why does a shared name matter? In a 1979 lab study, Latané, Williams, and Harkins had undergraduates clap and shout in groups:

• Two-person groups performed at 71% of the sum of their individual capacity.
• Four-person groups performed at 51%.
• Six-person groups performed at 40%.

In a follow-up shouting experiment, about half the loss was coordination and half social loafing. It’s a lab setting, so treat it as a mechanism.

Read that as an argument for identifiability. Effort nobody can trace to one person is easier to let thin out.

For that reason, the starting threshold is strict: any item past its 1st review without one named owner. Team names belong in context fields.

And so the decision is binary. Name one owner this week, or park the item until someone will take it.

Flag 6: People Quietly Pulled Onto “More Important” Work

The tasks stay assigned, with the owner’s name still on them. What stops is the activity on those tasks.

Catching it takes 3 steps per person:

1. Pull their assigned tasks.
2. Check their recent activity on each one.
3. Mark tasks gone silent while the owner stays busy elsewhere, the pattern that signals this flag.

It’s a known risk, too. Kappelman’s dozen includes “resources assigned to a higher priority project.”

The authors’ note on it is blunt: once that happens, “it is unrealistic to expect the short-changed project to be completed as planned.”

In practice, the starting threshold is 3 weeks of silence while the owner is active elsewhere. Some tasks idle between phases, so check history first.

Before acting, confirm it’s reassignment, not missed updates, then re-staff the task formally or re-plan its dates around the time the person actually has.

Reporting Signals: What Dates and Statuses Hide

Dates and statuses are often updated by hand. That leaves them exposed to the optimism described earlier.

The 2 flags here track how those fields move over time, or fail to move while the work stalls.

Flag 7: Checkpoint Dates That Move More Than Once

Trackers that log field history already hold this. Pull how many times each checkpoint date has moved, and whether anything downstream moved with it.

Buehler, Griffin, and Ross’s 1994 study of honors-thesis students found a stubborn gap:

• They predicted 33.9 days on average.
• They took 55.5 days.
• Only 29.7% finished by their own predicted date.

The authors frame the underlying paradox this way:

“Although aware that most of their previous predictions were overly optimistic, they believe that their current forecasts are realistic.”

Those were students, and the paper didn’t study re-planned dates. Still, expect a team that moved a date once to trust the new one too much.

Kappelman’s dozen also folds in a related sign: early delays ignored, with no revision to the overall schedule.

So set the starting threshold at the 2nd move on the same checkpoint, before ignored delays pile up. It forces a full re-plan of the path behind it.

Flag 8: Status Stays Green While Nothing Underneath Changes

Practitioners call it a “watermelon” status: green outside, red inside. The item reports on track while its tasks haven’t moved in weeks.

Two things make reported progress weaker evidence than it looks:

• Optimism in reporting. Snow, Keil, and Wallace’s respondents described status reports tilting optimistic, so a green status isn’t reliable evidence on its own.
• Rework nobody has found yet. Even movement can mislead. In the rework-cycle model summarized by Gozluklu and Sterman, “unknown rework is work believed to have been done correctly.” Perceived progress is completed work plus that unknown rework, so “done” overstates progress until someone checks the evidence.

To pull it, compare each item’s status history with change activity on the tasks beneath it. Green plus no movement is the flag.

From there, a starting threshold is green for 3 weeks with no change in the tasks underneath. Tune it against items that later turned red.

The decision is to ask for proof of progress, or downgrade the status yourself. Either way, the color stops being the owner’s call alone.

Reading Flags Together Without Drowning in Noise

One flag is a question. A pair of flags that share a cause, on one item or one team, is closer to an answer.

Combinations Worth Acting On

Some pairs reinforce each other because they share a cause. Read them as one finding, with one decision.

These 3 pairings deserve a closer look:

1. Aging plus reassignment. Check whether the item is old because its owner left for other work (flags 1 and 6).
2. Intake plus spread-thin experts. New starts keep landing on people already over their usual load (flags 2 and 4).
3. Moved dates plus steady green. The schedule keeps slipping while the status insists nothing’s wrong (flags 7 and 8).

Each pair points at its own decision.

Aging plus reassignment calls for re-staffing, intake plus spread calls for a hold on starts, and moved dates plus green call for a re-plan.

By contrast, a lone flag gets the decision in its table row. A pair gets its shared decision, made before the review ends.

The Cost of a False Alarm

Every flag has a false-positive cost. With too many alerts, people stop reading them, including the ones that matter.

Flags can also invite gaming once people know they’re watched. Expect items to get split to reset their age, and owners to post updates that change nothing.

And expect a flag turned into a target to lose its diagnostic value. So review flags as questions about the work, never as scores for people.

Treat every threshold as probabilistic. Crossing the 85th percentile means an item is unusual, and some unusual items finish fine.

Work That Should Age, and Where to Start

Discovery work needs its own baseline. Judge an experiment that’s still generating evidence against its learning plan, not your delivery percentiles.

Concretely, give discovery items their own percentiles, or exclude them from flag 1 until they reach a delivery stage. Otherwise the flag punishes learning.

Likewise, count discovery tasks separately for flag 2, and judge flag 7 against agreed learning checkpoints. A checkpoint that moves after a killed hypothesis is the process working.

For a first pass, start with 3 flags: aging, waiting on a decision, and ownership gaps. Each reads today’s field values, with no change history to mine.

Build the Review Around the Flags

A flag nobody reviews is a dashboard ornament. The review is where each flag turns into the decision it was built for.

Keep the room small, with 3 roles that can act:

1. The portfolio owner, who holds the priority calls
2. Whoever owns the flagged items, or the decisions they’re waiting on
3. Someone with authority to move people between tasks

The rule for the meeting is one decision per flag raised, or per pair read together.

Even “keep an eye on it” counts, if it’s recorded with a date. Without one, it’s the same flag next week.

As for timing, run the flag review at the cadence your portfolio review already keeps. Weekly fits delivery work, and monthly may suit a slower discovery portfolio.

Either way, compute the flags weekly, and send each crossed flag to its decision owner that week. A monthly review then decides on flags that owner has already seen.

Let the Tracker Push the Flags

Flags reach the room 2 ways:

1. Pull: someone queries the tracker before each review.
2. Push: the tracker surfaces crossed thresholds on its own.

Push is sturdier, because it doesn’t depend on anyone’s memory in a busy week.

This is where software earns its place, computing percentiles against your own history and pushing flags automatically. People still make the calls.

Better still, expect the meeting to shrink once flags arrive in the pre-read, since nobody spends it hunting for data.

In the end, a flag review is follow-through with a threshold attached. It targets the acting half, the one the 2011 PMI paper found weaker.

Pick 3 Flags and Run Them This Month

Your next slip may already be visible in the tracker while the status still reads green. The question is whether anyone pulls it before that status turns red.

Start small, in this order:

1. Switch on aging, waiting on a decision, and ownership gaps.
2. Name who makes each flag’s decision before the 1st review, so no flag arrives without someone to make the call.
3. Test the thresholds against your last missed milestone.
4. Revisit them after a quarter, keeping the flags that changed a decision and dropping the rest.

Expect the first month to feel noisy. That’s the calibration period, and the thresholds settle once they reflect your real history.

After that, the hard part is timing, so make each decision in the review where its flag appears.

Act while the status is still green and the milestone has room to move. Once it turns red, expect the cheaper options to be gone.

Download our free ebook Project Portfolio: From Opportunities to Value to see how progress and portfolio health tracking fit into stage-gate governance and prioritization.

Or request a demo to see how Accept Mission gives you stage progression, clear ownership, and real-time portfolio visibility on one shared set of records.