ProductUpdated 9 min read
The tire-swing problem in IT projects
How a simple ask mutates through handoffs into the wrong delivery - and the communication habits that keep projects honest.
project managementrequirementsmiscommunicationdeliveryacceptance criteria
Reckap Team
The tire-swing cartoon is funny until you are paying for it. Customer asks for a tire on a branch; the lead "improves" it; the analyst adds features; engineering ships something that hangs wrong; ops installs a different thing entirely. The fix is boring communication discipline - not a new methodology slogan.
How the ask mutates (the familiar plot)
| Role | What they think they heard | Failure mode |
|---|---|---|
| Customer | Tire swing for the kids | Assumes the obvious is understood |
| Project lead | A nicer bench swing | Rewrites without confirmation |
| Analyst | Multi-feature seat | Adds unrequested scope |
| Builder | Something that "works" on one side | Optimizes a wrong model |
| Ops | Nothing / different install | Never saw the real definition of done |
If the demo cannot be checked against the original ask, you are reviewing vibes - not delivery.
Habits that stop the fiasco
Communication loop
- 1
Capture outcome + acceptance
One page: who benefits, what "done" looks like, constraints, and how you will test it.
- 2
Share one artifact
Same doc or ticket for lead, analyst, builder, QA, and ops - not Slack folklore.
- 3
Prototype early
Show a thin version to the customer before you invest in ornaments.
- 4
Demo against the ask
Every sprint: does this still match acceptance? If not, stop and decide.
- 5
Control changes
Scope changes need an owner, a date, and an updated acceptance check.
Tools help - they do not replace clarity
Jira, Linear, Miro, or a shared Notion page only work when:
- The acceptance criteria live in the ticket
- Designs link back to the same outcome
- QA cases map to those criteria
- Ops sees install and rollback notes before go-live
A board full of tasks with no outcome statement is still a tire-swing factory.
When teams get it right
- Customer confirms a wireframe or thin prototype early
- Builders ship small increments against the same acceptance list
- QA catches mismatches while change is cheap
- Ops installs what was tested - with a runbook
Process weight
Pros
- One artifact + demos scales to small teams
- Change control prevents silent cost growth
- Ops handoff reduces post-launch blame
Cons
- Ceremony without acceptance criteria wastes time
- Verbal "we all know" agreements recreate the cartoon
Want a one-page outcome + acceptance template for your next build?
Book a callFAQ
- What is the tire-swing metaphor?
- A classic cartoon of how a simple request gets reinterpreted at each handoff until the delivered product barely matches what the customer asked for.
- Where do projects usually break?
- Between customer and lead ("improvements" without confirmation), lead and analyst (unrequested scope), analyst and builder (wrong mental model), and builder and ops (unrunnable delivery).
- How does Reckap prevent this?
- We lock a written job, acceptance checks, and short demos against that job - with named owners for scope changes and a handoff runbook.
- Do we need heavy process?
- No. You need one shared artifact, frequent demos, and explicit change control. Tooling helps; discipline matters more.