The First Conversation

Start from the process, not the technology

The useful first document describes what happens today, who does it, how long it takes and where it goes wrong. It should read sensibly without mentioning any technology at all.

If the document only makes sense with the word software in it, you are starting from the solution rather than the problem, and that is how projects go wrong.

Four things to prepare

1. The process, step by step, from whoever performs it
2. The cost — frequency, duration, who does it
3. Thirty real examples, including the awkward ones
4. Your systems — named, with whether they have APIs

With those four, any competent supplier can give you a real estimate. Without them, every estimate is a guess.

Include the exceptions

• What happens when something is rejected or returned
• Who can override, and when
• What happens at month end
• The one-off cases everyone knows about
• The steps nobody mentions because they are obvious

Exceptions are where the complexity lives. A description covering only the normal path produces an estimate for something that cannot handle real work.

Then decide what success means

A stated measure makes the project accountable and frequently changes what gets built.

The conversation is free

Bring those four things and you will get a straight answer, including whether the honest answer is that building is not worth it.

A clear written scope is worth having whoever eventually builds it, and it is yours either way.

Frequently asked questions