Small businesses tend to treat formal project methods in one of two ways. Most ignore them as paperwork for big organisations. A few send someone on a certification course and come back determined to apply the whole method, complete with documents, boards and reports that nobody in a 20-person business has time for. Both miss the useful middle: a handful of ideas from these methods do most of the work, cost very little and prevent the mistakes small businesses make most often on projects.
The two best-known methods come from different places and solve different problems. The PMBOK Guide, published by the Project Management Institute, grew up as a body of knowledge for project managers: the tools and practices for planning, estimating, scheduling, managing risk and leading a team. PRINCE2, which began in the UK public sector, focuses on the organisation’s control of a project: who decides, when they decide, how much freedom the people doing the work have, and how a project proves it is still worth doing. One equips the person running the project; the other equips the people who own it. Most small business projects need a little of both.
This article explains the core ideas from each method that suit a small business, how to keep them light, where formal methods go wrong in practice, and a minimal set of habits that covers most projects. It is general information. PRINCE2® and PMBOK® are registered trade marks of their respective owners, and this article is an independent explanation of publicly described ideas, not training in either method.
Two methods, two problems
| PMBOK Guide | PRINCE2 | |
|---|---|---|
| Origin | Project Management Institute (United States) | UK government, now maintained commercially |
| Main focus | The project manager’s knowledge and practices | The organisation’s governance and control |
| Strengths | Estimating, scheduling, risk, stakeholders, team leadership | Roles, stages, decision points, tolerances, business justification |
| Typical gap | Less explicit about who decides above the project | Less detail on techniques for doing the work |
Recent editions of the PMBOK Guide moved away from a fixed set of processes towards principles and broad areas of performance, such as stakeholders, team, planning, delivery, measurement and uncertainty, and they encourage tailoring. PRINCE2 is built around a set of principles, a set of management themes or practices, and a set of processes from start-up to closure, with tailoring as one of its principles. Neither expects to be applied in full on a small project.
Seven PRINCE2 principles as small business habits
PRINCE2’s seven principles translate well into plain habits:
- Continued business justification. Check at each decision point whether the project is still worth doing, not just whether it is on track.
- Learn from experience. Look for lessons from past projects at the start, record them during the work and pass them on at the end.
- Defined roles and responsibilities. Everyone knows who decides, who does the work and who represents the people who will use the result.
- Manage by stages. Break the project into stages, and decide at the end of each whether to continue, based on what you now know.
- Manage by exception. Agree limits, called tolerances, on time, cost and other factors. Within them, the project lead gets on with it; outside them, the decision comes back up.
- Focus on products. Define what will be delivered and how you will know it is acceptable, before working out the tasks.
- Tailor to suit the project. Scale the method to the size, risk and complexity of the work.
None of these needs a large organisation. All of them address common small-business failures: projects that continue after they have stopped making sense, owners drawn into every small decision, deliverables nobody defined, and arguments at the end about whether the work is finished.
What to borrow from the PMBOK Guide
The PMBOK Guide’s value for a small business lies in practical techniques:
- Estimating from defined work packages and past data rather than a single guess.
- Scheduling that shows dependencies and the chain of work that controls the finish date.
- Risk management that identifies, assesses and responds to risks, and reviews them regularly.
- Stakeholder engagement that identifies who is affected and plans how to involve them.
- Quality planning that agrees standards and checks before work starts.
- Team leadership, including clear roles and how the team will communicate.
Its newer emphasis on principles such as stewardship, value, systems thinking and adaptability is a useful reminder that technique serves judgement. The project management basics for small businesses article covers the core techniques at small-business scale.
Stages and phases are different things
One distinction from PRINCE2 is especially useful. Technical phases describe the work: design, build, test, install. Management stages describe decision points: the moments when the owner reviews progress and decides whether, and how, to continue. They often line up, but not always. A design phase might contain a decision point halfway, after a prototype; installation and commissioning might sit inside one management stage.
Placing decision points where the most important uncertainty is resolved, rather than simply at the end of each phase, makes them far more valuable. The learn before you commit article covers timing decisions so new information arrives before the point of no return.
Tolerances: freedom with limits
Tolerances turn delegation into something concrete. For each stage, agree how far time, cost and scope can move before the project lead must escalate, and consider quality, risk and benefits too. For example: “this stage may run up to 10% over budget or two weeks late; any change to what the customer receives comes back to the owner”. Inside the tolerances, the project lead decides. If a forecast shows a tolerance will be exceeded, the lead raises it early with options, rather than at the end with an apology.
Handle changes and issues deliberately
Both methods treat change as something to be managed rather than resisted. A simple version for a small business: keep one log of issues and requested changes; for each, note what it would do to time, cost, quality and the outcome; and decide according to the tolerances. Small changes inside tolerance are the project lead’s call; larger ones go to the owner with options and a recommendation. Keep the agreed version of key documents, such as the brief, designs and plans, clearly marked, so everyone works from the same version. Most project arguments about scope come from changes that were agreed informally and never recorded.
A minimal method for a small business
For most small business projects, a light version covers what matters:
- A one-page brief: why the project is worth doing, the outcome, what will be delivered and how it will be accepted, and what is out of scope.
- Three named roles: the owner who decides and is accountable for the outcome; someone representing the people who will use the result; and someone representing the people or suppliers doing the work. In a small business, one person may cover more than one role, but the perspectives should all be present.
- Two to four stages, each ending with a short decision: continue, change or stop.
- Tolerances for each stage, written down.
- A short exception note when a tolerance is forecast to be exceeded: what happened, the options and a recommendation.
- A lessons log, started at the beginning, not the end.
- A closing check: the products accepted, outstanding actions handed to someone, and the results reviewed after use.
Where formal methods go wrong
- Adopting the documents, not the logic. Templates are filled in while the decisions they are meant to support are never made.
- Treating certification as competence. Knowing a method’s vocabulary is not the same as judgement.
- Applying one size to everything. The same heavy process on a two-week task and a year-long investment wastes time on one and may under-control the other.
- Tailoring by deletion. Removing documents is not tailoring if the decisions and controls they supported also disappear. Tailor the information, not the accountability. The read the constraints, then tailor the method article covers tailoring well.
- Tribalism. Arguing about which method is best misses that they address different problems.
A worked example
This is an illustration. A 30-person food distributor plans to launch a refrigerated delivery service for restaurants, needing two refrigerated vans, temperature monitoring and new delivery procedures. Previous projects had drifted: the owner made every decision, and the last one ran four months late with nobody sure when it had started going wrong.
The operations manager, who has some PRINCE2 training, proposes a light approach.
Brief. One page: the outcome is a reliable chilled delivery service that meets restaurant customers’ temperature requirements; the products are two equipped vans, a temperature-logging system, written procedures and trained drivers. Acceptance criteria include temperature logs that stay within the customers’ required range across a two-week trial.
Roles. The owner decides and owns the business case. The delivery supervisor represents the drivers and customers who will use the service. The refrigeration contractor’s project lead represents the suppliers. The operations manager runs the project day to day.
Stages. Three: design and supplier selection; a pilot on one route; rollout to all routes. Each ends with a 30-minute decision meeting.
Tolerances. Each stage may run up to 10% over its budget or two weeks late. The temperature requirement cannot be traded at all. Any change to which customers are served comes back to the owner.
Exception. In stage one, the van supplier announces a six-week delay. Because that breaks the time tolerance, the operations manager brings the owner three options: wait, hire two refrigerated vans for the pilot, or switch suppliers. The owner chooses to hire vans for the pilot, so the pilot can start on time while the owned vans are built.
Closing. After rollout, the delivery supervisor confirms acceptance against the temperature criteria, outstanding actions go to the delivery team, and the lessons log records that hiring equipment for a pilot is a useful way to keep projects moving.
The project finishes three weeks later than first planned, inside its overall tolerance, and the owner was involved in two decisions rather than twenty.
How this applies to a small Australian business
- Borrow principles, not paperwork.
- Write a one-page brief with acceptance criteria.
- Name the decision-maker, the user voice and the supplier voice.
- Break work into stages with real decisions at the end of each.
- Set tolerances and let the project lead work within them.
- Use PMBOK techniques for estimating, scheduling and risk where they help.
- Keep a lessons log from the start.
- Scale the approach to the size and risk of each project.
Signals worth watching
- The owner involved in every project decision.
- Deliverables described as tasks with no acceptance criteria.
- Projects that never formally stop or close.
- Templates completed with nobody reading them.
- Problems reported only after deadlines are missed.
- The same method applied to every project, large or small.
- Changes agreed in conversation and never written down.
Common mistakes
- Rejecting formal methods entirely.
- Adopting a method in full on small projects.
- Confusing technical phases with decision stages.
- Delegating without tolerances.
- Tailoring by deleting controls.
- Treating training as a substitute for judgement.
- Agreeing changes informally without recording their effect.
Frequently asked questions
Should someone in our business get certified? It can help, especially for a person who will run many projects, but the value comes from applying the ideas sensibly, not from the certificate.
Which method should we follow? Neither in full. Use PRINCE2’s ideas for who decides and when, and PMBOK techniques for doing the work.
How does this fit with agile approaches? Comfortably. Stages, tolerances and business justification can sit above short, iterative work cycles.
How much documentation is enough? Enough that someone else could understand what was decided, why and by whom. For most small projects, a few pages.
What is a project board in a small business? Often just two or three people meeting briefly at each decision point: the owner, someone speaking for the users and someone speaking for the suppliers. What matters is that these views are heard before decisions, not that a formal committee exists.
Do these ideas apply to client projects as well as internal ones? Yes. Clear acceptance criteria, staged decisions and tolerances are just as valuable on work for customers.
Questions to ask
- Is this project still worth doing, and when did we last check?
- Who decides, who uses the result and who supplies the work?
- What will we deliver, and how will we know it is acceptable?
- Where are our decision points, and what will each decide?
- What tolerances has the project lead been given?
- What did our last project teach us that applies here?
Bringing it together
Formal project methods hold ideas that suit any business. From PRINCE2, borrow the principles: keep checking the project is worth doing, define roles, manage by stages and by exception, focus on what will be delivered and tailor to the project. From the PMBOK Guide, borrow techniques for estimating, scheduling, risk and stakeholders. Keep it light: a one-page brief, named roles, a few stages, written tolerances and a lessons log. Use the logic, not the paperwork, and scale it to each project.
Source: KEVOS notes, drawing on earlier KEVOS handbooks comparing the PMBOK Guide and PRINCE2, covering PRINCE2’s principles, themes, processes and tailoring, and the PMBOK Guide’s principles and performance domains. Examples in this article are illustrations. This article is general information and is not affiliated with or endorsed by the owners of PRINCE2 or the PMBOK Guide.
