Assistenza GPS nella roadmap all'implementazione di EPM
Questo articolo fa parte della nostra raccolta "From the Trenches". Descrive come creare una "roadmap" per la distribuzione di Enterprise Project Management quando si prevede di implementare EPM. Vengono descritti in modo brillante i fattori da prendere in considerazione per pianificare il percorso di implementazione.
Per altri articoli, vedere white paper "From the Trenches".
Assistenza G.P.S. nella roadmapping di una distribuzione EPM
Nell'ultima colonna ho parlato dell'uso di un approccio in più fasi per creare i piani per una distribuzione della soluzione Microsoft Enterprise Project Management (EPM). Oggi verrà affrontata la creazione di una roadmap per la distribuzione di EPM come parte del piano di progetto.
Se sei stato a Microsoft Live Maps, sai che le indicazioni stradali richiedono due cose: una destinazione e un punto di origine. Quando si applica questa analogia a una distribuzione EPM, è necessario considerare in termini simili:
Punto di origine definito in termini di tecnologia, processo e personale
Destinazione definita in termini di business e con priorità
Potremmo anche voler definire alcune "stazioni way" o fermate intermedie in cui è possibile raggruppare, scattare foto, godersi il paesaggio per un po 'e rifornire i vostri rifornimenti per la prossima tappa del viaggio.
Quando si crea una roadmap o indicazioni stradali, è piuttosto comune avere due scale. Manteniamo la prossima tappa del viaggio in grande dettaglio, fino a un percorso turn-by-turn. Tuttavia, potremmo anche mantenere una mappa di livello superiore dell'intero viaggio in modo meno dettagliato per mantenere la gamba corrente nel contesto dell'intero viaggio. In termini di gestione dei progetti, questa operazione viene chiamata "pianificazione delle onde in sequenza".
"Indicazioni stradali"
Quando si crea una roadmap di distribuzione di EPM, si inizia sempre con la visione o l'intenzione di dove l'azienda si sta dirigendo in termini di sforzi EPM. Questo ci offre la destinazione di cui avremo bisogno per fare indicazioni esattamente come farebbe Microsoft Live Maps.
Se ci si limitasse a chiedere: "Cosa vuoi?" la risposta viene quasi sempre in termini di soluzione. Persone è probabile che dica "Ho bisogno di un report simile al seguente" o "La nostra azienda ha bisogno di analisi del portafoglio".
Per quelli di noi nel settore delle soluzioni, sappiamo che questi tipi di note di progettazione sono pieni di rischi. I nostri consulenti vengono addestrare ad ascoltare i clienti che descrivono il loro problema come soluzione. "Questa è una soluzione a un problema", diremo, "non il problema. Definiamo ora il problema."
Quindi tendiamo a non chiedere "Cosa vuoi?" Le domande che possono essere utili durante un'idea possono invece includere:
"Quale decisione aziendale non è ora possibile prendere o è in grado di prendere solo con grande difficoltà, il cui processo sarebbe reso più semplice a seguito di questa distribuzione EPM?"
Oppure:
"Quale aspetto dell'organizzazione si ritiene possa essere reso più efficiente tramite un aumento della velocità effettiva o una riduzione dello sforzo attraverso questa distribuzione EPM?"
Ora, di chi dovremmo porre queste domande? Perché, le persone che prendono queste decisioni, naturalmente! Se avete mai avuto un minivan pieno di bambini e si voltò per chiedere loro dove si dovrebbe andare come destinazione, si sa che si otterrà 50 risposte.
Allo stesso modo, è necessario assicurarsi che i decision maker dell'organizzazione siano una parte fondamentale di questo processo o che si corre il rischio di scegliere una direzione verso cui il "driver" non è pronto a spostarsi. C'è un ulteriore vantaggio per portare i dirigenti senior nel processo di roadmapping EPM in questo momento. Oltre a essere un partecipante critico nella scelta della direzione in cui deve andare la distribuzione di EPM, è anche in grado di farsi un'idea dell'entità del progetto. Una delle sfide più comuni e difficili per una corretta distribuzione di EPM è il supporto della gestione a lungo termine. Alcuni alti dirigenti non hanno considerato quanto questo potrebbe cambiare le procedure e le procedure esistenti e quanto potrebbe essere dirompente, anche temporaneamente. Potrebbero anche non avere un apprezzamento di quanto sforzo possa essere un progetto di cambiamento di cultura come EPM.
Durante il nostro lavoro con i senior management, la gestione dei progetti e forse il personale di linea, cerchiamo di connettere le decisioni aziendali o l'efficienza aziendale con il processo e la tecnologia. È necessario creare un processo per soddisfare questo requisito? Cosa dovrebbe fare? Esiste una funzione di sistema che esiste o deve essere creata per gestire tale decisione aziendale? Cosa sarebbe necessario fornire?
L'analisi di base dei sistemi è fondamentale in questa fase. Si parte dalla decisione aziendale "output" e si torna agli elementi di dati necessari per prendere tali decisioni. In alcuni casi, i dati di base semplicemente non sono presenti e questo comporta che l'elemento della roadmap venga contrassegnato come "ad alto rischio". Dopo tutto, è ora necessario includere la raccolta di dati in un nuovo formato o struttura per acquisire questi nuovi elementi di dati prima di poter anche pensare di offrire un processo aziendale migliore e questo può essere un ordine alto in alcuni casi.
Abbiamo un'altra cosa da fare prima di chiudere il processo di destinazione e questo sta dando la priorità ai diversi elementi della visione finale. È molto comune pensare all'inizio del processo di roadmapping che le priorità andranno in un modo, ma scopriranno che mentre si va a registrarle effettivamente che vanno in modo molto diverso. È interessante notare che, quando tutti hanno concordato quali obiettivi sono inclusi nella nostra destinazione, c'è un notevole consenso su quali dovrebbero essere le priorità principali.
La prossima cosa di cui abbiamo bisogno per le indicazioni stradali è un punto di origine e lo gestiamo attraverso un inventario di dove l'organizzazione è ora in relazione agli obiettivi che abbiamo scelto.
Esaminiamo il personale esistente. Sono addestrati nella gestione dei progetti per i loro ruoli specifici? Abbiamo personale sufficiente con esperienza sufficiente per raggiungere gli obiettivi che sono stati stabiliti? Tenere presente che è necessario esaminare più misure in questo caso perché persone diverse avranno un ruolo diverso nel processo di gestione dei progetti aziendali finale. Non ha senso formare ogni dipendente a un programma di pianificazione del progetto se, in realtà, non sarà mai responsabile di creare pianificazioni. Per impostazione predefinita, si pensa a quattro ruoli: Amministratore, Project Manager, Singola risorsa ed Esecutivo. Se sono coinvolte schede attività, pensiamo anche ai supervisori come quinto ruolo. Naturalmente, a seconda della destinazione definita nel processo di previsione originale, i ruoli possono essere molto diversi. Questo cambia profondamente il processo di inventario delle competenze, motivo per cui iniziamo sempre definendo la destinazione prima di pensare al punto di origine.
Esaminiamo anche il processo esistente. Esiste un processo di gestione dei progetti dichiarato o documentato? Come viene mantenuto? Chi ne è responsabile? Se è già stato creato un Project Management Office, questo impegno è incentrato su questo aspetto. Dopotutto, non è opportuno creare nuove procedure se sono già presenti procedure e processi esistenti che sono già efficaci. È possibile inventariare i processi esistenti che si trovano sia all'interno del processo di gestione del progetto corrente che all'esterno, a seconda degli obiettivi finali dell'ambiente EPM.
Ad esempio, è possibile che si sia deciso che la gestione dei contratti sarà un elemento significativo del nuovo ambiente EPM e che questo non è mai stato parte dei processi di gestione dei progetti all'interno di questa organizzazione. Tuttavia, se si guarda un po' più lontano, è possibile che l'organizzazione disponga di un set di controlli sicuro per la gestione dei documenti e del flusso di lavoro esistente che già sposta i documenti, ad esempio in SharePoint. Si tratta di un processo ideale per l'adozione e, se necessario, l'adattamento per garantire che questo aspetto del nuovo ambiente di gestione dei progetti aziendali possa essere potenziato. Ciò comporta un vantaggio triplo. In primo luogo, non è necessario spendere lo sforzo per creare un nuovo processo. In secondo luogo, sappiamo che il personale ha già le competenze e le abitudini per utilizzare il processo in questo modo, il che significa nessun sforzo di formazione o sforzo per far rispettare il personale. Infine, non si ha la difficile situazione di tentare di creare un processo separato che potrebbe essere in contrasto con un processo esistente per la gestione dei documenti, ad esempio i contratti.
Sappiamo che una delle nostre maggiori sfide sarà la conformità. Non creare il sistema, ma fare in modo che tutti lo usino e lo usino in modo coerente. Più è possibile adottare le abitudini, le procedure e le procedure esistenti incorporate nell'organizzazione, la conformità diventa più semplice.
Infine, è necessario un inventario della piattaforma tecnologica. Poiché la soluzione Microsoft EPM si basa su una piattaforma tecnologica, è probabile che trovi già una parte di tale tecnologia, ma è anche possibile che l'organizzazione dovrà aggiornare parte della sua piattaforma per consentire il funzionamento della soluzione che stai progettando. SharePoint e SQL Server sono elementi ovvi della distribuzione di Microsoft Office Project Server, ma potrebbe anche essere necessario verificare la compatibilità del browser (tutti usano la versione più recente di Internet Explorer?), lo stato di sicurezza (il sistema si troverà verso l'esterno?), quale versione di SQL Server viene distribuita (sono servizi OLAP o SQL Server Reporting Services già in uso?). Potrebbe anche essere necessario prendere in considerazione altri sistemi con cui è necessario eseguire l'interfaccia o l'integrazione. Come si ottiene l'accesso a tali sistemi in produzione?
Le dimensioni del sistema pianificato possono anche richiedere l'esame dell'hardware, della rete e di altri elementi dell'infrastruttura per garantire che il sistema abbia la struttura necessaria al suo arrivo.
Come per qualsiasi sistema aziendale, è consigliabile pianificare sia un'area di produzione che un'area di staging in modo che gli aggiornamenti e i miglioramenti possano essere creati nel lab anziché nel sistema live nel tempo. Potrebbe anche essere necessario fare piani per una fase pilota o di verifica del concetto; qualcosa di cui parlerò di più nella mia prossima colonna.
"Ricalcolo della route"
Quando l'unità G.P.S. nella mia auto scopre che ho perso un turno, la voce di una signora molto bella dice "Percorso di ricalcolo". Pochi istanti dopo, la linea attraverso la mia mappa cambia e ho nuove direzioni. In una distribuzione EPM è necessario essere pronti per una deviazione o un turno bloccato per le riparazioni. Forse ci siamo persi l'uscita dell'autostrada. Come affrontiamo la ripianificazione? Ci sono due cose da chiedere quando vai fuori rotta: prima, stai ancora andando nello stesso posto? In secondo luogo, come ci arriviamo da qui? Una delle mie citazioni di gestione dei progetti preferite su questo argomento proviene da Napoleone Bonaparte, che una volta disse: "Un piano di battaglia dura fino al contatto con il nemico".
In una distribuzione EPM come si applica questo stesso principio? Prima di tutto, hai bisogno di una misura per determinare se non sei più in rotta. Se un membro del team ha un appuntamento dentistico di emergenza domani ed è assente dall'ufficio per quattro ore, dovremmo lasciare che tale discrepanza cambi tutte le attività downstream, riprogrammare tutti da domani a mezzogiorno fino alla fine del progetto e quindi inviare un messaggio di posta elettronica a tutti con i loro nuovi orari di assegnazione?
Assolutamente no.
Una discrepanza di quattro ore per una risorsa nell'arco di sei mesi di un progetto che coinvolge decine di persone non è sufficiente per giustificare la modifica del percorso. Per avviare qualsiasi tipo di progetto aziendale è necessario impostare soglie di avanzamento accettabili. Il mondo aerospaziale e della difesa sta trovando un nuovo termine per questo ultimamente, "Tripwires", che è molto descrittivo. È possibile stabilire quali criteri indicano che il percorso deve essere ricalcolato. Esistono diverse metriche o misure tipiche da considerare. In primo luogo, se il costo di completamento previsto varia di oltre X% rispetto al budget originale, questo potrebbe costituire una revisione del piano di progetto. È possibile eseguire la misura del costo in ore di lavoro o denaro. Entrambi sono efficaci. Ad esempio, se la data di fine prevista varia di più di X giorni rispetto alla data di fine pianificata in origine, potrebbe trattarsi di una revisione del piano di progetto.
Si potrebbe anche decidere che la mancanza di determinate attività cardine chiave di più di un determinato numero di giorni è un tripwire, oppure si potrebbero identificare determinati rischi realizzati come tripwire o si potrebbe determinare che un cambiamento di alcuni membri chiave del team di progetto, ad esempio lo sponsor esecutivo, è un tripwire. È più importante impostare alcuni criteri piuttosto che ottenere i criteri esattamente corretti. Ricorda anche che dovrai misurare in base a questi criteri per tutta la durata del progetto, quindi se scegli 50 o 100 metriche diverse, potresti passare più tempo a misurare il progetto che a fare il progetto.
Dopo aver stabilito di essere fuori rotta, il modo migliore per tornare in pista è eseguire una revisione del piano di progetto. È consigliabile includere la rappresentazione sia del gruppo originale di senior management che ha contribuito a stabilire la destinazione in primo luogo che dal gruppo all'interno del team di gestione del progetto che ha contribuito a fare l'inventario originale. Le revisioni del piano di progetto possono essere offuscate nell'assegnare la colpa del motivo per cui il progetto è fuori pista e del motivo per cui è stato attivato un determinato tripwire. Tale sforzo può essere estremamente controproduttivo. È consigliabile concentrarsi sulle domande seguenti:
Che cosa è successo?
Dove siamo finiti? Qual è il nostro punto di origine attuale?
Siamo ancora impegnati nella nostra destinazione originale o c'è un motivo convincente per rivedere tale processo o anche ripetere il processo di previsione?
È necessario reimpostare una delle fasi intermedie o intermedie?
È necessario modificare uno dei team di progetto?
È necessario reimpostare una delle metriche tripwire?
Le domande che si sono trovate meno produttive includono:
Di chi è la colpa che siamo qui? Chi è responsabile? Chi è la colpa?
Come facciamo a tornare in pista? tornare al vecchio piano?
Il motivo più comune per una revisione del piano di progetto è che le priorità dell'organizzazione cambiano. Ad esempio, gli elementi progettati per essere nella fase 3 vengono richiesti nella fase 2. Questo è in genere un segno di una dinamica sana all'interno dell'organizzazione e il risultato di persone che iniziano a pensare seriamente alle implicazioni della distribuzione del sistema EPM.
Maltempo
Prima di iniziare con un lungo viaggio in auto, è probabile che controlli il Canale Meteo (o weather.msn.com) per assicurarti che nessun tempo inclemente influisca sul tuo viaggio. I rischi fanno parte della vita. Ricorda, se non ci fossero rischi, non ci sarebbe bisogno di project manager! La pianificazione dei rischi più evidenti non è un processo complicato. Iniziare dall'inizio del processo di progettazione e, quando si esaminano tutti gli elementi della destinazione che si sta progettando, chiedere al gruppo quali ostacoli possono essere considerati per raggiungere questa destinazione. In alcuni casi i rischi saranno significativi. Non è raro che un'organizzazione desideri un determinato risultato, solo per scoprire che i dati non elaborati necessari per fornire tale risultato non sono mai stati raccolti e che potrebbe esserci una notevole resistenza alla raccolta di tali dati.
In un esempio è stata trovata un'organizzazione che voleva pianificare la capacità delle risorse. Ciò avrebbe richiesto una contabilità completa di tutta la disponibilità delle risorse di tutto il personale del progetto e una contabilità completa di tutti i possibili carichi di lavoro che potevano essere applicati a tale personale. Quando abbiamo chiesto se entrambi erano disponibili, ci è stato detto che erano disponibili, ma solo per due quinti dell'organizzazione. Quando poi abbiamo scoperto che i tre quinti dell'organizzazione per cui i dati non erano disponibili non erano nemmeno rappresentati alla riunione di previsione, abbiamo detto: "Indovina. I problemi riscontrati con la pianificazione della capacità delle risorse si trovano in queste tre divisioni." Naturalmente lo erano, e abbiamo dovuto identificare l'iscrizione dei capi divisione di tali divisioni come una fase separata del progetto e un rischio molto elevato.
Mentre si passa a collaborare con la gestione del progetto e il personale di linea nel processo di inventario, chiedere durante i colloqui eventuali rischi che il personale potrebbe essere in grado di identificare.
Dopo aver identificato i rischi, è importante organizzarli. Se non è stato fatto prima, le informazioni più di base saranno le più preziose. Includere:
Breve descrizione del rischio
Area o fase del progetto che può influire
La gravità del rischio se i criteri sono realizzati
Infine, una delle operazioni più importanti che è possibile eseguire consiste nell'aggiungere alcuni dettagli sulla mitigazione dei rischi. Pensare solo a un rischio è un fattore di mitigazione enorme, ma mentre la distribuzione EPM è ancora agli inizi, inserire alcune note su come gestire un particolare rischio durante il progetto può essere prezioso. È comune prendere decisioni in fretta in un contesto emotivo quando si realizzano i rischi. Avere alcune note che sono state pensate mentre le teste più fredde prevalgono può essere utile.
Guidiamo l'auto che stiamo costruendo
Ecco un suggerimento su come creare una roadmap che può pagare enormi dividendi: usare Project Server e la soluzione Microsoft EPM per creare e gestire il piano di roadmap. Sembra ovvio, forse, ma è abbastanza raro che le organizzazioni lo facciano qui.
Una volta un senior manager mi ha detto che il suo staff di progetto gli aveva chiesto se pensava che l'uso della soluzione Microsoft EPM per distribuire la soluzione Microsoft EPM non fosse eccessivo. "Se costruissimo aerei a reazione per vivere, non li volemmo al lavoro", hanno detto. "Stai scherzando?", Ha risposto. "Se potessi pilotare un aereo a reazione per lavorare, lo farei ogni giorno!"
In effetti, l'uso della soluzione Microsoft EPM per il team di distribuzione EPM è un'ottima idea.
L'installazione di Project Server e degli altri elementi della soluzione Microsoft EPM non è un'enorme sfida tecnica e con il minimo assoluto di configurazione è possibile essere operativi con un piccolo team di distribuzione come utenti entro un paio di giorni. Questo è un ottimo modo per gli utenti che diventeranno i promotori della distribuzione di acquisire familiarità con l'uso e i vantaggi del sistema prima che arrivi alle scrivanie della maggior parte del personale.
Questa distribuzione non deve essere l'ambiente di produzione. Quasi certamente lo si configura e lo si personalizza per soddisfare la visione della destinazione originale. Quasi certamente non si lavorerà a cose come la pianificazione di più progetti o la pianificazione della capacità delle risorse o l'ottimizzazione del portfolio nell'iterazione della distribuzione EPM di Project Server, ma sarà possibile offrire un sistema in grado di offrire grandi vantaggi. È consigliabile:
Eseguire una pianificazione di onde in sequenza come progetto pubblicato.
Una pianificazione delle onde in sequenza evidenzia la fase corrente in modo dettagliato e le fasi future come più di un riepilogo. Ciò consente ai membri del team di sapere su cosa devono lavorare ora e di visualizzare il progetto in un contesto più ampio.
Gestire il documento di visione nell'area di lavoro progetto.
L'area di lavoro progetto è un sito di SharePoint associato al progetto che per impostazione predefinita include un'area per problemi, rischi e documenti. Perché non inserire tutti i documenti del progetto per il progetto di distribuzione EPM e creare il controllo della versione di SharePoint in modo da poter sempre tornare alla versione originale?
Inserire le firme cardine e i "cancelli" nei risultati finali dell'area di lavoro del progetto.
Si tratta di un semplice elenco di attività che è possibile collegare alle attività in Project Server. Fornirà una visualizzazione di fascia molto alta del progetto ed è uno strumento facile da usare per la gestione delle soglie per determinare quando si va "fuori rotta".
Inserire la gestione delle modifiche nell'area di lavoro di Project come problemi.
La gestione del cambiamento è una delle grandi sfide dei progetti tecnologici. Man mano che si presentano nuovi suggerimenti per le modifiche al progetto, inserirle nell'area Problema come potenziale modifica da gestire. Aggiungendo alcuni campi a questa area è possibile ottenere un elenco di elementi con priorità elevata e chi ne è responsabile in qualsiasi momento.
Inserire i rischi del progetto nell'area di lavoro del progetto.
Oltre a documenti e problemi, l'area di rischio dell'area di lavoro è il luogo ideale per aggiungere i rischi e i piani di mitigazione. In effetti, la schermata predefinita contiene tutti i campi pronti per l'uso.
Sono stati raggiunti gli obiettivi prefissati?
"Quasi. Ci saremo presto.
Una distribuzione EPM può portare un'organizzazione in così tante posizioni diverse che non c'è modo di pubblicare semplicemente la pianificazione predefinita per tutti. Ma alcuni minuti di ricerca su Internet possono fornire molti esempi possibili per diverse parti del progetto. Se riepilogo l'esercizio di roadmap precedente, è probabile che si finisca con un progetto con alcune fasi ovvie:
Esercizio di roadmap
Provisioning (scegliere la destinazione)
Inventario dei processi esistenti (Identificare il punto di origine)
Inventario del personale esistente (identificare il punto di origine)
Inventario della tecnologia (Identificare il punto di origine)
Distribuzione della soluzione EPM per il team EPM
Fase 1
Design
Configurazione, personalizzazione, documentazione
Distribuzione pilota
Formazione
Implementazione
Rivedere la fase 1 e modificare la fase 2 in base alle esigenze
Fase 2
Fase 3
Fase 4
Ritorno a capo del progetto
L'applicazione di un esercizio di roadmap alla distribuzione di EPM può cambiare l'esperienza da caotica a gestibile molto rapidamente. Ricorda solo di scegliere prima la destinazione, di individuare il punto di origine successivo e di tracciare il percorso tra di loro.
Felice viaggio!
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).