Il "Bat telefono"

Il titolo di questo articolo si riferisce all'uso liberale del Batphone da parte del commissario Gordon ogni volta che la città di Gotham era in uno stretto stretto (dalla serie tv "Batman" degli anni '70).

Questo articolo fa parte della nostra raccolta "From the Trenches". Racconta la storia fittizia di "Batman" su come, durante un'implementazione di EPM, a un certo punto potremmo desiderare di avere accesso a un Batphone quando siamo nei guai. Vengono inoltre illustrati molti modi per evitare problemi durante l'implementazione.

Per scaricare la versione di Word di questo articolo, vedere Il Batphone.

Per altri articoli, vedere white paper "From the Trenches".

Il batfono

Nel 1966, la serie tv originale di Batman venne trasmessa. È durato solo 120 episodi, ma ha cambiato una cultura in modi che durano fino ad oggi. Nel mondo di Batman e Robin (interpretato da Adam West e Burt Ward), c'era una soluzione 'bat' a tutto. Indipendentemente dal problema, Batman avrebbe la soluzione. La Batmobile, Batboat, Batplane e Batcave avevano tutti il loro posto. E se tu fossi qualcuno che aveva bisogno di aiuto, non importa quanto sia difficile, come hai potuto raggiungere Batman? Beh, con il Batphone, naturalmente! Prendere il Batphone e l'aiuto sarebbe sulla strada.

Il Commissario Gordon si rivolgerebbe al Batphone quando le cose sono senza speranza, cosa che si è verificata naturalmente in ogni episodio. Non importava quanto fosse difficile la sfida, prendere il Batphone e in 22 minuti (più il tempo per gli spot pubblicitari) il cattivo sarebbe stato sconfitto e Gotham City tornò in stato di pace.

Ogni soluzione nel mondo di Batman è stata fatta per sembrare un pipistrello. Manette? A forma di pipistrello. Cintura di utilità? Logo dei pipistrelli. Gancio a grappling? Naturalmente - sembra ali di pipistrello. Con mia sorpresa, guardando indietro le immagini del Batphone sembrava sconvolgente normale. Un telefono rosso con un quadrante (ricorda quelli?) Non so perché aveva un quadrante. Si chiamava solo un luogo: la Batcave, dove la salvezza era a portata di mano.

Per quanto nostalgico possa essere pensare ai telefoni con quadranti e ai vecchi episodi di Batman, non è davvero il punto dell'articolo di oggi. Sono passati 40 anni da quando il Batphone è stato ritirato, ma le persone fanno chiamate ai consulenti EPM ogni giorno sperando che il Batphone funzionerà per un'altra chiamata.

I loro cattivi sono vari. Alcuni sono tecnici; devono eseguire l'aggiornamento dalla versione x alla versione y. Alcuni sono architettonici; devono comunicare il sistema EPM interno con gli utenti del mondo esterno. Alcuni sono culturali; gli utenti si rifiutano di utilizzare il sistema. E alcuni sono procedurali; il processo che seguono non sembra fornire il risultato previsto.

Indipendentemente dalla sfida, la richiesta per la società di consulenza è la stessa: è possibile risolverla in 22 minuti?

Si tratta di una situazione in cui un numero sorprendente di utenti EPM entra in una situazione in cui hanno urgente bisogno di assistenza per farli uscire da una situazione difficile. Si tratta spesso di un'emergenza e la soluzione è richiesta ieri dalla direzione. Le persone che effettuano queste chiamate (ottengo un paio ogni settimana) non sono deboli di mentalità. Sono manager altamente intelligenti, capaci e abile.

Non c'è nessun Batphone, ovviamente. Vorrei che ci fosse. Lo userei per ogni tipo di sfida personale. E così le persone che fanno queste chiamate sono raramente soddisfatte delle risposte che ottengono. Quindi, prendiamo qualche istante e parliamo di come le persone finiscono in un posto così stretto che sentono che hanno bisogno di prendere il telefono rosso e come si può evitare di essere uno di loro.

Entrare nei guai

Per prima cosa, si parlerà di come le persone si insidiano durante l'implementazione di un'implementazione di EPM. Esistono un paio di cause comuni:

• Sottovalutare la sfida Si tratta, di gran lunga, dell'errore più comune in una distribuzione EPM. Non si tratta di dire che ogni distribuzione deve essere grande e difficile. Non è sempre così. Ma, forse a causa di desideri, è incredibilmente comune sottovalutare ciò che ci vorrà per ottenere i vantaggi di una distribuzione EPM. Il primo errore nella sottostima è la selezione della destinazione. Alcune persone scelgono l'installazione dello strumento come progetto di successo. Non lo è, ovviamente. Alcune persone scelgono il primo uso dello strumento o il primo report che esce dallo strumento come destinazione. Anche questo non è tutto. La soluzione di qualsiasi problema per cui sono stati scelti gli strumenti EPM è la destinazione. Ciò significa che le impostazioni cultura sono cambiate, il training è completo, l'utilizzo è in produzione, gli strumenti funzionano, i dati sono lì. Sì, potrebbe essere una cosa importante, ma se sei a un pollice di distanza da quell'obiettivo, non hai ancora niente. (Beh, quasi niente, comunque.)

• Renderlo un progetto tecnico Per quelli di noi nel settore tecnologico, siamo più colpevoli di questo e in realtà, la maggior parte di noi lo sa meglio. Eppure, in qualche modo, la tentazione di credere che la disponibilità della tecnologia significa che il problema è risolto è difficile da resistere. Così tante organizzazioni che visitiamo dicono una certa variante di "ma abbiamo installato Project Server, perché il nostro personale è sovraccarico? Come abbiamo detto da tempo, fare del lavoro di gestione dei progetti aziendali è una combinazione di persone, tecnologia e processo e una buona quantità di gestione del cambiamento generata per una buona misura. Questo non arriva automaticamente quando il DVD software scorre attraverso la porta.

• Non coinvolgere la gestione Anche questo accade molto spesso. Dopo tutto, le persone che meglio comprendono i vantaggi di un sistema di gestione dei progetti aziendali sono molto probabilmente coloro che stanno lottando per analizzare le grandi quantità di dati provenienti da un ambiente con molti progetti e molte risorse. La gestione dei progetti aziendali è più diffusa quando un'organizzazione cerca di riconciliare una serie complessa di priorità in conflitto e una miriade di competenze ed esperienze. Si potrebbe pensare che la gestione sarebbe naturalmente coinvolto in un progetto di questo tipo, ma spesso non è il caso. La sfida di cambiare la cultura aziendale da una mentalità di progetto singolo a una mentalità del progetto aziendale è quasi impossibile da superare senza di loro e tuttavia troppo spesso la gestione viene ignorata a causa della preoccupazione che non saranno in grado di apprezzare ciò che ci vorrà per completare una distribuzione EPM.

• Creazione di pianificazioni non realistiche Nessuno vuole che una distribuzione EPM richiederà molto tempo. Ed è comune sperare che il progetto possa essere realizzato in giorni o un paio di settimane anziché nei mesi più comuni. Esiste anche una sfida comune di non ottenere le risorse per un progetto "interno", ad esempio EPM, come un progetto basato su client o commerciale. Per questi e altri motivi, è comune creare una pianificazione del progetto con requisiti di risorse tristemente insufficienti.

• Non applicare la gestione dei progetti al sistema di gestione dei progetti Se hai letto qualcosa che ho scritto, è probabile che tu l'abbia già visto. I project manager sono sensibili alla sindrome del "calzolaio i cui figli sono a piedi nudi". Il risultato è una mancanza comune di una carta del progetto, un budget approvato, una pianificazione tracciata, risorse dedicate e tutti gli altri accoutrement per il proprio progetto che sono comuni a tutti gli altri progetti gestiti.

Cosa si aspettavano?

Ok, è così che le persone così spesso si trovano nei guai. I vantaggi previsti dalla gestione della distribuzione di un sistema EPM derivano in genere direttamente dalle sfide aziendali. È la promessa di risolvere le sfide che portano la gestione ad approvare le spese per il software, l'hardware, l'infrastruttura e possibilmente anche i servizi. Le sfide più comuni possono sembrare familiari:

• Le risorse sono sovraccaricate Potrebbe non essere chiaro su quali risorse vengono utilizzate, ma è molto comune trovare che le risorse sono sovraccaricate. Un problema più complesso è quello di scoprire che alcune risorse sono sovraccariche e altre sono sotto-caricate, il che spesso indica una mancata corrispondenza tra le competenze e l'esperienza disponibile rispetto a quelle richieste.

• I progetti critici non vengono completati in modo tempestivo Dovrebbe essere ovvio che i progetti critici devono terminare quando sono pianificati, ma la vita sembra interrompere tali piani. Ciò può essere dovuto a requisiti di risorse in conflitto, alla scelta di un numero eccessivo di progetti che richiedono un numero eccessivo della stessa competenza o semplicemente a una definizione di priorità errata. A volte le organizzazioni pensano che sia una mancanza di competenza del project manager, ma in un ambiente multiprogetto e multi-reparto matrice, il colpevole più probabile è la natura organizzativa.

• I progetti non vengono completati entro il budget Ciò che vale per la pianificazione può essere applicato anche ai costi. Nell'alta tecnologia e in molti altri settori, la componente più variabile del costo di un progetto è la quantità di manodopera applicata. È necessario molto più tempo con le stesse persone e si aggiungono costi al progetto. Un numero incredibile di progetti di colletti bianchi rimane ancora non tracciata. Sono pianificati, ma il costo effettivo per progetto non viene registrato.

• La concorrenza sta completando i progetti più velocemente di quanto In un'economia competitiva, essere prima sul mercato può fare la differenza tra sopravvivenza e oblio. Quindi, per molte organizzazioni, assicurarsi che la gestione dei progetti sia almeno altrettanto efficace come la concorrenza è importante.

• Non c'è visibilità su ciò che le risorse di un progetto stanno spendendo il loro tempo o nessun modo per sapere quanto tempo viene speso per ogni progetto A volte nessuna risposta è peggiore di una cattiva risposta. Se si è in senior management questo è particolarmente vero. Se sai che i risultati sono negativi, puoi applicare le tue competenze e le risorse a tua disposizione al problema a portata di mano. Se sai che c'è qualcosa che non va, ma non sai cosa, sei ammanettato. Non c'è modo di sapere dove provare a risolvere qualcosa.

Ricerca per categorie tenere fuori dai guai?

Non vuoi mai arrivare a un punto in cui senti di aver bisogno del Batphone. Quindi, cosa puoi fare con l'ambiente EPM per assicurarti di non finire lì?

Ok, tutto quello che abbiamo detto nella prima sezione è ovvio:

• Eseguire una stima corretta

• Non pensare che EPM sia solo un progetto tecnico

• Coinvolgere i dirigenti fin dall'inizio

• Crea un programma realistico e dai un controllo della realtà confrontandolo con altri nel tuo settore

• Creare una pianificazione del progetto e una carta dei progetti ed eseguire tutte le operazioni normalmente eseguite con gli altri progetti

Cos'altro puoi fare?

Prima di tutto, iniziare il progetto con un apprezzamento che a un certo punto in futuro, si sta andando a voler usare il Batphone. Tu sei. Sapendo questo, una cosa che si può fare è quello di budget per l'assistenza che non si dispone di un piano corrente per. È consigliabile che i clienti budgetno dal 10% al 20% del progetto per i "requisiti non allocati". "A cosa serve?" ci viene sempre chiesto. "Ci dirai più tardi", rispondiamo sempre. È comune non usare tutti quei soldi. Ma è anche incredibilmente comune usarlo. Avere un esperto esperto già allocato e il budget per il progetto fa una differenza enorme in un secondo momento.

Iniziare con l'aspettativa che il piano e le persone cambieranno. La mia citazione preferita per la gestione dei progetti è di Napoleone Bonaparte, che ha detto: "Un piano di battaglia dura fino al contatto con il nemico". È vero anche per i piani EPM. Dato che è probabile che un'implementazione duri diversi mesi, la possibilità che alcuni membri del personale cambino nel piano è enorme. Pianificare quindi la ridondanza.

I sistemi EPM si evolvono. È comune in questi giorni in un'applicazione aziendale pensare al "costo totale di proprietà". Credo che dovremmo includere il ciclo di vita totale delle applicazioni nei piani di progetto EPM. Hai pensato a quale versione di uno strumento che stai per implementare? Hai pensato a quali altri strumenti dipende? Che ne dici dell'aggiornamento/aggiornamento regolare di questi strumenti? Sono state eseguite personalizzazioni? Che ne dite del training personalizzato? Si è pensato a come eseguire la migrazione di tali elementi a una nuova versione?

Pianificare anche la ridondanza degli esperti. Se hai un singolo consulente che lavora per te, cosa accadrà tra pochi mesi mentre passi a una nuova fase dell'implementazione o introduca un nuovo membro chiave del tuo team? Il consulente sarà disponibile? (I consulenti passano da un progetto all'altro, quindi la risposta è spesso "no". Se lavori con una società di consulenza, hai parlato di come possono preservare il lavoro del loro personale per fare in modo che altri lo replicano, se necessario?

Mettere che in scrittura

Una delle sfide più comuni e più facili da risolvere deriva da una documentazione insufficiente. È l'elemento più semplice da cambiare brevemente, ma l'esistenza di tale documentazione può fare la differenza tra tornare a un riferimento scritto e cercare il Batphone. Inoltre, non è sufficiente scrivere un documento e infilarlo in un cassetto da qualche parte. I documenti devono far parte di un record in corso e il processo EPM potrebbe farvi riferimento come parte di un processo di revisione regolare. Ecco alcuni dei documenti per un ambiente EPM che ritengo siano più critici:

• Business Case Non so cosa si tratti del business case originale che lo rende così poco attraente, ma è la cosa più comune da perdere e per molti aspetti, è il kernel del motivo per cui si dispone di un ambiente EPM in primo luogo. Il business case nota quali sono i vantaggi previsti per l'organizzazione; cosa si aspetta l'organizzazione dal sistema EPM? Quando riceviamo una chiamata a Batphone, una delle prime cose che chiediamo è: "Qual è il sistema che ci si aspetta di fornire per te?" Non è sufficiente chiedere all'amministratore. Chiediamo anche alla direzione, agli utenti e ai beneficiari aziendali. La risposta più comune è una risposta diversa da ogni parte. Questo perché la premessa aziendale originale è andata persa.

• Ruoli e responsabilità Nell'ultima versione dei ruoli e delle responsabilità, spesso ci risolviamo con il nome di un individuo e non ci vuole molto prima che il ruolo che l'individuo svolge nel sistema EPM venga dimenticato. Il mantenimento di un documento sui ruoli e le responsabilità consentirà di modificare i parametri di chi fa ciò che nel processo EPM, poiché l'organizzazione passa naturalmente attraverso i cambiamenti del personale o anche le modifiche alla struttura organizzativa.

• Guida al processo e diagramma di flusso Questo viene spesso dimenticato quando si arriva a guide procedurali. Persone vengono lasciati con i passaggi "Cosa fare" in un manuale procedurale, ma non il contesto per cui tali passaggi sono importanti e cosa facciamo con il risultato di ogni passaggio. Una guida al processo e, soprattutto, un diagramma di flusso visivo consentiranno ai futuri manager di comprendere ciò che il sistema fornisce e renderà molto più facile adattare il sistema in futuro.

• Criteri di selezione del sistema Quando scegli il tuo sistema EPM e qualsiasi strumento di terze parti che potresti aver selezionato lungo il percorso, fai sapere alle generazioni future su quale è stata la tua decisione. Siamo andati nelle organizzazioni 5, 7 o anche 10 anni dopo la distribuzione di un sistema e abbiamo visto un sistema con diversi strumenti associati e abbiamo chiesto "Perché lo stai facendo? Sarebbe molto più facile fare questo! I motivi di tali decisioni non sono da nessuna parte. In alcuni casi il cliente ha trascorso anni a fare qualcosa in modo estremamente complicato che avrebbe potuto essere molto più facile date le versioni più attuali degli strumenti esistenti. Non possono prendere una decisione semplice per modificare uno strumento o usare una versione più recente perché non hanno più accesso al motivo per cui hanno scelto di fare qualcosa in un certo modo anni fa.

Non c'è davvero nessun Batphone.

Quando dico questo, mi sembra di dire che non c'è davvero un coniglietto di Pasqua o nessun Babbo Natale. È solo una brutta notizia. Ma non c'è davvero nessun Batphone. Sono sicuro, però, che solo l'assenza di quel telefono magico non impedirà alla gente di chiamarmi domani chiedendomi di vancare l'ultimo cattivo di Gotham City. Se si verificano problemi e si sente la necessità di chiamare un esperto, ecco alcuni consigli:

1. Ascolta il consiglio che ricevi. È sciocco pagare un esperto per darti consigli e poi decidere di sapere meglio di loro. Se hai intenzione di chiedere consigli e hai a che fare con un esperto, prova ad ascoltare e almeno prendere in considerazione il consiglio. Batman non avrebbe continuato a presentarsi per il Commissario Gordon più volte se ogni volta lo avesse fatto, Gordon disse: "Ora che sei qui, Batman, per favore fai la stessa cosa che fanno tutti gli altri miei poliziotti".

2. Batman potrebbe farlo tra 22 minuti, ma probabilmente non lo farai. Se chiami un esperto, lascia che ti dica quanto tempo deve essere necessario per risolvere la tua sfida. È possibile scegliere di non risolverlo dopo che ha finito, ma risolvere le sfide EPM, anche quelle tecniche, raramente richiede solo pochi minuti. Dopo tutto, Batman doveva farlo in 22 minuti perché sono stati assegnati 8 minuti per le pubblicità, e sono essenziali.

3. Il commissario Gordon non ha mai detto a Batman la soluzione, solo il problema. Troppo spesso riceviamo una chiamata da un amministratore di EPM in preda al panico che sa che devo applicare una patch, scrivere un report ed eseguire il training di due persone. Ascolto sempre questo pazientemente e poi chiedo al cliente di descrivere il problema come mi hanno appena descritto la soluzione. Prima di prendere il telefono per chiamare un esperto, pensa prima a quale problema vuoi mettere sul loro tavolo.

Conclusione

Hai davvero bisogno di usare il Batphone. Chiedi in giro. Non chiedere a un solo esperto di consulenza e non ottenere una sola soluzione possibile. Chiedi ai tuoi colleghi o ad altri colleghi del settore chi sanno chi potrebbe prendere una chiamata batphone e parlare con almeno due di loro. È un buon controllo della realtà per vedere come un esperto e un altro potrebbero gestire il problema. Ricordate, Batman potrebbe essere stato incredibile, ma ci sono molti supereroi tra cui scegliere!

Informazioni sull'autore

Chris Vandersluis è il presidente e fondatore di Montreal, HMS Software, un partner microsoft certificato. Ha una laurea in economia presso la McGill University e oltre 30 anni di esperienza nell'automazione dei sistemi di controllo del progetto. È un membro di lunga data del Project Management Institute (PMI) e ha contribuito a fondare i capitoli di Montreal, Toronto e Quebec del Microsoft Project Users Group (MPUG). Le pubblicazioni per le quali Chris ha scritto includono Fortune, Heavy Construction News, computing Canada magazine, e PMNetwork di PMI, ed è un giornalista regolare per Project Times. Insegna Advanced Project Management alla McGill University e spesso parla alle funzioni dell'associazione di gestione dei progetti in America del Nord e in tutto il mondo. HMS Software è l'editore del sistema timekeeping orientato al progetto TimeControl ed è partner di Microsoft Project Solution dal 1995.

Chris Vandersluis può essere contattato via e-mail all'indirizzo: chris.vandersluis@hms.ca

Per altre informazioni sugli articoli correlati a EPM di Chris Vandersluis, vedere il sito guida EPM di HMS (https://www.epmguidance.com/?page_id=39).