I software di Project Management secondo Maurizio Mansueti

Sei domande a colleghi ed amici Project Managers. Primo confronto “a distanza” sul ruolo ed utilizzo dei software nella gestione dei progetti.

Oggi è la volta di Maurizio Mansueti.

Dovendo impiantare un sistema di Project Management per i tuoi progetti, che peso percentuale daresti tra metodo, formazione e strumenti?

Direi 50, 30, 20.

Il metodo è la base per qualunque contesto di project management. Nella mia esperienza, avere un metodo è essenziale in un progetto ed è il primo passo prima ancora della formazione. Avere un metodo significa in qualche modo focalizzare la propria esperienza, metterla in gioco e disporre poi di progetti “guida” utili per formare. La formazione accanto al metodo completano la responsabilità per chi deve condurre un team, o è responsabile di un progetto. Lo strumento è al terzo posto, non perché non sia importante, ma perché per essere un bravo manager non basta avere Microsoft Project per capirci.

Faccio un esempio fuori contesto: non basta avere un computer Apple e Photoshop per essere un grafico.

Come sono invece distribuiti nella realtà della tua esperienza odierna, ad esempio nel progetto che stai seguendo?

Il metodo ripeto non deve essere mai meno del 50%. Consideriamolo una soglia minima invalicabile. La formazione può venir meno se è un progetto iterativo o simile ad un progetto seguito nel passato. In questo periodo, ad esempio, sto seguendo progetti di Location Intelligence in collaborazione con Enti Pubblici ed importanti organismi nazionali. In questo tipo di progetti il know-how necessario unisce competenze di Business Intelligence a conoscenze territoriali e geo-spatial. In questo caso, è la mia formazione tecnica di ICT manager che mi consente di usare metodi che sono già parte del mio background, ma anche di adeguarmi alle nuove necessarie conoscenze che si acquisiscono.

La formazione, in questo esempio, è parte del mio background, ed occupa un 20% direi. Mentre gli strumenti in questo caso salgono al 30%, perché gestendo diversi “livelli di informazione”con figure responsabili di business di livello diverso e di aziende diverse occorre avere la propria “valigetta degli attrezzi”pronta all’uso. Intendo dire che occorre essere pronti a gestire con gli strumenti idonei sia le riunione di alto livello con i responsabili della linea di business, che le riunioni di avanzamento progetto o le comunicazioni tra tecnici ICT.

Quali tools di PM utilizzi maggiormente nei tuoi progetti? A quale livello rispetto alle loro potenzialità?

Per gli Staff Meeting, Powerpoint resta lo strumento privilegiato. In questo contesto utilizzo anche tool che aiutano a rappresentare una idea attraverso “mappe concettuali” fino alla wbs, ma non solo, sono anche utili per definire checklist di qualunque tipo per un certo processo di business o per sviluppare il cosiddetto “project scope”. Ne esistono diversi sul mercato come MindMapping, MindManager. Io uso Inspiration da oltre 10 anni ed è semplice e funzionale.

Per gli avanzamenti di progetto uso Microsoft Project, probabilmente non al 100% delle sue possibilità, ma uso un mio template, con definite le macro attività tipiche di un processo di ICT, e per le risorse umane il listino aggiornato dei costi/tariffe di progetto.

Ovviamente uso anche Excel, come tutti credo, con tutti i limiti che possono derivare dal dover un giorno consuntivare o statisticare dati proveniente da una costellazione di fogli excel. E’ uno strumento decisamente pervasivo! Ma anche in questo caso ho nel tempo definito/raccolto dei template che migliorano la mia efficienza nel fornire una soluzione.

Ad esempio, per pianificare una “opportunità commerciale”, ovvero un progetto pilota, od uno studio di fattibilità con un po’ di realizzazione, è più semplice usare excel. Naturalmente se ci si è costruiti un buon template, necessario per avere subito a disposizione la “pila” dei costi di un progetto tipo, delle proprie “misure” di riferimento, degli indicatori che rapidamente diano una idea dei costi/benefici di una certa opportunità.

Quali errori sono secondo te da evitare nell’utilizzo dei tools di Project Management?

Dipende dal tipo di attività. Dividiamo le attività di un Project Manager almeno in due: Attività di Pianificazione e Controllo e attività di Staff Meeting e Reporting Direzionale.

Per le attività di Pianificazione e Controllo uso Microsoft Project;  e,  nel mio caso di progetti di ICT, se usato con un giusto livello di breakdown delle attività è utile, se troppo dettagliato è inutile.

Se un diagramma di gannt non è “comprensibile” prima di tutto a me ed al mio staff di analisti del progetto, poi alla Direzione Tecnica e infine al Sistema di Qualità, allora è inutile.

Ho capito, dopo anni, che è necessario “semplificare”.

Wbs di attività troppo dettagliate non aiutano capire dove è il problema o a governarlo.

La giusta regola sta nella buona definizione della WBS delle attività. E qui torniamo al metodo, di cui si parlava prima, ed ovviamente, alla esperienza che portano ad adottare la giusta definizione delle attività comprensibile anche agli interlocutori di progetto.

Per il Reporting Direzionale uso PowerPoint, sia  per le riunioni di Staff Meeting  che di proposizione di una idea di business. Anche in questo caso la parole d’ordine è “semplificare”. In questo caso l’attenzione va catturata non attraverso slides iper-descrittive o copie di immagini provenienti ad esempio da excel o project (illeggibili ai più e soporifere per molti degli astanti!). L’effetto sarà negativo sulla persone della riunione.

Con questo non voglio dire che non si debba usare il tempo necessario per predisporre una buona presentazione. Anzi, l’uso di qualche effetto, ma sopratutto di qualche slide “graficamente” ad effetto è sicuramente utile nell’argomentare.  Ma occorre fare uno sforzo di sintesi sia nel definire un concetto in una slide, sia nel numero di slides da presentare.

Il suggerimento quindi è: scrivete il necessario, concentratevi sui concetti, non leggete le slides(!) ai presenti, Il resto lo farà la vostra abilità nel catturare l’attenzione.

Fatto 100 il patrimonio di conoscenza (dati, informazioni ecc.) che il progetto genera o utilizza, in che quota queste sono gestite all’interno del tools che utilizzi?

Dipende da alcuni fattori. E’ nell’essere umano farsi trasportare dalla ripetitività delle proprie azioni e a non cambiare mai nulla nelle proprie abitudini ed è così anche nel contesto lavorativo. Ma quando ci sono stimoli a migliorare, allora anche la buona cura nell’uso dei tool, favorisce la storicizzazione delle conoscenza attraverso i tool stessi.

Ad esempio, ho avuto l’occasione di partecipare a progetti di carattere internazionale con le Nazioni Unite. In questi contesti, le Nazioni Unite governano il processo e lo monitorano con un alto livello di efficienza nel gestire riunioni di staff meeting, avanzamenti di progetto, deliverables.

E questa efficienza è richiesta anche al team di ICT che sviluppa una certa soluzione. In conseguenza quindi di una “alta aspettativa”, questo metodo porta a generare efficienza anche nel tuo modo di lavorare e fornire i necessari deliverables. E qui che i tools ed il loro utilizzo giocano un importante ruolo perché si ottimizza il modo in cui li usi, e soprattutto tendi ad usare i tool in ogni passo del processo, e quindi, alla fine, generi un progetto “standard” che sarà utile come base del processo di pianificazione e controllo in nuovi progetti futuri.

Nel mio contesto lavorativo dove si offrono soluzioni e servizi ICT e non soltanto prodotti, il 100 del patrimonio di conoscenza è la somma della ricchezza gestito nei tools di project management più la ricchezza intesa come know-how prodotto degli esperti del contesto (i senior analyst).

Come autocritica devo ammettere che nel Software Engineering c’è ancora molto “virtuosismo”e meno “fabbrica”; ed il virtuoso del software è come un artista, e non sempre l’estro si conforma all’uso di “regole”o al trasferimento di know-how e quindi produce ricchezza documentata soltanto se stimolato. Ma sta nel gioco assumersi una percentuale di rischio nell’avere in squadra un fuori classe!

Quindi la risposta è che ci si deve porre sempre, fin dall’inizio del progetto, una adeguata percentuale di riuso del patrimonio di conoscenza del progetto (documenti tecnici, di riunione, di presentazione, di avanzamento di progetto, di consegna, librerie software), al di là dell’obiettivo del progetto stesso. La soglia minima di riuso dei deliverables generati dal Project Manager nel mio caso deve essere almeno del  50%. Ovviamente porsi questo obiettivo aiuta a far si che il patrimonio di conoscenza lasci una traccia nel proprio sistema di configuration management e generi quindi ricchezza per altri progetti in un processo virtuoso.

Potresti gestire il progetto che stai seguendo senza il tool specialistico che stai utilizzando? Se si, con che percentuale di sforzo/impegno in più?

Bisogna imporsi di essere “smart” in certi casi; usare gli appunti e scansionarli, fotografare le note, o crearsi dei taccuini ad esempio con Evernote (App per I-phone).

Utilizzare  tecniche di process-chart o use-case per farsi capire da interlocutori non necessariamente tecnici.

In certe fasi del processo, ad esempio in uno Staff Meeting con dei Decision Maker mai lasciare appunti disorganizzati. Anche una minuta di una riunione, anche se scritta a mano, va scansionata, codificata e messa tra i documenti di progetto, e condivisa anche rapidamente con i propri interlocutori seppur scritta a mano.

Esattamente come nel metodo del brainstorming o nella metodologia Agile anche una informazione in un post-it può avere la sua importanza se legato ad una attività e ad un processo e va codificata.

Chi gestisce il progetto capirà che hai organizzazione e metodo, anche senza un tool “specialistico”. Capirà che sei “smart” e che, nonostante i tempi ristretti, hai predisposizione a non lasciare indietro le fasi fondamentali come l’approvazione di una punto di decisione con il Cliente ad esempio.

Lo sforzo quindi è lo stesso. Mi spiego meglio: è la scelta del tool che deve essere commisurata al tempo necessario a disposizione nel progetto, e, come accennavo all’inizio della nostra chiacchierata, avere la propria “valigetta degli attrezzi” aiuta ad usare la “chiave” giusta al momento giusto.

Chi è Maurizio Mansueti

Maurizio Mansueti, è un ICT Manager.

Nel 1987 si laurea in Scienze dell’Informazione all’Università di Torino e da allora il Software Engineering è la sua passione (in tutti i sensi!). Dalla grande impresa alla piccola impresa, ha acquisito competenza nella governance di progetti “complessi” per aziende ed organizzazioni del comparto Pubblico e Privato, rivestendo ruoli di responsabilità quali Responsabile Progetti Software, Responsabile Sistema di Qualità, Responsabile Ricerca e Sviluppo e acquisendo conoscenza nelle seguenti aree di competenza: ICT Management, ICT Project Management, ICT Marketing and Sales Management, IT Business Consultancy, Research and Technology Development, ICT Quality Assurance.

Dal 2000, partecipa anche come azionista nella società Terzo Millennio di Roma, sempre nel comparto ICT, esplorando l’arduo mondo imprenditoriale della piccola e media impresa italiana. Con Terzo Millennio il contesto diviene anche internazionale, con il coordinamento di progetti UE e iniziative ONU.

Come Dottor Jeckill e Mr. Hide, parallelamente conduce professionalmente progetti di “Elettronica creativa”, applicando le tecnologie nei contesti della Musica Contemporanea e Multimedia, come artista, sound designer e giornalista.

Nonostante tutto, dopo 23 anni nel campo ICT, il Software Engineering è ancora la sua passione!

Link:

LinkedIn: http://it.linkedin.com/pub/maurizio-mansueti/23/65a/88b

Terzo Millennio: http://www.tmonweb.it/