06. Scoping Process Group
Indice
- Panoramica del Processo di Scoping
- Gestire le Aspettative del Committente
- Conditions of Satisfaction
- Project Scoping Meeting
- Requirements Breakdown Structure
- Alternative alla RBS
- Supporto alla Raccolta dei Requisiti
- Scegliere il PMLC Model
- Project Overview Statement
- Project Charter
- Approval Process
- Prossimi Argomenti
Panoramica del Processo di Scoping
Definizione
Il processo di scoping serve a definire il perimetro del progetto, chiarendo cosa deve essere prodotto, quali condizioni devono essere rispettate e quale approccio di project management usare.
In pratica: prima di pianificare in dettaglio, il team deve capire il problema o l’opportunita, i bisogni del committente, i requisiti principali e il tipo di ciclo di vita piu adatto.
Il processo sintetizzato nelle slide segue questa logica:
- Condurre le Conditions of Satisfaction.
- Definire i requisiti.
- Creare la Requirements Breakdown Structure.
- Valutare la completezza della RBS.
- Definire il PMLC model piu adatto.
- Scrivere il Project Overview Statement.
- Sottomettere il POS per l’approvazione.
Tools, Template e Processi
Per definire lo scope si possono usare diversi strumenti e processi:
- Conditions of Satisfaction.
- Project Scoping Meeting.
- Raccolta dei requisiti.
- Definizione dei processi aziendali e dei workflow.
- Diagrammi di processi aziendali.
- Prototipazione.
- Validazione dei business case.
- Project Overview Statement.
- Approvazione del POS da parte del senior management.
Client Wants vs Client Needs
Dilemma
Cio che il committente vuole potrebbe non coincidere con cio di cui ha bisogno.
Il compito del project manager e del team e verificare che i desideri del committente siano coerenti con i suoi bisogni reali e che il progetto consegni cio che serve davvero.
Gestire le Aspettative del Committente
Note
Lo scoping non e solo una raccolta tecnica di informazioni: e anche un processo di allineamento delle aspettative.
Per gestire correttamente le aspettative bisogna:
- Comprendere desideri, bisogni e aspettative del committente.
- Verificare che il committente abbia capito cosa verra fatto nel progetto.
- Assicurarsi che cio che il committente desidera sia cio di cui ha bisogno.
- Mettersi nei panni del committente.
- Dare al committente un ruolo attivo nella fase di scoping.
- Coinvolgere il committente il piu possibile.
- Tenerlo informato sullo stato del progetto.
- Definire con precisione lo stato corrente (as-is) e lo stato finale desiderato (to-be), distinguendo anche elementi nice-to-have.
Esempio
Se il committente chiede una nuova funzionalita, il team deve chiarire se quella funzionalita risolve davvero il problema operativo oppure se esiste un bisogno diverso non ancora espresso.
Conditions of Satisfaction
Definizione
Le Conditions of Satisfaction sono condizioni che devono essere rispettate per considerare soddisfacente il risultato del progetto.
In pratica: guidano la definizione dei requisiti e le decisioni durante il ciclo di vita del progetto. Non coincidono sempre con goal e obiettivi: possono aggiungere vincoli o condizioni specifiche.
Esempi di CoS indicati nelle slide:
- Completare alcuni componenti entro una certa data.
- Rispettare un budget.
- Usare una nuova tecnologia su cui l’azienda vuole investire.
- Prestare particolare attenzione alla User eXperience.
- Aderire a uno standard di qualita.
- Garantire performance in termini di tempi di risposta.
Note
Le CoS permettono di passare da una richiesta iniziale a una risposta concordata, fino alla negoziazione dell’accordo e alla scrittura del POS.
CoS vs Acceptance Criteria
Le slide distinguono due concetti:
| Concetto | Significato | Esempio agile |
|---|---|---|
| Conditions of Satisfaction | Determinano cosa deve essere il risultato del progetto o del work item | In Scrum possono essere definite dal Product Owner quando presenta nuovi work item |
| Acceptance Criteria | Determinano se il risultato puo essere accettato o meno | In Scrum sono definiti dal Dev Team e guidano verifica e test |
Warning
Le CoS aiutano a chiarire il risultato atteso; gli acceptance criteria incidono direttamente su come quel risultato verra verificato o testato.
Project Scoping Meeting
Definizione
Il project scoping meeting e la prima occasione concreta per incontrare il committente e iniziare a delineare lo scope del progetto.
Scopo principale:
- Documentare i requisiti tramite RBS.
- Produrre il Project Overview Statement.
Partecipanti tipici:
- Project Manager.
- Client Group.
- Core Team Members.
- Facilitator e Technographer.
Agenda Tipica
Un’agenda possibile include:
- Introduzione.
- Scopo del meeting.
- Discussione delle CoS.
- Descrizione dello stato corrente.
- Descrizione del problema o della business opportunity.
- Descrizione dello stato finale desiderato.
- Definizione e documentazione dei requisiti.
- Discussione del gap tra stato corrente e stato desiderato.
- Scelta del PMLC model piu adatto.
- Bozza e approvazione del POS.
- Eventuale aggiornamento a una riunione successiva.
Note
Il project scoping meeting puo durare molte giornate ed essere composto da piu sessioni anche distanti nel tempo.
Deliverable del Meeting
I deliverable attesi sono:
- CoS.
- Requirements Document, spesso tramite RBS.
- Best-fit PMLC model.
- POS.
Requirements Breakdown Structure
Definizione di Requisito
Definizione
Secondo IEEE Std 610.12, un requisito puo essere una condizione o capacita necessaria a un utente per risolvere un problema, una condizione che un sistema deve soddisfare, oppure la rappresentazione documentata di tali condizioni.
Secondo Wysocki, un requisito e uno stato finale desiderato che, se integrato con successo nella soluzione, fornisce all’organizzazione del committente un aumento specifico e misurabile di business value.
Raccolta dei Requisiti
Approcci citati per il requirements gathering:
- Facilitated Group Session.
- Interviews.
- Observation.
- Requirements Reuse.
- Business Process Diagramming.
- Prototyping.
- Use Cases.
| Metodo | Punti di forza | Rischi |
|---|---|---|
| Facilitated Group Session | Requisiti dettagliati, documentati e verificati subito; utile per processi cross-functional | Richiede tempo, costi e un facilitatore competente |
| Interviews | Coinvolge gli utenti finali; produce descrizioni high-level | Interviste poco strutturate o analisti prevenuti possono distorcere i bisogni reali |
| Observation | Utile quando le routine sono difficili da descrivere | Costosa, possibile presenza di problemi legali o sindacali, rischio di interpretazioni errate |
| Requirements Reuse | Riduce ridondanze e velocizza la raccolta | Richiede archivi, attenzione al diritto d’autore e al riutilizzo forzato |
| Business Process Diagramming | Usa comunicazione visuale e chiarisce what is/what is not | Dipende dall’apertura al cambiamento e richiede tempo |
| Prototyping | Aiuta utenti e team a chiarire la soluzione e la fattibilita | Il committente puo voler implementare il prototipo; difficile decidere quando fermarsi |
| Use Cases | Evidenzia flussi normali ed eccezioni | Puo richiedere interazioni lunghe e formazione costosa |
Caratteristiche e Vantaggi della RBS
Definizione
La Requirements Breakdown Structure organizza i requisiti in modo gerarchico, partendo dal project goal e dalla soluzione fino a requisiti, funzioni, sotto-funzioni e feature.
Caratteristiche:
- E coerente con le indicazioni del PMBOK.
- Usa un approccio basato sui deliverable.
- E intuitiva e significativa per il committente.
- Mantiene il contatto con il committente durante la pianificazione.
- Puo rappresentare la descrizione di piu alto livello della WBS.
Vantaggi:
- Non richiede necessariamente un facilitatore esperto.
- Evita strumenti troppo tecnici o con curve di apprendimento alte.
- Offre un approccio intuitivo alla raccolta dei requisiti.
- Permette al committente di lavorare in un ambiente familiare.
- Mostra quanto la soluzione e definita con chiarezza.
- Fornisce input per scegliere il PMLC model migliore.
Verifica degli Attributi
Controllo Qualita dei Requisiti
La RBS va valutata per capire se i requisiti sono completi, chiari, validi, misurabili e testabili.
Attributi da verificare:
- Completeness: manca qualcosa?
- Clarity: i requisiti sono chiari o ambigui?
- Validity: riflettono le intenzioni del committente?
- Measurability: esiste un criterio di misura?
- Testability: si puo verificare se il requisito risolve il bisogno?
- Maintainability: l’implementazione sara comprensibile e manutenibile?
- Reliability: requisiti di affidabilita e disponibilita soddisfabili?
- Look and Feel: percezione utente, GUI, ergonomia.
- Feasibility: requisiti implementabili?
- Precedent: simili a requisiti gia implementati?
- Scale: requisiti articolati e complessi?
- Stability: quanto possono cambiare?
- Performance: prestazioni costanti e soddisfacenti?
- Specifications: documentazione adeguata per progettazione, implementazione e test?
- Safety: requisiti di sicurezza dimostrabili?
Le categorie di requisiti citate sono:
- Functional Requirements: cosa il prodotto o servizio deve fare.
- Non-Functional Requirements: proprieta che il prodotto o servizio deve avere.
- Global Requirements: requisiti di alto livello.
- Product/Project Constraints: vincoli di prodotto o di progetto.
Alternative alla RBS
User Stories
Definizione
Una user story cattura gli elementi essenziali di un requisito chiarendo per chi e, cosa si aspetta dal sistema e perche e importante.
Template concettuale:
As a [role], I want to [action], so that [benefit].Elementi principali:
- Role: utente che interagisce con il sistema; il team di sviluppo non e un utente.
- Action: azione del sistema richiesta dall’utente; di norma una sola azione per user story.
- Benefits: benefici concreti, anche per stakeholder diversi dal protagonista della user story.
Le slide ricordano che c’e dibattito sulle definizioni di epic, theme, feature e user story.
INVEST
Note
I criteri usati per la RBS restano utili anche per le user story, ma negli approcci agile si puo usare anche INVEST.
INVEST significa:
- Independent: storie indipendenti si pianificano piu facilmente.
- Negotiable: non devono essere vincolate da specifiche troppo stringenti.
- Valuable: devono fornire valore, possibilmente incrementale.
- Estimable: devono essere stimabili.
- Small: abbastanza piccole da essere completate in una iterazione.
- Testable: devono essere testabili.
Warning
Negli approcci agile, definition of done e acceptance criteria non sono la stessa cosa: la prima definisce condizioni generali di completamento, i secondi sono specifici per ogni user story.
Supporto alla Raccolta dei Requisiti
Quando il committente fatica a immaginare la soluzione o il senior management non e convinto del valore economico, si possono usare strumenti di supporto:
- Diagrammi dei processi aziendali.
- Business Process Management e workflow.
- Prototipazione.
- Business validation.
- SWOT analysis.
Business Process e Workflow
Definizione
Un business process e un insieme di attivita che prendono input da una o piu sorgenti e producono un cambiamento di stato che fornisce business value.
Il business process diagramming puo usare formati come:
- Top-down, left-to-right.
- Swim-lane.
- Context diagramming.
- Use cases e use case diagrams.
Definizione
Un workflow, secondo WfMC, e l’automazione totale o parziale di un processo aziendale in cui documenti, informazioni o task passano da un partecipante all’altro secondo regole procedurali.
Nella progettazione di un sistema software che supporta processi aziendali bisogna definire il workflow da implementare. Potrebbe essere necessario reingegnerizzare i processi per ottenere beneficio dall’automazione.
PoC, Prototipo e MVP
| Strumento | Scopo |
|---|---|
| Proof of Concept | Verificare la fattibilita tecnica di un’idea |
| Prototipo | Mostrare aspetto e modalita d’uso per raccogliere correzioni e miglioramenti |
| Minimum Viable Product | Prima versione funzionante con sole funzioni principali, utile per feedback e business value iniziale |
SWOT Analysis, Business Model e User Journey
Definizione
La SWOT analysis identifica Strengths, Weaknesses, Opportunities e Threats relativi allo scope del progetto.
- Strengths: caratteristiche interne che possono favorire un risultato positivo.
- Weaknesses: caratteristiche interne che possono ostacolare il risultato.
- Opportunities: elementi esterni sfruttabili dal progetto.
- Threats: elementi esterni che possono causare problemi.
Definizione
Il business model descrive come l’organizzazione intende creare, distribuire e raccogliere valore.
Il modello di business incide sugli obiettivi del progetto e sui processi aziendali coinvolti. Le slide citano il modello canvas come approccio visuale per descriverlo.
Definizione
Lo user flow descrive i passi che un utente compie per usare una soluzione; lo user journey considera anche sensazioni, difficolta, soddisfazione e canali di interazione.
Differenza pratica: lo user flow mostra il percorso operativo; lo user journey aiuta a capire l’esperienza complessiva dal punto di vista dell’utente.
Scegliere il PMLC Model
Note
Il grado di completezza della RBS o del backlog e il fattore principale per scegliere il PMLC model.
I requisiti di alto livello possono essere quelli che forniscono direttamente la maggior parte del business value. Per il POS e opportuno considerare soprattutto questi requisiti, rimandando la definizione dettagliata di RBS e WBS alla fase di planning.
| PMLC Model | Quando usarlo |
|---|---|
| Linear | Soluzione e requisiti chiari; poche richieste di cambio scope; progetto routine e ripetitivo; template consolidati |
| Incremental | Condizioni simili al Linear, ma il cliente vuole business value incrementale; possibile qualche cambio scope |
| Iterative | Requisiti incompleti o soggetti a cambiamento; si imparera durante il progetto; alcune feature non identificate |
| Adaptive | Soluzione e requisiti solo parzialmente noti; molte possibili modifiche; sviluppo nuovo prodotto o process improvement; tempi stretti |
| Extreme | Goal e soluzione non chiaramente noti; progetto di tipo R&D |
Project Overview Statement
Definizione
Il Project Overview Statement e una descrizione sintetica del progetto usata come riferimento per il team di pianificazione, supporto alle decisioni e documento per ottenere l’approvazione a procedere.
Il POS rappresenta:
- Una dichiarazione generale del progetto.
- Un riferimento per il team di pianificazione.
- Un aiuto per le decisioni.
- Il documento per ottenere approvazione e nulla osta alla pianificazione.
Le slide indicano che, in alternativa, si puo usare un Project Charter.
Contenuto del POS
Sezioni principali:
- Problem/Opportunity: fondamento del progetto proposto.
- Project Goal: una o due frasi su come risolvere il problema o cogliere l’opportunita.
- Project Objectives: pochi statement che chiariscono cosa e incluso e cosa non e incluso.
- Success Criteria: criteri misurabili collegati al business value.
- Assumptions/Risks/Obstacles: assunzioni, rischi e ostacoli.
Attenzione
Nel POS vanno inclusi solo elementi rilevanti per il senior management. I dettagli troppo specifici vanno spostati nel Project Definition Statement o in documenti successivi.
Criteri SMART e IRACIS
Per goal e obiettivi, le slide citano i criteri S.M.A.R.T. di George Doran:
- Specific: obiettivo specifico.
- Measurable: indicatori misurabili.
- Assignable: chi deve conseguire l’obiettivo.
- Realistic: cosa e realistico con le risorse disponibili.
- Time-related: quando l’obiettivo puo essere raggiunto.
Per i success criteria viene citato IRACIS:
| Sigla | Significato |
|---|---|
| IR | Increased Revenue |
| AC | Avoided Costs |
| IS | Improved Services |
Warning
I success criteria devono essere quantitativi: quanto valore e entro quando.
Possibili allegati al POS:
- Risk Analysis.
- Financial Analyses.
- Feasibility studies.
- Cost/benefit analysis.
- Breakeven analysis.
- Return on investment.
Project Charter
Definizione
Il Project Charter, secondo PMBOK, e il documento che autorizza formalmente l’esistenza del progetto e assegna al project manager l’autorita di usare risorse organizzative per le attivita di progetto.
Benefici principali:
- Definisce project start e project boundaries.
- Crea una registrazione formale del progetto.
- Permette al senior management di accettare e impegnarsi formalmente.
- Stabilisce la partnership tra chi sviluppa la soluzione e il committente.
Warning
Il Project Charter, come il POS, non e un contratto: non entra nel merito del prezzo e delle condizioni contrattuali.
Input e contenuti collegati al Project Charter:
- Statement of Work.
- Business Case.
- Agreements.
- Enterprise Environmental Factors.
- Organizational Process Assets.
Il Project Charter documenta in particolare:
- Obiettivi misurabili e criteri di successo.
- Requisiti di alto livello.
- Assunzioni e vincoli.
- Descrizione di alto livello e confini.
- Rischi di alto livello.
- Milestone e budget sintetici.
- Stakeholder.
- Requisiti di approvazione.
- Project manager, responsabilita e autorita.
- Sponsor o persone che autorizzano il charter.
Approval Process
Definizione
L’approval process serve a ottenere dal senior management il nulla osta per procedere alla pianificazione del progetto.
Domande attese dal senior management:
- Quanto e importante il problema o l’opportunita per l’organizzazione?
- Quanto il progetto e legato ai Critical Success Factors aziendali?
- Il goal statement e collegato direttamente a problema o opportunita?
- Gli obiettivi rappresentano chiaramente il goal statement?
- Il business value giustifica i costi del progetto?
- La relazione tra objectives e success criteria e chiara?
- I rischi sono troppo alti e il business value troppo basso?
- Il senior management puo mitigare i rischi identificati?
Partecipanti al processo:
- Core project team.
- Project team.
- Project manager.
- Resource managers.
- Function/process managers.
- Client.
- Senior management.
Prossimi Argomenti
Continueremo con:
- Planning Process Group - passaggio dalla definizione dello scope alla pianificazione del lavoro, delle attivita e delle risorse.