Guide

How we scope a project, and why we sometimes say no

6 min readEngineering

Every engagement starts with a scoping conversation. It is free, it takes about an hour, and a fair proportion of them end with us saying we are not the right firm for the work.

What we are actually trying to establish

Three things. What problem this solves and for whom. What has already been tried and why it did not hold. And what would make the project a failure, which is consistently more revealing than asking what success looks like.

That last question surfaces the constraints that would otherwise appear in month three: a launch date tied to a conference, a regulator conversation already in the diary, a system nobody is permitted to modify.

Estimates are ranges, and the range is the information

A single number is almost always false precision. We give a range and say plainly what would push the estimate toward each end. If the range comes out uncomfortably wide, that is telling you the problem is not yet understood well enough for either of us to commit. Useful information, not an evasion.

When we say no

We say no when the work needs deep domain expertise we do not have, when the timeline cannot be met without producing something we would not want our name on, or when the thing being described would be better solved by configuring an existing product than by building anything at all.

That last one comes up more often than you would expect. Telling somebody not to build software is occasionally the most useful thing a software company can do for them.

What you leave with

A clear view of the approach, a range rather than a number, and the main risks named out loud. If we do proceed, none of it should come as a surprise in month four.

Written by the Prakmas team, Hyderabad and Union City.

All insights
Next step

Want to talk this through for your own system?

A scoping conversation costs nothing and ends with a clear view of approach, a range rather than a number, and the main risks named out loud.