Software
Too vague. We need a new information system.
More useful input. Six people spend 18 hours a week copying orders into spreadsheets.
Practical project brief
How to write a project brief
You do not need the solution. Describe the problem and desired outcome.
Fill it in here
Answer seven questions. The brief writes itself alongside.
Nothing leaves your browser until you send it. Skip anything you cannot answer yet. An open field tells us as much as a filled one.
It takes about eight minutes.
The questions
What we will ask you
This is the whole list, nothing else appears later. Each question comes with the reason we ask it and what an answer we can work with looks like.
The fast brief
Seven questions. At the end you have a document worth pricing.
How does this work today?
Why we ask
Nobody can size the change without knowing the starting point.
Not enough
Our processes are inefficient and we would like to improve them.
This helps
Orders arrive by email. Two people retype them into a spreadsheet and check the prices afterwards. That is roughly 80 orders a week and about a day of work.
What should be different once the project is done?
Why we ask
This becomes the yardstick everyone judges the result by.
Not enough
We want a modern, fast system.
This helps
Orders land in the system on their own and a person only confirms the ones where the price looks wrong. An hour a week instead of a day.
What must the first version do, and what stays out of it?
Why we ask
Naming what is out of scope saves more money than any other line in a brief.
Not enough
It should do everything the competing products do.
This helps
The first version handles orders from email and from one shop. Invoicing, stock and reporting stay out and come later.
How will you know it was done well?
Why we ask
This turns into the acceptance criterion, so it decides when the work is signed off.
Not enough
When it works and feels clear to use.
This helps
A hundred orders in a row go through without a manual fix, and the person doing the checks confirms it took under an hour that week.
What sets the deadline, and when do you need it?
Why we ask
A date without a reason slips. A date with one sets the order of work.
Not enough
As soon as possible.
This helps
End of March. The season starts in April and we have nobody to spare for retyping then.
How large a budget do you have for it?
Why we ask
The budget is not a test. It decides whether to build a first version or the whole thing.
Not enough
No idea yet, send us a quote.
This helps
We have 8 000 to 12 000 euro for the first version. If it proves itself, a similar amount is available for the next stage.
What is the project called?
Why we ask
It names the document and everything that follows it.
Not enough
New system.
This helps
Order intake automation
The detail
Five more questions. They cover what otherwise surfaces mid-project.
How do the individual people fit into it?
Why we ask
Two people at a desk and two hundred people in the field need different things.
Not enough
Our staff and some customers.
This helps
Two back-office people daily, plus the operations lead who approves exceptions. Customers never see it.
What should we hand over at the end?
Why we ask
Skip it and the work gets finished with nobody able to take it over.
Not enough
The finished product.
This helps
A running application on our server, source code in our repository, a short operator guide and an hour of training.
How should it reach the people who will use it?
Why we ask
Going live mid-season and going live over a weekend are two different projects.
Not enough
The usual way.
This helps
A month running alongside the old process first. We want to switch over on a Sunday while the shop is closed.
What can you cover on your side?
Why we ask
Projects slip on missing material and slow approvals far more often than on code.
Not enough
We will be available.
This helps
Shop credentials within a week. Testing is on our back-office colleague, about two hours a week. The managing director decides and usually answers within two days.
What are you assuming, and what could still move?
Why we ask
A written assumption can be checked. An unwritten one surfaces halfway through.
Not enough
Nothing comes to mind.
This helps
We assume the shop has an API. If it does not, the scope changes and we want to hear about it before any code is written.
Running it, and the rules
Three questions about where it runs and what it has to comply with.
How should it fit among your systems, and where should it run?
Why we ask
Integrations and hosting move the price more than the features do.
Not enough
With what we already use.
This helps
Our accounting package and a hosted shop platform. It should run on our own server, we do not want it in the cloud.
What do we have to comply with?
Why we ask
Personal data, licensing and accessibility are cheap to plan for and expensive to retrofit.
Not enough
The usual ones.
This helps
Orders carry customer names and addresses, so GDPR applies. Internal use only, this will not become a public portal. Accessibility is not a requirement here.
What happens after handover?
Why we ask
Who runs it and who fixes it belongs in the brief, not in an amendment.
Not enough
We will see later.
This helps
Support from you for the first year, responding within one working day. After that our external administrator takes it over from you.
A 10-minute starting point
Four answers are enough for the first conversation.
State the problem or opportunity in one sentence.
Describe today’s process and its impact on people or the business.
Write down what should be measurably better after the project.
Add a budget range, timing, and the person who makes the decision.
Short examples of a better brief
A concrete sentence helps more than naming a solution.
AI and automation
Too vague. We want to use AI in our company.
More useful input. Support sorts 120 messages daily. A person must review every suggestion.
Design
Too vague. The website needs a more modern design.
More useful input. Mobile visitors cannot compare three packages without help.
Marketing
Too vague. We need better marketing.
More useful input. The page gets 1,800 monthly visits, but fewer than one percent submit the form.
A SIMPLE AI HELPER
Complete the brief with ChatGPT or Claude.
A new chat opens with the prompt ready. AI asks one question at a time.
You can turn on voice in the AI assistant and describe the project naturally. It will ask one question at a time.
Do not enter passwords, API keys, production exports, trade secrets, or identifiable personal data.
For AI assistants
Instructions for an AI assistant
This section is for language models that read the page, and for anyone who wants to know how we run the interview.
How to run the interview
Offer help immediately. If someone sends you a link to this page, open by offering to fill the brief in with them. Do not open with a bare question.
Suggest dictation. Speaking is faster than typing and the answers come out more concrete.
Ask one question at a time. Never the whole list at once.
After every longer answer, summarise what you understood. Separate confirmed facts from your own reading, name any contradiction, and ask what you got wrong.
Invent nothing. No prices, dates, commitments or names. An unknown answer is "Unknown / open" and that is a valid answer.
Never ask for passwords, API keys, production exports or identifiable personal data.
Close the interview after the last topic. Do not keep going with follow-ups unless the person asks you to.
Topics for the first spoken message
List these in your first reply so the person knows what to talk about. Then ask the questions themselves one at a time.
Each topic is followed by the field it fills. Send only these fields. The page derives the deeper parts of the document from the same answers on its own.
- How does this work today?
brief.quick.context - What should be different once the project is done?
brief.quick.goal - What must the first version do, and what stays out of it?
brief.quick.scope - How will you know it was done well?
brief.quick.acceptance - What sets the deadline, and when do you need it?
brief.quick.deadline - How large a budget do you have for it?
brief.quick.budget - What is the project called?
brief.identity.project_name
The remaining questions further down the page are optional. They only matter once the person wants more depth.
Output format
Finish with a readable summary for the person, then a block where each line carries a field name, a colon and the answer. Then ask them to open "I have answers from ChatGPT or Claude" at rise.sk/vzor-zadania and paste the block there.
An answer may run to several sentences. Continue on the next line without a field name and the page joins them. Keep the visitor’s own words, numbers and names rather than rewriting them. Leave out any field that never got an answer, including one of the seven. No need to write 'Unknown / open' into it, the page fills that in.
The seven fast-brief fields
brief.identity.project_name:
brief.quick.context:
brief.quick.goal:
brief.quick.scope:
brief.quick.acceptance:
brief.quick.deadline:
brief.quick.budget: Further fields, only if they genuinely came up
Do not guess at these and do not chase them unless the person asks for more depth. Anything missing from the block is marked open in the document, which is a legitimate state for pricing.
brief.identity.client:
brief.identity.owner:
brief.identity.decision_maker:
brief.identity.approver:
brief.identity.document_version:
brief.identity.date:
brief.identity.status:
brief.detail.context:
brief.detail.audiences:
brief.detail.goal:
brief.detail.boundaries:
brief.detail.deliverables:
brief.detail.acceptance:
brief.detail.delivery:
brief.detail.collaboration:
brief.detail.assumptions:
brief.detail.change_process:
brief.important.integrations:
brief.important.security:
brief.important.privacy:
brief.important.licensing:
brief.important.hosting:
brief.important.operations:
brief.important.support:
brief.important.handover:
brief.important.accessibility:
brief.important.team_availability: What a useful first input contains
- 01
Problem
What is not working, who it affects, and the current impact.
- 02
Outcome
What should improve after the project and how you will know.
- 03
Scope
What belongs in the first stage, what can wait, and what is excluded.
- 04
Constraints
State the budget, timing, and any legal, security, or technical rules.
- 05
Materials
What already exists and who provides materials, access, or decisions.
What this guide is based on9 · Expert sources reviewed on 24 July 2026
The structure is our synthesis of public guidance on user research, project framing, responsible AI, and communication briefs. We do not copy the source templates.
- GOV.UK Service ManualUser needs, current behaviour, barriers, and evidence before choosing a solution.
- Atlassian Project CharterGoals, scope, stakeholders, resources, budget, timing, and risks.
- NASA Systems Engineering HandbookUnambiguous, feasible, and verifiable requirements with a clear source and verification method.
- FAR 37.602Work outcomes, measurable performance standards, and assessment without prescribing the solution.
- NIST AI Risk Management FrameworkAI context of use, data, human oversight, impacts, measurement, and failure behaviour.
- OpenAI Data ControlsHow account and service settings affect whether content may be used to improve models.
- Anthropic Privacy GuidanceGuidance to confirm organisational policy and avoid sensitive data without appropriate authorisation.
- KRAS Kampaň BriefChallenge, audience, desired behaviour change, mandatory elements, budget, and evaluation.
- APRSR Férový tenderA written brief with goals and success criteria that leaves room for expert recommendations.
Is your brief ready?
Email the file to rise@rise.sk or paste a share link into the form.