Perché mi rallegro #10

Sarà pure un motivo di rallegramento alquanto puerile ma una cazziata a Cicciopasticcio (alias R.B., alias il nostro Project Management Officer) da parte del capo non è cosa da tutti i giorni.

Il Nostro è freneticamente impegnato nella fase di upgrade del nostro Microsoft Project alla versione 2007. In quale ruolo non è dato sapere. Sulla carta è il Project Manager (nonché Amministratore del Sistema, mah). Come già detto in altro post, l’impresa potrebbe costituire la base per un manuale su come non si dovrebbero gestire i progetti IT.

L’altro giorno Cicciopasticcio ci comunica che il server non sarà disponibile causa manutenzione il tal giorno tra le 6 e le 7 della mattina (Central European Time) e ci chiede di astenerci dall’ utilizzarlo per non compromettere l’operazione.

Ieri, ecco giungere il flame cazziante da un adiratissimo R.B.:

[In grassetto] Nonostante avessi informato tutti della manutenzione blah blah qualcuno tra le 6 e le 7 stava registrando le proprie ore nel sistema blah blah ha compromesso la manutenzione blah blah ho dovuto riavviare la coda dei job (coda dei job? boh!) blah blah [in rosso] considero la disponibilità di Microsoft Project importante blah blah leggete gli email!!!!

Un classico esempio di come, sparando nel mucchio, si colpevolizzano tutti quanti e non si raggiunge lo scopo di sensibilizzare le persone. Anzi, riesci solo a farti dei nemici.

Sulle prime tuttavia, non ho prestato attenzione all’ennesima manifestazione di arroganza del Ciccio avendo cose più importanti a cui dedicarmi.

S.B. invece l’ha preso molto sul serio e ha risposto qualcosa del tipo:

Il tono del tuo email non mi piace, evidentemente chi stava lavorando alle 6 del mattino aveva delle buone ragioni per farlo, in questo modo crei solo stress e frustrazione, se hai il nome dell’individuo e appartiene al mio team fammelo sapere che ci penso io

Il capo (suo, mio e di R.B.) in copia.

A questo punto mi sono inzigato e dopo 24 ore rincaro la dose:

Ciccio, dovresti rivedere il tuo stile di comunicazione, non aiuta a sensibilizzare le persone e serve solo a demotivare coloro i quali tra le 6 e le 7 stavano dormendo, avrei preferito un’ispezione attenta dei file di log per risalire al nome dell’utente ed effettuare un’azione repressiva mirata

Anch’io metto il capo in copia. Pochi minuti dopo mi giunge un messaggio di Ciccio-bofonchiatore (di nuovo il capo in copia) che dice:

Se ho offeso qualcuno, faccio le mie scuse

Come a sottointendere che la mia reazione fosse dovuta a lamentele di gente del mio team e io avessi semplicemente dato voce alle proteste. Caro il mio Cicciopasticcio, non hai proprio capito un kakkio.

Ma dopo due ore giunge il memo del capo, diretto a me, S.B. e un nostro collega team leader d’oltreoceano, M.E.

Ho già avuto modo di commentare a Cicciopasticcio che il tono del suo mail ha probabilmente avuto l’effetto contrario a quello voluto, il grassetto e il colore rosso equivalgono a strillare, avrò un ulteriore chiarimento con lui in seguito, facciamo in modo che questo incidente non danneggi la nostra relazione di lavoro (sic!)  con R.B., ha svolto e sta svolgendo un bel lavoro per il team.

Grazie per la vostra pazienza

E’ la prima volta che il capo presenta il Ciccio come un accessorio di supporto (seppure importante) alle attività del gruppo dei Professional Services, quasi chiedendo di sopportarlo e portare pazienza…

Che goduria!

In che mani siamo!

Il dinamico duo H.G. (l’Olandese Volante, mio ex-capo che se ci penso…) e R.B. (l’ineffabile Cicciopasticcio) è di nuovo in azione.

Cosmic Hand by h.koppdelaney on Flickr

Il mandato del capo B.P. (che è pure il mio manager) è di implementare una soluzione basata su Microsoft Sharepoint per sostituire una varietà di sistemi informativi (Lotus Notes, Groove, ecc.) che vanno armonizzati su un’unica piattaforma.

R.B. è il nostro responsabile PMO (Project Management Office). Dovrebbe essere certificato PMP (Project Management Professional) ma è sistematicamente incapace di gestire un progetto.  In realtà nemmeno questa caratterizzazione è esatta. Qualunque cosa affidata alle sue sapienti mani e vibranti meningi non arriva mai allo stadio di “progetto”. Rimane bensì un guazzabuglio caotico, uno spreco di energie e di risorse finalizzato a produrre il residuo di un incubo. Purtroppo quasi tutti i nostri progetti interni sono affidati a questo minus habens: nessuno che io conosca ha mai preso visione di un project plan da lui redatto, nessuno ha mai avuto il piacere di esaminare i suoi raffinati quanto inesistenti risk management plan, i suoi communication plan sono copiati di sana pianta dal primo risultato ottenuto cercando la voce con Google, nessuno ha mai  rintracciato i suoi project status report, mai visto un documento di lessons learned da lui prodotto. Peccato che il personaggio sia poi designato a fare le pulci ai nostri Project Managers che guadagnano la metà di questo inutile parassita e da lui devono pure essere giudicati. E’ un politico nato, quando ha torto è sempre colpa di qualcun altro oppure gliel’ha chiesto il capo. Occasionalmente indice conference call totalmente inutili e da lì capisci che probabilmente il boss gli ha chiesto un aggiornamento sul progresso delle attività e deve rubare un po’ di idee dagli ignari colleghi. Oggi per esempio abbiamo partecipato a una telefonata proprio sul tema Sharepoint.  Questo giusto per spiegare l’utilità pari a zero di una certificazione PMP quando il soggetto è una zucca vuota. Secondo me all’esame per la certificazione ha copiato.

H.G. vive in un mondo tutto suo. Sono convinto che non veda l’ora di essere buttato fuori dalla azienda con congrua buona uscita e si trascina stancamente verso il miraggio dello scivolo d’oro. In fondo è un buon diavolo ma si trova aimè in una posizione nella quale può fare molti danni. E’ geneticamente incapace di riflettere sui dettagli. Manda messaggi broadcast a tutta l’organizzazione annunciando grandi iniziative. Quando gli fanno notare che forse è una cazzata partono le ammende, le smentite oppure… nulla! Tanto basta lasciar passare qualche giorno e nessuno si ricorderà più. Qualche settimana fa scrisse un annuncio sull’iniziativa di condividere con tutti i nostri Clienti il codice sorgente sviluppato nei progetti, nell’intento di creare una sorta di community open source. Il messaggio conteneva direttive, tempistiche e modalità. Dopo averlo letto mi sono venute in mente circa 57 domande sul tema ma mi sono trattenuto dal fornire qualunque tipo di contributo perché mi sono rotto di fare da balia al pivello ultracinquantenne come quando riportavo a lui. Dopo qualche tempo, visto che nessuno dei membri del team si muoveva eccolo che scrive a noi team leader chiedendo collaborazione per sensibilizzare le persone a supportare questa grande iniziativa. “Caro H.G., non sarebbe meglio se organizzassi una conference call in cui spieghi esattamente cosa vuoi che facciamo?”. “Grande idea” fu la risposta. Eccerto, tutto al contrario, accidenti! Durante la conference call e la sua sbrodolata introduttiva ecco il fuoco di fila delle ovvie domande:

• visto che condividiamo codice sorgente siamo sicuri che siamo coperti dal punto di vista legale?
• abbiamo chiarito di chi ne detiene  la proprietà intellettuale?
• cosa facciamo se la documentazione tecnica è stata  scritta in lingua locale?
• che si fa con le informazioni personali contenute nei documenti o nei commenti al codice sorgente (nomi, numeri di telefono, indirizzi email) ?
• come ci comportiamo se un Cliente che ha speso diciamo 50mila euro per la personalizzazione se la ritrova pubblicata liberamente accessibile da altri a costo zero?
• ecc. ecc.

Massacrato. Che pena sentirlo abbozzare una risposta bofonchiata a ogni domanda e immancabilmente avvertire persino attraverso il telefono la manciata di neuroni ancora in grado di funzionare nel suo cervello recitare in coro “Azz! Non ci avevo pensato!”. In olandese ovviamente.

La logica di H.G. ricorda a volte un treno in corsa su un binario morto. Oggi ne abbiamo avuto un esempio particolarmente divertente, ma ci sarebbe da piangere…

Orbene, nella famosa telefonata di oggi sul “progetto” Sharepoint (in collegamento Cicciopasticcio, i colleghi S.N. e M.E. dall’America e in ufficio con me il collega S.B.) H.G. illustra come il sistema verrà anche utilizzato per il controllo di revisione del codice sorgente sostituendo (illuso!) il mio caro Perforce. Premetto che avevo avuto l’occasione poco prima di Natale di esprimere i miei dubbi sulla soluzione da lui proposta: un mix di Sourceforge, Subversion, Tortoise che tra l’altro con Sharepoint non c’entrava assolutamente nulla. I dubbi erano principalmente legati al fatto che a quanto pare Tortoise non si comporta in maniera molto robusta quando due utenti effettuano contemporaneamente il check-out dello stesso file ingenerando la possibilità di corrompere i file.

Oggi risollevo lo stesso argomento di fronte all’audience allargata.

Io:”H., ti ricordi i problemi evidenziati rispetto alla possibilità che i file risultino corrotti se adottiamo l’approccio che proponi?”

H.G.:”Sì, certo!”

Io:”E come conti di risolverli?”

H.G.:”In nessuno modo, è una caratteristica del software che intendo adottare e non c’è nulla da fare”

Io:”Ne devo concludere quindi che l’integrità del codice sorgente non costituisce per te un requisito fondamentale di questo progetto”

H.G.:”Bè, direi che questa è la conclusione logica, sì”.

Ottimo: un sistema di controllo di revisione del codice sorgente che non è in grado di garantirne l’integrità.

Quando frequentavo il liceo, il professore di filosofia ci parlò del seguente sillogismo:

“Pietro e Paolo sono Apostoli, gli Apostoli sono dodici ergo Pietro e Paolo sono dodici!”

Secondo me lo ha escogitato H.G.

Cicciopasticcio #3: il Project Management Office è finalmente tra noi

 The TowerOriginally uploaded by iwayan.

 

(La seconda puntata si trova qui)

Con R.B. assunto a tempo indeterminato la strategia di implementare il Professional Project Management avanzò a pieno regime e il suo tempio cominciò a essere edificato.

Il Nostro incominciò a sfornare template di documentazione da usare nei progetti, organizzati in livelli a seconda della loro complessità, del budget disponibile, dei rischi, ecc. Creò matrici di ruoli e responsabilità, flow chart che descrivevano il processo di implementazione, communication management plan.

Il ciclo di vita del progetto veniva suddiviso in 5 fasi:

• Inititiation: fase pre-vendita durante la quale si raccolgono le informazioni necessarie a supportare l’offerta economica e si prepara un charter del progetto, una proposed solution e una stima dei costi

• Planning: durante la quale si crea una work breakdown structure delle attività, si definiscono le attività, le risorse e i tempi

• Executing: fase viva dell’implementazione durante la quale si eseguono le attività pianificate, si creano i deliverables e i rapporti di progetto

• Controlling: duranta la quale si implementano i processi di Change Management

• Closing: chiusura del progetto e redazione delle Lessons Learned

A supervisionare il tutto, una misteriosa entità denominata: Project Management Office (PMO).

A oggi, questo si dimostra essere l’unico contributo dato da R.B. alla nostra organizzazione. Perché risulti più chiaro: mi riferisco precisamente alla decina di righe riportate qui sopra. Credo che dieci righe di testo prodotte in 4 anni sia un contributo un po’ troppo modesto anche per la più indulgente delle organizzazioni no-profit.

Il totale dei template documentali da redigere nel corso di un progetto ammontava a 46. Secondo le procedure che stavano sempre più prendendo forma, un progetto nemmeno troppo complicato secondo gli standard adottati sino ad allora doveva prevederli tutti.

Chiunque avesse svolto un minimo di analisi sulle nostre attività di consulenza avrebbe immediatamente compreso che la preparazione di una tale massa di documenti avrebbe avuto un effetto nefasto sulla maggior parte dei nostri progetti, con budget ridotti all’osso e certo non sufficienti a coprire tanto overhead di lavoro.

A questa obiezione più che sensata ci sentivamo ribattere che la cosa era un problema solo in apparenza: lo scoglio maggiore sarebbe stato riempire i documenti la prima volta. Per i progetti successivi si sarebbe potuto largamente fare uso di copia e incolla: le parole chiave dell’evangelizzatore del Professional Project Management d’oltreoceano B.v.H erano “repeatable engagements”. Questa risposta nascondeva una verità alla quale allora non si prestò sufficiente attenzione: i template erano documenti vuoti. Non pagine bianche ovviamente ma giusto sommario e intestazioni, indici, ecc. il ché ne diminuiva grandemente l’utilità.

Appariva sempre più sospetto che R.B. lavorasse senza chiedere il minimo di contributo da chi nella nostra organizzazione il business lo conosceva bene. Ci si diceva: dopotutto è lui l’esperto.

All’epoca, fui coinvolto marginalmente nella predisposizione di un web server che avrebbe ospitato il sito Intranet del Project Management Office. Dubito che dal suo lancio, il carico di CPU della macchina abbia mai raggiunto il 5%.

Finalmente, all’incirca 7 mesi dopo l’inizio della sua impresa, R.B. dichiarò di essere pronto. Tutti si aspettavano l’annuncio che avrebbe cambiato per sempre il nostro modo di lavorare. Molti si attendevano riunioni in tutti gli uffici, che si individuasse un progetto pilota, che si lanciasse una newsletter, insomma che le persone fossero coinvolte anzi trascinate con entusiasmo in questa iniziativa.

Diamine! Il nostro R.B. era un esperto di communication management: chi meglio di lui avrebbe saputo come diffondere il verbo?

La nuova metodologia di lavoro venne invece introdotta con una webex di un paio d’ore in cui venne mostrato il diagramma del ciclo di vita di un progetto, i criteri di suddivisione dei progetti in livelli e venne consegnata la lista dei template. Arrivederci e grazie.

Qualcuno (parecchi mesi dopo venni a sapere chi) evidentemente pensava che questo sarebbe bastato a cambiare la mentalità di persone abituate da anni a lavorare in modo diverso.

Era la tarda primavera del 2004 e di lì a poco sarei stato promosso Team Leader.

Cicciopasticcio #2: le prime perplessità

(La prima puntata si trova qui)

Il primo ad avere qualche dubbio fu il collega e amico S.B., mente non debole: non sembrava un po’ troppo generico il materiale predisposto per il corso che trattava sì di Project Management ma in maniera decisamente scollegata dal nostro business?

I concetti illustrati si potevano tranquillamente applicare alla gestione di progetti di edilizia, costruzioni navali o telecomunicazioni. Mancava un solido legame con la nostra realtà di tutti i giorni che consentisse veramente alle persone di assimilare i concetti, farli propri e applicarli in maniera produttiva.

I commenti di chi tornava dalle sessioni di addestramento erano molto simili ma allora il vento del Professional Project Management soffiava forte nella nostra organizzazione ed era viva l’aspettativa che presto tutti noi saremmo magicamente stati in grado di migliorare enormemente le performance dei nostri progetti IT, a prescindere dal ruolo ricoperto nel project team.

Dopotutto il nuovo General Manager B.v.H. aveva chiaramente indicato che questa era la direzione in cui si doveva andare: avremmo aggredito il mercato Big Pharma, i nostri interlocutori non sarebbero stati più lab manager o key users, bensì i CEO, avremmo presto venduto progetti enormi e dovevamo essere preparati.

Nonostante la Storia abbia poi pronunciato il suo insindacabile giudizio (negativo) sul personaggio B.v.H., egli fu senz’altro in grado di presentare all’organizzazione una cosa che non si era mai vista con chiarezza prima: una visione. Quella cosa che tolti carriera, stipendio ed effimere soddisfazioni professionali è la ragione fondante per cui ogni giorno vai a lavorare e sei pure felice di farlo.

E poi a bordo avevamo un esperto, R.B. appunto, che di lì a poco sarebbe stato assunto a tempo indeterminato. Nessuno all’epoca poteva intuire che dentro di lui si nascondesse in realtà Cicciopasticcio.

Cicciopasticcio #1: le origini

Questo argomento richiederà alcune puntate per essere trattato in maniera esauriente.

Riguarda i guasti che si possono produrre tentando di implementare una strategia e modellare una organizzazione aziendale sulla base di principi nei quali non si crede fermamente e che non vengono propagandati in maniera convincente dal top management.

Un po’ come il leggendario Jack Welch, fautore ed evangelizzatore in General Electric della teoria e pratica Six-Sigma, e del suo successore Jeff Immelt: anch’egli credeva in Six-Sigma come il suo illustre predecessore ma non continuò nell’opera evangelizzatrice e non perseverò nel citare Six-Sigma in ogni suo discorso. Il grado di aderenza alle procedure decadde perchè la gente non pensava più che quella fosse la direzione in cui l’azienda voleva andare e smise di crederci aspettando la prossima grande idea del top management.

R.B., a.k.a. Cicciopasticcio, lavora con noi da ormai 3 anni. È tedesco ma porta un cognome che suona francese in modo dannatamente sospetto. Prima che la sua strada incrociasse la nostra, lavorò per una società che si occupava di speech recognition. Fallita. Succede.
Fu l’artefice (anche se a posteriori sarebbe meglio dire “spettatore”) della rivoluzione copernicana che ha portato la nostra organizzazione a dotarsi di un PMO, ovvero un Project Management Office, mutuato dalla dottrina del Project Management Institute.

Gli storici dateranno l’inizio di questa rivoluzione qualche mese addietro, a partire dall’ingresso nella stanza dei bottoni d’oltremare dell’incommensurabile General Manager B.v.H., la catastrofe umana, noto come teflon man per la sua incredibile capacità di sottrarsi a qualunque tipo di responsabilità. Non gli riuscì di sfuggire alla più grande di tutte, per la quale fu giubilato da un pesce molto più grande di lui (dilapidò una quantità innominabile di denaro per un prodotto che non vide mai compiutamente la luce e non realizzò il sogno della Grande Porta).

Un tipo molto fumo e nessunissimo arrosto che sulle prime fu pure in grado di abbozzare una specie di visione per la nostra organizzazione: l’unico merito che gli riconosco visto che nessuno è stato in grado finora di ripetersi con uguale efficacia seppure con migliori intenzioni.

Ebbene, B.v.H introdusse nella nostra organizzazione il virus del Professional Project Management e R.B., la cellula impazzita, lo propagò approfittando di menti deboli incontrate sul suo cammino come H.G. e soprattutto R.C., che alla fine commise il Sommo Errore e lo assunse a tempo indeterminato.

E fu così che le nostre truppe si recarono alla corte prussiana di R.B. per un training di due settimane (dicasi due settimane, un fatto mai visto né prima né in seguito) sul Project Management.