EPM: centralizzato o decentralizzato?

Questo articolo fa parte della nostra raccolta "From the Trenches". Descrive in che modo le organizzazioni devono comprendere i problemi che stanno cercando di risolvere quando decidono di implementare un sistema di gestione dei progetti. A volte la distribuzione di un sistema di gestione dei progetti centralizzato potrebbe non essere la risposta migliore.

Per scaricare la versione di Word di questo articolo, vedere EPM-Centralized or Decentralized?.

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

EPM - Centralizzato o decentralizzato?

Sono un sostenitore di Enterprise Project Management da quando sono entrato per la prima volta nel settore della gestione dei progetti nei primi anni '80. Si potrebbe pensare, quindi, che io voterei sempre sul lato della gestione centralizzata dei progetti, ma non è sempre così. Verrà illustrato per un attimo il significato di Enterprise Project Management.

EPM può significare molte cose diverse per persone diverse. In altri articoli di questa colonna è già stato illustrato come l'obiettivo di una distribuzione EPM possa essere la gestione dei documenti per un'organizzazione e le pianificazioni integrate per la successiva. Enterprise Project Management, tuttavia, ha alla base l'idea che le persone debbano interagire tra loro nell'esercizio di gestione dei progetti. Ciò significa che il project manager e/o il team di gestione del progetto non funzionano completamente in modo indipendente. Ma questo significa che l'unico modo per ottenere questa "interazione" è avere un sistema centralizzato di pianificazione dei progetti? Non necessariamente. Per alcune organizzazioni, la sfida di gestione dei progetti potrebbe essere l'impossibilità di produrre report di riepilogo e di gestione dei progetti a livello aziendale a causa della gestione ad hoc di tutti i progetti. In questo caso, EPM potrebbe essere ottenuto solo con standard di progetto condivisi tra tutto il personale di gestione del progetto. Ciò potrebbe essere ottenuto al meglio con un pool centrale di modelli, materiali di formazione, documenti e standard di report che tutti possono usare. Forse sarebbe sufficiente un semplice sito di SharePoint.

Per alcune organizzazioni, la sfida di gestione dei progetti potrebbe essere una pianificazione personale inefficace a causa di una mancanza di comunicazione tra le risorse su ciò su cui stanno lavorando e su quale sarà il loro prossimo obiettivo. In questo caso, EPM potrebbe essere ottenuto migliorando la comunicazione tra team e team. Gli strumenti possono essere semplici come un calendario condiviso, messaggistica istantanea o un portale condiviso in cui gli utenti possono elencare le priorità.

In alcune organizzazioni, la sfida di gestione dei progetti sta solo ottenendo progressi nella programmazione di progetti di sviluppo. In questo caso, gli strumenti già presenti in un prodotto come Visual Studio Team Services potrebbero essere sufficienti. È piuttosto comune nella programmazione di progetti scoprire che molte attività possono essere completate in quasi tutti gli ordini, quindi i rigori della pianificazione dei percorsi critici potrebbero anche non essere appropriati a seconda del tipo di sviluppo in corso.

Ricordo che alcuni anni fa lavoravo con il reparto di manutenzione di una compagnia aerea. Il personale era autorizzato a scegliere i propri orari all'inizio di ogni mese e se questo non era coordinato (come spesso accadeva), era possibile arrivare a gestire un turno solo per scoprire che nessuno stava lavorando. La loro sfida di gestione del progetto non era "Quando il lavoro sarà completato?" è stato "qualcuno viene a lavorare?" In questo caso, EPM è stato ottenuto implementando uno strumento di pianificazione dei turni.

Anche quando si concentra la sfida EPM sulle pianificazioni dei progetti, non è immediatamente ovvio che la distribuzione di un sistema di gestione dei progetti centralizzato sia l'unica o la risposta migliore. Vale la pena chiedersi quale interazione il personale di gestione del progetto deve avere tra loro. Se devono collaborare regolarmente per risolvere i conflitti di risorse, per vedere quali altre priorità dell'organizzazione stanno arrivando o per vedere come lo stato di avanzamento di un progetto influirà su un altro, quindi esaminare uno strumento come Project Server ha perfettamente senso, ma spesso finisco per interagire con le organizzazioni che non hanno nemmeno posto questa domanda di se stessi.

In alcune organizzazioni sono presenti un numero minimo di utilità di pianificazione e un numero elevato di risorse. Anche in un'organizzazione di buone dimensioni, questa può essere la struttura a seconda del settore e del tipo di progetti da realizzare. Non molto tempo fa ho incontrato un'organizzazione che era sicura di aver scelto la soluzione giusta per la loro sfida EPM. Mi hanno chiesto di articolare la soluzione, ma, come al solito, ho chiesto che prima articolassero il loro problema di gestione del progetto.

Quando hanno finito di descrivere il loro ambiente su una lavagna bianca, era evidente anche per loro che la soluzione che avevano scelto non avrebbe risolto il loro problema.

In questo caso, il problema era una mancanza di avanzamento del progetto segnalata da un ampio pool di subappaltatori. Il cliente ha stabilito che ciò che avrebbe realmente bisogno di fare sarebbe imporre un tipo di orario e di fatturazione della scheda attività ai subappaltatori. Il direttore del programma è stato scoraggiato. "Non saremo mai in grado di farlo entrare nei contratti di subappaltatori", hanno detto. Fortunatamente, era presente un membro del dipartimento delle finanze. "Sai," rispose quella persona, "una clausola che richiede loro di compilare la scheda attività di nostra scelta è già nel contratto di subappaltatori." Problema risolto.

L'idea di affrontare il problema prima di arrivare alla soluzione è quella di cui parlo spesso qui, ma è difficile da adottare. Il pensiero logico determinerebbe che l'ordine di determinazione di una soluzione automatizzata sia:

1. Identificare il problema

2. Definire la soluzione

3. Determinare se (e, in tal caso, come) automatizzare la soluzione

Le dimostrazioni di soluzioni automatizzate su siti Web, video e altrove ci fanno dimenticare questo. Naturalmente, non cerchiamo una soluzione, a meno che non si abbia un qualche tipo di problema, ma le soluzioni automatizzate sembrano così interessanti da finire per farlo:

1. Scegliere la soluzione automatizzata

2. Risolvere il problema di distribuzione della soluzione

3. Risolvere il problema definendo il modo in cui lo strumento automatizzato può essere applicato alla soluzione

4. Provare a ricordare qual era il problema originale

Il nuovo problema diventa la distribuzione della soluzione per un bel po 'di tempo e poi settimane, mesi, o anche un paio di anni lungo la strada qualcuno della direzione superiore chiede quando il problema originale sarà risolto e tutti si guardano piuttosto sorpresi. È stato facile dimenticarlo.

Nel corso degli anni ho consigliato tutti i tipi di possibili soluzioni automatizzate. Oh, Project Server è stata una delle opzioni naturalmente, ma ho anche consigliato una combinazione di Microsoft Project Pro e SharePoint Server. È consigliabile usare una combinazione di Excel e Outlook. È consigliabile usare schede attività di terze parti con Project.

Ho anche una volta consigliato l'uso di una grande lavagna bianca. Onesto. L'organizzazione era quella con cui avevo fatto affari per anni. La persona in questione era in un ruolo immobiliare e ha dovuto rinnovare i contratti di locazione a lungo termine nel settore immobiliare. Quando ho chiesto qual era il problema, era chiaramente un problema di pianificazione. La persona aveva perso alcune scadenze che erano importanti ed era sicuro che uno strumento di gestione dei progetti aziendali avrebbe risolto il problema. L'organizzazione aveva già chiesto che i report fossero distribuiti a diversi dirigenti in modo da non perdere le scadenze future. "Quanti utenti ci sarebbero?" Ho chiesto. "Solo me", rispose. "Quanti di questi progetti ci sono alla volta?" Ho chiesto "Sette o otto", ha risposto. "E quante di queste scadenze cardine si gestiscono per ogni progetto"È molto complicato. Ci sono circa una mezza dozzina di scadenze per ognuna", mi ha detto.

Era già chiaro per me che non dovremmo installare un grande sistema EPM centralizzato per questo povero collega.

"Perché non mettere una grande lavagna bianca nel cubicolo e usare alcuni marcatori colorati per le diverse tappe?" Ho chiesto. "Si potrebbe usare il blu per il primo, il verde per il secondo, il rosso per l'ultimo, ecc."

Ha preso note copiose, affascinato dal concetto. Ho lasciato l'azienda sapendo che quel giorno non avevo venduto alcun servizio o prodotto, ma che avevo lasciato la persona delusa dal fatto che non potesse distribuire il sistema che aveva previsto. Sulla strada di casa il mio telefono squillò in macchina. Era lui. "Potresti spiegare i diversi colori per la lavagna bianca?", Ha chiesto.

Capire quali problemi si sta tentando di risolvere prima di progettare la soluzione e prima di scegliere come automatizzarlo non solo consente di risparmiare denaro. Può risparmiare un'enorme quantità di tempo impiegato a lavorare su elementi dell'organizzazione che non hanno avuto un problema che doveva essere risolto in primo luogo.

Quando i problemi che si sta cercando di risolvere possono essere risolti al meglio con il software centralizzato di gestione dei progetti aziendali, allora nient'altro farà davvero, ma l'attenzione che avrete guadagnato articolando il problema aiuterà anche lì. Il team di distribuzione può creare metriche di esito positivo che consentono al progetto di essere dichiarato un esito positivo quando i problemi sono stati risolti. Centralizzare o decentralizzare? La gestione dei progetti aziendali può essere eseguita con entrambi.

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).