5 Qualità indispensabili dei Top Project Manager

Ascolta la versione audio di questo articolo

Essere un PM di punta ti fa risaltare e se sei riconosciuto come un PM di punta, sarai molto richiesto. Gli stakeholder si fideranno di più di te, vorranno lavorare con te e ascolteranno di più i tuoi consigli. Qualunque cosa tu stia aiutando a costruire, i migliori PM sono sempre richiesti nelle organizzazioni di tutto il mondo. Questo è un elenco di alcune qualità chiave dei migliori project manager. Si spera che ti aiutino a diventarlo o a controllare se hai già queste abitudini a tua disposizione.

1. Costruire la fiducia all'interno del tuo team

La fiducia è un aspetto importante di ogni squadra. Se ne parla e si scrive spesso, ma raramente si vede in azione quando si tratta di gestire un progetto. L'importanza della fiducia nel processo di gestione del progetto è stata persino riconosciuta da una varietà di diverse organizzazioni di gestione del progetto.

L'International Project Management Association ha appena incluso sezioni sulla fiducia nella loro certificazione ICB4, che è lo standard globale per le competenze individuali nella gestione di progetti, programmi e portafogli.

Allo stesso modo, i Tre Pilastri dell'Empirismo di Scrum sono stati a lungo basati sull'idea che la fiducia è uno dei tre fattori più importanti per mantenere il controllo del progetto empirico. La stessa tendenza alla creazione di fiducia è presente in LEAN e in altre metodologie tradizionali di gestione dei progetti. Se questo è stato un argomento così urgente per così tanto tempo, quali sono i principali ostacoli che impediscono ai PM di stabilire una vera fiducia all'interno dei loro team?

Una delle risposte più ricorrenti a questa domanda è "cultura della colpa". Una chiave per raggiungere la cultura della fiducia è migrare lontano da questa cultura e invece spostare ogni errore in un'opportunità di apprendimento.

Affinché ciò diventi realtà, i PM dovrebbero facilitare il giusto ambiente di trasparenza e comfort all'interno dei loro team, poiché la maggior parte delle persone si comporta molto meglio in un ambiente in cui i membri del team sono in grado di esprimersi e commettere errori.

Un importante PM insegna al proprio team questi principi con l'esempio vivendo al loro fianco, incoraggiando a condividere i propri errori e trasformandoli in esempi per l'apprendimento. I migliori PM si rendono conto che mostrare umiltà e vulnerabilità è un segno di forza. Soprattutto quando si tratta di ammettere i propri errori, è spesso vero che le persone tendono a mettersi sulla difensiva o a scaricare la colpa. Spiegare che hai commesso un errore e perché può farti sentire vulnerabile, ma se ammetti apertamente e analizzi questi errori, questa abitudine aiuterà gli altri a evitarlo in futuro e aiuterà tutti a creare fiducia e ad aprirsi ai propri errori . Ad esempio, se prometti troppo a uno stakeholder chiave di finire un traguardo prima del possibile, a causa della mancanza di profondità tecnica che avevi su quell'argomento, accetta di ammettere il tuo errore al team e di fargli sapere che hai sottovalutato le cose piuttosto che incolpare loro per non aver fornito la tecnologia alla velocità desiderata. Questo può ispirare gli altri ad aprirsi e costruire connessioni più forti con te e i loro compagni di squadra.

Comprendi i membri del tuo team: le loro capacità, paure, frustrazioni, cosa gli piace o non piace e come interagiscono con le altre persone. Quando i membri del team si sentono apprezzati, forniranno valore più facilmente. Trova dei modi per motivare il tuo team con il compito da svolgere invece di spingerlo con forza verso i tuoi obiettivi. Per fare ciò, delinea chiaramente quale sia il successo per il progetto e i ruoli e le responsabilità del team di progetto, ma poi lascia che siano esperti nei loro campi. Aspettati che i membri del tuo team ti dicano cosa deve essere fatto. Ascoltali, decentralizza il processo decisionale per potenziare il tuo team, ma preparati a prendere decisioni difficili quando necessario.

Dopotutto, il tuo team è lì per te con cui interagire. Troppi PM commettono errori tuffandosi direttamente nella scrittura di compiti e assumendosi troppe responsabilità da soli. Questo a volte accade a causa della mancanza di fiducia e comprensione all'interno di quei team. Quando hai la fiducia del tuo team, assicurati che siano coinvolti nell'analisi del lavoro, nella scrittura delle storie degli utenti e in generale nel darti consigli sulle questioni che ritengono importanti.

I migliori PM si rendono conto che il loro team è la loro migliore risorsa e coglieranno ogni opportunità per costruire solide relazioni con loro. Sii negoziatore e facilitatore, ma prima di tutto sii tutt'uno con la squadra. Hanno bisogno di sentirsi come se stessi lavorando con loro e non per qualcuno al di sopra. Questo è un precursore di alcuni dei suggerimenti più tecnici in questo articolo, poiché, senza questa fiducia, il tuo progetto probabilmente incontrerà una serie di problemi.

Key Takeaway: “Va bene mostrare che tutti commettono errori. Condividi i tuoi errori quando li commetti, mostra alla tua squadra che sei dalla loro parte e rendi la fiducia all'interno della tua squadra una priorità".

2. Coinvolgere le parti interessate affinché forniscano loro ciò di cui hanno veramente bisogno

Come PM, probabilmente sei ben consapevole del fatto che molti progetti software finiscono per fornire qualcosa di diverso da ciò che le parti interessate desideravano o avevano bisogno. Questo problema è dovuto a molti fattori diversi e ha generato tutta una serie di nuove metodologie che cercano di risolvere questo problema.

Tuttavia, anche nell'era dello sviluppo Agile, a volte cadiamo ancora nella trappola di costruire la cosa sbagliata. L'analisi delle parti interessate è essenziale ma spesso inizia con la domanda sbagliata. Senza porsi la domanda “Perché lo stiamo facendo?”, molti progetti vengono avviati e definiti in modo errato, cadendo nella trappola della costruzione verso una soluzione che non ha mai affrontato la reale esigenza aziendale.

Insieme a "perché", i massimi PM devono chiedere un seguito di "a chi?" Quali stakeholder stiamo supportando, al fine di fornire la soluzione, per coprire il loro "perché?"

È qui che un importante PM riconosce un'importante distinzione. La soluzione può essere definita come output o deliverable, ma un PM di alto livello comprende che qualsiasi soluzione in sé non coprirà necessariamente l'esigenza aziendale originale. Ad esempio, se le parti interessate pensano che la loro esigenza aziendale sia quella di implementare un sistema ERP, il PM deve aiutarli a scoprire la reale esigenza aziendale dietro l'utilizzo di una soluzione come ERP. L'ERP stesso è una soluzione, non un'esigenza aziendale.

Riconoscere la vera esigenza aziendale richiede una profonda comprensione del contesto e delle parti interessate, dei loro atteggiamenti, livello di potere o influenza, livello di interesse, il loro impatto sul progetto, l'impatto del progetto su di loro, le loro preoccupazioni e, naturalmente, cosa accetteranno come il successo di un progetto.

Pertanto, al fine di rendere i progetti più efficaci nel raggiungimento del loro scopo﹣creare soluzioni che incidono sugli obiettivi di business﹣ le responsabilità del project manager si espandono oltre la creazione della soluzione stessa, fino a dove le soluzioni entrano in gioco, misurando chiaramente se il valore effettivamente prodotto è allineato con gli obiettivi attesi nella definizione dell'obiettivo.

I PM dovrebbero sempre tenere a mente che i reali vantaggi della realizzazione del progetto durante l'intero processo devono essere allineati alle reali esigenze, obiettivi e obiettivi aziendali.

Troppo spesso, gli obiettivi aziendali vengono dimenticati nel bel mezzo dello sviluppo e dei cambiamenti dei requisiti. Spesso i progetti finiscono per fornire prodotti funzionali, che risolvono alcune, ma non tutte, reali esigenze aziendali che inizialmente hanno spinto lo sviluppo del prodotto in primo luogo. Ciò può essere evitato se le parti interessate sono gestite correttamente e presentate spesso le iterazioni del prodotto.

I migliori PM riconoscono anche il loro ruolo nella guida del progetto, e quindi non si aspettano che le parti interessate comunichino tutti i requisiti all'inizio del progetto. Capiscono che alcune parti interessate non sempre sanno come articolare i propri bisogni, ed è loro compito aiutare le parti interessate ad articolare le proprie esigenze, dall'elicitazione dei requisiti, fino alla consegna del progetto. È anche importante ricordare che durante il processo di elicitazione dei requisiti dobbiamo suscitare non solo i requisiti dagli stakeholder, ma anche le loro preoccupazioni.

Ad esempio, nelle organizzazioni meno mature si verifica spesso un paradosso interessante all'inizio di nuovi progetti. Durante la fase di inizializzazione del progetto, il team di sviluppo si aspetta che le parti interessate identifichino chiaramente tutti i requisiti e le esigenze per la soluzione per la quale svilupperanno. Allo stesso tempo, le parti interessate si aspettano che il team di consegna fornisca stime accurate sia in termini di tempo che di costo.

Tuttavia, proprio all'inizio dell'ambito del progetto, c'è troppa incertezza per definire queste stime e, così facendo, c'è il pericolo di creare stime non realistiche. A volte, le parti interessate includono il maggior numero possibile di requisiti, per far fronte all'incertezza di una soluzione attualmente meno tangibile. Nel frattempo, il team di consegna fornisce una stima molto approssimativa per l'ignoto.

Il risultato di ciò sarà molto probabilmente una soluzione che otterrà solo il 20% del suo pieno fabbisogno utilizzato dagli stakeholder. Il resto sarà sviluppato senza un obiettivo chiaro in mente, rendendo il progetto fuori budget e anche fuori programma.

Fortunatamente, i migliori PM sanno esattamente come coinvolgere gli stakeholder e guidarli attraverso ogni fase del mondo VUCA (volatilità, incertezza, complessità e ambiguità) del loro progetto. I project manager sono in grado di scomporre il progetto in incrementi più tangibili e coinvolgere gli stakeholder mentre creano e riesaminano attivamente gli apprendimenti.

Il punto chiave qui è: "Le soluzioni sono costruite per risolvere le esigenze aziendali, i PM devono assicurarsi che questo obiettivo non venga mancato quando il progetto viene creato. Assicurati che i tuoi stakeholder vogliano costruire le cose giuste, impegnandoti con loro per affrontare le loro esigenze e preoccupazioni principali".

3. Rendere la gestione del rischio di progetto un esercizio organico

La maggior parte dei progetti presenta una serie di rischi generici che vengono visualizzati all'inizio dell'inizializzazione del progetto.

Quasi tutti i progetti iniziano con questi rischi generici, inclusa la resistenza degli utenti al cambiamento, la mancanza di risorse e la tecnologia immatura, solo per citarne alcuni. I migliori PM impegnano i loro team a identificare non solo i rischi comuni, ma anche i rischi più urgenti e unici, in modo tale che l'identificazione dei rischi sia un riflesso durante tutto il ciclo di vita del progetto, non un compito umile all'inizio del progetto.

Nel riconoscere i rischi, i PM di alto livello guardano anche alla loro collaborazione con le parti interessate chiave, che spesso definiscono il rischio in modo esplicito o implicito nei loro requisiti e preoccupazioni. I grandi PM capiscono che questo processo avviene dalla fase di elicitazione dei requisiti fino all'intero ciclo di vita del progetto e lo considerano un vantaggio per la definizione del rischio durante tutto il processo.

I PM esperti si fidano anche dei loro team e riconoscono anche le loro conoscenze di esperti come una fonte di mitigazione del rischio. Al fine di consentire ai membri del team di individuare in modo proattivo il rischio, il PM autorizza il proprio team ad assumere la responsabilità del progetto e partecipare attivamente all'identificazione e alla gestione del rischio.

In termini pratici, la terza domanda durante uno standup quotidiano, "Cosa ti ostacola?" riflette risposte più prudenti poiché un team ha il potere di contribuire al successo del progetto. Naturalmente, alcuni bloccanti possono essere temporanei o rimossi immediatamente dopo lo scrum, tuttavia, alcuni sono potenziali candidati che possono diventare rischi sostanziali. I membri del team devono essere incoraggiati a identificare questi potenziali rischi e la loro inclusione dovrebbe essere celebrata piuttosto che disprezzata anche alla fine del ciclo di vita del progetto.

Anche il riconoscimento del rischio non è semplice quanto dichiarare il rischio e procedere. Il riconoscimento del rischio dovrebbe essere valutato regolarmente, in termini di probabilità, gravità e una metrica che a volte viene dimenticata: la prossimità. Quest'ultima metrica consente al team di definire le azioni giuste, sia che si tratti di "Non fare nulla fino al prossimo passaggio di riconoscimento del rischio" o qualcosa di più tangibile se il rischio è più vicino. Ciò che è importante riconoscere qui è che i migliori PM capiscono come rendere i rischi perseguibili, poiché qualsiasi rischio non è utile se non viene gestito. Inoltre, l'elenco degli elementi di azione non dovrebbe essere solo reattivo ma anche di natura proattiva, informando in definitiva un Product Backlog rettificato per il rischio.

In breve, un alto PM riconosce che, indipendentemente dall'esperienza o dall'autorità, non sono e non dovrebbero essere l'unica fonte per il riconoscimento e la gestione del rischio. Le parti interessate, il loro team e altri importanti contributori del progetto dovrebbero essere coinvolti nel riconoscimento e nella gestione del rischio non solo durante le fasi iniziali, ma anche regolarmente durante il ciclo di vita del progetto. Questo è importante perché i rischi che sono stati identificati all'inizio del progetto ma che da allora non sono stati gestiti sono molto scarsi.

Il punto chiave qui è: "Per ottenere una gestione del progetto di successo, l'intero team dovrebbe essere responsabile dell'identificazione dei rischi. La scoperta del rischio deve essere un processo continuo che si verifica per l'intera durata di un progetto".

4. Comprendere l'ambiente

Un primo PM non dovrebbe iniziare un progetto come un toro in un negozio cinese. Invece di forzare una metodologia o un approccio progettuale, il project manager dovrebbe eseguire un'analisi approfondita dell'ambiente, della struttura formale, della struttura informale, della cultura, delle abitudini, degli strumenti, delle capacità e delle risorse organizzative disponibili. Solo allora potrà iniziare il viaggio del cambiamento.

Mentre qualsiasi PM comprende che i progetti che stanno intraprendendo avranno un impatto sull'organizzazione, i migliori PM riconoscono che l'organizzazione ha un impatto simile sui loro progetti.

Invece di una mentalità imperfetta e universale, i migliori PM adattano il loro approccio comprendendo il loro ambiente. In tal modo, sono in grado di riconoscere meglio le esigenze aziendali più urgenti, il modo in cui le organizzazioni adatteranno o accetteranno una soluzione, l'adozione e quali modifiche verranno apportate alla soluzione per raggiungere la giusta misura nel raggiungimento degli obiettivi.

Durante la personalizzazione di un approccio efficace alla gestione dei progetti, i principali PM devono possedere una comprensione approfondita delle diverse metodologie, non solo dei diversi approcci PM, ma anche delle metodologie di analisi aziendale, dei framework di gestione del cambiamento, dei framework dell'architettura aziendale e di altri utili metodi di analisi. Questo dà a un PM la possibilità di trovare la soluzione più adatta per l'azienda a portata di mano per consegnare il progetto che sta intraprendendo.

Ad esempio, se stai avviando un progetto in un'organizzazione gerarchica estremamente rigida, in cui sono presenti molti livelli di approvazione diversi, l'approccio migliore potrebbe essere un approccio di gestione del progetto misto o ibrido. È possibile eseguire una fase strutturata di elicitazione dei requisiti, con l'approvazione dei requisiti effettuata in anticipo e quindi suddividendo il progetto in fasi con cancelli di fase formali. Parallelamente, il PM potrebbe impostare l'esecuzione iterativa di tipo Agile all'interno dei team di sviluppo per acquisire le migliori pratiche dello sviluppo iterativo, nonostante l'esecuzione di un progetto più tradizionale.

In sintesi, i migliori PM rispetteranno la cultura aziendale, proponendo rispettosamente nuovi approcci e guidando le organizzazioni nel miglioramento delle loro pratiche di gestione dei progetti. Riconoscono che molte organizzazioni si trovano a diversi punti di maturità e prontezza al cambiamento e la vedono come un'opportunità, piuttosto che una minaccia, per avere un impatto positivo sulla capacità di ciascuna azienda di implementare le migliori pratiche di gestione dei progetti.

Il punto chiave qui è: "I project manager non dovrebbero spingere ciecamente la propria agenda, ma dovrebbero adattarsi ai modi di lavorare delle organizzazioni e apportare il cambiamento lentamente se necessario".

5. Applicazione dei principi LEAN

I migliori PM sanno che il viaggio conta tanto quanto l'obiettivo. A volte, il percorso del progetto è reso particolarmente macchinoso da un processo che definisce come dovrebbero essere fatte le cose. Ciò potrebbe prendere forma in modelli inutilmente pesanti, riunioni inutili o periferiche che distraggono che ostacolano il viaggio, ma è tua responsabilità come PM assicurarti che questi ostacoli influiscano il meno possibile sul tuo team.

I migliori PM dovrebbero identificare processi più efficienti ed efficaci per il team, attingendo a principi di gestione agile del progetto, ben definiti nella metodologia LEAN.

Un malinteso popolare è che LEAN sia adatto solo per la produzione, il che semplicemente non è vero. I metodi LEAN di gestione dei progetti possono migliorare ogni progetto e ogni processo. Non è semplicemente un programma di riduzione dei costi, ma piuttosto un modo di pensare e agire per il tuo team.

I vantaggi dell'applicazione dei principi LEAN sono ben riassunti da una citazione del CEO di Toyota, Katsuaki Watanabe: “La gestione brillante dei processi è la nostra strategia. Otteniamo risultati brillanti da persone normali che gestiscono processi brillanti. Osserviamo che i nostri concorrenti spesso ottengono risultati medi (o peggiori) da persone brillanti che gestiscono processi interrotti".

Un PM di alto livello con una propensione all'eliminazione del rumore e del lavoro non necessari del progetto guiderà naturalmente il processo verso i principi LEAN. Un PM di alto livello dovrebbe lavorare a stretto contatto con un Product Owner, il suo team e le parti interessate per aiutarli a semplificare e specificare le proprie esigenze e il valore atteso come risposta a tali esigenze.

È anche utile guardare oltre LEAN per prendere in prestito le migliori pratiche di PM per il tuo progetto. Ad esempio, solo la metodologia PRINCE2 possiede un compito obbligatorio di acquisire le lezioni apprese durante la fase di avvio del progetto . Questo cattura tutte le lezioni apprese dai progetti precedenti, piuttosto che scrivere un documento alla fine del progetto che raramente verrà utilizzato da altri quando ne inizi uno nuovo. È importante non aver paura di modificare il processo per eliminare i passaggi non necessari e concentrarsi su quelli che aggiungono valore reale.

Questa è una buona opportunità, per aiutare e rimodellare i processi, o per aiutare il team a scegliere quelli giusti dall'inizio. Questi chiari indicatori di performance dovrebbero essere condivisi in modo trasparente con tutte le parti coinvolte per definire una guida chiara al successo del progetto.

Il punto chiave qui è: "Trovare le soluzioni giuste è importante quanto avere un processo snello e corretto per fornire tali soluzioni".