In una parola: contingenza.
La contingenza è l'importo che aggiungi per "altre cose" - le cose che non puoi tenere conto altrove nel tuo preventivo. SMc lo copre nella stima del software? Non ricordo e la mia copia è al lavoro (sono in vacanza e rispondo a questo - quanto sono triste) ...
Ad ogni modo, in generale ci sono tre tipi di contingenza che consiglierei di guardare:
1) contingenza specifica del rischio : è qui che si identifica un rischio specifico e si aggiunge un certo periodo di tempo per coprire il potenziale superamento ad esso correlato. La prima cosa da chiarire qui è il rischio: è qualcosa che potrebbe accadere, che avrà un impatto negativo sul progetto, che è al di fuori del tuo controllo .
Quest'ultima parte è fondamentale - non è solo "le cose richiedono un po 'più di quanto pensassi", è "il modulo di programmazione di terze parti che ci è stato detto che dobbiamo usare in quanto è uno standard aziendale potrebbe non essere all'altezza del compito". Il modo in cui calcoli quanta contingenza di rischio aggiungere è la probabilità percentuale che il rischio possa manifestarsi espressa in decimali (quindi 50% = 0,5), moltiplicata per l'impatto di tale rischio (quindi nell'esempio dire che è necessario scrivere CRON manualmente lavori invece di utilizzare lo scheduler e questo richiederà 10 giorni, questo numero è di 10 giorni).
Quindi, se c'è una probabilità del 50% che il tuo rischio si verifichi, e ci vorranno 10 giorni di sforzo per aggirarlo se lo fa, aggiungi 5 giorni. Aggiungi tutti i valori per tutti i rischi identificati nel progetto e aggiungili al totale.
2) Shit Happens Contingency - La migliore descrizione che io abbia mai sentito per questo, anche se non è elegante. È un progetto IT, succede di merda. Non va mai come pensi che succederà, le cose richiedono più tempo, si perdono e così via. Generalmente la contingenza SH sarà compresa tra il 10% (minimo assoluto) e il 25% (sebbene possa essere più elevato) con il 15% circa tipico, il livello esatto dipende dal livello di incertezza e rischio generale (spostamento dei pali degli obiettivi, requisiti incerti e così via ).
Se il tuo PM non accetta la contingenza SH (ed è possibile, potrebbe non avere esperienza di progetti IT o essere un ottimista cieco), quindi aggiungilo a tutti i singoli importi. Se sa cosa sta facendo, avrà un registro dei rischi tutto suo e ti amerà per aver pensato a queste cose. Certamente se ha qualche tipo di qualifica PM (come PRINCE2) lo saprà.
3) Modifica contingenza : è qui che sei abbastanza sicuro che il cliente aumenterà le modifiche ma non vuoi che sia un punto di contesa. Aggiungi X giorni o X% e va in un piatto per le modifiche che il cliente solleva. Esistono due modi per gestirlo: o glielo dici ed è il loro da spendere o non glielo dici.
Il primo modo è il migliore, ma ha bisogno di un cliente abbastanza educato ed equo - le cose sono classificate come cambiamenti e lui può spendere il suo piatto come meglio crede (in base a te che valuta le cose mentre escono).
Il secondo modo in cui dici che è un cambiamento, ma non cercare di addebitarlo di più. Devi annotare tutte le cose in cui lo spendi, quindi se arriva al punto in cui si esaurisce e devi tornare dal cliente e chiedere più tempo o denaro e loro dicono "aspetta, io" sto pagando blah blah blah "puoi indicare tutte le cose che sono già cambiate che non hai addebitato come segno che non sei del tutto irragionevole. Non sempre funziona, ma quasi sempre rafforza la tua mano nelle discussioni.
Nessuna di quelle tre copre specificamente le cose che hai dimenticato, ma penso che tra di esse riempirai molte lacune che hai.