I den siste tiden har jeg hatt glede av å delta i en tankesmie om bruk av Lean i IT-prosjekter. I tankesmien har det deltatt både ingeniører, advokater og økonomer. Ideen har vært å få ulike perspektiver på hva som er de praktiske utfordringene i slike prosjekter, både fra leverandørsiden, kundesiden og det juridiske. I smien har vi hatt med Iterate fra leverandørsiden, Belief som representant fra kundesiden og Bull & Co fra juridisk.

Arbeidet har bestått i å sammenligne de tradisjonelle prosessene med de arbeidsmåtene Lean foreskriver. På den måten har vi klart å tegne et kart som beskriver veien frem til å utnytte potensialet til Lean i dine IT-prosjekter. Hva er potensialet til Lean? Riktig utnyttet kan det oppsummeres på denne måten:

• Lavere investeringer og dermed lavere risiko
• Tidligere Return-On-Investment og dermed mer lønnsomme prosjekter
• Bedre feedback og dermed bedre løsninger for sluttbrukeren

Arbeidet med dette skal resultere i et veikart fra tradisjonelle til innføring av Lean i organisasjonen. Det vil være fokusert på utfordringer fra de ulike ståstedene i tankesmien. Det ser ut til å bli i form av et frokostseminar torsdag 8. oktober Følg med!

Minimum marketable features and incremental funding are used to partition the functionality of a computer system into units that are capable of delivering business value independently. By organizing a development project around MMFs and their internal dependencies, it is possible to have partially self-funding projects: As an MMF is completed, the business value that is saved or generated as it goes into production is used to fund the development of subsequent MMFs. Hence, we lower the up-front investment of our projects, and we reduce the development risks by continuously deploying functionality into production.

In short, we may say that using MMFs provide a financial model for lean thinking in software development projects. (For more info on this, refer to the excellent introduction given in “Software By Numbers” by Mark Denne and Jane Cleland-Huang, Prentice Hall, 2003).

Fra tid til annen kommer det prosjektmetodikker som går spesielt hardt ut mot dokumentasjon. Scrum er en metodikk som tilsynelatende faller i denne kategorien. Men det Scrum rammeverket sier er at man skal lage den dokumentasjonen som er nødvendig og ikke lage dokumentasjon for dokumentasjonens del.

Videre vet vi at dokumentasjon kan føre til tolkningsfeil og unøyaktigheter vel så mye som om man ikke hadde dokumentasjon. Det er kommunikasjonen mellom deltakerne i prosjektet som er viktig. Om den er skriftlig eller muntlig – vel det er det ingen fasit på.

Det som er viktig er å se på dokumentasjon (eller til og med kommunikasjon) som en leveranse mellom deltakerne i prosjektet. Hvordan skal jeg som er ansvarlig for en del av prosjektet (f.eks. strategi og visjon) kunne bringe de føringene inn i hele prosjektforløpet og til alle som bidrar i prosjektet? Er det et lite team som utvikler over kort tid så kan en muntlig overbringing være god nok. Kanskje etterfulgt av en konseptmodell som gjør at alle husker det som ble sagt. Hvis teamet er stort, lokalisert på flere steder/land, utvikler over lang tid (kanskje år) og er en del av et større program – vel så trenger man litt mer enn et lite foredrag og en skisse.

En leveranse er et dokument som skal fasilitere kommunikasjon, omfavne beslutninger og stimulere til innovasjon. De tre hovedgrunnene til en leveranse er:

1. Konsistent visjon – sørge for at alle er på samme spor.
2. Redegjørelse – sørge for at alle kjenner beslutninger og konsekvenser av dem.
3. Sporbarhet – den kollektive historien til prosjektet skal kunne spores for å kunne forbedre prosessen.

Dokumentasjon kan lages i lag for å kunne lettere kontrollere detaljer og omfang. Første lag består av de mest essensielle elementene. Det andre laget skal bidra til å skape økt forståelse hos leserne. Det tredje laget skal skape en helhetlig ramme rundt det og kanskje koblinger til andre kontekster.

I arbeidet med å skape en leveranse så er denne framgangsmåten et godt utgangspunkt:

1. Gjør en situasjonsanalyse (hensikt med leveranse, prosesstilhørighet og publikum).
2. Gjør en oversikt over alle informasjonselementer som skal leveransen skal omfatte.
3. Planlegg skissen på papir.
4. Lag en svart/hvitt skisse i et egnet tegneprogram (Illustrator, Visio, Omnigraffle).
5. Lag en plan for bruk av farger.
6. Rafiner det visuelle språket.
7. Legg på tekst på elementene.
8. Finn svake punkter i skissen.
9. Revider skissen i tegneprogrammet.
10. Sjekk arbeidet om alt er med og etter reglene.
11. Juster etter tilbakemelding.
12. Legg på støtteinformasjon (tittel, dato, attributter, legende, versjonsnummer…).