För större projekt rekommenderar jag att du skapar en spårbarhetsmatris för krav. Läs mer här:

Krav Spårbarhetsmatris i projektledning (Exempel + mall)

Process nr 2: Hur man kan slå ner krav och definiera omfattning

Här är ett krav :

”Webbplatsen pmbasics101.com bör ha möjlighet att samla in e-postmeddelanden och skicka ut ett PDF-dokument i utbyte.”

Vad krävs för att uppfylla detta krav?

1. Välj en leverantör av e-posttjänster.
2. Skapa ett konto.
3. Skapa formuläret för att samla e-postmeddelanden.
4. Implementera det utformade formuläret.
5. Installera plugin från e-postleverantören.
6. Ladda upp PDF-dokumentet.
7. Aktivera formuläret.
8. Testa formuläret.

Det är bara en lista med nödvändiga åtgärder. Om jag skulle sätta det korrekt som leverans- och arbetspaket skulle det hamna i:

1. E-postopt -i formuläret
   1.1 Rapport om posttjänstleverantörer
   1.2 Godkänd formulärdesign
   1.3 Anmälningsformulär för testmiljön
   1.4 Testrapport

Så, Hur gör kommer du från det kravet på en mening till det faktiska arbetets omfattning?

A) Du kan hitta någon som har relevant erfarenhet eller kunskap

Det kan vara intressenter, kunder eller externa konsulter, ämnesexperter eller andra parter.

Så, ditt mål är att skaffa dem från projektgruppen eller bara ta kontakt för att kommunicera. De kan ha en lösning redan.

Annars kan du få vägledning eller råd. Det är en grundläggande teknik som du kommer att använda i stor utsträckning.

B) Utför produktanalysen

Det är tillämpligt när du behöver skapa en produkt snarare än en tjänst eller ett resultat.

Denna teknik fokuserar på nedbrytning av produktvärde. Precis som WBS gör med omfattningen.

Dessutom måste du analysera produkten ur ergonomiska och funktionella synvinklar; och fatta sedan beslut om material eller processer som uppfyller prestandakraven.

25 Exempel på produktanalys

Sammantaget är ditt mål att definiera konkreta leveranser.

C) Använd alternativgenereringstekniken

Denna teknik fungerar bra när du har kunskap om projektets natur.

Så du måste hitta den bästa lösningen för Motsvara kraven. I de flesta fall använder du brainstorming för att få alternativen.

Vad är målet?

Du måste tydligt definiera vad som är och vad som inte ingår i projektets omfång.

Process # 3: Hantera projektomfång med en PM-programvara

Du kan säkert spåra projektets omfång i vilken tillgänglig app som helst. Till exempel kommer Google Drive, Evernote eller MS Word att göra.

Det finns dock allvarliga fördelar med att använda integrerad programhanteringsprogramvara för att hålla allt på ett ställe.

Helst vill du måste kunna länka krav till projektleveranserna.

Sedan från leverans till specifika uppgifter med uppskattningar, relaterade risker och defekter.

Till exempel kan jag rekommendera Paymo. Det är en av de bästa apparna för personligt bruk och för små projekt. Dessutom har den fantastiska funktioner för tidsspårning och fakturering.

Process nr 4: Hur man kontrollerar projektomfattning

Det räcker inte att identifiera 100% av projektets omfattning i början. . Att 100% kommer att förändras under projektets livstid.

Så du behöver ett sätt att övervaka, kontrollera och göra ändringar i omfattningen.

Kuren är välkänd. Det är en arbetsfördelningsstruktur.

Nåväl, du behöver också ett tydligt arbetsflöde för att införa ändringar i alla projektområden när arbetsmängden ändras.

Det handlar dock om en integrerad förändringshanteringsprocess.

Så, vad är fångsten?

Du behöver en högkvalitativ WBS. Dessutom behöver du ett icke-nördigt sätt att beskriva projektets omfattning. Därför behöver du också ett uttalande om projektets omfattning. Vi kommer att diskutera det nedan.

Om du deltar i ett smidigt projekt är det tydligt definierade omfattningen av steg eller iteration ännu viktigare. Tänk inte att smidig sparar dig från noggrann dokumentation av det arbete som ska utföras. Håll din Sprint-eftersläpning och användarberättelser snygga. Tillämpa en enkel regel: ”En nykomling ska förstå vad som behöver göras från beskrivningen av användarberättelsen.”

Hur man validerar räckvidd

Ibland måste du få en formell signera att en leverans uppfyller intressenternas förväntningar.

Det är viktigt att göra det kontinuerligt under hela projektet.Även om du leder ett plandrivet projekt bör ingenting hindra dig från att tillhandahålla produktsteg för granskning.

Varför behöver du det här?

Du vill inte få allt ändringsförfrågningarna, alla brister och ”mindre ändringar i projektet” i slutändan.

Du berövar dig själv möjligheten att faktiskt integrera en förändring i projektet.

Ju närmare projektavslutningen är, desto mindre tid och resurser kommer att finnas kvar. Dessutom kommer intressenterna att vara mindre benägna att förhandla om ändringar i omfattning, tidslinje eller budget. De kommer också att sätta mer press på teamet för att få vad de behöver.

Att bara säga det uppenbara:

Det är mycket viktigt att ha ett tydligt beskrivet och godkänt projektomfång från början.

När en leverans inte uppfyller förväntningarna kommer det att finnas korrigeringar.

Det är ditt ansvar att bevisa om en korrigering är en begäran om ändring och därför bör den integreras ordentligt. Annars är det en defekt och du måste göra gott. Ibland på egen bekostnad.

Hur validerar du faktiskt omfattningen hos kunderna?

På vilket projekt som helst kan du använda Scrum-liknande demomöte.

Bara förbereda en kort demonstration av leveransen. Förklara aktuell projektstatus och framsteg. Efter det, påpeka kända brister och pågående delar.

Samla också in feedback från kunden. Senare kan du tillhandahålla all stödjande dokumentation och rapporter som krävs enligt dina policyer.

Nedre raden:

Samla in feedback från intressenter kontinuerligt. Förhandla om villkoren för införandet av nya ändringsförfrågningar. Håll projektet Scope Baseline uppdaterad.

Skaffa min mall för projektomfattningshantering

Uppfinn inte hjulet! Det kan vara kostsamt för dig.

Klicka bara på knappen nedan och få min utfyllnadsmall. Den levereras med en resursguide om allt du behöver veta om scope management.

Varför hela räckvidden Baslinjen är kritisk för ditt projekt?

Vanligtvis startar ett projekt och vi får krav i olika former.

Till exempel: e-post, PDF-filer, möten, mockups, felrapporter, vad som helst .

Och naturligtvis förbereder vi inte en projektstadga eller något liknande. Dålig praxis!

I de flesta fall diskuterar vi inte ens affärsfallet för projektet.

Vi skapar vanligtvis en arbetsfördelningsstruktur.

Det används dock bara internt och går aldrig till kunden. Sedan bryter vi ner arbetet till aktiviteterna och uppskattar projektet. Vi använder en uppskattningsteknik nedifrån och upp.

Nu kommer den första förväntningskontrollen:

Vi presenterar uppskattningar för projektet.

Du förstår, det finns tydligen en brist på öppenhet här. Kunden vet inte vilket arbete vi faktiskt uppskattat.

Om uppskattningen ligger nära kundens förväntningar kommer han inte att gräva i detaljerna. Detta beror på att han redan är redo att spendera så mycket pengar och tid. Han vill inte slösa bort deras dyrbara tid.

Här är sanningen:

Många organisationer och projektledare döljer ineffektivitet. bakom sådana tysta avtal.

Det är ett ämne för ett separat inlägg, men det är grundorsaken till många av dina problem.

Vad händer härnäst?

Vi startar projektkörningen! Förr eller senare kommer kunden att be om att lägga till ytterligare ett arbete.

Därefter hittar vi en del av oidentifierat arbete. Senare kommer kvalitetsproblem att dyka upp. De kommer att äta upp mycket tid.

Sammantaget lämnar vi in en leverans för att ta reda på att vi gjorde något fel.

Och det är då kunden informerar oss om att han glömde något och det bör läggas till så fort.

Tro mig, du upplever det mer än en gång.

Definition av räckvidd baslinje

”Räckvidd baslinje är godkänd av ett omfattningsuttalande, arbetsfördelningsstruktur (WBS) och dess tillhörande WBS-ordlista, som endast kan ändras genom formell ändringsstyrning och används som jämförelsegrund. ” -PMBOK®-guide

Vad är ett projektomfattande uttalande?

Definition av Project Scope Statement

Project Scope Statement är en berättande beskrivning av en produkt och projektomfång.

Det används som en skriftlig bekräftelse på vad ditt projekt ska producera och hur.

Vad är nyckeln till ett värdefullt uttalande om projektets omfattning?

Jag tror att du behöver använda termer och språk som alla intressenter förstår. Denna del av projektets omfattning är främst för kunden.

OK, vad ska inkluderas?

Motivering av ett projekt

Det är en kort beskrivning av företagets behov. Ibland räcker en mening. Resten bör vara i en projektstadga

Produktomfattning

Det är en beskrivning av egenskaper, egenskaper och funktionalitet hos en produkt eller en tjänst som du kommer att producera.

Tänk på att du samlat krav från olika intressenter. Så antar inte att alla håller reda på varje krav. Det är inte alltid klart hur mycket arbete som krävs för att leverera ett krav.

Det är den primära platsen för att anpassa förväntningarna hos viktiga intressenter.

Du måste visa mängden och komplexiteten. av det arbete som krävs för att uppfylla olika krav. Lägg därför mest ansträngningar i det här avsnittet.

Godtagningskriterier

Det är villkoren som måste uppfyllas innan projektleveranser accepteras.

Du kan inkludera en acceptabel nivå och antalet fel också här.

Leveranser

Det är en beskrivning av alla leveranser som ditt projekt kommer att producera.

Det kan inkludera produkten eller service, projektdokumentation, produktmanualer, utbildningsmaterial för din produkt osv.

Uteslutningar av projekt

Här måste du ange vad som ligger utanför projektets omfång.

Ganska ofta vill en del av intressenterna ha något specifikt. Den andra delen av intressenter eller en kund stöder det inte.

Det är därför en konfliktsituation. När konflikten är löst och det beslutades att ta bort något från projektets omfång, lägg det här.

Var specifik och mycket tydlig om det. Det sparar tid i framtiden.

För det första behöver du inte se över dessa projektundantag igen. Intressenter kan försöka inkludera dem senare under projektgenomförandet.

Om inte något dramatiskt förändras bör du inte slösa tid på att granska uteslutningar.

För det andra, om det inte står klart, kan någon förväntar dig fortfarande att du kommer att leverera den. Mata inte falska förväntningar. Det blir lättare att lämna in projektet i slutet.

Begränsningar

Allt som begränsar dig att leverera produkten effektivt bör anges här.

Antaganden

Det är osäkerheterna som inte kunde klargöras just nu.

Du måste acceptera några av dem under planeringen. Om ett antagande visar sig vara ogiltigt har du rätt att ändra projektplanen.

En kund ska godkänna projektets omfattning. I själva verket är det ett formellt och ömsesidigt avtal.

Dessutom står det att du är fast besluten att leverera beskrivna resultat under ett bestämt antagande och med tydliga begränsningar. Å andra sidan accepterar kunden att acceptera det angivna resultatet.

Det betyder inte att vi inte kan ändra projektets omfattning. Nej. Det betyder att vi måste ändra avtalet för att göra en ändring.

Organisera projektets omfattning med WBS

WBS är en obligatorisk del av omfattningens baslinje för alla projekt. Stor eller liten. Agil eller planstyrd.

Det finns redan en komplett guide till en struktur för arbetsfördelning på PM-grunderna. Jag kommer inte att upprepa det här.

Det är bara en avgörande punkt som jag vill betona:

Leveranser som beskrivs i Project Scope Statement bör komma in i WBS som det är. Håll leveranser konsekventa under hela projektet.

Lägg allt du vet i WBS Dictionary

WBS Dictionary är ett dokument som beskriver det arbete som ska göras för varje arbetspaket.

Som en modern premiärminister skulle jag säga att det borde vara en del av ett uppgiftsspårningssystem. Det mesta av programhanteringsprogramvaran ger dig möjligheten att hålla denna information på ett ställe.

Därför föreslår jag inte att du skapar ett separat dokument. Att upprätthålla WBS-ordlistan är mycket arbete. Leta efter integrerade lösningar.

Du kan inkludera all information som specificerar en komponent i WBS. Till exempel kan WBS-ordlistan innehålla:

• Beskrivning av arbetet
• Antaganden och begränsningar
• Ansvariga personer eller organisationer
• Milstolpar
• Relaterade aktiviteter
• Nödvändiga resurser
• Kostnadsberäkningar eller budget
• Acceptkriterier
• Referenser annan dokumentation

Så vad som passar dina behov och hjälper dig att integrera WBS i andra processer.

Slutsats

”Det finns ingen vind som blåser rätt för sjömannen som inte vet var hamnen är.”

Du kan inte leda projektet till ett framgångsrikt resultat utan att veta vad som behöver göras.

Återigen vill jag betona den punkten.

Även om du befinner dig i den agila miljön och omfattningen är inte klart definierad för hela projektet, du måste fortfarande planera ett sätt att definiera, hantera, spåra och ändra projektets omfång.

Båda för en iterationsnivå och det slutliga projektresultatet.

Jag rekommenderar också att läsa:

• Utvalda artikel: Hur man blir en IT-projektledare utan erfarenhet
• Nästa i serie: Ultimate Guide on How to Create a Robust Work Breakdown Structure
• Föregående i serien: Krav Spårbarhetsmatris i projektledning (Ex gott om + mall)