Blog

En la reunión de arranque alguien dijo que el ambiente de pruebas iba a estar listo en octubre. Nadie lo puso por escrito porque no era una decisión, era un comentario. Todo el cronograma se construyó encima de ese comentario. Y en octubre resulta que el ambiente no estaba, porque quien lo dijo tampoco estaba seguro, solo estaba pensando en voz alta.😩

Eso es un supuesto, algo que el plan da por cierto sin tener evidencia de que lo sea. Y el problema no es que existan, porque todo proyecto se planifica sobre docenas de supuestos y es imposible evitarlo. El problema es que la mayoría vive en la cabeza de la gente y no en ningún documento. El PMI ha descrito el tema de los supuestos en la Gobernanza y la 8va edición del PMBOK lo trata con bastante seriedad, porque un supuesto no escrito es exactamente lo que dice la infografía de hoy: un riesgo invisible. Está ahí, puede tumbarte el proyecto, y no aparece en ningún registro, así que nadie lo monitorea y nadie es responsable de él.

Tres recomendaciones para que gestiones los supuestos de la manera más efectiva:
1.- El supuesto se reconoce por el "asumiendo que". Ese es el truco para cazarlos. Cada vez que alguien en una reunión de planificación diga "contando con que", "asumiendo que", "si todo sale como siempre" o "normalmente eso tarda", ahí acaba de pasar un supuesto volando. Los más comunes en nuestra realidad: que el recurso clave va a seguir en la empresa, que el proveedor entrega en el plazo que prometió verbalmente, que la aprobación de la casa matriz llega en dos semanas, que no va a haber cambio regulatorio, que la data del sistema viejo está actualizada y con calidad. Ese último ha matado más proyectos en banca que cualquier otra cosa.💔
2.- La restricción es distinta y también hay que escribirla. Se confunden seguido, así que vale separarlas. El supuesto es algo que uno cree que va a pasar; la restricción es un límite que uno no puede mover. La fecha del cierre fiscal, el presupuesto aprobado, la norma del regulador, la tecnología que la organización ya decidió usar. La diferencia práctica es lo que uno hace con cada una: el supuesto se valida, la restricción se acepta y se diseña alrededor de ella. Tratar una restricción como si fuera negociable desgasta al equipo. Tratar un supuesto como si fuera un hecho lo deja sin salida.
3.- Y un supuesto escrito se puede convertir en riesgo. Aquí está la parte que cierra el círculo. Cuando el supuesto queda registrado, uno le puede poner dos cosas: quién lo valida y para cuándo. "Asumimos que el ambiente de pruebas estará disponible el 15 de octubre. Responsable de confirmar: Marcos Rojas. Fecha límite de confirmación: 30 de septiembre." Si el 30 no hay confirmación, el supuesto se convierte formalmente en un riesgo con su plan de respuesta. Eso es gestión, y lo otro es esperanza.

Un detalle práctico que casi nadie hace y que rinde muchísimo: los supuestos también hay que revisarlos cuando el contexto cambia. Cambió el patrocinador, se reorganizó un área, la Super Intendencia de Bancos emitió una circular nueva. En ese momento vale la pena releer la lista completa, porque hay supuestos que eran perfectamente válidos en marzo y dejaron de serlo en septiembre sin que nadie lo notara.

Reto de hoy: Escribe cinco supuestos de tu proyecto. Cinco cosas que estás dando por ciertas y que, si resultan falsas, te cambian el plan. Ponle a cada uno un responsable de validarlo y una fecha límite. Mándalos por correo a tu equipo pidiendo que te agreguen los que faltan. Te van a llegar dos o tres que ni sabías que existían, y esos son los importantes.

Un proyecto no se cae por lo que no sabías. Se cae por lo que creíste saber y nunca verificaste. 🥺

¡Hasta que sea asombroso! 🚀❤️
PMI Capítulo Panamá. Vicepresidencia de Educación y Desarrollo Profesional
www.pmi-panama.org