La misurazione e il monitoraggio dei progetti e dei contratti ICT è da sempre una delle principali preoccupazioni dei CIO e oggi, con la complessità infrastrutturale dei sistemi informativi e delle architetture applicative, è un tema quanto mai di attualità. Con questo articolo dedicato a due schemi di classificazione relativi alle tipologie di progetto (123) e di requisiti (ABC) iniziamo una serie di approfondimenti su questa tematica.
Le macro caratteristiche di un progetto ICT
Il PMBOK (Project Management Body Of Knowledge) definisce un progetto come “a temporary endeavor undertaken to create a unique product, service, or result” e un contratto ICT di fatto suddivide un progetto complessivo in più sotto-progetti.
Nella versione più estesa pertanto si partirebbe da un progetto di sviluppo (DEV – Development), per passare poi alla sua operatività (OPS – Operation), per finire con una serie di interventi manutentivi (SVC – Service/Mainteinance), utili a prolungarne il ‘valore’ per i suoi stakeholder nel tempo.
Cos’è lo schema 1-2-3 nella gestione dei progetti IT
Quindi la gestione di un sistema implica un progetto di servizio il cui ‘scope’ (ambito) può essere suddiviso, seguendo il principio del ‘divide-et-impera’, in tre sotto-progetti, ciascuno con ‘scope’ puntuali e collegati ma da poter gestire separatamente. Da qui nasce lo schema ‘123’, laddove, invertendo le proporzioni note come la ‘regola di Pareto’, i tempi e i costi del DEV rispetto all’OPS/SVC potrebbero essere in una proporzione del 20/80.
La manutenzione può essere di diversi tipi, seguendo la classificazione proposta dallo standard ISO/IEC 14764:2006:
- correttiva (suddivisa in correttiva e preventiva)
- evolutiva (suddivisa in adeguativa e migliorativa)
e rappresenta con l’esercizio (OPS) nella vita utile di un servizio/sistema la gran parte del progetto di servizio complessivo, diversamente dalla percezione comune, numeri alla mano (figura 1).
Separando le parti (1-2-3) in contratti e gestioni distinte, sebbene intimamente collegate tra loro, si porrebbe una attenzione proporzionata a ciascuna delle parti, partendo dalle stime tecniche fino alla gestione economica. Si pensi ai livelli di servizio e alle misure per il controllo di ciascuna parte: ‘a plan of measures is not a measurement plan’, con un numero bilanciato di misure, da collegare in modo causale tra di loro per restituire un maggior valore informativo. Un esempio: misure e KPI relativi all’affidabilità (reliability) di un prodotto/servizio dipendono strettamente dalla qualità degli outcome prodotti, che a loro volta dipendono da come la prima progettazione e realizzazione sia stata ‘buona alla prima’ (c.d. first take), adottando tecniche che DevOps definirebbe di tipo ‘shift left’.
Quindi guardare il progetto complessivo, gestendo i singoli progetti ‘elementari’ e le relazioni tra loro, diventa sempre più fondamentale per contratti che vorrebbero essere gestiti più in termini di ‘valore’ che di pura ‘redditività’, misurati pertanto con VOI (Value on Investment) che non con il ROI (Return on Investment).
Lo schema ‘ABC’: cosa è e come applicarlo nello schema ‘123’
Ogni pianificazione nasce da un set di requisiti forniti dai diversi stakeholder. Ma i requisiti in un progetto non sono tutti uguali. Alcuni sono relativi alle funzionalità di un prodotto/servizio (COSA), altri a COME realizzarle o a quali livelli (QUANDO), espressione rispettivamente (COSA) di FUR (Functional User Requirements) e (COME e QUANDO) NFR (Non-Functional Requirements).
Cosa misurano i requisiti utente
Ma cosa misurano? Un prodotto/servizio e non un progetto: difatti non comprendono anche i requisiti gestionali ed organizzativi necessari alla loro messa in opera. Riassumendo, da ogni requisito utente (UR) si potrebbero avere quindi requisiti di prodotto/servizio funzionali (tipo A), non funzionali (tipo B) e gestionali (tipo C). Mettendoli insieme, si ottiene lo schema ‘ABC’ e la figura 2 propone le possibili combinazioni.
In un progetto software, per esempio:
- i task derivati da requisiti di tipo A sarebbero eseguiti principalmente da analisti/programmatori/tester (quelli che nelle tecniche Agile quali Scrum sarebbero definiti il ‘team’);
- i task di tipo B sarebbero eseguiti da specialisti di prodotto, esperti di usabilità, DBA, architetti, configuration manager e via dicendo;
- infine quelli di tipo C sarebbero eseguiti dai cosiddetti ‘gestionali’ quali un project manager, un misuratore, un service manager, un quality assurance (QA)/experience assurance (XA) ed altri che contribuiscono indirettamente alla creazione/modifica di un prodotto/servizio tramite task ‘altri’.
Distribuzione di effort e costi di un progetto ICT
Per conoscere una proporzione indicativa della distribuzione degli effort e costi di un progetto ICT, si consideri il doppio triangolo proposto nella figura 3, con distribuzioni che variano, ovviamente, in funzione del tipo di progetto (sviluppo, manutenzione) e del cosiddetto ‘dominio funzionale’, ovverosia della famiglia di progetti considerata (nel mondo software, lo standard ISO/IEC 14143-5 propone criteri di classificazione standard dal 2004): un progetto di software gestionale non potrebbe essere validamente comparato con uno per app mobile o per uno sviluppo di rete. È necessario pertanto classificare e clusterizzare i progetti in tipi omogenei ed equivalenti, per ogni pratica ed obiettivo di benchmarking.
La figura 4 invece illustra una possibile distribuzione degli effort ABC per alcuni possibili ‘domini funzionali’.
Come poter derivare queste proporzioni in un progetto? Non esistono ‘silver bullet’; basta considerare il Gantt/WBS di un progetto, classificare ciascun task ‘atomico’ secondo la natura del requisito (ABC) che lo origina e calcolare i totali per ciascun tipo in valore assoluto e quindi in percentuale sul totale generale. Nel caso di dubbio sulla classificazione di un task, questo potrebbe non essere ancora ben dettagliato, richiedendo una ulteriore scomposizioner in sotto-task, possibilmente assegnabili anche a personale diverso (per esempio: l’analisi, come le altre fasi tecniche, possono essere scomposte in due parti: funzionale e non-funzionale), come illustrato in figura 5.
Alcune misure/KPI per ciascuno dei diversi tipi di requisito potrebbero essere:
- (A) Function Point;
- (B) misure qualitative/tecniche relative al prodotto/servizio derivate ad esempio dalla norma ISO/IEC 25023 o dalla tecnica IFPUG SNAP;
- (C) non esistendo al momento una definizione condivisa, standard di ‘project size’, si possono identificare misure specifiche per ciascuna tipologia di task di questo tipo o, come spesso accade, passare direttamente ad una stima in giorni/persona.
La tecnica EAM (Entità-Attributo-Misura) può aiutare a classificare e determinare correttamente un ‘measurement plan’ bilanciato.
Riprendendo pertanto lo schema ‘123’, come in figura 6, i progetti di sviluppo (tipo 1) hanno tutti e tre i tipi di requisito (ABC), quelli di esercizio/operatività (tipo 2) solo quelli di tipo B/C. Le funzionalità sviluppate in questa fase difatti si ‘usano’, non si modificano. Infine, nei progetti di manutenzione (tipo 3) gli interventi di tipo correttivo saranno di tipo B/C, mentre quelli di tipo evolutivo possibilmente di tipo A e sicuramente di tipo B/C. ‘Possibilmente’ perché molti interventi di piccola manutenzione evolutiva possono non comportare modifiche funzionali (es: cambi grafici, aspetti qualitativi, prestazionali, …).
Schema ‘123’+’ABC’: una combinazione di ‘valore’ per una migliore gestione contrattuale
Attualmente molti contratti ICT considerano le misure funzionali di un prodotto software quali i Function Point (quale che sia lo standard applicato: IFPUG, COSMIC, NESMA, FISMA, Mark-II) la base di conteggio per la corresponsione di un singolo macro-progetto ICT che però include sotto-progetti di più tipi (1, 2, 3) e che quindi potrebbe non avere effort direttamente proporzionali alle formali quantità censite (valide solo per alcune delle suddette tipologie).
Ciò ha comportato (e ancora rischia di comportare) discussi tra le parti contrattuali, non perimetrando il corretto ‘scope’ progettuale usando la corretta combinazione di misure e KPI, ma semplificandone eccessivamente la gestione e riconduncendola principalmente a misure di tipo funzionale, non sempre, come detto, applicabili.
Potrebbe l’applicazione di questa semplice scomposizione di macro-progetti in sotto-progetti con un ambito ben definito essere l’inizio di un nuovo percorso nella contrattualistica ICT?
GUFPI-ISMA ha ridefinito nel 2016 le proprie Linee Guida con un primo volume relativo ai Principi, Assunzioni e Best Practice Contrattuali (PABCP) con i principali aspetti da poter osservare anche per auto-valutazioni dei propri contratti a cui seguirà a breve un secondo volume con indicazioni operative sui singoli lemmi discussi.
Interessati a saperne di più? Seguite i nostri prossimi contributi su ZeroUnoWeb e visitate il sito web GUFPI-ISMA per ulteriori spunti ed approfondimenti!
