Wat zijn de meerwaarden van een scope document in web development?

Wat is een scope document en hoe ziet dit er uit?

Het is moeilijk om een juiste definitie van het Engelstalige woord ‘scope’ te geven omdat er geen juiste Nederlandstalige vertaling voor bestaat. De scope omvat alle functionaliteiten die een product of project definiëren. Het is deze scope die je tegen het einde van het project moet kunnen opleveren. Je duidt met ‘scope’ niet enkel aan wat de omvang is maar ook wat de beperkingen zijn.

Een scope document is een document waarin we de scope neerschrijven. Als je even op internet zoekt dan kan je verschillende templates terugvinden en verschillende blogs die beschrijven welke elementen dergelijk document moet bevatten.
Wij volgen echter onze eigen template die we opgesteld hebben op basis van onze ervaringen en behoeften:

In het scope document sommen we pagina per pagina alle functionaliteiten op. We maken hierbij een onderscheid tussen enerzijds de functionaliteiten die een bezoeker van een website kan uitvoeren en anderzijds de functionaliteiten die de klant ter beschikking heeft voor het beheren van de website. Deze vormen de eerste twee tabbladen van het document.
Daarnaast maken we van het document gebruik om belangrijke notities te bewaren, bepaalde zaken die we niet mogen vergeten doorheen het project. Bijvoorbeeld “het logo en de huisstijl worden aangeleverd door de klant”.

Als webdesign bureau hechten we veel aandacht aan SEO. Het document bestaat daarom uit een vierde tabblad ‘keywords’ waarin we de belangrijkste keywords noteren waarop de klant goed wilt scoren, zodat we ook hier rekening mee kunnen houden bij de uitwerking van de website.

1. Vermijden van de expectation gap

Bron: https://studio.uxpin.com/blog/write-good-product-requirements-document/

Bovenstaande illustratie toont duidelijk aan dat eenzelfde uitleg kan leiden tot verschillende assumpties zonder documentatie van de vereiste functionaliteiten.

Wanneer de klant zijn visie over het product verschilt van datgene de projectmanager, designer, information architect of ontwikkelaar begrijpt, dan spreken we van ‘the expectation gap’.

De expectation gap kan het verschil betekenen tussen het succes of falen van het project. Een klant zal logischerwijs niet tevreden zijn met het eindresultaat wanneer het niet voldoet aan zijn of haar verwachtingen.

Het scope document voor het verkleinen van de expectation gap

Bij Inventis start elk project met het opstellen van het scope document. Eenmaal opgesteld, bespreken we het document met de klant en stemmen we af of het voldoet aan hun verwachtingen.
Het is tijdens dit gesprek dat de klant vaak goed begint na te denken over het project en nog functionaliteiten aanhaalt waar hij niet eerder aan gedacht heeft en waar we dus nog geen rekening mee hebben gehouden.

Het is dus reeds in deze eerste fase dat eventuele ‘conflicten’ naar boven komen die zonder het scope document waarschijnlijk pas na de oplevering van de website worden ontdekt.

Vanaf de start van het project hebben we dus een goed zicht wat de klant voor ogen heeft. Doordat de ontwikkelaars vervolgens het project uitwerken op basis van het scope document brengen we de lijn van wat de klant verwacht en wat de ontwikkelaar daadwerkelijk ontwikkelt wat korter bij elkaar, wat leidt tot het verkleinen van de expectation gap.

Bron: http://www.atarimagazines.com/analog/issue79/engineering.php

Het opstellen van een scope document is echter geen garantie voor het minimaliseren van de expectation gap. Je moet er steeds rekening mee houden dat het als klant zijnde moeilijk is om de tekstueel uitgeschreven functionaliteiten te visualiseren. Vandaar dat het wirefame dat onmiddellijk volgt op het scope document een grote aanvullende rol speelt.

2. Een scopedocument is begrijpbaar voor iedereen

Het scope document heeft als grote meerwaarde dat het begrijpbaar is voor iedereen. Het is niet enkel verstaanbaar voor jezelf of voor de klant, maar ook voor iedereen die betrokken is bij de verdere uitwerking van het project.

Het is hierbij uiteraard wel belangrijk dat je het scope document ook wel degelijk in klare taal schrijft.

Tip: Vermijd vak jargon! Als je dan toch gebruik moet maken van een specifieke term, schrijf er dan de bijhorende definitie bij.

Het scope document gebruiken we doorheen het hele projectverloop en moet dus begrijpbaar zijn door het hele team dat bestaat uit verschillende profielen. Hieronder een overzicht van de verschillende profielen en voor welke taken ze gebruik kunnen maken van het scope document:

Project manager:

Waarvoor gebruikt een project manager een scope document?

  • opmaken van budget en timing
  • beheren van scope verandering
  • opvolgen van de vooruitgang van ontwikkeling
  • documenteren van het project

Information architect:

Waarvoor gebruikt een information architect een scope document?

  • verder analyseren van de website
  • uitwerken van een functioneel wireframe

Ontwikkelaar:

Waarvoor gebruikt een ontwikkelaar een scope document?

  • identificeren van tegenstrijdigheden of missende functionaliteiten
  • identificeren van de moeilijkheden/knelpunten binnen de ontwikkeling
  • ontwikkelen van alle functionaliteiten in scope

Tester:

Waarvoor gebruikt een tester een scope document?

  • testen van het project op basis van de werking zoals uitgeschreven in het scope document
  • controleren of alle functionaliteiten in scope werden uitgewerkt

Klant:

Waarvoor gebruikt een klant een scope document?

  • voorleggen van het project aan stakeholders
  • documenteren van het project

3. Scope management

Het is zeer belangrijk dat je scope onder controle blijft tijdens de implementatie van een project. Een verandering in scope heeft namelijk impact op het budget en de timing, twee factoren die je tijdens de implementatie liever niet ziet wijzigen.

Een goed opgesteld scope document draagt bij tot scope management doordat:

  • elke functionaliteit gedetailleerd gedocumenteerd staat waardoor het zeer duidelijk is wanneer een vraag leidt tot een verandering in scope
  • je zicht hebt op de impact van verandering op reeds uitgewerkte functionaliteiten
  • er eenvoudig een inschatting kan gemaakt worden van de kost en het risico van verandering

Aan welke eisen moet het scope document voldoen om verandering in scope nauwgezet te kunnen opvolgen?

  • het scope document wordt opgesteld VOOR de uitwerking van het project begint.
  • het scope document duidt duidelijk aan wat in scope zit en wat niet.
  • het scope document bevat voldoende detail. Er is namelijk een directe relatie tussen de graad van detail en het risico op scope toename gedurende de implementatie.

Heeft je project te maken met verandering in scope? Welke stappen onderneem je dan best?

Bron: https://wiki.smu.edu.sg/is480/IS480_Team_wiki%3A_2011T1_Motiva
  1. Je start met het documenteren van de gewenste verandering in het scope document.
  2. Op basis van de documentatie kan je de voor- en nadelen bespreken met het team en bekijken wat de impact is.
  3. De conclusies leg je voor aan de klant waarna de klant zijn goedkeuring, afkeuring of uitstel geeft
  • Afkeuring: scope blijft ongewijzigd
  • Goedkeuring: scope wordt aangepast en de planning, budget en timing wordt bijgestuurd
  • Uitstel: afhankelijk van de impact zal je de scope nu reeds wat moeten bijsturen om later te anticiperen op de uitgestelde verandering.

Hou er rekening mee dat de vraag voor een verandering niet enkel van de klant kan komen maar ook van iemand intern.

4. Risk management

De scope van een project wordt beperkt door de volgende factoren:

  • Beschikbare middelen
  • Tijd
  • Kwaliteit
Bron: http://zilicus.com/Resources/blog-2012/Back-to-basics-project-management-project-scope-management-part-ii.html

Alle drie de factoren hebben een directe invloed op de scope. In het geval van een project met een strikte deadline bijvoorbeeld zullen we eerder werken met een beperkte en sterk afgelijnde scope, terwijl er bij een project zonder deadline een ruimere scope mogelijk is met ook meer ruimte voor verandering.

Hou er echter rekening mee dat de factoren ook onderling invloed kunnen uitoefenen op elkaar. De scope van een project met een strakke deadline kan groeien als er bijvoorbeeld meer beschikbare middelen worden vrijgemaakt of als er wordt ingeboet op de kwaliteit van het project.

Vaak wordt er echter vergeten dat ook risico een invloed uitoefent op de scope. Een koppeling met een ander systeem houdt bijvoorbeeld een risico in. Je kan de koppeling wel vastleggen in de scope door het lezen van documentatie en het experimenteren met trial versions. Maar vaak kom je pas tijdens de ontwikkeling te weten of de documentatie volledig en juist was.

Risico kan ervoor zorgen dat je meer tijd spendeert aan bepaalde functionaliteiten dan oorspronkelijk ingeschat, dat je uiteindelijk andere middelen moet inzetten dan degenen die beschikbaar zijn of dat je kwaliteit eronder lijdt.

Het scope document houdt rekening met risico door een zekere marge te verwerken in de inschattingen. Neem onderstaande afbeelding als voorbeeld. De marge kan je mee laten oplopen met het risico niveau. Zo laten wij het risico niveau variëren tussen 1 en 5. Om terug te komen op het voorbeeld van de koppeling met een ander systeem: hoe onvollediger de documentatie, hoe groter het risico en dus hoe groter de marge.

Het antwoord op de vraag of een scope document een meerwaarde kan betekenen lijkt me vanzelfsprekend ja. Hoe weet je namelijk wat te ontwikkelen als niet neergeschreven staat hoe de website of applicatie verondersteld is te werken.

Een scope document zal je geen garantie bieden dat je project succesvol wordt, daarvoor zijn meer factoren in het spel. Het draagt er echter wel toe bij dat je de verwachtingen van de klant tegemoetkomt, of zelfs nog beter, overtreft. Je zal er niet alleen nieuwe klanten mee aantrekken maar ook je huidige klanten behouden, wat zeker zo belangrijk is.

Een laatste tip dus als je op zoekt bent naar een webdesign bureau, vraag eens hoe zij werken aan het voldoen van de klantenbehoeften. Bij Inventis staan deze alleszins centraal!