Il vostro progetto è sta andando male. Voi ne siete a conoscienza e anche il vostro team. Ma in qualche modo dovrete cercare di salvarlo o limitare il più possibile i danni. Avete bisogno di una soluzione rapida che non c'è. Che cosa si può fare per tornare in carreggiata? Dal momento che le idee fino a ieri non hanno aiutato, ecco alcuni suggerimenti che potrebbero indicarvi la giusta direzione.

Ridefinire Lo Scope

Tornate alla documentazione prodotta in fase di pianificazione, Come ad esempio il Project Charter, la pianificazione dei task e assegnazione dei compiti e le richieste di modifica approvate. E' quindi essenziale  capire esattamente cosa vi siete impegnati a realizzare. Al contrario, documentare tutte le cose che sono state ufficiosamente aggiunte al progetto. Che cosa si sta cercando di ottenere è una chiara comprensione delle cose da fare e delle aspettative degli altri. Con queste liste in mano, fissate un incontro con lo sponsor del progetto (o equivalenti stakeholder chiave) e accordatevi per quali di questi deliverable dovrebbero essere oggetto degli sforzi attuali.

Rivedere lo schedule

Basandosi sul lavoro rimanente e sulle risorse correnti, ricalcolare lo schedule temporale. Dimenticate le deadline immesse sul progetto fino a questo punto. Data la quantità di lavoro e le persone disponibili, stabilire un calendario realistico per completare il progetto.

Determinate il costo

Analizzate qual è l'ammontare delle spese finora sostenute e quanto è il budget del progetto. Dopo aver calcolato la differenza tra i due importi (si spera non sia negativo) confrontatelo con quello che rimane da fare. In base al vostro scheduling rivisto, fate una nuova stima ragionevole dei costi necessari per completare il progetto.

Rivedere le "Lesson learned"

Organizzare un meeting con il team e gli altri stakeholder del progetto, per determinare dove il progetto è andato storto. Sviluppare un elenco di passi da compiere al fine di evitare che la prossima volta succededa la stessa cosa.

Sviluppare alternative

Analizzando la revisione dello Scope, Schedule e dei Costi, fate un'analisi delle opzioni disponibili. Basandosi sul Triangolo Del Project Management (o triangolo dei vincoli),  che mette in relazione, scope, tempi e costi uno contro l'altro, considerate l'impatto che ciascuna delle opzioni avrebbe su quei fattori. Il vostro piano include l'aggiunta di ulteriori risorse? Estendere la data? Ridurre lo scope? Potreste anche aver trovato una solida alternativa! In alcuni casi estremi, la decisione giusta sarà addirittura quella di annullare il progetto. Anche se una scelta impopolare, alcuni progetti devono essere sospesi. Ridurre la fase di test è invece di solito la scelta popolare, ma non è molto consigliabile.

Ammettere la realtà

Una volta che avrete prodotto e documentato un paio di alternative valide, dovrete presentarle al management. Iniziate con una buona dose di realtà. All'alta direzione non piace arrivare al fallimento del progetto. Odiano fare due volte le cose. Spiegate la situazione, preferibilmente senza inscenare il gioco delle colpe. Limitatevi a presentare i vostri piani per tornare in carreggiata. Consentite loro di parlare attraverso l'illustrazione delle opzioni e fatevi dare suggerimenti.

Nuovo inizio

Rilasciare un documento di rettifica dei deliverable, ottenere un nuovo finanziamento, riassettare lo schedule, ottenere le approvazioni del caso. Per qualunque di queste possibilità è stata data una nuova prospettiva al progetto. buttatevi subito sul nuovo piano e fare in modo di considerare la "lesson learned" appena acquisita, già dal vostro primo tentativo.

Fonte:  "How to really fix a failing project" di Thomas Cutting,PMP

Durante la fase di controllo di progetto, capita quotidianamente di fronteggiare l'insorgenza di problemi o azioni non previste. Quando questi si verificano, il project manager si troverà ad attuare delle azioni correttive. Ma dove è più conveniente intensificare i nostri sforzi? Facendo un passo ancora indietro, in fase di Pianificazione di progetto, in ottica di previsione dei rischi, quali sono le attività sui cui conviene intensificare il controllo?

L'Analisi di Pareto è una tecnica statistica nel processo decisionale che viene utilizzato per la selezione di un numero limitato di task che producono effetti significativi per il risultato finale. Utilizza il Principio di Pareto (noto anche come la regola 80/20) l'idea che facendo il 20% del lavoro è possibile generare l'80% del beneficio di fare tutto il lavoro. O in termini di miglioramento della qualità, la grande maggioranza dei problemi (80%) sono prodotti solo da alcune cause principali (20%). Questo è anche conosciuto come " the vital few and the trivial many".

Alla fine del 1940, Joseph M. Juran, guru del quality management, suggerisce il principio che prenderà poi il nome dall'economista italiano Vilfredo Pareto. Quest'ultimo osservò che l'80% del reddito in Italia andò al 20% della popolazione. Pareto in seguito svolse indagini su una serie di altri paesi e trovò con grande sorpresa una distribuzione del reddito analoga.

La regola 80/20 può essere applicato a quasi ogni cosa:

•     80% dei reclami dei clienti nascono dal 20% dei vostri prodotti o servizi.
•     80% dei ritardi nella programmazione deriva dal 20% delle possibili cause dei ritardi.
•     Il 20% dei vostri prodotti o servizi rappresentano l'80% dei tuoi guadagni.
•     Il 20% della vostra forza vendita produce l'80% del vostro fatturato aziendale.
•     Il 20% dei difetti di dei sistemi causa l'80% dei problemi.

Il Principio di Pareto ha molte applicazioni nel controllo qualità. E 'la base del "Diagramma di Pareto", uno degli strumenti principali utilizzati nel controllo della qualità totale e nel Six Sigma.

A livello di PMBOK, il diagramma Pareto è usato per guidare l'azione correttiva e per aiutare il team di progetto ad intervenire per risolvere innanzitutto, i problemi  che stanno causando il maggior numero di difetti.

Analisi di Pareto

Sette passi per identificare le cause importanti utilizzando l'analisi di Pareto:

1. Disegnare una tabella che elenca le cause e la loro frequenza in percentuale.
2. Disporre le righe in ordine decrescente di importanza delle cause. La causa più importante va per prima.
3. Aggiungere una colonna percentuale cumulativa alla tabella.
4. Segnare i punti sul grafico con le cause sulle ascisse e la percentuale cumulativa sulle ordinate
5. Unire i punti precedenti per formare una curva.
6. Plot (sullo stesso grafico) un grafico a barre con cause su asse x e la percentuale di frequenza su asse y.
7. Disegna una linea all' 80% sull'asse y, parallela all'asse delle ascisse. Poi fai cadere una linea nel punto di intersezione con la curva, sull'asse delle ascisse. Questo punto sull'asse x, separerà da ora in poi le cause importanti (a sinistra) dalle cause poco importante (sulla destra).

Questo è un semplice esempio di un diagramma di Pareto utilizzando dati di esempio che mostra la frequenza relativa delle cause per errori sui siti web. Vi permette di vedere quale 20% dei casi stanno causando l'80% dei problemi e dove gli sforzi dovrebbero essere concentrati per raggiungere il il miglioramento più significativo.

Il valore del principio di Pareto per un project manager, ricorda di concentrarsi sul 20% delle cose che contano. Tra tutte le azioni che farete durante il vostro progetto, solo il 20% sono davvero importanti. Quel 20% producono l'80% dei risultati. E' sempre opportuno quindi, identificare e concentrarsi prima sulle cose importanti, tuttavia non ignorando del tutto il restante 80% delle cause.

References:

• Wikipedia.com
• Projectsmart.co.uk

Quello che solitamente rende qualcuno un buon project manager è l'esperienza, il presupposto che abbiano fatto errori e imparato da essi in un vero ambiente di progetto e che abbiano avuto successo in seguito. L'esperienza su un insieme di diversi progetti e soprattutto su progetti complessi non può mai essere sottostimata. Ma non si può neanche sottostimare una qualifica individuale sia essa accademica o meno, e le relative certificazioni.

Un project manager con le giuste credenziali, ad esempio uno con la certificazione PMP, non è necessariamente migliore nella direzione dei progetti, ma la qualifica stessa è una indicazione della professionalità della persona. In sé stessa la qualifica è un indizio della determinazione nel raggiungere un obiettivo, il che spesso rappresenta una qualità molto importante quando si deve contribuire al successo di un progetto oppure al successo in una carriera.

E' anche vero che alcune organizzazioni incoraggiano i propri impiegati a diventare certificati insistendo sull'importanza del certificato stesso. Esse provvedono anche alle spese e concedono il tempo necessario all'esame. Alcune di esse addirittura offrono degli aumenti di stipendio a coloro che riescono a certificarsi PMP.
Ma ci sono anche organizzazioni di dimensioni più piccole seppur di successo che non enfatizzano troppo questi tipi di riconoscimenti, un pò per ragioni culturali ed un pò per ragioni di budget. E' comunque possibile che, visto che essere project manager è sempre più vicino ad essere riconosciuto come professione, anche l'enfasi sulle qualifiche e il continuo miglioramento personale possa assumere un peso crescente con il tempo.

Ci sono molti project manager esperti che sostengono di aver provato il loro valore con qualifiche di tipo accademico ed altre qualifiche nel corso degli anni, oltre all'esperienza lavorativa, quindi non vedono il motivo per ricevere ulteriori certificazioni.
A parte il continuo sviluppo personale una buona ragione è quella di aumentare comunque le proprie prospettive di carriera.
 

Perché quindi vale la pena prendere una certificazione PMP?

La certificazione PMP è un indice, per ogni azienda che vuole assumerti come project manager, del fatto che hai il giusto carico di esperienza e addestramento, oltre ad una buona conoscenza del PMI Body of Knowledge e principi generali del project management che ti hanno permesso di passare l'esame.
I pre requisiti dell'esame sono abbastanza stringenti, il che permette a questa certificazione di non essere un banale pezzo di carta, ma per accedervi il candidato deve dimostrare un'esperienza tra i 3 e 5 anni di gestione pratica di progetti.

Quindi il fatto che molti aziende in cerca di project manager pongano un peso significativo su questo tipo di certificazione è del tutto lecito. Molte organizzazioni infatti non effettuano neanche dei colloqui con persone che non hanno questa certificazione, e questo può essere di impiccio a tutti coloro che hanno fatto bene i project managers per anni ma che non hanno questa qualifica.
Ma allora come si fa a dire se un project manager con laurea specialistica e 10 anni di esperienza pratica è meno appetibile di un project manger con laurea triennale e solo 3 anni di esperienza ma certificato PMP?
Alcune aziende possono pensare che il secondo sia migliore ma è anche vero che nel mondo lavorativo molte aziende vanno oltre le credenziali. D'altro canto a parità di qualifiche è sempre meglio avere una certificazione che non averla.

Quindi, in buona sostanza, vale sicuramente la pena effettuare quei corsi che portano alla certificazione per qualifiche riconosciute a livello internazionale. Tali qualifiche infatti mettono in risalto il proprio curriculum vitae e aprono le porte per colloqui importanti dove si può far buona impressione per la propria conoscenza e le proprie esperienze.

In questo articolo vediamo come creare un Diagramma di Gantt attraverso uno dei diversi strumenti software online disponibili. Il software da noi utilizzato è in questo caso Attask, un software che conosciamo molto bene e che permette di effettuare una completa gestione di progetti e portfolio di progetti. In questo caso chiaramente ci limiteremo all'utilizzo dello strumento "Diagramma di Gantt". 

Chiaramente ci sono molti altri tool software che permettono la creazione di un Gantt chart, alcuni gratuiti ed altri non. Ad ogni modo tutti si assomigliano e rispecchiano grossomodo le stesse funzionalità che si possono trovare nel software illustrato.
In questo esempio vediamo una possibile implementazione di un Gantt relativo al processo di sviluppo di un sito web.

STEP 1: Iniziamo con un Gantt vuoto ed iniziamo a riempirlo con lo schedule delle nostre attività.

STEP2: Dopo aver definito quali sono le fasi e le attività da effettuare, si suddividono i task nelle varie fasi e si stabilisce la durata di ogni attività di livello inferiore.

STEP 3: A questo punto possiamo occuparci della creazione delle dipendenze tra i task. In questo caso abbiamo messo semplici dipendenze fine-inizio tra i task della prima fase. Abbiamo anche definito delle tipologie di dipendenze diverse come dipendenze inizio-inizio e delle date fisse per le fasi successive.

STEP 4: Infine possiamo completare il nostro gantt appena creato inserendo eventualmente i nomi delle persone assegnate ai task, le milestones.

Vuoi scoprire di più sul software ATTASK ?

Un ottimo modo per iniziare a pensare in maniera corretta è quella di porli gerarchicamente tra di loro. In cima alla gerarchia c'è il portfolio management, che contiene tutti i progetti ed i programmi secondo le priorità definite dagli obiettivi di business. Sotto c'è il program management che contiene numerosi progetti correlati, dal momento che essi supportano un obiettivo di business comune. I programmi sono pertanto composti da più progetti ma i progetti possono essere indipendenti tra di loro e far semplicemente parte del portfolio. I progetti sono diversi dai programmi semplicemente per la loro natura tattico-strategica.

Vediamo più nel dettaglio di ognuno di questi elementi di che cosa si tratta:

Portfolio Management

Uno dei punti chiave che distinguono il Project Portfolio Management è il fatto che sia un processo chiaramente caratterizzato dall'allineamento al business. Le priorità vengon decise tramite un appropriato processo di ottimizzazione per l'organizzazione. I rischi ed i guadagni vengono considerati e bilanciati ed i programmi vengono selezionati sulla base del loro allineamento alla strategia organizzativa. Dopo di che viene fornito un feedback per l'implementazione dei programmi e dei progetti in maniera tale che possano essere messi in atto i relativi aggiustamenti al portfolio, ammesso che siano necessari. I cambiamenti strategici richiedono anch'essi delle modifiche e degli aggiustamenti a livello di portfolio.

Program Management

Una caratteristica che distingue il program management è la sponsorizzazione del business. Quasi per definizione, in base alle decisioni prese a livello di Portfolio Management, i programmi vengono sponsorizzati a seconda delle necessità di business. Il programma si fa carico dei benefici e viene misurato prevalentemente a seconda dei risultati raggiunti su tali benefici. I programmi possono anche a volta avere dei "flussi di benefici" o dei benefici correlati dal momento che, ad esempio, l'aumento di capacità nel settore R&D combinato con l'aumento della penetrazione del mercato, può essere un beneficio cross funzionale nell'organizzazione. Dal momento che i programmi, che in genere consistono in più progetti, riguardano diverse funzioni in un'organizzazione, essi hanno tutti gli elementi che contraddistinguono un sistema di business e quindi sono orientati al general management.

Project Management

Il project management ha invece a che fare con il rilascio di risorse, come tipicamente viene definito all'interno di un programma. I progetti devono essere guidati dalla strategia ma non avere l'iniziativa strategica come invece fanno i programmi. Invece il progetto prende gli input e sviluppa ovvero implementa un piano tattico. Il monitoraggio durante il progetto e la misurazione finale del successo viene tipicamente basato più su delle considerazioni di natura tattica come budget e schedule piuttosto che sui raggiungimenti degli obiettivi strategici di business. Alcuni fattori chiave che sono coinvolti nel progetto e che impattano sulle scelte sono i seguenti:

- Industria: l'industria permette di farsi un'idea sulla stabilità e sulla consistenza delle operazioni. Alcune industrie, come quelle farmaceutiche, sono molto guidate dal ciclo di vita del prodotto, sebbene quelli particolarmente lunghi includano anche dei processi regolatori. Le aziende di elettronica di consumo invece hanno dei progetti con ciclo di vita molto più breve e, vista la rapida evoluzione della tecnologia, con poche regolazioni. Le aziende di costruzioni si basano molto sui progetti ed hanno a che fare con tecnologie e prodotti molto stabili.

- Grandezza dell'organizzazione: in genere maggiore è la grandezza e più formale è l'organizzazione. Senza una struttura, le relazioni tra strategie, portfolio management, programmi e progetti divengono presto indistinti e disuniti. I due punti principali sono avere dei framework organizzativi molto ben congeniati per ogni portfolio, programma e project management. Dopo di ché è necessario fare una grande attenzioni a creare dei forti legami tra di loro attraverso la comunicazione, la collaborazione ed il flusso informativo.

- Ampiezza operativo: quando ci si trova di fronte ad una capacità operativa più ristretta, come nel caso di organizzazioni finalizzate alle vendite o alla produzione, si tende a richiedere meno formalismo e le informazioni fluiscono più liberamente tra portfolio, programmi e processi di project management. Nelle organizzazioni ben integrate orizzontalmente, avere delle compentenze core ben sviluppate nell'R&D, marketing, produzione, distribuzione e similari porterà a delle separazioni naturali che dovranno essere gestite. Questo renderà il program management particolarmente stimolante dal momento che sarà facile che qualcuno scavalchi certi limiti.

- Strategia: come per le altre considerazioni in ambito operativo, la strategia avrà un impatto sul portolio, sui programmi, sul project management a seconda di quanto essa risulterà essere complessa. Una considerazione essenziale che non è ancora stata menzionata è l'alleanza strategica, che può influenzare fortemente il grado in cui i processi vengano gestiti e strutturati.

Gli standard per il Project Portfolio Management, il Program Management ed il Project Management esistono e portano con sé delle chiare definizioni di ogni ambito. Inoltre il Project Management Institute ha sviluppato e pubblicato i seguenti standard (gratuiti per i membri):

• Lo Standard per il Portfolio Management
• Lo Standard per il Program Management
• Una guida al Project Management Body of Knowledge (PMBOK)

Oggi molte organizzazioni hanno deciso di spostare il proprio sviluppo IT offshore per ridurre i costi ed aumentare la competitività. Il lavoro viene quindi mandato in posti come India, Cina e Russia. I risparmi in questi paesi è notevole, ma il risparmio totale in realtà è solo una parte rispetto a quello che ci possiamo immaginare.

Condurre progetti offshore è diverso da condurli in casa. Avendo parlato con diversi project manager ed avendolo provato in proprio, siamo in grado di dire che ci sono una serie di complicazioni che si ripetono quando si lavora in offshore, e questo vale per tutte le realtà. Identificarle prima di iniziare un progetto in offshore vi aiuterà ad essere preparati in maniera migliore. Ci sono infatti sei aree da considerare ed in queste si annidano tali complicazioni.
 

Capire la cultura

Questa è l'area più complessa e necessita di tempo per essere compresa. Le normative dei paesi occidentali non possono essere applicate in paesi come India e Cina. Senza una buona comprensione di tali culture è facile sbagliare e condurre il progetto verso il fallimento. Per questo è utile frequentare un corso per entrare nel merito di tale cultura. Un buon corso vi dirà cosa vi aspetta e come reagire oltre a quali strategie pianificare per avere a che fare con i diversi modi di lavorare.
 

Selezionare i progetti giusti per l'offshore

Alcune aziende adottano un approccio sbagliato, pensando poter fare a meno del loro team di sviluppo interno. Il problema invece è che non tutti i progetti si prestano allo sviluppo offshore. Dei buoni progetti per l'offshore sono quelli ben definiti, dove ci si aspettano pochi cambiamenti o che comunque prevedono del lavoro ripetitivo. I progetti che hanno bisogno di un grosso coinvolgimento del cliente o che probabilmente dovranno subire diversi cambiamenti durante lo sviluppo non sono idonei.
 

Definire i rilasci (scope)

I progetti offshore necessitano di una definizione più dettagliata rispetto a quelli fatti in casa. Dovete sincerarvi che tutto sia scritto e dettagliato e non assumere mai per ovvio o implicito un dettaglio. I benefici delle aziende che hanno fatto questo tipo di spin off sono il miglioramento della qualità nelle proprie specifiche tecniche e funzionali.
 

Avere quello per cui pagate

E' importante controllare se le persone ed i servizi per cui pagate vengano rilasciati. C'è infatti una tendenza a fornire delle situazioni a minor costo. Accordatevi in anticipo su quello che state comprando e controllate regolarmente quello che vi sta arrivando. Chiedete i curricula delle persone coinvolte e controllate che abbiano qualifiche ed esperienze rilevanti. Fate sopralluoghi regolari per controllare l'ambiente di lavoro e che vi siano tutti gli strumenti necessari.
 

Comunicazione efficace

Questa è in assoluto la parte più importante nel lavoro offshore. Dovrebbero essere  fatti i massimi sforzi nel set up di una buona struttura comunicativa. Non si può presupporre che le informazioni corrette verranno sempre passate alle persone giuste. E' importante accertarsi che lo siano per evitare problemi dopo. Una soluzione è quella di avere un company manager offshore, almeno inizialmente, per assicurarsi che ogni cosa scorra liscia.
 

Monitoraggio dello stato di avanzamento.

I termini "sviluppo offshore" e "black box" non dovrebbero stare nella stessa frase, questa idea non funziona. Lo sviluppo offshore ha bisogno di gestione o quantomeno di monitoraggio. E' molto importante avere delle milestone a breve raggio e dei deliverables frequenti in qualsiasi progetto offshore. Sta al cliente monitorare l'avanzamento dei lavori in quanto l'azienda offshore potrà tirar fuori dei problemi per salvarsi la faccia di fronte ad una milestone non rispettata.
 

Errori Comuni

• Non sono un modo veloce per tagliare il budget, occorrono da 3 mesi ad un anno per trasferire il lavoro ad un partner offshore e durante questo periodo di tempo il costo aumenterà, per cui non presumete di ridurre i costi in questo periodo.
• Impiegare braccia e gambe anziché cervelli. E' un luogo comune quello di pensare di ricevere degli sviluppatori esperti e molti praticanti o studenti che lo sviluppatore guiderà allo sviluppo dei pacchetti di lavoro. Queste persone invece spesso non sono capaci di prendere decisioni tecniche affidabili e in alcuni casi peggiori esse hanno solamente una conoscenza rudimentale della tecnologia con la quale stanno lavorando. Questo può portare ad un allungamento dei tempi di lavoro o ad una scarsa qualità.
• Mancanza di responsabilità. E' importante avere un punto di contatto singolo che possa prendere decisioni e farti avere quello di cui hai bisogno. Molto spesso il contatto non ha il potere per farlo oppure è stato messo lì solo per mantenere il cliente soddisfatto.
• Esperienza onshore. Non affidatevi solo sul telefono e sulla comunicazione via email. E' necessario che le figure chiave del partner offshore lavorino anche presso di voi in modo che possano capire la cultura aziendale e che cosa ci si attende da loro. Questo tipo di esperienza deve durare da 3 a sei mesi.

Le esperienze di lavoro offshore ci insegnano che può funzionare e che si può effettivamente risparmiare, ma anche che ci si deve preparare per anni di sforzi e grandi investimenti iniziali.

[Continua da parte 1/2 ]

Il Team

Il Team è responsabile della trasformazione degli oggetti presenti nel Product Backlog in funzionalità potenzialmente rilasciabili ad ogni Sprint. Lo Scrum Team è cross funzionale, ovvero è fatto da persone che hanno una o più capacità incluso, e non solo, il controllo qualità, lo sviluppo, il design di database e la business analysis. Il team è auto organizzato e auto gestito, per quello ognuno ha lo stesso titolo: Scrum Team Member.

La grandezza del team dovrebbe essere intorno alle 7 persone, più o meno 2. La grandezza non include chiaramente lo ScrumMaster ed il Product Owner a meno che essi siano pigs che lavorano su task inclusi nello Sprint Backlog.

Ostacoli alla transizione.

La metodologia Agile non è conforme alla metodologia PMI. Questo è in assoluto il più grande ostacolo da sorpassare ed è anche dove si formano i conflitti interni tra project manager a maggior ragione se si tratta di PMP di una certa esperienza. Per completare con successo la transizione il dipartimento deve scegliere un tipo di sviluppo o l'altro per tutti i progetti di sviluppo software. Il fallimento del rispetto di uno qualsiasi dei principi Agile porterà al fallimento della transizione.

Doppi Ruoli o due risorse differenti.

Ogni transizione ad Agile è di per sé un progetto. Quindi dovrà essere scelto un Project Manager per condurre la transizione. Oltre a questo, il ciclo di vita di uno ScrumMaster orbita intorno allo sviluppo software, che è solamente una parte del ciclo di vita dell'intero progetto.

Come ogni project manager sa, essere un Project Manager è un lavoro full time, lo stesso è essere uno Scrum Master. La domanda principale è: una singola risorsa può fare entrambi i ruoli? La risposta è dipende. Alcune aziende provano a riempire entrambe le posizioni con una singola risorsa, visti i vincoli di budget e anche per altre ragioni. Questo è un motivo assolutamente accettabile, ma non necessariamente il migliore. Un project manager che è anche uno ScrumMaster certificato può svolgere questo doppio ruolo, ma la scelta non è consigliata.
 

Deprogrammare i Project Managers

I project manager tradizionali guidati dalla pianificazione devono essere "deprogrammati" prima che essi possano diventare dei project managers agile di successo. Il presidente Eisenhower soleva dire: "La pianificazione è essenziale, i piani sono inutili". Questa frase è in realtà lo specchio della differenza principale tra Agile e PMI. Il successo in questo modo non viene più misurato da quando ben bilanciati siano i tre vincoli, ma viene solamente misurato dal cliente. L'ambito del progetto non è più il fattore guida, anzi sono il tempo ed il budget a guidarlo. Il successo non viene più misurato dal completamento dei tasks e dalle revisioni delle fasi, ma viene misurato il rilascio delle features e delle funzioni. Infine si deve imparare comprendere il cambiamento, ad amarlo ed a vivere per esso.
 

Lavorare Insieme.

Il Project Manager e lo ScrumMaster devono essere trattati alla pari se si vuole che il progetto abbia successo. Il Project Manager è in capo all'intero progetto, mentre lo ScrumMaster lo è solamente riguardo alla parte di sviluppo software del progetto. E' molto importante che il management rispetti questa differenza.
Durante lo sviluppo software vero e proprio, il project manager deve permettere allo ScrumMaster di utilizzare Scrum con la metodologia Agile, non la metodologia PMI. Come Project Manager, la parte difficile è quella di lasciar andare e fidarsi dello ScrumMaster. Questa parte può essere vista come una black box, il Project Manager qui è considerato come "chicken", può ascoltare ma non deve farsi carico di nessun peso.
 

Diventare veramente Agile.

Molte aziende sentono di essere Agile semplicemente perché stanno facendo sviluppo software in modo iterativo. Ad ogni modo adottare un modello a cascata in modo iterativo non è assolutamente Agile. Agile infatti è molto di più che un semplice sistema di sviluppo iterativo con rilasci rapidi. Il pensiero tradizionale PMI non può far da guida durante l'implementazione di Agile, per diventare veramente Agile tutto il dipartimento IT deve affrontare un vero e proprio cambio di paradigma.

I project managers IT tradizionali hanno sempre faticato ad utilizzare la metodologia PMI nonostante sia utilizzato per molto tempo per lo sviluppo software. Utilizzare la metodologia di project management tradizionale per lo sviluppo software è come cercare di forzare una situazione che non potrà mai essere adattata al meglio.

Negli ultimi anni la metodologia Agile ha iniziato a guadagnare peso. Questo in larga parte è dovuto alla popolarità di Scrum, anche se Agile è sul mercato già da circa 20 anni. Scrum è uno dei diversi framework che ricadono nell'ambito Agile, tra gli altri ci sono Extreme Programming (XP), Rational Unified Process (RUP), e Design for Six Sigma.

Teoria del controllo.

Ci sono due tipi diversi di teoria del controllo, il primo è il processo teoretico, ovvero quello che seguono i project managers tradizionali e che riguarda il comando ed il controllo. Esso prevede un sacco di pianificazione, la pianificazione di quello che ci si aspetta che succeda ed il conseguente rafforzamento del piano spesso senza tenere conto delle condizioni. Infine questi processi fanno largo utilizzo del cambio di controllo, spesso viene cambiato il comitato di controllo che ha in carico la supervisione delle richieste di cambiamento.

Scrum dall'altra parte utilizza quello che viene definito il processo empirico. In questo processo, a differenza del precedente, si impara mentre di lavora. Invece di pianificare tutto prima della partenza e di pianificare come si gestirà il cambiamento, il processo empirico stabilisce di "pianificare per il cambiamento". Quindi il processo empirico abbraccia il cambiamento attraverso il metodo dell'ispezione e dell'adattamento, che sono due dei tre pilastri fondamentali di ogni implementazione del processo di controllo empirico.

I tre pilastri

I project management tradizionale per anni ha sempre seguito il "triangolo dei vincoli": tempo, costo e qualità. Questi sono sempre i tre pilastri entro i quali un project manager si deve destreggiare. In un mondo ideale i progetti sarebbero rilasciati nelle tempistiche e nel budget stabiliti con la qualità migliore. Nella realtà questo accade molto raramente. Per i progetti di sviluppo software non accade mai di ottenere che tutti e 3 questi elementi vengano rispettati.

Anche uno ScrumMaster segue tre pilastri che sono la trasparenza, l'ispezione e l'adattamento. La trasparenza prevede una comunicazione aperta con tutti i membri del progetto Scrum e lo ScrumMaster mostra con orgoglio ai membri del proprio team i burn-down chars in modo tale che tutti siano al corrente dell'andamento del progetto. Essi effettuano anche dei controlli per vedere quanto siano andati bene durante il loro sprint, procedimento conosciuto come Sprint Review. Infine l'adattamento comporta apportare dei cambiamenti e miglioramenti ad i task che possono essere migliorati.

Iniziare la transizione.

Per molte aziende che cercano di fare una transizione verso Agile, la prima cosa è quella di capire che essere un buon project manager non serve necessariamente per essere un buono ScrumMaster. Essi infatti non sono interscambiabili. Al contrario di quanto si possa pensare, un buono ScrumMaster non deve avere esperienza di Project Management.

Essendo un problema di pratica, i migliori ScrumMaster sono in genere molto tecnici. Questo perché essi possono avere una migliore empatia con gli sviluppatori e capire quale sia la grande differenza tra il livello di sforzo e la durata e quindi anche prioritizzare al meglio le caratteristiche del prodotto, assieme al Product Owner.
 

Conoscere il proprio ruolo.

Ci sono tre ruoli principali in Scrum: ScrumMaster, Product Ownler ed il Team. Spesso sentirai chiamare persone "chicken" o "pigs". Le persone che fanno parte di questi tre ruoli principali vengono spesse chiamate "pigs" mentre ogni altra persone viene chiamata "chickens". Un "pig" è qualcuno che fa parte del progetto mentre un "chicken" è una persona coinvolta in qualche modo.
 

ScrumMaster

Il lavoro principale dello ScrumMaster è quello di aderire ai valori di Scrum, alle sue pratiche ed alle regole. Essi sono i sostenitori di Scrum ed aiutano a far sì che Scrum venga accettato ed adottato in tutta l'organizzazione. Essi possono essere anche visti come degli "scudi" in quanto proteggono il team dal rumore esterno ed assicurano che nessuno si rivolga direttamente ad un team member senza aver seguito la catena di comando appropriata. Questo permette al team di rimanere concentrato sul lavoro e, se emerge una qualsiasi priorità, lo ScrumMaster ed il Product Owner ne discuteranno e sceglieranno la priorità entro il Product Backlog come è appropriato.

[... continua in parte 2/2 ...]

I software project management non servono solamente per gestire progetti software ma possono essere utilizzati in molti altri campi. Questi software web based forniscono infatti strumenti per la pianificazione, l'organizzazione e la gestione delle risorse che permettono di raggiungere gli obiettivi di progetto.

Un project maangement software web based è un tipo di software al quale posso avere accesso tramite una intranet, una WAN, LAN o Internet utilizzando il browser. Questo vuol dire che non avrai mai la necessità di installare il software sul tuo sistema. Tramite questo tipo di software si possono anche gestire il controllo sugli accessi dei diversi utenti.

Elementi comuni a questi strumenti sono strumenti quali le issue e bug tracking, il calendario degli eventi e delle attività, i gantt chart, le notifiche email ecc.

I software che andiamo ad elencare sono stati tratti liberamente dal web, non sono gli unici e, dal momento che il mercato del software è in costante evoluzione, ciascuno di essi migliorerà e aggiungerà le proprie funzionalità in modo da allargare il proprio mercato nel corso del tempo.

1 – Codendi:

Codendi è una piattaforma open source per lo sviluppo collaborativo offerta da Xerox. In una sola interfaccia raccoglie tutti gli strumenti necessari ai team di sviluppo software: gestione e versioning di codice, bugs, requisiti, documenti, reporting, test ecc. Viene utilizzata prevalentemente per la gestione di progetti software.

Scarica Codendi -> http://www.codendi.com/index_en.php

2 – Redmine

Redmine è una applicazione web per il project management molto flessibile. E' stata scritta utilizzando il framework Ruby on Rails ed è cross-platform e cross-database. Include sia i calendari che i gantt chart per riprodurre in modo visuale i progetti e le rispettive scadenze.

Scarica Redmine -> http://www.redmine.org/

3 – ProjectPier

ProjectPier è un'applicazione php free, open-source e self hosted che permette di gestire i task, i progetti ed i relativi team tramite un'interfaccia web intuitiva. ProjectPier aiuterà la tua organizzazione a comunicare, collaborare e completare le attività tramite le proprie funzioni che risultano similia prodotti commerciali per il groupware e project management ma fornisce anche la libertà e la scalabilità del self hosting.

Scarica ProjectPier -> http://www.projectpier.org/

4 – Trac

Trac è uno strumento open source e web based utilizzato per il bug tracking. Trac permette di linkare le informazioni tra un database dei bug, la gestione di requisiti ed i contenuti in formato wiki. Lo strumento fornisce una interfaccia web ad un sistema di controllo del versioning come Subversion, Git, Mercurial, Bazaar e Darcs.

Scarica Trac -> http://trac.edgewall.org/

5 – ProjectHQ

Project HQ è uno strumento collaborativo ed open source per il project management simile a Basecamp ed activeCollab. Project HQ è creato in tecnologie open source quali Python, Pylons e SQLAlchemy ed è totalmente database independent. ProjectHQ utilizza un workflow strutturato per agevolare la gestione dei propri progetti.

Scarica Project HQ -> http://projecthq.org/

6 – Collabtive

Collabtive è un project management software web-based pubblicato come software open source. Questo progetto è iniziato nel Novembre 2007, il suo scopo principale è quello di fornire una valida alternativa open source a software proprietari quali Basecamp o ActiveCollab.

Scarica Collabtive -> http://collabtive.o-dyn.de/

7 – eGroupWare

eGroupWare è un software di groupware open source creato per ogni tipo di business, dai più piccoli ai più grandi. Le proprie funzioni principali permettono agli utenti di gestire i contatti, gli appuntamenti, i progetti e le liste to-do.
Questo prodotto viene utilizzato tramite la propria interfaccia web nativa, rendendo l'accesso platform independent, oppure utilizzando diversi client supportati quali Kontact, Novell Evolution oppure Microsoft Outolook. Vi si può accedere anche tramite un telefono cellulare o un PDA tramite SyncML.

Scarica eGroupWare ->  http://www.egroupware.org/Home

8 – KForge

KForge è un sistema open source (GPL) per la gestione di progetti software. Questo software riutilizza parti dei migliori sistemi in circolazione, come subversion, trac e moinmoin e li integra con il proprio sistema per quanto riguarda la parte di gestione progetti, utenti e permessi. KForge offre anche una interfaccia web completa per l'amministrazione dei progetti ed un sistema di plugin che consente di aggiungere nuovi servizi e funzionalità in maniera semplice.

Scarica -> KForge -> http://www.kforgeproject.com/

9 – OpenGoo

OpenGoo è una soluzione online completa che si concentra sul miglioramento della produttività, della collaborazione, della comunicazione e nella gestione del proprio team. Le principali caratteristiche di OpenGoo sono il document management, il contact management, e-mail, project management e time management. I documenti di testo e le presentazioni possono essere create facilmente e comodamente online. I files possono essere gestiti tramite upload, organizzati e condivisi indipendentemente dal tipo di formato.

Scarica OpenGoo -> http://www.opengoo.org/

10 – ClockingIT

ClockingIT è una soluzione per il project management gratuita che aiuta il proprio team a mantenersi concentrato sulle attività di progetto.

Scarica ClockingIT – > http://wiki.clockingit.com/

Durante la pratica dei processi Agile e Lean non si può fare a meno di dare la priorità alle azioni che apportano un aumento di valore. Quando si ha a che fare con la documentazione, molte persone che hanno solo una conoscenza superficiale di Agile potrebbero pensare che tale metodologia porti a una riduzione se non addirittura ad un'assenza della documentazione di progetto.

Invece tale metodologia dovrebbe essere più incentrata sulla creazione di pianificazioni importanti. Se questo significa documentazione, allora essa dovrebbe aggiungere valore ed essere della quantità appropriata. La documentazione non deve essere fine a se stessa.
Mentre molti tecnici sono riluttanti al solo pensiero della documentazione, in realtà essa può portare a dei benefici reali, tra i quali:

1. Determinare ciò che gli altri devono sapere.

Provate a pensare a tutti gli aspetti del progetto, l'implementazione, il supporto post lancio ed il mantenimento per determinare ciò che potrebbe essere necessario al team principale ed ai membri del team di supporto.
Se il team dedicato all'implementazione non è lo stesso team di supporto, sicuramente sarà necessario redarre una documentazione specifica. Analizzare con attenzione quello che di cui gli altri potrebbero aver bisogno vi darà una garanzia di spendere meglio il vostro tempo.

2. Determinare il metodo e lo stile appropriati.

Una volta che avete capito il contenuto ed il tipo di documentazione necessari, potete cercare di capire la tipologia e lo stile da utilizzare a seconda di chi dovrà leggere il vostro lavoro.
La documentazione dovrebbe essere in una pagina web ricercabile, come una pagina wiki, oppure essere in qualche modo più formale. Lo stile di scrittura ed il metodo di rilascio dovrebbero basarsi sull'audience.

3. Determinare un processo di aggiornamento.

Questa è in effetti la parte più difficile. Mantenere aggiornata una documentazione richiede un processo ben disciplinato. In accordo ai nostri schedule di progetto dovremmo pianificare un aggiornamento continuo della documentazione ed assicurarsi il tempo necessario per effettuare tali attività. Una volta preso un certo ritmo con la documentazione, vale la pena lavorare sodo per mantenerla aggiornata. Fermare questa attività per riprenderla dopo un periodo di inattività potrebbe essere molto difficile e rendere impossibile recuperare quanto lasciato indietro.

4. Considerare altri benefici e possibili campi di applicazione.

Mentre nei primi 3 punti ci siamo focalizzati sul fatto di fornire la documentazione per supportare un progetto o la comunicazione con gli altri, in questo punto possiamo vedere come il processo di documentazione possa anche diventare un esercizio di pianificazione.
Il processo di documentazione infatti richiede un pensiero analitico che ricopra svariati aspetti. Questo già in sé può essere un esercizio molto utile. E' pertanto auspicabile che durante questo esercizio si identifichino quali sono le più importanti aree di rischio e determinare quali attività di documentazione sono necessarie per tali aree.

La documentazione in fondo è una forma di documentazione, quindi prendere delle buone decisioni su "che cosa documentare", sul metodo, sullo stile e infine sul processo documentativo in sé è molto importante. Ogni attività all'interno dei nostri progetti richiede una considerazione molto attenta, con la documentazione è lo stesso.
Per essere efficace dovrai infatti tener presente un obiettivo specifico così come l'audience a cui è rivolto il tuo lavoro.