Pianificare o tenere traccia dei progetti

Questo articolo fa parte della nostra raccolta "From the Trenches". Descrive i vantaggi del rilevamento del lavoro del progetto, illustra i metodi di rilevamento e spiega la differenza tra il tempo di rilevamento e il rilevamento dello stato.

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

Tenere traccia o trattare

È la stagione di Halloween qui in America del Nord quindi ho pensato che avremmo parlato di qualcosa di spaventoso: tenere traccia dei nostri progetti. Che cosa? Non è spaventoso che tu dici? Le informazioni dal campo potrebbero essere diverse.

La pianificazione non gestione è ancora così comune

In molti settori e organizzazioni, è sorprendentemente comune che anche quando vengono create pianificazioni formali di gestione dei progetti, vengono lasciate in modalità di pianificazione solo e mai monitorate. Esercizio del piano e, se necessario, pianificare di nuovo. Da nessuna parte questo è più prevalente che nello sviluppo di software. Per tutti i progressi che abbiamo fatto nella gestione dei progetti nel settore del software, il numero di progetti che sono solo pianificati rispetto a quelli pianificati e poi monitorati è enorme. Se sei uno di quelli che pianificano solo, la buona notizia è che non sei solo. La cattiva notizia è che non sei solo!

Ci sono molti motivi per cui il monitoraggio dei progetti in alcuni settori non è popolare. In alcuni settori, ad esempio, è abbastanza comune disporre di personale specializzato nella creazione di offerte o nei prezzi dei progetti o nel contratto di progetto o nella stima di realizzare il piano originale per il progetto. Questo è vero in molti ambienti diversi, ma lo vediamo quasi sempre in progetti di costruzione, ingegneria pesante, aerospaziale/difesa e grandi progetti di ingegneria/approvvigionamento/costruzione (EPC). Una volta che l'offerta è stata vinta, un team completamente nuovo assume il monitoraggio e la consegna del progetto. Nei progetti di grandi dimensioni, le persone che hanno creato l'offerta originale si sono spesso spostate molto tempo fa per fare altre offerte, poiché il tempo tra la creazione della stima e la chiusura del contratto può essere esteso. Il progetto appena avviato potrebbe essere una vecchia notizia per loro. Quindi coloro che eseguono la gestione del progetto non sono in grado di tenere traccia del piano originale perché le persone che l'hanno creato e la struttura del piano stesso non sono disponibili.

Il motivo più comune dato per non eseguire il rilevamento del progetto è tuttavia che il progetto è così fluido che il rilevamento del lavoro è troppo impegnativo. Alcuni progetti vengono modificati così rapidamente che il semplice mantenimento del piano è un'impresa enorme. Se si passa tutto il tempo ad aggiornare il piano, rimane poco tempo prezioso per tenere traccia di ciò che si sta pianificando.

Questo può avere un effetto interessante che non è necessariamente una buona. Negli ambienti in cui il project manager aggiorna il piano più e più volte in base alle mutevoli condizioni, il progetto non è mai molto tardi; mai veramente oltre il budget; mai veramente fuori pista. Come potrebbe essere? Dopo tutto, abbiamo appena aggiornato il piano 20 minuti fa e siamo sulla buona strada con dove abbiamo pianificato.

Se si è nel settore dello sviluppo software e si sta pensando, che suona un po 'come Agile, si sarebbe esattamente giusto. L'idea della gestione dei progetti Agile era quella di creare durante la progettazione e la distribuzione di ciò che stiamo creando in modo iterativo. I nostri piani si adatterebbero di conseguenza e potremmo, in qualsiasi momento, dire "Il client segnala che è abbastanza buono. Possiamo fermarci qui per ora.

Questo è completamente appropriato per alcuni tipi di sviluppo, ma per gli altri, è la roba dei sogni. La maggior parte degli ambienti di sviluppo software ha gli stessi vincoli di gestione dei progetti di tutti gli altri settori. Abbiamo scadenze da rispettare, budget da rispettare e un elenco fisso di ambiti da realizzare. Chiamiamolo gestione dei progetti tradizionale. Anche in ambienti principalmente Agile, la mia esperienza è stata che la gestione Agile avviene all'interno di un ombrello della gestione dei progetti tradizionale.

Qualunque sia l'incentivo a pianificare semplicemente, tenere traccia del progetto comporta il potenziale di enormi vantaggi. Diamo un'occhiata all'intero concetto di rilevamento.

Cosa significa il rilevamento?

Si potrebbe pensare che il rilevamento del progetto abbia una definizione molto distinta e che non si sia corretti. Come tenere traccia di un progetto dipende in larga misura dagli obiettivi. Ecco un paio di metodi di rilevamento più comuni:

Indovinare una percentuale

"Siamo circa a metà strada", dice il leader del team e sappiamo che è circa il 50% di quello che avevamo pianificato. Anche se questo è il rilevamento e questo è molto meglio che non tenere traccia affatto, la qualità di questi dati è piuttosto debole. Se si ha un piano per completare un'attività in 10 giorni e si segnala che il completamento è di circa il 50%, gli strumenti di gestione dei progetti come Microsoft Project e Project Server faranno alcuni presupposti per me. Si vedrà che in base ai dati limitati che hanno, è necessario aver trascorso 5 giorni di lavoro finora e avere 5 giorni di lavoro rimanente. Forse è vero, ma maschera una situazione in cui si è circa il 50 per cento completo, ma ci sono voluti 20 giorni di sforzo per arrivarci e quindi probabilmente hanno 20 giorni di lavoro rimanenti.

Misurare quanto rimane

Anni fa un film comico oscuro chiamato "The Money Pit" con Tom Hanks presentava una squadra di appaltatori che non sembravano mai essere fatti. La gag in esecuzione attraverso tutto il film è stata la risposta a "Quando sarà fatto?" "Altre tre settimane" direbbero tutti gli appaltatori.

Tuttavia, il rilevamento della durata rimanente è una qualità dei dati molto migliore rispetto alla semplice individuazione di una percentuale. La durata rimanente ci dà una forte attenzione su ciò che rimane per ottenere questo pezzo fatto e quando può il prossimo pezzo che dipende da questo iniziare. Esistono due modi per pensare alla durata rimanente in base alla configurazione delle attività. Il primo consiste nel pensare alla durata rimanente dell'attività totale. Ciò sarebbe opportuno se non ci concentrassimo sullo sforzo necessario per completarlo. Il secondo consiste nel pensare alla durata o allo sforzo rimanente necessario per ogni assegnazione. Ciò sarebbe più appropriato se le attività sono guidate da risorse. Ma o è un grande passo avanti da solo indovinare una percentuale.

Misurare quanto abbiamo speso

"Ho passato 10 giorni finora", è un modo per esaminare i progressi. A volte indicato come LOE o "Livello o sforzo". Il livello di sforzo è un ottimo modo per esaminare il nostro tasso di ustioni effettivo, ma porta un lato cieco. Sul lato positivo di questo metodo, abbiamo una grande comprensione di quanto abbiamo speso per questo compito finora. Sul lato negativo, potremmo non avere una grande comprensione di ciò che resta da fare. Essendo nel business della scheda attività, ci occupiamo spesso con le organizzazioni che tentano di implementare questo metodo. Un tempo il nostro staff pensava a questo metodo come appropriato solo se abbinato ad altre tecniche di rilevamento del progetto più sofisticate, ma ci è stato dimostrato che spesso è molto forte solo da solo. "Se potessimo solo determinare dove sta andando il nostro tempo", mi è stato detto da un cliente, "questo ci avrebbe messo così avanti rispetto a quello che abbiamo fatto, potremmo diventare quasi immediatamente più efficaci." Aveva ragione anche lui. È stata implementata una scheda attività che ha consentito di tenere traccia del tempo rispetto alle attività pianificate e questo da solo ha reso le organizzazioni estremamente più efficaci. In seguito sono stati in grado di aggiungere altri metodi di rilevamento per migliorare ulteriormente le prestazioni.

Si userà il metodo del costo realizzato

Il metodo del valore guadagnato è stato sviluppato circa 30 anni fa come un modo per controllare i progetti estremamente complessi, ma il concetto fondamentale è piuttosto semplice. Se facciamo un budget per un'attività, non importa quanto tempo spendiamo, non possiamo guadagnare più del 100% del budget. Il valore ottenuto si concentra sul rilevamento del completamento della percentuale "fisica" e che si presta bene ad alcuni tipi di progetti e non tanto ad altri. Se stiamo costruendo una strada, per esempio, e abbiamo 100 miglia di strada da costruire, quando siamo a 50 miglia, siamo a metà. Se hai speso il 75% dei soldi fino a quel punto, hai grandi problemi e il metodo del valore guadagnato lo renderà ovvio. Ciò indicherebbe che probabilmente andrai al 50% rispetto al budget al termine.

Se stai facendo ricerche per un nuovo farmaco o scrivendo software, quindi misurare la percentuale fisica completa può essere molto più sfuggente. La gente del valore guadagnato ha un'intera casella degli strumenti di possibili modi per ottenere questo tipo di progresso e di tutti, "tappe ponderate" sarebbe il mio preferito. In un ambiente di gestione dei progetti cardine ponderato, sono stati configurati i cardini principali del lavoro e, quando si arriva a tale traguardo, si ottiene la percentuale che avevamo concordato prima di iniziare tale attività cardine. La cosa grandiosa di questo metodo è che c'è poco dibattito. Hai completato l'attività cardine? Sì o No? In caso contrario, non hai guadagnato nulla. Se è così, hai guadagnato quella percentuale.

Il progetto Ivory Snow

Anche se si sta usando uno di questi metodi, una delle cose che si dovrebbe prestare attenzione per è quello che io chiamo il progetto "Ivory Snow". Questi progetti avanzano quasi immediatamente al 99,97% di completamento e quindi rimangono bloccati lì per il resto del tempo.

Come appariranno tutte queste cose?

Indipendentemente dallo strumento di gestione dei progetti in uso, la visualizzazione dello stato di avanzamento è spesso un elemento abbastanza comune dello schermo. Ecco un'immagine di Microsoft Project che mostra una barra con avanzamento del 50%:

Se questo è tutto ciò che stiamo monitorando, abbiamo almeno qualche idea di dove siamo diretti, ma strumenti moderni come Project e Project Server possono offrire molto di più. Se si imposta una linea di base per il progetto, sarà possibile confrontare non solo l'avanzamento dell'attività, ma anche il modo in cui viene confrontato con il piano originale.

Qui possiamo vedere che l'attività doveva essere completata al 50% ed è, ma è iniziata con una settimana di ritardo. Sul lato destro del bar, possiamo vedere che abbiamo trascorso il 50% del tempo e (tenendo conto dei fine settimana) abbiamo riempito il 50% del bar. Se fosse stato immesso il lavoro per le risorse, si potrebbero avere 80 ore lavorative al giorno e 40 ore. Questo è giusto sulla buona strada per questa attività se ci si pensa in isolamento, ma anche se l'attività può progredire al ritmo e burn rate che ci aspettavamo, sta ancora avendo un impatto negativo su tutte le attività che sono downstream.

Ok, sto rintracciando, ora cosa?

Ok, quindi abbiamo trattato alcune delle nozioni di base. Sei già tra i primi 20% dei responsabili di gestione dei progetti qualificati. Seriamente. Questo è già meglio dell'80% di quelli là fuori. Ora per qualcosa di fondamentale, ma potenzialmente molto impatto.

Se x, allora y

Ciò che voglio dire è che il rilevamento efficace richiede una formula di conseguenza: se x accade, quindi eseguire l'azione y.

Si tratta di una formula di base, ma una delle più difficili da formare le persone. Molti anni fa, ho avuto il privilegio di lavorare con una squadra di bagnini certificati a livello nazionale. Questi erano professionisti esperti, ma una cosa poteva essere praticata, ma mai veramente vissuta fino a quando non è successo: come avrebbe reagito il bagnino in una vera emergenza. Coloro che fanno parte delle forze armate spiegherebbe una sfida simile. Puoi allenarti, allenarti e allenarti, ma non sai davvero con certezza come qualcuno reagirà quando c'è un'arma reale sparata con rabbia nei loro confronti.

La gestione dei progetti non è fortunatamente una questione di vita o di morte, ma abbiamo un problema simile con coloro che tengono traccia dei progetti. Il project manager sa cosa deve fare quando il progetto non tiene traccia esattamente come previsto? Questo è qualcosa a cui si può pensare con molto anticipo. Hai un budget di emergenza di tempo e/o denaro? Si dispone di una catena di comandi per ottenere l'autorità di agire? Si dispone di un piano di comunicazione per raggiungere le persone giuste quando il progetto è in ritardo o meno? E quali risultati costituiscono un'azione? Vale la pena un rinvio di un giorno? Che ne dici di una settimana? Che ne dici di un aumento del rischio o dell'ambito? L'impostazione di alcuni standard per questo in anticipo può evitare sconvolgimenti in un secondo momento.

Trucco o traccia

L'impostazione dell'organizzazione o del progetto per implementare il rilevamento non è difficile. Quasi mai prodotto di gestione del progetto nel settore ha una certa capacità di memorizzare i progressi del progetto, ma c'è un aspetto culturale aziendale del tracciamento che deve ancora essere preso in considerazione per avere una buona probabilità di successo e che è quello di non sparare il messaggero. Molti project manager con cui ho parlato nel corso del tempo esprimono preoccupazioni sul fatto che la loro gestione trovi solo buone notizie accettabili quando ricevono i report di progetto.

Alcuni anni fa ero in una grande sala riunioni di una grande società multinazionale. Si è discusso dell'impatto dello strumento di gestione dei progetti che riceve informazioni dalla scheda attività pubblicata.

"Non capisco", ha detto un vicepresidente senior, "perché, quando si ottengono le ore della scheda attività, che le attività non aggiornano lo stato di avanzamento".

"Se avessi un'attività di 40 ore e mettessi 40 ore di lavoro dalla scheda attività in quell'attività, cosa ti aspetteresti che sia il risultato?" Ho chiesto.

Il VP ha guardato confuso alla domanda.

"Mi aspetto che sia completo", ha detto.

"Ma cosa succede se non è?" Ho risposto.

"Non capisco", ha detto l'ormai sconvolta VP. "Se si tratta di un'attività di 40 ore e hai fatto 40 ore di lavoro, allora deve essere finita."

Non ero sicuro di cosa rispondere, ma fortunatamente sono stato salvato dal capo del gruppo di progetto che ha chiesto di parlare con il VP fuori per un momento e presumibilmente ha spiegato che la vita non sempre segue il piano.

Fare in modo che la gestione comprenda che può avere l'impatto maggiore quando il progetto non va come previsto è qualcosa che può offrire enormi vantaggi tanto quanto l'insistenza del management che tutto il progetto deve segnalare lo stato di avanzamento pianificato può essere paralizzante.

Tenere traccia del progetto può essere un trattamento non solo per chi lo gestisce, ma anche per l'intera organizzazione.

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