Roberto Meli
Il PNRR, come è noto, non ha solo a che fare con le prassi di governo degli investimenti pubblici nazionali ma deve essere coerente con gli approcci a livello europeo, tipicamente più orientati all’efficacia ed efficienza dei processi piuttosto che al rispetto pedissequo di procedure ammnistrative verticalizzate e spesso non integrate tipiche del nostro contesto nazionale. Il vento sta cambiando anche da noi, però, e gli indirizzi forniti dal governo centrale della PA spingono ora nella direzione giusta.
Ogni intervento ICT del PNRR (diretto o strumentale che sia ad altri ambiti) deve essere giudicato congruo in partenza (ex-ante), deve essere gestito in modo flessibile e trasparente (change requests, agile processes) e rendicontato in modo certo e verificabile (ex-post).
Molte iniziative sono inquadrate in modalità “a corpo” dove assume rilevanza strategica la capacità di fare stime iniziali di tempi, effort e costi accurate, altre sono inquadrate in modalità a consumo o a misura di risultato per le quali è fondamentale non solo fare una scommessa iniziale realistica per lo stanziamento dei fondi ma seguire il processo affinchè resti conveniente, adeguato, flessibile ed efficace.
La maggior parte delle iniziative ICT sono iscritte nell’ambito di mega gare pubbliche oppure accordi quadro o convenzioni CONSIP che, nel momento in cui vengono assegnate (e passano le forche caudine degli immancabili ricorsi alla giustizia amministrativa) apparirebbero già congruite. In realtà quello che viene congruito nelle grosse competizioni di mercato sono i prezzi unitari o le produttività. Dove può nascondersi allora il possibile “danno” o valutazione incongrua ? In genere è nella stima delle quantità di giorni persona oppure delle misure di prodotto che sono previste e rendicontate per raggiungere gli obiettivi che di volta in volta vengono identificati in modo più dettagliato di quanto possibile in un accordo quadro. Nel caso del software, le quantità si chiamano function points, oggi nella versione Simple FP, più moderna e agevole da utilizzare. Se sulle quantità non viene esercitato un governo attento (prima, durante e dopo) il rischio che tariffe congrue generino totali incongrui è elevato.
Ma i function point non sono tutto. Esistono altre componenti di costo che devono essere considerate.
Il Project Management fornisce tecniche di pianificazione e controllo la cui adozione diventa un asset strategico improrogabile per garantire equi processi e fluidità di erogazione e fatturazione dei fornitori nelle iniziative ICT del PNRR.
Il workshop illustra un modello ed un approccio per la valorizzazione economica preventiva e consuntiva di interventi ICT esternalizzati dalla Pubblica Amministrazione che sia coerente con il quadro normativo degli appalti di riferimento. Obiettivo principale del modello denominato R3 – VAMOS (VAlorization MOdel for Software) è quello di facilitare e velocizzare il processo di convergenza sulle stime economiche inizi
Stefano Broccardo | Digitalizzazione e sostenibilità: cosa può fare il cost m...
PMexpo 2022 | La valutazione di congruità dei progetti ICT del PNRR
1. La valutazione di congruità dei progetti ICT del PNRR:
strumento essenziale per il governo
ex-ante ed ex-post delle iniziative.
Roberto Meli
2. In permanente equilibrio tra «accademia» e «business»
•CEO di DPO
•Consulente /Trainer nel PM e Software
Management da +35 anni.
•Componente del Board of Directors dell’IFPUG
•Componente del Consiglio Direttivo GUFPI-ISMA
•Certified Senior Assessor ISIPM-PRADO
•Ideatore di E&QFP e Simple FP
roberto.meli@dpo.it
robertomeli
3. Quello che non so
• % di curiosi senza particolare esperienza di
modelli di costo del software
• % di professionisti con media formazione di
base ed esperienza sul campo
• % di esperti del settore
• che sanno già tutto
• che sono aperti a prospettive nuove
4. Obiettivi del mio intervento
• Contestualizzare
• Evidenziare i problemi presenti o potenziali
legati alle prassi correnti
• Presentare un approccio /soluzione
• Citare alcune esperienze
• Generare nell’uditorio idee, spunti e desideri
di approfondimento
• Cercare di rispondere alle vostre domande
5. Indice degli argomenti
• Il contesto degli interventi ICT nel PNRR
• Necessità attuali di governo degli interventi
• Le tipiche modalità contrattuali in vigore
• La valutazione di congruità ex-ante / ex-post
• Difficoltà emergenti
• Un approccio metodologico / soluzione
• Il modello VAMOS-R3
• Conclusioni
6. Il contesto dei progetti ICT nel PNRR
PNRR e Project Management – Stolfi – Di Gioacchino – Il Project Manager – n. 49 – F.Angeli
235,1 Miliardi di Euro
7. Quanto valgono i progetti ICT ?
Diretti Indiretti
Ogni intervento ICT del PNRR (diretto o strumentale che sia ad altri ambiti) deve
essere giudicato congruo in partenza (ex-ante), deve essere gestito in modo
flessibile e trasparente (change requests, agile processes) e rendicontato in
modo certo e verificabile (ex-post).
8. Che ruolo ha la verifica di congruità economica?
• Dare il massimo dell’oggettività possibile al
dimensionamento delle iniziative
• Garantire che in fase di preventivazione degli
interventi vengano stanziati fondi «equi» -
«congrui» rispetto alle necessità
• Garantire che in fase di consuntivazione non
vi siano scostamenti «importanti» rispetto alle
promesse fatte
• Garantire la sostenibilità e correttezza della
valorizzazione degli interventi di fronte ad
eventuali «audit» esterni
Danno Erariale
9. Gli strumenti contrattuali
• Accordi quadro (CONSIP e non)
• Convenzioni
• Gare d’appalto specifiche
• (Affidamenti diretti)
Dati i lunghi tempi di attivazione
di una gara ad hoc (>12 mesi) si
tende a preferire l’uso di
contratti già esistenti ed attivi.
Quindi tutto a posto !
I contratti attivi sono
già congrui per
definizione !
10. NO ! Dove si può annidare il problema?
Accordi quadro,
convenzioni,
strumenti generali,
congruiscono le
tariffe unitarie, non la
specifica
assegnazione di
risorse ad una
iniziativa progettuale.
•Tariffa congrua (€/gp; €/FP)
•Assegnazione incongrua (gp;
FP)
Danno erariale
11. Il progetto ICT non è solo software ma…
• Il «ferro» (le tecnologie) hanno mercati
di riferimento più standardizzati e/o
misurabili (listini, benchmark, etc.)
• Il software commerciale (COTS) ha
listini di riferimento e mercati di
confronto (licenze, sconti, etc.)
• I servizi immateriali sono i più critici
(servizi professionali, software ad hoc,
personalizzazioni di software
commerciale, dati, etc.)
12. Qual è il ruolo della stima economica?
Cambia a seconda del tipo di
contratto scelto:
• Modalità a corpo
(corrispettivo fisso)
• Modalità a misura di prodotto
(corrispettivo variabile)
• Modalità a misura di risorse
(corrispettivo variabile)
Stima economica
Requisito
di
Processo o
Vincolo
Requisito
Funzionale
Requisito
Non
Funzionale
13. Quali sono le prassi attuali per il software ad hoc?
14. Quali vantaggi / svantaggi ?
Vantaggi
• Facile da usare
• Altamente referenziato
Svantaggi
• I requisiti non funzionali e di processo non contribuiscono ad influenzare
il prezzo di acquisto creando disparità di situazioni produttive.
• Il prezzo unitario quadro del FP non rappresenta adeguatamente le
diverse situazioni produttive degli specifici interventi con conseguente
compensazione economica su partite diverse e perdita di trasparenza.
• Gli SLA a livello contratto tendono ad esagerare e omologare le richieste
su prestazioni non funzionali e di processo che dovrebbero, invece,
dipendere da intervento a intervento, creando sprechi o carenze di
risorse.
16. I Simple Function Points
SW application functional specifications
Logical file Transaction
Data Element Type
Record Element Type
FTR
0..*
I/O
1..*
SW application functional specifications
LF EP
Primary intent
SFP
FPA
17. L’effort e il costo dipendono dai FP ?
E' ormai acclarato che il lavoro (effort) di
Sviluppo e Manutenzione Evolutiva
funzionale dei sistemi software custom -
ovvero costruiti on demand senza l'uso
di prodotti commerciali (COTS) - è
spiegato statisticamente solo al 50%
circa dall'uso di una misura funzionale
pura (non "aggiustata" o "modulata" da
altri aspetti). Il restante 50% dobbiamo
andarlo a cercare negli altri tipi di
requisiti.
y = 0,7407x + 3,9295
R² = 0,4244
0
2
4
6
8
10
12
0 1 2 3 4 5 6 7 8 9
Ln(Impegno)
Ln(Impegno)
Lineare (Ln(Impegno))
18. L’effort e il costo dipendono dai FP ?
y= 0,7407x + 3,9295
R² = 0,4244
0
2
4
6
8
10
12
0 1 2 3 4 5 6 7 8 9
Ln(Impegno)
Ln(Impegno)
Lineare (Ln(Impegno))
Si assegnano gli
appalti quadro nella
speranza che
avvengano
compensazioni tra
gli errori in eccesso
e quelli in difetto.
19. La spirale non virtuosa…
Non si controlla
il consegnato
Il prezzo si slega
dai costi e serve
per vincere
Il prezzo, però, non è
remunerativo e quindi
non è rispettabile
Ormai il contratto è
assegnato e clienti-fornitori
diventano solidali nel trovare
una soluzione
Il prezzo è confortato
dalla storia delle
transazioni pubbliche
•Si inventano FP
•Si trovano partite
compensatorie
20. Cosa succede in Europa ?
Il prezzo unitario quadro del FP,
in Italia, è scivolato, a causa di
ribassi incontrollati, in zone di
«infattibilità» con il necessario
ricorso a «partite
compensative» che tolgono
trasparenza ed equità.
Harold van Heeringen (ex Presidente ISBSG) nella conferenza internazionale ISBSG
IT Confidence Conference 2021 del 8 ottobre 2021.
21. Una possibile soluzione ?
Utilizzare per la valorizzazione degli interventi la strada del «team
ottimale» stimando le attività in giorni persona MA basandosi, per la
verifica di congruità, su un modello articolato di effort legato a standard
di mercato (ISBSG, COCOMO, CAPER JONES). Tale modello prende in
considerazione tutte le metriche disponibili per oggettivizzare la
valorizzazione, compresa quella funzionale (FP) che diventa un cost
driver primario ma non unico e soprattutto non separabile dalle altre
componenti di modello.
23. E gli interventi misti ?
Programmazione
Personalizzazione
Parametrazione
D
Requisito di
business
Team di configurazione
Utente Finale
Team di sviluppo
Requisito
Software
Funzione Software
24. Adaptation Points
Per ogni requisito di business implementabile attraverso parametrizzazioni di
package, si conteggiano alcuni elementi logici caratteristici del processo di
configurazione.
A ciascuno di questi requisiti di business configurabili è assegnato un numero
di AP, driver principale per il modello produttivo per la parametrizzazione di
package software
Individuare gli oggetti di
Business
Individuare le
informazioni descrittive
degli oggetti di business
Individuare le
informazioni delle
relazioni tra gli oggetti di
business
25. Quali fattori influenzano la produttività ?
4 diversi sondaggi in 4
primarie organizzazioni
ICT italiane
Coinvolgimento di un
centinaio di
professionisti
Raccolta e bonifica di
elementi
Identificazione di oltre
un centinaio di fattori
26. Impatto dei NFR sui costi di progetto
A.NFR/PR non influenza il costo totale; il costo è proporzionale solo ai FP
B.NFR/PR genera un costo fisso da aggiungere al costo proporzionale ai FP
C.NFR/PR genera costi fissi che sono aggiunti al costo dipendente da FP in
maniera discreta (vengono determinati da soglie sulle dimensioni, per esempio)
D.NFR/PR influenza il tasso di produttività PDR aumentandolo o diminuendolo
A B C D
Se tracciamo i costi (asse y) contro la dimensione funzionale (asse x) si possono
visualizzare alcuni esempi di impatto di NFR (o PR) sui costi totali:
27. Come si misurano i Requisiti Non Funzionali?
• Non esiste una metrica unica per misurare
elementi così diversificati.
• Non tutti gli elementi, allo stato attuale, sono
misurabili in modo soddisfacente.
Ad esempio:
Bonifica di dati
Tempi di risposta delle transazioni
Architettura hw/sw ridondata e cooperante
Esperienza del team nel dominio applicativo
29. Dimensionamento da WBS: listini produttivi
Declaratorie per la
scelta del valore
alto, medio, basso
30. Dimensionamento da WBS: formato libero
Dimensione massima WP non superiore a 10-15 GP
Attività NON dipendente da size
Ad esempio:
Performance tuning Modifiche alle applicazioni finalizzate ad avere migliori performance (tempi di
risposta, durata dei processi etc.) che non modificano la funzionalità logica utente.
Le modifiche del software finalizzate al miglioramento delle prestazioni comportano
tipicamente una o più attività quali l’esecuzione del tuning o l’ottimizzazione di
parametri del sistema, mantenendo invariate le funzionalità esistenti.
Reingegnerizzazioni
tecniche
Attività finalizzate alla modifica di componenti tecniche della soluzione (es. linguaggi di
programmazione, data base, protocolli di comunicazione, application server, etc.) senza che vi
siano modifiche alle funzionalità logiche utente.
La realizzazione di tali prestazioni può comportare attività quali:
riscrittura del codice in linguaggi differenti;
riscrittura del codice per ottimizzazione della manutenibilità;
porting del codice tra ambienti di esecuzione differenti/su HW differenti;
modifiche dei protocolli di comunicazione tra i sistemi per adeguamenti tecnologici a parità di
dati logici (campi) scambiati.
Modifica di formati nei flussi di input o di output, inclusi i formati degli output di stampa e simili
(ad esempio aggiunta di un formato di tipo .xls ad un formato .txt già esistente).
aggiunta/modifica di controlli formali o di obbligatorietà in assenza di modifiche delle funzionalità
33. Stima Monitoraggio Consuntivazione
F
O
R
NI
T
O
R
E
P
A
Utilizzo modello
congruità XLS
Creazione e
trasmissione scheda
intervento e allegato
XLS
Verifica scheda
intervento / XLS
Accettazione
scheda
intervento
Lancio attività
Stati avanzamento
Lavori Economico
Tecnico
Approvazione
Avanzamento
C C
Documento informativo a
supporto della
fatturazione RUC
Ex ante & una
tantum
Mensile / ad hoc Bimestrale/ad hoc
Invio Fatture
Procedura di
pagamento
Condivisione Verbale
di conformità RUP
C
√
Un possibile processo
34. Conclusioni
• La stima e valutazione di congruità sono fasi essenziali per il corretto processo di
governance degli interventi del PNRR (e non solo)
• Gli approcci tradizionali si sono dimostrati incapaci di catturare l’articolazione della realtà e
generare rapporti equi tra cliente e fornitore
• Un modello di stima di effort/costo deve utilizzare tutte le possibilità oggi disponibili per
rendere la stima/verifica più oggettiva possibile
• Le misure alla base dell’uso di un modello devono essere light e poco invasive dei processi
produttivi
• I Simple Function Point sono una opzione moderna, efficace ed efficiente per misurare i
prodotti software custom
• I Requisiti Non Funzionali e di Processo devono essere valutati sia per la loro capacità di
impattare sulla profuttività funzionale che per il loro contributo diretto
• La WBS è uno strumento prezioso del PM che, opportunamente impostata e
standardizzata può contribuire al processo di congruità.
• VAMOS-R3 è un modello pubblico personalizzabile, evolvibile e compatibile con le esigenze
oggi necessarie e può risolvere molti problemi.