Voor grotere projecten raad ik aan om een Requirements Traceability Matrix te maken. Lees hier meer:

Traceerbaarheidsmatrix voor vereisten in projectbeheer (voorbeeld + sjabloon)

Proces 2: vereisten aanpakken en bereik definiëren

Hier is een vereiste :

“De website pmbasics101.com moet de mogelijkheid hebben om e-mails te verzamelen en in ruil daarvoor een pdf-document te verzenden.”

Wat is er nodig om aan deze vereiste te voldoen?

1. Selecteer een mailingserviceprovider.
2. Maak een account.
3. Ontwerp het formulier om e-mails te verzamelen.
4. Implementeer het ontworpen formulier.
5. Installeer de plug-in van de mailingserviceprovider.
6. Upload het pdf-document.
7. Activeer het formulier.
8. Test het formulier.

Het is slechts een lijst met vereiste acties. Als ik het correct zou plaatsen als Deliverable en Work Packages, zou het eindigen in:

1. Email Opt -in formulier
   1.1 Rapport over mailingserviceproviders
   1.2 Goedgekeurd formulierontwerp
   1.3 Opt-in-formulier in de testomgeving
   1.4 Testrapport

Dus, hoe doen u van die eis van één zin naar de werkelijke omvang van het werk komt?

A) U kunt iemand vinden met relevante ervaring of kennis

Dit kunnen belanghebbenden, klanten of externe consultants, materiedeskundigen of andere partijen.

Uw doel is dus om ze van het projectteam te werven of gewoon contact met ons op te nemen om te communiceren. Misschien hebben ze al een oplossing.

Anders krijg je misschien aanwijzingen of advies. Het is een basistechniek die u breed zult toepassen.

B) Voer de productanalyse uit

Het is van toepassing wanneer u een product moet maken in plaats van een dienst of resultaat.

Deze techniek is gericht op het ontbinden van productwaarde. Net zoals WBS dat doet met de scope.

Verder moet u het product analyseren vanuit ergonomische en functionele oogpunten; en vervolgens beslissingen nemen over materialen of processen die voldoen aan de prestatie-eisen.

25 Voorbeelden van de productanalyse

Al met al is het uw doel om tastbare resultaten te definiëren.

C) Gebruik de techniek voor het genereren van alternatieven

Deze techniek werkt goed als je ervaring hebt met de aard van het project.

Je moet dus de beste oplossing voldoen aan de vereisten. In de meeste gevallen zult u brainstormen gebruiken om de alternatieven te krijgen.

Wat is het doel?

U moet duidelijk definiëren wat wel en niet deel uitmaakt van de projectomvang.

Proces # 3: Projectscope beheren met een PM-software

Natuurlijk kun je de projectscope in elke beschikbare app volgen. Google Drive, Evernote of MS Word zijn bijvoorbeeld voldoende.

Er zijn echter serieuze voordelen aan het gebruik van geïntegreerde projectbeheersoftware om alles op één plek te bewaren.

Idealiter zou u moeten in staat zijn om requirements te koppelen aan de projectresultaten.

Vervolgens, van deliverable naar specifieke taken met schattingen, gerelateerde risico’s en defecten.

Ik kan bijvoorbeeld Paymo aanbevelen. Het is een van de beste apps voor persoonlijk gebruik en voor kleine projecten. Bovendien heeft het geweldige mogelijkheden voor tijdregistratie en facturering.

Proces # 4: hoe je de projectscope beheert

Het is niet voldoende om in het begin 100% van de projectscope te identificeren . Die 100% ZAL veranderen tijdens de levensduur van het project.

Dus je hebt een manier nodig om de scope te bewaken, te controleren en wijzigingen aan te brengen.

De remedie is algemeen bekend. Het is een Work Breakdown Structure.

Nou, je hebt ook een duidelijke workflow nodig om veranderingen door te voeren in alle gebieden van het project wanneer de hoeveelheid werk verandert.

Het is echter een kwestie van een geïntegreerd verandermanagementproces.

Dus, wat is het addertje onder het gras?

Je hebt een hoogwaardige WBS nodig. Bovendien heb je een niet-nerdy manier nodig om de projectomvang te beschrijven. Daarom heeft u ook een Project Scope Statement nodig. We zullen het hieronder bespreken.

Als u zich in een agile project bevindt, is de duidelijk gedefinieerde reikwijdte van increment of iteratie zelfs nog belangrijker. Denk niet dat agile u een grondige documentatie van het uit te voeren werk bespaart. Houd uw Sprint Backlog en gebruikersverhalen netjes. Pas een eenvoudige regel toe: “Een nieuwkomer moet begrijpen wat er moet gebeuren aan de hand van de beschrijving van het gebruikersverhaal.”

Hoe bereik te valideren

Af en toe moet u een formele geef aan dat een resultaat voldoet aan de verwachtingen van de belanghebbenden.

Het is cruciaal om dat continu te doen tijdens het project.Zelfs als u een planmatig project leidt, mag niets u ervan weerhouden productverhogingen ter beoordeling aan te bieden.

Waarom heeft u dit nodig?

U wilt niet alle de wijzigingsverzoeken, alle defecten en uiteindelijk “kleine wijzigingen aan het project”.

Je ontneemt jezelf de mogelijkheid om een wijziging daadwerkelijk in het project te integreren.

Hoe dichter u bij de afsluiting van het project bent, hoe minder tijd en middelen er over zijn. Bovendien zullen belanghebbenden minder geneigd zijn om te onderhandelen over wijzigingen in de reikwijdte, tijdlijn of budget. Ze zullen ook meer druk uitoefenen op het team om krijgen wat ze nodig hebben.

Gewoon het voor de hand liggende zeggen:

Het is zeer belangrijk om vanaf het begin een duidelijk omschreven en goedgekeurde projectomvang te hebben.

Wanneer een product voldoet niet aan de verwachtingen, er zullen correcties plaatsvinden.

Het is uw verantwoordelijkheid om te bewijzen of een correctie een wijzigingsverzoek is en daarom correct moet worden geïntegreerd. Anders is het een defect, en je moet het goedmaken. Soms op eigen kosten.

Hoe valideer je daadwerkelijk bereik bij klanten?

Op elk project kun je Scrum-achtige Demo Meeting gebruiken.

Gewoon bereid een korte demonstratie van het resultaat voor. Leg de huidige projectstatus en voortgang uit. Wijs daarna op bekende defecten en onderdelen in uitvoering.

Verzamel ook feedback van de klant. Later kunt u alle ondersteunende documentatie en rapporten verstrekken die door uw beleid worden vereist.

Kort gezegd:

Verzamel continu feedback van belanghebbenden. Onderhandel over de voorwaarden voor de introductie van nieuwe wijzigingsverzoeken. Houd de Project Scope Baseline up-to-date.

Haal mijn Project Scope Management Template

Vind het wiel niet uit! Het kan duur voor je zijn.

Klik gewoon op de onderstaande knop en ontvang mijn invul-sjabloon. Het wordt geleverd met een bronnengids over alles wat u moet weten over scopebeheer.

Waarom het hele bereik Baseline is cruciaal voor uw project?

Meestal start een project en ontvangen we vereisten in verschillende vormen.

Bijvoorbeeld: e-mails, pdf’s, vergaderingen, mockups, bugrapporten, wat dan ook .

En natuurlijk stellen we geen Project Charter of iets dergelijks op. Slechte praktijk!

In de meeste gevallen bespreken we niet eens de businesscase voor het project.

Meestal maken we een Work Breakdown Structure.

Het wordt echter alleen intern gebruikt en gaat nooit naar de klant. Vervolgens splitsen we het werk op in de activiteiten en schatten we het project in. We gebruiken een bottom-up schattingstechniek.

Nu komt de eerste verwachtingencheck:

We presenteren schattingen voor het project.

Zie je, er is blijkbaar een gebrek aan transparantie hier. De klant weet niet welk werk we eigenlijk hebben ingeschat.

Als de schatting dicht bij de verwachtingen van de klant ligt, gaat hij niet in op de details. Dit komt omdat hij klaar is om dat bedrag en die tijd al uit te geven. Hij wil hun kostbare tijd niet verspillen.

Hier is de waarheid:

Veel organisaties en projectmanagers verbergen inefficiënties achter zulke stille overeenkomsten.

Het is een onderwerp voor een apart bericht, maar het is de hoofdoorzaak van veel van uw problemen.

Wat gebeurt er daarna?

We beginnen met de uitvoering van het project! Vroeg of laat zal de klant vragen om nog een stuk werk toe te voegen.

Daarna zullen we een deel van niet-geïdentificeerd werk vinden. Later zullen er kwaliteitsproblemen optreden. Ze zullen veel tijd opeten.

Al met al geven we een levering af om erachter te komen dat we iets verkeerd hebben gedaan.

En dat is wanneer de klant ons laat weten dat hij iets vergeten en het moet zo snel mogelijk worden toegevoegd.

Geloof me, je ervaart het meer dan eens.

Scope Baseline Definition

”Scope baseline is de goedgekeurde versie van een scope-instructie, work breakdown structure (WBS) en het bijbehorende WBS-woordenboek, dat alleen kan worden gewijzigd via een formele wijzigingsbeheerprocedure en die als basis voor vergelijking wordt gebruikt. ” -PMBOK® Guide

Wat is een Project Scope Statement?

Definitie van de Project Scope Statement

Project Scope Statement is een verhalende beschrijving van een product en projectomvang.

Het wordt gebruikt als een schriftelijke bevestiging van wat uw project gaat produceren en hoe.

Wat is de sleutel tot een waardevolle verklaring van de projectomvang?

Ik denk dat je termen en taal moet gebruiken die elke belanghebbende begrijpt. Dit stuk baseline van de projectscope is voornamelijk voor de klant.

OK, wat moet worden opgenomen?

Rechtvaardiging van een project

Het is een korte beschrijving van de behoeften van het bedrijf. Soms is één zin voldoende. De rest moet in een projecthandvest blijven.

Productomvang

Het is een beschrijving van de kenmerken, eigenschappen en functionaliteit van een product of dienst die u gaat produceren.

Houd er rekening mee dat u vereisten van verschillende belanghebbenden heeft verzameld. Ga er dus niet vanuit dat ze allemaal elke vereiste bijhouden. Het is ook niet altijd duidelijk hoeveel werk er nodig is om aan een vereiste te voldoen.

Het is de eerste plaats om de verwachtingen van de belangrijkste belanghebbenden op één lijn te brengen.

U moet de hoeveelheid en complexiteit laten zien. van het werk dat nodig is om aan verschillende eisen te voldoen. Steek daarom de meeste moeite in deze sectie.

Acceptatiecriteria

Dit zijn de voorwaarden waaraan moet worden voldaan voordat projectresultaten worden geaccepteerd.

U kunt een acceptabel niveau en het aantal defecten hier ook.

Deliverables

Het is een beschrijving van alle deliverables die uw project zal opleveren.

Het kan het product of service, projectdocumentatie, producthandleidingen, educatief materiaal voor uw product, enz.

Projectuitsluitingen

Hier moet u specificeren wat buiten de projectomvang valt.

Heel vaak wil een deel van de stakeholders iets specifieks. Het andere deel van de belanghebbenden of een klant ondersteunt het niet.

Daarom is het een conflictsituatie. Zodra het conflict is opgelost en er is besloten iets uit de projectomvang te verwijderen, plaatst u het hier.

Wees er specifiek en duidelijk over. Het bespaart tijd in de toekomst.

Ten eerste hoeft u deze projectuitsluitingen niet opnieuw te bezoeken. Belanghebbenden kunnen proberen ze later tijdens de uitvoering van het project op te nemen.

Maar tenzij er iets dramatisch verandert, moet u geen tijd verspillen aan het herzien van uitsluitingen.

Ten tweede, tenzij het duidelijk wordt vermeld, verwacht nog steeds dat je het gaat bezorgen. Voed geen valse verwachtingen. Het is gemakkelijker om het project aan het einde over te dragen.

Beperkingen

Alles wat u beperkt om het product efficiënt te leveren, moet hier worden vermeld.

Aannames

Het zijn de onzekerheden die op dit moment niet konden worden opgehelderd.

Sommige ervan moet je accepteren tijdens het plannen. Indien een aanname ongeldig blijkt te zijn, heeft u het recht om het projectplan te wijzigen.

Een klant dient de projectomvangverklaring goed te keuren. In feite is het een formele en wederzijdse overeenkomst.

Er staat ook dat u zich ertoe verbindt de beschreven resultaten te leveren onder de duidelijke aanname en met duidelijke beperkingen. Aan de andere kant stemt de klant ermee in het gespecificeerde resultaat te accepteren.

Dit betekent niet dat we de projectomvang niet kunnen wijzigen. Nee. Het betekent dat we de overeenkomst moeten wijzigen om een wijziging aan te brengen.

Organiseer de projectomvang met WBS

WBS is een verplicht onderdeel van de scope-baseline voor alle projecten. Groot of klein. Agile of plan-gestuurd.

Er is al een complete gids voor een Work Breakdown Structure over PM Basics. Ik zal het hier niet herhalen.

Er is slechts één cruciaal punt dat ik wil benadrukken:

Te leveren producten die worden beschreven in de Project Scope Statement zouden in WBS moeten komen zoals ze zijn. Houd deliverables consistent gedurende het hele project.

Zet alles wat je weet in WBS Dictionary

WBS Dictionary is een document dat het werk beschrijft dat voor elk werkpakket moet worden gedaan.

Als moderne premier zou ik zeggen dat het een onderdeel zou moeten zijn van een taakvolgsysteem. De meeste projectbeheersoftware geeft u de mogelijkheid om deze informatie op één plaats te bewaren.

Daarom zou ik u niet aanraden om een apart document te maken. Het onderhouden van het WBS-woordenboek is veel werk. Zoek naar geïntegreerde oplossingen.

U kunt alle informatie opnemen die een component specificeert in de WBS. Het WBS-woordenboek kan bijvoorbeeld bevatten:

• Beschrijving van het werk
• Veronderstellingen en beperkingen
• Verantwoordelijke mensen of organisaties
• Mijlpalen
• Gerelateerde activiteiten
• Vereiste middelen
• Kostenramingen of budget
• Acceptatiecriteria
• Verwijst naar andere documentatie

Dus wat past bij uw behoeften en helpt u WBS in andere processen te integreren.

Conclusie

“Er is geen goede wind voor de zeeman die niet weet waar de haven is.”

Je kunt het project niet naar een succesvol resultaat leiden zonder te weten wat er moet gebeuren.

Nogmaals, ik wil dat punt benadrukken.

Zelfs als je bevindt je in de Agile-omgeving en de scope is niet duidelijk gedefinieerd voor het hele project, je moet nog steeds een manier plannen om de projectscope te definiëren, beheren, volgen en wijzigen.

Beide voor een iteratieniveau en het uiteindelijke projectresultaat.

Ik raad ook aan om te lezen:

• Uitgelicht artikel: Hoe word je een IT-projectmanager zonder ervaring
• Volgende in de serie: Ultieme gids voor het creëren van een robuuste Work Breakdown Structure
• Vorige in de serie: Matrix voor tracering van vereisten in projectbeheer (bijv. ruim + sjabloon)