Most failed software projects were already in trouble at the kickoff meeting. Here is the short list of things we check before we say yes.
We turn down roughly one project in five, and almost always for the same handful of reasons. None of them are technical.
Is there a person who can decide?
Software work generates a decision a day. If every one of them has to go to a committee, the project will not fail dramatically — it will just take three times as long and cost three times as much. We ask for one named person who can settle a question inside 24 hours.
Can we talk to the people who will use it?
Not their manager, not a summary of their feedback. Half an hour with three actual users tells us more than a fifty-page specification, and it usually contradicts it.
Is there a first release worth shipping?
If nothing useful can go live in twelve weeks, the scope is wrong. Every project we have seen run past a year without a release ended up rebuilt anyway.
What happens if we are late?
We ask this out loud. If the honest answer is "a regulator fines us", the plan needs contingency we would not otherwise build in — and you deserve to know that before signing.
None of this is gatekeeping. It is the same conversation we would want on the other side of the table.
