La empresa y el nombre del proyecto no se mencionan por confidencialidad, pero los datos son reales.

El proyecto

La definición del proyecto que proporcionó el cliente en primera instancia fue la siguiente: “Desarrollar solución técnica que permita brindar el servicio de tercero confiable para apoyo n las operaciones de comercio exterior”.

Como podemos ver, la información está dada a un nivel de abstracción muy alto y es muy ambigua. El cliente pidió con esto una cotización, lo que implicaba una estimación de duración y esfuerzo del proyecto.

Aunque sé que muchas personas por la finalidad de vender o por la costumbre de realizar así las estimaciones se verían tentados a dar los números solicitados, la realidad es que se pidió más información al cliente, éste proporcionó la siguiente información:

• Contar con una herramienta que permita apoyar la operaciones de Comercio Exterior de carga, sin la necesidad de presentación física de papeles, haciendo más eficientes los procesos en las agencias aduanales en cuestión de resguardo y localización de pedimentos, sus anexos y documentos relacionados.

• Contar con una herramienta que permita el resguardo digital de pedimentos, sus anexos y documentos relacionados por medio de un expediente único.

• Dentro del proceso de resguardo de archivos autentificar los mismos mediante el certificado digital de Firma Electrónica Avanzada.

• Contar con esquemas de búsqueda y consulta de información de acuerdo al rol del área y vigencia de resguardo.

• Contar con esquema de “Facturación” que incluya costeo de almacenamiento, manejo de niveles de cuotas, bonificaciones y emisión de reportes.

• Contar con información histórica (documentos) con una antigüedad hasta por 10 años.

  
  

Contexto del proyecto

El grupo que realizó las estimaciones conocía el contexto en el cual se realizaría el proyecto que lo describió de esta manera:

• El equipo que iba a realizar la solución no contaba con un buen conocimiento del negocio ya que usualmente ellos se dedicaban a cuestiones financieras.

• Tampoco se contaba con toda la experiencia de las tecnologías involucradas para el desarrollo de la solución como digitalización y firma electrónica aunque conceptualmente se conocían.

• El líder de proyecto no tenía toda la disponibilidad ya estaba compartido en tres proyectos y el suplente no tenía mucha experiencia ni liderazgo para llevar a cabo un proyecto de manera independiente.

  
  

Herramientas utilizadas para la estimación

Las herramientas con las que contaba la organización que realizó este proyecto eran la experiencia o sus expertos (herramientas empíricas, hojas de Excel generadas a partir de la experiencia, ejercicios históricos de FP (IFPUG) y Use Case Points (UCP) y una clasificación en rangos de esfuerzo históricos por tipo de proyecto específica para la organización

Resultados

El proyecto que se estimó originalmente en 5 meses por un grupo de expertos de la organización terminó en realidad en 13.25 meses lo que implicó un retraso de 165%. Cabe mencionar que este grupo realizó originalmente la estimación, en un aproximadamente una de esfuerzo.

Se puede observar claramente que el realizar malas estimaciones tiene una repercusión directa en la economía de las empresas ya que este tipo de defasamientos, que son comunes en la industria implica que alguien tiene que absorber el gasto, ya sea el cliente o el proveedor, implicando negociaciones por demás complejas y desgastantes.

“De acuerdo al testimonio de la Government Accountability Office el pasado septiembre, si se establecieran con más realismo las líneas base de los requerimientos, costos, calendario y riesgos durante las fases de planeación de proyectos, cerca de la mitad de cancelaciones o programas que rebasan el presupuesto de TI podrían ser evitados. Eso ahorraría anualmente $5.5 billones, de acuerdo a un estudio hecho por Price Systems LLS, una compañía de software y consultoría de Mount Laurel, N.J de EEUU. El estudio considera 140 ejecutivos TI del Gobierno”.

Con este método de estimación, las partes interesadas​​con una visión ambiciosa pueden establecer un cronograma o presupuesto general para un proyecto sin conocer todos los detalles. Luego, se puede dividir el plan en partes más pequeñas y delegar los detalles a aquellas personas con más conocimiento acerca de las especificaciones del proyecto.

Supongamos, por ejemplo, que tu empresa está planificando el lanzamiento de un producto nuevo en los próximos seis meses. Esta iniciativa involucraría a casi todos los equipos, desde desarrolladores hasta especialistas en marketing. Dado que conoces el cronograma general, puedes desglosar el proyecto en fases más pequeñas con cronogramas individuales asignados a equipos específicos.

Por lo general, se prefiere una estimación ascendente a una estimación descendente, ya que las personas que realizan el trabajo son las mismas que establecen el cronograma y el presupuesto. También es más probable que se realicen estimaciones más precisas.

Si consideramos el ejemplo anterior, es posible que te preguntes por qué este equipo de gestión optó por un cronograma de seis meses para el lanzamiento del producto. Si la gerencia hubiera consultado primero con cada uno de los departamentos, tal vez habría llegado a la conclusión de que ocho meses era un plazo más realista.

Si bien el método de estimación ascendente no siempre es una opción cuando los plazos o los presupuestos son ajustados, los gerentes generalmente lo prefieren al método de estimación descendente. Sin embargo, aunque este método es más preciso, lleva un poco más de tiempo armarlo.

• Tu mejor estimación

• Tu estimación optimista

• Tu estimación pesimista

Esta técnica se suele combinar con el método ascendente para crear estimaciones aún más precisas.

Por ejemplo, supongamos que estás planificando la fase de desarrollo de tu producto. Si todo sale según lo planeado, deberías tener una versión beta dentro de tres semanas (tu mejor estimación). Si el equipo obtiene la aprobación para el uso de un software más potente, entonces el desarrollo podría tomar tan solo dos semanas (tu estimación optimista). Pero si se presentan varios mensajes de error o fallas, esta fase podría demorar hasta cinco semanas (tu estimación pesimista).

Si realizas un promedio de las estimaciones de tres, dos y cinco semanas, puedes predecir que la tarea tomará alrededor de tres semanas y media.

Para esta técnica se usa un conjunto de algoritmos para calcular la estimación. Supongamos que tu equipo de marketing tardó cuatro semanas en desarrollar la campaña para el último lanzamiento de producto. Este proyecto se realizó hace un año y, actualmente, tu equipo cuenta con el doble de colaboradores. Si todos los miembros del equipo están involucrados en la campaña, puedes suponer que esta vez solo tomará dos semanas completar la misma tarea.

Este método tiene en cuenta las habilidades, la experiencia y los conocimientos especializados al momento de realizar una estimación. Es posible que debas colaborar con otros miembros de tu equipo, partes interesadas del proyecto, consultores o expertos en la materia para obtener la información que necesitas.

El juicio de expertos es un método útil si tienes como prioridad evaluar las respuestas a los riesgos o las oportunidades del proyecto. Sin embargo, ten en cuenta los sesgos que podrían distorsionar tus datos, como el exceso de confianza.

Este proyecto consistía en desarrollar un sistema de gestión documental para una empresa de logística. El sistema debía permitir el almacenamiento, búsqueda y consulta de documentos relacionados con operaciones de transporte y gestión de cargas, incluyendo funcionalidades para la gestión de facturación, cálculos de almacenamiento y búsqueda avanzada de información. Además, el sistema debía cumplir con regulaciones de seguridad y contar con mecanismos de firma electrónica para la autenticación de documentos.

Al igual que en el ejemplo anterior, la descripción inicial del proyecto era bastante general y no definía con precisión todos los requerimientos. A pesar de esta ambigüedad, la empresa solicitó una cotización que incluyera estimaciones de tiempo, esfuerzo y costos.

Contexto del proyecto

El equipo encargado del proyecto tenía experiencia en el desarrollo de software para la gestión de inventarios, pero carecía de un conocimiento profundo en las regulaciones específicas del sector de la logística y los requerimientos tecnológicos relacionados con la firma electrónica y la seguridad documental.

Además, el líder del proyecto estaba asignado simultáneamente a otros dos proyectos, lo que limitaba su capacidad para supervisar este nuevo desarrollo de manera integral.

Herramientas utilizadas para la estimación

La organización empleó una combinación de técnicas empíricas basadas en la experiencia previa y herramientas automatizadas para calcular los puntos de función (IFPUG) y los puntos de casos de uso (UCP). La estimación se apoyó en hojas de cálculo de Excel, en las que se documentaron las horas de trabajo necesarias según la complejidad de las funcionalidades solicitadas, basándose en proyectos similares previos.

También se utilizó una técnica de estimación "bottom-up", donde se desglosaron todas las tareas en elementos individuales, lo que permitió calcular de manera detallada las horas de trabajo de cada especialista involucrado en el proyecto.

Resultados

Inicialmente, la estimación de tiempo y esfuerzo fue de 7 meses, con un costo total estimado en $200,000. Sin embargo, varios factores no previstos retrasaron la entrega final del proyecto:

1. Falta de conocimiento del equipo: Al igual que en el ejemplo anterior, el desconocimiento del equipo sobre el dominio específico del negocio y las tecnologías clave retrasó el desarrollo de ciertas funcionalidades, en particular las relacionadas con la firma electrónica y la seguridad documental.

2. Problemas de gestión: La baja disponibilidad del líder del proyecto, junto con la inexperiencia del suplente, dificultó la coordinación efectiva del equipo y la resolución de problemas técnicos.

Como resultado, el proyecto se extendió a 11 meses, con un costo final de $350,000, lo que representó un incremento del 75% sobre el costo estimado y un retraso del 57% en el tiempo de entrega. Este retraso generó tensiones en la relación con el cliente, lo que implicó renegociaciones complejas y pérdida de confianza.

Conclusiones

Este caso demuestra la importancia de realizar estimaciones realistas, considerando la complejidad del dominio y las tecnologías involucradas. Además, subraya la necesidad de contar con un equipo que tenga experiencia en el área específica y con un liderazgo que pueda dedicar tiempo suficiente al proyecto para garantizar su éxito.

Las estimaciones empíricas, aunque útiles como punto de partida, no siempre capturan todos los factores que pueden impactar el proyecto. Por ello, es recomendable combinar estas estimaciones con técnicas más formales y robustas que permitan contemplar todos los posibles riesgos y desajustes.

• Reserva para contingencias: Se utiliza para cubrir riesgos conocidos que podrían materializarse, como demoras o problemas técnicos específicos.

• Reserva de gestión: Es para riesgos desconocidos o imprevistos que pueden surgir durante la ejecución del proyecto. Este análisis es fundamental para proyectos que presentan altos niveles de incertidumbre o donde se anticipan cambios potenciales en el alcance, tecnología o recursos.

• Costos directos: Son aquellos que se pueden rastrear directamente hasta una actividad específica del proyecto, como los salarios de los desarrolladores, licencias de software, equipos y materiales.

• Costos indirectos: Son aquellos que no están directamente asociados a una actividad particular del proyecto pero que son necesarios para su operación, como alquileres de oficina, servicios generales, costos administrativos y de gestión. Esta distinción es importante para asegurar que todos los gastos se tomen en cuenta y se reflejen en la estimación total del proyecto.

• Costos de prevención: Son aquellos asociados a evitar defectos antes de que ocurran, como capacitación, diseño robusto y pruebas durante el desarrollo.

• Costos de fallos: Se dividen en internos (corrección de errores antes de la entrega) y externos (costos asociados a corregir problemas que detecta el cliente después de la entrega, lo que incluye garantías y reclamaciones). Invertir en prevención es clave para reducir el costo de los fallos externos, que suelen ser los más costosos y los que más afectan la relación con el cliente.

• COCOMO Básico: Proporciona una estimación general basada en el tamaño del software.

• COCOMO Intermedio: Ajusta la estimación teniendo en cuenta factores adicionales como la experiencia del equipo y la complejidad del producto.

• COCOMO Detallado: Desglosa el proyecto en componentes más pequeños y calcula el esfuerzo para cada uno, lo que permite una mayor precisión en proyectos complejos. COCOMO se ajusta según la categoría del proyecto (orgánico, semidesarrollado o embebido) y es ampliamente utilizado para proyectos de gran envergadura.

• Compatibilidad de habilidades: Evalúa si el personal existente posee las habilidades técnicas necesarias para completar el proyecto, como conocimiento de lenguajes de programación específicos, herramientas de diseño o metodologías ágiles.

• Disponibilidad del personal: Determina si el equipo tiene suficiente tiempo disponible para dedicarse al proyecto sin comprometer sus responsabilidades actuales. Esto incluye revisar cargas de trabajo previas y otros proyectos en los que estén involucrados.

• Necesidad de capacitación: Si el análisis revela que el personal existente no tiene todas las habilidades necesarias, se puede considerar ofrecer formación o adquirir nuevas competencias, lo que puede ser más rentable que contratar nuevo personal.

• Redistribución de recursos: En lugar de contratar más personas, se puede redistribuir el personal dentro de la organización para cubrir las necesidades del proyecto. Esto puede implicar mover empleados de otras áreas menos críticas a roles más necesarios en el nuevo proyecto.

Este enfoque busca maximizar la eficiencia de los recursos internos y minimizar los costos asociados a la contratación o la subcontratación.

1. Selección de expertos: Se reúne a un grupo de personas con experiencia en proyectos similares y se les solicita que hagan una estimación independiente sobre el número de personal necesario para el proyecto en cuestión.

2. Primera ronda de estimaciones: Cada experto proporciona su estimación de manera anónima, lo que minimiza la influencia de opiniones dominantes y permite que cada miembro del grupo se base únicamente en su experiencia.

3. Análisis y retroalimentación: Se compilan las estimaciones y se devuelve un resumen estadístico al grupo, que incluye los valores medios, máximos y mínimos. Los expertos reciben este resumen, junto con justificaciones anónimas de otros expertos sobre sus estimaciones.

4. Segunda ronda: Basándose en los resultados de la primera ronda, los expertos pueden ajustar sus estimaciones si consideran que los argumentos presentados por sus colegas son válidos o relevantes. Este proceso se repite hasta que se llega a un consenso o las estimaciones comienzan a converger.

5. Decisión final: Se toma como resultado la estimación consensuada, que refleja una visión más equilibrada, basada en múltiples perspectivas expertas.

La técnica Delphi es especialmente útil para proyectos complejos o inciertos, donde no hay datos históricos precisos que permitan realizar estimaciones cuantitativas directas. Al involucrar a un panel de expertos, se incrementa la precisión de la estimación y se tiene en cuenta una gama más amplia de factores y riesgos potenciales.

Esta técnica es reconocida por su capacidad para reducir el sesgo en las estimaciones, mejorar la calidad de las decisiones, y proporcionar una estimación colaborativa que tiene un alto grado de confianza.

Jørgensen, M. (2004). Software Development Effort Estimation: A Study of Expert Judgments. Journal of Systems and Software, 73(2), 151-160. https://doi.org/10.1016/j.jss.2003.12.015

Karlsson, J., & Ryan, K. (1997). Requirements Engineering in Practice. IEEE Software, 14(6), 33-39. https://doi.org/10.1109/52.646183

Land, L. J., & G. D. (2015). Estimating the Cost of Software Development: A Survey of Practices. Software Quality Journal, 23(1), 37-57. https://doi.org/10.1007/s11219-014-9266-7

Sommerville, I. (2016). Software Engineering (10th ed.). Pearson. https://www.pearson.com/us/higher-education/program/Sommerville-Software-Engineering-10th-Edition/PGM32993.html

Valdes, F. (s. f.). Estimación de proyectos de software: Un problema, una solución. SG Buzz. https://sg.com.mx/revista/32/estimacion-proyectos-software

Team Asana. (2024, 28 enero). ¿Qué son los métodos de estimación? Conoce esta seis técnicas para una planificación de proyectos efectiva. Asana. https://asana.com/es/resources/estimation-methods

Santos, D. (2024, 20 febrero). Qué es y cómo hacer un análisis de riesgos (con ejemplos). HubSpot. https://blog.hubspot.es/marketing/analisis-de-riesgos

Team Asana. (2024b, febrero 3). Cómo realizar un análisis de riesgos y ejemplos. Asana. https://asana.com/es/resources/project-risks

Los métodos cuantitativos adjudican un valor numérico a cada riesgo. Existen varias técnicas para realizar un análisis cuantitativo de riesgos entre las que cabe destacar:

• El análisis de sensibilidad. Este tipo de técnica nos ayudará a identificar los riesgos que pueden afectar más al objetivo del proyecto.

• Análisis del valor monetario esperado o EMV (por sus siglas en inglés) calcula el resultado promedio teniendo en cuenta las oportunidades esperadas, que se expresarán en positivo, y los riesgos probables que se expresarán en negativo.

• Modelado y simulación. En una simulación se proyectan las incertidumbres para traducirlas en el impacto que podrían tener sobre el objetivo del proyecto. Generalmente, las simulaciones iterativas se realizan utilizando la técnica Montecarlo.

La matriz FODA consiste en elaborar un documento en el que desarrolles un análisis interno (fuerzas y debilidades), que quizá no harías en otras circunstancias; y realizar un contraste con las circunstancias externas (oportunidades, amenazas) para comprender mejor en qué áreas se necesita establecer un plan de prevención de riesgos.

Un brainstorming suele ser el primer paso para crear un registro de riesgos ya que se necesita un punto de partida para identificarlos. Aprender nuevas técnicas para lluvia de ideas puede ayudar a tu equipo a identificar los riesgos, mantener la agilidad y, posiblemente, evitar que los riesgos se materialicen.

Además, el líder del proyecto estaba asignado simultáneamente a otros dos proyectos, lo que limitaba su capacidad para supervisar este nuevo desarrollo de manera integral.

También se utilizó una técnica de estimación "bottom-up", donde se desglosaron todas las tareas en elementos individuales, lo que permitió calcular de manera detallada las horas de trabajo de cada especialista involucrado en el proyecto.