Everything starts with the same question: can we understand this well enough to make it better? This page explains what that means in practice — the beliefs, principles and approach that guide everything we do.
Major construction projects are becoming increasingly complex while the people responsible for delivering them are expected to achieve more with fewer resources. Projects generate vast quantities of information, yet many decisions are still made without a complete understanding of what that information is actually saying.
"Can we understand this well enough to make it better?"
The question that shapes every project, every tool and every engagement.Our purpose is not simply to provide commercial resource or to build software. It is to improve the way projects understand themselves. Sometimes that means acting as a commercial manager. Sometimes it means analysing programmes or earthworks. Sometimes it means developing a tool that removes a recurring bottleneck. The method changes. The objective does not.
Neither consultancy nor software exists to sell technology for its own sake. If a spreadsheet is the right answer, we use a spreadsheet. If a workshop solves the problem, we hold a workshop. The choice of tool is always secondary to understanding the problem.
Before suggesting solutions we seek to understand how the project was intended to operate, how it is actually operating and why those two positions differ. Better recommendations come from better understanding.
Rather than focusing solely on commercial, planning or operational issues in isolation, we look for the relationships between them. A programme delay may have its origins in design. Poor productivity may be linked to estimating assumptions. Understanding those relationships is often where the greatest value is created.
Projects succeed when people understand how different parts of the system influence one another. Every recommendation, product and engagement should connect disciplines together, not reinforce their separation.
Our experience spans real projects, not research papers. Recommendations and tools are grounded in what actually works in the field, not in what sounds good in a boardroom.
Too many organisations begin with software and then search for a problem that justifies its use. We begin with the problem. Every tool has genuine strengths and real limitations — our responsibility is to explain both honestly.
We aim to be practical rather than promotional. Construction is full of exaggerated claims and promises of transformation. Our credibility comes from experience and evidence, not from marketing language. We would rather explain a genuine problem clearly than claim to have revolutionised the industry.
Our communications should always begin with a problem that clients recognise — not with a product or feature. We write as experienced practitioners speaking to other experienced practitioners, respecting the reader's knowledge rather than trying to impress them.
A useful test: does it sound like a conversation with Colin over a coffee after a project meeting? Is it practical, honest and thoughtful? Does it leave the reader with a new way of looking at a familiar problem?
Before publishing content, building a feature, or accepting a commission, we ask six questions.