Statement of Work: Ultieme gids & sjabloon voor 2026
Het geheime recept: Een statement of work (SoW) verduidelijkt verantwoordelijkheden en wat wel en niet binnen de scope van uw project valt. Als het zorgvuldig wordt opgesteld, kan het vertragingen helpen verminderen en de winstgevendheid verhogen.
Essentiële ingrediënten: Een goed opgestelde SoW vat het doel, de deliverables, de governance en de tijdlijnen samen. Dit is cruciaal om verwachtingen op elkaar af te stemmen en een soepel verloop van het project te waarborgen.
De kunst van communicatie: Ken uw SoW goed en deel deze met belanghebbenden om ervoor te zorgen dat iedereen gedurende het hele project op één lijn blijft, verwarring te voorkomen en de samenwerking te verbeteren.
Een effectieve werkbeschrijving is het ultieme hulpmiddel om problemen te voorkomen voordat ze ontstaan. Het is de enige bron van waarheid die verduidelijkt waarvoor jij en je team verantwoordelijk zijn bij de uitvoering van het project.
Een onduidelijke werkbeschrijving kan leiden tot vertragingen, extra werk en een lagere winstgevendheid. Zo stel je er een op die duidelijke verwachtingen schept, jou en je team beschermt en de kans op succes van het project maximaliseert.
Wat is een werkbeschrijving?
Een werkbeschrijving (SoW) is een overeenkomst tussen een klant en een bureau, aannemer of dienstverlener waarin wordt vastgelegd wat er binnen een project is inbegrepen.
De SoW is het projectcontract dat verwachtingen vastlegt en op elkaar afstemt. Het vat het doel van het project samen en definieert de op te leveren resultaten, standaarden, criteria en vereisten voor elke projectfase.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Als je al een projectplan of tijdlijn en een projectraming hebt opgesteld, dan is de SoW de kers op de taart: deze bevat de sappige details die alles met elkaar verbinden.
Een goed geschreven SoW definieert duidelijk wat je team wel en niet zal doen binnen een project. Zo kun je je aannemers beter aansturen en zowel je planning als je bedrijfsresultaat beschermen.
Sjabloon voor werkbeschrijving en voorbeeld [Downloaden]
Gelukkig heb ik het sjabloon voor je! Mijn sjabloon voor een werkbeschrijving is gedetailleerd en klaar voor gebruik. Het helpt antwoord te geven op de vragen: “wat moet ik opnemen in mijn SoW?”, “hoeveel details heb ik nodig?” en “waar sla ik projectinformatie op?”
Mijn SoW-sjabloon is ongeveer 12 pagina's lang (1000 woorden) en beschikbaar in een indeling die compatibel is met Microsoft Word & Google Docs, zodat je het naar wens kunt aanpassen. Het sjabloon bevat geen merknaam en gebruikt een algemene opmaak, zodat je de inhoud eenvoudig kunt bewerken en van je logo kunt voorzien.
Het eerste gedeelte beschrijft de algemene projectinformatie, terwijl het tweede gedeelte de details van elke fase definieert. Je kunt volgende fasen toevoegen als je project dat vereist. Het sjabloon kan worden gedownload in de sjablonenbibliotheek van DPM Membership.
Vind hier meer sjablonen voor projectmanagement.
Wat moet een werkbeschrijving bevatten?
De SoW moet op zijn minst duidelijk het volgende bevatten:
- Projectdoelstellingen: doelverklaring, d.w.z. waarom het project wordt uitgevoerd en wat het zal bereiken
- Projectgovernance: wie goedkeuring heeft om wat te doen
- Werkverdelingsstructuur (WBS): hoe het project wordt uitgevoerd, welke aanpak wordt gevolgd en welke specifieke taken en fasen worden afgerond
- Op te leveren resultaten: wat er wordt geproduceerd en wanneer (met een specifieke vervaldatum)
- Uitvoeringsperiode: wanneer het project wordt opgeleverd, samen met de benodigde tijd, de geschatte start- en einddatum en een lijst met mijlpalen
- Raming: projectprijzen, samen met een betalingsschema
- Aannames: wat wel en niet binnen de projectscope valt, inclusief acceptatiecriteria, d.w.z. wat wel en niet aanvaardbaar is om op te leveren
- Werkvereisten: andere bijzondere vereisten en specificaties over hoe het project moet worden uitgevoerd, zoals specifieke aanpakken of projectmanagementtools. Voeg functionele vereisten toe voor softwareontwikkelingsprojecten.
Als de werkbeschrijving te vaag, te breed of te algemeen is, kan dat ruimte laten voor meerdere interpretaties. Dit kan later in een project tot misverstanden leiden. Aan de andere kant kan een SoW het project beperken als deze te gedetailleerd is. Je kunt uiteindelijk werk uitvoeren dat niet nodig is, simpelweg omdat je hebt gezegd dat je het zou doen.
Typen werkbeschrijvingen
Er zijn drie hoofdtypen werkbeschrijvingen: ontwerp of detail, inspanningsniveau en prestatiegericht. Elk type bepaalt hoe je projectvereisten specificeert, de voortgang meet en het opgeleverde werk beoordeelt.
- Werkbeschrijving voor ontwerp of detail: specificeert precies hoe het werk moet worden uitgevoerd, inclusief processen, materialen, technische vereisten en op te leveren resultaten. Dit type werkt het beste wanneer je strikte controle over de uitvoering nodig hebt, zoals bij bouw- of gereguleerde projecten. Het geeft leveranciers echter minder flexibiliteit om hun eigen aanpak te kiezen.
- Werkbeschrijving op basis van inspanningsniveau (LOE): definieert de hoeveelheid tijd, middelen of arbeid die een leverancier moet leveren, in plaats van een vaste reeks op te leveren resultaten. Dit is nuttig voor advieswerk, doorlopende ondersteuning en projecten waarin vereisten kunnen evolueren. Je hebt duidelijke rapportage en toezicht nodig om ervoor te zorgen dat de bestede tijd waarde oplevert.
- Prestatiegerichte werkbeschrijving: richt zich op de resultaten die een leverancier moet behalen, in plaats van voor te schrijven hoe het werk moet worden uitgevoerd. Dit type definieert meetbare resultaten, prestatienormen en acceptatiecriteria. Ik raad deze aanpak aan wanneer je succes duidelijk kunt definiëren, maar leveranciers flexibiliteit wilt geven in de manier waarop ze dit bereiken.
Het juiste type hangt af van de mate van controle die je over het werk nodig hebt en van hoe duidelijk je de verwachte resultaten kunt definiëren. Je kunt ook elementen van verschillende typen combineren om aan de vereisten van je project te voldoen.
Een werkbeschrijving schrijven
Houd deze tips en trucs in gedachten bij het opstellen van een SoW:
1. Deel het op
Baken niet af wat je niet kent. In plaats van een SoW voor een volledig project te proberen op te stellen, deel je het project op in fasen en ontwikkel je voor elke fase een afzonderlijke SoW naarmate het project vordert.
2. Maak een plan
Bepaal wat je doet en hoe. Definieer de op te leveren resultaten en het proces dat nodig is om deze te produceren, zodat je duidelijk kunt aangeven wat wel en niet binnen de projectscope valt.
3. Plaats het in context
Leg uit waarom je het project uitvoert. Zelfs als de details van het plan zich ontwikkelen, moet de SoW je helpen beoordelen of het project een succes was.
4. Wees specifiek
Stel de grenzen van het project vast. Beperk het risico op misinterpretatie door je klant door de omvang van het uit te voeren werk te definiëren en dit waar mogelijk te kwantificeren, zodat de klant niet meer verwacht dan waarvoor je budget hebt gereserveerd.
5. Maak aannames duidelijk
Leg de basisregels vast. Gebruik projectscopeverklaringen om wederzijdse verwachtingen uit te leggen en te beschrijven wat waar moet zijn om je team het project goed te laten uitvoeren.
6. Vereenvoudig
Wees duidelijk en beknopt. Zoek een balans tussen de SoW zo beknopt mogelijk maken en het werk dat moet worden uitgevoerd toch zorgvuldig specificeren. Vermijd woorden met meerdere interpretaties en gebruik eenvoudige taal om ervoor te zorgen dat de SoW gemakkelijk te begrijpen is.
7. Deel het
Als projectmanager moet je je SoW van binnen en van buiten kennen en de inhoud ervan aan je belanghebbenden kunnen communiceren. Zorg ervoor dat belanghebbenden een exemplaar van de SoW hebben gezien en blijf tijdens de hele projectlevenscyclus naar de SoW verwijzen.
Een Statement of Work gebruiken
Als je je niet aan de SoW houdt, is de kans groot dat je uiteindelijk:
- Niet helemaal levert wat gewenst was
- Je projectdoelen te laat bereikt
- Je budget overschrijdt
Dus hoe houd je je aan het plan en zorg je dat je SoW op koers blijft?
1. Ken je SoW van binnen en van buiten
Je moet je SoW beter kennen dan wie dan ook. Houd een exemplaar bij de hand — ik raad aan om het naar je projectmanagementsoftware te uploaden voor centrale toegang, maar je kunt het ook afdrukken.
Wat je ook doet, zorg dat de SoW beschikbaar is wanneer je aan een gesprek deelneemt of in een vergadering zit; zodra er vragen over zijn, kijkt iedereen naar jou voor antwoorden.
2. Maak belanghebbenden vertrouwd met de SoW
Het is niet voldoende dat alleen jij de SoW kent. Je moet de SoW actief onder de aandacht brengen bij je team om het risico op scope-uitbreiding te beperken.
Zelfs als je team betrokken was bij het opstellen van de SoW, is deze sinds de start van het project ongetwijfeld veranderd en verder ontwikkeld. Zorg ervoor dat teamleden begrijpen:
- Projectactiviteiten
- Op te leveren resultaten
- Aannames
- Hoe succes eruitziet
Stuur de SoW rond, druk exemplaren af, wat dan ook. Zorg er gewoon voor dat deze zichtbaar is en dat iedereen zich erin heeft verdiept. Het laatste wat je wilt, is dat een teamlid instemt met een ad-hocverzoek van een klant (dat geen onderdeel is van het uitvoeringsplan) of een belangrijke contractuele vereiste over het hoofd ziet.
3. Zorg voor draagvlak binnen je team
Blind instemmen is geen goede zaak. Neem de tijd om het definitieve plan met je projectteam door te nemen en zorg voor hun oprechte draagvlak. Als ze denken dat iets niet logisch is of uiteindelijk niet zal bijdragen aan het succes van het project, bespreek het dan voordat je iedereen aan het werk zet.
Als alles vanaf het begin duidelijk is, verminder je het aantal noodzakelijke overlegmomenten onderweg, waardoor je team in zijn eigen tijd met samenwerkingstools kan werken.
Het heeft nooit waarde om werk uit te voeren alleen omdat de SoW het voorschrijft. Als het goed is voor het project, moet je bij de klant kunnen beargumenteren waarom de SoW moet worden aangepast.
4. Houd je SoW voortdurend in gedachten
Wees niet bang om de SoW ter sprake te brengen tijdens klantvergaderingen — sterker nog, een beoordeling van de SoW zou een vast agendapunt moeten zijn. Bespreek of de SoW nog steeds geldig is en of alles volgens plan verloopt.
Als er zaken moeten worden aangepast, zorg dan dat je begrijpt waarom, voer de wijzigingen door en zorg ervoor dat iedereen daarvan op de hoogte is.
5. Let op scope-uitbreiding
Scope-uitbreiding vindt plaats wanneer de reikwijdte van het project ogenschijnlijk stiekem begint te groeien. Meestal gebeurt dit wanneer een verzoek om een wijziging van de reikwijdte begint als één ding en vervolgens langzaam verandert in een veel groter project dat je winst aantast.
Het is vervelend, maar het gebeurt nu eenmaal. Klanten zitten vol met (meestal) goede ideeën en begrijpen vaak niet wat de gevolgen van hun verzoeken zijn voor de planning of het budget.
Om scope-uitbreiding te beheersen, moet je het probleem signaleren, benoemen en oplossen. Wanneer je ad-hocverzoeken ziet binnensluipen, verwijs dan terug naar je SoW. Als jij en de klant het erover eens zijn dat het buiten de scope valt, maar de klant toch wil dat het wordt uitgevoerd, moet je een wijzigingsverzoek indienen (oftewel een update van de SoW).
Het wijzigingsverzoek moet het volgende beschrijven:
- De wijziging ten opzichte van de oorspronkelijke SoW
- Hoe je het verzoek gaat uitvoeren
- De gevolgen voor budget en planning
6. Wees vanaf het begin waakzaam
Projecten die ontsporen, doen dat vaak al in de beginfase van het project.
Dat gebeurt wanneer projectmanagers de boot niet willen laten schommelen door problemen aan te kaarten wanneer dat wel zou moeten. De gevolgen op een later moment van te flexibel zijn in de eerste paar weken van een project kunnen enorm zijn.
Je moet niet alleen achterstanden inhalen, maar wekt ook bij de klant de verwachting dat de SoW flexibel is. Ze kunnen ervan uitgaan dat je toekomstige verzoeken om wijzigingen in de scope zult honoreren, ongeacht de gevolgen daarvan voor hun budget of planning.
Als je dit laat gebeuren, kun je net zo goed afscheid nemen van het nut van je SoW.
Hier is een zeer luchtige uitleg:
Wat doet een werkbeschrijvingsdocument?
De werkbeschrijving dient om:
- Je te helpen bepalen wat je in rekening moet brengen
- Het extra detailniveau te bieden dat kostenramingen en projectplannen doorgaans niet bevatten
- De klant gerust te stellen over wat hij of zij voor het geld krijgt
- Je team verantwoordelijk te houden met duidelijke, openbaar overeengekomen tijdlijnen
- Scope creep buiten de deur te houden door te specificeren wat niet is inbegrepen
- Kristalheldere verwachtingen voor beide partijen vast te leggen, zodat miscommunicatie en conflicten proactief kunnen worden aangepakt
Als je denkt dat dit veel werk zal zijn, heb je niet helemaal ongelijk. Maar door vooraf werk te maken van het opstellen en overeenkomen van een gedetailleerde SoW, help je het project (winstgevend) te laten slagen en voorkom je later in de levenscyclus van het project veel hoofdpijn.
Veelvoorkomende valkuilen bij werkbeschrijvingen en hoe je ze voorkomt
Zelfs een goed geschreven werkbeschrijving kan leiden tot geschillen, vertragingen en onverwachte kosten als belangrijke details ontbreken. Hier zijn zes veelvoorkomende valkuilen waarop je moet letten en hoe je ze voorkomt:
- Vage scope en deliverables: Onduidelijke beschrijvingen van wat is inbegrepen kunnen leiden tot misverstanden en scope creep. Definieer specifieke deliverables, vereisten en uitsluitingen. Gebruik meetbare acceptatiecriteria, zodat iedereen het eens is over wat als afgerond werk geldt.
- Onrealistische tijdlijnen: Al te ambitieuze deadlines kunnen leiden tot gehaast werk, gemiste mijlpalen en budgetoverschrijdingen. Stel je planning op basis van realistische inspanningsramingen, beschikbare middelen en afhankelijkheden op. Neem tijdsreserves op voor beoordelingen, goedkeuringen en onverwachte vertragingen.
- Onduidelijke rollen en verantwoordelijkheden: Wanneer eigenaarschap niet is vastgelegd, worden taken gemist en lopen beslissingen vertraging op. Wijs voor elke belangrijke deliverable, goedkeuring en beslissing een eigenaar aan. Gebruik een RACI-matrix om duidelijk te maken wie verantwoordelijk is, eindverantwoordelijk is, wordt geraadpleegd en wordt geïnformeerd.
- Slecht wijzigingsbeheer: Zonder een formeel proces kunnen kleine verzoeken het project uitbreiden tot buiten de oorspronkelijke scope. Leg vast hoe belanghebbenden wijzigingen moeten indienen, beoordelen, goedkeuren en documenteren. Vereis schriftelijke goedkeuring voor wijzigingen die gevolgen hebben voor kosten, planning of deliverables.
- Ontbrekende acceptatiecriteria: Zonder overeengekomen normen loop je het risico op meningsverschillen over de vraag of het werk aan de verwachtingen voldoet. Definieer meetbare acceptatiecriteria voor elke deliverable, inclusief wie deze goedkeurt en hoeveel tijd die persoon heeft om de deliverable te beoordelen.
- Onduidelijke betalingsvoorwaarden: Onduidelijke betalingsschema's en voorwaarden kunnen geschillen tussen klanten en leveranciers veroorzaken. Koppel betalingen aan specifieke mijlpalen of goedgekeurde deliverables. Leg betalingsbedragen, vervaldata, facturatievereisten en de gevolgen van betwist werk voor de betaling vast.
Andere documenten die verband houden met de werkbeschrijving
Er zijn enkele vergelijkbare en aan de SoW gerelateerde documenten die vaak voor SoW's worden aangezien, ook al dienen ze andere doelen.
| Document | Wat het is | Hoe het verschilt van een SoW | Wanneer je het gebruikt |
|---|---|---|---|
| Werkverklaring | Een overeenkomst tussen een opdrachtgever en een dienstverlener waarin de projectscope, opleveringen, tijdlijnen, verantwoordelijkheden en kosten worden vastgelegd. | Legt het specifieke werk vast dat moet worden uitgevoerd, hoe het wordt opgeleverd en met welke voorwaarden beide partijen instemmen. | Wanneer je formeel wilt vastleggen wat wel en niet bij een project is inbegrepen voordat het werk begint. |
| Raamovereenkomst voor dienstverlening (MSA) | Een contract waarin de algemene voorwaarden voor een voortdurende relatie tussen opdrachtgever en leverancier worden vastgelegd. | Een MSA omvat bredere voorwaarden, zoals betalingsvoorwaarden, vertrouwelijkheid en aansprakelijkheid. Een SoW definieert het werk voor een afzonderlijk project. | Bij het aangaan van een nieuwe klantrelatie of het plannen van meerdere projecten met dezelfde leverancier. Een MSA gaat vaak samen met de eerste SoW en vermindert herhaalde onderhandelingen. |
| Projecthandvest | Een document dat een project formeel autoriseert en de doelstellingen, verwachte resultaten en belangrijkste belanghebbenden beschrijft. | Een projecthandvest richt zich op het algemene doel en de richting van het project. Een SoW geeft meer details over specifieke opleveringen, vereisten en uitvoering. | Bij de start van een project, vooral bij grotere projecten die uit meerdere fasen bestaan. Het helpt belanghebbenden gedurende de uitvoering op één lijn te houden over projectdoelstellingen. |
| Offerteaanvraag (RFP) | Een document dat organisaties gebruiken om voorstellen op te vragen bij potentiële leveranciers, bureaus of opdrachtnemers. Het beschrijft de projectvereisten, scope en verwachtingen. | Een RFP communiceert wat een organisatie nodig heeft voordat een leverancier wordt geselecteerd. Een SoW definieert het overeengekomen werk nadat de leverancier is geselecteerd. | Bij het vergelijken van potentiële leveranciers voor een project. Leveranciers reageren met voorstellen waarin ze hun aanpak, methodologieën en ervaring beschrijven. |
Veelgestelde vragen over verklaringen van werkzaamheden
Ik heb antwoorden verzameld op enkele veelgestelde vragen over project-SoW’s.
Is een verklaring van werkzaamheden noodzakelijk?
Ja, een verklaring van werkzaamheden is 1000% noodzakelijk.
Een verklaring van werkzaamheden draait om het beheren en documenteren van verwachtingen. En zoals bij elke overeenkomst is het het beste als degenen die de overeenkomst aangaan precies weten waarmee ze instemmen.
\u003c!– /wp:paragraph –\u003e \u003c!– wp:paragraph –\u003e
Als je een \u003ca href=\u0022https://thedigitalprojectmanager.com/projects/pm-methodology/agile-methodologies/\u0022\u003eagile\u003c/a\u003e aanpak voor documentatie hanteert—dus zo weinig mogelijk en alleen waar nodig—denk je misschien dat de tijd van het opstellen van een SoW voorbij is.
\u003c!– /wp:paragraph –\u003e \u003c!– wp:paragraph –\u003e
Als projectmanager is het in jouw belang om iets te hebben waarmee je kunt zeggen: “sorry, dat valt buiten de scope” wanneer een klant vraagt of de raming voor een banneradvertentiecampagne ook een landingspagina voor de campagne omvat.
\u003c!– /wp:paragraph –\u003e \u003c!– wp:paragraph –\u003e
Het niet schrijven (of niet goed schrijven) van een verklaring van werkzaamheden is vaak de reden dat klanten en bureaus met elkaar in conflict komen. Wanneer er onzekerheid of dubbelzinnigheid is, leidt dat tot spanning. Het doel van een SoW is niet om een klant in de val te lokken, maar om precies vast te leggen wat er wordt gedaan, hoe, wanneer en tegen welke kosten, zodat er een gezamenlijk begrip ontstaat van de \u003ca href=\u0022https://thedigitalprojectmanager.com/projects/scope-management/requirements-gathering-guide/\u0022\u003eprojectvereisten\u003c/a\u003e.
Zijn verklaringen van werkzaamheden belangrijk voor interne projecten?
Of je er daadwerkelijk een opstelt, is aan jou, maar het \u003cem\u003ekan \u003c/em\u003eecht helpen.
Een verklaring van werkzaamheden voor interne projecten is minder formeel; het is meer een plan van aanpak dan wat anders. Je team stelt verwachtingen vast en beschrijft de taken en projectresultaten die het moet opleveren. Het document hoeft geen formele SoW te zijn, zoals de verklaring die je voor een klant zou kunnen opstellen, maar het is wel nuttig om een vorm van SoW te hebben.
Hoe gedetailleerd moet een verklaring van werkzaamheden zijn?
\u003c!– wp:paragraph –\u003e
Het korte antwoord is: uiterst gedetailleerd over de zaken die ertoe doen. Minder gedetailleerd over de zaken die waarschijnlijk zullen veranderen.
Je moet specifiek zijn om:
\u003col\u003e
\u003cli\u003eTe bewijzen dat je begrijpt wat de doelen van het project zijn en dat je die vanaf het begin van het project kunt \u003ca href=\u0022https://thedigitalprojectmanager.com/projects/pm-methodology/project-initiation-guide-how-start-projects/\u0022\u003ecommuniceren\u003c/a\u003e\u003c/li\u003e
\u003cli\u003eTe begrijpen hoe succes wordt gemeten\u003c/li\u003e
\u003cli\u003eZo weinig mogelijk ruimte voor interpretatie te laten (en zo de deur voor scope-uitbreiding te sluiten)\u003c/li\u003e
\u003cli\u003eErvoor te zorgen dat twijfel en onenigheid vroegtijdig worden aangepakt\u003c/li\u003e
\u003cli\u003eJe te verzekeren tegen lastige klanten\u003c/li\u003e
\u003c/ol\u003e
De rest is aan jou.
Onthoud: het doel is niet om voor de vorm overdreven strikt te zijn; je SoW bestaat om ervoor te zorgen dat jij en je klant vanaf het begin op één lijn zitten. Gebruik zoveel details als nodig zijn om dat te bereiken.
Wanneer kun je het beste een verklaring van werkzaamheden opstellen?
Begin vroeg en maak je SoW in fasen.
In onze gids voor het \u003ca href=\u0022https://thedigitalprojectmanager.com/project-management/project-estimate/\u0022\u003eramen van projecten\u003c/a\u003e bespreken we drie fasen van het ramen:
\u003c!– wp:list {\u0022ordered\u0022:true} –\u003e
\u003col\u003e
\u003cli\u003eSchatting op hoofdlijnen\u003c/li\u003e
\u003cli\u003eBudget\u003c/li\u003e
\u003cli\u003eSoW-raming\u003c/li\u003e
\u003c/ol\u003e
\u003c!– /wp:list –\u003e
Het is een goed idee om tijdens de fase van de schatting op hoofdlijnen al aantekeningen voor je SoW te maken. Begin met het documenteren van je SoW terwijl je de budgetraming opstelt, zodat je tegen de tijd dat je de definitieve SoW-raming maakt de informatie hebt die je nodig hebt om de SoW ter goedkeuring naar de klant te sturen.
Wat staat er niet in de verklaring van werkzaamheden?
SoW’s zijn een cruciaal onderdeel van de \u003cem\u003eplanning\u003c/em\u003e van een project, niet van de \u003cem\u003euitvoering\u003c/em\u003e ervan (hoewel ze natuurlijk gedurende de levenscyclus van het project kunnen worden bijgewerkt om veranderende vereisten weer te geven). Daarom bevatten project-SoW’s doorgaans niet:
\u003cul\u003e
\u003cli\u003e\u003cspan style=\u0022letter-spacing: 0.1px\u0022\u003eRisico’s en \u003c/span\u003e\u003ca href=\u0022https://thedigitalprojectmanager.com/projects/risk-management/risk-management-plan/\u0022 style=\u0022letter-spacing: 0.1px;background-color: #ffffff\u0022\u003erisicobeperkende plannen\u003c/a\u003e\u003c/li\u003e
\u003cli\u003e\u003ca href=\u0022https://thedigitalprojectmanager.com/projects/communication/project-status-report-guide/\u0022\u003eProjectstatusrapporten\u003c/a\u003e / voortgang ten opzichte van de planning\u003c/li\u003e
\u003cli\u003eProjectuitgaven\u003c/li\u003e
\u003cli\u003e\u003ca href=\u0022https://thedigitalprojectmanager.com/projects/quality-management/project-management-lessons-learned-template/\u0022\u003eGeleerde lessen\u003c/a\u003e\u003c/li\u003e
\u003c/ul\u003e
\u003cul\u003e
\u003cli style=\u0022list-style-type: none\u0022\u003e\u003c/li\u003e
\u003c/ul\u003e
\u0026nbsp;
Wat nu?
Wil je de fijnere kneepjes van projectafbakening en -planning beheersen? Bekijk dan de door experts samengestelde training van de DPM School.
