Valutazione rischi su progetti ICT
Stefano Corona
Co-Founder, Project Manager & System Integrator. Applicazioni Gestionali e Professionali: Progetti, analisi e modelli funzionali.
Valutazione rischi e relativi fattori di successo.
Introduzione
Con la voglia di approfondire il discorso di valutazione del rischio in ambito di progetti ICT, ho letto diversi blog sull’argomento.
Colto dalla voglia di mettere ordine alle informazioni recepite, cercando di lasciare da parte l’enfasi che ognuno mette nel descrivere le varie esperienze e con l’obiettivo di fare il gazzettiere, cerco di puntualizzare i vari punti di vista.
Scenari ipotizzabili.
Scenario decisionale A
- Alto numero di fattori analizzati: aumento delle possibilità di ipotizzare uno scenario definitivo, abbattimento del rischio
Scenario decisionale B
- Pochi fattori analizzati: rischio di descrivere uno scenario unico, magari teorico, aumentando i fattori di rischio.
Scenario decisionale C
- Numero di fattori analizzati relativamente alto: scenari multipli, comunque preconfigurati; abbattimento del rischio rispetto a scenario a, comunque alto.
Scenario decisionale D
- Analizzati solo fattori vincolanti: probabilmente in output si avrà un solo scenario, con una buona possibilità che sia vicino alla realtà, permettendo di calmierare il rischio.
Rileggendo i punti sopra indicati sembrerebbe che gli scenari A e D siano quelli con maggior possibilità di successo.
Mi chiedo se questa ultima affermazione non sia troppo banale e di conseguenza il costo, come viene considerato, e/o pesato?
Provando a ipotizzare una riunione tra stakeholders e responsabili di progetto, e tra responsabili di progetto e sponsor, non so perché mi viene in mente una storia che inizia più o meno cosi: “c’era una volta un tedesco, un inglese, un francese…“.
Lo sponsor cercherà di puntare all’ipotesi B, cercando di trarre beneficio dall’esperienza del capo progetto (e qui mi viene in mente il tedesco!); il capo progetto potrebbe avere voglia di spingere per uno scenario di tipo C, cosi da essere più possibile vicino sia a sponsor che a stakeholders (mi viene in mente il francese); gli stakeholders sottolineeranno l’importanza di adottare lo scenario A (non so perché ma ci vedo l’inglese), evitando brutte sorprese.
Qui si gioca la riuscita di un buon progetto.
Solo con l’abilità del capo progetto e la sua capacità di convincere le altri parti sulla bontà della metodologia da applicare, che si arriverà al goal.
A questo punto lo scenario D che posto avrà? Potremmo pensare che alla storiella si aggiunga “… un italiano?“
A voi le giuste considerazioni.
ceo presso Sistemi Uno Roma srl
8 anniBravo Stefano, hai scoperchiato il vaso di Pandora! Spesso i problemi nati in questa fase si trascinano per anni irrisolti, in progetti non falliti del tutto ma dalla riuscita molto al di sotto delle aspettative Credo che una vera risposta non esista, o meglio c’è ma è solo dettata dal buon senso e varia in base alle “condizioni ambientali” ovvero le variabili puntuali del progetto come tempi, costi, ma anche e sopratutto qualità e quantità delle risorse disponibili lato utente (anche le nostre ma quelle le conosciamo bene) Annusando tutto questo un buon capo progetto capisce quanto si può permettere di rischiare, perché in fondo è sempre un gioco di equilibri dove ciò che si ricerca non è la soluzione perfetta in assoluto, spesso inapplicabile perché comporterebbe tempi e costi irragionevoli, ma il compromesso migliore Ciò che non dobbiamo perdere mai di vista è che un progetto può fallire in molti modi, e tra questi ce ne sono diversi che prescindono l’aspetto tecnico, l’applicazione di uno scenario di tipo A (che definirei uno scenario “brute force”) porterebbe con ogni probabilità ad un fallimento sul piano economico o su quello dei tempi che spesso sono un vincolo imprescindibile. Escludendo quindi il punto A, che appare quello che teoricamente darebbe più garanzie sul piano tecnico, ed in accordo con te quando dici che alla fine A e D sono i due realmente applicabili, credo che alla fine ci si ritrovi sempre ad applicare lo scenario D, dove la capacità di identificare i vari fattori vincolanti (spesso da effettuare in tempi strettissimi) è una delle capacità peculiari di un buon capo progetto
DPO Consulente Privacy, Sicurezza Informatica Whistleblowing
8 anniCiao Stefano, credo che il Capo progetto sia come il comandante di una nave. Se è bravo, durante la navigazione dovrà fare dei compromessi per evitare di allontanarsi dalla rotta, consumare meno gasolio ed arrivare nei tempi programmati evitando il mare grosso. Post interessante.