Antes de marcharnos el fin de semana, hacemos una pausa en la cocina del equipo y charlamos con colegas. Así entendemos nuestra serie de artículos "5 preguntas a", en la que entrevistamos a gestores de proyectos con experiencia sobre sus mejores prácticas.
Hoy hablamos con Jan Fischbach. Es director general de la consultora de organización CommonSense, formador de eventos Scrum y coorganizador del freiräume.camp para una nueva cultura de trabajo.
1. Sr. Fischbach, ¿cuál es su método de gestión de proyectos preferido?
Nuestros clientes nos solicitan apoyo principalmente por dos razones: proyectos de organización (p. ej., implantación de software ERP o de un sistema de gestión documental) o introducción de estructuras de trabajo ágiles (Scrum, etc.), lo cual es también, por supuesto, un proyecto de organización. En ambos ámbitos utilizamos mayoritariamente Scrum.
La comunidad no considera Scrum un método de gestión de proyectos, sino un proceso de equipo y un medio para desarrollar buenos productos. Y de eso tratan nuestros proyectos: formar equipos que comiencen a entregar un producto y lo mejoren de forma continua. Gestión de proyectos significa para nosotros entregar resultados en condiciones de incertidumbre. Los proyectos no se aprueban, se financian. Antes de hablar de planificación de tareas y tiempos, el equipo necesita una comprensión sólida de qué resultados se deben entregar realmente. Para ello recurrimos a la planificación basada en productos de PRINCE2, la Gestión del Valor Ganado (ANSI 748), la Gestión de Beneficios (Ward/Daniel), la Gestión de Proyectos Basada en Rendimiento (Alleman), el User Story Mapping (Patton) o el Impact Mapping (Adzic).
Los directivos y equipos suelen subestimar el nivel real de incertidumbre. Por ello utilizamos el modelo de diamante de Shenhar/Dvir para explicar la incertidumbre en los proyectos. En proyectos importantes recomendamos emplear una simulación de Monte Carlo para evaluar la probabilidad de plazos y costes. Quien trabaja con estimaciones de tres puntos para sus paquetes de trabajo más importantes y examina 1.000 escenarios con números aleatorios se da cuenta con frecuencia de que los primeros planes eran bastante improbables.
Por cierto, Ken Schwaber y Jeff Sutherland publicaron en noviembre de 2017 la nueva versión de la Guía de Scrum.
2. ¿Utiliza software para proyectos de mayor envergadura y, de ser así, cuál?
No somos grandes aficionados al software. No es culpa del software en sí, sino de cómo se utiliza. Nuestro objetivo son equipos estables que trabajen juntos en un mismo lugar. Para eso suelen bastar una pared libre, notas adhesivas y rotafolios. Cuando los miembros del equipo están en varias ubicaciones, el apoyo electrónico resulta útil. Aun así, preferimos fotografiar los tableros y guardarlos en un repositorio compartido.
Nuestros clientes utilizan con frecuencia JIRA y Trello. Sin embargo, el volumen de datos en estas herramientas crece más rápido de lo que los equipos pueden gestionar. Se introducen datos con diligencia y el mantenimiento se vuelve cada vez más costoso porque se añaden más y más campos obligatorios. En algún momento nadie tiene ya una visión clara de lo que se ha entregado y qué trabajo queda pendiente. La carga de páginas y las búsquedas tardan más. Algunos miembros del equipo evitan el software para poder sacar el trabajo adelante. En estos casos conviene detener el uso y reflexionar: ¿qué queríamos conseguir realmente con este software? Naturalmente, muchos productos permiten también gestionar puntos abiertos y registrar horas. Pero ¿es eso de verdad para lo que debe servir el software?
3. ¿Cuál es su ritual favorito en un proyecto?
Me encanta el Story Mapping. En los proyectos de nuestros clientes encontramos siempre colaboradores muy competentes. Lo que a menudo falta es una visión compartida de las cosas. El Story Mapping resulta muy útil para eso. Dedicamos una o dos horas a entender mejor un proceso o la estructura del producto y a deducir las prioridades de trabajo. En las sesiones de refinamiento y planificación posteriores retomamos esos mapas.
4. ¿Cuál es, en su opinión, el factor más subestimado para el éxito de un proyecto?
a) Pensar en resultados: Si analizo diferentes estudios sobre gestión de proyectos (p. ej., el de PwC: Insights and Trends: Current Portfolio, Programme, and Project Management Practices, The third global survey on management), llego a la conclusión de que los proyectos no fracasan por falta de conocimientos de gestión de proyectos. Creo que con demasiada frecuencia nuestra propia concepción del trabajo en proyectos se interpone en el camino. La gestión de proyectos es más que elaborar y administrar listas de tareas y planes de costes. Significa entregar resultados en condiciones de incertidumbre. La pregunta más importante es siempre: ¿qué queremos entregar o cambiar? En los proyectos de ERP, el objetivo no es proporcionar los sistemas técnicos. Los usuarios necesitan funciones concretas; quieren imprimir albaranes o facturas. En los proyectos de gestión documental no se trata de archivar documentos, sino de cerrar procesos en equipo, y para eso necesitamos documentos. ¿Qué competencias queremos dominar o mejorar gracias al proyecto?
b) Los proyectos se financian, no se aprueban: Con demasiada frecuencia los proyectos se consideran generadores de costes. La comunidad ágil ha ajustado su perspectiva: desde ese enfoque no se ejecutan proyectos, sino que se prefinancian productos con los que se gana (o se ahorra) dinero. Desde la perspectiva ágil y, por cierto, también desde la de PRINCE2, la rentabilidad (valor de negocio, caso de negocio) ocupa el primer plano. Después de que nuestros clientes hayan estimado los costes del proyecto, suelo preguntarles qué formas de trabajo tendrían que cambiar concretamente para que la empresa gane el doble o el triple de lo invertido. Esas conversaciones son muy enriquecedoras. En un contexto verdaderamente ágil, un Product Owner no es un director de proyecto sino un empresario.
5. ¿Cuál es su mayor ladrón de tiempo?
Reuniones sin foco: Valoro Scrum porque transforma las ceremonias en eventos con propósito. Cada evento de Scrum tiene un enfoque claro: o planificamos algo o revisamos resultados. No se trata de lo que una persona ya ha hecho, sino de evaluar únicamente los resultados. Eso libera energía. En los proyectos deficientes hay reuniones de estado en las que se repasan listas interminables. Personas adultas vuelven a comportarse como escolares que le explican al maestro por qué no han hecho los deberes. Es desolador. En lugar de eliminar las causas de una planificación poco realista, se presiona a las personas. Este sistema no funciona.
Sobrecarga de trabajo: En todos nuestros clientes, la lista de tareas en curso es demasiado larga. Abarcan demasiado a la vez. El cambio constante entre distintos frentes consume mucho tiempo. Con cinco proyectos simultáneos, un colaborador dedica tres cuartas partes de su tiempo a cambiar de proyecto: asiste a reuniones de estado, escribe y lee actas, realiza traspasos. Todo eso es trabajo que no añade valor al resultado pero consume una energía enorme.
Muchas gracias por su tiempo y mucho éxito en su próximo proyecto.
Si tiene alguna pregunta sobre este artículo del blog o desea debatirlo, esperamos su contribución en nuestro foro.
