La letteratura scientifica è unanime nel riconoscere quanto sia indispensabile che l’organizzazione che realizza il progetto incarichi una persona — il project manager — di guidare il team di progetto e di rispondere in prima persona del raggiungimento degli obiettivi.
L’elemento decisivo è la seconda metà della frase. Un coordinatore che raccoglie stati di avanzamento e li inoltra non è un project manager; è un centralino. Il ruolo esiste perché qualcuno risponda del risultato, e questo richiede che abbia gli strumenti per influenzarlo.
I requisiti fondamentali
I requisiti fondamentali per un buon project manager sono (Corini, 2010):
- Interesse per i macrosistemi — la capacità di guardare l’opera intera, e non soltanto la parte che si conosce meglio. È il requisito che manca più spesso quando il ruolo viene assegnato al miglior tecnico disponibile.
- Capacità di sintesi — saper ridurre una situazione complessa a poche informazioni su cui si possa decidere. Un avanzamento che richiede quaranta minuti per essere spiegato non è stato sintetizzato.
- Attitudine ai rapporti interpersonali — il lavoro si svolge per la maggior parte del tempo attraverso persone su cui non si ha autorità gerarchica.
- Carisma e capacità di fare squadra — tenere insieme un gruppo che, in un’azienda organizzata per reparti, riporta a qualcun altro.
Colpisce che tre requisiti su quattro siano relazionali e nessuno sia strumentale. La competenza tecnica è data per presupposta, non è ciò che distingue: chi guida una commessa passa più tempo a negoziare che a calcolare.
Autorità e responsabilità
Il problema strutturale del ruolo è lo scarto fra responsabilità e autorità. Il project manager risponde della data di consegna, ma i saldatori riportano al capo officina, i disegnatori al responsabile tecnico e gli acquisti a un ufficio che ha priorità proprie. Formalmente non comanda quasi nessuno.
Ci sono due modi per ridurre lo scarto, e il secondo funziona meglio. Il primo è dargli autorità gerarchica, cosa che in un’azienda piccola raramente è praticabile. Il secondo è dargli informazione incontestabile: se lo stato della commessa è visibile a tutti nello stesso posto e nello stesso momento, la discussione non verte più su quale versione del piano sia quella buona, e il project manager non deve spendere autorità per stabilire i fatti. Il potere di convincere cresce quando i dati non sono in discussione.
Il project manager nell’engineering-to-order
In una carpenteria o in un costruttore di macchine speciali il ruolo ha tre caratteristiche ricorrenti.
È quasi sempre part-time: la stessa persona segue tre o quattro commesse e spesso conserva un incarico tecnico o commerciale. Questo rende il tempo la sua risorsa più scarsa e penalizza qualunque metodo che richieda una manutenzione continua di documenti.
È quasi sempre tecnico di formazione, il che è un vantaggio in reparto e un rischio a tavolino: la tentazione di risolvere personalmente il problema tecnico invece di gestirlo è forte e ben nota.
Ed è quasi sempre il punto di contatto con il cliente, il che significa che la gestione delle varianti passa da lui. È il momento in cui il ruolo produce o distrugge margine: una variante accettata al telefono e mai tracciata è lavoro svolto e non fatturato.
Distinguere i ruoli vicini
Vale la pena tenere separati tre incarichi che nelle aziende medio-piccole finiscono spesso sulla stessa persona. Il project manager risponde di una commessa. Il program manager risponde di un insieme di commesse correlate, tipicamente per lo stesso cliente o per lo stesso stabilimento. Il responsabile commerciale risponde della relazione con il cliente e delle condizioni contrattuali.
Sovrapporli è legittimo quando l’organico è ridotto, purché resti chiaro con quale cappello si sta decidendo. Chi negozia una variante come commerciale e la subisce come project manager tende, in perfetta buona fede, a fare uno sconto due volte.