Project management software for architects: why generic tools lose to the work
Architects keep adopting generic project tools and quietly abandoning them by month three. It is not a discipline problem — the tools track tasks, and an architecture project is not made of tasks.
There is a pattern every practice principal recognises: the office adopts a well-known project tool, builds boards for live projects, and for a month everything is neat. By month three the boards are stale, the real state of every project lives in the drawing folders and the principal's head again, and the subscription quietly renews for software nobody opens. The failure is structural, not personal.
An architecture project is not made of tasks
Generic project software has one atom: the task — a sentence with an assignee and a date. But the load-bearing objects in a practice are different things entirely: the DRAWING (which has revisions, a discipline, a set, a transmittal history), the STAGE (which has deliverables and an approval that gates the next one), the FEE (which attaches to stages, not to tasks), and the CLIENT DECISION (which must be timestamped against exact revisions). Model those as tasks and the model is fiction within weeks — we wrote about the stage ladder here.
| What the practice means | What a task tool records | What is lost |
|---|---|---|
| Issue revision C of the working drawings to the contractor | "Send drawings" ✓ done | Which drawings, which revision, to whom, when — the transmittal record |
| Concept approved; begin developed design | "Concept" card moved to Done | The approval's timestamp, scope, and what exactly was approved |
| Stage 2 is 60% complete | A % typed by a human | Any connection to the actual deliverables' state |
| Invoice the stage-completion instalment | A reminder | The link between fee, stage and approval that justifies the invoice |
What to demand instead
- Stages as first-class objects, with deliverables and sign-offs attached — not folder names.
- Drawings with revision history and transmittals — who has revision B, and when C superseded it.
- Fees connected to stages, so "stage done" and "invoice due" are one fact — see dual-fee accounting.
- A client approval surface that timestamps decisions against revisions.
- A BOQ that belongs to the project, for the practices that produce them.
- And yes — ordinary tasks too, for the work that IS a sentence with a date.
This is the case for practice-shaped software over configured-generic software, and it is the argument Ofivio AE is built on: stages, sets, revisions, approvals, BOQ and fees as the native objects, with VO — the AI officer — answering questions across all of them. The generic tools are excellent at what they model; the question is whether your practice is willing to be remodelled to fit them.
Related reading
The best architectural practice management software in 2026
Most 'best software for architects' lists compare marketing pages. This one compares the five things that actually determine whether a tool fits an architecture practice — and is honest about which practices we're the wrong answer for.
Ofivio AE, explained: what's in the box, what it costs, and how the product system works
Ofivio moved to a product system: you buy the product for your industry, size it by seats, and add whole dashboards as you grow. Here is exactly how that works for an architecture or engineering practice.
From concept to handover: the design stages, and why your software should know them
Stages are not bureaucracy — they are how design risk is retired in order. Here is the ladder most projects climb, and what each rung means for drawings, fees and approvals.