Document classes that make up a business acumen toolkit

A tool, in an operating business, is usually a document. Not software: a document with a defined job, a defined owner, and a defined relationship to the other documents. Most of the confusion people have about running something is really confusion about which of these documents answers which question.

So this page defines the classes rather than naming products. Each entry gives the document, what it is the authority on, and the one thing that separates it from its nearest neighbor.

What to take away

Documents that describe what you sell

Price list. The prices offered to a defined group of buyers, on defined terms. Its neighbor is the rate card, which prices time or exposure rather than goods. The difference is the unit, and the unit changes what a discount means.

Quote. A price offered to one buyer for one scope, with an expiry. Its neighbor is the estimate, which is a considered guess and binds nobody. Using the words interchangeably is how a business ends up held to a number it thought was provisional.

Specification. What the thing is. Its neighbor is the scope of work, which is what you will do. A specification can be met by work nobody agreed to perform, and a scope can be performed on a thing nobody defined.

Documents that describe what it costs

Bill of materials. The components and quantities that go into one unit. Its

neighbor is the routing, which is the sequence of operations performed on them. Together they give a unit cost; separately, neither does.

Chart of accounts. The list of categories every transaction is sorted into. It is not a report. It is the vocabulary that all your reports are written in, which is why changing it breaks comparison with every earlier period.

Cost model. An arrangement of costs by behavior and traceability, built to answer a specific question. The vocabulary this rests on, fixed against variable and direct against indirect, is set out in the business vocabulary guide; the point here is that a cost model is built for one question and is misleading when borrowed for another.

Documents that describe capacity and commitment

The budget and forecast row is worth pausing on. It is one of the pairs the nine acumen confusions treats as a live error, not a definition.

A budget is a decision. A forecast is a prediction. Revise the budget every time the forecast moves and you have no budget. Never revise the forecast and you report a decision as an observation.

Documents about the business itself

Business plan. An argument for a course of action, with the reasoning exposed. Public guidance on what one contains, such as the Small Business Administration's business plan guide, is a better starting point than a template, because the value is in the questions rather than the headings.

Register. Any list kept current for a defined purpose: risks, assets, suppliers, decisions. What makes something a register rather than a list is that someone owns it and it has a review date.

Policy. A standing decision, made once, so it does not have to be remade. Its neighbor is the procedure, which is how the policy is carried out. Writing a procedure where a policy is needed leaves the judgment unmade.

How to tell whether you have too many

Three questions settle it faster than an inventory.

A document that fails all three is a habit rather than a tool. A document that answers all three is worth the maintenance even if it is a page long. This is the same test the decision record applies to the fields of a choice, and the same one the assessment guide applies to an instrument.

Writing them so they can be read

Every document here gets read by someone who did not write it, often under time pressure, often to settle a dispute.

That calls for plain construction: short sentences, defined terms, and no word doing two jobs. Federal guidance on writing for understanding gives the mechanics, and they apply to a bill of materials as much as to a public notice.

Common questions

Do I need all of these to run a small business?

No. You need the ones that answer questions you actually face. The list is useful as a vocabulary, so that when a question comes up you know what kind of document would settle it.

Can one document play two roles?

It can, if the roles are named inside it and the sections are kept apart. What does not work is a document that silently changes role halfway down, because readers carry the first role into the second half.

What if two documents disagree?

Decide in advance which one governs, and write that down in both. Deciding afterward, in the middle of a dispute, is how the more recent document wins regardless of whether it should.

How often should any of this be reviewed?

On a trigger, not on a calendar, wherever you can define the trigger. A review date with no trigger produces a document that is confirmed rather than checked.