IT-projektledelse. Planlægning og estimering samt Risici og projektmodeller

Transkript

1 IT-projektledelse Planlægning og estimering samt Risici og projektmodeller Lene Pries-Heje IT-projektledelse F2006

2 Indlæringsmål (I) Kunne forklare sammenhængen mellem estimat, ressourcer og projektplan Kunne identificere behovet for ressourcer til et givent projekt Kunne udføre funktionel dekomponering ( Work Breakdown ) Kunne udarbejde en projektplan for et mindre projekt med anvendelse af synkroniseringspunkter, kritiskvej, PERTdiagram og GANTT-diagram. Kunne gøre rede for fordel og ulemper ved udvalgte estimeringsteknikker Kunne argumentere for valg af en eller flere af ovennævnte teknikker ved estimering af et mindre IT-projekt Kunne anvende de valgte teknikker på et mindre ITprojekt.

3 Indlæringsmål (II) Du er i stand til at gennemføre en risikoanalyse og risikohåndtering for et ITprojekt. Kunne gøre rede for forskellige metoder til risikoidentifikation Kunne gøre rede for forskellige projektmodellers karakteristika, anvendelsesområde og betydning for risikostyring og projektplanlægning. Kunne gøre rede for valg af projektmodel i forhold til projektets risikoprofil

4 Hvorfor planlægning? Viser det er muligt at gennemføre projektet indenfor den forventede tid og med det forventede ressourceforbrug Skabe en detaljeret omkostningskalkule og cash-flow oversigt Kunne foretage ressourceallokering og koordinering af ressourcer Motivering af medarbejderne (forudsat de har deltaget i udarbejdelsen af planen). Skabe grundlag for opfølgning og justering af planen Skabe grundlag for risikovurdering af projektets aktiviteter og projektet som helhed

5 Simpel planlægning Tag udgangspunkt i projektets mål og udled: Indsatsområder Milepæle = Delmål på vejen Faser og beslutningspunkter Aktiviteter tilknyttet hver milepæl

6 Mellem- Mellem- Mellem- Slut- tilstand tilstand Y tilstand X tilstand Baglæns tilstandsplanlægning Tag udgangspunkt i den ønskede sluttilstand og udled: En mellemtilstand X, hvorfra man let når den ønskede sluttilstand En anden mellemtilstand Y, hvorfra man let når mellemtilstanden X osv. osv. Aktiviteter udledes ved at spørge: Hvad skal der til for at nå denne mellemtilstand?

7 Arbejdsstruktur Work Breakdown Structure System Opdeling efter: Program ALFA Program BRAVO Modul DELTA 1 Program CHARLIE Modul EKKO 2 1. Proces 2. Produkt 3. Begge dele

8 Netværksplanlægning -Et eksempel Forgængere Estimat A Valg af hardware 150 B Softwaredesign 100 C Installer hardware A 75 D Kodning og test af software B 100 E Konverter filer fra gl. system B 75 F Skriv brugermanual 250 G Brugertræning E, F 75 H Installér og test C, D 50 Lene Pries-Heje IT-projektledelse F2006

9 Vi tegner netværket A 150 C 75 art H 50 B 100 D 100 Slut F 250 E 75 G 75

10 Vi regner forlæns A 150 C 75 art 0 B D H Slut F E G

11 Og baglæns startende med H B F C D E A G art Slut

12 Kritisk vej Aktiviteter der hvis de forsinkes, forsinker det hele art A 0 75 B 0 0 F C D E H G Slut

13 Fra estimat til plan Estimer i timer så der ikke opstår tvivl om, hvad man taler om. En dag kan f.eks. være alt mellem 6 og 16 timer. En uge kan være fra 30 til 100 timer osv. Som omregningsfaktor kan evt. anvendes, at en gennemsnitlig personmåned i Danmark omfatter 18 arbejdsdage eller 135 arbejdstimer (ved arbejdsdage på 7,5 time).

14 Du er ikke effektiv! - 8 timer om dagen, 40 timer om ugen Effektivitetsfaktoren: Hvor meget tid arbejder hver projektdeltager effektivt på projektet. Det tager tid at læse post, deltage i afdelingsmøder, holde personalesamtale, læse fagtidsskrifter etc. Effektive arbejdstimer = Arbejstimer * 70-80% Rådighedsfaktoren: Hvor stor en del af deres tid, de er til rådighed for projektet.

15 Vi får nu tildelt 3 personer Alle mand fuld tid = 25 effektive timer HANSEN er god til hardware => A og C JENSEN er god til software => B, D og H NIELSEN er brugerspecialist => F og G Alle kan lave E (men ingen har lyst)

16 Samme netværk med personer Hansen Hansen A 150 C 75 art 0 Jensen Uge 6 Uge 7 Jensen Uge 9 H 50 B Uge 4 D Uge Uge 8 Slut Nielsen F 250??? E 75 G 75 0 Uge 10

17 Vi fordeler E til Hansen og Jensen, og bliver færdig i uge 13 Hansen Hansen art A 0 Jensen B Uge Uge 4 C Uge 7 Jensen D Uge 5 75 Uge Uge 8 Jensen H Uge Uge 12 Slut Nielsen F Uge 10 Jensen E Hansen U Uge 10 Nielsen G Uge Uge 13

18 PERT Expected times and standard deviation 0,08 2,08 2,50 2,00 2,00 H 0,33 3,00 4,00 3,00 2,00 G 1,17 10,50 15,00 10,00 8,00 F 0,50 2,83 4,00 3,00 1,00 E 0,25 4,08 5,00 4,00 3,50 D 0,17 2,83 3,00 3,00 2,00 C 0,33 4,00 5,00 4,00 3,00 B 0,50 6,17 8,00 6,00 5,00 A S.afvi. Forventet Pessimistisk Realistisk Optimistisk Aktivitet

19 PERT network Event Number Expected date Target date Standard deviation A t=6.17 s=0.5 B t=4.0 s= F t=10.5 s=1.17 C t=2.83 s=0.17 D H 3 t= t= s= s= E t=2.83 s= G t=3.00 s=0.33

20 Ressourcer Labour Equipment Materials Space Services Time Money

21 Projektværktøj ID Task Name Duratio 1 Analyse 130d 2 Analyseaktiviteter Usikkerhed analysefa 30d 4 Udvikling 325d 5 Udviklingsaktiviteter Usikkerhed udviklings Indførelse 90d 8 Indførelsesaktiviteter 50d 9 Usikkerhed indførelse 40d 10 Drift 300d Qtr 4 Qtr 1 Qtr 2 Qtr 3 Qtr 4 Qtr 1 Qtr 2 Qtr 3 Qtr 4 Qtr 1

22 Planlægningshorisonter - tre niveauer af planer Hovedplan Detailplan Individuel plan Hovedplan (overordnet projektplan) som dækker hele projektet. Detailplan som dækker en eller flere faser i projektet detaljeret (horisont 3-6 måneder). Plan for den enkelte medarbejder (typisk horisont 4-8 uger).

23 Planlægningsteknikker Milepæle Gantt Vægplan CPM PERT Milepæle er godt til meget simple projekter med f.eks. 10 aktiviteter eller 2 personer Et Gantt-diagram svarer til et stavdiagram. Kan vise overlap men ikke sammenhæng Vægplan laves af alle i projektet samlet i et rum. Giver godt overblik Critical Path Method tager højde for sammenhænge og afhængigheder Programme Evaluation Review Technique kan bruges til at regne på usikkerhed

24 Estimering (Hvorfor) er estimering en vigtig aktivitet i softwareudviklingsprojekter?

25 Målet for projektlederen er, at projektet gennemføres indenfor den afsatte tid, overholder budgettet og opnår den aftalte funktionalitet og kvalitet. Aktiviteter for projektlederen: Forudsige budget, planlægge og organisere gennemførelsen Kontrollere og tilpasse Sikre kvalitet og produktivitet i det arbejde der udføres

26 Et estimat er ikke: Den mest optimistiske forudsigelse der har en sandsynlighed forskellig fra nul Lig med det sidste estimat vi lavede Lig med sidste estimat + den forsinkelse kunden eller chefen er villig til at acceptere Lig med et udefra givent rigtigt svar

27 Sørg for at adskille estimering og planlægning Estimering TIMER eller KR Hvor mange timer skal bruges for at udføre projektet (opgaven)? eller Hvor mange kroner kommer det til at koste Projektplanlægning TID Hvornår kan projektet være afsluttet?

28 Hvad er et estimat (1 af 2)? Et udbredt syn på et estimat!!! Sandsynlighed for estimat Der er 100% sandsynlighed for at gennemføre projektet med det planlagte antal timer Timer

29 Hvad er et estimat (2 af 2)? Et estimat er en stokastisk variabel, hvilket betyder: Tilfældig, men til at forudberegne statistisk med tilnærmelsesvis sikkerhed. Sandsynlighed for estimat Timer Erfaring har vist, at sandsynligheden kan udtrykkes som en matematisk fordeling (Beta)

30 Fordelingsfunktion Mest sandsynlig værdi Vs Middelværdi Vm (forventningsværdi) rdi) Optimistisk værdi Vo Timer Pessimistisk værdi Vp

31 Estimeringsteknikker Der findes to typer teknikker til estimering: Erfaringsbaserede, som f.eks. tre-punktsteknikken, brug af analogier og eksperter, anvendelse af historiske data, samt successiv kalkulation og DELFIteknikken Parametriske (modelbaserede), som f.eks. COCOMO, Function Points og Use Case Points.

32 Tre-punkts teknikken Til at beregne middelværdien Vm kan vi bruge: Vm = (Vo + 3*Vs + Vp) / 5 Til at beregne standardafvigelsen S kan vi bruge: S = (Vp - Vo) / 5 Usikkerheden kan beregnes således at: 68% er omfattet. Formel: (Vm - S) til (Vm + S) 95% er omfattet. Formel: (Vm - 2S) til (Vm + 2S) 99% er omfattet. Formel: (Vm - 3S) til (Vm + 3S)

33 Vo = mest optimistiske skøn (mindsteværdi) Vs = mest sandsynlige værdi Vp = mest pessimistiske værdi (størsteværdi) Vm = middelværdi

34 Successiv kalkulation For en Erlang funktion med en k-værdi på 10 (hvor k er et udtryk for forelingsfunktionens skævhed) beregnes middelværdien som: Vm = (Vo + 2,95*Vs + Vp) / 4,95 Og standardafvigelsen S som: S 2 = (Vp - Vo) 2 / 21,66 K = 10 er valgt fordi den må anses for at være mest repræsentativ. For andre k-værdier er ovennævnte udtryk for middelværdien behæftet med en fejl, der dog for de mere hyppigt forekommende k-værdier (K = 5 til 15) kun når op til få promille. Citat: Steen Lichtenberg (1971, side 20)

35 Fortsæt nedbrydningen indtil... Tommelfingerregel fra Lichtenberg (1971:side 14): Den eller de poster der har den største varians opdeles i et antal delposter Således fortsættes indtil man enten har nået en tilfredsstillende nøjagtighed eller møder usikkerheder, der ikke kan nedbringes ved opdeling eller på anden vis.

36 Intuitive ekspertmetoder En erfaren ekspert vurderer hvad det vil koste Flere eksperter vurderer samme projekt uafhængigt af hinanden DELFI-teknikken er et eksempel på struktureret brug af flere eksperter Ekspertmetoder kan udbygges med en nedbrydning af projektet i delopgaver (WBS)

37 Analogi Find historisk projekt der ligner Analyser historisk projekt - Hvad var bestemmende for omkostningerne? Find tilsvarende faktorer i dette projekt og fastlæg dem ud fra størrelsen i det historiske projekt Find andet historisk projekt eller brug anden teknik til omkostningsfaktorer der adskiller sig meget Forklar hvori forskellene består i et internt arbejdspapir, således at dokumentationen foreligger

38 Delfi-teknikken Hvert medlem af en gruppe giver et estimat De der ligger i nederste og øverste fjerdedel fortæller resten af gruppen hvorfor deres estimat blev som det blev Gruppen estimerer igen, nu under hensyntagen til de argumenter man lige har hørt Kan fortsættes 2, 3, 4 eller flere gange efter behov Anvend eventuelt Silent Delphi og en mægler

39 Brug historiske data Eksempel 1: Vores database viser, at aktiviteter af denne type tager X timer. Eksempel 2: Vi ved at vi kan lave et X linier kode på 1 mandtime. Når et nyt program er 3000X = 3000 mandtimer, så tager det ca. 2 mandår. Eksempel 3: Fremragende, effektive og nominelle erfaringsdata for system software (drivere, compilere), in-house adm. systemer og standard-produkter fx. Tekstbehandling

40 Oppefra-ned og nedefra-op Oppefra-ned. Først estimeres helheden - systemet set som en sort kasse - siden brydes ned vha. procenttal baseret på erfaring. Teknikken kan f.eks. bruges til et første overslag meget tidligt. Nedefra-op. Selve programmet nedbrydes i detaljer - f.eks. i delsystemer og moduler. Hver enkelt lille del estimeres i timer. Summen af timer ganges op til en sum for helheden vha. procenttal baseret på erfaring. Nedefra-op alternativ. Hver enkelt lille del estimeres i antal linier. Summen af linier bruges som input til at inddrage historiske data eller til en estimeringsmodel.

41 Parametrisk estimering Omkostningernes størrelse er en funktion af en række omkostningsbestemmende faktorer Formlerne kan udtrykke additive sammenhænge, multiplikative sammenhænge, eksponentielle sammenhænge etc. Samlede omkostninger = X * f1 * f2 fn

42 COCOMO-modellen Organisk udvikling Relativ lille gruppe udvikler software af en velkendt type til in-house brug. Hovedparten af gruppen har erfaring med tilsvarende systemer i organisationen. PM = 2,4 (KDSI) 1,05 MU = 2,5 (PM) 0,38 PM = PersonMåneder KDSI = Tusind linier kildetekst MU = Måneder til udvikling

43 COCOMO Embedded Embedded (Indlejret) udvikling Projektet kan omfatte ny teknologi, algoritmer vi ikke kender godt, eller en ny innovativ udviklingsmetode. mest karakteristisk er, at projektet er underlagt mange bindinger ( tight constraints ) PM = 3,6 (KDSI) 1,20 MU = 2,5 (PM) 0,32

44 COCOMO Semi-detached Semi-detached udvikling Mellemting mellem organisk og embedded PM = 3,0 (KDSI) 1,12 MU = 2,5 (PM) 0,35 Eksempel med linier kode (10 KDSI): PM = 3,0 (10) 1,12 = 40 personmåneder MU = 2,5 (40) 0,35 = 9,1 måneder til udvikling Gennemsnitlig bemanding 40 / 9,1 = 4,4 mand

45 Udvidet COCOMO PM = 3,0 (KDSI) 1,12 * f1 * f2 * f3 f14 * f15 SOFTWARE FAKTORER f1 = Pålidelighed krævet af systemet (RELY) f2 = Størrelsen af databasen (DATA) f3 = Kompleksitet af systemet (CPLX) COMPUTER FAKTORER f4 = Krav til hastighed i drift (TIME) f5 = Krav til hovedlager ( Main storage ) i drift (STOR) f6 = Hyppighed af ændringer i teknisk platform (VIRT) f7 = Ventetid ved testkørsler på at få resultater (TURN)

46 Udvidet COCOMO PERSONLIGE FAKTORER f8 = Analytikernes kapabilitet / evne (ACAP) f9 = Udviklernes erfaring i applikationsdomæne (AEXP) f10 = Programmørernes kapabilitet / evne (PCAP) f11 = Udviklernes erfaring med teknisk platform (VEXP) f12 = Programmørernes erfaring med prog.sprog (LEXP) PROJEKT FAKTORER f13 = Graden af anvendelse af moderne programmering (MODP f14 = Brug af programmeringsværktøjer (TOOL) f15 = Krav til tidsplan / leveringstidspunkt (SCED)

47 COCOMO 2.0 (1995) II NYE FAKTORER i COCOMO 2.0 n1 = Dokumentationskrav n2 = Grad af krævet genbrug n3 = Udviklerkontinuitet n4 = Udvikling spredt på flere lokationer n5 = Organisationens erfaring med projekttype n6 = Kravenes fleksibilitet n7 = Opgavens velafklarethed n8 = Team Spirit n9 = Den faglige modenhed i udviklingsorganisation

48 Function Point Function Point er er et et udtryk for, hvor megen funktionalitet et et system stiller til til rådighed for brugerne. Lidt populært sagt er Function Point IT-branchens kilobegreb Hvor stort og tungt er det her system?

49 Fem ting skal tælles External user External Input External Output External Inquiry Internal Logical File External Interface File External Input External Output Application Boundary Other Applications

50 Eksempel: Function Point beregner Et skærmbillede med eksterne inddata (EI). Et skærm-billede med eksterne uddata (som vist). Mulighed for at udskrive en rapport af skærmbillede = 2 eksterne uddata

51 Eksempel på tælling af Function Points Parameter Antal Vægt Total EI - Eksterne inddata 1 x 4 = 4 EO - Eksterne uddata 2 x 5 = 10 EQ - Eksterne forespørgsler 0 x 4 = 0 ILF - Interne logiske filer 1 x 10 = 10 ELF - Eksterne græseflader 0 x 7 = 0 Ikke-justeret sum 24 Justeringsmultiplikator 0,75 Justeret sum 18

52 Function Point justering Justering kan ske efter flere modeller fra +/- 25% til meget avancerede modeller der går op til +/- 125% I eksemplet bruges IBM s 1984 metode der frem til 1995 svarede til IFPUG s fremgangsmåde Justeringsmultiplikator = (SUM*0,01) + 0,65 = (10*0,01) + 0,65 = 0,75 24 ikke-justerede FP * 0,75 Justerede Function Points Data Comunications 0 Distributed functions 0 Heavily used configuration 0 Transaction rate 0 On-line data entry 2 End-user efficiency 3 On-line update 2 Complex processing 0 Installation ease 0 Operational ease 3 Multiple sites 0 Facilitated change 0 TOTAL INFLUENCE SUM 10

53 Function Point Hvad kan de bruges til? Ændringsstyring (optælling af FP før, under og efter udvikling af system). Nøgletal for produktivitet eller kvalitet (antal fejl pr. FP). Beregning af størrelsesorden på standardsystem. En række danske virksomheder gør disse tre ting Estimering af Projektomkostninger (timer m.m.) og kalendertid (ud fra produktivitetstal). Meget få er nået så langt!

54 Generelle problemer med estimeringsmodeller Mange undersøgelser viser, at de giver meget upålidelige resultater afvigelser mellem 30 og 700% (Prodromos 1996) De input variable der indgår i modellerne er altid afhængige af subjektive skøn. Estimering sker før kravspecifikationen er kendt.

55 Estimering i praksis Gør dig typen af projekt klar. Der er forskel på et overslag, en fastpriskontrakt og et standardprodukt Planlæg estimeringsopgaven som en selvstændig aktivitet Gør det klart hvad produktet skal kunne Nedbryd opgaven i de aktiviteter der indgår i at lave produktet. Fortsæt nedbrydning til du har viden nok. Brug mere end én af metoderne til estimering, og lad (mindst) to uafhængige grupper estimere Husk opfølgning, sammenligning og re-estimering undervejs (især i større og længerevarende projekter)

56 Husk at fastholde forudsætninger Beskriv forudsætningerne for estimatet parallelt med at estimeringen foretages Forudsætningerne er utrolige vigtige og bør behandles på styregruppemøder samt fremgå klart af referater mv.

57 Estimatets poster: Hvad skal med? Ressourcer f.eks. materialer, arbejdsløn og materiel Projektledelse, dvs. omkostninger knyttet til projektet som helhed Overheads, dvs. mere overordnet ledelse, indirekte i forhold til projekt Forsikringer og afgifter, især ved anlægsprojekter, eller gebyrer ved finansiering, eller licenser Reguleringsposter f.eks. inflation og Contingencies

58 Contingency - Budgetreserve Skal dække forventede omkostninger, hvor det ikke på estimeringstidspunktet er muligt at fastlægge hvor og hvornår, eller hvor store. Der afsættes derfor ét samlet beløb til dækning af disse særlige forhold Contingency kaldes også budgetreserve, diverse, eller uforudsete omkostninger Contingency kan fastsættes som en procent af de øvrige poster. Procenten varierer med branche og projekttype Svarer til usikkerhed ved successiv kalkulation

59 Lad dig ikke presse af politiske forhold Lad dig ikke presse af politiske forhold - Ingen vinder ved det i længden. Estimering er ikke politisk - men det er derimod projektets slutdato ofte. Hvis hverken ressourcemængde eller kalendertid hænger sammen, så må ledelsen eller styregruppen skære ned i projektets omfang (husk dokumentation!).

60 Risikostyring Planlægning Identifikation Risikoanalyse Imødegåelse

61 Risikostyring Definition: En risiko for et projekt er et potentielt problem for projektet. Hvis problemet faktisk opstår, så kan det i værste fald ødelægge projektet. I ethvert projekt bør man tage sig tid til at identificere projekt-risici, tage stilling til hver risikos sandsynlighed og konsekvens, samt gennemføre relevante forebyggende og afhjælpende foranstaltninger.

62 Styring af projektets risici Risikostyring handler om at identificere, analysere og imødegå potentielle problemer i projektet Der indgår 6 processer i styringen af risici: 1. Planlægning 2. Risikoidentificering 3. Kvalitativ risikoanalyse 4. Kvantitativ risikoanalyse 5. Planlægning af risikohåndtering 6. Opfølgning på risici

63 1. Planlægning af risikostyring Lige som alt andet i et projekt er det en god idé at planlægge hvad man vil gøre lave en risikostyringsplan Hvem skal med? Projektgruppen? Styregruppen? Autoriserede sortseere! Er dine interessenter og din styregruppe tolerante over for risici? Nogle organisationer har faste rutiner for risikostyring Eksempel: Scandinavian IT Group har en skabelon hvori risici indgår der skal udfyldes til hvert styregruppemøde Husk ikke at tælle det samme to gange. Sørg for at skelne mellem risiko og usikkerhed

64 Forskellen på risiko og usikkerhed Risiko er knyttet til ydre betingelser og systemers virkemåde. Ting, der indgår som forudsætninger for estimater og projektplan. Usikkerhed er knyttet til handlinger, aktiviteter og planer, rettet mod at opnå resultater, og i sidste ende mod at producere et produkt.

65 2. Risikoidentifikation Der er to forskellige måder at finde risici i et projekt. Den ene er at tage en checkliste af risici som andre har lavet og spørge: Kunne dette gå galt i mit projekt? Den anden er at samle en gruppe og lave en brainstorm om hvad der kan gå galt i projektet?

66 Eksempel på checkliste 1 Der kryber nye krav ind hele tiden ( Feature Creep ) Forgyldning ( Gold plating ) Mangelfuld kvalitetssikring Optimistiske planer Utilstrækkelig design Silver-bullet syndromet Forskningspræget udvikling Problemer med projektdeltagere Underleverandør fejl/mangler Friktion mellem udviklere og kunder Det er bedre at forebygge end at helbrede! Kilde: McConnell, Steve (1996). Rapid Development. Microsoft Press. Side 86.

67 Eksempel på checkliste 2 Lack of top management commitment to the project Failure to gain user commitment Misunderstanding the requirements Lack of adequate user involvement Failure to manage end user expectations Changing scope / objectives Lack of required knowledge / skills in the project personnel Lack of frozen requirements Introduction of new technology Insufficient / inappropriate staffing Conflict between user departments Kilde: Keil et al. (1998). A Framework for Identifying software project risks. CACM, Vol. 41, No. 11, page 76-83

68 Eksempel på checkliste 3 Underbygger IT-projektet den offentlige myndigheds samlede strategi og målsætning? Har lederne og medarbejderne erfaring med at gennemføre IT-projekter? Har medarbejderne den nødvendige kompetence og kendskab til den valgte teknologi? Er tilpasninger af organisation og arbejdsgange gennemtænkt i forhold til det nye IT-projekt? Er forholdet mellem omkostninger og fordele ved gennemførslen af IT-projektet opgjort? Kilde: Finansministeriets checkliste til vejledning i risikostyring. Fundet den 31. juli 2003 på

69 Brainstorm til risikoidentifikation 1 Traditionel Brainstorm Formulér emne for Brainstorm: Hvad kan gå galt i dette projekt? Mindst tre personer. 6-8 personer virker bedst. Gør det klart for deltagerne at utraditionel tænkning, uden for de vante rammer, er ønskeligt. Gør det også klart, at idéer ikke skal forklares, forsvares eller defineres præcist. Jo flere ideer jo bedre. Ingen må kritisere andres ideer. Alle ideer nedskrives f.eks. på tavle eller flip-over. Skriv ideerne med samme ord som de blev formuleret (ingen bearbejdning). Stop når der går mere end 5 sekunder mellem nye ideer (Popcorns-reglen). Hele Brainstormen tager ofte kun minutter.

70 Risiko Identifikation HVAD KAN GÅ GALT? - Opmærksomhedsområder: Projektstørrelse, afgrænsning og karakter Projekt metoden Projektdeltagernes erfaring, kunnen, tilfredshed og personaleomsætningshastighed Estimerings- og planlægningskvalitet Hardware og software faktorer Underleverandører Selve den organisatoriske implementering Driftsforhold

71 Brainstorm til risikoidentifikation 2 Brainstorm med gule sedler Formulér tema: Hvad kan gå galt i dette projekt? Grupper af 3-8 personer placeret rundt om et bord eller ved en hvid tavle. Rundt-om-bordet Brainstorm. Først individuel, så gruppe. Idéer fra Brainstorm skrives på gule sedler (postit) og lægges frem på bordet.

72 Brainstorm til risikoidentifikation 3 Gruppering af de gule sedler En og en må man flytte to gule sedler sammen pga. slægtskab, eller fra hinanden, fordi man er uenig i et slægtskab. Efter et stykke tid opstår et antal stabile grupper. Navngiv grupper af risici med en fælles overskrift. Eliminér dobbeltgængere og skriv de fundne risici-grupper ned på f.eks. en flip-over.

73 3. Kvalitativ risikoanalyse Vurdér hvad sandsynligheden er for at en risiko indtræffer Vurder hvad konsekvensen er (i kroner & øre, forskydning i tidsplanen, produktets omfang og indhold, kvalitet) hvis den pågældende risiko indtræffer Prioriter din indsats ud fra både sandsynlighed og konsekvens Risikofaktor Sandsynlighed Konsekvens S * K Prioritet Alfa Bravo Charlie

74 Eksempel på pointskala til vurdering af sandsynlighed Point Sandsynlighed 0 Ignorerbar ½% eller mindre 1 Meget lille 0 20% 2 Lille 20% - 40% 3 Middel 40% - 60% 4 Stor 60% 80% 5 Meget stor 80% - 100%

75 Eksempel på pointskala til vurdering af konsekvens Point Konsekvens 0 Ignorerbar 1 Ubetydelig 2 Mindre alvorlig 3 Alvorlig 4 Voldsom 5 Katastrofal Projektstop!

76 Eksempel på matrix hvor sandsynligheden på en skala fra 1-5 ganges med konsekvensen Risikofaktor Sandsynlighed Konsekvens S * K Prioritet Alfa Bravo Charlie

77 4. Kvantitativ risikoanalyse Vi har nu en prioriteret liste af risici. Dem ser vi nærmere på: 1. Interviews kan bruges til at få detaljeret viden 2. Lige som ved estimering kan vi bede om tre tal for sandsynligheden og derved fastlægge en risikofordeling 3. Sandsynligheden for at en risiko forekommer kan være afhængig af en anden risiko eller beslutning. Eksempel: Hvis vi vælger prototyping så medfører det en risiko for at kravene ændrer sig meget 4. Afhængigheder af denne type kan afbildes i et beslutningstræ

78 5. Planlægning af risikohåndtering IDENTIFICEREDE RISICI AFHJÆLPENDE FOREBYGGENDE FORANSTALTNINGER FORANSTALTNINGER Hvad gør vi, når Hvad kan vi gøre nu for at skaden er sket? forebygge eller fjerne? NØD- PLAN Estimeres og indgår i projektplan

79 Eksempel på p risikohåndtering 1 Risiko: Der kryber nye krav ind hele tiden Undgå for mange ændringsønsker ved at : Anvende prototyping Anvend formel ændringsstyring Anvende bruger/situationsspecifikke beskrivelsesteknikker (use-case/scenarie beskrivelser) Involvere slutbrugere i udviklingsprocessen Designe en forandringsvenlig arkitektur (system, teknik, infrastruktur)

80 Eksempel på p risikohåndtering 2 Risiko: Forgyldning Gold plating Kvalitet på et aftalt grundlag opnås ved : Indsigt i projektets formål og idegrundlag Forventningsafstemning med interessenter før, under og efter Operationelle mål Forhåndsprioritering og timeboxing Leveranceopdelt projektforløb Kvalitetssikre udviklerestimater Sikre commitment til estimater

81 Eksempel på p risikohåndtering 3 Risiko: Mangelfuld kvalitetssikring Undgå mangelfuld kvalitetssikring ved at : Sikre at de rigtige involveres Sikre klare aftaler om indsatstidspunkt/omfang Udarbejde kvalitetssikringsplan Tage styregruppe/bidragsydere i ed Undgå bortprioritering af væsentlige kvalitetssikringsaktiviteter

82 Eksempel på p risikohåndtering 4 Risiko: Optimistiske planer Undgå optimistiske planer ved at : Sikre at de rigtige involveres i estimeringen Sikre at der planlægges med usikkerhed Anvende flere estimeringsmetoder Lad flere kompetente estimere Gruppeestimering Afsætte tilstrækkelig tid Tage hensyn til interne og eksterne afhængigheder Sige nej til politiske diktater

83 Eksempel på p risikohåndtering 5 Risiko: Utilstrækkeligt design Undgå utilstrækkeligt design ved at : Sikre at de rigtige involveres Afsætte tid nok til design Gennemføre tekniske designinspektioner/reviews Afprøve fremtidige forretningsvisioner/behov på design

84 Eksempel på p risikohåndtering 6 Risiko: Silver Bullet syndrom Undgå overdreven tillid til nye metoder/værktøjer ved at : Indregne usikkerhed ved nye metoder/værktøjer i estimat Måling tidligt i forløbet Separat/parallelt værktøjs-/metodeprojekt Referenceinstallationer

85 Eksempel på p risikohåndtering 7 Risiko: Forskningspræget udvikling Undgå forskningspræget udvikling ved at : Vælge afprøvede teknikker og metoder Stop aktiviteter med uforudsigeligt aktivitetsomfang

86 Eksempel på p risikohåndtering 8 Risiko: Problemer med projektdeltagere Undgå problemer med projektdeltagere ved at : Afdække kompetencekrav før rekruttering Anmode og kæmpe for de bedste Afstemme forventninger Teambuilding Coaching Feedback Lukke kompetencegab Kick-off seminar, workshop arbejde Følge op på performance Følge op på kvalitet

87 Eksempel på p risikohåndtering 9 Risiko: Underleverandør fejl/mangler Undgå problemer med underleverandører ved at : Vælge branchekyndige leverandører Checke referencer Checke underleverandørers ressourcesituation Aktiv styring af underleverandør og leverancer

88 Eksempel på p risikohåndtering 10 Risiko: Friktion mellem udviklere og kunder Vælg en projektmodel som passer til opgaven Identificer den rigtige kunde Sikring af repræsentative kundeansvarlige Sørg for intensiv brugerinvolvens under kravspecifikationsarbejdet Sørg for effektiv kommunikation Skab realisme i forventninger

89 6. Opfølgning på p risici Faste intervaller for gentagelse af risiko identifikation (f.eks. ved milepæle, faseafslutning, eller til styregruppemøder) Inddrag ledelsen og styregruppen (f.eks. til prioritering, kursændring etc.) LYT TIL PROJEKTGRUPPEN!!!

90 Valg af projektmodel Lene Pries-Heje IT-projektledelse F2006

91 Projekt-karakteristika Data- eller procesorienteret system informationssystem eller embedded software? Er softwaren et generelt produkt eller en specialudviklet applikation? Findes der specielle udviklingsværktøjer/- miljøer til denne form for applikation? Hvilket sikkerhedsniveau har applikationen? Hvilket hardware og software miljø skal henholdsvis udvikling og drift se i?

92 Kundens krav til implementering Projektet kan være underlagt strategiske valg, som f.eks. gælder for en hel koncern. Der kan være krav til kvalitetssikring, f.eks. brug af ISO standarder eller CMM.

93 Situation - overvejelser Kontrol System embedded system Information Systems Generelt software produkt Specielle teknikker. F.eks. Ekspertsystemer, grafiskesystemer. Hardware environment Sikkerhedskritiske Upræcis specifikation F.eks. Petri nets F.eks. SSADM eller Information Engineering. Tilpasning af SSADM Specielt udviklede metoder og værktøjer Svartid -> lav-niveau sprog Formelt specifikationssprog Parallelle udviklingsteam Soft system approach, prototyping eller incremental delivery.

94 Risiko (usikkerhed) Produktusikkerhed resultat af usikkerhed hos brugerne eller omgivelserne. Procesusikkerhed ingen eller begrænset erfaring med teknologi, værktøjer eller metode. Ressourceusikkerhed vil de rigtige ressourcer være til rådighed på det rigtige tidspunkt?

95 The Waterfall Model Feasibility Study User Requirements Analysis System Design Program Design Coding Testing Kilde Huges First description H.D. Bennington 1956, Production af Large Computer Programs Operation

96 The V-process model Feasibility Study Corrections Review User Requirements Corrections User Acceptance System Design Corrections System Testing Program Design Corrections Program Testing Kilde: Hughes 2002 Code

97 opieret fra: Steve McConnell (1996). Rapid evelopment. Microsoft Press. Side 142. Stammer prindeligt fra Barry Boehm (1988). A spiral model of oftware development and enhancement. Computer,

98 Typer af prototyping Blivende vs. Smid-væk Vertikal vs. Horisontal Problem-afklarende vs. Løsningsimplementerende Lille nøjagtighed & lighed vs. stor nøjagtighed & lighed

99 Tre eksempler på prototyper Papir mockup omfattende færdige skærmbilleder, dialogbokse, menuer etc. på almindeligt papir. Skærm Mockup der ser ud som det færdige system, men har meget lidt funktionalitet. Funktionel prototype er som Screen Mockup med en del funktionalitet implementeret.

100 Incremental Delivery Applikationen opdeles i små dele, som implementeres og leveres sekventielt. Time Boxing forbindes ofte med incremental delivery.

101 Incremental Delivery Fordele Hurtig feedback fra tidligere sekvenser Kort tid mellem specifikation og implementering => færre ændringer i krav. Cashflow forbedres p.g.a. hurtig impl. Små projekter er lettere at styre end store Nice to have funktionalitet reduceres Projekter kan midlertidig sættes på hold Større fleksibilitet

102 Incremental Delivery Ulemper Allerede leveret kode må ændres for at tilpasses senere udviklet kode. Programmører kan være mere produktive på et større projekt end på en serie af små. Der kan være mindre fokus på scalability, extensibility, portability og reusability, samt manglende fælles infrastructure (Grady Booch 1996).

103 De tidlige idéer bag Agile udvikling Systemer udvikles bedst i korte værdiskabende iterationer. Bruger og systemudvikler skal arbejde hånd i hånd. Hver iteration skal designes til at indeholde et minimum af krav. Når der opstår behov for en ændring, skal den designes ind i løsningen frem for tilføjes. Dokumentationen skal være minimal bortset fra det som koden i sig selv giver.

104 Eksempler på Agile metoder Lean Development Adaptive Software Development A Change-Oriented Life Cycle Featuredriven Development extreme Programming Crystal Methodes Dynamic Systems Development Method

105 Manifesto for Agile Software Development Top level: We are uncovering better ways of developing software by doing it and helping others do it. 2nd level: Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan. That is, while there is value in the items on the right, we value the items on the left more.

106 Principles behind the Agile Manifesto (3rd level) - I 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

107 Principles Agile Manifesto - II 6. The most efficient and effective method of conveying information to and within a development team is face-toface conversation. 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity--the art of maximizing the amount of work not done--is essential. 11. The best architectures, requirements, and designs emerge from self-organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

108 Planspektrum Get Ready for Agile Methodes, With Care Barry Boehm, IEEE 2002

109 Sammenligning af metoder (I) Developers Agile Plan-dreven Der lægges vægt på menneskelige faktorer som medmenneskelighed, talent, færdigheder og kommunikation. Får sin adræthed fra en antagelse om, at tilstrækkelig viden er indarbejdet i teamet. Get Ready for Agile Methodes, With Care Barry Boehm, IEEE 2002 Risiko for at træffe beslutninger på ufuldstændigt grundlag imødegås ved at investere i livscyklus arkitektur og planer. Resultaterne kan reviewes af eksterne eksperter Mange forandringer det er dyrt at opdatere planer

110 Sammenligning af metoder (II) Customers Agile Kunderepræsentanterne skal vær committed, vidende, samarbejdsvillige, repræsentative og empowered. Kunderepræsentanternes viden skal være dækkende for hele applikationen Plan-dreven Risikoen for at træffe beslutninger på ufuldstændigt grundlag imødegås ved at dokumentere beslutningsgrundlager og beslutningerne, således at der kan foretages review. Get Ready for Agile Methodes, With Care Barry Boehm, IEEE 2002

111 Sammenligning af metoder (III) Requirements Agile Antager at verden er foranderlig og har derfor indbygget en forventning om ændringer af krav. Krav kan ikke specificeres på forhånd, men udvikler sig over tid. Selv om der naturligvis er potentiale for succes ved villighed og evne til forandring, så er der en risiko for, at det kan give katastrofale konsekvenser at foretage mange ændringer. Plan-dreven Traditionelle metoder lægger vægt på: Fuldstændige krav Konsistente krav Testbare krav Sporbare krav Traditionelle metoder virker bedst, når krav forbliver forholdsvis stabile, med en ændrings radio på under 1% pr. måned. Get Ready for Agile Methodes, With Care Barry Boehm, IEEE 2002

112 Sammenligning af metoder (IV) Architecture Agile Plan-dreven Sætter værdien af koden der virker højre end dokumentation, og lægger vægt på enkelthed. Har som princip at maximere det arbejde, som ikke udføres. Det at arbejde uden arkitektur planlægning kan give større arbejdsbyrde totalt set over hele projektforløbet i forhold til det at indarbejde forventede fremtidige krav i arkitekturen. De traditionelle metoder lægger stor vægt på dokumentation af arkitektur og design. Det giver imidlertid en stor arbejdsbyrde ved mange forandringer. Der er eksempler på, at det traditionelle udviklingsmetoder der tager højde for forventede ændringer i krav kan gennemføre udviklingsprojekter med millioner af linier kode indenfor budget og tid. Get Ready for Agile Methodes, With Care Barry Boehm, IEEE 2002

113 Sammenligning af metoder (V) Refactoring Agile Plan-dreven Agile metoder bygger på en idé om at genopløse kode/design når ændringer skal indarbejdes. Med dygtige udviklere og små systemer, er genopløsning ikke et problem. I praksis viser det sig imidlertid, at hvis man ikke har dygtige udviklere, så vil omk. til genopløsning stige i takt med antallet af krav eller historier stiger. Get Ready for Agile Methodes, With Care Barry Boehm, IEEE 2002

114 Sammenligning af metoder (VI) Size Agile Plan-dreven Agile udvikling bliver vanskelig med mere end udviklere Plan-drevne metoder kan skaleres til meget store projekter. For meget små projekter er der store start omkostninger i forhold til nytteværdien. Get Ready for Agile Methodes, With Care Barry Boehm, IEEE 2002

115 Sammenligning af metoder (VII) Primary Objective Agile Our highest priority is to satisfy the customer through early and continuous delivery of valuable software Nogle Agile metoder eksperimenterer med koncepter, som minder om software arkitektur skeletter. Plan-dreven At gennemføre projektet indenfor aftalt tid, ressourcer og kvalitet ved hjælp af planlægning og dokumentation. Get Ready for Agile Methodes, With Care Barry Boehm, IEEE 2002

116 Hughes tommelfinger regler: IF uncertainty is high THEN use evolutionary approach IF complexity is high but uncertainty is not THEN use incremental approach IF uncertainty and complexity both low THEN use one-shot IF schedule is tight THEN use evolutionary or incremental