In this guide 6 sections
Before starting, name the business problem and its accountable person, and ask who will use the system, where the data lives and which tools it must work beside. Settle budget and deadline assumptions, agree who owns the system after launch, and turn the honest answers into a one-page go or no-go brief.
The business problem and its sponsor
Start with the problem, not software. Which specific business problem is this meant to solve, and who in the business is accountable for solving it by a named date? A project with a clear problem and no accountable sponsor loses momentum the first time it competes with something more urgent, such as a late shipment or month-end close. Sponsors keep projects alive.
Check whether the problem is real. “A competitor has an app” is not the same as “customers keep asking for something we cannot provide”, and the two lead to very different projects. One is a response to evidence from your own order book or support inbox, and the other is a guess dressed up as urgency with a budget attached. Ask for the evidence.
Write the sponsor’s name down. A named person who will attend the reviews and tell colleagues no when they ask for extras is worth more than a committee that shares the interest. Committees tend to drift.
Users, data and the tools already in place
Who will use this every day? Ask how comfortable they are with new tools, because a system designed for confident users struggles with a team that is not, however well it is built. Then ask where the data will come from, what condition it is in, and who is responsible for getting it clean before go-live. Dirty data delays launches.
List every tool already in use. Include minor ones, such as an accounting package, a chat ordering habit and a supplier’s portal, because the new system must sit beside all of them. Systems that ignore what is already in daily use get worked around rather than adopted, and the old spreadsheet quietly survives next to the expensive new platform. Adoption is the real test.
Spend an hour with users. Watching a dispatcher or a counter clerk work for an hour exposes shortcuts, workarounds and paper notes that no interview will ever mention, and each one is a requirement. Watching beats asking alone.
Budget, timing and scope assumptions
Put a budget range on the table. Even a rough range shapes every later decision, including custom versus packaged, how many features fit in a first release, and whether to phase the work. Projects that skip this step discover the real budget only when a quote arrives, after everyone has spent weeks comparing options that were never affordable. Awkward now, cheaper later.
Treat timing the same way. Is there a real external deadline, such as a licence expiring, a seasonal peak or a contractual commitment, or is the date merely aspirational? The two call for very different urgency and tolerance for risk, because a real deadline justifies a smaller first release while an aspirational one rarely justifies cutting corners. Name the date’s source.
Separate must-have from nice-to-have. Ask which three features would make the project worthwhile if everything else were dropped, because a team that cannot name three is not ready for a quote. Short lists clarify scope.
Ownership and support after launch
Planning often stops at launch day. Decide now who owns the system afterward: who fixes a bug, who trains a new hire and who approves the next round of changes. Decide also whether that is an internal role or an ongoing arrangement with the builder, and write the answer into the brief before any contract exists. Name a person, not a team.
Raising this early feels awkward. It sounds like planning for failure before the project has started, but agreeing it upfront is what stops the system being abandoned six months after launch. Nobody should discover during a Monday-morning outage that the person who built the system left the business, and that nobody else holds the passwords. Ownership is a launch task.
A go or no-go brief from the answers
Consider a wholesale distributor. A vendor offers a custom CRM after a chance chat at a trade event, and the owner works through these questions first. The sponsor turns out to be the owner alone, sales staff doubt there is a problem, the budget is undefined, and nobody has considered support after launch. That is a clear result.
Write the answers as a one-page brief. Those honest answers are the decision, and they are not a reason to drop the idea but a list of what to resolve first. Here the list is a conversation with the sales team, a defined budget and a support plan, and a vendor worth hiring will welcome that brief. Go, wait or stop.
Keep the brief to one page. List the problem, the sponsor, the users, the data position, the budget range, the deadline and the support owner, each with a one-line answer and a confidence note.
Project-start questionnaire
A one-page questionnaire covering the sponsor, daily users, data readiness, existing systems, budget range, deadline source and post-launch ownership. Fill it in honestly, with the sales and operations leads present, before any vendor conversation begins.
Open a blank worksheet to printQuestions owners ask
What if requirements are unclear?
Unclear requirements are normal at this stage, and these questions exist to surface what is unclear before money is committed rather than to demand a finished specification. Discovery fills the gaps.
Which questions should vendors answer?
Vendors should say how they handle unclear or changing requirements, what their testing and support process looks like, and which party holds the code and data after delivery. Those answers predict the relationship.
Who should answer these questions?
The sponsor and the people who run the process daily should answer together, because an owner answering alone tends to miss the users’ objections. Objections are cheap now.