ICT - Project Management - Gestione del tempo in ambiente multi-progetto

 

I problemi che riguardano i progetti sono relativi a :

  • ritardi nel concludere un progetto
  • eccessivi mutamenti in corso d’opera
  • indisponibilità delle risorse umane nel momento in cui si è stabilito
  • indisponibilità delle infrastrutture necessarie nei momenti stabiliti (server, licenze, installazioni, collegamenti, ecc)
  • conflittualità tra le priorità dei progetti
  • superamento delle spese stabilite
  • eccessive rielaborazioni di parti del lavoro

I problemi elencati si tende a risolverli dilatando i tempi di realizzazione del progetto e pregiudicando la qualità del lavoro.

In tutti e due i casi si presuppone in modo sbagliato che non si abbiano margini per gli imprevisti avuti.
In realtà il tempo a disposizione viene spesso sprecato. i progetti che terminano in ritardo sono molto al di sopra del 20 %.

 

riga3.gif

 

Self Fulfillment

Il fenomeno appena descritto viene nominato fulfillment, le sue cause sono:

  • perfezionismo
  • sindrome dello studente
  • mancanza di stimoli a portare a termine un progetto nei tempi stabiliti, anche a causa della mancanza di premi
  • mancanza di focalizzazione
  • presenza di milestone
  • multitasking
  • mancanza di reporting per gli anticipi e solo per i ritardi
  • legge di parkinson

 

Gli effetti del fulfillment:

  • potenzialità di terminare un progetto in anticipo non sfruttata adeguatamente
  • progetti penalizzati da attività lavorative che terminano in ritardo
  • perdita degli anticipi a discapito dei ritardi che si accumulano

gli effetti porteranno ineluttabilmente in un ritardo del progetto, vi è quindi occorrenza di un sistema che possa permettere al project manager di focalizzarsi sul progetto evitando lo spreco del safety time

 

Nuovo sistema di programmazione e controllo

  • diminuire i tempi di ogni attività annullando i safety time di ognuno
  • definire la protezione sui tempi di realizzazione del progetto (project buffer) che deve essere uguale o più basso ai safety time che si è riusciti a recuperare
  • proteggere il cammino critico dai ritardi sui cammini non critici (buffer time)
  • controllare il progetto facendo attenzione sul cammino critico e sulle risorse critiche (colli di bottiglia)

 




You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Leave a Reply