Software
Zu allgemein. Wir brauchen ein neues Informationssystem.
Hilfreichere Angabe. Sechs Personen übertragen Bestellungen 18 Stunden pro Woche in Tabellen.
Praktische Projektvorlage
So schreiben Sie einen Projektbrief
Sie müssen die Lösung nicht kennen. Beschreiben Sie Problem und gewünschtes Ergebnis.
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.
Ein Einstieg in 10 Minuten
Vier Antworten reichen für das erste Gespräch.
Benennen Sie das Problem oder die Chance in einem Satz.
Beschreiben Sie den heutigen Ablauf und seine Auswirkungen auf Menschen oder das Unternehmen.
Notieren Sie, was nach dem Projekt messbar besser sein soll.
Ergänzen Sie Budgetrahmen, Termin und die entscheidende Person.
Kurze Beispiele für ein besseres Briefing
Ein konkreter Satz hilft mehr als der Name einer Lösung.
KI und Automatisierung
Zu allgemein. Wir möchten KI in unserem Unternehmen nutzen.
Hilfreichere Angabe. Der Support sortiert täglich 120 Nachrichten. Jeden Vorschlag prüft ein Mensch.
Design
Zu allgemein. Die Website braucht ein moderneres Design.
Hilfreichere Angabe. Mobile Besucher können drei Pakete nicht ohne Hilfe vergleichen.
Marketing
Zu allgemein. Wir brauchen besseres Marketing.
Hilfreichere Angabe. Die Seite hat monatlich 1.800 Besuche, aber weniger als ein Prozent sendet das Formular.
EINFACHE KI-HILFE
Briefing mit ChatGPT oder Claude ausfüllen.
Ein neuer Chat öffnet sich mit dem fertigen Prompt. Die KI stellt jeweils eine Frage.
Sie können im KI-Assistenten den Sprachmodus einschalten und das Projekt frei beschreiben. Er stellt jeweils eine Frage.
Geben Sie keine Passwörter, API-Schlüssel, Produktionsdaten, Geschäftsgeheimnisse oder identifizierbare personenbezogene Daten ein.
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: Was eine hilfreiche erste Anfrage enthält
- 01
Problem
Was nicht funktioniert, wen es betrifft und welche Folgen es heute hat.
- 02
Ergebnis
Was nach dem Projekt besser sein soll und woran Sie es erkennen.
- 03
Umfang
Was zur ersten Phase gehört, was warten kann und was ausgeschlossen ist.
- 04
Rahmenbedingungen
Nennen Sie Budget, Termin sowie rechtliche, technische oder Sicherheitsvorgaben.
- 05
Unterlagen
Was bereits existiert und wer Unterlagen, Zugänge oder Entscheidungen liefert.
Worauf dieser Leitfaden basiert9 · Fachquellen geprüft am 24. Juli 2026
Die Struktur ist unsere Zusammenfassung öffentlicher Empfehlungen zu Nutzerforschung, Projektklärung, verantwortungsvoller KI und Kommunikationsbriefings. Die Quellvorlagen werden nicht kopiert.
- GOV.UK Service ManualNutzerbedürfnisse, heutiges Verhalten, Hürden und Nachweise vor der Lösungswahl.
- Atlassian Project CharterZiele, Umfang, Beteiligte, Ressourcen, Budget, Termine und Risiken.
- NASA Systems Engineering HandbookEindeutige, machbare und überprüfbare Anforderungen mit klarer Quelle und Nachweismethode.
- FAR 37.602Arbeitsergebnisse, messbare Leistungsstandards und Bewertung ohne Vorgabe der Lösung.
- NIST AI Risk Management FrameworkKI-Nutzungskontext, Daten, menschliche Aufsicht, Auswirkungen, Messung und Fehlerverhalten.
- OpenAI Data ControlsWie Konto- und Diensteinstellungen beeinflussen, ob Inhalte zur Modellverbesserung verwendet werden.
- Anthropic Privacy GuidanceHinweis, Organisationsregeln zu prüfen und sensible Daten nicht ohne angemessene Freigabe zu senden.
- KRAS Kampaň BriefAufgabe, Zielgruppe, gewünschte Verhaltensänderung, Pflichtbestandteile, Budget und Bewertung.
- APRSR Férový tenderEin schriftliches Briefing mit Zielen und Erfolgskriterien, das Raum für fachliche Empfehlungen lässt.
Ist Ihr Briefing fertig?
Senden Sie die Datei an rise@rise.sk oder fügen Sie einen Freigabelink in das Formular ein.