Escucha los defectos para limitar los riesgos eficazmente

«Si no atacas los riesgos activamente, ellos te atacarán activamente»
– Tom Gilb

Lo que suelo ver en las tablas de riesgos de los planes de proyecto o servicio es «retraso de la entrega», «sobrepasar el presupuesto», o «problemas en la aceptación del cliente debido a requisitos poco claros».

Al mismo tiempo, los equipos más a menudo se quejan de no poder cumplir los plazos, y superar los presupuestos.

Obviamente estamos más atacados que atacando los riesgos.

¿Por qué analizar los datos de defectos?

¿Qué podemos hacer para proteger mejor los proyectos y servicios de los riesgos?

Lógicamente, entender mejor las causas y las circunstancias de los problemas debería ayudar.

¿Has comprobado qué parte del tiempo total de entrega (lead time total) es desarrollo efectivo, re-trabajo debido a defectos, o bien espera de algo, p.ej. información o resultado de terceros? En otras palabras, ¿conoces la eficiencia de vuestro proceso?

Al estimar el tiempo de entrega, ¿incluiste el tiempo de re-trabajo y espera?

Mi experiencia muestra que pocas empresas analizan sistemáticamente sus defectos y asuntos bloqueantes con el fin de entender las causas para estos y actuar sobre ellas. Los asuntos bloqueantes paran el flujo de trabajo y por tanto son una especie de defectos en algún proceso que interviene en la realización del trabajo, por ejemplo, la gestión de proveedores, planificación, gestión de la información del cliente, etc.

Varias veces he visto la sorpresa en las caras de las personas cuando se dan cuenta de que la resolución de los bloqueadores y la corrección de defectos consume más de 30% del esfuerzo total estimado, prolonga la duración del proyecto con más de 20%, y afecta significativamente la satisfacción del cliente.

Si quieres que vuestro trabajo sea adecuado a su propósito (fit for purpose), tienes que escuchar a los datos de los defectos (incluyendo los asuntos bloqueantes) y actuar adecuadamente.

¿Cómo analizar los datos de defectos?

Analizar los datos de defectos no es tan difícil – hay varias técnicas que ayudan con esto. La principal razón para no obtener ventaja de esta valiosa fuente de información es que la mayoría de las empresas todavía no recogen datos sobre los defectos y/o no saben qué dicen estos datos.

Fishbone

Una práctica sencilla que puedes utilizar para aprender de vuestros datos es seguir estos pasos:

  1. Clasificar los defectos en base a criterios que surgen de contar la historia de cada defecto. Por ejemplo, empezamos a trabajar antes de conseguir el compromiso por parte del cliente acerca de la funcionalidad, las dependencias con otro sistema no se tomaron en cuenta, la persona involucrada era nueva y tenía escasos conocimientos del dominio, etc.
  2. Analizar las causas y buscar patrones. Aunque cada historia tiene sus aspectos individuales, los problemas comparten una gran parte de las raíces.
    Concentrarse en el lead time (tiempo de entrega) y la eficiencia de la resolución del defecto o bloqueador.
  3. Decidir cómo abordar las causas para evitar que se vuelvan a producir.

¿Qué tienen que ver los defectos con los riesgos?

La mayoría de los problemas son recurrentes al menos hasta que logremos impedirlos por completo. Esto significa que tenemos que estar preparados para ver nuestra experiencia de nuevo en el futuro. La pregunta es cómo podemos identificar el riesgo con suficiente antelación y evitarlo efectivamente.

Reflejando el pasado a través del punto “ahora” es una técnica sencilla y útil.

Cause-Problem Sp

El problema del pasado se convierte en un riesgo en el futuro. Las causas del pasado se transforman en síntomas de riesgo que tenemos que vigilar cuidadosamente.

¿Cuál es el lugar adecuado para comentar los riesgos?

Muchos equipos tratan de mitigar los riesgos de forma individual e independiente de los demás. Esto no es muy eficaz, especialmente cuando existen dependencias entre los servicios.

Supongo que celebréis reuniones periódicas en las cuales revisáis vuestros proyectos y servicios. Si utilizáis las rutinas Kanban (cadencias), el lugar ideal es la reunión Risk Review.

KanbanCadences

Imagen copiada con permiso del artículo Kanban cadences de David J Anderson.

Aseguraros de que tengáis una buena comprensión de todo el contexto para tomar decisiones pragmáticas sobre cómo mitigar los riesgos.

Resumen

  • A nivel de equipo no entender las causas de los defectos y los asuntos bloqueantes os hace vulnerables a los riesgos de los proyectos y servicios
  • A nivel de organización no abordar adecuadamente los riesgos reduce vuestra aptitud para el propósito del negocio
  • Aplicar un enfoque pragmático de analizar los defectos, comprendido y compartido por todos los involucrados limita los riesgos.

Artículos relacionados:

Share on facebook
Share on twitter
Share on linkedin

Comentarios cerrados.