Siamo tutti d’accordo nel dire che i progetti hanno molte più probabilità di essere di successo se si pongono obiettivi molto chiari e se il management è fortemente coinvolto. Tuttavia, avete notato che con gli approcci Agile e ibrido è aumentata la pressione sui Project Manager, che devono avviare un progetto senza consensi formali?
E sicuramente, questo aumento di pressione ha contribuito anche all’aumento dei rischi!
Quando regnavano i progetti predittivi, «a cascata» o «ciclo a V», una grandissima attenzione era rivolta al project plan, alla sua revisione da parte dello sponsor e delle parti interessate e degli altri membri del comitato di progetto e alla sua firma formale da parte di tutti.
Questa formalità non impediva comunque che le cose cambiassero e si evolvessero lungo il percorso: i rischi si manifestavano e i mercati e la concorrenza evolvevano ugualmente. Ma almeno tutti avevano consapevolezza di quello che era stato accordato e firmato.
La fase di inizializzazione di un progetto è particolarmente critica per il successo dei lavori: fornisce infatti un perimetro chiaro, degli obiettivi accordati e misurabili, dei mezzi definiti e approvati (risorse interne ed esterne) e anche il coinvolgimento delle alte sfere del management aziendale.
La firma manuale riflette un forte impegno che formalmente non può essere eguagliato da un semplice feedback di approvazione via e-mail o dall’estratto delle decisioni del comitato di progetto.
In effetti, prima di firmare un documento, ci sono molte probabilità che si sia letto il testo con attenzione e che siano stati chiesti chiarimenti o correzioni. Certo, sembra così retrogrado per i nostri leader più giovani ma anche per i più anziani che pochi oseranno rivendicarlo. Quindi, anche se la mia profonda convinzione rimane che una firma manuale ha più valore di un’approvazione elettronica, optare per la seconda è più realistico, soprattutto se si rende ben visibile nel documento chi l’ha approvata.
Siano manuali o elettroniche, la tentazione di iniziare il progetto senza firme formali è sempre forte. Se siete in un approccio adattivo-Agile o ibrido, la tentazione è ancora più forte che con i metodi predittivi: date di consegna imposte, scadenze inflessibili, Minimum Viable Product evasivi, pressione del management e dei colleghi, o a volte la semplice paura di lasciare il team inoccupato o di farsi “rubare” elementi chiave del team.
Proviamo a guardare queste false buone ragioni che a turno possono convincere a procedere nei lavori senza il giusto formalismo.
1. Date imposte e scadenze non flessibili
Se avete qualche anno (o come me, decine di anni!) di esperienza nel Project Management, una delle lesson learned che avrete sicuramente imparato a vostre spese è che le date imposte sono sempre una cattiva motivazione per spingere a definire i perimetri, il contenuto e il plan di un progetto. S E M P R E !
Se l’ingiunzione è del tipo: “Qualsiasi soluzione che venga consegnata dopo la stagione commerciale che inizia a novembre non ci interessa!”, allora è chiaro che una delle dimensioni fondamentali del progetto, le scadenze, è bloccata, ma c’è ancora modo di completare il progetto facendo leva sulle altre due dimensioni: contenuto (flessibile verso il basso) e mezzi utilizzati (flessibile verso l’alto).
Il/la Project Manager, dopo aver convalidato questo vincolo, si trova talvolta a dover prendere delle scelte basate più su criteri di disponibilità previsionale che di merito. Per esempio, alcune soluzioni tecniche avrebbero potuto rispondere meglio alle necessità di business ma avevano bisogno di troppo tempo per essere sviluppate. Per quanto riguarda il contenuto, vedere il punto due. Tuttavia, non abbiate dubbi a posteriori: questa decisione “breve-termista” imposta dalla data limite, potrà rivelarsi inutile se non addirittura controproducente, ma al momento non era possibile fare altra scelta.
2. Minimum Viable Product (MVP) evasivi
L’approccio Agile che viene travisato o non compreso a fondo, è una pessima scusa che viene spesso usata per non definire con precisione tutti i bisogni.
Sicuramente non è necessario definire tutti i bisogni che non faranno parte del perimetro e del contenuto del MVP, ma per quelli che sono inclusi, è necessario che siano dettagliati e se possibile questa va fatto con un team ristretto di sviluppatori e utilizzatori, senza lasciapassare.
Il Minimum Viable Product deve essere preciso e chiaro riguardo cosa sarà incluso e cosa non lo sarà relativamente a questa versione che sarà sicuramente utilizzabile ma comunque incompleta.
Per approfondire leggi anche: Importanza dei concetti di Minimum Viable Product (MVP) e Minimum Business Increment (MBI) nella gestione di progetti
3. Pressioni del management e dei colleghi
Ancora più attenzione a questo punto. Anche quando queste pressioni partono da convinzioni e coinvolgimento sinceri delle persone, troppo spesso sono il risultato di opinioni parziali dei bisogni e delle rispettive priorità. L’impatto del contesto (ecosistema) nel quale la soluzione sarà impiegata non può essere ignorato, come neanche gli obiettivi finali del progetto.
Queste pressioni sono talvolta caratterizzate da considerazioni più terra-terra piuttosto che dalla disponibilità delle competenze richieste per ciascuno dei bisogni riconosciuti e che sono ambite da altri progetti o iniziative più operative. È sempre utile darsi il tempo di comprendere e non sottovalutare le “lotte di potere interno”, i desideri di sviluppo di nuove competenze in un reparto o le scelte di assegnazione già presenti delle risorse dell’azienda.
Non si possono ignorare queste persone e le loro pressioni, ma di sicuro non devono oscurare la nostra visione e allontanarci dai criteri di scelta stabiliti come scelta migliore per il progetto.
4. Risorse chiave disponibili
La sensazione di dover utilizzare a tutti i costi le risorse disponibili e non assegnate è molto forte e abbastanza legittima per il management funzionale dell’impresa.
Ma, dal punto di vista del progetto, che corrisponde a quello del Project Manager, si pongono alcune questioni importanti:
- Queste risorse disponibili si adattano alle necessità del progetto? Sono adeguate ad esso?
In quanto potrebbero essere sotto-qualificate per i compiti richiesti o rischiano anche di essere sovra-qualificate: non si vuole correre il rischio che gli esperti qualificati se ne vadano perché annoiati dal lavoro.
- Possediamo internamente tutte le competenze richieste se dobbiamo basarci esclusivamente sulle disponibilità?
O le assegnazioni correnti possono essere cambiate se il progetto in questione ha la priorità, o bisognerà prendere risorse e competenze all’esterno.
- Quanto tempo ci vorrà per reclutare delle nuove risorse o per formare correttamente quelle in grado di crescere?
Alla fine, anche se queste risorse chiave fossero disponibili con le giuste competenze, è una ragione sufficiente per iniziare senza l’approvazione formale del progetto? NO!
In pratica, che fare?
In una piccola azienda con clienti che la conoscono bene e con una fiducia reciproca ben stabilita tra tutte le parti coinvolte nel progetto, è possibile mandare avanti dei progetti di piccole dimensioni senza bisogno di una firma formale.
Potete probabilmente lanciarli in maniera Agile con una buona idea del primo MVP, del risultato finale target e un fermo impegno sui contenuti e sulle risorse solo nelle prime fasi.
Tuttavia, soprattutto in grandi progetti e compreso l’approccio Agile, vale la pena assicurarsi le approvazioni di tutte le principali parti interessate prima di iniziare. In caso contrario, dovrai disfare tutto o parte del lavoro già fatto e ricominciare da capo (se ne hai ancora i mezzi).
“Se non vi prendete adesso il tempo per fare le cose per bene, ditemi quando vi prenderete il tempo per rifarle da capo! Perché senza alcun dubbio dovrete rifarle.”
Quindi, secondo voi le firme formali sui progetti rimangono ancora adesso importanti nonostante l’arrivo di approcci Agile e ibridi?
