Define Project Status Rules Before Building the Dashboard

A familiar indicator can hide an unfinished requirement

During an ongoing business application rebuild our team reviewed a project dashboard with indicators for schedule, budget and specification. The visual requirement appeared straightforward: show whether a project was on track. The discussion revealed that the rules behind those indicators were at different stages of definition.

The schedule discussion described a forecast moving beyond the original planned date. Budget was discussed in similar terms, but the precise calculation still needed documenting. The meaning of “on specification” remained unresolved. The interface could represent all three labels, but that did not establish how every status should be calculated.

Define the business signal before choosing its colour

A status indicator represents a business decision. Before implementing it, teams need to agree on what is being measured, which records support that measurement and what should happen when the information is incomplete.

• Meaning: What condition does this indicator represent?
• Baseline: Which approved date, amount or requirement is the comparison based on?
• Inputs: Which forecast, actual or approval records determine the result?
• Exceptions: What happens when data is missing, outdated or awaiting review?
• Ownership: Who approves the rule and any later changes to it?

These are validation questions drawn from the discussion, rather than completed features of the application. For example, a budget indicator might compare forecast total cost with an approved budget. Another organisation might need a different measure. The team should agree on that distinction before the dashboard presents either calculation as authoritative.

Keep setup progress separate from project performance

The review also clarified a separate set of indicators showing whether functional areas had been configured. Those indicators answered a different question from schedule, budget or specification: had a required setup step been completed?

That distinction matters when interpreting an existing screen. An icon’s appearance does not reliably explain its business meaning. Teams should document what each state means and whether the indicator is informational or supports an action. Otherwise, a rebuild can preserve the appearance of the old screen while changing the meaning users take from it.

Carry the agreed rule through the data, API and interface

The wider rebuild involved reviewing entities and relationships, developing read APIs and refining the interface. Status rules need the same shared understanding across those layers. A screen cannot resolve an undefined business rule simply by displaying a label or a coloured icon.

1. Write the rule in plain business language and identify its owner.
2. Map the rule to its required data and approved baseline.
3. Agree how the application will represent missing information and unresolved definitions.
4. Validate representative examples with users before relying on the result.

Those examples should include a project within its baseline, a project outside it and a project with insufficient information. For a specification indicator, the team first needs an agreed definition of conformance and the evidence required to establish it. Until then, an undefined status should remain visibly unresolved rather than defaulting to green.

The interface should also explain each status in text and make its meaning available without relying on colour alone. Users need to understand both the result and the basis for it.

What this ongoing work shows

At the latest recorded review, the team was still consolidating entities, refining screen feedback and preparing further API work. The specification criteria remained open. The transcripts do not establish a completed dashboard, verified integration or measured improvement.

The practical lesson is already useful: a dashboard review is also a requirements review. Clarifying what each indicator means gives the data model, APIs, interface and acceptance checks a common definition to work towards.