Many software projects begin with a sentence like “We want an app” or “We need a sales system,” and the conversation moves straight to screens, technologies, and prices. Halfway through, questions come up that should have been asked at the start, so stages slip, costs rise, and each side starts reading the agreement in its own way.
The five questions below are for the business owner to answer, not the developer, and they can be answered before you contact any software vendor. They don’t call for technical knowledge, only knowledge of your business and some quiet time with the people who know its day-to-day details.
Why projects start in the wrong place
When a business owner asks for a quote before defining what they want, each vendor fills the gap with its own assumptions. The quotes that come back can’t be compared: one assumes a small system for a single branch, and another assumes connections to accounting, the warehouse, and every branch.
And the problem doesn’t stop at the quotes. During implementation, unwritten assumptions turn into change requests, and every change request means time, cost, and a debate over what was “implicitly understood.” Answering a few questions in advance narrows this gray area before it becomes a dispute.
Besides, the vendor that builds the system doesn’t know your business the way you do. What seems obvious to you about the order cycle or approving discounts may not occur to them unless it’s written down.
The five questions
What exactly is the problem we are solving?
“We want an app” describes a proposed solution, not a problem. A problem is written in business terms: orders get lost between branches, invoices are delayed, or customers don’t know the status of their order. Once the problem is stated clearly, every proposed solution has one yardstick: whether it addresses the problem or not.
A good answer is short and specific, and it names the problem’s effect on the business, not on the tools. Suppose a distribution company says, “We need an app for our sales reps,” and on closer questioning it turns out that orders reach the warehouse through scattered calls and messages, so some ship incomplete and some are delayed by a whole day.
That is a statement you can build on, because it describes what happens, not what someone wants to buy. While writing it, you may discover that part of the problem can be solved by changing a procedure before any development.
Who will use the system, and how do they work today?
Every user has a different working day: the receptionist, the accountant, the field sales rep, and the manager. A system designed for one role that ignores the others is only partly used, and the side spreadsheets come back to fill the gap.
A good answer describes how each role gets its work done today, including workarounds such as WhatsApp groups and side Excel sheets, because these workarounds reveal real requirements that don’t show up in official procedures. Don’t overlook the working conditions themselves either: whether the sales rep works from a phone in the field, and whether an internet connection is always available at the branches.
Suppose the company’s accountant keeps a private spreadsheet to reconcile payments with invoices every evening. That spreadsheet doesn’t appear in any official description of the work, but it is a clear requirement: the new system must make reconciliation possible without it.
What must work in the first phase?
Not everything you want is needed in the first release. Every extra item lengthens the road to the first real use, and it postpones the moment your team judges the system by working with it rather than by watching a demo.
A good answer splits the requirements in two: what you can’t launch without, and what can wait. The question that settles the split is simple: does day-to-day work stop if this item is missing?
Suppose the company wants order entry, shipment tracking, detailed sales reports, and a customer loyalty program. Order entry and shipment tracking are indispensable, while the detailed reports and the loyalty program can wait until use settles in and the need for them becomes clear.
How will we know the project has succeeded?
Without an agreed measure, judging the project comes down to impressions that vary from person to person. The manager considers the system a success, the accountant thinks it added steps, and neither has anything to settle the debate.
A good answer sets one or two measures that can be observed in the work: the time it takes to prepare the monthly report, the number of orders that need manual follow-up, or the discrepancies a stocktake reveals. It also records their current value before the work begins, because without a baseline no improvement can be measured.
Suppose preparing the monthly sales report currently takes two working days of gathering and correcting spreadsheets. The measure of success here is clear: the report comes straight out of the system, and its figures match the accounts without manual adjustment.
Who decides on our side?
Every software project needs someone on the business owner’s side with the authority to settle questions and approve each phase. When decisions are spread among several people with no clear point of reference, reviews are delayed and change requests pile up.
A good answer names one person, defines what they decide alone and what they escalate to management, and gives them real time for the project, not whatever is left of their day. Suppose the operations manager is the decision-maker: they approve the business rules and the priorities of the first phase, and escalate to the general manager only what changes the budget or the deadline.
It also helps to name a deputy, so the project doesn’t stall when the decision-maker is away traveling or tied up with something urgent.
Turn the answers into a one-page document
Gather your answers in a short document that you share with every vendor you ask for a quote. The document makes the quotes comparable, because everyone starts from the same understanding, and it quickly shows which vendors ask about your business and which ones only talk about technology.
The document doesn’t need a special template or technical language. It only needs to include:
- A description of the problem in business terms, in one paragraph.
- The users and their roles, and how they work today.
- What the first phase must include, and what can be postponed.
- The agreed measure of success, and its current value.
- The decision-maker, and who reviews each phase.
- Known constraints: the required deadline, the approximate budget, and the existing systems it must connect to.
Write it in language a new employee at your company would understand. If a reader needs a verbal explanation to understand it, it needs a clearer paragraph, not more pages. Attach real samples if you have any, such as an invoice, a tracking sheet, or a paper order form, after hiding anything confidential.
A checklist before you ask for a quote
- The problem is written in business terms, without naming a technology or a type of app.
- Every role that will use the system is listed, along with how it works today.
- Current workarounds, such as spreadsheets and messaging groups, are known and recorded.
- First-phase items are kept separate from the items that wait.
- The measure of success is defined, and its current value is recorded.
- The decision-maker is named, and their time for the project is agreed.
- Known constraints are written down, and so is what you don’t know yet.
From the document to the discovery session
The answers don’t have to be complete or final; it’s enough that they are candid and show what you don’t know yet. The document is a starting point for the conversation, not a substitute for it.
At ITS, we start every project with business analysis before development, and the first step is the discovery session. In it, we review the answers with the people who know the work, ask about the exceptions and cases that don’t appear in the first description, and then turn what we agree on into a written scope that can be estimated and implemented.
A project that starts with a clear question about the business is less prone to disputes than one that starts with a list of screens.
The five questions don’t guarantee a project’s success, but before the project starts, they address recurring reasons projects stumble: a vague problem, overlooked users, scope creep, no measure of success, and scattered decision-making. If you want to review your answers, you can discuss your situation with the ITS team, looking at the business before the technology.
Related serviceBusiness analysis and product consulting