Een goede projectbrief zorgt ervoor dat iedereen op één lijn zit voordat een project van start gaat - wat er wordt gebouwd, waarom het ertoe doet, wie erbij betrokken is en hoe succes wordt gemeten. Met Trupeer kun je uren besparen op het schrijven van projectbrieven door te beginnen met een gratis projectbrief-sjabloon, dit aan te passen met je brand identity en de brief om te zetten in een korte videosamenvatting die stakeholders in 3 minuten kunnen bekijken.

Wat is een projectbrief-sjabloon en wanneer wordt het geschreven?

Een projectbrief is het korte document dat helemaal aan het begin van een project wordt geschreven, voordat het plan bestaat, en waarin staat waarvoor het project is, waarom het nu belangrijk is, wie ermee te maken krijgt, hoe succes eruitziet en wat het beperkt.

Het is het document dat mensen ondertekenen om het werk te autoriseren, en het wordt het referentiepunt waar iedereen zes maanden later tegenin gaat. Het is bewust kort, meestal één of twee pagina’s, omdat het wordt geschreven op het moment met de minste informatie.

Een sjabloon geeft je de onderdelen. Achtergrond, doelstellingen, scope, deliverables, planning, budget, stakeholders, succescriteria. Elke versie die je tegenkomt biedt grofweg diezelfde onderdelen, en daar is niets mis mee.

Het probleem met projectbrieven is bijna nooit de onderdelen. Het is wat je erin zet.

De meeste projectbrieven noemen een oplossing, geen probleem

Dit is de klacht die elk delivery team, elk bureau en elke engineeringgroep maakt over projectbrieven, op dezelfde manier verwoord in elke branche: we kregen de oplossing als briefing.

"Bouw een klantenportaal." "Maak een nieuw intranet." "Lever een mobiele app op." "Herontwerp de onboarding-flow." Elk van die zinnen is iets om te bouwen, alsof het een vereiste is, terwijl het in werkelijkheid iemands antwoord is op een vraag die de projectbrief nooit stelt.

Dat gebeurt om een redelijke reden. Degene die een project initieert, heeft er meestal al weken over nagedacht en is tot een conclusie gekomen. De conclusie opschrijven voelt als duidelijkheid, en het probleem opschrijven als vaagheid.

De kosten zijn dat de goedkoopste oplossingen worden uitgesloten voordat iemand ernaar kijkt. Zodra de brief een portaal noemt, is het project een portaalproject, en de optie die tachtig procent van het probleem voor vijf procent van het geld had opgelost, wordt nooit geëvalueerd, omdat niemand is gevraagd om iets te evalueren.

Een projectbrief die een probleem beschrijft, nodigt uit tot antwoorden. Een projectbrief die een oplossing beschrijft, nodigt uit tot schattingen.

Zo pas je dit sjabloon aan in Trupeer

Stap 1: Open de sectie Templates

Ga in het hoofdmenu naar de sectie Templates.

Stap 2: Selecteer en open een sjabloon

Klik op een willekeurig sjabloon waarmee je wilt werken om het te openen.

Stap 3: Breid de sjabloonweergave uit

Als dat nodig is, breid je de sjabloonweergave uit om de volledige lay-out en details duidelijk te zien.

Stap 4: Bewerk het sjabloon

Klik op Edit om te beginnen met het aanpassen van het geselecteerde sjabloon.

In de editor kun je:

• Nieuwe onderdelen toevoegen

• Opmaakregels definiëren of bijwerken

• Een logo toevoegen en de positie en gerelateerde instellingen aanpassen

Stap 5: Sla je aangepaste sjabloon op

Nadat je alle noodzakelijke wijzigingen hebt gedaan, klik je op Save om het bijgewerkte sjabloon op te slaan als je eigen sjabloon.

Stap 6: Bekijk en verfijn het sjabloon

Als je wilt zien hoe je aangepaste sjabloon eruitziet, open je de Preview.

Vanaf het preview-scherm kun je indien nodig direct verdere aanpassingen blijven doen, zodat het sjabloon precies verschijnt zoals jij het wilt.

Met een projectbrief-sjabloon kun je:

• Uren besparen op het schrijven: Sla de blanco pagina over met een bewezen projectbrief-structuur.

• Stakeholders snel op één lijn krijgen: Projectbrieven van één pagina maken goedkeuringen en afstemming sneller.

• In lijn blijven met je merk: Gebruik je logo, lettertypen en kleuren met Trupeer’s brand kit - perfect voor projectbrieven van bureaus en voor klanten.

• Pitch met impact: Zet de brief om in een videosamenvatting - geweldig voor sales enablement en pitches richting stakeholders.

• Standaardiseren over projecten: Gebruik hetzelfde projectbrief-formaat voor elk initiatief.

• Bereik wereldwijde teams: Vertaal projectbrieven naar 65+ talen met één klik.

De drie-antwoorden-test voor elke projectbrief

Twee minuten, en het is de enige projectbrief-test die de moeite waard is om uit te voeren.

Lees de projectbrief en noem drie echt verschillende dingen die eraan zouden voldoen.

Niet drie variaties op hetzelfde. Drie verschillende benaderingen: bouw iets, verander een proces, koop iets, haal een stap weg, communiceer anders, doe minder.

Als je er drie kunt noemen, beschrijft de projectbrief een probleem en staat er een echte beslissing voor je klaar.

Als je er maar één kunt noemen, beschrijft de projectbrief een oplossing. Dat is niet automatisch fout, want soms is de beslissing echt genomen om goede redenen, en in dat geval is het eerlijke om te zeggen dat het zo is en het document een specificatie te noemen in plaats van een projectbrief. Wat niet eerlijk is, is een uitgemaakte zaak presenteren als een open vraag en vervolgens verbaasd zijn dat niemand het heeft aangevochten.

Voer deze test uit op de projectbrief voordat je hem verspreidt, met iemand die niet betrokken was bij het schrijven. De persoon die het heeft geschreven kan altijd drie dingen noemen, omdat die weet wat er is afgewezen. Niemand anders kan dat, omdat de projectbrief het niet bevat.

Zo schrijf je het probleem in plaats van de deliverable

Vier gewoonten, en geen ervan kost meer tijd dan het schrijven van de oplossing.

Begin met een observatie en een getal. Niet "klanten vinden het lastig om hun bestellingen te controleren" maar "klanten hebben ons vorige maand zesduizend zevenhonderd keer benaderd om te vragen waar hun bestelling was". Het getal doet twee dingen: het bevestigt dat het probleem echt is en het bepaalt wat een oplossing waard is.

Beschrijf wat er nu gebeurt. Hoe het probleem momenteel wordt aangepakt, slecht, inclusief de workaround die mensen hebben bedacht. Een beschrijving van de huidige situatie is wat iemand in staat stelt om een goedkopere oplossing voor te stellen.

Scheid beperkingen van vereisten. Een budget is een beperking. Een deadline is een beperking. Moet integreren met het bestaande warehousesysteem is een beperking. "Moet een login hebben" is een vereiste die als beperking is vermomd, en komt meestal voort uit iemands mentale beeld van de oplossing.

Definieer succes als een verandering in het getal, niet als het bestaan van een deliverable. Het aantal contacten binnen zes maanden met de helft verlagen is een succescriterium. Een portaal live zetten is een mijlpaal.

Als je echt een oplossing voor ogen hebt, zet die dan in een duidelijk gelabeld onderdeel waarin je het aangeeft, als één kandidaat, niet als de projectbrief.

Gratis projectbrief-sjabloon: de structuur om over te nemen

Kopieer vanaf hier. Eén of twee pagina’s, en weersta de neiging om het uit te breiden.

Kop. Projectnaam, sponsor, auteur, datum, versie en de beslissing die wordt gezocht.

Het probleem. Een observatie met een getal, hoe vaak het voorkomt en wat het kost. Twee of drie zinnen.

Hoe het nu wordt aangepakt. Het huidige proces, inclusief de workaround, en waarom dat niet genoeg is.

Waarom nu. Wat er is veranderd waardoor dit deze kwartaalperiode de moeite waard is, in plaats van volgend jaar.

Wie wordt geraakt. De mensen of klanten die erbij betrokken zijn, en ongeveer hoeveel.

Succescriteria. Welk getal beweegt, met hoeveel en tegen wanneer. Eén of twee, uitgedrukt als uitkomsten.

Beperkingen. Budget, deadline, systemen die niet kunnen veranderen, wettelijke of contractuele verplichtingen, mensen die niet beschikbaar zijn. Alles wat echt vaststaat, en niets dat eigenlijk een voorkeur is.

Buiten scope. Wat dit project niet gaat aanpakken, specifiek genoeg benoemd om discussie uit te lokken.

Kandidaatbenaderingen, indien van toepassing. Oplossingen die al zijn overwogen, duidelijk gelabeld als kandidaten in plaats van als de projectbrief, met de reden waarom elke optie op de lijst staat.

Gezochte beslissing en door wie. Wat je vraagt en wie het autoriseert.

Kopieer tot hier. Als de projectbrief langer wordt dan twee pagina’s, is de gebruikelijke oorzaak achtergrond, die in een bijlage hoort die niemand leest, en dat is prima.

De retailer die een portaal bouwde waar niemand zich voor aanmeldde

Ashfold Group is een gespecialiseerde retailer met ongeveer negentig winkels en een omvangrijke online business.

De projectbrief was twee pagina’s, goed geschreven en zonder problemen goedgekeurd. Er stond: bouw een klantenportaal voor self-service waar klanten kunnen inloggen om de status van bestellingen te bekijken, facturen te downloaden en vragen te stellen. Budget driehonderdvijftigduizend pond. Negen maanden.

Het is op tijd opgeleverd en bijna binnen budget, namelijk voor driehonderdeenenzeventigduizend.

Zes maanden na de livegang waren er drieduizend eenhonderde geregistreerde accounts tegenover ongeveer vierenveertigduizend actieve klanten, dus minder dan zeven procent. Het aantal contacten met het servicecenter was ongewijzigd.

De evaluatie na implementatie stelde een simpele vraag: welk probleem moest dit oplossen? Niemand kon het aanwijzen in de projectbrief, omdat de projectbrief een oplossing had beschreven.

Dus iemand ging op zoek naar het probleem. Het servicecenter behandelde ongeveer elfduizend contacten per maand. Een steekproef van vijfhonderd liet zien dat eenenzestig procent een variant was van waar is mijn bestelling, wat neerkomt op ongeveer zesduizend zevenhonderd contacten per maand.

Van die klanten had vierentachtig procent al een verzendmail ontvangen met daarin een trackinglink. Of ze hadden die niet gezien, of ze waren erop teruggekomen nadat de link na veertien dagen was verlopen.

Het dominante probleem was dus niet dat klanten geen manier hadden om het te checken. Het was dat de manier die ze al hadden niet werkte.

Drie goedkopere benaderingen waren nooit geëvalueerd, omdat de projectbrief geen ruimte bood voor alternatieven. De geldigheid van de trackinglink verlengen. De link opnieuw versturen volgens een planning tot levering. Orderstatus toevoegen aan het accountgedeelte dat al bestond, achteraf geschat op ongeveer achttienduizend pond.

Het portaal was een legitieme oplossing voor een echt probleem. Het was niet het grootste probleem, en het vereiste registratie, die negenendertig procent van de klanten nooit deed.

De projectbrief voor het vervolgproject werd anders geschreven. Klanten nemen elke maand zesduizend zevenhonderd keer contact met ons op om te vragen waar hun bestelling is. Vierentachtig procent van hen had al een trackinglink ontvangen. Verlaag deze contacten binnen zes maanden met de helft. Beperkingen: geen wijziging aan de carrier-integratie, honderdvijftigduizend pond, en het moet werken zonder dat klanten zich hoeven te registreren.

Drie teams deden drie echt verschillende voorstellen. De gekozen optie kostte tweeënzestigduizend pond en verlaagde die contacten met achtenvijftig procent binnen vijf maanden.

Het verschil tussen de twee projectbrieven is dat de tweede op drie manieren kon worden beantwoord. De eerste kon op één manier worden beantwoord, en die manier was al gekozen.

De kernonderdelen die elke projectbrief nodig heeft

De twee rijen die het meeste gewicht dragen zijn huidige situatie en beperkingen, en beide zijn meestal dun. Huidige situatie is wat iemand in staat stelt om het goedkope antwoord voor te stellen. Beperkingen, eerlijk gescheiden van voorkeuren, zijn wat voorkomt dat een projectbrief per ongeluk een specificatie wordt.

Zo schrijf je een projectbrief in vijf stappen

Een. Schrijf het probleem met een getal. Als je geen getal kunt krijgen, besteed dan een middag om er één te vinden. Een projectbrief zonder getal is een voorkeur.

Twee. Beschrijf de huidige situatie, inclusief hoe mensen er vandaag omheen werken.

Drie. Stel succes in als een verandering in dat getal, met een datum.

Vier. Maak een lijst van beperkingen en daag elke beperking uit. Vraag bij elk item wie dit heeft vastgesteld en of het kan veranderen. Ongeveer een derde kan dat meestal, en elke beperking die verandert, vergroot het bereik aan mogelijke antwoorden.

Vijf. Doe de drie-antwoorden-test met iemand die het niet heeft geschreven. Als het faalt, open je de projectbrief of label je het document eerlijk opnieuw.

Verspreid het daarna en verwacht dat de antwoorden die je terugkrijgt minstens één antwoord bevatten dat je niet had bedacht. Als geen van de antwoorden je verrast, was de projectbrief waarschijnlijk een specificatie.

Beperkingen, en hoe ze als vereisten worden meegesmokkeld

Dit is waar de meeste projectbrieven stilletjes specificaties worden, en dat gebeurt zonder dat iemand het bedoelt.

Een echte beperking is iets waar de projectorganisatie geen controle over heeft. Het budget is wat het is. De wettelijke deadline staat vast. Het warehousesysteem wordt dit jaar niet vervangen. Het team heeft vier mensen.

Een voorkeur die als beperking is verkleed, klinkt identiek. Het moet een mobiele app zijn. Het heeft een dashboard nodig. Gebruikers moeten een login hebben. Elk van die punten is iemands mentale beeld van het antwoord, en zodra het in de sectie beperkingen staat, wordt het door iedereen stroomafwaarts behandeld als niet te veranderen.

De test is om bij elk item te vragen wie dit heeft besloten en wat er gebeurt als het verandert. Een echte beperking heeft een eigenaar buiten het project en een consequentie als die wordt geschonden. Een voorkeur heeft geen van beide, en meestal zal de persoon die het heeft geschreven het er vrolijk bij laten als je het direct vraagt.

Voer dat gesprek voordat je de projectbrief verspreidt. Het kost twintig minuten en is vaak de meest waardevolle twintig minuten van het hele project, omdat elke verwijderde beperking een mogelijk antwoord toevoegt.

Projectbrief, business case of projectplan?

Drie documenten aan het begin van een project, achter elkaar, met verschillende taken.

De projectbrief beschrijft het probleem, de beperkingen en de succescriteria. Die wordt als eerste geschreven, is kort en autoriseert onderzoek of uitvoering.

De business case onderbouwt de uitgaven. Die bevat opties met kosten en baten, en is wat een finance-functie of een investeringsboard goedkeurt. Een projectbrief die lang is geworden en vol cijfers staat, is meestal een business case met de verkeerde naam.

Het projectplan beschrijft hoe de gekozen aanpak wordt uitgevoerd: scope, planning, resources, afhankelijkheden en risico. Onze IT projectplan-sjabloon dekt die laag.

De volgorde is belangrijk. Projectbrief, dan opties, dan business case, dan plan. Het plan schrijven voordat de projectbrief er is, wat vaker gebeurt dan iemand toegeeft, betekent dat de aanpak al is gekozen voordat het probleem is benoemd.

Zodra het plan bestaat, moet de projectbrief expliciet worden vervangen en gemarkeerd, waarbij het plan de enige bron wordt van de overeengekomen scope. Twee documenten die autoriteit claimen is hoe scope-discussies onoplosbaar worden.

Varianten van projectbrieven: creatief, design, software en bouw

De structuur blijft hetzelfde over typen heen en de nadruk verschuift.

Creatieve en marketingprojectbrieven hebben het publiek en de boodschap nodig, en ze zijn het meest vatbaar voor solution-briefing, omdat een klant vaak met een format in gedachten binnenkomt. Het probleem hier is meestal een gedrag dat je wilt veranderen, in plaats van iets dat je wilt maken.

Designprojectbrieven hebben de gebruiker, de context van gebruik en de beperkingen van het bestaande systeem nodig. Bijna elke projectbrief in deze categorie profiteert van de drie-antwoorden-test, omdat een designprojectbrief die een lay-out specificeert, het design al heeft weggenomen.

Projectbrieven voor software hebben het probleem en de huidige workaround nodig, meer dan iets anders, en ze moeten volledig vrij blijven van features. Zodra features in scope komen, schrijf je een requirementsdocument, en dat dekt onze lean PRD-sjabloon.

Bouw- en designprojectbrieven bevatten beperkingen die echt beperkingen zijn: locatie, planning, regelgeving, budget. Hier is de sectie beperkingen de inhoud, niet het risico.

Projecten met veel inkoop hebben de projectbrief nodig om te beschrijven wat er als uitkomst wordt ingekocht, in plaats van als specificatie, omdat de beslissing over de volwassenheid van de specificatie later komt en onze procurement management plan template dat dekt.

Kan ik een projectbrief-sjabloon in Word of Excel krijgen?

Word of Google Docs. Een projectbrief is tekst, één of twee pagina’s, en er wordt commentaar op gegeven voordat hij wordt goedgekeurd. Er zit niets in dat een spreadsheet wil.

Excel krijgt alleen een plek als je veel projecten draait en een register wilt: project, sponsor, probleem op één regel, succescriterium, budgetbeperking, status en datum van goedkeuring. Dat register is echt nuttig om het patroon te herkennen dat je anders niet ziet, namelijk hoeveel van je projecten een succescriterium hebben dat als deliverable is uitgedrukt in plaats van als getal.

PDF voor de goedgekeurde versie, geëxporteerd bij sign-off. Omdat een projectbrief het referentiepunt is voor latere discussies, is het hier belangrijker om de goedgekeurde versie met een datum vast te zetten dan bij de meeste documenten.

PowerPoint is een slechte container. Een projectbrief die als slides wordt gepresenteerd, neigt het probleembeschrijving kwijt te raken en de oplossing te behouden, om dezelfde reden die in de hele pagina wordt beschreven.

Zo toon je het probleem in plaats van het te beschrijven

Het moeilijkste deel van een goede projectbrief is ervoor zorgen dat een probleem echt voelt voor mensen die het niet zelf ervaren. Een getal helpt. Een alinea doet dat zelden.

Er is een goedkope alternatieve aanpak die bijna niemand gebruikt: leg vast dat het probleem gebeurt.

Twee minuten van een serviceagent die een waar-is-mijn-bestelling-aanvraag afhandelt, of van iemand die om een kapotte stap heen werkt met drie browser-tabbladen en een spreadsheet, communiceert meer dan een pagina beschrijving en is heel moeilijk te betwisten. Voeg het toe aan de projectbrief.

Trupeer AI maakt dat eenvoudig, omdat een schermopname zowel een video als een geschreven walkthrough van het huidige proces wordt, precies wat de sectie huidige situatie in de projectbrief nodig heeft. Het geeft het delivery team ook iets om naar terug te verwijzen bij het kiezen tussen benaderingen, in plaats van later maandenlang op de bewoordingen van de projectbrief te vertrouwen.

Leg het vast. Branded het. Vertaal het. Trupeer it.

Dezelfde opname is daarna ook nuttig als de beginsituatie wanneer je meet of het project werkte. Het materiaal staat in je knowledge base met consistente branding, en setup-instructies staan in de document template setup guide.

Veelgestelde vragen

Is er een gratis projectbrief-sjabloon in Word?

De structuur hierboven plakt direct in Word of Google Docs. Er is geen afgeschermde download en geen formulier. De twee secties die je als eerste moet schrijven zijn het probleem met het getal en de beperkingen, omdat alles wat volgt daarvan afhangt en dit de twee onderdelen zijn waar sjablonen het zwakst zijn.

Is er een gratis projectbrief-sjabloon in Excel?

Excel is geschikt voor een register van projectbrieven binnen een portfolio, niet voor één individuele projectbrief. Kolommen voor project, sponsor, het probleem op één regel, het succescriterium, de budgetbeperking, status en goedkeuringsdatum. Dat register scannen op succescriteria die als deliverables zijn uitgedrukt, is een snelle manier om te vinden welke projecten geen meetbare uitkomst hebben.

Waar kan ik een voorbeeld van een projectbrief in PDF vinden?

Gepubliceerde voorbeelden zijn eenvoudig te vinden, ook van overheidsinstanties en zorgorganisaties, en ze zijn de moeite waard om te lezen vanwege de volgorde van de secties. Lees ze kritisch, omdat een groot deel van de gepubliceerde projectbrieven solution briefs zijn en ze onkritisch lezen het patroon versterkt waar deze pagina over gaat.

Hoe lang moet een projectbrief zijn?

Eén of twee pagina’s. Langere projectbrieven dragen meestal achtergrondinformatie die in een bijlage hoort, of ze hebben de business case geabsorbeerd. Als de projectbrief niet binnen vijf minuten door een sponsor kan worden gelezen, wordt hij gescand en wordt de sectie die als eerste wordt gescand, de probleembeschrijving.

Wie moet de projectbrief schrijven?

De sponsor of de persoon die het probleem beheert, met iemand uit delivery die het leest voordat het wordt verspreid. Die tweede lezer vangt solution-briefing, omdat die anders negen maanden zou besteden aan het bouwen van het verkeerde antwoord.

Wat is het verschil tussen een projectbrief en een creatieve brief?

Vooral domein, niet structuur. Een creatieve brief voegt publiek, boodschap, toon en kanaal toe, en wordt meestal door een klant voor een bureau geschreven. Beide lijden op dezelfde manier onder solution-briefing, en de drie-antwoorden-test geldt voor beide zonder aanpassingen.

Wanneer moet de projectbrief worden goedgekeurd?

Voordat er ook maar iets aan planning of schattingen begint, en specifiek voordat iemand zich heeft gecommitteerd aan een aanpak. Een projectbrief die is goedgekeurd nadat de aanpak is gekozen, is een formaliteit en helpt niet wanneer scope later wordt betwist, omdat iedereen zich de aanpak zal herinneren in plaats van het document.

Wat gebeurt er met de projectbrief zodra het projectplan bestaat?

Die moet expliciet worden vervangen en gemarkeerd, waarbij het plan de enige bron wordt van de overeengekomen scope. De projectbrief live laten als tweede autoriteit is wat scope-discussies onoplosbaar maakt, omdat beide partijen naar een document kunnen verwijzen. Houd de projectbrief als registratie van welk probleem werd opgelost, wat echt nuttig is bij afsluiting.