Quitarse “la gorra del técnico”, ponerse “la gorra del gestor”

En los proyectos de hoy en día, las causas de fracaso rara vez hay que buscarlas en las razones de tipo técnico. El conocimiento técnico es fácil de encontrar en los miembros del equipo. Las razones de fracaso más frecuentes, a mi juicio, son tres: 

• Deficiente gestión de los riesgos
• Deficiente gestión de los costes
• Deficiente gestión de los interesados (cliente, equipo, subcontratistas, etc.)

Sin embargo, la gran mayoría de Directores de Proyecto proceden del ámbito del dominio técnico: Como son buenos técnicamente, se presupone que pueden liderar equipos y proyectos (efecto “halo”). 

Pero el conocimiento técnico no es suficiente para dirigir proyectos, porque un buen Director de Proyectos no hace el trabajo, coordina a los miembros del equipo para que lo hagan ellos (se parece a un director de orquesta). Es el primer responsable del proyecto, pero tiene cierto nivel de autoridad para tomar decisiones con autonomía. Un buen Director de Proyectos ha de quitarse “la gorra del técnico”, y ha de ponerse “la gorra del gestor”.

Ponerse “la gorra de gestor” de proyectos no es fácil. Piense en el mejor Director de Proyectos que conozca. Sí, ese que termina siempre sus proyectos en plazo y por debajo del presupuesto, por el que se pelean los jefes, para el que todos quieren trabajar, el que sabe anticiparse a los problemas (rara vez pulsa el botón de “crisis”), a quien los clientes adoran. ¿Dónde cree que lo aprendió todo? No en los libros. Como toda disciplina compleja, la gestión de proyectos se aprende practicando. 

Es este un aprendizaje continuo, cada nuevo proyecto es un desafío, y las verdaderas lecciones son los errores cometidos.

Aceptemos el rol de Director de Proyectos, conozcamos el juego y juguemos bien (2/2)

–Pregunta Nº 6: Este proyecto tiene multitud de riesgos. No hago otra cosa que hablar de ellos, pero todo el mundo parece ignorarlos. ¿Cómo hago para que cuando los problemas se materialicen no me echen la culpa a mí?

–Respuesta: Las palabras se las lleva el viento. Mejor mantengo un registro de riesgos actualizado. Gestión de riesgos es lo contario a gestión de crisis. Es la única forma de anticiparnos a los problemas. Como Director de Proyectos, quiero problemas, no sustos. Cuando los problemas aparezcan, daré una imagen profesional si los veía venir y ya tenía preparada la respuesta. En cada reunión de seguimiento dedico una sección monográfica para gestionar los riesgos (quizá sea suficiente revisar los más importantes). Presento cada riesgo indicando el nivel de exposición que supone, en euros. Si la respuesta es asumir, anoto fecha y decisor en el registro de riesgos.

–Pregunta Nº 7: El jefe de mi jefe quiere estar al tanto de todo lo que pasa, pero no viene a ninguna reunión de seguimiento. Un día le va a llamar el cliente con alguna queja, no va a saber qué responder, y habrá una cascada de reprimendas hasta mí. ¿Cómo evito esto?
–Respuesta: Es normal que los altos ejecutivos no tengan tiempo para ir a las reuniones de seguimiento, pero no es la única manera de informarles. La comunicación hay que adaptarla al receptor. En estos casos viene muy bien enviar periódicamente un informe de situación resumido, publicar cuadros de mandos con indicadores semafóricos, cronogramas de hitos, etc.

–Pregunta Nº 8: Me parece que el cliente no sabe lo que quiere, lo que pide es demasiado general y ambiguo. Cuando entreguemos, va a decir que no a todo ¿qué puedo hacer?
–Respuesta: Practicar iteraciones, entregando una parte cada vez, primero las más importantes, que puedan ir validando progresivamente: Los clientes puede que no sepan lo que quieren, pero siempre saben lo que no quieren. Quizá la primera entrega la rechacen, habrá retrabajo, se corregirán los defectos. Con toda probabilidad, la segunda entrega no será rechazada por entero y quizá sirva para validar la primera entrega al 100%. Esta dinámica de validaciones sucesivas le permite también al cliente ir modelando su visión del producto.

–Pregunta Nº 9: El cliente quiere introducir cambios continuamente.  
–Respuesta: Esto no hay que permitirlo. Si el alcance cambia todos los días, entonces no hay manera de gestionar el proyecto. Es lo que se conoce como degradación del alcance (scope creep, en inglés). La técnica más efectiva contra el scope creep es un sistema de gestión de cambios.

–Pregunta Nº 10: Los miembros del equipo asignados no tienen mucha experiencia en algo parecido, nunca han trabajado juntos, ¿voy a tener que hacerlo yo todo?  
–Respuesta: Por supuesto que no. Es recomendable un liderazgo situacional, adaptado a la madurez del equipo, primero habrá que dirigirles estrechamente, luego habrá que asignar roles y que entiendan el por qué de las actividades (dejar que se equivoquen), luego me necesitarán sólo de vez en cuando y a partir de cierto momento serán autosuficientes. Se han convertido en un verdadero activo dentro de la organización.

Si tú eres un Director de Proyectos que suele dirigir proyectos que acaban siendo un éxito, tú también eres un activo muy importante para cualquier organización de hoy día, porque cada día hay más proyectos en cartera dentro de cualquier organización, y cada día son más críticos. En algunas empresas, todo lo que hay son proyectos.

Aceptemos el rol de Director de Proyectos, conozcamos el juego y juguemos bien (1/2)

–Pregunta Nº 1: Me colocan al mando de un proyecto crítico. Me asignan equipo, objetivos, presupuesto, plazos, pero también me asignan muchas responsabilidades. ¿Esto es bueno o malo?
–Respuesta: Esto es algo bueno: Mi empresa confía en mí. Tengo un reto por delante y mucho que aprender demostrar.

–Pregunta Nº 2: Empiezo a ver muchas barreras. ¿Qué hago?

–Respuesta: Como dijo Randy Paush : “Los muros están ahí por una razón. No están para dejarnos fuera, sino para darnos la oportunidad de demostrar lo mucho que queremos algo. Los muros están ahí para detener a las personas que no quieren algo lo suficiente ¡Están ahí parar detener a los demás!”.

Culpable de “teamicidio” Nº 8: Horas extra (overtime) para todos salvo para algunos

Imagine que Vd. dirige un equipo bien cohesionado y sinérgico. Está produciendo buenos resultados a un ritmo fantástico a sus ojos y los de su jefe. Todos saben que los buenos resultados provienen del nivel de cohesión y sinergia del equipo: El todo es más que la suma de las partes.

Pero no es suficiente. Las altas esferas han prometido el producto en junio, lo que no va a ser posible al ritmo actual. Suena como un caso propicio para el overtime, ¿verdad?

Culpable de “teamicidio” Nº 7: El control sobre las camarillas

Las palabras “equipo” y “camarilla” (clique, en inglés) son tan diferentes como “brisa” y “corriente”. Las dos significan cosas muy parecidas “flujo de aire fresco”, pero “brisa” tiene una connotación agradable, mientras que “corriente” es algo molesto. La gente usa “equipo” cuando el estrecho lazo que une a las personas es agradable, y usan “camarilla” cuando el grupo representa una amenaza. 

Las razones que unen a un equipo cohesionado y sinérgico son más fuertes que las que les unen a la empresa, por eso está siempre el temor a una fuga en masa. Los equipos cohesionados y sinérgicos pueden ser arrogantes, auto-suficientes, irritantes y excluyentes, pero sirven mejor a los auténticos objetivos de la dirección que cualquier otra combinación de elementos intercambiables. 

Culpable de “teamicidio” Nº 6: Los plazos imposibles

A veces, imponer fechas límite ajustadas es desmotivador para el equipo. Por el contrario, imponer plazos ajustados pero no imposibles, muchas veces también constituye un desafío, una oportunidad para el logro conjunto y el desarrollo del equipo. 

Lo que nunca va a ayudar, sin embargo, es imponer plazos imposibles de cumplir.

Cuando el jefe dice: “Es imperativo que el proyecto finalice necesariamente tal día…” los miembros del equipo experimentados no lo pueden evitar: Levantan las cejas, cierran los ojos y suspiran. Ya han pasado por ello antes. Ya conocen la rutina.

Culpable de “teamicidio” Nº 5: La reducción autoimpuesta de la calidad

Nadie quiere realmente reducir la calidad de los productos, sino su coste. Habitualmente, sin embargo, el significado es el mismo. Los pasos que se dan para entregar el producto en menos tiempo implican menor calidad. A menudo son los usuarios finales quienes consienten una menor calidad a cambio de una entrega en menos tiempo y con menos coste.

Pero estas concesiones pueden ser muy dolorosas para los programadores. Su autoestima y disfrute del trabajo salen perjudicados ante la necesidad de construir un producto de una calidad claramente inferior a la que son capaces.

Culpable de “teamicidio” Nº 4: La multitarea

Muchas veces, la dirección impone políticas de fragmentación del tiempo porque consideran que las habilidades y el conocimiento de los profesionales les hacen indispensables en otros proyectos, aparte del que supone su asignación principal.

La multitarea es perjudicial para la formación de equipos, pero también es perjudicial para la eficiencia. Por lo general, las personas no estamos diseñadas para seguir muchas interacciones humanas al mismo tiempo. Si alguien trata de formar parte de 4 equipos de trabajo a la vez, se pasará el tiempo cambiando de marcha. Nadie puede formar parte de varios equipos cohesionados al mismo tiempo. Las estrechas interacciones que ocurren en los equipos cohesionados y sinérgicos son exclusivas. 

Culpable de “teamicidio” Nº 3: El papeleo (la burocracia)

En las décadas de los 70 y 80, Caper Jones dirigió una serie de estudios para categorizar los costes en los desarrollos de sistemas de información. Una de las categorías era el papeleo (paperwork, en inglés). Lo que Jones llama papeleo es algo así como la documentación que se genera sin sentido, la que sirve para "cubrir el expediente", simple y llana "burocracia". Hablamos aquí de la documentación no relacionada con los requisitos, el análisis, el diseño, codificación, planes de pruebas, ayudas, manuales, etc. Jones concluía que el papeleo supone más del 30% del coste de producir un determinado producto software. 

El jefe que no confía en su equipo

Como Director de Proyectos, Vd. debe practicar la desconfianza en muchas áreas de riesgo. Si trabaja con material defectuoso, habrá que preparar material de repuesto. Si el cliente cambia constantemente de criterio, tratará de cerrar al máximo las especificaciones. Si un proveedor tiende a “olvidarse” de sus compromisos, publicará un acta después de cada reunión.

Hay un área, sin embargo, donde ser desconfiado no le dará nunca buen resultado: Vd. no puede protegerse ante la incompetencia de su propio equipo. Si su equipo no está capacitado para realizar el proyecto, Vd. fracasará.

No hay “team building”, sólo hay “team growing”

En su célebre obra Peopleware: Productive Projects and Teams, los autores Tom DeMarco y Timothy Lister inventaron el término "Teamicide" (¿podemos decir “teamicidio”, en español?). Esta palabra expresa muy gráficamente lo que les pasa a los equipos cohesionados y sinérgicos que acaban muriendo por causas externas.

También sirve para identificar las causas por las que muchos equipos nunca llegan a formarse realmente como equipos. A este respecto, proponen cambiar el término "team building" por "team growing". En español, diríamos que hay que cambiar el término "formar al equipo" por "hacer crecer al equipo". A mí me gusta más el término "sembrar equipo", me recuerda mejor la ley de la cosecha.

  

El overtime se compensa con undertime

Muchos jefes se consideran mejores cuanto más "exprimen" a los programadores. Siendo el desarrollo de software un trabajo intelectual, pensar así es claramente un error. 

Ciertos estudios demuestran que trabajar más de 80 horas semanales no aumenta la productividad neta. 

Programar es un trabajo intelectual

En su célebre obra Peopleware: Productive Projects and Teams, los autores Tom DeMarco y Timothy Lister comparan la actividad de “programar” con otra actividad altamente industrializable, como es el negocio de la comida rápida. El siguiente cuadro resume los puntos de comparación:

Receta para Gestionar Riesgos

Este texto se ha traducido del libro:
Slack. Getting past burnout, busywork, and the myth of total efficiency
Editorial: Broadway Books. Autor: Tom DeMarco.

Un riesgo es algo negativo que puede ocurrir o no (o quizá ocurra en algún grado). Es negativo porque si ocurre, sus probabilidades globales de éxito disminuyen. Cuando un riesgo sucede, decimos que se materializa.

Gestionar riesgos significa declarar explícitamente la incertidumbre provocada por esas posibles materializaciones, pero antes de llegar a esto, es necesario trabajar individualmente sobre cada una de las incertidumbres identificadas. Hay dos clases de riesgos, que exigen diferente tipo de gestión: los riesgos agregados y los riesgos individuales. 

Planificando el Fracaso

Este texto se ha traducido del libro: 
Slack. Getting past burnout, busywork, and the myth of total efficiency
Editorial: Broadway Books. Autor: Tom DeMarco.


Los cambios radicales en nuestra economía global nos han traído nuevos modelos para hacer negocios, nuevos mercados y competencia sin fronteras. Todo esto genera oportunidades, pero toda oportunidad implica riesgo. Nadie tiene éxito si no arriesga, todo el mundo lo sabe. Incluso las organizaciones más serias de hoy en día saben que el riesgo es algo de lo que no se pueden escapar.

Una definición interesante de éxito en muchas organizaciones actuales es esta: Tome usted un montón de riesgos y supere todos y cada uno de ellos. Cuando los detalles de todos estos pequeños triunfos se oficializan, el resultado es un enfoque llamado “Planificar el Éxito”. Planificar el Éxito es un principio de filosofía de gestión muy frecuente, especialmente en el sector tecnológico. Este principio de gestión consiste en contar con que se materializan todos los resultados deseados, y aceptar compromisos basados en la consecución de dichos objetivos.

Planificar el Éxito es el equivalente intelectual de: Fórrese usted después de ganar 15 manos consecutivas al blackjack, sin retirar dinero de la mesa hasta el final. Esto funciona cuando funciona, pero le dejará hundido cuando no (la mayoría de las veces). También favorece la aversión al riesgo. Una organización que se espera supere todas las adversidades sólo puede permitirse tomar los riesgos más triviales. De la misma manera, una organización que no ha sufrido perjuicios importantes, en realidad no ha tomado riesgos de verdad.

La gestión de riesgos es casi lo contrario a Planificar el Éxito. La gestión de riesgos es –respire hondo, esto va a ser desconcertante- una disciplina para Planificar el Fracaso. Las empresas que practican gestión de riesgos prevén un montón de fallos pequeños (pero caros) a lo largo del camino antes del éxito global. El éxito global consiste en retirarse de la mesa con mucho dinero al final.

Tomar riesgos significa exponerse a sobrecostes y retrasos potenciales. Si usted toma un montón de riesgos, algunos terminarán costándole y otros no. La cuenta final le puede salir favorable. Suponga que sólo se materializa un 10% de los riesgos, con sobrecostes y retrasos. Usted no debe esperar sortear todas las consecuencias negativas. Debe reservarse algunas holguras de tiempo y dinero para hacer frente a estas consecuencias. La gestión de riesgos es la ciencia que le guiará a la hora de determinar estas holguras.

Gestionar Proyectos: Más Sociología y menos Tecnología

Los proyectos fracasan la mayoría de las veces no por la innovación tecnológica que suponen. ¡A veces, un proyecto fracasa sencillamente porque Pepe no se habla con Juan! La ausencia de “habilidades humanas” explica muchas veces el porqué de la imposibilidad de cerrar los requisitos, de superar las pruebas de aceptación, de la baja productividad, del excesivo retrabajo, retrasos, sobrecostes, etc. ¿No será la nuestra  una profesión donde la Sociología tiene más peso que la Tecnología?

Pocas profesiones hay más orientadas a objetivos que la del Director de Proyectos. Además, es extraordinariamente injusta, porque si el proyecto es un éxito nadie nos felicita, pero si es un fracaso, entonces la culpa es sólo nuestra. El inconveniente es que el trabajo del proyecto no cae en nuestra zona de control, sólo podemos coordinar lo que hacen otros.

Evaluando a un Director de Proyectos ineficaz

Pensemos en un Director de Proyecto que no nos guste. ¿Qué suele decir un jefe cuando evalúa a esta persona? A continuación va una lista de defectos que yo recuerdo haber observado en compañeros y en mí mismo (hay mucha autocrítica en esta lista):

• Siempre se está quejando de los procesos internos, de los recursos, del cliente, de los plazos, pero nunca propone soluciones.
• No es proactivo. No se anticipa a los problemas. Avanza reactivamente, de crisis en crisis.
• Tarda mucho en tomar cualquier decisión, no me parece que tenga criterios claros.
• No tiene un plan completo del proyecto, ni por escrito ni en su cabeza. Cuando se lo pido, me hace un gantt, pero sospecho que es sólo para cubrir el expediente.
• No gestiona bien el tiempo. Siempre anda desbordado. Nunca parece tener tiempo para nada nuevo. No responde a los correos. No devuelve las llamadas. Lo urgente no le deja tiempo para lo importante. Generalmente no cumple lo que promete.
• No sabe delegar, todas las decisiones han de ser suyas. Se mete demasiado en las tareas técnicas.
• Es demasiado autoritario. Ha quemado al equipo. He recibido muchas quejas de los responsables funcionales, del cliente, de los proveedores, etc. No mantiene buena relación con los interesados, no confían en él.
• Le falta empuje para cerrar de una vez el proyecto. Siempre me dice que estamos al 90%.
• Le veo cometer siempre los mismos errores. Tropieza con las mismas piedras una y otra vez. No le preocupa mejorar.
• No lleva un registro de incidencias. No gestiona el alcance. Al cliente le dice a todo que sí.
• No conoce el presupuesto, lo gastado, lo facturado, el margen comercial, etc.
• No me da información ejecutiva. Por ejemplo, no es capaz de justificar el progreso real, qué retraso final acumulará el proyecto y cuál será el sobrecoste.

Si usted hace su propia lista, seguramente no coincidirá con la mía, pero apuesto a que tienen algo en común: Casi todos los defectos entran en el grupo de las llamadas "habilidades sociales", o soft-skills, en inglés. Como puede comprobar, en mi lista sólo los últimos tres puntos se refieren a técnicas y herramientas del tipo hard-skills. El resto tiene que ver con los elementos "sociológicos" del proyecto. Un proyecto puede resultar un fracaso sólo porque no se comprenda bien al cliente, porque la moral de los miembros del equipo esté baja, o porque dos personas en el equipo estén permanentemente enfrentadas.

El paradigma de los 7 hábitos adaptado a los Project Managers

... y esta es la adaptación que yo he pensado para los Directores de Proyectos:

El paradigma de los 7 hábitos

Estos son los 7 hábitos de la gente altamente efectiva, propuestos por Stephen Covey en 1989:

Conversando en el ascensor con un Director de Proyectos eficaz

Ahora démosle la vuelta a la escena. En ese mismo trayecto en ascensor ¿qué diría un Director de Proyectos eficaz?

-Patrocinador: ¡Hombre, ya tenía yo ganas de verte! ¿Cómo va mi proyecto?

-Director de Proyectos: Tienes un mail mío en tu inbox. El riesgo que se identificó hace dos semanas se ha materializado. Necesito tu aprobación para sustituir al experto en base de datos. Recordarás que habíamos aprobado una subcontratación por 2 meses, 10.000€. Este sobrecoste reducirá el margen final medio punto.

-Patrocinador: ¿Impactaba la fecha límite?

-Director de Proyectos: Si cuento con él el próximo lunes, como me aseguran, no habrá retraso por esta razón.

-Patrocinador: ¿Por esta razón? ¿Te preocupa otra cosa?

-Director de Proyectos: El nivel de retrabajo que estamos asumiendo. Este lunes nos han cambiado las especificaciones por tercera vez. Calculo que hemos producido 500 puntos función que hay que tirar a la basura. Esto son otros 10.000€.

-Patrocinador: ¿Qué sugieres que hagamos?

-Director de Proyectos: He preparado tres alternativas para reducir el alcance. Hay una presentación en el mail que te he enviado. ¿Tienes tiempo ahora? Me gustaría contártela bien. Creo que deberíamos ir mañana a ver al cliente...

¿Aprecian la diferencia? Este otro Director de Proyectos sí transmite una imagen de eficacia, desde luego. ¿Cuál es su secreto? 

Conversando en el ascensor con un Director de Proyectos ineficaz

Imaginemos la siguiente escena: Un Director de Proyectos coincide con su patrocinador en el ascensor:

-Patrocinador: ¡Hombre, ya tenía yo ganas de verte! ¿Cómo va mi proyecto?

-Director de Proyectos: Pues, así, así... Resulta que Pepe se va de la empresa y nos deja un poco colgados...

-Patrocinador: ¿Quién es Pepe?

-Director de Proyectos: Nuestro experto en base de datos, creía que le conocías. No sé qué vamos a hacer sin él…

-Patrocinador: Entonces, ¿le tengo que decir al cliente que hay un retraso?

-Director de Proyectos: Estaría bien, sí.

-Patrocinador: ¿Cuánto tiempo? ¿Qué acciones vamos a tomar? ¿Cuánto nos va a costar? ¿Por qué no había un reemplazo?

-Director de Proyectos: Es que no damos abasto con las nuevas peticiones. Día sí, día también, nos cambian los requisitos.

-Patrocinador: Eso no puede ser, no podemos decirle a todo que sí, es un fixed price. Iré a verle mañana. Dame el registro de cambios, el registro de riesgos y el estimate to complete.

-Director de Proyectos: Ejem..., bueno... yo me quedo en este piso. Luego, si eso, ya te pongo un mail...

Como es de esperar, el patrocinador no recibirá ese mail esta tarde, habrá que atender otras peticiones urgentes. ¿Qué pensará este patrocinador de este Director de Proyectos? ¿Le verá como un Director de Proyectos eficaz? ¿Qué dirá cuando le pidan opinión para su evaluación anual? ¿Y si el Director General hubiera coincidido también en el mismo ascensor?

Adaptar los 7 hábitos de Covey a la gestión de proyectos

Stephen Covey publicó en 1989 su libro “Los 7 hábitos de la gente altamente efectiva” que fue elegido el libro empresarial más influyente del siglo XX y uno de los diez libros más influyentes de la historia, llegándose a vender más de 18 millones de ejemplares en 38 idiomas en todo el mundo. Muchos ven en el paradigma de efectividad de los 7 hábitos las claves para gestionar mejor el día a día y para lograr la efectividad personal sostenible a largo plazo.  El modelo de los 7 hábitos de Stephen Covey le ha servido a millones de personas durante más de dos décadas para orientar el camino hacia la efectividad. Este marco de 7 hábitos ya se ha adaptado para las familias, los adolescentes, las escuelas de primaria y las empresas, siempre superando todas las expectativas.

Si hay alguien que necesita la efectividad más que nadie, ese es el Director de Proyectos. Como personas eficaces deberían seguir el paradigma de los 7 hábitos de Covey, y cómo no, todas las recomendaciones de buscar la propia voz e inspirar a los demás dentro de la empresa, liderazgo basado en principios, planificación personal, etc. Esto está muy bien pero, en mi opinión, no es suficiente: Debería profundizarse en el paralelismo existente entre los hábitos de Covey y el cuerpo de conocimientos detallado en el PMBOK.

Podemos aprender y enseñar los 7 hábitos de Covey en el lenguaje de nuestra profesión.