Nobody reads the design basis memo — should I keep writing it?

Kavita TanCost Engineering · 26 yrs

Shortening it did not work because length was never the problem — the problem is that at kickoff the client has no question the memo answers. People read documents that resolve something they are currently uncertain about, and at kickoff the client is certain, wrongly, that everyone agrees. The format change that has worked for me is to stop delivering it as a document to read and start delivering it as a set of decisions to confirm. Same content, but every assumption is written as a statement requiring a yes, with a named owner and a date, and the ones that carry cost or schedule consequences are flagged as such.

In practice that means about eight to twelve confirmation lines at the front, each one phrased so that agreeing to it is a real act — we are designing to this standard, the client is providing this survey by this date, this scope is excluded, this jurisdiction governs. They get read because they need a response, and the prose behind them becomes reference material that nobody has to read at kickoff. The dispute value is unchanged and the up-front engagement goes from near zero to most of the material points being actively confirmed.

Kenji RahmanSystems Engineering · 21 yrs

Verified expertise in Systems Engineering

A structured table does beat prose, but only for the assumptions themselves — the reasoning still needs prose and it is fine for that part to go unread until needed. What made ours get read was putting a consequence column next to each assumption. Not the assumption alone but what changes if it turns out to be wrong: this survey datum assumption, if incorrect, is a two-week rework of the setting-out drawings. Clients skim assumptions and stop dead at consequences, because the consequence column is the only part written in their currency rather than ours.

The secondary benefit is internal and I did not anticipate it. Filling in the consequence column forces you to actually think about which assumptions matter, and on most projects three or four dominate and the rest are administrative. Once that is visible you can spend the kickoff conversation on the three that matter instead of walking through all twenty, which is a better meeting and takes less time than the version nobody engaged with.

Samuel MehtaOperations Research Engineering · 15 yrs

Worth separating the two audiences, because they want different things and one document serving both is part of why neither reads it. The client cares about scope, exclusions, what they owe you and when, and what changes the price. The reviewer or the next engineer cares about load cases, standards, software versions, and where each number came from. Splitting into a one-page scope and assumptions confirmation for the client and a full technical basis in the project file got the first one read reliably and left the second one doing its real job, which is being findable in eighteen months.

On that second job: the technical basis memo is worth writing even if literally nobody reads it during the project, because the person it serves most often is you, a year later, being asked why a member was sized the way it was. I have never regretted the day spent. I have regretted not writing one on a project where the client changed procurement route eight months in and every assumption had to be reconstructed from the model.