En un mot - la contingence.
La contingence est le montant que vous ajoutez pour «d'autres choses» - les choses que vous ne pouvez pas expliquer ailleurs dans votre estimation. SMc le couvre-t-il dans l'estimation de logiciels? Je ne me souviens pas et ma copie est au travail (je suis en vacances pour répondre à cela - comme je suis triste) ...
Quoi qu'il en soit, de manière générale, il y a trois types de contingence que je recommanderais d'examiner:
1) Risque spécifique au risque - c'est là que vous identifiez un risque spécifique et ajoutez un certain temps pour couvrir le dépassement potentiel qui y est lié. La première chose à préciser ici est ce qu'est un risque - c'est quelque chose qui peut arriver, qui aura un impact négatif sur le projet, qui est hors de votre contrôle .
Cette dernière partie est critique - ce n'est pas seulement "les choses prennent un peu plus de temps que je ne le pensais", c'est "le module de planification tiers que l'on nous a dit que nous devons utiliser car c'est une norme d'entreprise qui n'est peut-être pas à la hauteur". La façon dont vous calculez la quantité de risques à ajouter est le pourcentage de chances que le risque puisse se produire, exprimé sous forme décimale (donc 50% = 0,5), multiplié par l'impact de ce risque (dans l'exemple, par exemple, vous devez écrire manuellement CRON au lieu d'utiliser le planificateur et cela prendra 10 jours, ce nombre est de 10 jours).
Donc, s'il y a 50% de chances que votre risque se concrétise et qu'il faudra 10 jours d'efforts pour le contourner, si vous le faites, vous ajoutez 5 jours. Additionnez toutes les valeurs de tous les risques identifiés sur le projet et ajoutez-les au total.
2) Shit Happens Contingency - La meilleure description que j'aie jamais entendue, même si elle n'est pas élégante. C'est un projet informatique, ça se passe. Cela ne se passe jamais comme vous le pensez, les choses prennent plus de temps, vous manquez, etc. Généralement, la contingence SH sera comprise entre 10% (minimum absolu) et 25% (mais peut être plus élevé), 15% étant à peu près typique, le niveau exact dépendant du niveau d'incertitude et du risque général (déplacement des poteaux de but, exigences incertaines, etc.) ).
Si votre PM n'accepte pas la contingence SH (et c'est possible, il pourrait ne pas avoir d'expérience des projets informatiques ou être un optimiste aveugle), alors ajoutez-le simplement à tous les montants individuels. S'il sait ce qu'il fait, il aura son propre journal des risques et vous aimera pour avoir pensé à ce genre de choses. Certes, s'il a une qualification PM (comme PRINCE2), il le saura.
3) Contingence de changement - C'est là que vous êtes à peu près sûr que le client apportera des modifications mais ne voulez pas que ce soit un point de discorde. Ajoutez X jours ou X% et cela va dans un pot pour les changements que le client soulève. Il y a deux façons de le gérer: soit vous leur en parlez et c'est à eux de dépenser, soit vous ne leur en parlez pas.
La première façon est la meilleure, mais nécessite un client assez éduqué et juste - les choses sont classées comme des changements et il peut dépenser son pot comme bon lui semble (en fonction de votre estimation des choses à mesure qu'elles se présentent).
La deuxième façon, vous mentionnez que c'est un changement, mais ne cherchez pas à lui faire payer un supplément. Vous devez noter toutes les choses que vous dépensez, donc si cela arrive au point où il s'épuise et vous devez retourner auprès du client et demander plus de temps ou d'argent et ils disent "attendez, je" Je paie bla bla bla "vous pouvez signaler toutes les choses qu'ils ont déjà changées et que vous n'avez pas facturées comme signe que vous n'êtes pas totalement déraisonnable. Cela ne fonctionne pas toujours mais cela renforce presque toujours votre main dans les discussions.
Aucun de ces trois ne couvre spécifiquement les choses que vous avez oubliées, mais je pense qu'entre elles, vous comblerez beaucoup des lacunes que vous avez.