Il Project Management

I progetti di System Integration

La metafora dell’altalena (narrazione semi-seria)

Considerazioni dall’esperienza
I progetti di System Integration
 Progetto

Un progetto è un’iniziativa coordinata e

temporanea intrapresa per creare un
prodotto o servizio unico.
Un progetto coinvolge più interlocutori
(“stakeholder”) interessati a ciò che
viene realizzato.
Un progetto possiede requisiti ed è
sottoposto a vincoli.
Project management

Il project management è l’applicazione di

conoscenze, abilità, strumenti e tecniche
per soddisfare i requisiti di progetto.
Il project manager è il responsabile del
soddisfacimento dei requisiti di progetto
nel rispetto dei vincoli.
System integration

L’attività di system integration rende i

corrispondenti progetti estremamente complessi:
scarsa definizione dei requisiti
elevata pressione competitiva
architetture composite
necessità di competenze di dominio
contesto in evoluzione
 Project lifecycle

Il project manager affronta la complessità in tutte le

fasi del ciclo di vita del progetto:
formulazione dell’offerta e stima
definizione e pianificazione delle attività
costituzione e governo del project team
esecuzione e controllo delle attività
gestione dei rischi
controllo della qualità
comunicazione
 Proposal & Offering

Sempre più spesso la complessità dei progetti richiede

una doppia fase: Proposal (proposta con indicazioni
economiche, pro budget) e Offering (offerta formale
con dettaglio esplicito dei deliverable e delle
esclusioni, pro contratto).
Con la struttura di Ingegneria dell’Offerta e con la
creazione on-the-fly dei Proposal Team è possibile
rispondere in tempi brevissimi alle richieste (Request
for Proposal e/o Bandi Gara).
Gli strumenti a supporto delle stime
offrono i razionali a
giustificazione.
 Project Scope &
Definition

Il processo top-down di specificazione del Project

Scope e di definizione delle conseguenti attività di
dettaglio per la realizzazione dei deliverable offerti
richiede esperienza e competenze tecniche e di dominio
applicativo.
Con il Portfolio di Template (es. WBS, MetaFasi, etc.)
e con la Library costruita per la certificazione CMMI®
il project manager può utilizzare nello specifico
progetto l’esperienza sedimentata dai progetti
precedenti.
 Project Staffing

Proprio a causa del fatto che un progetto è

“un’attività svolta da persone per fare qualcosa che
non era mai stato fatto prima” è indispensabile poter
accedere alle migliori persone possibili, sia per
competenze che per esperienza.
Impiegando lo Skill Inventory e il “social networking
informale” presente in azienda, il project manager può
individuare le persone più adatte ai suoi obiettivi e
ingaggiarle nel progetto.
 Knowledge Sharing

Per loro natura i servizi di system & business

integration sono “knowledge intensive service”.
Molta della conoscenza e delle competenze necessarie
per erogarli efficacemente sono patrimonio delle
persone e possono essere condivisi anche grazie ad
infrastrutture dedicate allo scopo.
I sistemi di Knowledge Sharing e le
Digital Library consentono alle
persone ingaggiate nel progetto di
disporre di quel “capitale
intellettuale diffuso” che è il
principale asset aziendale.
 Competence Centre

Con lo spostamento dalla system integration pura,

patrimonio dei tecnologi, alla system & business
integration, vengono chiamate alla ribalta competenze
di dominio che i tecnologi puri non possiedono.
Inoltre il Cliente riconosce maggior valore a quelle
aziende che “parlano la sua lingua” e sono perciò in
grado di comprenderne a fondo le esigenze.
All’interno dei Competence Centre
sono disponibili le professionalità
in grado di dialogare efficacemente
con il management del Cliente,
massimizzando la comprensione delle
esigenze e consentendone la
traduzione in requisiti.
Presidio Tecnologico

L’elevata articolazione tecnologica presente nei

progetti di system integration si traduce in una
pluralità di piattaforme applicative eterogenee che
debbono operare organicamente interconnesse.
L’elevata specializzazione connessa con l’impiego di
queste piattaforme determina una frammentazione delle
competenze a cui spesso si unisce una rapida
obsolescenza dei saperi.
La funzione Ricerca & Innovazione
forma e offre specialisti dotati di
visione “olistica” del loro operato,
in grado di sintonizzarsi sulle
esigenze progettuali ed offrire
competenze tecnologiche
immediatamente fruibili.
 Project Management

L’attività centrale di project management è quella

relativa a pianificazione, esecuzione e controllo ed è
articolata in un’area economica ed una progettuale.
L’area economica è presidiata grazie al sistema di
Controllo di Gestione attraverso il quale sono gestiti
tutti gli elementi economici del progetto.
L’area progettuale è presidiata riferendosi alle
indicazioni metodologiche del CMMI® e del PMBOK® ed
impiegando MS Project®.
 Requirement

L’elemento più importante nella conduzione di un

progetto è la chiarezza dei requisiti: da essa
discendono stime, organizzazione, attività e
deliverable.
Per contro è inusuale che il Cliente sia in grado di
rendere completamente esplicite le sue esigenze,
lasciandole spesso inespresse o, peggio, variandole in
corso d’opera.
La Gestione Requisiti offre lo strumento
più efficace con cui raccoglierli,
tracciarne il soddisfacimento e
fronteggiarne le variazioni (“change
request”).
 Risk Management

Dall’elevata complessità sottesa ad un intervento di

system integration discende spesso un elevato livello
di rischio, sia realizzativo che economico.
Un costante presidio del rischio, articolato in tutti
i suoi componenti: relazioni con gli stakeholder,
aspetti contrattuali, instabilità dei requisiti, etc.
è l’elemento con cui il project manager può effettuare
una corretta politica di “risk mitigation”.
La Matrice dei Rischi è lo strumento con
cui presidiare i rischi di progetto,
ottenendone una valutazione il più
possibile oggettiva, utilizzabile come
base per la definizione delle
contromisure.
 Relationship

Last but not least: l’attività di relazione, interna

ed esterna.
La relazione con gli stakeholder del Cliente per
ottenere il costante riscontro alle decisioni
progettuali: dal livello tecnico al top management.
La relazione con il Project Team per mantenere la
corretta tensione e l’indispensabile condivisione
degli obiettivi.
Lo Steering Committee e lo Stato
Avanzamento Lavori sono gli
strumenti istituzionali deputati
alla comunicazione di progetto.
 L’altalena: una metafora
drammaticamente calzante.
 Come il Cliente ha
illustrato le
esigenze.

Requisiti, requisiti ed ancora requisiti.

La gestione “competente” e “documentata” dei requisiti è il
pilastro che sorregge il successo di un progetto.
Nel “competente” deve starci la necessaria traduzione tra esigenze
(scarsamente formali) e requisiti (molto formali). Può starci anche
la messa in discussione di alcune esigenze dissonanti rispetto allo
scope o ai tempi di progetto. Deve starci la capacità di
identificare le esigenze in conflitto.
Nel “documentata” ci deve stare la completa tracciatura di tutte le
variazioni, unica linea di difesa contro i costi nascosti nella
scarsa chiarezza.
 Come sono state
descritte le
funzionalità in
proposta.

La proposta è come il corteggiamento: vince chi è più “sexy”.

Di conseguenza la proposta deve sottolineare gli aspetti che
renderanno il progetto “confortevole”: piena comprensione delle
esigenze, tempi ridotti, architettura ottimale, ricchezza
funzionale, etc.
Occorre però evitare di generare un livello di aspettative
“artificiale” ed eccessivamente elevato che si scontrerà con la
“dura realtà” delle prime, difficili, fasi di progetto. È
indispensabile uno stretto rapporto tra il Proposal Team e l’Account
commerciale.
 Come le esigenze
sono state
comprese dal
Project team.

Una scarsa comprensione delle esigenze non può che originare

specifiche incoerenti.
È meglio investire risorse preziose (e costose) nelle fasi iniziali
per arrivare ad una piena comprensione (e formalizzazione) dei
requisiti piuttosto che sperare di “rimediare” in corso d’opera.
Così facendo si ottiene anche di influenzare positivamente la
percezione del management del Cliente (normalmente il detentore dei
requisiti) che incontra professionisti competenti proprio durante la
“luna di miele” iniziale, quando tensioni e sfiducia non sono ancora
presenti.
 Come le esigenze sono
state tradotte in
requisiti ed in disegno
architetturale.

Al crescere dei gradi di formalizzazione i nodi iniziano a venire al

pettine (ma la scarsa comprensione è sempre in agguato!).
I requisiti (e più ancora il disegno architetturale e,
successivamente, quello tecnico) richiedono maggior formalizzazione
e conseguentemente evidenziano i problemi di coerenza, di
realizzabilità o i conflitti logici.
C’è ancora tempo per ottenere una miglior comprensione anche
sfruttando il fatto che, durante questa fase, spesso si è immersi
nella realtà operativa del Cliente.
 Come sono stati
realizzati i
componenti

La realizzazione è l’evento con il più alto grado di formalizzazione

(esiste il software!) e, conseguentemente, di rigidità.
A valle della realizzazione c’è anche il primo momento di reale
confronto tra le esigenze del Cliente (talvolta da parte di
interlocutori diversi da quelli originariamente coinvolti) ed il
funzionamento concreto di quello che è stato realizzato.
Il modo per evitare un pericolo scollamento (che in questa fase
richiede una profonda rilavorazione) tra esigenze e realizzazione è
mostrare rapidamente dei semilavorati o prototipi in un approccio
che proceda per raffinamenti successivi.
Una corretta “tracciatura” dei requisiti che, partendo da questi
ultimi, raccolga in un filo logico i documenti di disegno, i
componenti realizzati (o attivati) e la loro documentazione è
fondamentale per evitare di lasciare il Cliente di fronte al
“deserto” del mancato collegamento tra esigenze e applicazione.
Non è solo questione di “manuale utente” ma soprattutto di poter
rispondere alle domande su come fare per attivare un particolare
processo di business.

Cosa è stato
documentato.
 Il “reworking” è il vero nemico del successo di un progetto: genera
insoddisfazione nel Cliente che vede protrarsi i tempi, frustrazione
nel Project team che lavora più volte sugli stessi componenti,
dilatazione dei tempi con effetti negativi a cascata e, soprattutto,
lievitazione dei costi, spesso non riconosciuti.
La vera causa del “reworking” è da addebitarsi alla mancata
comprensione delle esigenze, che viene alla luce solo dopo il
rilascio.
Ancora una volta il nefasto influsso di una non corretta gestione
dei requisiti.

Quanto è
costato il
progetto.
 La semplicità risulta spesso la carta vincente (“did you remember
the KISS principle”): è bene che il Project manager, attraverso
un’accorta combinazione di competenze e sensibilità di business,
sappia discriminare tra “complessità artificiali” e reali necessità.
Due sono gli elementi centrali:
evitare di cadere nella “autoreferenzialità tecnologica” per cui lo
strumento diviene un fine invece di restare un mezzo;
avere presente che Murphy con la “Legge del 90/90” ci ricorda che
l’ultimo 10% delle esigenze consuma uno sforzo asintotico.

Cosa voleva
Murphy’s Law on project
realmente il
scheduling. Cliente.
“The first 90% of the
project task takes 90% of
the time. The last 10% of
the project takes the other
90% of the time.”
La contraddizione del
Project Manager

manù
manus
mano “Una di quelle parole che
hanno sfidato i millenni è
to manage
‘mano’, dal latino ‘manus’.
manager Umberto Galimberti [...]
evocò la definizione
kantiana della ‘mano’ come
proiezione esterna della
mente. ‘Manus’, che non ebbe
un'etimologia, ha il suo
antecedente nell'antico
accadico ‘manù’ (calcolare,
computare).”
(Giovanni Semerano, "L'infinito: un equivoco
millenario", Bruno Mondadori, Milano, 2004)
La contraddizione del
Project Manager

“Poiché non siamo in

grado di misurare ciò che
è importante, tendiamo a
dare importanza a ciò che
è misurabile.”
(Milton)
 Project Manager
“olistico”

Il Project Manager “olistico” parte dalla razionalità,

dal calcolo, per governare la complessità, ma non
riduce tutto al calcolo. Egli ha la capacità di
“interpretare” la realtà e dotarla di “significato”:
leadership “by competence”
esperienza
relationship
ambizione
curiosità
orientamento al risultato
responsabilità
concretezza
passione
C'è bisogno di una prova per
conoscersi;
nessuno sa quel che può se
non sperimentandosi.
(Seneca)