Sfide per il Program Manager attraverso le Differenze Interculturali

nel Contesto di Progetti su Larga Scala

Originale in inglese: Roberto S. Greco, Projects & Cultures – Intercultural Differences in Large-Scale Projects – Challenges to the Program Manager, [Caso di Studio per la certificazione IPMA Livello A]. Wiesbaden, Assia, D. CSC Akademie Wiesbaden, 2017. Senza ISBN.

Rif. [greco2017]

Caso di Studio

Questa Caso di Studio, redatto da Roberto S. Greco per la certificazione IPMA Livello A nel febbraio 2016, analizza le complesse sfide che un Program Manager (PgM – Capo di Larghi Progetti/Programmi) affronta la gestione di progetti e programmi IT su larga scala, con un focus particolare sull’impatto delle differenze culturali (nazionali e organizzative).

Il caso di studio si basa sull’esperienza personale dell’autore nella gestione di un programma complesso (denominato Programma Principale per chiarezza) all’interno di una grande organizzazione tecnologica globale (denominata Organizzazione Madre).

[NdA: I termini Organizzazione Madre e Programma Principale sono usati qui per anonimizzare il nome della società per cui lavoravo ed il programma che gestivo]

0. Premessa

La premessa introduce la complessità dei grandi programmi e progetti IT, caratterizzati da pluralismo di tecnologie, organizzazioni, persone e culture.

Viene sottolineato come la comprensione del contesto in cui il Programma Principale operava sia fondamentale per capire il ruolo delle differenze interculturali nella sua gestione e successo.

L’Organizzazione Madre, con una lunga storia di fusioni e acquisizioni, presenta un paesaggio eterogeneo di sistemi, tecnologie, persone e culture lavorative.

Questa diversità è terreno fertile per potenziali conflitti, che rappresentano una sfida per il PgM.

0.1. Interculturale rispetto Cross-Culturale

In questa sezione, l’autore definisce i termini: interculturale si riferisce a ciò che avviene tra due o più culture, mentre cross-culturale indica un confronto e contrasto tra gruppi culturali.

0.2. Cultura Organizzativa rispetto Nazionale

Viene adottata la definizione di cultura di Geert Hofstede (* 2 ottobre 1928, Haarlem, NH, NL; † 12 febbraio 2020, Ede, GE, NL) come programmazione collettiva della mente che distingue i membri di un gruppo.

Si considerano sia la cultura nazionale che quella organizzativa.

La cultura organizzativa è più delimitata, dipendendo dal datore di lavoro, mentre la cultura nazionale è più difficile da definire chiaramente.

L’autore menziona la sua esperienza personale trentennale nel settore IT e ventennale nella gestione di progetti/programmi, con un contesto culturale nazionale eterogeneo.

0.3. Valutazione Personale delle Differenze Culturali

Si sottolinea che le valutazioni delle differenze culturali presentate sono personali e non rivendicano scientificità.

L’autore riconosce che la sua stessa provenienza culturale può aver influenzato le sue valutazioni.

1. L’Ambiente del Programma

Questo capitolo descrive il contesto del Programma Principale attraverso un’analisi SLEPT (Sociale, Legale, Economico, Politico, Tecnologico).

Vengono coperti gli aspetti sociali (cultura organizzativa e nazionale), legali (conformità normativa), economici (budget e ricavi), politici (strutture organizzative e stakeholder) e tecnologici (piattaforme e sistemi come driver principale).

1.1. Organizzazione Permanente

Viene presentata la struttura dell’Organizzazione Madre, attiva nei servizi transazionali di business e pagamenti.

Si descrivono le sue Business Unit (BU: Unità Aziendale) regionali e le due unità orizzontali chiave: Dipartimento di Sviluppo SW e Programma per la Standardizzazione dei Sistemi Globali.

1.1.1. Dipartimento di Sviluppo SW

Questa unità paneuropea si occupava dello sviluppo e del refactoring di prodotti e servizi interni, utilizzando un approccio SOA (Service-Oriented Architecture) e ridisegnando il Paesaggio Globale dei Servizi di Pagamento (PGSP).

I prodotti di questo dipartimento erano destinati alla personalizzazione per clienti locali.

1.1.2. Dipartimento di Sviluppo SW e Programma per la Standardizzazione dei Sistemi Globali

QUesto Programma globale, gestito principalmente da uffici in Belgio, Francia e Germania, mirava alla coordinazione e standardizzazione di processi, servizi e sistemi.

Ha agito sia come organizzazione permanente che come programma temporaneo, essendo il principale acquirente e distributore interno dei prodotti del succitato dipartimento.

Si evidenzia la stretta interconnessione tra le due organizzazioni e programmi, sottolineando come le differenze interculturali (nazionali e organizzative) fossero un fattore cruciale.

1.2. Ambiti Business e Tecnici

Si spiega l’interrelazione tra i processi di business dei clienti dell’Organizzazione Madre e i sistemi che li abilitano.

1.2.1. Business (Attività, Campo di Applicazione)

Si illustrano i processi principali nel dominio dei pagamenti con carta (Accettazione, Acquisizione, Elaborazione degli Schemi, Emissione), e come il PSGP sia stato creato per categorizzare questi processi e dare una visione unificata a diverse unità e progetti.

Il PSGP è stata un mezzo potente per il successo dei programmi, fungendo da riassunto per i manager, architettura SOA per i PM e portfolio per i venditori.

1.2.1.1 La Codifica del Programma Principale

Viene descritto un sistema di codifica a quattro cifre utilizzato nel PGSP, che ha rappresentato un legame chiave tra i requisiti di business e le consegne IT.

Questa codifica è stata adottata sia dal business che dall’IT.

1.2.2. Sistemi, Prodotti e Tecnologia

Si descrive come molte aziende dell’Organizzazione Madre avessero sistemi proprietari per i servizi, portando a una competizione interna per l’adozione dei propri sistemi nei programmi.

Il PgM ha affrontato la sfida di scegliere quale sistema includere nel Programma Principale, negoziando con gli stakeholder per ottenere il consenso anche dalle unità escluse, il che ha richiesto notevoli capacità politiche e diplomatiche e una comprensione delle diverse culture nazionali.

Vengono forniti esempi specifici di approcci diplomatici adottati con manager di diverse nazionalità (tedeschi, belgi, francesi).

1.3. Applicazione della Gestione dei Progetti nell’Organizzazione Madre

Si rileva che diverse entità dell’Organizzazione Madre avevano diverse culture e orientamenti nella gestione dei progetti, legate principalmente alla loro posizione organizzativa.

1.3.1. Orientamento al Portafoglio

Le entità verticali gestivano portafogli di prodotti, servizi o clienti.

Il ruolo del PgM era di aiutare i manager locali a scegliere i progetti per i loro portafogli tra quelli influenzati dal Programma Principale, richiedendo visite personali per ottenere il loro consenso.

1.3.2. Orientamento al Progetto

Tutte le entità erano orientate al progetto, ma con significati, approcci, metodi e strumenti molto diversi.

Nelle BU, la gestione del progetto era vista più come un lavoro amministrativo, mentre nelle entità orizzontali dedicate allo sviluppo software, l’unica sfida era assumere il PM giusto.

1.3.2.1 Metodi PM all’interno del Programma Principale

Le discussioni sui metodi PM (Agile, Waterfall, RUP/2TUP, PRINCE2, PMBOK Guide) non mostravano differenze culturali nazionali nell’adozione, se non per la prevalenza di certificazioni PRINCE2 in alcuni paesi (Paesi Bassi, Belgio) e PMP in altri (Francia, Germania).

1.3.3. Orientamento al Programma

Le entità orizzontali dell’Organizzazione Madre erano chiaramente orientate al programma.

L’autore è stato coinvolto in due programmi di questo tipo (Programma Sviluppo Prodotti e Programma per la Standardizzazione dei Sistemi Globali), che si focalizzavano sui benefici a lungo termine e avevano un Program Management Office (PgMO) centrale.

L’autore ha avviato numerosi programmi e progetti componenti, selezionando il personale e sviluppando linee guida e strumenti.

1.3.4. Implementazione di Progetto, Programma e Portafoglio

Per implementare una cultura di progetto e programma, l’autore ha organizzato e condotto sessioni di formazione per Project Leader (PL), che includevano sia hard skills che soft skills data la natura interculturale delle organizzazioni.

Sono stati organizzati anche corsi cross-culturali, ad esempio per l’integrazione con un Centro di Consegna Offshore in India ed uno in Marocco, notando differenze nelle sessioni adattate alle culture locali.

1.4. Struttura del Programma, Organizzazione e Allineamento Strategico

Il Programma per la Standardizzazione dei Sistemi Globali manteneva un PgMO-Handbook che fungeva da base per i singoli PgM per sviluppare i propri Charter e Piani.

Viene mostrato l’organigramma di alto livello del programma, evidenziando il numero di comitati e la loro interazione.

Si nota come il programma fosse percepito come un’organizzazione indipendente, con i PgM che interagivano sia internamente che con entità esterne, creando potenziali conflitti.

1.4.1. Struttura Tecnica e Organizzativa del Programma Principale

La complessità del Programma Principale si rifletteva anche nella sua struttura organizzativa e tecnica, data dalla necessità di modificare sistemi esistenti.

Viene mostrato un diagramma che mappa i componenti tecnici alle Regional Business Unit (RBU) e ai programmi del Programma per la Standardizzazione dei Sistemi Globali.

Alcuni componenti avevano requisiti contrastanti, risolti con l’Architetto Globale.

1.4.2. Organizzazione del Programma

Si illustra l’organigramma del Programma Principale e le relazioni tra i progetti componenti e le linee di gestione.

Le differenze culturali (organizzative e nazionali) hanno giocato un ruolo cruciale nella gestione dei PM e PgM, richiedendo l’adattamento dello stile di gestione (ad esempio, uno stile laissez-faire con il Belgio, paternalistico/autocratico con la Francia, e democratico con la Germania).

Si evidenzia come le diverse culture portassero a presentare in riunione organigrammi diversi (linea di gestione rispetto a programma).

1.4.2.1 Self-control (Auto-controllo) L’auto-controllo è stato un PM-Element difficile per l’autore. Vengono descritte strategie per gestire situazioni difficili, come non rispondere a attacchi diretti in riunione o via email, chiedere chiarimenti scritti e posticipare le risposte a mail accusatorie. Si nota una differenza culturale: i nord-europei erano più auto-controllati dei sud-europei.

1.4.3. Program Requirements, Benefits, and Scope (Requisiti, Benefici e Ambito del Programma) La definizione del Business Case (BC) del “Programma Principale” è stata una delle prime attività. L’autore ha incontrato resistenza nel proporre modifiche al BC, poiché non tutte le parti coinvolte lo consideravano un documento dinamico. Il BC era la base per definire l’ambito dei singoli progetti componenti.

1.4.4. Scope & Deliverables (Ambito e Deliverable) L’ambito del “Programma Principale” era ben definito dalla GSC. Alcuni componenti sono stati scelti per utilizzare sistemi legacy anziché nuovi progetti O&S per ragioni politiche ed economiche, e alcuni componenti legacy sono stati modificati con funzionalità limitate. L’autore ha affrontato la sfida della inconsistenza nelle convenzioni di denominazione tra diverse unità, mitigandola con comunicazioni ridondanti e precise.

1.4.5. Complexity of [Programma Principale] and its main Components (Complessità del Programma Principale e dei suoi Componenti Principali) La complessità del programma è difficile da misurare. L’autore ha percepito una complessità complessiva “estrema”, superiore a quella dei singoli progetti componenti. Viene menzionato un bias comune nel settore, dove la complessità viene spesso ridotta al solo budget o al numero di “Person Days”, ignorando altri fattori.

1.5. Interested Parties (Parti Interessate) La gestione degli stakeholder è considerata fondamentale per il successo dei programmi. L’autore ha implementato un processo strutturato per analizzare e gestire gli stakeholder, classificandoli in base a posizione, influenza/potere, attitudine e potenziale di conflitto, con sottodimensioni relative al concern, al programma e al progetto componente. Le differenze culturali nazionali e i relativi bias hanno avuto un impatto su questo PM-Element.

1.5.1. Assertiveness (Assertività) Si discute l’importanza delle capacità comunicative e della retorica, specialmente in ambienti multiculturali dove l’inglese è la lingua del progetto ma non la lingua madre di tutti. L’autore ha notato che le riunioni in francese facilitavano l’espressione dei partecipanti. Era cruciale che decisioni e richieste fossero chiare per evitare incomprensioni, e la conoscenza della lingua madre del proprio interlocutore aiutava a chiarire ambiguità.

1.5.2. Conflict & Crisis (Conflitto e Crisi) I conflitti sorgevano quasi quotidianamente a causa delle differenze culturali organizzative (strutture gerarchiche diverse) e nazionali (diversi paesi europei, India, Marocco). L’autore, grazie alla sua origine italiana e alla lunga esperienza in Germania, è riuscito a fare da ponte tra le culture e a moderare l’intensità dei conflitti. La risoluzione dei conflitti e la de-escalation erano attività principali.

1.5.3. Negotiation (Negoziazione) La negoziazione ha avuto un ruolo fondamentale nella risoluzione delle situazioni conflittuali e nella risposta alle crisi. L’Organizzazione Madre ha organizzato workshop sull’etichetta delle riunioni, che l’autore ha supportato. Le strategie di negoziazione cambiavano a seconda della provenienza culturale degli interlocutori, mantenendo però i passi base.

1.6. Personal Role and Function (Ruolo e Funzione Personale) L’autore si definisce un “pompiere” (firefighter) e “problem-solver”, spesso ingaggiato in programmi in stato critico e che lascia una volta risolte le problematiche. La sua esperienza internazionale (Italia, Germania, Finlandia, Austria, ecc.) e i suoi interessi (Linguistica, Cultura, Psicologia) lo hanno reso un candidato ideale per programmi interculturali.

1.6.1. Leadership (Leadership) Lo stile di gestione dell’autore è rigoroso ma equo. Il fattore culturale nazionale ha influenzato la leadership: in Francia, la leadership era associata a una forte autorità e comandi, richiedendo all’autore di adattare il suo stile (meno partecipativo/democratico) per funzionare con i team in quelle località. Ha comunque mantenuto comunicazione aperta e trasparenza “scendendo di livello” fino ai membri del team.

1.6.2. Progam Manager (in O&D) (Program Manager in Offerte & Sviluppo) Come membro del PgMO in O&S e poi PgM del “Programma Principale”, l’autore ha svolto attività di pianificazione, esecuzione, controllo e monitoraggio, oltre a consigliare i PM su metodi e strumenti, sviluppare piani di capacità, coordinare team onsite/offshore, selezionare e assumere nuovi PM e condurre sessioni di formazione.

1.6.3. PCI Compliance Manager (in O&D) (Responsabile Conformità PCI in Offerte & Sviluppo) L’autore ha ricoperto anche il ruolo di Responsabile Conformità PCI, coordinando un comitato interno per la conformità con gli standard PCI DSS e PCI PA-DSS. Questa esperienza e conoscenza hanno facilitato il suo ruolo di consulenza all’interno del “Programma Principale”, specialmente per garantire la conformità PCI dei sistemi.

1.7. Constraints for the Program Realization (Vincoli per la Realizzazione del Programma) I principali vincoli per il successo del programma includevano aspetti tecnici (sistemi legacy), gestionali (detrattori), temporali (scadenze rigide) e inter-progetto. L’autore ha aggiunto anche vincoli geografici (es. ridondanza dei data center) e regolatori (conformità a standard di settore e PCI)

1.7.1. Health, Security, Safety & Environment (Salute, Sicurezza & Ambiente) Sebbene non direttamente coinvolto, l’autore ha gestito un’emergenza sanitaria (allarme pandemia aviaria nel luglio 2011) che ha richiesto lo sviluppo di un piano di contingenza per garantire la continuità dei progetti ad alta priorità. Le misure includevano l’identificazione di membri chiave del team, la fornitura di accessi remoti e l’autorizzazione al lavoro da remoto. Si è notata una differenza culturale nella percezione della minaccia.

2. The Program and its Planning (Il Programma e la Sua Pianificazione) Questo capitolo fornisce i dati chiave del “Programma Principale”, che è iniziato nel luglio 2009 e ha consegnato i primi risultati a metà 2012.

2.1. Program Poster (Poster del Programma) Vengono presentati i dati chiave del programma, inclusi tipo, organizzazione responsabile, periodo, cliente (interno), sponsor (livello C), utenti senior, fornitori senior e una breve descrizione del programma e della sua rilevanza a lungo termine.

2.2. Projects Requirements and Objectives (Requisiti e Obiettivi dei Progetti) Si è posto l’accento sui benefici per l’Organizzazione Madre, derivati dalla visione e strategia del programma “IT-Globalizzazione”. Questi benefici sono stati tradotti in requisiti di alto livello per i progetti componenti. L’autore ha dovuto approfondire la comprensione dei requisiti tecnici per argomentare con i manager che tentavano di allocare sforzi di manutenzione o sviluppo extra al programma.

2.3. Time & Project Phases (Tempo e Fasi del Progetto) Viene presentato il programma di progetto di alto livello del “Programma Principale”. La pianificazione avveniva a diversi livelli di dettaglio, con scale temporali che andavano dai mesi (per i livelli superiori) ai giorni o frazioni di ora (per i piani di cut-over).

2.3.1. Planning Tools (Strumenti di Pianificazione) Molti PM utilizzavano MS-Project o MS-Excel. L’autore stesso utilizzava MS-Project anche per la pianificazione di alto livello e raccomandava corsi di formazione sull’uso di questo strumento.

2.3.2. Cut-Over / Roll-Out Management (Gestione del Cut-Over / Roll-Out) Vengono descritti i diversi ambienti IT (DEV, INT, QA, PROD) e il concetto di “cut-over” come il passaggio da un vecchio sistema a uno nuovo. I piani di cut-over sono estremamente dettagliati (fino a ore o frazioni), data la rigidità dei vincoli temporali e le penalità in caso di superamento dei tempi di inattività. Viene illustrata una procedura di cut-over per sistemi ridondanti per garantire la continuità del servizio.

2.3.2.1 Efficiency (Efficienza) L’efficienza nel “Programma Principale” ha beneficiato dell’adozione di metodi e strumenti già consolidati da altri programmi. Si sono riscontrate differenze culturali nella comprensione dell’efficienza, ad esempio, per un Centro di Consegna Offshore, l’efficienza era sinonimo di seguire i processi stabiliti (CMMi Livello 5).

2.4. Project Structures (Strutture di Progetto) La struttura di più alto livello per i programmi IT-Globalizzazione era data dalla GSC. Diversi tipi di diagrammi erano utilizzati a seconda degli interlocutori o del framework PM utilizzato. Viene mostrato un esempio di Product Flow Diagram secondo la metodologia PRINCE2, evidenziando il focus sui deliverable (prodotti) piuttosto che sulle attività. L’autore ha supportato l’uso della Product Breakdown Structure rispetto alla Work Breakdown Structure nel contesto del “Programma Principale”.

2.5. Quality (Qualità) La qualità, misurata in termini di difetti software e tempo di risposta della piattaforma, era cruciale. Il PgM si è affidato a un PM esperto per il team di test. L’unica problematica riguardante la qualità è stata legata a poche escalation relative a un sistema legacy con un alto numero di difetti apparenti.

2.6. People Management (Gestione delle Persone) L’articolo critica l’uso del termine “risorse” per riferirsi alle persone, specialmente nel contesto tedesco dove “Ressourcen” ha una connotazione negativa.

2.6.1. Resources (Risorse) Le attività legate alle risorse includevano l’assegnazione dei progetti a diverse entità, l’identificazione delle competenze necessarie e la verifica della disponibilità del personale. I conflitti sorgevano spesso a causa di stime troppo ottimistiche fornite da alcune entità per “vincere” i progetti. Si ritiene che questi conflitti fossero più legati alle differenze organizzative che a quelle nazionali.

2.6.1.1 Relaxation (Rilassamento/De-escalation) La risoluzione dei conflitti e la de-escalation erano attività principali del PgM. La conoscenza delle culture coinvolte ha permesso di estinguere proattivamente molti conflitti prima che escalassero. Ciò è stato ottenuto tramite visite frequenti e incontri informali di persona, ritenuti più efficaci delle riunioni formali. L’umorismo può aiutare a formare il team e alleviare lo stress, ma deve essere usato con cautela a causa delle differenze culturali nella percezione dell’umorismo.

2.6.2. Teamwork (Lavoro di Squadra) Nonostante il management promuovesse l’idea di “un programma, un team”, la realtà quotidiana era complessa a causa della competizione tra le diverse entità, che spesso impediva ai team di superare la fase di “storming” (secondo Tuckman). Tuttavia, iniziative come sessioni cross-culturali e eventi globali hanno contribuito a migliorare la coesione tra i PM e i membri del team nei loro progetti.

2.6.2.1 Values appreciation (Apprezzamento dei Valori) Mostrare un approccio etico alla gestione, ascoltare attivamente le preoccupazioni del team e considerare le loro opinioni ha rafforzato le relazioni, rivelandosi utile nelle fasi critiche. È importante studiare e comprendere i valori legati alle culture nazionali.

2.6.3. Personnel management (Gestione del Personale) Il lavoro dell’autore non era direttamente legato alla gestione del personale di tutti i PM e membri del team, in quanto impiegati da altre organizzazioni. Tuttavia, ha partecipato alle valutazioni dei PM a lui riportanti e ha raccomandato l’uso di checklist e questionari standardizzati per mitigare i bias culturali nel processo di assunzione. Ha notato che le organizzazioni più gerarchiche erano più rigide nelle loro valutazioni.

2.7. Program Funding and Legals (Finanziamento del Programma e Aspetti Legali) Questi PM-Elementi non erano direttamente gestiti dall’autore, se non per gli aspetti finanziari relativi alle risorse umane. I conflitti sorgevano principalmente riguardo a ciò che doveva essere incluso o escluso dalle liste di priorità dei programmi IT-Globalizzazione.

2.7.1. Finance (Finanza) Il finanziamento del “Programma Principale” dipendeva dal finanziamento del programma “IT-Globalizzazione”. La posizione in classifica del “Programma Principale” (5° su 10) richiedeva un monitoraggio e una giustificazione costante dei suoi benefici per i principali stakeholder.

2.7.2. Cost and Finance (Costo e Finanza) Nel contesto del “Programma Principale”, budget e costi erano calcolati principalmente in termini di numero di risorse o Person Days, mentre altri costi erano a carico di altre organizzazioni.

2.7.3. Procurement & Contract (Approvvigionamento e Contratti) Questo elemento era di competenza dei dipartimenti Infrastrutture e Operazioni delle rispettive aziende. L’autore aveva un ruolo consultivo.

2.7.4. Legal (Legale) Gli aspetti legali erano regolati dalle entità operative, con due eccezioni: le certificazioni degli schemi da parte delle industrie di pagamento (Visa e MasterCard) e la conformità PCI del software e dei sistemi. L’autore ha avviato un progetto per le certificazioni e ha sfruttato la sua precedente esperienza come Responsabile Conformità PCI.

2.7.4.1 Ethics (Etica) L’Organizzazione Madre non aveva un Codice Etico obbligatorio, ma l’autore ha aderito personalmente al Codice Etico del PMI e al TATA Code of Conducts. Non ha notato differenze culturali significative relative a questo PM-Element.

3. Program Execution (Esecuzione del Programma) L’autore ha assunto il programma quando era già iniziato e lo ha lasciato prima della sua conclusione, quindi non ha sperimentato personalmente l’inizio o la chiusura completi.

3.1. Program and Project Start and Closure (Avvio e Chiusura di Programmi e Progetti) Assumendo il programma a metà percorso, l’autore ha dovuto condurre una “iniziazione tardiva”, compiendo un “Health-Check” del programma e rivedendo/emendando il Program Charter e il Program Management Plan, allineandoli agli obiettivi strategici. Ha anche revisionato la Program Work Breakdown Structure (PWBS), individuando ridondanze e raccomandando la chiusura o il ridimensionamento di alcuni progetti per risparmiare costi e migliorare la riusabilità.

3.1.1.1 Engagement & Motivation (Coinvolgimento e Motivazione) Il processo di onboarding dei membri del team seguiva un processo definito, con presentazioni personali e attività informali. L’approccio dell’autore per mostrare il proprio coinvolgimento e motivare il team variava in base alla cultura nazionale, con la delega e l’assegnazione di responsabilità come fattori chiave di successo. L’approccio generale era “duro ma equo”, assumendosi la responsabilità anche degli errori del team.

3.1.2. Close-Out (Chiusura) Nonostante non abbia gestito direttamente la chiusura del “Programma Principale”, l’autore ritiene che la maggior parte del lavoro per una corretta chiusura dovrebbe essere preparato durante tutta la vita del progetto/programma. La “Lessons Learned” dovrebbe essere registrata costantemente, non solo alla fine.

3.2. Governance (Governance) La composizione dello Steering Committee (SteerCo) si è ampliata nel tempo per includere più capi unità.

3.2.1. Communication (Comunicazione) L’autore ha revisionato il piano di comunicazione del “Programma Principale”, includendo report mensili per i contributors, chiamate mensili per i neutrali e visite mensili per i detrattori. L’adattamento della comunicazione alle diverse culture era fondamentale per ottenere il buy-in degli stakeholder. Si critica la matrice RACI per la sua ambiguità nel significato di “Responsible” in alcune culture (es. tedesca), suggerendo l’uso di matrici alternative come DACI o PACSI.

3.2.1.1 Openness (Apertura) Molti progetti di sviluppo utilizzavano metodologie Agile. L’autore ha applicato i valori Agile come apertura, trasparenza e attenzione alle persone all’interno del “Programma Principale”, senza però trascurare l’importanza della documentazione e della pianificazione. L’apertura era cruciale per interagire con persone di diverse culture.

3.2.2. Control & Reports (Controllo e Reportistica) A causa della mancanza di un PgMO dedicato al “Programma Principale”, l’autore ha delegato la raccolta e il consolidamento dei report ai PM a rotazione, migliorando la consapevolezza e la fiducia tra di loro. Il controllo del business case e dei benefici è rimasto una responsabilità primaria dell’autore. Si è notata una resistenza al cambiamento nei report da parte di alcune unità con forti gerarchie.

3.3. Knowledge Management (Gestione della Conoscenza) Gli sforzi del programma “IT-Globalizzazione” per ottenere il consenso delle unità tramite eventi globali e newsletter non sono stati sufficienti a superare le sfide di un ambiente eterogeneo. Tuttavia, alcune iniziative, come un piccolo libretto riassuntivo del programma e dei suoi principali stakeholder, sono state molto apprezzate.

3.4. Change and Configuration Management (Gestione dei Cambiamenti e della Configurazione) I processi di Change Management e Configuration Management erano ben consolidati e seguiti. Il PgM del “Programma Principale” non ha avuto molta influenza su questi processi, poiché il programma utilizzava quelli esistenti.

3.4.1. Changes (Cambiamenti) Il processo di gestione dei cambiamenti era gestito dal PgMO. L’autore si è occupato principalmente di rivedere e aggiornare il business case e i requisiti di alto livello in caso di modifiche.

3.5. Risks & Issues (Rischi e Problemi) L’autore ha riscontrato una difficoltà diffusa nel distinguere rischi da problemi e nel formulare piani di mitigazione. Raccomanda un Risk Manager o un Team di Risk Management dedicato per programmi su larga scala.

3.5.1. Risk & Opportunity (Rischio e Opportunità) L’identificazione e la classificazione dei rischi, insieme alla preparazione di piani di back-up, erano attività quotidiane del PgM. L’autore ha dedicato molto sforzo alla normalizzazione e al monitoraggio dei rischi segnalati dai PM dei progetti componenti. Sono state notate differenze culturali organizzative e nazionali nella gestione dei rischi.

3.5.2. Problem resolution (Risoluzione dei Problemi) I problemi più comuni riguardavano questioni interculturali, conflitti tra obiettivi globali e locali, mancanza di risorse e rivalità tra le aziende del gruppo. L’autore ha preferito de-escalare i problemi, anche partecipando a riunioni in francese per favorire un clima più rilassato. Ha avuto il mandato di ri-prioritizzare i progetti e spostare risorse all’interno del programma. Vengono citati esempi di risoluzione di problemi critici, come il coinvolgimento di Centri di Consegna Offshore per superare la mancanza di competenze.

3.5.2.1 Creativity (Creatività) La creatività è vista come essenziale per risolvere problemi e mitigare i rischi. L’autore ha utilizzato sessioni di brainstorming mensili con il team per elaborare liste di problemi, rafforzare il senso di squadra e condividere informazioni.

3.5.2.2 Results orientation (Orientamento ai Risultati) L’orientamento ai risultati è stato applicato tramite matrici di tracciabilità per monitorare i progressi dei benefici dal livello del programma fino ai singoli progetti e deliverable.

3.6. Program Culture (Cultura del Programma) Nel programma “IT-Globalizzazione” e in “Offerte & Sviluppo” era presente una cultura di lavoro di squadra, apertura, fiducia e rispetto. Nonostante i conflitti interculturali, il “Programma Principale” ha avuto successo.

3.6.1. Geographical distribution of CSCH Sub-Projects (Distribuzione Geografica dei Sotto-progetti del Programma Principale) Viene mostrata la distribuzione geografica dei sotto-progetti di sviluppo software del “Programma Principale”, evidenziando la natura multinazionale e multiculturale delle organizzazioni.

4. Personal Program Management Experience (Esperienza Personale di Gestione del Programma) L’autore ha contato quanti dei 46 elementi di competenza IPMA 3.0 sono stati influenzati da differenze culturali (nazionali e/o organizzative). Sebbene questa non sia una ricerca scientifica, l’autore ha percepito che tali differenze permeatevano quasi ogni attività. Scrivere questo studio ha aiutato l’autore a riflettere su nuovi modi per risolvere i conflitti interculturali.

5. Concluding Remarks (Conclusioni) L’autore intende approfondire le proprie conoscenze e esperienze nella gestione di portfolio e negli aspetti finanziari dei progetti, programmi e portfolio. Ha già iniziato questo percorso nella sua attuale azienda, un’importante società di consulenza, occupandosi della gestione di portfolio e partecipando a workshop di finanza. Continuerà anche i suoi studi di psicologia. Infine, l’autore auspica che la gestione dei progetti venga riconosciuta come una vera professione, al di là delle numerose certificazioni disponibili.