Qualche volta il committente ha difficoltà a immaginare la soluzione, oppure il senior management non è convinto che il progetto proposto possa avere un valore economico. In queste situazioni si può supportare il processo di raccolta dei requisiti con cinque strumenti:
Notate la doppia platea: i primi tre strumenti servono a sbloccare il committente, che non riesce a immaginare la soluzione; gli ultimi due servono a convincere il senior management, che non vede il valore economico. Sono problemi diversi e chiedono strumenti diversi.
Un processo aziendale è un insieme di attività che prendono uno o più input da una o più sorgenti e producono un cambiamento di stato che fornisce business value.
| Formato | Che cosa rende visibile |
|---|---|
| Top-Down, Left-to-Right | La sequenza delle attività dall'inizio alla fine, letta come una pagina. È il formato base con cui si comincia. |
| Swim-Lane | Le corsie dei diversi attori: rende evidente chi fa cosa e dove il flusso passa da un attore all'altro. Nella discussione a lezione emerge subito un miglioramento del processo: «se l'ordine è ok sarebbe utile una notifica». |
| Context Diagramming | Il processo in rapporto con le entità esterne che gli forniscono o ricevono dati. Anche qui la discussione fa emergere un'opportunità: «il warehouse potrebbe fornire dati per l'order processing». |
| Use Cases / Use Case Diagrams | Gli scenari di interazione tra attori e sistema, con flusso normale ed eccezioni. |
Osservate che cosa succede nei due esempi: appena il processo viene disegnato, qualcuno in sala vede un miglioramento che nessuno aveva formulato a parole. È esattamente il punto di forza dichiarato del Business Process Diagramming — «utilizza la comunicazione visuale» ed è una «verifica efficace del what is / what is not».
Il Business Process Management (BPM) si occupa di definire, integrare, gestire, monitorare, analizzare e ottimizzare i processi aziendali. Il processo di gestione dovrebbe essere iterativo e supportato dalle tecnologie, per garantirsi un efficace ed efficiente processo di miglioramento continuo (il riferimento a lezione è il Gartner's BPM Lifecycle).
Quando si affronta un progetto per realizzare un'infrastruttura tecnologica a supporto di processi aziendali è necessario considerare questi aspetti — e la domanda aperta del corso è: ci possono aiutare approcci Agile, DevOps?
«The automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules.»
In altre parole, il workflow identifica l'automazione, completa o anche solo parziale, di un processo aziendale, in cui dati e documenti sono elaborati e scambiati dalle diverse entità coinvolte per svolgere, con il supporto di un sistema software, le attività previste.
C'è la possibilità che ciascun processo aziendale debba essere adattato per ottenere il massimo vantaggio dalla sua automazione. Quindi, durante la progettazione, potrebbe essere necessario reingegnerizzare i processi aziendali: automatizzare un processo inefficiente produce un processo inefficiente più veloce, non un miglioramento.
Nella definizione dello scope si potrebbero avere dubbi sulla fattibilità o sulla soluzione necessaria all'utente finale. In questi casi si può ricorrere a tre strumenti diversi tra loro, che spesso vengono confusi.
La Proof of Concept (PoC) è utilizzata per verificare se un'idea (concetto) è fattibile dal punto di vista tecnico (feasibility), ossia per dimostrare se può essere realizzata con le tecnologie e le conoscenze a disposizione.
Un prototipo di un prodotto è una sua «rappresentazione», che serve a mostrare l'aspetto e la modalità d'uso consentita all'utente, per poter identificare eventuali correzioni o miglioramenti da apportare all'idea iniziale.
Un Minimum Viable Product (MVP) è la prima versione funzionante del prodotto, in cui sono implementate solo le funzioni principali. Consente di ottenere feedback dall'utente finale e di fornire subito del business value.
L'analisi SWOT è una tecnica di pianificazione strategica impiegata per identificare Strengths, Weaknesses, Opportunities e Threats relative allo scope del progetto.
Il modello di business descrive come l'organizzazione intende creare, distribuire e raccogliere valore. Ha un impatto fondamentale nel determinare gli obiettivi di un progetto e i processi aziendali che saranno coinvolti.
In un progetto interessano più modelli di business insieme: quello dell'azienda cliente; quello del prodotto o servizio che si intende realizzare; quello dell'azienda che svilupperà la soluzione; quello dei concorrenti — di chi sviluppa la soluzione e/o del cliente — con cui ci si deve confrontare.
Per definirlo e descriverlo si possono usare numerosi approcci: quello indicato dal corso come «molto interessante e facile da usare» è il modello canvas, che consente di visualizzare tutti gli elementi fondamentali del modello di business (il riferimento bibliografico è Osterwalder e Pigneur, Creare modelli di business).
Qui si chiude il cerchio aperto nel capitolo 1: Facebook aveva idea ed execution ma non il modello di business. Il canvas è lo strumento che, in fase di scoping, costringe a rispondere alla domanda che quel caso lasciava aperta.
| User flow | User journey | |
|---|---|---|
| Che cos'è | Il percorso che deve percorrere un utente per utilizzare una soluzione, suddiviso in una serie di passi che l'utente deve necessariamente effettuare per ottenere un dato risultato. | Una rappresentazione visuale del percorso che un utente può affrontare se impiega la soluzione. |
| Che cosa aggiunge | Definisce, per ogni requisito o funzionalità, quale percorso l'utente dovrà seguire. Serve ad architetto, sviluppatori e anche al committente. | Non descrive solo i passi, ma considera anche il «feeling» atteso dell'utente in termini di sensazioni, possibili difficoltà e soddisfazione. |
| Come si rappresenta | Di solito non è lineare: prevede diverse alternative, quindi si rappresenta con un flow chart che include vari percorsi. La versione semplificata è il cosiddetto «happy path». | Con template visuali dedicati, che mostrano le interazioni tra utente e soluzione sui diversi canali a disposizione. |
| A cosa serve | A definire con precisione i passi obbligati. | A scoprire possibili limiti nella user experience offerta o a individuare opportunità: è molto utile per capire il punto di vista dell'utente sull'intera esperienza. |
Il tipico percorso di acquisto su un sito di e-commerce:
Il grado di completezza della RBS (o del backlog) è il fattore di maggior rilievo per decidere quale PMLC model usare.
Altri due suggerimenti operativi:
| Modello | When to use it |
|---|---|
| Linear | The solution and requirements are clearly defined. You do not expect too many scope change requests. The project is routine and repetitive. You can use established templates. |
| Incremental | Same conditions as the Linear approach, but the client wants to deploy business value incrementally. There may be some likelihood of scope change requests. |
| Iterative | You feel that requirements are not complete or may change. You will learn about remaining requirements in the course of doing the project. Some features of the solution are not yet identified. |
| Adaptive | The solution and requirements are only partially known. There may be functionality that is not yet identified. There will be a number of scope changes from the client. The project is oriented to new product development or process improvement. The development schedule is tight and you can't afford rework or re-planning. |
| Extreme | The goal and solution are not clearly known. The project is an R&D type project. |
Il POS è una descrizione sintetica del progetto — Wysocki parla di una «singola» pagina, ma può includere anche qualche pagina a seconda della complessità — che rappresenta quattro cose insieme:
| Sezione | Che cosa contiene |
|---|---|
| Problem / Opportunity | Il progetto può riguardare la soluzione di un problema o lo sfruttamento di un'opportunità di business. Questa sezione descrive il fondamento su cui si basa il progetto proposto: uno statement che possa trovare tutti d'accordo e che si possa sostenere. |
| Project Goal | Una o due frasi su come si intende risolvere il problema o cogliere l'opportunità. Uno «scoping statement» che circoscrive l'ambito del progetto proposto. |
| Project Objectives | Pochi brevi statement — di norma 5 o 6, ma il numero dipende dalla complessità — che delimitano ulteriormente gli obiettivi descritti nel goal statement. Da questi deve essere chiaro cosa è incluso e cosa non è incluso; devono identificare chiaramente i principali risultati e deliverable; definiscono l'insieme degli obiettivi necessari e sufficienti. |
| Success Criteria | Spesso espressi in termini di IRACIS — Increase Revenue, Avoid Costs, Improve Service. Devono essere strettamente correlati al business value e misurabili: «use quantitative metrics only! How much and by when?» |
| Assumptions, Risks, Obstacles | Categorie: technological (nuova per l'azienda, obsolescenza); environmental (cambio del management, turnover del personale); interpersonal (rapporti di lavoro); cultural (adattamento all'azienda); causal relationships — cioè: la soluzione risolverà davvero il problema? |
Per la definizione di goal e obiettivi, George Doran ha suggerito i criteri S.M.A.R.T.: Specific (essere specifici nel definire un obiettivo), Measurable (stabilire indicatori misurabili per stabilire i progressi), Assignable (definire chi deve conseguire il completamento), Realistic (definire ciò che può essere realisticamente fatto con le risorse disponibili), Time-related (definire quando può essere raggiunto l'obiettivo). Alcuni autori interpretano l'acronimo in modo un po' diverso: il corso cita la variante proposta dal Lean Construction Institute.
Scrivi (o modifica) un goal e osserva quali criteri risultano soddisfatti. Il controllo è automatico e volutamente severo.
Bisogna fare molta attenzione a includere nel POS solo gli elementi che possono interessare il senior management. Gli elementi non inclusi, perché troppo specifici e dettagliati, devono essere inseriti nel Project Definition Statements (PDS). La lista degli elementi del PDS può essere molto estesa: tutti i dettagli raccolti costituiscono un ottimo input per le fasi successive — definizione delle attività, analisi dei rischi, piano finanziario.
Fra gli allegati spesso inclusi nel POS: Risk Analysis e Financial Analyses, cioè feasibility studies, cost/benefit analysis, breakeven analysis, return on investment.
L'esempio discusso a lezione è un progetto di riduzione dei costi delle forniture per ufficio, preparato da Olive Branch e approvato da Del E. Lama, con project manager Paul Bearer.
| Sezione | Contenuto dell'esempio |
|---|---|
| Problem / Opportunity | La task force di riduzione dei costi riporta che le spese per forniture d'ufficio hanno superato il budget in media del 4% per ciascuno degli ultimi tre esercizi. Inoltre è stato annunciato un taglio generalizzato del budget del 2% e si stima un'inflazione del 3% per l'anno. |
| Goal | Implementare un programma di contenimento dei costi che porti le spese per forniture d'ufficio entro il budget entro la fine del prossimo esercizio. |
| Objectives | 1) Istituire un sistema dipartimentale di budgeting e controllo delle forniture; 2) implementare un magazzino centrale per forniture d'ufficio e di copisteria; 3) standardizzare tipi e marche di forniture usate in azienda; 4) aumentare la consapevolezza dei dipendenti sulle pratiche di copia che riducono i costi. |
| Success Criteria | 1) Il costo totale del progetto è inferiore al 4% del budget annuale corrente per le forniture; 2) almeno il 98% delle richieste di forniture è evaso a richiesta; 3) almeno il 90% dei dipartimenti ha spese entro budget; 4) nessun dipartimento supera il budget di oltre il 4%. |
| Assumptions, Risks, Obstacles | 1) Il magazzino centrale può operare al punto di pareggio o sotto; 2) gli utenti saranno sensibili e favorevoli alle iniziative di contenimento; 3) si possono stabilire budget equi per le forniture; 4) il management sarà di supporto e coerente; 5) il sistema di controllo dell'inventario esistente può supportare l'operatività del magazzino centrale. |
Guardate i criteri di successo dell'esempio: sono quattro numeri con una soglia. Nessuno di essi dice «migliorare la gestione delle forniture». È questo che significa «use quantitative metrics only».
Cinque sezioni, con i controlli suggeriti dal corso. Il testo resta nella pagina: serve a esercitarsi, non viene salvato.
Il PMBOK propone di usare il Project Charter invece del POS:
«Develop Project Charter is the process of developing a document that formally authorizes the existence of a project and provides the project manager with the authority to apply organizational resources to project activities.»
«The key benefit of this process is a well-defined project start and project boundaries, creation of a formal record of the project, and a direct way for senior management to formally accept and commit to the project.»
Il project charter stabilisce la partnership tra chi svilupperà la soluzione e il committente — cosa vera anche per il POS. Ma attenzione:
Il project charter, come il POS, non può essere considerato un contratto, perché non entra nel merito del prezzo e delle condizioni. Nel caso di progetti esterni sarà stipulato anche un contratto formale tra le parti, che definirà contenuti e condizioni. Il charter stabilisce come un'organizzazione fornirà la soluzione, rispettando eventualmente un contratto. E, aggiunge il PMBOK: «the project charter provides the project manager with the authority to plan and execute the project».
| Input | Contenuto |
|---|---|
| Project Statement of Work (SOW) | La descrizione del risultato atteso dal progetto (prodotto, servizio o altro). Per progetti interni, chi ha promosso il progetto fornisce lo SOW basandosi sui bisogni dell'azienda e sui prodotti e servizi commercializzati. Per progetti esterni, lo SOW può essere una richiesta documentata del cliente (RFP, RFI), oppure un contratto o un bando. Si compone di: business need, product scope description, strategic plan. |
| Business Case | Fornisce tutte le informazioni necessarie a determinare se il progetto vale l'investimento richiesto; è utilizzato nel processo decisionale dal senior management. I bisogni aziendali e l'analisi costi-benefici che contiene servono a giustificare e stabilire i confini del progetto. Elementi tipici: market demand, organizational need, customer request, technological, legal requirement, ecological impacts, social need. |
| Agreements | Definiscono le intenzioni iniziali riguardanti il progetto e possono assumere diverse forme: contratti, memorandum d'intesa (MOU), accordi sul livello di servizio (SLA), letter of agreements, lettere di intenti, accordi verbali, e-mail o altri accordi scritti. |
| Enterprise Environmental Factors | Standard governativi, standard di settore o regolamenti (codici di condotta, standard di qualità); cultura e struttura organizzativa; condizioni del mercato. |
| Organizational Process Assets | Definizione dei processi aziendali e organizzativi, standard, policy, linee guida; template (per esempio il template di project charter); informazioni storiche e knowledge base sulle lezioni apprese, cioè informazioni e documenti raccolti da altri progetti. |
Dettaglio sui tre elementi dello SOW: il business need può dipendere dalla domanda del mercato, dal progresso tecnologico, da requisiti legali e regolamenti — e in genere bisogni aziendali e analisi costi-benefici sono contenuti nel business case che giustifica il progetto. La product scope description documenta le caratteristiche di prodotti, servizi e altri risultati del progetto, che ne giustificano l'esecuzione, e definisce la relazione tra i diversi risultati e i bisogni aziendali. Lo strategic plan documenta la visione strategica e gli obiettivi dell'azienda: tutti i progetti dovrebbero essere allineati con il piano strategico dell'organizzazione, così che ogni progetto contribuisca agli obiettivi strategici.
Alcuni elementi appartengono al POS di Wysocki, altri al Project Charter del PMBOK, altri ancora ai suoi input.
Il POS (o il charter) va sottoposto al senior management per ottenere il via libera a pianificare. Ecco le domande che ci si può attendere — vale la pena scrivere il documento avendole già in mente.
Ai partecipanti al processo di approvazione appartengono: core project team, project team, project manager, resource manager, function/process manager, client, senior management.
Le prime due esercitazioni del corso mettono al lavoro esattamente ciò che si è visto in questo capitolo e nel precedente, sul caso Pizza Delivered Quickly introdotto nel capitolo 4.
«Non esiste la soluzione corretta, ma tante soluzioni che potrebbero permettere il raggiungimento degli obiettivi. Ogni gruppo potrebbe proporre una soluzione diversa per risolvere il medesimo problema.» È la stessa impostazione con cui viene valutato l'elaborato d'esame: conta la solidità delle argomentazioni a supporto delle scelte, non l'aderenza a un modello.
Sul metodo di lavoro, due indicazioni operative: ogni gruppo deve leggere il testo e, quando lo ritiene necessario, può chiedere chiarimenti al docente, che svolgerà il ruolo del «committente»; le domande e le risposte saranno condivise con tutti i gruppi. È una simulazione fedele del ciclo delle Conditions of Satisfaction: la richiesta si chiarisce interrogando chi l'ha formulata.
Il caso PDQ contiene già, sparsi nel testo, gli elementi delle cinque sezioni: il problem (perdita del 30% del fatturato per il concorrente che consegna in 45 minuti), il goal (le pizza factory e i due tempi di consegna, 30 minuti crudo e 45 minuti cotto), i vincoli e i rischi (una presidente che dice di non risparmiare nulla e che il futuro dell'azienda dipende dal progetto). Il lavoro non è inventare: è estrarre e rendere misurabile.
È «un insieme di attività che prendono uno o più input da una o più sorgenti e producono un cambiamento di stato che fornisce business value». La differenza sta nell'ultima clausola: non basta trasformare input in output, il cambiamento di stato deve produrre valore per il business.
Top-Down / Left-to-Right (la sequenza letta come una pagina), Swim-Lane (le corsie degli attori, che rendono evidente chi fa cosa), Context Diagramming (il processo rispetto alle entità esterne che forniscono o ricevono dati) e gli Use Case Diagrams. Il valore dell'approccio è che usa la comunicazione visuale ed è una verifica efficace del «what is / what is not».
«The automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules.» La conseguenza: ciascun processo aziendale potrebbe dover essere adattato per ottenere il massimo vantaggio dall'automazione, quindi in fase di progettazione può essere necessario reingegnerizzare i processi.
La PoC verifica se un'idea è fattibile dal punto di vista tecnico, cioè se può essere realizzata con tecnologie e conoscenze a disposizione. Il prototipo è una rappresentazione del prodotto che mostra aspetto e modalità d'uso, per identificare correzioni e miglioramenti all'idea iniziale. L'MVP è la prima versione funzionante con le sole funzioni principali: consente di ottenere feedback dall'utente finale e di fornire subito business value.
Strengths: caratteristiche del progetto che potrebbero fornire un vantaggio rispetto alla concorrenza e favorire un risultato positivo. Weaknesses: caratteristiche che potrebbero fornire uno svantaggio e impedire un risultato positivo. Opportunities: elementi del mondo esterno che il progetto potrebbe sfruttare a suo vantaggio. Threats: elementi esterni che potrebbero causare problemi. Strengths e Weaknesses sono fattori interni, Opportunities e Threats fattori esterni.
Lo user flow è il percorso di passi che l'utente deve necessariamente effettuare per ottenere un risultato; di solito non è lineare, si rappresenta con un flow chart con percorsi alternativi, e la versione semplificata è l'happy path. Lo user journey è una rappresentazione visuale dello stesso percorso che però considera anche il «feeling» atteso dell'utente — sensazioni, difficoltà, soddisfazione — e le interazioni sui diversi canali: serve a scoprire limiti nella user experience o a individuare opportunità.
Il grado di completezza della RBS (o del backlog). Due suggerimenti collegati: i requisiti di più alto livello possono essere quelli che forniscono direttamente la maggior parte del business value, e i senior manager potrebbero preferire valutare solo quelli; e nella sezione obiettivi del POS conviene considerare solo i requisiti di più alto livello, rimandando la definizione definitiva di RBS e WBS alla fase di planning.
Problem/Opportunity (il fondamento del progetto, uno statement condivisibile e sostenibile); Project Goal (una o due frasi su come risolvere il problema o cogliere l'opportunità, uno scoping statement che circoscrive l'ambito); Project Objectives (di norma 5–6 statement che chiariscono cosa è incluso e cosa no, identificando i principali deliverable); Success Criteria (IRACIS, misurabili); Assumptions, Risks, Obstacles.
S.M.A.R.T. (George Doran), per goal e obiettivi: Specific, Measurable, Assignable (chi deve conseguirlo), Realistic (con le risorse disponibili), Time-related. IRACIS, per i criteri di successo: Increase Revenue, Avoid Costs, Improve Service. La regola che li accompagna: «use quantitative metrics only! How much and by when?»
Il Project Definition Statement raccoglie gli elementi non inclusi nel POS perché troppo specifici e dettagliati per interessare il senior management. Esiste perché il POS deve contenere solo ciò che interessa a chi decide; ma quei dettagli non vanno persi, anzi costituiscono un ottimo input per le fasi successive: definizione delle attività, analisi dei rischi, piano finanziario.
È il documento che autorizza formalmente l'esistenza di un progetto e fornisce al project manager l'autorità di applicare risorse organizzative alle attività di progetto; il suo beneficio chiave è un inizio e dei confini ben definiti, un record formale del progetto e un modo diretto perché il senior management accetti e si impegni. Non è un contratto — come non lo è il POS — perché non entra nel merito del prezzo e delle condizioni: per i progetti esterni sarà stipulato anche un contratto formale a parte.
È la descrizione del risultato atteso dal progetto. Per progetti interni lo fornisce chi ha promosso il progetto, basandosi sui bisogni aziendali e sui prodotti e servizi commercializzati; per progetti esterni può essere una richiesta documentata del cliente (RFP, RFI), un contratto o un bando. Si compone di business need, product scope description e strategic plan — quest'ultimo garantisce che il progetto sia allineato con gli obiettivi strategici dell'organizzazione.
Quanto è importante il problema o l'opportunità per l'organizzazione? Quanto il progetto è legato ai Critical Success Factors aziendali? Il goal statement è legato direttamente al problema/opportunità? Gli obiettivi sono una chiara rappresentazione del goal statement? C'è sufficiente business value, misurato dai criteri di successo, per giustificare i costi? La relazione tra obiettivi e criteri di successo è stabilita chiaramente? I rischi sono troppo alti e il business value troppo basso? Il senior management può mitigare i rischi identificati?
Chiede di scrivere il POS (o un documento equivalente con struttura propria) e la RBS (o un'alternativa) per il caso PDQ, individuando per ogni obiettivo e per ogni requisito il business value corrispondente, le assunzioni, i rischi e gli ostacoli; è incoraggiato modificare o sostituire la struttura proposta a lezione. Il criterio: non esiste la soluzione corretta, ma tante soluzioni possibili. Il docente svolge il ruolo del committente e le domande e risposte sono condivise con tutti i gruppi.