Trece años auditando proyectos de software dan una conclusión clara: los proyectos no fracasan por mala suerte, fracasan por trece errores que se
repiten. Cuatro son de planteamiento (alcance abierto, equipo equivocado, plazo imposible, presupuesto basado en fe). Cuatro son de ejecución
(sin tests, sin documentación, deuda técnica desde el día uno, decisiones por consenso). Cinco son de gobernanza (sin propietario claro, comités
sin decisión, métricas vagas, sin criterios de aceptación, cambio constante sin priorización). Detectarlos en las primeras dos semanas evita el 90%
del coste.
ULa literatura sobre gestión de proyectos de software está saturada de buenas prácticas. Lo que falta es honestidad sobre los errores. Tras trece años auditando proyectos atascados o fracasados, hemos identificado trece errores que se repiten en casi todos los casos. Conocerlos por nombre permite detectarlos en las primeras dos semanas, cuando todavía se pueden corregir con coste razonable. Detectarlos en el mes seis cuesta entre 5 y 20 veces más.
Los agrupamos en tres categorías: errores de planteamiento, errores de ejecución y errores de gobernanza.
Error 1 · Alcance abierto firmado como cerrado. El contrato dice “implementación del CRM” pero no especifica qué módulos, qué integraciones, qué nivel de personalización. Cada parte cree haber firmado un al‐ The Cloud Group · Documento Maestro 3 cance distinto. La discusión sobre qué entra y qué no entra empieza en el mes tres y no termina nunca. Solución: firmar alcance por módulos con entregables explícitos.
Error 2 · Equipo equivocado para el tipo de proyecto. Contratar Big
Four para un MVP rápido es ineficiente. Contratar un freelance para un
sistema crítico regulado es temerario. Contratar boutique senior para una
tarea pequeña es caro. La elección de proveedor define el resultado más
que cualquier metodología.
Error 3 · Plazo imposible firmado por presión comercial. El cliente necesita
“para junio” porque tiene un anuncio comprometido. El proveedor
firma sabiendo que es imposible porque necesita el contrato. El proyecto
sale en septiembre, el anuncio se cae, todos se culpan mutuamente.
Solución: estimar honestamente y rechazar lo imposible.
Error 4 · Presupuesto basado en fe. Estimaciones de “más o menos
esto” sin desglose de hitos, sin contingencia y sin criterios de cambio.
Cuando el proyecto se desvía un 30% en el mes dos, no hay manera de
saber si es razonable o catastrófico. Solución: estimación detallada por
módulo con buffer firmado.
Error 9 · Sin propietario claro del proyecto en el cliente. Proyectos
donde “el proyecto es de tecnología pero también de operaciones, también
de marketing y también de comercial”. Cuando todo el mundo es propietario,
nadie lo es. Las decisiones se posponen, los entregables se
quedan sin validar y el proyecto se ralentiza. Solución: un único
responsable con autoridad real desde el día uno.
Error 10 · Comités sin capacidad de decisión. Reuniones quincenales
con quince personas donde nadie tiene poder para tomar decisiones que
importen. Sirven para informar, no para decidir. Solución: reuniones de
decisión separadas de reuniones de información, con poder firmado.
Error 11 · Métricas vagas o ausentes. “Que funcione bien y los usuarios estén contentos” no es una métrica. Sin métricas objetivas, la decisión de
“está terminado” depende del estado de ánimo de quien la tome. Solución: métricas declaradas antes del primer commit, medidas semanalmente.
Error 12 · Sin criterios de aceptación firmados. El proyecto entra en testing sin que se haya acordado qué significa “aceptado”. Empiezan las
discusiones interminables sobre si el bug X es bloqueante o no. Solución: criterios de aceptación firmados al inicio del módulo, antes de empezarlo.
Error 13 · Cambio constante sin priorización. Cada semana el cliente añade requisitos nuevos sin sacar otros del backlog. El proyecto crece sin
que crezcan ni el plazo ni el presupuesto. Termina explotando. Solución: política firmada de cambios donde añadir es posible pero exige sacar algo
o ampliar plazo y presupuesto.
Las primeras dos semanas de un proyecto son las más importantes. Si en ese periodo se detectan tres o más de los trece errores, el proyecto está
en riesgo y hay que parar antes de avanzar. Cinco preguntas que se pueden hacer en una reunión de 60 minutos:
Si la respuesta a tres o más es “no” o “no del todo”, hay que parar y
resolver antes de avanzar.
No, pero el coste se reduce mucho cuando se identifican pronto. Un proyecto perfecto no existe. Un proyecto bien gestionado es uno que detecta los errores en semanas, no en meses.
En nuestra experiencia, el error 1 (alcance abierto) y el error 9 (sin propietario claro) son los más caros porque amplifican todos los demás.
No por sí solas. Una mala implementación ágil puede convertirse en “scrum sin disciplina” y reproducir todos los errores con otro nombre. La disciplina importa más que la metodología.
Hay herramientas (SonarQube, CodeClimate) que dan métricas objetivas. Lo importante es medirla desde el día uno, no descubrirla en el mes seis.
Cuando el coste estimado de terminarlo supera el valor esperado de lo que se va a entregar. Es una decisión incómoda pero a veces necesaria. Lo hemos recomendado a clientes a quienes nos contrataron para auditar.
Sí, esa es exactamente la función. Una auditoría de 10 días con TCG cubre los trece errores y entrega un informe corto con los más críticos para el proyecto concreto.
Diagnóstico honesto: qué se salva, qué se reescribe, qué hay que parar. A veces salir adelante con esfuerzo extra es más caro que rehacer parte. La
decisión depende del caso concreto y debería tomarse con criterio externo.
Los proyectos de software no fracasan por la tecnología elegida ni por mala suerte. Fracasan por una combinación predecible de errores de
planteamiento, ejecución y gobernanza. Conocer los trece errores por nombre permite detectarlos a tiempo y corregirlos cuando todavía se
puede. Si tu proyecto reconoce tres o más, conviene una auditoría externa antes de invertir más recursos.
Automated page speed optimizations for fast site performance