gebruik van agile methodologie voor IT consulting projecten

Inleiding

projecten zijn vaak het middel om strategische plannen van een organisatie te operationaliseren. Er worden projecten gepland om producten en diensten te ontwikkelen en de operationele efficiëntie te vergroten. Het bedrijfsleven wordt steeds meer geprojecteerd en de wereldwijde uitgaven aan projecten zijn in de Orde van vele miljarden dollars per jaar (Williams, 2005). De redenen zijn duidelijk. Projecten bieden de mogelijkheid om projectmanagementpraktijken toe te passen die een efficiënt en effectief gebruik van middelen bevorderen. Ondanks de vooruitgang in de discipline en het beroep van projectmanagement wijst de gemeenschappelijke ervaring er echter op dat veel projecten mislukken (Williams, 2005), wat het belang en de noodzaak onderstreept om projectmanagementprocessen en prestaties te verbeteren.

in het algemeen streven organisaties ernaar om de beste praktijken van traditioneel projectmanagement—gebaseerd op PMI—standaarden-te implementeren om projectdoelstellingen te bereiken en aan de verwachtingen van de klant te voldoen. Echter, niet alle aanbevolen processen en praktijken van het project Management Body of Knowledge (PMBOK® Guide) kunnen relevant zijn voor elk project. Vaak is een selectieve aanpak zinvol bij het aannemen van projectmanagementprocessen en-praktijken om aan de specifieke behoeften van het project te voldoen op basis van de omvang, het type, de complexiteit en de industrie waarin het project wordt uitgevoerd. Een dergelijke behoefte aan een andere aanpak van het beheer van IT-projecten is goed gedocumenteerd in de literatuur over projectmanagement.

Softwareontwikkelingsprojecten worden vaak geconfronteerd met conflicterende uitdagingen bij het ontwikkelen van softwareproducten in een versneld tempo, terwijl ze worden ontwikkeld met een robuustheid om ze betrouwbaar te maken (Boehm, 2002). IT-projecten, die gelijke tred willen houden met de snel veranderende technologische ontwikkelingen, ondergaan vaak ingrijpende veranderingen tijdens de plannings-en uitvoeringsfase. IT-projecten hebben dus andere uitdagingen dan traditionele projecten. Voor IT-projecten worden verschillende aanpassingen en aanpassingen aan traditionele projectmanagementpraktijken ontwikkeld en toegepast, waardoor nieuwe projectmanagementmethoden zoals agile Projectmanagement worden geïntroduceerd.

Agile projectmanagementmethodologie—met haar Grotere aanpassingsvermogen aan vaak veranderende scope-maakt gebruik van iteratieve of gefaseerde planning en continue integratie. Het belangrijkste principe is om de reikwijdte van het project zacht te houden. De methodologie bevordert de samenwerking en resulteert in een verhoogde klanttevredenheid. Echter, agile is niet een complete oplossing voor het ontwikkelen van software in een snel tempo terwijl het voldoen aan de eisen van de klant van robuustheid en betrouwbaarheid. In deze context, Boehm (2002) aanbevolen een combinatie van traditionele project management en agile Software development methodologie die haalbaar is en de voorkeur. Een aanvullende benadering zou zijn om een risicogebaseerde benadering te ontwikkelen die is toegesneden op het behoud van de voordelen van zowel agile als plangestuurde methoden en tegelijkertijd veel van hun zwakke punten te verzachten (Boehm & Turner, 2003).

dit onderzoekspaper heeft tot doel de bovenstaande voorstellen te onderzoeken (Boehm, 2002; Boehm & Turner, 2003) van een gecombineerde aanpak voor het beheren van IT-consultingprojecten, die verschillen van IT-projecten. IT consulting projecten zijn ontworpen om IT-projecten te beheren en te ondersteunen. Ze worden vaak geïnitieerd in de overheidssector. IT-adviesprojecten zijn geen softwareontwikkelingsprojecten; zij bieden eerder projectondersteuning aan IT-projecten.

in deze studie willen we inzicht krijgen in hoe agile project management praktijken relevant zijn voor IT consulting projecten. De doelstellingen van de studie zijn het identificeren van de voordelen van het gebruik van agile project management, de geschiktheid, en welke aspecten van de traditionele project management kunnen worden gecombineerd met agile project management voor IT consulting projecten om de projectprestaties te verbeteren. In de volgende sectie, met behulp van een uitgebreide literatuurstudie van agile Project management methodologie, hebben we opvallende kenmerken van de agile methode en hun unieke benadering van het beheer van projecten in vergelijking met traditionele project management geïdentificeerd. Het literatuuronderzoek heeft bijgedragen tot een beter begrip van de belangrijkste concepten en voordelen van het gebruik van agile software development. Verder hebben we op basis van bevindingen uit literatuurstudie een onderzoeksmethode ontwikkeld en gepresenteerd aan de hand van een gestructureerde vragenlijst om inzicht te krijgen in it-consultingprojecten. Data-analyse en discussie, vervolgens gepresenteerd, leveren belangrijke inzichten en bevindingen van de studie. We sluiten de paper af met onze onderzoeksresultaten en aanbevelingen voor IT consulting projecten.

literatuuronderzoek

traditionele projectbeheerpraktijken, die gebaseerd zijn op uitgebreide planning, kunnen worden gebruikt wanneer projectspecificaties duidelijk zijn gedefinieerd. Aan de andere kant, wanneer de specificaties tijdens de looptijd van het project regelmatig worden gewijzigd, kan de traditionele aanpak van het beheer van projecten niet efficiënt werken. Softwareontwikkelingsprojecten worden vaak ontworpen met minimale specificaties, waardoor deze specificaties vaak worden gewijzigd tijdens de uitvoering van het project. Verder, software project ontwikkeling duur zijn kort. Agile methoden, vergeleken met traditionele project management technieken, zijn geschikt voor software development projecten vanwege de korte duur van deze projecten voor ontwikkeling (Hanakawa & Okura, 2004).

in het algemeen beloven verschillende softwareontwikkelingsmethoden, zoals agile project management, een verhoogde klanttevredenheid, lagere defectpercentages, snellere ontwikkelingstijden, en ze dienen als een oplossing voor snel veranderende projectvereisten (Boehm & Turner, 2003). In tegenstelling tot agile Projectmanagement gebruikt een stage-gate model een werkproces van conceptidee tot een product dat uiteindelijk wordt geleverd. Dit model ontwikkelt project management levenscyclus fasen op basis van verschillende stadia van productontwikkeling voor het beheer van projecten. Een belangrijk onderscheid tussen een stage-gate model en agile project management is dat de eerste pogingen om de eisen te minimaliseren veranderingen, zodat het product is voltooid in de tijd (Karistrom & Runeson, 2005). Een andere methode voor het ontwikkelen van software is SCRUM, een reeks projectmanagementprincipes waarbij gebruik wordt gemaakt van kleine cross-functionele en zelf beheerde teams (Schatz & Abdelshafi, 2005). SCRUM vereist dat elk teamlid en producteigenaar samenwerken aan het begin van elk ontwikkelingsitem en de methodologie fungeert als een wrapper rond bestaande ontwikkelingsprocessen. Daarom argumenteerden Schatz en Abdelshafi dat SCRUM geen baseline plan zal hebben om het succes van het project te meten. Echter, agile project management wordt overwogen voor deze studie vanwege de grotere flexibiliteit en het aanpassingsvermogen aan software ontwikkelingsprojecten.

naast de hierboven besproken voordelen is agile methodologie toepasbaar op turbulente en voortdurend veranderende omgevingen (Highsmith & Cockburn, 2001). Verder benadrukt de agile methode aanpassingsvermogen aan markt, technologie en proces (Mellor, 2005). De agile-methodologie is een benadering die zich eerst zal richten op belangrijke kenmerken, en als gevolg daarvan zal worden gezocht naar vroege feedback over kenmerken (Karistrom & Runeson, 2005). Zodra belangrijke functies zijn geïdentificeerd, zal de projectmanager ervoor zorgen dat er geen vertragingen zijn. Karistrom en Runeson aangegeven dat de agile proces zou voorkomen dat proppen van middelen, vaste plannen, en het ondersteunen van lange termijn plannen.

agile methodologie is echter niet geschikt voor alle softwareontwikkelingsprojecten. Onder verwijzing naar Scott Ambler, de ontwikkelaar van de agile methode, Boehm (2002) aanbevolen traditionele, plan-driven project management methodologie voor assurance software zoals life-critical systems.

de agile-methode heeft, vanwege de veeleisende projectomgeving die wordt gekenmerkt door chaos en onzekerheid, projectteams met getalenteerde mensen nodig om aan uitdagende behoeften en eisen te voldoen. Onder verwijzing naar een onderzoek van Constantine (2001), Boehm (2002) gesuggereerd dat agile methoden vereisen zeer capabele mensen. Verder is agile niet geschikt voor grotere teams (Highsmith & Cockburn, 2001), omdat het nauw gecoördineerd teamwerk vereist om te slagen, en teams met meer dan 15 of 20 ontwikkelaars vergroten de moeilijkheid om het project te beheren (Constantine, 2001).

het is duidelijk dat bij de agile-methode coherente teams werken (Karistrom & Runeson, 2005). Karistrom en Runeson identificeerden extra agile functies, zoals kleine en beheersbare taken, continue integratie en automatische testen. Daarom worden agile projectteams gekenmerkt door goede interne communicatie, hogere kwaliteit en een gevoel van controle (Karistrom & Runeson). Zij voorzien echter in een mogelijke isolatie voor het agile team.

op het gebied van communicatie, document-based management of progress en kwaliteitscontrole komt een gangbare praktijk in traditioneel projectmanagement niet overeen met agile Software development method (Hanakawa & Okura, 2004). In agile methodologieën wordt doorgaans de voorkeur gegeven aan Face-to-face interactie voor een voortdurende heroriëntatie van ontwikkelingsdoelstellingen (Melnik & Mauer, 2004). Melnik en Mauer benadrukten het verschil tussen traditionele en agile methoden en stelden voor dat korte kennisoverdracht en directe communicatie en samenwerking de voorkeur krijgen in softwareontwikkeling, in tegenstelling tot de traditionele projectmanagementpraktijken, waar lange kennisoverdrachtketens worden gebruikt, die vaak gevoelig zijn voor vervorming en verlies van informatie.

een van de belangrijke verschillen tussen plan-driven traditionele project management praktijken en agile methoden is dat agile methoden vangen de flexibiliteit van de stilzwijgende kennis van het projectteam in plaats van de expliciete kennis, vaak gebruikt in de vorm van documenten en plannen in de traditionele project management (Boehm, 2002).

een ander verschil is het bedrag en het soort documentatie dat voor projecten is gecreëerd. Plan-driven traditioneel projectmanagement legt de nadruk op gedetailleerde planning, monitoring en controle van documenten. Ontwerprationales, documenten die redenen en rechtvaardigingen uitdrukken, worden gemaakt met behulp van een sterk geautomatiseerde procedure en deze ontwerprationales dienen als flexibele documentatie (Sauer, 2003).

Coram en Bohner (2005) hebben gemeenschappelijke kenmerken van de agile methode geïdentificeerd: samenwerking, kleine teams, short release schema ‘ s, time boxing, en constant testen. De projectmanager is verantwoordelijk voor een sterk samenwerkende omgeving. Hiervoor stimuleert de agile methode kleine teams en een paar subteams per project om samenwerking te bevorderen. Als gevolg hiervan zal de agile methode waarschijnlijk minder proces en planning vereisen om teamactiviteiten te coördineren. De agile methode maakt ook gebruik van korte release schema ‘ s, die kunnen variëren van twee weken tot zes maanden. Time boxing is een concept dat een vaste duur oplegt voor de release van project deliverables, die helpt bij het verminderen van gold plating en scope creep. Constant testen zorgt voor productkwaliteit en integratie. Bovendien stelden Coram en Bohner voor dat projectmanagers de voortgang moeten volgen en zakelijke beslissingen moeten nemen met de nadruk op het reageren op veranderingen in plaats van het volgen van een specifiek plan.

tijd boksen leidt tot onvoorspelbare planning volgens beste schatting en vaste data kunnen onverwachte verrassingen veroorzaken tijdens de ontwikkelingsfase (Patton, 2003). Een ander resultaat van dit iteratieve projectplanningsproces is dat de agile methode de voortgang niet kan controleren op basis van percentage voltooid (Patton, 2003).

de betrokkenheid van kleine subteams bij de planning zal resulteren in gemotiveerde softwareontwikkelingsingenieurs; technische problemen worden vroeg in het project aan de orde gesteld en er zal weinig weerstand zijn bij de implementatie (Karistrom & Runeson, 2005). Bovendien zou het definiëren van projectscope met een agile aanpak resulteren in kostenreductie (Mcgovern, 2002). De agile methode maakt gebruik van requirements based planning, en laat ons ook controle scope (McGovern).

gebruikmakend van alle referenties en discussies tot nu toe en anderen (Little Greene, Phillips, Pilger & Poldervaart, 2004; Little, 2005; Abrahamsson, Warsta, Siponen, & Ronkainen, 2003; Ilieva, Ivanov, & Stefanova, 2004; Lindvall, 2004) geeft Tabel 1 Een samenvatting van de vergelijking tussen traditionele en agile projectmanagementpraktijken.

Tabel 1: Vergelijking tussen Agile en Traditionele Project Management

fase van het Project Traditionele Agile
Initiatie
  • Geformaliseerd project
  • Mogelijkheden
  • Kwaliteit
  • Voorzienbare, evolutie eisen
  • Formele communicatie beleid
  • Hoge zekerheid en stabiliteit aanpak
  • Prioriteit
  • Informele verhalen
  • Test cases
  • Onvoorziene snelle verandering
  • Informele, face-to-face communicatie
  • Radicale verandering en snelle aanpak waarde
Planning
  • Gedocumenteerde
  • Expliciet gedocumenteerde kennis
  • Formeel plan
  • integrale aanpak
  • Goed gedefinieerde scope
  • Langzaam verandering in reikwijdte (goedgekeurde)
  • Voorspelbaarheid
  • Optimalisatie
  • Plan-driven resource allocation
  • Laag risico, omdat de plannen
  • Inflexibel plan en omvang
  • Uitgebreid gebruik van kwaliteitscontrole en-gereedschappen
  • Plan – en business-gedreven project
  • Plan-driven planning
  • Minder gedocumenteerd gedreven flexibel plan
  • Stilzwijgende interpersoonlijke kennis
  • Iteratieve plan
  • Eisen-gedreven aanpak
  • het Veranderen van omvang
  • Frequente, radicale wijzigingen
  • Onvoorspelbaar
  • Requirements-gebaseerd, felxible
  • Behoefte-gebaseerde resourcetoewijzing
  • Hoog risico, onvoorspelbare
  • Flexibel plan en omvang
  • Geen quality tools gebruik als gevolg van wijzigingen in de scope
  • Business – en moet-gedreven project
  • Time-driven 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
  • Kleine teams voor de uitvoering
Toezicht en controle
  • Kwantitatieve controle
  • Gedocumenteerd-test plannen en procedures
  • Verdiende waarde voor het bijhouden van de project kosten
  • Wekelijkse en maandelijkse
  • Kwalitatieve controle
  • Uitvoerbare test cases definiëren testen
  • Vaak wisselende baseline
  • Eenvoudige grafische tools voor rapportage
Closeout
  • Systematische benadering van de contract close-out
  • gemakkelijk vast te leggen geleerde lessen
  • expliciete en stilzwijgende lessen
  • gebrek aan richtsnoeren (voorwaarden)
  • moeilijk vast te leggen geleerde lessen
  • stilzwijgend-kennisintensieve geleerde lessen

samenvatting van literatuuronderzoek

Agile project management methodologie wordt vaak gebruikt voor software ontwikkelingsprojecten. Het heeft een groter aanpassingsvermogen aan vaak veranderende reikwijdte. Als gevolg hiervan maakt agile Projectmanagement gebruik van iteratieve of gefaseerde planning en continue integratie gedurende de gehele levensduur van het project. Het belangrijkste principe in agile Projectmanagement is om de projectscope zacht te houden. Agile project management methode verschilt van een traditionele project management Methode door het toekennen van belang aan factoren die traditioneel als onbelangrijk worden beschouwd. Agile wijst relatief groter belang toe aan:

  • individuen en interacties over processen en instrumenten
  • projectuitvoering over uitgebreide documentatie
  • samenwerking tussen klanten over contractonderhandelingen
  • reactie op verandering over een projectplan

de agile methode benadrukt flexibiliteit om aan projectbehoeften te voldoen. Verder, het is gebaseerd op feedback van klanten om wijzigingen in een projectplan te initiëren. De methodologie maakt gebruik van de aanpak van het identificeren van de juiste eindgebruikers en hun doelen om project deliverables te formuleren en om te voldoen aan de presterende behoeften van de bedrijfsprocessen. Voordelen van het gebruik van de agile methode zijn onder meer verhoogde klanttevredenheid, lagere defectpercentages en snellere ontwikkelingstijden. Bovendien is de agile-methode een antwoord op snel veranderende eisen, omdat het vroege feedback over technologische kenmerken van project deliverables gebruikt. De agile methode zorgt ervoor dat de eisen niet worden volgepropt. Belangrijke kenmerken van de agile methode zijn effectieve communicatie binnen en buiten het projectteam, en toonde flexibiliteit in het toevoegen van meer eisen.

deze voordelen zouden organisaties helpen een betere klantenservice te bieden. Verder zijn ze relevant in de huidige economie waar globalisering en een vrije marketing filosofie van invloed zijn op de percepties van de klanten in het verhogen van de verwachtingen om producten en/of diensten sneller, goedkoper en beter te leveren.

de agile-methode is echter niet zonder tekortkomingen, zoals blijkt uit Tabel 1. Vaak veranderende reikwijdte leidt tot problemen bij het toezicht op de voortgang van het project. Ook is het niet gemakkelijk om stilzwijgende kennis vast te leggen in de vorm van geleerde lessen. Scope change control, documentatie, uitgebreid plan, kwaliteitsmanagement en risicomanagement zijn belangrijke voordelen van traditioneel projectmanagement die we kunnen worden ontnomen bij het gebruik van agile methode.

onderzoeksmethodologie

we hebben zowel persoonlijke interviews als vragenlijsten gebruikt om de gegevens te verzamelen. We ontwikkelden een gestructureerde vragenlijst bestaande uit twee secties. Het eerste deel werd ontworpen om details over het project en de kenmerken ervan vast te leggen. Deze sectie bestaat uit 13 vragen, die betrekking hebben op Project demografie en project management praktijken. Zij werden aan de deelnemers aan de studie gepresenteerd met de mogelijkheid om zo nodig open antwoorden te geven.

het tweede deel richtte zich op de praktijkverklaringen van projectmanagement, en de deelnemers werd gevraagd om op deze verklaringen op vijfpuntenschaal te reageren met 1 aanduiding “strongly agree” en 5 aanduiding “strongly agree”.”De volgende verklaringen werden gebruikt om belangrijke gemeenschappelijke principes van projectmanagementpraktijken aan te pakken, evenals om traditionele en agile projectmanagementpraktijken te contrasteren.

  • de criteria voor het meten van het succes van het project zijn gebaseerd op de doelstellingen en doelstellingen van het project.
  • het project wordt gedreven door vereisten.
  • het project kan worden aangepast aan veranderingen.
  • naar uw mening worden de verwachte resultaten van projectbeheer
  • Face-to-face interacties en kortere communicatieketens belangrijker dan processen en instrumenten.
  • het Team richt zich op de uitvoering van het project via uitgebreide documentatie.
  • samenwerking tussen klanten over contractonderhandelingen werkt beter voor uw team.
  • het project heeft een duidelijk omschreven projectomvang.
  • project management practices volgen de PMBOK ® Guide project life cycle.
  • iteratieve of gefaseerde projectplanning wordt gevolgd voor het project.
  • het project heeft documentatievereisten zoals naleving van normen zoals ISO9000, OMB 300.
  • procedures voor het testen van gebruikers (UAT) worden gedurende het hele project gevolgd.
  • de projectmanager is bevoegd om projectgerelateerde beslissingen te nemen zonder tussenkomst van de klant.

de antwoorden op deze verklaringen worden geanalyseerd in combinatie met de desbetreffende vragen uit de eerste reeks van 13 vragen. Samen gaven de reacties op beide secties een gedetailleerd inzicht in het project voor een zinvolle analyse.

studieresultaten

de vragenlijst was gestructureerd om gegevens te verzamelen over 20 it-consultingprojecten die ten tijde van het onderzoek aan de gang waren. Van de projecten, 65% zijn tijd en materiaal contract type projecten en de resterende zijn vaste vaste prijs (FFP) type. Van de tijd-en materiële projecten heeft 55% een projectduur van meer dan twee jaar.

de meeste projectteams zijn klein: slechts 15% heeft 10 of meer leden. Wat de communicatie tussen de leden van het projectteam betreft, heeft 60% van de respondenten alleen formele communicatie gebruikt voor projectbehoeften; 30% maakte gebruik van zowel formele als informele communicatie, en de overige 10% vertrouwde alleen op informele methoden.

Eén op de twee respondenten gaf aan dat in hun projecten gebruik is gemaakt van een projectplan. In een verwante vraag, van de projecten die geen projectplan hadden, gebruikte 80% ook geen iteratieve planning.

verandering van het toepassingsgebied is een belangrijk aspect van deze studie. Bij 70% van de projecten is de omvang ten minste één keer veranderd. Van degenen die het projectscope veranderden, ondervond 60% het meer dan twee keer. Terwijl de klant beslist over de scope verandering, kan de consultant—met toestemming van de klant—het kwaliteitscontroleplan opnemen in het projectmanagementplan. Op de vraag of zij een kwaliteitscontroleplan voor hun project hebben, gaf 65% van de respondenten aan geen kwaliteitscontroleplan te hebben gebruikt.

resultaten discussie en analyse

de resultaten van het onderzoek werden geanalyseerd door een zorgvuldig onderzoek naar het verband tussen een vraag en alle andere vragen, ten eerste om de resultaten te valideren en ten tweede om effectieve managementstrategieën te ontwikkelen. Daarnaast werden deze resultaten geanalyseerd om na te gaan welke agile en traditionele project management praktijken in combinatie kunnen worden gebruikt om een robuuste project management aanpak voor IT consulting projecten te ontwikkelen.

criteria voor succes van projecten op basis van de doelstellingen en doelstellingen

een project wordt als succesvol beschouwd wanneer het aan de doelstellingen en doelstellingen voldoet. Slechts 60% van de respondenten was het eens met de uitspraak: “de criteria voor het meten van het succes van het project zijn gebaseerd op de doelstellingen en doelstellingen van het project.”Ongeveer 30% van de respondenten was het daar niet mee eens. Verdere analyse heeft uitgewezen dat de reden voor onenigheid was dat deze projecten voortdurend veranderende omstandigheden en eisen ondervonden, of dat de opdrachtgever niet duidelijk was over het project. Uiteindelijk veranderden deze projecten vaak van omvang. In een specifiek geval veranderden de doelstellingen van het project.Het is interessant op te merken dat er geen verband is tussen het feit dat de succescriteria van een project worden afgeleid uit de doelstellingen en de wijziging van de reikwijdte, het type project en het bestaan van een projectplan. Met andere woorden, het afleiden van projectcriteria uit het strategisch plan van de organisatie heeft geen invloed op de scope verandering en of het project een plan heeft.

projectvereisten

gewoonlijk wordt een gedetailleerd projectplan opgesteld nadat de vereisten van de projectsponsor duidelijk zijn vastgesteld. De ontwikkeling en de uitvoering van het projectplan MOETEN in principe op deze vereisten zijn gebaseerd. Daarom zou men verwachten dat projectmanagers het eens zouden zijn met de uitspraak: “het project wordt gedreven door vereisten.”Uit studieresultaten blijkt dat slechts 60% van de respondenten zei dat hun projecten gedreven worden door vereisten. Ongeveer 20% van de respondenten die het niet eens waren met de verklaring gaf aan dat hun projecten worden uitgevoerd zonder gebruik te maken van een projectplan.

ongeveer 20% van de respondenten die neutraal waren in reactie op deze verklaring zijn de projectmanagers die geen verandering in de reikwijdte van hun projecten ondervonden. Alle andere respondenten, degenen die het eens of niet eens met de verklaring, hebben ervaren Perimeter verandering ten minste een keer in hun huidige projecten.

als een project niet volgens het plan wordt uitgevoerd, kunnen we er in het algemeen van uitgaan dat de vereisten niet worden vastgesteld of dat de projectvereisten naar verwachting tijdens de uitvoering zullen veranderen. In deze studie kunnen we echter geen verband leggen tussen “de uitvoering van het project zonder gebruik te maken van het projectplan” en “het project wordt niet gedreven door vereisten”, omdat slechts 50% van degenen die akkoord gingen met de tweede verklaring ook projecten hebben beheerd zonder gebruik te maken van een plan.

aanpassingsvermogen aan veranderingen

achttien van de twintig projecten hebben met succes op veranderingen in het project gereageerd. Aanpassingsvermogen aan verandering wordt beschouwd als een primaire eigenschap voor een project om een kandidaat te zijn voor het gebruik van agile Project management methodologie. De in deze studie vertegenwoordigde it-adviesprojecten hebben aangetoond dat zij zich kunnen aanpassen aan veranderingen in de omvang.

projectbeheer bereikte verwachte resultaten

resultaten wijzen erop dat de opdrachtgever tevreden is met het resultaat van de meeste projecten (70%). Deze antwoorden werden echter niet geassocieerd met antwoorden op andere belangrijke onderzoeksvragen over de voortgang van het project en het product ontwikkeld vanuit het perspectief van de projectmanager. De redenen zijn duidelijk. Projecten werden nog steeds geconfronteerd met tijd-en kostenoverschrijdingen. Hoewel het eindresultaat bij het leveren van het softwareproduct bevredigend is, zijn projectbeheerprocessen niet met succes uitgevoerd. De conclusie zou kunnen zijn dat het aannemen van traditionele project management praktijken zoals het ontwikkelen van mijlpalen, monitoring, en controlling zou hebben geholpen het project succesvol te beheren.

belang van Face-to-Face communicatie versus processen

communicatie is de sleutel tot het begrijpen van rollen, verantwoordelijkheden, beleid en procedures met betrekking tot projecten, en het aanmoedigen van samenwerking. Uiteindelijk leidt communicatie tot een samenhangend projectteam en moedigt teamleden aan om samen te werken en deel te nemen aan de besluitvorming. Zeven van de tien projectmanagers die deelnamen aan de studie waren het erover eens dat face-to-face interacties en kortere communicatieketens meer belang kregen dan processen en tools.

de resultaten tonen een sterk verband tussen het belang van face-to-face communicatie en de communicatiemiddelen onder de leden van het projectteam. Degenen die het er niet mee eens waren dat face-to-face communicatie belangrijker is dan projectprocessen, hebben informele communicatie tussen de leden van het projectteam gebruikt, terwijl degenen die face-to-face communicatie belangrijker vonden, zowel formele als informele communicatie hebben gebruikt.

Focus op projectuitvoering ten opzichte van documentatie

Projectdocumentatie wordt vaak over het hoofd gezien en als gevolg daarvan worden organisaties beroofd van belangrijke lessen die zij hebben geleerd in projectplanning en-uitvoering. Gezien het feit dat alle in deze studie vertegenwoordigde projecten federale overheidsprojecten zijn, is het interessant op te merken dat 70% van de projectmanagers ermee akkoord ging dat hun teams zich richtten op de uitvoering van het project in vergelijking met het maken van uitgebreide documentatie. In enkele gevallen waarin projectmanagers van mening waren dat documentatie belangrijker is dan de uitvoering van het project, bleek uit nader onderzoek dat de klant in al die gevallen besluiteloos was over het project.

samenwerking tussen klanten bij contractonderhandelingen

contractonderhandelingen zijn een essentieel kenmerk van externe projecten. Tijdens de onderhandelingen zouden beide partijen zich richten op het beschermen van hun eigen belangen. De onderhandelingen over het contract kunnen in verschillende fasen van het project plaatsvinden. Het is wenselijk om deze kwesties door middel van samenwerking aan te pakken, met name tijdens de uitvoering van het project; anders zal dit leiden tot problemen zoals de verlenging van het contract. Gezien het feit dat alle in deze studie vertegenwoordigde projecten contracten zijn, is het bemoedigend om op te merken dat meer dan de helft van de projectmanagers (60%) klantsamenwerking belangrijker vindt dan contractonderhandelingen. Zij stelden voor dat samenwerking beter werkt voor projectteams.

wanneer er onenigheid was, hetgeen impliceert dat samenwerking niet zo belangrijk is als onderhandelingen, werden twee interessante feiten met deze projecten in verband gebracht. Alle andere projecten gebruikten direct contact als communicatiemiddel met de projectstakeholders, maar deze projecten gebruikten chain-of-command communicatie en ook de klant was besluiteloos over het project. Beide factoren impliceren moeilijke voorwaarden voor samenwerking.

Project en een duidelijk omschreven Projectbereik

projecten worden gewoonlijk geassocieerd met onzekerheden en onbekende factoren, die tot dubbelzinnigheid leiden. Bijgevolg kunnen tijdens de eerste fase van het project geen gedetailleerde reikwijdte en specificaties worden ontwikkeld. De omvang van het project verandert voortdurend gedurende het hele project. Soms kunnen de oorspronkelijke doelstellingen van het project ook veranderen. Van de onderzochte projecten heeft 40% een duidelijk afgebakend toepassingsgebied, terwijl nog eens 45% dat niet heeft gedaan.

bij 80% van de projecten verandert de reikwijdte echter ten minste één keer, hetgeen de eerder aangevoerde argumenten bevestigt.

Project Management Practices en de PMBOK ® Guide Project Lifecycle

de PMBOK ® Guide heeft een uitgebreid project management life cycle proces ontwikkeld; het is uitputtend en uitgebreid. Het is echter niet nodig dat elk proces van de PMBOK ® Guide projectmanagement levenscyclus op elk project wordt toegepast. De goedkeuring ervan moet projectspecifiek zijn. Zoals verwacht volgde 45% van de projectmanagers de projectmanagementpraktijken van de PMBOK® Guide project life cycle, en nog eens 45% niet.

iteratieve of gefaseerde projectplanning

afbakening en projectbeheerplan maken deel uit van het projectplan. Zoals eerder besproken, kan een gedetailleerde ontwikkeling van het toepassingsgebied en de specificaties niet vroeg in het project worden ontwikkeld. Bijgevolg verandert de reikwijdte van het project voortdurend gedurende het hele project, wat het belang onderstreept van iteratieve of gefaseerde projectplanning, een belangrijk kenmerk van agile methode. Op de vraag of iteratieve of gefaseerde projectplanning voor het project wordt gevolgd of niet, gaf de helft van de respondenten ja aan, en slechts 15% volgde geen iteratieve projectplanning. Het is interessant om op te merken dat iedereen die het niet eens was met de praktijk van iteratieve projectplanning in de eerste plaats geen projectplan had.

documentatie en naleving van normen

Projectdocumentatie dient als referentie voor de analyse van historische gegevens en helpt organisaties voortdurend projectbeheerprocessen te verbeteren en normen te ontwikkelen. De documentatie zal ook helpen om geleerde lessen te identificeren en om projectbeheersystemen te wijzigen die zullen leiden tot de volwassenheid van projectbeheer. OMB300 en ISO9000 dienen als gidsen bij het ontwerpen van projectdocumentatiesystemen. In het bijzonder moeten veel overheidsprojecten zich houden aan de OMB300-richtlijnen. Van de respondenten zei 80% dat de IT-projecten die zij beheerden documentatievereisten hadden, zoals naleving van normen zoals ISO9000 en omb300. Deze vereisten voor de IT-consultingprojecten zijn echter in beperkte mate van toepassing.

testprocedures voor acceptatie door gebruikers

klanttevredenheid is de belangrijkste maatstaf voor kwaliteit en succes voor projecten. Daarom worden acceptatietestprocedures voor gebruikers belangrijk geacht. Zelfs in het geval van minder tastbare project deliverables zoals service, de onderliggende maatstaf van projectsucces is klanttevredenheid. Het is echter subjectief. Slechts 30% van de respondenten gaf aan dat zij de gebruikerstoetsingsprocedures gedurende het hele project hebben gevolgd, en 45% van de respondenten deed dat niet.

bevoegdheid om projectgerelateerde beslissingen te nemen

over het algemeen moeten projectmanagers de vrije hand krijgen om projectgerelateerde beslissingen te nemen zonder tussenkomst van de klant, wanneer deze beslissingen geen grote impact hebben op het projectbereik of de projectresultaten. Slechts 15% stemde ermee in dat de projectmanager de bevoegdheid heeft om projectgerelateerde beslissingen te nemen zonder tussenkomst van de klant. Ongeveer 40% bleef neutraal, en de overige 45% zei dat de projectmanager deze macht niet had. Gezien het feit dat deze projecten externe en overheidsprojecten zijn, zijn deze resultaten zinvol.

conclusie

onze studieresultaten tonen aan dat de meeste projecten worden gedreven door behoeften. Bijna alle in deze studie vertegenwoordigde projecten hebben aangetoond dat zij aan verandering kunnen worden aangepast. Informele communicatie wordt belangrijker geacht dan formele processen en systemen. Gezien het feit dat de projecten in de studie gerelateerd zijn aan overheidswerk, blijkt uit de resultaten dat het projectteam zich heeft gericht op de uitvoering van het project over uitgebreide documentatie. Daarnaast werkt samenwerking met klanten over contractonderhandelingen beter voor projectteams. Frequente verandering van projectscope betekent het belang van iteratieve of gefaseerde projectplanning; een belangrijk kenmerk van agile Projectmanagement. Gezien het feit dat alle IT-consulting projecten vertegenwoordigd in deze studie zijn contracten, studieresultaten moedigen formeel aannemen agile methodologie voor IT-consulting projecten en deze te combineren met traditionele project management praktijken zoals plan-driven mijlpaal ontwikkeling en monitoring, gebruikers acceptatie procedures, en kwaliteit management praktijken.

de geschiktheid van de agile-methode voor projecten is een contractuele verplichting met betrekking tot documenten betreffende projectplanning, monitoring en controle. Projecten in verband met de federale overheid hebben meestal belangrijke documentatievereisten, zoals naleving van normen zoals ISO9000 en OMB300; we moeten voorzichtig zijn bij het wijzigen van de agile methode voor dergelijke projecten.

de uitdaging bestaat erin de flexibiliteit, de snelle reactie op veranderingen, flexibele en eenvoudige plannen, continue integratie en andere voordelen van de agile-methode te behouden, terwijl een aantal van de uitgebreide processen van traditionele projectbeheerpraktijken worden geïntegreerd.

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.