y la calidad no acaba con el pitido final¡

En el post titulado Qué cambios nos deparará la 5ª edición del PMBOK: una síntesis avancé que es una pena que, entre los cambios previstos para la 5ª Edición del PMBOK, no haya cambios significativos en la, para mí, más pobre de las áreas de conocimiento.

En el último post titulado La calidad empieza en el vestuario o ¿Qué tiene que ver Ishikawa con todo esto…? (1ª Parte) hablé del comentario de un lector para el que “ya era hora de que se dijera que el área de gestión de la calidad del PMBOK es muy floja”.  Así que… … me animé a hacer un esquema de lo que, creo, debiera ser el enfoque.

En La calidad empieza en el vestuario o ¿Qué tiene que ver Ishikawa con todo esto…? (1ª Parte) nos quedamos en las especificaciones, resultado de la traducción a criterios medibles de los requerimientos de las partes interesadas. Así que el siguiente paso, tras identificar lo que debe cumplir el producto y el proyecto, es definir el alcance del proyecto.

En el enunciado del alcance, junto con la descripción del alcance del producto -requisitos (condiciones o capacidades que debe poseer o satisfacer el servicio o producto- deberán recogerse los criterios de aceptación -especificaciones de rendimiento, funcionalidad,…que deben cumplirse antes de que se acepte el producto-.

Y, en el siguiente paso, la EDT -el documento más importante de un proyecto en mi modesta opinión- deberemos dar un paso más en la planificación y gestión de la calidad. Será en la EDT, más bien en el diccionario de la EDT, en la ficha de cada paquete de trabajo, donde recojamos, entre otras cosas,

- la descripción del trabajo a realizar,

- la asignación de responsabilidades para ese trabajo y

- LOS CRITERIOS DE APROBACIÓN -QUIÉN Y CÓMO SE DARÁ POR VÁLIDO Y ACEPTADO EL PAQUETE DE TRABAJO.

Esto es, se recogerá para cada paquete de trabajo: la parte interesada que lo acepta, los requerimientos que deben cumplirse y la forma en que se aceptará.

De esta manera habremos dado un paso más en el proceso clave de planificar -para bien poder gestionar- la calidad:

Con los requerimientos de cada parte interesada bien claros y definidos en especificaciones medibles, con el enunciado del alcance en el que se recogen perfectamente los criterios de aceptación del servicio o producto y con  un diccionario de la EDT en el que para cada paquete de trabaja hay unos criterios de aceptación claros, el siguiente paso, elaborar el plan de calidad será más algo más fácil…

Para cada paquete de trabajo tendremos identificado su requerimiento y su especificación y podremos proceder a definir

- cómo vamos a asegurarnos de que el procedimiento de trabajo, la forma de trabajar es la adecuada para lograr cumplirlo y qué controles vamos a hacer a los procesos

- cómo vamos a controlar que el servicio o producto final cumple los requerimientos previstos (y que, dado el caso, no es el cliente el que descubre que no es así…)

Pero la calidad no acaba aquí… …si no que continua o vuelve a empezar en un ciclo continuo de mejora continua… … para que en el próximo proyecto…

… no nos dejemos

… ninguna parte interesada relevante

… ningún requerimiento de alguna parte interesada relevante

… ninguna especificación bien definida de ningún requerimiento de alguna parte interesante relevante

…porque si lo hemos hecho…

… no estará en el enunciado del alcance, ni en el diccionario de la EDT…

…y no habrá plan de calidad, ni aseguramiento ni control de calidad que lo resuelva…

Y seguimos sin hablar de Ishikawa, Juran, Deming,… … y esas preguntas que gusta de poner el PMI en sus exámenes y que no tienen nada que ver con la planificación y gestión de la calidad…

dnl

Ah¡ No dejéis de leer el nuevo post en el blog del Grupo de Análisis de la ISO21500¡

La gestión de la calidad empieza en el minuto uno… (1ª parte)

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…

Los factores de éxito en un proyecto de software

En un curso reciente de introducción a Scrum en Pamplona, pregunté a los asistentes cuáles eran los factores de éxito de un proyecto (de software).

Para ello utilicé, por una parte, la técnica de !Presto! (sacada del entretenido Agile Retrospectives) para generar respuestas y romper el hielo y, por otra, una matriz complejidad impacto que proyecté sobre la pared y sobre la que fuimos colocando las respuestas anotadas sobre post-its.

La dinámica !Presto¡ consiste en que cada participante escribe en una hoja uno o dos criterios o factores de éxito de un proyecto -para lo cual tienen 1 minuto-.

Pasado el minuto, el facilitador dice !Presto! -palabras que los magos italianos dicen al sacar el conejo de la chistera- y cada participante pasa su hoja a su compañero de la izquierda.

A continuación de la lista del compañero y sin repetir lo ya escrito, cada participante escribe otros dos criterios o factores de éxito.

El juego se repite hasta que se agoten las ideas o se haya dado la vuelta completa al grupo.

Al acabar fuimos pasando a post-its los resultados y los fuimos pegando en la matriz en función de si el criterio o factor de éxito era complejo de llevar a cabo o no y si tendría un impacto algo o bajo en el potencial éxito del proyecto.

El resultado lo tenéis en la figura siguiente:

En un primer vistazo aparecía factores de éxito que eran fáciles de lograr y ncon un impacto alto (lo que nuestros amigos anglosajones llaman la “low hanging fruit”): obtención de feedback frecuente del cliente y seguimiento del proyecto.

Por otra parte, teníamos fruta deliciosa pero muy alta… Si nos fijamos en el angulo superior derecho, tendríamos la fruta rica pero complicada (o no…) de lograr: visión clara, estrategia de producto definida, equipo adecuado,…

Y más arriba, ya fuera del árbol… …en la azotea… los requisitos completos al inicio… una quimera…

Unas conclusiones rápidas, quizás apresuradas…: el tiempo y el coste no parecen estar entre las factores de éxito. Otros como el seguimiento y feedback temprano, la colaboración con el cliente, la visión y estrategia del proyecto claras, sí.

Pero no nos olvidemos, hablamos de proyectos de software…

¿Y tu qué opinas?

El Costa Concordia, el Titanis y la (In)Gestión de Riesgos

“Ni Dios será capaz de hundirlo”. E.J Smith. Capitán del Titanic

Hace un año escribí un post sobre el Titanic y la Gestión de Riesgos. Hoy, impactado por la noticia del hundimiento del Costa Concordia, lo recupero. Impactado por dos razones: por la magnitud del acidente y porque entre esta foto

y ésta:

solamente cambia el año (aunque la foto dice 2007, fue el 2010) y los personajes… …porque es la misma compañía, el mismo barco, el mismo recorrido… …y si es el mismo capitán, ya no me acuerdo…

Como es pronto para saber qué es lo que pasó, aunque todas las pistas apuntan al capitán, os refresco el análisis del caso Titanic:

(post de la serie “Pon un PMP en tu vida y…

… te contará la historia del Titanic que, aunque no pudo conseguir terminar su primera travesía, sí logró pasar a la historia como el barco más famoso jamás construido. Lo cierto es que miles de libros y artículos se han escrito sobre él.

Como ocurre en la viña del Señor (al que mencionaba el osado capitán), dentro del mundo de los project managers hay gente para todo. Y entre ellos uno llamado J Bruce Weeks que, para explicar la identificación de riesgos en entornos de alta interacción (PMI Virtual Library, 2010), escribe un artículo de project Management sobre el Titanic.

Así que el tan famoso como malhadado barco tiene también su hueco en la estantería de tu “renacentista” PMP.

Como lo lee el artículo desde la curiosidad histórica más que desde la técnica en gestión de proyectos, te contará nada más las razones por las que, como decía nuestra canción infantil, “había una vez un barquito… …y aquel barquito naufragó… y si esta historia te parece poca volveremos, volveremos a empezar”.

Que porqué naufragó? Pues porque prácticamente todos los riesgos conocidos (known unknowns) que se pudieran imaginar sucedieron (y no había plan de respuesta) y un par de unknown unknowns que, con perdón, ni Dios se esperaba.

Primero había una serie de KNOWN UNKNOWNS –como decíamos en el último post “dedicado” a Ronald Rumsfeld- que son riesgos identificables y sobre los que sí se puede tener un plan de respuesta previsto si el riesgo lo merece:

• calidad y requerimientos:

el diseño de las mamparas de cristal no era adecuadamente estanco y además estaban sólo unos metros por encima de la línea de flotación. Al fallar seis de los dieciséis compartimentos estancos, comenzó a entrar agua…

• requerimientos funcionales mal definidos:

El timón era demasiado pequeño para las necesidades de navegación y maniobras en alta mar. Las pruebas se habían hecho en puerto lo que llevó a un diseño con un tamaño un 40% del necesario…

• Y si…. sé negativo al identificar riesgos:

el barco tenía tres turbinas de hélice de las cuales solamente las dos exteriores eran reversibles. La más potente, la central, no. Cuando el barco necesitó virar, frenar, reducir velocidad,… para minimizar el golpe, solamente pudo utilizar las dos pequeñas exteriores… insuficientes.

• La comunicación…

Los informes actualizados de dos barcos que navegaban por la zona no le llegaron al Capitán Smith que trabajó con los datos de días anteriores de acuerdo a los cuales hizo un pequeño ajuste…

• Hacer caso a todas las partes interesadas?:

El dueño del marco quería asombrar al mundo y pidió al capitán que el barco fuera a la máxima velocidad –demasiado alta para el slalom que tuvo que hacer entre hielos-. Efectivamente el armador asombró al mundo…

• Nos olvidamos de las prioridades (o es un problema de comunicación):

Puesto que el cuadro de comunicaciones había estado estropeado, a los “telefonistas” se les acumuló el trabajo de envió de mensajes de los tripulantes a sus familias. El aviso de otro barco de la presencia de un gran iceberg se quedó en la lista de espera…

• Recursos insuficientes…: dos de los tres equipos de vigilancia en cubierta no tenía prismáticos lo que, unido a que el mar estaba en calma y no rompía contra el iceberg, hizo difícil para los pobres vigilantes ver nada especial…

Y después –como dice el dicho español “éramos pocos y parió la abuela-: los UNKNOWN UNKNOWNS, riesgos difícilmente identificables para los que no hay plan de respuesta posible…

• Los aceros actuales tienen un menor contenido de azufre pero el utilizado para construir el Titanic era alto y lo hacía frágil –se rompía directamente sin deformarse-

• Estas roturas, hicieron saltar las ventanillas circulares y que el agua entrara con más rapidez..

En fin, que no era su día (o más bien lo fue pues cumplió con el objetivo del sponsor de “asombrar al mundo”

Cuando se aclaren las causas del naufragio del Costa Dorada, haremos un análisis más calmado. ¿Os parece?

dnl

que este año nos traiga tantos proyectos como… … recortes

Este año, como todos los años, suelo hacer una reflexión y una pequeña promesa –que no siempre acabo cumpliendo (el año pasado dejé el gimnasio la primera semana de febrero, el anterior dejé la dieta la cuarta semana de enero…)-. Pero bueno…

Este año que nos recibe con recortes y más recortes, me he propuesto estar atento a las oportunidades que puedan surgir para que no me pillen pensando en Babia… Me he propuesto tener un año más pleno que el 2011 –lo que, me temo, implica complicarme un poco más la vida…-. En el fondo, voy a tratar de poner en marcha mi ADN de Project manager, sufrido y aguerrido, inasequible al desaliento (oigo sonar de fondo la banda sonora de Rocky…)…

Una vida más plena… ¿qué significará esto?  Por ejemplo: tener suficientes éxitos significativos para mí (no tienen porqué ser profesionales, ni mucho menos; de hecho, mejor repartir…). Desafortunadamente,  nada me garantiza ese ansiado éxito -es casi seguro que me caeré de bruces unas cuantas veces este  2012 con aire de yincana-.

Así que más me vale aprender a caer, levantarme y volver a andar.

Leí una vez que E.I. Goldratt veía cada nueva iniciativa como un prototipo, que es muy probable que tenga errores, pero que es fundamental para aprender de él y ver qué no hacer y sí hacer la próxima vez.

Por eso, convendrá que practique un poco esto de la prueba y el error.

Como me he propuesto tener (algún) éxito, hay algo que tengo claro: necesito tener un montón de oportunidades. Como no podré aprovechar todas (ni mucho menos), más me vale tratar de encontrar, generar, reconocer unas cuantas (ya sabemos que cuantos más números cojas, más posibilidades tienes de que te toque…).

Yo siempre había pensado que las oportunidades que surgen no tienen que ver con las personas: que hay personas afortunadas que se topan con un montón de oportunidades y otras, la mayoría, que las contamos con los dedos (en ocasiones gordos) de las manos…

Pero mi admirado E.I. Goldratt sostiene que la vida ofrece a todo el mundo una secuencia continua de situaciones que pueden convertirlas en oportunidades, que el problema no es el mayor o menor número de oportunidades sino la capacidad para reconocerlas y aprovecharlas (incluso inventárselas…).

Pero para ello, tenemos que estar preparados. Cuanto más mejor. Preparados en el sentido en que cuando se presente una oportunidad, tengamos más probabilidad de reconocerlas  y actuemos en consecuencia.

Esto es lo que quiere decir Goldratt cuando cita la frase “la suerte es lo que sucede cuando la oportunidad se encuentra con la preparación”. Pablo Picasso decía que a él la inspiración siempre le pillaba trabajando. Va ser que el gurú israelí y el pintor malagueño estaban de acuerdo.

¿Y tu? Pues si estás de acuerdo, a prepararse y a estar atento a la primera oportunidad¡

Vamos a buscar nuestras oportunidades y nuestros proyectos (que los recortes nos lo traen otros)!!