Projectscopeverklaring: Zo schrijft u er een in 5 stappen

Belangrijkste onderdelen van een scopeverklaring van een project

Een scopeverklaring van een project bepaalt de grenzen van het project, met inbegrip van wat het team zal opleveren, hoe het werk wordt uitgevoerd en wat van het project is uitgesloten. De belangrijkste onderdelen van een scopeverklaring van een project zijn:

Onderdeel	Wat moet erin staan?
Projectoverzicht	Een korte samenvatting waarin wordt uitgelegd wat het project inhoudt, waarom het project wordt uitgevoerd, wat de zakelijke behoefte is en wat het algemene projectdoel is
Werk binnen de scope	De uiteindelijke resultaten, middelen, producten of diensten die het projectteam zal produceren
Werk buiten de scope	Op te leveren resultaten, verzoeken, functies of activiteiten die specifiek van het project zijn uitgesloten om ongecontroleerde scope-uitbreiding te voorkomen
Op te leveren projectresultaten	De uiteindelijke resultaten, middelen, producten of diensten die het projectteam zal produceren
Projectaanpak en fasen	Hoe het project wordt voltooid, met inbegrip van werkstromen, methodologieën, fasen, belangrijke taken of de implementatieaanpak
Tijdlijn en mijlpalen	Belangrijke projectdeadlines, mijlpalen, lanceringsdatums, goedkeuringen en leveringsschema's
Budget en betalingsschema	Projectramingen, budgetten, betalingsvoorwaarden, factureringsschema's of financiële aannames
Aannames en afhankelijkheden	Aannames voor het project, afhankelijkheden, voorwaarden of externe factoren die de oplevering van het project beïnvloeden
Projectbesturing en goedkeuringen	Belanghebbenden, goedkeurders, besluitvormers, escalatieroutes en verantwoordelijkheden voor goedkeuring
Verduidelijkingen en uitsluitingen	Aanvullende opmerkingen, verduidelijkingen, definities of uitsluitingen die nodig zijn om misverstanden over de scope van het werk te voorkomen

Voorbeeld van een scopeverklaring van een project

Hieronder staat een voorbeeld van een vereenvoudigde scopeverklaring van een project voor een project voor het vernieuwen van een website.

Sectie	Beschrijving
Projectoverzicht	Het bureau levert de klant strategie voor de website, UX-ontwerp, visueel ontwerp, responsieve front-endontwikkeling en e-commerce-integratiediensten als onderdeel van een volledige herontwerping van de e-commercewebsite van het bedrijf.
Werk binnen de scope	Ontdekking van de website en workshops met belanghebbenden, UX-onderzoek en ontwikkeling van wireframes, responsief visueel ontwerp, e-commerce-integratie, QA-tests en ondersteuning bij de lancering
Werk buiten de scope	Doorlopend websiteonderhoud, aanvullende ontwerpwijzigingen buiten de goedgekeurde revisierondes, fotografie- of videoproductie, licentie- of hostingkosten van derden, copywritingdiensten
Projectopleveringen	De uiteindelijke opleveringen omvatten responsieve websitesjablonen, goedgekeurde ontwerpvoorbeelden, integratie van e-commercefunctionaliteit, ondersteuning bij QA-tests en assistentie bij de implementatie van de website.
Projectaanpak en fasen	Het bureau levert twee eerste ontwerprichtingen ter beoordeling. Eén goedgekeurde richting wordt verder uitgewerkt tot paginavullend ontwerp en ontwikkeling. Ontwerpwijzigingen zijn beperkt tot twee revisierondes per goedkeuringsfase, tenzij anders overeengekomen via een formeel wijzigingsverzoek.
Projectplanning en mijlpalen	Het project wordt uitgevoerd in de fasen ontdekking, ontwerp, ontwikkeling, QA en implementatie, verspreid over een geschatte periode van 16 weken.
Budget en betalingsschema	Het geschatte projectbudget bedraagt $75,000, met betalingen gepland rond de projectstart, de goedkeuring van het ontwerp en de mijlpaal van de uiteindelijke lancering van de website.
Veronderstellingen en afhankelijkheden	Alle feedback van de klant moet via één contactpersoon worden gebundeld en binnen drie werkdagen na elke beoordelingscyclus schriftelijk worden ingediend. Vertraagde goedkeuringen of ontbrekende contentmiddelen kunnen van invloed zijn op de uiteindelijke opleveringsplanning.
Governance en goedkeuringen	De definitieve goedkeuringen worden vóór de lancering verstrekt door de marketingdirecteur en e-commercemanager van de klant.
Verduidelijkingen en uitsluitingen	De klant is verantwoordelijk voor het aanleveren van alle websiteteksten, afbeeldingen en productgegevens voordat de ontwikkeling begint. Voor aanvullende functies, revisies of diensten buiten de goedgekeurde scope is een formeel wijzigingsverzoek vereist en kunnen extra kosten in rekening worden gebracht.

Een projectscopeverklaring opstellen

Zo schrijf je een waterdicht projectscopedocument.

Stay Ahead of What Deserves Your Attention

Get timely perspective on the shifts, decisions, and trade-offs shaping your role, plus practical resources you can put to work.

Get Free Access

Have an account? Log In

1. Begin met een duidelijk projectoverzicht

Deze scopeverklaring op hoofdlijnen beschrijft wat het project is, waarom het wordt uitgevoerd en wat het zal bereiken. Begin de scopeverklaring met een beknopte samenvatting waarin je uitlegt:

• Wat het project is
• Waarom het project wordt uitgevoerd
• Het zakelijke doel of de zakelijke doelstelling
• De waarde die het project naar verwachting oplevert

Deze sectie moet belanghebbenden context bieden, zodat zij het doel van het project begrijpen voordat ze de gedetailleerde opleveringen of planningen bekijken. Zorg ervoor dat je:

• Het kort houdt. Je hebt het project verkocht — nu zetten we alleen de details klaar.
• Alle KPI's toevoegt waarvoor binnen deze overeenkomst verantwoordelijkheid wordt gedragen.

Ik raad aan om dit onderdeel door je accountmanager of verkoper te laten schrijven als die bij het project betrokken is.

2. Definieer opleveringen en mijlpalen

Definieer vervolgens duidelijk wat er wordt opgeleverd, wanneer dat gebeurt en in welk formaat. Wees specifiek over:

• Opleveringen
• Opgenomen platforms of apparaten
• Aantal revisies
• Planningen en mijlpalen
• Afhankelijkheden

Vermijd waar mogelijk vage formuleringen. Hoe gedetailleerder je opleveringen zijn, hoe gemakkelijker het wordt om verwachtingen te beheren en later scope-uitbreiding te voorkomen. Als je bijvoorbeeld wireframes levert: lever je die voor de volledige desktop- en mobiele ervaring? Alleen voor tablets? Hoeveel sjablonen? Hoeveel schermen?

3. Beschrijf het goedkeuringsproces

Een sterke projectscopeverklaring moet uitleggen hoe beoordelingen, goedkeuringen en feedback gedurende de hele levenscyclus van het project zullen verlopen.

Definieer:

• Wie feedback geeft
• Hoe feedback moet worden ingediend
• Termijnen voor goedkeuring
• Verantwoordelijkheden van belanghebbenden
• Beoordelingsprocessen

Dit zorgt voor verantwoordelijkheid en voorkomt vertragingen die worden veroorzaakt door versnipperde of late feedback. Meestal neem ik deze formulering op in het gedeelte 'Aannames en afhankelijkheden'. Vervolgens bespreek ik dit mondeling met de klant om overeenstemming te bereiken over het verwachte feedback- en goedkeuringsproces.

4. Neem inbegrepen en uitgesloten onderdelen op

Een van de belangrijkste onderdelen van een projectscopeverklaring is het definiëren van wat wel en niet binnen het project valt. Dit gedeelte helpt om:

• Scope-uitbreiding te voorkomen
• Geschillen te verminderen
• De begrotingscontrole te verbeteren
• Realistische verwachtingen te scheppen

5. Maak een systeem voor scopebewaking

Maak voor grotere of complexere projecten een systeem om goedkeuringen, op te leveren resultaten, beoordelingen en scopewijzigingen gedurende het hele project bij te houden.

Veel projectmanagers gebruiken:

• Scopematrices
• Beoordelingsoverzichten
• Goedkeuringsregisters
• Projectmanagementsoftware

Waarom zijn projectscope-documenten belangrijk?

Projectscope-documenten helpen je belanghebbenden op één lijn te brengen, verwachtingen te beheren en scope-uitbreiding gedurende de hele levenscyclus van het project te voorkomen.

Dit zijn zes redenen waarom projectscope-documenten belangrijk zijn:

• Voorkom scope-uitbreiding: Door duidelijk vast te leggen wat wel en niet is inbegrepen, beschik je over een referentiepunt wanneer er nieuwe verzoeken binnenkomen. Je kunt werk dat buiten de scope valt identificeren voordat het gevolgen heeft voor je budget of planning.
• Breng de verwachtingen van belanghebbenden op één lijn: Met een gedeeld scopedocument zorg je ervoor dat klanten, sponsors en teamleden het eens zijn over projectdoelstellingen, op te leveren resultaten en beperkingen. Dit vermindert latere misverstanden en geschillen.
• Verbeter de projectplanning en ramingen: Gedefinieerde vereisten en op te leveren resultaten helpen je team om kosten, middelen en doorlooptijden nauwkeuriger te ramen. Je hebt een duidelijker beeld van het benodigde werk voordat je toezeggingen doet.
• Leg duidelijke verantwoordelijkheden vast: Scopedocumenten verduidelijken wie verantwoordelijk is voor specifieke op te leveren resultaten en wat van elke partij wordt verwacht. Dit helpt dubbel werk, over het hoofd geziene taken en onduidelijkheid over verantwoordelijkheid te voorkomen.
• Ondersteun verandermanagement: Een goedgekeurde scopebasis biedt een referentiepunt om voorgestelde wijzigingen mee te vergelijken. Je kunt de impact beoordelen, onderhandelen over afwegingen en goedkeuringen vastleggen voordat je extra middelen toezegt.
• Stel meetbare acceptatiecriteria vast: Door vast te leggen wanneer een op te leveren resultaat als voltooid geldt, kan je team controleren of aan de vereisten is voldaan. Het biedt klanten ook een duidelijke basis voor het beoordelen en goedkeuren van het afgeronde werk.

5 tips en trucs voor het definiëren van scopeverklaringen

Zelfs met een goed geschreven projectscopeverklaring kunnen onduidelijke verwachtingen en vage aannames later in het project nog steeds voor verwarring zorgen. Gebruik de volgende tips om duidelijkere, beter uitvoerbare scopeverklaringen op te stellen die belanghebbenden en projectteams gemakkelijker kunnen volgen.

1. Vermijd dubbelzinnige formuleringen

Vage formuleringen leiden tot misverstanden en maken het later in het project moeilijker om scopewijzigingen te beheren.

Schrijf bijvoorbeeld niet:

• “Ontwerpondersteuning inbegrepen”
• “Website-updates indien nodig”
• “Aanvullende revisies indien vereist”

Definieer:

• De exacte op te leveren resultaten
• Het aantal revisies
• Ondersteunde platforms of sjablonen
• Specifieke projectfasen of verantwoordelijkheden

Hoe specifieker je scopeverklaring is, hoe gemakkelijker het wordt om verwachtingen te beheren.

2. Bepaal wat 'voltooid' betekent

Leg duidelijk uit hoe op te leveren resultaten worden beoordeeld, goedgekeurd en afgerond.

Dit helpt situaties te voorkomen waarin:

• Belanghebbenden blijven eindeloos om herzieningen vragen
• Teams zijn het niet eens over de criteria voor voltooiing
• Opleveringen blijven vastzitten in beoordelingsrondes

Definieer:

• Goedkeuringsfasen
• Acceptatiecriteria
• Beperkingen voor herzieningen
• Vereisten voor formele goedkeuring

3. Leg aannames vroegtijdig vast

Veel projectproblemen ontstaan doordat teams aannemen dat iets is inbegrepen zonder dit duidelijk vast te leggen.

Gebruik de scopebeschrijving om aannames vast te leggen over:

• Contentlevering
• Beschikbaarheid van belanghebbenden
• Tools van derden
• Integraties
• Toegang tot platforms
• Goedkeuringstermijnen

Als het project afhankelijk is van iets externs, leg dit dan schriftelijk vast.

4. Plan voor scopewijzigingen

Zelfs sterke scopebeschrijvingen kunnen niet elk wijzigingsverzoek voorkomen. Projecten evolueren, prioriteiten verschuiven en belanghebbenden vragen vaak om extra werk nadat de aftrap heeft plaatsgevonden.

In plaats van scopewijzigingen volledig te proberen te voorkomen, definieer je:

• Hoe wijzigingsverzoeken worden afgehandeld
• Wie scopewijzigingen goedkeurt
• Hoe de gevolgen voor planning of budget worden beoordeeld
• Wanneer aanvullende schattingen of wijzigingsopdrachten vereist zijn

Hierdoor ontstaat een gestructureerd proces voor het afhandelen van wijzigingen zonder het project onnodig te verstoren.

5. Houd de scopebeschrijving overzichtelijk

Een scopebeschrijving moet gedetailleerd zijn, maar ook gemakkelijk snel door belanghebbenden kunnen worden beoordeeld.

Gebruik:

• Duidelijke koppen
• Opsommingstekens
• Tabellen
• Korte alinea's
• Afgebakende secties

Vermijd overdreven juridische of ingewikkelde taal, tenzij dit vereist is door je organisatie of contractstructuur.

Projectscopebeschrijving versus projectcharter versus werkbeschrijving

Projectcharters, projectscopebeschrijvingen en werkbeschrijvingen hebben verschillende doelen binnen projectmanagement, met belangrijke verschillen in inhoud, timing en gebruik:

Aspect	Projectcharter	Projectscopebeschrijving	Werkbeschrijving
Primair doel	Geeft het project formeel toestemming	Definieert de projectgrenzen en opleveringen	Definieert de volledige commerciële en projectovereenkomst
Projectfase	Wordt opgesteld tijdens de projectinitiatie	Wordt opgesteld tijdens de projectplanning	Wordt doorgaans opgesteld voordat het werk begint, tijdens het contracteren
Belangrijkste focus	Bedrijfsdoelen, belanghebbenden, budget en projectbevoegdheid	Scope, opleveringen, aannames, uitsluitingen en tijdlijnen	Scope, prijsstelling, juridische voorwaarden, tijdlijnen en verantwoordelijkheden
Detailniveau	Overzicht op hoofdlijnen	Gedetailleerd en gericht op uitvoering	Gedetailleerd, met contractuele en commerciële vereisten
Doelgroep	Opdrachtgevers, leidinggevenden en leidinggevende belanghebbenden	Projectteams, klanten en belanghebbenden bij de oplevering	Klanten, leveranciers, projectmanagers, inkoop- en juridische teams
Gebruik	Bevestigt de goedkeuring en richting van het project	Verduidelijkt wat wel en niet is inbegrepen, beheert verwachtingen en helpt scope-uitbreiding voorkomen	Regelt de werkrelatie en legt contractuele verplichtingen vast
Vorm	Zelfstandig document voor projectautorisatie	Zelfstandig document of onderdeel van een grotere projectovereenkomst	Formele overeenkomst waarin vaak een projectscopebeschrijving is opgenomen
Goedkeuring	Goedgekeurd door de projectsponsor of bevoegde leiding	Beoordeeld en goedgekeurd door relevante projectbelanghebbenden	Ondertekend of formeel aanvaard door bevoegde vertegenwoordigers van de klant en dienstverlener
Wijzigingsbeheer	Voor grote wijzigingen kunnen updates of hernieuwde autorisatie nodig zijn	Dient als basis voor het beoordelen en beheersen van scopewijzigingen	Definieert contractuele procedures voor het goedkeuren van wijzigingen in scope, kosten of tijdlijnen

Project Scope Statements | What You Need To Know In Just 60 Secs!

Veelgestelde vragen

Wat is het verschil tussen een projectscopeverklaring en een projectvoorstel?

Een projectvoorstel wordt doorgaans gebruikt vóór goedkeuring van het project, terwijl een projectscopeverklaring wordt gebruikt nadat het project is goedgekeurd.

Onderdeel	Projectvoorstel	Projectscopeverklaring
Projectfase	Opgesteld vóór goedkeuring van het project	Opgesteld tijdens de planning of start van het project
Primair doel	Helpt het werk te presenteren of binnen te halen	Helpt het werk te definiëren en te beheren
Belangrijkste focus	Oplossingen, prijsstelling en bedrijfswaarde	Scope, resultaten, tijdlijnen en projectgrenzen
Doelgroep	Besluitvormers die het voorstel beoordelen	Teams en belanghebbenden die de projectuitvoering beheren

Wat is het verschil tussen een scopeverklaring en een scopebeheerplan?

Een scopeverklaring definieert de daadwerkelijke scope van het project, terwijl een scopebeheerplan uitlegt hoe de projectscope gedurende het project wordt beheerd en gecontroleerd.

Onderdeel	Scopeverklaring	Scopebeheerplan
Primair doel	Definieert de projectresultaten en scopegrenzen	Definieert hoe de scope wordt beheerd en gecontroleerd
Belangrijkste focus	Wat wel en niet binnen het project valt	Hoe scopewijzigingen, goedkeuringen en validatie worden afgehandeld
Inhoud	Resultaten, aannames, uitsluitingen, tijdlijnen en beperkingen	Processen voor scopebeheer, goedkeuringswerkstromen en procedures voor wijzigingsbeheer
Gebruik	Helpt belanghebbenden de projectverwachtingen te begrijpen	Helpt teams de scope tijdens de projectuitvoering te beheren
Projectfase	Opgesteld tijdens de projectplanning	Opgesteld tijdens de projectplanning en het opzetten van het bestuur
Doel	Misverstanden over het projectwerk voorkomen	Ongecontroleerde scopewijzigingen en scope-uitbreiding voorkomen

Welke andere documenten worden doorgaans naast een projectscopeverklaring gebruikt?

Projectteams gebruiken gedurende de hele projectlevenscyclus vaak aanvullende project- en juridische documenten om verantwoordelijkheden te definiëren, vertrouwelijke informatie te beschermen en dienstverleningsovereenkomsten te beheren.

Veelvoorkomende voorbeelden zijn:

• NDA (geheimhoudingsovereenkomst): Beschermt vertrouwelijke informatie die vóór of tijdens projectbesprekingen tussen beide partijen wordt gedeeld
• MSA (raamovereenkomst voor dienstverlening): Definieert de langdurige juridische en commerciële relatie tussen de klant en de dienstverlener en regelt doorgaans toekomstige projectopdrachten voordat afzonderlijke werkverklaringen worden opgesteld
• ICA (overeenkomst met een zelfstandige opdrachtnemer): Definieert de werkrelatie, verantwoordelijkheden en juridische voorwaarden voor freelancers, opdrachtnemers of externe dienstverleners
• SLA (dienstverleningsovereenkomst): Definieert afspraken over hosting, onderhoud, ondersteuning, beschikbaarheid of dienstverlening tussen de klant en de dienstverlener
• Contracten: Definiëren de juridische verantwoordelijkheden, betalingsvoorwaarden, aansprakelijkheden en verplichtingen van beide partijen
• Projectvoorstellen: Beschrijven de voorgestelde oplossing, prijsstelling, aanpak en bedrijfswaarde vóór goedkeuring van het project

Kan een projectscopeverklaring worden bijgewerkt nadat het project is gestart?

Ja. Scopeverklaringen worden vaak bijgewerkt wanneer projectvereisten, tijdlijnen, resultaten of prioriteiten veranderen.

Elke scopewijziging moet echter een gedocumenteerd wijzigingsbeheerproces volgen waarin het volgende wordt uitgelegd:

• Wat er verandert
• Waarom de wijziging nodig is
• Gevolgen voor de tijdlijn
• Gevolgen voor het budget
• Vereiste goedkeuringen

Is een projectscopeverklaring juridisch bindend?

Een projectscopeverklaring is op zichzelf niet altijd juridisch bindend, tenzij deze is opgenomen in een ondertekend contract of een werkverklaring.

Scopeverklaringen zijn echter nog steeds belangrijk omdat ze het volgende documenteren:

• Projectverwachtingen
• Resultaten
• Scopegrenzen
• Goedkeuringsprocessen
• Verantwoordelijkheden

Veel teams nemen de scopeverklaring op in juridisch bindende projectovereenkomsten.

Wat nu?

Wil je contact leggen met andere digitale projectmanagers om hulpmiddelen en best practices te delen? Word lid van onze community en krijg toegang tot meer dan 100 sjablonen, voorbeelden en casussen, en kom in Slack in contact met honderden andere digitale projectmanagers.

OPMERKING: Niets van het bovenstaande is bedoeld als professioneel juridisch advies en ik ben niet bevoegd om juridisch advies van welke aard dan ook te geven. Als je geen sjablonen hebt voor deze niet-SoW-items, raad ik je sterk aan om de projectsjablonen in ons lidmaatschapsgedeelte te bekijken en deze naar eigen inzicht aan te passen met hulp van juridisch advies.