Smidige Metoder Praktisk erfaring med bruk av smidige metoder (EVO) Jens Egil Evensen, Seniorkonsulent

1. Introduksjon til smidige metoder og EVO Agenda 1. Introduksjon til smidige metoder og EVO 2. Gjennomgang av praktisk bruk av smidig metode (EVO) Hva gjorde vi og hvordan Hva fungerte bra og mindre bra Observasjoner 3. Noen refleksjoner i forhold til prosjektleders rolle

1. EVO – Evolutionary Project Management ”Foredlet” av Tom Gilb Modnes over tid av brukerne av metoden (Open source metode?) Første tilfelle innen industri på 40 tallet Benyttet innenfor IT fra 60-tallet (IBM ”Cleanroom”) Mye fokus på krav (mål) og rutiner Krav skal være målbare (kvantifisering og nedbrytning av komplekse krav) Krav skal ikke inneholde systemdesign (med mindre det er absolutte krav – da kaller vi det begrensninger, eller Design Constraints) Krav skal være entydige (for alle tiltenkte lesere) Faste iterasjoner med faste møter og rutiner Praktisk gjennomføring overlates for en stor del til fagkompetansen Kan med fordel benytte egen metodikk for produksjon av løsninger (for eksempel Scrum)

Eksempel: Krav: Selger.Effektivitet Skala: Tiden en [Selger] benytter for å registrere en [Salgsordre] Målemetode: Ta tiden på 10 [Salgsordre] og regne ut gjennomsnitt Før [KAM, Standardordre med 2 produkter]: 5 minutter <- måling 2006 Mål[KAM, Standardordre med 2 produkter]: 1 minutt <- salgssjef Toleranse[KAM, Standardordre med 2 produkter]: 2 minutter <- salgssjef Kravet sier ingenting om HVORDAN dette skal gjøres. Kun noe om hva man ønsker å oppnå! (skiller mellom mål og middel)

Eks: Design: System.Salgsordre.Utforming Beskrivelse: Redesign av skjermbilde for registrering av salgsordre Detaljbeskrivelse: <link til dokument> Est. Pris: 40 timer? <- Utvikler:Gunnar Troverdighet: 0,8 (Har gjort det før i et annet prosjekt) Påvirker: Selger.Effektivitet + 100% (fra 5 min til <1 minutt) Selger.Fleksibilitet – 5% (fra x til y?) Selger.Effektivitet.AntallTelefonerPerDag + 100% (fra 50 til 100 per dag)

Designforslag prioriteres etter kost/nytte Retningslinjer Designforslag prioriteres etter kost/nytte Summen av positiv og negativ på virkning på de viktigste kravene (10-20) og vesentlig påvirkning på andre krav Design forslag som ikke benyttes beholdes som mulige senere løsninger Designforslag bør kunne implementeres på en iterasjon Ressursforbruker på en iterasjon bør ikke overskride 2-5% av totalressursene Designforslag (løsningsforslag) bør kunne gå utover ”applikasjonens” grenser

Prosjekt livssyklus – Tradisjonell Krav / Analyse Design Kan gå tilbake til Implementering / Test Kan gå tilbake til: Produksjon Kontrakt (point of no return)

Prosjekt livssyklus - Smidig Gevinstplan Krav / Analyse Design Implementering Produksjon / Måling Går tilbake til Krav / Analyse Kontrakt (på gevinstplan) – Hva skal kunden oppnå sammen med oss?

Hva gjør metoden smidig? Varierende midler (means) eller Varierende mål (goals) NB! : Hvis målet er varierende – er du sikker på at det er det virkelige målet? Hvis man opplever et varierende mål. Kan et perspektivskifte avsløre det egentlige målet?

2. Praktisk eksempel på faktisk gjennomføring Kunde: Stor norsk data- og telekommunikasjonsbedrift Oppstart: 01.12.2006 Mål: Implementering av Microsoft CRM Begrensning: Microsoft CRM Mål: Bedre kundeservice, selge mer, øke marginer, effektivisere, ledelsesinformasjon etc…etc… vha bl.a. Microsoft CRM ??

Innledende workshop - ledelse Etablering av prosjektrutiner Møter Rapportering Tilgang til beslutningstakere Felles forståelse av mål (visjon, gevinster, strategi) Forankring Bevisstgjøring av rettigheter (og plikter) som kravstiller

Innledende workshop - IT Etablering av prosjektrutiner Møter Rapportering Tilgang til ressurser Felles forståelse av ledelsens mål (Hvorfor?) Forankring Bevisstgjøring av rettigheter (og plikter) som premissgiver

Syklus Mandag Tirsdag Onsdag Torsdag Fredag Styringsgruppe Møte v. behov P.leder kunde Daglig kontakt Statusmøte P.leder Avenir Statusrapport Oppfølging IT Avenir Utvikling Prod ved behov IT kunde Prod hver 14. d

Om å holde interessen oppe Levere verdi, HVER UKE til interessenter Prioritere de viktigste interessentene (i dette tilfellet, ledelsen representert ved kundens prosjektleder og prosjekteier) Være hos kunden Løse problemer NÅ, ikke til uken eller neste møte Omfattende bruk av workshops med ledelse og brukere for å utforme krav og løsninger underveis

Sub-optimalisering (for organisasjon og system) Observasjoner Personavhengighet (!?) Kunden blir veldig avhengig av navngitt prosjektleder. Ofte relatert til rollen som bindeledd mellom IT og ledelse fordi begge ”parter” opplever prosjektleder som sin mann i forhold til den andre ”part” Sub-optimalisering (for organisasjon og system) Mellomløsninger kan gi konsekvenser videre og misoppfattes ofte som mål Vanskelig å ”kaste” lønnsomme midlertidige løsninger ”Rotete” arkitektur Må løses med ”grønne” uker eller måneder

Konklusjon – for dette prosjektet Fokus på gevinst har gitt bedre kvalitet på løsningen Krever mye av prosjektleder Krever engasjement og forankring hos kunde Samme kostnad som andre prosjekter, men MYE mer for pengene Krever medlemmer som er ”problemløsere”, og som forstår kundens forretning, ønsker og behov

3. Noen refleksjoner i forhold til prosjektleders rolle En ”smidig” prosjektleder må som før kombinere Fagkompetanse og Forretningsforståelse Men smidige metoder stiller endrede krav til prosjektlederen

Endringer i fokus for prosjektleder Prosjektledelse (Endrede virkemidler, endret fokus) Følge opp fremgang (og fremdrift) Holde prosjektet innenfor gjeldende rammer Prosessleder (Mer fokus på dette, kortere sykluser) Prosesser i forhold til utviklingsteam Prosesser i forhold til oppdragsgiver/kunde/bruker Rådgiver (Enda mer fokus og større frihetsgrad) Ansvar for at bedriften får den best mulige løsningen (kost/nytte) uavhengig av system Endringsleder (Enda mer fokus – gevinstuttak med en gang!) Sørge for at organisasjonen er i stand til å utnytte løsningen Styre forventninger Tolk (Dette er vi vant med, men nå blir vi enda mer operative) Til en viss grad ”limet” mellom forretningssiden og teknologisiden Prosjektleder: Holde orden på fremdriftsplan, estimater og budsjet. Motivere og følge opp prosjektteam Rapportere til kunde/ledelse Rådgiver Sørge for at kunden og prosjektet er tilstrekkelig informert til å foreta kloke beslutninger og prioriteringer underveis Endringsleder Sørge for å følge opp at organisasjonen er klar for å ta systemet i bruk Sørge for at gevinster realiseres løpende Tolk ”Oversette” mellom IT-ish og Management-ish og andre veien, for å sørge for en enhetlig oppfatning av hvilke mål man har og hvilke løsninger man går for

Spesielle utfordringer Dialogen mellom ledelse og IT (forretning og teknologi) Synliggjøringen av mål på ”realiserbart” nivå Gevinstplan som viser sammenhengen mellom overordnede mål og detaljerte realiserbare gevinster Perspektiv (en persons mål er en annen persons middel) Finne målemetoder som gir ”riktige” svar Ikke måle bare det som er enklest å måle, men det som er lurest å måle Fokusere på de aller viktigste kravene!!! Få ALLE til å fokusere på de aller viktigste kravene!!! Viktigste krav: Non-functional requirements Ikke-funksjonelle krav Øvrige krav Andre krav Visjon Strategi Kvalitetskrav

Hva med tidsplaner og estimater? Man bestemmer seg for et eller flere mål/krav og hvor mye penger eller hvor mye tid man vil bruke, så jobber man sammen for å oppnå mest mulig innenfor disse rammene Det å estimere et samlet smidig prosjekt er derfor i noen grad en selvmotsigelse Implementeringen av et design kan estimeres, men disse blir til underveis