Har du noen gang ønsket deg en kort liste over elementer du kan holde “i sjakk” mens du administrerer prosjekter? Denne korte listen vil inneholde nøkkeltiltak som, hvis alltid holdt i sjakk og balanse, ville føre deg til prosjektsuksess? Klart det er viktig å følge bransjeprosjektretningslinjene fra Project Management Institute og innenfor Project Management Professional (PMP) Certification, men det er viktig å alltid ha disse nøkkeltiltakene i forgrunnen HELE VEIEN gjennom prosjektet – fra begynnelsen til fullføring. Noen ganger kan disse faktorene overses eller glemmes, eller tenkes på som “ikke nødvendig” i hastverket for å få i gang et prosjekt. Stå opp og stopp galskapen, sørg for at du har en klar sti før du prøver å komme deg til målet ditt… Ellers vil du gå deg vill underveis.
Nøkkeltiltak:
- Før du i det hele tatt ser på forretningskrav eller bruker mye tid på et prosjekt, sørg for at du vet:
en. Hvem er den utøvende sponsoren og få følgende informasjon direkte fra den sponsoren:
Jeg. Prosjektintensjoner og omfang
ii. Hva prosjektet IKKE er eller hva som er utenfor omfanget
iii. Hvem “kundene” er for prosjektet. (mange ganger er kunder interne i organisasjonen)
iv. Hvis et avkastningsdokument er opprettet og hva som forventes av et ROI-dokument. Hvilke områder av virksomheten forventes avkastning?
v. Prosjektbudsjett og hvordan utgifter godkjennes
vi. Forventede prosjektsuksessfaktorer
vii. At de ønsker at dette prosjektet skal gå videre på det nåværende tidspunkt, hvis ikke, når skal det starte
viii. Forventet tidslinje for ferdigstillelse av prosjektet
ix. Enighet om å sette bedriftens ressurser på prosjektet for å få det til
x. Nødvendig prosjektstatus og rapportering
xi. Avtale om kommunikasjonsplan til sponsorer, kunder og andre berørte parter
xii. Enighet om tildelt prosjektleder og støtte fra sponsor om at hvis det er problemer med prosjektet som krever oppmerksomhet fra den utøvende sponsoren, at sponsoren vil gi støtte for å oppnå vedtaket
b. Skriv deretter all denne informasjonen skriftlig, vanligvis i et slags prosjektinitieringsdokument, og deretter signerer alle prosjektledere, sponsorer og kunder og CIO dokumentet. Jeg kan ikke stresse
hvor viktig denne delen er. Jeg kan ikke understreke hvor mange ganger vi har kommet til slutten av et prosjekt og minst én av disse partene (sponsorer, kunder eller CIO) sier at de aldri har godtatt noen del av den dokumenterte informasjonen i prosjektinitieringsdokumentet. Dette er spesielt viktig for systemimplementeringsprosjekter ettersom det kan gå mye tid mellom prosjektet ble igangsatt og det endelige produktet leveres. - Forretningskrav
en. Det er svært viktig, før du snakker med noe IT-personell (hvis prosjektet involverer intern IT – som, hvis det er systemimplementering, det mest sannsynlig vil gjøre det) eller produktleverandører, at du tar deg tid til å dokumentere alle forretningskrav fra alle. kunder. Dokumentasjon av forretningskrav bør som et minimum innebære å gå gjennom følgende trinn:
Jeg. Identifisere fageksperter og prosjektrepresentanter fra hver del av virksomheten som fungerer som dine kunder for sluttresultatet av prosjektet.
1. Identifiser gjeldende problem eller behov
2. Dokumentere aktuelle prosesser
3. Diskuter hva som ikke fungerer med prosessen
4. Gjennomgå resultater de ønsker å se for å støtte virksomheten og analyser de må utføre for å administrere virksomheten
ii. I dokumentasjonen for forretningskrav, IKKE bruk tid på å diskutere hva systemer eller teknologi vil tillate dem. Diskuter hva som trengs for virksomheten. Ikke la kundene prøve å definere en prosess rundt systemer eller teknologi. Teknologi er der for å støtte virksomheten, ikke for å diktere hvordan en virksomhet skal drives. Ikke bekymre deg, alle de tekniske delene vil komme sammen senere.
iii. Dokumenter alle forretningskrav som diskutert med alle kundegrupper og fageksperter. Pass på at du spesifiserer problemene og behovene, hvordan det skader virksomheten, hva som trengs, og hvordan det vil hjelpe virksomheten. Vær spesifikk. Denne informasjonen vil hjelpe deg å sette sammen ROI-dokumentet for å være sikker på at kostnadene og de forventede fordelene er i tråd med hva prosjektsponsoren(e) forventer. Noen prosjektledere kan være uenige her og si at avkastningen bør gjøres før de kommer til virksomhetens kravstadiet. Imidlertid har jeg alltid funnet at nye investeringsområder (kostnad) og avkastning på investeringen presenterer seg når de går gjennom prosessen for oppdagelse av forretningskrav. - iv. Sørg alltid for å tenke på hvordan et produkt skal brukes og hvordan rapportering vil kreves. Dette kan virkelig få deg til slutt hvis du ikke følger nøye med på forhånd under kravfasen.
- v. Du vil deretter matche forretningskravene til omfanget du opprettet i prosjektinitieringsdokumentet, eller endre omfanget, noe som vil kreve en endring av prosjektinitieringsdokumentet som krever nye signaturer.
- vi. Når det riktige settet med krav er dokumentert og det stemmer overens med prosjektets omfang, sørg for å igjen ha prosjektsponsorer, kunder (husk, kunder kan være interne eller eksterne), og CIO som erkjenner at dette er forretningskravene, at prosjektet er aktive og sponsede, og at de er enige om å gå videre til neste prosjektfaser. Dette stykket er spesielt viktig, ettersom folk har en tendens til å glemme eller si ting som “Jeg har aldri sagt det” når du kommer lenger i prosjektet. Du kan alltid bringe dem tilbake til den opprinnelige dokumentasjonen og signaturene.
- Får du ikke underskrifter, er du en sittende and.
- Nå er det på tide å finne ut hvordan du skal oppfylle disse forretningskravene. Dette fører vanligvis til en kjøps- eller byggebeslutning. Det vil si, kjøp programvare fra en leverandør som spesialiserer seg på den type produkt som trengs, eller bygg med internt IT-personell. Forretningskravdokumentet er ditt grunnlag for å evaluere kjøps- eller byggebeslutningen. Ikke gå bort; ikke utvide omfanget eller budsjettet uten å gå tilbake gjennom avmeldingsprosessen. Hvis du “kjøper” et produkt fra en leverandør, gjør den første “nedskjæringsprosessen” for å finne de beste programvareproduktene som samsvarer med forretningskravene.
- Nå som du har din toppliste over programvarekonkurrenter, få demonstrasjoner utført av leverandørene for kundegruppen(e). De kan hjelpe til med å stemme på det valgte produktet. Det er avgjørende å få buy-in fra kundene dine hvert trinn på veien.
- Hvis mulig, er det en god idé å utføre en prøvefase med 2 toppleverandører for å se hvordan forretningskravene samsvarer med produktet.
- Etter prøvefasen, kom tilbake med kundene dine for å demonstrere produktene mot forretningskravene. Deretter får kundene dine gjøre sitt endelige valg. På det tidspunktet må du sørge for at det er skrevet et teknisk spesifikasjonsdokument som samsvarer med forretningskravene. Formålet med det tekniske spesifikasjonsdokumentet er å demonstrere innenfor produktet, hvordan forretningskrav vil bli oppfylt, hvilke forretningskrav som ikke kan oppfylles eller bare kan oppfylles delvis, og IT-kravene til produktet. Vær sikker på at du, før du starter en større utviklingsfase, har gått tilbake til dine sponsorer, kunder og CIO eller andre representanter for IT-parter for å bli enige om spesifikasjonene og avtalen for å gå videre. Denne fasen vil også kreve en oppdatert prosjektplan som beskriver hele utviklingsplanen, ressurskrav og engasjement fra involverte parter.
- Sørg for å gjøre en “pulssjekk” med dine kunder og sponsorer på mange punkter gjennom utviklingssyklusen. Dette vil sikre at kundene dine ikke blir overrasket over sluttresultatet eller at du ikke har gått helt ned på en vei som de ikke ønsket eller at du utviklet noe feil. Det er mye bedre å fange disse tingene mens utviklingen fortsatt pågår – tidslinjen din vil sannsynligvis bli påvirket mye mindre på denne måten OG oppfatningen av prosjektsuksess hos kunder og sponsorer vil være mye høyere på denne måten. Til syvende og sist er det best å ikke ha noen slike “hang-ups” under utviklingsprosessen. Men det er sannsynligvis ikke realistisk å forvente at du ikke vil ha noen. Det er prosjektlederens jobb – å jobbe gjennom slike problemer og likevel fullføre prosjektet i tide.
- Når utviklingsfasen er fullført, er det viktig at du ikke bare har dokumentert hvordan du bruker produktet, men hvordan det påvirker forretningsprosessene. Det vil kreve diskusjon med kundegrupperepresentanter om hva systemet nå skal gjøre, og hvordan den nye prosessen skal se ut. Det er viktig å ha dette dokumentet og være i samråd med kundegrupperepresentanter FØR en eventuell produktutrulling skjer. Hvis du gjør dette, kan du forvente en mye jevnere trenings- og utrullingsfase av produktet enn om du bare prøver å kaste produktet ut der. Dersom du ikke har en nøye planlagt opplærings- og utrullingsfase, vil alt arbeidet ditt gå i vasken, og prosjektet vil mest sannsynlig ikke oppleves som noen stor suksess.
- Under utrullings- og opplæringsfasen er det ekstremt viktig å kommunisere hva brukerne må gjøre dersom de trenger hjelp til produktet.