En el post anterior hice una síntesis sobre los cambios que (creo) deparará la nueva, 5ª versión, del PMBOK y uno de ellos, de los menos significativos, era la inclusión de las salidas del proceso de «Recoger los Requisitos» como entradas del Proceso de Planificar la Calidad.

Uno de los comentarios que recibí en uno de los grupos de linkedin era que «ya era hora de que alguien diga que la gestión de la calidad en PMBOK no es sino una mala trasposición de los conceptos de calidad en fabricación y operaciones». Si bien mi intención no era ser tan radical, sí que pienso que es una de las áreas más flojas de la guía del PMBOk y no parece que vaya a modificarse en la ansiada 5ª versión.

En una reciente clase en la Universidad Pública de Navarra comencé con una transparencia que decía «La calidad empieza en el minuto uno (de partido)». Pero quizás empiece antes, en el vestuario con la pizarra del entrenador, o incluso antes en los entrenamientos…

Dejando el simil futbolístico, sí que estoy firmemente convencido que la calidad empieza… …en el acta de constitución.

En este fundamental y con tanta frecuencia minusvalorado documento se incluye la descripción del producto o servicio resultante y se definen los requerimientos de alto nivel.

Y la calidad continúa en el minuto dos con la identificación de partes interesadas de las que, no olvidando su relevancia en el proyecto medida por su interés-impacto en el proyecto, trataremos de conocer sus necesidades, sus expectativas,… …sus requerimientos respecto al servicio o producto.

Les comentaba  a los alumnos (de ingeniería informática) que en este paso nos jugamos una buena parte del partido. Les subrayaba la necesidad de ser exahustivos en la búsqueda de potenciales partes interesadas hasta debajo de las piedras (ya habría tiempo de clasificarlas y quedarnos con las más relevantes).

Porque, si nos dejamos una parte interesada importante, nos dejamos sus necesidades y expectativas, nos dejamos sus requerimientos respecto al producto,… y no habrá plan de calidad que aborde el cumplimiento de unos requerimientos que nos se han recogido…

Una vez bien identificadas las partes interesadas, comienza la labor de plasmar en negro sobre blanco sus necesidades y expectativas, traducirlas a requerimientos y expresarlas en especificaciones medibles. Medibles.

Les recalqué que la calidad que no se puede medir será un problema durante y al final del proyecto porque ambas partes, equipo de proyecto y cliente, deben tener claro que significa «hecho de acuerdo a lo establecido«.Y les recalqué que «cómodo», «rápido», «azul»,… no son medibles y que como dice el proverbio inglés «the devil is in the details» y que el tiempo invertido en acordar estos aspectos es tiempo ganado después… …y que, por esto precisamente, es tan importante este paso de requerimientos a especificaciones (definiciones operativas,… o como queramos llamarlas).

E Ishikawa, sin aparecer…