Gestione dell'ambito

Che cosa comprende la gestione dell’ambito

Un costruttore installa una recinzione intorno al cantiere per delimitarlo. Definire l’ambito del progetto serve allo stesso scopo. La gestione dell’ambito definisce il lavoro necessario e assicura che il team lo completi per intero restando entro i confini concordati.

Pianifica in anticipo come determinare, gestire e controllare l’ambito. Raccogli i requisiti di tutti gli stakeholder e ottieni l’approvazione formale di un ambito ben definito. Raccogliere i requisiti soltanto dallo sponsor o da un piccolo gruppo può portare a un ambito inadeguato. Nei progetti di grandi dimensioni, la raccolta richiede più tempo, impegno e risorse, perciò una definizione chiara è particolarmente importante.

Usa l’ambito approvato per mantenere il lavoro entro i limiti del piano di gestione dell’ambito. Il gold plating, ovvero aggiungere elementi non richiesti, è vietato. Monitora l’ambito con continuità, così tutti possono distinguere il lavoro che rientra nel progetto da quello che ne è escluso.

Valuta gli effetti delle modifiche all’ambito su tempi, costi, rischi, qualità, risorse, soddisfazione del cliente e altri aspetti pertinenti. Usa la gestione integrata delle modifiche per approvarle. Chi propone la modifica aggiorna il relativo modulo e la modifica viene tracciata nel registro di controllo delle modifiche.

Apri il diagramma a grandezza naturale ↗

Apri il diagramma a grandezza naturale ↗

Ambito del prodotto

L’ambito del prodotto risponde alla domanda «Che cosa vuole il cliente?» L’organizzazione può avviare un progetto a parte per definirlo oppure definirlo mentre raccoglie i requisiti del progetto in corso.

In un progetto software, l’ambito del prodotto potrebbe essere «una nuova applicazione per gestire i flussi di lavoro che soddisfi i requisiti dei nostri clienti interni ed esterni». Per verificare se il progetto ha soddisfatto l’ambito del prodotto, confronta l’applicazione completata con i requisiti riportati nella relativa documentazione e nella descrizione dell’ambito del progetto.

Ambito del progetto

L’ambito del progetto è il lavoro necessario per realizzare l’ambito del prodotto. Nell’esempio del software comprende lo sviluppo dell’applicazione e le attività di pianificazione, coordinamento e gestione che ne consentono la consegna, come riunioni e rapporti. Queste attività sono trattate nel piano di gestione del progetto e nel relativo piano di gestione dell’ambito. Al termine del progetto o della fase, confronta il lavoro svolto con la baseline dell’ambito contenuta nel piano di gestione del progetto per verificare se rispetta l’ambito concordato.

Piano di gestione dell’ambito

Il piano di gestione dell’ambito riguarda pianificazione, esecuzione e controllo dell’ambito. Nel quadro dei processi adottato qui, il team lo sviluppa durante la pianificazione della gestione del progetto e lo include nel piano di gestione del progetto. Tratta gli aspetti seguenti.

• Come il progetto realizzerà l’ambito concordato.
• Quali strumenti servono al team per realizzarlo.
• Di quali fattori ambientali aziendali il team deve tenere conto.
• Quali asset dei processi organizzativi servono al team.
• Come il team gestirà e controllerà l’ambito durante tutto il progetto.

Le organizzazioni dovrebbero disporre di modelli, moduli o standard per la gestione dell’ambito. Sono essenziali per il lavoro di progetto. Alcune parti del piano si possono standardizzare, ma ogni progetto ha comunque bisogno di un piano proprio. Il project manager usa il piano di gestione dell’ambito come riferimento per guidare e misurare il progetto fino alla chiusura.

Il piano si può sviluppare per fasi e rivedere durante la pianificazione. Decidi prima come definire l’ambito. Dopo aver pianificato l’intero progetto, decidi come realizzare e controllare quell’ambito e inserisci le decisioni nel piano di gestione dell’ambito. Le attività di pianificazione successive, come quelle per le risorse umane, possono far emergere altri lavori da includere e richiedere un’ulteriore revisione.

Per preparare il piano, il project manager deve comprendere bene l’ambito. Individua l’ambito sia del prodotto sia del progetto prima di iniziare il lavoro. Il piano di gestione dell’ambito è obbligatorio nella gestione del progetto.

Processo di gestione dell’ambito

1. Determina i requisiti. Usa il business case descritto nel project charter per verificare che ciascun requisito sostenga il progetto.
2. Considera le esigenze degli stakeholder quando definisci l’ambito del prodotto e quello del progetto.
3. Usa una struttura di scomposizione del lavoro (WBS) per suddividere l’ambito in parti più piccole e gestibili.
4. Progetta il processo dal punto di vista del cliente.
5. Misura i risultati rispetto all’ambito e apporta le modifiche necessarie per tutta la durata del progetto.

Preparati a rifiutare il lavoro non necessario. Un ambito più ampio richiede più costi, tempo e impegno.

Raccogliere i requisiti

I requisiti descrivono ciò di cui il progetto o il prodotto ha bisogno per raggiungere i propri obiettivi dichiarati. Possono riguardare la qualità, i processi aziendali, i regolamenti, la conformità, la gestione del progetto e altri aspetti. La raccolta riguarda sia i requisiti del prodotto sia quelli del processo. Confronta ogni richiesta con gli obiettivi prima di includerla.

Durante l’avvio, il project charter riporta i requisiti generali del progetto e del prodotto. La raccolta dei requisiti riunisce informazioni più specifiche e le eventuali ipotesi correlate di tutti gli stakeholder. Requisiti mancanti possono portare al fallimento, a modifiche ripetute o a conflitti durante tutto il progetto.

Comincia individuando gli stakeholder e annotandoli in un registro. Un progetto può averne diverse centinaia e gruppi diversi possono richiedere metodi di raccolta diversi. Riserva tempo e impegno alla raccolta prima dell’inizio del lavoro. Una raccolta incompleta può comportare modifiche costose e laboriose. Le informazioni storiche e le lezioni apprese possono aiutare. Scegli tecniche adatte al progetto e agli stakeholder. Puoi usarle anche per individuare i rischi durante la gestione dei rischi.

Esaminare i dati storici

I dati storici e le lezioni apprese mostrano quali requisiti avevano i progetti simili e aiutano a individuare i processi pertinenti. Aiutano chi entra nel progetto a comprendere le aspettative dei diversi team. Possono anche rivelare gli errori commessi da altri project manager nel definire l’ambito, così puoi raccogliere requisiti che in quei progetti erano stati trascurati.

Interviste

Le interviste, talvolta dette interviste a esperti, aiutano il project manager a individuare i requisiti degli stakeholder relativi al prodotto o al processo. Si possono tenere individualmente o in gruppo, per e-mail, telefono, lettera o con altri mezzi.

Gruppi di discussione

Un moderatore o facilitatore raccoglie opinioni e requisiti da un gruppo selezionato di stakeholder o esperti della materia. La discussione può concentrarsi sul prodotto o su un aspetto del progetto.

Workshop con facilitatore

Un workshop con facilitatore riunisce stakeholder con punti di vista diversi per definire i requisiti di un prodotto o servizio.

Brainstorming

Il brainstorming genera molte idee in poco tempo facendo sviluppare ai partecipanti le idee degli altri. Per esempio, una persona propone un modo per definire l’ambito. La proposta fa venire un’idea a un’altra persona e questa, a sua volta, ne stimola un’altra. Invita persone con funzioni, esperienze e punti di vista diversi, interne o esterne all’organizzazione.

Tecnica del gruppo nominale

Dopo il brainstorming, i partecipanti classificano le idee migliori.

Tecnica Delphi

In questa tecnica di ricerca del consenso, gli esperti partecipano in forma anonima e non si incontrano. Invia loro una richiesta di informazioni, raccogli le risposte e rinvia i risultati per un ulteriore riesame. Ripeti finché gli esperti non raggiungono un consenso.

Mappe mentali

Una mappa mentale aiuta a generare idee e a organizzarle in gruppi logici. Disegna le idee principali come rami di un’idea centrale, poi aggiungi le idee collegate come diramazioni.

Diagrammi di affinità

Raggruppa per somiglianza le idee emerse dalle altre tecniche di raccolta dei requisiti. Assegna un titolo a ogni gruppo.

Apri il diagramma a grandezza naturale ↗

Questionari e sondaggi

Un questionario raccoglie le risposte a una serie di domande. Questionari e sondaggi possono raggiungere gruppi numerosi.

Osservazione

Osserva un potenziale utente del prodotto mentre lavora.

Prototipi

Un prototipo è un modello del prodotto proposto. Mostralo agli stakeholder e chiedi un riscontro. Il team può avere bisogno di più versioni per raccogliere tutti i requisiti, finalizzare il modello e ottenerne l’approvazione.

Decisioni di gruppo

I contributi di molti stakeholder possono generare idee in concorrenza tra loro, confusione o conflitti. Esamina e analizza ogni idea, approvala o respingila e assegna una priorità alle idee approvate prima di registrarle nei documenti di progetto.

• Unanimità. Tutti concordano sul requisito, quindi la decisione è semplice.
• Dittatura. Una persona decide per tutto il gruppo. La decisione è rapida e altri stakeholder possono non essere d’accordo.
• Maggioranza assoluta. Il gruppo adotta la decisione sostenuta da più della metà dei suoi membri.
• Maggioranza relativa. Se nessuna opzione raggiunge la maggioranza assoluta, il gruppo adotta quella con più sostenitori.
• Consenso. Il gruppo raggiunge una decisione che può accettare. I membri che preferivano un’altra opzione sono disposti ad accettare la decisione sostenuta dal maggior numero di persone.

Documentazione dei requisiti

Dopo che il team ha raccolto i requisiti, documentali in modo chiaro e senza ambiguità. La documentazione è un risultato della raccolta dei requisiti. Un requisito presentato male può essere frainteso. Chiedi agli stakeholder di confermare che i requisiti documentati soddisfino gli obiettivi dichiarati. Il loro riscontro aiuta a verificare che il team abbia raccolto i requisiti giusti e che il deliverable risultante sia accettabile.

Bilanciare i requisiti degli stakeholder

Assegna priorità ai requisiti e risolvi i conflitti affinché il progetto raggiunga i suoi obiettivi. Quando non puoi soddisfare tutti i requisiti, individua come conciliare le esigenze concorrenti relative ad ambito, tempi, costi, qualità, risorse, rischi e soddisfazione del cliente.

Continua a bilanciare i requisiti anche dopo averli raccolti. In seguito, alcuni requisiti degli stakeholder potrebbero entrare in conflitto con quelli del progetto o di altri stakeholder. Il project manager valuta queste esigenze rispetto agli interessi del progetto e risolve i conflitti.

Stabilisci obiettivi di progetto chiari. Durante la raccolta, individua e assegna una priorità a tutti i requisiti di tutti gli stakeholder. Entrambe le condizioni sono indispensabili per bilanciare i requisiti.

Risolvere i conflitti tra requisiti

I reparti possono avere interessi diversi in un progetto. Per esempio, dopo aver individuato un rischio, il team che si occupa dei rischi può voler rallentare il progetto, mentre il team operativo vuole finire prima. Cerca una soluzione che entrambi i reparti possano accettare.

I conflitti complessi richiedono l’intervento della direzione. Il project manager verifica quali requisiti sostengono il business case e riesamina il project charter, la descrizione dell’ambito e i vincoli.

Respingi le richieste che esulano dagli obiettivi del progetto o dal project charter approvato, anche se riguardano il motivo originario del progetto. Discuti con lo sponsor ogni modifica proposta al project charter per ottenere l’approvazione. Se il costo è il vincolo principale, le richieste che lo aumentano hanno meno probabilità di essere accettate. Quelle che contengono i costi senza incidere gravemente sugli altri vincoli hanno più probabilità di essere accettate. Le richieste che esulano da questi criteri possono essere prese in considerazione per un progetto futuro.

Piano di gestione dei requisiti

Questo capitolo presenta il piano di gestione dei requisiti come un risultato della raccolta dei requisiti. Il piano risponde alle domande seguenti.

• Quali metodi serviranno a individuare i requisiti?
• Quale analisi servirà per ciascun requisito?
• Come saranno stabilite le priorità dei requisiti?
• Come saranno gestiti?
• Come saranno tracciati?
• Quali informazioni deve fornire la matrice di tracciabilità dei requisiti?

Matrice di tracciabilità dei requisiti

In un progetto di grandi dimensioni, una documentazione inadeguata può far perdere alcuni requisiti. Un requisito può portare a diversi perfezionamenti o chiarimenti, rendendo difficile ricordare da dove proviene ciascuno. Perdere di vista il motivo di un requisito può impedire al progetto di raggiungere i propri obiettivi.

La matrice di tracciabilità è un altro risultato della raccolta dei requisiti. Collega i requisiti agli obiettivi del progetto, ad altri requisiti o a entrambi per sostenere gli obiettivi strategici. Usala durante tutto il progetto per analizzare le modifiche proposte all’ambito del prodotto o del progetto.

Apri il diagramma a grandezza naturale ↗

Definire l’ambito

Usa la documentazione prodotta dalla raccolta dei requisiti, il project charter e le informazioni su rischi, ipotesi e vincoli per definire l’ambito del prodotto e del progetto. Specifica che cosa è incluso e che cosa è escluso dal progetto e dai suoi deliverable.

La pianificazione è iterativa. Una volta noti i requisiti, usali per elaborare il cronoprogramma e il budget. Se uno dei due non soddisfa le aspettative della direzione o dello sponsor, riesamina i vincoli e bilancia i requisiti rispetto al budget e al cronoprogramma. Presenta alla direzione alternative per raggiungere gli obiettivi di ambito, tempi e costi. Puoi comprimere il cronoprogramma, trovare altri modi di svolgere il lavoro oppure adeguare il budget o l’ambito. L’obiettivo è ottenere un cronoprogramma e un budget realistici per realizzare l’ambito.

Analisi del prodotto

Analizza gli obiettivi e la descrizione del prodotto forniti dal cliente e dallo sponsor. Usa l’analisi per individuare deliverable concreti.

Descrizione dell’ambito del progetto

La descrizione dell’ambito è uno dei risultati principali della sua definizione. Prepararla richiede tempo e può richiedere contributi da più stakeholder, compresi esperti esterni. Individua esplicitamente due tipi di esclusione.

1. Ambito non approvato. Individua i lavori richiesti la cui inclusione non è mai stata approvata.
2. Ambito non necessario. Chiarisci i confini che si potrebbero facilmente fraintendere.

La descrizione dell’ambito del progetto, la WBS e il relativo dizionario costituiscono la baseline dell’ambito, che fa parte del piano di gestione del progetto. La descrizione può comprendere gli elementi seguenti.

• Ambito del prodotto.
• Ambito del progetto.
• Deliverables.
• Criteri di accettazione del prodotto.
• Attività fuori ambito.
• Vincoli e ipotesi.

Creare la struttura di scomposizione del lavoro (WBS)

Ogni progetto, grande o piccolo, ha bisogno di una WBS. La WBS suddivide l’intero ambito del progetto in deliverable gestibili. Senza una WBS, il progetto supererà la data di fine prevista e il project manager rischia anche di tralasciare attività importanti.

Apri il diagramma a grandezza naturale ↗

La maggior parte dei project manager compila un elenco di azioni da svolgere. Un elenco lungo può essere scomodo da usare, può omettere alcuni deliverable e rende difficile dividere un grande progetto in parti gestibili. Chi legge può avere difficoltà a capire il progetto o a individuare la persona che ha compilato l’elenco.

Una WBS tiene conto di ogni azione. La sua gerarchia mostra come il lavoro è suddiviso in pacchetti e come i deliverable si collegano tra loro. Il contributo degli stakeholder e del team aiuta a ottenere il loro sostegno e a migliorare i risultati. Creare la WBS permette al team di ripercorrere mentalmente il progetto e migliorare il piano. Questo facilita l’esecuzione, riduce i rischi, incoraggia la partecipazione e aiuta le persone a vedere che il progetto è realizzabile.

La WBS può assomigliare a un organigramma. Serve a scomporre il progetto e il lavoro richiesto per i deliverable in parti che puoi pianificare, organizzare, gestire e controllare. Inizia dall’alto e suddividi deliverable e lavoro in unità più piccole, chiamate pacchetti di lavoro.

Regole per creare una WBS

1. Coinvolgi il team.
2. Completa il primo livello prima di scomporre ulteriormente il lavoro.
3. Fai in modo che ogni livello sia una suddivisione di quello superiore.
4. Assicurati che l’insieme dei livelli della WBS renda comprensibile l’intero progetto.
5. Includi soltanto i deliverable di questo progetto.

Pacchetti di lavoro e conti di controllo

Un deliverable si può considerare un pacchetto di lavoro se soddisfa le condizioni seguenti.

1. Si può stimare in modo realistico e affidabile.
2. Si può completare rapidamente.
3. Si può completare senza interruzioni o ulteriori informazioni.
4. Si può affidare a un fornitore o dare in appalto, quando opportuno.

Numera i livelli della WBS una volta completata, affinché ogni pacchetto di lavoro abbia un identificativo. Alcuni progetti gestiscono i costi a un livello più alto della WBS, chiamato conto di controllo, anziché al livello dei singoli pacchetti.

Durante la pianificazione, il team usa la descrizione dell’ambito, la WBS e il relativo dizionario per scomporre i pacchetti di lavoro nelle attività necessarie a produrre i deliverable. L’elenco di queste attività si sviluppa nel processo di definizione delle attività, nell’ambito della gestione dei tempi.

La WBS è la base per il resto della pianificazione del progetto. La sua gerarchia grafica identifica tutti i deliverable. Per appartenere al progetto, un’attività deve riguardare un lavoro incluso nella WBS. La WBS aiuta il team a esaminare ogni parte del progetto e si può riutilizzare in altri progetti. Usala per mostrare la gerarchia e usa il diagramma reticolare del cronoprogramma per mostrare le dipendenze tra le attività.

Il project manager usa la WBS per suddividere il progetto. In questo contesto, la decostruzione e la scomposizione descrivono lo stesso processo.

Apri il diagramma a grandezza naturale ↗

Dizionario della WBS

Il dizionario della WBS descrive il lavoro previsto per ogni pacchetto. È un risultato del processo di creazione della WBS. Aiuta a prevenire l’espansione incontrollata dell’ambito e dà a tutti una descrizione chiara del deliverable. Può svolgere le funzioni seguenti.

• Fungere da sistema di autorizzazione del lavoro, indicando quando inizia un pacchetto di lavoro.
• Registrare le milestone, i criteri di accettazione e altri dettagli dei pacchetti di lavoro.
• Aiutare a controllare quale lavoro viene svolto.
• Aiutare gli stakeholder a comprendere l’impegno richiesto da un pacchetto di lavoro.

Apri il diagramma a grandezza naturale ↗

Baseline dell’ambito

Una baseline è la versione finale approvata di una parte del piano di gestione del progetto. La baseline dell’ambito comprende la descrizione dell’ambito, la WBS e il relativo dizionario. La direzione e gli stakeholder devono approvare tutti e tre gli elementi prima dell’inizio del lavoro. Confronta l’avanzamento effettivo con la baseline dell’ambito.

Richiedi una modifica per ogni scostamento dalla baseline dell’ambito. Gestisci la richiesta mediante il controllo integrato delle modifiche. Se viene approvata, aggiorna la descrizione dell’ambito, la WBS, il dizionario e ogni altro documento o componente interessato. Il rispetto dei requisiti e della baseline dell’ambito misura il successo del progetto.

Verificare l’ambito

La verifica dell’ambito aiuta a mantenere il progetto in linea con l’ambito approvato. Parla regolarmente con il cliente o lo sponsor e chiedi l’accettazione dei deliverable completati.

Input per la verifica dell’ambito

• Deliverable convalidati dal controllo della qualità.
• Descrizione dell’ambito, WBS e relativo dizionario.
• Matrice di tracciabilità dei requisiti.
• Documentazione dei requisiti.

Risultati della verifica dell’ambito

• Deliverable accettati.
• Richieste di modifica.
• Aggiornamenti ai documenti di progetto.

La verifica dell’ambito può avvenire alla fine di ogni fase o nel corso di tutto il progetto come parte del monitoraggio e controllo. Consente di ottenere l’accettazione formale dei deliverable intermedi da parte del cliente. Il processo di chiusura del progetto o della fase fornisce l’accettazione o l’approvazione definitiva del progetto o della fase nel suo insieme.

Controllare l’ambito

Il controllo dell’ambito ha due responsabilità principali. Misura le prestazioni rispetto all’ambito del progetto, del prodotto o di entrambi e gestisce le modifiche alla baseline dell’ambito. Verifica spesso l’ambito per capire se il lavoro procede come previsto.

I due input essenziali sono la baseline dell’ambito tratta dal piano di gestione del progetto e il lavoro completato fino a quel momento. Possono aiutare anche la documentazione dei requisiti e la matrice di tracciabilità. Individua gli scostamenti dalla baseline e raccomanda azioni correttive o preventive. Se occorre una modifica, presenta una richiesta, applica il controllo integrato delle modifiche e aggiorna i documenti necessari.

Il project manager controlla in modo proattivo il progetto rispetto alle baseline del piano di gestione del progetto. Segui il processo di gestione delle modifiche per ogni variazione dell’ambito.