IT Management blog

Un interessante post nel sito ITIL, Italia descrive il sistema di gestione in ISO 20000. Nello standard, l’obiettivo del sistema di gestione e’ quello di fornire le politiche (policies), procedure ed il contesto (framework) per consentire una effettiva gestione ed implementazione dei servizi IT.

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

Uno dei processi piu’ affascinanti introdotti in ITIL v3 e’ senza dubbio il processo di Knowledge management (o Gestione della Conoscenza). In qualche modo rimette il fattore umano all’interno del meccanismo perfetto (?) dell’IT service management. Il sito ITIL, Italia ci da’ alcuni spunti sul Knowledge Management che vi riassumo in breve di seguito.

Lo scopo principale di questo processo e’ di assicurare che le giuste informazioni siano disponibili a chi deve prendere delle decisioni, sia a livello di top management sia a livello di service desk staff.

Il processo di Gestione della Conoscenza e’ parte del Service Transition in quanto e’ uno degli elementi che e’ fondamentale “transitare” nell’ambiente di produzione. Gli utenti finali, lo staff del service desk ed altro staff di supporto devono avere le informazioni necessarie prima che il sistema nuovo venga “transitato” in produzione in modo da facilitarne l’adozione e da assicurare il corretto svolgimento dei rispettivi ruoli.

Un concetto importante nell’ambito della Gestione della Conoscenza e’ la struttura Dati-Informazioni-Conoscenza-Saggezza (Data-to-Information-to-Knowledge-to-Wisdom o DIKW), che non e’ altro che un metodo per capire le relazioni che intercorrono tra i dati, le informazioni, la conoscenza e la saggezza e spiega come ciascuno di questi elementi si basa sugli altri.

Naturalmente, occorre un sistema per aiutare nella gestione della conoscenza, che, secondo il glossario ufficiale italiano di ITIL v3, si chiama Sistema di gestione della conoscenza del servizio (Service Knowledge Management System o SKMS), ed e’ un insieme di strumenti e database che vengono utilizzati per gestire la conoscenza e le informazioni. Il SKMS, tra tanti altri elementi, include anche il Configuration Management System, così come altri strumenti e database. Il SKMS archivia, gestisce, aggiorna e mostra tutte le informazioni di cui un fornitore di Servizi IT necessita per gestire i servizi IT, durante tutto il ciclo di vita. Ovviamente tutte queste informazioni, come dicevamo prima, non sono tutte “informatizzabili” e spesso comprendono anche elementi quali:

• L’esperienza dello staff
• L’esperienza e conosenza degli utenti
• Informazioni esterne quali, dati aziendali, finanziarie, politiche etc.. che possono essere rilevanti per il supporto del servizio

Il SKMS e’ un po’ il cuore del processo di gestione della conoscenza, e, come tutte le cose va pianificato e gestito opportunamente.

Le informazioni da me riassunte sopra sono disponibili sul sito ITIL, Italia oppure direttamente sulla parte relativa al Knowledge Management.

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.

Fortunatamente il sito ITIL, Italia ci da ancora alcuni spunti per scrivere e ci fornisce ancora una volta nuovi contenuti in italiano su  ITIL v3.

Oggi tocca al processo di Access Management, nuovo con ITIL v3. Questo processo e’ parte del Service Operation nell’ambito del lifecycle di ITIL v3.Gli obiettivi di questo processo sono di fornire agli utenti i diritti per usare uno o piu’ servizi ed eseguire le politiche definite nei processi di Availability e Security Management 

Da quanto sopra si evince che questo processo e’ l’attuazione in pratica, appunto nel Service Operations - nell’operare quotidiano, di alcuni aspetti del Security Management relativi alla fornitura dei diritti di accesso (ed alcuni aspetti di Availability Management, in particolare quelli relativi al rendere disponibili le informazioni solo a chi e’ autorizzato).

Nel processo di Access Management si definiscono i concetti di accesso, identita’ e diritti (o privilegi). Tipicamente, il processo di Access Management viene svolto dal Service Desk, se necessario, il Service Desk passa la richiesta ad altri gruppi, anche se e’ utile che queste richieste possano essere tutte delegate al Service Desk, almeno per i tipi di accesso piu’ comuni.

Il processo si svolge, tipicamente, nelle fasi di richiesta di accesso,verifica, fornitura dell’accesso, monitoraggio dei cambi di stato, logging degli accessi, revoca o riduzione dell’accesso.

Maggiori dettagli nella parte del sito ITIL, Italia dedicata all’Access Management.

Il sito ITIL, Italia ci fornisce ancora una volta nuovi contenuti su  ITIL v3. Oggi tocca al processo di Request Fulfilment.

Il processo di Request Fulfilment e’ nuovo con ITIL v3. Questo processo e’ parte del Service Operation nell’ambito del lifecycle in ITIL v3. Gli obiettivi di questo processo sono sostanzialmente di fornire agli utenti un canale per richiedere (e ricevere) servizi standard per i quali esiste uno schema predefinito di approvazione (i.e. richiesta di un computer). Nell’ambito del processo di Request Fulfilment si definisce la Service Request come: una richiesta da un utente per un informazione, consiglio, un cambiamento standard (standard change) o per un accesso ad un servizio IT.

Le attivita’ del processo di Request Fulfilment in ITIL v2 erano incluse nel processo di Incident Management, ove si suggeriva di utilizzare per le Service request lo stesso workflow degli incidenti. Uno dei motivi per cui si e’ deciso di separare le due cose e’ che gli incidenti sono non-schedulabili o non-pianificabili, mentre le service request possono e devono essere pianificate.

Una trattazione piu’ approfondita e’ disponibile sulla pagine relativa (qui) del sito ITIL, Italia.

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

L’obiettivo principale del processo di Gestione della sicurezza delle informazioni (Information Security Management o ISM), parte del Service Design in ITIL v3, è di allineare la sicurezza delle informazioni alla sicurezza attesa dal business ed assicurarsi che la sicurezza delle informazioni sia gestita in maniera efficace in tutte le attività di fornitura e gestione dei servizi.

Il processo di ISM dovrebbe essere il punto centrale per tutte le problematiche relative alla sicurezza delle informazioni, ed è responsabile per la creazione, manutenzione ed attuazione delle politiche e piani di sicurezza. Il processo di ISM deve tenere ben presente le politiche aziendali sulla sicurezza ed allinearsi ad esse, tenendo presente che è inutile avere il migliore sistema antiintrusione informatica, se chiunque ha accesso fisico ai server.

Un sistema di gestione della sicurezza delle informazioni (Information Security Management System o ISMS) a supporto del processo di ISM deve includere elementi di Controllo, Pianificazione, Implementazione, Valutazione e Manutenzione

Nella gestione degli incidenti relativi alla sicurezza (security incidents) si possono identificare i seguenti stadi:

• Preventivo - Le misure di sicurezza sono definite con lo scopo di evitare (prevenire) incidenti (per esempio rimuovere accessi a chi non ne ha bisogno)
• Riduttivo - Le misure di sicurezza sono orientate alla riduzione del danno.(per esempio effettuare copie di sicurezza dei file)
• Investigativo - Le misure di sicurezza sono orientate all’identificazione immediata (o a breve termine) dell’incidente (per esempio revisione periodica dei log, o sistemi di monitoraggio)
• Repressivo - Le misure di sicurezza sono orientate a contrastare la causa dell’incidente (per esempio spegnimento di nodi affetti da virus, etc…)
• Correttivo - Le misure di sicurezza sono orientate alla correzione dei danni provocati nell’incidente (per esempio, ripristino del file originale da backup, etc…)

Maggiori informazioni disponibili nella pagina sull’Information Security Management in ITIL v3 del sito ITIL, Italia.

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.