For større projekter anbefaler jeg at oprette en Sporbarhedsmatrix med krav. Lær mere her:

Krav Sporbarhedsmatrix i projektstyring (eksempel + skabelon)

Process nr. 2: Sådan nedbrydes krav og definerer omfang

Her er et krav :

“Webstedet pmbasics101.com skal kunne samle e-mails og sende et PDF-dokument til gengæld.”

Hvad skal der til for at opfylde dette krav?

1. Vælg en mailtjenesteudbyder.
2. Opret en konto.
3. Design formularen til at indsamle e-mails.
4. Implementer den designede formular.
5. Installer plugin fra mailtjenesteudbyderen.
6. Upload PDF-dokumentet.
7. Aktiver formularen.
8. Test formularen.

Det er bare en liste over nødvendige handlinger. Hvis jeg anbragte det korrekt som en leverings- og arbejdspakke, ville det ende med at:

1. Email Opt -i form
   1.1 rapport om posttjenesteudbydere
   1.2 Godkendt formdesign
   1.3 Tilmeldingsformular til testmiljøet
   1.4 Testrapport

Så, hvordan kommer du fra det krav om en sætning til det faktiske omfang af arbejdet?

A) Du kan finde nogen, der har relevant erfaring eller viden

Det kan være interessenter, kunder eller eksterne konsulenter, fageksperter eller andre parter.

Så dit mål er at erhverve dem fra projektteamet eller bare komme i kontakt for at kommunikere. De har muligvis allerede en løsning.

Ellers kan du få vejledning eller rådgivning. Det er en grundlæggende teknik, som du vil anvende bredt.

B) Udfør produktanalyse

Det gælder, når du har brug for at oprette et produkt i stedet for en service eller et resultat.

Denne teknik fokuserer på nedbrydning af produktværdi. Ligesom WBS gør med omfanget.

Desuden skal du analysere produktet ud fra ergonomiske og funktionelle synspunkter; og tag derefter beslutninger om materialer eller processer, der overholder ydelseskravene.

25 Eksempler på produktanalyse

Alt i alt er dit mål at definere håndgribelige leverancer.

C) Brug den alternative generationsteknik

Denne teknik fungerer godt, når du har ekspertise i projektets art.

Så du skal finde den bedste løsning til leve op til kravene. I de fleste tilfælde bruger du brainstorming for at få alternativerne.

Hvad er målet?

Du skal klart definere, hvad der er og hvad der ikke er en del af projektets omfang.

Process nr. 3: Administrer projektomfang med en PM-software

Du kan helt sikkert spore projektets omfang i enhver tilgængelig app. For eksempel gør Google Drive, Evernote eller MS Word.

Der er dog alvorlige fordele ved at bruge integreret projektstyringssoftware til at holde alt på ét sted.

Ideelt set er du skal være i stand til at linke krav til projektleverancer.

Derefter fra leverbare til specifikke opgaver med estimater, relaterede risici og mangler.

For eksempel kan jeg anbefale Paymo. Det er en af de bedste apps til personlig brug og til små projekter. Derudover har den gode tidssporings- og faktureringsfunktioner.

Process nr. 4: Sådan styres projektomfang

Det er ikke nok at identificere 100% af projektets omfang i starten . At 100% vil ændre sig i løbet af projektets levetid.

Så du har brug for en måde at overvåge, kontrollere og foretage ændringer i omfanget.

Kuren er velkendt. Det er en arbejdsopdelingsstruktur.

Nå, du har også brug for en klar arbejdsgang for at introducere ændringer i alle områder af projektet, når arbejdsmængden ændres.

Det er dog et spørgsmål om en integreret ændringsstyringsproces.

Så hvad er fangsten?

Du har brug for et WBS af høj kvalitet. Desuden har du brug for en ikke-nørdet måde at beskrive projektets omfang på. Derfor har du også brug for en erklæring om projektets omfang. Vi diskuterer det nedenfor.

Hvis du er på et smidigt projekt, er det klart definerede omfang af stigning eller iteration endnu vigtigere. Tro ikke, at agil sparer dig for grundig dokumentation af det arbejde, der skal udføres. Hold din Sprint Backlog og brugerhistorier pæne. Anvend en enkel regel: “En nybegynder skal forstå, hvad der skal gøres fra beskrivelsen af brugerhistorien.”

Sådan valideres omfanget

En gang imellem skal du få en formel underskrive, at en leverance lever op til interessenternes forventninger.

Det er afgørende at gøre det kontinuerligt gennem hele projektet.Selvom du leder et planstyret projekt, bør intet forhindre dig i at give produktsteg til gennemgang.

Hvorfor har du brug for dette?

Du ønsker ikke at få alt ændringsanmodningerne, alle mangler og “mindre ændringer i projektet” i sidste ende.

Du fratager dig muligheden for faktisk at integrere en ændring i projektet.

Jo tættere du er på projektlukningen, desto mindre tid og ressourcer vil der være tilbage. Desuden vil interessenter være mindre tilbøjelige til at forhandle om ændringer i omfang, tidslinje eller budget. De vil også lægge mere pres på teamet for at få det, de har brug for.

Bare med det åbenlyse:

Det er meget vigtigt at have et klart beskrevet og godkendt projektomfang fra starten.

Når en leveres ikke opfylder forventningerne, vil der være rettelser.

Det er dit ansvar at bevise, om en rettelse er en anmodning om ændring, og derfor skal den integreres ordentligt. Ellers er det en defekt, og du skal rette op. Nogle gange for egen regning.

Hvordan validerer du faktisk omfanget hos kunderne?

På ethvert projekt kan du bruge Scrum-lignende demo-møde.

Bare forberede en kort demonstration af det leverede. Forklar den aktuelle projektstatus og status. Derefter skal du påpege kendte mangler og dele, der er i gang.

Indsaml også feedback fra kunden. Senere kan du levere enhver understøttende dokumentation og rapporter, der kræves i henhold til dine politikker.

Bundlinie:

Indsaml løbende feedback fra interessenter. Forhandle vilkårene for introduktionen af nye anmodninger om ændring. Hold projektets anvendelsesområde baseline opdateret.

Få min skabelon til projektomfangsstyring

Opfind ikke hjulet! Det kan være dyrt for dig.

Klik bare på knappen nedenfor og få min skabelon til udfyldning af tomme felter. Den leveres med en ressourcevejledning om alt hvad du behøver at vide om omfangsstyring.

Hvorfor hele omfanget Baseline er kritisk for dit projekt?

Normalt starter et projekt, og vi modtager krav i forskellige former.

For eksempel: e-mails, PDF-filer, møder, mockups, fejlrapporter, uanset hvad .

Og selvfølgelig forbereder vi ikke et projektcharter eller lignende. Dårlig praksis!

I de fleste tilfælde diskuterer vi ikke engang business case for projektet.

Vi opretter normalt en arbejdsopdelingsstruktur.

Det bruges dog kun internt og går aldrig til kunden. Derefter nedbryder vi arbejdet til aktiviteterne og estimerer projektet. Vi bruger en bottom-up estimeringsteknik.

Nu kommer den første forventningskontrol:

Vi præsenterer estimater for projektet.

Ser du, der er tilsyneladende en manglende gennemsigtighed her. Kunden ved ikke, hvilket arbejde vi faktisk estimerede.

Hvis estimatet er tæt på kundens forventninger, graver han ikke i detaljerne. Dette skyldes, at han allerede er klar til at bruge den mængde penge og tid. Han ønsker ikke at spilde deres dyrebare tid.

Her er sandheden:

Mange organisationer og projektledere skjuler ineffektivitet. bag sådanne tavse aftaler.

Det er et emne for et separat indlæg, men det er grundårsagen til mange af dine problemer.

Hvad sker der derefter?

Vi starter projektudførelsen! Før eller senere beder kunden om at tilføje endnu et stykke arbejde.

Derefter finder vi en del af uidentificeret arbejde. Senere vises kvalitetsproblemer. De spiser meget tid.

Alt i alt overleverer vi en levering for at finde ud af, at vi har gjort noget forkert.

Og det er her kunden oplyser, at han glemte noget, og det skal tilføjes hurtigst muligt.

Tro mig, du oplever det mere end én gang.

Definition af omfangsgrundlag

”Omfangsbaseline er den godkendte version af en omfangserklæring, arbejdsnedbrydningsstruktur (WBS) og dens tilknyttede WBS-ordbog, der kun kan ændres gennem formel ændringsstyringsprocedure og bruges som sammenligningsgrundlag. ” -PMBOK®-vejledning

Hvad er en erklæring om projektets omfang?

Definition af erklæring om projektets omfang

Erklæring om projektets omfang er en fortællende beskrivelse af et produkt- og projektomfang.

Det bruges som en skriftlig bekræftelse af, hvad dit projekt skal producere, og hvordan.

Hvad er nøglen til en værdifuld erklæring om projektomfang?

Jeg mener, at du skal bruge termer og sprog, som enhver interessent forstår. Dette stykke projektomfangsbaseline er primært til kunden.

OK, hvad skal der medtages?

Begrundelse for et projekt

Det er en kort beskrivelse af virksomhedens behov. Nogle gange er en sætning nok. Resten skal forblive i et projektcharter

Produktomfang

Det er en beskrivelse af karakteristika, træk og funktionalitet for et produkt eller en tjeneste, du vil producere.

Husk, at du har samlet krav fra forskellige interessenter. Så antag ikke, at alle holder styr på hvert krav. Det er heller ikke altid klart, hvor meget arbejde der kræves for at levere et krav.

Det er det primære sted at tilpasse forventningerne hos de vigtigste interessenter.

Du skal vise mængden og kompleksiteten af det arbejde, der kræves for at imødekomme forskellige krav. Brug derfor mest muligt dette afsnit.

Acceptkriterier

Det er de betingelser, der skal være opfyldt, før projektleverancer accepteres.

Du kan medtage en acceptabelt niveau og antallet af mangler også her.

Leverancer

Det er en beskrivelse af alle leverancer, som dit projekt vil producere.

Det kan omfatte produktet eller service, projektdokumentation, produktmanualer, undervisningsmateriale til dit produkt osv.

Projektekskluderinger

Her skal du specificere, hvad der er uden for projektets omfang.

Ofte ønsker en del af interessenterne noget specifikt. Den anden del af interessenter eller en kunde understøtter det ikke.

Derfor er det en konfliktsituation. Når konflikten er løst, og det blev besluttet at fjerne noget fra projektets omfang, skal du lægge det her.

Vær specifik og meget klar over det. Det sparer tid i fremtiden.

For det første behøver du ikke se disse projektekskluderinger igen. Interessenter kan forsøge at medtage dem senere under projektudførelsen.

Men medmindre noget dramatisk ændres, bør du ikke spilde tid på at gennemgå ekskluderinger.

For det andet, medmindre det tydeligt er angivet, kan nogen muligvis forventer stadig, at du vil levere det. Giv ikke falske forventninger. Det bliver lettere at aflevere projektet i slutningen.

Begrænsninger

Alt, hvad der begrænser dig til at levere produktet effektivt, bør angives her.

Antagelser

Det er usikkerheden, der ikke kunne afklares i øjeblikket.

Du er nødt til at acceptere nogle af dem under planlægningen. Hvis en antagelse viser sig at være ugyldig, har du ret til at ændre projektplanen.

En kunde skal godkende projektomfangserklæringen. Faktisk er det en formel og gensidig aftale.

Den siger også, at du er forpligtet til at levere beskrevne resultater under en bestemt antagelse og med klare begrænsninger. På den anden side accepterer kunden at acceptere det angivne resultat.

Det betyder ikke, at vi ikke kan ændre projektets omfang. Nej. Det betyder, at for at foretage en ændring – er vi nødt til at ændre aftalen.

Organiser projektets omfang med WBS

WBS er en obligatorisk del af anvendelsesområdet for alle projekter. Stor eller lille. Agil eller plandrevet.

Der er allerede en komplet guide til en Work Breakdown Structure on PM Basics. Jeg gentager det ikke her.

Der er kun et afgørende punkt, jeg vil understrege:

De leverancer, der er beskrevet i projektomfangserklæringen, skal komme ind i WBS, som den er. Hold leverancer konsistente gennem hele projektet.

Sæt alt, hvad du kender, i WBS Dictionary

WBS Dictionary er et dokument, der beskriver det arbejde, der skal udføres for hver arbejdspakke.

Som en moderne premierminister vil jeg sige, at det skal være en del af et opgavesporingssystem. Det meste af projektstyringssoftwaren giver dig mulighed for at opbevare disse oplysninger ét sted.

Derfor vil jeg ikke foreslå, at du opretter et separat dokument. Vedligeholdelse af WBS-ordbogen er meget arbejde. Se efter integrerede løsninger.

Du kan medtage alle oplysninger, der specificerer en komponent i WBS. For eksempel kan WBS-ordbogen omfatte:

• Beskrivelse af arbejdet
• Antagelser og begrænsninger
• Ansvarlige personer eller organisationer
• Milepæle
• Relaterede aktiviteter
• Påkrævede ressourcer
• Omkostningsestimater eller budget
• Acceptkriterier
• Referencer anden dokumentation

Så uanset hvad der passer til dine behov og hjælper dig med at integrere WBS i andre processer.

Konklusion

“Der er ingen vind, der blæser rigtigt for sømanden, der ikke ved, hvor havnen er.”

Du kan ikke føre projektet til et vellykket resultat uden at vide, hvad der skal gøres.

Endnu en gang vil jeg understrege dette punkt.

Selvom du befinder dig i det agile miljø, og omfanget er ikke klart defineret for hele projektet, du skal stadig planlægge en måde at definere, styre, spore og ændre projektets omfang.

Begge for et iterationsniveau og det endelige projektresultat.

Jeg anbefaler også at læse:

• Fremhævet artikel: Sådan bliver du IT-projektleder uden erfaring
• Næste i series: Ultimate Guide on How to Create a Robust Work Breakdown Structure
• Forrige i serien: Krav Sporbarhedsmatrix i projektledelse (Ex rigelig + skabelon)