Feilmelding

  • Deprecated function: __autoload() is deprecated, use spl_autoload_register() instead i require_once() (linje 9 av /customers/c/5/e/rofconsulting.no/httpd.www/sites/all/libraries/htmlpurifier/library/HTMLPurifier.auto.php).
  • Deprecated function: Methods with the same name as their class will not be constructors in a future version of PHP; ctools_context has a deprecated constructor i require_once() (linje 127 av /customers/c/5/e/rofconsulting.no/httpd.www/sites/all/modules/ctools/ctools.module).
  • Deprecated function: Methods with the same name as their class will not be constructors in a future version of PHP; ctools_context_required has a deprecated constructor i require_once() (linje 127 av /customers/c/5/e/rofconsulting.no/httpd.www/sites/all/modules/ctools/ctools.module).
  • Deprecated function: Methods with the same name as their class will not be constructors in a future version of PHP; ctools_context_optional has a deprecated constructor i require_once() (linje 127 av /customers/c/5/e/rofconsulting.no/httpd.www/sites/all/modules/ctools/ctools.module).
  • Deprecated function: Methods with the same name as their class will not be constructors in a future version of PHP; panels_cache_object has a deprecated constructor i require_once() (linje 127 av /customers/c/5/e/rofconsulting.no/httpd.www/sites/all/modules/ctools/ctools.module).
  • Deprecated function: The each() function is deprecated. This message will be suppressed on further calls i _menu_load_objects() (linje 571 av /customers/c/5/e/rofconsulting.no/httpd.www/includes/menu.inc).

Suksessfullt IT prosjekt

IT prosjekt på tid, på budsjett og med riktig kvalitet.

IT prosjekt kan leveres i henhold til opprinnelig tidsplan, i henhold til avtalt budsjett og med riktig kvalitet i forhold til forutsetninger, krav og forventninger.  Jeg ser IT prosjekt som typiske prosjekter som først og fremst har store utfordringer med å treffe de tre kriteriene som ligger til grunn for suksess (egentlig fire suksesskriterier, men det er en annen og senere artikkel …). Her skal jeg fortelle om hvordan et prosjekt klarte å nå disse målene og derfor kan regnes som et suksessfullt IT prosjekt.

Bakgrunnen til prosjektet.

SAS har inngått en avtale hvor Lufthansa vil være totalleverandør av flykomponenter til SAS, med en varighet på syv år. En slik avtale er en av mange forutsetninger for robust og økonomisk flyvedlikehold. Dette avhenger selvfølgelig av at det blir gjort nødvendige tilretteleggelser i de operasjonelle prosessene for å klare å ta ut de økonomiske fordelene, og ikke minst for å skape robustheten i leveransene.

En av disse tilretteleggelsene var for SAS og Lufthansa en opprettelse av et elektronisk integrasjon, en såkalt EDI løsning (Electronic Data Interchange), mellom SAS sitt material håndteringssystem og Lufthansa sitt system (i realiteten er dette ikke bare ett system hverken hos SAS eller Lufthansa, men flere systemer som ivaretar forskjellige funksjoner i logistikk- og luftdyktighetsøyemed). Hensikten med en slik modul er å synkronisere deler av systemet i SAS med deler av systemet til Lufthansa.

Et svært forenklet eksempel på dette: Når det blir gjort en bestilling i innkjøpsmodulen i SAS’ system, vil systemet generere en melding som sendes direkte til Lufthansa sitt system. Der vil meldingen blant annet oppdatere deres forsyningssystem slik at ordren blir gjort kjent der og prosessert etter gjeldende regler i deres system.

Med bakgrunn i dette behovet ble det derfor besluttet å sette sammen en prosjektgruppe med mandat og ansvar for design, utarbeidelse, testing og implementering av en slik løsning. Med hensyn til de store effektene i bedriften, blev det satt stort fokus på at prosjektet må lykkes, både med tanke på tid og kvalitet. Siden luftfarten lenge har vært i en nedgangsperiode var også budsjettet relativt begrenset. Min oppgave ble å lede prosjektet.

Prosjektets forutsetninger.

Det er en forutsetning i SAS at prosjekter, så langt det er mulig, skal drives etter SAS’ prosjektstandard, noe som også gjaldt dette prosjektet. Standarden har mange likhetstrekk med PMI (Project Management Institute) sin Project Management Book of Knowledge, som er en verdenskjent standard for prosjektenes diverse prosesser.

Videre lå det en rekke forutsetninger i avtalen for hvordan EDI løsningen skulle bygges opp, og blant annet at det skulle gjøres i to prosjektfaser, hvor den første skulle inneholde en «basis løsning», og den andre diverse tilleggs forbedringer for å optimalisere løsningen.

Prosjektplanlegging.

Før prosjektet gikk i gang, ble det i henhold til SAS’ prosjektstandard skrevet en ToR (Terms of Reference), som blant annet gir prosjektleder mandatet som trengs for å drive gjennom prosjektet med alle dets tilhørende prosesser. Prosjektet startet derfor opp med kun en prosjektleder samt en styringsgruppe hvor prosjekteier var ordførende.

Prosjektleders oppgaver var derfor først planlegging, deretter bemanning, deretter planlegging og til sist planlegging. Her ble det gjort en grundig jobb, og en prosjektplan ble utformet hvor prosjektets viktigste prosesser var planlagt.

Blant annet fantes det her en plan for hvordan prosjektet skulle bemannes, korrespondansen med ressursenes linjeledere, en kommunikasjonsstrategi, en plan for hvordan jobbe med risikoer, håndtering av innkjøp, osv. Viktigst av alt var nok den delen av prosjektplanen som beskrev definisjonen av prosjektets oppdrag (scope definition), tidsplanen, budsjettet og ikke minst krav til kvalitet og hvordan dette skulle oppnås.

Ut over det allerede nevnte ble også en prosess for endringshåndtering beskrevet for å sikkerstille at prosjektets oppdrag ikke ville endre seg ukontrollert. Igjen, planlegging, planlegging og atter planlegging.

Dette høres kanskje utrolig omfattende ut, men tro meg, det er det ikke. Denne investeringen av tid, har også betalte seg opptil flere ganger gjennom prosjektets livssyklus.

Gjennomføring og resultater – Planen blir satt i live

Etter planleggingsfasen gikk prosjektet over i sin gjennomføringsfase, hvor det blant annet ble satt sammen en prosjektgruppe med de forskjellige og nødvendige kompetansene. Den første fasen var i gang, og design, utarbeidelse, testing og implementering ble iverksatt.

En interessant vurdering i denne fasen var at, mot normalt, IT prosjektet var på tidsplanen, mens resten av organisasjonen og alle andre forutsetninger for samarbeidsavtalen var etter planen. Dette medførte at de som skal utarbeide kravspesifikasjonen etter sine prosesser ikke hadde sine prosesser klare enda. Dette var definitivt en risiko for å klare gjennomføringen etter planen, noe som krevde strukturert risikostyring. En strategi for å håndtere dette ble justeringer i tidsplanen, slik at enkelte aktiviteter ble presset gjennom raskere for å øke tidsbufferen i enden.

Prosjektleveransene fra første fase ble levert på tid, selv med de utfordringene som fantes på veien. Det fantes en tidsplan som fortalte hvilken aktiviteter som måtte på plass inne hvilken tid, og det fantes en plan for hvordan risikoer i prosjektet skulle håndteres. Planene ble brukt og resultatet var leveranse på tid.

Når prosjektet gikk over i den andre fase ble det avgjort at lærdommen fra første fase skulle brukes for optimering av planverket, og blant annet tidsplanen ble justert for å øke tidsbufferen i enden. Dette var nå blitt en aggressiv plan som krevde høyt fokus og mye oppfølging over en periode. Planen var dog realistisk, selv om det fantes noe skepsis i forhold til gjennomførbarheten.

Resultatet ble at planen ble fulgt og tidsbufferen i enden ble en tilnærmet ubrukt buffer. Det var en god følelse, men det er da også naturlig å stille spørsmålet om hvordan dette påvirket kostnaden. Vanligvis vil reduksjon av aktiviteters gjennomføringstid resultere i en høyere kostnad hvis ikke det skal gå på bekostning av kvalitet. Dette er korrekt, men det finnes allikevel et lite unntak. Vi mennesker jobber bedre under en viss mengde press, og det er derfor mulig å presse ned tiden på aktiviteter en viss grad uten at det påvirker kvaliteten, samtidig som det kan redusere kostnaden. Her finnes det selvfølgelig begrensninger, men i dette prosjektet klarte vi å presse til det ytterste for å oppnå den positive effekten av dette.

Så, hvorfor ble dette et suksessfullt prosjekt?

Dr. W. Edwards Deming gjorde PDCA sirkelen kjent, gjennom å skape forståelse for denne arbeidsmetodikken i kvalitetsarbeid. PDCA står for Plan-Do-Check-Act, og kan definitivt også appliseres i prosjektarbeid, og det handler om i grunnen om å ha en plan om hva som skal gjøres, gjøre det man planla, sjekke at det du gjorde gir forventede resultater og til sist gjøre om det som ikke ga forventede resultater.

En forutsetning for denne tankegangen er at det finnes en solid plan som også tar høyde for kontinuerlig forbedring og optimering underveis.

Eksempler på dette er det mange av, men for å nevne et vil jeg gjerne trekke frem et eksempel på forsøk på å utvide prosjektets oppdrag (scope creep). EDI løsningen er i utgangspunktet, som nevnt tidligere en løsning for å synkronisere informasjon mellom to systemer, og dette er også da hva som ligger i prosjektets oppdrag.

Etter hvert som prosjektet går fremover, blir det mer og mer tydelig at det også er fornuftig med endring av systemlogikken i materialhåndteringssystemet i SAS. Det blir derfor etter hvert flere diskusjoner rundt dette med flere at prosjektets medlemmer, og ikke minst en forventning om at dette også løses i prosjektet.

I dette tilfellet var det ingen tvil om at det eneste fornuftige var å gjøre denne endringen i systemlogikken. For det første ville dette gjøre arbeidsprosessene mer smidige, og for det andre vil det gjøre EDI løsningen mer robust. Det var derfor også fristene å bare «fikse» dette!

Men som nevnt, fantes det for dette prosjektet en definisjon av prosjektets oppdrag, hvor dette ikke var inkludert, og det fantes en definert prosess for å håndtere endringer. Uansett hvor fristene det var å bare «fikse» dette, ble den definerte prosessen fulgt, og resultatet ble at vi måtte sette noen forutsetninger for å ta inn denne endringen.

En forutsetning var endring av kompetanseprofilen i prosjektgruppen, den andre var endring av tidslinjen. Dette ble godkjent av styringsgruppen, og endring ble godtatt og skrevet inn i definisjonen av prosjektets oppdrag (Plan). Vi utførte så denne tilleggsoppgaven (Do), og så deretter at visse systemforutsetninger ikke var på plass (Check). For å komme videre med dette, var vi nødt til å benytte et eksternt selskap til å gjøre noen nødvendige systemendringer, noe som medførte en høyere kostnad. Dette ble kontrollert opp mot budsjettet, og det kunne fint legges inn under bufferen som var planlagt inn i budsjettet, uten at det var nødt for ytterligere finansiering. Endringen ble derfor iverksatt (Act).

Dette eksemplet viser en endring i prosjektet som ble håndtert under helt kontrollerte former fordi forutsetningene lå til rette for det. Hadde vi bare «fikset» dette er sannsynligheten stor for at vi hadde bommet på både tid og kostnad i forhold til vår godkjente plan. Dette er en av grunnene til at dette prosjektet ble suksessfullt!

Det skal selvfølgelig nevnes at jeg hadde dyktige ressurser i prosjektet som ga meg alle forutsetninger jeg trengte for å drive prosjektet gjennom. Dette er nok den viktigste suksessfaktoren i alle prosjekt, men kanskje også den mest kjente. Jeg valgte derfor ikke å belyse dette i denne artikkelen.

Hva kan vi lære av dette?

Et hvert prosjekt trenger en solid plan, som dekker alle elementer nødvendig for dette prosjektet. En investering av tid i denne planen vil betale seg! Når planen er på plass, må den følges, og den må jobbes med.

En plan skal ikke være statisk, men et verktøy som til enhver tid er optimalisert for situasjonen prosjektet befinner seg i. Altså, lag en plan, jobb etter den, sjekke oppnådd fremdrift og resultat, og ikke minst, gjør endringer når fremdriften eller resultatet ikke viser seg å være som forventet.

Lykke til med ditt neste suksessfulle prosjekt..!