Picture a familiar situation. The sponsor’s brief is clear: a document approval portal, two approval steps and a dashboard. The client signs and kickoff goes well. Three weeks later a document controller mentions that most supplier drawings never arrive through the official channel. They come by email to individual engineers and are uploaded, sometimes days later, by the document controller. That changes the design, the data migration and the training plan.
The team understands the requested system, but not the client’s business requirements. The fix is not a longer requirements document. It is a short, deliberate period of domain discovery before the plan is fixed.
How do you understand client business requirements?
To understand client business requirements, start with the business outcome and the end-to-end work, not the requested system. Observe the work as it happens, speak to frontline users, approvers and support staff as well as the sponsor, and record the vocabulary, rules, exceptions and workarounds you find. Then separate what you observed from what people told you and what you assumed, and test the riskiest assumptions before you commit to a plan.
Why a feature list is not a business requirement
A feature list describes one person’s idea of a solution. It rarely describes:
- The consequences of failure. What happens to the client’s client, regulator or cash flow when this work goes wrong?
- The exceptions. Delegated authority, urgent cases, rework loops and the cases that “never happen” but do.
- The informal system. Spreadsheets, shared inboxes and phone calls that keep the official process working.
- The language. Terms that sound shared but mean different things in different departments.
The UK Government Digital Service puts the principle plainly in its service manual: “Before you commit to building a service, you need to understand the problem that needs to be solved” (How the discovery phase works). That guidance is written for public services, but the logic transfers: the cheapest time to discover you are solving the wrong problem is before you commit.
A five-step process for understanding the client’s business
In a small firm one person may hold several of these roles; what matters is that each step has a clear owner.
| Step | Owner | Evidence produced | Decision it supports |
|---|---|---|---|
| 1. Outcome and end-to-end workflow | Engagement lead with the client sponsor | Outcome statement, one-page workflow sketch | Are we solving the right problem? |
| 2. Observe real work | Analyst or consultant | Observation notes from real cases | Does the stated process match practice? |
| 3. Map terms, rules, data, handoffs, exceptions | Analyst, reviewed by a client subject expert | Glossary, rules list, exception list | What must the solution handle? |
| 4. Separate evidence, opinion and assumption | Analyst with engagement lead | Assumption log | What do we actually know? |
| 5. Confirm the model and test the riskiest unknowns | Engagement lead with sponsor | Confirmed model, test results | Proceed, adjust or stop |
Step 1: Start with the business outcome and the end-to-end workflow
Ask what the client is trying to change and how they will know it has changed. “A document approval portal” is a solution. “Issue approved design packages to site without revision errors, within five working days of submission” is an outcome you can plan against.
Then sketch the workflow from the first trigger to the point where the client’s customer, regulator or finance team is affected, not where the requested system would end.
Step 2: Observe real work, not only the sponsor’s description
Interviews tell you how people believe the work happens; observation shows how it does. Sit with someone while they process three or four real cases, including one that went wrong.
Widen the group beyond the sponsor. The GDS discovery guidance asks teams to understand “how they do it currently” and “the problems or frustrations they experience”, and to research “with a broad range of users, including disabled people and people with low digital skills” (User research in discovery). For a client engagement, that means frontline users, approvers, support staff who absorb the failures, and less frequent users such as month-end, audit or after-hours roles. Ask about accessibility needs directly; a screen reader user or a colleague on a site laptop will expose constraints a head-office demo never will.
The sponsor often controls access to these people, so ask for it up front. Make named access to frontline, approver and support roles a condition in the proposal or charter, and explain it in terms of the sponsor’s outcome: it is how you avoid planning to the wrong process. Where the domain is unfamiliar, propose a short, separately priced discovery step tied to the decision date rather than absorbing it into unpaid pre-sale work.
Step 3: Map vocabulary, business rules, data, handoffs and exceptions
Capture five things as you go:
- Vocabulary: every term people use, and what they mean by it.
- Business rules: who may do what, under which conditions, and what must never happen.
- Data: what information moves, where it originates and who trusts it.
- Handoffs: where work changes hands, and what gets lost at each boundary.
- Exceptions: absent approvers, urgent cases, corrections, work that bypasses the official route.
Exceptions deserve the most attention: they are where rework and support demand come from later.
Step 4: Separate observed evidence, stakeholder opinion and assumptions
Some of your notes record what you saw, some what you were told and some what you filled in yourself. Label each important statement accordingly. A sponsor’s opinion is valuable but is not the same as watching the work, and an assumption buried in the estimating spreadsheet is weaker than both.
Step 5: Confirm a shared model and test the riskiest unknowns
Play back what you learnt: the outcome, the workflow sketch, the glossary and the main exceptions. Ask the client to correct it. Then rank the remaining assumptions by the damage if they are wrong, and test the top few with a specific action and a date: pull a sample of records, observe another team, ask the person who actually holds the authority.
The decision at the end is genuinely open. Proceed as planned, adjust scope or approach, or stop. GDS notes that it is “not a failure to stop at the end of the discovery phase if your research shows that’s the best thing to do”, and the same applies when discovery shows the requested solution will not deliver the client’s outcome. Record what you learnt in the engagement’s project charter so the agreed outcome and boundaries rest on evidence.
Hypothetical example: a document approval portal for an engineering consultancy
Hypothetical example: a 60-person engineering consultancy asks for a portal to route design documents for internal approval before issue to site. This is the same engagement as the opening scenario, but with discovery done before the plan was fixed.
What the brief said. Engineers upload documents; a checker reviews; a discipline lead approves; the document is issued.
What observation found. Across three mornings with the document controller and a discipline lead, working through real packages:
- Discipline leads routinely delegate approval when on site or on leave, by forwarding the email to a named colleague. There is no record of who held authority on which day.
- Supplier drawings arrive by email to individual engineers and are uploaded, sometimes days later, by the document controller.
- One senior engineer uses a magnifier and high-contrast settings; the proposed dashboard’s dense table would be hard for them to use.
The ambiguous term. “Revision” meant different things to different people. To engineers it meant a formal revision letter (Rev B to Rev C) issued after a change is approved. To the document controller it meant any resubmission, including a corrected title block. Built on the wrong meaning, the portal would have issued a new revision letter for every typo fix.
The difficult exception. The sponsor insisted supplier documents were out of scope: “that’s their problem, not ours.” But in the sample reviewed, the late approvals the sponsor most wanted to fix were mostly waiting on supplier drawings. The team did not argue from opinion. They showed the traced cases and offered two options: a simple supplier intake step in phase one, or an explicit exclusion recorded in the charter with the known effect on the outcome. The sponsor chose the intake step and dropped the dashboard to protect the budget.
Non-software adaptation. An advisory team preparing a restructuring recommendation found that “client sign-off” meant an email from the CFO to the engagement partner, but a board resolution to the client’s lenders. Planning to the CFO’s meaning would have scheduled sign-off, final invoicing and team release three weeks before the board could meet, leaving no time in the plan for the resolution the lenders actually needed. Same method, no system involved.
The domain discovery interview and observation sheet
Copy this into your engagement notes. It is designed for one to three sessions per group, not an exhaustive study.
Part 1: Discovery interview questions
Outcome and consequences
- What should be different when this work is finished, and how will you notice?
- What happens, and to whom, when this process goes wrong today?
- Which deadlines, regulations or contractual obligations cannot move?
The work as it happens
- Walk me through the last real case you handled, from the moment it arrived.
- Where do you keep information the official system does not hold?
- Which step do you most often wait on, and for whom?
Rules and authority
- Who can approve, reject or override this, and what happens when they are away?
- What must never happen, even in an emergency?
Exceptions
- Tell me about a case that did not follow the normal route. What did you do?
- What happens at month-end, year-end or during an audit?
People and access
- Who else touches this work occasionally that we have not spoken to?
- Does anyone use assistive technology, a small screen or poor connectivity to do this?
Part 2: Observation prompts
While watching someone work, note:
- Every switch to a spreadsheet, inbox or message outside the official system.
- Every wait, and who or what they are waiting for.
- Terms that differ from the sponsor’s terms.
- Checks that are not written down anywhere.
- Hesitation, re-keying or workarounds; ask “why?” afterwards, not during.
Part 3: Domain glossary
| Term | Meaning to group A | Meaning to group B | Agreed definition and owner |
|---|---|---|---|
| Revision | Engineering: formal revision letter after an approved change | Document control: any resubmission | Formal revision only; corrections tracked as versions. Owner: document controller |
| Approved | Discipline lead: technically accepted | Project manager: cleared to issue to site | Two states: “technically accepted” and “approved for issue”. Owner: engineering director |
| Sign-off | CFO: email acceptance | Lenders: board resolution | Board resolution; CFO email is an interim acceptance. Owner: engagement partner |
Part 4: Assumption log
| Statement | Evidence type and source | Impact if wrong | Test, owner and date |
|---|---|---|---|
| Suppliers can submit through a portal | Assumption (estimating team) | Late approvals persist; outcome missed | Ask three main suppliers. Analyst, 17 Oct |
| Delegation is rare | Opinion (sponsor) | Approvals stall when leads are on site | Review two months of approval emails. Analyst, 20 Oct |
| All approvers use desktop screens | Observed for four of five approvers | Accessibility and site use fail | Confirm with site engineers and the senior engineer. Engagement lead, 21 Oct |
Assumptions whose impact would be serious belong in the project’s risk register too. How to identify project risks before they become delivery problems explains how to turn them into owned risks with a decision date.
Limits of domain discovery and the common failure mode
One workshop is not domain expertise. A discovery session shows you where the important questions are. Later findings should update the glossary and assumption log, not be treated as the client changing their mind. The most common failure is running that session only with the sponsor, which is why Step 2 widens the group.
Discovery can become avoidance. Tie it to a decision and a date. If the remaining unknowns would not change scope, approach or price, stop discovering and start delivering, testing the rest as you go.
Keep it proportionate. Save the full sheet for unfamiliar domains, several departments or work where failure has serious consequences.
Observation needs consent. Explain why you are watching, avoid recording personal or client-confidential data you do not need, and never use observation notes to assess individual performance.
For the wider principle behind all of this, see Good project management is really about reducing uncertainty.
Keeping discovery evidence with the project
Discovery only helps if the delivery team can find it later. In Chronodesk, the built-in project wiki keeps specifications and documentation attached to the project, so the glossary and discovery notes sit alongside the tasks they inform, and each project has its own risk register for the assumptions that carry real delivery risk. If you want to see how that works for your engagements, explore Chronodesk project management. The method above works just as well in a shared document; what matters is that it is kept and used.
Your next step
Pick one upcoming or early-stage engagement. Before the next planning meeting, ask the interview questions in Part 1 of one frontline user who is not the sponsor, and add three rows to the assumption log. If any of those assumptions would change your plan if wrong, give it an owner and a test date this week.
Frequently asked questions
How do you understand a client’s business requirements quickly?
Start with the outcome the client needs and walk the end-to-end workflow with the people who do the work, not only the sponsor. Watch a few real cases, including at least one that went wrong, and write down the terms, rules and exceptions you hear. Then list your assumptions and test the riskiest ones first. Speed comes from focusing on the unknowns that would change the plan, not from skipping observation.
Who should you interview during client discovery?
Interview the sponsor for the outcome and constraints, but also frontline users, the people who approve or check the work, support staff who handle the problems, and less frequent users such as month-end or audit roles. Include people with accessibility needs and people who use the process in unusual ways. The sponsor describes how the work should happen; the others show how it does happen.
What is the difference between a business requirement and a solution requirement?
A business requirement describes the outcome or capability the client needs, such as approving design documents without losing revision control. A solution requirement describes how a particular system or deliverable will provide it, such as a portal with a two-step approval screen. Discovery should establish the first before the team commits to the second.
How long should domain discovery take on a client project?
Long enough to test the unknowns that would change scope, approach or price, and no longer. That can be one walkthrough for familiar work or several sessions over a few weeks for an unfamiliar, regulated or multi-department process. Set a date for the decision discovery informs, and review what is still unknown then.