** Evolutionär  **
DET LÄRANDE PROJEKET

Swedish/English
Uppdaterad 061227, rev 1.3

PROJEKTSTYRNING - ARBETSSÄTT!!!   
METODIK!!!  KRAFTFULLT, EFFEKTIVT!

Lärande resultatsökning

Syfte med Evo.
Syfte med Evo. är att erbjuda ett alternativt arbetssätt för projekt där nya eller oprövade resultat önskas eller där det är uppenbart att liknande lösningar inte finns eller har misslyckats tidigare.
Evo:s arbetssätt möjliggör en avsevärd reducering av riskerna i projekt. Arbetssättet kräver mer ledningskapacitet än vad som normalt antas, bl.a. för resurs och relationshantering samt för målstyrning.

Evo. kräver en tydlig vision och väl genomarbetade och förankrade mål.
Under genomförandet raffineras krav, produkt och framställning i en lärande process. Arbetssättet tar vara på befintliga system och kunskaper. De korta effektiva stegen med erfarenhetsöverföring och användarmedverkan är starka drivande faktorer.
Systemintegration samt test tas om hand i varje steg och blir inget problem på slutet av projektet. Stora problem och tekniska osäkerheter kommer snabbt upp till ytan tack vare prioriteringsreglerna.
Varje steg rekommenderas till 2-4% av projektets totala tid, ca 2-4 veckors kalendertid. Helst 2%.

Evo. Passar mindre bra om uppdragsgivaren/kunden vill byta ut ett befintligt system eller produkt i sin helhet.

När man vill ... hantera en oklar/oprövad kravbild och oprövad teknisk design, d.v.s. hög risk successivt införa en ny vision öka möjligheten att träffa marknadsfönster använda resultaten för styrning/uppföljning få tidig återkoppling från användarna få tidig återkoppling på konstruktionen få tidig återkoppling på processen kontrollera riskerna med små tydliga steg tillgodose "brinnande" behov

Nytta... ger hög målfokusering i hela projektet och därmed hög produktivitet utreder och beskriver nytt arbetssätt och nya rutiner med användarna ger en kontinuerlig serie förbättringar i verksamheteten som skall använda resultatet ger ett resultat integrerat med omgivningen tar hand om befintliga uppgifter, system och data. Vilka lätt glöms bort vid normal nyutveckling ger lärande genom att i små kontrollerade steg tillåta misstag och experiment i rimlig omfattning

Fördelar, nackdelar, fallgropar

Anders introduktion

Vad kommer du som läsare att få ut av länkarna och texten nedan om det lärande projektet. Varför är stora företag som Ericsson, IBM, HP och många storföretag inne på detta?

Jag kommer att behålla en del artiklar på originalspråket Engelska, jag svarar gärna på frågor!

Min ambition är att du skall vara övertygad eller minst nyfiken på det evolutionära konceptet.

Du skall få en jämförelse mellan olika metoder för att bedriva större och mindre utvecklingsprojekt och få en förståelse för varför stora projekt med en eller få leveranser är något som bör undvikas.

Hur arbetar vi i det LÄRANDE projektet.

Initiering/utredning (mina förslag):

• Mognadsutvärdering, processtatus
• Förankring, åtagande från ledningen, hur motivera
• Hur paketera och sälja

Huvud planerings process:
1. Undersök effektmål, finns dom, verksamhetsstudie
2. Förbered/bearbeta effektmål, syntax på mätbara mål
3. Riskanalys
4. Ta fram strategier, brainstorming/seminariet kring strategivalen
5. Utför måluppskattning / seminarieform?
5a. Besluta om projektmål (De funktions- och kvalitetsmål vi tar ansvar för)
6. Komplettera/justera/ta bort strategier
7. Utför måluppskattning
8. Om inte 150-300% gå till 6
9. Gör en stegplan, samt tidplan
10. Ev.. ny riskanalys
11. Stegplanering
- sök användarsenarios, gruppera funktioner. Planeringstips - tänk på...
12. Prioritera (störst nytta samt högst risk först) - planeringsexempel
13. Bemanning - nyckelroller (användaransvarig, designansvarig, projektledning)
14. Åtagande
15. Start av genomförandet

Genomförande:
Uppföljning av helheten:

• Hur långt har vi kommit:- Infrastruktur/teknologi- Uppnådd nytta (effekt) (även nedlagd kostnad)
• Korrigera stegplan/strategier
• Resurser/förbrukning (användare och projektteam)
• Uppföljning
• Projektanalys
• Lathund för mätningar

Genomförande av evolutionärt steg:

• Sätt förbättringsmål för steget
• Välj/besluta om idéer (lösningsstrategier)
• Utvärdera idéer (Mål/effekt uppfyllnadsutvärdering)
  - Hur mycket påverkar vald strategi målet för steget
  - Lärdomar från tidigare steg
  - Effekt från efterföljande steg
• Gör steget / köp steget
• Testa internt i projektet
  - uppgift för användarsamordnaren(framgångsfaktor, det som levereras ska fungera)
• Genomför med användare
• Uppdatera plan - tid mm
• Studera resultatet / nyttan
  - Involvera gärna användare i beslut om fortsättning
  

Exempel på hur en grov stegplan görs/beräknas för ett systemutvecklingsprojekt.

I de första stegen planeras de scenarios som ger störst effekt på målen, mest nytta hos kunden.
Samtidigt skall de funktioner som har störst risk lösas.

I de sista stegen planeras de scenarios som ger minst effekt och de funktioner som har
minst risk.

Hur väl något utförs (egenskap på funktion) Kvalitetsmål: - användbarhet - tillgänglighet - lönsamhet - spridning - efterfrågan - testbarhet - underhållskostnad - tillförlitlighet (data) - enkelhet - ljudnivå

Projektmål kan vara både kvalitets- och funktionsmål. Effektmål likaså. AFFÄRS- UPPGÖRELSEN bestämmer.

Vad som skall göras Funktionsmål: - transportera - svarstid - bearbetning... - "arbetsuppgift" - installation - komponent - produkt

Länkar till Thomas Gilbs och Kai Gilbs egen dokumentation, artiklar mm:

Nyheter 2005:  Dokument från Tom; Agile Spec, Design Evalu, Real Req och Firm

Toms tidningsartikel om den evolutionära metodiken från september 1996

En intressant jämförelse mellan olika utvecklingsmodeller, Evolutionär, Inkrementell och traditionell

En artikel skriven inom Hewlet Packard där man infört evolutionär utveckling

Website för Software Research Institute

REQUIRE.ZIP [569k] Requirements - Driven Management using Planguage. GAMLA UTGÅVAN.

EVO_mini.ZIP [520k] Requirements - Driven Management using Planguage. Äldre utgåva! En handbok med avancerade metoder. A guide to critical thinking about complex ideas problems or systems.

Tom Gilb alias Thomas Gilb

Övrigt:

• Introduktion till Practical (INDUSTRIAL) Creativity av Tom.
• Länkar till Thomas Gilbs och Kai Gilbs egen dokumentation
• Plan-Do-Check-Act definerad i Total Quality Management TQM

EVOLUTIONÄR PLANERING
Att tänka på när ett Evolutionärt projekt planeras i små evolutionära steg

• Håll målbilden levande, kommunicera ut den till medarbetarna och användarna kontinuerligt under projektet.
• Håll ledningen väl informerade om strategival.
  Befintliga system och dagens arbetssätt duger ofta mycket väl som en plattform för ett radikalt nytt system. Det innebär många fördelar. Det skapar goodwill hos användargruppen. Att ta vara på det befintliga är en framgångsfaktor. Kostnaden måste ses i ljuset av värdet av att göra framsteg och att få praktisk erfarenhet.
• Gör tidiga leveranser till positiva, lokala och mogna delar av användargruppen.
• Fokusera på några små användbara resultat för användare och/eller kund. (Inget resultat är för litet, en sak en förbättring).
• Fokusera på resultatet (som är definierat i målen), ta små steg mot PLANERAD målnivå).
• Fokusera inte på konstruktions idéer i sig, de är avledande. Ibland kan du ignorera dem helt i det korta perspektivet. T ex. i inledande steg.
• När vissa steg (leverabler) tar lång tid, starta tidig (i bakgrund av andra steg), gör andra användbara steg (leveranser) medan du väntar. Steg kan ibland ta längre tid och kosta mer än 2-4%. 2% rekommenderas.
• Evo. är en alternativ projektstyrmodell, inte en modell för hur resultatet tas fram.
• Du kan förstå saker mycket bättre genom tidiga praktiska upplever (därmed försvinner mycket oro tidigt).
• Om någonting tycks för dyrt att köpa för begränsad inledande användning/utveckling, se om du kan förhandla fram att betala när du verkligen använder produkten. De flesta leverantörer ställer nog upp. De undviker att medtävlare eller andra tillverkare får samma möjlighet.
• Om du inte kan hitta några användbar små leveranser, prata direkt med en riktig 'kund' eller slutanvändare. De har säkert dussintals förslag. Prata med slutanvändarna i vilket fall som helst, de har insikter och kunskaper du behöver.
• Ifall det är omöjligt att få fram slutanvändare, se till att få motsvarande "surrogat" från t.ex interna kunder eller från kommande led i processen.
• Identifiera hinder, men använda inte hindren som ursäkter. Använd istället kreativiteten för att få bort hindren.
• Ett normalt hinder/invändning är: För att ge slutanvändarna ny funktionalitet så måste infrastrukturen/grundstrukturen på plats. Det brukar ta mellan 30-50% av projekttiden. Gör ett evo.delprojekt av infrastruktur uppbyggnaden.

Fördelar med Evo:

• Lärande löper alltid igenom hela cykeln från behov till användbarhet och nytta. Lärande för alla inblandade. Tid avsätts för lärandet.
• Utmanande för teamet, ställer krav på blandning av olika kompetenser.
• Användbara resultat tidigt, redan inom 2 veckor efter förberedelserna.
• Bygger förtroende hos användare och beställare genom att kontinuerligt leverera användbar nytta.
• Integration, test och verifiering är en del i varje steg. Integration, test och verifiering blir inte stort och svårt på slutet av projektet.
• Införande sker gradvis och blir inte problem på slutet eller efter projektet.
• Ger driftåterkoppling tidigt. Vilket medför att underhåll når överenskommen nivå.
• Tidig reell återkoppling av vald teknologi och levererade resultat.
• Visar tidigt om vald design/strategi håller. Riskfyllda eller omfattande funktioner/delar tas tidigt under projektet.
• Om projektet avbryts efter en tid så är delresultaten i praktiskt bruk.
• Projektet är lätt att följa upp mha. nyttoeffekten (många användbara leveranser).
• Arbetssättet Evo. passar bra ihop med t.ex. objektorienterad utveckling.

Nackdelar med Evo:

• krav på kompetens för formulering av mål (och kunskaper om verksamheten)
• kan vara svårt hitta små användbara steg med nytta
• många är ovana att arbeta så - nytt sätt att tänka
• kräver delvis "nya" beslutsmekanismer
• kräver insikt i metoden (från alla inblandade)
• kan ge motstånd hos driftansvariga. (Många leveranser)
• beställaren får inte hela produkten vid första leveransen
• beställaren har svårt att byta ut "allt" efter projektslut

Fallgropar

• starta inte utan tydliga väl förankrade mål men framförallt inte utan vision.
• avsätt extra ledningkapacitet
• tänk på att planera installationer, kom överens med driftansvariga
• börja inte med det enkla utan användarnytta
• glöm inte att utbilda projektmedarbetarna i det nya arbetssättet (en investering i sig)
• kommer ingen 1:a leverans inom 2-3 v så är risken stor att det inte blir ett evo. projekt