introduktion

projekt är ofta medel för att operationalisera strategiska planer för en organisation. Projekt planeras för att utveckla produkter och tjänster och för att få operativ effektivitet. Verksamheten blir alltmer projektiserad och globala utgifter för projekt är i storleksordningen många miljarder dollar årligen (Williams, 2005). Skälen är uppenbara. Projekt ger möjlighet att använda projektledningspraxis som främjar effektiv och effektiv resursanvändning. Trots framsteg inom projektledningsdisciplin och yrke tyder den gemensamma erfarenheten på att många projekt misslyckas (Williams, 2005), vilket understryker vikten och behovet av att förbättra projektledningsprocesser och prestanda.

i allmänhet strävar organisationer efter att implementera bästa praxis för traditionell Projektledning—baserat på PMI—standarder-för att uppnå projektmål och uppfylla kundens förväntningar. Dock kan inte alla rekommenderade processer och praxis i Projektledningsorganet (PMBOK-guiden) vara relevanta för varje projekt. Ofta är ett selektivt tillvägagångssätt meningsfullt när man antar projektledningsprocesser och metoder för att passa specifika behov av projektet baserat på dess storlek, typ, komplexitet och den bransch där projektet genomförs. Ett sådant behov av ett annat tillvägagångssätt för att hantera IT-projekt är väl dokumenterat i projektledningslitteraturen.

mjukvaruutvecklingsprojekt står ofta inför motstridiga utmaningar med att utveckla mjukvaruprodukter i en snabbare takt samtidigt som de utvecklas med en robusthet för att göra dem pålitliga (Boehm, 2002). IT-projekt, som syftar till att hålla jämna steg med den snabbt föränderliga teknikutvecklingen, genomgår ofta omfattningsförändringar under planerings-och implementeringsstadierna. Följaktligen har IT-projekt utmaningar som skiljer sig från traditionella projekt. Flera justeringar och modifieringar av traditionella projektledningsmetoder utvecklas och praktiseras för IT-projekt och introducerar därmed nya projektledningsmetoder som agil projektledning.

Agile projektledningsmetodik—med sin större anpassningsförmåga till ofta föränderliga omfattning—använder iterativ eller fasad planering och kontinuerlig integration. Huvudprincipen är att hålla projektets omfattning mjuk. Metodiken främjar samarbete och resulterar i ökad kundnöjdhet. Agile är dock inte en komplett lösning för att utveckla programvara i snabb takt samtidigt som kundens krav på robusthet och pålitlighet uppfylls. I detta sammanhang rekommenderade Boehm (2002) en kombination av traditionell projektledning och smidig mjukvaruutvecklingsmetodik som är genomförbar och föredragen. Ett kompletterande tillvägagångssätt skulle vara att utveckla ett riskbaserat tillvägagångssätt som är skräddarsytt för att behålla fördelarna med både smidiga och plandrivna metoder och samtidigt mildra många av deras svaghet (Boehm & Turner, 2003).

detta forskningsdokument syftar till att undersöka ovanstående förslag (Boehm, 2002; Boehm & Turner, 2003) av ett kombinerat tillvägagångssätt för att hantera IT-konsultprojekt, som skiljer sig från IT-projekt. IT-konsultprojekt är utformade för att hantera och ge projektstöd till IT-projekt. De initieras ofta i den offentliga sektorn. IT-konsultprojekt är inte mjukvaruutvecklingsprojekt; snarare ger de projektstöd till IT-projekt.

i denna studie syftar vi till att utveckla en förståelse för hur agila projektledningsmetoder är relevanta för IT-konsultprojekt. Syftet med studien är att identifiera fördelarna med att använda agile projektledning, dess lämplighet och vilka aspekter av traditionella projektledningar som kan kombineras med agile projektledning för IT-konsultprojekt för att förbättra projektprestanda. I nästa avsnitt, med hjälp av en omfattande litteraturöversikt av agile projektledning metodik, vi har identifierat framträdande dragen i agile metoden och deras unika metod för att hantera projekt jämfört med traditionell Projektledning. Litteraturöversikten har bidragit till att utveckla en förståelse för nyckelbegreppen och fördelarna med att använda agile mjukvaruutveckling. Vidare har vi, baserat på litteraturöversiktsresultat, utvecklat och presenterat en forskningsmetod med hjälp av ett strukturerat frågeformulär för att utveckla en förståelse för IT-konsultprojekt. Dataanalys och diskussion, som presenteras senare, ger viktiga insikter och resultat av studien. Vi avslutar uppsatsen med våra forskningsresultat och rekommendationer för IT-konsultprojekt.

litteraturöversikt

traditionella projektledningsmetoder, som drivs av omfattande planering, kan användas när projektspecifikationer är tydligt definierade. Å andra sidan, när specifikationerna är föremål för frekventa förändringar under projektets livstid, kanske det traditionella sättet att hantera projekt kanske inte fungerar effektivt. Mjukvaruutvecklingsprojekt är ofta utformade med Minsta specifikationer, vilket orsakar frekventa ändringar av dessa specifikationer under projektets genomförande. Vidare är utvecklingstiden för mjukvaruprojekt korta. Agila metoder, jämfört med traditionella projektledningstekniker, är lämpliga för mjukvaruutvecklingsprojekt på grund av dessa projekts korta varaktighet för utveckling (Hanakawa & Okura, 2004).

i allmänhet lovar olika mjukvaruutvecklingsmetoder som agile project management ökad kundnöjdhet, lägre defektnivåer, snabbare utvecklingstider och de fungerar som en lösning på snabbt föränderliga projektkrav (Boehm & Turner, 2003). Till skillnad från agil projektledning använder en stage-gate-modell en arbetsprocess från konceptide till en produkt som slutligen levereras. Denna modell utvecklar projektledningslivscykelfaser baserade på olika stadier av produktutveckling för att hantera projekt. En viktig skillnad mellan en scenportmodell och smidig projektledning är att de tidigare försöken att minimera kraven ändras så att produkten är klar i tid (Karistrom & Runeson, 2005). En annan metod för att utveckla programvara är SCRUM, som är en uppsättning projektledningsprinciper som använder små tvärfunktionella och självstyrda Team (Schatz & Abdelshafi, 2005). SCRUM kräver att varje teammedlem och produktägare arbetar tillsammans i början av varje utvecklingsobjekt och metodiken fungerar som ett omslag kring befintliga utvecklingsprocesser. Därför hävdade Schatz och Abdelshafi att SCRUM inte kommer att ha en basplan för att mäta projektets framgång. Agil projektledning beaktas dock för denna studie på grund av dess större flexibilitet och anpassningsförmåga till mjukvaruutvecklingsprojekt.

förutom de fördelar som diskuterats ovan är smidig metodik tillämplig på turbulenta och ständigt föränderliga miljöer (Highsmith & Cockburn, 2001). Vidare betonar den smidiga metoden anpassningsförmåga till marknad, teknik och process (Mellor, 2005). Den agila metodiken är ett tillvägagångssätt som kommer att fokusera på viktiga funktioner först, och som ett resultat kommer det att leta efter tidig feedback på funktioner (Karistrom & Runeson, 2005). När viktiga funktioner har identifierats kommer projektledaren att se till att det inte finns några förseningar. Karistrom och Runeson indikerade att den smidiga processen skulle undvika att plugga resurser, fasta planer och stödja långsiktiga planer.

agil metodik är dock inte lämplig för alla mjukvaruutvecklingsprojekt. Med hänvisning till Scott Ambler, utvecklaren av agile-metoden, rekommenderade Boehm (2002) traditionell, plandriven projektledningsmetodik för assurance-programvara som livskritiska system.

agile-metoden, på grund av sin krävande projektmiljö som kännetecknas av kaos och osäkerhet, behöver projektgrupper bestående av begåvade människor för att möta utmanande behov och krav. Med hänvisning till en forskningsstudie av Constantine (2001) föreslog Boehm (2002) att smidiga metoder kräver mycket skickliga människor. Vidare är agile inte lämpligt för större lag (Highsmith & Cockburn, 2001), eftersom det kräver tätt samordnat lagarbete för att lyckas, och lag med mer än 15 eller 20 utvecklare ökar svårigheten att hantera projektet (Constantine, 2001).

det är uppenbart att den smidiga metoden använder sammanhängande lag (Karistrom & Runeson, 2005). Karistrom och Runeson identifierade ytterligare smidiga funktioner, såsom små och hanterbara uppgifter, kontinuerlig integration och automatisk testning. Därför kännetecknas agila projektgrupper av god intern kommunikation, högre kvalitet och en känsla av kontroll (Karistrom & Runeson). De förutser dock potentiell isolering för det smidiga teamet.

när det gäller kommunikation, dokumentbaserad hantering av framsteg och kvalitetskontroll matchar en vanlig praxis i traditionell Projektledning inte med agile software development method (Hanakawa & Okura, 2004). Ansikte mot ansikte interaktion för kontinuerlig omställning av utvecklingsmål föredras vanligtvis i agila metoder (Melnik & Mauer, 2004). Melnik och Mauer betonade skillnaden mellan traditionella och smidiga metoder och föreslog att kort kunskapsöverföring och direkt kommunikation och samarbete föredras i mjukvaruutveckling, i motsats till de traditionella projektledningspraxis, där långa kunskapsöverföringskedjor används, som ofta är mottagliga för snedvridning och förlust av information.

en av de viktiga skillnaderna mellan plandriven traditionell projektledningspraxis och agila metoder är att agila metoder fångar smidigheten från projektgruppens tysta kunskap snarare än den uttryckliga kunskapen, som ofta används i form av dokument och planer i traditionell Projektledning (Boehm, 2002).

en annan skillnad är mängden och typen av dokumentation som skapats för projekt. Plandriven traditionell Projektledning betonar detaljerad planering, övervakning och kontroll av dokument. Design rationales, dokument som uttrycker skäl och motiveringar, skapas med hjälp av en mycket automatiserad procedur och dessa design rationales fungerar som smidig dokumentation (Sauer, 2003).

Coram och Bohner (2005) har identifierat gemensamma funktioner i den smidiga metoden: samarbete, små lag, korta släppscheman, tidsboxning och konstant testning. Projektledaren är ansvarig för att säkerställa en mycket samarbetsmiljö. För detta ändamål uppmuntrar den smidiga metoden små team och några undergrupper per projekt för att främja samarbete. Som en konsekvens kommer den smidiga metoden sannolikt att kräva mindre process och planering för att samordna lagaktiviteter. Den smidiga metoden använder också korta släppscheman, som kan variera från två veckor till sex månader. Time boxing är ett koncept som ställer fast varaktighet för frisläppandet av projektleveranser, vilket bidrar till att minska guldplätering och omfattning kryp. Konstant testning säkerställer produktkvalitet och integration. Dessutom föreslog Coram och Bohner att projektledare måste följa framsteg och fatta affärsbeslut med tonvikt på att reagera på förändringar snarare än att följa en specifik plan.

tidsboxning leder till oförutsägbar planering genom bästa gissning och fasta datum kan ge oväntade överraskningar under utvecklingsfasen (Patton, 2003). En annan följd av denna iterativa projektplaneringsprocess är att den smidiga metoden inte kan övervaka framstegen baserat på procent komplett (Patton, 2003).

deltagande av små undergrupper i planeringen kommer att resultera i motiverade mjukvaruutvecklingsingenjörer; tekniska problem tas upp tidigt i projektet och det kommer att finnas lite motstånd i genomförandet (Karistrom & Runeson, 2005). Dessutom skulle definitionen av projektomfång med ett smidigt tillvägagångssätt leda till kostnadsminskning (Mcgovern, 2002). Den agila metoden använder kravbaserad planering och låter oss också styra scope (McGovern).

använda alla referenser och diskussioner hittills och andra (Little Greene, Phillips, Pilger & Poldervaart, 2004; Little, 2005; Abrahamsson, Warsta, Siponen, & Ronkainen, 2003; Ilieva, Ivanov, & Stefanova, 2004; Lindvall, 2004), Tabell 1 ger en sammanfattande jämförelse mellan traditionella och smidiga projekthanteringsmetoder.

Tabell 1: Jämförelse mellan Agile och traditionell Projektledning

projektfas	traditionell	Agil
inledande	formaliserat projekt kapacitet kvalitet förutsebar, utvecklingskrav formell kommunikationspolicy hög försäkran och stabilitetsmetod	prioriterad informella berättelser testfall oförutsebar snabb förändring informell, ansikte mot ansikte kommunikation radikal förändring och snabb värdeinriktning
planering	dokumenterad Explicit dokumenterad kunskap formell plan omfattande tillvägagångssätt väldefinierad omfattning långsam förändring av omfattning (godkänd) förutsägbarhet optimering Plandriven resursallokering låg risk på grund av planer oflexibel plan och omfattning omfattande användning av kvalitetskontroll och verktyg plan-och affärsdriven projekt Plandrivet schema	mindre dokumenterad driven flexibel plan tyst interpersonell kunskap iterativ plan Kravdriven strategi ändra omfattning frekventa, radikala förändringar oförutsägbar Kravbaserad, felxibel behovsbaserad resursallokering hög risk, oförutsägbar flexibel plan och omfattning ingen användning av kvalitetsverktyg på grund av omslagsändringar affärs-och behovsstyrt projekt tidsdriven schedule
Execution	Extensive design Longer increments Detailed execution plan Comprehensive scope change control Contractual and scope-based procurement Integration during integration Large teams for execution	Simple design Short increments Iterative and reactive execution plan Easy refactoring Requirement-based procurement Continuous integration små lag för utförande
övervakning och kontroll	kvantitativ kontroll dokumenterad-testplaner och procedurer förtjänat värde för att spåra projektkostnader veckovis och månadsvis	kvalitativ kontroll körbara testfall definiera testning ofta ändra baslinjen enkla grafiska verktyg för rapportering
Closeout	systematiskt tillvägagångssätt för kontraktsnedläggning lätt att fånga lärdomar tydliga och underförstådda lärdomar	brist på riktlinjer (villkor) svårt att fånga lärdomar tyst-kunskapsintensiva lärdomar

sammanfattning av litteraturöversikt

Agile projektledningsmetodik används ofta för mjukvaruutvecklingsprojekt. Det har större anpassningsförmåga till ofta föränderliga omfattning. Som en konsekvens använder agil projektledning iterativ eller fasad planering och kontinuerlig integration under hela projektets livstid. Huvudprincipen i agil projektledning är att hålla projektets omfattning mjuk. Agile projektledning metod skiljer sig från en traditionell Projektledning metod genom att tilldela betydelse för faktorer som traditionellt anses oviktiga. Agile tilldelar relativt högre betydelse för:

• individer och interaktioner över processer och verktyg
• projektkörning över omfattande dokumentation
• kundsamarbete över kontraktsförhandlingar
• svar på förändring över en projektplan

den smidiga metoden betonar flexibilitet för att möta projektbehov. Vidare är det beroende av kundåterkoppling för att initiera ändringar i en projektplan. Metoden använder metoden för att identifiera lämpliga slutanvändare och deras mål för att formulera projektleveranser och för att möta affärsprocessernas prestandabehov. Fördelarna med att använda agile-metoden inkluderar ökad kundnöjdhet, lägre defektnivåer och snabbare utvecklingstider. Dessutom är agile-metoden ett svar på snabbt föränderliga krav, eftersom den använder tidig feedback om tekniska funktioner i projektleveranser. Den smidiga metoden säkerställer att kraven inte är proppade. Viktiga funktioner i den agila metoden är effektiv kommunikation inom och utanför projektgruppen, och visade flexibilitet i att lägga till fler krav.

dessa fördelar skulle hjälpa organisationer att ge bättre kundservice. Vidare är de relevanta i den nuvarande ekonomin där globalisering och en fri marknadsföringsfilosofi påverkar kundernas uppfattningar för att höja förväntningarna att leverera produkter och/eller tjänster snabbare, billigare och bättre.

den smidiga metoden är dock inte utan brister, vilket framgår av Tabell 1. Ofta förändrade omfattning leder till svårigheter att övervaka projektets framsteg. Det är inte heller lätt att fånga tyst kunskap i form av lärdomar. Omfång förändringskontroll, dokumentation, övergripande plan, kvalitetsstyrning och riskhantering är viktiga fördelar med traditionell projektledning som vi kan berövas när vi använder agile metod.

forskningsmetodik

vi använde både personliga intervjuer och frågeformulär för att samla in data. Vi utvecklade ett strukturerat frågeformulär bestående av två sektioner. Det första avsnittet var utformat för att fånga detaljer om projektet och dess egenskaper. Detta avsnitt består av 13 frågor, som är relaterade till projektdemografi och projektledningspraxis. De presenterades för deltagarna i studien med möjlighet att ge öppna svar vid behov.

det andra avsnittet fokuserade på projektledningspraxis, och deltagarna ombads att svara på dessa uttalanden på fempunktsskala med 1 som betecknar ”starkt oense” och 5 som betecknar ”starkt överens.”Följande uttalanden användes för att ta itu med viktiga gemensamma principer för projektledningspraxis, samt tjäna till att kontrastera traditionella och smidiga projektledningspraxis.

• kriterierna för att mäta projektets framgång baseras på projektets mål och mål.
• projektet drivs av krav.
• projektet kan anpassas till förändring.
• enligt din åsikt uppnådde projektledningsinsatser förväntade resultat
• ansikte mot ansikte interaktioner och kortare kommunikationskedjor ges större betydelse än processer och verktyg.
• Team fokus ligger på projektgenomförande över omfattande dokumentation.
• kundsamarbete över kontraktsförhandlingar fungerar bättre för ditt team.
• projektet har ett väldefinierat projektomfång.
• projektledningspraxis följer projektlivscykeln för PMBOK i den svenska guiden.
• iterativ eller fasad projektplanering följs för projektet.
• projektet har dokumentationskrav som efterlevnad av standarder som ISO9000, OMB 300.
• user Acceptance Testing (UAT) – procedurer följs under hela projektet.
• projektledaren har befogenhet att fatta projektrelaterade beslut utan kundintervention.

svar på dessa uttalanden analyseras i samband med lämpliga frågor från den första uppsättningen av 13 frågor. Tillsammans gav svar på båda avsnitten detaljerad förståelse för projektet för meningsfull analys.

studieresultat

frågeformuläret var strukturerat för att fånga data om 20 It-konsultprojekt, som pågick vid tidpunkten för forskningen. Av projekten är 65% projekt av tid och material av kontraktstyp och de återstående är fasta fasta priser (FFP) typ. Bland tid-och materialprojekten har 55% en projekttid på mer än två år.

de flesta av projektgrupperna är små: endast 15% har 10 eller fler medlemmar. När det gäller kommunikation mellan projektgruppsmedlemmarna har 60% av de svarande endast använt formell kommunikation för projektbehov; 30% använde både formell och informell kommunikation, och de återstående 10% förlitade sig på informella metoder ensamma.

en av två svarande uppgav att deras projekt har använt en projektplan. I en relaterad fråga, av de projekt som inte hade en projektplan, använde 80% inte heller iterativ planering.

Scope change är en viktig aspekt av denna studie. Av projekten har 70% upplevt omfattning förändring minst en gång. Av dem som upplevde projektomfång förändring, 60% upplevde det mer än två gånger. Medan kunden bestämmer omslagsförändringen kan konsulten—med kundens samtycke-inkludera kvalitetskontrollplanen i projekthanteringsplanen. På frågan om de har en kvalitetskontrollplan för sitt projekt uppgav 65% av de svarande att de inte använde en kvalitetskontrollplan.

resultat diskussion och analys

forskningsresultat analyserades genom att noggrant undersöka eventuella samband mellan en fråga och alla andra frågor först för att validera resultat och för det andra för att utveckla effektiva förvaltningsstrategier. Dessutom analyserades dessa resultat för att undersöka vilka agila och traditionella projektledningsmetoder som kan användas i kombination för att utveckla en robust projektledningsmetod för IT-konsultprojekt.

projektets framgångskriterier baserat på dess mål och mål

ett projekt anses vara framgångsrikt när det uppfyller sina mål och mål. Endast 60% av de svarande instämde i uttalandet, ” kriterierna för att mäta projektets framgång baseras på projektets mål och mål.”Cirka 30% av de svarande var oense. Ytterligare analys har visat att orsaken till oenighet var att dessa projekt upplevde ständiga förändrade förhållanden och krav, eller att kunden inte var tydlig om projektet. I slutändan upplevde dessa projekt ofta omfattande förändringar. I ett särskilt fall ändrades projektets mål och mål.

det är intressant att notera att det inte finns något samband mellan det faktum att ett projekts framgångskriterier härrör från dess mål och omfattning förändring, typ av projekt, och förekomsten av en projektplan. Med andra ord, härleda projektkriterier från organisationens strategiska plan har ingen betydelse för omfång förändring och om projektet har en plan.

projektkrav

vanligtvis utvecklas en detaljerad projektplan efter att projektsponsorns krav tydligt identifierats. Projektplanutveckling och dess genomförande bör i princip drivas av dessa krav. Därför kan man förvänta sig att projektledare skulle hålla med uttalandet, ”projektet drivs av krav.”Studieresultaten visar att endast 60% av de svarande sa att deras projekt drivs av krav. Cirka 20% av de svarande som inte var överens med uttalandet indikerade att deras projekt genomförs utan att använda en projektplan.

cirka 20% av de svarande som var neutrala som svar på detta uttalande är projektledare som inte upplevde någon förändring av omfattningen i sina projekt. Alla andra respondenter, de som gick med på eller inte var överens med uttalandet, har upplevt omfångsändring minst en gång i sina nuvarande projekt.

i allmänhet, om ett projekt inte genomförs enligt planen, kan vi anta att kraven inte identifieras eller att projektkraven förväntas förändras under genomförandet. I denna studie kan vi emellertid inte upprätta en sådan koppling mellan ”genomförande av projektet utan att använda projektplanen” och ”projektet drivs inte av krav”, eftersom endast 50% av dem som kom överens med det andra uttalandet också har hanterat projekt utan att använda en plan.

anpassningsförmåga till förändring

arton av 20 projekt har svarat på förändringar i projektet framgångsrikt. Anpassningsförmåga till förändring anses vara en primär egenskap för att ett projekt ska vara en kandidat för att använda agile projektledningsmetodik. IT-konsultprojekt representerade i denna studie har visat att de har anpassningsförmåga för att hantera omfångsförändringar.

Projektledningsinsatser uppnådde förväntade resultat

resultat tyder på att kunden är nöjd med resultatet i majoriteten av projekten (70%). Dessa svar var dock inte förknippade med svar på andra viktiga enkätfrågor om projektets framsteg och produkt som utvecklats ur projektledarens perspektiv. Skälen är uppenbara. Projekt upplevde fortfarande tid och kostnadsöverskridanden. Även om slutresultatet i att leverera programvaruprodukten är tillfredsställande, utfördes inte projektledningsprocesser framgångsrikt. Slutsatsen kan vara att anta traditionella projektledningsmetoder som att utveckla milstolpar, övervakning och kontroll skulle ha hjälpt till att hantera projektet framgångsrikt.

betydelsen av ansikte mot ansikte kommunikation kontra processer

kommunikation är nyckeln till att förstå roller, ansvar, policyer och förfaranden relaterade till projekt och uppmuntra samarbete. I slutändan leder kommunikation till ett sammanhängande projektteam och uppmuntrar teammedlemmar att samarbeta och delta i beslutsfattandet. Sju av tio projektledare som deltog i studien var överens om att ansikte mot ansikte interaktioner och kortare kommunikationskedjor fick större betydelse än processer och verktyg.

resultaten visar en stark koppling mellan vikten av ansikte mot ansikte kommunikation och kommunikationsmedel bland projektteammedlemmarna. De som inte var överens om att kommunikation ansikte mot ansikte är viktigare än projektprocesser har använt informell kommunikation bland projektgruppens medlemmar, medan de som ansåg att kommunikation ansikte mot ansikte var viktigare har använt både formell och informell kommunikation.

fokus på projektgenomförande över dokumentation

projektdokumentation förbises ofta och följaktligen berövas organisationer viktiga lärdomar i projektplanering och genomförande. Med tanke på att alla projekt som representeras i denna studie är federala regeringsprojekt är det intressant att notera att 70% av de svarande projektledarna var överens om att deras team fokuserade på projektgenomförande jämfört med att skapa omfattande dokumentation. I ett fåtal fall där projektledare har ansett att dokumentation är viktigare än projektgenomförande, visade ytterligare undersökning att kunden var obeslutsam om projektet i alla dessa fall.

kundsamarbete över kontraktsförhandlingar

kontraktsförhandlingar är ett viktigt inslag i externa projekt. Under förhandlingarna skulle båda parter fokusera på att skydda sina egna intressen. Förhandlingar om kontraktet kan ske på olika stadier av projektet. Det är önskvärt att hantera dessa frågor genom samarbete, särskilt under projektets genomförande; annars kommer det att leda till problem som förlängning av kontraktet. Med tanke på att alla projekt som representeras i denna studie är kontrakt, är det glädjande att notera att mer än hälften av de svarande projektledarna (60%) anser att kundsamarbete är viktigare än kontraktsförhandlingar. De föreslog att samarbete fungerar bättre för projektgrupper.

där det fanns oenighet, vilket innebär att samarbete inte är lika viktigt som förhandlingar, var två intressanta fakta associerade med dessa projekt. Alla andra projekt använde direktkontakt som ett kommunikationsmedel med projektets intressenter, men dessa projekt använde kommandokommunikation och kunden var också obeslutsam om projektet. Båda dessa faktorer innebär svåra förutsättningar för samarbete.

projekt och ett väldefinierat Projektomfång

projekt är vanligtvis förknippade med osäkerheter och okända faktorer, vilket leder till tvetydighet. Som en följd av detta kan inte detaljerad omfattning och specifikationer utvecklas under projektets tidiga fas. Projektets omfattning förändras kontinuerligt under hela projektet. Ibland kan projektets ursprungliga mål också förändras. Av de undersökta projekten har 40% väldefinierad räckvidd, medan ytterligare 45% inte gjorde det.

men 80% av projekten upplevde omfattning förändring minst en gång, vilket validerar de argument som tidigare presenterats.

projektledningspraxis och PMBOK-guiden för projektlivscykel

PMBOK-guiden för projektledning har utvecklat en utarbetad livscykelprocess för projektledning; den är uttömmande och omfattande. Det är dock inte nödvändigt att varje process i projektledningens livscykel för PMBOK Asia-guiden tillämpas på varje projekt. Antagandet bör vara projektspecifikt. Som förväntat följde 45% av projektledarna projektledningspraxis i PMBOK-guidens projektlivscykel, och ytterligare 45% gjorde det inte.

iterativ eller Fasad projektplanering

omfattning definition och projektledningsplan är en del av projektplanen. Som diskuterats tidigare kan detaljerad utveckling av omfattning och specifikationer inte utvecklas tidigt i projektet. Följaktligen förändras projektets omfattning kontinuerligt under hela projektet, vilket understryker vikten av iterativ eller fasad projektplanering, en viktig egenskap för smidig metod. På frågan om iterativ eller fasad projektplanering följs för projektet eller inte, angav hälften av de svarande ja, och endast 15% följde inte iterativ projektplanering. Det är intressant att notera att alla som inte var överens med övningen av iterativ projektplanering inte hade en projektplan i första hand.

dokumentation och efterlevnad av standarder

Projektdokumentation fungerar som referens för analys av historiska data och hjälper organisationer att kontinuerligt förbättra projektledningsprocesser och utveckla standarder. Dokumentationen kommer också att bidra till att identifiera lärdomar och att ändra projektledningssystem som leder till projektledningsmognad. OMB300 och ISO9000 fungerar som guider i utformningen av projektdokumentationssystem. Specifikt krävs många regeringsprojekt för att följa omb300-riktlinjerna. Av de svarande sa 80% att IT-projekten de hanterade hade dokumentationskrav som att följa standarder som ISO9000 och omb300. Dessa krav för IT-konsultprojekten är dock tillämpliga i begränsad utsträckning.

Användaracceptprovprocedurer

kundnöjdhet är det primära måttet på kvalitet och framgång för projektlevererbara artiklar. Därför anses användaracceptprovprocedurer vara viktiga. Även när det gäller mindre konkreta projektleveranser som service är det underliggande måttet på projektframgång kundnöjdhet. Det är dock subjektivt. Endast 30% av de svarande sa att de följde testprocedurer för användaracceptans under hela projektet, och 45% av de svarande gjorde det inte.

bemyndigande att fatta projektrelaterade beslut

i allmänhet bör projektledare ges fria händer att fatta projektrelaterade beslut utan kundintervention, när dessa beslut inte har någon större inverkan på projektets omfattning eller projektleveranser. Endast 15% var överens om att projektledaren har befogenhet att fatta projektrelaterade beslut utan kundintervention. Cirka 40% förblev neutrala, och de återstående 45% sa att projektledaren inte hade denna makt. Med tanke på att dessa projekt är externa och statliga projekt, är dessa resultat vettiga.

slutsats

våra studieresultat visar att majoriteten av projekten drivs av krav. Nästan alla projekt representerade i denna studie visade att de kan anpassas till förändringar. Informell kommunikation anses vara viktigare än formella processer och system. Med tanke på att projekt i studien är relaterade till statligt arbete visar resultaten att projektgruppen fokuserar på projektgenomförande över omfattande dokumentation. Dessutom fungerar kundsamarbete över kontraktsförhandlingar bättre för projektgrupper. Frekvent förändring av projektomfång innebär vikten av iterativ eller fasad projektplanering; en viktig egenskap för smidig projektledning. Med tanke på att alla IT-konsultprojekt som representeras i denna studie är kontrakt, uppmuntrar studieresultaten formellt att anta smidig metod för IT-konsultprojekt och kombinera dem med traditionella projekthanteringsmetoder som plandriven milstolpeutveckling och övervakning, användaracceptprocedurer och kvalitetshanteringspraxis.

den smidiga metodens lämplighet för projekt är avtalsenlig skyldighet relaterad till dokument som rör projektplanering, övervakning och kontroll. Projekt som är associerade med den federala regeringen har vanligtvis betydande dokumentationskrav, såsom efterlevnad av standarder som ISO9000 och omb300; vi bör vara försiktiga när vi ändrar den smidiga metoden för sådana projekt.

utmaningen är att upprätthålla smidigheten, det snabba svaret på förändring, flexibla och enkla planer, kontinuerlig integration och andra fördelar med den smidiga metoden samtidigt som man införlivar några av de omfattande processerna i traditionella projekthanteringsmetoder.