Gestión de Calidad y Riesgos · Serie 8 · Semana 1 · Tema 1
La gestión de la calidad nació en la fábrica. Sus herramientas, su vocabulario y sus ejemplos vienen de ahí: lotes, muestras, límites de control, defectos por millón.
Todo eso funciona porque en una fábrica se repite la misma operación miles de veces. Puedes medir, ajustar, volver a medir. El proceso aprende.
Un proyecto es lo contrario por definición: un esfuerzo temporal para crear algo único. Se hace una vez. No hay lote del que tomar muestra, no hay repetición de la que aprender, y cuando terminas de entender bien el trabajo, el trabajo se acabó.
Esa diferencia cambia mucho más de lo que parece, y explica por qué aplicar el manual de calidad de operaciones a un proyecto produce papeles y no resultados.
Cuatro diferencias que sí importan
1. No hay curva de aprendizaje que aprovechar
En producción, el defecto número uno te enseña a evitar los mil siguientes. En un proyecto, muchas veces solo existe el defecto número uno, y su costo lo pagas entero.
La consecuencia práctica: en proyectos hay que invertir más en prevención y menos en inspección, porque la inspección solo rinde si vas a producir lo mismo otra vez. Revisar un diseño antes de construir vale más que revisar cien unidades después.
2. Los requisitos cambian mientras construyes
En operaciones, la especificación es estable: la pieza mide lo que mide. En un proyecto, lo que el cliente pidió en enero puede no ser lo que necesita en junio, y a veces con razón.
Esto rompe una premisa de la calidad clásica, que define calidad como conformidad con los requisitos. Si los requisitos se mueven, la conformidad deja de ser suficiente: puedes cumplir al cien por cien una especificación que ya no sirve.
Por eso en proyectos la calidad tiene que incluir un mecanismo de revalidación: comprobar cada cierto tiempo que el requisito sigue siendo el correcto, no solo que se está cumpliendo.
3. El equipo es temporal
Una planta acumula décadas de conocimiento en las mismas personas. Un proyecto junta gente que no había trabajado junta, la mantiene unida un año y la dispersa.
De ahí que en proyectos el conocimiento tenga que quedar escrito o se pierde entero. Los criterios de aceptación, las decisiones de diseño y las razones de cada una no son burocracia: son lo único que sobrevive a la disolución del equipo.
4. La medición llega tarde
En producción mides el producto terminado y todavía estás a tiempo, porque mañana produces otro. En un proyecto, cuando el entregable está terminado, el presupuesto está gastado.
Por eso el control de calidad en proyectos tiene que ser incremental: medir entregables parciales, no el resultado final. Un proyecto que reserva toda la verificación para el final no tiene gestión de calidad, tiene una apuesta.
Qué sí se traslada bien
No todo cambia. Tres cosas de la calidad clásica funcionan igual de bien en proyectos:
La escalera de costos. Prevenir es más barato que corregir, y corregir antes de entregar es más barato que corregir después. Lo vimos en los cinco niveles del costo de la calidad y la aritmética no cambia por ser un proyecto.
La responsabilidad de la dirección. Los recursos y las capacidades los proporciona quien dirige. Un equipo no puede compensar con voluntad una capacidad que la organización decidió no financiar.
El ciclo de mejora. Planificar, hacer, verificar, actuar sigue aplicando, pero en un plazo distinto: dentro del proyecto, entre iteraciones, no entre lotes.
Las tres preguntas que ordenan la calidad de un proyecto
¿Cuál es el entregable que más caro sale si va mal?
La atención de calidad no se reparte por igual. Hay entregables cuyo fallo se corrige en un día y otros sobre los que se construye todo lo demás.
La regla: invierte verificación en proporción a cuántas cosas dependen de ese entregable, no a su tamaño. Un documento de requisitos de diez páginas puede merecer más revisión que un módulo de diez mil líneas.
¿Cuándo sabremos que va mal?
Para cada entregable importante: en qué momento existirá la primera evidencia de si está bien o mal. Si la respuesta está cerca del final del proyecto, hay que inventar una evidencia temprana: un prototipo, una maqueta, una prueba de concepto, una revisión con el usuario real.
Esta es la pregunta que más proyectos salva, y la que menos se hace en la planificación.
¿Quién dice que algo está bien?
Con nombre, y con autoridad para decir que no. En operaciones lo dice una máquina de medición; en un proyecto lo dice una persona, y si esa persona depende de quien tiene prisa por entregar, el criterio se va a doblar.
Caso práctico: la calidad medida el último mes
Escenario construido con patrones habituales; las cifras son ilustrativas.
Un proyecto de catorce meses planifica una fase de pruebas de seis semanas al final. Es el plan habitual y parece razonable: pruebas cuando haya algo que probar.
En el mes trece empiezan las pruebas y aparece un problema de fondo: dos módulos hacen suposiciones incompatibles sobre cómo se identifica a un cliente. Uno usa el número de contrato; el otro, el documento de identidad. Un mismo cliente con dos contratos aparece duplicado en la mitad del sistema.
La decisión de diseño que lo causó se tomó en el mes tres, y no fue un error: cada equipo eligió lo razonable para su parte. Nadie comparó las dos decisiones porque no había ningún momento previsto para compararlas.
Corregirlo en el mes trece costó once semanas. Detectarlo en el mes tres habría costado una conversación de media hora.
Lo que faltó no fue rigor en las pruebas —las pruebas lo encontraron— sino una verificación temprana de las decisiones de diseño, que en un proyecto es donde se decide la calidad del resultado.
Errores frecuentes
Copiar el sistema de calidad de operaciones. Produce indicadores que nadie puede accionar, porque miden repetición donde no la hay.
Concentrar la verificación al final. Es el error más caro y el más común, porque el cronograma lo sugiere de forma natural.
Confundir calidad con exhaustividad documental. Un proyecto puede tener toda la documentación en regla y entregar algo que no sirve.
Dejar la aceptación en manos de quien tiene la prisa. Si la misma persona responde de la fecha y de la calidad, ya sabes cuál va a ceder.
No revalidar los requisitos. Cumplir una especificación obsoleta se ve en los informes como éxito.
Checklist
- ¿Sabes cuál de tus entregables es el que más cosas sostiene?
- Para cada entregable importante, ¿cuándo aparecerá la primera evidencia de si está bien?
- ¿Hay alguna verificación programada en el primer tercio del proyecto?
- ¿Quién puede rechazar un entregable, y de quién depende jerárquicamente?
- ¿Los criterios de aceptación están escritos antes de construir?
- ¿Hay un momento previsto para comprobar que los requisitos siguen siendo los correctos?
- Si el equipo se disolviera mañana, ¿qué parte del conocimiento se iría con él?
Para cerrar
La calidad en proyectos no es la calidad en operaciones con otro nombre. Es una disciplina con una restricción propia: solo tienes un intento, y la información sobre si lo estás haciendo bien llega tarde salvo que la fuerces a llegar antes.
Casi todo lo que se puede hacer al respecto consiste en adelantar esa información.
Te leo en los comentarios: ¿cuándo apareció la primera señal fiable de si el resultado iba a servir?
Referencias
- Project Management Institute, Guía del PMBOK, 7.ª edición, dominio de desempeño de entrega.
- ISO 10006, directrices para la gestión de la calidad en proyectos.
- Juran, J. M., Juran's Quality Handbook, sobre prevención frente a inspección.
- Boehm, B., sobre el costo relativo de corregir un defecto según la fase en que se detecta.
← Anterior en la serie: El plan de gestión de calidad: cómo se escribe uno que alguien use
Siguiente en la serie: Paneles de clientes: para descubrir qué preguntas había que hacer →
Este artículo forma parte de Gestión de Calidad y Riesgos, una serie de 108 artículos. Ver todos los de esta serie · Índice completo por materia.