En una palabra: contingencia.
La contingencia es la cantidad que agrega por "otras cosas": las cosas que no puede tener en cuenta en otra parte de su estimación. ¿SMc lo cubre en la estimación de software? No puedo recordar y mi copia está en el trabajo (estoy de vacaciones respondiendo esto, qué triste estoy) ...
De todos modos, en general, hay tres tipos de contingencia que recomendaría mirar:
1) Contingencia específica de riesgo : es donde identifica un riesgo específico y agrega una cierta cantidad de tiempo para cubrir el posible exceso relacionado con él. Lo primero que debe quedar claro aquí es qué es un riesgo: es algo que puede suceder, que tendrá un impacto negativo en el proyecto, que está fuera de su control .
Esta última parte es crítica: no se trata solo de "cosas que tardan un poco más de lo que pensaba", es "el módulo de programación de terceros que nos han dicho que tenemos que usar, ya que es un estándar de la compañía que podría no estar a la altura de la tarea". La forma en que calcula cuánta contingencia de riesgo agregar es el porcentaje de probabilidad de que el riesgo pueda pasar expresado como un decimal (50% = 0.5), multiplicado por el impacto de ese riesgo (en el ejemplo, digamos que necesita escribir manualmente CRON trabajos en lugar de usar el planificador y esto llevará 10 días, este número es de 10 días).
Entonces, si hay un 50% de probabilidad de que su riesgo se cumpla, y tomará 10 días de esfuerzo para evitarlo, agrega 5 días. Sume todos los valores para todos los riesgos identificados en el proyecto y agréguelo al total.
2) La mierda sucede con la contingencia : la mejor descripción que he escuchado sobre ella, incluso si no es elegante. Es un proyecto de TI, sucede una mierda. Nunca funciona como crees que será, las cosas tardan más, te las pierdes, etc. En general, SH Contingency estará entre el 10% (mínimo absoluto) y el 25% (aunque puede ser mayor), siendo el 15% aproximadamente típico, el nivel exacto depende del nivel de incertidumbre y riesgo general (traslados de objetivos, requisitos inciertos, etc.) )
Si su PM no acepta SH Contingency (y es posible, es posible que no tenga experiencia en proyectos de TI o sea un optimista ciego), simplemente agréguelo a todas las cantidades individuales. Si sabe lo que está haciendo, tendrá un registro de riesgos propio y te amará por pensar en estas cosas. Ciertamente, si tiene algún tipo de calificación de PM (como PRINCE2), lo sabrá.
3) Cambio de contingencia : aquí es donde está bastante seguro de que el cliente generará cambios pero no quiere que sea un punto de contención. Agregue X días o X% y se coloca en una olla para los cambios que el cliente plantea. Hay dos formas de lidiar con esto: o les dices al respecto y es para que ellos gasten o no les cuentas al respecto.
La primera forma es mejor, pero necesita un cliente bastante educado y justo: las cosas se clasifican como cambios y él puede gastar su bote como lo considere conveniente (según usted estima las cosas a medida que surgen).
La segunda forma en que mencionas que es un cambio, pero no buscas cobrarle más. Debe tener en cuenta todas las cosas en las que lo gasta, por lo que si llega al punto de que se agota y tiene que volver al cliente y pedir más tiempo o dinero y le dicen "espera, yo" "Pagando, bla, bla, bla", puedes señalar todas las cosas que ya han cambiado y que no has cobrado como una señal de que no estás siendo completamente irracional. No siempre funciona, pero casi siempre fortalece tu mano en las discusiones.
Ninguno de esos tres cubre específicamente las cosas que has olvidado, pero creo que entre ellas llenarás muchos de los vacíos que tienes.