3.0 Faser av projektdistribution (del 2)

Utveckling #

Under utvecklingsfasen monteras alla nödvändiga komponenter för att genomföra projektet. Potentiella leverantörer eller underleverantörer kontaktas, en tidtabell skapas, leveranser och verktyg beställs och anställda instrueras bland annat. När implementeringsfasen är redo att börja är utvecklingsfasen klar. Alla frågor måste klargöras för de personer som ansvarar för avrättningen.

En formell utvecklingsfas är kanske onödig för vissa projekt, särskilt mindre. Det som är kritiskt är att det är uppenbart vad som måste åstadkommas under implementeringsfasen, av vem och när.

Genomförande #

Under implementeringsfasen formas projektvinster. Denna fas innebär att själva projektets resultat byggs upp. Programmerare kodar, designers skapar visuellt innehåll, entreprenörer konstruerar och den verkliga omorganisationen sker. Detta är den period under vilken projektet blir uppenbart för utomstående, som kanske tror att projektet just har börjat. De

Implementeringen är “gör” -fasen, och det är avgörande för att upprätthålla fart under denna period.

I ett fall var projektteamet omedvetet om att en av de viktigaste teammedlemmarna skulle bli förälder och därför skulle vara helt otillgänglig i ungefär en månad. När det var dags att byta ut honom kallades en extern expert in för att förhindra att laget slipade till ett stopp. Medan teamet kunde behålla tog den externa expertisen en rejäl bit av budgeten.

I slutet av implementeringsfasen jämförs resultatet med listan över krav som fastställdes under definitionsfasen. Dessutom bedöms det i förhållande till mönster. Exempelvis kan testning utföras för att bekräfta att onlineapplikationen stöder Internet Explorer 5 och Firefox 1.0 och senare. Det är möjligt att verifiera om trimmen på byggnaden konstruerades i enlighet med avtalet eller om de material som användes faktiskt var de som specificerades under definieringsfasen. Denna fas är klar när alla kriterier har uppfyllts och den resulterande produkten överensstämmer med designen.

De som deltar i ett projekt bör komma ihåg att det är mycket sällan man får en produkt som exakt uppfyller alla kriterier som anges under definieringsfasen. Under ett projekts genomförande kan oväntade händelser eller framsteg i förståelsen tvinga projektteamet att avvika från den ursprungliga uppsättningen krav eller andra konstruktionsdokument.

Detta är en möjlig tvisteorsak, särskilt om en extern klient har lagt en order på projektets resultat. I vissa fall kan kunden åberopa de överenskommelser som träffades under definieringsprocessen.

I allmänhet kan kraven inte ändras när definieringsprocessen är klar. Detta gäller även mönster: när designprocessen är klar kan designen inte ändras. Om detta blir nödvändigt (som det ibland händer) bör projektledaren se till att ändringarna meddelas alla intressenter (särskilt beslutsfattare eller konsumenter) så snart som möjligt. Dessutom är det viktigt att de ändringar som görs registreras korrekt för att undvika framtida missförstånd. Ytterligare information om projektets dokumentation finns senare i denna guidebok.

Stäng ut och följ upp #

Även om det är kritiskt förbises uppföljningssteget ofta. Under denna fas görs alla viktiga arrangemang för att säkerställa projektets framgång. Uppföljningsfasen kan innefatta skapande av manualer, instruktion och utbildning för användare, inrättande av en helpdesk, underhåll av resultatet, utvärdering av själva projektet, skrivning av projektrapport, värd för en fest att fira resultatet av resultatet, överföringen av projektteamet till direktörerna och demontering av projektteamet.

Uppföljningsfasens nyckelfråga är när och var projektet ska avslutas. Projektledare skämtar ofta med att de första 90% av ett projekt går snabbt, och de sista 10% kan ta år.

Projektets gränser bör utvärderas från projektets början för att projektet ska stängas i uppföljningsfasen när det når dessa gränser.

Det är ibland oklart för individer om slutresultatet av projektet blir en prototyp eller en fungerande produkt. Detta är särskilt vanligt i kreativa initiativ med osäkra resultat. Även om kunderna kan förvänta sig att få en produkt, kan projektgruppen tro att den utvecklar en prototyp. Sådana situationer är mest lämpliga att dyka upp under uppföljningsperioden. Tänk på exemplet på en mjukvaruutvecklingsinsats som är utformad för att validera en ny idé. Det fanns stor oro över genomförbarheten av att få några fynd alls.

Så småningom fick projektet positiva resultat. Teamet producerade programvara som fungerade bra, åtminstone inom testmiljöns ramar. Kunden, som inte kände till informationsteknologi, trodde att han hade fått en funktionell produkt. Det hade trots allt fungerat på datorn på hans kontor. Även om programmet fungerade bra, när det placerades på PC: arna för femtio arbetare, utvecklade prototypen problem och blev instabil vid vissa punkter.

Även om programmerarna kunde reparera programvaran var de pressade på tid på grund av deras engagemang i nästa projekt. Dessutom hade de ett litet intresse av att reparera vad de ansåg som ett försöksobjekt. Flera månader senare, när Microsoft introducerade Windows Service Pack 2, slutade programmet att fungera fullt ut. Kunden blev upprörd över att “produkten” hade avbrutits.