Alcuni consigli utili a chi ha deciso di imboccare la strada della gestione “consapevole” dei progetti informatici, per non incorrere negli errori tipici dei fallimenti del passato
Narra la Bibbia che, anticamente, su tutta la terra esisteva una sola lingua. L’invenzione del mattone e del bitume diede agli uomini l’idea di innalzare una torre fino al cielo, che consentisse loro di non disperdersi e di poter vivere nello stesso luogo. Si tratta del più antico esempio letterario di gestione di un progetto, anzi della nascita del concetto stesso di progetto.
Spesso si fa riferimento a eventi storici per raccontare l’origine del project management (come l’organizzazione del lavoro nell’arsenale di Venezia o la costruzione delle piramidi), ma l’archetipo è rappresentato, a mio avviso, dal racconto della torre di Babele, sia perché affonda le sue origini in un passato talmente lontano da diventare mitico, sia perché è emblematico che il progetto venga interrotto per intervento divino, come certamente noto a tutti.
La storia del project management inizia, dunque, con un fallimento, dovuto non come si crede generalmente a un fatto di superbia dell’uomo. Dio, infatti, dà all’umanità una pluralità di lingue affinché non persegua un unico scopo e non rimanga tutta concentrata nello stesso luogo, ma affida allo stesso tempo all’uomo il compito di gestire questa diversità, questa confusione, per portare a compimento i suoi progetti e realizzare i suoi obiettivi. Insomma lo mette alla prova.
Gestire la diversità rappresenta, dunque, la più importante risorsa e il principale problema del project management. In quanto disciplina utilizzata per la gestione di progetti all’interno di un’organizzazione, questo si articola in “teorie”, “tecniche” e “metodologie”.
Metodologie non univoche
Parlando di teorie, il project management può essere inteso come una vera e propria “filosofia”. In estrema sintesi, infatti, la moderna teoria del management si basa sull’assunto che tutti i processi presenti all’interno di un’organizzazione debbano essere pianificati, realizzati, gestiti e monitorati secondo un principio di “azione e reazione” (feedback), che permette di intervenire costantemente per risolvere le criticità che si presentano e rispondere alle nuove esigenze non appena si verificano.
Tale evoluzione è stata resa possibile, ovviamente, dalla disponibilità di strumenti e tecniche sempre più sofisticate. Tra gli strumenti, i tool di reportistica e i software di gestione dei piani. Tra le tecniche, invece, vanno citati gli strumenti concettuali a disposizione del manager, indispensabili per qualsiasi tipo di valutazione, che rivestono un’importanza notevole per il successo di un progetto.
Con metodologia s’intende, infine, la specifica “infrastruttura” che lega insieme le tecniche, in accordo con la visione degli obiettivi del progetto da parte del management. Questo significa che non esiste e non può esistere un’unica metodologia. Solitamente, infatti, quest’ultima riflette l’orientamento e lo stile del management nel selezionare le tecniche e gli strumenti, nonché le risorse, giudicati più adatti al successo del progetto. Un esempio può essere dato dalla definizione dei ruoli: una data metodologia può imporre che lo sponsor interno (incaricato di promuovere e sostenere l’iniziativa) venga maggiormente coinvolto nella definizione delle aspettative e degli obiettivi del progetto, laddove un’altra prescrive un ruolo egualmente attivo anche in fase esecutiva (segnatamente per la risoluzione delle problematiche più importanti). Riassumendo, si può argomentare che esiste sempre un mix di teorie, tecniche e strumenti tale da garantire il mantenimento degli standard e il conseguimento degli obiettivi di qualunque progetto. Di più, è lecito supporre che sia facile portare un progetto al successo. Ma non è così.
Incrementi di produttività
Secondo una recente indagine condotta da Kpmg per conto del Pmi (Project Management Institute) risulta, infatti, che negli ultimi 12 mesi, il 49% degli intervistati ha vissuto almeno il fallimento di un progetto. Nello stesso periodo di tempo, solo il 2% delle organizzazioni ha raggiunto completamente i benefici previsti, mentre l’86% delle organizzazioni ha riscontrato la mancata realizzazione dei benefici attesi fino al 25%. Lo stesso lavoro mette in luce, inoltre, che se da un lato le organizzazioni riescono a trarre vantaggi dagli investimenti in progetti, molte non riescono a determinare esattamente a quanto ammontino tali vantaggi. Come si spiegano questi risultati? Si potrebbe pensare che siano dovuti al fatto che il management non segue correttamente le metodologie, oppure utilizza poco e male le tecniche di project management. Ma le cose stanno davvero così? A partire dalla metà degli anni Novanta, i benefici generati dall’It sui processi produttivi hanno assunto un’importanza del tutto sconosciuta in precedenza, tanto da far parlare di tecnologia che abilita il business. Il crescente utilizzo di strumenti informatici da parte delle imprese aumenta la produttività in due modi: permettendo di ottenere lo stesso output con meno addetti e aumentando la circolazione di informazioni rilevanti all’interno dell’organizzazione, così favorendo l’innovazione. Purtroppo, in molti casi, si è ritenuto che gli incrementi di produttività fossero in un certo senso “automatici”, ovvero legati all’introduzione di nuove tecnologie, con ciò inducendo due tipi di errore. In primo luogo prescindendo, o dando secondaria importanza, alla misurazione dei benefici reali delle singole iniziative. In secondo luogo, lasciando in secondo piano le modifiche di processo che inevitabilmente si accompagnano a qualunque cambiamento organizzativo. Come si vede, si tratta più di un’errata attitudine mentale che di veri e propri errori di project management. A questo proposito, posso citare il caso di un progetto cui ho partecipato anni fa per una grossa azienda, in cui una quota rilevante del tempo veniva speso nella redazione e nell’avanzamento di piani di lavoro, nonché nella stesura della documentazione secondo gli standard e la redazione di verbali di riunione.
I problemi da considerare
Gli incontri di Stato avanzamento lavori (Sal) venivano tenuti con regolarità, le comunicazioni di progetto erano costanti e aggiornate all’interno del team. Inoltre, i ruoli chiave del progetto erano chiaramente definiti e il set di strumenti e metodologia impiegato era sicuramente adeguato. Eppure, il progetto non portò a termine, nei tempi e nel budget stabiliti, il sistema informativo che ne era l’obiettivo. Anzi, a un certo momento fu necessario ridefinire l’architettura e parte dei requisiti. Questa situazione era il risultato di un insieme di fattori, in parte interni all’azienda (resistenze e ripensamenti da parte degli utenti finali e del management, aspetto questo mai da sottovalutare nei progetti It), in parte frutto di errori di valutazione sulla direzione da dare al progetto. Tra questi, il fatto che i piani di lavoro fossero formalmente condivisi tra il management, gli utenti finali e i gruppi di lavoro, ma non sempre rispettati. Le istanze che venivano aperte a spiegazione dei ritardi sul piano erano, a volte, attribuite ad attori esterni al gruppo di lavoro e, quindi, servivano da alibi anche ai ritardi interni. Inoltre, alcune criticità date per chiuse in realtà erano ancora aperte e, pertanto, non davano luogo a un riassorbimento del ritardo generato sul piano. Si dava per risolta la causa immediata dell’istanza, ma non quella più profonda. Ancora, la visione del modo di condurre il progetto non era interamente condivisa tra i team di lavoro (che erano numerosi e includevano sia persone interne che esterne all’organizzazione) e ciò causava endemiche situazioni di stallo, che richiedevano enormi sforzi di negoziazione da parte del management di progetto per essere superate. Infine, nel corso dell’avanzamento del progetto, la tecnologia adottata era diventata obsoleta e si era reso necessario, quindi, un ripensamento complessivo del progetto. Errori, questi, da evitare accuratamente nella gestione di un’inziativa.
