- Describe the problem, not the solution.
- Link every piece of evidence to the issue it proves.
- State the consequence of doing nothing.
- Set success criteria you can measure.
Every project starts with a need: something that is wrong, missing or at risk. The needs case sets out that need clearly, with the evidence behind it, before anyone decides what to do about it. It is the foundation of the options, the business case and ultimately the decision. If the needs case is weak, everything built on it is weak too.
Describe the problem, not the solution
The most common mistake is to write the needs case around the answer. Compare these two statements:
- Solution led: "The pumps need replacing."
- Problem led: "Pump set A has failed twice in the last 18 months and pump set B shows the same wear pattern. A further failure would take the site out of service for up to a week."
The second version explains why action is needed and leaves room for different ways to address it: repair, refurbishment, replacement or a change to how the site operates. That is exactly what a good options appraisal needs.
This matters most when interventions are proposed remotely, for example by a strategy or asset management team working from a defect register. A fix for one defect can look right on paper and still be wrong for the site. It may clash with other planned work, be impossible to access safely, need an outage nobody can give or leave a bigger problem nearby untouched. Treat each proposed intervention as an idea to test during development and optioneering, not as the answer.
What a good needs case includes
- The current situation. What exists today and what condition it is in.
- The evidence. Inspection findings, survey data, photos, failure records and performance data. Each piece of evidence should be dated, located and traceable to its source.
- The consequence of doing nothing. What happens if the situation continues. Express this as risk where you can: how likely is the problem and how serious would it be?
- The drivers. Why act now: safety, legal or regulatory obligations, performance, capacity, customer impact or strategy.
- Constraints. Anything that limits the solution: budget, outages, access, planning, standards or dependencies on other work.
- Success criteria. How you will know the need has been met. Make them SMART: specific, measurable, achievable, relevant and time bound.
Make the evidence work harder
Evidence is most persuasive when it is connected to the problem it supports. A photo in a folder called "Site visit March" proves little on its own. The same photo, located on a plan of the site and linked to the issue it shows, proves a great deal. When you gather evidence, record where it was taken, when and what it demonstrates. Future reviewers, including your own team months later, will thank you.
Involve the people who know the site
Operations staff, maintenance teams and subject matter experts often know about problems that never reach a formal record. Talk to them early. Capture their observations with the same care as survey data and record who said what. Their input frequently changes the needs case and it builds support for whatever option is eventually chosen.
A simple structure
| Section | What it answers |
|---|---|
| Summary | What is the need, in two or three sentences? |
| Current situation | What exists today and what condition is it in? |
| Evidence | How do we know? What surveys, data and observations support it? |
| Risk of doing nothing | What happens if we continue as we are? |
| Drivers and urgency | Why act and why now? |
| Constraints | What limits the possible solutions? |
| Success criteria | How will we know the need has been met? |
From needs case to options
Once the needs case is agreed, it becomes the yardstick for everything that follows. Each option should be tested against it and the success criteria usually become the starting point for the appraisal criteria. In project management terms this is requirements management: gather the needs, analyse them for gaps, overlaps and conflicts, justify them against the project's objectives and agree a baseline with the key stakeholders. See building a credible range of options for the next step.
Common mistakes
- Assuming the intervention is already known. A fix recorded against a defect without looking at the wider site, its constraints or whether the work is feasible is a starting point for development, not a decision.
- Writing the solution into the need, which rules out alternatives before they are considered.
- Evidence without context: photos and reports that are not linked to the problem they prove.
- No consequence of doing nothing, so the urgency is unclear.
- Vague success criteria such as "improve reliability" with no measure attached.
- A needs case that never changes, even when new surveys tell a different story.
How DevelopVault helps
DevelopVault pins issues and comments directly onto site imagery and drawings and links each one to the photos and reports that prove it. That gives your needs case a clear record of the site condition to draw on, connected to the options that follow. See DevelopVault Pro.
Frequently asked questions
What is a needs case?
A clear statement of why a project is needed, supported by evidence, written before a solution is chosen. It sets out the current situation, the consequence of doing nothing, the drivers for action and how success will be measured.
How is a needs case different from a business case?
The needs case explains why action is needed. The business case goes further: it compares the options for meeting the need and justifies the preferred one.
How much evidence is enough?
Enough for someone unfamiliar with the site to understand the problem and its seriousness. Each piece of evidence should be dated, located and traceable to its source.
Related guides
This guide is general information, not professional or regulatory advice.