Questo è un sito di contenuti disponibili anche in formato

eBook

Benvenuto

  Avvio Progetto

1.0 Definizione del Lavoro

2.0 Sviluppo Schedulazione e Budget

3.0 Gestione Schedulazione e Budget

4.0 Gestione Problemi

5.0 Gestione Modifiche

6.0 Gestione Comunicazione

7.0 Gestione Rischio

8.0 Gestione Risorse Umane

9.0 Gestione Qualità

10.0 Gestione Metriche

  Chiusura Progetto

    Estensione per Acquisti

Glossario TenStep

PMP-Prep Online

L'esame di certificazione in  meno di 100 giorni

White Paper 

Se trovi utili questi contenuti, sostienici con una donazione

 

0.2.2  Sviluppare il Business Case

 

 0.2.2.P1 Panoramica

Una delle ragioni per cui è difficile mettere il lavoro in priorità nel tuo portfolio è dovuto alla difficoltà di confrontare differenti tipi di progetti. Come puoi confrontare facilmente i progetti dell’area Finance con quelli delle aree Vendite, Produzione, HR e IT? Tutti danno dei benefici ma non è facile sapere quali sono di maggiore valore e quali sono i più allineati alla strategia aziendale.

Uno dei modi in cui puoi fare questo confronto è chiedere che ogni progetto venga descritto e giustificato utilizzando un modello di documentazione comune. Il documento chiave è il comune Business Case. Esso descrive le ragioni e la giustificazione del progetto sulla base dei suoi costi stimati, i rischi coinvolti, i futuri benefici di business attesi ed il valore. La persona che alla fine  sosterrà l’iniziativa dovrebbe essere anche  responsabile del Business Case.

Il Business Case dovrebbe contenere le seguenti informazioni:

  • Nome del progetto. Questo è un nome su una sola riga, ed i nomi possono essere standardizzati per tipi di lavori simili se vuoi.

  • Descrizione del progetto. Questa è una breve descrizione di ciò che viene proposto. Contienila in pochi paragrafi, ma assicurati che fornisca abbastanza informazioni in modo che gli altri possano comprendere il lavoro che viene proposto.

  • Assunzioni. Elenca le circostanze o gli eventi che devono verificarsi affinché il progetto abbia successo. Le assunzioni sono cose che vengono considerate vere  anche se non sono fatti al 100%. C’è della incertezza, ma il Business Case “assume” che certe cose siano vere ai fini della pianificazione e definizione del progetto.

  • Rischi.  Elenca le circostanze o gli eventi che sarebbero di maggiore impedimento al successo del progetto. I rischi hanno una probabilità di accadimento, ma non è garantito che si verifichino. I rischi generalmente vengono visti come fatti negativi che hanno un impatto deleterio sul progetto. E’ importante conoscere i rischi del progetto in modo che posano essere eliminati, minimizzati, monitorati, trasferiti o evitati.

  • Modello finanziario. La tua organizzazione deve creare il modello finanziario comune a tutti i progetti (ROI, EVA, etc.). Ciò è estremamente importante se stai confrontando progetti su base mele con mele. Potresti avere più di un modello finanziario, ma qualsiasi cosa scegli, deve essere applicata a tutti i progetti nel portfolio.

  •  Stima dei Benefici di Business. Devi cercare di determinare i benefici tangibili ed intangibili nei termini del tuo modello finanziario comune. Alcuni benefici di business potrebbero essere indiretti, ma i benefici dovrebbero essere il più possibile tangibili  per poterli confrontare con quelli di altri progetti.

  • Costi stimati. Fornisci le stime quanto più accurate possibile. Il tuo reparto potrebbe stabilire uno standard per il livello di accuratezza richiesto. Per il Business Case, potresti guardare per costi stimati entro il 35% - 50%.

  • Allineamento.  Confermare l’allineamento specificando come questo lavoro contribuisce ed è allineato a propositi, obiettivi e strategia del reparto. La tua organizzazione dovrebbe avere un modello predefinito ed uno schema comune di pesi per l’allineamento in modo che tu possa confrontare efficacemente i progetti.

  • Il lavoro è necessario? Specifica se ritieni che questo lavoro è essenziale. Alcuni lavori possono essere richiesti per motivi legali o obbligatori, anche se non sono allineati e ovviamente non danno alcun beneficio di business.

  • Urgenza. Descrivi la tempificazione richiesta per il progetto. Alcuni progetti devono partire ad un certo momento. Altri progetti devono terminare per una certa data. Altri progetti possono essere eseguiti in qualsiasi momento nel corso del prossimo anno.

  • Conseguenze nel non realizzare il progetto nell’anno. Descrivi  quali possono essere le conseguenze se non viene eseguito il lavoro. In molti casi, ciò è tanto importante  saperlo quanto i benefici di business e l’allineamento. Qualche lavoro è di grande valore per il reparto, ma non è urgente. Sulla base delle priorità e dei fondi disponibili, alcuni lavori molto utili ed allineati possono essere rinviti all’anno successivo.

Può sembrare che questo sia tanto lavoro. Infatti, può esserlo. Però, il Business Case viene utilizzato per determinare quali progetti finanziare e quali non finanziare. Così, è importante dedicare il tempo giusto al Business Case. Se non fai un buon lavoro su questo documento, il tuo progetto potrebbe non confrontarsi favorevolmente con altri progetti che hanno più dettagli e informazioni rilevanti.

 

English Spanish Dutch Portuguese Bulgarian English Spanish Croatian Spanish French German Greek Hungarian Indian English Hebrew Italian Macedonian Malay/English Spanish Polish Portuguese Romanian and Moldavian Russian Spanish Caribbean Dutch Swedish Ukrainian English

Condizioni Generali            |        Mappa del sito principale              |        Cerca nel sito            |          Informativa sulla Privacy          |         Contattaci        |   

TenStep Italia di Vito Madaio - Via Orazio Console 140 -  00128 Roma  -  tel. 39-348-3974474 - 39-06-5088134 - P. IVA 07627281004 - Copyright ©2004 - 2010


Ecco cosa possiamo offrirti immediatamente:

Gestione Progetti

Project Management Office

Portfolio

Metodologia

Formazione

PMBoK

Consulenza

   Registrati al nostro sito  e consulta le ultime novità in materia di Project Management  

Aggiornato a Tuesday, 20 July 2010 00.12