Articoli sulla disciplina del Project Management

Definizione della Soluzione

di Vito Madaio – TenStep Italia

La Metodologia TenStep insiste sul concetto che un progetto non può essere gestito bene, se non è stato attentamente definito. Questa responsabilità ricade sul Project Manager, il quale non può accettare di gestire un progetto senza comprendere il risultato da produrre. Se lo fa, ai primi intoppi ne paga le conseguenze.

Approccio metodologico

Se partiamo dal concetto che un progetto risolve un problema, una volta compreso il problema (vedi Come nasce un progetto) bisogna concentrarsi sulla descrizione della soluzione. A inizio progetto non tutto è chiaro e chi non è direttamente coinvolto, di solito sottovaluta questo aspetto, incoraggiando il team di progetto a partire immediatamente e a cominciare a dare risultati.

Quando poi il progetto finisce in stallo, perché le risorse anziché produrre risultati, impiegano il loro tempo a discutere i dettagli dell’ambito del progetto, tutti gli ottimisti si eclissano ed il Project Manager rimane da solo a salvare il salvabile o a fare da caprio espiatorio dei mali di una intera organizzazione. Un approccio simile è tipico delle metodologie “Agili”, dove si accetta che l’utente fornisca le specifiche man mano che vede qualche risultato. In questo modo, l’utente manifesta le sue esigenze gradualmente e può anche cambiarle radicalmente rotta, strada facendo.

Simili progetti riescono a condizione che siano piccoli, semplici e condotti da veri esperti. Con le metodologie “Agili” si appura la soluzione dopo che è stata implementata. Troppo facile!

Le  “Metodologie Tradizionali” come TenStep, non suggeriscono questi approcci accomodanti, anche se, a guardar bene, distinguono chiaramente tra progetti piccoli, progetti medi e progetti grandi; oppure tra progetti semplici e progetti complessi, suggerendo uno specifico approccio per ogni categoria.  Pertanto, l’approccio  è molto simile per progetti piccoli e semplici, ma per favore, non mettiamo sullo stesso piano i progetti grandi o complessi.

I progetti grandi richiedono rigore e formalismo nella fase iniziale, per evitare catastrofi nella fase finale e questo rigore e formalismo è garantito soltanto dall’applicazione di una buona metodologia tradizionale, come il Processo di Project Management TenStep.

Modello di Business

Definire la Soluzione significa documentare la comprensione del problema, l’impatto sull’organizzazione e l’ipotesi di  una o più vie di uscite, dove lo Sponsor - il vero responsabile del progetto, ne ha scelto ed autorizzata una ed una sola.

Trovare la migliore soluzione di un problema non è una cosa facile. Per arrivare ad una soluzione in modo razionale occorre affrontare una serie di aspetti preliminari:

• Sviluppare un modello di business che tenga conto dell’ambiente tecnologico e della strategia aziendale.

• Valutare l’impatto sul business attraverso l’esperienza dell’utente, fondamentale per ipotizzare una  soluzione tecnica. Passare dal modello tecnico prescelto al modello operativo è una conseguenza.

• Il modello di business prescelto deve:

  • essere coerente con la strategia, o in grado di influenzarla,

  • supportare l’implementazione effettiva della soluzione,

  • portare ad una transizione dai vecchi processi ai nuovi.

Approccio Metodologico alla Soluzione

Per sviluppare una soluzione efficace occorre comprendere la struttura organizzativa, la terminologia utilizzata, il contesto nel quale la soluzione dovrà essere calata.

Questa è la maggiore difficoltà per un Project Manager, in quanto tutti i suoi interlocutori inizialmente sono proiettati verso la propria soluzione funzionale, basata sulle proprie congetture.  La descrizione sommaria dell’ambiente fatta dall’utente o da chi vuole fortemente il progetto, non sempre corrisponde alla realtà. Una piccola verifica iniziale può determinare scelte sostanzialmente diverse dalle ipotesi dell’utente.

L’errore più comune nell’interpretare una metodologia di project management è che la ricerca della soluzione prende  troppo tempo. Non è vero. La chiave di volta non è la soluzione in sé stessa, ma la condivisione della sua descrizione iniziale. 

Il Project Manager ha il dovere di descrivere a beneficio di tutti: la struttura organizzativa; la soluzione  prescelta e le  alternative possibili. Queste descrizioni per avere un senso devono essere condivise dallo Sponsor e dai principali Stakeholder (Utenti in particolare).

Questo approccio è ben diverso dal partire immediatamente, senza una descrizione del percorso e della meta da raggiungere. Si finisce semplicemente con il diventare ostaggio dell’utente il quale, secondo le metodologie “Agili”, sarebbe libero di modificare a suo piacimento il percorso e volendo anche la meta.

Definendo e condividendo fin dall’inizio una soluzione tecnica, non si escludono modifiche in corso d’opera. Successivamente, al mutare dei fatti, tali descrizioni possono essere anche emendate, seguendo precise e rigorose procedure di Change Management. Questa non è burocrazia, ma semplice trasparenza.

Ogni richiesta di cambiamento sarà classificata e valutata dal punto di vista dell'impatto sulla soluzione stessa, sul suo costo e sui tempi complessivi del progetto. Senza un chiaro  processo di “Change Management” non è dato sapere né il percorso ipotetico, né quello definitivo, e neanche la soluzione finale. Se questo approccio può piacere all’Utente, non può appartenere alla mentalità di chi finanzia un progetto: lo Sponsor.

Condivisione della Terminologia

In letteratura esistono troppi saggi di project management e spesso con significato diverso dello stesso termine. La creazione di un glossario pur essendo una nobile idea, non sempre trova attuazione presso le aziende. Proprio perché le maestranze possono provenire da ambienti diversi, con terminologia e cultura diversa, la prima preoccupazione di un Project Manager è concordare con il team di progetto  e gli Stakeholder una terminologia che consenta di dare lo steso significato alle parole, alle idee, ed alle risposte.

Pensare di chiarirsi durante l’implementazione è troppo tardi. Si finisce con il dovere gestire tanti conflitti, per poi scoprire che la causa dei conflitti era dovuta alla diversa interpretazione di un termine. La mancanza di una terminologia comune può generare continue riunioni di chiarimenti, con il rallentamento o lo stallo del progetto nelle fasi conclusive.

Documentazione esistente

Per arrivare ad una accettabile definizione della soluzione da parte di tutti, occorre raccogliere tutta la documentazione esistente, tutte le opinioni espresse, tutti i pareri degli Stakeholder influenti e risolvere  ogni contraddizione. Anche se la vita ci insegna ad essere sempre più “equilibristi”, di fronte a due pareri opposti bisogna scegliere e convincere della scelta fatta. Purtroppo non bisogna schierarsi da una parte o dall’altra ma scegliere la soluzione più conveniente per il tuo progetto.

Spesso la soluzione viene enucleata come un fatto tecnico per addetti ai lavori. La nuova figura emergente di Project Manager infatti è necessariamente un tecnico, perciò non potrà avere le competenze per valutare un elaborato tecnico. Però, il suo ruolo consiste nel raccogliere  la migliore interpretazione dell’elaborato e descriverlo a beneficio degli altri Stakeholder, che potrebbero essere nella stessa situazione. La sua descrizione, o semplificazione di un elaborato tecnico, deve essere formalmente riconosciuta  corrispondente all’elaborato tecnico. Questo esercizio consente al Project Manager e a tutti gli Stakeholder di comprendere una soluzione tecnica e costituisce l’elemento principe per creare consenso intorno al progetto.

Comunicare non significa trasmettere informazioni, significa soprattutto accertarsi di essere stato compreso. Senza questo passaggio indispensabile, il Project Manager agirebbe da semplice passa carte. Come farebbe a comprendere le metriche di un collaudo se non  ha capito la portata iniziale della soluzione?

Soluzione e Contesto

La definizione di una soluzione deve tener conto del contesto nel quale deve essere realizzata ed il contesto nel quale dovrà essere messa in esercizio. Ogni progetto è unico proprio perché il contesto è sempre diverso: le persone, il clima, le stagioni, i materiali, le competenze, etc.

Il contesto, oltre ad essere mutevole,  può condizionare fortemente la scelta della soluzione e quindi è bene descriverne i limiti nella fase iniziale. Alcuni condizioni  future (rischi) possono impedire la prosecuzione del progetto, modificarne il percorso, oppure favorirlo in termini di costi e tempi.

Gli eventi futuri più significativi sono:

• Per quando serve una risorsa o una informazione o un materiale (soglie temporali)

• Coinvolgimento di altre entità esterne o interne (cooperazione)

• Decisioni del management in base ai risultati parziali (go - no go)

• Ripetitività di questi eventi (ciclicità).

Con in mente queste considerazioni, il Project Manager può ipotizzare una soluzione finale, facendo riferimento continuamente alle fonti delle informazioni ed al consenso raccolto sulla sua descrizione.

Se riesce a trovare il consenso sulla situazione corrente (As Is), la soluzione finale (To Be) non è altro che la soluzione corrente più le modifiche necessarie per transitare da una all’altra (Gap Analysis).

Di solito si parte dalla situazione corrente, per immaginare una soluzione finale, passando per una serie di stadi intermedi. Operare al contrario dalla soluzione finale al quella iniziale non solo è rischioso ma a volte è proprio impraticabile, con buona pace dei sostenitori delle metodologie “Agili”. In ogni caso, non mancheranno le sorprese oltre alla resistenza delle persone, che se opportunamente informate e coinvolte possono accettare la soluzione anche se a livello personale li danneggia.

Per arrivare a formulare una soluzione bisogna avere una visone chiara dei fattori che potrebbero ostacolarla:

• Rivedere in modo critico l’ambiente di business corrente.

• Stabilire una terminologia comune, creando un glossario per chiarire i principali  termini equivoci.

• Raccogliere tutta la documentazione esistente e finalizzarla al progetto o contestarla.

• Rilevare e descrivere il contesto attuale, salvo smentite in fase di feedback degli Stakeholder.

• Elencare i condizionamenti ed i limiti.

• Descrivere l’organizzazione di business presente in contrapposizione a quella futura.

• Farsi approvare il modello di Business e recepire i feedback prodotti dagli Stakeholder.

• Riprendere e ribadire la descrizione del problema ed i goal dello Sponsor.

• Fissare gli Obiettivi e le relative Deliverable che dovranno essere prodotte.

• Commentare le alternative scartate per problemi di business, per problemi tecnici o per il costo.

• Documentare la direzione strategica e come sostenerla.

• Descrivere il contesto tecnologico del momento.

• Descrivere le infrastrutture disponibili.

• Descrivere il modello di business con chiara evidenza dei flussi di informazioni.

• Definire la strategia nell’utilizzo di nuove tecnologie (quali e quando).

Il Project Manager non può realizzare tutto ciò da solo. Però, se ha ricevuto correttamente il mandato, ha l’opportunità di rivolgersi a tutta l’organizzazione e raccogliere tutte queste informazioni.

Nella fase di definizione della soluzione il Project Manager ha il diritto di fare ogni tipo di domanda, cosa che non potrà più permettersi in fase di implementazione.

Stakeholder e Requisiti

A questo punto il Project Manager, per raccogliere le informazioni deve stabilire chi sono i suoi Stakeholder. Le informazioni vanno raccolte con un certo formalismo, semplicemente per essere certi che chi le ha fornite ne risponda successivamente, o che non possa rinnegarle. Il formalismo, a pensarci bene, è a favore di chi ci dà l’informazione, in quanto lo aiuta a non essere approssimativo. I processi minimi da mettere in piedi sono:

• Definire la tracciabilità dei requisiti raccolti (quando, chi e cosa è stato detto).

• Definire chi può accedere le informazioni (quando e con quale livello di riservatezza).

• Definire l’utente tipo (la audience completa della nostra soluzione).

• Definire il profilo di tutti gli utenti (interni, esterni, istituzionali, etc.).

• Identificare gli utenti pilota (utenti che sperimenteranno la soluzione).

• Raccogliere le adesioni alla fase di sperimentazione ed alla fase di collaudo.

• Rappresentare gli scenari tipo per  far comprendere la soluzione finale.

Tutte queste informazioni sono la base per creare l’ambiente di Project Management, cioè per scegliere i processi necessari per controllare l’esecuzione del progetto.

Anche se stiamo parlando di soluzione non abbiamo ancora accennato ai Requisiti Funzionali.

Il PMBOK (lo schema di riferimento del PMI – Project Management Institute) dedica ben 21  processi su 44 alla pianificazione.  Questo per confermare che i dati funzionali vanno raccolti solo dopo aver definito e compreso il contesto di Project Management da utilizzare. Per il PMBOK “Pianificare” significa soprattutto scegliere i processi per gestire il progetto.

La raccolta dei requisiti funzionali prevede come minimo:

• Definire come un processo di business si traduce in funzioni (cosa fa e non come si implementa).

• Esemplificare con un prototipo (cosa ci si aspetta).

• Osservare il prototipo dal punto di vista di:

  • Utente,

  • Analisi dei dettagli,

  • Gestione del contenuto,

  • Presentazione.

• Adattare il modello di business alle informazioni logiche ricavate del prototipo.

• Definire i requisiti in termini di contenuto  e sua conservazione.

• Descrivere il modello di business logico alla luce dei requisiti raccolti.

• Definire  la matrice delle dipendenze tra Processi – Dati  - Persone.

• Definire requisiti ambientali (sicurezza, riservatezza, integrità dei dati).

• Definire requisiti per l’esercizio (contesto l’esercizio della soluzione).

• Definire livelli di servizi ottimali della soluzione.

• Definire i vincoli o i limiti della soluzione.

Impatto della soluzione

Per completare la descrizione della soluzione bisogna preoccuparsi di valutare il suo impatto sulle persone, sul business e sui sistemi esistenti.

• Valutare le competenze  necessarie per utilizzare correttamente la nuova soluzione.

• Valutare i cambiamenti organizzativi necessari:

  • Impatto organizzativo. L’automazione di alcuni flussi può richiedere una ridistribuzione dell’organico o la nascita di nuove funzioni a supporto dell’utente finale.

  • Costi / benefici. Giustificare la soluzione dal punto dei nuovi costi operativi oppure dalla migliore immagine che si riesce a dare all’organizzazione (customer satisfaction).

Soluzione Operativa

La soluzione è destinata a diventare operativa alla fine dell’implementazione.  E’ opportuno fissare fin da subito le condizioni ottimali per la distribuzione della soluzione. La situazione  di fine progetto e l’effetto delle modifiche in corso d’opera ci potranno far cambiare idea, ma è opportuno avere un contesto di riferimento per la diffusione della soluzione.

Una soluzione resta teorica fino a quando non viene misurata con i primi casi prova. I casi prova devono avere un’aspettativa ed un target di riferimento. In fase di definizione della soluzione bisogna  descrivere formalmente:

• La strategia per la gestione e la valutazione dei casi prova.

• La strategia di collaudo (i casi prova devono portare ad una accettazione o ad una richiesta di correzione, etc.).

• L’approccio alla manutenzione successiva (per quanto possa sembrare perfetta una soluzione avrà sempre bisogno di miglioramenti o correzioni).

• Le metriche per valutare la bontà della soluzione ed i livelli di servizi minimi da rispettare.

• La configurazione degli asset necessari per le tre fasi (implementazione, casi prova, esercizio).

• Il piano di diffusione della soluzione a partire dalla sua accettazione.

Conclusioni

Contrariamente a come comunemente si pensa, la definizione della soluzione è tempo ben speso. Comprendere una soluzione significa padroneggiare la successione degli eventi che attività dopo attività porteranno alla realizzazione del risultato.

Scoprirla in corso d’opera è quasi una follia, a meno che non si tratti di un piccolo progetto affidato ad un esperto di cui abbiamo piena fiducia.

Chi dice che richiede molto tempo lo dice perché o non conosce il suo ambiente o non si fida dei colleghi.

La definizione della soluzione, dove esiste una metodologia condivisa, è un esercizio di routine che le persone reclamano per la loro tranquillità.

E’ evidente che le regole le utilizza chi le ha codificate. Gli altri navigano agilmente a vista!

La definizione della soluzione, in sintesi è:

 Queste considerazioni sono il frutto di considerazioni che si possono trovare sistematicamente ed in modo più completo nella Metodologia TenStep. Però sono sufficienti a far percepire al lettore la necessità di investire risorse a inizio progetto, per comprendere cosa ci si aspetta da un progetto, per veleggiare poi verso le aspettative create proprio con l’analisi iniziale.

Senza una chiara comprensione  dell’ambito del progetto, quale ambito andiamo a gestire?

 Vito Madaio - TenStep Italia