Introduzione
I progetti sono spesso il mezzo per rendere operativi i piani strategici di un’organizzazione. Sono previsti progetti per sviluppare prodotti e servizi e per ottenere efficienza operativa. Gli affari stanno diventando sempre più proiettati e la spesa globale per i progetti è nell’ordine di molti miliardi di dollari all’anno (Williams, 2005). Le ragioni sono ovvie. I progetti offrono l’opportunità di utilizzare pratiche di gestione del progetto che promuovono un uso efficiente ed efficace delle risorse. Tuttavia, nonostante i progressi nella disciplina e nella professione di project management, l’esperienza comune suggerisce che molti progetti falliscono (Williams, 2005), il che sottolinea l’importanza e la necessità di migliorare i processi e le prestazioni di project management.
In generale, le organizzazioni si sforzano di implementare le migliori pratiche di gestione dei progetti tradizionali, basate su standard PMI, per raggiungere gli obiettivi del progetto e soddisfare le aspettative dei clienti. Tuttavia, non tutti i processi e le pratiche raccomandate del Project Management Body of Knowledge (Guida PMBOK®) possono essere rilevanti per ogni progetto. Spesso, un approccio selettivo ha senso nell’adozione di processi e pratiche di gestione del progetto per soddisfare le esigenze specifiche del progetto in base alle sue dimensioni, tipo, complessità e l’industria in cui il progetto è intrapreso. Tale necessità di un approccio diverso alla gestione dei progetti IT è ben documentata nella letteratura sulla gestione dei progetti.
I progetti di sviluppo software spesso affrontano sfide contrastanti nello sviluppo di prodotti software a un ritmo accelerato mentre li sviluppano con una robustezza che li rende affidabili (Boehm, 2002). I progetti IT, che mirano a stare al passo con gli sviluppi tecnologici in rapida evoluzione, spesso subiscono cambiamenti di portata durante le fasi di pianificazione e implementazione. Di conseguenza, i progetti IT presentano sfide diverse dai progetti tradizionali. Diversi aggiustamenti e modifiche alle pratiche tradizionali di project management sono sviluppati e praticati per i progetti IT, introducendo così nuove metodologie di project management come la gestione agile del progetto.
Agile project management methodology—con la sua maggiore adattabilità all’ambito che cambia frequentemente—utilizza la pianificazione iterativa o graduale e l’integrazione continua. Il principio chiave è quello di mantenere l’ambito del progetto morbido. La metodologia promuove la collaborazione e si traduce in una maggiore soddisfazione del cliente. Tuttavia, agile non è una soluzione completa per lo sviluppo di software ad un ritmo veloce, mentre soddisfare le esigenze dei clienti di robustezza e affidabilità. In questo contesto, Boehm (2002) ha raccomandato una combinazione di gestione del progetto tradizionale e metodologia di sviluppo software agile che è fattibile e preferibile. Un approccio complementare sarebbe quello di sviluppare un approccio basato sul rischio che sia adattato per mantenere i benefici dei metodi sia agili che basati sul piano e allo stesso tempo mitigare molte delle loro debolezze (Boehm & Turner, 2003).
Questo documento di ricerca mira ad esaminare le proposte di cui sopra (Boehm, 2002; Boehm & Turner, 2003) di un approccio combinato per la gestione di progetti di consulenza IT, che sono diversi dai progetti IT. I progetti di IT consulting sono concepiti per gestire e fornire supporto progettuale ai progetti IT. Sono spesso avviati nel settore governativo. I progetti di consulenza IT non sono progetti di sviluppo software; piuttosto, forniscono supporto ai progetti IT.
In questo studio miriamo a sviluppare una comprensione di come le pratiche di gestione del progetto agile siano rilevanti per i progetti di consulenza IT. Gli obiettivi dello studio sono identificare i vantaggi dell’utilizzo della gestione agile del progetto, la sua idoneità e quali aspetti della gestione tradizionale del progetto possono essere combinati con la gestione agile del progetto per i progetti di consulenza IT per migliorare le prestazioni del progetto. Nella sezione successiva, utilizzando un’ampia revisione della letteratura sulla metodologia di gestione del progetto agile, abbiamo identificato le caratteristiche salienti del metodo agile e il loro approccio unico alla gestione dei progetti rispetto alla gestione tradizionale del progetto. La revisione della letteratura ha contribuito a sviluppare una comprensione dei concetti chiave e dei vantaggi dell’utilizzo dello sviluppo software agile. Inoltre, sulla base dei risultati della revisione della letteratura, abbiamo sviluppato e presentato un metodo di ricerca utilizzando un questionario strutturato per sviluppare una comprensione dei progetti di consulenza IT. L’analisi e la discussione dei dati, presentati successivamente, forniscono importanti approfondimenti e risultati dello studio. Concludiamo il documento con i nostri risultati di ricerca e le raccomandazioni per i progetti di consulenza IT.
Revisione della letteratura
Le pratiche tradizionali di gestione del progetto, guidate da una pianificazione completa, possono essere utilizzate quando le specifiche del progetto sono chiaramente definite. D’altra parte, quando le specifiche sono soggette a frequenti cambiamenti durante la vita del progetto, l’approccio tradizionale alla gestione dei progetti potrebbe non funzionare in modo efficiente. I progetti di sviluppo software sono spesso concepiti con specifiche minime, causando frequenti modifiche a queste specifiche durante l’implementazione del progetto. Inoltre, le durate di sviluppo del progetto software sono brevi. I metodi agili, rispetto alle tradizionali tecniche di project management, sono adatti per progetti di sviluppo software a causa della breve durata di sviluppo di questi progetti (Hanakawa & Okura, 2004).
In generale, vari metodi di sviluppo software come l’agile project management promettono una maggiore soddisfazione del cliente, tassi di difetti inferiori, tempi di sviluppo più rapidi e servono come soluzione ai requisiti di progetto in rapida evoluzione (Boehm & Turner, 2003). In contrasto con la gestione agile del progetto, un modello stage-gate utilizza un processo di lavoro dall’idea concettuale a un prodotto che viene infine consegnato. Questo modello sviluppa le fasi del ciclo di vita della gestione del progetto in base a diverse fasi di sviluppo del prodotto per la gestione dei progetti. Un’importante distinzione tra un modello di stage-gate e una gestione del progetto agile è che il primo tenta di minimizzare i cambiamenti dei requisiti in modo che il prodotto sia completato in tempo (Karistrom & Runeson, 2005). Un altro metodo per lo sviluppo del software è SCRUM, che è un insieme di principi di gestione del progetto che impiegano piccoli team interfunzionali e autogestiti (Schatz & Abdelshafi, 2005). SCRUM richiede che ogni membro del team e il proprietario del prodotto lavorino insieme all’inizio di ogni elemento di sviluppo e la metodologia funge da wrapper attorno ai processi di sviluppo esistenti. Pertanto, Schatz e Abdelshafi hanno sostenuto che SCRUM non avrà un piano di base per misurare il successo del progetto. Tuttavia, agile project management è considerato per questo studio a causa della sua maggiore flessibilità e adattabilità ai progetti di sviluppo software.
Oltre ai benefici discussi sopra, la metodologia agile è applicabile agli ambienti turbolenti e in continua evoluzione (Highsmith & Cockburn, 2001). Inoltre, il metodo agile enfatizza l’adattabilità al mercato, alla tecnologia e al processo (Mellor, 2005). La metodologia agile è un approccio che si concentrerà prima sulle funzionalità importanti e, di conseguenza, cercherà un feedback precoce sulle funzionalità (Karistrom & Runeson, 2005). Una volta identificate le caratteristiche importanti, il project manager farà in modo che non ci siano ritardi. Karistrom e Runeson hanno indicato che il processo agile eviterebbe il cramming di risorse, piani fissi e piani a lungo termine.
Tuttavia, la metodologia agile non è adatta a tutti i progetti di sviluppo software. Citando Scott Ambler, lo sviluppatore del metodo agile, Boehm (2002) ha raccomandato la tradizionale metodologia di gestione del progetto basata su piani per software di assicurazione come i sistemi critici per la vita.
Il metodo agile, a causa del suo impegnativo ambiente di progetto caratterizzato da caos e incertezza, ha bisogno di team di progetto composti da persone di talento per soddisfare esigenze e richieste impegnative. Citando uno studio di ricerca di Constantine (2001), Boehm (2002) ha suggerito che i metodi agili richiedono persone altamente capaci. Inoltre, agile non è adatto a team più grandi (Highsmith & Cockburn, 2001), in quanto richiede un lavoro di squadra strettamente coordinato per avere successo e team con più di 15 o 20 sviluppatori aumentano la difficoltà di gestire il progetto (Constantine, 2001).
È ovvio che il metodo agile impiega team coerenti (Karistrom & Runeson, 2005). Karistrom e Runeson hanno identificato funzionalità agili aggiuntive, come attività piccole e gestibili, integrazione continua e test automatici. Di conseguenza, i team di progetto agile sono caratterizzati da una buona comunicazione interna, una qualità superiore e una sensazione di controllo (Karistrom & Runeson). Tuttavia, prevedono un potenziale isolamento per il team agile.
In termini di comunicazione, gestione documentale del progresso e controllo della qualità, una pratica comune nella gestione tradizionale del progetto non corrisponde al metodo di sviluppo software agile (Hanakawa & Okura, 2004). L’interazione faccia a faccia per il riallineamento continuo degli obiettivi di sviluppo è solitamente preferita nelle metodologie agili (Melnik & Mauer, 2004). Evidenziando la differenza tra metodi tradizionali e agili, Melnik e Mauer hanno suggerito che il breve trasferimento di conoscenza e la comunicazione diretta e la collaborazione sono preferiti nello sviluppo del software, in contrasto con le tradizionali pratiche di gestione del progetto, in cui vengono utilizzate lunghe catene di trasferimento della conoscenza, che sono spesso suscettibili di distorsione e perdita di informazioni.
Una delle differenze importanti tra le pratiche di gestione dei progetti tradizionali basate sui piani e i metodi agili è che i metodi agili catturano l’agilità dalla conoscenza tacita del team di progetto piuttosto che dalla conoscenza esplicita, spesso utilizzata sotto forma di documenti e piani nella gestione dei progetti tradizionali (Boehm, 2002).
Un’altra differenza è la quantità e il tipo di documentazione creata per i progetti. La gestione del progetto tradizionale basata su piani enfatizza la pianificazione dettagliata, il monitoraggio e il controllo dei documenti. Le motivazioni di progettazione, i documenti che esprimono ragioni e giustificazioni, vengono creati utilizzando una procedura altamente automatizzata e queste motivazioni di progettazione fungono da documentazione agile (Sauer, 2003).
Coram e Bohner (2005) hanno identificato caratteristiche comuni del metodo agile: collaborazione, piccoli team, programmi di rilascio brevi, time boxing e test costanti. Il project manager è responsabile di garantire un ambiente altamente collaborativo. A tale scopo, il metodo agile incoraggia piccoli team e alcuni sotto-team per progetto a promuovere la collaborazione. Di conseguenza, è probabile che il metodo agile richieda meno processi e pianificazione per coordinare le attività del team. Il metodo agile utilizza anche programmi di rilascio brevi, che possono variare da due settimane a sei mesi. Time boxing è un concetto che impone una durata fissa per il rilascio dei risultati del progetto, che aiuta a ridurre la doratura e lo scorrimento dell’ambito. Il test costante garantisce la qualità e l’integrazione del prodotto. Inoltre, Coram e Bohner hanno suggerito che i project manager devono monitorare i progressi e prendere decisioni aziendali con l’accento sulla risposta al cambiamento piuttosto che seguire un piano specifico.
La boxe del tempo porta a una pianificazione imprevedibile secondo le migliori ipotesi e le date fisse potrebbero portare a sorprese inaspettate durante la fase di sviluppo (Patton, 2003). Un altro risultato di questo processo di pianificazione del progetto iterativo è che il metodo agile non può monitorare i progressi in base alla percentuale completa (Patton, 2003).
Il coinvolgimento di piccoli sotto-team nella pianificazione si tradurrà in ingegneri di sviluppo software motivati; problemi tecnici vengono sollevati all’inizio del progetto e ci sarà poca resistenza nell’implementazione (Karistrom & Runeson, 2005). Inoltre, la definizione dell’ambito del progetto con un approccio agile comporterebbe una riduzione dei costi (Mcgovern, 2002). Il metodo agile utilizza la pianificazione basata sui requisiti e ci consentirà anche di controllare l’ambito (McGovern).
Utilizzando tutti i riferimenti e le discussioni finora e gli altri (Little Greene, Phillips, Pilger & Poldervaart, 2004; Poco, 2005; Abrahamsson, Warsta, Siponen, & Ronkainen, 2003; Ilieva, Ivanov, & Stefanova, 2004; Lindvall, 2004), la Tabella 1 fornisce un sommario confronto tra la tradizione e l’agile project management pratiche.
Tabella 1: Confronto tra Agile e Tradizionali di Gestione del Progetto
| fase di Progetto | Tradizionale | Agile |
| Iniziazione |
|
|
| Pianificazione |
|
|
| Execution |
|
|
| il Monitoraggio e il Controllo |
|
|
| Liquidazione |
|
|
Riassunto di Letteratura
Agile metodologia di project management, è comunemente utilizzato per progetti di sviluppo software. Ha una maggiore adattabilità al campo di applicazione che cambia frequentemente. Di conseguenza, agile project management utilizza la pianificazione iterativa o graduale e l’integrazione continua per tutta la vita del progetto. Il principio chiave nella gestione agile del progetto è quello di mantenere l’ambito del progetto morbido. Il metodo di gestione del progetto agile è diverso da un metodo di gestione del progetto tradizionale assegnando importanza a fattori tradizionalmente considerati non importanti. Agile assegna un’importanza relativamente maggiore a:
- Individui e interazioni su processi e strumenti
- Esecuzione del progetto su documentazione completa
- Collaborazione con i clienti sulla negoziazione del contratto
- Risposta al cambiamento su un piano di progetto
Il metodo agile enfatizza la flessibilità per soddisfare le esigenze del progetto. Inoltre, si basa sul feedback dei clienti per avviare le modifiche a un piano di progetto. La metodologia utilizza l’approccio di identificare gli utenti finali appropriati e i loro obiettivi per formulare i risultati del progetto e per soddisfare le esigenze performanti dei processi aziendali. I vantaggi dell’utilizzo del metodo agile includono una maggiore soddisfazione del cliente, tassi di difetti inferiori e tempi di sviluppo più rapidi. Inoltre, il metodo agile è una risposta ai requisiti in rapida evoluzione, in quanto utilizza un feedback precoce sulle caratteristiche tecnologiche dei risultati del progetto. Il metodo agile garantisce che i requisiti non siano stipati. Le caratteristiche principali del metodo agile sono una comunicazione efficace all’interno e all’esterno del team di progetto e una flessibilità dimostrata nell’aggiungere più requisiti.
Questi vantaggi aiuterebbero le organizzazioni a fornire un servizio clienti migliore. Inoltre, sono rilevanti nell’economia attuale in cui la globalizzazione e una filosofia di marketing gratuito stanno influenzando le percezioni dei clienti nell’aumentare le aspettative di fornire prodotti e/o servizi più veloci, più economici e migliori.
Tuttavia, il metodo agile non è privo di carenze, come si può vedere nella Tabella 1. Cambiare frequentemente ambito porta a difficoltà nel monitoraggio dei progressi del progetto. Inoltre, non è facile catturare la conoscenza tacita sotto forma di lezioni apprese. Il controllo delle modifiche dell’ambito, la documentazione, il piano completo, la gestione della qualità e la gestione dei rischi sono importanti vantaggi della gestione dei progetti tradizionali di cui possiamo essere privati quando utilizziamo il metodo agile.
Metodologia di ricerca
Abbiamo utilizzato sia interviste personali che questionari per raccogliere i dati. Abbiamo sviluppato un questionario strutturato composto da due sezioni. La prima sezione è stata progettata per catturare dettagli sul progetto e le sue caratteristiche. Questa sezione è composta da 13 domande, relative alla demografia del progetto e alle pratiche di gestione del progetto. Sono stati presentati ai partecipanti allo studio con l’opzione di fornire risposte aperte quando necessario.
La seconda sezione si è concentrata sulle dichiarazioni pratiche di gestione del progetto, e ai partecipanti è stato chiesto di rispondere a queste affermazioni su una scala di cinque punti con 1 che indica “fortemente in disaccordo” e 5 che indica “fortemente d’accordo.”Le seguenti dichiarazioni sono state utilizzate per affrontare importanti principi comuni delle pratiche di gestione del progetto, oltre a servire a contrastare le pratiche di gestione del progetto tradizionali e agili.
- I criteri per misurare il successo del progetto si basano sugli obiettivi e gli obiettivi del progetto.
- Il progetto è guidato dai requisiti.
- Il progetto è adattabile al cambiamento.
- Secondo te, gli sforzi di gestione del progetto hanno raggiunto i risultati attesi
- Le interazioni faccia a faccia e le catene di comunicazione più brevi hanno più importanza dei processi e degli strumenti.
- Il team si concentra sull’esecuzione del progetto su una documentazione completa.
- La collaborazione con i clienti sulla negoziazione del contratto funziona meglio per il tuo team.
- Il progetto ha un ambito di progetto ben definito.
- Le pratiche di gestione del progetto seguono il ciclo di vita del progetto PMBOK® Guide.
- Per il progetto viene seguita la pianificazione iterativa o graduale del progetto.
- Il progetto ha requisiti di documentazione come l’adesione a standard come ISO9000, OMB 300.
- Le procedure di User Acceptance Testing (UAT) sono seguite durante tutto il progetto.
- Il project manager ha il potere di prendere decisioni relative al progetto senza l’intervento del cliente.
Le risposte a queste affermazioni vengono analizzate insieme alle domande appropriate della prima serie di 13 domande. Insieme, le risposte a entrambe le sezioni hanno fornito una comprensione dettagliata del progetto per un’analisi significativa.
Risultati dello studio
Il questionario è stato strutturato per acquisire dati su 20 progetti di consulenza informatica, che erano in corso al momento della ricerca. Dei progetti, il 65% sono progetti di tipo contratto di tempo e materiale e il restante è di tipo fisso fisso (FFP). Tra i progetti di tempo e materiali, il 55% ha una durata del progetto superiore a due anni.
La maggior parte dei team di progetto sono piccoli: solo il 15% ha 10 o più membri. Per quanto riguarda la comunicazione tra i membri del team di progetto, il 60% degli intervistati ha utilizzato solo la comunicazione formale per le esigenze del progetto; il 30% ha utilizzato sia la comunicazione formale che quella informale, mentre il restante 10% si è affidato ai soli metodi informali.
Uno su due ha dichiarato che i propri progetti hanno utilizzato un piano di progetto. In una domanda correlata, di quei progetti che non avevano un piano di progetto, l ‘ 80% non ha utilizzato nemmeno la pianificazione iterativa.
La modifica dell’ambito è un aspetto importante di questo studio. Dei progetti, il 70% ha subito un cambiamento di ambito almeno una volta. Di quelli che hanno sperimentato il cambiamento dell’ambito del progetto, il 60% l’ha sperimentato più del doppio. Mentre il cliente decide la modifica dell’ambito, il consulente—con il consenso del cliente-può includere il piano di controllo qualità nel piano di gestione del progetto. Alla domanda se dispongano di un piano di controllo della qualità per il loro progetto, il 65% degli intervistati ha dichiarato di non utilizzare un piano di controllo della qualità.
Risultati Discussione e analisi
I risultati della ricerca sono stati analizzati esaminando attentamente qualsiasi interrelazione tra una domanda e tutte le altre domande prima per convalidare i risultati e in secondo luogo, per sviluppare strategie di gestione efficaci. Inoltre, questi risultati sono stati analizzati al fine di esaminare quali pratiche di gestione del progetto agile e tradizionale possono essere utilizzate in combinazione per sviluppare un solido approccio di gestione del progetto per i progetti di consulenza IT.
Criteri di successo del progetto in base ai suoi obiettivi e obiettivi
Un progetto è considerato di successo quando soddisfa i suoi obiettivi e obiettivi. Solo il 60% degli intervistati è d’accordo con la dichiarazione, “I criteri per misurare il successo del progetto si basano sugli obiettivi e gli obiettivi del progetto.”Circa il 30% degli intervistati non è d’accordo. Ulteriori analisi hanno dimostrato che il motivo del disaccordo era che questi progetti stavano vivendo condizioni e requisiti in costante cambiamento, o che il cliente non era chiaro sul progetto. In definitiva, questi progetti stavano vivendo frequenti cambiamenti di portata. In un caso particolare, gli obiettivi e gli obiettivi del progetto sono cambiati.
È interessante notare che non esiste alcuna associazione tra il fatto che i criteri di successo di un progetto derivano dai suoi obiettivi e dal cambiamento di portata, dal tipo di progetto e dall’esistenza di un piano di progetto. In altre parole, derivare i criteri del progetto dal piano strategico dell’organizzazione non ha alcuna incidenza sul cambiamento dell’ambito e sul fatto che il progetto abbia un piano.
Requisiti del progetto
Di solito, un piano di progetto dettagliato viene sviluppato dopo che i requisiti dello sponsor del progetto sono chiaramente identificati. Lo sviluppo del piano di progetto e la sua esecuzione, in linea di principio, dovrebbero essere guidati da questi requisiti. Pertanto, ci si aspetterebbe che i project manager sarebbero d’accordo con la dichiarazione, ” Il progetto è guidato da requisiti.”I risultati dello studio mostrano che solo il 60% degli intervistati ha dichiarato che i loro progetti sono guidati dai requisiti. Circa il 20% degli intervistati che non erano d’accordo con la dichiarazione ha indicato che i loro progetti sono eseguiti senza utilizzare un piano di progetto.
Circa il 20% degli intervistati che sono stati neutrali in risposta a questa affermazione sono i project manager che non hanno subito alcun cambiamento di portata nei loro progetti. Tutti gli altri intervistati, coloro che hanno concordato o in disaccordo con la dichiarazione, hanno sperimentato cambiamenti di portata almeno una volta nei loro progetti attuali.
In generale, se un progetto non viene implementato secondo il suo piano, possiamo supporre che i requisiti non siano identificati o che i requisiti del progetto debbano cambiare durante la sua esecuzione. In questo studio, tuttavia, non possiamo stabilire una tale associazione tra “implementare il progetto senza utilizzare il piano di progetto” e “il progetto non è guidato da requisiti”, perché solo il 50% di coloro che hanno concordato con la seconda affermazione hanno anche gestito progetti senza utilizzare un piano.
Adattabilità al cambiamento
Diciotto progetti su 20 hanno risposto con successo ai cambiamenti del progetto. L’adattabilità al cambiamento è considerata una caratteristica primaria per un progetto di essere un candidato per l’utilizzo della metodologia di gestione del progetto agile. I progetti di consulenza informatica rappresentati in questo studio hanno dimostrato di avere adattabilità per affrontare il cambiamento dell’ambito.
Gli sforzi di project Management hanno raggiunto i risultati attesi
I risultati suggeriscono che il cliente è soddisfatto del risultato nella maggior parte dei progetti (70%). Tuttavia, queste risposte non sono state associate a risposte ad altre importanti domande del sondaggio sullo stato di avanzamento del progetto e sul prodotto sviluppato dal punto di vista del project manager. Le ragioni sono ovvie. I progetti erano ancora in fase di superamento dei tempi e dei costi. Mentre il risultato finale nella fornitura del prodotto software è soddisfacente, i processi di gestione del progetto non sono stati eseguiti con successo. L’inferenza potrebbe essere che l’adozione di pratiche tradizionali di gestione del progetto come lo sviluppo di pietre miliari, il monitoraggio e il controllo avrebbe aiutato a gestire il progetto con successo.
Importanza della comunicazione faccia a faccia rispetto ai processi
La comunicazione è la chiave per comprendere ruoli, responsabilità, politiche e procedure relative ai progetti e incoraggiare la collaborazione. In definitiva, la comunicazione porta a un team di progetto coeso e incoraggia i membri del team a collaborare e partecipare al processo decisionale. Sette dei dieci project manager che hanno partecipato allo studio hanno convenuto che le interazioni faccia a faccia e le catene di comunicazione più brevi hanno avuto più importanza dei processi e degli strumenti.
I risultati mostrano una forte associazione tra l’importanza della comunicazione faccia a faccia e i mezzi di comunicazione tra i membri del team di progetto. Coloro che non erano d’accordo sul fatto che la comunicazione faccia a faccia sia più importante dei processi di progetto hanno usato la comunicazione informale tra i membri del team di progetto, mentre coloro che consideravano la comunicazione faccia a faccia più importante hanno usato sia la comunicazione formale che informale.
Concentrarsi sull’esecuzione del progetto sulla documentazione
La documentazione di progetto è spesso trascurata e, di conseguenza, le organizzazioni sono private di importanti lezioni apprese nella pianificazione e nell’esecuzione del progetto. Considerando che tutti i progetti rappresentati in questo studio sono progetti del governo federale, è interessante notare che 70% dei project manager che hanno risposto hanno concordato che i loro team si sono concentrati sull’esecuzione del progetto rispetto alla creazione di una documentazione completa. In alcuni casi in cui i project manager hanno ritenuto che la documentazione sia più importante dell’esecuzione del progetto, ulteriori indagini hanno rivelato che il cliente era indeciso sul progetto in tutti questi casi.
Collaborazione con i clienti sulla negoziazione del contratto
La negoziazione del contratto è una caratteristica essenziale dei progetti esterni. Durante la negoziazione, entrambe le parti si concentrerebbero sulla protezione dei loro interessi personali. La negoziazione del contratto può avvenire in diverse fasi del progetto. È auspicabile affrontare questi problemi attraverso la collaborazione, in particolare durante l’attuazione del progetto; altrimenti, porterà a problemi come l’estensione del contratto. Dato che tutti i progetti rappresentati in questo studio sono contratti, è incoraggiante notare che più della metà dei project manager che rispondono (60%) considera la collaborazione con i clienti più importante della negoziazione del contratto. Hanno suggerito che la collaborazione funziona meglio per i team di progetto.
Dove c’era disaccordo, implicando che la collaborazione non è importante quanto la negoziazione, due fatti interessanti sono stati associati a quei progetti. Tutti gli altri progetti utilizzavano il contatto diretto come mezzo di comunicazione con gli stakeholder del progetto, ma questi progetti utilizzavano la comunicazione a catena di comando e anche il cliente era indeciso sul progetto. Entrambi questi fattori implicano condizioni difficili per la collaborazione.
Progetto e un ambito di progetto ben definito
I progetti sono solitamente associati a incertezze e fattori sconosciuti, che portano all’ambiguità. Di conseguenza, la portata e le specifiche dettagliate non possono essere sviluppate durante la fase iniziale del progetto. La portata del progetto cambia continuamente nel corso del progetto. A volte, gli obiettivi originali del progetto possono anche cambiare. Dei progetti intervistati, il 40% ha una portata ben definita, mentre un altro 45% non lo ha fatto.
Tuttavia, l ‘ 80% dei progetti ha subito una modifica dell’ambito almeno una volta, il che convalida gli argomenti precedentemente presentati.
Pratiche di gestione del progetto e la Guida PMBOK® Ciclo di vita del progetto
La Guida PMBOK® ha sviluppato un elaborato processo di gestione del ciclo di vita del progetto; è esaustivo e completo. Tuttavia, non è necessario che ogni processo del ciclo di vita della gestione del progetto PMBOK® Guide venga applicato a ogni progetto. La sua adozione dovrebbe essere specifica per il progetto. Come previsto, il 45% dei project manager ha seguito le pratiche di project management del ciclo di vita del progetto PMBOK® Guide e un altro 45% no.
Pianificazione iterativa o graduale del progetto
La definizione dell’ambito e il piano di gestione del progetto fanno parte del piano di progetto. Come discusso in precedenza, lo sviluppo dettagliato del campo di applicazione e delle specifiche non può essere sviluppato all’inizio del progetto. Di conseguenza, l’ambito del progetto cambia continuamente durante il progetto, il che sottolinea l’importanza della pianificazione del progetto iterativa o graduale, una caratteristica importante del metodo agile. Quando è stato chiesto se la pianificazione del progetto iterativa o graduale è seguita per il progetto o meno, la metà degli intervistati ha indicato sì, e solo il 15% non ha seguito la pianificazione del progetto iterativo. È interessante notare che tutti coloro che non erano d’accordo con la pratica della pianificazione del progetto iterativo non avevano un piano di progetto in primo luogo.
Documentazione e rispetto degli standard
La documentazione di progetto funge da riferimento per l’analisi dei dati storici e aiuta le organizzazioni a migliorare continuamente i processi di gestione dei progetti e a sviluppare standard. La documentazione aiuterà anche a identificare le lezioni apprese e a modificare i sistemi di gestione dei progetti che porteranno alla maturità della gestione dei progetti. OMB300 e ISO9000 servono come guide nella progettazione di sistemi di documentazione di progetto. In particolare, molti progetti governativi sono tenuti ad aderire alle linee guida OMB300. Tra gli intervistati, l ‘ 80% ha affermato che i progetti IT che stavano gestendo avevano requisiti di documentazione come l’adesione a standard come ISO9000 e OMB300. Tuttavia, questi requisiti per i progetti di consulenza informatica sono applicabili in misura limitata.
Procedure di test di accettazione dell’utente
La soddisfazione del cliente è la misura primaria della qualità e del successo per gli articoli consegnabili del progetto. Pertanto, le procedure di test di accettazione dell’utente sono considerate importanti. Anche nel caso di risultati del progetto meno tangibili come il servizio, la misura sottostante del successo del progetto è la soddisfazione del cliente. Tuttavia, è soggettivo. Solo il 30% degli intervistati ha dichiarato di aver seguito le procedure di test di accettazione degli utenti durante tutto il progetto e il 45% degli intervistati non l’ha fatto.
Potere di prendere decisioni relative al progetto
In generale, i project manager dovrebbero avere mano libera per prendere decisioni relative al progetto senza l’intervento del cliente, quando queste decisioni non hanno alcun impatto importante sull’ambito del progetto o sui risultati del progetto. Solo il 15% ha convenuto che il project manager è autorizzato a prendere decisioni relative al progetto senza l’intervento del cliente. Circa il 40% è rimasto neutrale e il restante 45% ha dichiarato che il project manager non aveva questo potere. Dato che questi progetti sono progetti esterni e governativi, questi risultati hanno senso.
Conclusione
I risultati del nostro studio mostrano che la maggior parte dei progetti sono guidati da requisiti. Quasi tutti i progetti rappresentati in questo studio hanno dimostrato di essere adattabili al cambiamento. La comunicazione informale è considerata più importante dei processi e dei sistemi formali. Considerando che i progetti nello studio sono legati al lavoro del governo, i risultati mostrano che il team di progetto si è concentrato sull’esecuzione del progetto su una documentazione completa. Inoltre, la collaborazione con i clienti rispetto alla negoziazione del contratto funziona meglio per i team di progetto. Il frequente cambiamento dell’ambito del progetto indica l’importanza della pianificazione iterativa o graduale del progetto; una caratteristica importante della gestione agile del progetto. Dato che tutti i progetti di consulenza IT rappresentati in questo studio sono contratti, i risultati dello studio incoraggiano l’adozione formale di una metodologia agile per i progetti di consulenza IT e la loro combinazione con pratiche di gestione del progetto tradizionali come lo sviluppo e il monitoraggio di milestone guidati dal piano, le procedure di accettazione degli utenti e le pratiche di gestione della qualità.
L’idoneità del metodo agile per i progetti è l’obbligo contrattuale relativo ai documenti relativi alla pianificazione, al monitoraggio e al controllo del progetto. I progetti associati al governo federale di solito hanno requisiti di documentazione significativi, come l’adesione a standard come ISO9000 e OMB300; dovremmo esercitare cautela nel modificare il metodo agile per tali progetti.
La sfida consiste nel mantenere l’agilità, la risposta rapida al cambiamento, i piani flessibili e semplici, l’integrazione continua e altri vantaggi del metodo agile incorporando alcuni dei processi completi delle pratiche tradizionali di gestione del progetto.