Foredraget tar utgangspunkt i hvorvidt prosjektledelse som fag og ansvarsområde endrer seg etter inntoget av smidige metoder. Påstanden min er at vi alt for liten grad er flinke til å utnytte det potensialet vi har fått med Scrum. Spesielt mangler vi fokus på gevinstrealisering. Dette fører til at systemutviklingsprosjektene blir gode på kontinuerlig forbedring av selve det å lage god kode, men i liten grad evaluerer treffsikkerheten i leveransene opp mot systembrukernes behov.
Her finner du foilene jeg brukte:
Mangler vi fokus på gevinstrealisering i smidige prosjekter?
For flere artikler og foredrag om gevinstrealisering, sjekk gevinstrealiseringbloggen min.
torsdag 12. november 2009
søndag 25. oktober 2009
Når applausen i prosjektet har stilnet: Hva skjer etter at Smidigprosjektet er levert?
Fra Computerworld mars 2009:
Anne Kristine Næss er Cand.Polit med hovedfag i Sosialantropologi, og er seniorkonsulent i Avenir AS. Hun har erfaring som prosjektleder og endringsleder fra IT-prosjekter i offentlig sektor. For tiden jobber hun med innføring av leveransene av et stort, offentlig prosjekt som baserer seg på smidig systemutvikling. Anne Kristine er Avenirs fagansvarlige for gevinstrealisering.
I Computerworld 30.03.09 åpner Ahlert Hysing døra ytterligere på gløtt for smidig systemutvikling som nytt paradigme her til lands. Metoden, eller rettere sagt settet med gode praksiser, tar tak i mye av det som ikke har fungert i fossefallsprosjektene. Hysing beskriver noen utfordringer med fossefall og noen fordeler med Smidig, men lar tittelen ”Klappsalver for smidig” henge litt i lufta. Med mindre man leser artikkelen nøye, kan man tro at Smidig gir løsninger på alle fossefallsprosjektenes problemer. Det var kanskje ikke Hysings hensikt? I dette innlegget ønsker jeg å belyse noen forventninger det kan være skummelt for prosjekteiere og andre premissgivere å ha til Smidig – forventninger Smidiglitteraturen i liten grad selv tar mål av seg å innfri. De kan føre til like dårlige prosjektresultater og mangelfull gevinstrealisering som andre systemutviklingsmetoder til nå har gitt. For det er ikke nødvendigvis i systemutviklingsløpet de største feilene gjøres.
Fra behov til måloppnåelse
Mange aspekter ved systemutvikling påvirkes i overgangen fra fossefall til Smidig. Samlebåndsarbeid skiftes ut med tverrfaglige utviklingsteam, som gjennom dialog med kunden (her: produkteieren) forfiner behovene prosjektet springer ut fra. Beslutninger tas først når behovene er ferdig utdypet. Fokus på kontrakter og spillteori byttes ut med stor åpenhet rundt arbeid og fremdrift. Borte er den vrange kunden som ønsket rabatt, og inn trår en løsningsfokusert produkteier som fortløpende gir klarsignaler eller korrigerer kurs. Selvorganiserende utviklingsteam leverer potensielt implementerbar kode hver iterasjon (1-4 uker), uten at noen behøver å rasle med kontrakten. Det er altså mye god tenkning bak dette nye paradigmet.
Smidig utvikling løser behov istedenfor å tilfredsstille krav, hevder Hysing. Er det å løse behov det samme som å nå strategiske mål? I fossefallsprosjektene ble unødvendig funksjonalitet laget fordi kravene måtte skrives lenge før systemutviklingen og modningen av prosjektet startet. Men hva med produkteiere som lar seg forføre av alt utviklerne kan tilby av smart funksjonalitet underveis? Nye behov overskygger lett gamle og langt viktigere behov, eller fører til prosjektutvidelser. Hysing skriver også at ”Løsningen reflekterer ofte de mest taleføre og dominerende brukerrepresentantene” i fossefallsprosjektene. Blir dette bedre i smidige prosjekter? Kravspesifikasjonen i fossefallsprosjekter blir sendt på høring i organisasjonen, noe som gir diskusjoner og justeringer mellom brukergruppene. I Smidig justeres kravene i daglige eller impulsive stand up-møter, hvor alle har adgang til å lytte. Men de minst taleføre vet ikke alltid når det skal gjøres avklaringer som får betydning for deres behov, og må stole på en felles produkteier. En kollega av meg beskrev dennes dilemma: ”Tenk deg et systemverktøy som skal løse behovene på et sykehus: hvordan kan én produkteier gjøre rede for alle avdelingenes behov?” Og hvordan han eller hun skal prioritere mellom konkurrerende og motstridende behov gir ikke Smidig svar på.
Gevinstrealisering
Mye av årsaken til overskridelser i systemutviklingsprosjekter skyldes manglende evne eller vilje hos kunden til å fokusere på hvilke konkrete mål prosjektet skal bygge opp under, og hvordan måloppnåelsen skal måles og følges opp etter implementering. Smidig slår fast at alt man lager skal beskrives i form av hvilken nytte elementet skal kunne gi, men sier ikke hvordan ferdig utviklet funksjonalitet skal utløse gevinster. Metoden sier heller ikke noe om hvilke overordnede mål og strategier funksjonaliteten skal understøtte. Det er produkteieren som selv må foreta disse vurderingene. Man kan altså si at smidig systemutvikling minsker risikoen for at prosjektet fullstendig kaster bort tiden, men sikrer ikke at tiden brukes til å gi uttelling for investeringen.
Det er gledelig å se at smidig systemutvikling har tatt grep om mye av det som gjorde systemutviklingsjobben vanskelig. Desto mer synd er det når man glemmer at Smidigparadigmet regulerer og optimaliserer nettopp systemutviklingsløpet. Det å slutte fra at dette gjøres rasjonelt og hensiktsmessig til at behovene til systembrukerne faktisk dekkes i siste instans, er i beste fall naivt. Teknologien er kun ett av flere virkemidler for å dekke et behov. Man må i tillegg sørge for økt kompetanse, en organisasjon som legger til rette for bedre arbeidsprosesser, og ikke minst: en økt forståelse hos systembrukerne av hva som skal til for å skape verdier. Hva er våre primære mål? Er våre behov godt nok kartlagt før vi begynner? Kan vi dekke behovene våre gjennom å utnytte det vi allerede har på en bedre måte, i stedet for å starte nyutvikling? Hvordan sikrer vi at systemløsningen blir brukt etter hensikten? Dette har ikke Smidig noen teknikker eller praksiser som løser, like lite som fossefallsprosjektene hadde det. Så gå i gang med å etablere solide prosesser for gevinstrealisering først som sist. Jobb deg selv frem til svarene på disse spørsmålene, og tenk mer på det som skal skje etter at prosjektet er pakket sammen. Enten du ønsker å oppleve klappsalver underveis i systemutviklingsløpet eller la det skumme hvitt mellom fasene i et fossefall.
Anne Kristine Næss er Cand.Polit med hovedfag i Sosialantropologi, og er seniorkonsulent i Avenir AS. Hun har erfaring som prosjektleder og endringsleder fra IT-prosjekter i offentlig sektor. For tiden jobber hun med innføring av leveransene av et stort, offentlig prosjekt som baserer seg på smidig systemutvikling. Anne Kristine er Avenirs fagansvarlige for gevinstrealisering.
I Computerworld 30.03.09 åpner Ahlert Hysing døra ytterligere på gløtt for smidig systemutvikling som nytt paradigme her til lands. Metoden, eller rettere sagt settet med gode praksiser, tar tak i mye av det som ikke har fungert i fossefallsprosjektene. Hysing beskriver noen utfordringer med fossefall og noen fordeler med Smidig, men lar tittelen ”Klappsalver for smidig” henge litt i lufta. Med mindre man leser artikkelen nøye, kan man tro at Smidig gir løsninger på alle fossefallsprosjektenes problemer. Det var kanskje ikke Hysings hensikt? I dette innlegget ønsker jeg å belyse noen forventninger det kan være skummelt for prosjekteiere og andre premissgivere å ha til Smidig – forventninger Smidiglitteraturen i liten grad selv tar mål av seg å innfri. De kan føre til like dårlige prosjektresultater og mangelfull gevinstrealisering som andre systemutviklingsmetoder til nå har gitt. For det er ikke nødvendigvis i systemutviklingsløpet de største feilene gjøres.
Fra behov til måloppnåelse
Mange aspekter ved systemutvikling påvirkes i overgangen fra fossefall til Smidig. Samlebåndsarbeid skiftes ut med tverrfaglige utviklingsteam, som gjennom dialog med kunden (her: produkteieren) forfiner behovene prosjektet springer ut fra. Beslutninger tas først når behovene er ferdig utdypet. Fokus på kontrakter og spillteori byttes ut med stor åpenhet rundt arbeid og fremdrift. Borte er den vrange kunden som ønsket rabatt, og inn trår en løsningsfokusert produkteier som fortløpende gir klarsignaler eller korrigerer kurs. Selvorganiserende utviklingsteam leverer potensielt implementerbar kode hver iterasjon (1-4 uker), uten at noen behøver å rasle med kontrakten. Det er altså mye god tenkning bak dette nye paradigmet.
Smidig utvikling løser behov istedenfor å tilfredsstille krav, hevder Hysing. Er det å løse behov det samme som å nå strategiske mål? I fossefallsprosjektene ble unødvendig funksjonalitet laget fordi kravene måtte skrives lenge før systemutviklingen og modningen av prosjektet startet. Men hva med produkteiere som lar seg forføre av alt utviklerne kan tilby av smart funksjonalitet underveis? Nye behov overskygger lett gamle og langt viktigere behov, eller fører til prosjektutvidelser. Hysing skriver også at ”Løsningen reflekterer ofte de mest taleføre og dominerende brukerrepresentantene” i fossefallsprosjektene. Blir dette bedre i smidige prosjekter? Kravspesifikasjonen i fossefallsprosjekter blir sendt på høring i organisasjonen, noe som gir diskusjoner og justeringer mellom brukergruppene. I Smidig justeres kravene i daglige eller impulsive stand up-møter, hvor alle har adgang til å lytte. Men de minst taleføre vet ikke alltid når det skal gjøres avklaringer som får betydning for deres behov, og må stole på en felles produkteier. En kollega av meg beskrev dennes dilemma: ”Tenk deg et systemverktøy som skal løse behovene på et sykehus: hvordan kan én produkteier gjøre rede for alle avdelingenes behov?” Og hvordan han eller hun skal prioritere mellom konkurrerende og motstridende behov gir ikke Smidig svar på.
Gevinstrealisering
Mye av årsaken til overskridelser i systemutviklingsprosjekter skyldes manglende evne eller vilje hos kunden til å fokusere på hvilke konkrete mål prosjektet skal bygge opp under, og hvordan måloppnåelsen skal måles og følges opp etter implementering. Smidig slår fast at alt man lager skal beskrives i form av hvilken nytte elementet skal kunne gi, men sier ikke hvordan ferdig utviklet funksjonalitet skal utløse gevinster. Metoden sier heller ikke noe om hvilke overordnede mål og strategier funksjonaliteten skal understøtte. Det er produkteieren som selv må foreta disse vurderingene. Man kan altså si at smidig systemutvikling minsker risikoen for at prosjektet fullstendig kaster bort tiden, men sikrer ikke at tiden brukes til å gi uttelling for investeringen.
Det er gledelig å se at smidig systemutvikling har tatt grep om mye av det som gjorde systemutviklingsjobben vanskelig. Desto mer synd er det når man glemmer at Smidigparadigmet regulerer og optimaliserer nettopp systemutviklingsløpet. Det å slutte fra at dette gjøres rasjonelt og hensiktsmessig til at behovene til systembrukerne faktisk dekkes i siste instans, er i beste fall naivt. Teknologien er kun ett av flere virkemidler for å dekke et behov. Man må i tillegg sørge for økt kompetanse, en organisasjon som legger til rette for bedre arbeidsprosesser, og ikke minst: en økt forståelse hos systembrukerne av hva som skal til for å skape verdier. Hva er våre primære mål? Er våre behov godt nok kartlagt før vi begynner? Kan vi dekke behovene våre gjennom å utnytte det vi allerede har på en bedre måte, i stedet for å starte nyutvikling? Hvordan sikrer vi at systemløsningen blir brukt etter hensikten? Dette har ikke Smidig noen teknikker eller praksiser som løser, like lite som fossefallsprosjektene hadde det. Så gå i gang med å etablere solide prosesser for gevinstrealisering først som sist. Jobb deg selv frem til svarene på disse spørsmålene, og tenk mer på det som skal skje etter at prosjektet er pakket sammen. Enten du ønsker å oppleve klappsalver underveis i systemutviklingsløpet eller la det skumme hvitt mellom fasene i et fossefall.
torsdag 17. september 2009
Documentation is not Waste
Many agile projects focus merely on producing running code, and leave out documentation on how to use, implement and maintain it in an IT-services organization. Thus losing great value potential for its stakeholders.
One thing is if this is extremely user friendly software, or standard out of the box-products. Another thing entirely is if this is software tailor made for the customer, making changes in the way people will work while using it:
· Change of processes and workflow for end users and IT-services
· Change of quality of the end users’ work
· Change of skills needed in order to use the software correctly
· Change of the management’s way of following up on their employees
· Change of results/output (financial value)
· Change of results on SLA’s (IT availability, HR, etc.)
· Etc.
Even small changes in these and other factors in the customer’s organization need planning. And this is why Scrum and other practices can be very efficient. Good dialogue between customer and developers lead to good software. And documentation showing value potential and possible negative effects for each user story – produced as a natural part of every sprint – gives the
customer time to prepare for what’s coming.
See http://almostasfunny.blogspot.com/2009/08/using-wiki-for-agile-user-stories.html for a good tip on how to arrange documentation along the way.
The Product Owner
Unfortunately there are large variations in how Product Owners perceive their roles. There are also many obstacles to managing the stakeholders and Scrum teams in a good way:
One thing is if this is extremely user friendly software, or standard out of the box-products. Another thing entirely is if this is software tailor made for the customer, making changes in the way people will work while using it:
· Change of processes and workflow for end users and IT-services
· Change of quality of the end users’ work
· Change of skills needed in order to use the software correctly
· Change of the management’s way of following up on their employees
· Change of results/output (financial value)
· Change of results on SLA’s (IT availability, HR, etc.)
· Etc.
Even small changes in these and other factors in the customer’s organization need planning. And this is why Scrum and other practices can be very efficient. Good dialogue between customer and developers lead to good software. And documentation showing value potential and possible negative effects for each user story – produced as a natural part of every sprint – gives the
customer time to prepare for what’s coming.
See http://almostasfunny.blogspot.com/2009/08/using-wiki-for-agile-user-stories.html for a good tip on how to arrange documentation along the way.
The Product Owner
Unfortunately there are large variations in how Product Owners perceive their roles. There are also many obstacles to managing the stakeholders and Scrum teams in a good way:
- The Product Owner looses his daily contact with his line organisation, thus being rejected as a good manager of its needs.
- The Product Owner stops being interested in what happens within each sprint, causing trouble for the Scrum teams when it comes to clarifying their needs.
- The Project Manager interferes with what the Product Owner can order (scope handling).
Abonner på:
Innlegg (Atom)