PRINCE2 – Il Business Case – II parte

Nella metodologia PRINCE2 il Business Case viene sviluppato durante la fase iniziale di un progetto come evoluzione del Project Brief (documento iniziale che definisce in modo sommario gli scopi, i costi, le tempistiche e le tolleranze creato nella fase di avvio del progetto a valle di un Mandato di Progetto), dal Piano di Progetto e dal Registro dei Rischi . E’ ovvio che nella fase iniziale del progetto il Business Case risulta essere ancora un’entità basata su informazioni presunte quindi lo stesso sarà corretto e riveduto ciclicamente durante tutta la durata del progetto per valutare che la giustificazione commerciale dello stesso resti tale.

Il responsabile del Business Case è l’EXECUTIVE che, facendo parte del team di gestione del progetto, ha la responsabilità di assicurare la creazione e l’approvazione dello stesso (la creazione del BC può comunque essere delegata ad altri membri del team che abbiano le competenze necessarie per poter assolvere a tale compito).

Il Business Case viene quindi:

  • Sviluppato tenendo in considerazione tutte le informazioni in proprio possesso sulle quali poter prendere decisioni in merito al progetto.
  • Verificato continuamente durante tutto il ciclo di vita del progetto per comprendere se la gistificazione commerciale dello stesso sia ancora valida o meno.
  • Manutenuto ovvero ciclicamente aggiornato con un consuntivo sui costi e sui benefici ottenuti sul periodo appena passato e preventivati per quello immediatamente successivo.
  • Confermato o meno successivamente alla valutazione delle consuntivazioni effettuate nel tempo.

Contenuto del Business Case

Come già detto più volte il Business Case descrive le motivazioni per le quali è conveniente intraprendere il progetto in relazione a Costi, Rischi e Benefici previsti e generalmente consta di:

  • Motivazioni per le quali è necessario realizzare il progetto.
  • Opzioni per l’aziendaovvero enumera e motiva le diverse posizioni che l’azienda può assumere in merito ad una questione.
    • Non Agire: l’azienda può decidere che non sia conveniente intraprendere alcuna azione relativamente ad una questione.
    • Agire al minimo: l’azienda può decidere che sia conveniente intraprendere un’azione relativamente ad una questione entro determinati limiti.
    • Agire in qualche modo: l’azienda può decidere in base ad una serie di valutazioni variabili in che modo agire in merito alla questione.
  • Benefici Previsti insieme di tutti i benefici ritenuti conseguibili in seguito alla realizzazione dei prodotti finali del progetto.
  • Controbenefici Previsti insieme di tutti i controbenefici ritenuti possibili durane o a seguito della realizzazione dei prodotti finali del progetto.
  • Tempistiche
    • Periodo di sostenimento costi.
    • Periodo di analisi.
    • Periodo necessario per lo svolgimento di tutte le attività per ogni pacchetto di lavoro.
    • Periodo …
  • Costi di progetto, di manutenzione, …
  • Valutazione dell’investimento ovvero un confronto dettagliato tra i costi ed i benefici previsti.
  • Rischi Principali ovvero una sintesi di tutti i rischi per il progetto.

PRINCE2 – Il Business Case – I parte

La fase di startup di un progetto, sia esso legato alla crescita aziendale o perché no a quella personale, è sempre preceduto da un’attenta analisi del contesto nel quale lo stesso sarà presumibilmente realizzato. In questa fase si individueranno dei costi di realizzazione (“costo zero” è pur sempre un costo), dei tempi di sviluppo, una certa percentuale dei rischi, dei benefici e/o dei controbenefici.

Ognuna di queste variabili, oltre a variare da progetto a progetto, è soggetta a variazioni anche nella realizzazione di uno stesso progetto, portando talvolta a considerare, in corso d’opera, che non sia più conveniente continuare nell’impresa (in quest’ultimo caso comunque non deve necessariamente significare che non siamo stati abbastanza bravi nel nostro operato, infatti ogni impresa è sempre calata in un contesto che non è statico ma che evolve nel tempo mutando in relazione con gli elementi che lo influenzano e contemporaneamente ne vengono influenzati). L’errore che può essere ingenuamente commesso durante la stesura di un piano di progetto è considerare l’analisi delle variabili succitate come un’operazione da fare una tantum per ottenere il benestare sul progetto, poiché tale analisi se ciclicamente riveduta è anche la sentinella di allarme da utilizzare per prevenire possibili ostacoli e spesso l’unica arma vincente per raddrizzare la rotta verso il raggiungimento degli obietti iniziali.

Nell’ambito della metodologia PRINCE2 viene identificato come BUSINESS CASE

La raccolta e l’organizzazione delle informazioni utili per determinare l’auspicabilità (rapporto tra costi/beneficii/rischi), la fattibilità (capacità di realizzazione dei prodotti richiesti) e la realizzabilità (capacità dei prodotti realizzati di portare i benefici aspettati) di un progetto.

Così come il contesto nel quale si decide di agire anche il BUSINESS CASE non è un’entità statica, al contrario quest’ultimo DEVE essere aggiornato costantemente con le informazioni relative ai costi sostenuti, ai rischi, alle opportunità ed ai benefici che si svilupperanno in corso d’opera in modo da poter essere sempre in grado di valutare lo stato dell’arte e prendere decisioni in merito alla continuità dell’impresa non a caso il Business Case è alla base di tutti i processi decisionali.

PRINCE2 – Il Business Case – II Parte

ITIL – IT Infrastructure Library

ITIL (IT Infrastructure Library) è un framework di best practice consigliate per garantire il miglioramento dei servizi e delle strutture coinvolte nei processi IT e che, a differenza di altri, non si presenta come un modello teorico ma pittosto come una raccolta di metodologie che hanno dimostrato “sul campo” di migliorare la qualità di tali servizi nonchè i mezzi necessari a supportarli nel tempo.

La prima versione del framework, al tempo non ancora conosciuta con questo nome, fu rilasciata verso la metà degli anni ’80 e nacque dalla richiesta dal Governo Britannico che, non considerando sufficientemente valido il livello qualitativo dei servizi IT erogati, incaricò la CCTA (Central Computer and Telecommunication Agency) oggi nota come Office of Government Commerce (OGC), per ottimizzare l’efficienza ed il costo delle risorse IT.

ITIL v1 è poi successivamente evoluto prima nella versione 2 (con la quale raggiunse l’approvazione dei più nel mondo IT) nei primi anni del 2000 e poi nella 3 nel 2007.

La v3 si basa su un approccio basato sull’intero Ciclo di Vita dei Servizi IT introducendo il concetto di Service Life Cycle differentemente dalla v2 strettamente focalizzata sui processi. Questa impostazione, porta il dipartimento IT a focalizzare la propria attenzione sul valore che i servizi portano al Business dell’azienda o in generale del committente.

I 5 Core Books sui quali è basata ITIL v3 sono sono suddivisi uno per ogni fase del ciclo di vita del servizio:

  • Service Strategy: ovvero la definizione della strategia IT rispetto al Business
  • Service Design: quindi la fase progettazione del servizio
  • Service Transition: erogazione del servizio
  • Service Operation: manutenzione e gestione del servizio
  • Continual Service Improvement: miglioramento continuo del servizio in tutte le fasi del ciclo di vita

Una cosa da tenere assolutamente in considerazione nell’utilizzo di ITIL è che lo stesso non è uno standard, ciò vuol dire che mantenere le linee guida proposte non vuol dire non poterle “adattare” alle proprie strutture organizzative.

Approfondimenti:
http://www.itil-italia.com/
http://it.wikipedia.org/wiki/ITIL
http://www.itsmfi.org/content/introductory-overview-itil-v3-pdf
http://www.isacaroma.it/pdf/080131/ITL-Renna-31.01.08.pdf