Gli artefatti sono, di una cultura, quel che affiora allo sguardo, in accordo con un noto modello di Schein. L’articolo suggerisce che lo stesso valga per la cultura di una comunità di pratiche, discutendo l’evoluzione in corso della cultura del Project Management a partire dalla recente riedizione dell’artefatto “Project Management Body of Knowledge”.
Premessa
Curioso il destino del termine /artificio/ e del suo derivato /artefatto/! La parola ha assunto connotazioni negative pur riferendosi all’arte, che è cosa nobilissima. Usato nel linguaggio comune come aggettivo, /artefatto/ esprime infatti la qualità indesiderabile della inautenticità.
Per il resto, come nome comune di cosa, il termine è andato in disuso, se si esclude qualche linguaggio settoriale come quelli dell’archeologia e dell’antropologia.
Sennonché, la parola ha assunto una certa utilità nelle scienze dell’organizzazione, da quando Edgar Schein l’ha usata per distinguere gli “artefatti” da altre due categorie generiche: i “valori dichiarati” (o “sposati”) e le “gli assunti di base”. Le tre categorie, disposte su tre livelli come gusci concentrici, forniscono un modello stratificato di cultura organizzativa. Come mostra la seguente mia rappresentazione del modello.
Gli artefatti sono il livello visibile e tangibile; gli assunti di base, invece, sono nascosti in profondità. Nel mezzo, ci sono i valori dichiarati che: 1) sono esplicitazione del substrato implicito e magmatico degli assunti e 2) sono matrice della superficie esterna degli “artefatti”. Dunque, per Schein, è piena di artefatti la superficie sulla quale viviamo la nostra vita nelle organizzazioni.
Analisi e interpretazione di una cultura
L’analista organizzativo à la Schein aspira a conoscere le dinamiche che fanno affiorare, dallo strato profondo e invisibile degli assunti, le cose osservabili nello strato visibile. Allo stesso tempo aspira a possedere strumenti per osservare le cose visibili dell’organizzazione e scendere, come un archeologo, negli stati profondi, per interpretare una cultura. E parlo di “interpretare” nell’accezione filosofica, perché il metodo interpretativo di analisi si presenta, come nel metodo di Schein, con caratteristiche di “circolarità ermeneutica”, vale a dire di continua e interminabile circolazione dal visibile all’invisibile, dalla superficie al profondo.
L’ermeneutica si applica non solo all’interpretazione della realtà, ma anche dei testi, dei discorsi e degli artefatti non testuali che parlano della realtà. La svolta linguistica che ha caratterizzato le scienze umane e sociali (ad esempio con la semiotica) a partire dagli anni ’60, ci ha lasciato una serie di strumenti ancora utilissimi per l’analisi e l’interpretazione di quei particolari artefatti che sono i testi e le parole che li compongono.
Il caso del Project Management Body of Knowldege
Una buona occasione per parlare di artefatti in organizzazione viene da un artefatto che riguarda oltre un milione di project manager sparsi per il mondo che condividono uno standard professionale e un corpus di conoscenze. Per loro è uscita, a luglio 2021, la nuova edizione del Project Management Body of Knowledge (PMBOK) redatto dalla comunità del Project Management Institute. Un documento che comprende lo standard e la guida all’applicazione.
La “Bibbia” dei project manager contiene, in questa edizione, un cambiamento epocale. Usiamo il caso del PMBOK, in questo numero di Prospettive in Organizzazione dedicato agli artefatti, perché consideriamo il Manuale un artefatto interessante e perché, curiosamente, nella settima edizione del documento è presente largamente il termine “artifact” (usato 138 volte in 370 pagine, con una precisa definizione e classificazione dei diversi tipi di artefatti). Nella sesta edizione la parola era più rara e usata in termini generici (49 occorrenze in 976 pagine). Nelle edizioni precedenti il termine era quasi assente.
Se le parole sono attaccate come etichette alle idee e “le idee hanno delle conseguenze”, come ha scritto George Akerlof citando Milton Friedman in un libro sull’economia dell’identità, è anche vero il contrario, che le parole sono conseguenze di una cultura e di un’identità. E dunque, forzando il ragionamento di Akerlof, l’introduzione di una nuova parola in una comunità è segno di un cambiamento non solo culturale ma anche d’identità. In questo caso, come nel caso dell’uso della parola “artifact” negli studi organizzativi da parte di Schein, il neologismo non è lessicale (una parola completamente nuova) ma semantico (una parola esistente usata in modo nuovo). In ogni caso, ogni neologismo, lessicale o semantico, prodotto intenzionalmente è un artefatto ed è frutto di una cultura. Come è un artefatto la parola /artefatto/ usata da Schein o nel manuale del Project Management.
Come è giunto al PMBOK il neologismo semantico “artifact”?
La parola viene al project management dall’ingegneria del software. Quella è la matrice culturale e la cosa è interessante perché evidenzia il caso di due culture limitrofe che condividono in modo crescente certi assunti, certi valori e, come vedremo, certi artefatti.
La cultura del project management è nata prima di quella dell’ingegneria del software, nell’ambito della costruzione di impianti, opere civili e sistemi di difesa. E’ una cultura che si identifica, da circa 50 anni, in un corpus di conoscenze condivise (Body of Knowledge). La cultura tradizionale del project management è caratterizzata da un modo di lavorare basato su fasi in sequenza, l’una preliminare all’altra: progettazione, validazione, costruzione. Un modo di lavorare “a cascata” (waterfall) che da circa 25 anni ha cominciato a mostrare sintomi di inadeguatezza nel fronteggiare il progresso tecnologico e le sfide della competizione. Una crisi che si è manifestata da una parte nell’ingegneria di sistemi sempre più complessi per l’aerospazio e la difesa, dall’altra nell’ingegneria di sistemi software costituiti da una enorme quantità di “moduli” sviluppati e integrati fra loro da una moltitudine di analisti/sistemisti programmatori.
Nelle due tipologie di settori si affermavano metodologie di sviluppo di nuovi prodotti caratterizzate dalla capacità di:
- trattare un numero smisurato di requisiti da soddisfare, a volte tra loro contrastanti e mal definiti in fase iniziale
- abbreviare il time to market rendendo parallele alcune fasi col superamento della logica a cascata
- Validare con il cliente il prodotto in corso d’opera, il più precocemente possibile e su sottosistemi, evitando di lavorare fino alla validazione finale su requisiti non ben specificati
Da una parte il cosiddetto “Systems Engineering”, dall’altra lo sviluppo “Agile” del software, incarnavano lo spirito “lean” dei tempi, guidato dal principio di non far nulla che non abbia valore accertato per il cliente o lo stakeholder e far tutto nel momento opportuno. L’essenza dell’essere “customer driven”.
Nella comunità dei project manager nasceva dunque la consapevolezza che gli strumenti di pianificazione, di esecuzione e controllo e il modo di lavorare tradizionale non erano più al passo coi tempi. Ovvero, rimanevano molto efficaci per alcuni tipi di progetti ma non si adattavano alla maggiore agilità strategica e organizzativa richiesta in certi campi. Al tradizionale “Body of Knowledge” adatto al waterfall, si aggiunsero, come allegati, linee guida e integrazioni per le metodologie “agili” basate su una frequente iterazione del ciclo di sviluppo e validazione lungo tutto il Project Lifecycle (ma anche del Product Lifecycle).
Una rivoluzione culturale ma anche di identità professionale
Nel luglio 2021, con la settima edizione del PMBOK, la transizione timidamente auspicata verso un modello più largamente applicabile nell’attuale contesto competitivo si traduce in una piccola “rivoluzione culturale”. Con tutti i turbamenti che una rivoluzione porta con sé.
Se il “vecchio” standard condiviso (una sorta di Bibbia) era fonte di un “guadagno” di identità (nell’accezione di Akerlof), il nuovo standard, prima annunciato e poi pubblicato, diventava probabilmente latore di una parziale “perdita” di identità. Trattandosi di un fatto recentissimo, non ci sono ancora ricerche su questo fenomeno. L’esistenza di un “libro sacro”, linea guida e oggetto della prova d’esame per acquisire la credenziale di “Project Manager Professional” (PMP), mi fa pensare ad un artefatto con forte capacità di generare identità.
Cosa cambia nella cultura del project management col nuovo standard?
Nel nuovo documento si prende atto che alcuni progetti vanno gestiti a cascata e altri in modo iterativo e si crea una “struttura di alto livello, come fatto dall’ISO (International Standards Organization) per i sistemi gestionali normati. Al livello superiore di astrazione, il documento fornisce una linea guida sia per i progetti (e i project manager) che usano un approccio waterfall, sia per quelli che usano un approccio iterativo-incrementale. Il salto ad un livello logico più astratto e generale è fatto abbandonando il punto di vista particolare dei processi (49, individuati per ciascun ciclo di progetto e raggruppati per gruppi di processi, nelle edizioni precedenti del PMBOK) e individuando invece un set di 12 “principi”.
Il salto di astrazione dal livello “processi” al livello “principi” corrisponde ad una visione “dall’alto” del campo di gioco, per la quale, indipendentemente dalla metodologia utilizzata è meno importante il “cosa” e il “come” si fa ed è più importante il “perché” si fa, letto nell’ottica del cliente e, più in generale, degli stakeholder. Se la precedente edizione del Body of Knowledge induceva a pensare che il successo del project manager fosse legato alla conformità dell’output e che questa fosse garantita dalla diligente esecuzione dei processi di project management, l’edizione nuova si concentra sugli outcome del progetto.
Nel concetto di outcome è compreso il contributo agli obiettivi di business, al successo del cliente e, più in generale, alla soddisfazione degli interessi degli stakeholder. Insomma, non è più importante per il Project Manager sapere esattamente quali gruppi di processi sia prescritto gestire, come e con quali strumenti, ma usare processi, metodologie e strumenti idonei a dare al cliente il modo di trarre valore da quanto gli è stato consegnato.
L’ottica del nuovo standard si riflette anche in un altro grande cambiamento della guida. L’edizione precedente era organizzata per “aree di conoscenza” e quella attuale per “domini di performance”. Nella precedente suddivisione si diceva: per gestire bene i 49 processi di Project Management devi sapere queste cose riguardo la pianificazione e gestione delle attività da svolgere, dei tempi, dei costi, delle risorse umane, dei rischi, della qualità, della comunicazione, degli stakeholder e degli acquisti. Nell’attuale versione si prende atto che possedere un set di conoscenze non è condizione sufficiente per la performance e che quindi è meglio dare più enfasi direttamente alla performance che le conoscenze e le competenze possono sviluppare. Tra l’altro la performance è più misurabile del possesso di conoscenze. Le conoscenze saranno approfondite in documenti ad un livello più basso di astrazione.
Perché entrano nel PMBOK gli “artefatti”?
In chiave linguistica, vediamo innanzitutto il livello denotativo, cioè cosa, nel PMBOK, è considerato un artefatto.
Sono “artefatti” alcune vecchie conoscenze dei Project Manager, ad esempio: il Business case, il Project Charter, il Risk Register, il Project Management Plan, la Work Breakdown Structure, la Organization Breakdown Structure, la Baseline, la curva ad S, il diagramma di Gantt e la Matrice di assegnazione delle responsabilità (RAM). Come sa ogni PM, non c’è un modo univoco e standardizzato di fare ciascuno di questi “artefatti”, tra loro molto diversi. Quello che li accomuna è che ciascuno corrisponde ad un output documentale da redigere, conservare e distribuire a specifici attori del progetto. La produzione di un artefatto risponde ad esigenze varie: 1) di facilitare il processo che, a partire da una raccolta di input, supporta le fasi di apertura, di pianificazione, di esecuzione, di controllo e di chiusura di un progetto; 2) di comunicare con uno strumento intellegibile da tutti i destinatari; 3) di lasciare traccia del processo svolto.
Abbiamo elencato una quindicina di artefatti già presenti nelle vecchie edizioni del PMBOK, anche se non venivano chiamati così. Il nuovo manuale ne elenca 76, alcuni tipici della gestione “waterfall” e alcuni della gestione “agile” (ad esempio le “user story”), alcuni tratti da altri domini del management (il management della qualità e degli acquisti, ad esempio).
L’elenco non vuole essere esaustivo perché si lascia al PM libertà di utilizzare altri artefatti o sviluppare gli artefatti che gli servono in base al progetto. Inoltre il documento, essendo di “alto livello” (in termini d’astrazione), non spiega come redigere gli artefatti.
E qui subentra al livello denotativo il livello connotativo: la parola suggerisce l’idea del “fatto ad arte” e la necessità di un’intelligenza contestuale e artigianale (e non burocratica) del PM. Qualcosa che richiama alla mente dei compassati project manager con la cravatta e le matite nel taschino, l’ingenium creativo dei giovani geek del software, che lavorano in pantaloncini e sandali. La parola /artefatto/, importata nel Body of Knowledge, suggerisce un nuovo modo di lavorare, ma anche uno spirito e uno stile diverso. Coerente con i 12 principi guida.
Viene specificato nel PMBOK, e questo può interessare anche i “non PM”, che un artefatto è un output (di un processo). Se l’output di un progetto è una serie di cose da consegnare (deliverables) correttamente consegnate (delivered), un artefatto è, invece, un elaborato che serve internamente per far funzionare i processi di project management nello sviluppo dei prodotti.
Il concetto non nasce, come dicevamo, nella cultura del project management ma in quella dello sviluppo software. Magari per far funzionare bene il processo di creativo e co-creativo saranno artefatti utili anche un biliardino vicino alla macchinetta del caffè, i pantaloncini e i sandali, le pareti a colori vivaci con ampie superfici su cui scarabocchiare e mettere post-it.
Gli “artifacts” nello sviluppo del software
Nell’ingegneria informatica è definito artifact un by product dello sviluppo del software. Nel ciclo di vita dello sviluppo software, l’artefatto di solito si riferisce non al prodotto ma a “cose” prodotte dalle persone coinvolte nel processo.
Una volta che tutti gli artefatti iniziali sono stati redatti, un team di sviluppo può iniziare a programmare e costruire il prodotto vero e proprio. Durante questo processo, possono essere sviluppati ulteriori artefatti. Questi possono apparire in qualsiasi momento e includere qualsiasi cosa, da appunti a nuovi schemi a casi d’uso.
Ciò che, grazie alla matrice comune, è passato dall’industria del software al project management è che anche la dimensione gestionale dello sviluppo dei prodotti, così come la dimensione tecnica, ha bisogno di artefatti. Dunque il classico project management plan, il business case, il risk register vengono classificati come “artefatti” anche nel linguaggio di un project manager che costruisce edifici o ponti. Così come nessun software è completo senza una serie di artefatti, così nessun prodotto consegnato da un project manager è completo senza certa documentazione, senza artefatti.
Esiste una cultura della comunità del Project Management?
Il modello di Schein si riferisce alla cultura di un’organizzazione. Non risulta un’applicazione del modello a una comunità professionale o di pratiche. L’ipotesi che possa identificarsi una cultura della comunità di PM è alla base dello sforzo che qui è stato fatto per interpretarne gli artefatti. L’ipotesi si può articolare in due parti: 1) che esista una comunità di pratiche nel caso dei PM e 2) che tale comunità esprima, oltre a delle conoscenze condivise, una cultura identificabile e identitaria. Lo stesso si può dire per la comunità degli sviluppatori software. Se e solo se questi due assunti sono verificati sia per i PM che per i softwaristi, possiamo parlare di una fusione che traspare dall’adozione di artefatti comuni.
La difficoltà di utilizzare il costrutto di “comunità di pratiche” è che questo risale a studi collocati nell’area del Knowledge Management o dell’apprendimento organizzativo. Laddove ci si focalizza, più che sulla cultura, sulle conoscenze tipiche di una certa comunità professionale e sui modi di trasferimento di tali conoscenze. D’altra parte il documento “identitario” della comunità dei PM è un “Body of Knowledge”. Si parla in quel caso di conoscenze ma non di tratti culturali che si esprimono in assunti di base, valori e artefatti. Che la mancanza stia per essere colmata è osservabile dalla struttura “per principi” dell’ultima edizione del PMBOK: un “principio” attiene a una “cultura” molto più di uno standard di processo.
E’lodevole quanto infruttuoso, però, lo sforzo di trovare intersezioni tra la ricerca sulle comunità di pratiche e quella sulle culture organizzative, come notano Anzela Huq, Jawwad Z. Raja e Duska Rosenberg (2006).
Evidenzia bene il filone “critico” all’interno della letteratura sul project management un lavoro di Bellini e Canonico sulle comunità di Project Manager (2008). I ricercatori critici, secondo i due autori, propongono una nuova visione del project management in cui l’unità di analisi è diventata la questione della socialità, in qualche modo spingendosi a monte della questione della gestione della conoscenza e dell’apprendimento, verso le dinamiche sociali che sono certamente attinenti alle culture.
Nell’articolo di Bellini e Canonico si evidenzia quanto la gestione del progetto abbia a che fare intrinsecamente con i meccanismi della conoscenza ma anche del substrato culturale. “Poiché (a) La conoscenza non è la rappresentazione di una realtà oggettiva, ma è un’interpretazione (quindi una costruzione) di essa; (b) La creazione di senso collettivo spinge le organizzazioni prima a stabilire la verità delle dichiarazioni di conoscenza, e poi a organizzare il consenso di una comunità rilevante”.
Potremmo affermare che una cultura che abiliti certe modalità di apprendimento e di trasferimento della conoscenza, ad esempio una cultura più informale (come quella dei programmatori, caratterizzata, ad esempio, dai sandali, dall’uso di Twitter mentre si lavora e da certi artefatti di comunicazione) potrebbe facilitare la condivisione della conoscenza e quella formale (come quella dei vecchi PM, che usano mocassini lucidi, l’intranet aziendale ed altri artefatti) potrebbe ostacolarla.
Che le organizzazioni non siano monoculturali ma composte da culture diverse è una circostanza ampiamente studiata per le imprese internazionali che hanno una composizione multi-etnica. La multiculturalità è una sfida ben identificata negli studi di cross cultural management. Appare meno esplorata, invece, la dimensione dell’inclusione e dell’integrazione di culture professionali diverse (quella degli HR, dei tecnici, dei manager, dei commerciali ecc.), soprattutto quando la cultura di queste professioni si sviluppa anche al di fuori della propria organizzazione, come nel caso dei project manager che fanno riferimento ad una specifica comunità professionale, dotata non solo di specifiche conoscenze e competenze ma anche di specifici tratti culturali (assunti, valori, artefatti).
Il presente articolo vuole stimolare, col caso del nuovo PMBOK del PMI e di nuove “parole chiave” in esso contenute, una riflessione e ulteriore ricerca su questa tipologia di problemi.
Conclusioni
Il nuovo PMBOK chiama artefatto (del tipo “visual data and information”) il diagramma causa-effetto che viene dalla cultura del Total Quality Management e chiama ugualmente artefatto (del tipo “agreements and contracts”) il Memorandum of Understanding (MOU) che viene dalla cultura degli acquisti. Ma se chiamassimo “artefatto” un diagramma causa-effetto tra i professionisti della qualità susciteremmo ilarità, se chiamassimo “artefatto” un MOU tra i professionisti degli acquisti susciteremmo il sospetto che il documento nasconda qualche imbroglio.
Il “prestito” ai project manager, dal linguaggio dell’ingegneria del software, della parola “artefatto” può essere interpretata in chiave di standardizzazione. Vale a dire alla luce di quella cultura tecnica e ingegneristica che ha da sempre la standardizzazione alla base del successo dei suoi processi di progettazione ed esecuzione. La standardizzazione ha la capacità di facilitare l’interfaccia e l’integrazione tra le parti e tra le attività.
Abbiamo provato, con questo contributo, a sussumere senza esitazione nella cultura aziendale la cultura tecnica e ingegneristica e trattare il caso di studio della pubblicazione del nuovo PMBOK alla luce del modello di Schein di analisi della cultura organizzativa.
Riflettendo sulla funzione del nuovo PMBOK, abbiamo anche proposto all’attenzione un certo tipo di artefatti, che nella cultura dei sistemi gestionali normati si chiama High Level Structure (HLS): documenti che, spostandosi dal punto di vista dei processi a quello dei principi, sono artefatti di integrazione culturale. Ad esempio un HLS sviluppato da ISO uniforma e allinea a un livello più alto le culture degli specialisti dei sistemi della qualità, di quelli della sicurezza, di quelli della responsabilità sociale, di quelli della sostenibilità ambientale, eccetera.
Nell’articolo, abbiamo anche provato a toccare il tema dell’identità professionale nel quadro di un più ampio del concetto di identità così come è stato formulato da Akerlof. L’identità (fatta anche di artefatti utilizzati) come fonte di “guadagno” e lo sfocamento dell’identità, invece, come fonte di “perdita”.
Riteniamo questo un promettente campo di ricerca. E pensiamo che le comunità professionali, come quella dei project manager, possano dare un accessibile e numeroso campione per un’indagine quantitativa.
Crediamo che nel nuovo Body of Knowledge dei PM, oltre al desiderio di adeguare alla competizione il “way of working” (che in alcuni documenti viene abbreviato con WoW, in uno nuovo stile più “giovanile”), ci sia anche un tentativo di svecchiare progressivamente la cultura della comunità di pratiche e la professione del Project Manager. Non escludo che, dagli assunti di base della comunità, emerga la volontà di attrazione di giovani alla professione, alla membership e alla certificazione e che questo si sia tradotto in nuovi valori dichiarati nella comunicazione dell’Associazione. Non mi sembra casuale che nel 2020 si sia trasformata l’identità visiva del PMI utilizzando una grafica più “fresca” e che parte dei contenuti del PMBOK si stia trasferendo in forma multimediale sul sito web dell’Associazione.
La figura in cui ho mostrato la crescente sovrapposizione della cultura del Project Management e quella del Software Development potrebbe essere letta in chiave di “mashup” culturale. Probabilmente molte aziende stanno attivamente lavorando nel rinnovare la propria cultura per renderla più attrattiva per le ultime generazioni. Generazioni che hanno la cultura del remix e del mashup che le generazioni precedenti forse non avevano.
Questo svecchiamento potrà mettere in crisi aziende incapaci di trasformarsi. Perché non basta adottare, in superficie, artefatti “trendy” come un biliardino negli uffici, un dress code molto disinvolto, un nome “figo” per un documento o una riunione. Schein ci dice che, nella trasformazione culturale, devono cambiare, oltre agli artefatti e prima di essi, gli assunti di base e i valori dichiarati. E questo è un viaggio molto lungo e impegnativo.
Bibliografia
Schein, E. H. (1992). Organisational culture and leadership, Jossey-Bass Publishers, San Francisco.
Akerlof, G.A., Kranton, R.E. (2011), Identity Economics: How Our Identities Shape Our Work, Wages, and Well-Being, Princeton University Press
Project Management Institute Inc, The Standard for Project Management and a Guide for Project Management Body of Knowledge (PMBOK Guide), Seventh Edition, 2021
Huq, A., Raja J. Z., Rosenberg, D. (2006) Linking organisational culture and communities of practice, January. In book: Encyclopedia of Communities of Practice in Information and Knowledge Management.
Bellini, E ., Canonico P. (2008). Knowing Communities in Project Driven Organizations Analysing the Strategie lmpact of Socially Constructed HRM Practices. lnternational Journal of Project Management (IJPM) 26 (2008) 44-50.
