Spreadsheet replacement
Replace the project management spreadsheet with a connected AI workflow.
Move teams coordinating projects in spreadsheets from fragile spreadsheet handoffs into a focused workflow with clearer ownership, live context, and connected execution.
Introduction
A plan that describes intent and never learns.
Almost every project management process starts in a spreadsheet, and for a while that is the right call. A sheet holding tasks, owners, dates, dependencies, and status across concurrent projects costs nothing, takes an afternoon, and fits the process exactly — because the person who built it is the person who runs it.
The project sheet is updated immediately before it is inspected, which turns it from a coordination tool into a reporting ritual. A single project on a shared sheet works. It fails with concurrent projects and shared people, when the question stops being how a project is going and becomes which project the same three people should be on this week.
What follows covers that transition for teams coordinating projects in spreadsheets: what the sheet holds, why it fails, what the replacement records instead, and — set out plainly further down — the case for leaving it where it is.
The problem
Four ways a project sheet stops being true.
A project sheet holds a plan, and a plan is a statement about the future that stops being accurate the moment reality diverges. What is missing is the record of divergence — that this date has moved three times, that this task has been blocked for a fortnight, that these two projects both need the same person in March. None of that is expressible in a grid of dates.
Each project lead maintains their own tab, the roll-up happens before the steering meeting, and nobody notices two plans have committed the same engineer to the same two weeks.
The sheet holds tasks, owners, dates, dependencies, and status across concurrent projects, and the authoritative version of most of it already lives in Slack or Google Drive. The status report says amber, the task list shows four overdue items, and the person running the project believes both and reports the first.
You're likely here because
- A date moved and nobody can say what it was before or why
- The project sheet is updated immediately before it is inspected, which turns it from a coordination tool into a reporting ritual.
- When a row is stale, a dependent team keeps planning against a date that stopped being real days ago
The operating problem
Why the current process stops scaling.
Move teams coordinating projects in spreadsheets from fragile spreadsheet handoffs into a focused workflow with clearer ownership, live context, and connected execution.
Failure mode 1
Status is opinion, not derivation
A colour typed in by the project lead reflects how they felt on Thursday. It cannot be reconciled against the underlying tasks because the sheet holds both and relates neither.
Failure mode 2
Cross-project dependencies are invisible
Two projects need the same person and neither tab can see the other. This is where multi-project organisations actually break, and it is exactly what per-project sheets cannot model.
Failure mode 3
Blockers live in chat
What is holding a project up is raised in a message and recorded nowhere. Nobody can produce the list of things that are stuck, which is the only list that would change any decision.
Failure mode 4
Milestone dates overwrite silently
Four one-week slips are individually reasonable and collectively a month. Overwriting the previous date destroys the pattern as it forms.
The record model
What the replacement holds that the sheet cannot.
- Blocker with an owner and an age
- The highest-value view in the system. Most organisations find at least one blocker open far longer than anyone believed and clearable in a day once seen.
- Milestone date history
- Every value it has held, so a slow slip is visible as a pattern rather than as a sequence of reasonable adjustments.
- Derived status with a reasoned override
- Status computed from underlying state, overridable with a recorded 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 tab can see the same three names appearing everywhere.
- Blocking dependency
- Modelled where a real blockage has occurred rather than speculatively, since speculative dependency graphs are maintained for a fortnight and abandoned.
- 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 works
From a plan document to tracked state.
Step 01
Describe the project management process
Model what a blocker is and who clears each type 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 deliverables, the calendar holds where decisions were taken. Reading them keeps the tracker attached to reality.
Step 03
Build the operating surface
Workstreams, milestones with owners, cross-project dependencies, and status derived rather than typed. The cross-project view is the part no sheet can provide.
Step 04
Migrate the workflow, not just the data
Live projects move with their current plan. Historical date changes do not exist in the sheet, so the slip baseline starts now and should be described that way.
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 time to detect that a dependency has slipped
Blocker age at resolution and the number of times a milestone date moved. Both are objective and both correlate with delivery better than status colour.
Implementation path
Tracking projects without a project about tracking.
- 01
Define blocker types and who can clear each. Tracking blockers without a resolution path produces a well-maintained list of things that are stuck.
- 02
Ship the cross-project blocker view first. It requires no change to how anyone plans and it surfaces the thing per-project sheets structurally cannot.
- 03
Derive status from underlying state rather than asking for it. A typed status reflects a mood; a derived one reflects the work, and the gap between them is the useful signal.
- 04
Retain every previous date rather than overwriting, starting immediately. The pattern can only accumulate forward.
- 05
Run it alongside the sheet for one full cycle, then retire the file only after the parallel run holds.
Controls
Controls that matter.
Control 01
Every date change retained with its previous value and a reason, since projects slip three months in one-week increments
Control 02
Cross-project resource commitment visible, because the binding constraint in a multi-project organisation is people rather than plans
Control 03
Escalation paths defined in advance by blocker type, so raising one does not require knowing whom to ask
Build with Launch
Turn the operating requirement into working software.
- • Build a project management app
- • Add forms, views, status, and workflow logic
- • Create role-specific dashboards
Operate with Grow
Keep the workflow connected after the interface exists.
- • Attach follow-up where the workflow touches revenue
- • Keep customer context connected
- • Measure activity through the same context
Connected context
Keep systems of record. Fix the gaps between them.
These are representative connections. UbiGrowth supports 700+ connections across business systems. Connection availability and permissions depend on workspace configuration.
The case against
When the spreadsheet is still the right answer.
With one project and one team, a shared sheet works and a tracker is overhead. The trigger is concurrent projects sharing people, which is exactly what per-project tabs cannot represent.
Examples
Three questions the sheet cannot answer.
The blocker open for five weeks
Blocker age with an escalation threshold turns something everyone mentioned and nobody owned into a tracked exception with a route to a person who can clear it.
The same three people on everything
Cross-project commitment in one view converts an argument about priorities between project leads into an arithmetic problem with a visible answer.
The date that moved four times
Retaining every previous date makes a slow slip visible as a pattern rather than as four separately defensible one-week adjustments.
Measurement
Measure the workflow, not the demo.
Choose a baseline before implementation so speed, quality, exceptions, and downstream impact can be compared using the same definitions.
Model the value of moving repetitive spreadsheet work into a connected workflow.
Use the ROI calculator with your own workload, lead volume, close rate, and deal assumptions. The result is illustrative, not a guaranteed outcome.
Open the ROI calculator →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.
- Derived status is only as honest as the state beneath it. If tasks are marked done to keep a board green, the derived status inherits the fiction with more authority.
- Cross-project dependency modelling gets stale quickly. Model the dependencies that have actually caused a slip rather than every conceivable one.
- Connector coverage varies: Slack, Google Drive, Google Calendar are representative rather than guaranteed, and the fields exposed depend on your workspace permissions.
Keep people in control of consequential decisions.
Automate bounded, observable work first. Keep explicit approvals, escalation paths, permissions, and auditability around financial, legal, clinical, employment, coverage, or other consequential decisions. The goal is faster execution with clearer control—not unbounded autonomy.
FAQ
Questions teams ask before moving off the sheet.
How is this different from a project tool?
General project tools model tasks within a project well and cross-project dependency and shared-resource commitment poorly, which is where multi-project organisations actually break — and it is why the summary ends up in a spreadsheet regardless of what tool is in use.
Should status be manual or derived?
Derived, with an override that requires a reason. Manual status tracks how the reporter felt; derived status tracks the work. Making the disagreement between them visible is more valuable than either number alone.
What is the single highest-value view?
Open blockers by age with an owner, across all projects. Most organisations find at least one that has been open far longer than anybody believed, and it is usually resolvable in a day once somebody can see it.
How much task detail should we carry over?
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.
Do we still need Slack?
Yes. Slack stays authoritative for what it owns, and the new surface reads it through a governed connector rather than storing a second copy.
How do we know whether it actually worked?
Measure time to detect that a dependency has slipped against the baseline you took before switching, alongside manual updates removed and how often a record turns out to be stale.
Start with ARIA
Ask ARIA to build the replacement.
Describe what the spreadsheet is really doing. ARIA plans the operating surface, connects the systems that stay authoritative, builds it, and keeps it running.
- 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
Rebuild the project management workflow, not the file.
Build the cross-project blocker view first, derive status rather than asking for it, and keep every date a milestone has held.