Gestionando proyectos

Un año con Murex. Lecciones póstumas de Fermat

0

En 1637 Pierre de Fermat enunciaba el conocido como su último teorema:

“Es imposible descomponer un cubo en dos cubos, un bicuadrado en dos bicuadrados, y en general, una potencia cualquiera, aparte del cuadrado, en dos potencias del mismo exponente. He encontrado una demostración realmente admirable, pero el margen del libro es muy pequeño para ponerla.”

En álgebra moderna diríamos que la ecuación  x^n + y^n = z^n \,no se cumple para ningún conjunto de números enteros positivos n, x, y, z si n es mayor que dos.

Fermat tenía la costumbre de ensayar demostraciones de los teoremas en los márgenes de los libros donde los leía, por eso su afirmación de que había encontrado una demostración resultó creíble para los matemáticos de su tiempo. Pero si lo logró se llevó el secreto a la tumba. Durante más de 300 años muchísimos otros matemáticos intentaron encontrar la demostración, algunos llegando al borde de la locura y recomendando a sus sucesores que se mantuviesen apartados de este infernal problema.

Finalmente, en 1995 Andrew Wiles consiguió la tan perseguida demostración tras 8 años de trabajo dedicados casi en exclusiva a este problema. Él mismo describió el proceso de la siguiente manera:

Uno entra en la primera habitación de una mansión y está en la oscuridad. En una oscuridad completa. Vas tropezando y golpeando los muebles, pero poco a poco aprendes dónde está cada elemento del mobiliario. Al fin, tras seis meses más o menos, encuentras el interruptor de la luz y de repente todo está iluminado. Puedes ver exactamente dónde estás. Entonces vas a la siguiente habitación y te pasas otros seis meses en las tinieblas. 

Exactamente así me he sentido trabajando este último año en un equipo de soporte de Murex, sólo que con ciclos de un mes en cada habitación oscura.

Un mundo complejo

Murex es sin duda el producto de software más complejo que yo haya conocido en toda mi carrera. Sus funcionalidades son virtualmente infinitas y el uso que hacen de ellas sus clientes es muy diverso. El propósito del producto se podría resumir como la gestión de la posición de tesorería, cálculo de riesgos y resultados y control del flujo de operaciones para una entidad que opere con productos financieros mínimamente complejos.

Ser eficiente en un equipo IT de Murex requiere un conocimiento bastante avanzado de:

  • Productos financieros: cómo se calculan los beneficios y cuáles son los riesgos de cada uno de ellos.
  • Varias ramas IT: Bases de datos, Linux, Middleware y experiencia en programación.
  • El ciclo de vida de las operaciones en los mercados financieros: Qué hacen los Ventas, los Traders, Riesgos, el Backoffice…
  • Estar acostumbrado a trabajar con datos: ser muy ordenado para no naufragar en el océano de información.
  • Conocer bien tu organización: Muchos usuarios de muchos departamentos trabajan en la aplicación. Casi nadie sabe lo que hace su departamento vecino. Si mezclas la respuesta de uno con la que has dado a otro no le ayudas y además le confundes.

La misión con la que llegué a este equipo fue la reducción de costes en un momento complicado para mi organización. Era la primera vez en mi carrera que me incorporaba a un equipo donde no tenía conocimiento técnico sobre la labor que desempeña el equipo. Y ese era mi desafío: un rol de gestión sin conocimiento profundo de lo que tenía que gestionar. Hace no mucho tiempo no creía que fuese posible desempeñarse con eficacia en una situación como la que me esperaba. Una cosa más que he desaprendido.

Trabajar en un equipo de Murex requiere gestionar la complejidad. Y esto aplica tanto en el desarrollo de nuevos proyectos como en la explotación del sistema implantado. Este es el resumen de mi experiencia en cada uno de los dos ámbitos.

Proyectos

La evolución del software la realiza el proveedor y la capacidad de añadir funcionalidad a ese software desde el lado del cliente es ciertamente limitada. Se le pueden solicitar cambios específicos pero su entregable será (casi siempre) una versión completa del producto. Cada nueva versión, por tanto, requiere de un esfuerzo brutal de pruebas de compatibilidad regresiva. Estas pruebas son necesarias tanto si los cambios solicitados son enormes como si son meramente cosméticos. El riesgo en el que se pone la organización a implantar incorrectamente una versión es tan grande que el parámetro de la calidad en las de pruebas no es negociable: seguridad total.

La situación por tanto es que el coste marginal de cualquier cambio es enorme y el beneficio económico marginal es en muchos casos solamente hipotético. La única forma de que salgan las cuentas para actualizar el software es incluir muchos cambios en la misma versión para reducir el coste de las pruebas. Pero muchos cambios hacen que el entregable tarde más tiempo en estar disponible.

Esto nos lleva al siguiente conflicto: la negociación de qué cambios se incluyen y cuales se dejan fuera. Cuando no conoces bien tu organización te tropezarás en la oscuridad con más muebles de los necesarios. En general, las expectativas depositadas sobre el software son infinitas. Esperamos que resuelvan incluso los problemas de comunicación con nuestros compañeros.

A medida que avanzan los proyectos se van ajustando los compromisos: no toda la funcionalidad prevista en el Power Point original se consigue, no todos los errores se logran corregir y además aparecen errores nuevos. Al mismo tiempo sí que se consigue implantar nueva funcionalidad y se corrigen algunos errores. ¿Habría alguna forma de conseguir todos los objetivos iniciales sin tener que sufrir nuevos problemas? Seguro qué sí, pero llevaría mucho más tiempo y mucho más coste. Y los tiempos y los costes son dos parámetros muy importantes en todas las implantaciones de Murex. Si llegas demasiado tarde tal vez el negocio ya no pueda obtener la ganancia que esperaba. Si tu proyecto cuesta demasiado eres tú quien se come su ganancia.

No hay que olvidar que los usuarios principales son traders. Su trabajo es negociar. El software es una ciencia ciertamente compleja, pero en última instancia está basada en la electrónica. Y con los electrones no se negocia. Hacen exactamente lo que se les pidió que hiciesen. Si aparece una situación inesperada y requiere cambio de software hay que repetir todas las pruebas desde cero: más tiempo, más coste…

Con todo esto en la coctelera, los proyectos de Murex se convierten en una máquina de generar frustración. Las expectativas son inmensas y la realidad las defrauda continuamente. Todos los participantes acabamos con la impresión de que se podría haber hecho mejor. Todos tenemos una lista de cosas que se hicieron mal. La tarea del director del proyecto es administrar esa complejidad y canalizar esa frustración hacia acciones de mejora para futuros proyectos. También hay quien se enfada y patalea. Incluso hay quien amenaza con no respirar. Luego nunca lo cumple.

Soporte

Después de los primeros seis meses en mi equipo lo rebautizamos informalmente como Soporte Espiritual Murex. La mayoría de las cuestiones que nos llegaban son preguntas de gente que ya sabe lo que tiene que hacer, pero que necesita una de estas dos cosas:

  • Una mera confirmación de alguien que conozca mejor la herramienta.
  • Un descargo de responsabilidad por si se equivoca.

No hay presupuesto que soporte a un equipo de expertos en Murex que pueda proteger a todos los usuarios de las dos contingencias arriba descritas. Por eso mi función principal ha sido reducir la necesidad de soporte por la vía de dotar de confianza a los equipos que ya estaban haciendo las tareas. Para los dos casos apliqué la misma medicina: procedimiento, procedimiento y más procedimiento.

La complejidad asusta: en general todo el mundo pide permiso. En un sistema como Murex tiene sentido que sea así, y con la experiencia de las consecuencias de errores pasados la gente aprende a temer. Al mismo tiempo los operadores que trabajan con el sistema saben hacer muchas más cosas de las que creen. Implantar confianza manteniendo la seguridad sólo se puede lograr con unos procedimientos suficientemente sólidos y suficientemente flexibles para incorporar cambios cuando se estime necesario.

Negociar procedimientos con todos los equipos participantes puede llegar a ser una tarea agotadora. Siempre participan muchos actores y no todos tienen incentivos para llegar a un acuerdo. Pero si se consigue se obtienen dos beneficios inmediatos: reducción de los costes operativos y disposición al compromiso de todas las partes para los procedimientos que estén por venir.

También hay incidencias del producto muy complejas que nadie más sabe resolver en la organización. Y todos los días llega alguna. Estas eran mi principal temor cuando me hice cargo del servicio. Mi experiencia en este sentido se limita a acercarle el botijo a quien las está resolviendo. Y conozco a personas en mi organización que en medio del fuego (y el fuego de Murex calienta mucho) no se paran ni a quitarse el sudor de la frente. Cuando sea mayor yo quiero ser como ellos.

Conclusión

En realidad, Andrew Wiles no demostró el teorema de Fermat. Lo que demostró fue un caso particular de la conjetura de conjetura de Taniyama-Shimura que era el último paso en una larga serie de teoremas, que en conjunto demostraban el teorema de Fermat. Fue el chute que metió el balón en la portería e hizo subir el gol al marcador, pero no otra cosa que la culminación de una sucesión de pasos en el desarrollo de la matemática de los últimos siglos. Conviene recordar la cita de Newton “Si he logrado ver más lejos, ha sido porque he subido a hombros de gigantes”.

Si yo fui capaz de sobrevivir a dirigir un equipo de soporte de una aplicación en la que nunca me había logado, fue gracias a la colaboración que han tenido conmigo absolutamente todos los equipos que conviven en este ecosistema. Equipos que, en su conjunto, cubren con creces todos los criterios necesarios para ser eficiente en un equipo de IT Murex. Y, por qué no decirlo, algunos individuos que también los tienen todos a la vez, gente a la que sólo teniendo cerca ya aprendes un montón.

P.D.: Apenas una semana antes de cumplir mi año de Murex, cuando ya tenía en mente el boceto de este artículo, como si fuera una premonición y mis jefes me metieron en una sala para darme la licencia y encomendarme una nueva misión. Ya he empezado a buscar el primer interruptor.

Project Management Profesional

0

Me había interesado por la certificación PMP unos meses atrás. Pero vista desde fuera pensé: cuesta una pasta, seguramente requiera un montón de horas de estudio, no tienes ninguna garantía de aprobar y en caso de que lo consigas tampoco sabes si realmente sirve para algo. Sin embargo, cuando es la empresa la que cubre los gastos, al menos una de las cuatro variables queda despejada. Eso sí, las otras tres siguen intactas.

El proceso para optar a la certificación PMP, otorgada por el Project Management Institute (PMI) es más o menos sencillo:

1) Debes acreditar unos miles de horas de experiencia en dirección de proyectos

2) Realizas un curso presencial (en grupo) de unas 40 horas impartido por una empresa acreditada

3) Superas un examen de tipo multirespuesta. 4 horas. 200 preguntas con 4 opciones cada una.

El temario del examen está recogido en el libro conocido como PMBOK, un ladrillo de 500 y pico páginas donde se desglosa toda la metodología de gestión de proyectos de PMI. A primera vista asusta, pero una vez que entras en faena no deja de ser una metodología con todos sus flujos de procesos, entradas, salidas y documentos. Si realmente has hecho dirección de proyectos no te sorprenderá demasiado. Es otro estándar, y como dijo aquel sabio, lo bueno de los estándares es que hay muchos donde elegir.

(más…)

Mi equipo de alto rendimiento

0

Como en cualquier otro sector, en los proyectos de tecnologías de la información sigue creciendo la presión por mejorar la eficiencia de los procesos y por aumentar la productividad. Reflexionando sobre el ecosistema en el que vivo empiezo a intuir que casi todas las mejoras que podemos obtener van a depender del funcionamiento interno de los equipos más que de las mejoras en la tecnología.

JumpHablamos mucho de la automatización y el poder de las máquinas, pero en mi negocio, empiezo a detectar cada vez con más intensidad que por cada incremento marginal que podemos conseguir con la tecnología conseguiríamos diez veces más con la mejora de la colaboración entre los humanos. Como no hemos conseguido métricas de colaboración entre personas, seguimos midiendo las de las máquinas. Esperando a que nos solucionen problemas de relaciones personales que son similares a los que ha enfrentado la Humanidad desde que bajamos de los árboles: las relaciones de poder y de estatus o el conflicto entre el individualismo y el comunitarismo podrían ser dos de ellos.

Los vertiginosos cambios que vivimos en estos tiempos están llegando también a la estructura de los equipos de trabajo. Empezamos a considerar la jerarquía piramidal taylorista-militar como superada, básicamente porque no hay esquema de costes que lo soporte. Se habla mucho de los equipos de alto rendimiento y ya que me siento orgulloso de pertenecer a uno de ellos, me gustaría compartir mi experiencia sobre cómo funciona.

(más…)

Las personas que trabajan contigo

0

(Viene de Gestión del Producto)

Me ha costado varios meses escribir este artículo. Lo tenía titulado tal y como lo rotuló la cultura laboral que existía cuando yo empecé a trabajar: Gestión de Recursos. Ese fue el primer motivo que me bloqueó para la formulación de cualquier idea coherente.

He tenido que renombrarlo simplemente para poder pasar más allá del título. Esa idea de que uno gestiona “personas” me parece completamente obsoleta y aún así me cuesta deshacerme de ella. Cada persona sabe gestionarse a sí misma y lo hará de forma eficiente sólo si quiere. El líder debe gestionar la capacidad de trabajo del equipo en su conjunto, que es algo muy distinto de “gestionar personas”.

Existen numerosas teorías sobre el liderazgo, algunas ya con cierta solera y otras más novedosas. Yo no soy experto en ninguna de ellas por lo que me limitaré a escribir lo que me ha aportado mi exieriencia, compilado todo ello por mi propio sentido común.

De un líder de cualquier equipo yo esperaría que cumpliese, al menos con estas cuatro funciones

Organizar el trabajo

Como ya hemos visto en artículos anteriores del blog, el trabajo no siempre llega en un pedido perfectamente ordenado y entendible. Organizar el método por el cual aceptamos peticiones de los clientes y las desarrollamos en nuestro equipo es una función de su líder.

En esta función a casi todos los trabajadores de nuestra generación nos educaron para pensar que el jefe manda y el equipo ejecuta. Y según el rol que te asignen, esa será tu función.

Hoy la evidencia empieza a ser bastante clara en un sentido un tanto contraintuitivo. Proporcionar a las personas que trabajan en tu equipo autonomía, capacidad de mejorar en lo que trabaja (maestría) y un propósito claro que trascienda la propia tarea fomenta la creatividad y la productividad mucho más que un jefe dando órdenes y velando por que se cumplan.

Gestionar las excepciones

Carl von Lineo creó un sistema de clasificación de los seres vivos a principios del siglo XVIII que sigue siendo una referencia a día de hoy en los estudios de Ciencias Naturales en todo el mundo. Dividía a los animales vertebrados en peces, anfibios, reptiles, aves y mamímeros. Luego los europeos encontraron en Australia al Ornitorrinco que mama pero pone huevos, tiene pico y cola de castor. ¿Es un animal erróneo? Obviamente no, es que la clasificación no lo contempla. La realidad siempre tiene prioridad a la hora de dar una explicación.

Pasa lo mismo con todas las metodologías. Cuando aparece una excepción se requiere de la toma de una decisión excepcional. Al igual que en el punto anterior la tentación para que sea “el jefe” quien las resuelva todas es grande. En primera instancia debe ser quien se encuentra la excepción quien intente gestionarla (principio de autonomía). Pero el equipo debe saber que su líder está ahí para apoyarle en la decisión, o llegado el caso para tomarla él mismo si cuenta con mayor información o más experiencia para valorar la situación.

Cuando aparecen muchas excepciones o una excepción aparece muchas veces, hay que plantearse si realmente lo son. Tal vez sea que simplemente es tu trabajo habitual y que la forma en la que has organizado el trabajo requiere de una revisión.

Manejar los conflictos internos del equipo

En todos los grupos de Homo Sapiens surgen conflictos, es inherente a la socialización. Mirar hacia otro lado para que se resuelvan solos es una buena forma de ir creando conflictos mayores. Poner la esperanza en encontrar un equipo adecuado donde los conflictos no existan es una tarea inútil. Algo parecido sucede cuando esperas que alguien cambie su personalidad para que el conflicto desaparezca.

Los dos conflictos principales que aparecen en la dinámica interna de un equipo están relacionados con la ambición y el reconocimiento. Para ambos casos, gestionar los conflictos implica tratar con las personas a nivel emocional. Esto exige tratar a humanos diferentes de forma diferente, lo cual puede crear nuevos conflictos internos en el equipo.

Establecer y conservar un clima de confianza y que los objetivos grupales prevalezcan sobre los individuales ayuda a hacer la tarea más fácil. Pero existen objetivos personales que también son legítimos. Hay que valorar cuando unos y otros son o dejan de ser compatibles.

Ayudar a cada persona a proyectar lo mejor de sí mismo

No todas las personas somos igual de hábiles para la misma tarea. Ni siquiera tenemos gustos parecidos para todas las tareas que existen dentro de cualquier actividad mínimamente compleja.

A los dictadores les gusta pensar que todos los humanos somos iguales, por eso unas normas muy sencillas deben servir para todos. Por eso mismo las dictaduras suelen llevar a la pobreza a los países que las sufren: simplemente acaban por no funcionar.

Es fundamental conocer a tu equipo: saber qué le gusta hacer y qué hace a desgana. Quién es el más indicado para las tareas que requieren socialización con otras personas. Quién para las tareas que exigen concentración absoluta. Quién encaja mejor para entregables que requieren un gran nivel de detalle. Quién puede entregar un diseño rápido que sirva para hacernos una idea claramente de a qué nos enfrentamos.

A veces no se puede elegir y las tareas las tiene que hacer simplemente quien está disponible. Pero, si se puede, mejor asignar a cada uno aquello que más le pueda hacer crecer.

Cuenta Leon Tolstoi en el epílogo de Guerra y Paz que la victoria francesa en la Batalla de Austerlitz se le asigna al genio militar de Napoleón. El emperador había dado instrucciones muy precisas a sus principales generales el día anterior. Terminaban indicando que se dejaba al albedrío de cada oficial las decisiones pertinentes que dependieran de los lances de la batalla.

Cuando estallaron las hostilidades casi ninguna de las divisiones estaban en el lugar que había previsto el genio militar, así que la última de las instrucciones fue a la que tuvieron que acogerse la mayoría de los generales. Ganaron los franceses.

No se puede ser un gran líder sin tener un gran equipo

Gestión del producto

0

Viene de (Parámetros gestionables de un proyecto)
Cobrar a muchos clientes por el mismo producto es un negocio más rentable que mantener un producto para cada cliente. En el caso de los proyectos de software esto es especialmente cierto, ya el coste de la copia del producto es prácticamente cero.

Sin embargo no todos los clientes necesitan (o se conforman con) el mismo producto. Existe, por tanto, un conflicto inherente entre el beneficio que supone conseguir clientes con un producto ya operativo y el coste que supone adaptar ese producto al cliente. La posición que tomemos ante ese dilema influye decisivamente en el tipo de proyecto que vamos a tener que gestionar.

Establecer si nos vamos a dedicar a crear un producto o crear una solución es un primer paso para la definición de nuestra estrategia. Un producto tiene, por naturaleza, la vocación de ser vendido a más de un cliente. Una solución es un entregable específico para el cliente que lo solicita.

Es muy común trabajar en el día a día con la flexibilidad que otorga trabajar en una solución y desear llegar a ser un producto. No suele salir bien. Para cuando quieres buscar un segundo cliente tienes tu aplicación tan empotrada en el primero que es muy costoso extraer únicamente las funcionalidades que pueden ser factor común.

diagrama_gestion_producto_software
Si tu intención es comercializar un producto por el que puedas facturar a múltiples clientes:

1) Elabora un plan de producto

Un plan donde se definan las líneas estratégicas del producto (qué incluye nuestro producto y, sobre todo, qué es lo que excluye), un plan de entregas del producto (qué se entrega cuándo) y un orden de priorización de características a incluir en el producto.

2) Diseña una estrategia de evolución de tu producto

Los productos evolucionan principalmente por cuatro vías, dependiendo de tu estrategia con tus clientes pueden tener prioridad una u otra:

  • Calidad proactiva: Mantenemos métricas de calidad y observamos cuando empiezan a incumplirse. Se corrigen y entregan en versiones posteriores
  • Calidad reactiva: Incidencias levantadas por los clientes.
  • Evolución basada en nuestro know-how del negocio: tratamos de adelantarnos a lo que los clientes nos pueden requerir
  • Peticiones de los clientes: Solicitudes de nueva funcionalidad

3) Cuando recibamos una petición del cliente, debemos hacernos la pregunta: ¿es parte de mi producto?

Manteniendo una visión global sobre el producto, debemos decidir si queremos incluir dentro de él lo que nos solicita el cliente.

  • Es producto: incluirlo en nuestro Plan de Producto
  • No es producto: Adoptar una solución ad-hoc (fuera del producto) o rechazar la petición.

Es común en estos casos que la avaricia acabe por romper el saco. No querer perder un cliente (o conseguir uno nuevo) nos puede llevar a tomar la decisión de decir “sí a todo”. Cuidado: una mala decisión puede generarnos un lastre que acabe por arrastrar al resto del producto que sí funcionaba correctamente. Recordemos la importancia de establecer los objetivos y generar expectativas realistas.

4) Diseño de soluciones para nuevos negocios

Si decidimos que una petición del cliente no es parte de nuestro producto, aún podemos hacer negocio con ella: podemos crear una solución a medida o tratar de crear un producto nuevo.

Hay que valorar los esfuerzos en el corto y en el largo plazo. Es posible que debamos rechazar en el corto incluirlo como parte de nuestro producto, pero que exista una confluencia en el largo con el producto que ya tenemos. Las opciones siguen siendo múltiples siempre que hayamos valorado correctamente los objetivos. Los problemas comienzan, una vez más, cuando sólo se nos enciende la luz del “sí”.

Hay que recordar que los costes de mantenimiento de las soluciones muy dispersas se multiplican con el tiempo. Si el mantenimiento no va a generar un ingreso recurrente, la venta de la solución puede dejar de ser rentable.

A la hora de la verdad, solemos hacer más bien lo que podemos que lo que queremos, y todo esto que es teoría, tiene una traslación más bien incierta a la práctica. Pero nunca está de más tener un ojo más allá del momento presente y recordar que nada es gratis, que las decisiones estratégicas de hoy traerán los éxitos (o lloros y lamentos) de mañana.

Parámetros gestionables de un proyecto

0

(Viene de Definición de objetivos)

recursos-tiempo-alcance-calidadEl desarrollo de un proyecto supone un compromiso constante entre cuatro variables:

  • Recursos (coste)
  • Tiempo
  • Alcance
  • Calidad

El éxito o fracaso de un proyecto dependerá en gran medida del acierto en la estimación inicial de estos cuatro parámetros. Al igual que con los objetivos al gestor del proyecto le pueden llegar ya dados estos parámetros o puede que se solicite su estimación.

Al gestionar el día a día del proyecto hay que recordar constantemente que nada es gratis: no se puede modificar uno de los cuatro parámetros sin afectar a alguno de los otros tres. Los deseos de los clientes chocan a menudo con las leyes de la probabilidad. Al igual que al definir los objetivos, nos encontramos con una guerra entre lo deseable y lo posible.

Cuando las condiciones iniciales del proyecto se ven modificadas, surgen imprevistos o eventos que modifican de forma relevante los objetivos del proyecto el gestor tendrá que actuar sobre alguno de los cuatro parámetros. Algunos ejemplos:

Actuar sobre el alcance

  • Reducir alcance para evitar un retraso
  • Ampliar alcance para ganar/conservar un cliente
  • Crear una segunda fase del proyecto donde se entregue las peticiones menos prioritarias

como-quieres-tu-proyectoActuar sobre los costes

  • Si son cambios solicitados por el cliente hay que trasladarle los costes: nada es gratis. Regalar a los clientes ampliaciones unilaterales del proyecto es una estrategia que rara vez sirve para conservar a esos clientes. Cabe preguntarse si nos interesa ese tipo de cliente.
  • Si los cambios no son achacables al cliente, van contra nuestro margen. Hay que tratar de minimizarlos.

Actuar sobre la calidad

  • Normalmente la calidad se asume como absoluta. Casi siempre que hay que actuar sobre la calidad es para reducirla

Actuar sobre el tiempo

  • Negociar los retrasos con los clientes.
  • Los adelantos sobre la planificación generan pocos agradecimientos. Se pueden publicar u ocultar para utilizar ese tiempo en otras tareas que siempre existen pero para las que nunca encontramos el momento.

En el dibujo anterior podemos ver de forma muy esquemática los tipos de proyectos a los que puedes asipirar (para un mismo alcance) según tus preferencias sobre los otros tres parámetros.

En casi todos los proyectos hay un factor que prevalece sobre los demás. Es necesario conocer el nuestro para ser consecuentes con las implicaciones sobre el resto de factores.

Si vas a lanzar un cohete al espacio, debes asegurarte que todas las operaciones del  ordenador de vuelo pueden trabajar en el rango de números enteros que sabe tratar el procesador. En caso contrario puedes decir adiós a 370 millones de dólares en cuarenta segundos. Eso fue lo que le pasó al cohete Arianne 5 de la Agencia Espacial Europea. En un proyecto así la calidad es crucial.


Si por el contrario tu proyecto es la página web de una cafetería, las consecuencias de falta de calidad pueden ser mucho más modestas. En ese caso el tiempo en el que esté disponible la primera versión puede primar sobre la calidad.

Todos los clientes te dirán que la cálidad y el alcance deben ser máximas y el coste y el tiempo de entrega mínimos. Si están firmemente convencidos entonces nunca tendrán su proyecto porque en la intersección de esos cuatro círculos está el conjunto vacío. También es trabajo del gestor del proyecto plantear un proyecto que encaje en alguna combinación de los cuatro parámetros.

Como gestor, debes conocer el enfoque de todos los participantes en el proyecto y elaborar tus escenarios de tiempo / coste / alcance / calidad. Estos escenarios pueden cambiar a lo largo de la vida del proyecto, por eso es muy importante comunicar los cambios cuando se produzcan y hacer un seguimiento transparente del proyecto. Cualquier alternativa pasará tarde o temprano por alguna opción menos deseable como generar expectativas imposibles o esconder los problemas de la vista del cliente con la esperanza de que nunca afloren.

Lo más importante a la hora de tomar decisiones de gestión es que estén basadas en la realidad presente. En lo que hay y no en lo que podría haber o tendría que haber sido. Recibiremos muchas peticiones para montar en el DeLorean y resolver en el presente problemas del pasado. Desgraciadamente la trilogía sólo existió para el cine.

Definición de objetivos

0

(viene de Gestionando la complejidad)

A la hora de lanzar un proyecto, lo más probable es que hayamos (o nos hayan) definido, al menos someramente, unos objetivos a lograr. Ojalá siempre fuera así. El responsable del proyecto se encuentra muchas veces con que está arrancando su tarea sin tener muy claros los objetivos.

create-smart-goalsSi la definición de los objetivos no es tu tarea (te vienen dados) asegúrate al menos de tener claro cuál es para ti el objetivo del proyecto. Comunica entonces al resto de participantes el objetivo que perseguirás para que lo validen o al menos que estén informados.

Si la definición de los objetivos del proyecto te corresponde a ti, tienes pocas excusas para no hacer una definición de objetivos SMART.

Casi todos los grandes problemas de los proyectos aparecen por una gestión deficiente de las expectativas en las fases tempranas. La generación de unas expectativas realistas y su comunicación a todos los participantes es una clave fundamental para el éxito de cualquier proyecto. El solicitante tiene su petición en la imaginación y al ejecutor le tocará traducir las ideas en hechos, pasar de las musas al teatro, y como al gran Lope, se lo pedirán muchas veces en 24 horas.

Antes de comprometerte con los objetivos del proyecto conviene aplicarles el filtro SMART. Hay miles de maneras de conseguir que tus objetivos NO sean SMART y muy pocas de lograr que sí que lo sean.

Definiremos nuestros objetivos para que sean:

Específicos

Al final del proyecto debemos poder responder de forma binaria (sí o no) si hemos conseguido cada uno de los objetivos planteados en un inicio. Esta meta sólo la podemos alcanzar si los objetivos que definimos son específicos.

Definir un objetivo específico ayuda a trabajar para alcanzarlo, pero también deja a la vista muy claramente si no se consigue. La tentación de definir objetivos muy vagos del tipo “mejorar el proceso, reducir los tiempos…” es muy grande. Estas definiciones de las metas son propias de quien tiene miedo a fracasar. Facilita mucho la capacidad de defender con la verborrea lo que no se puede conseguir con la gestión.

Los clientes son también muy dados a evitar los requerimientos específicos. Dejar las peticiones abiertas o definidas con ambigüedad es una vía para conseguir ampliar constantemente el alcance con el mismo presupuesto. He visto meses de trabajo de un equipo por una frase en el contrato abierta a la interpretación. Es muy desagradable para todos y se resuelve con algo tan sencillo como una definición específica tal que todos los participantes podamos estar de acuerdo en si está conseguido o no más allá de las sutilezas del lenguaje.

Medibles

Nadie obtiene un cheque en blanco a la hora de realizar un proyecto. Detrás habrá un cliente o un financiador que con mayor o menor frecuencia preguntará qué hay de lo suyo. Si queremos tener informados a los participantes sobre nuestro grado de cumplimiento de los objetivos, estos habrán de ser cuantificables y el grado de cumplimiento debe estar soportado por evidencias entendibles por los participantes ajenos al desarrollo del proyecto.

Esto es especialmente importante en proyectos que persiguen objetivos con plazos largos (qué es un plazo largo va a depender de cada organización). Para objetivos no demasiado costosos en el tiempo puede tener menos sentido la capacidad de medirlos porque nos encontraremos que nuestro cliente sólo quiere saber cuándo hemos finalizado.

Utilizar el ojímetro para informar de que hemos coseguido el x% de nuestro objetivo nos puede sacar de un apuro… sólo si nuestro cliente no es riguroso en el seguimiento. Mejor tener preparado un desglose del coste del objetivo con hitos intermedios verificables. Tendremos más claro qué tal vamos y por tanto seremos capaces de contarlo y mantener la credibilidad.

Alcanzables

Un objetivo que no se puede alcanzar es una fuente de frustración para todo el equipo del proyecto. Tener la certeza de que hagas lo que hagas no lo vas a lograr no es la mejor forma de tener a un equipo motivado. ¿Y hay objetivos que se definen sobre la base de que no se pueden alcanzar? Pues sí, los hay.

Hay gestores que temen que sus equipos “se relajen” sin tienen la consciencia de que han hecho un buen trabajo. Por eso les fijan objetivos imposibles de alcanzar de modo que al final del periodo sólo se discuta cuan lejos se ha quedado el equipo de la meta. Es una estrategia que sirve para mantener la disciplina en el corto plazo, pero que mina la moral en el largo.

Muchos objetivos no alcanzables se lanzan en situaciones de parálisis-por-el-análisis donde prima la actitud de “lo intentaremos” esperando que el objetivo se vea modificado durante la vida del proyecto. Es una opción arriesgada y no suele acabar bien ni para el cliente ni para el equipo.

Si como gestor del proyecto ves claramente que el objetivo no es alcanzable en los términos que te es planteado, es tu obligación informarlo a tu peticionario.

Realistas

La fantasía vende mucho más que la realidad. Los deseos no conocen fronteras y la realidad es muy tozuda.

Los objetivos realistas son el principal caballo de batalla entre los comerciales y los equipos de producción de las empresas. Un viejo compañero solía decir que en la primera reunión con el cliente después de la visita del comercial había que empezar diciendo: “Los reyes son los padres”.

Un objetivo en definición es un evento sucederá en el futuro. Y a falta de la bola de cristal no hay certezas de lo que se alcanzará al final del camino. Por ese motivo en este apartado es fundamental la experiencia del gestor de proyectos para valorar si un objetivo es o no es realista y bajo qué condiciones.

Acotados en el Tiempo

Todos los objetivos serán alcanzables o realistas si no los acotamos en el tiempo. La eternidad da para mucho.

Al fijarnos un objetivo debemos establecer en qué momento del tiempo planeamos alcanzarlo. El propio paso del tiempo servirá también como métrica de lo cerca o lejos que estamos de conseguirlo.

 

Definidos los objetivos, ya sólo nos queda lograrlos, aunque de eso ya hablaremos más adelante.

Gestionando la Complejidad

Invitado por la iniciativa YUZZ que patrocina Santander Universidades acudí al centro Yuzz de Madrid a impartir una charla sobre gestión de proyectos. El principal desafío al que me enfrenté fue tratar de resumir negro sobre blanco aquello que yo haya podido aprender sobre la gestión de proyectos en los años que a ello me dedico.

Se me ocurrió titularlo como a este post: Gestionando la Complejidad. Es la mejor definición que se me ocurre para este arte que supone dirigir un proyecto o un equipo de personas que desarrolla proyectos. Es relativamente sencillo encontrar a quien resuelva cualquiera de las tareas que aparecen durante la vida de un proyecto. Los problemas aparecen cuando se deben gestionar todas a la vez.

A partir de la presentación que realicé iré desarrollando algunos artículos en los que resumo mi visión sobre el oficio. El primero de ellos es sobre la propia idea de gestionar la complejidad.

Si acudimos a la Wikipedia para saber más sobre la gestión de proyectos nos encontraremos con esta definición:

La gestión de proyectos es la disciplina del planeamiento, la organización, la motivación, y el control de los recursos con el propósito de alcanzar uno o varios objetivos. Un proyecto es un emprendimiento temporario diseñado a producir un único producto, servicio o resultado con un principio y un final definido (normalmente limitados en tiempo, y en costos o entregables), que es emprendido para alcanzar objetivos únicos, y que dará lugar a un cambio positivo o agregará valor.

 

Organización y control de recursos, objetivos, obtención de un producto, principio y final definido… son palabras grandilocuentes que conviene tener presentes como horizonte filosófico, pero rara vez se hayan en el día a día del gestor. Llevado al extremo nos podemos encontrar con el caso de este jefe de proyecto, que siguió al pie de la letra de la teoría y le funcionó.

Gestionar la complejidad implica enfrentarse, entre otras cosas a:

  • Objetivos no completamente definidos: a la hora de arrancar se ve sólo el horizonte, no el destino.
  • Confluencia de intereses en ocasiones contradictorios en el desarrollo de un proyecto: no todos los participantes esperan lo mismo de la iniciativa en curso.
  • Resistencia al cambio: un proyecto se ejecuta para cambiar las cosas, las resistencias sólo se van descubriendo a medida que el proyecto avanza.
  • El objetivo de un proyecto no es únicamente finalizarlo, sino conseguir que sea rentable. En ocasiones la mejor forma de hacer rentable un proyecto es abandonarlo.
Estas cuestiones deben estar en la mente del director del proyecto de forma continua. El apoyo y el refugio de muchos gestores es el uso de una metodología. Las metodologías de gestión de proyectos son útiles porque proporcionan herramientas para facilitar la recolección de información y la toma de decisiones. Pero así como la azada no cava la viña, la metodología tampoco realiza el proyecto.
  • La metodología ayuda a gestionar la realidad, pero no podemos pedir a la realidad que se ajuste a una metodología. Es importante tener esto en cuenta ahora que se permite culpar a la realidad de no ajustarse a tus previsiones.
  • Las metodologías de gestión de proyectos son abstracciones de reglas basadas en la experiencia que han proporcionado casos reales. Toda abstracción implica una pérdida del detalle.
  • Se debe elegir la que mejor se adapte a nuestra forma de trabajar y al tipo de proyecto que desarrollemos, pero nunca dejará de ser una guía. Gestionar implica tomar decisiones, y la metodología no lo hará por nosotros.

(continuará)

Go to Top