Fast-tracking e crash possono far tornare il tuo progetto sulla tabella di marcia

I project manager dovrebbero valutare le loro schedulazioni su base settimanale per assicurarsi che il loro progetto rimanga in pista. Se il progetto inizia ad andare alla deriva, ci sono una serie di tecniche che possono essere usate per tornare sulla tabella di marcia. La maggior parte di queste non sono drammatiche.

Punte nella tua casella di posta

Cercando l’esperto IT project management? Ottieni l’aiuto che ti serve dalla newsletter gratuita di TechRepublic sulla gestione dei progetti, consegnata ogni mercoledì.

Iscriviti automaticamente oggi stesso!

Tuttavia, supponiamo che il tuo progetto inizi a slittare drammaticamente. Potrebbe non essere possibile rimettersi in carreggiata attraverso le tipiche tecniche di gestione delle scadenze. Supponiamo inoltre che la scadenza del progetto sia fissa e non possa cambiare. In questo caso potresti aver bisogno di impiegare mezzi più drammatici. Due tecniche da considerare sono il fast tracking e il crash.

Fast tracking

Fast tracking significa che guardi le attività che normalmente sono fatte in sequenza e le assegni invece parzialmente in parallelo. Per esempio, normalmente non iniziereste a costruire una soluzione fino a quando il design non è stato completato. Tuttavia, se si facesse fast-tracking, si inizierebbe a costruire la soluzione nelle aree in cui si ritiene che il progetto sia abbastanza solido senza aspettare che l’intero progetto sia completato. Il fast-tracking implica sempre un rischio che potrebbe portare a un aumento dei costi e a qualche rilavorazione in seguito. Per esempio, nell’esempio della progettazione e costruzione di un’applicazione, è possibile che il progetto possa cambiare prima che sia finalizzato, e quei cambiamenti finali possono risultare nel dover rifare alcuni dei lavori di costruzione già in corso.

Una buona regola empirica è che le attività sequenziali a volte possono essere velocizzate fino al 33%. In altre parole, se si fa il refast-tracking, si può iniziare la seconda di due attività sequenziali quando la prima attività è completa al 66%. C’è un rischio implicito. Tuttavia, questo sembra essere un livello di rischio di fast-tracking che è normalmente accettabile.

Crashing

“Crashing” del programma significa gettare risorse aggiuntive sul percorso critico senza necessariamente ottenere il massimo livello di efficienza. Per esempio, diciamo che una persona stava lavorando su un’attività di dieci giorni sul percorso critico. Se foste davvero disperati per accorciare questo lasso di tempo, potreste aggiungere una seconda risorsa a questa attività. Infatti, la risorsa potrebbe non avere tutte le competenze giuste e potrebbe lavorare cinque giorni solo per ridurre il tempo complessivo di due giorni.

In superficie, il compromesso precedente potrebbe non avere senso. Dopo tutto, perché dovresti far lavorare una persona cinque giorni solo per ridurre un’attività di due giorni? Non è efficiente. Tuttavia, puoi immaginare un progetto così importante da essere disposto a fare questo tipo di compromesso? Pensa ai progetti YR2K. Quando la fine del 1999 stava rotolando intorno, molte aziende stavano gettando risorse sui progetti; disperatamente per farli completare in tempo. Facevano fast-tracking.

Le risorse aggiuntive possono venire dall’interno del team del progetto, o possono essere prestate temporaneamente dall’esterno del team. Uno degli obiettivi dell’abbattimento del programma è di minimizzare il costo incrementale. Tuttavia, in cambio del completamento di alcuni lavori in anticipo sulla schedulazione, il crash di solito porta sempre ad un costo incrementale aggiuntivo per il progetto. Se sei disposto e capace di spendere di più per accelerare la schedulazione, il fast-tracking può essere un’opzione fattibile per te.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.