Skal du lykkes innen min bransje, så må du gjøre din kollega god - du må gjøre ham knallgod! Man stiller opp for kollegaen, man inkluderer denne i "success and failures", man skaper lagfølelse og trygghet og man tar et felles eierskap i det å lykkes.

Det er ikke så veldig stor forskjell på forretningsideen til Arsenal og Amende:

• Vi skal jobbe med å skape fornøyde kunder,(TILHENGERE)
  
• Vi skal skape en attraktiv arbeidsplass med fornøyde ansatte, (SPILLERE)
• Vi skal skape et levende fagmiljø som tiltrekker seg andre gode konsulenter (HANG AROUNDS)
  

Det er mulig dette er en overtydelig lignelse, men enn så viktig: Står man sammen, og gjør hverandre gode, kan man klare hva som helst - til og med slå Spurs 3:0.

Prosjektarbeid og systeminnføring er en prosess hvor man lærer underveis og hvor endring er absolutt. De som påvirkes av prosjektet må derfor hjelpes til å forstå at endringer er nødvendig. Dette kan være prosesser, roller, organisasjon, prosedyrer m.m. Målet er at organisasjonen skal svelge unna og forstå disse endringene så raskt som mulig med minst mulig effekt for kunder, effektivitet og lignende.

Endringsledelse er for så vidt en egen profesjon men med enkle hjelpemidler og teknikker kan du som prosjektleder ivareta deler av dette, selvfølgelig avhengig av størrelsen på prosjektet. Jeg tar ofte på meg rollen som endringsagent i mine prosjektlederoppdrag og sørger for nødvendig involvering gjennom coaching, opplæring, kommunikasjon, håndtering av motvilje osv.

Endringsledelse er ikke et arbeid du starter med etter at et prosjekt er avsluttet eller at et produkt er
levert. Skal du få en hel organisasjon til å forstå og iverksette endringer, er det nødvendig med et parallelt løp fra dag 1 i prosjektet.Hovedaktivitetene i arbeid med endringer du som endringsagent, eller prosjektleder, må rette fokus mot, er

1. Skape forankring hos ledelsen, nøkkelressurser samt prosjektgruppen din slik at viktigheten av endringen blir forstått
2. Identifisere alle interne og eksterne parter som vil kunne påvirkes
3. Identifisere endringsområder med forslag
4. Gjennomfør endringen
5. Gjennomføre en evaluering etter endringen er gjennomført for å se om den har gitt ønskede resultater

Joda, de samme risikofaktorene gjentar seg fra prosjekt til prosjekt. Jeg kom over en liste i fra et tidligere prosjekt. Jeg skulle ønske jeg hadde satt noen av de med en annen "impact", og da tenker jeg spesielt på de punktene som retter seg mot tilgang på linjeressurser og de med basis i uvilje mot ny løsning.

• Mangel på brukerinvolvering pga prioritet på andre oppgaver
• Manglende tilgang på kjerneressurser
• Mangel på forpliktelse fra linjeapparatet
• Prosjektdeltakerne har andre forpliktelser
• Manglende teknisk kompetanse hos prosjektdeltakerne
• Manglende kunnskap om eksisterende miljø hos nye prosjektdeltakere
• Mangler løsningsarkitekt
• Uventede nye krav
• Urealistisk ambisjonsnivå
• Leveranse av stort og omfattende system uten å splitte leveransen opp i håndterbare moduler
• Endringer i lov og regelverk
• Uklar prosjektorganisering og ansvarsfordeling
• Høye forventninger fra brukerne
• Mangelfull statusrapportering
• Mangelfull planlegging
• Urealistiske mål mht ferdigstillelse
• Undervurdering av organisasjons- og kompetanseutvikling
• Ensidig fokus på IT i prosjektet
• Mangelfull kvalitetssikring
• Mangelfull brukermedvirkning
• Mangelfull forankring
• Mangler kontrakt som styringsredskap
• Motstand mot forandringer
• Brukerne har dårlige erfaringer med IKT-prosjekt
• Spredt prosjektorganisasjon
• Uvilje internt mot prosjektet

Prosjektet er estimert til å ta x år. Når er kravspesifikasjonen utdatert.
Etter 1 måned? 2? Du trenger konstant å justere kursen din og du trenger å hugge opp ”elefanten” i
håndterbare biter... Dette er viktig både for deg og din oppdragsgiver. Begge parter får verifisert
retning og innhold jevnlig.

Sørg for at det opprettes et mottaksprosjekt hos kunden som kan ta i mot dine hyppige leveranser.
Ikke minst: det er viktig for prosjektdeltakerne og alle interessenter som påvirkes av prosjektet, å føle
progresjon.

Følelsen av progresjon er inspirerende og verdifull...

Når du starter opp et nytt prosjekt og skal fylle de viktigste rollene, starter også kampen om de gode hodene. Du vil ha ressurser som har vært i ”krigen” tidligere.

Nøkkelressurser bekler typisk rollene knyttet til teknisk arkitektur, forretningsarkitektur, testledelse og delprosjektledelse. Dette er dine nøkkelressurser.

Utfordringen er ofte at de er knyttet opp til linjeoppgaver eller med i andre prosjekter. Sørg for å ha en plan for hvordan beholde disse. De er sjelden lett å erstatte.

Lag tidlig en rutine for å håndtere viktige saker eller endringer som vil oppstå i prosjektet og kjør kompromissløst på endringskontroll. En av de største risikiene man har i et prosjekt, er for sent ankomne krav og endringer, og faren for forrykkelse av tidsplan, budsjett, funksjonalitet, kvalitet og lignende er stor, uansett hvor SMIDIG man ønsker å være.

Rutinen for viktige saker må fange opp både endringer som påvirker prosjektstyringen samt de ønsker og endringer som påvirker leveransen som sådan. De førstnevnte endringene skal reflekteres i prosjektplan og – direktiv mens de sistnevnte skal være vedlegg til kontrakten som en ren endringsordre.

I korte ordelag er rutinen som følger:

• Register avvik i en endringslogg
• Skriv en endringsanmodning
• Gjør en konsekvensanalyse av avviket opp mot ønsket løsning
• Legg innstillingen frem for Styringsgruppen
• Implementer eller ekskludèr og sats på å unngå ”omstridte” endringer

Som prosjektleder er du ansvarlig for at denne rutinen utarbeides. Avhengig av hvor ”prosjektvant” kunden din er, så må du sørge for at det opprettes et endringsråd som du må ta ledelsen for. Du må også etterse at alle innkomne saker videre legges frem for Styringsgruppen til behandling.

Husk at en underskrevet endringsordre er et kontraktuelt dokument

Prosjektdeltakere og interessenter trenger daglige påminnelser om prosjektets mål. Hvorfor man starter prosjekter og hva som er det opprinnelig målet går fort i glemmeboken - kanskje ikke hovedscope - men mer gevinstene man ønsker å oppnå.

Prosjektleder må ta ansvar for å jobbe tett sammen med sin Styringsgruppe og dyrke frem prosjektets hovedmål, resultatmål og gevinstmål. Eierskapet til de målene man setter må forplantes i Styringsgruppen og kanaliseres ut i hele organisasjonen. Det er viktig at dette oppfattes som organisasjonens egne mål og ikke mål som settes for prosjektet alene.

Som hovedregel er hovedmålet for prosjektet satt og skal skal leve gjennom hele prosjektløpet uforandret, noe som også gjelder resultatmålene. Gevinstmålene er dog noe som kan håndteres som mer levende i og med at målet endrer seg, endringer i organisasjonen og ikke minst kravene til leveransen.

En reell holdning til gevinstrealisering er smertefull og "glemmes" ofte. Hvem vil fjerne stillinger, endre rutiner, effektivisere, redusere, halvere, spare osv. Dette er dog en sak som prosjektleder må fronte. Sørg for at det opprettes en dedikert rolle i prosjektet med ansvar for å utvikle en plan for planlegging og gjennomføring av gevinstrealisering.

Fire avsnitt om målledelse var kanskje i det korteste laget. Jeg kommer tilbake til dette senere - det er faktisk noe av det mest spennende med prosjektarbeid.

Det viktigste budskapet i denne omgang er dog rett og slett: Ta en pust i bakken og hør med nærmeste utvikler: "Vet du hvorfor vi lager denne app'en"? Får du et relevant svar er muligheten for at du har en mål- og endringsorientert prosjektorganisasjon. Begynner svaret med "Øhhhhh....." så har du en liten jobb å gjøre.

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:

"Roing handler om:

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