Approccio top-down o bottom-up
Questo articolo fa parte della nostra raccolta "From the Trenches". Viene illustrata la gestione dei progetti, la gestione del portfolio e la gestione delle attività e vengono confrontate le procedure di gestione top-down e bottom-up correlate.
Per scaricare la versione di Word di questo articolo, vedere Il white paper top-down o bottom-up (Project Server 2010) .
Per altri articoli, vedere white paper "From the Trenches".
Dall'alto verso il basso o dal basso verso l'alto?
"Abbiamo bisogno di gestione dei progetti... um um, intendevo gestione portfolio... Um, voglio dire davvero gestione delle attività... Oh cavolo, abbiamo bisogno di tutti loro", è un grido di battaglia che sento spesso. Non è una mancanza di definizioni di questi tre concetti che causa confusione, è la loro somiglianza.
Quelli di noi che hanno lavorato nell'IT per molti anni tendono a vedere le cose da un punto di vista tecnico e a volte non ci servono bene. Se si esaminano i dati di Gestione portfolio, Gestione progetti e Gestione attività, l'aspetto potrebbe essere molto simile. Ho un campo ID, un campo descrizione e una data di inizio e fine in tutti e tre. Il collegamento di tutti e tre questi dovrebbe essere naturale allora.
Forse no.
Esaminiamo questi tre concetti uno alla volta. È facile vedere le loro analogie, ma ci sono differenze fondamentali nelle tre prospettive.
Gestione portfolio: approccio dall'alto verso il basso
Persone può significare molte cose diverse dalla "gestione del portfolio", ma il significato più comune è probabilmente la selezione del progetto e la definizione delle priorità. I principi in definitiva interessano tutti nell'organizzazione, ma il processo è di grande interesse per i dirigenti senior. La gestione inizia con alcuni vincoli, come un budget totale disponibile e la necessità di rispondere alla domanda: "Cosa possiamo e dobbiamo fare con questa quantità di denaro?" Se il processo di gestione del portfolio è sufficientemente maturo, questa analisi potrebbe includere non solo nuove idee, ma anche progetti esistenti.
Per creare un processo di selezione e definizione delle priorità del portfolio, la gestione deve confrontarsi con i criteri aziendali che guidano l'azienda e concordare in anticipo le metriche che verranno considerate quando si esaminano progetti nuovi ed esistenti. Il ritorno sull'investimento deve essere una metrica chiave? Forse dovremmo considerare gli effetti sulla soddisfazione dei clienti o sulla conservazione del personale o sull'allineamento con gli obiettivi strategici. Indipendentemente dalle metriche chiave, il management deve valutare ogni iniziativa di progetto per stabilire come tale progetto possa far avanzare tali obiettivi e come ogni progetto si confronta con iniziative alternative su cui potrebbero essere spesi i fondi.
Si tratta di un processo altamente analitico anche se viene eseguito nella propria testa. È sicuramente altamente analitico quando si usa il software di gestione del portfolio di progetti. Anche una volta che l'analisi dal software arriva in un report o in una vista, c'è praticamente sempre una supervisione a livello di gestione in cui viene presa una decisione finale sulle priorità. Al termine, i risultati finali devono essere trasmessi a coloro che eseguono la gestione dei progetti di ognuno dei progetti. L'effetto di queste decisioni sarà quello di finanziare alcuni progetti e non di finanziarne altri, di mettere a disposizione risorse su una priorità più alta per alcuni progetti e non per altri, di anticipare il programma di alcuni progetti e di ritardare altri.
Gestione dei progetti : dall'alto verso il basso e dal basso verso l'alto
Una volta approvato, un progetto si sposta completamente in un'area di autenticazione diversa. A questo punto, la visualizzazione più classica della pianificazione dei progetti viene messa a fuoco. Ora dobbiamo effettivamente costruire la cosa che abbiamo descritto nella nostra giustificazione aziendale prima che fosse approvata.
Un project manager inizia a pensare in termini di ambito del progetto e risultati finali. Il project manager conosce il prodotto finale che deve essere creato, sia che si tratti di un software o di un edificio pronto per l'occupazione. Possono pensare alle fasi principali del progetto e creare una struttura di suddivisione del lavoro.
Viene progettato un percorso critico dei passaggi logici necessari per completare il progetto. Il responsabile del progetto sa anche che sarà tenuto a tenere conto del programma prodotto, quindi consulta una serie di esperti in materia nel progetto. Il project manager crea una visualizzazione dal basso verso l'alto del progetto esaminando le attività in base all'attività e riepilogando tali attività fino alle fasi del progetto e infine al progetto stesso. In questo momento il project manager potrebbe anche iniziare ad allocare le risorse per competenza, per reparto o anche per nome. A queste risorse potrebbero essere associati costi. Il risultato del calcolo della durata delle attività, delle risorse necessarie e delle relative tariffe fornisce una stima dal basso verso l'alto del progetto.
Fin qui tutto bene.
Ma quando si esamina l'approccio dall'alto verso il basso del processo di selezione del portfolio di progetti, c'è stato anche un costo. Infatti, il costo stimato del progetto faceva parte della giustificazione aziendale considerata dalla gestione quando ha approvato il progetto. Se stiamo solo ottenendo la stima dal basso verso l'alto del progetto grazie alle competenze combinate degli esperti in materia, cosa hanno usato nella selezione del progetto nella suite executive?
È una buona domanda. In alcune organizzazioni, al progetto verrà fornita una stima approssimativa dal reparto del progetto per creare una giustificazione aziendale per il progetto. In altre organizzazioni viene creata una stima bottom-up completa prima di prendere in considerazione il progetto nel processo di portfolio. Il problema con entrambi questi approcci è che si sforzano. Una stima completa può richiedere molto sforzo, eppure il progetto deve ancora ricevere l'approvazione per il finanziamento di qualsiasi sforzo. Quindi, in molte organizzazioni, un management fa semplicemente un'ipotesi sui costi di questo progetto.
Quindi il processo sembra tutto integrato, ma potrebbe esserci un po 'di un catch-22 qui. Qual è il primo, il lavoro speso per fare la stima o la selezione del progetto per poter trascorrere del tempo sul progetto?
Inoltre, cosa accade se la stima bottom-up non corrisponde alla stima del processo di selezione del portfolio? Se la stima è inferiore, probabilmente non c'è alcun problema, ma se il lavoro non può essere completato nel tempo o nel budget stimato dalle persone di selezione del portfolio, c'è un conflitto.
Si potrebbe pensare che la cosa naturale da fare sarebbe quello di riconvocare senior management e solo discutere il problema, ma ci sono un sacco di situazioni in cui che non è così facile come sembra.
In primo luogo, il comitato di selezione del portafoglio è raramente il personale di gestione del progetto. I membri del personale responsabile del progetto sono quasi sempre inclusi nel comitato di selezione del portfolio, ma il gruppo stesso è in genere molto senior executives che trovano difficile organizzare il tempo per stare tutti insieme. In secondo luogo, il comitato di selezione può incontrarsi in modo irregolare, quindi riunirli per discutere tutte le ramificazioni di un costo non corrispondente per un progetto rispetto alla stima potrebbe essere una grande sfida. Infine, ci sono alcune culture aziendali in cui non sarà una mossa che avanza la carriera per dover fornire la notizia al senior executive che la loro ipotesi è completamente sbagliata su quale sia il programma e il budget appropriati per questo progetto.
Gestione delle attività: approccio dal basso verso l'alto
Quando pensiamo alla gestione delle attività, tendiamo a pensare in modo molto operativo e questo più spesso ci porta alla nostra agenda quotidiana e a un prodotto come Outlook.
Ora stiamo lavorando a un singolo o a un piccolo livello di membro del team. Le attività non vengono visualizzate nel contesto. Vengono visualizzati gli elementi a cui ci si è impegnati o, forse, gli elementi a cui è stato chiesto a un membro del team di eseguire il commit. Questa non è affatto una visualizzazione analitica. Ci sono compiti da fare e l'individuo ha promesso di farlo.
Alla base, la gestione delle attività è molto semplice. Si esegue l'attività e al termine si dice alla persona che ti ha dato l'attività di eseguire questa operazione è completa. Tutte le funzionalità per questo è già in Outlook.
Il male di dati simili
C'è un detto: "Se sembra un'anatra e ciarlatano come un'anatra, deve essere un'anatra." Questo vale per le anatre, ma non è sempre vero per i dati basati su attività.
Si considerino questi tre livelli di dati orientati al progetto:
A livello di portfolio, abbiamo un progetto e forse fasi al di sotto di tale progetto. Le informazioni sulla fase potrebbero avere un numero di codice, una descrizione, una durata, una data di inizio e una data di fine.
A livello di progetto sono presenti un progetto e attività al di sotto del progetto. Le informazioni sull'attività potrebbero avere un numero di codice, una descrizione, una durata, una data di inizio e una data di fine.
A tale livello di gestione delle attività, è disponibile un'attività e le informazioni sull'attività potrebbero avere un numero di codice, una descrizione, una durata, una data di inizio e una data di fine.
Di sicuro hanno lo stesso aspetto, ma in realtà la prospettiva dei dati rende ognuno di questi record piuttosto comuni serve a uno scopo molto diverso.
Spesso mi viene chiesto: "È possibile spostare i dati dalla visualizzazione del portfolio alla visualizzazione del progetto in Outlook e indietro".
La breve risposta a questa domanda è "Sì".
Ma nella nostra azienda abbiamo un mantra che diciamo a noi stessi quando diamo consigli tecnici: "Non dirmi come farlo, dimmi perché dovresti farlo".
Per fare il punto, si immagini questo esempio. Facciamo un ambiente completamente integrato. All'estremità superiore della scala è disponibile un elenco di progetti organizzati per portfolio. Non solo selezioniamo questi progetti, ma li integriamo ulteriormente, seguendoli dopo che sono stati attivati in progetti live dal sistema EPM. A tale scopo, viene usata la funzionalità già disponibile per spostare le definizioni di progetto e fase dal lato Portfolio del sistema integrato al lato progetto del sistema. I dati sono identici.
Nel sistema di gestione dei progetti aziendali viene ora creata una definizione più dettagliata, usando le fasi originali della definizione del portfolio che è stata spinta dall'alto verso il basso. In questo modo, il riepilogo può essere aggiornato nel sistema di portfolio quando si aggiornano i progetti. Vengono eseguite molte attività e vengono assegnate molte risorse. È ora possibile eseguire un'analisi del livello delle risorse per determinare la capacità in molti progetti.
Le assegnazioni di risorse vengono usate per eseguire il push dei dati delle attività e delle assegnazioni a ogni utente come evento di calendario o attività di Outlook. Gli utenti non devono più passare a un "sistema di gestione dei progetti". Ora sono in grado di visualizzare i propri dati nell'agenda quotidiana. I dati sono simili a quanto avviene nell'elenco dei progetti ed sono collegati più a monte alla visualizzazione portfolio.
Lo stato di avanzamento di queste attività e la disponibilità da Outlook vengono spostati di nuovo dal singolo utente al sistema di gestione del progetto insieme alle stime su quando questo lavoro verrà completato. I dati sono simili a quanto avviene negli altri due sistemi, quindi lo spostamento dei dati è relativamente semplice.
La creazione di un sistema di questo tipo è tecnicamente molto semplice usando gli strumenti attualmente disponibili insieme a un po ' di configurazione e sviluppo. E dimostrerebbe splendidamente.
Ci viene chiesto esattamente questo tipo di struttura su base regolare. Ma, anche se possiamo farlo, dovremmo?
Si supponga che a livello di attività, un individuo prende la mattinata fuori per una visita dentale di emergenza e aggiorna il suo Outlook che non sarà disponibile questa mattina. Questa è una brutta notizia per lui, ma gli effetti dell'increspatura sul progetto potrebbero essere enormi. Ora, il sistema di progetto calcola che l'attività che era stata pianificata per essere eseguita questa mattina non verrà completata oggi; sarà completata solo a metà giornata domani. Esamina correttamente il percorso critico e tutte le attività a valle di questo e li spinge in avanti di quattro ore. Forse centinaia di attività sono state interessate. Il risultato potrebbe essere il push della data di fine del progetto mezzo giorno dopo. Altri progetti sono interessati anche come altri utenti che lavorano su questo progetto deve ora avere le loro attività riordino e la visualizzazione portfolio stessa scorre in avanti di alcuni pixel.
Se lo immaginiamo in tempo reale, il problema è ingrandita. Centinaia o migliaia di persone apportano modifiche per tutto il giorno e la visualizzazione EPM, la visualizzazione di livellamento delle risorse e la visualizzazione portfolio si animano avanti e indietro con gli effetti.
In realtà questo non accade. Prima di tutto, la paziente dentale sfortunata tornerà al suo posto a mezzogiorno e potrebbe solo lavorare poche ore più tardi stasera per assicurarsi che questo percorso critico sia raggiunto e tutto tornerà in pista la mattina.
Inoltre, anche se i dati hanno lo stesso aspetto, non sono mai integrati in questo modo a causa di questo effetto.
Contesto dei dati: la prospettiva è importante
Quando si esaminano i dati, il contesto dei dati è fondamentale. I dati che possono avere lo stesso aspetto da uno schema da record a record vengono usati per scopi molto diversi in base alla prospettiva dell'applicazione.
In una visione top-down del portafoglio, stiamo prendendo decisioni strategiche su dove mettere le nostre risorse per massimizzare il nostro ritorno sugli investimenti. È possibile fare scelte che un project manager non farebbe. Nella mia organizzazione, a volte abbiamo scelto progetti completamente al di fuori del nostro set di competenze esistenti, sapendo che saremmo terribilmente inefficienti nel raggiungerli, ma farlo perché volevamo migliorare quelle stesse competenze. Il ritorno sull'investimento non è stato un'installazione efficace, è stato sottoposto a training programmi di installazione. Si tratta di una visualizzazione analitica.
In un progetto tattico, stiamo prendendo decisioni operative su dove ottenere la migliore velocità effettiva del nostro personale e per completare i nostri progetti nel modo più rapido ed efficiente possibile. L'occhio di un project manager è sempre verso il futuro. Ciò che è successo in passato è di interesse solo per il responsabile del progetto nella misura in cui migliora la sua visione del futuro. Si tratta anche di una visualizzazione altamente analitica.
In una visualizzazione di gestione delle attività come un'agenda, non siamo analitici. Un'agenda è un sistema di impegno. Promettiamo a noi stessi o agli altri che faremo una cosa particolare in un determinato momento. Questa operazione può essere adatta alla visualizzazione analitica. E potrebbe non farlo.
La combinazione di queste prospettive e contesti senza comprendere l'impatto può causare il caos.
Dall'alto verso il basso o dal basso verso l'alto?
Non c'è, come al solito, una risposta giusta. Alcuni aspetti del sistema di gestione dei progetti devono provenire dal basso verso l'alto. Dopo tutto, alla fine, sono gli individui che costruiranno tutto ciò che il vostro progetto è circa. Ma alcune decisioni sono, e dovrebbero essere, prese dall'alto e sono, come una necessità, dall'alto verso il basso.
Quando si mantengono le distinzioni di ogni livello del paradigma di gestione del progetto, diventa più chiaro vedere se alcuni di questi sistemi devono essere effettivamente integrati o meno. Se il processo e il pensiero di un livello non hanno un vantaggio diretto grazie all'integrazione completa da un altro livello, l'integrazione non è il gioco migliore. È importante esaminare il funzionamento di tale integrazione in un contesto reale e stabilire se la frequenza e i dettagli di un livello offrono qualsiasi valore all'altro.
Se, ad esempio, un comitato direttivo si riunisce una sola volta al trimestre per prendere decisioni importanti su quali progetti andare avanti e quali no, qual è il vantaggio di aggiornare la loro opinione ogni giorno, ogni settimana o anche ogni mese?
L'algoritmo di livellamento delle risorse per la gestione dei progetti aziendali deve davvero visualizzare l'appuntamento dentale di un individuo o è sufficiente conoscere la disponibilità approssimativa di tale individuo?
Eppure, se potessimo inviare un'assegnazione direttamente alla schermata dell'agenda o della scheda attività di un individuo, li risparmierebbe qualche minuto al giorno dovendo entrare in un sistema e un'interfaccia diversi per vedere gli stessi dati?
Quindi, top-down è giusto in alcune circostanze e dal basso verso l'alto è proprio in altri. È necessario esaminare la propria situazione per vedere dove l'integrazione di questi strumenti e concetti può restituire i giusti dividendi prima di legarli insieme.
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).