Foto di Gabriel Sollmann su Unsplash

Consapevolmente o inconsapevolmente?

In realtà, non c'è niente di peggio per gli stakeholder, come i clienti o i committenti, quando non sanno cosa sta succedendo nel progetto, qual è lo stato attuale e come stanno andando le cose, oppure si parla di molte cose e non c'è la possibilità di verificare i risultati raggiunti.

Solo raramente vedo progetti che vengono deliberatamente tenuti segreti per un certo periodo di tempo. Questa soluzione può essere scelta nei progetti di ristrutturazione in cui si esaminano diversi scenari e la segretezza ha lo scopo di evitare temporaneamente inutili confusioni e voci all'interno dell'organizzazione. Ma attenzione, non si può non comunicare. Anche in questo caso, un minimo di trasparenza è utile. In molti casi, le voci aumentano quando qualcosa è segreto.

Inoltre, ci sono progetti in cui la trasparenza è deliberatamente mantenuta bassa, in modo che non ci sia un presunto controllo "esterno" e una guida esterna. Personalmente, non credo che sia una buona idea. Perché i progetti non sono fini a se stessi, ma sono fatti per clienti e committenti con i quali si vuole perseguire una comunicazione di fiducia. E la trasparenza crea fiducia! Nella stragrande maggioranza dei progetti, la mancanza di trasparenza non è un atto consapevole, ma una conseguenza della complessità e del ritmo frenetico del progetto; in molti casi è anche il segno di un certo sovraccarico temporale o tecnico. La trasparenza non manca del tutto, ma di solito è insufficiente.

Come si crea la trasparenza?

Il problema della mancanza o dell'insufficiente trasparenza è la complessità di un progetto. Tutto è collegato in qualche modo. Ad esempio, se una decisione necessaria al comitato direttivo del progetto non viene presa entro un certo periodo di tempo, ciò comporta dei ritardi nel progetto. I ritardi hanno un impatto sulla disponibilità del personale, e il nuovo personale potrebbe dover sostituire quello esistente, con conseguente aumento del lavoro. Se non è disponibile un sostituto interno, è necessario ricorrere a specialisti esterni, il che comporta costi aggiuntivi per l'acquisto e l'integrazione, che a loro volta comportano costi aggiuntivi nel progetto. Le dipendenze sono molto grandi in un progetto e possono portare a tutta una serie di problemi.

Creo principalmente trasparenza con l'uso di strutture (chiamate anche strutture di progetto o strutture di ripartizione del lavoro WBS). Mi sembra che le strutture siano passate in secondo piano, soprattutto nel mondo agile, sebbene anche Scrum, SAFe e altri utilizzino strutture chiare. Le strutture riducono la complessità e si concentrano su un argomento più ristretto. Ecco perché i libri nelle biblioteche, ad esempio, non sono ordinati solo in ordine alfabetico, ma anche per argomento. Le strutture possono essere presentate in modo gerarchico, sotto forma di matrici e reti e integrate con raggruppamenti e relazioni. In questo contesto, le strutture non sono una divisione o una suddivisione del progetto, che non è possibile a causa della suddetta interconnessione e delle dipendenze all'interno del progetto. Le strutture sono modi di vedere e assegnare il progetto.

Consiglio di non reinventare la ruota, ma di utilizzare riferimenti collaudati per le strutture. Faccio una distinzione tra gestione del progetto (PM) e sviluppo del prodotto. Se non viene specificato altro, personalmente utilizzo la metodologia PM PMI PMBOK Guide per la prima. Per molti anni ho utilizzato le dieci cosiddette Aree di conoscenza come struttura principale. Con l'ultima edizione, la settima, della Guida al PMBOK, queste Aree di conoscenza, insieme alle fasi del progetto nel 2021, sono state trasformate in Domini di performance del progetto, che mi piacciono ancora di più. Questi sono:

• Gli stakeholder
• Squadra
• Approccio allo sviluppo e ciclo di vita
• Pianificazione
• Progetto di lavoro
• Consegna
• Misurazione
• Incertezza

Ma anche le vecchie aree di conoscenza continuano ad avere la loro giustificazione. Naturalmente, si possono utilizzare anche le strutture di altri metodi PM. Oltre al valore comprovato di un metodo, mi dà la certezza di raggiungere l'equilibrio tematico e la completezza del progetto con questa struttura. Con un metodo generalmente conosciuto, posso presumere che anche le parti interessate comprendano e accettino le strutture.

Nel processo di sviluppo del prodotto, utilizzo sempre prima la struttura del risultato (struttura del prodotto) nel senso della WBS e poi integro le fasi/task del processo. In questo modo ottengo un approccio orientato al risultato, in cui prima si definisce cosa deve essere raggiunto e poi come può essere raggiunto. Purtroppo, ci sono ancora progetti che sono strutturati al contrario, in base alle fasi di sviluppo del progetto (ad esempio, progettazione, costruzione, test), il che porta sempre a problemi.

In sostanza, la struttura applicata non deve essere di per sé troppo complicata, nello spirito di Albert Einstein: "Il più semplice possibile, ma non più semplice".

Come si applicano queste strutture?

Una volta trovata e implementata una struttura adatta al progetto, il progetto viene controllato attraverso questa struttura. Solo l'uso coerente e ricorrente della struttura nel progetto porta alla trasparenza e alla familiarità desiderate e crea fiducia. Spesso osservo che le strutture, pur essendo state implementate, si diluiscono nel corso del progetto, se ne aggiungono di nuove e se ne tralasciano altre. Questo porta a un miscuglio di strutture diverse e la trasparenza ne risente. Uso la struttura scelta (principale) ogni volta che è possibile per tutto il progetto. Ogni elemento strutturale contiene numerose sottostrutture, che possono essere adattate alle esigenze specifiche. Di conseguenza, pianifico e gestisco il progetto in base a questa struttura e comunico in base a questa struttura. Un rapporto mensile sullo stato del progetto, ad esempio, è concepito esattamente secondo questa struttura. Anche il cockpit del progetto ha esattamente questa struttura.

È consigliabile verificare le strutture dopo l'implementazione e poi di tanto in tanto per vedere se sono davvero comprese e accettate, e se sono ancora adatte al progetto, che può anche cambiare. Se così fosse, dovrebbero essere adattati all'interno della metodologia. Tuttavia, questo non dovrebbe accadere troppo spesso e troppo spesso, poiché le strutture sono un elemento fondamentale del progetto in cui le modifiche possono avere un grande impatto e confusione.

Ciò comporta un notevole lavoro e impegno per il project manager, che purtroppo non sempre viene percepito come tale dall'esterno. Non viene naturale e deve essere applicata e mantenuta attivamente. Ma è un ottimo investimento, che vale la pena di fare.

Le strutture del progetto vanno sempre di pari passo con i dati del progetto. Tutti i dati del progetto devono essere allineati alla struttura, cioè assegnati agli elementi strutturali. Uno strumento di gestione dei progetti con un database centrale è molto utile in questo caso. Ciò consente al progetto di avere in qualsiasi momento diverse visioni dell'intero progetto e di tutti i dati del progetto. Quando si utilizzano singoli documenti (ad esempio per i costi, la pianificazione, le risorse), la generazione di viste generali richiede molto più tempo, è inefficiente e talvolta non è nemmeno possibile. Al contrario, uno strumento di PM di questo tipo è molto meno utile se nel progetto non viene memorizzata una struttura adeguata.

Conclusione

Nonostante le strutture, ci sono ancora problemi nel progetto e ce ne saranno sempre. Tuttavia, grazie alla trasparenza creata dalle strutture, i problemi possono essere identificati precocemente, le cause individuate e quindi affrontate e risolte in modo sostenibile. Come già detto, la trasparenza del progetto crea fiducia tra le parti interessate, sia all'interno che all'esterno del progetto. La fiducia garantisce una collaborazione migliore e più costruttiva, che è anche più divertente per tutte le parti coinvolte e, in ultima analisi, porta a risultati migliori.