Superare il periodo di dimezzamento (t 1/2): controllare la soluzione PPM dopo l'implementazione
Questo articolo fa parte della nostra raccolta "From the Trenches". Viene descritto come configurare un framework per configurare un modello di governance per la soluzione di gestione del portfolio di progetti . Include anche un piano di governance di esempio che può essere usato come punto di partenza per configurare la propria strategia di governance.
Per scaricare la versione Word di questo articolo, vedere Beat the Half-life (t 1/2): Governing Your PPM Solution, Post-Implementation: white paper.
Per altri articoli, vedere white paper "From the Trenches".
Beat the Half-life (t 1/2): Governance della soluzione PPM, post-implementazione
Introduzione
In Fisica radioattiva, l'emevita (t1/2) è la quantità di tempo necessaria affinché una quantità cada a metà del valore misurato all'inizio del periodo di tempo. (Ref: https://en.wikipedia.org/wiki/Half-life).
Quindi, come si applica alla nuova soluzione Project Portfolio Management (PPM) implementata di recente? Il motivo per cui si applica è che la soluzione PPM, implementata correttamente, ha una data di scadenza. Se non si prende il tempo necessario per pianificare, progettare ed eseguire un processo di governance relativo alla gestione della soluzione PPM, è possibile essere certi che la soluzione verrà riempita con dati non aggiornati, modifiche di progettazione non valide, processi non sincronizzati con i processi aziendali effettivi e l'elenco continua. Proprio come un'auto che non riceve mai manutenzione, la soluzione smetterà di restituire il ROI previsto. Gli utenti diventeranno passivi e smetteranno di usare la soluzione o difendono in modo rumoroso una soluzione diversa.
Questo documento descrive un framework per configurare un modello di governance per la soluzione PPM. Viene inoltre fornito un piano di governance di esempio che può essere usato come punto di partenza per configurare la propria strategia di governance.
Cosa e perché
Mentre la parola governance potrebbe significare cose diverse per persone diverse, in fondo, un piano di governance è un set di politiche e procedure autoimpotte, per assicurarsi che l'applicazione sia integra in tutte le aree e produrre il miglior ritorno di valore per l'investimento effettuato sullo strumento.
Perché è necessario avere queste restrizioni, si chiede? È simile alla manutenzione della casa in cui vivi. Immaginate, ogni volta che avete bisogno di qualcosa da fissare o aggiungere alla vostra casa, un altro appaltatore si presenta, e fa il lavoro in modo diverso rispetto al precedente appaltatore. Molto presto si può essere sicuri di finire con finestre non corrispondenti, manopole porta multi-design, e così via. Questo è il motivo per cui è opportuno che i costruttori abbiano tutti quei codici e linee guida da seguire durante la creazione di qualcosa, gli standard dei componenti che devono mantenere e così via.
Analogamente, una volta attiva la soluzione PPM, verranno apportate diverse modifiche, miglioramenti e rimozione delle funzionalità. A meno che non si imposti uno standard su "come" vengono eseguite queste modifiche, è possibile essere certi di una soluzione che si trova nel caos completo lungo la strada.
Aree di governance
Quando si inizia a prendere in considerazione la configurazione di un piano di governance per la soluzione PPM, è necessario considerare quali aree si vuole effettivamente gestire. Esistono molte teorie e modelli per stabilire un piano di governance per le soluzioni aziendali ed è possibile scegliere quello migliore adatto all'organizzazione. In questo articolo verrà illustrato uno di questi modelli che si adattano alla maggior parte delle implementazioni PPM.
Il modo più semplice per individuare le aree di governance necessarie consiste nel considerare le aree in cui è probabile che si verifichino modifiche e quindi configurare un piano di governance per la gestione di tali modifiche.
Nota
Anche per gli elementi che non sono "modifiche" di per sé e piuttosto per la manutenzione standard (ad esempio: aggiunta di nuovi utenti, aggiornamento di periodi della scheda attività e così via), è importante registrare un set di procedure standard.
In generale, esistono quattro aree chiave in cui potrebbero verificarsi modifiche per la soluzione PPM.
Governance delle informazioni
Quando la soluzione PPM viene implementata, è ragionevole presupporre di iniziare con dati "master" validi nella soluzione. Ad esempio, questi includono Dettagli risorsa organizzazione, Calendari organizzazione, campi personalizzati correlati e così via, essenzialmente tutti i dati "master" che consentono di usare la soluzione PPM in modo efficace. Tuttavia, man mano che si usa la soluzione, gli utenti modificano i reparti, alcuni lasciano l'organizzazione, i calendari devono essere aggiornati con nuove festività, è necessario creare periodi di report di tempo, potrebbe essere necessario modificare i periodi fiscali e l'elenco continua. Ovviamente, se questi dati non vengono mantenuti aggiornati, tutti i report saranno imprecisi, così come la configurazione della sicurezza.
La governance delle informazioni si assume la responsabilità di mantenere aggiornati e completi questi dati in modo che il resto della soluzione possa trarre vantaggio da questi dati di base.
Progettare la governance
La seconda area che deve far parte del piano di governance è la manutenzione della "progettazione" della distribuzione PPM. Man mano che si continua a usare la soluzione, ci saranno richieste per modificare la progettazione della soluzione. Questi potrebbero verificarsi da un gruppo specifico che vuole cambiare il modo in cui usano lo strumento o che vogliono sfruttare le nuove funzionalità. Un esempio classico consiste nel cambiare il modo in cui viene eseguita la creazione di report temporali. È possibile che si sia scelto di utilizzare un metodo %Work Complete, mentre con un nuovo reparto aggiunto potrebbe essere necessario passare al metodo "ore lavorate per periodo" per motivi di integrazione con altre soluzioni finanziarie. La domanda è quindi chi valuterà l'impatto di questa modifica nella soluzione e come verranno implementate le modifiche.
La governance di progettazione è il piano per gestire le modifiche che influiscono sulla progettazione complessiva della soluzione PPM.
Governance dei processi
È facile pensare a questo settore della governance come parte della governance della progettazione, perché la maggior parte del tempo, il processo e la progettazione vanno di pari passo. Tuttavia, in termini olistici, questa area copre più del semplice design. Si occupa della governance dei processi all'interno e all'esterno della soluzione PPM che ne determinano l'efficacia.
Si prenda, ad esempio, uno scenario in cui il PMO dovrebbe inviare un report ai dirigenti ogni mercoledì. È possibile che sia stato configurato un processo per assicurarsi che le schede attività vengano inviate ogni venerdì entro una determinata ora e che tutti i project manager aggiornino e pubblichino i piani di progetto entro lunedì mattina, prima che si verifichi la creazione del report. Si supponga ora che il senior management richieda l'invio di report lunedì am anziché ogni mercoledì am. In questo modo viene attivata una modifica del processo relativa all'uso della soluzione PPM, anziché una modifica alla progettazione della soluzione PPM stessa.
Questi tipi di modifiche dovranno essere regolati da un set standard di regole, definito come parte della governance dei processi.
Governance dell'infrastruttura
Questa è un'altra quelle aree che sembrano essere facili da silo, tuttavia possono sovrapporsi alle altre tre aree menzionate sopra. In poche parole, l'infrastruttura che supporta la soluzione PPM deve essere mantenuta con l'installazione. Alcuni esempi degli elementi chiave che devono rientrare in questo tipo di modello di governance sono:
Installazione di Service Pack o aggiornamenti cumulativi.
Installazione di nuovi componenti aggiuntivi o applicazioni.
Aggiornamento dell'infrastruttura (aggiunta di server applicazioni, server Web e così via) per risolvere i problemi di prestazioni.
Modifiche all'infrastruttura dovute a modifiche apportate ad altre applicazioni nelle organizzazioni , ad esempio la virtualizzazione di tutti i server.
Da un lato dell'equazione, la decisione di installare qualcosa o meno è basata esclusivamente sul merito (ad esempio, se influirà negativamente su qualsiasi soluzione di produzione corrente). L'altro lato dell'equazione di qualsiasi infrastruttura consiste nell'esaminare le modifiche "processo" o "progettazione" che saranno causate dall'installazione. In alcuni casi, la modifica dell'infrastruttura potrebbe essere il risultato di eventuali modifiche nelle altre aree. Come accennato in precedenza, mentre il nostro tentativo è quello di classificare ogni cambiamento come parte di una di queste aree, è possibile che alcune modifiche si sovrappongano completamente a tutte e quattro le aree.
Domande chiave
Indipendentemente dall'area di governance che si sta tentando di configurare, è necessario rispondere a tre domande chiave che costituiranno il nucleo del piano di governance.
Come fa il team PPM a sapere che deve verificarsi una modifica (ad esempio, qual è il trigger per queste modifiche?). A volte, queste modifiche non vengono "attivate" di per sé, ma fanno parte dell'assistenza e dell'alimentazione regolari dell'implementazione PPM (ad esempio, l'aggiunta di nuove visualizzazioni per Il Centro progetti)
Chi approva queste modifiche, non solo dal punto di vista del ritorno sugli investimenti aziendali, ma anche dal punto di vista della governance?
Chi apporta effettivamente queste modifiche? Per molte di queste modifiche, sono coinvolti più team. In alcune organizzazioni alcune delle funzionalità di modifica vengono trasferite a un subset di utenti finali, in base alle esigenze aziendali. In questi tipi di scenari diventa ancora più importante definire chi apporti effettivamente le modifiche.
Governance Team
Un componente chiave di qualsiasi strategia di governance è il team che esegue effettivamente il piano di governance. Anche se ci sono diversi modi per tagliare e dadi su come dovrebbe apparire questo team di governance, l'unica raccomandazione su cui tutte le scuole di pensiero saranno d'accordo è di mantenerlo semplice.
Di seguito è riportato un modo per configurare la struttura del team:
Proprietari dell'area di governance Questi sono i proprietari di ognuna delle aree di governance indicate in precedenza in questo articolo. In generale, qualsiasi richiesta di modifica che influirà sull'area designata per questi proprietari di governance diventerà responsabilità di questi proprietari. Sarà il loro ruolo valutare, fornire raccomandazioni, configurare la governance per le nuove funzionalità e così via.
Comitato centrale per la governance (CGC) Si tratta del team di decision maker che può approvare o rifiutare le raccomandazioni formulate dai proprietari della governance. Avere un comitato di governance centrale non solo aiuta a ridurre la burocrazia, ma aiuta anche a portare tutte le idee in una piattaforma comune e a valutarle a vicenda.
Come accennato in precedenza, a seconda delle dimensioni dell'implementazione e dei processi correnti esistenti in un'organizzazione per altre applicazioni, la definizione e la struttura di questi ruoli potrebbero essere più piccole o maggiori. Il punto importante è che per avere almeno una struttura minima in atto.
Altri componenti chiave
Alcuni degli altri componenti chiave per una strategia di governance efficace includono, ma non si limitano a:
Soluzione Richiesta di lavoro che consente agli utenti di richiedere modifiche, funzionalità e funzionalità. Può essere semplice come un elenco di SharePoint o una soluzione di richiesta di lavoro interna attualmente usata.
Un processo per la gestione delle modifiche, che include revisioni di IT, governance, CGC e altre funzioni aziendali coinvolte.
Processo per l'implementazione effettiva delle modifiche. Potrebbe trattarsi di una semplice progressione delle modifiche da sviluppo a soluzioni di test a soluzioni di produzione o un Release Management completo in base agli standard dell'organizzazione.
Il processo
Verranno ora esaminati tutti i componenti descritti in precedenza come parte della creazione di una strategia di governance e verrà creato un processo che lo circonda. Ecco come potrebbe apparire (potrebbe variare in base ai requisiti dell'organizzazione).
Conclusione
Anche se è difficile prevedere e pianificare ogni modifica che può verificarsi nella soluzione PPM, è importante avere una strategia in tempi flessibili e scalabili per qualsiasi scenario.
Come considerazioni, prendere in considerazione i seguenti approcci di base di buon senso per la creazione della strategia di governance.
Un piano di governance non deve necessariamente essere un tome con una terminologia molto oscura e un linguaggio che nessuno può usare nella vita quotidiana. Può essere semplice come un foglio di Excel, con risposte rapide alle domande chiave (affrontate nelle domande chiave).
Tenere presente che un piano di governance non è una documentazione della configurazione. Si tratta di un "piano" per proteggere, mantenere e modificare (se necessario) la configurazione.
Un piano di governance deve essere facile da implementare e deve integrarsi bene nei processi esistenti dell'organizzazione. Non è necessario reinventare la ruota.
Comprendere che la governance della soluzione PPM è un processo in continua evoluzione. È importante non essere appeso con paralisi dell'analisi. Iniziare in piccolo, offrire valore e quindi aumentare le prestazioni.
Informazioni sull'autore
Prasanna Adavi (PMP, MCTS, MCITP, MCT) è consulente e formatore senior di Enterprise Project Management (EPM) specializzato nelle piattaforme Microsoft Project, Microsoft Project Server e Microsoft SharePoint. Il suo obiettivo principale è quello di creare e abilitare soluzioni aziendali per aiutare le organizzazioni a ottenere il miglior ritorno sui propri investimenti.
Ha anche una vasta esperienza nei progetti leader end-to-end in un'ampia gamma di domini e verticali, tra cui IT, ERP (SAP), Produzione, Sviluppo di applicazioni, Automotive e Servizi creativi. È un relatore abituale di vari eventi di Project Server, EPM e SharePoint in tutto il paese/area geografica e collabora regolarmente alla community di SharePoint ed EPM.
Prasanna è un blogger regolare (https://www.prasannaadavi.com) e gestisce anche un podcast bi-settimanale (https://www.msprojectpodcast.com), incentrato principalmente sulle soluzioni Microsoft Project e Project Server. Prasanna è senior consultant presso EPMA (https://www.epmainc.com).