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

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

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.

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

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

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

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?

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

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

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

Vi regner forlæns A 150 C 75 art 0 B 0 150 100 100 150 D 100 225 100 200 H 225 50 275 Slut F 0 250 250 E 100 75 175 G 250 75 325

Og baglæns startende med 325 275 225 50 H 325 275 100 0 100 B 175 75 250 0 250 F 250 0 225 150 75 C 275 200 200 100 100 D 275 175 175 100 75 E 250 175 150 0 150 A 200 50 325 250 75 G 325 250 art Slut

Kritisk vej Aktiviteter der hvis de forsinkes, forsinker det hele 50 200 200 275 art A 0 75 B 0 0 F 0 150 150 175 100 100 250 250 250 C 150 175 D 100 175 E 100 75 225 275 100 200 250 75 175 275 H 225 250 G 250 325 50 275 325 75 325 Slut

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).

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.

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)

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

Vi fordeler E til Hansen og Jensen, og bliver færdig i uge 13 Hansen Hansen art A 0 Jensen B 0 150 Uge 6 100 Uge 4 C Uge 7 Jensen D Uge 5 75 Uge 9 100 Uge 8 Jensen H Uge 11 50 Uge 12 Slut Nielsen F 0 250 Uge 10 Jensen E Hansen U. 9-10 75 Uge 10 Nielsen G Uge 11 75 Uge 13

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

PERT network Event Number Expected date Target date Standard deviation 1 0 0 A t=6.17 s=0.5 B t=4.0 s=0.33 2 6.17 0.50 F t=10.5 s=1.17 C t=2.83 s=0.17 D H 3 t=4.08 4 10 t=2.08 6 15 s=0.25 4 0.33 9 0.53 s=0.08 13.5 1.22 E t=2.83 s=0.5 5 10 10.5 1.17 G t=3.00 s=0.33

Ressourcer Labour Equipment Materials Space Services Time Money

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

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).

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

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

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

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

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?

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

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)

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

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.

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)

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

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)

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.

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)

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

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

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

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.

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

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

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

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 10.000 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

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)

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)

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

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?

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

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

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

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

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!

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.

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)

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.

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

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

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!).

Risikostyring Planlægning Identifikation Risikoanalyse Imødegåelse

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.

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

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

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.

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?

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.

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

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å http://e.gov.dk/sitemod/design/layouts/default/index.asp?pid=2930

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 10-15 minutter.

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

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.

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.

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 2 5 10 1 Bravo 4 2 8 3 Charlie 3 3 9 2

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%

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

Eksempel på matrix hvor sandsynligheden på en skala fra 1-5 ganges med konsekvensen Risikofaktor Sandsynlighed Konsekvens S * K Prioritet Alfa 2 5 10 1 Bravo 4 2 8 3 Charlie 3 3 9 2

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æ

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

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)

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

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

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

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

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

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

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

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

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

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!!!

Valg af projektmodel Lene Pries-Heje IT-projektledelse F2006

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?

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.

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.

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?

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

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