I doveri (di fronte a se stesso) del Committente

Autore: Roberto Gallerani

In ogni progetto, e quindi anche di carattere informatico e organizzativo,  il committente è il principale decisore e, in quanto tale, per la miglior garanzia di buona riuscita dell’opera ha, di fronte a se stesso,  alcuni importanti doveri dettati dal  buon senso e dalla necessità  essere “colui che affida” e “non colui che si affida”.

Per prima cosa ci chiediamo: cosa è un committente?

“Chi ordina un lavoro, una prestazione, o si impegna ad acquistare una merce per conto proprio” secondo la principale definizione che si può trovare in un comune dizionario della lingua italiana.

Paradossale è il fatto che pur essendo ìl committente  il principale attore di un qualsisasi progetto,  non esiste una formazione per diventare committente: la strada più comune è quella di imparare dai propri sbagli.

Penso  che possa essere indiscutibile sostenere che il committente è la figura disposta a sostenere i costi per il progetto, e che ha la responsabilità di valutare se il risultato è accettabile. E’ il principale decisore del progetto, ed il suo ruolo deve essere indiscutibilmente chiaro ed accettato da tutte le parti interessate all’andamento ed agli esiti del progetto (i cosiddetti  “stakeholders”).

Tra le tipiche  responsabilità di un committente troviamo:

• partecipare in modo attivo al progetto
• coinvolgere nel progetto la maggior parte possibile delle parti interessate esprimere esigenze, obiettivi,  requisiti, e chiarimenti sui requisiti
• definire le priorità sui requisiti
• controllare l’avanzamento dei lavori, ed i prodotti / servizi che costituiscono il risultato del progetto
• gestire i rischi di progetto
• prendere decisioni in caso di conflitto (ad esempio, di contrasto tra i punti di vista dei vari “stakeholders”), o di incongruenza tra risorse e obiettivi (ad esempio, in caso di ritardo nello sviluppo, il committente deve decidere se è meglio rispettare una data di rilascio prevista rimandando lo sviluppo di alcune funzionalità, oppure se completare tutte le funzionalità rimandando il rilascio).

La logica oltre che l’esperienza dimostrano che più il committente si avvicina ad un’adeguata copertura dei punti precedenti, più migliora la qualità del risultato ottenuto per qualunque progetto.

Nel mondo delle PMI, ed in particolare nei progetti informatici ed organizzativi (infatti “non c’è informatizzazione senza organizzazione”), nella maggior parte dei casi ci si trova ancora in situazioni in cui invece di  “affidare un progetto”,  ci “si affida per un progetto” a un fornitore esterno, lasciandogli  oltre al difficile compito di districarsi tra una serie di requisiti poco ben definiti, anche il compito  di autodirigere  i lavori ed autovalutare i risultati (fonte tutto ciò di interminabili discussioni e contestazioni)

La buona copertura dei punti elencati sopra costituisce  un importante fattore in grado di amplificare le possibilità di successo di un qualsiasi progetto. Il tempo, le esperienze e le competenze necessarie per questo non dovrebbero essere mai  delegate alla società commerciale  fornitrice la quale, seppur partner del committente, non è l’azienda e si pone legittimamente in una posizione di interesse diversa dal  cliente.

Poiché in ogni caso nessuna impresa o rete di imprese potrà mai essere un sistema a “capacità infinita”  (ne di tempo, ne di esperienze e competenze), ecco allora l’importanza e l’opportunità di avvalersi per la durata di un progetto, quando serve e per il tempo che serve, di ingegneri dell’informazione e dell’organizzazione in grado di operare nell’azienda come elementi  dell’azienda ed a suo favore, per favorire  una migliore gestione interna dei progetti  e la necessaria diffusione ed assimilazione stabile nell’azienda dei risultati e del loro mantenimento.

Per evitare che …