IT Management blog

Con il 2009 riprendono le attività del Chapter del Sud Italia del Project Management Institute (http://www.pmi-sic.org) con un nuovo Seminario dal titolo “Il Project Management e il mercato del lavoro” il prossimo 28 Gennaio 2009, presso la splendida cornice del Palazzo PICO a Fuorigrotta, via Terracina.

Il tema scelto è caldo ed interessante: la relazione tra il mondo del lavoro e il project management. L’esperienza decennale della Dott.ssa Elisabetta Vernoni nel campo della formazione manageriale sarà preziosa per accompagnare gli ospiti nella scoperta e soluzione di questo interrogativo.

Maggiori informazioni sono disponibili nell’area apposita del sito del PMI-SIC, peraltro rinnovato di recente: http://www.pmi-sic.org/index.php?option=com_content&task=view&id=80&Itemid=1

Accanto alle classiche misure di performance dei progetti (Costi, tempi, earned value, etc…) si fa sempre piu’ strada il concetto di stabilita’ di progetto.

Si definisce stabilita’ di progetto (relative stability of a project) la resistenza (o viceversa, la sensibilita’) delle attivita’ e risorse di progetto ad eventi non pianificati. In altre parole, un progetto e’ stabile se riesce ad assorbire eventi non pianificati senza particolari ripercussioni sul piano originale. Un progetto si dice, invece, instabile quando, a fronte di eventi non pianificati, devia in modo significativo dal piano originale.

Si definiscono tre tipi di stabilita’:

• Stabilita’ positiva - quando un progetto, a fronte di eventi non pianificati, riesce a manternere invariato il piano originale (per esempio, a fronte di un ritardo di tre giorni su una consegna, la data di fine del progetto rimane invariata)
• Stabilita’ neutrale - quando un progetto, a fronte di eventi non pianificati, mantiene la variazione determinata dall’evento immodificata fino alla fine (per esempio, a fronte di un ritardo di tre giorni su una consegna, la data di fine del progetto viene ritardata degli stessi tre giorni)
• Stabilita’ Negativa - quando un progetto, a fronte di eventi non pianificati, subisce variazioni in misura maggiore a quelle determinate direttamente dall’evento (per esempio, a fronte di un ritardo di tre giorni su una consegna, la data di fine del progetto viene ritardata di un mese)

Ovviamente la stabilita’ di progetto, in molti casi, ha un costo, ed ovviamente anche un valore. Per avere un progetto a stabilita’ positiva (rispetto ai tempi) e’ spesso sufficiente costruire il piano con opportuni buffer di tempo tra un attivita’ e l’altra, in modo da poter assorbire ritardi. Questo sara’ tanto piu’ importante quanto l’ambiente di progetto e’ instabile (per esempio: si utilizzano nuove tecnologie, nuove risorse umane, possibilita’ di cambiamenti in corsa, etc…), mentre sara’ meno importante per progetti in ambienti relativamente stabili.

Certo e’ che i project manager di vecchio pelo queste cose le sanno gia’, pero’ adesso possono usare la nuova buzzword - Project stability - per giustificare i buffer al proprio management.

Nel numero di Dicembre 2008 del Project Management Journal del PMI è uscito un interessante articolo di Barry Shore, sugli effetti della cultura e dei pregiudizi sistemici sul fallimento dei progetti (Systematic Biases and Culture in Project Failures).

Il termine “pregiudizio sistemico” è generalmente usato per descrivere un pregiudizio che è endemico o inerente ad un sistema, specialmente un sistema umano. L’analogo per sistemi automatici viene chiamato errore sistemico. Il pregiudizio sistemico è generalmente un sottoprodotto della cultura dell’organizzazione e, nel caso dei progetti, della cultura del team di progetto.

Il motivo per cui, a mio parere, questo studio è interessante, ed in qualche modo diverso dagli studi classici sui progetti falliti, e che invece di concentrarsi sui gli aspetti metodologici come sorgente di errore, si concentra sugli aspetti culturali. Questo aspetto diventa tanto più importante quanto più le metodologie di project management si diffondono, facendo diminuire l’incidenza dei fallimenti per mancanze metodologiche.

I pregiudizi sistemici identificati nello studio sono i seguenti:

• Disponibilità dei dati (Availability of data) - Eccesso di attenzione ai dati analizzati solo perchè disponibili, non potrebbero dare una visione completa.
• Atteggiamento conservatore (Conservatism) - Difesa dello status quo e riluttanza ad accettare nuove informazioni o feedback negativo che lo minacci.
• Escalation dell’impegno (Escalation of Committment) - Aumento dell’impegno, anche economico e di risorse, in vista delle difficoltà e della possibilità del fallimento del progetto, senza considerare l’opportunità di chiuderlo.
• Pensiero di gruppo (Groupthink) - Membri di un gruppo che tendono a pensare nello stesso modo, rifiutando nuove prospettive che mettano in dubbio la propria.
• Illusione di controllo (Illusion of Control) - Convinzione, illusoria, del management di avere il controllo della situazione e che non deriva da valutazioni oggettive.
• Eccesso di confidenza (Overconfidence) - Livello di convinzione eccessivo che non deriva da valutazioni oggettive.
• Eccesso di importanza a eventi recenti (Recency) - Eccessiva enfasi fornita ai datit più recenti rispetto ad una visione più di largo respiro.
• Percezione selettiva (Selective Perception) - Situazione in cui diverse persone o gruppi percepiscono gli stessi dati od eventi in modo diverso, aumentando l’ambiguità della situazione.
• Responsabilità sui costi (Sunk Costs) - Inabilità di accettare le spese già effettuate come perse, tentando l’impossibile per giustificarle.

Nello studio che sottende all’articolo vengono analizzati un insieme di noti progetti falliti, tra i quali i seguenti:

• Design dell’Airbus 380, ove si sono identificati i seguenti pregiudizi sistemici: Disponibilità dei dati (Availability of data), Pensiero di gruppo (Groupthink), Illusione di controllo (Illusion of Control) e Percezione selettiva (Selective Perception).
• Disastro dello Shuttle Columbia, ove si sono identificati i seguenti pregiudizi sistemici: Atteggiamento conservatore (Conservatism), Eccesso di confidenza (Overconfidence) ed Eccesso di importanza a eventi recenti (Recency).
• Mars Climate Orbiter, ove si sono identificati i seguenti pregiudizi sistemici: Percezione selettiva (Selective Perception) e Responsabilità sui costi (Sunk Costs).
• Design della consolle Xbox 360, ove si sono identificati i seguenti pregiudizi sistemici: Atteggiamento conservatore (Conservatism), Pensiero di gruppo (Groupthink) e Responsabilità sui costi (Sunk Costs).

Ripreso dal sito ITIL, Italia: sarà presto in pubblicazione il volume:: “Delivering IT Services using ITIL, PRINCE2 and DSDM Atern”. L’uscita dell’interessante libro, parte della collana ufficiale su ITIL v3 dal TSO, è programmata per l’estate 2009. Offre consigli pratici per fornire servizi IT usando i tre framework: ITIL e PRINCE2 li conosciamo, mentre DSDM (Dynamic Systems Development Method), è una metodologia di project management ”agile” distribuita in modo gratuito dal consorzio omonimo ai propri membri. Oltre a discutere i tre framework, ne fornisce un sommario e descrive le aree di attenzione nell’implementazione degli stessi.
Link originale: http://www.itil-italia.com/apps/blog/entries/show/225465-fornire-servizi-it-con-itil-prince2-e-dsdm-

Dopo aver parlato qualche tempo fa’ di PRINCE2 e di due processi (Starting Up a Project ed Initiating a Project), ci occupiamo oggi del processo relativo alla chiusura del progetto: Closing a Project. Una delle definizioni stessa di Progetto in PRINCE2:

“Un organizzazione temporanea che ha lo scopo di produrre un risultato predefinito in un tempo predeterminato e con una quantita’ di risorse definita”,

implica che i progetti abbiano un “tempo predeterminato” e quindi una fine. Come tutte le cose, questa “fine” va gestita, ed il processo CP si occupa proprio di questo. I vantaggi di avere una chiara fine al progetto sono, tra gli altri, i seguenti:

• si evita di impantanarsi in un ciclo di utilizzo e modifiche del prodotto;
• si cede la gestione del “prodotto” generato dal progetto ai team “operativi” che si devono occupare del supporto del prodotto stesso;
• si da’ l’opportunita’ di documentare tutti gli obiettivi eventualmente non raggiunti e le lessons learned.

Il processo CP puo’ iniziare in uno dei seguenti modi:

• non appena l’ultimo stadio del progetto e’ stato approvato
• se si comprende che il progetto non e’ piu’ utile per vari motivi

Il Processo CP e’ composto dei seguenti sotto-processi:

• CP1 - Terminazione del Progetto (Decommissioning a Project). Questo sottoprocesso si occupa di assicurarsi che tutti i prodotti siano stati approvati e consegnati al cliente finale, che siano aderenti alle specifiche iniziali ed eventualmente passati a chi si deve occupare del supporto operativo. In questo sottoprocesso si raccolgono tutte i documenti di progetto e vengono opportunamente archiviati. Durante questo processo si comunica ufficialmente la chiusura del progetto a tutte le entita’ coinvolte.
• CP2 - Identificazione di azioni successive (Identifying follow-on actions). In questo sottoprocesso si identificano tutti gli obiettivi eventualmente non raggiunti e si definiscono le eventuali azioni successive in un documento formale (Follow on Actions Recommendations).
• CP3 - Valutazione del Progetto (Evaluating a Project). In questo sottoprocesso si raccolgono tutte le informazioni valide per un “apprendimento organizzativo” cioe’ le informazioni necessarie a valutare il progetto e quelle utili affinche’ si impari sia dalle scelte giuste che da quelle sbagliate, nei progetti successivi. Il documenti formali prodotti in questa fase sono le lessons learned e l’End Project Report.

Il sito ITIL, Italia (http://www.itil-italia.com/), dopo una pausa di qualche mese, si è preparato per il 2009 con parecchie novità:

• Una nuova veste grafica
• Nuove aree del sito per: ITIL v3, ISO 20000, PRINCE2

Il 19 Giugno a Milano, al Circolo della Stampa - Corso Venezia 16 si terra’ una conferenza dal tema molto interessante:

Service e Project Management: relazioni e sinergie

L’evento e’ organizzato da iCONS - Innovative Consulting ed iSYS - Innovative Systems in collaborazione con itSMF Italia.

Questo evento si svolge nel contesto del ciclo di seminari ITIL® dalla TEORIA alla PRATICA, gia’ pubblicizzato nel passato e si propone di indicare un metodo ed un percorso concreto per l’adozione dei processi del framework ITIL.

Questo tema risulta di particolare importanza nell’ambito di ITIL v3, ove il design e la transizione, che sono largamente project based, hanno assunto una dignita’ pari ai processi di operations. Rimane molto interessante capire come interagiscono tali processi e come gestire in modo organico e produttivo queste interrelazione. Cosi’ come sara’ utile capire quali siano le possibili sinergie e come trarne vantaggio.

Dopo aver illustrato le potenziali interrelazioni in essere verranno presentate linee guida e raccomandazioni finalizzate al miglioramento dell’efficienza operativa e tali da consentire una visione completa ed integrata delle attività di progetti e servizi.

Per maggiori informazioni andate sul sito itSMF italia (www.itsmf.it)

L’International Standards Organization (ISO) ha iniziato lo sviluppo dello standard ISO 21500, nuovo standard internazionale per il project management.

Lo standard ISO 21500 si basera’ su standard esistenti e su sviluppi gia’ effettuati a livello nazionale. Tra di essi vi saranno senz’altro il PMBOK® del PMI (www.pmi.org), che servira’ come base per la terminologia (a quanto pare). Per la suddivisione in processi si utilizzeranno input dal PMBOK®, dallo standard BSI 6079 ed IPMA (www.ipma.ch).
Lo standard dovrebbe, nelle intenzioni, essere applicabile ad organizzazioni di ogni dimensione e settore.

Lunedì, 31 Marzo 2008, il Southern Italy Chapter (http://www.pmi-sic.org) del Project Management Institute (http://www.pmi.org) organizza un seminario presso la Facoltà di Ingegneria dell’ Università Federico II a Napoli (c/o Aula Scipione Bobbio, Piazzale V. Tecchio, 80 - Napoli).

Il titolo esteso del seminario e’: “Program e Risk Management: Il caso A380 per Alena Aeronautica”. Il relatore sara’ l’Ing. Roberto Polidoro, Executive Vice President per i Programmi Airbus di Alenia Aeronautica ed esperto del settore.

L’iscrizione e’ obbligatoria (scusate per il breve preavviso…). Per iscriversi cliccate sul link seguente: http://www.pmi-sic.org/iscrizione_eventi/modulo_iscrizione_free.htm

Il risk management e’ senz’altro un argomento importante, ma senz’altro sara’ interessante seguire da una fonte primaria il caso di studio che e’ relativo all’arcinoto progetto Airbus A380.

Qualche post fa abbiamo analizzato il processo Starting up a project (SU) di PRINCE2, proseguiamo su quello traccia ed occupiamoci del secondo processo: Initiating a Project (IP).

Il processo IP inizia non appena il Project Board (l’autorita’ che dirige il processo in PRINCE2) approva il Mandato di progetto (Project Brief), preparato durante il processo precedente (SU).

Di fatto il processo SU e’ il primo vero e proprio processo del modello PRINCE2, in quanto, per essere precisi, il processo SU non fa parte del progetto in senso stretto, ma della fase di pre-progetto. Nel processo SU in effetti si stabilisce il Project Board, che e’ l’autorita’ massima del progetto che poi da’ il via ufficiale al progetto sulla base del Mandato di progetto.

Alcuni degli obiettivi di questo processo sono i seguenti:
 - Finalizzare il Project Initiation Document (PID)
 - Preparare lo Stage Plan per la prima fase di progetto
 - Documentare e confermare il Business Case per il progetto
 - Ottenere l’impegno delle varie parti
 - Assicurarsi che il Project Board assuma la “proprieta’” (ownership) del progetto
 

Il Processo IP e’ composto dei sotto processi:

IP1 - Pianificazione della Qualita’ (Planning Quality). Questo sottoprocesso si occupa di determinare i requisiti di qualita’ del progetto, nonche’ l’approccio da tenere durante il progetto rispetto alla qualita’. Sia i requisiti che l’approccio vanno documentati nel piano di qualita’ di progetto (Project Quality Plan)

IP2 - Pianificazione di progetto (Planning a Project). Questo sottoprocesso di occupa di creare il Piano di progetto (Project Plan). Il piano include le attivita’ principali, i deliverables, i costi , il ciclo di vita nonche’ le risorse necessarie allo svolgimento del progetto stesso.

IP3 - Affinamento del Business Case e dei rischi di progetto (Refining Business Case and Risks). Questo sottoprocesso si occupa di ampliare e verificare il Business Case descritto nel Mandato di Progetto (Project Brief) alla luce del piano di progetto. Lo stesso lavoro di ampliamento e verifica viene effettuato con riferimento ai rischi di progetto.

IP4 - Impostazione dei controlli di progetto (Setting up Project Controls). In questo sottoprocesso vengono definiti dei meccanismi di controllo per assicurarsi che ad ogni livello di progetto possano essere verificati il progresso (con riferimento al piano di progetto) e definite le misure correttive eventuali. In questo sottoprocesso viene anche definito un Communication Plan che chiarisca come, quando e a chi le informazioni vadano distribuite.

IP5 - Impostazione dell’archivio di Progetto (Setting Up Project Files). In questo sottoprocesso si sviluppa il sistema informativo di progetto, tra le altre cose di creano l’ Issue Log, il Lessons Learned Log ed il Daily Log.

IP6 - Creazione del Project Initiation Document (Assembling a PID). Nell’ultimo sotto processo del processo IP ci si occupa di creare il Project Initiation Document, che e’ il documento (fisico o logico) che abbia tutte le informazioni necessarie ad effettuare deciusioni sul progetto. Il PID sara’ riutilizzato durante tutta la durata del progetto.