Free, no sign-up needed
12 questions to answer before you brief any software vendor
Most software projects go wrong before anyone writes code — at the point where a business describes what it wants and a vendor hears something slightly different. These are the questions we work through in a process-mapping call. Answer them before you brief anyone, and you will get better proposals, more comparable quotes, and far fewer surprises in month four. Useful whoever you end up hiring.
The operation as it stands today
-
Which single workflow costs you the most time or money right now?
Not "we need a system" — one workflow, named. A vendor who can quote a whole ERP but cannot describe your worst workflow back to you has not understood the job. Starting narrow also gives you something working sooner, which is what convinces the rest of the organization.
-
Who actually does that work, and what do they use to do it?
Names and tools, not job titles. The spreadsheet nobody officially owns, the WhatsApp group where approvals really happen, the personal notebook someone keeps because the software cannot hold that field. This is where the real process lives.
-
What breaks when a specific person is on leave?
Every operation has knowledge held in one head. Naming it turns a risk you carry silently into a requirement you can hand a vendor.
-
Which exceptions happen often enough to matter?
Systems get abandoned because of the edge cases, not the happy path. The rush order that skips two approvals, the client with different payment terms, the site that reports weekly instead of monthly. If these are not in the brief, they will not be in the software.
What "done" means
-
What decision will this system help you make that you cannot make today?
Software is worth building when it changes a decision — what to stock, whom to dispatch, which contract to chase. "Better visibility" is not a decision. Push until you get a sentence with a verb in it.
-
What number should be different six months after go-live?
Days to close the month, percentage of renewals missed, hours spent assembling a report. Write down the current value before you start. Without a baseline you cannot tell whether the project worked, and neither can the vendor.
-
Which reports do you need, and who reads them?
Reporting is usually where scope quietly doubles. Get the actual list early — with a real example of each — rather than discovering it during user acceptance testing.
-
What must this system exchange data with?
Tally, Zoho, a bank portal, a government filing system, an existing website. Every integration is real work and some are not possible at all. Finding out in month one is cheap; finding out in month five is not.
Risk, money and what happens after
-
Who inside your organization owns this project?
Someone has to answer questions, make trade-off calls and chase their own colleagues for information. If nobody has the authority and the time, the project stalls on your side, not the vendor's — and it will still be your money.
-
What happens if the vendor stops halfway?
Ask directly: what do I keep, what do I owe, and can someone else pick this up? You want payment tied to delivered milestones, source code and database ownership in writing, and no licensing arrangement that makes your own system rentable back to you.
-
Who has to change how they work, and what will they say about it?
The most common failure is not technical. It is a team that quietly keeps using the old spreadsheet. Identify those people now, involve them in the mapping, and treat their objections as requirements rather than resistance.
-
What does it cost to keep running once it is live?
Software needs bug fixes, security updates and workflow changes as the operation changes. Get the annual support scope and its cost basis before you sign the build, not after — it is much harder to negotiate once you depend on the system.
If you can answer these twelve, you are ready to brief anyone. If several of them are hard to answer, that is worth knowing too — it usually means the process needs mapping before it needs software.
Want help answering them?
A 45-minute call where we map one of your workflows end to end. You get a one-page summary of what a system would need to do — yours to keep, whether or not we work together.
Book a process-mapping call