Gestión de Programas en Servicios

0

Siempre digo, y no me canso de repetir, que la gestión de servicios y proyectos están tan ligados que no podemos decir que somos expertos en uno sin tener conocimientos básicos en el otro. Hoy os presento una de las razones por la que un gestor de servicios no estará completo si no domina la gestión de proyectos. Esta razón es la gestión de programas dentro de un servicio. Es decir, la gestión de los múltiples proyectos que se suceden en el ámbito del servicio y que son ejecutados principalmente por el mismo equipo que está operando el servicio.

Describiendo el entorno

Vamos a situarnos antes de nada. Somos los responsables de un equipo que presta uno o más servicios a un conjunto de clientes. Por simplificar diremos que presta un servicio. Este servicio realiza tareas repetitivas de forma continua, dentro del ámbito de los típicos procesos y funciones de operación del servicios, vamos lo que comúnmente se llama “dar soporte al servicio”. Desde la gestión de incidencias, peticiones de servicio o problemas hasta las tareas de mantenimiento, monitorización o control de las operaciones de TI. Pero estos servicios no son estables eternamente. Continuamente se presentan cambios en los mismos que van desde actualizaciones de software a cambios en los procedimientos de soporte. Estos “cambios” (y lo pongo entre comillas para no confundirlo con el cambio desde el punto de vista ITIL) tienen dos características principales:

  • Implicarán modificaciones al servicio.
  • Serán gestionados y realizados principalmente por el personal de soporte del servicio.

La manera de gestionarlos es muy variada. He visto que cada organización, o incluso equipos dentro de la misma organización, los administra de forma diferente. Hay equipos que crean una lista de “cosas para hacer” en el servicio, como un kanban. Otros tratan al servicio como un gran proyecto y pintan un Gantt con estos cambios. Otros crean tickets del tipo “tarea” en su sistema de gestión del servicio. Y otros (quizás los más) van a salto de mata haciendo los cambios según se van organizando los miembros del equipo en sus ratos libres.

La realidad de estos cambios

Estos cambios no son tareas simples. A veces son tareas de un día o dos. Pero en muchas ocasiones implican desplegar entornos nuevos de test, probarlos antes de pasar a producción y pasar por todo el circuito de gestión de cambios (estos si que son ITIL) de la organización. A veces hablamos de trabajos que se extienden varios meses. ¿Un trabajo complejo, delimitado en el tiempo, qué puede ser? Un proyecto. Son claramente proyectos. Y como tales hay que tratarlos, aplicando todo nuestro conocimiento en gestión de los mismos.

Bueno, he de ser sincero: la verdad es que la mayoría de gente los considera proyectos. Pero, al menos los equipos con los que me he topado no los tratan como proyectos con el mismo celo que se ve en el mundo de desarrollo de software. Como mucho ves una planificación y poco más. Pero es muy raro ver un control de riesgos, un seguimiento en condiciones o un cálculo del valor ganado.

En este punto creo que ya tenemos claro que dentro del servicio tenemos un conjunto de proyectos que comparten recursos. ¿Y cómo llaman en PMBOK a un conjunto de proyectos que comparten recursos? Un programa. Así que estaremos de acuerdo en que dentro de un servicio tenemos un programa. El problema es que creo que en el mundo de gestión de servicios, la gran mayoría de implicados no ha oído hablar de programas; y mucho menos de cómo se gestionan.

La situación actual

Bueno, la verdad es que mientras planteaba el problema ya he descrito bastante la situación actual, pero voy a intentar hacer un poco de análisis sobre la misma. Sobretodo en lo que a errores más comunes se refiere:

  • Los proyectos no se tratan como tales en muchos casos, y cuando se hace sólo se tiene en cuenta al iniciarlos.
  • En el caso de tratarse como proyectos, muchos aspectos de la gestión de proyectos no se realizan, como la gestión de interesados, la de riesgos, comunicaciones, etc.
  • No se calculan los principales indicadores de estos proyectos (costes, plazos, recursos, …) a la hora de que el gestor del programa y los patrocinadores estén informados y puedan hacer una priorización y calendarización realista y ajustada a los objetivos del negocio.
  • La gestión de los proyectos se realiza en muchos casos por parte de un técnico. Y cuando dos técnicos del equipo llevan proyectos en paralelo no se crea una figura central que los coordine (el gestor de programa).

Ventajas de aplicar una gestión de programa

Si aplicamos una gestión de programa, ganaremos ventajas por partida doble:

  • Por la gestión de proyectos
  • Por la gestión de programa

Es decir, sólo por dar un enfoque más profesional a la gestión de esos proyectos ya ganaremos mucho. Nos tenemos que preocupar de aplicar las mejores prácticas, y en el caso de proyectos dentro de un servicio las más importantes quizás son:

  • Correcta gestión de riesgos: Esto lo tendremos alineado con ITIL. El proyecto casi seguro terminará en un cambio, que nos pedirá esta gestión de riesgos. Así que esto es trabajo que hemos adelantado.
  • Correcta gestión de interesados. Los proyectos en servicios suelen tener múltiples implicados. Un cambio de versión de un Oracle tendrá implicaciones a todos los niveles de la empresa. Pararemos servicios, pondremos en riesgo aplicaciones. Esto implica mucha comunicación con interesados.
  • Correcta gestión de plazos. Los proyectos dentro de un servicio suelen pecar de “cuando se pueda se tendrá”. Suelen contar con los recursos sobrantes de la operación del servicio. Así que muchas veces se olvida la planificación y la estimación. Pero es más que posible que tengamos a muchos interesados esperando, y tenemos que poder informarles de cómo va el proyecto y cuando esperamos alcanzar los hitos.

Lo anterior es de aplicación incluso en proyectos pequeños que duren unas pocas semanas.

Por otro lado si aplicamos las mejores prácticas de gestión de programas dentro del servicio veremos que tenemos importantes ventajas, al tratar todos los proyectos en conjunto:

  • La gestión de interesados puede hacerse desde un punto de vista de programa, con comunicaciones que aglutinan información sobre todo el programa. Los interesados suelen ser comunes, por lo que reduciremos costes. Es decir, nos costará menos esfuerzo gestionar los interesados desde el punto de vista del programa, que del proyecto.
  • La gestión de recursos es imposible de conseguir si no se le otorga de una visión de programa. Son totalmente compartidos.
  • La priorización de proyectos (cuales acometo antes y cuales después) es también muy compleja si no se estructura como un programa. Si se estructura como un programa los criterios de valoración serán comunes y las decisiones objetivas e informadas (y defendibles). Incluso,  ¡aquí podríamos hablar de gestión de cartera de proyectos!
  • Toma de decisiones transversal. Cada proyecto puede encontrarse con dilemas, que deben tratarse también teniendo en cuenta otros proyectos. Tener una gestión de programa estructura estas decisiones y crea un marco de trabajo para tratarlas.

Roles

En un servicio solemos tener un lider, un service manager. Después tendremos varios perfiles clave que suelen coordinar y liderar distintos equipos. Muchas veces son los admins senior. Y luego tenemos al resto del equipo. La gestión de cada proyecto debería realizarse por estos lideres intermedios, siempre que el alcance de los mismos no sea global a todo el equipo. Y el service manager actuaría como gestor de programa.

Si la organización dispone de PMO, estos proyectos debería enmarcarse en las buenas prácticas dictadas por esta oficina. Pero si carece de ella, el service manager debería actuar como PMO.

Mundo Agile

¿Y que hacer si la organización está orientada a metodologías ágiles. Pues aplicar los mismos criterios que el resto de la empresa en la medida de lo posible. ¿Funcionan con SCRUM? Pues intenta aplicarlo en tus equipos. ¿En vez de programas tienen Scrum de Scrums? Pues aplícate el cuento tú también. No hay mucha diferencia entre los objetivos de un Scrum de Scrums y la gestión de programas. Ambos intentan planificar y seguir de forma conjunta los proyectos buscando las sinergias entre ellos y reduciendo los conflictos, a la vez que consiguen una comunicación común con el resto de la organización. Es cuestión de adaptarse a la cultura de tu organización, y no nadar contracorriente.

Sobre el autor

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de proyectos, usando metodologías clásicas y ágiles, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector. Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo. Actualmente trabaja en Sunhotels, como responsable del equipo de operaciones TI.

Sin comentarios