Introduksjon
Prosjekter er ofte midler til å operasjonalisere strategiske planer for en organisasjon. Prosjekter er planlagt for å utvikle produkter og tjenester, og for å få operasjonell effektivitet. Virksomheten blir stadig mer prosjektilisert og globale utgifter på prosjekter er i størrelsesorden mange milliarder dollar årlig (Williams, 2005). Årsakene er åpenbare. Prosjekter gir en mulighet til å ansette prosjektledelse praksis som fremmer effektiv og effektiv bruk av ressurser. Til tross for fremskritt i prosjektledelsesdisiplinen og yrket, tyder den felles erfaringen på at mange prosjekter feiler (Williams, 2005), noe som understreker viktigheten og behovet for å forbedre prosjektledelsesprosesser og ytelse.
generelt forsøker organisasjoner å implementere beste praksis for tradisjonell prosjektledelse-basert PÅ PMI-standarder-for å oppnå prosjektmål og for å møte kundens forventninger. Imidlertid kan ikke alle anbefalte prosesser og praksis I Project Management Body Of Knowledge (Pmbok® Guide) være relevante for hvert prosjekt. Ofte er en selektiv tilnærming fornuftig i å vedta prosjektledelsesprosesser og praksis som passer til spesifikke behov i prosjektet basert på størrelse, type, kompleksitet og bransjen der prosjektet gjennomføres. Et slikt behov for en annen tilnærming til styring AV IT-prosjekter er godt dokumentert i prosjektledelseslitteraturen.
Programvareutviklingsprosjekter står ofte overfor motstridende utfordringer med å utvikle programvareprodukter i et akselerert tempo mens de utvikler dem med en robusthet for å gjøre dem pålitelige (Boehm, 2002). IT-prosjekter, som tar sikte på å holde tritt med den raskt skiftende teknologiutviklingen, gjennomgår ofte omfangsendringer i planleggings-og implementeringsstadiene. DERFOR HAR IT-prosjekter utfordringer som er forskjellige fra tradisjonelle prosjekter. Flere justeringer og modifikasjoner til tradisjonelle prosjektledelse praksis er utviklet og praktisert FOR IT-prosjekter, og dermed innføre nye prosjektledelse metoder som agile prosjektledelse.
Agile project management metodikk—med større tilpasningsevne til ofte skiftende omfang-bruker iterativ eller faset planlegging og kontinuerlig integrasjon. Hovedprinsippet er å holde prosjektets omfang mykt. Metoden fremmer samarbeid og resulterer i økt kundetilfredshet. Agile er imidlertid ikke en komplett løsning for å utvikle programvare i et raskt tempo, samtidig som kundens krav til robusthet og pålitelighet oppfylles. I denne sammenheng anbefalte Boehm (2002) en kombinasjon av tradisjonell prosjektledelse og smidig programvareutviklingsmetode som er mulig og foretrukket. En komplementær tilnærming vil være å utvikle en risikobasert tilnærming som er skreddersydd for å beholde fordelene med både smidige og plandrevne metoder og samtidig redusere mange av svakhetene Deres (Boehm & Turner, 2003).
denne forskningsartikkelen tar sikte på å undersøke de ovennevnte forslagene (Boehm, 2002; Boehm & Turner, 2003) av en kombinert tilnærming for å håndtere IT-konsulentprosjekter, som er forskjellige FRA IT-prosjekter. IT consulting prosjekter er tenkt å administrere OG gi prosjektstøtte TIL IT-prosjekter. De er ofte initiert i offentlig sektor. It-konsulentprosjekter er ikke programvareutviklingsprosjekter; snarere gir de prosjektstøtte TIL IT-prosjekter.
i denne studien tar vi sikte på å utvikle en forståelse av hvordan smidig prosjektledelsespraksis er relevant for IT-konsulentprosjekter. Målene med studien er å identifisere fordelene ved å bruke agile project management, dets egnethet, og hvilke aspekter av tradisjonelle prosjektledelse som kan kombineres med agile project management FOR IT-konsulentprosjekter for å forbedre prosjektets ytelse. I neste avsnitt, ved hjelp av en omfattende litteraturgjennomgang av agile prosjektledelsesmetodikk, har vi identifisert fremtredende trekk ved agile-metoden og deres unike tilnærming til styring av prosjekter i forhold til tradisjonell prosjektledelse. Litteraturgjennomgangen har bidratt til å utvikle en forståelse av nøkkelbegrepene og fordelene ved å bruke smidig programvareutvikling. Videre, basert på funn fra litteraturgjennomgangen, har vi utviklet og presentert en forskningsmetode ved hjelp av et strukturert spørreskjema for å utvikle en forståelse AV IT-konsulentprosjekter. Dataanalyse og diskusjon, presentert senere, gir viktig innsikt og funn av studien. Vi avslutter papiret med våre forskningsresultater og anbefalinger FOR IT-konsulentprosjekter.
Litteraturgjennomgang
Tradisjonell prosjektledelsespraksis, som drives av omfattende planlegging, kan brukes når prosjektspesifikasjoner er klart definert. På den annen side, når spesifikasjoner er gjenstand for hyppige endringer i løpet av prosjektets levetid, kan den tradisjonelle tilnærmingen til å styre prosjekter ikke fungere effektivt. Programvareutviklingsprosjekter ofte er unnfanget med minimum spesifikasjoner, forårsaker hyppige endringer i disse spesifikasjonene under prosjektgjennomføring. Videre er programvareprosjektutviklingsvarigheter korte. Smidige metoder, sammenlignet med tradisjonelle prosjektledelsesteknikker, er egnet for programvareutviklingsprosjekter på grunn av disse prosjektets korte varighet for utvikling (Hanakawa & Okura, 2004).
generelt lover ulike programvareutviklingsmetoder som smidig prosjektledelse økt kundetilfredshet, lavere feilfrekvenser, raskere utviklingstider, og de tjener som en løsning på raskt skiftende prosjektkrav (Boehm & Turner, 2003). I motsetning til agile project management bruker en stage-gate-modell en arbeidsprosess fra konseptidee til et produkt som til slutt leveres. Denne modellen utvikler prosjektledelseslivssyklusfaser basert på ulike stadier av produktutvikling for styring av prosjekter. Et viktig skille mellom en stage-gate modell og agile prosjektledelse er at de tidligere forsøk på å minimere kravene endres slik at produktet er ferdig i tide (Karistrom & Runeson, 2005). EN annen metode for å utvikle programvare ER SCRUM, som er et sett med prosjektledelsesprinsipper som bruker små tverrfunksjonelle og selvstyrte lag (Schatz & Abdelshafi, 2005). SCRUM krever at hvert teammedlem og produkteier jobber sammen i begynnelsen av hvert utviklingselement, og metodikken fungerer som en wrapper rundt eksisterende utviklingsprosesser. Derfor hevdet Schatz Og Abdelshafi at SCRUM ikke vil ha en grunnlinjeplan for å måle prosjektets suksess. Imidlertid vurderes agile prosjektledelse for denne studien på grunn av sin større fleksibilitet og tilpasningsevne til programvareutviklingsprosjekter.
i tillegg til fordelene som er omtalt ovenfor, er agile metodikk anvendelig for turbulente og stadig skiftende miljøer (Highsmith & Cockburn, 2001). Videre legger agile-metoden vekt på tilpasningsevne til marked, teknologi og prosess (Mellor, 2005). Agile-metoden er en tilnærming som vil fokusere på viktige funksjoner først, og som et resultat vil den se etter tidlig tilbakemelding På funksjoner (Karistrom & Runeson, 2005). Når viktige funksjoner er identifisert, vil prosjektlederen sørge for at det ikke er noen forsinkelser. Karistrom og Runeson indikerte at agile-prosessen ville unngå å kramme ressurser, faste planer og støtte langsiktige planer.
agile metodikk er imidlertid ikke egnet for alle programvareutviklingsprosjekter. Med Henvisning Til Scott Ambler, utvikleren av agile method, anbefalte Boehm (2002) tradisjonell, plandrevet prosjektledelsesmetodikk for forsikringsprogramvare som livskritiske systemer.
agile-metoden, på grunn av sitt krevende prosjektmiljø preget av kaos og usikkerhet, trenger prosjektteam bestående av talentfulle mennesker for å møte utfordrende behov og krav. Siterer en forskningsstudie Av Constantine (2001), boehm (2002) foreslo at smidige metoder krever svært dyktige mennesker. Videre er agile ikke egnet for større lag (Highsmith & Cockburn, 2001), da det krever tett koordinert samarbeid for å lykkes, og lag med mer enn 15 eller 20 utviklere øker vanskeligheten med å administrere prosjektet (Constantine, 2001).
det er åpenbart at agile-metoden benytter sammenhengende lag (Karistrom & Runeson, 2005). Karistrom og Runeson identifiserte flere smidige funksjoner, for eksempel små og håndterbare oppgaver, kontinuerlig integrasjon og automatisk testing. Agile prosjektteam kjennetegnes derfor av god intern kommunikasjon, høyere kvalitet og en følelse av kontroll (Karistrom & Runeson). De ser imidlertid for seg potensiell isolasjon for agile-teamet.
når det gjelder kommunikasjon, dokumentbasert styring av fremdrift og kvalitetskontroll, samsvarer en vanlig praksis i tradisjonell prosjektledelse ikke med smidig programvareutviklingsmetode (Hanakawa & Okura, 2004). Ansikt-til-ansikt interaksjon for kontinuerlig omstilling av utviklingsmål er vanligvis foretrukket i smidige metoder (Melnik & Mauer, 2004). Melnik og Mauer fremhevet forskjellen mellom tradisjonelle og smidige metoder, og foreslo at kort kunnskapsoverføring og direkte kommunikasjon og samarbeid er foretrukket i programvareutvikling, i motsetning til de tradisjonelle prosjektledelsespraksis, hvor lange kunnskapsoverføringskjeder brukes, som ofte er utsatt for forvrengning og tap av informasjon.
en av de viktige forskjellene mellom plandrevet tradisjonell prosjektledelsespraksis og smidige metoder er at smidige metoder fanger smidigheten fra prosjektteamets stilltiende kunnskap i stedet for den eksplisitte kunnskapen, ofte brukt i form av dokumenter og planer i tradisjonell prosjektledelse (Boehm, 2002).
En annen forskjell er mengden og typen dokumentasjon som er opprettet for prosjekter. Plandrevet tradisjonell prosjektledelse legger vekt på detaljert planlegging, overvåking og kontroll av dokumenter. Design rasjoner, dokumenter som uttrykker grunner og begrunnelser, er opprettet ved hjelp av en svært automatisert prosedyre og disse design rasjoner tjene som smidig dokumentasjon (Sauer, 2003).
Coram og Bohner (2005) har identifisert felles trekk ved agile-metoden: samarbeid, små lag, korte utgivelsesplaner, tidsboksing og konstant testing. Prosjektlederen er ansvarlig for å sikre et svært samarbeidsmiljø. For dette formålet oppfordrer agile-metoden små lag og noen få undergrupper per prosjekt for å fremme samarbeid. Som en konsekvens vil agile-metoden sannsynligvis kreve mindre prosess og planlegging for å koordinere teamaktiviteter. Agile-metoden bruker også korte utgivelsesplaner, som kan variere fra to uker til seks måneder. Tid boksing er et konsept som pålegger fast varighet for utgivelsen av prosjektet leveranser, noe som bidrar til å redusere gull og omfang krype. Konstant testing sikrer produktkvalitet og integrasjon. Videre foreslo Coram Og Bohner at prosjektledere må spore fremgang og ta forretningsbeslutninger med vekt på å reagere på endring i stedet for å følge en bestemt plan.
tidsboksing fører til uforutsigbar planlegging etter beste gjetning, og faste datoer kan gi uventede overraskelser i utviklingsfasen (Patton, 2003). Et annet resultat av denne iterative prosjektplanleggingsprosessen er at agile-metoden ikke kan overvåke fremdriften basert på prosent fullført (Patton, 2003).
involvering av små undergrupper i planlegging vil resultere i motiverte programvareutviklingsingeniører; tekniske problemer tas opp tidlig i prosjektet, og det vil være liten motstand i gjennomføringen (Karistrom & Runeson, 2005). I tillegg vil definere prosjektomfang med en smidig tilnærming resultere i kostnadsreduksjon(Mcgovern, 2002). Agile-metoden bruker kravbasert planlegging, og vil også la oss kontrollere omfanget (McGovern).
Bruke alle referanser og diskusjoner så langt og andre (Little Greene, Phillips, Pilger & Poldervaart, 2004; Little, 2005; Abrahamsson, Warsta, Siponen, & Ronkainen, 2003; Ilieva, Ivanov, & Stefanova, 2004; Lindvall, 2004), Tabell 1 gir en oppsummering sammenligning mellom tradisjonell og smidig prosjektledelse praksis.
Tabell 1: Sammenligning Mellom Agile Og Tradisjonell Prosjektledelse
| Prosjektfase | Tradisjonell | Agile |
| Innvielse |
|
|
| Planlegging |
|
|
| Execution |
|
|
| Overvåking og Kontroll |
|
|
| Avslutning |
|
|
Sammendrag Av Litteratur Gjennomgang
Agile prosjektledelse metodikk er ofte brukt for programvareutviklingsprosjekter. Den har større tilpasningsevne til ofte skiftende omfang. Som en konsekvens bruker agile prosjektledelse iterativ eller faset planlegging og kontinuerlig integrasjon gjennom hele prosjektets levetid. Nøkkelprinsippet i agile prosjektledelse er å holde prosjektets omfang mykt. Agile project management method er forskjellig fra en tradisjonell prosjektledelse metode ved å tildele betydning til faktorer som tradisjonelt anses uviktig. Agile tildeler relativt høyere betydning for:
- Enkeltpersoner og interaksjoner over prosesser og verktøy
- prosjektgjennomføring over omfattende dokumentasjon
- kundesamarbeid over kontraktsforhandlinger
- Respons på endring over en prosjektplan
agile-metoden legger vekt på fleksibilitet for å møte prosjektets behov. Videre er det avhengig av tilbakemeldinger fra kunder for å starte endringer i en prosjektplan. Metoden bruker tilnærmingen til å identifisere de riktige sluttbrukerne og deres mål for å formulere prosjektleveranser og for å møte de utøvende behovene til forretningsprosessene. Fordelene ved å bruke agile-metoden inkluderer økt kundetilfredshet, lavere feilrater og raskere utviklingstider. I tillegg er agile-metoden et svar på raskt skiftende krav, da den bruker tidlig tilbakemelding på teknologifunksjoner i prosjektleveranser. Den smidige metoden sikrer at kravene ikke er proppet. Viktige trekk ved agile-metoden er effektiv kommunikasjon i og utenfor prosjektteamet, og demonstrert fleksibilitet i å legge til flere krav.
disse fordelene vil hjelpe organisasjoner med å gi bedre kundeservice. Videre er de relevante i dagens økonomi der globalisering og en fri markedsføringsfilosofi påvirker kundens oppfatninger om å øke forventningene til å levere produkter og/eller tjenester raskere, billigere og bedre.
den smidige metoden er imidlertid ikke uten mangler, som det kan ses i Tabell 1. Ofte skiftende omfang fører til vanskeligheter med å overvåke prosjektets fremgang. Det er heller ikke lett å fange taus kunnskap i form av erfaringer. Omfangsendringskontroll, dokumentasjon, omfattende plan, kvalitetsstyring og risikostyring er viktige fordeler med tradisjonell prosjektledelse som vi kan bli fratatt ved bruk av smidig metode.
Forskningsmetodikk
vi brukte både personlige intervjuer og spørreskjemaer til å samle inn dataene. Vi utviklet et strukturert spørreskjema bestående av to seksjoner. Den første delen ble designet for å fange opp detaljer om prosjektet og dets egenskaper. Denne delen består av 13 spørsmål, som er relatert til prosjektet demografi og prosjektledelse praksis. De ble presentert for deltakerne i studien med mulighet til å gi åpne svar når det var nødvendig.
den andre delen fokusert på prosjektledelse praksis uttalelser, og deltakerne ble bedt om å svare på disse uttalelsene på fempunkts skala med 1 betegner » sterkt uenig «og 5 betegner» sterkt enig.»Følgende uttalelser ble brukt som adresserer viktige vanlige prinsipper for prosjektledelsespraksis, samt tjener til å kontrastere tradisjonelle og smidige prosjektledelsespraksis.
- kriteriene for måling av prosjektsuksess er basert på prosjektets mål og mål.
- prosjektet drives av krav.
- prosjektet kan tilpasses til endring.
- etter din mening er prosjektledelsesarbeidet oppnådd forventede resultater
- Ansikt-til-ansikt-interaksjoner og kortere kommunikasjonskjeder gitt større betydning enn prosesser og verktøy.
- Team fokus er på prosjektgjennomføring over omfattende dokumentasjon.
- kundesamarbeid over kontraktsforhandlinger fungerer bedre for teamet ditt.
- prosjektet har et veldefinert prosjektomfang.
- prosjektledelsespraksis følg pmbok-veiledningen prosjektets livssyklus.
- Iterativ eller faset prosjektplanlegging følges for prosjektet.
- prosjektet har dokumentasjonskrav som etterlevelse av standarder SOM ISO9000, OMB 300.
- uat-prosedyrer (User Acceptance Testing) følges gjennom hele prosjektet.
- prosjektlederen er bemyndiget til å ta prosjektrelaterte beslutninger uten kundeintervensjon.
Svar på disse uttalelsene analyseres i forbindelse med de aktuelle spørsmålene fra det første settet med 13 spørsmål. Sammen ga svar på begge seksjonene detaljert forståelse av prosjektet for meningsfylt analyse.
Studieresultater
spørreskjemaet ble strukturert for å fange data på 20 it-konsulentprosjekter, som var i gang på tidspunktet for forskningen. Av prosjektene er 65% tids – og materialkontraktstypeprosjekter, og de resterende er fast fastpris (ffp) type. Blant tid og materielle prosjekter har 55% en prosjektvarighet på mer enn to år.
de fleste prosjektteamene er små: bare 15% har 10 eller flere medlemmer. Når det gjelder kommunikasjon mellom prosjektgruppemedlemmene, har 60% av respondentene kun brukt formell kommunikasjon for prosjektbehov; 30% brukte både formell og uformell kommunikasjon, og de resterende 10% var avhengige av uformelle metoder alene.
en av to respondenter indikerte at deres prosjekter har brukt en prosjektplan. I et relatert spørsmål, av de prosjektene som ikke hadde en prosjektplan, brukte 80% heller ikke iterativ planlegging.
Omfangsendring er et viktig aspekt ved denne studien. Av prosjektene har 70% opplevd omfangsendring minst en gang. Av de som opplevde prosjektomfang, opplevde 60% det mer enn to ganger. Mens klienten bestemmer omfangsendringen, kan konsulenten—med samtykke fra klienten—inkludere kvalitetskontrollplanen i prosjektstyringsplanen. På spørsmål om de har en kvalitetskontroll plan for sitt prosjekt, 65% av respondentene indikerte at de ikke brukte en kvalitetskontroll plan.
Resultater Diskusjon Og Analyse
Forskningsresultater ble analysert ved å nøye undersøke enhver sammenheng mellom et spørsmål og alle andre spørsmål først for å validere resultatene og for det andre å utvikle effektive styringsstrategier. I tillegg ble disse resultatene analysert med sikte på å undersøke hvilke smidige og tradisjonelle prosjektledelsespraksis som kan brukes i kombinasjon for å utvikle en robust prosjektledelsestilnærming for IT-konsulentprosjekter.
Prosjektsuksessekriterier Basert På Dens Mål Og Mål
et prosjekt anses som vellykket når det oppfyller sine mål og mål. Bare 60% av respondentene var enige med uttalelsen, » kriteriene for måling av prosjektsuksess er basert på prosjektets mål og mål.»Omtrent 30% av respondentene var uenige . Videre analyser har vist at årsaken til uenighet var at disse prosjektene opplevde stadig skiftende forhold og krav, eller at klienten ikke var klar over prosjektet. Til slutt opplevde disse prosjektene hyppig omfangsendring. I et spesielt tilfelle endret prosjektets mål og mål.
det er interessant å merke seg at det ikke er noen sammenheng mellom det faktum at et prosjekts suksesskriterier er avledet fra dets mål og omfangsendring, prosjekttype og eksistensen av en prosjektplan. Det å utlede prosjektkriterier fra organisasjonens strategiske plan har med andre ord ingen betydning for omfangsendring og om prosjektet har en plan.
Prosjektkrav
vanligvis utvikles en detaljert prosjektplan etter at prosjektsponsorens krav er tydelig identifisert. Prosjektplanutvikling og gjennomføring bør i prinsippet drives av disse kravene. Derfor ville man forvente at prosjektledere ville være enige med uttalelsen, » prosjektet er drevet av krav .»Studieresultater viser at bare 60% av respondentene sa at deres prosjekter er drevet av krav. Om lag 20% av respondentene som var uenige med uttalelsen, indikerte at prosjektene deres utføres uten å bruke en prosjektplan.
Om lag 20% av respondentene som var nøytrale som svar på denne uttalelsen, er prosjektledere som ikke opplevde noen omfangsendring i prosjektene sine. Alle andre respondenter, de som er enige eller uenige med uttalelsen, har opplevd omfangsendring minst en gang i sine nåværende prosjekter.
generelt, hvis et prosjekt ikke er implementert i henhold til planen, kan vi anta at kravene ikke er identifisert eller prosjektkravene forventes å endres under gjennomføringen. I denne studien kan vi imidlertid ikke etablere en slik sammenheng mellom «gjennomføring av prosjektet uten å bruke prosjektplanen «og» prosjektet drives ikke av krav», fordi bare 50% av de som var enige med den andre uttalelsen, også har klart prosjekter uten å bruke en plan.
Tilpasningsevne Til Å Endre
Atten Av 20 prosjekter har svart på endringer i prosjektet vellykket. Tilpasningsevne til endring regnes som en primær egenskap for et prosjekt for å være kandidat for å bruke agile project management methodology. IT-konsulentprosjekter representert i denne studien har vist at de har tilpasningsevne til å håndtere omfangsendring.
Prosjektledelse Oppnådde Forventede Resultater
Resultater tyder på at kunden er fornøyd med resultatet i de fleste prosjektene (70%). Disse svarene var imidlertid ikke knyttet til svar på andre viktige spørreundersøkelsesspørsmål om prosjektets fremdrift og produkt utviklet fra prosjektlederens perspektiv. Grunner er åpenbare. Prosjekter opplevde fortsatt tids-og kostnadsoverskridelser. Selv om sluttresultatet i å levere programvareproduktet er tilfredsstillende, ble prosjektledelsesprosesser ikke utført med hell. Slutningen kan være at vedta tradisjonelle prosjektledelse praksis som å utvikle milepæler, overvåking og kontroll ville ha bidratt til å administrere prosjektet vellykket.
Viktigheten Av Ansikt-Til-Ansikt Kommunikasjon versus Prosesser
Kommunikasjon er nøkkelen til å forstå roller, ansvar, retningslinjer og prosedyrer knyttet til prosjekter, og oppmuntre til samarbeid. Til slutt fører kommunikasjon til et sammenhengende prosjektteam og oppfordrer teammedlemmer til å samarbeide og delta i beslutningsprosesser. Syv av ti prosjektledere som deltok i studien var enige om at ansikt-til-ansikt-interaksjoner og kortere kommunikasjonskjeder ble gitt større betydning enn prosesser og verktøy.
Resultatene viser en sterk sammenheng mellom viktigheten av ansikt-til-ansikt-kommunikasjon og kommunikasjonsmidler blant prosjektgruppemedlemmene. De som var uenige om at ansikt-til-ansikt-kommunikasjon er viktigere enn prosjektprosesser, har brukt uformell kommunikasjon blant prosjektgruppemedlemmene, mens de som anså ansikt-til-ansikt-kommunikasjon som viktigere, har brukt både formell og uformell kommunikasjon.
Fokus På Prosjektgjennomføring Over Dokumentasjon
Prosjektdokumentasjon blir ofte oversett, og organisasjoner blir derfor fratatt viktige erfaringer i prosjektplanlegging og gjennomføring. Med tanke på at alle prosjektene som er representert i denne studien er føderale regjeringsprosjekter, er det interessant å merke seg at 70% av de responderende prosjektlederne var enige om at deres lag fokuserte på prosjektgjennomføring sammenlignet med å skape omfattende dokumentasjon. I noen få tilfeller der prosjektledere har vurdert at dokumentasjon er viktigere enn prosjektgjennomføring, viste videre undersøkelser at kunden var ubesluttsom om prosjektet i alle disse tilfellene.
Kundesamarbeid Over Kontraktsforhandlinger
Kontraktsforhandlinger er en viktig del av eksterne prosjekter. Under forhandlingene ville begge parter fokusere på å beskytte sine egne interesser. Forhandling av kontrakten kan finne sted på ulike stadier av prosjektet. Det er ønskelig å håndtere disse problemene gjennom samarbeid, spesielt under prosjektgjennomføring; ellers vil det føre til problemer som forlengelse av kontrakten. Gitt at alle prosjektene som er representert i denne studien er kontrakter, er det oppmuntrende å merke seg at mer enn halvparten av de responderende prosjektlederne (60%) anser kundesamarbeid for å være viktigere enn kontraktsforhandlinger. De foreslo at samarbeid fungerer bedre for prosjektteam.
der det var uenighet, noe som innebar at samarbeid ikke er like viktig som forhandling, var to interessante fakta knyttet til disse prosjektene. Alle andre prosjekter brukte direkte kontakt som kommunikasjonsmiddel med prosjektets interessenter, men disse prosjektene brukte kommandokommunikasjon og kunden var også ubesluttsom om prosjektet. Begge disse faktorene innebærer vanskelige forhold for samarbeid.
Prosjekt Og Et Veldefinert Prosjektomfang
Prosjekter er vanligvis forbundet med usikkerhet og ukjente faktorer, noe som fører til tvetydighet. Som en konsekvens kan ikke detaljert omfang og spesifikasjoner utvikles i prosjektets tidlige fase. Omfanget av prosjektet endres kontinuerlig gjennom hele prosjektet. Noen ganger kan de opprinnelige målene for prosjektet også endres. Av de undersøkte prosjektene har 40% veldefinert omfang, mens en annen 45% ikke gjorde det.
imidlertid opplevde 80% av prosjektene omfangsendring minst en gang, noe som validerer argumentene som tidligere ble presentert.
Prosjektledelsespraksis og Pmbok® Guide Prosjektlivssyklus
Pmbok hryvnias Guide har utviklet en omfattende livssyklusprosess for prosjektledelse; den er uttømmende og omfattende. Det er imidlertid ikke nødvendig at hver prosess I pmbok® guide prosjektledelse livssyklus brukes på hvert prosjekt. Vedtaket bør være prosjektspesifikt. Som forventet fulgte 45% av prosjektlederne prosjektledelsespraksis i pmbok® Guide prosjektets livssyklus, og en annen 45% gjorde det ikke.
Iterativ Eller Faset Prosjektplanlegging
Omfangsdefinisjon og prosjektstyringsplan er en del av prosjektplanen. Som nevnt tidligere kan ikke detaljert utvikling av omfang og spesifikasjoner utvikles tidlig i prosjektet. Følgelig endres prosjektets omfang kontinuerlig gjennom hele prosjektet, noe som understreker betydningen av iterativ eller faset prosjektplanlegging, en viktig egenskap ved smidig metode. På spørsmål om iterativ eller faset prosjektplanlegging følges for prosjektet eller ikke, svarte halvparten av respondentene ja, og bare 15% fulgte ikke iterativ prosjektplanlegging. Det er interessant å merke seg at alle de som var uenige med praksis med iterativ prosjektplanlegging ikke hadde en prosjektplan i utgangspunktet.
Dokumentasjon Og Overholdelse Av Standarder
Prosjektdokumentasjon tjener som referanse for analyse av historiske data og hjelper organisasjoner kontinuerlig med å forbedre prosjektledelsesprosesser og utvikle standarder. Dokumentasjonen vil også bidra til å identifisere erfaringer og å endre prosjektstyringssystemer som vil føre til prosjektledelse modenhet. OMB300 OG ISO9000 er veiledere i utformingen av prosjektdokumentasjonssystemer. Spesielt er mange offentlige prosjekter pålagt å følge OMB300-retningslinjene. Av respondentene sa 80% AT IT-prosjektene de ledet hadde dokumentasjonskrav som overholdelse av standarder SOM ISO9000 og OMB300. Disse kravene til it-konsulentprosjektene gjelder imidlertid i begrenset grad.
Testprosedyrer For Brukeraksept
kundetilfredshet er det primære målet for kvalitet og suksess for prosjektleverbare varer. Derfor anses brukerakseptstestprosedyrer som viktige. Selv i tilfelle av mindre konkrete prosjektleveranser som service, er det underliggende målet for prosjektsuksess kundetilfredshet. Det er imidlertid subjektivt. Bare 30% av respondentene sa at de fulgte brukerakseptstestprosedyrer gjennom hele prosjektet, og 45% av respondentene gjorde det ikke.
Myndiggjøring for Å Ta Prosjektrelaterte Beslutninger
generelt bør prosjektledere gis frie hender til å ta prosjektrelaterte beslutninger uten kundeintervensjon, når disse beslutningene ikke har noen stor innvirkning på prosjektets omfang eller prosjektleveranser. Bare 15% er enige om at prosjektlederen er bemyndiget til å ta prosjektrelaterte beslutninger uten kundeintervensjon. Om lag 40% forblir nøytrale, og de resterende 45% sa at prosjektlederen ikke hadde denne kraften. Gitt at disse prosjektene er eksterne og offentlige prosjekter, gir disse resultatene mening.
Konklusjon
våre studieresultater viser at flertallet av prosjektene er drevet av krav. Nesten alle prosjektene som er representert i denne studien viste at de er tilpasningsdyktige til endring. Uformell kommunikasjon er viktigere enn formelle prosesser og systemer. Med tanke på at prosjekter i studien er relatert til regjeringens arbeid, viser resultatene at prosjektgruppen fokuserte på prosjektgjennomføring over omfattende dokumentasjon. I tillegg fungerer kundesamarbeid over kontraktsforhandlinger bedre for prosjektteam. Hyppig endring av prosjektomfang betyr betydningen av iterativ eller faset prosjektplanlegging; en viktig egenskap ved smidig prosjektledelse. Gitt at ALLE IT-konsulentprosjektene som er representert i denne studien, er kontrakter, oppfordrer studieresultatene formelt til å vedta smidig metodikk for IT-konsulentprosjekter og kombinere dem med tradisjonelle prosjektledelsespraksis som plandrevet milepælutvikling og overvåking, brukerakseptprosedyrer og kvalitetsstyringspraksis.
egnetheten til agile-metoden for prosjekter er kontraktsmessig forpliktelse knyttet til dokumenter om prosjektplanlegging, overvåking og kontroll. Prosjekter knyttet til den føderale regjeringen har vanligvis betydelige dokumentasjonskrav, for eksempel overholdelse av standarder SOM ISO9000 OG OMB300; vi bør være forsiktige med å endre agile-metoden for slike prosjekter.
utfordringen er å opprettholde smidigheten, den raske responsen på endring, fleksible og enkle planer, kontinuerlig integrasjon og andre fordeler med agile-metoden, samtidig som du inkorporerer noen av de omfattende prosessene i tradisjonell prosjektledelsespraksis.