Initiering #
Projektets början kallas startfasen. I denna fas utforskas och utvecklas projektets idé. Den här fasens mål är att se om projektet verkligen kan slutföras. Val görs om vem som ska leda insatsen, vilken organisation som kommer att delta och om verksamheten kommer att få tillräckligt med stöd från de inblandade.
Detta steg kräver att den befintliga eller framtida projektledaren förbereder ett förslag som beskriver de punkter som nämns ovan. Affärsplaner och bidragsansökningar är exempel på denna typ av projektförslag. Projektets potentiella sponsorer bedömer ansökan och ger den finansiering som krävs om den godkänns. Projektet startar formellt efter godkännande. Måste tas upp följande frågor i början av skedet:
- Varför detta projekt?
- Är det fysiskt möjligt?
- Vilka är de önskade resultaten?
- Vilka är projektets gränser (vad ingår i projektets omfattning)?
Förmågan att säga nej är en kritisk egenskap hos en projektledare. När individer blir entusiastiska över ett projekt tenderar det att växa i omfattning. ”Medan vi håller på kan vi lika gärna …” är den bakomliggande tanken. Projekt till vilka ytterligare mål läggs till och projekt som fortsätter att växa kommer nästan garanterat att gå för sent och kommer sannolikt inte att uppfylla sina ursprungliga mål.
Det första steget är att upprätta en koppling mellan alla projektets intressenter. Orealistiska förväntningar på projektets resultat kan undvikas om omfattningen är väl förstått. För att komma igång, upprätta en koppling mellan de olika involverade personerna. Det är viktigt att ha ett fast grepp om dess omfattning.
Den metod som valts för en specifik typ av projekt har en betydande inverkan på resultatet. Till exempel kan en forsknings- och utvecklingsinsats tillhandahålla en rapport som bedömer en applikations tekniska livskraft. Ett projekt som resulterar i att utveckla en prototyp inkluderar alla funktioner i en applikation. Ändå behöver de inte vara lämpliga för användning i en specifik miljö (t.ex. av hundratals användare). Ett projekt som producerar en fungerande produkt måste också hantera frågor om underhåll, dokumentation och applikationsadministration.
Många missförstånd och tvister uppstår på grund av de människor som engagerar sig projektledning är oklart på dessa punkter. Kunder kan förutse en funktionell produkt medan projektgruppens medlemmar tror att de skapar en prototyp. Medan en sponsor kan tro att projektet skulle resultera i en användbar programvara, måste gruppmedlemmar först avgöra om konceptet är tekniskt genomförbart.
Definition #
Efter den accepterade initieringsprojektplanen startade projektet den andra fasen: definitionsfasen. Denna fas specificerar så exakt som möjligt kraven i samband med ett projekts resultat. Denna fas innebär att fastställa förväntningarna hos alla parter som är involverade i projektets utveckling. Hur många filer krävs för arkivering? Ska metadata ha formatet Data Documentation Initiative (DDO), eller skulle Dublin Core (DC) räcka? Är filer tillåtna i sitt ursprungliga format eller bara de som följer ”Preferred Standards”? Är det insättarens skyldighet att garantera att en datamängd behandlas korrekt i arkivet, eller är detta arkivarens ansvar? Vilka garantier kommer att ges om projektets resultat? Listan över förfrågningar kan fortsätta på obestämd tid.
Det är viktigt att fastställa behov så tidigt som möjligt i processen.
Wijnen (2004) fastställer följande typer av projektbehov som ett minnehjälpmedel:
- Förkunskaper
- Krav för funktionalitet
- Krav för funktionalitet
- Designbegränsningar
Förutsättningar ger den ram i vilken projektet måste genomföras.
Lagstiftning, arbetsvillkor och godkännandeförfaranden är alla exempel. Dessa kriterier är oföränderliga inuti projektet.
Det är viktigt att komma ihåg att kravspecifikationer är de som har att göra med kvaliteten på den slutliga produktionen – tekniska specifikationer relaterade till hur projektets resultat kommer att användas. Till exempel måste antalet fel minskas med 90% efter att ett mjukvaruprojekt är klart. Konstruktionsrestriktioner är å andra sidan projektspecifika krav. Farliga kemikalier och utländska partners med tveksamma arbetsnormer kan inte inkluderas i projektet, som ett exempel.
Under definieringsfasen av ett projekt som inkluderade att bygga en webbapplikation för ett konsortium av stora organisationer, togs inga beslut om webbläsaren som programmet skulle stödja. Konsortiet trodde att det skulle vara Microsoft Explorer eftersom det var ’allas webbläsare.
Utvecklarna byggde programmet på Firefox eftersom de redan var bekanta med webbläsaren och hade flera särskilt användbara funktioner under hela utvecklingen. Eftersom de flesta webbplatser som är utformade för Firefox också ser bra ut i Explorer, var förändringen först omärklig. Men mot projektets avslutning började klienten protestera mot att webbplatsen ”inte såg bra ut”. Programmerarna, som besökte webbplatsen via Firefox, var förvirrade över klagomålet.
När det blev uppenbart att de två webbläsarna var inkompatibla svarade programmerare defensivt: ’Kan de inte installera Firefox? Det är trots allt gratis ’. Å andra sidan tvingade organisationerna statliga systemadministratörer som av vilken anledning som helst vägrade att installera Firefox tillsammans med Explorer.
Även om de ville installera det skulle proceduren ha varit lång och det skulle ha tillkommit extra kostnader i samband med den tid som systemadministratörerna ägnat åt jobbet. Slutligen bestämt att applikationen skulle behöva anpassas för Explorer. Detta krävde betydligt mer ansträngning, vilket resulterade i att projektet hamnade längre bakom schemat än det redan var, vilket krävde förhandlingar om merkostnaderna. Senare undersökning visade att de olika organisationerna använde olika versioner av Microsoft Explorer.
Det är kritiskt att alla intressenter som är engagerade i projektet, särskilt slutanvändarna som kommer att använda projektets resultat, deltar under hela definieringsfasen. Eftersom slutkunder ofta inte är de som beställer projektet, försummas de ofta. Under definieringsfasen ombeds kunden, som betalar för projektet, att bidra till kraven. Ändå vinner initiativet genom att bjuda in framtida användare. Som utgångspunkt är det fördelaktigt att upprätta sammankallande möten med alla intressenter under projektets definieringsfas.
Senare blev användare (unga) involverade i utvecklingen av ett pedagogiskt videospel. När spelet var nästan klart bestämde det sig för att testa det med en grupp unga människor. Deras första utvärderingar verkade vara måttliga och vänliga. Men när de trycktes erkände de att de hade tyckt att spelet var väldigt tråkigt och att de inte skulle spela det själva. Om dessa unga individer engagerade sig tidigt i projektet hade spelet utan tvekan varit en framgång. För närvarande är spelet nästan oplacerat på en internetsida.
Den definierande fasen ger en lista med behov från alla intressenter som är engagerade i projektet. Varje tillstånd har naturligtvis en invers.
Ju mer invecklat jobbet, desto mer tid och pengar kommer att krävas. Dessutom kan vissa kriterier kollidera med varandra. Nya kopieringsmaskiner avsedda att vara mer miljövänliga; de måste också uppfylla brandsäkerhetsstandarder. Bestämmelser om brandsäkerhet föreskriver användning av flamskyddsmedel, som är mindre ekologiskt vänliga. Som visas i den här bilden måste den åtgärdas.
Slutligen skapas en lista med bestämda kriterier och skickas till projektets beslutsfattare för godkännande. Efter godkännande av listan kan designprocessen påbörjas – de flesta avtal mellan klienten och projektteamet som nåddes i slutet av definitionsfasen.
Kravlistan fastställer de parametrar inom vilka projektet måste fungera.
Denna lista används för att utvärdera projektgruppen. Som ett resultat kan klienten inte lägga till ytterligare behov efter definitionsfasen.
En datorinstallation som skapats som en del av ett projekt inkluderar en ny visning på ett museum. På grund av avsaknaden av en definierande fas i projektet nåddes inga konkreta förhandlingar mellan museet och de ansvariga för installationens konstruktion. När installationens dator misslyckades halvvägs trodde museet att projektgarantin skulle täcka den. Projektgruppen intog en motsatt ståndpunkt – krävde förhandlingar mellan direktörerna för att nå en överenskommelse.
Design #
Definitionsfasens uppsättning krav kan användas för att vägleda konstruktionsbeslut. Under designfasen skapas en eller flera mönster som verkar uppfylla projektets mål. Designfasen kan producera dioramor, ritningar, flödesscheman, platsträd, HTML -skärmdesigner, prototyper, bildavtryck och UML -scheman, beroende på projektets ämne. Projektledarna använder dessa ritningar för att välja den slutliga designen för projektet. Efter det kommer utvecklingsfasen. När en design väljs kan den inte förändras under projektets efterföljande stadier som med den definierande frasen.
Uttrycket ”designavdelning” var inte lämpligt i detta fall. den hänvisade snarare till en grupp designers som samarbetade. Dessutom var alla alldeles för upptagna, inklusive avdelningschefen.
Ett projekt krävde skapandet av en rad olika design som var avgörande för projektets framgång. Designen som utvecklats av en ung designer i projektteamet. Även om designteamets chef var ytterst ansvarig för mönstren, var han aldrig närvarande vid ett projektteammöten under vilka granskning av mönstren. Den projekterande chefen bjöd honom konsekvent och skickade e -postmeddelanden till honom med teckningar av hans unga kollega, men e -postmeddelandena ignorerades. Projektledaren och den unga designern trodde felaktigt att avdelningschefen hade accepterat mönstren. Implementeringsfasen startade. När projektet var nästan klart, levererade resultatet till avdelningschefen, som blev arg och beordrade att det hela kan göras om.
