Two plans and a slide

Each company plans in its own tool. The joint plan is a slide, and it's wrong by Wednesday. The dates that slip are almost always the handful of dependencies that cross the line.

The Beevyl team

6 min read

Ask an agency and its client to show you the plan for their joint project and you will usually get three artefacts. The agency has a real plan, in the tool the delivery team actually uses. The client has a real plan, in a tool the agency has never opened. And somewhere between them sits Joint plan v7.pptx, rebuilt by hand the afternoon before each steering committee.

The deck is the only place both companies can see the whole thing. It is also the least true document either side owns, because it was accurate for about four hours in the middle of last Thursday.

The slide is not a plan

A plan is a live model with dependencies in it. If a task slips, the things behind it move. That’s the whole reason to have one.

A slide has none of that. It’s a photograph of somebody’s belief about a plan, flattened onto sixteen-by-nine, arranged to survive a meeting. Change a date on a slide and nothing downstream notices, because there is no downstream — just other rectangles.

Everyone involved knows this, which is why the deck comes with a spoken footnote. This is roughly where we are. Both sides nod. The steering committee approves the roughly, and the actual project keeps running on two internal plans that have never been reconciled with each other.

Two internal plans, the crossings between them, and a disconnected joint slideTwo greyed stacks of tasks represent each company's internal plan. Five curved lines cross the dashed company line between them; four are drawn as faint dashes because nothing tracks them, and one is red because nobody modelled it at all. Above, a dashed rectangle labelled Joint plan v7 dot pptx connects to nothing.Joint plan v7.pptxrebuilt by hand for Thursday's steering committeeconnected to nothingAtlas Studio · internal plan118 tasks, none of which the client can seeMeridian Corp · internal plan96 tasks, none of which the agency can seethe crossing nobody modelled
Where the work actually isTwo hundred and fourteen tasks, five of which leave their own company. The deck at the top describes those five. It is not connected to any of them, which is why moving a bar on the slide changes nothing at all.

Where the date actually dies

Here’s the thing that surprises people the first time they count it. On a typical joint project, the overwhelming majority of tasks never leave the company that owns them. Atlas has a hundred and eighteen tasks; Meridian has ninety-six. Between them, maybe five things genuinely cross the line — a credential set, a dataset, an approval, a signed-off spec, a final delivery.

Those five are where the schedule lives or dies. And they’re precisely the ones nobody’s plan is designed to hold.

A task inside one company has an owner, a tool, a standup, and a manager who notices when it stops moving. A crossing has two half-owners. On Atlas’s plan it appears as waiting on Meridian with no due date, because you can’t commit another company’s calendar. On Meridian’s plan it may not appear at all, since nobody there raised a ticket for it. The dependency is real, load-bearing, and structurally invisible to both tracking systems.

214

tasks across both plans, tracked in detail by somebody

5

that cross the company line — where the dates are decided

0

of those five with a named owner on both sides

So the slip has a signature. It’s never we underestimated the build. It’s four working days lost because a dataset arrived in the wrong format, and neither side had written down what the right format was, and the person who could have said so was told about it on a Thursday call.

A dependency that belongs to both companies belongs to neither.

Why merging the plans doesn’t work

The instinct is to build one plan. It has been tried, roughly three ways, and each fails for its own reason.

Invite them into your tracker. Now one company hosts and the other visits. The guest under-invests because it isn’t their system, keeps a private copy “just for our side”, and loses access the moment the engagement ends or someone runs a security review. You’ve centralised the plan and decentralised the trust.

Build a master plan in a third tool. Maintaining it becomes a job, and it’s nobody’s job. Master plans decay from the leaves inward: first the internal detail stops being copied up, then the dates stop being copied down, and within a month it’s the deck again, only with more clicking.

Rekey between the two. Two systems, one human synchroniser, and a permanent gap between them. Every copy introduces drift, and the drift is always discovered late.

The mistake all three share is scope. They try to unify the plans, when the plans were never the problem. Atlas’s tracker is good. Meridian’s is fine. Both companies are competent at running their own work — it’s the seam that has no home.

The slide

  • Rebuilt by hand before each meeting
  • Dependencies described, not modelled
  • Moving a date changes nothing downstream
  • Accurate for a few hours
  • Two versions in circulation by Friday

The spine

  • Maintained by the act of doing the work
  • Each crossing is an object with a state
  • A slipped acceptance moves what's behind it
  • Accurate continuously, for both companies
  • One copy, owned jointly

Model the crossings, not the plans

Beevyl’s design starts from the count above. If five things out of two hundred and fourteen cross the line, then the joint layer should hold five things — not two hundred and fourteen.

That’s the spine: a thin structure between two internal plans, holding only what passes between them. Each crossing becomes a handoff, and a handoff is a real object rather than a row in a deck.

Anatomy of a handoff objectA card representing one crossing. It carries a type chip and a state chip, the thing being handed over, the direction and due date, three acceptance criteria with two already met, a progress meter, and a response clock. Labels around the card point to each part.A state both companies readhandoffin progressSandbox credentials & API keysMeridian ⟶ Atlas · due Thu 14 AugRead and write scopes confirmedRate limits documentedTest tenant seeded with sample datatime to accept · 1h 40m2 of 3 criteria metWhat crosses the linenamed, not buried in a threadCriteria, agreed up frontwhat "done" means, before work startsWho acts nextdirection and date, on the objectA clock, runningstarted when it was proposedSlip the acceptance date and everything behind it moves — on both sides.
One crossing, modelledNot a row in a deck: an object with two named owners, criteria agreed before the work starts, a lifecycle both companies can see, and a clock that began the moment it was proposed.

The nice side effect is that the deck becomes honest. When the five crossings have real states, Joint plan v7.pptx stops being a hand-built artefact and becomes a screenshot of something true — or, more often, stops being built at all, because nobody needs a photograph of a thing they can just look at.

Two plans is the correct number of plans. What was missing was the five lines between them.