IT Project Management
Lezione 3 – Scope Management
Federica Spiga
[email protected]
A.A. 2010-2011
1
Identificare gli obiettivi di progetto
pecific
isurable
cheivable
ealistic
Se gli obiettivi di progetto non rispettano
queste caratteristiche difficilmente il
progetto avrà successo:
Se non sono specifici, non è possibile
individuare uno “scope” preciso
Se non sono misurabili, non è possibile
stabilire se il lavoro è stato completato o no
Se non sono realistici e raggiungibili, non
è possibile fare un piano adeguato
Se non ci sono dei limiti temporali, è
impossibile portare a termine il lavoro
Ime based
3
Scope del progetto
REQUISITI TECNICI (requisiti funzionali,
requisiti di performance, requisiti di
affidabilità ecc )
DELIVERABLES ( prodotti output del
progetto , es documentazione, report di
test, release del prodotto, ecc)
VINCOLI TEMPORALI
VINCOLI DI RISORSE (sia per richieste
del cliente, sia per mancanza di risorse da
parte del fornitore, ecc)
Definisce l’ambito non solo tecnico del
progetto.
4
Gestione dello Scope
La comunicazione (interna e con il
cliente) è fondamentale. Il Project
Management è al 90%
comunicazione
Completare TUTTE le attività
previste dal progetto e SOLO le
attività previste dal progetto
Fare enorme attenzione ai
cambiamenti dei requisiti per gli
impatti che hanno sul progetto
Ogni cambiamento richiesto deve
essere valutato e gestito
5
Gestione dello Scope
6
Gestione dello Scope
Dividere il progetto in una serie di
attività e task in modo da renderlo
più gestibile.
Si evita di “dimenticare” attività
importanti
Permette di associare agevolmente
attività alle risorse
7
Work Breakdown Structure
ork
reackdown
tructure
Strumento di supporto alla scomposizione analitica di
un progetto in tutte le sue parti.
Facilita l’attribuzione di responsabilità a persone e di
budget a sottoprogetti, la tempificazione del progetto, la
valutazione delle performance di progetto.
E’ la base per la stima dell’effort e dei costi di progetto
Per costruire una WBS occorre un criterio, un metodo di
classificazione che deve valutare e dare risposta ai
seguenti aspetti:
•Quale struttura?
•Quali criteri di scomposizione delle attività?
•Come descrivere i blocchi di attività scomposte?
•Quale livello di dettaglio?
•Quali modalità di aggregazione?
8
WBS
•Struttura:
•Struttura gerarchico – piramidale
•Logica top- down: dal generale al particolare
•Le attività o gli obiettivi previsti ad un livello,
dipendono da quelli situati al livello sottostante
Deve contenere tutte le voci consegnabili (deliverables
- prodotti del progetto, e milestones – punti di
controllo), e tutte le attività principali ad esse
necessarie.
Regola del 100%
Non ci devono essere sovrapposizioni tra due o più
elementi della WBS
NON è una pianificazione del progetto e non è una
lista in ordine cronologico
9
WBS: Regola del 100%
IL PMI precisa che
la WBS debba includere il 100% del lavoro definito dal progetto e includere TUTTO il
necessario - interno, esterno e appaltato - alla realizzazione del progetto, inclusa la gestione
del progetto stesso.
La regola del 100% è una delle più importanti linee guida per lo sviluppo, la
decomposizione e la valutazione della WBS.
La regola si applica a tutti i livelli della gerarchia: la somma del lavoro dei livelli "figli" deve
essere uguale al 100% del lavoro rappresentato dal loro "padre" e la WBS non dovrebbe
includere alcun lavoro al di fuori dai limiti del progetto, ovvero non può includere più del
100% del lavoro.
È importante ricordare che la regola del 100% si applica anche al livello di attività, Il lavoro
rappresentato dalle attività in ciascun pacchetto di lavoro devono dare, sommate, il 100%
del lavoro necessario per completare il pacchetto." (p. 8)
10
WBS
11
WBS
Qual è il giusto modo di procedere?
suddivisione in elementi troppo
piccoli porterebbe a entrare in un
dettaglio che nessuna fase
preliminare potrà mai raggiungere.
definizione di attività troppo ampia
ci porterebbe a sottostimare il peso di
un progetto.
Elaborazione progressiva.
(Rolling Wave Elaboration)
ridefinire le attività mano mano che il
lavoro inizia su ogni singolo elemento.
Ci si concentra inizialmente sull’aspetto
generale del progetto e mano a mano
dettagliare maggiormente.
La WBS quindi non può essere considerata
statica, ma dinamica e modificabile con
l’evoluzione del progetto.
12
Logiche di costruzione della WBS
La suddivisione del progetto in attività e sottoattività può essere effettuata
secondo diversi criteri, dipendenti dalla tipologia del progetto, il dominio del
progetto e/o lo standard scelto
CRITERIO PER FASI (o per PROCESSO): la scomposizione della attività viene
effettuata in base al ciclo di vita del progetto
CRITERIO PER DELIVERABLES: Il primo sottolivello è costituito da
macroblocchi di attività legati alla produzione dei deliverable del progetto. Usato
in progetti con un’alta standardizzazione (Consigliato dal PMI)
CRITERIO PER LOCALIZZAZIONE: la suddivisione gerarchica è connessa allo
spazio fisico o paese dove l’output del progetto verrà realizzato
13
Esempio WBS – Criterio per obiettivi
Analisi
requisiti
Documento
requisiti
Sviluppo Use
Cases
Portale
Definizione
della Grafica
Architettura di
Alto livello
Documento
Requisiti
Progetto SW 1
Definizione
Seqeunce
Diagram
Back end
Architettura di
alto livello
Sviluppo WBS
Task di
supporto
Progetto
Esecutivo
Piano di
progetto
Matrice
responsabilità
14
Esempio WBS – Criterio per fasi 1
Configuration
Management
Definire
configuration
Intem
Quality
Management
Preparare piano
di qualità
Analisi Requisiti
Sviluppo Use
Cases
Sviluppo
Architettura
applicativa
Progettazione
Interaction
Diagram &
Class Diagram
Progetto SW 1
Sviluppo caso
d’uso 1
Task di
supporto
Sviluppo & Unit
Test
Sviluppo caso
d’uso 2
Unit test
Integration &
System Test
Sviluppo WBS
Project
Management
Piano di
progetto
Matrice
responsabilità
15
Esempio WBS – Criterio per fasi 2
Quality
Management
Inception
Preparare piano
di qualità
Analisi Requisiti
Sviluppo Use
Case
Raffinamento
Use case
Definizione
Architettura
(SAD)
Definizione
Modello di
progetto
Iteration 1
Progetto SW 1
Definizione
modello dei dati
Elaboration
Iteration n
Implementazione
casi d’uso
Test
Siluppo caso
d’uso x
Costruction
Iteration 1
Test
Transiction
Iteraction 1
Integration and
System test
16
Esempio WBS – Criterio per localizzazione
Installazione
Deploy su
Roma
Configurazione
Progetto 1
Deploy su
Milano
Installazione
17
Descrizione delle attività
Ciascun elemento della WBS deve essere identificato da una descrizione che
deve essere al concisa, chiara e priva di ambiguità.
Ogni elemento della WBS deve essere identificato da un codice numerico o
alfanumerico che contiene un numero di item pari al numero di livelli presenti
nella struttura gerarchica
Deploy su
Roma 1
Progetto 1
Deploy su
Milano 2
Installazione
1.1
Configurazione
1.2
Installazione
2.1
18
Work Package
La suddivisione per livello procede riducendo ampiezza e complessità fino a
quando non perviene a una descrizione adeguata e inequivocabile della voce
finale. Quest ultimo livello si definisce “pacchetto di lavoro” o “work
package” e deve avere le seguenti caratteristiche:
DEVE ESSERE DISTINTO DA OGNI ALTRO PACCHETTO DI LAVORO
DEVE ESSERE PROGRAMMABILE IN TEMPI DI COSTI E RISORSE
DEVE AVERE UN SOLO RESPONSABILE
LA SUA DURATA DEVE ESSERE LIMITATA A PERIODI DI TEMPO DEFINITI
Nella pratica, un limite effettivo della granularità della WBS può considerarsi
raggiunto quando non è più possibile definire risultati di progetto pianificati, e i
soli dettagli rimanenti sono azioni; a meno che queste azioni non possano
essere ridefinite per conformarsi alla "regola del 100%", la WBS non dovrebbe
essere ulteriormente suddivisa.
19
Livelli della WBS
Generalmente la WBS ha circa 5-6 livelli.
•Non c’è un limite ai livelli possibili, ma una
WBS con più di 6 livelli rischia di essere
troppo dettagliata. Rischio di “micro
programmazione”
Normalmente i primi 2/3 livelli rappresentano
il Livello Manageriale
Gli altri livelli sono i livelli “tecnici” dove è
descritto un maggiore dettaglio delle attività
20
Tecniche di costruzione
Top Down: Si parte dal livello più alto, e si scompone nei livelli inferiori. Usabile se
•Contesto e problema ben conosciuto
•Tecnologie e processo ben conosciuti
Bottom Up: si parte da una serie di attività di dettaglio e si procede per astrazione fino ai
livelli superiori
•Pro: molto dettagliata
•Contro: procedimento dispersivo, si rischia di perdere il focus
Analogia: si parte da un progetto analogo al progetto che si deve analizzare e si procede
per analogia
•Pro: veloce, si possono utilizzare template
•Contro: si deve aver eseguito almeno un progetto simile
Rolling Wave: si suddivide il progetto in attività per successive iterazioni, man mano che
aumentano le informazioni
Operativamente si procede con una logica sia top down che bottom up. Nella scomposizione
in livelli si procede top down, per la definizione di ciò che contiene il pacchetto di lavoro si
procede invece bottom up. In quest’ultimo caso si compila un elenco dettagliato delle
attività che il progetto richiede… le attività vengono poi aggregate in un pacchetto di lavoro
gestibile da un solo responsabile e collocato nella struttura.
21
Matrice responsabilità
Dopo aver scomposto il progetto in attività e sotto attività, fino ai
workpackage, bisogna assegnare le attività ai singoli profili, stabilire chi è
l’owner del task e chi è a supporto
Livello 1
Livello 2
Livello 3
Project
Manager Analista
Test
Configuration Quality
Siluppatore Tester Manager Manager
Manager
Configuration
Management
Definire configuration
x
Owner
Quality
Preparare piano di qualità
Owner
Analisi Requisiti
Sviluppo Use Cases
Owner
Progettazione
Sviluppo
Architettura applicativa
Interaction Diagram & Class
Diagram
Owner
Owner
Owner
Sviluppo & Unit
Sviluppo caso d’uso 1
Sviluppo caso d’uso 2
Owner
Owner
Owner
x
Unit test
Integration &
Project
Sviluppo WBS
Piano di progetto
Matrice responsabilità
Owner
Owner
Owner
x
x
Owner
x
22