Most growing firms cannot say how many projects they have in flight, or what a week of delay costs on the biggest one. Both numbers belong in the 2027 plan, writes Dr Albert Ponsteen.
Ask the owner of a growing engineering or manufacturing business two questions. How many projects are you running right now? And what does one week of delay cost on the most important of them? The first answer is usually too low. The second rarely comes at all. Yet November is when most small and mid-sized firms sign next year’s plan: the customer commitments, the hires, the budget for new software and AI. Every line of it is a bet on weeks nobody has priced.
Hiring will not cover the gap. In the British Chambers of Commerce’s Quarterly Recruitment Outlook published in July, 73 per cent of firms trying to recruit reported difficulties, and 92 per cent of the more than 4,700 respondents were SMEs. So when delivery starts to slip, owners reach for the other levers: a planning spreadsheet that grows a new tab every month, or a shortlist of PMO tools. Both can help. Neither can rank a list nobody has written down, or tell you which late week costs money and which costs nothing.
The list nobody has written down
In a business of 50 or 200 people, projects rarely start with a decision. They start in a sales call, an email, a “while you’re at it” in the corridor. None of them is refused, because each one is small and reasonable on its own. The load is real, but it has never been added up in one place. Ask three directors how busy the team is and you get three different guesses.
That is why priority exercises in smaller firms so often go nowhere. A confident ranking of an unknown list cannot be proved wrong until the deadlines start to slip. So count first. Write down every piece of work in flight as a project, however small, with a rough number of hours for the team it needs. Then set the total against what that team can actually give. The total usually settles the argument on its own.
23 projects, all priority one
I saw this at full strength during my PhD research, in the engineering department of a mid-sized manufacturer. Its engineers were working on 23 projects at once and told me they “don’t get anything done”. One group of seven engineers, about five full-time equivalents of real capacity, had twice as much work as it could do.
I asked the chief executive for the priority of each project. All 23, he said, were priority one. A week later he came back with a list ranked 1 to 23 by what each project would bring the company, and he backed it. Projects that had not started waited their turn. Each engineer worked on one project at a time instead of five. Nothing was dropped and nobody was hired.
Within five weeks the overload had gone and the team’s output had doubled. The most valuable projects were delivered first, and much earlier than when everything ran in parallel. The team had never been short of people. It had been short of one decision. Saying yes to a project commits the money. Deciding when it starts commits the people, and that second decision is the one most firms never take on purpose.
Not every week costs the same
Once the list exists, put a price on the weeks. On some projects a week of slip costs nothing: the customer date has slack, or the next stage is not ready anyway. On others it costs real money. A contract that earns £20,000 a month in margin loses around £4,600 for every week it finishes late. In a small business that week is also late cash, because the final invoice, the stage payment and the next job all move with the finish date.
The cost rarely climbs in a straight line, either. Miss a customer’s installation window or a seasonal launch, and one late week becomes a lost quarter.
The expensive weeks also gather in one place. In most growing firms they queue in front of the same two or three people: the senior design engineer, the estimator, the one person who signs off quality. In many smaller firms, one of those names belongs to the owner. When those people are overloaded, everything behind them waits, and the waiting is where the money goes.
Spend where the week is expensive
The same logic should shape the 2027 budget. A new hire, a subcontractor or an AI tool pays back only if it sits in front of an expensive week. Speeding up a team that nobody is waiting for just adds to the pile in front of the team everyone is waiting for.
Most SMEs will be sold some form of AI this winter. Before buying, ask three questions about the work you plan to hand over. Is anything waiting on it? Does the wait cost real money? Can a machine do it well? If the first two answers are no, the tool may still save time, but no customer will receive anything sooner and no invoice will go out earlier.
Three numbers before you sign 2027
Most 2027 plans quietly assume unlimited people. Next year will not provide them. Before the plan is signed, make sure it rests on three numbers.
How many projects are in flight? All of them, including the ones that started in a conversation.
Whose time do they wait for? Name the people, not the departments. The list is usually short.
What does a week cost on the projects that matter most? Use figures the business already holds: margin per month, payment milestones, penalty clauses, the next job that cannot start until this one ends. A rough figure in pounds is enough to begin.
Then rank the projects once, from first to last, and start only as many at a time as those few people can carry. The rest wait their turn on the list, not in someone’s inbox. With a dozen projects, a spreadsheet will do. With dozens sharing the same people, every start date moves the others, and that is where planning software starts to earn its keep.
An overloaded team is usually a decision nobody took. Count the work, price the week and take that decision before 2027 is signed, not after the first deadline slips.
Dr Albert Ponsteen is CEO of Epicflow, a project portfolio platform that engineering firms such as Blueprint Automation and Rondal use to plan their projects and people. His PhD research at the Open Universiteit examined resource allocation in multi-project environments.
