2.0 faser af projektimplementering (del 1)

Table of contents

Indvielse #

Projektets begyndelse kaldes startfasen. I denne fase udforskes og udvikles projektets idé. Denne fases mål er at se, om projektet virkelig kan gennemføres. Der træffes valg om, hvem der skal lede indsatsen, hvilken organisation der deltager, og om virksomheden får nok støtte fra de involverede.

Dette trin kræver, at den eksisterende eller fremtidige projektleder udarbejder et forslag, der beskriver de ovennævnte punkter. Forretningsplaner og tilskudsansøgninger er eksempler på denne form for projektforslag. Projektets potentielle sponsorer vurderer ansøgningen og giver den nødvendige finansiering, hvis den godkendes. Projektet starter formelt efter godkendelse. Skal behandles følgende spørgsmål i begyndelsesfasen:

  • Hvorfor dette projekt?
  • Er det fysisk muligt?
  • Hvad er de ønskede resultater?
  • Hvad er projektets grænser (hvad er inkluderet i projektets omfang)?

Evnen til at sige ‘nej’ er en kritisk egenskab ved en projektleder. Når enkeltpersoner bliver begejstrede for et projekt, har det en tendens til at vokse i omfang. ‘Mens vi er ved det, kan vi lige så godt …’ er den bagvedliggende idé. Projekter, hvortil der tilføjes yderligere mål, og projekter, der fortsætter med at vokse, løber næsten garanteret for sent og vil sandsynligvis ikke opfylde deres oprindelige mål.

Det første trin er at etablere en forbindelse mellem alle projektets interessenter. Urealistiske forventninger til projektets resultat kan undgås, hvis omfanget er godt forstået. For at komme i gang skal du etablere en forbindelse mellem de forskellige involverede personer. Det er vigtigt at have et solidt greb om dets omfang.

Den metode, der er valgt til en bestemt slags projekt, har en betydelig indvirkning på dens resultat. F.eks. Kan en forsknings- og udviklingsindsats levere en rapport, der vurderer en applikations tekniske levedygtighed. Et projekt, der resulterer i at udvikle en prototype, omfatter alle applikationens funktioner. Alligevel skal de ikke være egnede til brug i et specifikt miljø (f.eks. Af hundredvis af brugere). Et projekt, der producerer et fungerende produkt, skal også behandle problemer med vedligeholdelse, dokumentation og applikationsadministration.

Mange misforståelser og tvister opstår på grund af de mennesker, der engagerer sig projektledelse er uklare på disse punkter. Kunder kan forvente et funktionelt produkt, mens projektteamets medlemmer mener, at de skaber en prototype. Selvom en sponsor måske tror, at projektet ville resultere i et nyttigt stykke software, skal teammedlemmer først afgøre, om konceptet er teknisk levedygtigt.

Definition #

Efter den accepterede initieringsprojektplan startede projektet den anden fase: definitionsfasen. Denne fase specificerer så præcist som muligt de krav, der er forbundet med et projekts resultat. Denne fase indebærer bestemmelse af forventningerne til alle parter, der er involveret i projektets udvikling. Hvor mange filer kræves til arkivering? Skal metadataene være i formatet Data Documentation Initiative (DDO), eller ville Dublin Core (DC) være tilstrækkelig? Er filer tilladt i deres originale format eller kun dem, der overholder ‘Foretrukne standarder’? Er det indskyderens pligt at garantere, at et datasæt behandles korrekt i arkivet, eller er det arkivarens ansvar? Hvilke garantier vil blive givet om projektets resultat? Listen over forespørgsler kan fortsætte på ubestemt tid.

Det er afgørende at fastlægge behov så tidligt som muligt i processen.

Wijnen (2004) fastlægger følgende typer projektbehov som hukommelseshjælp:

  • Forudsætninger
  • Krav til funktionalitet
  • Krav til funktionalitet
  • Designbegrænsninger

Forudsætninger danner de rammer, som projektet skal finde sted i.

Lovgivning, regler for arbejdsforhold og godkendelsesprocedurer er alle eksempler. Disse kriterier er uforanderlige inde i projektet.

Det er vigtigt at huske, at kravspecifikationer er dem, der har at gøre med kvaliteten af det endelige output – tekniske specifikationer relateret til, hvordan projektets resultater vil blive brugt. F.eks. Skal antallet af fejl reduceres med 90%, efter at et softwareprojekt er afsluttet. Designrestriktioner er derimod projektspecifikke krav. Farlige kemikalier og udenlandske partnere med tvivlsomme arbejdsstandarder kan ikke medtages i projektet som eksempel.

Under defineringsfasen af et projekt, der omfattede opbygning af en webapplikation til et konsortium af større organisationer, blev der ikke truffet nogen beslutninger om den browser, som programmet ville understøtte. Konsortiet troede, at det ville være Microsoft Explorer, da det var ‘alles browser.

Udviklerne byggede applikationen på Firefox, fordi de allerede kendte browseren og havde flere særligt nyttige funktioner under hele udviklingen. Fordi de fleste websteder designet til Firefox også fremstår flotte på Explorer, var ændringen først umærkelig. Men mod projektets konklusion begyndte klienten at protestere mod, at webstedet ‘ikke så godt ud.’ Programmørerne, der fik adgang til webstedet via Firefox, var forvirrede over klagen.

Da det blev klart, at de to browsere var inkompatible, svarede programmører defensivt: ‘Kan de ikke installere Firefox? Det er jo gratis «. På den anden side forpligtede organisationerne statslige systemadministratorer, der af en eller anden grund nægtede at installere Firefox sammen med Explorer.

Selvom de ønskede at installere det, ville proceduren have været lang, og der ville have været ekstra udgifter forbundet med den tid, som systemadministratorer brugte på jobbet. Endelig fastslået, at applikationen skulle tilpasses Explorer. Dette krævede betydeligt mere indsats, hvilket resulterede i, at projektet faldt længere bagud end planlagt, end det allerede var, hvilket nødvendiggjorde forhandlinger om meromkostningerne. Senere undersøgelse viste, at de forskellige organisationer brugte forskellige versioner af Microsoft Explorer.

Det er kritisk, at alle interessenter, der er involveret i projektet, især de slutbrugere, der vil udnytte projektets resultat, deltager i hele defineringsfasen. Fordi slutkunder ofte ikke er dem, der bestiller projektet, negligeres de ofte. I løbet af definitionsfasen bliver kunden, der betaler for projektet, bedt om at bidrage til kravene. Ikke desto mindre vinder initiativet ved at invitere fremtidige brugere. Som udgangspunkt er det fordelagtigt at etablere indkaldelsesmøder med alle interessenter i hele projektets defineringsfase.

Senere blev brugere (unge) involveret i udviklingen af et pædagogisk videospil. Da spillet var næsten klart, besluttede det at teste det med en gruppe unge mennesker. Deres første evalueringer syntes at være moderate og mindelige. Men når de blev skubbet, erkendte de, at de havde fundet spillet ‘meget kedeligt’ og ‘ikke ville spille det selv. Hvis disse unge personer engagerede sig tidligt i projektet, ville spillet uden tvivl have været en succes. I øjeblikket er spillet næsten ikke placeret på et internetwebsted.

Den definerende fase producerer en liste over behov fra alle interessenter, der er involveret i projektet. Hver tilstand har naturligvis en omvendt.

Jo mere indviklet jobbet er, jo mere tid og penge skal der til. Derudover kan nogle kriterier kollidere med hinanden. Nye kopimaskiner beregnet til at være mere miljøvenlige; de skal også opfylde brandsikkerhedsstandarder. Forordninger vedrørende brandsikkerhed pålægger brug af flammehæmmende materialer, som er mindre miljøvenlige. Som vist på dette billede, skal det behandles.

Endelig oprettes en liste over bestemte kriterier og forelægges projektets beslutningstagere til godkendelse. Efter godkendelse af listen kan designprocessen begynde – de fleste aftaler mellem klienten og projektteamet nået ved slutningen af definitionsfasen.

Kravlisten fastlægger de parametre, inden for hvilke projektet skal fungere.

Denne liste bruges til at vurdere projektteamet. Som et resultat kan klienten ikke tilføje yderligere behov efter definitionsfasen.

En computerinstallation, der er oprettet som en del af et projekt, inkluderer en ny visning på et museum. På grund af fraværet af en definerende fase i projektet nåede der ingen konkrete forhandlinger mellem museet og de ansvarlige for installationens konstruktion. Da installationens computer mislykkedes halvvejs, mente museet, at projektets garanti ville dække det. Projektteamet indtog en modsat holdning – krævede forhandlinger mellem direktørerne for at nå til enighed.

Design #

Definitionsfasens kravsæt kan bruges til at styre designbeslutninger. I designfasen oprettes et eller flere designs, der ser ud til at opfylde projektets mål. Designfasen kan producere dioramaer, tegninger, flowdiagrammer, webstedstræer, HTML -skærmdesign, prototyper, billedindtryk og UML -skemaer afhængigt af projektets emne. Projektlederne bruger disse tegninger til at vælge det endelige design til projektet. Herefter kommer udviklingsfasen. Når et design er valgt, kan det ikke ændre sig i hele projektets efterfølgende faser som med den definerende sætning.

Udtrykket ‘designafdeling’ var ikke passende i dette tilfælde; den henviste snarere til en gruppe designere, der samarbejdede. Derudover havde alle alt for travlt, inklusive afdelingens chef.

Et projekt krævede oprettelse af en række designs, der var afgørende for projektets succes. Designene udviklet af en ung designer i projektteamet. Selvom designteamets leder i sidste ende var ansvarlig for designene, var han aldrig til stede ved et projektteammøder, hvorunder designet blev gennemgået. Den projekterende chef inviterede ham konsekvent og sendte ham mails med tegninger af sin unge kollega, men e -mails blev ignoreret. Projektlederen og den unge designer mente forkert, at afdelingslederen havde accepteret designet. Implementeringsfasen startede. Da projektet var næsten færdigt, leverede resultatet til afdelingslederen, som blev rasende og beordrede, at det hele kan laves om.