Project management (background noise)

Quanto il rumore di fondo crea "discontinuità nella gestione di un progetto".
Credo che la situazione sia comune alla maggior parte delle persone che affrontano la gestione di un proggetto.
Il fenomeno si presenta sotto parecchi aspetti e forme ma l'effetto è sempre lo stesso "allontanarsi dalla meta" sia questa la data di fine progetto sia questa una milestone.
Nel corso della mia esperienza ho imparato a riconoscere/individuare alcuni fenomeni che portano alla creazione di rumore e ad oggi ne traggo dei benefici.

Rumore causato da Attori
Durante il corso di project management più volte si è discusso di quanto uno sponsor abbia interesse nella promozione del progetto, o quanto sia necessario veicolarlo nella stessa.
Di contro è proprio lo sponsor ad essere il primo ( e in molti casi involontario ) generatore di rumore.
Nel caso specifico l'atto di promuovere un progetto comporta, da parte dello sponsor stesso delle azioni di p.r. per cui il rischio di presentare o raccogliere requisiti in corso d'opera, solo per rendere più appetibile la soluzione.
Come figura cardine o come desunta tale, "io sto facendo questo per il progetto, sarebbe quindi utile dar seguito anche queste implementazioni", lo sponsor potrebbe introdurre nuovi elementi ( validi o fronzoli ) che tuttavia potrebbero farci allontare dalla meta.
Per gestire questa situazione ci sono differenti vie di fuga, non sempre eleganti e non sempre attuabili.
La prima e l'essere propositivi, "queste nuove specifiche ci faranno ritardare la consegna, se il ritardo è tollerato, rivediamo il piano di progetto in tal senso, caso contrario dobbiamo comprendere se queste nuove specifiche possono essere incluse in una fase successiva".
In questo modo l'entropia è contenuta, e le redini rimangono nelle nostre mani, ma si dà piena visibilità allo sponsor della nostra completa disposizione a riorganizzare il lavoro.
La seconda è molto restrittiva, "queste nuove specifiche stravolgono il progetto originale. Istruiamo un tavolo perchè cambiando i requisiti quanto fatto ad oggi potrebbe non essere più valido."
In questo modo creiamo due possibili effetti il primo e di creare un punto d'attenzione, il secondo di rivedere tutto il progetto, il rischio in questo è molto alto, ma di contro il nostro compito è di portare a termine il progetto, creare quindi un momento di riflessione può far comprendere che la strategia di presentazione del prodotto non può eccdere.
Sempre per il secondo caso è necessario essere dei buoni mediatori e nel caso specifico dell'apertura di un tavolo di discussione dovrà essere nostro compito individuare cosa è realmente necessario al nostro proggeto e cosa è un "fronzolo".
Diciamo che bisogna essere diplomatici ma senza perdere il focus sul progetto.

Gli Stakeholder sono figure direttamente o indirettamente conesse al progetto, che tuttavia hanno / nutrono interessi nello stesso.
Per la mia esperienza ho potuto notare differenti tipi di influenze da parte di questo Attore, in molti casi si tratta di mail, di chiacchere al caffè, di "uscite estemporanee" in breve asserzioni, non ben definite e nella maggior parte non condivise.
"Sarebbe bello che fosse più blu" per evidenza di fatti questa frase, detta in contesti diversi assume pesi diversi.
Se questa asserzione è fatta durante un caffè, certo la si può considerare ma lascia il tempo che trova, se al contrario si presenta in più occasioni e in più incontri ufficiali assume il peso di un dicta. La viralità di un asserzione porta alla convinzione che sia corretta.
Per ovviare a questi problemi è necessario comprendere il peso dello Stakeholder se si tratta di figure influenti e irremovibili si deve scendere a compromessi, con tutti i rischi che comporta il gesto stesso.
Mi è capitato di dover "incastrare" in una soluzione di 40 giornate, altre 5 giornate solo per un "pò di blu in più". Ma mi è anche capitato di rispedire al mittente la richiesta con un categorico "questa modifica non è in capitolato, e non sarà implementata".
E' necessario ricordarsi che "il progetto noi lo si conduce e il committente lo paga", il nostro compito è di affrontare con il committente anche questo tipo di decisione, avvalandoci di dati, e nello specifico il "quanto" di tempo necessario per assolvere alla richiesta.

Le risorse di progetto.
L'argomento è esteso e molto dipende dal team, dalla comunicazione, della esperienza del team e di tutte le regole che lo governano.
Un team coeso, con un forte orientamento alla comunicazione è un buon punto di partenza, ma spetta a noi e ai senior nel team stesso mantenerlo nella stessa condizione. Gli attori discussi in precedenza potrebbero e in molti casi è l'aspetto più difficile da gestire, intervenire direttamente sulle risorse.
"Hai tempo ? devo chiederti se mi modifichi questo" in molte occasioni questo evento si verifica in assenza del p.m. causando sia l'interruzione della comunicazione, sia una variazione non "prevista".
A giochi fatti, l'unica è avere ( e dovrebbe sempre essere così ) la possibilità di effettuare un rollback ma non sempre è possibile, prevenire questa situazione è altrsì complesso, anche spiegando quanto questa situazione possa essere pericolosa, potrebbe non esserci .

Noi stessi...
Noi per primi rischiamo di essere causa di rumore per noi stessi. Questo dipende dal fatto, che in molti casi la pressione, lo stress rischia di giocarci brutti scherzi. In questo caso ci si può avvalere di vari strumenti per monitorare le attività per non perdere il focus, per accentrare le informazioni e per "non mollare il colpo sul più bello".