The projects wesay no to,and why

The first conversation tells you most of what you need. If every question comes back as "I will have to check", and the person who would be checking has never been named, the project does not have a decision maker — it has a messenger.

This is not about seniority. We have run excellent projects with a single operations manager who had real authority over their own area, and painful ones with a committee of directors who had none over each other. The question is whether one named person can change how their own team works without convening anybody.

Without that, every disagreement escalates, nothing gets cut, and the scope only ever grows. The project does not fail loudly; it just never finishes.

There is a specific shape of project where the deadline arrived before the requirements: a trade show, a funding milestone, the end of a financial year, a contract that expires. The date is real and immovable, and the scope was reverse-engineered from it rather than the other way round.

Sometimes that is workable, if everyone accepts that the scope is the variable. It becomes a no when the date is fixed, the scope is fixed, and the only remaining variable is quality — which means it is our quality, and our name on it.

The honest response is to offer what genuinely fits the date, in writing, and let the client decide. About half the time that conversation turns into a better project. The other half it ends, which is also a good outcome.

"We want to rebuild it, it is old" is not a reason, it is a feeling. Sometimes there is a real one underneath — nobody can change it safely, it cannot do a thing the business now needs, the people who understood it have left, the platform is going out of support. Those are reasons, and rebuilds driven by them usually go well.

When the only driver is that the stack is unfashionable, the rebuild tends to recreate every behaviour of the old system plus a new set of bugs, at considerable expense, and nobody can say afterwards what improved. We would rather spend six weeks making the existing thing safe to change than nine months reproducing it.

We ask one question: what will someone be able to do after this that they cannot do now? If the answer is about the codebase rather than the business, it is a no, or at least a different project.

Any project that involves existing data, we ask to see a real extract early — not a schema, not a description, an extract. If the answer is that it will be available later, or that it needs cleaning first, that is the project.

Old data is never as described. There are records with no owner, three date formats, a status code retired years ago that still appears thousands of times, and a free-text field an entire department has been using as a structured one. None of that is in the documentation, because none of it was decided. It accumulated.

Taking a fixed-scope project without having looked at the data is taking a fixed-scope project with an unknown attached. We are happy to do the looking as a paid first phase. We are not happy to price around it.

Occasionally the first conversation is mostly about what happens if we fail — penalty clauses, ownership of work in progress, approval gates on individual commits. Caution is fair and we have no problem with a proper contract. But when the shape of the engagement is designed around the assumption that we will behave badly, the project is going to be run that way too.

Those projects consume senior attention far out of proportion to their size, because every ordinary decision becomes a negotiation. Meanwhile the work that would actually reduce the client's risk — early slices, visible progress, honest reporting — is crowded out by the process built to manage distrust.

The tell is usually that they were burned before. That is a real wound and it deserves sympathy. It is also, in our experience, not something a new vendor can heal inside one engagement.

Some projects would leave the client dependent on us permanently: an unusual stack nobody local hires for, a system only we can operate, an architecture nobody on their side can reason about. That is good for short-term revenue and bad for everything else.

It is bad for them because the cost of leaving us becomes the main feature of the system. It is bad for us because the relationship stops being chosen and starts being endured, and those relationships end badly even when the software works.

So we ask who maintains this in two years. If there is no credible answer that does not involve us forever, we either change the approach until there is one, or we pass.

The last one is the simplest and the least commercial. Some projects are competent work in service of something we would not want attached to our name. There is no framework for this and no scoring matrix. Six people decide, and one strong objection is enough.

The reason this is written down is that it is easiest to abandon when the quarter is thin. That is exactly when it matters — a line that only holds when business is good is not a line, it is a preference.

It costs money, immediately and visibly. It costs an awkward conversation and sometimes a referral that does not come. Those are real and we do not pretend otherwise.

What it buys is a team that is not demoralised by work it cannot do well, capacity available for the project that turns up a month later, and a body of work that is representative rather than apologetic. In a studio of six, one bad engagement is a sixth of everything — the arithmetic is simply less forgiving than it is at scale.

The uncomfortable call in week zero is always cheaper than the one in month five. That is the whole argument.