Progress, attention and health
"Is this task done?" sounds like it has one answer. In practice a project usually has two sources willing to answer it, and they do not always agree.
Somebody reports a task as 80% complete. Meanwhile its card sits in the Done column of the Kanban board. Which one does the project believe?
Dime.Scheduler does not guess. Your organization tells it, once, for every projectProjectA job seen as a whole in project planning: a body of work with a budget, a team, dependencies and a deadline. Its tasks are still planned as ordinary appointments on the board..
The progress measure
The progress measure decides which signal is read as completion. It is one setting for the whole organization, chosen by an administrator on the Projects tab of application setup, and everything that talks about progress follows it: the percentage the portfolio and every project page show, the work done on the overview, and the health rules that read progress.
The Projects tab of application setup
| Progress measure | A task is done when |
|---|---|
| Progress % | It is completed, or reported at 100% |
| Kanban status | It is completed, or its card sits in a lane marked as done |
| Progress % and Kanban status | Both figures are shown, and health reads the lower of the two |
Pick the one that matches how your teams actually work. If people diligently report percentages, use that. If they never do but they do move cards, use the board. Choosing a signal nobody maintains produces projects that look permanently stalled.
Progress % and Kanban status is the interesting setting, and it is not simply the cautious middle option. The pages show both readings side by side, so you see where they part ways, and health reads the more pessimistic one. A portfolio is a triage view, and the optimistic reading is exactly the one that makes risk disappear.
When the signals disagree
Whatever the measure, a task whose two signals contradict each other is worth pointing at. There are four ways that happens, and they mean genuinely different things:
| Conflict | What it usually means |
|---|---|
| On the board this is done, but the task is still open | The work finished and nobody closed the task |
| Reported 100% done, but the task is still open | Same, reported the other way round |
| The task is closed, but its card never moved to a done column | The task was closed administratively without the board catching up |
| On the board this is done, but the reported percentage is lower | The board says finished, the number says otherwise |
None of these is necessarily wrong. What they all are is a place where the project's two records of reality have come apart, and the value of surfacing them is that somebody decides which is right rather than the project quietly averaging them.
The Inconsistent progress rule counts these tasks, and the project page lists them under To reconcile. Both need at least one lane marked as done on the task board, since without one the board has no opinion about being finished.
Project health
Every project gets one verdict: On track when no rule applies, At risk when a rule is at warning, and Off track when a rule is critical. The most severe rule that applies decides it, and every rule that fired is listed, the critical ones first. A project without tasks has No status.
The rules are the same everywhere. The portfolio, its overview and the project page all read one verdict from one set of health rulesHealth ruleOne condition that can make a project At risk or Off track, such as overdue tasks or hours used against the budget. Each rule warns and turns critical from thresholds an administrator sets for the whole organization; the most severe rule that applies decides the verdict., so a project cannot be on track in one place and off track in another. An administrator maintains the rules on the Projects tab of application setup. Planners see them read-only, on the Health view of each project.
How a rule decides
A rule that counts or measures something takes two thresholds, Warning from and Critical from, each with its own switch. A rule can warn without ever turning critical, turn critical without warning first, or do both, in which case the critical value must be the higher one. A rule that is simply true or false takes a Severity instead: Off, Warning or Critical.
A rule with both thresholds off does nothing at all: it neither colors the project nor lists anything under Needs attention. There is no separate switch for attention. A rule that is on both colors the project and flags the work behind it.
The rules
The rules come in four groups, and each group is the column it colors in the portfolio list. The defaults below are what an organization that never changed anything reads.
| Group | Rule | Measures | Default |
|---|---|---|---|
| Schedule | Overdue tasks | Tasks whose planned end date has passed while they are not done | Critical from 1 |
| Schedule | Baseline slip | Days the planned finish lies beyond the date saved as the baselineBaselineThe original plan frozen in the Gantt chart. Shown underneath the current bars, it is how a project manager sees how far the plan has drifted from what was agreed. | Warning from 1, critical from 5 |
| Schedule | Project end date passed, work left | The project's own end date is behind you and tasks are still open | Critical |
| Schedule | Due soon with low progress | The project ends within a number of days and is less than a share done | Warning, within 14 days and below 80% |
| Schedule | Blocked tasks | Tasks in a lane marked as blocked | Warning from 1 |
| Schedule | Waiting on dependency | Tasks that cannot start because a task before them is not finished | Warning from 1 |
| Budget | Hours used | Hours spent as a share of the budget | Warning from 90%, critical above 100% |
| Budget | Planned beyond budget | The hours already on the board add up to more than the budget | Warning |
| Budget | Tasks over their hours | Tasks that used more hours than their own budget | Off |
| Resources | Busiest person's load | The most loaded person on the project, against their capacity in a week | Warning above 100%, critical above 115% |
| Resources | Team capacity | The team's planned work on all its projects against its capacity, until the project ends | Warning from 90%, critical from 110% |
| Watch list | Unplanned tasks | Tasks with nothing on the board yet | Off |
| Watch list | Unplanned work coming up | Tasks starting within a window with nothing on the board yet | Warning from 1, within 14 days |
| Watch list | Behind tasks | Tasks with less done than their elapsed time suggests | Off |
| Watch list | Awaiting confirmation | Tasks whose work on the board is still tentative | Off |
| Watch list | Inconsistent progress | Tasks whose % done and board lane disagree | Off |
The watch list rules are off by default because counting them turns almost every project amber. Switched on, they count toward the Schedule column.
A few rules are worth reading closely.
Overdue means the planned end, not the date the customer asked for. Summary tasks and milestones are left out, since a summary's end date goes stale as soon as its children move. A task counts as done when it is completed, reported at 100%, or sitting in a done lane, whatever the progress measure. Fully planned is not done: work that is booked is committed, not finished.
Baseline slip is the one worth thinking hardest about, because it is the only rule that measures the plan against what the plan originally said rather than against today. A project can have no overdue tasksTaskA unit of work that belongs to a job. It appears in the open task list until it is scheduled to a resource. and nothing flagged and still have quietly moved two months to the right. Every individual deadline was renegotiated in good faith, each time for a good reason, and nothing ever looked wrong. The baseline, which is set from the Gantt chart, is what catches that.
Busiest person's load only counts people who carry a meaningful part of the project, by default those with at least 10% of its planned hours, so a colleague who spent one afternoon on it does not turn it red. Lower the share for large teams, where everyone does a small part. A person's load is everything planned on them, on every project and none, and exactly 100% is full rather than over.
Team capacity looks at the whole team instead: everyone planned on the project, from this week until the project's end, with all their planned work against all their capacity. It catches the project whose people are each just about fine and together have no room left. A project without an end date, or one already past it, is measured over the next 13 weeks.
Both resource rules measure planned work only, the appointments on the boards, and capacity from capacity records only. A week without capacity is not counted as overloaded, and a project nobody is planned on reads Nobody planned rather than on track.
A task is behind when its reported progress trails the share of its duration that has passed by more than 25 points, once at least 10% of that duration is behind it.
"Today" is your own local date, so a task ending late on the 17th is overdue from midnight on the 18th where you are, not from midnight in another time zone.
Needs attention
Health tells you that a project is in trouble. The Needs attention list on the project's Overview tells you where, task by task. It lists the tasks behind every task-counting rule that is switched on, so its contents follow the same rules as the verdict.
The tasks are grouped by what they call for:
| Group | The tasks in it |
|---|---|
| To plan | Unplanned, starting soon first |
| To confirm | Planned, but only tentatively |
| Late | Overdue or behind. Moving the task's dates or updating its progress clears them; moving appointments does not. |
| To unblock | Blocked, or waiting on a dependency |
| To reconcile | Signals that disagree |
Each task appears once, under the most pressing of its reasons, and each row carries the one action that clears it, such as planning the task or locating it on the board. A row is amber when its rule warns and red when its rule only goes critical.
The portfolio's overview has a Needs attention block of its own, one row per project and problem, for the signals that can be judged across the whole portfolio at once.