Esercitazioni di Gestione dell'innovazione e dei progetti

Flessibilità: risorse (entrambe), sovrapposizione delle attività, sono state sviluppate alternative e l'output è stato costruito in modo modulare.

1.b Alla luce delle informazioni qui riportate, valutate le performance di progetto. Cosa è possibile dire circa il raggiungimento degli obiettivi specifici e degli obiettivi strategici? Giustificate la risposta.

Pratica

Gli obiettivi strategici sono stati raggiunti perché sono stati commissionati altri progetti, tuttavia sono stati raggiunti parzialmente perché hanno fatto slittare alcuni progetti, perché sono arrivati lunghi con i tempi. Questo può portare ad una brutta immagine dell'azienda.

Gli obiettivi specifici:

• Tempo: non è stato raggiunto l'obiettivo perché sono stati prolungati
• Costi: sono il doppio, quindi non è stato ben gestito
• Qualità: ampiamente raggiunto

1.c Mettetevi nei panni della Green Venture Spa, la quale vuole fare

tesoro dell'esperienza maturata in questo primo progetto. Quali principi di gestione non adottati nel corso del primo progetto potrebbero essere utili al fine di migliorare le performance dei nuovi progetti? Giustificate la risposta. Pratica Quello che possiamo consigliare è di applicare alcuni principi nel progetto:

• Coinvolgere gli stakeholders dalle fasi iniziali tramite meeting, video call, email;
• Usare dei metodi di lavoro più strutturati, non fermarsi alla mera stima di costi e tempi ma usare delle metodologie proprie nella gestione del progetti;
• Fare più leva sull'esperienza derivante da esperienza precedenti (sia per il PM che per le funzioni), dovrebbero sfruttare di più la loro conoscenza di progetti del passato, oppure venire a conoscenza di progetti simili fatti anche magari da altre aziende, per fare una stima generale del progetto;
• Essendo un impianto innovativo consiglio di condurre test e prove (o sviluppo di prototipi) prima

dellosviluppo vero e proprio del prodotto, per essere più flessibile ed arrivare al prodotto finito con caratteristiche molto buone, grazie al passaggio dai test di verifica e validazione.

Spartacus è un'azienda molto forte sul mercato ed innovativa. Ora sviluppa una bici estremamente innovativa.

1. Elencate e descrivete le variabili rilevanti che occorre prendere in esame al fine di definire correttamente la struttura organizzativa di progetto.

   Teoria

   Ci sono 3 variabili principali per descrivere i progetti (fattori contingenti):

   • Rilevanza del progetto (più è elevata, più richiede un PM forte, quindi è un decisore, prende in mano tutte le decisioni del progetto)
   • Criticità degli obiettivi
   • Novità/innovatività del progetto

   Altre variabili sono:

   • Competenze specifiche delle risorse nelle funzioni: si tende a preferire una struttura debole quando le competenze specifiche sono nelle funzioni. Se fosse forte il PM ha in mano tutte

Le decisioni delle risorse; invece in una struttura debole viene dato più spazio alle competenze specifiche delle funzioni Ruolo del PM: dal testo non si evince, se i fattori contingenti hanno un livello elevato, questo fa si che PM avrà un ruolo forte, ma non abbiamo niente a riguardo nel testo Livello di criticità nel rilascio delle risorse: quanto è problematico rilasciare le risorse appartenenti al team di progetto una volta che è finito. Se PM è forte prende decisioni e gestisce risorse in mano alle funzioni, ciò vuole dire che è più difficile riportare le risorse nelle funzioni; quindi in media si tende a preferire una struttura debole, perché almeno tutte le risorse sono in mano alle funzioni, una volta finito il progetto restano in mano alle funzioni. Più è difficile il rilascio, più si tende a preferire una struttura debole. Criticità nella valutazione delle performance: non

c'è nulla nel testo, ma più la criticità è alta, più si preferisce una struttura forte o debole. Quello più difficile è la valutazione della performance nei casi intermedi perché avendo un ruolo improntante sia il PM sia le funzioni, non si capisce chi deve fare cosa, c'è confusione e ciò non permette una valutazione oggettiva e non c'è una raccolta dati efficiente. Più questa è alta si tendono a preferire strutture deboli o forti.

Per l'esame non è importante dire se i valori sono elevati meno, ma è importante giustificare la risposta. Giustificare il ragionamento che c'è dietro alle proprie scelte. Non solo dire se è alto o basso, (es. la rilevanza del progetto risulta elevate perché viene detto che progetto è importante e PM è di tipo forte ecc.) Bisogna mischiare info nel testo con la discussione da parte nostra.

2.b

Per il progetto sopra descritto, consiglierei di adottare una struttura organizzativa matriciale. Questa scelta è motivata dal fatto che i fattori contingenti sono molto elevati, il che richiede una struttura forte come una task force. Tuttavia, sono anche richieste competenze specifiche dalle funzioni, il che suggerisce l'utilizzo di una struttura debole. L'organizzazione matriciale rappresenta quindi un compromesso tra queste due esigenze. Per quanto riguarda il peso della figura del PM, sarebbe preferibile che assuma un ruolo intermedio. Se il PM fosse troppo forte, potrebbero sorgere problemi di conflitto con le funzioni, che hanno un ruolo importante nel progetto. D'altra parte, se il PM fosse troppo debole, potrebbe non essere ascoltato e non riuscire a svolgere efficacemente il suo ruolo di coordinamento. Quindi, un ruolo intermedio per il PM sembra essere la scelta migliore in questa situazione. Per quanto riguarda la struttura dei progetti gestiti in Blossom, sembra che venga adottata una struttura flessibile. Questa scelta sembra coerente con la tipologia di progetti gestiti, in quanto la flessibilità consente di adattarsi meglio ai cambiamenti e alle esigenze specifiche di ciascun progetto. Tuttavia, potrebbero esserci alcune criticità migliorabili nella struttura dei progetti. Ad esempio, potrebbe essere utile definire in modo più chiaro i ruoli e le responsabilità di ciascun membro del team, al fine di evitare ambiguità e conflitti. Inoltre, potrebbe essere utile stabilire una comunicazione più efficace tra il PM e le funzioni, al fine di garantire una migliore collaborazione e coordinamento.la sequenzialità è molto rigida e non è possibile iniziare una fase successiva prima che sia stata completata quella precedente. Questo approccio è adatto quando il livello di incertezza del progetto è basso e l'innovazione è limitata. Approccio flessibile, le fasi sono definite ma possono sovrapporsi parzialmente, consentendo uno scambio maggiore di informazioni. Questo approccio è preferibile quando il livello di incertezza è alto e l'innovazione è elevata. La sovrapposizione parziale delle fasi consente di anticipare i vincoli e favorisce l'integrazione e lo scambio tra le diverse fasi. In pratica, l'approccio stage gate prevede una netta separazione tra le fasi, mentre l'approccio flessibile consente una maggiore flessibilità e adattabilità durante lo sviluppo del progetto.

ciò ci fa capire che i gate sono bene definiti e c'è una forte sequenzialità tra le fasi. Una cosa che potrebbe trarci in inganno è il pezzo di verde, sono due attività che non sono sovrapposte ma vengono svolte in parallelo, non ci sono scambi di informazioni tra le due fasi, sono solo parallele ed è diverso dal dire che sono sovrapposte. In caso di incertezza (se siamo incerti sulla scelta tra i due approcci) come questo bisogna valutare lo scambio di informazioni e siccome non ci sono, non è flessibile. Un meeting può essere visto come un gate per poi passare alla fase successiva, si scambiano informazioni solo alla fine. Una volta finito un gate vado a dire alla funzione dopo che ho finito e che si passa al gate dopo. Se è di bassa incertezza si usa questo approccio. È coerente perché il state gate è ottimale nei casi di bassa incertezza, quindi è coerente. Non ci sono molte informazioni sulla criticità.

Nel testo viene detto che il cliente viene coinvolto nelle fasi del progetto, ma non viene detto nulla sulle funzioni interne, sono coinvolte le parti esterne ma non c'è coinvolgimento delle funzioni interne e ciò deve essere migliorato. Bisognerebbe fare quindi delle riunioni anche per le funzioni interne per dividere i ruoli. 3.b In base a quanto descritto quale tipologia di project manager è adottato dall'impresa? Vi sembra che tale figura sia correttamente progettata? Teoria

• PM debole è un facilitatore (non ha il controllo delle funzioni) perché le attività e le gestione delle risorse sono in mano alle funzioni interne dell'azienda. Non c'è un controllo delle funzioni.
• PM bilanciato è un coordinatore, non ha mero controllo sulle funzioni ma le negozia con i functional manager, c'è un equilibrio tra manager di funzione e PM e tra di loro si negoziano le risorse. C'è un

controllointermedio delle funzioni

1. PM forte, gestisce tutto lui, le funzioni non hanno potere decisionale. E' un mero decisore. C'è un controllo delle funzioni
2. Pratica: Qui il PM è debole, nel rosa si dice che PM non ha grande ruolo e siccome deve gestire diversi progetti, non ha una gestione completa delle funzioni. E' coerente con il tipo di progetto, i progetti in media non sono innovativi quindi non avrebbe senso avere un PM forte e i progetti sono molto piccoli. In media un progetto ha un valore di 500 mila euro, quindi questo è un progetto piccolo. Gestisce tanti progetti quindi non riesce ad avere un ruolo forte. Il PM viene semplicemente notificato, è un facilitatore, facilita la risoluzione di alcuni problemi che poi sono le funzioni che devono risolverle.

DDT4.a Indicate per i diversi fattori prima riportati se questi contribuiscono alla definizione del ruolo del PM (in termini di PM forte o debole) e come.

Teoria: Per distinguere se un PM

è debole o forte (fattori contingenti):

• Rilevanza del progetto: quanto il raggiungimento degli obiettivi strategici del progetto è rilevante ai fini dellabuona riuscita
• Criticità del progetto: quanto sono stringenti e critici gli obiettivi specifici del progetto (tempo costi e qualità)
• Novità/innovatività del progetto

Più questi fattori contingenti sono preponderanti, più in media si sceglie un PM di tipo forte.

• Ruolo delle funzioni: se svolgono un ruolo critico all’interno del progetto (se è critico di solito il PM è debole)
• Ruolo del PM che necessitiamo: ci serve un facilitatore, decisore o coordinatore?
• Rilascio risorse: più è complicato più si preferisce ruolo di tipo debole del PM
• Misurazione delle performance: più è complicato misurarle, più si preferisce un PM forte o PM debole, il problema è quando ci sono casi intermedi

Pratica4.b In

A base di quanto prima indicato, adotteremmo un Project Manager forte per entrambi i progetti. Questa scelta è giustificata dal fatto che entrambi i progetti richiedono una gestione rigorosa e competente per garantire il successo. Un Project Manager forte avrà le competenze e l'esperienza necessarie per gestire le sfide e le complessità dei progetti in modo efficace, assicurando che le risorse siano allocate correttamente, i tempi siano rispettati e gli obiettivi siano raggiunti.