Standardisation is one of the easiest management benefits to explain. Common templates, reporting cycles, job sheets, checklists and escalation rules stop people reinventing the same thing, make information comparable and help new staff get up to speed. A business that does the same kind of work again and again should not solve the same administrative problem from scratch each time.
It is also one of the easiest benefits to overdo. A process that suits a large, high-risk project can smother a small, routine job. A report that helps an owner make decisions becomes a burden when every field is compulsory whether or not it matters. Over time, processes accumulate: each one added for a good reason, few ever removed, until people spend more time feeding the system than doing the work it was meant to support.
This article is about deciding what deserves consistency and what needs judgement. It sets out three tests every process should pass, what usually benefits from standardising, what usually does not, how to design reporting around the minimum information a decision needs, and how a small business can trim its processes without losing control.
Where the idea comes from
Much of the thinking on this comes from the practice of running project management offices (PMOs), the teams in larger organisations that set project methods, templates and reporting. Practitioner guidance has pointed in two directions. Some, such as a 2017 Accenture paper on centralised PMOs, emphasises that standard reporting, progress measures, meeting schedules and tools improve executive oversight and let delivery teams focus on execution rather than rebuilding project administration every time. Other guidance, including a 2013 paper by the Boston Consulting Group and the Project Management Institute, stresses “smart and simple” processes and minimum sufficiency, describing executive monitoring focused on a limited set of milestones, indicators, changes and exceptions.
Put together, the two views produce a stronger principle than either alone: standardise enough to create reliable control and a shared language, but no more than the decisions require. That principle applies just as well to a small business with job sheets and a weekly meeting as to a large organisation with a formal PMO.
Common misreadings
- More process means more maturity. More documents can indicate better control. They can also indicate anxiety, with each past problem answered by another form.
- Standard formats mean standard information. Two jobs can submit identical reports while meaning different things by “complete”, “on track” or “at risk”. Standardising definitions matters more than standardising layouts.
- A template can make the decision. A process can organise evidence. It cannot decide whether a job should continue or a customer should be kept. That remains a judgement.
- Compliance is the measure of success. If the business cares more about fields being filled in than about better decisions, people learn to fill in fields.
Three tests for every process
Every recurring process, template, report or meeting should pass three tests:
- Repeatability: is the underlying task similar enough across jobs that a common method saves effort and reduces errors?
- Decision relevance: does the process produce information or control that someone actually uses to make a decision that matters?
- Proportionality: is the effort proportionate to the size, complexity, risk and reversibility of the work?
A process that fails all three is probably inherited administration rather than useful management. A process that passes only one deserves redesign.
What usually benefits from standardising
Some things are the plumbing of a business. Consistency makes everything else easier:
- Terms and status definitions: what “quoted”, “approved”, “in progress”, “complete” and “at risk” mean.
- Minimum information for a job or project: customer, scope, price, dates, responsible person.
- Escalation paths: who to tell, how quickly, when something goes wrong.
- Decision records: what was decided, by whom, and why.
- Basic financial tracking: budget, cost to date and forecast cost to complete.
- Document naming and version control.
- Roles and approval limits.
- Close-out records: what was delivered and what was learned.
Even here, implementation can scale. A small job might capture all of this on one page, while a large project uses separate documents.
What usually needs judgement
Other things depend heavily on context, and forcing uniformity creates false comparability:
- How customers and stakeholders are engaged.
- How much planning detail is needed.
- How often progress is reported.
- How deeply risks are analysed.
- How much checking and assurance is needed.
- How changes are managed.
A fixed monthly report may be far too slow for a critical, fast-moving job and far too frequent for a stable, low-risk one. A useful rule is to standardise the decision requirement and let the method vary. For example, require every job to show its forecast completion date and cost to complete, but let the size of the job decide how that forecast is prepared.
Minimum sufficiency is an information design problem
The key question for any reporting is: what is the minimum evidence that lets the person above understand whether the work is on track, what has changed and where they need to step in?
That question often simplifies reporting dramatically. A project team may manage hundreds of tasks, but the owner may need only a handful of indicators: forecast completion against commitment, forecast cost against budget, the most important risk, decisions needed and changes since last time. Reporting by exception, highlighting only what is off track or needs a decision, focuses attention where it is needed. Minimum sufficiency is not a fixed number of fields. It is the smallest set that supports the decisions that actually need to be made.
Mandatory core, optional depth
A practical structure is a mandatory core that every job provides, plus optional depth added where size, risk or complexity justify it. For example:
| Job tier (illustrative) | Planning | Reporting | Reviews |
|---|---|---|---|
| Small, routine work | One-page job card | Exceptions only | Close-out note if something went wrong |
| Standard jobs | Job card plus simple schedule | Short fortnightly status | Brief close-out |
| Major or high-risk projects | Full plan, risk register, change log | Weekly status | Start-up review, mid-point review, formal close-out |
The tiers are set by criteria such as value, duration, technical risk, safety risk and customer importance, so the choice is not left to whoever is busiest.
A process value test
Run each mandatory report, form, template and meeting through a few questions:
| Question | If the answer is no |
|---|---|
| Does a named person use the output to make a decision? | Remove or redesign it |
| Does it save duplicated work? | Question why it is centrally required |
| Does it improve comparability or control? | Let teams handle it locally |
| Is the effort proportionate to risk and size? | Scale it to tiers |
| Can the people doing it explain why it exists? | Clarify or remove it |
| Does it reveal problems early? | Add forward-looking content |
Administration has an opportunity cost
Every hour spent producing management information is an hour not spent doing, checking or improving the work. That does not make administration waste. Good records and reporting protect much larger amounts of money and reputation. But it does mean every process should earn its place.
One revealing signal is the shadow system: people keeping their own spreadsheets, notebooks or whiteboards alongside the official process because the official one does not help them run the work. When shadow systems appear, the formal process has usually drifted away from what people need.
Definitions come first
Before changing any template, agree what the business’s common words mean. “Complete” might mean the work is finished, or that it is finished and inspected, or that it is finished, inspected, documented and invoiced. “On track” might mean on schedule, or on schedule and within budget. When different people use different meanings, standard reports produce comparable-looking numbers that are not actually comparable, and decisions are made on a false picture. A single page of agreed definitions, kept where everyone can see it, often improves reporting more than any new template.
Retire processes deliberately
Processes are easy to add and hard to remove. Each was introduced for a reason, often after a specific problem, and removing it feels risky. Build in a habit of review: once or twice a year, list the business’s mandatory processes and ask, for each one, whether it still passes the three tests. Remove or simplify those that do not, and note why, so the decision is not quietly reversed the next time someone feels nervous.
A worked example
This is an illustration. An engineering and fabrication business with 25 staff runs jobs ranging from $2,000 repairs to $400,000 installations. Over the years, it has built up a nine-page job start pack, a weekly status report with 22 fields and a formal close-out report, all required for every job regardless of size.
Its five project managers each spend about three hours a week on reporting, around 15 hours a week in total. The owner’s weekly review meeting runs for 90 minutes and mostly walks through green jobs. Several project managers keep their own spreadsheets because the official report does not show what they need. Problems on two large jobs were reported late, buried among routine updates.
The owner applies the three tests and the process value test with the project managers. They agree:
- Common definitions for “on track”, “at risk” and “complete”, written on one page.
- Three tiers: small jobs under $20,000 use a one-page job card and report only exceptions; standard jobs up to $150,000 use the job card and a fortnightly status with six fields; major jobs keep a full plan and weekly reporting.
- Six core status fields: forecast completion against commitment, forecast cost against budget, the top risk, decisions needed, changes since last report and customer issues.
- An exceptions-first review meeting, starting with jobs that are at risk or need decisions.
After three months, reporting time falls from about 15 hours to about 6 hours a week across the project managers, saving about 9 hours a week. The review meeting shrinks to about 40 minutes and spends most of that time on the three or four jobs that need attention. A cost overrun on a major job is raised in its second week rather than its sixth. The project managers stop maintaining separate spreadsheets for small jobs.
How this applies to a small Australian business
Small businesses often have either too little process, with everything in the owner’s head, or a patchwork of forms added after past problems. Practical steps:
- List every recurring report, form, template and meeting.
- Name the decision each one supports and the person who uses it.
- Agree definitions for common terms before standardising formats.
- Set tiers so small jobs get light process and large or risky ones get more.
- Report by exception wherever possible.
- Watch for shadow systems and ask what they reveal.
- Review processes once or twice a year and retire what no longer helps.
- Keep legal and safety obligations: some records are required by law, contracts or insurers, regardless of their usefulness for management. Check with your adviser before removing any of these.
The articles on building standard operating procedures and running a weekly business review cover related practices.
Signals worth watching
- Reporting effort growing faster than the work.
- The same data entered in several places.
- Completed templates nobody reads.
- Meetings that review everything and decide little.
- Teams asking for exemptions just to work at a normal pace.
- Shadow spreadsheets and whiteboards.
- Problems surfacing late despite extensive reporting.
Positive signals include shorter meetings with clearer decisions, consistent definitions across jobs, fewer disputes about what the numbers mean and earlier warning of problems.
Common mistakes
- Applying the same process to every job regardless of size or risk.
- Standardising formats before agreeing definitions.
- Adding a form after every problem and never removing any.
- Measuring compliance rather than decision quality.
- Reporting everything instead of exceptions.
- Removing records required by law, contract or insurance in the name of simplicity.
Frequently asked questions
Is less process always better? No. Too little process causes errors, rework and dependence on individuals. The goal is enough process for reliable control, scaled to risk.
How do we decide the tiers? Use a few objective criteria, such as job value, duration, safety risk, technical novelty and customer importance. Review the thresholds after a few months.
Where should we start if our processes are already a tangle? Start with definitions and the most frequent reports. Agree what common status words mean, then trim the report that consumes the most hours each week. Early, visible time savings build support for the rest of the review.
What if staff resist simplification? Some people value thorough documentation because it has protected them in the past. Involve them in the review, keep anything with a clear purpose, and test changes for a period before making them permanent.
Questions to ask
- Which of our processes improve a decision or save duplicated work?
- If we had to cut administration by a third, what would we stop?
- Are we standardising definitions, or just layouts?
- Which jobs deserve more than the minimum, and why?
- Where are people keeping their own systems because ours do not help?
- When did we last retire a process?
Bringing it together
Standardisation is valuable because a business should not solve the same administrative problem repeatedly. But judgement cannot be standardised away. Test every process for repeatability, decision relevance and proportion. Standardise definitions, minimum information, escalation and decision records, and let methods vary with context. Design reporting around the minimum evidence a decision needs, structure requirements as a mandatory core with optional depth, watch for shadow systems and retire processes that no longer earn their place. When the process becomes the product, it has crossed from management into bureaucracy.
Source: KEVOS notes, drawing on practitioner guidance on project management offices from Accenture (2017) and the Boston Consulting Group with the Project Management Institute (2013). Examples and figures in this article are illustrations.
