La importancia del “handover” en la gestión de proyectos

¿Te imaginas que tuvieras que dar soporte eterno a todos y cada uno de los productos de los proyectos que has gestionado a lo largo de tu carrera profesional? ¡A que no!

Yo llevo más de 20 años gestionando proyectos, y sólo pensarlo me pone los pelos de punta.

Afortunadamente no nos encargamos de eso, hay un momento, en el que el trabajo del proyecto acaba y nos desligamos de ese producto  final que tanto esfuerzo nos costó conseguir.

¿Qué es handover?

Con esta pequeña introducción acabamos de aproximarnos a lo que en la gestión de proyectos se denomina handover.
Según el diccionario Cambridge

Handover significa «the giving of control of or responsibility for something to someone else.»

En español lo traduciríamos como «ceder el control» o «traspasar la responsabilidad» del algo (en este caso del resultado final de un proyecto) a otros.

Este paso forma parte del ciclo de vida natural de los proyectos, y seguramente todos estamos de acuerdo en que tiene bastante importancia.

Ciclos de los proyectos y el handover

Es bien conocido que hay distintos ciclos de vida de proyecto. Unos requieren que el alcance, el tiempo y el coste se determinen con detalle en sus primeras etapas, antes de que el trabajo comience a producir entregables, y otros utilizan ciclos de vida iterativos o incrementales (ágiles) que tienen entregas parciales del producto para cada iteración. Pues bien, independientemente de cuál sea el ciclo de vida, el handover está siempre presente.

Antes de profundizar en la importancia del handover, vamos a echar un vistazo a esos entregables que forman parte del producto final de nuestros proyectos, y vamos a ver cómo viajan por los distintos grupos de procesos, siempre según PMI.
La primera vez que aparecen los entregables como tal es durante el grupo de procesos de planificación. Dentro del plan de gestión de proyecto (project management plan) se definen, con sus requisitos detallados, su alcance, su calidad…, y dentro de este plan también definimos claramente cómo vamos a obtener la aceptación de los mismos una vez completados, es decir, desde el principio, tenemos que definir qué criterios nos asegurarán que nuestro cliente aceptará esa pieza, esa casa, o ese nuevo producto tecnológico que le vamos a entregar.

En el grupo de procesos de ejecución el equipo se pone en marcha y a toda vela, fruto de lo cual se generan esos entregables, en concreto son una de las salidas del proceso «dirigir y gestionar el trabajo del proyecto» (direct & manage project work), de allí, y dentro del grupo de procesos de seguimiento y control, entran en «controlar la calidad» (control quality), de donde saldrán verificados (de acuerdo a unos criterios de calidad previamente definidos) y posteriormente deberán ser validados en el proceso de «validar el alcance» (validate scope). Esta validación tiene que ver, no con la comprobación de que los entregables son los correctos, eso ya lo hicimos antes, esta validación es la formalización de aceptación de los entregables por parte del cliente. El principal beneficio de este proceso es que aporta objetividad a la aceptación e incrementa las posibilidades de aceptación del producto, servicio o del resultado final del proyecto.

Los entregables ya aceptados pasarán, al grupo de procesos de cierre y en «cerrar proyecto o fase» (close project or phase) allí se produce el cierre formal del trabajo del proyecto o de la fase correspondiente.

¡Menudo viaje realizan los entregables!

Bueno, espero que el siguiente gráfico ayude a comprender este pequeño lio.

¿Con todo esto que os he contado ¿Dónde reside la importancia del handover?

Esta transferencia de responsabilidades de los entregables es lo que nos permite a los Jefes de Proyecto, y al equipo de proyecto hacer lo que mejor sabemos hacer: «Crear productos, servicios o resultados únicos y temporales, con un inicio y un final establecidos», vamos lo que viene siendo emprender nuevos proyectos, dedicarnos a hacer cosas nuevas.

Todo lo que describí con anterioridad con respecto al handover parece de bastante sentido común. Nuestro proyecto arranca para satisfacer las necesidades de un cliente y una vez construido ese producto final, se lo tenemos que transferir para que lo utilice.

Es por esto, por lo que desde el principio, nos estamos preparando para esa transferencia de responsabilidades, porque está implícita en el «encargo» que nos han realizado, y por eso lo tenemos en cuenta y lo planificamos con detalle y esmero desde el principio, pero ¿es eso suficiente?

¡Quizás no! Lo que hemos descrito con anterioridad se centra en el  handover hacia el cliente. Pero no sólo existe esa transferencia de responsabilidades, ya que normalmente en los proyectos existe la transferencia hacia otra área más. En mi relación con la gestión de proyectos, he visto con demasiada frecuencia que esta otra transferencia no se planifica como sería deseable, o en otras palabras, a menudo algunos proyecto se olvidan de planificarla.

Como algunos habréis adivinado, me refiero al área de operaciones, porque aunque parezca un poco drástico, cuando ponemos en marcha algo nuevo, tenemos siempre una certeza: algún día va a fallar…

Sabemos que proyecto y operaciones son dos áreas de trabajo distintas, pero están estrechamente conectadas. Cuando se termina un proyecto, el producto se ha de entregar al área de operaciones para que lo gestione, para que lo mantenga y para que lo «cuide». Esta transferencia no se hace mediante la ciencia infusa, sino que normalmente requiere proporcionar a ese nuevo equipo de personas capacitación específica y suficiente para realizar nuevas labores, y quizás requiera también de ajustes a determinados procesos operativos que se utilizarán el producto o el servicio del proyecto.

Esta es la segunda transferencia de responsabilidades a la que me refería. Cuando el área de operaciones pertenece al cliente, todas las actividades relacionadas con ellas se suelen planificar con el mismo cariño y detalle que ponemos en la transferencia del resultado final del proyecto, pero si él área de operaciones pertenece a nuestra compañía… ¡Ay! Ya se sabe, «donde hay confianza…»

¿Cómo realizar el traspaso del resultado del proyecto al área de Operaciones?

Generalmente los equipos de proyecto están tan centrados en crear, que a veces dejan de lado las necesidades de los que se van a encargar de apoyar y mantener lo que estamos creando. Eso hace que nos olvidemos de lo importante que es para ellos participar del proyecto desde el principio y entender cuál será resultado final para que puedan definir qué necesitan a la hora hacerse cargo de él.

Lo cierto es que tampoco es tan difícil, al fin y al cabo no tenemos nada más que considerar al área de Operaciones como un involucrado (stakeholder) más, y contar con ellos como hacemos con el resto de stakeholders. Tienen que conocer con antelación qué se espera de ellos después del cierre del proyecto y tienen que decirnos qué necesitan del proyecto para poder conseguirlo. A menudo no saben lo que tienen que hacer (e incluso si tienen que hacer algo) hasta que es demasiado tarde, cuando hay un incidente y el cliente trata de averiguar quién se tiene que hacer cargo de ese problema.

También es importante asegurar que después de la aceptación del resultado final del producto hay un sistema establecido de escalado y de comunicación de incidencias u otros asuntos, es decir, quién es responsable de qué y con quién tiene que contactar el cliente cuando pasa algo.

Más cosas, ¿hemos dejado documentación suficiente para que los que vienen detrás sepan qué hacer? ¿Necesitan algún tipo de formación? ¿Existen los procedimientos necesarios para esta fase post-proyecto?

Si tenemos en cuenta estos pequeños consejos ahorraremos problemas en nuestro proyecto y haremos que el área de Operaciones este «razonablemente» satisfecho con nosotros.

Recordemos, cuando pensemos en «ceder el control» o «traspasar la responsabilidad» de los entregables de un proyecto, que esta cesión no es exclusiva hacia el cliente final.
¡Suerte con vuestros proyectos!