Build it with AI
Build a project tracker around your milestones, owners, blockers, and decisions.
Create a focused system for workstreams, tasks, dates, dependencies, risks, and status reporting.
Introduction
What a project tracker has to hold.
Most teams end up with a project tracker the same way: a project tool that records tasks, and status updates written by hand for anyone who asks. A single project with one team runs fine on a shared document. The break comes with concurrent projects and shared people, when the question is no longer how a project is going but which project the same three people should be on this week.
The tracker records the plan faithfully and says nothing about whether the plan is still true. There is no dependency between one project’s milestone and another’s start, no record of who is committed to how much at once, and no history of what a date was before it moved.
What follows covers building a project tracker: the records it holds (projects, tasks, owners, dependencies, due dates, and current state), the systems it reads (Slack and Google Drive), and what it does not fix.
The problem
Status is a story told weekly, not a state anyone can read.
General project tools model tasks well and dependencies across projects poorly, which is where multi-project organisations actually break. Spreadsheets model anything and enforce nothing, so the plan and the reality separate silently.
The records are projects, tasks, owners, dependencies, due dates, and current state, and the authoritative copy of most of them already lives in Slack or Google Drive. The status report says amber, the task board says four overdue items, and the person running the project believes both and reports the first.
The cost is not the inconvenience: a dependency is discovered at the deadline rather than when it slipped.
You're likely here because
- A date moved and nobody can say what it was before or why
- The tracker records the plan faithfully and says nothing about whether the plan is still true.
- When it is wrong, a dependency is discovered at the deadline rather than when it slipped
What gets built
Launch builds it, Grow operates it.
Built in Launch
- • Project board
- • Milestone timeline
- • Risk register
Operated through Grow
- • Notifications
- • Stakeholder follow-up
- • Scheduling
Systems it reads
- • Slack
- • Google Drive
- • Google Calendar
The record model
What a project record has to hold.
- Blocker with an owner and an age
- The single highest-value view in the system. Most organisations find at least one blocker open far longer than anyone believed, and usually clearable in a day once seen.
- Milestone date history
- Every value it has held. Four one-week slips are individually reasonable and collectively a month, and only the history shows the second thing.
- Derived status with manual override
- Status computed from underlying state, with an override that requires a reason. The disagreement between the two is the informative part.
- Cross-project resource commitment
- Because in a multi-project organisation the constraint is people, and no per-project tool can see the same three names appearing everywhere.
- Dependency that blocks
- Modelled only where a real blockage has occurred. Speculative dependency graphs are maintained for a fortnight and abandoned quietly.
- Escalation path by blocker type
- Defined in advance, so raising a blocker does not depend on knowing whom to ask.
- Decision record
- What was decided and what was rejected, because the same question returns in six months and the reasoning is otherwise gone.
How it runs
From status reporting to tracked state.
Step 01
Describe what a project tracker has to do
Model what a blocker is and who resolves it, before modelling tasks. Project tracking failures are blocker-resolution failures far more often than they are planning failures.
Step 02
Connect the systems of record
Chat is where blockers are actually raised, the document store holds the deliverables, and the calendar holds the meetings where decisions were taken. Reading them keeps the tracker attached to reality.
Step 03
Build the operating surface
Workstreams, milestones with owners, dependencies across projects, a risk register, and status derived from the underlying state rather than typed in weekly.
Step 04
Start narrow
Blockers with an owner and an age, across every project, in one view. Almost every organisation finds something in that list that has been open longer than anyone realised.
Step 05
Route the exceptions
A blocker older than its threshold escalates to whoever can actually clear it, which is usually not the person managing the project.
Step 06
Measure share of overdue items with a named blocker rather than an unexplained delay
Measure blocker age at resolution and the number of times a milestone date moved. Both are objective, and both correlate with delivery far better than status colour does.
Implementation path
Tracking projects without a project about tracking.
- 01
Define what counts as a blocker and who is empowered to clear each type. Tracking blockers without a resolution path produces a well-maintained list of things that are stuck.
- 02
Baseline how often milestone dates move and by how much, using the last two quarters. Status colour is not a baseline; it is an opinion recorded weekly.
- 03
Derive status from underlying state rather than asking for it. A status that is typed in is a status that reflects how the person felt on Thursday afternoon.
- 04
Retain previous dates rather than overwriting them, so a pattern of movement is visible rather than reconstructed from memory at the retrospective.
- 05
Build the narrowest useful version first: a view of tasks past due whose blocker is another team, with that team named.
- 06
Defining blocker types and who can clear each is a half-day and is what makes the blocker view actionable rather than a well-maintained list of things that are stuck. The cross-project blocker view is a week. Deriving status from underlying state takes longer and depends on the underlying state being honest, which is a cultural question as much as a technical one.
- 07
After the blocker view, add cross-project resource commitment — it converts a priority argument between project owners into arithmetic. Decision records come next and are the most durable artefact in the system.
Controls
Controls that matter.
Control 01
Every date change retained with its previous value and reason, since overwritten dates are how a project slips three months in one-week increments
Control 02
Cross-project resource commitment visible, because the constraint in a multi-project organisation is people rather than plans
Control 03
Blocker escalation paths defined in advance and by type, so raising one does not depend on knowing whom to ask
Examples
Three questions the tracker answers.
The blocker that was open for five weeks
Blocker age with an escalation threshold turns a thing everyone mentioned and nobody owned into a tracked exception with a route to someone who can clear it.
The date that moved four times
Retaining every previous date makes a slow slip visible as a pattern rather than as four separately reasonable one-week adjustments.
The same three people on everything
Cross-project commitment in one view converts an argument about priorities between project owners into an arithmetic problem with a visible answer.
How it goes wrong
Three ways trackers start lying.
Blockers are tracked diligently and none of them clear, because tracking was mistaken for a resolution path.
Define who can clear each blocker type before you start collecting them. A list of blockers with no escalation route is an inventory of stuckness with better formatting.
Tasks are marked done to keep the board green, and derived status inherits the fiction with more authority.
Derived status is only as honest as the state beneath it. If the board is being managed rather than used, that is what needs addressing, and no tracker will do it.
Every conceivable dependency is modelled and the graph is stale within a month.
Model the dependencies that have actually caused a slip. Comprehensive dependency modelling is a maintenance burden that produces confidence in a graph nobody has updated.
Limitations and considerations
What tracking cannot make true.
- A tracker cannot make a plan realistic. It exposes optimism faster, which is uncomfortable and is the point, but the estimate was always the weak link.
- Status derived from underlying state is only as honest as the state. If tasks are marked done to keep a board green, the derived status inherits the same fiction with more authority.
- Cross-project dependency modelling is genuinely hard and gets stale quickly. Model the dependencies that have actually caused a slip rather than every conceivable one.
- With one project and one team, a shared document works and a tracker is overhead. If the estimates are the problem, a tracker exposes optimism faster and does not improve the estimate, which was always the weak link.
- Connector coverage varies: Slack, Google Drive, Google Calendar are representative rather than guaranteed, and the fields exposed depend on your workspace permissions.
FAQ
Build a project tracker with AI: common questions.
How is this different from Jira or Asana?
Those model tasks within a project well. The gap they leave is cross-project dependency and shared-resource commitment, which is where multi-project organisations actually break, and which is why the summary of them ends up in a spreadsheet anyway.
Should status be manual or derived?
Derived, with a manual override that requires a reason. Manual status tracks how the reporter felt; derived status tracks the underlying state and makes the disagreement between them visible, which is the informative part.
What is the single highest-value view?
Open blockers by age with an owner against each, across all projects. Most organisations discover at least one that has been open far longer than anybody believed, and it is usually resolvable in a day once seen.
How much detail should tasks carry?
Enough that the blocker and the owner are unambiguous. Detail beyond that is maintained for two weeks and then abandoned, at which point the tracker starts lying with high resolution.
What should the first version contain?
A view of tasks past due whose blocker is another team, with that team named. Everything else waits until that one is genuinely used.
How will we know whether it worked?
Measure share of overdue items with a named blocker rather than an unexplained delay against the baseline taken before anything changed.
Start with ARIA
Ask ARIA to build it.
Describe the website, application, workflow, or operating surface you need. ARIA plans, connects, builds, tests, and keeps refining it — inside the permissions you set.
- ARIA acts only through the systems and permissions you connect.
- Connections use scoped credentials you can change or revoke.
- Actions are recorded, and consequential ones can require approval.
Start here
Build a project tracker around the process you actually run.
Build the blocker view first, derive status rather than asking for it, and keep every date a milestone has ever had.