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á…

El examen PMP se administra por centros Prometric con supervisión de Project Management Institute. Hace falta contestar correctamente el 61% – equivalente a 106 preguntas de 175. Hay que tener en cuenta que son 200 preguntas en total y las 25 son de prueba que no se tendrán en cuenta para el cálculo del resultado. Estas preguntas están insertadas de forma aleatoria durante entre preguntas reales y son necesarias para análisis estadístico realizado por PMI.

El periodo de garantía en proyectos de software es una parte integral del ciclo de vida del proyecto, por lo tanto a la hora de realizar estimaciones de esfuerzo – presupuestos, el hecho de tener disponible una determinada cantidad de recursos supone costes y gastos que en su mayor parte obviamos, dejándonos llevar por la ilusión de una nueva iniciativa. El soporte y mantenimiento fuera de garantía también son parte del ciclo de vida como bien indica Joe en su comentario, pero no del proyecto sino del producto. En estos casos las cuentas de cargo deben ser diferentes ya que no se trata de alcanzar los objetivos del proyecto en sí (ya lo hemos conseguido anteriormente, hurraaaa!), sino tomar las fases de soporte de la aplicación como un proyecto nuevo… con objetivos definidos, criterios y SLA’s establecidos y sobre todo con alguna rentabilidad, aunque eso es ya una decisión comercial. Si trabajamos con empresas de desarrollo de software, nos estarán eternamente agradecidos si tratamos el proyecto en sí, soporte dentro de garantía y también soporte posterior fuera de garantía como 3 proyectos independientes. Estos proyectos pueden llevarse acabo por diferentes grupos de trabajo, lo que evitará que el mismo grupo de programadores que inicialmente montaron la aplicación se quemen finalmente con la garantía o con el soporte posterior. La garantía es una obligación conjunta de todas las empresas que participan en el proyecto hacía el cliente. Por otro lado el mantenimiento y soporte fuera de garantía – no. El cliente tiene libertad de mantener la aplicación usando medios propios o subcontratar a la misma o una nueva empresa – un nuevo acuerdo. Para concluir, a veces algunos clientes una vez entregado el producto, se dan cuenta que para mantener el software a la par con sus crecientes demandas, debe existir un mantenimiento considerable, otros simplemente solicitan ampliaciones del alcance original del proyecto…

Agradecimientos a Joe por llamar mi atención sobre el tema de garantía y mantenimiento.

¿Puede existir una relación establecida entre el coste y el precio de proyecto? El precio, diríamos como regla, debería ser superior al coste, y corresponder al margen que la empresa desea sacar al realizar el proyecto más las reservas de contingencia; estén éstas reembolsables o no. Algunas veces por decisiones comerciales la empresa puede ofrecer servicios o productos a precios de coste o inferiores. Estas decisiones pueden están motivadas por el deseo de "entrar" al cliente y empezar a trabajar con él con la intención de recuperar las pérdidas en futuros proyectos. Otro ejemplo podría ser venta de consolas PS3 o incluso impresoras, el coste de fabricación, comercialización es superior al precio venta público, sin embargo los fabricantes recuperan las pérdidas con la venta de consumibles como cartuchos para impresoras, mantenimiento integrado, royalties por la venta de juegos, etc.

Nos llega por correo del jefe o directamente del cliente una petición de estimar un proyecto basándose en un fichero adjunto. Ese es el escenario más común a partir del cual empiezan nuestras peripecias para responder al requerimiento usando ¿sólo? la información proporcionada… Según el alcance y el detalle de información incluida en la documentación de requerimientos podemos utilizar una o varias técnicas de estimación de proyectos. Imaginemos que con suerte el documento anexo es un análisis funcional con casos de uso de la aplicación (escenario óptimo), en este caso hemos tenido suerte ya que según el esmero del personal técnico y el nivel de insistencia podemos usar cualquiera de las técnicas más comunes de estimación (FP – Puntos Funcionales, UCP – Puntos de Casos de Uso, EDT/WBS – Bottom up, etc.). Pero no siempre es así, suelen llegar documentos poco detallados y ambiguos que no permiten estimación cerrada fiable. Para estos casos se puede todavía aplicar estimaciones por puntos funcionales (FP), lógicamente no obtendremos estimaciones fiables cerradas. Es nuestro deber informarle al cliente o al sponsor, o alternativamente intentar solicitar aclaraciones y más detalles. Desde el punto de vista de precisión de la estimación tenemos siguientes tipos:

• Estimación de Orden de Magnitud (ROM) Precisión -25% +50/75%
• Budget Precisión -15% +30%
• Definitiva (cerrada) Precisión -5% +15%

Continuará…

Al entregar un proyecto de software aunque tengamos muy presente las enseñanzas de Philip Crosby siempre existirán fallos, incidencias e incluso defectos que deberán ser tratados. Proyectos comerciales de desarrollo de software suelen llevar de 3 a 6 meses de garantía después de la entrega del proyecto. El cliente debe instalar el software y validarlo lo antes posible y siempre dentro de este periodo de tiempo. Aunque pueden existir periodos de garantía más amplios, son acuerdos comerciales puntuales entre cliente y proveedor. Durante el periodo de garantía las incidencias encontradas deben ser reportadas formalmente y arregladas por parte del proveedor sin cargo alguno – mantenimiento correctivo del producto en garantía. Cualquier cambio – Change Request – introducido durante la garantía y aprobado por CCB debe ser facturado ya que se encuentra fuera del alcance inicial de los trabajos. Al finalizar la garantía, a fin de mantener el proyecto vivo, es responsabilidad del proveedor de sugerir la formalización de un acuerdo de mantenimiento. Estos acuerdos suelen ser anuales, dónde para mantenimiento correctivo se establece una bolsa de horas mensual, que si no se llega a utilizar puede ser acumulada y usada durante la validez del contrato (un año). Al renovar el acuerdo las horas no consumidas se restablecen a favor del proveedor ya que éste reserva horas de recursos para ello. Para mantenimiento perfectivo igual que adaptivo - Change Requests – no se reserva una bolsa de horas dentro del acuerdo, sólo se define el precio hora.

Para reducir la duración de un proyecto podemos usar diferentes técnicas como por ejemplo crashing y fast tracking. Actuaremos con éstas técnicas siempre sobre el plan de proyecto que hemos preparado, teniendo en cuenta que la duración de camino crítico es la duración del proyecto y que puede existir más de un camino crítico.

Crashing - Esta técnica permite reducir la duración del proyecto cuando hay exceso de trabajo y la duración debe ser reducida sea dedicando horas adicionales o involucrando nuevos recursos. Esta técnica aunque puede reducir la duración del proyecto pero implica aumento de costes. Tiene sus ventajas y desventajas.

• Soft crashing - Este tipo de crashing se hace dedicando horas extra. Es efectivo pero no es sostenible. Se puede utilizar durante periodos cortos de tiempo a fin de evitar quemar al equipo.
• Hard crashing – Consiste en involucrar a nuevos recursos al proyecto. Es una opción cara y si se introduce tarde en el proyecto inefectiva ya que existen las desventajas de que el equipo que se acaba de unir debe aprender lo que sabe el equipo actual y éste debe dejar de hacer su trabajo para enseñar. Pueden también existir circunstancias cuando no se debe añadir nuevo equipo ya que las tareas están suficientemente distribuidas, si ese es el caso se requerirá el uso de un recurso dedicado a la integración (configuration manager).

Fast tracking – Esta técnica de igual forma que crashing reduce la duración del proyecto pero incrementa el riesgo de tener que rehacer partes ya realizadas. Consiste en jugar con las dependencias fin – inicio. En circunstancias normales si existe esa dependencia una tarea debe terminar para que empiece la siguiente, pero con fast tracking la segunda tarea puede empezar lo antes posible e incluso correr en paralelo con la primera. Se realiza paralelización de trabajo pero teniendo en cuenta que los requerimientos que se conocerían al terminar la primera tarea no se conocen y que el otro desarrollador empieza con la segunda tarea sin esperar el fin de la primera, puede ser que se necesite realizar, reajustes en las dos tareas para que los componentes interoperen correctamente.