Questo sito utilizza cookie per raccogliere informazioni sull'utilizzo. Cliccando su questo banner o navigando il sito, acconsenti all'uso dei cookie. Leggi la nostra cookie policy.OK

Quella sottile differenza fra project e product management

pittogramma Zerouno

Analisi

Quella sottile differenza fra project e product management

07 Mar 2011

di redazione TechTarget

Molti progetti falliscono perché si sbaglia l’approccio. Il project manager deve fare come un pilota di jet, “regolando” obiettivi, tempi e risorse per tenere il progetto “in rotta”

Quanti sono i progetti che sono stati consegnati in ritardo oppure con le specifiche non complete o non rispettando i budget? Tutti hanno riscontrato in azienda problemi di questo tipo, soprattutto quando si parla di sviluppo software.

Si tratta di un progetto o di un prodotto?

Il nucleo di quanto sperimentate quando incontrate ambiguità in un progetto, è che spesso si sbaglia il tipo di approccio applicando tecniche di project management, processi di product management o viceversa. Questa sottile differenza sta alla radice di gran parte delle mancate consegne dei progetti.

Secondo The Project Management Institute, un progetto è un “impegno temporaneo intrapreso per creare un unico prodotto, servizio o risultato”. Questa definizione è in netto contrasto con la natura del product management, che Wikipedia definisce come “una funzione organizzativa all’interno di una azienda che si occupa della progettazione, del forecast o della commercializzazione di uno o più prodotti in tutte le fasi del loro ciclo di vita”.

La tabella qui sotto evidenzia alcune differenze di base tra un approccio di project management e uno di product management.

Project management

Product management

Temporaneo

Continuo

Definiti l’inizio e la fine

Definito l’inizio ma non la fine

Inizio o upgrade

Ciclo di vita complessivo

Definiti obiettivi, piani e budget

Obiettivi, piani e budget sono in divenire


Se un progetto è un impegno temporaneo, come si fa a sapere quando è completato?

Nel project management tradizionale, il progetto termina quando si arriva all’obiettivo. Il successo è determinato dal fatto che in primo luogo, l’obiettivo sia stato raggiunto, e, in secondo e terzo luogo, che il progetto sia stato completato in linea con i tempi e il budget previsti.

Questi sono i tre lati del triplo vincolo o dell’iron triangle ai cui vertici (vincoli) troviamo l’ambito (cosa deve essere fatto), i tempi (quando deve essere fatto) e le risorse (quanto verrà a costare).

Si può applicare il triplo vincolo ai progetti agile?

Abbiamo già accennato all’Agile Project Management. Agile vuol dire anzitutto essere trasparenti su ciò che possiamo e non possiamo fare.

Nello spirito della trasparenza, siamo onesti: in molti progetti (soprattutto quelli software), dove ci sono diversi fattori imprevedibili, non possiamo gestire con accuratezza tutti e tre i lati – obiettivi, piani e budget – del triangolo di ferro. Quello che si può invece fare è tenere sotto controllo uno e gestire gli altri due in funzione dei loro cambiamenti dinamici attraverso:

  • una costante comunicazione al management dei fattori più importanti del progetto
  • una forte concentrazione sull’obiettivo finale del progetto
  • un’accurata gestione complessiva con obiettivi chiari, all’interno di tempi o budget prefissati.

Come un pilota di un jet, che costantemente regola i parametri per tenere l’aereo in rotta, il project manager aggiusta obiettivi, piani e budget per condurre un progetto a un perfetto atterraggio. Obiettivi, tempi e budget sono le tre leve su cui agire per far volare il progetto.

redazione TechTarget

Articolo 1 di 5