{"id":1746,"date":"2025-07-31T08:30:04","date_gmt":"2025-07-31T06:30:04","guid":{"rendered":"https:\/\/robertogreco.eu\/biblioteca\/?p=1746"},"modified":"2025-08-03T17:55:13","modified_gmt":"2025-08-03T15:55:13","slug":"program-manager-differenze-interculturali-progetti-larga-scala","status":"publish","type":"post","link":"https:\/\/robertogreco.eu\/biblioteca\/program-manager-differenze-interculturali-progetti-larga-scala\/","title":{"rendered":"Sfide per il Program Manager attraverso le Differenze Interculturali nel Contesto di Progetti su Larga Scala"},"content":{"rendered":"

Sfide per il Program Manager attraverso le Differenze Interculturali<\/h1>\n

nel Contesto di Progetti su Larga Scala<\/strong><\/p>\n

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

Rif. [greco2017]<\/a><\/p>\n

Caso di Studio<\/h2>\n

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<\/em> (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).<\/p>\n

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

[NdA: I termini Organizzazione Madre<\/em> e Programma Principale<\/em> sono usati qui per anonimizzare il nome della societ\u00e0 per cui lavoravo ed il programma che gestivo]<\/p>\n

0. Premessa<\/span><\/strong><\/h2>\n

La premessa introduce la complessit\u00e0 dei grandi programmi e progetti IT, caratterizzati da pluralismo di tecnologie, organizzazioni, persone e culture.<\/p>\n

Viene sottolineato come la comprensione del contesto in cui il Programma Principale<\/em> operava sia fondamentale per capire il ruolo delle differenze interculturali nella sua gestione e successo.<\/p>\n

L’Organizzazione Madre,<\/em> con una lunga storia di fusioni e acquisizioni, presenta un paesaggio eterogeneo di sistemi, tecnologie, persone e culture lavorative.<\/p>\n

Questa diversit\u00e0 \u00e8 terreno fertile per potenziali conflitti, che rappresentano una sfida per il PgM. <\/span><\/p>\n

0.1. Interculturale rispetto Cross-Culturale<\/span><\/strong><\/h3>\n

In questa sezione, l’autore definisce i termini: interculturale<\/em> si riferisce a ci\u00f2 che avviene <\/span>tra<\/span><\/em> due o pi\u00f9 culture, mentre cross-culturale<\/em> indica un <\/span>confronto e contrasto<\/span><\/em> tra gruppi culturali. <\/span><\/p>\n

0.2. Cultura Organizzativa rispetto<\/span><\/strong>\u00a0Nazionale<\/span><\/strong><\/h3>\n

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

Si considerano sia la cultura nazionale che quella organizzativa. <\/span><\/p>\n

La cultura organizzativa \u00e8 pi\u00f9 delimitata, dipendendo dal datore di lavoro, mentre la cultura nazionale \u00e8 pi\u00f9 difficile da definire chiaramente. <\/span><\/p>\n

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

0.3. Valutazione Personale delle Differenze Culturali<\/span><\/strong><\/h3>\n

Si sottolinea che le valutazioni delle differenze culturali presentate sono personali e non rivendicano scientificit\u00e0.<\/p>\n

L’autore riconosce che la sua stessa provenienza culturale pu\u00f2 aver influenzato le sue valutazioni. <\/span><\/p>\n

1. L’Ambiente del Programma<\/span><\/strong><\/h2>\n

Questo capitolo descrive il contesto del Programma Principale<\/em> attraverso un’analisi SLEPT (Sociale, Legale, Economico, Politico, Tecnologico).<\/p>\n

Vengono coperti gli aspetti sociali (cultura organizzativa e nazionale), legali (conformit\u00e0 normativa), economici (budget e ricavi), politici (strutture organizzative e stakeholder) e tecnologici (piattaforme e sistemi come driver principale). <\/span><\/p>\n

1.1. Organizzazione Permanente<\/span><\/strong><\/h3>\n

Viene presentata la struttura dell’Organizzazione Madre<\/em>, attiva nei servizi transazionali di business e pagamenti.<\/p>\n

Si descrivono le sue Business Unit<\/em> (BU: Unit\u00e0 Aziendale) regionali e le due unit\u00e0 orizzontali chiave: Dipartimento di Sviluppo SW<\/em> e Programma per la Standardizzazione dei Sistemi Globali<\/em>. <\/span><\/p>\n

1.1.1. Dipartimento di Sviluppo SW<\/span><\/h4>\n

Questa unit\u00e0 paneuropea si occupava dello sviluppo e del refactoring<\/em> di prodotti e servizi interni, utilizzando un approccio SOA (Service-Oriented Architecture<\/em>) e ridisegnando il Paesaggio Globale dei Servizi di Pagamento<\/em> (PGSP).<\/span><\/p>\n

I prodotti di questo dipartimento erano destinati alla personalizzazione per clienti locali. <\/span><\/p>\n

1.1.2. Dipartimento di Sviluppo SW e Programma per la Standardizzazione dei Sistemi Globali<\/span><\/h4>\n

QUesto Programma globale, gestito principalmente da uffici in Belgio, Francia e Germania, mirava alla coordinazione e standardizzazione di processi, servizi e sistemi. <\/span><\/p>\n

Ha agito sia come organizzazione permanente che come programma temporaneo, essendo il principale acquirente e distributore interno dei prodotti del succitato dipartimento.<\/span><\/p>\n

Si evidenzia la stretta interconnessione tra le due organizzazioni e programmi, sottolineando come le differenze interculturali (nazionali e organizzative) fossero un fattore cruciale. <\/span><\/p>\n

1.2. Ambiti Business e Tecnici<\/span><\/strong><\/h3>\n

Si spiega l’interrelazione tra i processi di business dei clienti dell’Organizzazione Madre<\/em> e i sistemi che li abilitano. <\/span><\/p>\n

1.2.1. Business<\/em> (Attivit\u00e0, Campo di Applicazione)<\/span><\/strong><\/h4>\n

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\u00e0 e progetti.<\/span><\/p>\n

Il PSGP <\/span>\u00e8 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. <\/span><\/p>\n

1.2.1.1 La Codifica del Programma Principale<\/span><\/strong><\/h5>\n

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.<\/p>\n

Questa codifica \u00e8 stata adottata sia dal business che dall’IT. <\/span><\/p>\n

1.2.2. Sistemi, Prodotti e Tecnologia<\/span><\/strong><\/h5>\n

Si descrive come molte aziende dell’Organizzazione Madre<\/em> avessero sistemi proprietari per i servizi, portando a una competizione interna per l’adozione dei propri sistemi nei programmi. <\/span><\/p>\n

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

Vengono forniti esempi specifici di approcci diplomatici adottati con manager<\/em> di diverse nazionalit\u00e0 (tedeschi, belgi, francesi). <\/span><\/p>\n

1.3. Applicazione della Gestione dei Progetti nell’Organizzazione Madre<\/span><\/strong><\/h4>\n

Si rileva che diverse entit\u00e0 dell’Organizzazione Madre<\/em> avevano diverse culture e orientamenti nella gestione dei progetti, legate principalmente alla loro posizione organizzativa. <\/span><\/p>\n

1.3.1. Orientamento al Portafoglio<\/span><\/strong><\/h5>\n

Le entit\u00e0 verticali gestivano portafogli di prodotti, servizi o clienti.<\/p>\n

Il ruolo del PgM era di aiutare i manager<\/em> locali a scegliere i progetti per i loro portafogli tra quelli influenzati dal Programma Principale<\/em>, richiedendo visite personali per ottenere il loro consenso. <\/span><\/p>\n

1.3.2. Orientamento al Progetto<\/span><\/strong><\/h5>\n

Tutte le entit\u00e0 erano orientate al progetto, ma con significati, approcci, metodi e strumenti molto diversi.<\/p>\n

Nelle BU, la gestione del progetto era vista pi\u00f9 come un lavoro amministrativo, mentre nelle entit\u00e0 orizzontali dedicate allo sviluppo software, l’unica sfida era assumere il PM giusto. <\/span><\/p>\n

1.3.2.1 Metodi PM all’interno del Programma Principale<\/span><\/strong><\/h6>\n

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). <\/span><\/p>\n

1.3.3. Orientamento al Programma<\/span><\/strong><\/h5>\n

Le entit\u00e0 orizzontali dell’Organizzazione Madre<\/em> erano chiaramente orientate al programma.<\/p>\n

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

L’autore ha avviato numerosi programmi e progetti componenti, selezionando il personale e sviluppando linee guida e strumenti. <\/span><\/p>\n

1.3.4. Implementazione di Progetto, Programma e Portafoglio<\/span><\/strong><\/h5>\n

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

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

1.4. Struttura del Programma, Organizzazione e Allineamento Strategico<\/span><\/strong><\/h4>\n

Il Programma per la Standardizzazione dei Sistemi Globali<\/em><\/span> manteneva un PgMO-Handbook<\/em> che fungeva da base per i singoli PgM per sviluppare i propri Charter<\/em> e Piani. <\/span><\/p>\n

Viene mostrato l’organigramma di alto livello del programma, evidenziando il numero di comitati e la loro interazione. <\/span><\/p>\n

Si nota come il programma fosse percepito come un’organizzazione indipendente, con i PgM che interagivano sia internamente che con entit\u00e0 esterne, creando potenziali conflitti. <\/span><\/p>\n

1.4.1. Struttura Tecnica e Organizzativa del Programma Principale<\/em><\/span><\/strong><\/h5>\n

La complessit\u00e0 del Programma Principale<\/em> si rifletteva anche nella sua struttura organizzativa e tecnica, data dalla necessit\u00e0 di modificare sistemi esistenti.<\/p>\n

Viene mostrato un diagramma che mappa i componenti tecnici alle Regional Business Unit<\/em> (RBU) e ai programmi del Programma per la Standardizzazione dei Sistemi Globali<\/em><\/span><\/span>. <\/span><\/p>\n

Alcuni componenti avevano requisiti contrastanti, risolti con l’Architetto Globale. <\/span><\/p>\n

1.4.2. Organizzazione del Programma<\/span><\/strong><\/h5>\n

Si illustra l’organigramma del Programma Principale<\/em> e le relazioni tra i progetti componenti e le linee di gestione. <\/span><\/p>\n

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<\/em> con il Belgio, paternalistico\/autocratico<\/em> con la Francia, e democratico<\/em> con la Germania). <\/span><\/p>\n

Si evidenzia come le diverse culture portassero a presentare in riunione organigrammi diversi (linea di gestione rispetto a programma). <\/span><\/p>\n

…<\/div>\n

1.4.2.1 Self-control (Auto-controllo)<\/span><\/strong> L’auto-controllo \u00e8 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\u00f9 auto-controllati dei sud-europei. <\/span><\/p>\n

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

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

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

1.5. Interested Parties (Parti Interessate)<\/span><\/strong> La gestione degli stakeholder \u00e8 considerata fondamentale per il successo dei programmi. <\/span> 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. <\/span> Le differenze culturali nazionali e i relativi bias hanno avuto un impatto su questo PM-Element. <\/span><\/p>\n

1.5.1. Assertiveness (Assertivit\u00e0)<\/span><\/strong> Si discute l’importanza delle capacit\u00e0 comunicative e della retorica, specialmente in ambienti multiculturali dove l’inglese \u00e8 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\u00e0. <\/span><\/p>\n

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

1.5.3. Negotiation (Negoziazione)<\/span><\/strong> 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\u00f2 i passi base. <\/span><\/p>\n

1.6. Personal Role and Function (Ruolo e Funzione Personale)<\/span><\/strong> 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. <\/span> 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. <\/span><\/p>\n

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

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

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

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

1.7.1. Health, Security, Safety & Environment (Salute, Sicurezza & Ambiente)<\/span><\/strong> 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\u00e0 dei progetti ad alta priorit\u00e0. Le misure includevano l’identificazione di membri chiave del team, la fornitura di accessi remoti e l’autorizzazione al lavoro da remoto. <\/span> Si \u00e8 notata una differenza culturale nella percezione della minaccia. <\/span><\/p>\n

2. The Program and its Planning (Il Programma e la Sua Pianificazione)<\/span><\/strong> Questo capitolo fornisce i dati chiave del “Programma Principale”, che \u00e8 iniziato nel luglio 2009 e ha consegnato i primi risultati a met\u00e0 2012. <\/span><\/p>\n

2.1. Program Poster (Poster del Programma)<\/span><\/strong> 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. <\/span><\/p>\n

2.2. Projects Requirements and Objectives (Requisiti e Obiettivi dei Progetti)<\/span><\/strong> Si \u00e8 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. <\/span> 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. <\/span><\/p>\n

2.3. Time & Project Phases (Tempo e Fasi del Progetto)<\/span><\/strong> 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). <\/span><\/p>\n

2.3.1. Planning Tools (Strumenti di Pianificazione)<\/span><\/strong> 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. <\/span><\/p>\n

2.3.2. Cut-Over \/ Roll-Out Management (Gestione del Cut-Over \/ Roll-Out)<\/span><\/strong> 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. <\/span> I piani di cut-over sono estremamente dettagliati (fino a ore o frazioni), data la rigidit\u00e0 dei vincoli temporali e le penalit\u00e0 in caso di superamento dei tempi di inattivit\u00e0. <\/span> Viene illustrata una procedura di cut-over per sistemi ridondanti per garantire la continuit\u00e0 del servizio. <\/span><\/p>\n

2.3.2.1 Efficiency (Efficienza)<\/span><\/strong> L’efficienza nel “Programma Principale” ha beneficiato dell’adozione di metodi e strumenti gi\u00e0 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). <\/span><\/p>\n

2.4. Project Structures (Strutture di Progetto)<\/span><\/strong> La struttura di pi\u00f9 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. <\/span> Viene mostrato un esempio di Product Flow Diagram secondo la metodologia PRINCE2, evidenziando il focus sui <\/span>deliverable<\/span><\/em> (prodotti) piuttosto che sulle attivit\u00e0. <\/span> L’autore ha supportato l’uso della Product Breakdown Structure rispetto alla Work Breakdown Structure nel contesto del “Programma Principale”. <\/span><\/p>\n

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

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

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

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

2.6.2. Teamwork (Lavoro di Squadra)<\/span><\/strong> Nonostante il management promuovesse l’idea di “un programma, un team”, la realt\u00e0 quotidiana era complessa a causa della competizione tra le diverse entit\u00e0, che spesso impediva ai team di superare la fase di “storming” (secondo Tuckman). <\/span> 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. <\/span><\/p>\n

2.6.2.1 Values appreciation (Apprezzamento dei Valori)<\/span><\/strong> 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. \u00c8 importante studiare e comprendere i valori legati alle culture nazionali. <\/span><\/p>\n

2.6.3. Personnel management (Gestione del Personale)<\/span><\/strong> 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. <\/span> Ha notato che le organizzazioni pi\u00f9 gerarchiche erano pi\u00f9 rigide nelle loro valutazioni. <\/span><\/p>\n

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

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

2.7.2. Cost and Finance (Costo e Finanza)<\/span><\/strong> 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. <\/span><\/p>\n

2.7.3. Procurement & Contract (Approvvigionamento e Contratti)<\/span><\/strong> Questo elemento era di competenza dei dipartimenti Infrastrutture e Operazioni delle rispettive aziende. L’autore aveva un ruolo consultivo. <\/span><\/p>\n

2.7.4. Legal (Legale)<\/span><\/strong> Gli aspetti legali erano regolati dalle entit\u00e0 operative, con due eccezioni: le certificazioni degli schemi da parte delle industrie di pagamento (Visa e MasterCard) e la conformit\u00e0 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\u00e0 PCI. <\/span><\/p>\n

2.7.4.1 Ethics (Etica)<\/span><\/strong> 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. <\/span><\/p>\n

3. Program Execution (Esecuzione del Programma)<\/span><\/strong> L’autore ha assunto il programma quando era gi\u00e0 iniziato e lo ha lasciato prima della sua conclusione, quindi non ha sperimentato personalmente l’inizio o la chiusura completi. <\/span><\/p>\n

3.1. Program and Project Start and Closure (Avvio e Chiusura di Programmi e Progetti)<\/span><\/strong> Assumendo il programma a met\u00e0 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\u00e0. <\/span><\/p>\n

3.1.1.1 Engagement & Motivation (Coinvolgimento e Motivazione)<\/span><\/strong> Il processo di onboarding<\/em> dei membri del team seguiva un processo definito, con presentazioni personali e attivit\u00e0 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\u00e0 come fattori chiave di successo. L’approccio generale era “duro ma equo”, assumendosi la responsabilit\u00e0 anche degli errori del team. <\/span><\/p>\n

3.1.2. Close-Out (Chiusura)<\/span><\/strong> 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. <\/span> La “Lessons Learned” dovrebbe essere registrata costantemente, non solo alla fine. <\/span><\/p>\n

3.2. Governance (Governance)<\/span><\/strong> La composizione dello Steering Committee (SteerCo) si \u00e8 ampliata nel tempo per includere pi\u00f9 capi unit\u00e0. <\/span><\/p>\n

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

3.2.1.1 Openness (Apertura)<\/span><\/strong> 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\u00f2 trascurare l’importanza della documentazione e della pianificazione. <\/span> L’apertura era cruciale per interagire con persone di diverse culture. <\/span><\/p>\n

3.2.2. Control & Reports (Controllo e Reportistica)<\/span><\/strong> 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. <\/span> Il controllo del business case e dei benefici \u00e8 rimasto una responsabilit\u00e0 primaria dell’autore. <\/span> Si \u00e8 notata una resistenza al cambiamento nei report da parte di alcune unit\u00e0 con forti gerarchie. <\/span><\/p>\n

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

3.4. Change and Configuration Management (Gestione dei Cambiamenti e della Configurazione)<\/span><\/strong> 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\u00e9 il programma utilizzava quelli esistenti. <\/span><\/p>\n

3.4.1. Changes (Cambiamenti)<\/span><\/strong> Il processo di gestione dei cambiamenti era gestito dal PgMO. L’autore si \u00e8 occupato principalmente di rivedere e aggiornare il business case e i requisiti di alto livello in caso di modifiche. <\/span><\/p>\n

3.5. Risks & Issues (Rischi e Problemi)<\/span><\/strong> L’autore ha riscontrato una difficolt\u00e0 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. <\/span><\/p>\n

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

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

3.5.2.1 Creativity (Creativit\u00e0)<\/span><\/strong> La creativit\u00e0 \u00e8 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. <\/span><\/p>\n

3.5.2.2 Results orientation (Orientamento ai Risultati)<\/span><\/strong> L’orientamento ai risultati \u00e8 stato applicato tramite matrici di tracciabilit\u00e0 per monitorare i progressi dei benefici dal livello del programma fino ai singoli progetti e <\/span>deliverable<\/span><\/em>. <\/span><\/p>\n

3.6. Program Culture (Cultura del Programma)<\/span><\/strong> 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. <\/span><\/p>\n

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

4. Personal Program Management Experience (Esperienza Personale di Gestione del Programma)<\/span><\/strong> 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\u00e0. <\/span> Scrivere questo studio ha aiutato l’autore a riflettere su nuovi modi per risolvere i conflitti interculturali. <\/span><\/p>\n

5. Concluding Remarks (Conclusioni)<\/span><\/strong> L’autore intende approfondire le proprie conoscenze e esperienze nella gestione di portfolio e negli aspetti finanziari dei progetti, programmi e portfolio. Ha gi\u00e0 iniziato questo percorso nella sua attuale azienda, un’importante societ\u00e0 di consulenza, occupandosi della gestione di portfolio e partecipando a workshop di finanza. <\/span> Continuer\u00e0 anche i suoi studi di psicologia. <\/span> Infine, l’autore auspica che la gestione dei progetti venga riconosciuta come una vera professione, al di l\u00e0 delle numerose certificazioni disponibili. <\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

Sfide per il Program Manager attraverso le Differenze Interculturali nel Contesto di Progetti su Larga Scala Originale in inglese: Roberto<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[201],"tags":[574,383,579,580,575,209],"class_list":["post-1746","post","type-post","status-publish","format-standard","hentry","category-management","tag-casi-di-studio","tag-differenze-culturali","tag-gestione-progetti","tag-gestione-programmi","tag-inglese","tag-ipma-level-a","comments-off"],"_links":{"self":[{"href":"https:\/\/robertogreco.eu\/biblioteca\/wp-json\/wp\/v2\/posts\/1746","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/robertogreco.eu\/biblioteca\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/robertogreco.eu\/biblioteca\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/robertogreco.eu\/biblioteca\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/robertogreco.eu\/biblioteca\/wp-json\/wp\/v2\/comments?post=1746"}],"version-history":[{"count":5,"href":"https:\/\/robertogreco.eu\/biblioteca\/wp-json\/wp\/v2\/posts\/1746\/revisions"}],"predecessor-version":[{"id":1748,"href":"https:\/\/robertogreco.eu\/biblioteca\/wp-json\/wp\/v2\/posts\/1746\/revisions\/1748"}],"wp:attachment":[{"href":"https:\/\/robertogreco.eu\/biblioteca\/wp-json\/wp\/v2\/media?parent=1746"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/robertogreco.eu\/biblioteca\/wp-json\/wp\/v2\/categories?post=1746"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/robertogreco.eu\/biblioteca\/wp-json\/wp\/v2\/tags?post=1746"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}