Figura 28 - Analisi dei costi del Progetto F-XM
€ 0
€ 1.000
€ 2.000
€ 3.000
€ 4.000
€ 5.000
€ 6.000
€ 7.000
€ 8.000
€ 9.000
€ 10.000
€ 11.000
Ricerca di mercato Studio di fattibilità tecnica Studio di fattibilità economica Attività di controllo Disegno Attività di controllo Realizzazione prototipo finale Valutazione tecnica Valutazione economica Preparazione documentazione Deposito domanda Realizzazione stampo pilota Produzione serie test Test in azienda Attività di controllo Aggiornamento catalogo Produzione e preparazione serie anteprima Definizione costo di produzione Politica comunicazione Attività di controllo Invio anteprima ai clienti Definizione prezzo finale Attività di controllo Inizio produzione in serie Lancio del prodotto
Figura 29 - Analisi dei costi del Progetto F-Boa
Per entrambi i progetti, i costi sostenuti a consuntivo hanno rispettato il budget fissato inizialmente, nonostante sia stato necessario ricorrere al lavoro straordinario di alcune risorse allocate in attività critiche. Allo scopo di scongiurare sorprese legate ai costi indiretti, che, come precedentemente detto, verranno presi in considerazione per le sole commesse esterne che non prevedano la produzione successiva alla progettazione, sono
€ 0
€ 1.000
€ 2.000
€ 3.000
€ 4.000
€ 5.000
€ 6.000
€ 7.000
€ 8.000
€ 9.000
€ 10.000
€ 11.000
€ 12.000
Lavoro pregresso di progettazione Ricerca di mercato Studio di fattibilità tecnica Studio di fattibilità economica Attività di controllo Disegno Attività di controllo Realizzazione prototipo finale Valutazione tecnica Valutazione economica Preparazione documentazione Deposito domanda Realizzazione stampo pilota Produzione serie test Test in azienda Attività di controllo Aggiornamento catalogo Produzione e preparazione serie anteprima Definizione costo di produzione Politica comunicazione Attività di controllo Invio anteprima ai clienti Definizione prezzo finale Attività di controllo Inizio produzione in serie Lancio del prodotto
C.T. Pianificati Cumulativi [€] C.T. a Consuntivo Cumulativi [€] Budget di Progetto
stati inseriti nelle analisi anche i costi dei fattori produttivi indiretti, verificando che il budget come le date di chiusura non è stato superato.
Seguendo i principi dell’Agile Project Management, non è corretto però limitarsi ad una valutazione dei soli tempi e costi: riguardando tuttavia le attività precedenti e come il prototipo è evoluto nel tempo, non sono stati registrati tempi morti e, soprattutto nelle ultime fasi di progettazione meccanica, lavorare per release ha permesso da un lato di perfezionare i deliverable, ma dall’altro lato ha anche vincolato il team ai tempi di prototipazione.
Di seguito, viene affrontata la gestione dei progetti in Bartolucci, riprendendo la teoria dietro alle metodologie innovative di Project Management illustrata nel Capitolo 2, L’Agile Project Management, e applicandola sui due casi reali introdotti nel Paragrafo 3.2 Il Project Portfolio di Bartolucci.
La possibilità di gestire all’interno dell’ azienda due progetti molto simili sia per quanto riguarda la pianificazione delle attività sia in merito al deliverable finale ha permesso di poter guardare più oggettivamente alla disciplina della gestione dei progetti, tenendo conto degli accorgimenti che ogni modello di Project Management necessita per poter essere correttamente applicata nelle singole realtà aziendali.
Nel Paragrafo 2.1, Le origini ed il Manifesto Agile, tra i concetti fondamentali della famiglia di modelli “agili” è stata riportata anche l’importanza di fornire con cadenza regolare un output funzionante, utilizzandolo come oggetto di valutazione nei confronti del cliente (indifferentemente interno o esterno), ma anche come punto di partenza per raggiungere il risultato finale mediante iterazioni progressive.
È stato quindi richiesto in fase di progettazione meccanica di massimizzare, seppur ragionevolmente, lo sfruttamento della fase di prototipazione. Era stato infatti esposto come i modelli di Agile Project Management fossero nati specificamente per lo sviluppo software, che tra tutti i possibili deliverable si presta egregiamente alla possibilità di lavorare con frequenti release funzionali dell’output, prima di arrivare alla soluzione definitiva.
Con tutte le differenze del caso, anche un sistema di fissaggio leggero si presta ottimamente alla possibilità di lavorare “per rilasci”, dunque, in accordo con il titolare, è stata aumentata all’interno della fase di disegno la frequenza di richiesta di un prototipo.
Se inizialmente però può essere poco utile richiedere lo stampaggio di un pezzo fin troppo lontano dalla sua validazione, può più avanti costituire un importante strumento di verifica e, soprattutto in caso di commessa esterna, di comunicazione con il committente.
Sia per quanto concerne prodotti fisici, che per servizi, i prototipi si possono suddividere tipicamente per natura e per livelli:
Secondo il primo criterio, i prototipi funzionali replicano il principio di funzionamento, pur essendo lontani esteticamente dall’aspetto fisico del deliverable finale, mentre i prototipi estetici, al contrario, replicano esclusivamente il lato estetico.
La categorizzazione per livelli separa i prototipi alpha, cioè output di progetto molto lontani dalla soluzione finale sia come materiali e componenti, sia come processi di produzione, dai prototipi beta, costituiti con componenti e processi simili, e dai prototipi pilota, pressoché identici al prodotto finale.
Dunque, premesso che l’oggetto di progettazione in azienda è generalmente un pezzo più legato alle performance meccaniche che al mero lato estetico, in accordo con Bartolucci, per i due progetti è stata sfruttata la fase di prototipazione fin dai prototipi funzionali alpha, richiedendo sempre un minimo di due prototipi fino ad un massimo di cinque.
Richiedere sempre più di un prototipo per release ha avuto un duplice significato:
innanzitutto alcune caratteristiche tecniche oggetto di progettazione nell’iterazione precedente potevano richiedere più versioni possibili ed ugualmente valide, secondariamente per permettere al team di avere sempre un riferimento fisico a portata di mano su cui ragionare. Soprattutto negli ultimi sprint dedicati alla progettazione, quando i dispositivi avevano acquisito un’architettura più chiara, era diventata una prassi particolarmente apprezzata iniziare lo sprint meeting, disponendo accanto alle risorse del team il “proprio” dispositivo.
Un ulteriore accorgimento, sempre legato all’implementazione di un modello di Agile Project Management, è stato quello di guardare alla pianificazione delle attività in maniera meno rigida rispetto ai metodi sequenziali di gestione dei progetti, pur cercando di avere dei punti di riferimento temporali, forniti dalle milestone.
Aver pianificato e schedulato il progetto insieme al Product Owner e lo Scrum Master e condividendo le informazioni in merito allo sprint planning, ha permesso al team di sviluppo di avere tutte le informazioni necessarie per operare con consapevolezza ed in autonomia sprint dopo sprint, permettendo alle risorse di essere orientate al risultato finale e sentirsi parte integrante della mission dell’azienda.