Risolvere il progetto
Questo articolo fa parte della nostra raccolta "From the Trenches". Descrive alcune problematiche comuni che possono verificarsi durante la pianificazione dei progetti. Descrive l'approccio migliore quando si tenta di determinare la durata delle attività e il numero di attività da eseguire per ottimizzare la pianificazione di un progetto. Viene illustrato in che modo diversi settori richiedono in genere diversi tipi di pianificazioni (ad esempio sviluppo di software, EPM (ingegneria, approvvigionamento e costruzione) e arresto degli impianti. Vengono inoltre illustrati diversi fattori nella scelta della risoluzione del progetto, ad esempio la lunghezza del progetto, le risorse coinvolte, la gestione o la divisione delle risorse, la velocità e l'impegno necessari per la raccolta dei dati e la pianificazione dell'aggiornamento dei dati.
Per scaricare la versione di Word di questo articolo, vedere Dicono di volere una risoluzione: white paper (Project Server 2010).To download the Word version of this article, see They say they want a resolution: white paper (Project Server 2010).
Per altri articoli, vedere white paper "From the Trenches".
Risolvere il progetto
Con le scuse ai Beatles per il titolo, l'argomento di oggi è la risoluzione del tuo progetto.
Ci sono molti materiali disponibili su come fare una pianificazione, ma una delle lezioni più critiche è terribilmente difficile da trovare: quante attività è necessario avere nella pianificazione del progetto e quanto tempo deve essere ogni attività?
A intervalli regolari mi trovo di fronte a pianificazioni di progetto che sembrano incredibilmente complesse o con project manager che sembrano impotenti a individuare problemi nella loro pianificazione perché la pianificazione è a un livello di riepilogo simile. Ho visto un progetto che durava più di cento anni (sì, davvero) che era perfettamente appropriato per lunghezza e in cui ci sono stati alcuni compiti che sono stati lunghi decenni. Ho anche visto pianificazioni di progetto che sono durate solo un'ora o meno che erano perfettamente appropriate e in cui alcune attività sono durate solo un minuto. Ho visto progetti con solo una manciata di attività e altri con oltre 100.000 attività.
Il software che usiamo oggi può gestire migliaia di attività e un'ampia gamma di durate.
Qual è l'approccio giusto?
Per quanto tempo devono essere eseguite le attività e quante devono essere necessarie per ottimizzare la pianificazione del progetto? Lo chiamerò la risoluzione del progetto.
Tratti diversi per persone diverse
Poiché il requisito potrebbe essere diverso per settori diversi, tipi diversi di progetti e situazioni diverse, si esaminerà come decidere quante attività inserire nella pianificazione e quanto devono essere lunghe le attività.
Diversi tipi di progetti richiedono naturalmente diversi tipi di pianificazioni. Si consideri ora tre diversi esempi:
Sviluppo di software. Molti progetti software hanno caratteristiche comuni. Anche se ogni progetto software è univoco, in genere esiste una fase di progettazione, una fase di programmazione, una fase di controllo della qualità, una fase del documento e una fase di distribuzione. I progetti software sono in genere misurati in settimane o mesi e si prestano ad attività che durano da un giorno a un paio di settimane. L'allocazione delle risorse qui viene spesso assegnata al singolo livello.
Coloro che hanno adottato il processo Agile per lo sviluppo di software cercano brevi "sprint" di una o due settimane e all'interno di tale sprint hanno messo attività di breve durata, ma la durata complessiva del progetto è ancora misurata in settimane. Più avanti verranno illustrate altre informazioni sullo sviluppo Agile.
EPC - Ingegneria, Approvvigionamento e Costruzione. I progetti EPC sono il punto di partenza della metodologia di pianificazione dei percorsi critici. In questo tipo di progetto, si sta sviluppando qualcosa di molto grande. Potrebbe trattarsi di un grande progetto di difesa come il progetto Polaris Missile che ha dato inizio ai diagrammi PERT, o potrebbe essere una piattaforma petrolifera offshore, una nuova nave o una centrale elettrica. In questi tipi di progetti c'è una fase di progettazione in cui il progetto finito è concepito. La fase di progettazione presenta in genere alcuni aspetti che non sono mai stati progettati prima. La fase di approvvigionamento si occupa di individuare, contrarre e gestire la fornitura di forniture o sotto-contratti per gli elementi del progetto. Nella fase di costruzione, il prodotto finale viene costruito e quindi commissionato per l'uso. In genere si pensa alle pianificazioni dei progetti EPC in molti mesi o diversi anni con durate di attività che durano da un paio di settimane a un paio di mesi. Non è affatto insolito avere da 5.000 a 20.000 attività in un progetto di questo tipo. La pianificazione delle risorse qui è quasi sempre assegnata al livello di competenza anziché al singolo utente e , solo per aggiungere al divertimento, potrebbero essere presenti molti sottoprogetti realizzati in un programma o in un progetto master per semplificare la gestione.
Arresto dell'impianto. Quando si esegue una pianificazione del progetto per l'arresto di un impianto e la turnaround per la manutenzione, si lavora in uno degli ambienti di pianificazione più complessi possibili. Un arresto dell'impianto per eseguire la manutenzione è disponibile in due gusti: pianificato e di emergenza. Lasciamo da parte il tipo di emergenza per un attimo; è un mondo a se stesso. La durata di un arresto pianificato dell'impianto dipende in larga misura dal tipo di impianto. Un'unità di centrale nucleare, ad esempio, potrebbe effettuare un arresto e una turnaround di impianti "veloci" in 12 mesi. Una raffineria di petrolio potrebbe durare 4-6 settimane. Ma il tipo di pianificazione del progetto di impianto che trovo più interessante è una fabbrica come un'acciaieria, una fabbrica di carta o qualcosa di simile. Ci sono migliaia o decine di migliaia di tali piante in tutto il mondo, e devono essere sottoposte a manutenzione regolare ogni anno o così via.
Il costo dell'arresto per queste situazioni è in genere misurato in costo opportunità; il costo del prodotto che non verrà prodotto mentre l'impianto è inattivo e sottoposto a manutenzione. Questo costo è misurato in ore e il costo può essere fino a $ 150.000 a $ 250.000 all'ora! Quindi la pressione è su minuto per minuto per ottenere il lavoro fatto. In questo tipo di situazione, l'arresto dura in genere 5-8 giorni e il ritardo di un singolo giorno viene calcolato in milioni. Se si è abituati solo a pianificazioni più lunghe e tradizionali, si potrebbe pensare che in pochi giorni, "quante attività potrebbero esserci in genere?" ma non è affatto insolito che un arresto di questo tipo abbia da 2.000 a 4.000 attività, ognuna della durata da 15 minuti a un paio d'ore. Le assegnazioni di risorse vengono eseguite in base alla competenza, ma il livellamento delle risorse viene eseguito raramente sul personale. Con il costo all'ora così intenso, non importa se si mette più persone nel progetto, basta farlo in fretta. Il livellamento delle risorse in questa situazione viene spesso eseguito per colli di bottiglia altamente vincolati. Ad esempio, "possiamo adattare solo due persone nella stanza elettrica, in modo che sia gestito discretamente".
Ok, ora abbiamo tre tipi di esempi, e ce ne sono molti altri, ma questi tre serviranno ai fini della discussione proprio bene. Nel tipo 1 (Sviluppo software) vengono visualizzate attività che in genere durano da un giorno o due giorni a due settimane. Nel tipo due (EPC) si ottengono attività che durano settimane o mesi. Nel tipo 3 (arresto dell'impianto), le attività vengono misurate in unità di 6 minuti (1/10 di un'ora), 10 minuti, 15 minuti (1/4 di un'ora), fino a un paio d'ore. È ovvio che in alcuni casi le attività brevi hanno senso e in altri le attività lunghe sono più appropriate. Seguendo la stessa logica, a volte ha senso avere un numero enorme di attività e a volte non lo fa.
Fattori nella scelta della risoluzione del progetto
Con queste tre distinzioni, è facile vedere che l'attività del progetto EPC di due mesi sarebbe ridicola in una pianificazione di arresto di sei giorni e che un'attività di 15 minuti sarebbe fuori posto nel progetto EPC o Software. Ma oltre a fare riferimento a questo articolo e dire: "Vandersluis dice che si tratta di un progetto software, quindi le attività possono durare solo 1-10 giorni", (e per favore, non farlo) quali caratteristiche del progetto ci dicono quale livello di risoluzione scegliere? Di seguito sono riportati alcuni elementi ovvi:
Quanto dura il progetto?
Iniziamo con il più ovvio. Se si prevede che il progetto sia lungo alcuni giorni, ad esempio nell'esempio di arresto, l'esecuzione di attività che durano diversi giorni non ha alcun senso. A partire da un approccio dall'alto verso il basso è spesso produttivo quando si pensa alla suddivisione secondaria dell'ambito. Usare il pensiero della struttura di suddivisione del lavoro. Iniziare con i componenti principali. Pensa di avere non meno di 4 e non più di 20 elementi.
È una regola? No, ovviamente no.
È buon senso. Meno di 4 ti fa chiedere perché hai diviso il lavoro a tutti e più di 20 è troppo difficile da tenere nella mente in una volta. Personalmente vado con non più di 8 elementi per elemento WBS e questo è a causa di un articolo che ho letto anni fa che ha suggerito che un ottagono era la forma più complessa semplice che la mente potesse riconoscere immediatamente.
Pensaci un attimo. È possibile identificare un cerchio, un triangolo, un quadrato, un pentagono, un esagono che ha 6 lati, un ettagono che ha 7 lati (ok, che uno è difficile da visualizzare) e un ottagono.
È possibile identificare una forma a 9 lati senza contare? Non posso. Si chiama "nonagon" per voi appassionati di trivia.
Quindi, personalmente, mi sforzo per il limite di 8 elementi, ma la mia regola generale è 4-20.
Per ogni elemento che hai esaminato, pensa a come dividere il lavoro. Ancora una volta, pensate alla regola 4-20. Ma sapere quando fermarsi è il segreto. I project manager più recenti suddividono e suddividono e suddividono fino a quando ogni passaggio lungo il corridoio non è un'attività gestita. Alcune buone domande spartiacque che puoi porsi sulla lunghezza di un'attività potrebbero essere:
Quale azione eseguirei se l'attività fosse in ritardo? Se la risposta è "nothing", è una buona indicazione che l'attività a cui si sta pensando è troppo piccola per essere gestito. Se questo è il caso si sta guardando in troppi dettagli. Eseguire il backup di un livello, fare un passo indietro e verificare se è stato completato.
La raccolta dei dati sull'aggiornamento di questa attività richiederà più tempo dell'attività stessa? Non sempre pensiamo a quale tipo di sforzo ci vorrà per gestire un'attività pianificata, ma vale la pena pensare anche se per un attimo. Se ci vorrà più sforzo per gestire l'attività di quanto ci vorrà per completare, questa è una buona indicazione che l'attività viene definita in modo troppo dettagliato.
Quanto dura questa attività? Quando stiamo dividendo il lavoro, a volte perdiamo di vista quanto minuscolo diventa un compito. Le grandi fasi al livello superiore sono state forse lunghe settimane, ma man mano che si scende un paio di livelli di granularità, è possibile cadere facilmente nella trappola di definire un'attività da gestire che dura solo pochi minuti. Quando si arriva a piccoli compiti, dobbiamo chiedere quale sarebbe il vantaggio di gestirli.
Applichiamo un controllo della realtà a ciò di cui ho appena parlato. In un progetto EPC di due anni, se un'attività di una settimana è un giorno in ritardo, quasi certamente non vale la pena intervenire. In un progetto Software di sei mesi, un'attività di una settimana con un giorno di ritardo probabilmente non vale la pena intervenire. In un progetto di arresto di sei giorni, un'attività di una settimana con un giorno di ritardo è un'emergenza di massa. In altre parole, un'attività di una settimana nel progetto EPC potrebbe essere troppo fine per un livello di dettaglio; nel progetto software, probabilmente è giusto; e nel progetto Shutdown, quasi certamente deve essere suddiviso in modo più dettagliato.
Quante risorse sono coinvolte?
So che stiamo solo lavorando sull'ambito, ma quando esaminiamo il tipo di risoluzione che abbiamo bisogno, vale la pena pensare a quante persone lavoreranno a un'attività. In un progetto EPC di grandi dimensioni, ad esempio, si possono avere decine di lavoratori di una competenza coinvolta in una fase di lavoro. Ma quando si finisce con molte competenze diverse nella stessa attività, la gestione di tale attività diventa molto impegnativa, se non impossibile. Quindi, in questa situazione, le attività che richiedono molte competenze diverse probabilmente devono essere divise.
In un progetto software si tende a considerare quasi ogni individuo come una risorsa altamente tecnica con funzionalità uniche. Inoltre, nei progetti software è comune avere molte attività riassegnare all'interno di un reparto, ma solo un'attività assegnata a una persona. Pertanto, quando sono presenti attività allocate a un livello di una sola persona di un particolare gruppo di risorse o reparto (ad esempio la programmazione di interfacce) siamo abbastanza vicini da dire che non sono necessari altri dettagli.
Come vengono gestite o suddivise le risorse?
La modalità di gestione delle risorse è un fattore determinante per la suddivisione delle attività. Nei progetti EPC di grandi dimensioni, ad esempio, i progetti vengono spesso suddivisi in sottoprogetti che sono suddivisi in grandi subappaltatori. In questa situazione è necessario eseguire un paio di operazioni:
Definire il lavoro in un modo che consenta a un project manager di supervisionare il sub-appaltatore con la certezza che i progressi fatti siano un fattore importante.
Definire le attività in modo che il personale addetto alla gestione dei progetti e all'ingegneria del subfornitore comprenda il significato di tali attività senza ambiguità.
Assicurarsi che il livello di risoluzione adottato come standard sia compreso e accettato dal sub-appaltatore.
Quando si esaminano progetti di tipo white collar, ad esempio software, ricerca biologica o ingegneria, è molto probabile che si verifichi una struttura di Gestione matrice in cui i project manager non possiedono nessuna delle risorse e che è necessario lavorare tra i responsabili del reparto che allocano tali risorse in molti progetti diversi. In questo caso, le domande principali sono:
Quanti progetti è probabile che una risorsa funzioni in un singolo giorno?
Quanto tempo richiede un dipendente per passare da un progetto a un altro?
Il lavoro è definito in modo che sia i dipendenti che i responsabili del reparto risorse comprendano come allocare la competenza corretta?
Quando si esamina un progetto di arresto o costruzione, si tende a lavorare tra gli equipaggi appositamente costruiti. In queste situazioni, un responsabile del team di risorse potrebbe gestire il team elettrico (anche se tale team include falegnami e montatori di tubi), un team idraulico o un team di ricondizionamento dell'unità caldaia. Il lavoro deve essere organizzato in modo che l'equipaggio possa essere tenuto occupato per tutto il turno e che non arrivi su un altro equipaggio che già lavora in quella zona. Data l'intensa pressione di completamento di un progetto di arresto, il lavoro viene spesso organizzato in base al lavoro prima, pianificato e quindi raggruppato e suddiviso in base a un responsabile del team di risorse in modo che ogni responsabile del team possa spostarsi con solo le attività in un documento e con l'intero progetto nel contesto in un altro. Le attività devono quindi essere definite in modo comprensibile dal dipendente e dal responsabile del team di risorse. Le attività qui sono probabilmente definite fino all'ora o con una granularità ancora maggiore fino al decimo o al quarto d'ora.
Quanto velocemente è possibile raccogliere i dati e quanto impegno richiede?
Sembra una domanda sciocca quando si è abituati a visualizzare i dati del progetto tutti ben allineati alla fine della settimana da rivedere, ma quando si sta cercando di determinare il livello di risoluzione del progetto, questa può essere una domanda chiave. Ad esempio, quando si lavora attraverso numerosi subappaltatori, è probabile che si otterrà un qualche tipo di aggiornamento settimanale o mensile. Infatti, la compilazione della clausola di aggiornamento della gestione del progetto nel contratto è essenziale. In questa situazione è necessario integrare i dati di queste diverse aziende nel proprio, verificare che i dati sullo stato di avanzamento siano appropriati e quindi eseguire analisi e report personalizzati. In modalità EPC, si tratta probabilmente di un'occorrenza mensile.
In un progetto di arresto, sarà necessario aggiornare il progetto ogni turno, aggiornarlo rapidamente e ottenere gli aggiornamenti ai responsabili del team di risorse nel corso del turno successivo. In questa situazione, il personale del progetto brulica in tutto l'impianto durante il turno, raccogliendo i dati il più vicino possibile al tempo reale e facendo in modo che i responsabili del team di risorse e i foremen usino fogli "take-down" per "eliminare" lo stato delle loro assegnazioni. In un progetto di software o ricerca, probabilmente si sta lavorando a un programma settimanale o a qualcosa di simile con gli individui che segnalano i propri progressi e passano attraverso approvazioni in un giorno o due.
Si tratta di un punto importante da considerare quando si esamina il numero di attività da avere nel progetto, perché è previsto un costo per la raccolta dei dati.
È quindi fondamentale considerare la rapidità con cui è possibile raccogliere, approvare, integrare, analizzare e segnalare i dati su base ciclica regolare, così come la considerazione del costo della raccolta dei dati e del ritorno sull'investimento dei dati raccolti.
Con quale frequenza verrà eseguito l'aggiornamento?
Ecco due chiavi per determinare la quantità di dati che è possibile raccogliere e includere:
Pensa a come raccogliere i tuoi dati.
Si pensi alla frequenza con cui è possibile aggiornare ragionevolmente il progetto e fornire alla gestione gli strumenti decisionali necessari per guidare il progetto e le risorse nella giusta direzione.
Ho visto alcuni project manager insistere che vogliono passare alla gestione dei progetti in tempo reale e alla raccolta di progetti e, anche se questo può essere possibile in teoria, è terribilmente difficile da realizzare in pratica.
Quando si esaminano i dati di gestione dei progetti, vengono fatte alcune ipotesi. Si presuppone che:
I dati sono tutti lì. Non ci aspettiamo di esaminare alcune attività che vengono aggiornate e altre che non lo sono.
Tutti i dati sono stati aggiornati in un momento simile. Non prevediamo che la metà delle attività sia stata aggiornata qualche minuto fa, ma l'altra metà non è stata aggiornata per due settimane.
Tutti i dati hanno avuto un certo livello di approvazione. Ci aspettiamo che il responsabile del progetto si trovi dietro i dati presentati e che sia in grado di dire "Si tratta di una rappresentazione equa e accurata del progetto".
I dati appartengono insieme. Non ci aspettiamo che i rischi siano offuscati con i costi e con le risorse a meno che non abbiamo progettato in modo specifico i nostri report e analisi in questo modo.
Spesso chiedo ai dirigenti che sono entusiasti del concetto di gestione dei progetti in tempo reale cosa faranno se riuscissimo a superare i punti che ho appena sollevato in precedenza. "Sei pronto a prendere decisioni di gestione per tutta la settimana?" Glielo chiedo. La risposta deve dipendere dal livello di risoluzione. In un progetto di arresto è meglio che la risposta sia "Sì". In un progetto software, la risposta è probabilmente "No, lo faremo ogni settimana". E in un progetto EPC la risposta sarebbe"Mensile".
A un certo punto la legge di diminuzione dei rendimenti inizia a dire: "La distribuzione di report di progetto più velocemente non ci darà alcun aumento di efficienza."
Revisione del lavoro
È stato fatto un po' di riflessione, è stato usato il metodo di suddivisione del lavoro per suddividere i dati in modo secondario e sono stati osservati alcuni dei segnali di avviso che segnalano che i dati sono troppo finemente definiti. Ora è il momento di appoggiare la pianificazione contro il muro, fare un passo indietro e guardare il progetto con una certa prospettiva. Sorprendentemente, molti project manager non lo fanno mai. Vengono così coinvolti nel ottenere gli ultimi dettagli definiti e sono così occupato sotto-divisione attività ancora e ancora che si spingono fino alla scadenza go-live e non guardare mai fino a vedere se ciò che hanno fatto sarà un incubo da gestire.
In alcuni casi, i dirigenti sono certi da tutto il training MBA che "più dettagli sono migliori" e stanno spingendo per quelle attività di 5 minuti o 15 minuti su progetti di sei mesi.
La modifica del progetto prima dell'avvio è sempre più semplice rispetto a qualsiasi altro momento in un secondo momento, quindi è necessario compilare il tempo nell'attività di compilazione della pianificazione per rielaborare la pianificazione, se necessario.
È troppo?
A volte i project manager esaminano l'ambito di ciò che hanno creato e si rendono conto di avere un livello di dettaglio troppo elevato. In questo caso, la correzione è ovvia. Può essere un sacco di lavoro, ma si ringrazierà più tardi per rendere il programma più semplice passando a un livello superiore.
A volte l'immagine non è così facile. In alcuni casi, è solo una volta assemblata l'intera pianificazione che il project manager può vedere quanto sia complessa. I progetti complessi sono, per loro natura, più rischiosi e il rischio nell'economia di oggi è un fattore di selezione chiave per i progetti. Alcune domande che vale la pena considerare prima dell'avvio di un progetto così complesso potrebbero essere:
Possiamo farlo a pezzi? Alcuni progetti rischiosi possono essere suddivisi in porzioni più piccole e, man mano che i progetti più piccoli, il loro rischio diminuisce. Tuttavia, se si usa questa strategia, ogni progetto discreto deve avere il proprio valore al termine.
Dovremmo ripensare l'ambito? A volte le azioni più semplici sono tornare ai progettisti del lavoro in primo luogo, spiegare la complessità che sembra evidente nella pianificazione e vedere se il lavoro può essere riposato. Questo spesso porta a un pensiero innovativo che non avrebbe mai avuto la possibilità di verificarsi.
Dovremmo farlo a tutti?
Alcuni progetti non sono mai stati pensati per essere, e il momento più economico per annullarli è il giorno prima che inizino. Se il rischio del progetto è solo ora evidente, è meglio realizzarlo ora che in seguito. Quando si intrecciano i risultati dell'esecuzione della pianificazione nel processo di gestione del portfolio di progetti (PPM), è possibile che il rischio di un progetto più complesso abbia un punteggio di lavoro molto peggiore in una scala di ritorno sugli investimenti.
Un agile... no, un progetto Agile
Ho promesso di dire alcune cose sulla gestione dei progetti Agile e se sei un fan agile e hai letto fino a questo punto, apprezzo la tua pazienza. La gestione di progetti software tramite il metodo Agile è una filosofia, ma è una filosofia sempre più popolare con coloro che sono stati bruciati su progetti di sviluppo software di grandi dimensioni che hanno fallito.
In un mondo di sviluppo software Agile, cerchiamo di suddividere il nostro progetto in "sprint" di una o tre settimane e l'obiettivo per ogni miniprogetto è quello di finire con codice utilizzabile. In questo caso stiamo lavorando all'interno di alcuni vincoli abbastanza noti in modo che il nostro livello di risoluzione sia praticamente scelto per noi.
È disponibile una finestra di una o tre settimane, le risorse sono disponibili e si assegnerà il lavoro a ogni risorsa. Il numero di possibili attività che possiamo definire in tale struttura è finito e questo si presta a mantenere un livello di risoluzione appropriato. Sì, è possibile creare problemi in Agile definendo attività troppo brevi. "Definisci campo1: 10 minuti, Definisci campo2: 10 minuti, Definisci campo3: 10 minuti" e così via, ma è molto meno comune.
Agile è stato progettato per un ambiente di sviluppo aziendale in cui stiamo creando software per uso interno e il suo uso viene spesso esteso allo sviluppo di software commerciale. Il metodo viene usato qui in HMS per lo sviluppo di TimeControl. Il metodo Agile si traduce in un reparto di sviluppo più manovrabile e agile, ma non sarà applicabile a ogni settore o anche a ogni azienda di software. Se si esegue la gestione dei progetti in un ambiente software, è consigliabile leggere agile, imparare da esso e quindi adottare gli elementi (tutti, alcuni o nessuno) che ti renderanno più efficace.
Ritorno a capo
Come per la maggior parte degli aspetti della gestione dei progetti, non esiste una risposta impostata alle domande che all'inizio sembrano essere così ovvie. Quante attività hai nel tuo progetto e per quanto tempo ognuna di queste attività dovrebbe essere qualcosa che devi cercare per te stesso per decidere ... ma decidete che dovete.
La scelta del livello di risoluzione del progetto è una responsabilità di gestione del progetto che può essere un fattore di successo chiave nella gestione della pianificazione del progetto.
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).