A company decides to replace a spreadsheet with a small custom application. The owner writes a long email, the supplier sends a quote, and three weeks into the project the person who actually does the work says, "But we never do it like that." The email was not wrong. It simply described one person's view of the work.
A short, well-run workshop fixes most of this. This article is for an owner or operations manager who is preparing a software project and wants to give a supplier, internal or external, a clear starting point. Two hours is enough for a small project. It is not a replacement for a full requirements document, but it produces the page from which a good document grows.
Who attends
Keep the group to four to six people. More voices do not mean better requirements; they mean slower decisions and quieter users.
- The sponsor. The person who pays and decides priorities. They settle disputes about what matters most.
- Two or three people who will use the system daily. Not their manager, the people who actually enter the data and answer the customer. Pick people from different roles if the work is split.
- One person who knows the data and the systems around it. Often someone in finance, the office or IT. They know where the numbers live today and which tools must keep working.
- A facilitator. Someone who asks questions and writes, and does not defend a solution. If the supplier facilitates, they should say so and stay neutral on technology.
Send a short invitation a few days before: the goal, the agenda and one request, "Bring two real examples of the work, such as a recent order or a recent mistake." Real examples are the most useful material in the room.
A simple agenda
| Time | Topic | Result |
|---|---|---|
| 0:00–0:10 | Goal and ground rules | Everyone agrees what the project is for |
| 0:10–0:50 | Walk through work as it happens today | A rough sequence of steps on a wall or shared page |
| 0:50–1:20 | Problems and wishes | A list of pain points, sorted by how often and how costly |
| 1:20–1:40 | Must-have, nice-to-have, not now | A first cut of scope |
| 1:40–2:00 | Open questions and next steps | Owners and dates |
Put the clock where everyone can see it. If a topic runs over, park it in the open questions rather than steal time from the next block.
What to ask the users
Ask about the work, not about the software. People who are asked "What features do you want?" describe what they have seen elsewhere. People who are asked to describe last Tuesday describe what they need.
- "Walk me through the last order (or request, or job) from start to finish." Let them use the real example they brought.
- "Where do you wait, re-type or check something twice?" These are the places where software saves time.
- "What goes wrong most often, and what does it cost?" Wrong deliveries, late invoices and lost emails are better arguments for a feature than opinions.
- "Who else touches this, and what do they need from you?" This finds handovers and the people who were not invited.
- "What must never happen?" Often the answer is a rule about data, money or customers, such as "no one outside the finance team sees prices". These become hard requirements.
- "What do you do today that the new system must still allow?" Workarounds that look odd are often there for a reason.
Ask the sponsor different questions: What decision will this system help you make? How will you know in six months that it worked? What is the budget range and the date that really matters?
Handle disagreement without losing the room
Users and sponsors will sometimes want different things. Do not settle it by volume. Write both positions on the page, ask what each would lose, and let the sponsor decide only if the group cannot. If the decision needs information nobody has in the room, move it to the open questions.
Watch for two traps. The first is solution talk too early: "We need an app with a dashboard." Ask what question the dashboard answers. The second is the loudest user setting the scope for everyone. The facilitator should ask each user directly before the group moves on.
What you leave with: one page
Within a day, send a one-page summary to all attendees and ask for corrections. It contains:
- Problem and goal. Two or three sentences: what hurts today and what should be better.
- Users and their main tasks. Who uses the system and the three to five things they must be able to do.
- Must-haves. Short statements in plain language, each tied to an example from the workshop.
- Not now. Things discussed and deliberately left out of the first version. This line prevents arguments later.
- Data and systems involved. Where the information lives today and which tools must connect.
- Open questions. Each with an owner and a date.
This page is the input for the next step. If you want to turn it into a fuller specification, the article What a good software requirements document contains shows the structure. If you are still choosing a supplier, the page also lets you compare quotes on the same basis, as described in Choosing a software supplier: eight questions for the first meeting.
What stays open, and that is fine
Do not try to answer everything in two hours. Some questions need a number from finance, a test with a real file or a conversation with a customer. The goal of the workshop is not to close every question but to know which ones remain and who is answering them. A supplier who sees a clear list of open questions can price the known part honestly and name the risk in the unknown part.
If the open list is longer than the must-have list, plan a second, shorter session after the answers arrive, or start with a small first step that tests the biggest uncertainty.
Sources
- Practical guidance based on common software project and business analysis practice, offered as a planning aid. The agenda timings and examples are illustrations to adapt to your own project. No client results or product performance figures are claimed in this article.