Planning a Project

What a Plan Actually Is

Strip away the templates and the tooling, and a plan is two things. First, a shared mental model: everyone who will build, review, or depend on the project holds the same picture of what is being built, why, and how the pieces fit. Second, a de-risked sequence: the work is ordered so that the things most likely to be wrong are discovered first, while there is still time and budget to react. That is the whole product. A plan is not a Gantt chart — that is a rendering. It is not a promise — promises are commitments, and they live on the roadmap with dates and buffers attached. It is a model plus a sequence, held in common.

Eisenhower's line — "plans are useless, but planning is everything" — is usually quoted as a shrug and is actually a precise engineering claim. The artifact goes stale on contact with reality: an estimate slips, a dependency surprises you, a client moves a date. But the planning survives, because what the exercise actually produced was the shared model — and a team holding the same model can re-derive the sequence in a hallway conversation when the artifact breaks. A team without the model re-plans by meeting, every time, at meeting speed.

Planning failure has two poles, and most engineers have lived at both:

• No plan. "We're agile, we'll figure it out as we go." Three engineers start building immediately — each building their own private guess at the system. Week three: the integration points do not fit, the data model supports nobody's feature, and half the code answers a question the client never asked. The weeks saved by skipping planning are repaid with interest, in rework and in morale.
• Planning theater. The opposite pole: weeks of documents. A forty-page design doc, six-week estimates to the half-day, a risk register nobody will reopen. The document is impressive, obsolete by the second sprint, and — the tell — nobody building the system ever cites it. All the cost of planning, none of the shared model, because a document that long is written to be approved, not read.

The Hireboard method threads the needle in roughly one day of elapsed work: a couple of hours of research, a few hours of drawing, a review, and a decomposition session. Small enough that nobody skips it under deadline pressure, substantial enough that the expensive mistakes get caught while they are still cheap. Here it is in full — the rest of the module walks through each step.

Notice what the method spends its budget on: research to avoid reinventing, diagrams to find design errors cheaply, buy-in to find objections early, and decomposition that treats people as people — with knowledge, enthusiasm, and existing obligations — rather than as interchangeable capacity. Every step exists because skipping it has a named, expensive failure mode.

The Rapid Research Phase

Before drawing anything, spend one to two hours — timeboxed, on purpose — answering a single question: what already exists? Almost no project at Hireboard is the first attempt at its problem. Someone has formalized it in a paper, shipped it in a competing product, sold it as a platform, or tried it here two years ago and left opinions behind. The research phase exists to inherit all of that before you commit a single box to a diagram.

The phase has two halves. The first is external:

• Research papers. If the project has an algorithmic or data-shaped core — ranking, matching, dedup, scoring, scheduling — someone has probably formalized your problem, named its hard cases, and benchmarked three approaches. Twenty minutes of search-and-skim can replace a month of rediscovering known results, including the known dead ends.
• Competitor analysis. How do products in the space handle this? Not to copy — to calibrate. Competitors have paid for user research you get to read for free in their UI: what they expose, what they hide, what they charge for. Where every competitor converges on the same shape, there is usually a reason; find it before you diverge from it.
• Tools and platforms. The build-vs-buy inputs from the ROI module land here. Is there a library, a managed service, an API that makes a third of this project someone else's problem? You are not deciding build-vs-buy in this hour — you are making sure the buy option is on the table when the architecture gets drawn, because a diagram drawn in ignorance of a viable platform will quietly commit you to building it.

The second half is internal, and it is the half engineers skip: talk to teammates who have touched this area. Fifteen minutes with the right two people surfaces prior attempts ("we tried that queue shape in 2024, here is the postmortem"), strong opinions ("whatever you do, do not put this in the main tenant database"), and landmines ("that client's data violates the assumption you are about to make"). Internal soundings also start the buy-in process early — the reviewer who was consulted before the diagram existed reads it as a collaborator, not a judge.

Why the hard timebox? Because research has sharply diminishing returns after the first pass — the second hour finds a fraction of what the first did — and because research is unbounded by nature: there is always one more paper, one more competitor teardown. The goal is to inherit the state of the art and avoid reinventing, not to write a literature review. When the timer runs out, you write the deliverable: a short research note — the links worth keeping, the two or three viable approaches you found, and your leaning with one sentence of why. That note becomes the first page of the plan document and the context for everyone who reviews the diagrams.

The Three Artifacts

Research done, you produce exactly three artifacts: the static view (architecture), a dynamic view (the conceptual diagram), and the data view (the ERD). Three, because each one catches a class of design error the other two structurally cannot — and only three, because a plan that takes a week to draw is planning theater with better graphics.

Why diagrams at all? Two reasons, and they carry the whole method. First, diagrams are the cheapest medium in which to find design errors. An hour of drawing catches what ten pages of prose hides — prose lets a contradiction sit politely in two different paragraphs, while a diagram forces the pieces onto one page where they visibly collide — and what three weeks of code makes expensive to unwind. The cost of moving a box is zero; the cost of moving a service is a sprint. Second, diagrams are the buy-in instrument. People can point at a box and disagree with it. Nobody argues productively with a wall of text; everybody can say "that arrow is wrong, the webhook goes to the queue, not the API." The precision of the disagreement is the value.

Artifact 1: The Architecture Diagram

The static view: what exists, and where the boundaries are. Boxes for components and services, lines for how they talk, clear marks for third parties and trust boundaries, and an explicit answer to where state lives. Crucially for a plan — as opposed to documentation — it distinguishes what is new, what is touched (existing components that will be modified), and what is untouched (context drawn for orientation only). That three-way split is the scope statement in visual form: reviewers can see the blast radius at a glance.

A good architecture diagram answers, at a glance:

• What are the components, and which are new versus modified versus just context?
• Where does state live — which stores, owned by which components?
• What third parties are involved, and where do we cross a trust or billing boundary?
• Where are the seams — the interfaces where this system could be extended, replaced, or cut in scope?
• What is deliberately out of scope, drawn greyed-out or listed at the edge?

Keep it to one page. This is a forcing function, not an aesthetic preference: if the diagram does not fit on one page, either the project scope is too big for one plan — split it — or the diagram has the wrong zoom level and is drowning its own signal in detail that belongs elsewhere.

Artifact 2: The Conceptual Diagram

The dynamic view: how the system behaves over time. The architecture diagram shows the machine at rest; the conceptual diagram runs it. Unlike the other two artifacts, its form is chosen to fit the project:

• Request flow for systems work: a request enters here, gets authenticated there, fans out to these services, writes land in this order. The natural home for questions about latency, retries, idempotency, and partial failure.
• User journey for product surfaces: the screens and decisions a user moves through, including the unhappy paths — abandonment, validation failure, the back button. The natural home for "wait, how did they get here without an account?"
• Business-logic / state flow for domain-heavy work: the states an entity moves through and the rules governing each transition. A candidate goes from sourced to screening to submitted to placed — who can trigger each transition, and what makes one invalid?
• Sequence diagrams for anything crossing service boundaries: the vertical lifelines make ordering, ownership, and failure handling explicit in exactly the places where prose says "and then the webhook fires" and hides three race conditions behind the word "then."

In practice this is the artifact that most often changes the design. The architecture diagram tends to survive review; the conceptual diagram is where hidden assumptions and missing steps become visible, because walking a concrete scenario through the boxes is a simulation, and simulations fail loudly. "What happens if the client uploads the CSV twice?" is invisible in the static view and unavoidable in the dynamic one. If your conceptual diagram walk produced no changes to the architecture, the usual reason is that you walked only the happy path — walk a failure.

Artifact 3: The ERD / Data Model

Entities, relationships, cardinality, and ownership: what things exist in the domain, how they relate, one-to-many or many-to-many, and which service owns which table. Of the three artifacts this looks the most mechanical, and it earns its dedicated slot for one reason: the data model is the hardest-to-reverse decision in the project. In one-way-door terms from the ROI module, most code is a two-way door — refactors are cheap, interfaces can be shimmed. A schema with production data in it is about as close to a one-way door as day-to-day engineering gets: migrations are risky, backfills are slow, and every downstream consumer has quietly coupled to your column names. You can rewrite a service's internals in a week; you cannot un-ship a wrong cardinality that three clients' data now depends on.

The working discipline:

• Model the entities before the endpoints. APIs are projections of the data model; getting the model right makes the API design mostly mechanical, and getting it wrong makes every endpoint a workaround.
• Question every many-to-many. Each one is a claim about the world — "a candidate can belong to many pipelines, a pipeline holds many candidates" — and each is expensive if wrong in either direction. Modeled one-to-many when reality is many-to-many, you get the worst migration in the book. Modeled many-to-many "to be safe" when reality is one-to-many, every query grows a join and every invariant gets harder to state.
• Name the invariants. Write down, next to the diagram, the sentences that must always be true: "a placement always references exactly one active contract," "an interview cannot exist without a submitted application." Invariants are where reviewers with domain knowledge catch the errors that cardinality notation is too coarse to express.

Getting Buy-In

The three artifacts now circulate — before anyone builds anything. This is a genuine review, not an FYI: the artifacts are at roughly the 30% stage from the Communication Standards module — direction chosen, details deliberately open — which is exactly when feedback is cheapest to act on. An objection raised now costs a redrawn diagram: thirty minutes. The same objection raised at PR review costs the entire iteration — the code exists, the design is load-bearing, and the choice is between an expensive rewrite and quietly shipping a design someone correctly flagged as wrong. Buy-in is how objections get moved from the expensive end of the project to the cheap end.

Three groups must actually look at the artifacts:

• The teammates who will build it. They will find the practical flaws, and — equally important — people execute plans they shaped with far more energy than plans they were handed. The review is where the plan stops being yours and starts being the team's.
• Owners of the systems it touches. Every "touched" component on the architecture diagram has someone who knows its landmines. Skipping them converts their knowledge from a review comment into a production incident.
• Whoever owns the client commitment. The plan makes assumptions about scope and timing; the account owner is the only person who can check those assumptions against what was actually promised. Discovering at delivery that "the export" meant something different to the client is a planning failure, not a communication accident.

Mechanically, run it as a short review meeting (thirty minutes; walk the conceptual diagram against the architecture, then walk the ERD) or an async thread with a deadline ("objections by Thursday EOD"). Either works. What does not work is treating silence as agreement: silence is not buy-in. People do not read attachments; collect explicit acks, by name. The difference matters most precisely when the plan later hits trouble — "you saw this and agreed" versus "I never really looked at it" are two very different conversations to be having in week four.

And the review has an end. Objections get heard, the design gets amended or the objection gets answered, and once the review closes, disagree-and-commit applies: the time for redesigning was the review, and relitigating the architecture in week three — without new information — is a process foul. The flip side of taking objections seriously before the close is being entitled to full commitment after it.

Chopping It Up

Artifacts agreed, the plan becomes work. Decomposition at Hireboard is done under four considerations, applied in order: slice for a steel thread first, assign by knowledge and passion, constrain by reality, and emit a timeline that aligns all of it.

Slice for a steel thread first

Before anyone builds in parallel, the first slice is the thinnest end-to-end path through the whole design: one real input, through a skeletal version of every component on the architecture diagram, to one real output. The steel thread proves the architecture — the boundaries connect, the data flows, the third party behaves as its docs claim — before three people spend three weeks building against interfaces that were never exercised. Integration risk is the failure mode that detonates late by default; the steel thread forces it to detonate in week one, when it is a design conversation instead of a crisis. Only after the thread stands does the team fan out to thicken each part in parallel.

Assign by knowledge AND passion

With slices defined, who takes what? The house doctrine is to weigh two signals, and the second is the one most planning processes ignore:

• Knowledge is the obvious one. The teammate who knows the scoring pipeline will be fast and right in it — they know the landmines, the history, the reasons the weird parts are weird. All else equal, knowledge wins.
• Passion is the underrated one. An engineer genuinely excited about an area moves at roughly twice the speed of one assigned to it indifferently — they think about it in the shower, they read around it, they push past the first acceptable answer to a good one. And passion compounds: assignment is also a development tool. The engineer who is excited about search but has never owned it becomes, via this project, your next search owner. Staffing purely by current knowledge produces a team whose experts are permanent bottlenecks and whose juniors never become experts — optimal for this quarter, corrosive over four.

When the two conflict — the knowledgeable senior versus the passionate junior — the answer is usually structure, not either/or: give the passionate engineer the ownership and the knowledgeable one a bounded reviewer role. The junior moves fast and grows; the senior's knowledge flows in through review at a fraction of their time; the bus factor on that area goes from one to two. Reserve pure-knowledge staffing for slices that are genuinely critical path with no schedule slack.

Constrained by reality

The ideal assignment meets two constraints that live outside the project. First, current assignments: nobody actually has 100% free capacity, and a plan that assumes otherwise is fiction with names in it. If your best-fit owner for the integration slice is 60% committed to another team's deliverable until the 15th, the plan must know that — either the slice starts on the 16th, or it starts thinner, or someone else takes it. Second, upcoming client deliverables: the immovable dates from the roadmapping module. Client commitments are the fixed points the timeline bends around, never through — a plan that schedules its riskiest integration work the same week as a contract deliverable owned by the same person has decided, silently, to miss one of them.

The output: an aligned timeline

The result of chopping is a timeline that aligns people, dependencies, and dates optimally: dependencies sequenced so nobody is blocked waiting on an interface, risky work pushed early where there is still time to react, buffers placed on the critical path rather than sprinkled evenly, and client dates protected absolutely. A worked example — a three-person project, five slices:

Read the rationale column again — that is the method in miniature. Every assignment names its logic: knowledge, passion with a review backstop, or an external constraint. Every sequencing choice is risk-first: the scary slice gets the early start and the buffer, the safe slice absorbs the late start, and the client date has clear air in front of it. A timeline whose every row can answer "why this person, why this week" is aligned; one that cannot is just names in a grid.

The Assembled Plan

Everything above assembles into a deliberately small package: a one-pager plus the three artifacts. The one-pager contains:

• Problem statement — two or three sentences: what business outcome this serves and which roadmap objective it traces to.
• The research note — links, the viable approaches considered, the chosen leaning and its one-sentence why. Six months from now this paragraph is the answer to "did we consider X?"
• The three diagrams — architecture, conceptual, ERD — linked or embedded, with the ack list from the review.
• Milestones with owners — the slices from decomposition, each with a name and a why-them.
• The timeline — sequenced, buffered, client dates marked as immovable.
• Top risks with kill criteria — the two or three things most likely to sink the plan, and for each, the evidence that would trigger a re-plan. Declared now, while everyone is neutral.
• Explicit out-of-scope — the sentences that prevent scope creep by making every expansion a visible decision instead of a quiet drift. What the plan will not do is as load-bearing as what it will.

The document is living, and this is where Eisenhower closes the loop. Update it at every milestone — two minutes of status against the timeline. And when reality diverges from the plan, as it will, change the plan loudly rather than quietly missing it: the overcommunication doctrine applied to planning. "The scoring slice is a week behind because the legacy data was dirtier than modeled; here is the re-cut timeline; the client date is still protected because that is what the buffer was for" — sent the week you know, not the week the date arrives — is a leader managing a plan. A plan that still claims week-3 status in week 5 is worse than no plan: it is actively lying to everyone who reads it, and the team learns to stop reading.

Knowledge Check

Five situations from real project starts. Pick the answer the house method gives — and notice, in each, which step of the method is being tested.