Testlederen er prosjektleders høyre hånd og en av hans viktigste støttespillere. En testansvarlig er ikke en rolle man bekler når prosjektet nærmer seg slutten, men derimot en rolle som trenger fokus fra dag 1. I følge V-modellen starter testarbeidet straks prosjektet tar form, og da allerede ved kravanalysen.

Typiske oppgaver for testlederen er å utarbeide teststrategi, utarbeide testplan, avklare hvilke tester som skal utføres, ta ansvar for testmiljøet, definere og vedlikeholde testdata, lede testgjennomføringen, rapportere resultater til prosjektleder samt foreslå tiltak.

Sørg for at du får utnevnt en dedikert testleder fra dag 1 i prosjektet, en som tar ansvar at alle leveranser testes på en kvalitetsmessig god måte, en som har lang erfaring og god forretningsforståelse og en som utviser grundighet på kanten til autisme…

Straks du får ansvar for utvikling av en ny forretningskritisk løsning så start umiddelbart et delprosjekt med fokus på datakonvertering. Insister på å få med de beste db-ressursene fra leverandøren og de eldste brukerne fra kunden som virkelig forstår og kjenner de eksisterende dataene i dette delprosjektet.

Målsetningen med denne konverteringen er at data fra eksisterende system, så som kundedata, transaksjoner, reskontro osv, skal endres for å tilpasses ny løsning. Det høres i utgangspunktet enkelt ut med automatisk konvertering, vasking og validering men sann mine ord: Dette er ikke rett frem! Det er ikke mange år siden jeg satt flere helger på rad og manuelt la inn data i et kommunalt system fordi datakonverteringen ikke gikk som planlagt.

Datakonvertering er og blir en møysommelig prosess som krever nittygritty-ressurser som virkelig kjenner betydningen av de eksisterende dataene. I tillegg er det greit å sette av mye tid. Jeg garanterer deg: det går aldri som planlagt…

Et soleklart godt råd er å kjøre prosjektinterne minigranskninger. Det aller beste er selvfølgelig å hente inn eksterne "granskere" men man kommer ofte lang med å bytte fra prosjektleder- til gransker-hatt.

De følgende 10 spørsmål er ut utgangspunkt for å sjekke "tempen" på prosjektmiljøet. Det første spørsmålet er alltid nerveprirrende: "Har de skjønt noe som helst av hva vi skal gjøre" og det andre spørsmålet er alltid like avslørende med hensyn til hvor god du som prosjektleder har vært til å kommunisere internt.

1. Har prosjektdeltagerne en klar forståelse av prosjektets mål og omfang

2. Vet prosjektdeltakerne når prosjektet skal levere

3. Er det godt fellesskap i prosjektet. Er det en god lagånd

4. Er motivasjonen til prosjektdeltakerne på topp. (Er den dalende hos enkelte: så juster eller bytt ressurser)

5. Gis det rom for nytenkning, initiativ og kreativitet

6. Er det fysiske arbeidsmiljøet godt

7. Oppmuntres prosjektdeltakerne til å dele informasjon

8. Er prosjektgruppen lojal mot beslutninger som fattes

9. Får hver enkelt prosjektdeltaker tilstrekkelig med oppmerksomhet hva angår oppfølging av oppgaver

10. Føler prosjektdeltakerne at de har noe igjen for tiden de bruker på statusmøter

Tid for justering eller er alt under kontroll

Som ”Barn Av Fossefallsmetoden” skulle vi gjerne etter å ha blitt enig med kunden om en detaljert kravspesifikasjon gå i hi og utvikle, for så å komme ut og levere en løsning ferdig til test måneder og år senere. Da var det tid for ”Full Akseptansetest” og nødvendigvis ”Jakt På Synderen”. Det var egentlig ganske så gitt at vi satt igjen med mange skuffede kunder som fikk levert løsninger som ikke dekket deres behov.

Det er så godt som umulig å avdekke alle krav før man starter opp et utviklingsløp. Man evner ikke å se alle krav og sammenhenger knyttet til større systemleveranser. I beste fall er kravspesifikasjonen et øyeblikksbilde av semigeniale krav og ønsker fra dag 1, og i verste fall et kontraktsbilag på avtalte begrensninger i en leveranse.

Et alternativ som er mer krevende, som gjør kunden til prøvekanin i utviklingsløpet, som kan ta lenger tid og som kanskje innebærer en større kostnad på kort sikt, er å benytte en iterativ tilnærming til utviklingen. Dette er en metode hvor man kjører flere sekvenser hvor hver er et miniprosjekt med planlegging, kravanalyse, design, koding, testing og dokumentasjon med fungerende kode etter hver iterasjon. På tross av alle ulempene får man til gjengjeld en utvikler som forstår kunden og en kunde som forstår utvikleren og en større sikkerhet for en korrekt systemløsning gjennom daglige eller ukentlige møter og leveranser. Systemutviklingsavtalen PS2000 kommer for øvrig i 2008 med Smidig bilag.

For en tid tilbake skulle en god venn av meg forklare meg hva agile systemutvikling var. Han er roer, utvikler og prosjektleder og sa så treffende:

a) Teknikk – både rent teknisk (hardware) og menneskelig
b) Metode – treningsmåter etter annerkjente og velprøvde prinsipper
c) Utholdenhet, guts og vilje
d) Roere er sterke – både fysisk og mentalt
e) Ekstrem(!) samhandling
f) Lag/team
g) Drar i samme retning

Fordi man også sitter med ryggen til fartsretningen så kan man kanskje si at roere er ekstremt
Agile – man starter å ro uten egentlig å vite hvor mål er..."

Jeg bruker denne metaforen ofte når jeg skal forklare smidighet til kunder og utviklere

Jeg har ikke tall på de gangene jeg har blitt møtt med utsagn som. "Styringsgruppe, nei det trenger vi ikke. Det tar for mye tid og skaper bare unødig kost. Du kan vel rapportere til adm.dir, økonomisjef eller personalsjef".

Et prosjekt skal være ganske så lite for ikke å trenge en Styringsgruppe. Du trenger en sentral instans som kan være med på å ta alle avgjørelser i prosjektet som påvirker omfang, kostnader og tidshorisont for prosjektet ut over det som er delegert til prosjektleder. 

Styringsgruppen skal godkjenne prosjektdirektiv, godkjenne og signere alle styrende dokumenter for prosjektet, ta beslutninger vedrørende prosjektets budsjett, ta beslutninger vedrørende prosjektets omfang, avgrense og setteambisjonsnivå, ta beslutninger vedrørende overordnede prioriteringer, ta beslutninger vedrørende forslag til endringer og tillegg som går ut over de fastlagte prosjektrammene og som ikke håndteres av et endringsråd, følge opp at prosjektets fremdrift og resultater er i samsvar med prosjektmandatet og kvalitetsplanen samt sørge for at prosjektet får tilført de nødvendige ressurser til å møte sine målsetninger.

Styringsgruppen er også svært viktig med hensyn til å forankre prosjektet i virksomheten, så sant den er fornuftig sammensatt. Sørg altså for at denne blir opprettet og at du får med deg de i virksomheten med nødvendig besluttende makt og at de representerer hele virksomheten.

Er du ekstra heldig så klarer du å få med deg en ”prosjektmotstander”. Styringsgruppen er et ypperlig sted å plassere en kritiker og gjøre denne til et ”gissel” som egentlig er mot men som må være med ut fra rolle.

Min erfaring er at det viktig å dra styringsgruppen så langt som mulig inn i aktivt prosjektarbeid. Gi de rett og slett regulære arbeidsoppgaver. Dette gjør at de føler tilhørighet og er lettere å styre og hanskes med.

Det er et godt råd å legge risikoplanen din i oppstartsfolderen på pc’en. Denne må hentes frem og gjennomgås hver eneste dag.

Som relativt nyutdannet og prosjektleder for første gang ble jeg rådet til å jobbe med prosjektets risiki. Som så mange andre prosjektledere sydde jeg sammen et omfattende dokument med kartlegging av risiki med vurderinger, estimater, konsekvenser vektig/ skalering osv osv, før dokumentet havnet i prosjektfolderen og forble urørt gjennom prosjektet. Det var sikkert den beste risikoplanen som noen gang har vært laget, men akk så bortkastet.

I dag utgjør risikoplanen et av mine mest sentrale redskaper i mine prosjekter. Jeg er ikke så nøye på innpakningen heller. Jeg lager meg et excel-ark med oversikt over mulige risker og jobber mye med tiltakene. Det er også en god ide å gjemme historikken til tiltakene slik at du kan studere utviklingen av disse.

Jeg gjenbruker gjerne dette excel-arket og benytter det aktivt i rapportering til styringsgruppen eller ledelsen. Jo mer de er involvert i din risikoplan jo enklere er det å få forståelse for de grep du tar som prosjektleder.

Jeg bruker å forfølge risiki over en enten en 3 måneders periode eller en 3 ukers periode og populariserer rapporteringen med å slenge på smilefjes. Har du 3 smilefjes på rad, så vekk med’n.

Et prosjekt uten risikoplan – tar du risk’en?

Sørge for å vite hvem prosjektets interessenter er: Straks man har nedfelt målsetningene til et prosjekt, må prosjektlederen starte arbeidet med en interessentanalyse. En interessentanalyse er verktøyet for å avdekke hvem som påvirkes av og kan påvirke prosjektet.

Når interessentene er kartlagt, kan man analysere disses mulighet til å påvirke prosjektet i positiv eller negativ retning. Prosjektleder kan også tidlig tilpasse sin informasjonsplan til de ulike mottakerne.

De enkle grepene for en slik analyse er:

1. Kartlegg alle interessenter og deres interesse i prosjektet
2. Still deg så spørsmålet hvor viktige de ulike aktørene er, hvor nærme de sitter prosjektet og hvilken innflytelse de kan tenke seg å ha
3. Lag en tiltaksplan for å kunne møtekomme den innflytelsen interessentene besitter

Prosjektledelse handler ofte om å håndtere "Den Menneskelige Faktor". Dette gjelder ikke bare egne prosjektressurser, men gjelder vel så mye kundens og gjerne kundens kunde.

Prosjektlederen er politikeren, sosionomen, cheerleader'n og muntrasjonsrådet.

For å lykkes: vær fleksibel og forhandlingsvillig heller enn kantete, men sett en klar grense – du vil ikke tape målet av synet.

Og husk: En IOU er greit å ha med seg når krigen spisser seg til.

Ethvert prosjekt uansett størrelse må ha en informasjons- og kommunikasjonsstrategi. Strategien skal dekke formål og prinsipper for kommunikasjon og informasjon i prosjektet. Kommunikasjonsplanen vil beskrive kontrete tiltak og aktiviteter basert på de prinsipper og retningslinjer i strategien: Hva skal bli kommunisert, til hvem, når, hvordan og av hvem.

Bestem tidlig kommunikasjonsprinsippene og hvilke retningslinjer som skal legges til grunn. Dette kan for eksempel være å fokusere på et enkelt og konsistent budskap, bruk av flere kanaler for kommunikasjon, skreddersy informasjon til interessenter, unngå informasjons-overload, oppmuntre interessenter til å etterspørre informasjon, repetering av nøkkelinfo samt oppmuntre til feedback.

Vanlige risikoområder knyttet til informasjonsaktiviteter det er greit å vite om er for eksempel at kommunikasjonsplanen ikke er nok målrettet, tidspunkt for release av info er feil i forhold til aktiviteter, feil informasjon til målgruppen, viktige interessenter er ikke tatt med i prosessen eller at budskapet rett og slett er blitt misforstått.

Informasjonsarbeid i prosjekt er altså mer enn å produsere statusrapporter til styringsgruppen og prosjektdeltakerne. Prosjektleder må sørge for å skape bevissthet, skape forståelse og skape en positiv oppfatning om prosjektet.

Det er egentlig ikke så komplisert: sett dato for når kommunikasjonsaktivitetene skal gjennomføres, skisser hvilke aktiviteter og hvilke områder de tilhører, bestem hvilke målgrupper du vil kommunisere mot, hvem som skal utføre aktiviteten og bestem hvilken kommunikasjonskanal som skal benyttes.

Jeg har gjennom 15 år ledet store og små prosjekter, nasjonale og internasjonale prosjekter, kjedelige og spennende prosjekter, og ikke minst: jeg har lykkes og mislykkes.

Jeg håper å kunne gi noe av min erfaring gjennom denne bloggen. Jeg har ingen ambisjon om å diskutere de ulike rådene til bunns, men mer skape oppmerksomhet og hva man bør tenke på i sin virke som prosjektleder.

Mvh

Bjørn Eilertsen
Prosjektmann
Amende AS

Et av de største suksesskriteriene for et prosjekt er å få med seg linjeledere som en aktiv part. Sørg for å enten tildele de en rolle som reell prosjektdeltaker eller som ”hørerør” i viktige saker. Den sistnevnte rollen er oftes den vanlige man tildeler linjeledere hvor de kan sitte i ekspertpanel som rådgiver til prosjektleder.

Prosjektlederen må skape tillit og gode relasjoner med linjelederne. Det er flere grunner til dette, men de viktigste er at du ønsker de som positive ambassadører for prosjektet ditt.

Ikke noe er værre for et prosjekt enn negative ledere som i det skjulte motarbeider prosjektet, enten fordi de ser på prosjektet som skadelig for deres posisjon eller at de mister sin makt fordi de selv ikke er deltaker.

I tillegg sitter disse på prosjektressurser du vil bruke i prosjektet ditt. Prosjekter som ikke har en god dialog og får med seg linjen og brukermiljøene dømmes oftest nedenom og hjem.

Jeg har gjennom 15 år ledet store og små prosjekter, nasjonale og internasjonale prosjekter, kjedelige og spennende prosjekter, og ikke minst: jeg har lykkes og mislykkes.

Jeg håper å kunne gi noe av min erfaring gjennom denne bloggen. Jeg har ingen ambisjon om å diskutere de ulike rådene til bunns, men mer skape oppmerksomhet og hva man bør tenke på i sin virke som prosjektleder.

Mvh

Bjørn Eilertsen
Prosjektmann
Amende AS