Domande frequenti

Un progetto pieno di attività non è necessariamente un progetto che avanza. Responsabilità poco chiare, obiettivi contrastanti, presupposti mancanti o decisioni rinviate possono bloccare i risultati. Il primo passo è identificare il vero ostacolo.

Verifichi quali risultati siano stati effettivamente raggiunti, quale decisione o presupposto manchi e chi ne sia responsabile. Ci sono conflitti tra committente, funzioni aziendali e IT? Mancano risorse o i requisiti sono incompatibili? Altre riunioni, rapporti più frequenti e ulteriori attività non eliminano automaticamente queste cause. Identifichi la prossima decisione necessaria, la persona responsabile e una scadenza. Conta l’impatto, non soltanto l’attività.

Cinque domande fanno chiarezza: chi decide? Chi prepara la decisione? Chi deve essere coinvolto prima? Chi deve essere informato dopo? Che cosa succede se non si raggiunge un accordo?

L’autorità decisionale, la preparazione tecnica e la comunicazione sono responsabilità diverse. Occorre chiarirle prima delle decisioni importanti e garantire informazioni e poteri adeguati alle persone coinvolte. Chi decide deve comprendere le conseguenze e assumersi la responsabilità prevista dal proprio ruolo. Le decisioni aziendali restano alle persone competenti della sua organizzazione.

Non necessariamente. Un conflitto può dipendere da dati, ipotesi o interpretazioni differenti, ma anche da obiettivi realmente contrastanti. Le vendite possono privilegiare la rapidità, il controllo qualità l’affidabilità e la direzione la sostenibilità economica.

Occorre anzitutto distinguere i fatti verificabili dalle ipotesi non confermate e dalle interpretazioni divergenti. Poi vanno chiariti interessi legittimi, obiettivi, rischi e dipendenze. Se gli obiettivi non sono tutti realizzabili contemporaneamente, maggiori informazioni non bastano: la persona o l’organo competente deve stabilire le priorità e decidere. Si documentino il compromesso, la decisione e le conseguenze.

Una visione obiettivo condivisa dell’IT nasce quando i settori coinvolti chiariscono insieme problemi, esigenze e priorità. Solo dopo si dovrebbero confrontare soluzioni, dispositivi o fornitori.

Analizzi la situazione attuale con amministrazione, funzioni aziendali, IT ed eventualmente scuole. Distingua le osservazioni dai desideri, rilevi le dipendenze e concordi quali problemi affrontare prima. Da questa base elabori una visione obiettivo con ambiti d’intervento prioritari, responsabilità e prossimi passi. Hosang Consulting ha accompagnato questo approccio in un incarico documentato per un'organizzazione pubblica. Una visione condivisa aiuta a decidere, ma non coincide ancora con l’attuazione tecnica.

La gestione informale dei progetti raggiunge i propri limiti quando le responsabilità diventano poco chiare, aumenta il bisogno di coordinamento, le decisioni restano in sospeso e i collaboratori esperti devono intervenire continuamente per far avanzare le iniziative.

Nelle piccole organizzazioni i canali informali e diretti sono spesso un punto di forza. Con l’aumento delle iniziative e delle persone coinvolte, mantenere una visione comune diventa più difficile. I segnali sono domande ricorrenti, priorità contrastanti, lavori duplicati e conoscenze concentrate in poche persone. Non esiste una soglia fissa di dipendenti. È più utile un’impostazione snella e condivisa, con ruoli, decisioni e pochi principi comuni chiari, che una burocrazia superflua.

Saper improvvisare è prezioso. Senza principi condivisi e una documentazione comprensibile, però, le soluzioni riuscite spesso restano nella «tasca» delle singole persone e sono difficili da ripetere o migliorare.

Un metodo non deve essere un manuale voluminoso. Possono bastare pochi principi comuni: come chiariamo un incarico? Chi decide? Come impariamo dai risultati? Così l’esperienza individuale diventa utile anche agli altri, senza soffocare l’iniziativa. Un’organizzazione può sviluppare un proprio approccio. Conta che sia comprensibile, trasmissibile e utile nel lavoro quotidiano.

Verifichi se dati, documentazione e conoscenze necessarie alle decisioni restano utilizzabili anche senza l’attuale fornitore. La dipendenza emerge soprattutto quando un cambio è possibile in teoria, ma nella pratica comporterebbe la perdita di conoscenze, interfacce o capacità operative.

Esegua una prova concreta di uscita: tutti i dati rilevanti sono esportabili in formati utilizzabili? Interfacce, diritti di accesso e regole decisionali sono documentati? Chi può accedere alle informazioni e che cosa succede se i prezzi cambiano o il servizio si interrompe? Consideri contratti, impegno richiesto e rischi di transizione. Sovranità digitale non significa sviluppare tutto internamente, ma conservare alternative e capacità decisionale.

Più di quanto sembri a prima vista: finché una decisione è in sospeso, i costi continuano a correre, i benefici slittano e alcune opzioni possono scadere. Questi costi si possono stimare a grandi linee, e già una stima approssimativa mostra che non decidere è a sua volta una decisione.

Una decisione rinviata sembra gratuita, perché non arriva nessuna fattura. In realtà l'indecisione prolungata vincola risorse, rende sfumate le responsabilità e impedisce di imparare. Il team continua a lavorare, spesso girando intorno alla questione aperta, e produce attività senza progressi. Per una stima approssimativa bastano quattro domande: quanto costa il progetto ogni settimana mentre aspetta questa decisione, ad esempio per personale, prestazioni esterne e infrastruttura? Quale beneficio slitta con ogni settimana, ad esempio risparmi, fatturato o lo sgravio di un reparto? Quali opzioni scadono a una data precisa, per esempio un'offerta, una finestra per il passaggio o uno specialista disponibile? E quale lavoro potrebbe dover essere rifatto se in seguito si decide diversamente? Moltiplicato per la durata realistica del rinvio, il risultato è un ordine di grandezza, non una cifra esatta. Questo calcolo non è un argomento a favore di decisioni affrettate. Più il danno possibile è grande e irreversibile, più serve diligenza. Obbliga però a un confronto onesto: quali informazioni guadagniamo aspettando, e quanto ci costa l'attesa? Se aspettare è la scelta giusta, fissate una data e indicate quali informazioni devono essere disponibili entro quel momento. Una possibile formulazione per il documento decisionale: «Fino alla decisione continuano a maturare circa X franchi di costi alla settimana, e il beneficio atteso slitta ogni volta di una settimana. Dal [data] l'opzione Y non sarà più disponibile. Raccomandiamo di decidere entro il [data], oppure di rinviare consapevolmente alla seguente condizione: …»

Nominando apertamente l'incertezza, commisurando la diligenza alla reversibilità della decisione e stabilendo fin dall'inizio quando e in base a che cosa la decisione verrà riesaminata. Una buona decisione non è automaticamente una decisione con un buon esito, ma una presa con cura, trasparenza e responsabilità sulla base disponibile.

Per prima cosa ordinate la base: che cosa è comprovato, che cosa è ipotizzato, che cosa è contraddittorio, che cosa è sconosciuto? Così si vede se ulteriori chiarimenti cambierebbero davvero la decisione o la ritarderebbero soltanto. Poi scegliete il grado di diligenza in base alla posta in gioco: più il danno possibile è grande e irreversibile, più serve diligenza. Per decisioni correggibili, decidere su una base sufficiente può essere meglio di un'esitazione prolungata. Una domanda di verifica utile è: ci assumeremmo ancora la responsabilità della decisione se si verificasse il caso peggiore che abbiamo accettato? Infine rendete la decisione correggibile: valutate i rischi per probabilità e impatto, definite indicatori precoci e misure, nominate i rischi residui e i responsabili. Annotate domanda e obiettivo, fatti noti e ipotesi aperte, opzioni esaminate, rischi, motivazioni e la data del riesame. In seguito si potrà distinguere se è stata cattiva la decisione o solo il suo esito.

Scegliendo esplicitamente, alla fine di ogni fase, tra più opzioni, non solo tra proseguire e interrompere, e basando la scelta su poche domande di verifica. HERMES 2022 prevede a tal fine decisioni di approvazione del committente; l'approccio di Hosang Consulting aggiunge cinque opzioni e sette domande di verifica.

HERMES 2022 prevede alle pietre miliari decisioni del committente, tra cui l'avvio del progetto, l'avvio dell'esecuzione e le decisioni di avvio della fase. Al momento della decisione di avvio dell'esecuzione il committente può approvare, rinviare l'approvazione e farla richiedere di nuovo più tardi, oppure porre fine al progetto. Un passaggio di fase è quindi un punto decisionale, non una data di calendario. Nell'approccio di Hosang Consulting distinguo a ogni passaggio cinque opzioni: Go, se i presupposti sono sufficienti. Adjust, se obiettivo, perimetro, ruolo, approccio o risorse vengono adattati. Hold, finché presupposti definiti non sono soddisfatti. Stop, se il progetto viene concluso per motivi fondati. Handover, se la responsabilità passa all'organizzazione. Questa suddivisione è un modello di lavoro proprio, non una prescrizione di HERMES. Baso la scelta su sette domande di verifica: che cosa sappiamo ora che prima non sapevamo? Quali ipotesi sono state confermate o smentite? L'obiettivo è ancora sensato e raggiungibile? Benefici, impegno e rischi sono ancora giustificabili? Responsabilità e competenze sono chiare? Quale ruolo del supporto esterno serve ora, oppure, con una direzione interna, quale ruolo di conduzione serve ora? Che cosa deve essere osservabile entro il prossimo punto di verifica? In pratica il documento per il passaggio di fase contiene una raccomandazione per una di queste opzioni, le risposte alle domande di verifica e, in caso di Hold, la condizione alla quale si prosegue. Un «avanti come prima» senza decisione non è un Go, ma una decisione mancata.

Non tutte le cifre in un documento decisionale hanno la stessa attendibilità. Indicate per i dati decisivi se sono noti, sconosciuti, non confermati, superati, contraddittori o non disponibili, riportando fonte e data. L’incertezza dichiarata è un’informazione utile, non una mancanza.

Si possono distinguere sei stati: noto (comprovato e attuale), sconosciuto (non ancora rilevato), non confermato (un'ipotesi da verificare), superato (un tempo corretto, da allora non più verificato), contraddittorio (le fonti dicono cose diverse) e non disponibile (nessuno vi ha attualmente accesso). Se un numero non confermato viene presentato come un fatto, si prende una decisione su una base sbagliata senza che nessuno se ne accorga. In pratica: aggiungete nel documento, per i dati decisivi, una colonna «stato» e una colonna «fonte e data». Per i pochi numeri che reggono davvero la decisione chiedetevi: è comprovato o ipotizzato? A quando risale? La nostra raccomandazione cambierebbe se questo numero fosse sensibilmente sbagliato? Dove la risposta è sì, conviene verificare per prima cosa. Più dati non risolvono automaticamente il problema. Secondo la mia valutazione, le decisioni raramente sono difficili per mancanza di volontà, ma perché la base non è chiara: troppe fonti, troppe opinioni, troppo poca chiarezza sullo stato effettivo delle cose. L'obiettivo non sono più dati, ma un quadro coerente che mostri apertamente che cosa è comprovato, ipotizzato e contraddittorio, e una decisione che poi venga anche sostenuta. Perché qualcuno scriva «questo non lo sappiamo con certezza» in un documento, deve poterlo fare senza svantaggi. Nel 1999 Edmondson ha descritto la sicurezza psicologica come la convinzione condivisa in un team che sia sicuro assumersi rischi interpersonali; nel suo studio sul campo con 51 team di un'azienda industriale, era associata al comportamento di apprendimento. Chi vuole vedere l'incertezza nei documenti non dovrebbe quindi penalizzarla nelle riunioni. Vale non solo per i documenti: chi dice che cosa sa, che cosa suppone e che cosa non sa rende le decisioni più solide.

La preparazione si può delegare, le decisioni legate alla responsabilità di conduzione no. Fa parte del compito di conduzione anche fare in modo che il sapere di conduzione e di controllo, cioè modo di procedere, ruoli, logica decisionale e conoscenze acquisite, sia registrato e non stia solo nelle teste.

Per conduzione si intende ogni persona responsabile di risultati ottenuti insieme, dalla titolare alla capoteam. Si possono delegare per esempio un confronto tra varianti, un rapporto sullo stato, un'analisi dei rischi o una bozza del mandato di progetto. Restano alla conduzione per esempio la priorità tra iniziative concorrenti, l'approvazione o l'interruzione di un'iniziativa e la definizione dei diritti decisionali. Tracciare con chiarezza questo confine alleggerisce e protegge allo stesso tempo: la conduzione non deve raccogliere da sé ogni base, e i collaboratori non portano decisioni per cui non hanno competenza. Come vale questo principio quando il chiarimento del lavoro per progetti va affidato a consulenti esterni o a una nuova funzione è trattato in una domanda separata. Fa parte del compito di conduzione anche ridurre il rischio di un sapere che sta solo nelle teste. L'organizzazione deve registrare soprattutto le proprie informazioni di conduzione e di controllo: modo di procedere, ruoli, logica decisionale e conoscenze acquisite. I risultati di progetto specialistici possono restare nei sistemi previsti a tale scopo. Secondo la pubblicazione non servono per questo un archivio centrale per tutte le informazioni di progetto né una soluzione di gestione della conoscenza per l'intera azienda. Una semplice domanda di controllo dopo ogni decisione importante: dove è registrato che cosa abbiamo deciso e perché?

Documentando consapevolmente, oltre al risultato, anche la motivazione: domanda e obiettivo, fatti noti e ipotesi aperte, opzioni esaminate e scartate, rischi, responsabili, motivi e momento del riesame. Un verbale mostra di solito che cosa è stato deciso, raramente perché.

È proprio questo contesto che si perde per primo con i cambi di personale, ai confini tra reparti e alla fine di una collaborazione esterna. Allora si decide di nuovo senza conoscere la vecchia motivazione, oppure una decisione viene portata avanti in modo sbagliato perché l'ipotesi che la reggeva non è più visibile. Le discussioni ricorrenti ne sono spesso un indizio. Hosang Consulting registra le decisioni importanti in modo tracciabile: domanda e obiettivo, fatti noti e ipotesi aperte, opzioni esaminate, rischi, responsabili, motivi e il momento in cui la decisione verrà riesaminata. Raccomando di annotare inoltre le opzioni scartate, i rischi residui accettati e la separazione tra preparazione e decisione, e di mantenere la nota breve, perché venga davvero scritta e letta. Conservate le note dove sono accessibili indipendentemente dalle singole persone e collegate al progetto interessato, e stabilite chi le cura. Quando una discussione si ripresenta, leggete prima la nota e chiedetevi: che cosa sappiamo ora che allora non sapevamo? Un'informazione nuova giustifica una revisione; non conoscere la vecchia motivazione no.

Spesso non dipende dalla strategia, ma da capacità mancanti dell'organizzazione tra obiettivo e attuazione. Un altro progetto colma raramente una tale lacuna; tende piuttosto a distribuirla su più persone. Prima andrebbe nominata la lacuna concreta.

Si intendono capacità dell'organizzazione come sistema, non la competenza di singole persone, che spesso c'è. Hosang Consulting descrive cinque lacune tipiche: nessuno porta l'attuazione oltre la fine del progetto. Le conoscenze dipendono troppo da singole persone. Le decisioni vengono prese, ma non portate avanti con coerenza. La tecnologia c'è, ma non è inserita nell'organizzazione. E l'attività quotidiana soffoca il cambiamento finché questo scompare silenziosamente dall'agenda. È un'osservazione dalla pratica, non un elenco esaustivo. Se mancano la base di capacità e la responsabilità, ulteriori iniziative generano, secondo la valutazione di Hosang Consulting, più coordinamento, carico, parallelismi e decisioni aperte piuttosto che più impatto. L'attività non è progresso. Domande di verifica: chi porta l'attuazione del nostro obiettivo più importante, con nome e cognome e non solo sulla carta? Dove il successo dipende oggi da una singola persona? Quale decisione è stata presa ma mai attuata davvero? Quale tecnologia abbiamo introdotto senza adeguare il modo di lavorare? Quanta capacità confluisce davvero nel cambiamento più importante? Da qui risulta quale lacuna colmare per prima; solo dopo si pone la questione dell'attuazione o della tecnologia.

I compiti svolti non sono ancora un effetto. Un progetto può fallire per ciò che sta tra i compiti: decisioni che nessuno prende, contraddizioni che nessuno nomina ed effetti che nessuno verifica più dopo l'attuazione.

Svolgere i compiti misura l'output: il workshop si è tenuto, il sistema è stato introdotto, il rapporto è stato consegnato. Se in seguito cambia qualcosa è l'outcome. Molti rapporti si fermano all'output perché è più facile da dimostrare. Così ogni ruolo può segnalare come conclusa la propria parte, mentre l'iniziativa nel suo insieme manca l'obiettivo. Secondo la mia esperienza, le cause si trovano spesso tra le competenze: un requisito contraddittorio che tutti notano ma nessuno nomina; una decisione necessaria che nessuno vuole prendere; un'escalation vista come un rischio per la propria posizione. Allora si continua a lavorare intorno al problema. Il progetto si muove, ma non avanza. Aiutano tre domande: chi risponde del risultato dell'insieme, non solo delle proprie parti? Quale decisione si sta evitando invece di prenderla? Da che cosa capiremo dopo l'attuazione se ha funzionato, e chi lo verificherà?

Trattate la resistenza prima di tutto come un'informazione, non come un avversario. Può indicare preoccupazioni non ascoltate, rischi sottovalutati, obiettivi poco chiari, mancanza di fiducia, perdite reali o una soluzione non ancora sostenibile.

Capite la causa prima di reagire. Chiedete concretamente: «Che cosa cambierebbe esattamente per Lei?», «Che cosa teme se succede?», «Che cosa dovrebbe essere diverso perché possa aderire?» Fate attenzione anche agli spunti che migliorano la vostra soluzione. Distinguete da dove viene la resistenza, perché richiede reazioni diverse. Se ha ragioni comprensibili, adattate la soluzione. Se nasce dalla preoccupazione per il cambiamento, date sicurezza e accompagnamento, per esempio con informazioni chiare, tempi di transizione e interlocutori fissi. Se nasce dalla mancata disponibilità a verificare i fatti e ad assumersi responsabilità, indicate limiti e conseguenze e rivalutate i presupposti del progetto. Un cambiamento duraturo non si può imporre. La pressione può modificare il comportamento a breve termine, ma non sostituire la disponibilità interiore. La leadership può creare chiarezza, indicare conseguenze e sfidare, ma non manipolare le persone o aggirare la loro libertà di scelta. Chi rifiuta un cambiamento ne sopporta le conseguenze; rendetele visibili apertamente e per tempo.

Il mio principio è: quanta più fiducia possibile, tanto controllo quanto il rischio richiede. Il controllo deve governare i rischi, non mascherare la mancanza di fiducia.

Dove manca la fiducia nascono costi di attrito: più cautele, più cicli di approvazione, informazioni trattenute e decisioni più lente. D'altra parte la fiducia non sostituisce né la governance né il controllo necessario. La fiducia senza responsabilità può diventare ingenua; la responsabilità senza fiducia sfocia facilmente nel micromanagement. In pratica potete commisurare il controllo al rischio: quanto è grande e quanto è reversibile il danno possibile? Più è irreversibile, più ravvicinati i punti di verifica, per esempio per la firma di contratti, le migrazioni di dati o le modifiche rilevanti per la sicurezza. Dove gli errori si correggono facilmente bastano spesso obiettivi chiari, limiti definiti e riscontri regolari invece di singole approvazioni. Un segnale d'allarme: se un'approvazione o un rapporto non affronta un rischio concreto ma serve soprattutto a cautelarsi, conviene chiedersi quale problema di fiducia ci sia dietro. Affrontarlo direttamente può essere più efficace di un ulteriore ciclo di controllo.

Può funzionare bene finché siete disponibili. Se però il coordinamento dipende stabilmente da voi, nasce un collo di bottiglia. In vostra assenza le decisioni subiscono ritardi e conoscenze importanti rischiano di rimanere nelle vostre mani, invece di diventare disponibili nell'organizzazione.

Intervenire personalmente può essere giusto in un primo momento. Diventa un problema quando si trasforma in uno stato permanente e nessuna responsabilità passa ad altri. Spesso chi dirige compensa allora a mano ciò che manca come base comune, ad esempio una visione affidabile del lavoro in corso. Una semplice domanda di verifica: le vostre iniziative più importanti procederebbero in modo altrettanto affidabile se foste irraggiungibili per due settimane? Se no, conviene chiarire quali decisioni spettano a chi, quali informazioni servono a tutti e quale sapere finora è solo vostro. Un'organizzazione capace di attuare è quella in cui nessuno deve più tenere insieme tutto.

Secondo la mia esperienza, spesso dal livello di conduzione sopra la direzione di progetto. Se nessuno con tempo e competenza decide per tempo, nemmeno un'ottima direzione di progetto riesce a far avanzare il progetto, perché prepara le decisioni della conduzione, ma non le prende.

HERMES 2022 descrive esplicitamente questa ripartizione dei compiti: il committente conduce il progetto, ne porta la responsabilità complessiva e prende le decisioni alle pietre miliari. Tra le sue responsabilità rientrano decisioni tempestive su richieste e misure. Il capoprogetto dirige il progetto su incarico del committente e ha competenza decisionale nel quadro definito con il committente. La stessa logica vale anche al di fuori di HERMES: un progetto avanza solo alla velocità con cui vengono prese le decisioni di cui ha bisogno. Secondo la mia esperienza, il problema si trova allora spesso un livello più in alto, presso il committente. Schemi tipici che ho osservato, ma non rilevato in modo sistematico: la persona è indicata come committente, ma non ha tempo o non ha competenza decisionale. Si fa informare, ma non decide. Un comitato dovrebbe decidere insieme e alla fine nessuno si sente responsabile. Oppure un fornitore conduce di fatto, perché ha le conoscenze specialistiche. Un test semplice: tenete un elenco delle decisioni aperte con la data in cui sono state richieste. Se alcune decisioni attendono da settimane, il collo di bottiglia non è la direzione di progetto. Chiarite allora, con nome e cognome, chi decide, se questa persona ha il tempo di decidere a ogni pietra miliare e che cosa può decidere da sola la direzione di progetto. Una possibile formulazione della direzione di progetto verso il committente: «Nelle prossime due settimane ho bisogno di tre decisioni da parte Sua. Senza di esse continuiamo a lavorare, ma non avanziamo. Entro quando può decidere, oppure chi deve farlo al Suo posto?»

Riunioni, strumenti o collaboratori aggiuntivi possono essere utili. Tuttavia, se le priorità, gli obiettivi o le competenze decisionali non sono chiari, spesso aumentano soltanto il lavoro di coordinamento. Per questo verifico innanzitutto perché un'iniziativa non avanza. Mancano davvero le risorse oppure sono responsabilità poco chiare e decisioni in sospeso a ostacolare i progressi?

Più riunioni recuperano a voce ciò che manca in termini di ordine comune e interrompono così il lavoro vero e proprio. In un'osservazione sul campo di Gloria Mark e colleghi, la maggior parte degli ambiti di lavoro dei knowledge worker osservati era interrotta (57 per cento). Quando il lavoro interrotto veniva ripreso lo stesso giorno, ciò avveniva in media dopo 25 minuti e 26 secondi, con nel mezzo in media poco più di due altri ambiti di lavoro. In un esperimento della stessa ricercatrice le persone interrotte lavoravano persino più velocemente, ma riferivano più stress, frustrazione, pressione temporale e fatica. Un nuovo strumento rappresenta solo ciò che è già ordinato. Persone aggiuntive possono finire nella stessa situazione disordinata, e con la crescita del team aumenta lo sforzo di coordinamento; chi era già coinvolto può inoltre interpretarlo come un segnale di sfiducia. Chi alla guida si fa carico di tutto diventa il collo di bottiglia, e il proprio sapere non diventa sapere condiviso. Queste valutazioni sono esperienza e tesi, non risultati di ricerca. Non esiste un'unica causa: a volte le iniziative si contendono semplicemente troppo poche persone, le priorità cambiano, le persone saltano da un compito all'altro tra troppe attività. Secondo la tesi della pubblicazione, però, l'ingorgo nasce spesso più in alto, dove andrebbero chiarite le basi. Prima di aggiungere riunioni, licenze o posti, consiglio tre domande: è deciso quale iniziativa ha la precedenza, e chi può deciderlo? Ogni iniziativa ha un obiettivo chiaro e un contributo riconoscibile alla strategia? È visibile a tutti che cosa è in corso e dove si blocca?

I continui cambi di contesto non sono automaticamente un problema attribuibile ai collaboratori. Spesso le cause risiedono nell'organizzazione del lavoro: troppe attività parallele, priorità mutevoli o competenze decisionali poco chiare. Per questo esamino prima come viene pianificato, prioritizzato e gestito il lavoro. È essenziale capire se le persone dispongono di tempo sufficiente e di condizioni chiare per portare a termine le attività con concentrazione.

In un mandato presso un'agenzia digitale in crescita non era una questione di talento. Il modello operativo non era cresciuto con le ambizioni di crescita: le priorità venivano fissate in modo informale, le responsabilità erano poco chiare e mancava un ritmo di lavoro comune tra direzione, vendite, delivery e produzione. Un sistema Kanban ha reso visibili priorità e lavoro in corso, a cui si sono aggiunti cicli di sprint più chiari e user story con criteri di accettazione. Le priorità sono diventate più chiare e i cambi di contesto più rari. È un caso singolo. Corrisponde però a ciò che la pubblicazione «Il project management come capacità organizzativa» descrive come esperienza e tesi per le organizzazioni in crescita: ciò che a lungo ha funzionato a voce a un certo punto non regge più. I cambi di contesto costano più di quanto sembri. Nell'osservazione sul campo di Gloria Mark e colleghi, il lavoro interrotto che veniva ripreso lo stesso giorno proseguiva in media solo dopo 25 minuti e 26 secondi, con nel mezzo poco più di due altri ambiti di lavoro. In un esperimento le persone interrotte compensavano lavorando più velocemente, ma riferivano più stress, frustrazione, pressione temporale e fatica. Che cosa potete verificare e cambiare: rendete visibile in un unico luogo tutto il lavoro in corso. Controllate esplicitamente quante attività sono in lavorazione contemporaneamente; il Kanban Guide richiede proprio questo controllo consapevole del lavoro in corso (work in progress). Stabilite dove si fissano e si cambiano le priorità e chi può farlo. Se lavorate con Scrum: secondo lo Scrum Guide 2020 lo Sprint Goal è l'impegno (commitment) per lo Sprint Backlog; crea focus e lascia flessibilità sul lavoro esatto. Durante lo sprint non si apportano modifiche che metterebbero a rischio lo Sprint Goal; il perimetro può essere chiarito e rinegoziato con il Product Owner. Le nuove priorità vanno quindi di norma nel Product Backlog e con ciò nella prossima Sprint Planning. Naturalmente la causa può anche essere la mancanza di competenze o di capacità. Ma la questione si può giudicare in modo equo solo quando priorità e flusso di lavoro sono chiariti; altrimenti valutate persone in un sistema che produce interruzioni continue.

Hosang Consulting è adatto a organizzazioni che affrontano un compito complesso e non necessitano solo di una raccomandazione, ma di chiarezza, responsabilità e attuazione.

Può trattarsi di un riorientamento strategico, una trasformazione, un progetto a rischio, un cambiamento organizzativo o una combinazione impegnativa di persone, processi e tecnologia.

Decisiva è la disponibilità a esaminare la situazione con apertura, prendere le decisioni necessarie e contribuire all'attuazione. Dove si tratta solo di confermare una soluzione già decisa, potrei non essere il partner giusto.

Soprattutto in due situazioni: prima di una decisione importante e durante un'attuazione impegnativa.

Prima di una decisione: un progetto, un investimento o un cambiamento ha delle conseguenze, ma obiettivi, requisiti, opzioni o rischi non sono ancora sufficientemente chiari, una decisione è bloccata o manca il collegamento tra strategia e quotidianità operativa.

Durante l'attuazione: un progetto non avanza, perde la direzione oppure mancano guida, decisioni e responsabilità chiare. Rientrano qui anche trasformazioni, avvicendamenti di personale, tensioni organizzative e iniziative in cui devono essere riuniti più ambiti e interessi diversi.

Digitalizzazione e IA sono frequenti campi di applicazione in entrambe le situazioni. Il mio lavoro però non inizia con una tecnologia o un metodo, ma con la domanda su cosa debba realmente essere chiarito, deciso o attuato.

Sì. Molti mandati iniziano con domande aperte, aspettative contrastanti o un problema che non può ancora essere descritto con chiarezza.

In una situazione simile creo innanzitutto una comprensione condivisa. Esamino obiettivi, interessi, dipendenze, rischi e capacità esistenti, considerando persone, processi e tecnologia come un sistema unico e correlato.

Solo dopo decido insieme a voi quali siano i prossimi passi sensati. Evito di proporre affrettatamente una soluzione o avviare un progetto di grande portata finché la reale situazione di partenza non è stata compresa.

Il Radical Change è una prospettiva propria di Hosang Consulting, non un modello scientifico standard consolidato. In questa prospettiva il Rapid Change descrive la rapidità con cui un'azienda reagisce ai cambiamenti. Il Radical Change pone la domanda più profonda se le capacità esistenti siano ancora adatte a ciò che l'organizzazione dovrà raggiungere domani.

Una trasformazione classica non basta più quando c'è molta attività ma le decisioni richiedono comunque troppo tempo, la responsabilità è distribuita su più ruoli senza che nessuno la porti davvero, oppure un problema strutturale viene affrontato ripetutamente con un nuovo strumento invece che con una vera chiarificazione.

Sì, a condizione che i coinvolti siano disposti a esaminare apertamente la situazione reale.

Nei progetti a rischio non analizzo solo scadenze, costi e problemi tecnici. Le cause principali si trovano spesso in obiettivi poco chiari, decisioni mancate, interessi contrastanti, responsabilità non definite o un coinvolgimento insufficiente delle persone interessate.

A seconda della situazione, stabilizzo il progetto, creo trasparenza, chiarisco la struttura di guida e decisione oppure assumo la responsabilità operativa del progetto. Non raccomando di proseguire a ogni costo: talvolta un riorientamento, un ridimensionamento o una chiusura ordinata sono la soluzione più responsabile.

Rifiuto un mandato se non posso offrire un contributo realistico, non posso garantire la competenza necessaria oppure obiettivi e aspettative non sono responsabili.

Questo vale anche se si tratta solo di legittimare a posteriori una decisione già presa, se informazioni essenziali vengono deliberatamente trattenute o se manca la disponibilità a considerare rischi e conseguenze evidenti.

Allo stesso modo non accetto incarichi in cui riservatezza, integrità o un trattamento responsabile di persone e informazioni non possano essere garantiti. In questi casi esprimo apertamente la mia valutazione.

Tre passaggi aiutano una prima valutazione: descrivere ciò che oggi funziona e ciò che non funziona, definire una situazione obiettivo concreta e ricavarne le prossime decisioni, i rischi e le azioni. È uno strumento di riflessione, non un test scientificamente validato.

Parta da ciò che funziona: che cosa va conservato, che cosa potrebbe migliorare e che cosa ostacola l’iniziativa? Poi descriva come si presenterebbe concretamente una buona situazione nel lavoro quotidiano. Confronti la situazione iniziale con quella desiderata e stabilisca che cosa chiarire per primo. Un breve premortem amplia la prospettiva: immagini che l’iniziativa sia fallita. Quali cause sarebbero plausibili? Il risultato può anche essere una scelta consapevole di non cambiare nulla o di proseguire internamente. La guida completa è in «Uno sguardo onesto sulla Sua prossima iniziativa».

Quando il compito può essere risolto internamente altrettanto bene: le conoscenze necessarie ci sono, una persona adatta riceve davvero tempo e poteri e le persone coinvolte possono discutere apertamente la situazione. Il sostegno esterno conviene di più quando fanno la differenza uno sguardo indipendente, un'esperienza mancante o una capacità temporanea.

Un caso particolare è la situazione opposta, in cui senza una persona esterna presente da anni non si decide più nulla; allora manca più la capacità interna che la consulenza (vedi la domanda se avete un problema di consulenza o di capacità interne). Prima di coinvolgere qualcuno aiutano quattro domande: sappiamo esattamente che cosa va chiarito o deciso? C'è internamente qualcuno con un'esperienza adatta che riceverà davvero il tempo necessario? Possiamo affrontare internamente risultati scomodi senza creare conflitti di ruolo? E ci serve il sostegno solo per un periodo limitato? Se le prime tre risposte sono sì, molto depone a favore di farlo da soli; se manca solo capacità e per un periodo limitato, può bastare un sostegno esterno mirato. Se coinvolgete un sostegno esterno, stabilite fin dall'inizio da che cosa capirete che può terminare (vedi la domanda su quando un mandato di consulenza può concludersi).

Sì. Offro una valutazione indipendente su quali cambiamenti siano sensati e realistici, anche per progetti già in corso. Un secondo parere ha però valore solo se eventuali interessi per una determinata soluzione o per un incarico successivo sono dichiarati e il risultato può essere anche «sospendere» o «non proseguire».

Un buon secondo parere non esamina prima la tecnologia, ma la motivazione del progetto. Domande utili sono: quale problema deve essere risolto, e le persone interessate lo vedono allo stesso modo? Su quali ipotesi si basa il beneficio atteso, e sono state verificate? Quali alternative sono state confrontate, compreso ciò che è possibile con i sistemi esistenti? Quali costi nascono sull'intera durata di vita, quindi anche per esercizio, supporto e sviluppo? Quali presupposti devono essere soddisfatti, ad esempio capacità, competenze e decisioni? E quanto rende dipendenti da un fornitore la soluzione? Per un progetto in corso si aggiungono tre domande: che cosa sappiamo ora che prima non sapevamo? L'obiettivo è ancora sensato e raggiungibile? Benefici, impegno e rischi sono ancora giustificabili? Un progetto non dovrebbe proseguire solo perché vi si è già investito molto. L'indipendenza si riconosce da alcuni punti semplici: chi esamina dichiara se è legato a produttori, strumenti o partner di attuazione e se si candida per l'attuazione. Valuta le opzioni in modo indipendente dai produttori. E ha confermato in anticipo che anche un no, una sospensione o la prosecuzione interna sono risultati ammissibili. Presso Hosang Consulting si inizia con un colloquio conoscitivo gratuito di 20-30 minuti. Secondo il criterio indicato sopra, anche la nostra posizione va messa sul tavolo: dopo un secondo parere, Hosang Consulting può assumere anche la direzione di progetto o l'organizzazione dell'attuazione e, se necessario, coinvolgere specialisti o partner di attuazione. È bene saperlo prima di valutare il parere. Se serve un chiarimento approfondito, questo è il primo passo a pagamento, fatturato in base all'impegno effettivo con un tetto di costo concordato in anticipo. Ricevete una raccomandazione; non vi obbliga a un incarico successivo.

Una direzione di progetto esterna ha senso quando all'interno mancano capacità, esperienza adeguata o l'indipendenza necessaria. Una soluzione interna basta quando una persona idonea riceve davvero il tempo per il compito, mandato e percorsi decisionali sono chiari e non c'è un motivo deliberato per far guidare il progetto dall'esterno.

Motivi tipici per una direzione di progetto esterna sono: per un nuovo progetto mancano capacità proprie; i capiprogetto interni sono già pienamente impegnati; per un compito specifico manca l'esperienza adatta; un progetto deve essere guidato consapevolmente da una persona esterna; il committente desidera uno sguardo esterno indipendente; oppure un progetto in corso è in difficoltà. Prima di affidare l'incarico all'esterno, conviene verificare onestamente la soluzione interna con quattro domande. La persona prevista riceve davvero tempo, oppure la direzione del progetto si aggiunge semplicemente al suo compito di linea? Ha già guidato un progetto di complessità paragonabile? È chiaro chi è il committente e dove vengono prese quali decisioni? E può sollevare risultati scomodi con superiori e colleghi senza finire in un conflitto di ruoli? Se tutte e quattro le risposte sono sì, molto parla a favore della soluzione interna, anche perché conoscenze e relazioni restano in casa. Tra le due esiste una terza possibilità: non tutti i progetti hanno bisogno di una nuova direzione. Un supporto esterno può affiancare la direzione di progetto esistente, effettuare una valutazione della situazione o collaborare su compiti concreti e impegnativi. Guida e decisioni restano allora interne. Questa forma è adatta quando la persona interna è fondamentalmente idonea, ma per singoli aspetti le mancano esperienza o tempo. Che cosa dovrebbe restare al committente quando si esternalizza la direzione di progetto: gli obiettivi strategici, le decisioni imprenditoriali e il ruolo di committente. Una direzione di progetto esterna è limitata nel tempo e andrebbe pianificata fin dall'inizio con un passaggio di consegne ordinato, affinché logica decisionale, conoscenze e documentazione restino nell'organizzazione. Nella scelta, un certificato attesta un'esperienza verificata in un determinato momento, ma non sostituisce la domanda su progetti paragonabili e sull'adeguatezza alla propria organizzazione.

Non con l'ennesima classifica, ma con una decisione esplicita: quali progetti proseguono, quali vengono sospesi e quali conclusi, in base al loro contributo e alle persone effettivamente disponibili. Per questo serve un organo che abbia il diritto di decidere su tutti i progetti insieme.

Primo: tutto su un'unica lista. Registrate tutti i progetti in corso e pianificati, anche quelli piccoli e non ufficiali, ciascuno con obiettivo, committente, persone chiave coinvolte e prossima decisione in sospeso. Questa lista può mostrare che diversi progetti si contendono le stesse poche persone. In tal caso il collo di bottiglia non è il numero dei progetti, ma il tempo di queste persone. Secondo: valutare in base al contributo, non a chi alza di più la voce. Criteri utili sono: quale contributo dà il progetto allo scopo e all'attività dell'organizzazione? È vincolante per legge, contratto o sicurezza dell'esercizio? Altri progetti dipendono da esso? Quanto costa rinviarlo di sei mesi? Se tutti i progetti hanno la priorità massima, non è stato prioritizzato nulla. Terzo: decidere invece di ordinare. Gestire il portafoglio significa decidere quali progetti vengono avviati, prioritizzati, sospesi o conclusi. Una leva efficace è la sospensione: solo quando un progetto viene messo esplicitamente in pausa, e lo si comunica, le persone diventano davvero disponibili. Un progetto non prosegue solo perché vi si è già investito molto. Quarto: chiarire chi decide. Se manca un organo che decide su tutti i progetti insieme, ogni direzione di progetto negozia separatamente per le stesse persone, e c'è il rischio che prevalga chi fa più pressione. Nella pubblicazione di Hosang Consulting «Il project management come capacità organizzativa» si tratta degli ambiti di chiarimento 3 («Quali iniziative avviamo, e quali no?») e 4 («Chi decide sulle iniziative?»). Nelle piccole organizzazioni questo organo può essere la direzione. Importante è un ritmo fisso in cui verificare le priorità, ad esempio al momento dell'approvazione di nuovi progetti.

Non a partire da una determinata dimensione aziendale. Contano il numero e la complessità delle iniziative, le loro dipendenze reciproche, le risorse disponibili e l'effettivo bisogno di coordinamento. Anche le piccole organizzazioni possono aver bisogno di un quadro vincolante; dovrebbe essere il più semplice possibile e completo quanto necessario.

La ricerca organizzativa spiega il legame: quanto maggiore è l'incertezza di un compito e quanto più le sue parti dipendono l'una dall'altra, tanta più informazione deve essere elaborata e coordinata (Galbraith 1974; Burton e Obel 2018). Di conseguenza il PMI raccomanda di adattare approccio e governo all'iniziativa concreta, ai suoi rischi e al suo contesto, invece di imporre a tutte le iniziative lo stesso quadro. Un modello di calcolo semplificato mostra quanto rapidamente crescono i possibili canali di comunicazione: con n persone sono n·(n-1)/2, quindi 190 con venti persone. Indica un ordine di grandezza, ma non fornisce una soglia empiricamente fondata oltre la quale diventa necessario un ordine comune dei progetti. Un numero maggiore di iniziative simili e in gran parte indipendenti può richiedere meno coordinamento di poche iniziative complesse e fortemente interdipendenti. Per questo consiglio di verificare, invece della dimensione, queste domande: quante iniziative sono in corso contemporaneamente? Quanto dipendono l'una dall'altra, per esempio tramite scadenze, sistemi o risultati comuni? Competono per le stesse persone o risorse? È chiaro chi decide su priorità, approvazioni e interruzioni? Per ogni iniziativa è chiaro chi ne è responsabile e chi ne riprende il risultato? I rapporti sullo stato di iniziative diverse sono confrontabili? Quante più di queste domande restano aperte, tanto più conviene un quadro comune e snello. I segnali quotidiani da cui si capisce che i progetti non si gestiscono più a voce sono descritti in una domanda separata.

È opportuno chiarire la situazione prima che obiettivi e soluzione siano definiti in modo vincolante, quando le alternative principali sono ancora aperte. La ricerca sui grandi progetti di investimento pubblico evidenzia l’importanza di questa fase iniziale. Un risparmio economico nel singolo caso resta un’ipotesi motivata, non una garanzia generale.

La ricerca sui grandi progetti di investimento pubblico in Norvegia va nella stessa direzione: Knut Samset e Gro Holst Volden hanno riscontrato spesso carenze nell'analisi e nel processo decisionale della fase iniziale, prima che venga scelto un concetto di soluzione, e vi vedono un grande potenziale di miglioramento. Da questo lavoro la pubblicazione «Il project management come capacità organizzativa» riprende il paradosso per cui le organizzazioni investono meno mezzi nel trovare l'idea di fondo giusta che nel migliorare le prestazioni durante la realizzazione. Che il chiarimento iniziale venga comunque spesso tralasciato dipende anche da un errore di ragionamento che Daniel Kahneman descrive come visione interna contro visione esterna: chi stima lo sforzo a partire dal proprio piano resta regolarmente troppo basso. La previsione per classi di riferimento corregge la propria stima con l'andamento reale di iniziative comparabili. La pubblicazione usa Kahneman come fonte di pensiero, non come prova. Prima di un'approvazione vincolante consiglio cinque domande: quale problema va risolto, e per chi? Da che cosa riconosceremo il successo? Quali alternative esistono, compreso «non fare nulla»? Quanto sono durate e quanto sono costate davvero iniziative comparabili? Se l'iniziativa fosse fallita tra un anno, quale sarebbe il motivo più probabile? Chiarire presto non significa rendere ogni progetto più pesante. Si tratta di porre le domande giuste finché le correzioni di rotta fondamentali sono ancora relativamente semplici.

Da quando ho compiuto 50 anni, perseguo l'obiettivo di investire una parte considerevole del mio tempo in progetti selezionati non commerciali. Non è una quota matematica né un'offerta gratuita, ma tempo investito consapevolmente dove viene assunta responsabilità e può nascere un impatto reale.

Maggiori informazioni e gli impegni attuali si trovano su /engagement.

No. Dove investo tempo ed esperienza, mi aspetto serietà, puntualità, partecipazione attiva e la disponibilità ad assumersi responsabilità e ad affrontare davvero il cambiamento.

Non ogni richiesta è adatta – e non ogni buona idea ha bisogno di consulenza. Un colloquio permette solitamente di chiarire rapidamente se la mia esperienza può generare impatto nel posto giusto.

Capire significa non ridurre la situazione di partenza ai sintomi visibili. Considero insieme a voi obiettivi, persone, processi, tecnologia, interessi e condizioni quadro.

Responsabilità significa non fermarsi ad analisi e raccomandazioni. Esprimo chiaramente la mia valutazione, accompagno le decisioni e, a seconda del mandato, assumo anche responsabilità di guida, di progetto o di attuazione.

Impatto significa che un cambiamento non viene solo deciso o introdotto tecnicamente. Deve funzionare nella quotidianità lavorativa, essere sostenuto dai coinvolti e portare all'organizzazione un beneficio riconoscibile.

Con Hosang Consulting i clienti lavorano direttamente con le persone che comprendono, guidano e sono responsabili del mandato. Non c'è alcun passaggio a team di consulenza in continuo cambiamento.

Unisco chiarificazione strategica, business analysis, guida di progetti e trasformazioni e attuazione operativa. A seconda della situazione agisco come Challenger, Accelerator, Executor o Observer.

Affronto apertamente rischi e condizioni mancanti. Allo stesso tempo il mio obiettivo non è creare una dipendenza duratura: conoscenza, responsabilità e capacità devono radicarsi nell'organizzazione.

Sì. La collaborazione diretta e personale è una componente essenziale del mio modo di lavorare. I clienti non vengono affidati a un team che cambia dopo il colloquio iniziale.

Per i mandati di Hosang Consulting mi assumo la responsabilità complessiva. A seconda dell'incarico, partner commerciali specializzati lavorano in modo autonomo nei rispettivi ambiti di responsabilità concordati. Per temi di HR e recruiting collaboro con Elizabeth Kunhimon, per il supporto esterno nel project management con un partner esperto. I mandati dell'Istituto di fallimento applicato dei progetti li conduco insieme a Dorian Ferrari.

Quando serve una competenza specialistica aggiuntiva, coinvolgo persone adatte della mia rete. La responsabilità per la selezione, il coordinamento e la qualità resta in capo a Hosang Consulting.

La business analysis crea chiarezza su bisogni, requisiti e spazio delle soluzioni – obiettivi, interessi e dipendenze, prima che una soluzione sia definita.

Il project management crea il quadro organizzativo, pianifica e guida l'attuazione e fa sì che decisioni, rischi e dipendenze vengano affrontati. A seconda del contesto lavoro con HERMES o con approcci classici, agili o ibridi; HERMES stesso supporta diverse forme di attuazione. Nella pratica i due ruoli si intrecciano invece di restare rigidamente separati.

Offro entrambe le cose.

Un mandato può iniziare con un inquadramento della situazione, un chiarimento prima di una decisione importante o uno sparring. Se la situazione lo richiede, assumo poi anche la guida di progetto, la guida della trasformazione o compiti concreti di attuazione, sempre per un periodo limitato.

Il ruolo più adatto viene chiarito all'inizio e verificato regolarmente nel corso del mandato. Il mio obiettivo non è assumere quanta più responsabilità possibile, ma quella responsabilità che è necessaria per il progetto e sostenibile per l'organizzazione.

La governance è il quadro vincolante entro cui un'organizzazione prende decisioni, distribuisce responsabilità ed esercita il controllo. Per i progetti significa soprattutto: chi può approvare, modificare o fermare un'iniziativa, chi ha voce in capitolo, chi viene informato e come si procede all'escalation?

La governance di progetto comprende ruoli, diritti decisionali, approvazioni e percorsi di escalation. Va distinta dalla conduzione di una singola iniziativa (come viene pianificata e controllata?) e dal portafoglio (quali iniziative vengono avviate?). Nel modello degli otto ambiti di chiarimento di Hosang Consulting la governance è il quarto ambito. Senza diritti decisionali chiariti nasce un attrito tipico: tutti aspettano tutti e nessuno osa decidere. La pubblicazione «Il project management come capacità organizzativa» afferma, come esperienza e tesi, che la domanda su chi decida davvero è spesso più importante per il successo o il fallimento di qualsiasi piano, per quanto buono. In pratica consiglio di fissare per iscritto per ogni iniziativa: chi approva il mandato, chi può modificare perimetro, scadenze e budget ed entro quali limiti, chi può fermare l'iniziativa, chi va sentito prima e chi informato dopo, e a chi si ricorre in caso di mancato accordo. Per le piccole iniziative tutto ciò sta su una pagina. Governance non significa più burocrazia. Un quadro chiaro può accelerare le decisioni, perché meno cose devono essere chieste, assicurate e rinegoziate.

Le milestone di management sono punti decisionali in cui la conduzione verifica se sussistono i presupposti per il passo successivo e se l'iniziativa continua a essere sostenuta. Le milestone interne, come la fine di un test o di uno sprint, si trovano invece nello svolgimento del progetto. Chi decide in quale punto lo stabiliscono il mandato e la governance dell'organizzazione.

Nel modello di riferimento di Hosang Consulting il percorso va dall'impulso di progetto, attraverso inizializzazione, concezione, realizzazione e introduzione, fino all'utilizzo. Per i progetti di cambiamento interni l'arco di conduzione arriva fino all'utilizzo, per i progetti per i clienti fino a una consegna affidabile. Lungo il percorso si trovano cinque milestone di management: ammissione al chiarimento, approvazione del mandato, decisione di realizzazione, decisione di introduzione, collaudo ed efficacia. Chi decide è descritto dal modello attraverso cinque livelli di responsabilità: strategia (decisioni di principio e di indirizzo), portafoglio (decisioni su iniziative e priorità nel quadro assegnato), controllo (approvazioni di progetto e adeguamenti sostanziali secondo il mandato), conduzione (decisioni operative di progetto nel quadro delegato) e svolgimento (decisioni specialistiche nell'incarico di lavoro). Un livello non è una persona; può essere esercitato da un comitato direttivo o da una committente. La mappa del progetto assegna, come orientamento: sull'ammissione al chiarimento decide il portafoglio. Approvazione del mandato, decisione di realizzazione e decisione di introduzione spettano al livello di controllo; all'approvazione del mandato il portafoglio conferma priorità e mezzi, alla decisione di introduzione l'organizzazione ricevente conferma di essere pronta. Su collaudo ed efficacia decide il livello di controllo insieme all'organizzazione ricevente o utilizzatrice. Nelle prime quattro milestone gli esiti possibili sono in sostanza approvare, rielaborare, rinviare o concludere, oppure respingere; per collaudo ed efficacia per esempio collaudare, collaudare con riserve, chiedere misure o rivalutare il beneficio. L'ultimo punto è voluto: per le iniziative interne non ci si chiede solo se un risultato è stato introdotto, ma se regge nell'esercizio e produce il beneficio atteso. Per questo sono determinanti gli indicatori della linea.

Una persona. HERMES esige che il committente sia un'unica persona fisica dell'organizzazione di linea, collocata dalla parte degli utenti. Un organo collegiale può essere coinvolto tramite un comitato di progetto, ma non sostituisce il ruolo.

Secondo il manuale di riferimento il committente avvia, finanzia e guida l'intera iniziativa e ha la responsabilità complessiva dell'iniziativa e del raggiungimento degli obiettivi. Deve essere collocato dalla parte degli utenti, rappresentare il progetto nella direzione dell'organizzazione di linea e avere una posizione gerarchica adeguatamente elevata. Committente e capoprogetto non possono essere la stessa persona. Se devono partecipare una direzione, un Municipio o una commissione, HERMES prevede il comitato di progetto: il committente ne nomina i membri, lo dirige e ne stabilisce il diritto di voto. Così resta responsabile una persona, e le organizzazioni rilevanti sono comunque rappresentate. Vi raccomando di designare il committente con nome e cognome, non solo con la funzione. Lo schema in cui un organo deve decidere collegialmente e alla fine nessuno si sente responsabile l'ho osservato nella pratica, ma non l'ho rilevato in modo sistematico. È inoltre importante che la persona scelta abbia tempo e potere di decidere a ogni pietra miliare. Secondo il manuale di riferimento tra le sue competenze rientrano il potere decisionale nei limiti delle competenze stabilite dall'organizzazione di linea e l'escalation verso di essa. Se nella vostra organizzazione è formalmente competente un'autorità o un organo collegiale, per esempio per i crediti, ciò non esclude una persona come committente HERMES. Vi raccomando di fissarne per iscritto le competenze: agisce nei limiti delle decisioni prese dall'organo e gli sottopone le decisioni che vanno oltre.

Non con l'idea stessa. Un impulso di progetto, per esempio un problema, un'opportunità o un'esigenza di un cliente, non è ancora un mandato. Prima si decide se debba essere esaminato come possibile iniziativa. Nel modello di riferimento di Hosang Consulting diventa un progetto solo con un'approvazione consapevole del mandato; molti metodi prevedono un passo di approvazione comparabile.

Un impulso di progetto può essere un'idea, un problema, un'opportunità, un'esigenza di un cliente, un'iniziativa strategica o un cambiamento necessario. Nel modello di riferimento di Hosang Consulting seguono due passi consapevoli: con l'«ammissione al chiarimento» il portafoglio decide se l'impulso viene esaminato ulteriormente. Nell'inizializzazione vengono poi chiariti obiettivi, benefici, incarico, mezzi, rischi, quadro e cerchie decisionali, finché il livello di controllo decide con l'«approvazione del mandato». Per l'ammissione basta una breve scheda di progetto. La mappa del progetto indica come contenuto minimo: breve descrizione, obiettivi e benefici, perimetro e deliverable, varianti, date chiave, risorse, ipotesi e rischi. Il mandato di progetto per l'approvazione contiene almeno situazione iniziale, obiettivi, deliverable, delimitazione, pianificazione, finanziamento, milestone, organizzazione, risorse, rischi, dipendenze e approvazioni. Il passo consapevole conviene perché il chiarimento all'inizio è di regola il più economico (esperienza e tesi). Senza di esso le iniziative partono di passaggio, e nessuno ha deciso che possano impegnare risorse. Anche rinviare o respingere un impulso è un risultato legittimo. Per l'ammissione la mappa del progetto indica esplicitamente gli esiti ammettere, rielaborare, rinviare o respingere.

In un progetto HERMES agile, di norma il rappresentante degli utenti assume anche la responsabilità di Product Owner. La guida HERMES sull'agilità prevede tuttavia anche l'assegnazione dei due ruoli a persone diverse, soprattutto per iniziative più complesse.

Non conta soltanto l'attribuzione organizzativa. Il Product Owner deve comprendere le esigenze funzionali, definire le priorità e assumersi la responsabilità del valore del prodotto. Per farlo ha bisogno di competenze decisionali sufficienti e, per mia esperienza, anche di tempo. La scelta di assegnare entrambi i ruoli alla stessa persona o a persone diverse dovrebbe quindi essere consapevole e basata sull'organizzazione del progetto e sulle esigenze effettive.

In HERMES, il committente è responsabile della governance complessiva del progetto. Prende in particolare le decisioni di sua competenza alle pietre miliari, per esempio sull'approvazione dell'avvio del progetto, dell'esecuzione, del passaggio tra fasi e della chiusura o interruzione del progetto.

Nei progetti agili possono essere necessarie ulteriori decisioni sui rilasci, se previste per il progetto. Le modifiche sostanziali agli obiettivi, al budget o ai tempi devono essere valutate e approvate dal livello decisionale competente. Il capoprogetto prepara tali decisioni e dirige operativamente il progetto nei limiti delle proprie attribuzioni. Le decisioni che il committente può prendere personalmente dipendono dall'organizzazione del progetto e dalle competenze vigenti. Soprattutto negli acquisti e negli impegni finanziari possono essere coinvolti altri organi competenti dell'organizzazione permanente.

L'analisi di business esamina le esigenze di un'organizzazione, chiarisce problemi e obiettivi e pone le basi per soluzioni efficaci. Non si limita alla raccolta dei requisiti, ma cerca anche di comprendere perché sia necessario un cambiamento e quali benefici debba produrre.

Il requirements engineering si concentra sull'individuazione, la descrizione, la verifica e la gestione sistematica dei requisiti. È quindi una componente importante dell'analisi di business, pur potendo essere utilizzato anche in altri contesti. In Scrum, il Product Owner è responsabile di massimizzare il valore del prodotto e di gestire efficacemente il Product Backlog. È responsabile dell'ordinamento degli elementi del Product Backlog. Nella pratica queste attività si completano a vicenda. Un business analyst può supportare il Product Owner nel chiarire le esigenze, analizzare le opzioni di soluzione o dettagliare i requisiti. La responsabilità del Product Owner rimane invariata.

Una collaborazione inizia con un colloquio conoscitivo gratuito di 20-30 minuti sulla situazione attuale, gli obiettivi e le domande aperte.

In questa fase entrambe le parti verificano se il compito, le aspettative e il tipo di collaborazione sono compatibili. Se non esiste ancora un incarico solido, un mandato di chiarificazione limitato può essere il primo passo.

Prima dell'avvio vengono definiti ruolo, responsabilità, coinvolgimento, risultati attesi e condizioni organizzative. Nasce così una base condivisa su cui la collaborazione potrà essere verificata in seguito.

Mi aspetto apertura sulla situazione reale, accesso alle informazioni rilevanti e la disponibilità a coinvolgere le persone necessarie.

Altrettanto importanti sono referenti chiari, persone decisionali raggiungibili e la disponibilità a non rimandare continuamente le decisioni.

La responsabilità è reciproca. Hosang Consulting si assume la responsabilità per il ruolo concordato e per la qualità del proprio lavoro. Il committente resta responsabile delle proprie decisioni, della propria organizzazione e del coinvolgimento interno necessario.

Il coinvolgimento necessario dipende dal mandato e viene concordato concretamente all'inizio.

Tipicamente servono accesso a informazioni e persone rilevanti, tempo per le decisioni, riscontri onesti e la partecipazione attiva di chi è toccato dal cambiamento o dovrà sostenerlo in seguito.

Una trasformazione non può essere delegata interamente a una persona esterna. Io posso strutturare, guidare, sfidare e attuare. L'organizzazione deve però essere pronta ad assumersi la responsabilità e a sostenere il cambiamento nella quotidianità.

Sì. Fa parte della mia responsabilità.

Affronto tempestivamente rischi, obiettivi contrastanti, aspettative irrealistiche, capacità mancanti e responsabilità poco chiare. Lo faccio in modo diretto, oggettivo e rispettoso.

Il mio obiettivo non è offrire una consulenza il più possibile priva di conflitti, ma rendere possibili decisioni solide e un'attuazione efficace. Questo talvolta richiede anche una valutazione che non corrisponde alle aspettative iniziali.

Rendo trasparenti le conseguenze e le discuto con le persone responsabili.

Insieme a voi verifico se le condizioni mancanti possono essere create, gli obiettivi adattati o i ruoli ridefiniti. Ciò può includere ad esempio decisioni aggiuntive, risorse disponibili, il coinvolgimento di altre persone o una riduzione dell'incarico.

Se condizioni essenziali continuano a mancare, non proseguo il mandato senza cambiamenti. Continuare formalmente un progetto senza una base realistica per generare impatto non sarebbe responsabile né per il committente né per me.

Sì. Un'interruzione può rendersi necessaria quando condizioni decisive continuano a mancare, il coinvolgimento concordato non avviene o rischi fondamentali vengono ignorati consapevolmente.

Non compio questo passo in modo affrettato. Rendo prima trasparente la situazione ed esamino insieme a voi possibili adattamenti.

Se comunque non resta una via realistica verso un impatto responsabile, raccomando un riorientamento o un'interruzione. Proseguire un mandato solo per la sua durata o il suo fatturato non corrisponde alla mia idea di responsabilità.

Fatturo in base all'impegno effettivo. La tariffa dipende dal compito, dalla responsabilità e dalle condizioni quadro ed è indicata nell'offerta.

Il primo colloquio conoscitivo di 20-30 minuti è gratuito. Per ogni fase a pagamento concordiamo in anticipo un tetto di costo.

Per progetti sociali e cristiani selezionati posso lavorare anche a titolo gratuito, in particolare da remoto. In determinate situazioni definiamo l'onorario insieme. Decisivo è un accordo equo per entrambe le parti.

Lo sparring è un confronto critico su decisioni concrete con un consulente indipendente. Porto domande, esperienza e raccomandazioni; la decisione resta a lei. È utile se è disposto a mettere in discussione le proprie ipotesi e ad assumersi la responsabilità dei passi successivi.

Lo sparring può aiutare a chiarire opzioni, obiettivi contrastanti e ruoli nella direzione o nei progetti. Sono diretto sui contenuti e rispettoso delle persone. Il confronto non serve soltanto a confermare un’opinione, ma ad aprire nuove prospettive. Offro valutazioni e raccomandazioni, senza prendere le sue decisioni aziendali. Se al centro vi sono problemi medici o psicologici, occorre rivolgersi a un professionista qualificato. Lo sparring non è consulenza psicologica né terapia; modalità e durata vengono concordate individualmente.

Conviene verificare prima due cause: se tutti intendono la stessa cosa con «impegno», e se lavoro e blocchi sono effettivamente visibili. Nello Scrum Guide 2020 l'impegno dei Developers è lo Sprint Goal; quanto lavoro viene completato nello sprint è una previsione che durante lo sprint può essere rinegoziata con il Product Owner.

Chiarire i termini: nello Scrum Guide 2020 ogni artefatto ha un impegno. Per lo Sprint Backlog è lo Sprint Goal, a cui si impegnano i Developers. Lo Sprint Backlog stesso è un piano dei Developers e per i Developers. Durante lo sprint il perimetro può essere precisato e rinegoziato con il Product Owner, purché lo Sprint Goal non sia messo in pericolo; la pianificazione del perimetro viene definita dalla guida come previsione (forecast). Chi tratta ogni attività pianificata come una promessa fissa misura il team con un metro che Scrum non considera un impegno. Poi verificate le cause prima di attribuire colpe: nello sprint è entrato lavoro non pianificato, come guasti o richieste estemporanee? Le priorità sono cambiate durante lo sprint? Alcuni elementi dipendevano da altri team o fornitori? La Definition of Done era chiara a tutti? Gli elementi erano pianificati troppo grandi? E tutti i team registrano il lavoro allo stesso modo, così che i blocchi diventino visibili? In un'organizzazione di sviluppo documentata, con team in più sedi, ogni team registrava il lavoro in modo diverso. Gli impegni di sprint venivano presi e non rispettati, senza che nessuno sapesse dire perché. Lì sono stati introdotti una board Kanban comune a tutti i team, che rendeva visibili lavoro e blocchi, strutture di sprint con «impegni espliciti», come li chiama il caso di studio, e retrospettive che portavano a reali cambiamenti di processo. Il termine «impegno» del caso di studio non coincide con l'impegno nel senso dello Scrum Guide, che si riferisce allo Sprint Goal. Per la prossima retrospettiva: prendete gli ultimi tre sprint e, per ogni elemento non completato, segnate il motivo, ad esempio lavoro non pianificato, dipendenza, cambio di priorità, sottostima o requisito poco chiaro. Lo schema mostra dove deve intervenire una misura e sposta la discussione dalla colpa alle cause.

Facendo sì che una funzione dalla vostra parte sia responsabile dell'insieme, che ogni interfaccia tra i fornitori sia assegnata esplicitamente a responsabili e che un organo decida regolarmente e in modo vincolante. Il coordinamento diventa un collo di bottiglia quando ogni dettaglio deve passare da un'unica persona.

Più fornitori consegnano singole parti, ma nessuno di loro è responsabile dell'insieme. Questa responsabilità resta alla vostra organizzazione in quanto committente. HERMES 2022 prevede che le prestazioni interne ed esterne siano concordate e confrontate periodicamente con la pianificazione e gli accordi; gli scostamenti passano dalla gestione delle modifiche, i problemi rilevanti dalla gestione dei problemi. Se di fatto conduce un fornitore, perché ha la maggior parte delle conoscenze, la responsabilità si sposta senza che nessuno se ne accorga. Elementi utili sono: un elenco delle interfacce in cui ogni interfaccia ha una persona responsabile sia dalla parte del fornitore sia da quella del committente; un piano di integrazione comune con le dipendenze, invece di piani separati; un organo settimanale con il mandato di decidere, non solo di informare; una regola chiara su che cosa i fornitori possono chiarire direttamente tra loro; e un termine di escalation oltre il quale ciò che non è risolto passa al livello successivo. È proprio la regola sul chiarimento diretto a evitare il collo di bottiglia: se i fornitori possono risolvere direttamente le questioni tecniche di dettaglio e al coordinamento arrivano solo le decisioni con effetti su scadenze, costi, qualità o altri fornitori, il coordinamento resta capace di agire. In un mandato documentato per il rinnovo dei dispositivi in una rete di filiali a livello nazionale, regole di coordinamento hanno mantenuto allineati più fornitori senza diventare un collo di bottiglia; organi decisionali settimanali avevano il mandato di decidere anziché discutere. Per una soluzione self-service regolamentata, la responsabilità assunta comprendeva la preparazione della scelta dei fornitori, il coordinamento dello sviluppo individuale di hardware e software e la definizione delle interfacce.

Non necessariamente. HERMES prevede esso stesso di adattarne la portata: prima con la funzione di sizing su HERMES Online, poi, se serve, con il tailoring. Per piccole iniziative al di sotto della soglia di progetto della vostra organizzazione esiste inoltre la variante HERMES One.

Il manuale di riferimento afferma che la portata completa è pensata per progetti grandi e molto complessi e raccomanda alle organizzazioni che gestiscono soprattutto progetti medi e piccoli di adattare il metodo con la funzione di sizing. Il sizing determina la dimensione del progetto partendo da alcuni dati e fornisce uno scenario su misura con piano strutturale ed i modelli necessari. Secondo il manuale riduce complessità e documentazione al minimo assoluto, rispettando la governance HERMES. In seguito potete adattare ulteriormente lo scenario con il tailoring: togliere i moduli che non servono, eliminare compiti e risultati (tranne i documenti minimi richiesti), aggiungere moduli propri oppure compiti e risultati. La Cancelleria federale ha introdotto il sizing perché, secondo quanto ha spiegato, la maggior parte dei progetti è relativamente piccola e molti utenti erano sopraffatti dal tailoring di prima. Per iniziative molto semplici è pensato HERMES One, un modello per piccole iniziative al di sotto della soglia di progetto, che ogni organizzazione stabilisce autonomamente. Secondo HERMES Online, in tal caso la governance secondo HERMES 2022 non è più garantita. Se il vostro progetto deve poter dimostrare a revisione, vigilanza o finanziatori di seguire HERMES, vi raccomando HERMES regolare con sizing invece di HERMES One. Una domanda di verifica che non viene da HERMES, ma è una mia raccomandazione dalla pratica: redigete un documento solo se qualcuno ne ha bisogno per una decisione o una consegna. Anche in un piccolo progetto non tralasciate però tre cose: un committente con nome e cognome, un obiettivo messo per iscritto e un collaudo finale. Questi tre punti valgono anche se non lavorate affatto con HERMES.

Restano obbligatori quattro moduli, tre ruoli e i documenti minimi richiesti dai moduli utilizzati. Si risparmia soprattutto con sizing e tailoring e, nell'attuazione agile, facendo rinviare la specifica dettagliata allo strumento di sviluppo.

Per rispettare la governance di progetto, secondo il manuale di riferimento ogni progetto deve comprendere i moduli conduzione del progetto, gestione del progetto, basi del progetto e organizzazione dell'introduzione. I ruoli minimi da occupare sono committente, capoprogetto e rappresentante degli utenti. Questi ruoli e la loro appartenenza al gruppo di partner «utenti» non possono essere modificati nemmeno negli adattamenti specifici all'organizzazione. I documenti minimi richiesti sono obbligatori. Ne fanno parte, per esempio, il mandato di avvio del progetto, lo studio, il piano di gestione progettuale, il mandato di esecuzione, le liste delle decisioni di progetto e la valutazione finale del progetto. Se un modulo non è pertinente per il progetto, decadono anche i suoi documenti minimi. Nel tailoring i documenti minimi non si possono eliminare; un'organizzazione può però adattarne l'elenco alle proprie regole di governance. Il risparmio maggiore lo ottenete usando prima il sizing e solo dopo il tailoring mirato. Nell'attuazione agile, secondo il manuale di riferimento, la specifica dettagliata può limitarsi a rinviare alla documentazione nello strumento di sviluppo. Gli scenari definiti dall'utente si possono scaricare e scambiare con altri utenti HERMES, così progetti simili non vanno reimpostati ogni volta da capo. Per tutto ciò che va oltre il minimo vi raccomando una semplice domanda di verifica: chi ha bisogno di questo documento, per quale decisione o consegna? Se non c'è nessuno, è un candidato da eliminare. Questa regola viene dalla pratica, non da HERMES.

Non è una scelta alternativa, perché i due disciplinano cose diverse. HERMES è un metodo di gestione dei progetti e stabilisce che cosa nasce nel progetto, quando e chi decide. L'Individual Competence Baseline (ICB4) dell'IPMA descrive le competenze di cui una persona ha bisogno e non prescrive alcun metodo.

HERMES è il metodo di gestione dei progetti dell'Amministrazione federale svizzera, pubblicato dalla Cancelleria federale. Disciplina fasi, pietre miliari, ruoli, compiti e risultati e mette a disposizione modelli. Il manuale di riferimento presuppone che i partecipanti abbiano una formazione in gestione dei progetti o almeno una solida pratica. L'ICB4 dell'International Project Management Association descrive in totale 29 elementi di competenza in tre ambiti: contesto (5), competenze personali e sociali (10) e competenze tecniche (14); per la gestione dei progetti ne sono descritti 28, perché il quattordicesimo elemento tecnico (selezione ed equilibrio) riguarda solo programmi e portafogli. Non si considera né un manuale didattico né un ricettario, non descrive fasi di processo e si affianca a standard più incentrati sui processi. In Svizzera il VZPM certifica le persone secondo il sistema IPMA a quattro livelli. HERMES descrive per ogni ruolo le capacità necessarie, come capacità di comunicazione o propensione a decidere, ma nessun modello di competenze. Leadership, lavoro di squadra, conflitti e crisi o negoziazione sono nell'ICB4 elementi di competenza autonomi. Al contrario, l'ICB4 non prescrive fasi, modelli o approvazioni. Per un'organizzazione ciò significa: un metodo come HERMES crea una struttura e un linguaggio comuni per i progetti; competenze e certificati IPMA mostrano se le persone sanno condurre all'interno di questa struttura. Nella scelta di una direzione di progetto vi raccomando di verificare le due cose separatamente: conoscenze HERMES, se la vostra organizzazione o il vostro committente richiede HERMES, e competenza di conduzione, per esempio tramite un certificato IPMA dal livello C, per il quale il VZPM valuta un rapporto su un proprio progetto e un colloquio. Per lo sviluppo dei capiprogetto l'ICB4 può servire da griglia delle capacità che un metodo presuppone ma non insegna.

Un certificato IPMA attesta la competenza in gestione dei progetti secondo il sistema IPMA a quattro livelli, indipendentemente da un metodo specifico. Dal livello C il VZPM in Svizzera valuta, oltre alle conoscenze, anche l'applicazione, tramite un rapporto su un proprio progetto e un colloquio. Un certificato vale cinque anni; secondo il VZPM la prima certificazione costa tra CHF 900 e CHF 5'900 a seconda del livello.

Il livello D attesta ampie conoscenze delle competenze di gestione dei progetti e non richiede pratica; la verifica avviene con un esame scritto. Dal livello C si aggiungono condizioni di ammissione con esperienza professionale, e il VZPM valuta un rapporto su un proprio progetto reale e un colloquio; ai livelli C e B si aggiunge un esame scritto, al livello A no. Per il livello C la procedura dura di regola, secondo il VZPM, da otto a nove mesi. Un certificato è un'istantanea. Non dice nulla sulle conoscenze del settore o specialistiche, sulla conoscenza di un metodo specifico come HERMES o sull'adeguatezza alla vostra organizzazione; l'ICB4 su cui si basa non prescrive espressamente alcun metodo. Vi raccomando quindi di chiedere la data dell'ultima (ri)certificazione, i progetti svolti dopo la certificazione e referenze da iniziative comparabili. Per la ricertificazione dei livelli da A a C il VZPM richiede di dimostrare, nei cinque anni dall'ultima (ri)certificazione, almeno 30 mesi di pratica nella gestione di progetti, programmi o portafogli e almeno 175 ore di formazione continua. Per il livello D bastano 175 ore di formazione continua, in parte coperte dalla pratica. Il certificato non deve essere scaduto da più di sei mesi, dodici in casi eccezionali motivati. Prima certificazione nelle sessioni pubbliche secondo il listino prezzi VZPM (valido dal 1° marzo 2024, versione 9.0): livello D CHF 900, livello C CHF 3'200, livello B CHF 4'300, livello A CHF 5'900. Chi possiede già un certificato valido di livello inferiore paga meno, per esempio CHF 2'900 per il livello C con il livello D. Per il livello D esistono prezzi ridotti in aziende (CHF 800) e istituti di formazione (CHF 440) a partire da cinque persone per sessione. La ricertificazione costa CHF 250 per il livello D e CHF 600 per i livelli da A a C; in caso di dubbio per A a C può aggiungersi un colloquio per ulteriori CHF 600. I corsi di preparazione non sono inclusi.

Descrivono responsabilità e complessità crescenti: livello D per ampie conoscenze di gestione dei progetti e la collaborazione nei progetti, C per la gestione di progetti di complessità limitata, B per progetti, programmi o portafogli complessi e A per progetti, programmi o portafogli molto complessi a livello strategico.

Livello D, Certified Project Management Associate: attestazione di ampie conoscenze delle competenze di gestione dei progetti; nessuna pratica richiesta; domanda con autovalutazione ed esame scritto. Livello C, Certified Project Manager: gestire progetti di complessità limitata. Ammissione: negli ultimi sei anni almeno tre anni di esperienza come capoprogetto in progetti di complessità limitata; nei progetti complessi contano solo i ruoli di vice capoprogetto o di capo di un sottoprogetto. Procedura: domanda con executive summary report, esame scritto, rapporto e colloquio. Livello B, Certified Senior Project Manager (analogamente per programmi e portafogli): gestire progetti, programmi o portafogli complessi. Ammissione: negli ultimi otto anni almeno cinque anni di esperienza, di cui almeno tre in una funzione di conduzione responsabile in iniziative complesse. Livello A, Certified Project Director (analogamente Programme e Portfolio Director): gestire progetti, programmi o portafogli molto complessi a livello strategico; come Project Director, negli ultimi dodici anni almeno cinque anni in una funzione dirigenziale, di cui almeno tre a livello strategico. Vi raccomando di commisurare il livello adeguato alla complessità della vostra iniziativa, non solo alla sua dimensione. Un livello è un'attestazione riferita a un determinato momento; se una persona oggi guidi iniziative più complesse lo mostra solo un colloquio su progetti concreti.

Un approccio agile è adatto quando la soluzione nasce solo provando e imparando e si possono consegnare presto parti utilizzabili. È meno adatto quando la soluzione è sostanzialmente definita, non è possibile consegnare presto risultati parziali utilizzabili o nessuno con tempo e potere decisionale può assumersi la responsabilità dei requisiti funzionali.

La Scrum Guide descrive Scrum come un framework leggero per problemi complessi. Si basa sull'empirismo: si impara dall'esperienza e si decide sulla base di ciò che si è osservato. HERMES 2022 ammette sia l'attuazione tradizionale sia quella agile e richiede che la scelta sia motivata nel merito durante l'inizializzazione, invece di seguire una moda. Ne derivano alcune domande di verifica: il compito è davvero aperto, oppure la soluzione è in gran parte nota, ad esempio in un acquisto chiaramente specificato o con requisiti fissi? È possibile consegnare presto risultati parziali utilizzabili e farli verificare dagli utenti? C'è una persona che si assume la responsabilità dei requisiti funzionali con competenza, tempo e potere decisionale? Il team può sbagliare e imparare dagli errori? Secondo il manuale di riferimento HERMES, il Controllo federale delle finanze ritiene fatale per il lavoro agile una cultura dell'errore zero. Se mancano queste condizioni, un approccio tradizionale con fasi e approvazioni chiare è spesso più onesto di un'etichetta agile. La scelta non deve valere nemmeno per l'intera iniziativa: in un progetto HERMES agile l'inizializzazione e la chiusura si svolgono in modo tradizionale, solo l'attuazione avviene per iterazioni.

Sì. Nella pubblicazione «Il project management come capacità organizzativa» intendo il project management come la gestione consapevole e ordinata dei progetti da parte di un'intera organizzazione: quali iniziative avviare, chi decide su di esse, come vengono condotte, quali informazioni sono affidabili e come l'organizzazione ne trae insegnamento.

La conduzione di un singolo progetto con piano, team e budget resta importante, ma è solo una parte. Ne fanno parte anche la selezione delle iniziative (portafoglio), il quadro di ruoli e diritti decisionali (governance), un modo comune di condurre le iniziative, informazioni di conduzione affidabili, strumenti adeguati e l'apprendimento da un'iniziativa all'altra. «Capacità organizzativa» significa che i progetti non riescono solo perché singole persone esperte li sostengono, ma perché l'organizzazione dispone di un percorso ordinato e condiviso. Solo allora il modo di procedere diventa ripetibile, confrontabile e capace di apprendere, e la capacità dei singoli diventa capacità dell'organizzazione. Vale per i cambiamenti interni e le introduzioni di sistemi come per le commesse dei clienti svolte in forma di progetto nell'attività principale. Una semplice domanda di verifica: la vostra prossima iniziativa importante procederebbe in modo altrettanto affidabile se la persona più esperta non fosse disponibile? Se no, la capacità di condurre le iniziative in modo affidabile dipende ancora più dalle persone che dall'organizzazione.

Non appena le iniziative sono uniche, trasversali ai settori e limitate nel tempo, di norma sì. La linea porta ciò che è permanente, un progetto concentra il coordinamento per un risultato specifico. Le due logiche hanno bisogno l'una dell'altra, e un'organizzazione di progetto non significa necessariamente nuovi posti.

La linea, detta anche struttura di base, porta responsabilità, processi e conoscenze permanenti. Un progetto è un'iniziativa a termine con un risultato specifico e un proprio compito di coordinamento. Può essere un cambiamento interno, ma anche una commessa di un cliente condotta come progetto perché unica e perché richiede collaborazione tra settori. Linea e progetto quindi non coincidono con «run» e «change». Un'azienda può vendere commesse in modo ricorrente come parte della sua attività principale e condurre comunque ogni singola commessa come progetto. La linea non è spettatrice. I progetti di cambiamento interni devono consegnare i loro risultati alla struttura di base; le commesse svolte in forma di progetto, a loro volta, hanno bisogno di processi, ruoli e conoscenze stabili della linea. Nella mappa del progetto relativa al modello di riferimento di Hosang Consulting, un orientamento senza carattere vincolante, l'organizzazione ricevente conferma quindi prima dell'introduzione di essere pronta, e sul collaudo o sull'efficacia decide il livello di controllo insieme all'organizzazione ricevente o utilizzatrice. Alle organizzazioni più piccole consiglio di non partire con nuovi posti, ma di stabilire esplicitamente per ogni iniziativa: mandato e obiettivo, chi decide, chi conduce l'iniziativa e chi riprende il risultato nella linea.

Uno strumento di gestione dei progetti è più utile quando compiti, responsabilità e informazioni sono chiariti. Anche semplici strumenti digitali possono aiutare già all’inizio; non sostituiscono però le decisioni della direzione.

Ciò che entra in un sistema in modo disordinato resta disordinato anche nel sistema. La pubblicazione «Il project management come capacità organizzativa» descrive il ricorso allo strumento come il primo dei tre errori più frequenti nel mettere ordine nei progetti; si tratta di un'affermazione basata sull'esperienza, non di un conteggio. Nel modello degli otto ambiti di chiarimento di Hosang Consulting la questione degli strumenti è perciò la settima, non la prima. Nel modello di maturità rivisto il supporto digitale è una capacità trasversale e può aiutare già nelle prime fasi. Tuttavia, quanto più uno strumento presuppone processi e indicatori standardizzati, tanto più è importante chiarire prima compiti, ruoli e informazioni pertinenti. Prima di un acquisto consiglio quattro domande di verifica: esiste un modo comune di condurre un'iniziativa, con fasi, ruoli e punti decisionali? È stabilito chi assegna le priorità, approva e ferma le iniziative? Quali informazioni deve fornire lo strumento e a chi, e quanto sono affidabili oggi? In quali sistemi esistenti si trovano già i risultati specialistici? Uno strumento può senz'altro risolvere un problema concreto, per esempio quando un processo già chiarito non è ancora rappresentato digitalmente o quando le informazioni sono sparse in troppi luoghi. Allora l'acquisto non sostituisce il chiarimento, ma lo sostiene.

Hosang Consulting lo riassume in un proprio modello con otto ambiti di chiarimento: scopo, contributo di valore, portafoglio, governance, conduzione del progetto, informazioni affidabili, strumenti e apprendimento. È una suddivisione scelta consapevolmente dalla pratica, non una dottrina generale e non una checklist.

Le otto domande sono: 1. A che scopo, e quali iniziative vi contribuiscono? 2. Come creiamo valore, e che cosa vi apportano i progetti? 3. Quali iniziative avviamo e quali no? 4. Chi decide sulle iniziative? 5. Come conduciamo una singola iniziativa? 6. Su che cosa si può contare in un'iniziativa? 7. Quali strumenti supportano i progetti? 8. Come impariamo da un'iniziativa all'altra? Gli ambiti 1 e 2 riguardano scopo e valore, 3 e 4 portafoglio e governance, da 5 a 8 esecuzione, informazione, strumenti e apprendimento. Gli ambiti si fondano l'uno sull'altro: una questione aperta più in alto può generare attriti più in basso, che alla fine diventano visibili come ingorgo nei progetti. L'ordine si ispira al «perché, come, che cosa» di Simon Sinek, che la pubblicazione usa come fonte di pensiero e non come prova. Il modello presuppone cultura e identità, il «perché»; non le crea. Che gli ambiti siano esattamente otto non è una derivazione, ma una suddivisione scelta: abbastanza fine per essere concreta, abbastanza ampia per restare chiara. Non vanno confuse tre prospettive della stessa pubblicazione: gli ambiti di chiarimento chiedono che cosa debba essere chiarito. I cinque livelli di responsabilità (strategia, portafoglio, controllo, conduzione, svolgimento) chiedono chi porti quale responsabilità. Il livello di maturità chiede fin dove sia arrivata l'organizzazione. Un ambito di chiarimento può riguardare più livelli contemporaneamente. Per iniziare consiglio una semplice domanda per ogni ambito: oggi sappiamo rispondere in modo chiaro e condiviso, e dove ci accorgiamo nel quotidiano che la questione è ancora aperta?

Il modello di maturità proprio di Hosang Consulting, non validato empiricamente, offre un orientamento in cinque livelli: dipendente dalle persone, definito e documentato, standardizzato in tutta l’organizzazione, gestito attivamente e misurato, e migliorato continuamente. Gli strumenti digitali possono aiutare a ogni livello. Il modello indica possibili percorsi di sviluppo, non un voto né una strada obbligatoria.

I cinque livelli di maturità descrivono come le competenze individuali possano diventare sempre più una capacità condivisa dell’organizzazione di gestire i progetti. 1. Dipendente dalle persone: i progetti riescono soprattutto grazie a singole persone esperte, dalle quali dipendono conoscenze e decisioni. Un passo utile è documentare le basi essenziali. 2. Definito e documentato: ruoli, procedure e modelli sono descritti in parte e applicati in singoli progetti, ma non ancora condivisi in modo coerente da tutta l’organizzazione. Il passo successivo è una base comune comprensibile. 3. Standardizzato in tutta l’organizzazione: regole e approcci comuni sono realmente applicati nei progetti pertinenti e adattati ai tipi di progetto. Il passo successivo è governarne in modo affidabile i risultati. 4. Gestito attivamente e misurato: la direzione usa informazioni e indicatori adeguati su tempi decisionali, risorse, risultati dei progetti e, se pertinente, benefici; riconosce gli scostamenti e interviene consapevolmente. Misurare serve a guidare, non è un fine in sé. 5. Migliorato continuamente: l’organizzazione valuta le esperienze e migliora sistematicamente procedure, modelli e decisioni al di là dei singoli progetti. Si impara a ogni livello; qui l’apprendimento diventa sistematico e diffuso. Il supporto digitale non è un quinto livello ma una capacità trasversale: un semplice archivio condiviso può aiutare sin dall’inizio; sistemi più complessi diventano utili quando compiti e informazioni sono chiariti. La digitalizzazione non sostituisce né responsabilità né cultura. Questo modello in cinque livelli è un orientamento redazionale di Hosang Consulting, non una valutazione IPMA Delta o CMMI. Si ispira alla loro logica di sviluppo, dalla prestazione individuale agli standard definiti e applicati, fino alla gestione attiva e al miglioramento continuo. I livelli non rappresentano una sequenza obbligatoria dimostrata empiricamente. Non tutte le organizzazioni devono aspirare al livello massimo. Contano l’importanza dei progetti, i rischi, le esigenze aziendali e il prossimo passo ragionevole. Questa prospettiva sull’intera organizzazione non va confusa con il modello di governo go-to-market di Hosang Consulting, che valuta separatamente ciascuna delle nove fasi di processo su livelli da 0 a 4. Una domanda pratica: che cosa funziona già in modo affidabile, dove responsabilità o informazioni dipendono ancora da persone singole e quale miglioramento porterebbe un beneficio verificabile nel prossimo progetto?

La preparazione sì, le decisioni no. Elaborare le basi, preparare le informazioni e sviluppare proposte si può delegare. Ciò che dipende dalla responsabilità di conduzione, come le priorità tra le iniziative e i diritti decisionali, deve essere deciso dalla conduzione stessa.

La pubblicazione «Il project management come capacità organizzativa» descrive come secondo errore frequente lasciare l'intero chiarimento a un esterno o a una nuova funzione. Come schema ricorrente nelle iniziative fallite indica, esplicitamente come valore di esperienza e non come risultato di ricerca: all'inizio non si affrontano conduzione, parti coinvolte e rischi, la direzione prende troppo poca iniziativa e troppo peso grava sui collaboratori. La ragione è semplice: chi stabilisce i diritti decisionali li ridistribuisce, e chi fissa le priorità dice anche che cosa non si farà. Una persona esterna o una nuova funzione può prepararlo, ma non deciderlo con la legittimazione necessaria. Consiglio di fissare esplicitamente fin dall'inizio la ripartizione del lavoro: che cosa elabora la persona esterna o la nuova funzione, entro quando, e chi decide in merito e quando. Una possibile formulazione per l'incarico: «Vi chiediamo di prepararci due o tre varianti con le relative conseguenze. Decideremo in direzione alla data concordata.» Un segnale che il chiarimento è stato ceduto invece che delegato: i risultati ci sono, ma nessuno nella conduzione si sente vincolato ad essi.

Un premortem è un breve strumento di riflessione prima di un'importante decisione di progetto: i partecipanti immaginano che l'iniziativa sia fallita tra un anno e ciascuno scrive per conto proprio come si è arrivati a questo. Così dubbi e rischi diventano visibili prima che si decida.

Il metodo è dello psicologo Gary Klein ed è stato descritto nel 2007 nella Harvard Business Review; Daniel Kahneman lo raccomanda. La pubblicazione «Il project management come capacità organizzativa» lo considera una fonte di pensiero, non una prova. Uno svolgimento possibile, per esempio in 30-45 minuti: presentare brevemente il piano. Poi proporre lo scenario: «Immaginate che sia passato un anno e che l'iniziativa sia fallita. Come si è arrivati a questo?» Tutti scrivono per qualche minuto in silenzio e individualmente. In seguito ciascuno legge a turno un punto, senza discussione, finché tutto è raccolto. Infine i punti più importanti vengono raggruppati e inseriti nel piano con una misura e una persona responsabile. Il vero guadagno non sta nelle risposte, ma nel fatto che i dubbi sono permessi e persino richiesti. Chi altrimenti tacerebbe per non frenare lo slancio ottiene un luogo legittimo per esprimersi. Scrivere in silenzio e individualmente evita che tutti si allineino alla prima opinione o a quella più forte. Limiti: un premortem non è una previsione. Può anche far emergere rischi che nella realtà quasi non esistono, e funziona solo se esprimere dubbi non ha conseguenze negative per la persona.

I due modelli possono essere letti come prospettive distinte ma compatibili. Il modello di riferimento descrive un quadro organizzativo per la conduzione delle iniziative. Il modello in nove fasi descrive l’accompagnamento di un’iniziativa concreta fino all’impatto e alla consegna. Questa è una lettura redazionale; le fonti non indicano una corrispondenza esplicita uno a uno.

Il modello di riferimento non è un ulteriore metodo di progetto. Traccia un arco dall'impulso di progetto all'utilizzo, o alla consegna per i progetti per clienti, con milestone di gestione in cui decide la direzione, mentre lo svolgimento vero e proprio del progetto può seguire HERMES, PRINCE2, SAFe o un approccio proprio. Il modello in nove fasi va dall'idea di progetto all'effetto e al ritiro. Tra una fase e l'altra si decide consapevolmente: proseguire, adeguare, sospendere, terminare o consegnare. Definisce anche quale ruolo ha di volta in volta la consulenza e quando si ritira. Non è documentata una corrispondenza uno a uno tra le fasi. Come lettura redazionale, un mandato secondo il modello in nove fasi può svolgersi all'interno di un'iniziativa che l'organizzazione conduce secondo il proprio modello di riferimento.

Sì. HERMES è adatto non solo all'Amministrazione federale svizzera, ma anche a Comuni, PMI e altre organizzazioni. L'importante è adattare il metodo alle dimensioni, alla complessità e ai rischi dell'iniziativa.

HERMES e PRINCE2 sono metodi di gestione dei progetti con accenti diversi. HERMES offre in particolare un quadro chiaro per la governance del progetto, le responsabilità, i risultati e le decisioni. Anche PRINCE2 adotta un approccio strutturato alla direzione e al controllo dei progetti. PMI, invece, non è un metodo, bensì un'associazione professionale che offre standard e certificazioni di project management. Questi approcci non si escludono a vicenda. Non consiglio quindi un metodo soltanto in base al suo nome: verifico quale quadro si adatti all'organizzazione, ai suoi processi decisionali e alle sue sfide specifiche.

Sì. HERMES e Scrum possono essere combinati. HERMES fornisce il quadro per la direzione e la governance del progetto, mentre Scrum organizza lo sviluppo agile della soluzione.

HERMES definisce in particolare responsabilità, risultati, pietre miliari e decisioni necessarie. All'interno di questo quadro, uno Scrum Team può sviluppare la soluzione in modo incrementale. È essenziale definire chiaramente le interfacce tra la governance del progetto e l'attuazione agile. Occorre soprattutto stabilire chi prende quali decisioni, come vengono concordati i risultati e come i responsabili del progetto vengono informati sull'avanzamento.

Il committente HERMES è responsabile della governance complessiva del progetto. Garantisce le risorse necessarie e prende le decisioni di sua competenza relative all'esecuzione, alle modifiche sostanziali e alla continuazione del progetto.

Lo Scrum Team, invece, gestisce autonomamente il proprio lavoro entro gli obiettivi e i vincoli concordati. In particolare, i Developers decidono come svolgere il lavoro necessario per raggiungere lo Sprint Goal. Autogestione non significa che il team agisca indipendentemente dalla governance del progetto. Obiettivi, budget, responsabilità e decisioni necessarie devono restare coordinati. La distinzione deve quindi essere chiara: il committente governa il progetto, mentre lo Scrum Team organizza concretamente l'attuazione entro il quadro concordato.

Gli artefatti Scrum, come Product Backlog, Sprint Backlog e Increment, non sostituiscono automaticamente i risultati di progetto previsti da HERMES. Possono tuttavia contribuire a elaborarli progressivamente e a rendere trasparente l'avanzamento.

I risultati HERMES effettivamente necessari dipendono dallo scenario scelto e dall'adattamento del metodo al progetto. Le decisioni formali restano necessarie soprattutto in corrispondenza delle pietre miliari HERMES previste. Anche modifiche sostanziali agli obiettivi, al budget o alle tempistiche possono richiedere una decisione dell'organo di governance competente. Le modifiche all'interno del quadro già approvato possono invece essere gestite dai ruoli responsabili. È importante definire chiaramente le competenze decisionali senza ostacolare il lavoro agile con approvazioni inutili.

Per i nuovi progetti consiglio generalmente l'edizione attuale HERMES 2022. Nei progetti già avviati il passaggio non è automaticamente necessario. Contano le disposizioni vincolanti della vostra organizzazione, nonché i benefici e gli oneri di un cambiamento di metodo.

I modelli e le direttive basati su HERMES 5.1 dovrebbero comunque essere esaminati. HERMES 2022 ha sviluppato ulteriormente la struttura del metodo, i ruoli, i risultati e l'integrazione con gli approcci agili. Non basta quindi modificare soltanto il numero di versione nei documenti esistenti. Un confronto mirato tra le disposizioni di progetto e il metodo attuale permette di capire quali documenti aggiornare e quali regole restano adeguate.

HERMES 2022 ha sviluppato ulteriormente il metodo, in particolare il rapporto tra governance del progetto e sviluppo della soluzione.

Il cambiamento principale è una separazione più chiara tra gestione del progetto e gestione dello sviluppo. La soluzione può così essere sviluppata con un approccio tradizionale o agile, ad esempio Scrum, mentre HERMES continua a definire l'organizzazione del progetto, le responsabilità, i risultati e le decisioni necessarie. Sono stati inoltre rielaborati scenari e moduli, rafforzato il ruolo del rappresentante degli utenti e sviluppato ulteriormente l'adattamento del metodo a progetti di dimensioni diverse. Le organizzazioni possono così utilizzare HERMES con maggiore flessibilità. Le disposizioni di progetto, le descrizioni dei ruoli e i modelli esistenti dovrebbero quindi essere esaminati e, se necessario, aggiornati.

No. Un metodo di gestione dei progetti crea una struttura e definisce ruoli, responsabilità, processi e punti decisionali. Non garantisce però il successo del progetto.

Conta il modo in cui il metodo viene applicato nella pratica. I responsabili devono prendere decisioni, affrontare i conflitti, stabilire le priorità e assicurare le risorse necessarie. Anche il Controllo federale delle finanze osserva nel manuale di riferimento HERMES che l'applicazione coerente di un metodo, da sola, non garantisce il successo del progetto. Per questo considero il project management non soltanto una questione di metodo, ma anche di leadership, responsabilità e capacità decisionale dell'organizzazione.

HERMES definisce un quadro strutturato per la gestione dei progetti. Ne fanno parte fasi, pietre miliari, processi decisionali, ruoli, attività, risultati, scenari, moduli e modelli.

HERMES descrive anche la collaborazione tra organizzazione del progetto e organizzazione permanente. Non ne definisce però in modo esaustivo la struttura interna, tutte le competenze decisionali o i processi di leadership. HERMES non prescrive neppure in via generale il metodo di lavoro concreto per sviluppare una soluzione. All'interno del quadro di progetto possono essere utilizzati approcci tradizionali o agili come Scrum. Il punto essenziale è che HERMES offre chiarezza metodologica, ma non sostituisce una leadership efficace, le competenze specialistiche, l'assunzione di responsabilità o le decisioni necessarie.

Hosang Consulting è il centro responsabile di ogni mandato.

I clienti lavorano direttamente con le persone responsabili di Hosang Consulting. Quando servono competenze aggiuntive, compongo un team adatto di specialisti interni ed esterni.

In questo modo unisco la responsabilità personale alla possibilità di coprire ambiti specialistici diversi. Non nasce un apparato di consulenza inutilmente grande, ma nemmeno una limitazione artificiale alle capacità di una singola persona.

Gli specialisti aggiuntivi vengono selezionati in base al compito concreto, alla loro competenza professionale, alla loro esperienza e alla loro idoneità personale.

Non conta solo se qualcuno padroneggia un ambito specialistico: la persona deve anche essere adatta alla situazione, all'organizzazione e al modo di lavorare concordato.

Hosang Consulting chiarisce ruoli e interfacce, coordina la collaborazione e resta responsabile della guida complessiva del mandato. Il committente deve sapere in ogni momento chi svolge quale compito e chi risponde del risultato complessivo.

La decision architecture significa trasformare una situazione complessa in una base decisionale comprensibile: riunire le informazioni, rendere visibili le contraddizioni e separare ciò che conta da ciò che è secondario.

Il mio partner commerciale Ralph Mattli svolge questo ruolo come fondatore di QUENARIS. QUENARIS collega conoscenza, decisioni, ruoli, contesto ed esperienze tra persone, collaboratori digitali e partner esterni in un quadro condiviso con cui i team possono lavorare. Supporta il lavoro decisionale e di attuazione, ma non sostituisce né i sistemi esistenti né la responsabilità umana. La decisione stessa resta sempre alle persone coinvolte.

Nel mio lavoro utilizzo QUENARIS come sistema digitale di lavoro e di organizzazione. Trasparenza: lavoro io stesso anche presso Mattli Digital, che realizza tecnicamente QUENARIS, e posso influire direttamente sulle funzionalità di QUENARIS. Hosang Consulting resta aperta a qualsiasi tecnologia: QUENARIS è una soluzione possibile, ma non un risultato obbligato di un mandato. Dove QUENARIS fa parte di una soluzione per il cliente, ciò viene concordato esplicitamente.

Per memoria organizzativa si intende ciò che un'organizzazione sa di sé stessa, delle proprie decisioni e delle relative motivazioni – indipendentemente da quali persone siano presenti in un dato momento.

Non si forma da sola. La conoscenza lascia un'organizzazione a ogni cambio di personale, a ogni confine tra reparti e alla fine di ogni collaborazione esterna, se nessuno la trattiene consapevolmente. Una memoria organizzativa rende l'esperienza collegabile – per la prossima decisione, non solo per l'archivio.

Coaching e sparring per dirigenti li offro io stesso, come Sparring & empowerment.

L'executive search non è un servizio di Hosang Consulting. A chi vuole coprire una posizione dirigenziale metto volentieri in contatto con il mio partner commerciale Heinz Brägger, Partner e Practice Lead Change & Transformation presso Leverage Experts. Offre l'executive search in modo autonomo.

Chiarimento prima di una decisione importante: analisi chiaramente delimitate e workshop che creano una base decisionale solida.

Guida di un progetto per un periodo limitato: direzione di progetto esterna e ruoli operativi di guida per un periodo limitato nei progetti.

Supporto esterno e prospettiva indipendente: affiancamento a tempo determinato della direzione di progetto, una valutazione della situazione o collaborazione su compiti concreti, quando non serve una nuova direzione di progetto. Guida e decisioni restano a voi.

Trasformazione e attuazione: mandati di trasformazione e ruoli operativi di attuazione, se necessario con specialisti coinvolti in modo mirato.

Sparring e revisione indipendente: accompagnamento puntuale o regolare di dirigenti e responsabili di progetto.

I mandati possono essere puntuali, coprire una fase di progetto definita o svolgersi su un periodo più lungo. È possibile anche una combinazione, ad esempio una fase intensiva di chiarificazione e avvio seguita da un accompagnamento ridotto.

Il modello dipende dal compito e dall'effettivo bisogno di responsabilità. Portata e durata non vengono scelte più ampie di quanto necessario per un'attuazione efficace.

All'inizio chiarisco quale cambiamento concreto debba essere raggiunto con il mandato e da cosa sarà riconoscibile.

A seconda del compito, l'impatto può consistere ad esempio in decisioni più chiare, processi più stabili, responsabilità definite, un'introduzione riuscita, una collaborazione migliorata o un'organizzazione capace di agire in autonomia.

I criteri non vengono considerati solo alla fine. Durante il mandato verifico regolarmente se le misure scelte contribuiscono davvero all'impatto concordato. Se non è così, adatto l'approccio o rimetto in discussione le ipotesi di base.

Coinvolgo tempestivamente i team esistenti e le persone responsabili. Conoscenza, basi decisionali, ruoli e modalità di lavoro vengono documentati in modo tracciabile e costruiti insieme.

Dove assumo temporaneamente un ruolo operativo o di guida, pianifico anche il passaggio di questa responsabilità. L'obiettivo è un'organizzazione capace di proseguire in autonomia dopo il mandato e di valutare da sé nuove situazioni.

Un supporto esterno può restare sensato, ma dovrebbe essere una scelta consapevole e non la conseguenza del fatto che conoscenza o responsabilità vengano trattenute deliberatamente dalla consulenza.

Se nessuno lo è esplicitamente, spesso nessuno. Stabilite già al momento della decisione chi verificherà dopo la fine del progetto se la misura ha cambiato qualcosa, quando e in base a che cosa; senza questo collegamento dall'impatto alla decisione, un'organizzazione impara poco dai propri risultati.

Una decisione è l'inizio di una catena: decisione, misura, attuazione, impatto, conoscenza, apprendimento. Secondo l'esperienza pubblicata da Hosang Consulting, i primi tre anelli di solito funzionano bene. Gli ultimi tre si assottigliano, perché il progetto è ufficialmente concluso e il team è già nel progetto successivo; la domanda sull'impatto non trova più posto in agenda. La conseguenza: senza questo collegamento un'organizzazione ripete schemi invece di correggerli, perché nessuno sa più quale decisione precedente abbia portato a quale risultato. Hosang Consulting descrive come lacuna di capacità tipica il fatto che un progetto abbia uno sponsor e una direzione di progetto, ma nessuno che resti responsabile del risultato nella quotidianità dopo la fine del progetto. In pratica raccomando: nominate una persona responsabile dell'impatto nella linea, non nel progetto che si chiude. Alla chiusura del progetto documentate quale impatto ci si attende, da che cosa sarà riconoscibile e quando verrà verificato. Collegate il risultato alla nota decisionale originale e portate le conoscenze nelle decisioni successive. Una decisione non è conclusa quando la misura è terminata, ma quando il suo impatto è noto.

«Attuato» dimostra un output, non l'impatto. L'impatto si misura con indicatori precoci e tardivi adatti al progetto concreto: quelli precoci mostrano se si va nella direzione voluta, quelli tardivi se l'impatto si è verificato.

Un workshop concluso o un sistema introdotto è un output. Se in seguito collaborazione, comportamento decisionale o utilizzo siano cambiati è l'outcome. Molti rapporti si fermano all'output perché è più facile da dimostrare; una risposta onesta alla domanda se abbia funzionato richiede tempo, distanza e talvolta il coraggio di accettare una risposta scomoda. Esempi usati da Hosang Consulting: riconoscibili presto sono per esempio la qualità e l'apertura dei colloqui, una comprensione più condivisa della situazione di partenza, obiettivi, ruoli e responsabilità più chiari, ipotesi e rischi visibili e decisioni più rapide e tracciabili. Riconoscibili più tardi sono l'utilizzo effettivo di nuovi sistemi e modi di lavorare, la stabilità nella quotidianità, l'accettazione, risultati organizzativi misurabilmente migliori, una minore dipendenza da singole persone o da consulenza esterna e la capacità di svilupparsi autonomamente. Concordate all'inizio obiettivo, risultato atteso e criteri di misurazione, con obiettivi formulati, dove utile, secondo il principio SMART. Misurate ciò che è rilevante per l'impatto concordato, non solo ciò che è facile da misurare. Se all'inizio mancano dati affidabili, non è un lasciapassare: indicatelo come parte della situazione di partenza e migliorate la misurabilità passo dopo passo. La misurazione serve alla decisione e all'apprendimento, non a sé stessa.

Studi scientifici mostrano associazioni statistiche positive tra pratiche efficaci di project management e successo dei progetti. Alcuni rilevano anche associazioni con le prestazioni economiche delle organizzazioni. Ciò non dimostra un rendimento generale o causalmente certo di ogni investimento aggiuntivo nel project management. Conta quali problemi concreti vengono risolti e quali miglioramenti si ottengono davvero.

Esistono risultati positivi. Mir e Pinnington (2014) hanno analizzato 154 risposte di professionisti di progetto e trovato un’associazione statisticamente significativa tra efficacia del project management e successo dei progetti. Il loro modello spiegava circa il 44,9 per cento della variabilità del successo misurato. Joslin e Müller (2015) hanno analizzato 254 risposte internazionali: l’applicazione di una metodologia di project management spiegava il 22,3 per cento della variabilità statistica del successo dei progetti. Entrambe le percentuali indicano varianza spiegata, non aumenti di fatturato, rendimenti finanziari o causalità dimostrata. Per le prestazioni economiche dell’intera organizzazione i dati sono più difficili da interpretare. Yazici (2009) ha rilevato tra 86 professionisti un’associazione tra maturità percepita del project management e prestazioni aziendali percepite, ma non tra maturità e prestazioni dei progetti; la cultura organizzativa aveva un ruolo autonomo. I risultati dipendono dalle misure, dal contesto e dalle organizzazioni studiate. Non dimostrano un rendimento universale dell’investimento. Consiglio quindi di partire dal problema concreto e dalla situazione iniziale: decisioni in ritardo, informazioni sullo stato non affidabili, risorse assegnate più volte, passaggi di consegne insufficienti o obiettivi poco chiari? Prima del cambiamento concordate indicatori adeguati, per esempio decisioni prese entro le scadenze, tempi di attraversamento, rapporti confrontabili, rilavorazioni o benefici verificabili nell’attività ordinaria. In seguito verificate che cosa è migliorato, quanto è costato il cambiamento e quali altri fattori possono aver contribuito. Anche un quadro snello, oppure rinunciare consapevolmente a ulteriore burocrazia, può essere la scelta giusta.

Spesso perché le conoscenze vengono sì registrate, ma non rese di nuovo disponibili e utilizzate nell'iniziativa successiva; lo indicano la ricerca e l'esperienza pratica, ma manca una prova rigorosa. L'apprendimento diventa efficace solo quando confluisce nel modo in cui la prossima iniziativa viene preparata e condotta.

La ricerca indica un divario tra procedura e pratica: nelle indagini tra capi progetto una larga parte dichiara di avere una procedura formale per le lessons learned, ma solo una piccola parte la rispetta davvero. La pubblicazione «Il project management come capacità organizzativa» conosce questo risultato di seconda mano e lo presenta esplicitamente come indizio, non come prova. Come esperienza e tesi, la pubblicazione descrive che cosa succede tipicamente dopo: le conoscenze finiscono in archivi che diventano silenziosi. Ciò che sopravvive sono moduli e modelli, non le conoscenze vere e proprie. Il sapere prezioso che nasce quando un'iniziativa passa all'esercizio dipende dalle persone e se ne va con loro. Consiglio di ancorare l'apprendimento all'inizio invece che alla fine: all'inizializzazione di una nuova iniziativa esaminare esplicitamente da tre a cinque conoscenze tratte da iniziative comparabili. Registrare le conoscenze in modo breve, concreto e con una persona responsabile. E, dove possibile, non limitarsi a scrivere un rapporto, ma adeguare direttamente modello, checklist o processo, così che la conoscenza agisca da sola la volta successiva. Nel modello degli otto ambiti di chiarimento di Hosang Consulting, l'apprendimento da un'iniziativa all'altra è l'ottavo ambito; secondo la pubblicazione, senza di esso ogni miglioramento resta un caso isolato.

Le informazioni riservate vengono utilizzate esclusivamente per lo scopo concordato del mandato e rese accessibili solo alle persone che ne hanno bisogno per il proprio compito.

All'inizio chiarisco, se necessario, requisiti aggiuntivi su protezione dei dati, sicurezza delle informazioni, sistemi e documentazione. Quando coinvolgo altri specialisti valgono gli stessi requisiti di riservatezza concordati.

Strumenti tecnici e applicazioni di IA non vengono alimentati in modo incontrollato con informazioni riservate dei clienti. Il loro impiego deve essere adeguato al fabbisogno di protezione del rispettivo mandato.

Molti dei miei mandati riguardano decisioni strategiche, conflitti interni, progetti a rischio, cambiamenti organizzativi o iniziative tecnologiche riservate.

Una descrizione pubblica dettagliata potrebbe permettere di risalire a organizzazioni, persone o situazioni aziendali. Per questo anonimizzo i casi di studio, salvo esplicita autorizzazione a una pubblicazione con nomi.

L'anonimizzazione non serve a ingigantire artificialmente i risultati. Protegge le persone coinvolte, pur permettendo di presentare in modo comprensibile la situazione di partenza, l'approccio e le conclusioni principali.

L'IA può supportarmi nella ricerca, nella strutturazione, nella documentazione, nell'elaborazione di varianti e nel trattamento di grandi quantità di informazioni.

L'impiego avviene in funzione del compito e tenendo conto di riservatezza, protezione dei dati e qualità professionale. I risultati dei sistemi di IA non vengono ripresi come fatti o decisioni senza verifica.

L'IA è parte integrante del mio modo di lavorare, ma non sostituisce il lavoro umano. La qualità nasce da esperienza, contesto, guida, verifica e giudizio umano. Chi approva un risultato ne porta la responsabilità; la profondità della verifica dipende dal rischio.

Le persone conducono i colloqui decisivi, valutano le correlazioni, ponderano interessi e rischi e si assumono la responsabilità di raccomandazioni e azioni.

Questo vale in particolare per le decisioni di guida, i conflitti, le valutazioni etiche, i temi di personale sensibili e le situazioni in cui le informazioni sono incomplete o contraddittorie.

L'IA può fornire spunti, strutture e bozze, ma non può valutare con responsabilità ciò che è appropriato per un'organizzazione concreta e le sue persone. Questa responsabilità resta alle persone coinvolte.

Sì. Ezra Luck è un agente di IA (software) di MATTLI-DIGITAL, non una persona. Mi supporta nel coordinamento dei progetti, nel lavoro di CRM e documentazione e in compiti ricorrenti di marketing e coordinamento.

Ezra Luck opera sempre sotto guida umana. Decisioni, comunicazione esterna e responsabilità professionale restano alle persone competenti – il suo compito è riunire le informazioni e mantenere la visione d'insieme, non decidere. Non prende decisioni strategiche o imprenditoriali autonome.