Prosjektledelse

Kompetent til å forbedre

Bj�rn Eilertsen — Sat, 31 Oct 2009 22:09:28 GMT

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.

Systeminnføring er en prosess.

Bj�rn Eilertsen — Mon, 22 Jun 2009 07:08:58 GMT

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

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

Det finnes standard risikofaktorer man kan lære av...

Bj�rn Eilertsen — Tue, 17 Feb 2009 22:37:16 GMT

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

Levér biter ofte

Bj�rn Eilertsen — Tue, 16 Dec 2008 20:10:50 GMT

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...

Ha en plan for dine nøkkelressurser

Bj�rn Eilertsen — Tue, 11 Nov 2008 20:36:48 GMT

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.

Ta kontroll med endringer/ avklaringer i prosjektet

Bj�rn Eilertsen — Fri, 24 Oct 2008 16:01:20 GMT

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

Snakk daglig om prosjektets mål

Bj�rn Eilertsen — Fri, 10 Oct 2008 20:33:44 GMT

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.

Sørg for å ha en dedikert testleder

Bj�rn Eilertsen — Wed, 01 Oct 2008 18:15:41 GMT

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…

Konverter beistet

Bj�rn Eilertsen — Thu, 25 Sep 2008 17:21:32 GMT

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…

Tid for revisjon av prosjektmillø

Bj�rn Eilertsen — Fri, 12 Sep 2008 18:55:12 GMT

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 :-)