Written by Secondo il PMBOK® Guide 7th Edition ci sono due definizioni molto importanti che riguardano questo Performance Domain:
Questo performance domain riguarda il set di attività inerenti la consegna dello scope di progetto nel rispetto dei requisiti di qualità.
Al completamento di tali attività, ci si aspetta che vengano realizzati i benefici attesi. Tale realizzazione deve portare alla soddisfazione degli stakeholder, che possono valutare gli esiti del progetto in modo diverso. Ad esempio un gruppo di stakeholder può dare valore alla facilità d’uso o al risparmio di tempo di un deliverable, mentre un altro gruppo al rendimento economico o alla differenziazione di mercato. Quindi il valore rilasciato ha molteplici aspetti e modi di essere inteso ed è per questo che come concetto è centrale per questo performance domain.
Rilascio di valore
E’ di fondamentale importanza aver chiaro che cosa si intende per “rilascio del valore”. I progetti che rilasciano deliverable durante il ciclo di vita, iniziano a rilasciare valore durante il progetto, mentre i progetti che forniscono deliverable solo al termine del ciclo di vita, generano valore dopo il primo rilascio (e a volte continuano a generarlo anche dopo anni che il progetto è teminato). Ma cosa si intende per deliverable? E’ il prodotto, il servizio o i risultati intermedi o finali di un progetto. Devono riflettere i requisiti degli stakeholder, lo scope e la qualità, oltre all’impatto a lungo termine sui profitti, sulle persone e sull’ambiente.
Requirements Elicitation
La raccolta dei requisiti è cruciale per il soddisfacimento delle aspettative degli stakeholder. Non si tratta solo di raccoglierli, ma anche di “stimolarne l’emersione”, dedurli, scorpirli e farli evolvere. Esistono una serie di metodi per ottenere questo risultato, che non è detto debba essere ottenuto interamente nelle fasi iniziali di progetto: in quei casi in cui si ha inizialmente una comprensione solo ad alto livello dei requisiti, possono avere una loro evoluzione nel tempo durante il ciclo di vita del progetto (vengono spesso “scoperti” proprio durante il lavoro).
Scope definition
La definizione dell’ambito di progetto è un processo continuo, che parte dalle fasi iniziali fino alla chiusura del progetto stesso.
Una volta che l’ambito viene definito, solitamente fa nascere l’esigenza di individuare ulteriori requisiti. Quindi esattamente come accade per i requisiti, ci si può trovare in situazioni in cui lo scope è definito in anticipo o in situazioni in cui evolve nel tempo o può essere “scoperto” durante il ciclo di vita del progetto.
Normalmente lo scope viene elaborato mediante delle tecniche di scpomposizione in modo da identificare in maniera efficace i deliverable di progetto e i relativi criteri di accettazione (è ciò che avviene nella creazione di una WBS – Work Breakdoen Structure in un contesto tradizionale o nella creazione di epiche e user story in un contesto agile).
A seconda dell’approccio di sviluppo utilizzato, ci sono diversi modi per descrivere i criteri di completamento dei deliverable. I più comuni sono gli acceptance o completion criteria (criteri che devono essere soddisfatti prima che il cliente accetti il deliverable o prima che il progetto sia considerato completo), la misura delle prestazioni tecniche (le specifiche tecniche di un prodotto possono essere documentate a parte oppure come estensione della WBS, il cosiddetto WBS Dictionary) e la Definition of Done (usata negli approcci adattativi, specialmente nei progetti disviluppo software: si tratta di una checklist con tutti i controlli che devono essere soddisfatti affinché un deliverable possa essere considerato pronto per l’utilizzo da parte del cliente).
I progetti che nascono in ambienti in cui i requisiti sono incerti e mutevoli rapidamente, hanno degli obiettivi di completamento che possono essere soggetti a modifiche. Per questo parliamo di “obiettivi di completamento mobili”. In mercati in cui la concorrenza è forte e continutamente vengono rilasciati sul mercato nuovi prodotti o nuove versioni di prodotti esistenti, può essere necessario aggiornare le funzionalità molto frequentemente. In tali ambienti, la definizione dell’obiettivo del progetto fornito è in costante movimento (“done drift”). Negli ambienti predittivi, la questione viene affrontata adottando dei change control systems, che aiutano ad evitare il fenomeno dello scope creep.
Qualità
Nelle attività di delivery, oltre a quelle relative alla gestione dei reqisiti e definizione dello scope, sono comprese quelle che riguardano i livelli prestazionali che devono essere soddisfatti da ciò che viene rilasciato. E’ questo che intendiamo quando parliamo di qualità. I requisiti di qualità influenzano i criteri di completamento, la Definition of Done, nel capitolato o nella documentazione dei requisiti. Condurre tali attività ha un costo, che deve essere bilanciato con il costo di sviluppo dei prodotti. Si parla cioè di “Costo della Qualità” (COQ – Cost Of Quality). Quella del COQ è una metodologia secondo cui vengono identificati quattro categorie di costi associate alla qualità: prevenzione, valutazione, difetti rilevati internamente (prima che venga consegnato il prodotto) e difetti rilevati esternamente (quando il prodotto è già in possesso del cliente).
Fonti:
- Wikipedia
- PMBOK® Guide 7th Edition
Immagini:
- Public domain images from Pexels