How to write a project briefHow to write a project brief

Before an agency can quote for a website or a piece of software, it has to know what you need. Most of the time that information arrives as a three-line email and a link to a competitor's website. The quotes that come back can hardly be compared, because each agency fills the gaps in its own way.

A project brief closes those gaps. It says in your own words what the project should achieve, for whom, and how you will judge the result. This guide is for owners, managers and project leads at small and mid-sized companies who are about to commission a website, a web app or a mobile app. By the end you will have a brief in eight parts that a team can review and quote for, and that you can later sign the work off against. If you want to start right away, download the free Word template and fill it in as you read.

Brief or specification: who writes what

The two documents are often mixed up, but the split is simple. You, the client, write the brief. It records what you need and why. In German-speaking countries it is called the Lastenheft, and the DIN 69901-5 standard describes it as the full set of requirements the client sets for what is to be delivered. The supplier writes the specification in reply, called the Pflichtenheft in German. It sets out how the requirements will be met, what that costs and when it will be ready.

In short: the brief covers the what and the why, the specification covers the how. If your brief already prescribes which database or framework to use, you take over the work you are paying the agency for, and with it the risk of that decision.

Swiss usage is looser. In Switzerland the client's document is often called Pflichtenheft too, for example in projects run with HERMES, the federal government's project management method. Don't let the name confuse you: what matters is who writes the document and what it contains. For more depth, the German guideline VDI 2519 explains how to structure both documents in detail. For a small or mid-sized company's website or software project, the structure shown here is enough.

What goes into a brief

A good brief for a website or software has eight parts. Each builds on the one before: the goal leads to the users, the users to the workflows, and the workflows to the features. The last parts set the frame: quality, acceptance, budget and dates.

To keep the parts concrete, one example runs through the whole guide. It is invented but typical: a plumbing company with 25 staff in the canton of Fribourg, in Switzerland. Its customers speak German or French. Job orders are handled on paper today, and the company already invoices with Bexio, a Swiss accounting tool. Now it wants software to replace the paper. We leave the company unnamed and give no amounts.

Goal and background

Start with the reason for the project. What goes wrong today, what should be better afterwards, and how will you know it worked? Describe what already exists, too: systems, documents and habits. A goal like “go digital” helps nobody. A goal like “no report is ever typed up again” can be checked.

Example: Today the technicians write their reports by hand. In the evening the office types them up, and only then can the invoice be created in Bexio. Hours and materials get lost along the way, and invoices often go out days after the job. Goal: every job is recorded digitally, from the customer's call to the invoice. Success means the office no longer types up any reports and the invoice is ready the day after the visit.

Users and roles

Write down who will use the system, how many people that is and what each role may see and do. Roles decide permissions, and permissions account for a large share of the work. Think about people who use the system only now and then, too, such as management or an external accountant.

Example: Three people in the office create jobs and plan assignments. Around 20 technicians see only their own jobs and file reports on their phones. The owner sees everything and approves invoices. Customers don't use the system; they only receive a text message and the invoice.

Workflows

Describe step by step how the work runs today and how it should run in the new system. Who does what, in what order, and where does responsibility change hands? Most errors happen at these handovers, and that is where software helps most.

Example: The customer calls. The office creates the job and books a technician. The technician gets the job on their phone. On site, they record photos, materials, hours and the customer's signature. The office checks the report, the invoice goes to Bexio, and the customer receives it. Today, between the fourth and fifth step, there is a paper report that gets typed up in the evening. That is the step the project should replace.

Features by priority

List the features that follow from the workflows and give each one a priority: must, should, could or not now. The musts make up the first release; without them the project misses its goal. Shoulds come in if budget and time allow. Coulds are ideas for later, and not now records what is deliberately left out. That last column matters more than it looks, because it stops a wish from quietly growing into the project.

Example: Must: create jobs, plan assignments, a job report on the phone with photos and signature, and the invoice to Bexio. Should: a text message to the customer before the visit, and recurring maintenance jobs. Could: online booking for customers, and reports per technician. Not now: a customer portal, and stock management. The first release covers all four musts plus the text message before the visit.

Data and connections

Write down which data you keep, where it comes from and which systems the new one must connect to. Name the existing programs and say which way the data flows. If old data has to be moved across, note that here too, with a rough volume.

Example: Customer data lives in Bexio today and stays there. The new system reads customers and addresses from Bexio and writes approved invoices back, with lines for hours and materials. Photos and signatures stay stored with the job. Old paper reports are not imported.

Quality

This part holds the requirements that are not features but still decide whether the project succeeds: speed, security, languages, devices and accessibility. Write each one so it can be checked, with a number or a clear condition. In Switzerland, data protection belongs here: personal data falls under the Federal Act on Data Protection (FADP), and if you serve customers in the EU, the GDPR may apply as well. Say where the data may be stored.

Example: The technicians' screens are in German and French, and the text message goes out in the customer's language. The app runs on common Android and iOS phones and works in a basement without signal: the report is saved and sent later. Every page loads in under 2.5 seconds on a typical phone over mobile data. The data is stored in Switzerland or the EU.

Acceptance

Describe how you will check the finished work before you sign it off. Who tests, with what data, and what must the result be? Setting acceptance in the brief makes you write clearer requirements, because every requirement needs a check. Note what you receive at handover as well: access, documentation and an introduction for your team.

Example: The office and two technicians run 20 test jobs from the call to the invoice. Acceptance passes when every approved invoice arrives in Bexio without retyping, and a new technician files their first report in under three minutes without training. At handover the company receives all access rights and a short guide for the office and the technicians.

Budget, dates and code ownership

Give a budget range, even a rough one. A range doesn't weaken your position. It lets the agency propose a solution that fits instead of guessing. Name the dates that are truly fixed, and say why. And settle who owns the code afterwards. When you work with us, you own the code, but that isn't true everywhere, and it is worth putting in writing.

Example: Budget range for the first release: from CHF ___ to CHF ___. The first release should be running before the heating season in autumn, when most jobs come in. The company receives the full source code and all access, and can have another team develop the system later.

Requirements a team can test

Most briefs don't fail because features are missing. They fail on vague wording. “The app should be fast” sounds reasonable, but nobody can check whether it is met. The agency reads something different into it than you do, and the argument starts at acceptance.

A testable requirement has three parts: what is measured, the limit, and how it is checked. The international standard ISO/IEC/IEEE 29148 asks the same of good requirements: among other things, they should be unambiguous and verifiable. You don't need to read the standard. It is enough to test each requirement with one question: at acceptance, how would I find out whether this is met?

In the example it looks like this:

• The app should be fast. Testable: every page loads in under 2.5 seconds, measured on a typical phone over mobile data. The value is an example. It matches Google's threshold for a good Largest Contentful Paint, the moment the largest element on a page appears.
• The app should be easy. Testable: a new technician files their first report in under three minutes, without training.
• The app should connect to Bexio. Testable: every approved invoice arrives in Bexio without retyping, checked with 20 test jobs at acceptance.

The limits don't have to be perfect. What matters is that there is one. If an agency thinks a value is unrealistic, it will say so in its questions, and you can adjust it together. That is better than finding out at acceptance that both sides meant something different.

What to leave out

A brief doesn't get better the more it contains. Three things make it worse:

• Prescribing a technology without a reason. “Must be built with React” is a decision about the how. If there is a real reason, for example because your own team will maintain the code in exactly that technology, write the reason down. Otherwise leave the choice to the team that will be responsible for it.
• Screen designs as requirements. Sketches help explain, but they are not requirements. A design fixes how something looks, not what it must do. Describe the purpose and attach the sketch as a suggestion.
• A competitor's feature list. A competitor built its features for its own customers and workflows. Copy them and you pay for features nobody uses while your own workflows go unmentioned.

What happens after you send it

When you send us your brief, we read it and come back with questions. Almost every brief leaves something open, and that is normal: the questions show where assumptions are hiding. After that you receive an offer with scope, price and schedule that refers back to your eight parts. In essence, that is the specification from the first section.

Once you accept, design, build, acceptance and handover follow. Acceptance checks exactly what you described in part 7 of your brief. How long the build takes depends on the scope. Our cost guide lists the timelines we work with: a marketing website in 1–2 weeks, a web app in 2 months or more, and a mobile app's first release in 1–2 months. It gives the price ranges too. A project like the example, with an office, technicians and a connection to Bexio, is a web app. Our page on web applications explains how we build them.

Briefs in agile projects

You will often hear that agile projects don't need a brief because the requirements change anyway. That is only half true. The details change; the goal doesn't. An agile team also needs to know what it is building, for whom, within which limits and how the result will be accepted.

In an agile project, the brief therefore fixes the goal, the limits, the priorities and how acceptance works. The individual features are not described down to the last detail. They move into a backlog, an ordered list the team works through step by step and that you can reprioritise as you go. The priorities from part 4 are the starting point. In the example, the goal stays fixed: no report is ever typed up again. Whether the text message before the visit goes into the first release or the second can change along the way.

Common mistakes

These are the mistakes we see most often in briefs:

• No goal, only features. Without a goal, nobody can decide which feature matters more.
• Everything is a must. If every feature is a priority, none is. The first release becomes too large and too expensive.
• Vague quality requirements. “Fast”, “secure” and “user-friendly” without a limit cannot be signed off.
• Forgetting existing systems. A connection to accounting, a CRM or stock that only turns up during the build moves the budget and the dates.
• No budget range. Without a range, three agencies quote for three different projects.
• No acceptance. If you don't decide how the work is checked, you end up arguing about it.
• Code ownership left open. Who owns the code should be settled before the start, not when you first change supplier.

The free template

Our template contains the eight parts from this guide, each with a short explanation and space for your answers. It is a Word file you can edit freely and pass on. We don't ask for your email address.

• Project brief template in English
• Template in German (Lastenheft-Vorlage)
• Template in Albanian

Fill in the goal, users and workflows first. The features follow from them almost on their own. Leave blank what you don't know and note that it is open. An honest gap is better than a guessed answer.

FAQ

What is Lastenheft in English?

In English the client's document is usually called a project brief or requirements document, and in product teams a PRD (product requirements document). The counterpart to the Pflichtenheft is the specification; in software it is often a software requirements specification (SRS) as described in ISO/IEC/IEEE 29148. There is no word-for-word translation, so with English-speaking partners it helps to say who wrote the document.

Lastenheft or Pflichtenheft: which do I need?

As the client, you need a Lastenheft, the brief. The agency writes the Pflichtenheft in reply, usually as part of its offer or after you accept it. In Switzerland the client's document is often called a Pflichtenheft too; in that case it still means your document, which is what this guide describes.

How detailed should a brief be?

Detailed enough that an agency can quote without guessing, and no more. For a web app like the example, a few pages are often enough. More important than length is that all eight parts are there and every quality requirement has a limit. Details that can only be settled during the build belong in the backlog.

Do I need a brief for a small website?

You don't need a long document, but you do need the answers behind it. Even for a small website you should know what it is for, who visits it, which pages and languages it needs, who supplies the content and what the budget range is. A single page with the template's eight headings is often enough.

Send us your brief

When your brief is ready, even with gaps in it, send it to us through the contact page. We read it, come back with our questions and then prepare an offer. If you want to know what to look for when choosing a team, our guide to hiring a software company in Kosovo can help.

Sources

• Wikipedia (German), Lastenheft, with the DIN 69901-5 definition and the reference to VDI 2519
• HERMES, the Swiss federal project management method
• web.dev, Largest Contentful Paint: a good value is 2.5 seconds or less
• ISO/IEC/IEEE 29148, systems and software requirements engineering