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.

Definizione Del Business Case

Il nostro processo di software selection nasce con l'acquisizione e la comprensione dei Critical Success Factors (CSF) in cui definiamo tutte quelle cose che un'organizzazione deve fare al meglio per avere raggiungere il successo secondo obiettivi strategici fissati. Definiremo per tanto un meeting con i membri del management/executive in cui i saranno identificati tutti i CSFs piuttosto che i requisiti chiave ed i KPIs (Key Performance Indicators).
Ci sono molti modi per raggiungere i CSF ma il nostro focus è in questo caso sul miglior software di project management o project portfolio management che più si adatta alla realtà aziendale. La nostra indagine prosegue quindi sul chiedere quali sono le funzionalità di sistema che potrebbero aiutare a raggiungere i CSFs. Ciò si traduce dalla nostra parte in requisiti critici per le funzionalità che avrà il nuovo sistema. Analizzeremo inoltre come sono misurati i CSFs, ovvero i KPIs, insieme alle metriche dei KPI goals per il nuovo sistema.

Revisione dei Processi Di Business

LA fase successiva del nostro processo è capire e mappare gli attuali processi di business. Documenteremo le varie attività, fasi, cicli di approvazione, problemi, l'impatto dei problemi e i requisiti. Forniremo dei Flow chart che aiuteranno a capire la correlazione tra le varie fasi. La nostra attenzione sarà incentrata sui problemi. Un nuovo sistema è la miglior oppurtunità per un'organizzazione di risolvere i problemi. Ogni problema infatti dovrebbe essere considerato un'opportunità. L'impatto permette di sapere cosa è utile e importante in un business case. I requisiti sono basati sui punti di forza del sistema esistente e sulle funzionalità che potrebbero potenzialmente risolvere i problemi. Gli "swimlane" flowchart sono un modo semplice ed esplicativo di visualizzare il flusso dei processi di business.

Analisi Requisiti

In questa fase creiamo un documento dei requisiti che contiene requisiti chiave e unici. Il documento ha lo scopo di essere chiaro, non ambiguo e di non annoiare con funzionalità base. Incontreremo le esigenze del cliente, basandoci ovviamente anche sulla nostra esperienza nel settore dei software di project Management, selezionandoli in base all'infrastruttura di rete disponibile, alla collaborazione richiesta tra i vari attori dei progetti, al budget per l'acquisto, ecc… Ogni requisito sarà confermato e prioritizzato.

Analisi dei Fornitori

I requisiti saranno racchiusi in una richiesta, inviata poi ai potenziali fornitori. Prepareremo un'analisi preliminare dei fornitori includendo costi, punteggio delle loro rispondenze, infrastruttura di rete, informazioni sulle release e sulle implementazioni. La presentazione dei fornitori ad alto livello, sarà facilmente comprensibile in base alle nostre esplicative check list precedentemente preparate.

Negozazione contratto

Assistiamo il cliente nella negozazione del contratto per assicurare termini favorevoli e ottimi prezzi.

Vuoi conoscere nel dettaglio i nostri criteri ?

Per maggiori informazioni compila il form  ed inviaci la richiesta?

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 ?

         VAI AL SITO DEL PRODOTTO

Un Social Network o un Software di Project Management?

TeamLab è una piattaforma creata da Ascensio System Limited per la collaborazione commerciale e la gestione dei progetti. E' disponibile in versione Free SaaS (Software as a Service) , Open Source e Premium a pagamento.
La piattaforma TeamLab è fondata sull'idea di rendere più efficiente il social networking e la gestione dei progetti. Una varietà di funzioni offerte permettono alla società di funzionare come un unico organismo al fine di realizzare i compiti aziendali e ottenere ottimi risultati.

Panoramica

Teamlab è una soluzione web based di gestione e collaborazione gratuita . Il target sono le piccole imprese. Il software unisce buoni strumenti per il lavoro in team ad ad ottimi tools per Collaborazione online.

TeamLab comprende 3 sezioni principali:

1. gestione dei progetti online;

2. collaborazione e comunicazione online;

3. gestione dei documenti online

L'interfaccia grafica è molto user friendly ed è proprio la facilità di utilizzo che identifica Teamlab come uno strumento gradevole ed intuibile da usare. Per l'utilizzo non è richiesta nessuna conoscenza approfondita. installazione di TeamLab offre 3 soluzioni offerte:

1. Versione SaaS in linea è destinata alle società interessate al servizio già pronto.

2. Versione open-source è destinata agli utenti esperti che desiderano configurare e sostenere il portale sul loro server.

3. Server  di Amazon (AMI) è destinata alle società che desiderano utilizzare TeamLab sul proprio server virtuale di Amazon.

Gestione dei progetti

Teamlab offre delle funzionalità versatili ed affidabili che soddisfano le esigenze basilari della gestione di un progetto. Si possono aggiungere nuovi progetti, impostare milestone, creare ed assegnare compiti, lasciare i commenti ad ogni compito oppure iniziare una discussione relativa ad un certo progetto. Così il responsabile del progetto tiene traccia del progresso di lavoro e quindi valuta il contributo di ogni membro della squadra . Da segnare invece, la totale mancanza di strumenti di pianificazione come il Diagramma di Gantt, cosa che lo pone un po' al di sotto di un vero e proprio software canonico di Project Management

Collaborazione

Grazie a strumenti di comunicazione avanzati come wiki, chat in linea, segnalibri, forum di discussione, blog e sondaggi, i membri della squadra possono liberamente esprimere le loro opinioni, trovare i nuovi approcci per la realizzazione dei compiti impegnativi e creare una base di conoscenza comune condivisa.

Gestione dei documenti

L'elaborazione dei documenti online è forse una delle parti più interessanti di TeamLab. Si possono caricare documenti (PowerPoint, Word, fogli elettronici, PDF, ecc.), condividerli con la squadra o renderli accessibili agli altri utenti del portale. Così ogni membro della squadra può visualizzare e modificare la documentazione di progetto 24 ore su 24, 7 giorni su 7.

Quindi, per conludere, TeamLab permette agli utenti di comunicare, collaborare e gestire i progetti senza difficoltà. Non è paragonabile ad un vero software di project management come Attask, MS Project o Oracle Primavera, ma può essere utile per chiunque cerchi un prodotto gratis senza molte pretese, ma che incrementi la collaborazione e l'organizzazione del proprio team di lavoro.

Sviluppi Futuri:

Al fine di presentare un prodotto ancor più competitivo, il team di sviluppo di Ascensio System sta lavorando non solo sull'incorporamento del Diagramma di Gantt, ma anche su una sezione per la gestione dei clienti, sul calendario delle attività e su un sistema di posta elettronica integrato. Se le aspettative verranno rispettate, avremmo davanti un prodotto gratuito, veramente di tutto rispetto.

Pro:

    gratuito

    interfaccia molto semplice da usare

    3 soluzioni di servizio

    Server veleoce anche in modalità gratuita SaaS

    ottima combinazione degli strumenti di gestione dei progetti e di collaborazione

Contro:

    diagramma di Gantt è assente

    impostazione dei diritti di accesso è una funzionalità premium a pagamento

VAI AL SITO DEL PRODOTTO

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 ...]