6 síntomas del exceso de metodología

Un error frecuente en muchas organizaciones, y también en líderes inexpertos, consiste en pensar que lo necesario para garantizar el éxito de un proyecto es implementar una buena metodología de gestión. Es importante conocer las distintas normas y estándares de dirección de proyectos, pero las metodologías de gestión son simplemente herramientas, pautas y buenas prácticas que pueden hacer el trabajo más eficiente. Considerarlas paquetes salvavidas y obsesionarse con su aplicación estricta es sólo una manera de ocultar los problemas del proyecto y alejarnos de la posibilidad de resolverlos. 

La obsesión injustificada por la aplicación estricta de una metodología suele venir acompañada por alguno de los siguientes síntomas:

  • El libro se sigue al pie de la letra. Es un error no recortar y adaptar la metodología escogida al trabajo concreto que se va a realizar (el denominado proceso de tailoring). Todo la preocupación es seguir los dictámenes del libro o guía de turno, ignorando que cada proyecto y cada organización tiene necesidades particulares que obligan a analizar los procesos metodológicos para eliminar y redefinir muchos de ellos.
  • El proyecto es un régimen burocrático. La gestión del proyecto y del equipo parece, más que en una ejercicio de project management, un régimen burocrático donde la rigidez es absoluta y una gran parte del tiempo se dedica a pulir cuestiones como la utilización de plantillas para todo, la entrega de informes mastodónticos para trabajos minúsculos o efímeros, la redacción de actas de conversaciones de diez minutos… En general, se realizan grandes esfuerzos, pero no se justifican por el beneficio que se obtiene de ellos.
  • La creatividad no está permitida. Cualquier movimiento que se salga de lo especificado estrictamente por la metodología está fuera de las normas y por tanto debe ser intervenido y neutralizado. La metodología ya deja muy claro cuál es el camino a seguir y la improvisación y la creatividad son comportamientos peligrosos.
    Si bien no se debe fomentar el incumplimiento de los protocolos y el desorden, en ocasiones es necesario considerar alternativas que redundan positivamente en ahorro de recursos o en la eficiencia del trabajo. Algunas veces es necesario adoptar este tipo de medidas excepcionales para reconducir el curso de un proyecto. Determinar cuándo y de qué modo es conveniente salir del camino marcado originalmente es también tarea del gestor de proyectos.
  • Nada puede hacerse sin aprobación. No existe libertad para asumir la más mínima iniciativa, ni tampoco mecanismos de delegación eficaces. Todo tiene que pasar por un nodo central, una máquina expendedora de firmas y aprobaciones incluso para las decisiones menos relevantes, según lo dispuesto en el diseño de procesos de la guía metodológica. En esta situación, cuanto mayor es el proyecto o el equipo, mayor es el perjuicio.
  • Presumir de metodólogos. Enfermedad común en las PMO (Project Management Office) que se da cuando la principal pretensión es conocer al dedillo determinada norma o estándar y presumir de su alto nivel de aplicación. El cumplimiento estricto y minucioso de un estándar se sitúa por encima del auténtico objetivo final: la entrega del trabajo bien hecho y a tiempo.
  • Antipatrones peligrosos. La parálisis por el análisis y el liderazgo por responsabilidad sin autoridad son antipatrones que suelen surgir en escenarios en los que la aplicación excesivamente rigurosa de una metodología dificulta la consecución de los objetivos del proyecto.

Las metodologías de gestión de proyectos son imprescindibles, y aportan muchos más beneficios de los que restan. Siempre, y ahí está la clave, correctamente adaptadas a cada proyecto y administradas, como todo,  en su justa medida.

Aprender a delegar: 5 pasos básicos y 2 grandes errores

Delegar es una de las tareas más importantes de un directivo. Aprender a delegar correctamente puede hacer el trabajo mucho más productivo y satisfactorio, especialmente el de cualquiera que ostente un cargo de responsabilidad. No todos los directivos son capaces de hacerlo con eficacia, y a menudo se cometen fallos que llevan a malos resultados en cadena.

Los dos errores más típicos y frecuentes al delegar son los siguientes:

  • Negarse a hacerlo. Actitud típica de quien necesita tener control absoluto de todo y no muestra confianza suciente en nadie. Ocurre también en quienes ejercen un liderzgo autocrático o en esos responsables de proyecto que han tenido una mala experiencia delegando trabajo. En muchos casos, los fracasos del pasado radican en que el directivo que delega espera del responsable de la tarea que se comporte como un clon suyo, planificando, analizando, ejecutando tareas exactamente igual que lo haría él.
  • Delegar y olvidar. El error más triste. Delegar no es endosar, sino gestionar. Lo primero conduce a la servidumbre, lo segundo es una fórmula más del trabajo en equipo. Conviene recordar que la persona que delega sigue siendo la responsable final de la decisión de delegar y del trabajo resultante. Asignar tareas y no hacer nada más (seguimiento, evaluación de resultados, etc.) es un error grave. Las causas puede ser múltiples: falta de organización, mala comunicación, irresponsabilidad o falta de capacidad de gestión.

El sencillo esquema de cinco pasos básicos para delegar eficazmente:

  1. Explicar bien la tarea que se delega: paquete de trabajo, importancia, contexto, herramientas necesarias, actores involucrados, riesgos, etc.
  2. Definir bien el alcance de la tarea: qué decisiones se delegan completamente, cuáles se consultan y qué asuntos no se consideran.
  3. Definir entregables concretos: evitar ambigüedades, indeterminaciones y sorpresas desagradables.
  4. Establecer hitos de control.
  5. Hacer una crítica constructiva: refinar el proceso, destacar lo que ha salido bien y analizar los que se debe mejorar.

Como conclusión, las palabras del 50º presidente de los Estados Unidos, Ronald W. Reagan:

Surround yourself with the best people you can find, delegate authority, and don’t interfere as long as the policy you’ve decided upon is being carried out.

Es decir: rodéate de los mejores y delega en ellos.

La importancia que debes dar a tus conversaciones

Reseño aquí un libro interesante, The talking manager, de Álvaro González-Alorda. Título de 2011 en el que se trata una idea fundamental tanto en la vida laboral como en la personal: la necesidad de cuidar la calidad de nuestras conversaciones, considerándolas una herramienta más de gestión y liderazgo.

Dos minutos de lectura son suficientes para revelar la importancia crucial que el autor concede a las conversaciones. Las tres primeras palabras del prólogo son: “Somos seres dialógicos”, mientras que el primer capítulo comienza con un rotundo “nos jugamos la vida en las conversaciones que tenemos”.

El libro recoge varias razones por las que las conversaciones son instrumentos de gran utilidad, al margen de la función elemental de transmisión de mensajes:

  • Resolución de problemas. Una simple conversación puede conducirnos al desenlace de una situación desagradable o enquistada. “A este problema le falta una conversación”.
  • Fomento de la creatividad, que surge en un ambiente de diálogo.
  • Demostración de liderazgo. La relación directa entre el liderazgo y la capacidad de comunicar, de transmitir ideas y valores, de generar motivación y actitudes deseables. “La calidad de tu liderazgo depende de la calidad de tus conversaciones”.

Los apartados del libro que considero más interesantes están dedicados a:

  • Los cuatro tipos básicos de conversaciones que identifica el autor.
  • La conversación encrucijada (no incluida en los cuatro anteriores), ese “tipo de conversación cuyo desenlace, ineludiblemente, te abre un camino y te cierra otros”.
  • Un compendio de claves para lograr conversaciones de alto impacto, mejorando los dos principales aspectos de una conversación: argumentación y empatía.

The talking manager, con subtítulo Cómo dirigir personas a través de conversaciones / Leading people through conversations, ha sido publicado en edición bilingüe en inglés y español por Alienta Editorial. Un libro pequeño, de apenas 100 páginas, ideal para leer durante un viaje en tren o avión. Redacción sencilla y sin complicaciones, de lectura fácil y centrado en argumentar bien un único tema: la importancia que debes dar a tus conversaciones.

Antipatrones: las prácticas que debes evitar y conocer

En el diseño de software, un patrón es una solución a un problema concreto que se demuestra reutilizable y aplicable a casos similares. Lo contrario es un antipatrón: un patrón que nos lleva directamente de un problema a una mala solución. Si ya es interesante conocer las buenas prácticas que nos ayudan a mejorar, tanto o más conviene conocer aquellas que nos conducen al fracaso.

La mayoría de los antipatrones se producen en proyectos de desarrollo de software, como el modelo en avalancha, muy útil en estos tiempos en que sigue muy presente la reminiscencia clásica (modelo de cascada) mientras se sigue con esmero la moda ágil. Sin embargo, también hay antipatrones válidos para proyectos que nada tienen que ver con el software, pues se refieren a prácticas de gestión, liderazgo, comunicación, relación con el equipo, etc. Algunos de mis favoritos son: cultura del héroe (el que tarda más en irse),  tirita (aplicar un parche sin eliminar el problema de fondo) o confusión de objetivos (no alineamiento de los objetivos del gestor-equipo-proyecto).

Podéis consultar un listado de antipatrones aquí, amplio, en inglés y con la posibilidad de buscar por categorías. Muy recomendable y en español la recopilación de antipatrones de Jummp.

Los términos que debes conocer de la gestión de proyectos

Conocer y utilizar correctamente los términos y expresiones propios del área de conocimiento sobre la que se escribe, investiga, trabaja, es siempre una muestra de profesionalidad y de respeto. En el ámbito de la gestión de proyectos, las siguientes fuentes pueden ayudarnos a manejar rápidamente el léxico adecuado:

  • PMI Lexicon of Project Management Terms. Mi primera referencia siempre, la documentación del Project Management Institute.
  • Gartner IT Glossary. Un glosario estupendo, muy completo.
  • PMO and Project Management Dictionary. Un glosario de PM Hut que aguanta una consulta urgente pero que está mal presentado y sin estructurar.
  • Glossary of Project Management terms. PMGloss ofrece un glosario clasificado por metodologías, lo cual es una característica más que interesante. Hay siete categorías: PMI, PRINCE2, RUP, MSF, PJM, COMPTIA y CMMI.
  • Glossary of Project Management. El glosario de gestión de proyectos que publica Wikipedia. No hay disparates (en alguno casos son definiciones generalmente aceptadas; del PMBOK, por ejemplo), pero si Wikipedia se convierte en nuestra fuente de referencia… debemos seguir buscando hasta encontrar otra.

El contenido de todos los sitios referenciados anteriormente está en inglés. EOI publica un glosario en español, aunque es bastante limitado: no busquéis la definición de proyecto, no está.

Qué es (y qué no es) un proyecto

Resulta curioso comprobar que muchas de las personas que trabajan en proyectos, de cualquier tipo, no son capaces de explicar con sencillez y claridad qué es un proyecto. Trabajan en uno, manejan sus recursos y asumen sus objetivos, pero no conocen ninguna definición de proyecto y les resulta complicado elaborar una en dos líneas. 

Hay varios textos a los que generalmente se acude. La norma ISO 10006 define un proyecto como “un proceso único, que consiste en un conjunto de actividades coordinadas y controladas con fechas de inicio y finalización, llevadas a cabo para lograr un objetivo conforme con requisitos específicos y requerimientos específicos, incluyendo las limitaciones de tiempo, coste y recursos”. Demasiado larga y detallada.

El estándar británico PRINCE2 define un proyecto como “un entorno de gestión que es creado con el objeto de entregar uno o mas productos de acuerdo a un plan de negocio dado”. Más acertada que la anterior, pero sin entrar en el concepto fundamental de unicidad del objetivo del proyecto.

La guía PMBOK del Project Management Institute aporta la mejor definición, por su contenido y brevedad:

Un proyecto es un esfuerzo de carácter temporal llevado a cabo con objeto de crear un producto o servicio único.

De las definiciones anteriores podemos deducir algunas de las características generales de un proyecto:

  • Consta de más de una tarea o actividad, seguramente estructuradas en fases y bloques de trabajo.
  • Son necesarios mecanismos de control y planificación para gestionar correctamente objetivos, requerimientos, actividades y recursos.
  • De carácter temporal: nace con una vida determinada y, por tanto, debe tener fechas de inicio y finalización.
  • Su objetivo es proporcionar un producto o servicio concreto y distinto. Éste es quizá uno de los puntos que más confusión crean. Por ejemplo: la construcción de los edificios de dos colegios puede llevarse a cabo con los mismos planos o materiales, pero se trata de dos proyectos con entidad propia debido a que cada producto final será único (distinta localización, elementos de diseño, dirección, constructor, proveedores, etc.).

Operaciones: qué no es un proyecto

Es un error frecuente el confundir proyectos con operaciones. Las operaciones se caracterizan por ser continuas y permanentes, en contraposición al carácter temporal (comienzo y finalización determinados) de los proyectos. Un proyecto es un trabajo que empieza y acaba y que responde a una necesidad concreta -y probablemente estratégica- del negocio. Las operaciones son un continuo que permite el funcionamiento de la organización a lo largo del tiempo. Proporcionan regularmente el mismo tipo de producto o servicio; por ejemplo, operaciones de producción en una fábrica, mantenimiento de sistemas industriales o prestación del servicio de firma electrónica en una organización TI.


La cuarta edición del PMBOK explica en su apartado 1.5 que los proyectos pueden converger con las operaciones en determinadas situaciones, fundamentalmente entre fase y fase de un proyecto, cuando se mejoran productos o servicios existentes o al incorporar otros nuevos. Todo ello puede implicar un trasvase de información, conocimiento y artefactos varios del proyecto a la gestión de operaciones (o al revés). Por ejemplo: formación, manuales, buenas prácticas, canales de comunicación o contactos.

En numerosas ocasiones se sigue denominando proyecto a aquello que resulta ser una mera gestión de operaciones. No dejará de ser un error por mucho que las tareas, en ocasiones pequeñas, abundantes, repetitivas, técnicamente complejas… supongan una elevada carga de trabajo y guarden relación con un producto o servicio que, en su momento, representó el objetivo de un proyecto.

Por qué es difícil ser un buen mando intermedio

En un artículo de 2009 titulado Why it’s so hard to sell to the middle manager, se refiere Brian Sommer a los mandos intermedios como “frequently under-loved, under-studied and under-appreciated group of business people”. Lo cierto es que no es fácil ser un buen mando intermedio. Algunas de las causas que lo explican son las siguientes:

  • Tarea compleja. El trabajo de los mandos intermedios es planificar, ejecutar y controlar a los equipos. Esta tarea es compleja y requiere de múltiples habilidades: personales, de comunicación, organización, gestión de expectativas o resolución de conflictos. Todo ello al margen de los conocimientos específicos del área de trabajo.
  • Incertidumbre. Los mandos intermedios toman muchas decisiones en condiciones de incertidumbre y soportan niveles de estrés más elevados que otro tipo de perfiles.
  • Formación. La formación en habilidades de liderazgo y gestión es generalmente deficiente.
  • Alinear objetivos. Deben alinear, hacer compatibles y gestionar simultáneamente los objetivos, problemas y soluciones del día a día con los objetivos, problemas y soluciones a medio y largo plazo.
  • Decisiones de arriba. Asumen como propias decisiones de la alta dirección y guían a sus equipos para cumplir objetivos… que no siempre comparten pero que tienen que defender. Además, su conocimiento específico sobre determinadas parcelas de trabajo les permite detectar con impotencia las decisiones incorrectas que se toman en la alta dirección.
  • La parte y el todo. Gestionan solamente una parte de la organización, aunque su trabajo tenga repercusión en toda la compañía. Los mandos intermedios dirigen proyectos, equipos,  departamentos, aplicando sus propios métodos y principios, pero intentando al mismo tiempo que los defectos, vicios y malos hábitos del resto de la organización no afecten a su parcela. Lograr hacerse impermeable a los males del entorno sin convertirse por ello en una isla solitaria es uno de los retos más difíciles de un mando intermedio.

Para terminar, incluyo tres artículos interesantes. En los dos primeros se augura el fin de los mandos intermedios, y se exponen propuestas que en mi opinión sólo son fácilmente aplicables en entornos pequeños. El tercero y último va en sentido contrario a los anteriores.

10 medidas para mejorar tu vida

Del reputado Tony Schwartz leí Be excellent at anything, con subtítulo The four keys to transforming the way we work and live. Ya en ese libro de 2010 se mencionan algunas pautas que el autor ha recopilado recientemente en un artículo para lo que denomina “recuperar tu vida”. He aquí un resumen de las 10 medidas que propone para, digamos, mejorar tu vida:

  1. Duerme.
  2. Haz ejercicio.
  3. Come mejor.
  4. Trabaja en períodos cortos con descansos cortos entre ellos. *
  5. Dedica tiempo a tus seres queridos.
  6. Sé agradecido. *
  7. Haz primero lo más importante. *
  8. Reflexiona. *
  9. Sigue formándote.
  10. Sé altruista.

Los puntos señalados con asterisco son directamente aplicables en el trabajo diario, el resto dependerá del caso. Aunque no lo parezca, en la práctica el punto 7 es especialmente difícil de cumplir: dedicar los primeros esfuerzos de cada jornada a las tareas más importantes. Al comienzo del día disponemos de más frescura y capacidad de concentración que al final, pero a menudo dedicamos esas horas con picos de energía a reuniones y cuestiones burocráticas menores que acaban mermando nuestra productividad.
Una medida que esperaba y no está incluida en la lista: busca un trabajo que te proporcione motivaciones y recompensas.
De interés: Schwartz organiza además un webinar gratuito cada mes (empezando en febrero) para explicar cómo implementar con facilidad cada una de las diez medidas. Detalles y ampliación en el artículo original, publicado en su blog de HBR.org: Take back your life in ten steps.

3 deseos de un IT project manager para el año nuevo

Llevo unos años dedicado a la gestión de proyectos TI, un mundo por el que comencé a interesarme cuando cursaba estudios de  ingeniería. A lo largo de mi vida laboral y de estudiante he cubierto diversas facetas: he estado “de cara al público”, en atención al cliente, soporte técnico, programación de software y gestión o dirección de proyectos. La universidad me ayudó a ponerme la primera meta: ser ingeniero para participar en la dirección de proyectos.

Desde mis comienzos en este mundo me siguen llamando la atención sobremanera las mismas taras. Voy a inaugurar el blog compartiendo mis deseos de año nuevo como project manager, tres cosas básicas que deberían existir en cualquier proyecto:

Desde mis comienzos en este mundo me siguen llamando la atención sobremanera las mismas taras. Voy a inaugurar el blog compartiendo mis deseos de año nuevo como project manager, tres cosas básicas que deberían existir en cualquier proyecto:

  1. Respeto por la profesión. La del informático, ingeniero, desarrollador, analista, trabajador TI, etc., es una profesión a menudo desprestigiada… por los propios informáticos. La ausencia de metodologías de trabajo, la programación improvisada, el desprecio por los mecanismos de análisis, la falta de protocolos, la recogida poco rigurosa de requisitos, la escasez de acuerdos vinculantes entre cliente y proveedor, la fiabilidad de las aplicaciones…
    Son grandes lastres de los proyectos TI que tienen su origen en la falta de respeto que un porcentaje significativo de los propios profesionales de las tecnologías de la información sienten por su profesión y disciplina. ¿Cuántos proyectos empiezan, sobreviven y terminan sin existir siquiera un project charter (o documento equivalente)? ¿En cuántos no hay documentos de requisitos o son insuficientes? ¿Cuántas veces el curso de un proyecto no está correctamente alineado con las necesidades reales del negocio?
  2. Distinción entre equipos de soporte y de desarrollo. Para optimizar el uso de recursos de un proyecto es fundamental contar con un equipo de soporte al margen de los programadores o desarrolladores, de modo que no se mezclen funciones ni recursos, ni se pierda tampoco la concentración necesaria para crear nuevo productos, el “ambiente de laboratorio”.
    Combinar en un mismo grupo soporte y desarrollo actúa en detrimento del orden y la planificación, y convierte a menudo el trabajo de un equipo de programadores en una maraña de peticiones sin control. A menudo se acaba dedicando esfuerzos a tareas no prioritarias, se expone la imagen y el prestigio del equipo a cambio de nada y se permite al usuario o cliente interferir involuntaria e ilimitadamente en la planificación real de los proyectos.
  3. Enfoque metodológico claro. Hay muchos estándares, guías, compendios de buenas prácticas… Sólo es necesario hacer un análisis serio para escoger el que mejor y más fácilmente responde a las necesidades del momento. Rara vez puede aplicarse una metodología al pie de la letra y al 100% de su contenido, por lo que generalmente es necesario realizar aproximaciones para cada caso concreto. Todos los enfoques resultarán en algún aspecto inadecuados por incompletos, incómodos, complejos, poco flexibles o muy rigurosos, por lo que habrá que hacer sacrificios.
    Lo fundamental, no por ello frecuente, es recorrer el siguiente camino: i) escoger bien la metodología; ii) realizar el proceso de tailoringadaptarla al proyecto, organización y equipo particulares; y iii) aplicarla con rigor y continuidad, dotándose de un método.

Lo anterior son piezas elementales para fortalecer el trabajo de un project manager. Son tres de los elementos básicos sobre los que se pueden construir buenos mecanismos de gestión de proyectos TI.

Popurrí de lecturas recomendadas (2013)

He recopilado algunas de los libros que me han mantenido ocupado en 2013. No están todos, y se trata de lecturas variopintas, que agrupo por temática y que me han gustado. Unos más, otros menos:

Comunicación

The talking manager y Los próximos 30 años, de Álvaro González Alorda. El primero centrado en la importancia de las conversaciones, el segundo es más un libro para reflexionar sobre nuestra estrategia y  actitud ante acontecimientos venideros.

Negociar es fácil, si se sabe cómo, de Alejandro Hernández. Un autor que conoce sobradamente el arte de la negociación, la venta en persona y la conversación. Gran parte del contenido de este libro lo conocí en sus clases del MBA.

Presentation Zen, de Garr Reynolds. Un clásico para hacer presentaciones con Power Point y similares.

Proyectos

Project Management Body of Knowledge, fifth edition.

Gestión Ágil de Proyectos de Software, de Javier Garzás. Buen libro para repasar los conceptos básicos de las metodologías ágiles de desarrollo de software, como Scrum.

Economía

La convergencia inevitable, de Michael Spence. Gran obra, economía, globalización, naciones,  geoestrategia…

Economics in one lesson, de Henry Hazlitt. Uno de los básicos. Algo tan elemental como la falacia de la ventana rota se explica en este libro.

Novelas

Viejas recomendaciones de Seleucus:

El ministerio del dolor, de Dubravka Ugresic.

La ruleta chechena, de Robert Lozinski.

Administración Pública, Filosofía, Historia

Corrupción en la universidad, de José Penalva.

Historia de España contada para escépticos, de Juan Eslava Galán. Fue un regalo inesperado; lectura muy amena, estilo sencillo y divertido. Los capítulos, breves pero rigurosos, se pueden leer en el orden que el lector prefiera.

De Nietzsche a Mourinho. Guía filosófica para tiempos de crisis, de Santiago Navajas. Se lee solo, filosofía, gestión de equipos, fútbol…

Poesía

Antología Cátedra de poesía de las letras hispánicas. Edición pequeña y en tapa blanda, imprescindible. Todos los grandes clásicos de la poesía española. Un libro de tamaño pequeño que guarda un tesoro colosal.

Antes del nombre, de Eloy Sánchez Rosillo. Un maestro de nuestro tiempo.

¿Cómo pudo ocurrir aquel prodigio
de que al llegar a un punto, a tal momento,
tú ya no fueras tú
y fueras justamente tu contrario?
Qué enigmático es todo, qué aventura
esta ignorancia ciega del vivir.

Antes del nombre. Eloy Sánchez-Rosillo