The cost of copies
Why teams keep several versions of the same plan, what each copy costs, and what changes when a tool refuses to make a second one.
Abstract. Every project of any size ends up with more than one copy of its plan. This paper names the copies, estimates what they cost in time and trust, and describes a design that avoids them by holding one record per task and treating views, whiteboards and presentations as lenses on it.
1. The copies
Ask a project lead where the plan is and the honest answer is several places.
The kickoff copy is the whiteboard or the sticky notes, photographed and typed up. The working copy is the board the team moves cards on. The sponsor copy is the timeline someone was asked for, drawn in a scheduling tool or a spreadsheet. The review copy is the deck, redrawn from whichever of the others looked most current the night before.
Each copy exists because a different audience needed a different shape, and the tool that held the previous copy could not produce that shape. Each one is a translation, and translations are made at a point in time. From that point the copies diverge.
2. What a copy costs
Time to make it. Rebuilding a twenty-task plan as a timeline takes an hour the first time and twenty minutes each time after. A review deck takes an evening. Across a quarter with monthly reviews and weekly sponsor updates, a single plan owner spends a working week on copies.
Time to reconcile. Before every review, someone checks the copies against each other. Which dates moved? Was the task that slipped on the board moved on the timeline? This is unpaid detective work and it lands on the most senior person in the room.
Trust. When two copies disagree in a meeting, the meeting stops. Decisions wait until someone finds out which one is true. Over time people stop believing any of them, and the plan loses its authority as a plan.
Information. A translation drops what the destination cannot hold. The board loses dependencies. The timeline loses who owns what. The deck loses everything but the dates. The next copy is made from a lossy source.
3. Why tools make copies
Most project tools were built around one shape. A board tool adds a timeline later as a separate module that reads from the board at the moment you open it, and writes back only some of what you change. A scheduling tool adds a board that is a filtered list. A whiteboard tool exports to the board tool. A slide tool imports from a spreadsheet.
Each product is honest about its center of gravity. The copies are the seams between them.
4. One record
The alternative is structural rather than clever. Hold one record for each task, with every attribute any shape could need, and treat the board, the list, the timeline, the calendar and the table as lenses on that record. A lens reads and writes the record; it never keeps its own.
Three consequences follow.
Nothing drifts, because there is nothing to drift from. A card moved to Done is a row marked complete; the timeline reads the same row.
The handoffs stop being handoffs. If the whiteboard lives in the same product as the record, a sticky note can become a task without being retyped, and keep a link back to the note. If the presentation tool reads the record, the review timeline draws from the plan and stays linked to it.
Depth comes along for free. Dependencies, critical path, capacity and baselines are attributes and calculations on the one record, visible wherever they are useful, rather than features of one module that other modules cannot see.
5. What it demands of the product
One record is a discipline, and it has costs of its own.
The record is wide. Every view must cope with tasks created in another view: the board needs a home for tasks without a lane; the timeline needs an answer for undated tasks; the list needs an order for tasks the board positioned.
Completion must have one owner. Each view has its own gesture for done; the record must have one flag, set by any of them and read by all.
Presentations must be built from data, not pictures. A timeline exported as an image is a copy again. The export has to be shapes and text that the presenter can still edit.
6. The arc
Work has a shape: it starts loose, gets structured, gets done, and gets shown. A product that holds one record across that arc, from the sticky note to the slide, does not remove the audiences that wanted different shapes. It gives each of them a lens instead of a copy. The plan owner stops reconciling and starts planning.
That is the design behind Kyndium. The specifics, the data model, the triggers that own completion, the compiler that turns rows into editable shapes, are described in the engineering posts on this site. The claim of this paper is narrower: the copies are the cost, and a tool can refuse to make them.
Comments