Ask around and you will find far more studios that abandoned a project tool than studios that chose the wrong one. The software was fine. The rollout was a Monday announcement, a shared login, and an expectation that everyone would work it out. By week three the board is stale, and a stale board is worse than no board because now the studio has two versions of the truth.
Adoption is a separate discipline from selection, and it is the one nobody plans for. This is a rollout that works in a small or mid-size practice, in the order the steps actually have to happen.
Do not migrate everything
The single most common rollout failure is moving all live projects at once. It generates a week of data entry, produces a system full of half-imported records nobody trusts, and burns the team's goodwill before anyone has seen a benefit.
Move one project. Pick a live one in the middle of a phase — not a new one, which hides all the awkward cases, and not the most critical one either. One project generates every real problem you will face, at a scale where you can still fix them.
The first 30 days: one project, one crew
Put three or four people on it, including at least one sceptic. Sceptics are the most valuable people in a rollout, because the objections they raise in week one are the objections the whole studio will raise in month two, and it is much cheaper to answer them now.
- Set one measurable goal — usually "nobody asks what to work on next in the Monday meeting".
- Move only what is live. Historic tasks are archaeology; leave them where they are.
- Name one person who answers questions. Rollouts die in the gap where nobody knows who to ask.
- Book a 20-minute review at day 30. Not optional, and not a status meeting.
Days 30 to 60: the second project, and the rules
By day 30 the pilot crew has opinions. Turn them into two or three written conventions before you widen — where drawings go, what a task title looks like, when something moves to Review. Studios that skip this end up with four people using the same tool in four incompatible ways, which looks like a software problem and is not.
Then add a second project and a second crew, ideally one with a different project type, so the conventions get tested rather than just repeated.
Days 60 to 90: switch the meeting
This is the step that decides everything, and it is cultural rather than technical: run the weekly studio meeting from the tool. Not from a printout, not from someone's notes — from the board, on a screen, in front of everyone.
The moment the meeting depends on it, the board stays current, because being out of date now has a visible cost. Every studio that has made a tool stick did some version of this. Every studio where it rotted skipped it.
A tool becomes real the week the studio meeting cannot run without it.
The four ways rollouts die
| Failure | What it looks like | The fix |
|---|---|---|
| Big-bang migration | Everything moved in week one, nothing trusted by week three | One live project first |
| No owner | Questions go unanswered, people revert to email | One named person for 90 days |
| Parallel running | The tool and the old spreadsheet both maintained | Set a date the spreadsheet dies |
| Principal opt-out | Leadership asks for updates by email anyway | Leadership uses it first, visibly |
Kill the old system on a date
Running the new tool alongside the old spreadsheet feels prudent and is the slowest possible way to fail. Two sources of truth means neither is trusted and everyone maintains both until they give up and keep the familiar one. Set a date, announce it, and on that date make the old system read-only. Expect a rough fortnight and plan for it rather than being surprised.
What to measure at 90 days
Not licence utilisation. Ask three questions instead: does the Monday meeting run off the board, can a principal answer where a project stands without asking anyone, and has anything important been decided somewhere other than in the tool. Three yeses and it has taken. Any no tells you precisely which habit has not moved yet.
Choosing versus rolling out
If you have not settled on a product yet, do that with a weighted framework and a two-week live trial rather than a demo — and remember that the tool most likely to survive this rollout is the one that needed the least configuration to look like your practice in the first place.