Projects We Say No To, and Why

Saying no is the useful part of advice

A supplier who agrees with everything is selling scope. The projects we decline are the ones that would have ended badly, and those are the ones everybody remembers.

Check yours against these five before commissioning anything, from us or anyone.

1. The process is still changing

If the team is still arguing about how something should work, encoding one version in software makes the argument more expensive and slower to resolve.

Run it manually until it settles for a few months, then automate what survived. The delay costs less than building twice.

2. The volume does not justify it

Automating a task done four times a week rarely pays back however irritating it is. Emotional cost and financial cost are different things.

Hours saved a year, times a fully-loaded rate, against build plus three years of maintenance. If that arithmetic does not work, we will show you the sum rather than the proposal.

3. Nobody will own it

Custom software needs someone who handles questions, decides on changes and notices when it drifts from what the business needs. Without one it degrades quietly and is abandoned within two years.

If you cannot name that person before we start, that is the finding.

4. An off-the-shelf product does 80% of it

Spending five figures to gain the last 20%, and owning the maintenance forever, is rarely the better deal — unless that 20% is the part that makes you money.

Automating your differentiator is worth building. Automating something everyone does is worth buying.

5. The real problem is organisational

• “Nobody updates the system” is usually about incentives
• “Departments have different numbers” is usually about definitions
• “Approvals take weeks” is usually about authority

Software will not fix any of those, and building around them produces an expensive record of the dysfunction.

Frequently asked questions