Notater til Projektetablering. Vidar Jon Bauge 2005

Notater til Projektetablering Vidar Jon Bauge 2005 Datamatikeruddannelsen forår/efterår 2005 Side 1 av 28

Indholdsfortegnelse Projektdefinition......2 Planlægning......4 Estimering......11 Projekt, struktur og organisering......13 Kontrol og rapportering......16 Dokumentstyring og kontrol......18 Risiko styring......20 Team building, samarbejde og kommunikation......22 Kvalitetsikring......25 Projektkontoret......26 Kommunikation......27 Datamatikeruddannelsen forår/efterår 2005 Side 2 av 28

Projektdefinition Hvordan startes et projekt? Hvordan kan man vide hvad man skal opnå? Hvordan skal dette opnås? Hvordan kan man vide om det er en god idé, i det hele taget? Hvordan kan man vide om kriteriene for success er opnået? Der er et grundlæggende behov for at alle deltagere har en fælles forståelse for hvad projektet handler om I den virkelige verden er man ofte nødt til at sætte i gang uden at have klarlagt punkter som mål, opgave, budget og finansiering. Som en grundlæggende forudsætning er det vigtigt at sikre sig hvem der er sponsor for projektet. Har de beføjelser nok til at gennemføre projektet, og allokere de nødvendige ressourcer. Sponsorene, dvs dem der tager initiativet til og finansierer projektet, har ofte et klart billede af hvad de ønsker gennemført, men uklare idéer om hvordan de skal udføres og hvilke fordele det indebærer. Projektdefinition Mandat 1. Har sponsorene myndighed til at gennemføre projektet? 2. Kan sponsorene skaffe de nødvendige ressourcer? 3. Er der andre organer der skal godkende projektet? Formål og Mål 1. Kan man definere klare, målbare mål for projektet? 2. Er målene fornuftige og opnåelige? 3. Er sponsorene enige? Virkeområde Hvad skal projektet omfatte? 1. Hvilke afdelinger, forretningsområder eller forretningsprocesser? 2. Vil der blive krav om ændringer i organisationen? 3. Hvilke forretnings processer vil blive påvirket, eller forblive uændret? Fordele Forretnings behov Projekt definition Projekt udførelse Tidlig i projektet, kan det være svært at afgøre alle fordele ved projektet. Under opstarten af projektet, vil projektledelsen arbejde med sponsorene på at klargøre de forventede fordele. Dette inkluderer alle fordele, ikke bare de økonomiske. Datamatikeruddannelsen forår/efterår 2005 Side 3 av 28

Tidsrammer 1. Er der specielle krav til tidsplanlægnig f.eks. deadlines, leveringstider og -frister. 2. Når regner man med at begynde på arbejdet? Kontroll Hvordan vil projektet blive ledet og kontrolleret? 1. Hvem har det endelige ansvar for projektet? 2. Hvem er daglig leder? 3. Hvem udgør styregruppen? 4. Hvordan og hvor ofte regner deltagerne med at deltage i gruppen? Prioriteringer, gennemførbarhed og tilladelse Er alle enige om at starte projektet? 1. Kan målet virkelig nås? Kan man finde de nødvendige ressourcer og personel? 2. Er de vigtigste risici forstået og accepteret? 3. Er organisationens ledelse indforstået, og villig til at gå ind for projektet? Det er vigtig at alle implicerede ansatte har sat sig ind i projekt definitionen, og forstår den. Detaljerne bør fældes ned i et dokument, og vedtages. Dette dokumentet skal læses af alle implicerede parter. Det skal være muligt, under projektets forløb, at ændre i projektets definition som resultat af projektets arbejde. Datamatikeruddannelsen forår/efterår 2005 Side 4 av 28

Planlægning Planlægning Definering af det arbejde der skal udføres, inkluderet specificering krav til ressourcer, afhængighed og tidsplanlægning. Beregning Beregning af forbrug af tid og arbejdsindsats der er påkrævet for hver type af ressource til hver del af det arbejde der skal udføres. Tildeling av ressourcer Tildeling af ressourcer normalt projektets personale. Tilgængelige ressourcer er næsten altid utilstrækkelige, og dette kræver som regel at der indgåes kompromisser når arbejdet skal planlægges, eller under selve udførelsen. Sådanne omlægniner kan godt indebære at perioder/faser i projektet forlænges. Måder at planlægge på Oppefra-ned (Top-down) Den klassiske metode er oppefra-ned (Top-down). Alt der kræves deles op i få, høj-niveau komponenter. Disse deles op i mindre enheder, der så planlægges i detalje. Detlaje planlægningen kan så foretages umiddelbart inden arbejde på området påbegyndes. Dette er den mest logiske metode, og indebærer at man tidlig får en overdnet plan der kan bruges i projekt definitionen og i en cost-benefit analyse Nedenfra-op (Bottom-up) Her starter man med en tidligere, fuldt detaljeret plan, og justerer detaljerne, beregningerne og afhængighederne. Dette indebærer allerede fra begyndelsen har en detaljeret plan, men også at en opsummering af projektet ikke er udgangspunktet, og derfor skal laves. Detaljering Ved nedenfra-op, har man allerede en detaljeret plan. Hvis man derimod planlægger oppefra-ned, skal man planlægge detaljeret efterhånden som projektets stadier skrider frem. Ellers kan man risikere at spille sin tid på detaljeret planlægning af begivenheder der ligger langt fremme i tid. Delt plan Planlægning Beregning Tildeling af ressourcer En god måde at håndtere en stor og kompleks plan på, er at dele den op. Del-planer håndterer dele af problemet. Ideelt set, har så hvert område sin leder, der pålægges ansvaret for den detaljerede plan for sit område og for at opfylde målsætningene herfor. Datamatikeruddannelsen forår/efterår 2005 Side 5 av 28

Projektlederen skal stå for koordineringen af del planene, og skal have opmærksomhed på fælgende punkter, angående koordinering: Identificere og arbejde mod generelle milestones. Krydsafhængigheder. Koordinering af ressourcer når disse deles mellem flere del projekter (planer). Sikre kompabilitet og standarder. Aktivitets fokuseret plan Aktivitets fokuseret plan Aktivitets fokuseret plan Logisk struktur Eksempel Logisk Fase 1struktur Eksempel Fase 1 Definer projektet Fase 1 Aktivitet 1 Aktivitet Opgave 1 A Opgave AB Fase 1 Definer projektet Definer projektets anvendelse Definer projektets anvendelse Definer anvendelse Definer Opnå enighed anvendelse Aktivitet Opgave 2 B Forberede benefit analyse Opnå enighed Aktivitet 2Opgave C Forberede benefit analyse Lav benefit analyse Opgave CD Opgave D Lav Opnå benefit enighed analyse Opnå enighed Deler planlægningen op i opgaver, eller hvilke aktiviteter der skal udføres. Disse deles typisk op, og struktureres i kategorier. Et velkendt koncept der kaldes Work Breakdown structure WBS. Proces fokuseret plan Proces fokuseret plan Proces fokuseret plan Logisk struktur Eksempel Logisk Proces struktur 1 Lever Eksempel projektets målsætninger Proces 1 Del proces 1 Del proces Opgave 1 A Lever projektets målsætninger Definer projektets anvendelse Definer projektets anvendelse Definer anvendelse Opgave AB Definer [Alle aktiviteter anvendelse vedrørende Del proces 2 projektets anvendelse] Opgave B [Alle aktiviteter vedrørende Del proces Opgave 2 C Levere den optimale benefit projektets analyse anvendelse] Opgave CD Levere den optimale benefit Lav benefit analyse analyse Opgave D Lav [Alle benefit aktiviteter analyse vedrørende benefit analyse] [Alle aktiviteter vedrørende benefit analyse] Beskriver projektet i processer, der deles op i under processer. Dette er forenelig med at tænke og planlægge i workstreams. I disse diagrammer bruges verber, da de peger på ting der skal udføres. Datamatikeruddannelsen forår/efterår 2005 Side 6 av 28

Leverings fokuseret plan Leverings fokuseret plan Logisk struktur Eksempel Fase 1 Fase 1 Lever Projektdefinition Stor Del aflevering 1 Definer projektets anvendelse Levering A Definition Levering B Definition afleveringsdokument Stor Del aflevering 2 Levering C Benefit analyse Levering D Benefit analyse Benefit analyse afleveringsdokument Istedenfor at fokusere på opgaver og funktioner, fokuseres det på de resultater der skal leveres. Derfor bruges der substantiver i stedet for verber i diagrammet. Begræsningerne i denne måden at gøre det på, ligger i brugen. Projektledere kan tænke på færdig aflevering i form af et dokument, heller end om resultatet er opnået. Resultat fokuseret plan Resultat fokuseret plan Logisk struktur Eksempel Fase 1 Fase 1 Lever Projekt defineret Stor Del aflevering Definer projektets anvendelse Levering A Forslag fremmet Levering B Enig om forslaget Stor Del aflevering 2 Levering C Benefit analyse Levering D Benefit defineret Enighed om Benefit analyse Man kan også lave en plan der fokuserer på resultaterne.dette vil, istedenfor at fokusere på det der bliver gjort eller leveret af dokumenter, fokusere på om man har opnået tilfredsstillende resultater af sit arbejde. Derfor vil man ofte se et successkriterium som at der er opnået enighed om resultatet af gruppens aktiviteter. For alle disse måder at planlægge på, gelder det at man skal identificere kritiske punkter milestone - hvor der er sat en målsætning. F.eks. ved færdiggørelsen af en komponent, aflevering etc. Datamatikeruddannelsen forår/efterår 2005 Side 7 av 28

Fordele Ulemper Aktivitets fokuseret plan De fleste er vant til denne. Tilsyneladende meget arbejde uden målbart resultat Proces fokuseret plan Leverings fokuseret plan Forklarer godt hvordan ting gøres Henleder opmærksomheden på at levere det leverbare. Taber det trindvise overblik Kan tilskynde til at levere trivielle dokumenter istedenfor at fokusere på arbejdet. Resultat fokuseret plan Fokuserer på det vigtigste. Kan være vanskeligt at målet resultatet Milestone fokuseret Viser på en enkel måde kritisk information. Er i virkeligheden fokuseret på levering eller resultat. Vil ikke normalt rette opmærksomheden mod at opnå målene i de forskellige milestones. Projektets form Et projekt kan planlægges på mange måder. Planlægningen er afhængig af projektets formål, hvem der planlegger, projektets størrelse osv. Hvis man vælger en metode til at forme projektet, vil formen også afhænge af metoden. Antal faser Størrelsen på faserne Vandfaldsmetoden, overlappende eller iterative faser Vandfaldsmetoden Den klassiske metode til at organisere et projekt. Hver fase udgør et større segment. Arbejdet i hver fase færdiggøres og godkendes før man begynder på den næste. Der opstår ofte tidspilde i forbindelse med overgangen fra en fase til den næste, fordi der er kan opstå sager tæt på afleveringer og det tager tid at få startet den næste fase op. Et andet problem med vandfaldsmodellen er at det er svært at gå tilbage og ændre i arbejde fra tidligere faser. Fase 1 Aflevering Fase 2 Fase 3 Aflevering Fase 4 Fase 1 Fase 2 Fase 3 Tidsspilde Datamatikeruddannelsen forår/efterår 2005 Side 8 av 28

Overlappende faser For at undgå spils af tid i forbindelse med afslutning og opstart af faser, man man prøvet at overlappe faserne. Hvis en fase bygger på arbejde i den forrige, må man imidlertid sikre at der ikke udføres arbejde på det forkerte grundlag. For eksempel vis man påbegynder implementering før design er fuldført. Iterationer Dele af projektplanen vil blive gentaget indtil projektet er færdig. Der er to former for iterationer Gentage design, prototyping og evaluering så løsningen gradvis nærmer sig opfyldelsen af behovet. Frigør komponenter uden at vente på den færdige løsning. Iterative projekter er specielt egnet for eprojekter fordi: Nødvendig at levere hurtige resultater Start Hurtige ændringer i teknologi og forretnings processer Iterativ løsning med 2 niveauer for iterationer. Man kan lave iterationer på flere niveauer Svært at definere kravene nøjaktig uden prototyper. Design Nej Test Klar til levering? Ja Ja Implementer Nej Flere opgaver? Start Nej Datamatikeruddannelsen forår/efterår 2005 Side 9 av 28

Et projekts form. Der er 7 logiske overlappende faser. Der er tre generelle stadier hvor man 1. stadie: Udarbejder systemet begrebsmæssige design. 2. stadie: Udarbejder detaljeret design og bygger systemet. Dette er det længste stadie, og kræver meget mere arbejde end de andre. 3. stadie: Systemet tages i brug. Planlægning Vision Definition Begrebsmæssig design Begrebsmæssig design Detaljeret design Byg løsning Før hver fase påbegyndes, er en nøje planlægning påkrævet. Dette er alltid koblet sammen med beregninger af bl.a. forbrug og ressourcer. Med god planlægning, en gennemtænkt Work Breakdown Structure (WBS), milestones og en god beskrivelse af afhængigheder, kan dette kalkuleres godt. De vigtigste formater for dette er GANTT og PERT diagrammer. Udvikling og testing Implementering Operation Vedligeholdelse og forbedring Pert diagram Projektets Arbejdsområde 12.02.2005 5 0 Projekt-definition 14.02.2005 8 0 Projekt-definition Godkent 16.02.2005 4 0 Projekt-definition Godkent 16.02.2005 4 0 Arbejdsområdet Godekendt 14.02.2005 8 0 Gantt diagram Gantt giver en grafisk oversigt over opgaverne, og er umiddelbart nemmere at læse for en uden kundskaber om projektstyring. Datamatikeruddannelsen forår/efterår 2005 Side 10 av 28

Pert diagrammet viser mer detaljeret logikken og afhængigheder i et projekt. Afhængigheder De fleste værktøjer til projekthåndtering tager udgangspunkt i Finish-start afhængigheder mellem opgaver. Dette er imidlertid ikke alltid det optimale. Afhængighed Brug Eksempel Finish-start Finish-finish Start-start Start-finish Den næste opgave kan ikke påbegyndes før den forrige er fuldført. Du kan begynde på den næste opgave, men kan ikke fuldføre den før den forrige er fuldført. Den næste opgave kan først påbegyndes, når den har fået nogen output fra den forrige Forgængeren kan ikke blive færdig for forgængeren er fuldført Man skal være enige have en kontrakt. Fysisk umulig, kræver f.eks. at hardware er installeret. Begynde at lave en prototype inden design er fuldført. Interviews kan dokumenteres så snart man har det første. Kontrol påbegyndes så snart testing er kommet i gang. Bruges sjældent Milestones Milestones er nyttige til planlægning. De kan bruges til at måle om man har opnået mål på højt niveau, eller til identificere færdiggørelsen af konkrete, afgørende opgaver. Milestones indeholder i sig selv ingen opgaver, men beskriver målsætninger i projektet. Tidsplanlægning I udgangspunktet skal følgende identificere: 1) Hvornår skal en opgave påbegyndes og 2) Hvor lang tid tager det at løse den? Tidsforbrug kan i princippet så beregnes med formelen Varighed = 20 dages arbejde / 5 personer = 4 dage. Dette er ikke alltid gyldig: Varighed = Arbejdsmængde / Tildelte Ressourcer Kan 100 mennesker skrive en manual på 1 time?? Hvis man har 8 måneder til en opgave, ville man sætte en person til at arbejde 1 time daglig? Komplekse afhængigheder Del opgaverne ind i processer, og tilstræb afhængigheder her. Link faser til faser Link aktiviteter til aktiviteter Datamatikeruddannelsen forår/efterår 2005 Side 11 av 28

Undgå links fra en delproces eller -plan til en anden. Estimering Der er mange metoder for at beregne hvad der skal bruges af ressourcer til et projekt. Beregningsteknikker indebærer altid overslag og gætterier, og vil ofte være baseret på tidligere erfaringer. Hvis oplysninger om tidligere erfaringer er struktureret, er de lettere at bruge. Tilnærminger til estimering Tilnærming Vi har gjort det før Erfaringer fra et lignende projekt er det bedste udgangspunkt, forudsat at man tager udgangspunkt i de faktiske resultater. I nogle tilfælde er det hensigtsmæssig at gentage planer, f.eks. for software leverandører eller ved rollout. Kvalificeret gæt Struktureret viden fra tidligere erfaringer Antal linjer kode Et kvalificeret gæt, baseret på egne og andres erfaringer og erfaringer fra mange tidligere projekter. Her ser man efter lignende erfaringer der kan overføres til det nuværende. Man bereger udfra en samling struktureret viden der bygger på erfaringer fra tidligere. Nøglen til successs ligger i en riktig klassificering af de faktorer der udgør tid og arbejdsindsats. Ud fra programmeringsteknik og programmeringsprog kan man beregne arbejdsindsatsen. Der er to mangler ved denne model: Hvordan beregne antal linjer kode? Der er mange andre faktorer end bare leveringen af kode. Nogle systemer er lette at bygge, men vanskelig at implementere. Arbejdsindsats er proportional med: Projektets omfang gange Fleksibilitet gange Organisationens kompleksitet Dette giver udgangspunkt for følgende spørgsmål: Hvor mange ting skal udføres? Hvor mange alternativer skal der være i løsningen? Hvor mange mennesker skal involveres i hvert alternativ for hver opgave der skal udføres? Datamatikeruddannelsen forår/efterår 2005 Side 12 av 28

Kompleksitets Faktor Hvis en opgave skal udføres, så er der bare en ting at håndtere Ved to opgaver, skal man også håndtere overlapning, interaktioner, afhængigheder etc, det giver 3 ting 4 opgaver giver 15 aspekter Formelen: Antal aspekter = 2 n -1, hvor n er antal ting Gøre noget 10 gange så stort er 1023 gange så kompliceret Ting kan være: Antal systemer der skal udskiftes Antal integrerede komponenter Antal business processer der skal ændres Antal afdelinger der berøres etc En person bruger lang tid på en opgave 2 personer bruger kortere tid, men ikke halvdelen 3 personer er måske hurtigere, men kan det betale lønnen til tredjemand? Osv. Balance mellem arbejdsindsats og risici Den arbejdsinsats der lægges, kan balanceres imod de risici man tager ved at spare. Man vil bruge mere tid på at beregne drivstof forbruget til og fra månen, end til og fra næste by. Hvis man kan levere 80% af resultatet, med 20% af arbejdsindsatsen, vil man det, selvom antallet risici fordobles? Dette er specielt vigtigt for eprojekter, hvor hurtige resultater er afgørende. Det er almindeligt at møde 80% af kundens behov og undgå de 20% der er vanskelige og kræver en betydelig arbejdsindsats. Datamatikeruddannelsen forår/efterår 2005 Side 13 av 28

Projekt, struktur og organisering De forskellige roller i projektgruppen vil variere efter projektets formål og dets forløb. Roller og ressourcer vil være identificeret i løbet under projektets planlægning og beregningsfase. Ofte vil et lille team udarbejde forretningsløsningen. Et større team vil blive sat til at føre denne ud i livet. Teamets struktur vil gennemgå forandringer i projektets forløb, der afspejler udviklingen i projektet. Nogen er fuldtids beskæftiget, andre på deltid og nogle træder til ved behov, bl.a. med special kompetence. Der er to vigtige dimmensioner for et team: Hvilken type ressource repræsenterer en person? Hvad kan vedkommende bidrage med? Heller end at betragte dette som et valg, kan man prøve at samle de ressourcer projektet behøver. Mennesker med forskellige ressourcer skal arbejde sammen, i forskellige teams, for at opnå målsætningen. Hvert team skal have sin egen leder. Mennesker der arbejder sammen i et team, vil arbejde loyalt sammen og der vil udveksles kundskaber mellem dem. Interaktioner mellem medarbejdere i et team, er den bedste måde at få belyst alle områder. Roller Der er mange roller i en projektgruppe. Nogle på fuld tid, andre på deltid, mens nogle vil optræde efter behov. Projektets sponsor Projektets Ansvarlige leder Styregruppen Regnskabsmedarbejder Projektleder Eksperter på forskellieg områder Slutbruger Jurister Kvalitetsmedarbejdere Datamatikeruddannelsen forår/efterår 2005 Side 14 av 28

Proces eller funktionelt struktureret team Alle de store funktionelle aspekter ved projektet har fået sit eget team. Hvert team er sammensat af medlemmer med forskellig slags kompetence, færdigheder og forståelse for projektets mål. Proces eller funktionelt struktureret team Overordnet ledelse Styregruppe Ansvarlig leder Projektleder Funktionel Teamleder Funktionel Teamleder Teknisk Teamleder Team medlem Funktionel Teamleder Funktionel Teamleder Funktionel Teamleder Funktionel Teamleder Funktionel Teamleder Datamatikeruddannelsen forår/efterår 2005 Side 15 av 28

Ressource orienteret struktur I denne strukturen er teamet bygget op efter type ressourcer. Lignende ressourcer er samlet i teams. Dette er nødvendigvis den mest effektive løsning, men mange medarbejder har det godt med denne løsningen. For en given opgave kan det være nødvendig at sætte sammen medlemmer fra forskellige teams. F.eks. prototyping kan kræve samarbejde mellem User team og Application team. Ressource orienteret struktur Styrende komité Projektets ejere Projektets sponsorer Ansvarlig leder Projektleder Projektets kontor BPR / Change facilitators User Teamleder Application Teamleder Teknisk Teamleder Bruger Team Krav specifikation Business Process redesign Management of change Business Design Prototyping Procedurer Accaptance testing Application Team Training/Coaching Application analysis & Design Custom dvelopment Prototyping Application testing Integration testing Technical Team Hardware, network and environment Operating system Database Data migration Backup & recovery Performance Operating procedures Operational testing Datamatikeruddannelsen forår/efterår 2005 Side 16 av 28

Kontrol og rapportering Projektledelsen og teamlederne skal bære i stand til at kontrollere det arbejde der bliver udført af den enkelte. Dette kræver oplysninger som: Hvad den enkelte laver Hvor meget tid, ressourcer og penge der bruges Hvor effektivt arbejde og ressourceudnyttelsen er Hvilke problemer der kan opstå Holder målene hvad angår tidsfrister og beregnet frobrug af ressourcer? De ansvarlige for projektet, som styregruppen og sponsorene har behov for at følge med i oplysninger der sætter dem i stand til at Intervenere hvis der dukker op problemer Juster budgetter og tildelte ressourcer Vide når de skal gribe ind ved problemer Sikre at frister og projektets specifikationer overholdes Forståelse for hvad der opnås og hvornår. For at opnå dette, må projektlederen opnå følgende mål: Balancere mellem behovet for information og de følelsesmæssige konsekvenser dette har for medarbejderne Få kommunikeret klart og tydeligt hvorfor man samler ind oplysninger om den enkeltes tidsog ressourceforbrug Kontrol og rapport De vigtigste hjælpemidler Timesedler Timesedler er en meget brugt måde at indsamle data om arbejdet på. Timesedler kan udfyldes på papir eller elektronisk, gerne via e-mail. Timeseddelen indeholder en oversigt over hvilke projekter medarbejderen arbejder på, hvor mange timer der er lagt, og en beregning af hvor mange timers arbejde der genstår. Dette kan beregnes op imod tidsfrister. I tilæg er der plads til kommentarer og forslag og en oversigt over leveringer. Status over leveringer omfatter både afleverede, og leveringer beregnet ind i fremtiden. Informationssamlinger Alle store projekter må sætte op en metode til at samle ind dataene på. Dette er ofte en opgave for projektkontoret. Data kan lægges på en central server, hvor den enkelte kan lægge data. Alternativt kan data indsamles via e-mail eller vie en hjemmeside der er oprettet for projektet. Der findes værktøj til dette på markedet. Rapporter Datamatikeruddannelsen forår/efterår 2005 Side 17 av 28

Der vil være store mængder information tilgængelig om projektet. Derfor kan det godt være en udfordring at udarbejde gode rapporter. Forskellige modtagere vil have et forskelligt behov for information. Allerede udført arbejd og overslag over færdiggørelsen Færdige leverancer og datoer for resterende leverancer Opnåede milestones og datoer for fremtidige milestones Forbrug målt op i mod budget Indtægter Analyse af risici Problemer der er opstået og problemer der er løst Større ændringer og ændringer der kræver godkendelse Resultater kan præsenteres i kurver og opsummerende GANTT diagrammer. En anden måde at præsentere fremskridt på er ved hjælp af milestones. Disse kan plottes ind i en kurve, så man får en grafisk præsentation af projektets status i forhold til milestones. Møder og kommunikation God kommunikation er vitalt for et projekt. Der vigtigt at der er god kommunikation mellem bl.a Projektlederen, sponsorene, styregruppen og den ansvarlige for projektet. Regelmæssige møder og rapporter er de mest almindelige kommunikationsformer med ledelsen. En typisk dagsorden kan bestå af Hvad er udført Hvor står vi nu Ud fra dette, hvordan ser fremtiden ud Hvilke problemer skal håndteres? Anbefalinger Møder bør have en fast dagsorden, og behovet for dem skal altid afvejes i mod andre opgaver for personalet. Der bør også være faste regler for hvem der beslutter hvad. Alle papirer til et møde må selvfølgelig sendes ud i god tid til deltagerne. Datamatikeruddannelsen forår/efterår 2005 Side 18 av 28

Dokumentstyring og kontrol Alle projekter medfører produktion af dokumenter både til internt og eksternt brug. Der udarbejdes mange typer dokumenter til mange forskellige formål. Mange af disse dokumenterne vil være elektroniske. Eksterne Interne Permanente dokumenter Permanent dokumentation der leveres i forbindelse med projektet. Hjælpeinformation, manualer etc Permanent dokumentation til drift og vedligeholdelse af systemet. Dsegign og databasespecifikationer, kildekode, proces diagrammer Midlertidige dokumenter Midlertidige eksterne dokumenter i forbindelse med projektet. Diskussionspapirer, forslag, dokumenter til gennemsyn etc. Midlertidige dokumenter til intern kommunikation. Idéer, arbejdsdokumenter etc. Eksterne dokumenter må holde en høj kvalitet, mens interne dokumenter godt kan være uformelle eller ikke udfyllende Permanente dokumenter skal kunne opdateres når der er behov herfor, mens midlertidig dokumentation ikke vil blive opdateret. Noen systemer, f.eks. til e-handel, må være selv dokumenterende. Dette er tilsvarende værdifuldt for anden dokumentation: Analyse, design og udviklingsværktøjer bør være selv dokumenterende. Standarder for kildekode bør sikre at andre kan læse og forstå den. Procedurer kan præsenteres i forbindelse med arbejdsgange. Manualer og hjælpetekster kan indarbejdes i systemet, afhængigt af sammenhængen de præsenteres i. Dokumentation kan med fordel katalogiseres i 2 niveauer, så man får en tabel. Business Proces Teknologi Mennesker Flere... Dokumentation BP1 BP2 T1 T2 M1 M2 Vision Business krav Flere I begyndelsen, hvor dokumentationen ikke er omfattende, kan man godt undvære katalogisering, men det vil efterhånden blive nødvendig at definere en metode til at styre dokumenter på. For et lille system, kan dette klares med regneark, hvor man styrer dem i et hoveddokument. For større systemer vil det være hensigtsmæssig at bruge værktøjer til dokumentstyring. Datamatikeruddannelsen forår/efterår 2005 Side 19 av 28

Hvis muligt, skal dokumenter overholde en standard man sætter for projektet. Dette kan bl.a. sikres ved hjælp af Skabeloner Modeller Eksempler på dokumenter. Projektkontoret vil som regel stå for driften af et Document management system. Preojektkontoret eller projektleder vil følge dokumenter med henblik på: Dokumenter der ikke er kommet så langt som planlagt. Fuldført arbejde hvor dokumentationen ikke er lavet. Konkurrerende behov for et dokument. Medarbejdere der ikke arbejder på den korrekte version af et dokument. Tilfredsstillende kontrol eller kvalitet i dokumenter. Ved projektets slut, bliver dokumenter behandlet efter sin natur: Midlertidige dokumenter bliver arkiveret for et tilfældes skyld. Permanente dokumenter arkiveres til senere brug. Eksterne dokumenter er afleveret, og skal vedligeholdes. Datamatikeruddannelsen forår/efterår 2005 Side 20 av 28

Risiko styring Der<er risici ved alt, også projektarbejde. Afhængigt af systemets størrelse eller funktion, kan modtagers fortsatte eksistens være på spil. Ved udarbejdelse af kritiske systemer kan menneskeliv komme til skade eller gå tabt hvis kritiske komponenter svigter. En god projektleder vil vurdere risici konstant, og handle om nødvendig. Handle for at ungå risici, reducere sandsynligheden for problemer eller konsekvensene af dem. Udarbejde kriseplaner, så teamet er beredt til at handle på konsekvensene, og imødegå risici hvis de opstår. Sige sig enig i at det er acceptabelt at tage en chance, og håbe at der ikke opstår noget. Identificer risici Analyser sandsynlighed og konsekvens Undgå eller reducer Udarbejd kriseplan Overvåg og tag kontrol Procedure for at imødegå risici. Grundprincipper for at imødegå risici. Identificer alle realistiske mulige problemer. Analyser sandsynligheden for at de opstår, og hvilke konsekvenser de kan have. Tage beslutning om der skal gøre noget for at reducere chancen for at de opstår eller reducere konsekvensene. Om nødvendigt udarbejde planer for at håndtere problemer hvis de opstår. Overvåg konstant med tanke på risiko for problemer. Vurdere risici Formel: Sandsynlighed gange Udgifter hvis de opstår er lig med Forventede udgifter. Man kan reducere omkostningerne ved risici enten ved at reducere sandsynligheden for at de opstår eller ved at reducere konskvensene. Når man skal vurdere tiltag for at møde risici, skal man vurdere tiltagenes omkostninger imod kondekvensenes omkostninger og sandsynliheden for at de opstår. Under projekt definitionen bliver der kigget på de store linjer, og fokus for risiko vurdering vbil typisk være om der er så store risici at projektet må skrinlægges. Datamatikeruddannelsen forår/efterår 2005 Side 21 av 28

Dette er ikke en opgave for en person alene, men må diskuteres blandt projektets deltagere eller være genstand for brainstorming eller andre gruppe aktiviteter. Alternativt kan man få hjælp af en der er ekspert på det området hvor man mener der kan være risici. For hver fase, vurderes risici mere detaljeret, og de bør registreres elektronisk. En sådan beskrivelse bør indeholde: En beskrivelse Sandsynlighed for problemer Beskrivelse af konsekvenser Et overslag over omkostninger hvis noget skulle opstå Hvilke tiltag der skal iværksættes og af hvem Eventuelle kriseplaner der skal udarbejdes. Risici kan dreje sig om sygdom blandt medarbejderne, mangelfuld business løsning, manglende delagelse, forståelse eller motivation fra brugerne, tekniske problemer, systemsvigt etc. I tilæg må man vurdere risici der er specifik for det aktuelle projekt. Risiko styring Dette skal betragtes som en proces der kører i hele projektets levetid. Så snart et register over risici er etableret, sammen med procedurer for disse, må alle deltagere i projektet være opmærksom på nye risici der kan opstå. Procedurer for at registrere risici bør være let tilgængelige, og feedback fra alle projektets deltagere bør påskønnes. Både projekt kontoret og projektlederen bør overvåge registrede risici kontinuerlig, og følge op ved at kontakte de ansvarlige og bede om status. En oversigt over risici skal rapporteres til den øverste projektledelsen sammen med andre oplysninger om projektets status. Datamatikeruddannelsen forår/efterår 2005 Side 22 av 28