For større prosjekter, anbefaler jeg at du oppretter en sporbarhetsmatrise for krav. Lær mer her:

Krav Sporbarhetsmatrise i prosjektledelse (eksempel + mal)

Prosess nr. 2: Hvordan knekke krav og definere omfang

Her er et krav :

«Nettstedet pmbasics101.com skal kunne samle e-post og sende ut et PDF-dokument i retur.»

Hva skal til for å oppfylle dette kravet?

1. Velg en leverandør av posttjenester.
2. Opprett en konto.
3. Utform skjemaet for å samle inn e-post.
4. Implementer det utformede skjemaet.
5. Installer plugin fra posttjenesteleverandøren.
6. Last opp PDF-dokumentet.
7. Aktiver skjemaet.
8. Test skjemaet.

Det er bare en liste over nødvendige handlinger. Hvis jeg setter det riktig som leverings- og arbeidspakker, vil det havne i:

1. E-postvalg -i skjema
   1.1 rapport om posttjenesteleverandører
   1.2 Godkjent skjemautforming 1.3 Tilmeldingsskjema for testmiljøet 1.4 Testrapport

Så, hvordan gjør kommer du fra det kravet om en setning til det faktiske omfanget av arbeidet?

A) Du kan finne noen som har relevant erfaring eller kunnskap

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

Så, målet ditt er å skaffe dem fra prosjektgruppen eller bare ta kontakt for å kommunisere. De kan ha en løsning allerede.

Ellers kan du få veiledning eller råd. Det er en grunnleggende teknikk som du vil bruke mye.

B) Utfør produktanalyse

Den gjelder når du trenger å lage et produkt i stedet for en tjeneste eller et resultat.

Denne teknikken fokuserer på å nedbryte produktverdien. Akkurat som WBS gjør med omfanget.

Videre må du analysere produktet fra ergonomiske og funksjonelle synspunkter; og ta deretter avgjørelser om materialer eller prosesser som vil oppfylle ytelseskravene.

25 Eksempler på produktanalyse

Alt i alt er målet ditt å definere håndgripelige leveranser.

C) Bruk alternativgenereringsteknikken

Denne teknikken fungerer bra når du har ekspertise i prosjektets art.

Så, du må finne den beste løsningen på Møt kravene. I de fleste tilfeller bruker du brainstorming for å få alternativene.

Hva er målet?

Du må definere tydelig hva som er og hva som ikke er en del av prosjektomfanget.

Prosess 3: Administrer prosjektomfang med en PM-programvare

Du kan helt sikkert spore prosjektets omfang i en hvilken som helst tilgjengelig app. For eksempel vil Google Drive, Evernote eller MS Word gjøre det.

Det er imidlertid alvorlige fordeler ved å bruke integrert prosjektadministrasjonsprogramvare for å holde alt på ett sted.

Ideelt sett er du må kunne knytte krav til prosjektleveringene.

Deretter, fra leverbare til spesifikke oppgaver med estimater, relaterte risikoer og mangler.

For eksempel kan jeg anbefale Paymo. Det er en av de beste appene for personlig bruk og for små prosjekter. I tillegg har den gode tidssporings- og faktureringsmuligheter.

Prosess 4: Slik styrer du prosjektomfang

Det er ikke nok å identifisere 100% av prosjektets omfang i begynnelsen. . At 100% VIL endre seg i løpet av prosjektets levetid.

Så, du trenger en måte å overvåke, kontrollere og gjøre endringer i omfanget.

Kuren er velkjent. Det er en arbeidsfordelingsstruktur.

Vel, du trenger også en tydelig arbeidsflyt for å introdusere endringer i alle områder av prosjektet når arbeidsmengden endres.

Det handler imidlertid om en integrert endringsledelsesprosess.

Så hva er fangsten?

Du trenger en WBS av høy kvalitet. Videre trenger du en ikke-nerdete måte å beskrive prosjektets omfang. Derfor trenger du også en Project Scope Statement. Vi diskuterer det nedenfor.

Hvis du er på et smidig prosjekt, er det klart definerte omfanget av økning eller iterasjon enda viktigere. Ikke tro at smidig sparer deg for grundig dokumentasjon av arbeidet som skal utføres. Hold Sprint Backlog og User Stories pent. Bruk en enkel regel: «En nykommer skal forstå hva som må gjøres fra beskrivelsen av brukerhistorien.»

Hvordan validere omfanget

En gang i blant må du få en formell sign-off at en leveranse oppfyller interessenters forventninger.

Det er viktig å gjøre det kontinuerlig gjennom hele prosjektet.Selv om du leder et plandrevet prosjekt, bør ingenting hindre deg i å gi produktsteg for gjennomgang.

Hvorfor trenger du dette?

Du vil ikke få alt endringsforespørslene, alle manglene og «mindre endringer i prosjektet» til slutt.

Du fratar deg muligheten til å faktisk integrere en endring i prosjektet.

Jo nærmere prosjektavslutningen er, desto mindre tid og ressurser vil være igjen. Videre vil interessenter være mindre tilbøyelige til å forhandle om endringer i omfang, tidslinje eller budsjett. De vil også legge større press på teamet for å få det de trenger.

Bare det å si det åpenbare:

Det er veldig viktig å ha et klart beskrevet og godkjent prosjektomfang fra starten.

Når en leveres ikke oppfyller forventningene, vil det bli korrigert.

Det er ditt ansvar å bevise om en korreksjon er en endringsforespørsel, og derfor bør den integreres ordentlig. Ellers er det en feil, og du må gjøre opp for deg. Noen ganger på egen bekostning.

Hvordan validerer du faktisk omfanget hos kundene?

På ethvert prosjekt kan du bruke Scrum-lignende demo-møte.

Bare forberede en kort demonstrasjon av det leverte. Forklar gjeldende prosjektstatus og fremdrift. Deretter peker du på kjente mangler og deler som pågår.

Samle også tilbakemeldinger fra kunden. Senere kan du gi all støttedokumentasjon og rapporter som kreves av retningslinjene dine.

Bunnlinjen:

Samle tilbakemeldinger fra interessenter kontinuerlig. Forhandle vilkårene for innføring av nye endringsforespørsler. Hold prosjektets omfangsnivå oppdatert.

Få min prosjektomfangsstyringsmal

Ikke finn opp hjulet! Det kan være kostbart for deg.

Bare klikk på knappen nedenfor og få utfyllingsmalen. Den leveres med en ressursveiledning om alt du trenger å vite om omfangshåndtering.

Hvorfor hele omfanget Baseline er kritisk for prosjektet ditt?

Vanligvis starter et prosjekt, og vi får krav i forskjellige former.

For eksempel: e-post, PDF-filer, møter, mockups, feilrapporter, hva som helst .

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

I de fleste tilfeller diskuterer vi ikke engang forretningssaken for prosjektet.

Vi lager vanligvis en arbeidsfordelingsstruktur.

Imidlertid brukes den bare internt og går aldri til kunden. Deretter nedbryter vi arbeidet til aktivitetene og estimerer prosjektet. Vi bruker en estimeringsteknikk fra bunnen av.

Nå kommer den første forventningskontrollen:

Vi presenterer estimater for prosjektet.

Ser du, det er tilsynelatende en mangel på åpenhet her. Kunden vet ikke hvilket arbeid vi faktisk estimerte.

Hvis estimatet er nær kundens forventninger, vil han ikke grave i detaljene. Dette er fordi han allerede er klar til å bruke så mye penger og tid. Han vil ikke kaste bort den dyrebare tiden deres.

Her er sannheten:

Mange organisasjoner og prosjektledere skjuler ineffektivitet. bak slike tause avtaler.

Det er et tema for et eget innlegg, men det er grunnårsaken til mange av dine problemer.

Hva skjer videre?

Vi starter prosjektgjennomføring! Før eller siden vil kunden be om å legge til et nytt stykke arbeid.

Etter det finner vi en del av uidentifisert arbeid. Senere vil kvalitetsproblemer dukke opp. De vil spise opp mye tid.

Alt i alt overleverer vi en levering for å finne ut at vi har gjort noe galt.

Og det er da kunden informerer oss om at han glemte noe, og det skal legges til så raskt som mulig.

Tro meg, du opplever det mer enn en gang.

Definisjon av omfangets grunnlinje

”Omfangets baseline er den godkjente versjonen av en omfangserklæring, arbeidsbruddstruktur (WBS) og tilhørende WBS-ordbok, som bare kan endres gjennom formell endringskontrollprosedyre og brukes som sammenligningsgrunnlag. » -PMBOK®-guide

Hva er en uttalelse om prosjektomfang?

Definisjon av Project Scope Statement

Project Scope Statement er en narrativ beskrivelse av et produkt og prosjektomfang.

Det brukes som en skriftlig bekreftelse på hva prosjektet ditt skal produsere og hvordan.

Hva er nøkkelen til en verdifull uttalelse om prosjektomfanget?

Jeg tror du trenger å bruke ord og språk som enhver interessent forstår. Denne delen av prosjektets omfang er hovedsakelig for kunden.

OK, hva skal inkluderes?

Begrunnelse for et prosjekt

Det er en kort beskrivelse av virksomhetens behov. Noen ganger er en setning nok. Resten skal være i et prosjekt Charter

Produktomfang

Det er en beskrivelse av egenskapene, egenskapene og funksjonaliteten til et produkt eller en tjeneste du vil produsere.

Husk at du samlet inn krav fra forskjellige interessenter. Så ikke anta at alle holder oversikt over hvert krav. Det er heller ikke alltid klart hvor mye arbeid som kreves for å levere et krav.

Det er det primære stedet for å tilpasse forventningene til viktige interessenter.

Du må vise mengden og kompleksiteten. av arbeidet som kreves for å oppfylle forskjellige krav. Legg derfor mest mulig vekt på denne delen.

Akseptkriterier

Det er betingelsene som må oppfylles før prosjektleveranser godtas.

Du kan inkludere en akseptabelt nivå og antall feil også her.

Leveranser

Det er en beskrivelse av alle leveranser prosjektet ditt vil produsere.

Det kan omfatte produktet eller service, prosjektdokumentasjon, produktmanualer, utdanningsmateriell for ditt produkt osv.

Prosjektutelukkelser

Her må du spesifisere hva som er utenfor prosjektets omfang.

Ofte vil en del av interessentene ha noe spesifikt. Den andre delen av interessenter eller en kunde støtter ikke det.

Derfor er det en konfliktsituasjon. Når konflikten er løst, og det ble besluttet å fjerne noe fra prosjektomfanget, legg det her.

Vær spesifikk og veldig klar om det. Det sparer tid i fremtiden.

For det første trenger du ikke å se på disse prosjektutelukkelsene på nytt. Interessenter kan prøve å inkludere dem senere under prosjektgjennomføring.

Men med mindre noe endres dramatisk, bør du ikke kaste bort tid på å gjennomgå ekskluderinger.

For det andre, med mindre det er klart angitt, kan noen forventer fortsatt at du vil levere det. Ikke gi falske forventninger. Det blir lettere å avlevere prosjektet til slutt.

Begrensninger

Alt som begrenser deg til å levere produktet effektivt, bør angis her.

Antakelser

Det er usikkerhetene som ikke kunne avklares for øyeblikket.

Du må godta noen av dem under planleggingen. Hvis en antagelse viser seg å være ugyldig, vil du ha rett til å endre prosjektplanen.

En kunde bør godkjenne prosjektets omfangserklæring. Faktisk er det en formell og gjensidig avtale.

Den sier også at du er forpliktet til å levere beskrevne resultater under den bestemte antagelsen og med klare begrensninger. På den annen side godtar kunden å godta det spesifiserte resultatet.

Det betyr ikke at vi ikke kan endre prosjektomfanget. Nei. Det betyr at vi må endre avtalen for å gjøre en endring.

Organiser prosjektomfanget med WBS

WBS er en obligatorisk del av omfangets baseline på alle prosjekter. Stor eller liten. Agil eller plandrevet.

Det er allerede en fullstendig guide til en Work Breakdown Structure on PM Basics. Jeg vil ikke gjenta det her.

Det er bare ett viktig poeng jeg vil understreke:

Leveranser beskrevet i Project Scope Statement bør komme inn i WBS som det er. Hold leveranser konsistente gjennom hele prosjektet.

Sett alt du vet i WBS Dictionary

WBS Dictionary er et dokument som beskriver arbeidet som skal gjøres for hver arbeidspakke.

Som en moderne statsråd vil jeg si at det bør være en del av et oppgavesporingssystem. Det meste av prosjektledelsesprogramvaren gir deg muligheten til å oppbevare denne informasjonen på ett sted.

Derfor vil jeg ikke foreslå at du oppretter et eget dokument. Å opprettholde WBS Dictionary er mye arbeid. Se etter integrerte løsninger.

Du kan inkludere all informasjon som spesifiserer en komponent i WBS. For eksempel kan WBS-ordboken inneholde:

• Beskrivelse av arbeidet
• Forutsetninger og begrensninger
• Ansvarlige personer eller organisasjoner
• Milepæler
• Relaterte aktiviteter
• Nødvendige ressurser
• Kostnadsoverslag eller budsjett
• Akseptkriterier
• Referanser annen dokumentasjon

Så hva som passer dine behov og hjelper deg med å integrere WBS i andre prosesser.

Konklusjon

«Det er ingen vind som blåser riktig for sjømannen som ikke vet hvor havnen er.»

Du kan ikke lede prosjektet til et vellykket resultat uten å vite hva som må gjøres.

Nok en gang vil jeg understreke det punktet.

Selv om du er i det smidige miljøet og omfanget er ikke klart definert for hele prosjektet, du må fortsatt planlegge en måte å definere, administrere, spore og endre prosjektomfanget.

Begge for et iterasjonsnivå og det endelige prosjektresultatet.

Jeg anbefaler også å lese:

• Utvalgt artikkel: Hvordan bli IT-prosjektleder uten erfaring
• Neste i serie: Ultimate Guide on How to Create a Robust Work Breakdown Structure
• Forrige i serien: Krav Sporbarhetsmatrise i prosjektledelse (Eks rikelig + mal)