Recibidos los requerimientos del proyecto de un cliente procedemos a validarlos y realizar la estimación del esfuerzo. Después de varios días de reuniones, realización de WBS y la preparación de un PP detallado enviamos la propuesta al cliente. Pasan varios días, semanas y el cliente no da señales de vida. De repente contesta y facilita requerimientos adicionales y pide volver a estimar el proyecto. El equipo vuelve a reunirse, se validan las nuevas premisas y su implicación sobre la línea base marcada. Project Plan actualizado, la propuesta modificada y enviada al cliente. Pasan varias semanas, el cliente contesta informando de que les parece bien la propuesta sin embargo han realizado varios cambios y necesitan que se actualice la estimación, alcance y en fin la propuesta. ¿Fue correcto el comportamiento del project manager en la primera instancia cuando el cliente solicitó actualización? "Sí" y "No", "Sí" en caso de que la decisión fue tomada con criterio comercial, sin embargo "No" desde el punto de vista de la gestión. En mi opinión lo correcto sería fijarle con el cliente un marco básico de alcance y en base a la estimación aceptada desarrollar las modificaciones en formato Change Requests que deberían ser estimados de forma independiente del core de proyecto. Asimismo favoreceríamos la claridad, modularidad del proyecto así como la gestión.

¿En qué consiste una estimación del proyecto? Cada vez que un cliente solicita un presupuesto en esta acostumbrado o mejor dicho habituado a recibir un presupuesto según determinados criterios implícitamente claros para él. Para que el presupuesto no juegue con una desventaja innecesaria, preguntamos al cliente el formato en el que desea recibir el presupuesto. Tratándose del gobierno, nos lo indicarían en el pliego, pero si tratamos con empresas medianas o pequeñas debemos intentar de forma explicita solicitar esta información a fin de que el cliente tenga facilidades para leerlo. En aquellos casos cuando esta info adicional no esta disponible recomiendo facilitarle al cliente la estimación de forma escalonada, salvo que hayan instrucciones en contra. La estimación ocupa tiempo y recursos, para intentar asegurarse de que cuando lo preparemos y se lo enviaremos no se asusta, primero sería prudente facilitarle un orden de magnitud, como si avisáramos sobre el alcance. Si vemos que la reacción es favorable, pues a continuación tranquilamente podemos dedicarnos a realizar una estimación bottom-up. Este paso previo sirve como hemos visto para reducir un poco el riesgo. Para facilitarle un presupuesto al cliente sobre un proyecto, sería adecuado el formato de MS Project o cualquier otra alternativa que permita plasmar de forma gráfica las tareas, costes, duración, dependencias entre las tareas, etc. Un WBS con un diccionario WBS de alto nivel para explicar en que consiste cada una de las tareas. El último documento permite entender al cliente el contenido de paquetes de trabajo. Y cuando el cliente se pronuncie favorablemente sobre nuestra estimación en MS Project podemos concluir esta fase del proyecto formalizando un Statement of Work, dónde se definen claramente las condiciones comerciales, alcance, fechas, embediendo el presupuesto en MS Project original.

Continuando con el tema de estimaciones de proyecto, tenemos un escenario donde se nos ha facilitado un documento breve que describe en términos generales el alcance del proyecto. El documento contiene suficiente información para poder preparar estimaciones de tipo ROM o en mejor de los casos Budget, sin embargo el cliente desea que nos comprometamos con un precio cerrado. En estos casos debemos barajar siguientes variables:

1. Background y conocimiento del Cliente
2. Plazo para proporcionar la estimación
3. Importancia proyecto (volumen de negocio, cliente, etc.)
4. Riesgo vs. volumen información proporcionada.
5. Relación que existe con el cliente y confianza.

Consideremos diferentes escenarios:

• Worst Case Scenario. El cliente tiene pocos conocimientos técnicos y su background no permite elaborar documentación como casos de uso o análisis funcional para correcta estimación del proyecto. El cliente tiene mucha prisa y solicita un presupuesto "ya". Es un cliente nuevo y no tenemos una relación de confianza establecida.
  • Evaluando la importancia del proyecto y cliente para la empresa el PMO únicamente puede preparar estimaciones ROM y Budget, pero será la decisión de la dirección comercial de la empresa si desea adquirir un compromiso con el cliente, considerando una de nuestras estimaciones como fija.
  • El cliente no busca soluciones alternativas sino una estimación y nada más, la otra opción que nos quedaría es ser transparentes e informarles que con el volumen de requerimientos que tenemos no podemos abordar el proyecto en condiciones de seguridad o riesgo conocido.

• Best Case Scenario. El cliente aunque no tenga conocimientos técnicos y preparación para crear el documento por sí entiende la complicación de la preparación de una estimación fija ya que no desea otro tipo de ofertas, sin embargo dispone de tiempo para ayudar a la empresa a preparar la documentación de requerimientos con suficiente detalle. En este caso se podría ofrecerle romper el proyecto en 2 fases:
  • En la primera fase se realizaría un trabajo onsite en instalaciones del cliente, recogiendo toda la información necesaria para preparar unos casos de uso en condiciones. Este documento podrá ser usado por cualquier otra empresa de gestión de proyectos o empresa desarrolladora de software. Se puede formalizar este trabajo de consultoría con contrato de tipo "time and material" o "precio fijo" (incluyendo desplazamientos, consultoría y etc.).
  • En la segunda fase con la documentación de casos de uso preparada se puede realizar una estimación fija. Normalmente si en la primera fase la empresa se muestra profesional, el cliente suele confiar en su criterio. En este caso el cliente si lo desea puede tener contrato de tipo firm fixed price FFP – precio fijo.

Continuará…