3.0 faser af projektimplementering (del 2)

Udvikling #

I udviklingsfasen samles alle de nødvendige komponenter til implementering af projektet. Potentielle leverandører eller underleverandører kontaktes, der laves en tidsplan, bestiller forsyninger og værktøjer, og medarbejderne instrueres bl.a. Når implementeringsfasen er klar til at begynde, er udviklingsfasen færdig. Alle spørgsmål skal afklares for de personer, der er ansvarlige for henrettelsen.

En formel udviklingsfase er måske unødvendig for visse projekter, især mindre. Det afgørende er, at det er indlysende, hvad der skal opnås i implementeringsfasen, af hvem og hvornår.

Implementering #

I implementeringsfasen danner projektet gevinster. Denne fase indebærer den faktiske opbygning af projektets resultat. Programmerere koder, designere skaber visuelt indhold, entreprenører konstruerer, og den reelle reorganisering sker. Dette er den periode, hvor projektet bliver tydeligt for udenforstående, som måske tror, at projektet lige er startet. Det

Implementeringen er ‘gør’ -fasen, og det er afgørende for at opretholde momentum i hele denne periode.

I et tilfælde var projektteamet ikke klar over, at et af de væsentlige teammedlemmer skulle blive forælder og derfor ville være totalt utilgængelig i cirka en måned. Da tiden var inde til at udskifte ham, blev der tilkaldt en ekstern ekspert for at forhindre holdet i at slibe. Mens teamet var i stand til at beholde, tog den eksterne ekspertise en betydelig bid ud af budgettet.

Ved afslutningen af implementeringsfasen sammenlignes resultatet med listen over krav, der blev fastlagt i definitionsfasen. Derudover vurderes det i forhold til designene. F.eks. Kan der udføres test for at bekræfte, at online -applikationen understøtter Internet Explorer 5 og Firefox 1.0 og nyere. Det er muligt at verificere, om beklædningen på bygningen blev konstrueret i overensstemmelse med aftalen, eller om de anvendte materialer faktisk var de specificerede under defineringsfasen. Denne fase er færdig, når alle kriterier er opfyldt, og det resulterende produkt er i overensstemmelse med designet.

Dem, der deltager i et projekt, skal huske på, at det er meget sjældent at få et produkt, der nøjagtigt opfylder alle de kriterier, der blev angivet under defineringsfasen. I løbet af et projekts udførelse kan uventede hændelser eller fremskridt i forståelsen tvinge projektteamet til at afvige fra det første sæt krav eller andre designdokumenter.

Dette er en mulig årsag til strid, især hvis en ekstern klient har bestilt projektets resultat. I visse tilfælde kan kunden påberåbe sig de aftaler, der blev indgået under defineringsprocessen.

Generelt kan krav ikke ændres, når defineringsprocessen er afsluttet. Dette gælder også for designs: Når designprocessen er færdig, kan designet ikke ændres. Hvis dette bliver påkrævet (som det nogle gange sker), skal projektlederen sikre, at ændringerne meddeles alle interessenter (især beslutningstagere eller forbrugere) hurtigst muligt. Derudover er det afgørende, at de foretagne ændringer registreres korrekt for at undgå fremtidige misforståelser. Yderligere oplysninger om projektets dokumentation er inkluderet senere i denne vejledning.

Luk ud og følg op #

Selvom det er kritisk, overses opfølgningstrinnet ofte. I denne fase træffes alle væsentlige foranstaltninger for at sikre projektets succes. Opfølgningsfasen kan omfatte oprettelse af manualer, instruktion og træning for brugerne, oprettelse af en helpdesk, vedligeholdelse af resultatet, evaluering af selve projektet, skrivning af projektrapport, vært for en fest for at fejre opnåelsen af resultatet, overførsel af projektteamet til direktørerne og demontering af projektteamet.

Opfølgningsfasens centrale problem er, hvornår og hvor projektet afsluttes. Projektledere joker ofte med, at de første 90% af et projekt bevæger sig hurtigt, og de sidste 10% kan tage år.

Projektets grænser bør evalueres fra projektets start, for at projektet kan lukkes i opfølgningsfasen, når det når disse grænser.

Det er nogle gange uklart for de involverede, om projektets slutresultat vil være en prototype eller et fungerende produkt. Dette er især udbredt i kreative tiltag med usikre resultater. Selvom kunderne kan forvente at modtage et produkt, kan projektteamet tro, at det er ved at udvikle en prototype. Sådanne situationer er mest tilbøjelige til at dukke op i opfølgningsperioden. Overvej eksemplet på en softwareudviklingsindsats designet til at validere en ny idé. Der var betydelig bekymring for muligheden for overhovedet at indhente nogen fund.

Til sidst havde projektet positive resultater. Teamet producerede software, der fungerede godt, i det mindste inden for testmiljøets rammer. Klienten, der ikke var bekendt med informationsteknologi, mente at han havde fået et funktionelt produkt. Det havde jo virket på computeren på hans kontor. Selvom programmet fungerede godt, da det blev placeret på pc’erne med halvtreds arbejdere, udviklede prototypen problemer og blev ustabil på punkter.

Selvom programmørerne kunne reparere softwaren, blev de presset på tid på grund af deres engagement i det næste projekt. Derudover havde de ringe interesse i at reparere det, de betragtede som et eksperimentelt element. Flere måneder senere, da Microsoft introducerede Windows Service Pack 2, ophørte programmet med at fungere fuldt ud. Klienten var vred over, at ‘produktet’ var blevet afbrudt.