Parte VII — Caso di studio ed esercitazioni · Capitolo 19

Caso PDQ, esercitazioni e linee guida del progetto

~50 min di lettura3 widget interattivi3 tavole

In questo capitolo

  1. Il caso Pizza Delivered Quickly (PDQ)
  2. I sei sottosistemi della soluzione
  3. L'esercitazione 1+2: POS e RBS
  4. I gruppi di esercitazione
  5. Il progetto d'esame: linee guida
  6. Il percorso di ripasso completo
  7. Verifica le tue conoscenze

1. Il caso Pizza Delivered Quickly (PDQ)

Il caso di studio del corso è Pizza Delivered Quickly (PDQ), proposto da Wysocki in «Effective Project Management: Traditional, Agile, Extreme» (Wiley); il materiale è distribuito in due copie identiche (PDQ e PDQ-2). PDQ è una catena locale di 40 negozi di pizze da asporto e con consegna a domicilio, che ha recentemente perso il 30% dei ricavi soprattutto per il calo della consegna a domicilio. La causa attribuita: il principale concorrente ha lanciato una garanzia di consegna in 45 minuti dall'ordine alla consegna, mentre PDQ pubblicizza la consegna in un'ora.

Pepe Ronee, Supervisor of Computer Operations, è incaricato di sviluppare un'applicazione software per identificare le location delle «pizza factory» e il sistema software necessario a gestirle. Dee Livery, la presidente, commissionando il progetto ha detto di «tirare fuori tutte le fermate» (pull out all the stops): «il futuro di PDQ dipende da questo progetto». Il team deve valutare due opzioni:

Le pizza factory non avranno spazio retail: la loro unica funzione sarà ricevere ordini, preparare e consegnare le pizze. L'ordine arriva a una struttura centrale di ordinazione (central ordering facility) e viene instradato alla factory più vicina al cliente, che lo processa e consegna entro 30 o 45 minuti dall'inserimento dell'ordine, a seconda che la pizza sia richiesta pronta per il forno o già cotta. Pepe ha identificato sei applicazioni software per la soluzione.

Il sistema PDQ Central ordering facility ordini telefonici in un'unica sede Store eat-in e consegna Pizza factory nessun retail: riceve, prepara, consegna Pizza van produzione e consegna mobili L'ordine arriva alla struttura centrale e viene instradato elettronicamente a store, factory o pizza van: la van è un'unità mobile di produzione e consegna, e l'assegnazione dell'ordine deve considerare dove si troverà al momento della consegna.
Tavola 19.1 — Il sistema PDQ: struttura centrale di ordinazione, store, pizza factory e pizza vans. La complessità logistica delle vans mobili è al centro del caso.

2. I sei sottosistemi della soluzione

Le sei applicazioni software identificate da Pepe sono «ovviamente progetti di sviluppo software molto diversi, che richiedono approcci molto diversi»:

  1. Pizza Factory Locator Subsystem: trova le location delle pizza factory; non si sa quante servano né dove collocarle. «The goal can be clearly defined, but even at that the solution will not be at all obvious»: richiede uno strumento di modellazione molto sofisticato, requisiti non ovvi e una soluzione «elusive» da scoprire durante lo sviluppo.
  2. Order Entry Subsystem: supporta le operazioni di store e factory; gli ordini telefonici arrivano in un'unica sede e vengono instradati elettronicamente. «Focuses on routine business functions and should be easily defined»: può usare software commerciale COTS.
  3. Order Submit Subsystem: instrada l'ordine a store, factory o pizza van. «The logistics for making this assignment are not at all clear, and subsystem design will be complex».
  4. Logistics Subsystem: «the most complex of the six subsystems»: richiede una visione olistica dell'intero sistema PDQ, perché le pizza vans sono unità mobili di produzione e consegna — l'assegnazione di un ordine deve considerare dove sarà la van al momento della consegna.
  5. Routing Subsystem: l'instradamento dei camion di consegna; «straightforward», probabilmente con sistemi GPS installati su tutti i camion.
  6. Inventory Management Subsystem: gestisce le scorte di tutti gli store e le factory e riordina automaticamente dall'unico fornitore; «should also be a COTS application» — e il fornitore ha informato PDQ che può ottenere sconti usando il riordino automatico.

La conclusione del caso: «The six subsystems that make up the PDQ solution may each require a different project management approach» — ci saranno esercizi a ogni capitolo per formare la strategia e trovare e mantenere l'approccio best-fit (i modelli PMLC del capitolo 4).

I sei sottosistemi: complessità crescente Routing — straightforward GPS sui camion Inventory Management — COTS riordino automatico dal fornitore Order Entry — routine, COTS facilmente definibile Order Submit — design complesso logistica di assegnazione non chiara Factory Locator — modellazione obiettivo chiaro, soluzione elusiva Logistics — il più complesso visione olistica, vans mobili «These applications are obviously very different software development projects requiring very different approaches.» Ogni sottosistema può richiedere un approccio di project management diverso: il lavoro del caso è trovare il best-fit per ciascuno.
Tavola 19.2 — I sei sottosistemi PDQ per complessità crescente: dal routing e dall'inventory (semplici, COTS) al factory locator e alla logistica (soluzione elusiva o visione olistica).

Riconosci i sottosistemi dal loro profilo

Sei descrizioni prese dal caso. Per ciascuna scegli il sottosistema che descrive, poi verifica.

3. L'esercitazione 1+2: POS e RBS

L'esercitazione n. 1 + 2 chiede di scrivere il POS / Project Charter e di definire i requisiti (RBS o altro) per la proposta di progetto del caso «Pizza Delivered Quickly». Le buone pratiche suggeriscono di includere le seguenti sezioni nel POS o in un documento equivalente con struttura definita dagli studenti:

I quattro suggerimenti del docente:

  1. individuare per ogni obiettivo il corrispondente business value, le assunzioni, i rischi e gli ostacoli;
  2. modificare la struttura del POS e/o del Project Charter proposta a lezione, cercando di migliorarla;
  3. proporre un documento «alternativo» al POS e al Project Charter (basta anche solo la struttura);
  4. anche per i requisiti individuati, individuare il corrispondente business value, i rischi e gli eventuali ostacoli/assunzioni.

Durante la definizione dello scope del progetto e del corrispondente POS o Project Charter è necessario costruire la RBS (oppure una descrizione dei requisiti alternativa), che poi sarà finalizzata durante il planning. Ogni gruppo può strutturare la RBS e la sua presentazione «come meglio crede, provando a trovare la soluzione "migliore" per il proprio team».

Che cosa include il POS secondo le buone pratiche?

Sette voci. Scegli Sì se le buone pratiche dell'esercitazione la includono tra le sezioni suggerite del POS, No altrimenti; poi verifica.

4. I gruppi di esercitazione

L'esercitazione si svolge in gruppi: il corso pubblica la composizione dei 9 gruppi (da 2 a 4 membri ciascuno), da «unire» prima di partire con l'esercitazione.

Nota del redattore

La fonte originale elenca i nominativi e gli indirizzi e-mail dei partecipanti; in questa pagina non vengono riprodotti i dati personali, ma solo la struttura organizzativa (numero di gruppi e consistenza di ciascuno) necessaria a comprendere l'attività.

5. Il progetto d'esame: linee guida

L'esame è orale e prevede la verifica delle conoscenze acquisite durante il corso e la discussione di un elaborato: la simulazione delle attività di «gestione di un progetto di sviluppo software» reale o di fantasia. Ogni elaborato deve prevedere due sezioni:

L'obiettivo non è l'implementazione del software (che non dovrà essere eseguita), ma dimostrare la capacità di gestire un progetto. Gli elaborati devono essere concordati con il docente.

Come sarà valutato

Regole e suggerimenti

Che cosa serve nell'elaborato?

Sei affermazioni sulle linee guida del progetto. Scegli Sì se coerente con le linee guida, No altrimenti; poi verifica.

6. Il percorso di ripasso completo

Le linee guida del progetto chiedono di documentare tutte le fasi: scoping/initiating, planning, launching/execution, monitoring & controlling, closing. Ecco la mappa completa dei 19 capitoli del corso, con le parti e le fonti da cui derivano — il punto di partenza per preparare l'elaborato e l'orale.

Il percorso completo: 7 parti, 19 capitoli Parte I — Fondamenti cap. 1–4 · fonti 1–4 + caso Parte II — Processi e avvio cap. 5–11 · fonti 5–7 Parte III — Launching cap. 12–15 · fonte 8 Parte IV — Monitoring & Controlling cap. 16 · fonte 9 Parte V — Closing cap. 17 · fonte 10 Parte VI — Kanban e altro cap. 18 · fonte 11 Parte VII — Caso di studio ed esercitazioni cap. 19 · caso PDQ, esercitazione POS-RBS, gruppi, linee guida Le cinque fasi richieste dall'elaborato corrispondono alle parti II–V: scoping (cap. 6–7), planning (8–11), launching (12–15), monitoring & controlling (16) e closing (17). Gli approcci agili e Kanban (cap. 2, 4, 18) sostengono le scelte da argomentare.
Tavola 19.3 — La mappa completa del corso: sette parti, diciannove capitoli, undici fonti più caso di studio, esercitazione e linee guida. Il corpus è coperto integralmente.

Come preparare l'esame

Verifica le tue conoscenze

Che cosa è successo a PDQ e qual è la sfida del progetto?

PDQ (40 negozi) ha perso il 30% dei ricavi a causa del calo della consegna a domicilio, attribuito al concorrente che garantisce 45 minuti contro l'ora pubblicizzata da PDQ. La sfida: consegnare la pizza non cotta («pronta per il forno») in 30 minuti o meno, oppure pre-cotta in 45 minuti o meno, usando pizza factory senza spazio retail servite da una struttura centrale di ordinazione.

Quanti sottosistemi compongono la soluzione PDQ e quale è il più complesso?

Sei: Factory Locator, Order Entry, Order Submit, Logistics, Routing, Inventory Management. Il più complesso è il Logistics Subsystem, perché richiede una visione olistica del sistema e le pizza vans sono unità mobili di produzione e consegna.

Quali sezioni suggeriscono le buone pratiche per il POS?

Problem/Opportunity, Goal, Objective, Success Criteria, Assumptions, Risks, Obstacles — o un documento equivalente con una struttura definita dagli studenti.

Come si consegna l'esercitazione 1+2?

Il risultato (POS + RBS o varianti con commenti) va inviato via mail entro le ore 24 di venerdì 24 aprile, con oggetto «Esercitazione – Gruppo X», elencando i membri del gruppo con le rispettive mail (che devono essere anche in CC). Non esiste la soluzione corretta: ogni gruppo può proporre una soluzione diversa per lo stesso problema.

In cosa consiste l'elaborato d'esame?

Nella simulazione delle attività di gestione di un progetto di sviluppo software (reale o di fantasia), in due sezioni: descrizione dell'approccio utilizzato e documentazione di progetto. L'obiettivo non è l'implementazione del software (che non dovrà essere eseguita), ma dimostrare la capacità di gestire un progetto. L'elaborato va concordato con il docente.

Quali fasi devono essere documentate nell'elaborato?

Scoping/initiating, planning, launching/execution, monitoring & controlling, closing — con l'illustrazione di ogni documento allegato, e per i meeting l'ordine del giorno, i partecipanti e una sintesi dell'ipotetico svolgimento.

Come sarà valutato l'elaborato?

Per gli aspetti relativi alla gestione del progetto, in base alle buone pratiche del corso e della letteratura e alla solidità delle argomentazioni; sono premiati i contributi originali, gli approfondimenti autonomi e l'uso di strumenti di supporto. La parte architetturale non è valutata se non per ciò che è correlato alla gestione, ma le scelte architetturali e di gestione devono essere coerenti.

Quando va consegnato l'elaborato?

Almeno una settimana prima dell'orale (su appuntamento, anche fuori dagli appelli indicati), concordato con il docente; il ricevimento è su appuntamento per chiarimenti e supporto.