5.0 Gestione Modifiche (Change Management)
5.0.P1 Panoramica
Change Management
Si dice
che l’unica costante del mondo è il “cambiamento”. Tu puoi fare piani perfetti,
ma essi non possono mai tener conto di tutti i potenziali cambiamenti che
possono rendersi necessari. Più lungo è il tuo progetto, più probabilità ci sono
di dover gestire cambiamenti. Questo è uno dei motivi per cui il Processo
TenStep riconosce che i due processi iniziali definizione e pianificazione non
possono essere perfetti. Tu ed il tuo team dovete fare il meglio possibile sulla
base di ciò che conoscete in quel momento. Ciò è abbastanza valido.
Successivamente, bisogna gestire le modifiche.
Ci sono
numerosi aspetti relativi alle modifiche che possono verificarsi su un progetto.
Modifiche generali (non riguardanti contenuto e configurazione)
Questa
sezione del processo TenStep copre tutti gli aspetti delle modifiche. Su molti
progetti, l’aspetto più importante delle modifiche è la gestione delle modifiche
al contenuto, l’aspetto più esteso in questo passo.
5.0.P2 Modifiche al
Contenuto
Contenuto (Scope) è il termine utilizzato per
descrivere il perimetro del progetto. Il contenuto viene utilizzato per definire
ciò che il progetto realizzerà e ciò che non realizzerà. Per grandi progetti,
può comprendere le principali deliverable che vengono create, le organizzazioni
interessate, le transazioni impattate, i tipi di dati utilizzati, etc.
Se osservi i motivi per cui falliscono molti
progetti, di solito scopri che è dovuto a due problemi. O il team di progetto
non ha impiegato abbastanza tempo a definire il lavoro, e/o c’è stata carenza
nella gestione del contenuto. Anche se il project manager ha fatto un buon
lavoro nel definire il contenuto, la parte difficile arriva con il dover gestire
il progetto nei termini del contenuto concordato.
Lo scopo della gestione del contenuto è proteggere
l’applicabilità di Capitolato di Progetto e requisiti di progetto approvati. In
altri termini, il Capitolato di Progetto definisce il contenuto complessivo del
progetto, ed i requisiti di business definiscono le deliverable in dettaglio. Il
team di progetto si è impegnato per una scadenza e per un budget su queste
definizioni di alto livello e di dettaglio. Se le deliverable cambiano durante
il progetto (e di solito questo significa che il cliente vuole più funzioni), le
stime di costo, impegno e durata possono non essere più valide. Se lo sponsor
accetta di inserire il nuovo lavoro nel contenuto del progetto, il project
manager ha il diritto di aspettarsi che vengano modificati budget e scadenza
(di solito in aumento) per rispecchiare il lavoro aggiuntivo. Questa nuova
stima di costo, impegno e durata diverranno il nuovo target approvato.
A volte il project manager crede che gestire il
contenuto significhi dire "no" al cliente. Ciò rende il project manager nervoso
e preoccupato.
Invece, la buona notizia è che gestire il
contenuto significa permettere allo Sponsor di prendere le giuste decisioni che
modificheranno il contenuto del progetto.
Questo è troppo importante. Pochi clienti possono
vedere ed raccontare tutti i requisiti fin dall'inizio di un progetto. Perciò,
solitamente, ci sono modifiche che devono essere introdotte durante il ciclo di
vita del progetto. Queste modifiche possono essere molto necessarie per la
soluzione e ci possono essere valide ragioni di business per cui dovranno essere
apportate. Il project manager e il suo team devono riconoscere quando queste
modifiche sono necessarie. Però, devono seguire un predefinito processo di
modifica al contenuto. Questo processo, infine, fornisce le appropriate
informazioni allo Sponsor e gli consente di decidere se le modifiche dovranno
essere approvate, sulla base del valore di business e l'impatto sul progetto in
termini di costi e schedulazione.
5.0.P3 Modifiche alla Configurazione
Gestione
della Configurazione è il termine che esprime l’identificazione, il tracciamento
e la gestione di tutti gli asset di un progetto, e le caratteristiche (metadati)
degli asset stessi. In alcune organizzazioni questo processo è definito in modo
più ristretto per indicare soltanto la gestione fisica degli asset. Vedi
5.1.3.1 Gestione Configurazione per maggiori dettagli.
5.0.P4 Modifiche
Generali
Il tuo progetto potrebbe affrontare modifiche che non
necessariamente ricadono sotto la gestione delle modifiche al contenuto o la
gestione della configurazione. Queste modifiche possono essere raggruppate in
una categoria generale di change management. Per esempio, diciamo che un membro
del team lascia e deve essere sostituito. Questo non è un esempio di modifica al
contenuto, né una modifica alla configurazione. E’ un cambiamento in generale.
In questo caso, tu devi documentare il fatto che c’è bisogno di sostituire una
risorsa, determinare l’impatto del cambiamento, mettere in piedi un piano per
gestire la sostituzione, etc. Con tutto il rispetto, tu seguirai un processo
similare a quello di una richiesta di modifica al contenuto, anche se questa
modifica ed il suo impatto sul tuo progetto, non è il risultato di una richiesta
di modifica al contenuto.
Una differenza chiave tra change management generale e
gestione delle modifiche al contenuto è che tu ti aspetti che la modifica al
contenuto venga richiesta ed approvata, e tu modificherai budget e
schedulazione per adattare la modifica al progetto. Non puoi avere la stessa
aspettativa per modifiche non attinenti il contenuto del progetto. Nell’esempio
precedente quando il membro del team doveva essere sostituito, c’era un
cambiamento e probabilmente c’era anche un impatto sul progetto. Ma, non ci si
aspettava che questa modifica comportasse una modifica al budget o alla
schedulazione. Infatti, ci potrebbe essere impatto su schedulazione e budget.
Però, non ci può essere una aspettativa automatica che garantisce una
modifica a budget o schedulazione.
|
Gestione
Progetti