See every job's real state before the week runs away.
GA Applications designs operations and project dashboards that show jobs, tasks, milestones, resources and issues from your current-state system of record. Progress and delay are defined in writing, workload is visible by person and week, and every blocked or changed job has a named action owner with drill-through to the underlying record.
Operations teams rarely lack data — they lack a shared, current picture of what is on track, what is slipping and who is doing something about it. This direction turns the job system you already run into a view that coordinators can act from.
Demonstration below uses fictional jobs and dates. Your build reads from your system of record.
Operations board — coordinator view
Interface demonstration — fictional dataQuoted 3
Scheduled 2
In progress 2
Blocked 2
The decisions this view exists to support
This direction is built for operations and project managers, coordinators and the owners they report to. Its decisions are concrete and daily: Is the week's workload deliverable with the people we have? Which jobs need intervention today rather than at Friday's review? What do we tell the client whose job has slipped — and what is the recovery plan? Each of those questions maps to a specific part of the view, with definitions that stop 'on track' meaning different things to different people.
The target operating outcome: one shared, current picture of job state that the coordinator acts from in the morning and the manager reviews exceptions from in the afternoon — instead of a board in one tool, a spreadsheet in another and the truth in someone's head.
Board, timeline, workload — three readings of the same truth
The board above reads job state left to right: quoted, scheduled, in progress, blocked. Cards carry their owner and their exception state; anything blocked carries a name, because an unowned blocker is a decision nobody has made. Underneath the board, two more readings of the same job system answer the planning questions.
Milestone window — next 6 weeks
Interface demonstration — fictional dataWhich milestones land in the next six weeks, and which are already at risk?
Planned milestone dates per active job, against today (week 30). 'At risk' = predecessor incomplete within tolerance (def v1.2). Source: job system, refreshed 06:12. Fictional data.
Same data as a table
| Job | Milestone | Planned week | State | Reason / note |
|---|---|---|---|---|
| Bakery cold room | Commissioning | 31 | On track | Predecessors complete |
| Office level 2 refit | Fit-off | 32 | At risk | Parts delivery delayed 3 days |
| Winery pump install | Install day | 32 | On track | Crew A assigned |
| School hall AV | Rigging | 33 | Uncommitted | No crew assigned |
| Havelock cafe fit-out | Stage 1 start | 34 | Uncommitted | Quote not yet accepted |
Is next week's workload deliverable with the people available?
Committed job hours vs available hours per crew, week 31. Available = rostered hours minus leave and training (capacity def v1.0). Source: job system + roster, refreshed 06:12. Fictional data.
Same data as a table
| Crew | Committed hours | Available hours | State |
|---|---|---|---|
| Crew A | 30 | 38 | Deliverable |
| Crew B | 43 | 38 | Over-committed — reassign or approve overtime |
| Crew C | 18 | 38 | Spare capacity |
Drill-through is the point of the exercise: any card, bar or row opens the underlying job in your system of record, so verifying a number never means asking someone to check another tool. Changes and blockers carry history — who moved a job, when, and what reason they recorded.
Definitions this view typically carries
Job progress
Completed milestones divided by planned milestones for the current stage. Not a percentage of hours — hours measure effort, milestones measure progress.
Delay
Current milestone past planned finish by more than the agreed tolerance (default 2 working days). Client-caused holds are labelled separately, not hidden.
Workload deliverability
Committed hours vs available hours per crew per week. Over 100% is a planning decision — overtime, reassignment or resequencing — never a silent expectation.
Blocker age
Days since a job entered blocked state, by blocker type (parts, access, client decision, weather, other). Ageing beyond threshold raises the attention queue.
Where each field comes from — and how it fails honestly
System of record
- Job / project system: state, milestones, owners
- Roster system: availability
- Timesheets: actual hours (lagging)
Governed layer
- Delay & progress definitions v1.2
- Capacity definition v1.0
- Refresh: job system 15 min, roster hourly, timesheets daily
- Reconciliation vs weekly ops report
Views
- Coordinator board
- Manager exception queue
- Owner weekly summary
- Field personal job queue
Failure behaviour is designed, not discovered. If the job system feed fails, the board shows last-received data with its age and a stale treatment, and the refresh failure is raised to the responsible person. If timesheets are late — they usually are — workload history is marked provisional until they land. If a job's state is unknown because a field update has not synced, the card says unknown rather than guessing 'in progress'. Offline field capture queues locally and syncs with its original timestamp, so a late sync never looks like a late job.
Every exception has an owner, a response and a closure
What the view asks people to do
- Coordinator (morning): work the exception queue — blocked jobs, unassigned work, stale updates — and record a response on each.
- Operations manager (daily): review delay and workload deliverability; approve overtime, reassignment or client communication.
- Owner (weekly): read the reconciled summary with narrative exceptions, not a live board.
- Field team: update job state from site; the board is only as current as those updates, and it says so.
What the view never does
- Reassign people or notify clients by itself — it routes context to the person who decides.
- Treat a phone-call update and a verified field sync as the same certainty — scheduled, reported and confirmed stay distinct.
- Show margin or client financials to roles that do not need them — access is role-based and tested at acceptance.
Security, privacy & accessibility
Role-based access limits financial and client-identifiable detail. Every chart has a table equivalent; state is icon-plus-pattern-plus-text, never colour alone; the board is keyboard-operable and readable at 200% zoom. Personal data is limited to what coordination requires.
What we need from you, and how delivery runs
Inputs
- Access (read) to your job/project system and roster, subject to interface review
- Your real definitions of progress, delay and 'blocked' — or an hour to draft them together
- The names of the coordinator, manager and owner roles
- One recent week of real exceptions to prototype against
Delivery & acceptance
- Decision workshop → source profile → prototype with your job data
- Reconcile against your existing weekly report for an agreed period
- Pilot with the coordinator and manager alongside current practice
- Acceptance checks: delay definition matches reality; stale feed visibly stale; access rules verified; drill-through reaches the job of record; keyboard and table equivalents pass
- Release with fallback, then improve from use
Right fit
- Jobs run through a system (or disciplined spreadsheet) with state and dates
- Slippage is currently discovered late, in meetings or inboxes
- Someone can own blocker response each day
Wrong fit
- Job state lives only in people's heads with no capture habit yet
- You want automated rescheduling or client notification without human review
- You need a guarantee of project outcomes — visibility helps, it does not warrant results
Related directions and services
Frequently asked questions
Which job or project systems can this read from?
Any system that exposes job state — project tools, job-management software, CRM pipelines, databases or structured spreadsheets. The source profile step confirms what each system exposes and how current it is before design begins; the dashboard always labels which system is the source of record for each field.
How do you define 'delayed' when every manager defines it differently?
In writing, before anything is built. Delay might mean past planned finish, past a milestone tolerance, or blocked longer than an agreed threshold. The chosen definition, its tolerance and its owner appear in the metric glossary next to the measure, so a red job means the same thing to everyone.
Can field staff update job state from site?
Yes, where the underlying system supports it. The dashboard reflects whatever the system of record holds; field capture is usually delivered alongside field technology workflows. The view distinguishes scheduled, reported and confirmed state so a phone call and a verified update never look identical.
What happens when the job system is offline or a feed fails?
The dashboard keeps showing the last received data, clearly stamped with its age and styled as stale, and the refresh failure is raised to the responsible person. Nobody mistakes yesterday's board for this morning's.
Who sees commercially sensitive job margins?
Only roles you approve. Cost, margin and client-identifiable fields can be restricted by role, and the coordinator view can show state and workload without financial detail. Access rules are agreed during scoping and tested as an acceptance check.
Which job slipped this week — and who found out last?
Send us a description of how job status reaches you today — the board, spreadsheet or inbox it lives in — and we will scope a view that shows state, delay and ownership in one place, piloted against your real workload.