Cierre del proyecto

  • José Ramón Rodríguez

    José Ramón Rodríguez

    Es consultor independiente en Dirección de Tecnologías de la Información y Gestión de Proyectos TIC, profesor de Sistemas de información y dirección de las TIC de la UOC y autor de artículos y libros sobre estas materias. A lo largo de su carrera profesional, ha alternado la actividad entre el sector privado y el sector público como directivo y consultor. Ha sido ejecutivo de empresas internacionales de servicios de sistemas de información y gerente de organización y sistemas de información en diferentes servicios públicos. Es licenciado en Filosofía y Letras, PDG del IESE y cuerpo técnico de la Seguridad Social. Su último libro es Gestión de proyectos informáticos: métodos, herramientas y casos, publicado por la editorial UOC.

  • Pere Mariné Jové

    Pere Mariné Jové

    Ingeniero superior en Informática (UPC), magíster en Gestión pública (UAB), DEA en Sociedad del conocimiento y de la información (UOC) y PMP del Project Management Institut. Es consultor de estrategias tecnológicas de negocio y de metodologías de dirección de proyectos. Ha trabajado como director de SI y director de proyectos en diversas organizaciones, públicas y privadas, tanto grandes como pequeñas, ha sido consultor y formador de metodologías de dirección de proyectos, externalización y calidad en los últimos años, así como colaborador externo desde el año 2001 en la UOC, en las asignaturas de GOPI, MGPI y GP de las ingenierías de Informática, así como de Gestión de proyectos en el máster TIC, y en la UAB.

PID_00247939
Ninguna parte de esta publicación, incluido el diseño general y la cubierta, puede ser copiada, reproducida, almacenada o transmitida de ninguna forma, ni por ningún medio, sea este eléctrico, químico, mecánico, óptico, grabación, fotocopia, o cualquier otro, sin la previa autorización escrita de los titulares de los derechos.

Introducción

La última etapa del proyecto es la de cierre. Los buenos proyectos acaban de forma controlada, resolviendo los problemas y flecos que surgen inevitablemente en la entrega, retirando ordenadamente los recursos y asegurando la satisfacción del cliente y su capacidad de usar los nuevos sistemas y recuperar los beneficios que aspiraba obtener.
Los proyectos bien hechos acaban también con un montón de papeles. Como dicen Snyder y Parth (2008): "No se acaba el trabajo hasta que no se acaban los papeles". Esto es mucho más sencillo que hacer el proyecto, pero misteriosamente parece que cuesta más.
La etapa de cierre incluye las actividades necesarias para finalizar la gestión del proyecto y completar las obligaciones contenidas en el contrato. Por tanto, incluye la verificación de que éstas se han cumplido y la documentación del proyecto y de los productos o servicios TIC que se han entregado.
Incluye o debe incluir un ejercicio de aprendizaje para la organización y las personas que han participado, la documentación de las lecciones aprendidas y su depósito en alguna clase de almacén de conocimiento para otros que harán proyectos parecidos en algún momento, así como la evaluación de los participantes.
Puede ser también un motivo de celebración y cohesión entre los miembros.
Con frecuencia, después del proyecto se abren nuevas fases u otros proyectos nuevos o sigue un mantenimiento. Por esta razón, cerrar el proyecto adecuadamente cobra aún más importancia.
La figura 1 representa la posición del cierre en el ciclo de gestión del proyecto.
Figura 1. La etapa de cierre en el ciclo de gestión de proyectos
Figura 1. La etapa de cierre en el ciclo de gestión de proyectos
A veces, el proyecto puede concluirse antes de haber conseguido los objetivos que se perseguían por diferentes motivos. Es el caso del cierre abrupto, que examinaremos al final del módulo.
En la mayoría de los casos, el proyecto se acaba, cumple sus etapas y se entregan al cliente los productos o servicios prometidos. Esta es la esencia del proyecto: ¡tiene un final! Y es bueno que así sea.
Pero el objetivo último de los proyectos TIC no es la entrega de determinados resultados de producción, sino ayudar a que los clientes alcancen los objetivos de negocio que se propusieron. La evaluación del proyecto posterior a la implantación permite reconocer si se han alcanzado los beneficios operativos, técnicos, de adopción de la nueva tecnología por los usuarios y, finalmente, los objetivos de negocio que se establecieron al inicio.

Objetivos

Los objetivos principales de este módulo son los siguientes:

  1. Mostrar los principales procesos incluidos en la etapa de cierre del proyecto y los aspectos clave de un cierre exitoso, en particular, la aceptación de los productos y la transición a operaciones.

  2. Explicar las situaciones y momentos que pueden generar un cierre abrupto de un proyecto y cómo deben manejarse.

  3. Explicar la importancia de la evaluación de los resultados del proyecto posteriores a su implantación y mostrar algunas técnicas habituales de evaluación.

1.Cerrar el proyecto. Temas y aspectos clave

Entre los profesionales TIC informáticos y las empresas de servicios que ejecutan proyectos, existen dos tendencias contradictorias y las dos muy peligrosas. Una es pensar que los proyectos no acaban nunca, uno se instala en la organización cliente y siempre hay motivos de mejora, actualización, corrección, etc. del proyecto acabado. Es el mito del proyecto río o del albañil, que se instala en una casa donde "siempre hay algo que hacer". Esto es poco profesional y además no es cierto. Un proyecto acaba cuando se alcanzan los objetivos específicos que se habían establecido, el tiempo y el presupuesto disponible. Si no es así, es que las cosas no se están haciendo bien, ni por el cliente ni por el proveedor.
La otra desviación frecuente es acabar el proyecto antes de tiempo, normalmente por presiones de coste. Entregar, por ejemplo, un software insuficientemente testado, subirlo a producción y salir corriendo. Lo más habitual es que el cliente no acepte la situación, reclame acabar los trabajos, no esté dispuesto a pagar el tiempo extra, el litigio acabe de mala manera y el proveedor no repita con ese cliente.
El cierre es una fase muy importante del proyecto, tanto para el cliente como para el proveedor, el jefe de proyecto y los equipos. Normalmente, se debe asegurar que los productos se han fabricado, instalado o implantado, se han sometido a las pruebas que toque, se debe asegurar la formación de las personas que necesitan usarlos y de los nuevos administradores del sistema, corregidos los errores o, a veces inevitablemente, las situaciones nuevas que sólo se pueden ver con el sistema construido, y proporcionar durante un tiempo cierto nivel de soporte o mantenimiento al cliente y facilitar la transición.
Para el proveedor (interno y externo) y para los equipos, el cierre es una oportunidad de aprendizaje, a través de la evaluación del proyecto y de sus miembros, y de documentar los procesos, resultados y consecuencias de la evaluación, de manera que puedan ser usados en el futuro.
Recordemos una vez más que en proyectos TIC una cosa es el producto o servicio a entregar, que es objeto del proyecto y otra cosa es el proyecto. En el momento del cierre, necesitamos asegurar el cumplimiento de las condiciones de entrega de las dos cosas. Es decir, que el producto funcione según las especificaciones acordadas. Y que el proyecto se haya realizado según el alcance acordado.
Los elementos que consideramos clave para el cierre de un proyecto importante se muestran en la tabla 1.
Tabla 1

Temas clave en el cierre de proyecto

Finalizar el producto o servicio TIC de acuerdo con las especificaciones.

Establecer una lista de las cuestiones pendientes para cerrar el proyecto y gestionar su progreso hasta el punto en el que se pueda considerar el cierre.

Establecer un plan de transición del producto desde el equipo de proyecto hacia sus usuarios y el equipo de mantenimiento asignado, que incluirá las tareas que habrá que realizar tras la entrega y las habilidades que se deberán desarrollar o de las que habrá que disponer, para mantener o mejorar sus resultados.

Asegurar el mantenimiento tras el cierre del proyecto, y diseñar un plan específico que incluya las revisiones y modificaciones previstas, el enfoque de recursos dedicados al mantenimiento y quién ejecutará el plan.

Planificar la reintegración de los miembros del equipo en sus posiciones de línea, y asegurar su reinserción en su lugar de trabajo normal o proponer un nuevo puesto de trabajo en la organización.

Finalizar la documentación de proyecto (y del producto) en el cierre, y cubrir todos los aspectos de diseño, construcción y uso.

Finalizar la formación de usuarios, en tanto que todas las personas y organizaciones afectadas por el nuevo sistema han participado de la formación.

Realizar la valoración final de proyecto en dos ámbitos: cumplimiento de los objetivos propuestos y contraste final del plan con la realización (en términos de alcance, tiempos, recursos y coste final).

Medir el grado de satisfacción del cliente con los resultados producidos por el proyecto.

Medir y valorar la aportación de cada uno de los miembros del equipo según los resultados de las tareas asignadas, las capacidades y habilidades demostradas, el apoyo personal al éxito colectivo, las lecciones aprendidas y las recomendaciones para el plan de carrera profesional.

Realizar el cierre económico del proyecto, firmar el estado de costes finales del proyecto comparado con el presupuesto disponible y proceder al cierre de facturación.

Firmar la aceptación final de todos los entregables del proyecto.

Realizar la entrega formal del producto (entregables de producto y documentación de proyecto) a la organización de línea.

Firmar el cierre contractual del proyecto.

Proceder al inventariado y archivo de todos los documentos y trabajos intermedios.

Identificar nuevos proyectos potenciales a partir de los resultados del proyecto.

Documentar las lecciones aprendidas y la referencia del proyecto para nuevos proyectos.

Fuente: Rodríguez, García, Lamarca (2007), modificado

Toda esta lista puede resumirse, en nuestra opinión, en cuatro objetivos que consideramos básicos:
1) Asegurar la aceptación de los productos.
2) Asegurar la transición del proyecto y los productos al funcionamiento ordinario en producción y explotación de los nuevos sistemas.
3) Cerrar toda la documentación administrativa y los contratos.
4) Documentar las lecciones aprendidas para las personas y la organización.

2.Los procesos de cierre

Formalmente, en PMBOK la fase de cierre no tiene un gran desarrollo, probablemente porque fuera de los sectores TIC y de algún otro las tareas de cierre no tienen una gran complejidad.
El PMBOK reconoce un proceso:
1) La gestión del cierre del proyecto (o fase de proyecto), incluido en el área de conocimiento de "integración", y que incluye básicamente la comprobación de que se han realizado las tareas incluidas en el plan y entregado los productos comprometidos en el alcance.
Los componentes del proceso de cierre, según PMBOK se muestran en la figura 2:
Figura 2. Componentes principales del proceso de cerrar el proyecto o fase
Fuente: PMBOK (2017)
Fuente: PMBOK (2017)
Por nuestra parte, detallaremos en el apartado siguiente un conjunto de actividades que consideramos imprescindibles para el cierre de proyectos TIC.
Los documentos que consideramos básicos en esta etapa son:

  • El acta de aceptación.

  • El Informe de cierre.

3.La gestión del proceso de cierre

En proyectos TIC, el proceso de cierre suele incluir las siguientes actividades:
1) Obtención de la aceptación del cliente, es decir, la verificación y validación del cumplimiento de los requisitos del producto y del proyecto.
2) Transición a explotación, es decir, el traslado del producto a la operación ordinaria de la empresa u organización en la que debe funcionar, una vez estabilizados los productos.
3) Entrega y documentación del proyecto, también llamada cierre administrativo. Consiste en la entrega al cliente y a nuestra organización de la documentación técnica y administrativa de los productos y del proyecto.
4) Informe de post-implantación. Consiste en una reflexión informada y documentada sobre las lecciones aprendidas a lo largo del trabajo y su entrega en una base de datos de conocimiento u otros medios de los que disponga la organización.
Algunos autores recomiendan incluir entre las actividades de cierre una auditoría de calidad, similar a la que se proponía durante la ejecución, en proyectos de cierta envergadura. Ciertamente puede tener más sentido en este momento que durante la ejecución, excepto en proyectos muy grandes o si se han producido circunstancias que lo aconsejan.

3.1.Obtener la aceptación del cliente

En los proyectos TIC, los entregables suelen ser varios y se ejecutan a lo largo del proyecto, en forma de EDT e hitos. Normalmente, en el momento de cierre de cada hito, ya se ha debido producir un proceso de aceptación, que habrá quedado documentado en un acta o, alternativamente, en una reunión del comité de dirección del proyecto.
En el momento de cierre, el jefe de proyecto revisará la documentación y recopilará las actas de aceptación.
Cuando hablamos de aceptación, normalmente hablamos de varias cosas que hemos ido presentando a lo largo de este material. Por un lado, está la aceptación de los productos o servicios TIC, que han sido objeto del contrato o que figuran en el acta de constitución. Estos productos deben cumplir unas especificaciones, estándares o requisitos que pueden validarse a través de una comprobación visual y subjetiva y verificarse a través de diferentes procesos de prueba (testing), inspección o análisis. En sistemas de información, las pruebas de usuario suelen ser las más críticas, porque determinan también la satisfacción subjetiva (la calidad percibida).
Por otro lado está la aceptación del proyecto, que normalmente incluye otra serie de entregables de diferente tipo, la comprobación de la documentación del trabajo y la satisfacción del cliente sobre el proceso de trabajo, sobre "cómo se han hecho las cosas", la calidad de los profesionales, la interacción con su organización, la comunicación y gestión de problemas, el nivel de servicio... y que es en ocasiones muy subjetiva, pero no por eso menos importante.
De todos estos componentes, el que suele ser más complejo, el que mayor número de conflictos produce y, como hemos dicho, la mayor causa de proyectos fracasados, es la validación del alcance, es decir, la comprobación de si los productos satisfacen las necesidades de los clientes o, mejor dicho, lo que los clientes o usuarios tenían en la cabeza. Uno puede estar convencido (y haberlo probado y testado de todas las maneras contra los requisitos documentados) de que ha hecho lo que tenía que hacer o lo que se le había pedido, y sin embargo, el producto puede no satisfacer las necesidades del cliente, una vez tras otra.
Normalmente, entre las necesidades del negocio, el análisis de requisitos, el diseño técnico y la construcción (por poner un ejemplo del ciclo de vida de desarrollo de sistemas de información) se producen una serie de gaps de comunicación y de tiempo, en los que el usuario no suele participar. Por este motivo, hemos recomendado a lo largo de este material una aproximación basada en los objetivos de negocio (gestión de proyecto basada en objetivos, GDPM) más que en la producción de entregables, un mayor énfasis en los aspectos humanos, de organización y comunicación y una mayor involucración de clientes y usuarios a lo largo del proyecto. Gestionar el alcance con rigor es ciertamente crítico y PMBOK proporciona herramientas exhaustivas para conseguirlo. Disponer de estándares de calidad y cumplimiento, como los que proporcionan algunas de las metodologías actuales, es un paso muy importante. Pero nada de esto resuelve el gap entre las expectativas del cliente y el producto entregado.
Algo que está ayudando en los proyectos de IT y multimedia de cierto volumen, aunque puede encarecer el producto, es la presentación de prototipos en pre-producción o la descomposición del proyecto, pactada con el cliente en varias entregas o releases parciales. Esto permite visualizar al usuario de forma anticipada lo que obtendrá o no obtendrá con el sistema en un formato casi final. También algunas herramientas y lenguajes de desarrollo (open source, visual basic, html), o los productos estándar parametrizables permiten obtener más rápidamente productos que se pueden enseñar al usuario y la involucración del usuario en el proceso de diseño y construcción (o parametrización).
El documento básico que certifica la aceptación del entregable o entregables del proyecto es el Acta de aceptación. Un ejemplo de formulario se muestra en la figura 3.
Figura 3. Ejemplo de formulario de Acta de aceptación
Figura 3. Ejemplo de formulario de Acta de aceptación
76527_m7_04.gif

3.2.La transición a operación

Una vez realizada la validación y aceptación de los productos, el cliente debería hacerse cargo de su gestión y mantenimiento y los usuarios deberían sustituir sus sistemas anteriores con un apoyo limitado. En proyectos TIC, en especial los de sistemas de información y algunos de telecomunicaciones y multimedia, las cosas no son tan sencillas.
Ocurre que de la misma manera que resulta costoso obtener la validación de los productos y evitar la frustración de los usuarios, resulta complicado que la organización funcional y de IT del cliente se haga cargo del producto y se puedan retirar los equipos y dar por finalizado el proyecto. El apoyo a los usuarios nunca parece suficiente y la corrección de incidencias o reparación de errores parece no acabar nunca.
Es cierto que los planes y presupuestos de proyectos tienden a minusvalorar el esfuerzo que requiere la transición y no se suele disponer de los recursos y herramientas adecuadas o no se está dispuesto a pagar por ellos. Abunda la idea (entre clientes y proveedores) de que una vez construidos o instalados los sistemas, el trabajo está acabado. En realidad, el trabajo acaba cuando los usuarios (internos o externos a la organización) utilizan los nuevos sistemas masiva y satisfactoriamente y la organización de IT ha asumido su mantenimiento ordinario. No antes.
A veces, este bloqueo que se produce para transferir la "propiedad" del proyecto a la organización lo causa el propio proveedor, que ve una oportunidad comercial en mantener la dependencia del cliente con relación a sus servicios.
La mayoría de las soluciones para estos problemas se tienen que anticipar mucho antes del cierre, a ser posible en el propio documento de alcance y en el contrato, en su caso. Allí debe determinarse durante cuánto tiempo se mantendrá el equipo de soporte (funcional y técnico), qué nivel de incidencias se considera aceptable, qué formación y manuales deben recibir unos y otros, cuál será el plan de mantenimiento futuro. También vale la pena, entre el conjunto de pruebas (cuya importancia no nos cansaremos de enfatizar) incluir una prueba de disponibilidad operativa a la que debe asistir el cliente o sponsor y las condiciones para su realización.
Finalmente, hemos observado que, en bastantes ocasiones, lo que bloquea la transición (igual que lo dificultaba la validación de productos) ha sido una insuficiente gestión de las expectativas de interesados o, aún más, una insuficiente gestión del cambio, en el sentido en el que la definimos en el módulo "El lado humano de la gestión de proyectos", es decir, las cosas que tienen que pasar en el cliente para que el proyecto tenga éxito. Dicho de otro modo, la separación entre el mundo del proyecto y el mundo del cliente es casi siempre artificial, como lo es la separación ente proyectos "tecnológicos" y proyectos "organizativos". Para que un proyecto tecnológico tenga éxito se requieren casi siempre cambios en la organización, en los procesos de trabajo, en los roles y responsabilidades, en las habilidades y capacidades del personal del cliente, en sus sistemas de recompensa y un proceso de gestión de todo esto que sea robusto, consistente y efectivo. Eso es la gestión del cambio.
Por desgracia, pocas organizaciones invierten lo suficiente en gestión del cambio a la hora de abordar un proyecto TIC y pocos proveedores están preparados para proporcionar servicios de calidad en este ámbito que ayuden al cliente de forma efectiva. Unos y otros suelen llamar gestión del cambio a cosas como sesiones de formación, soporte a usuarios y confección de manuales.

3.3.La documentación de cierre

Cerrar y documentar un proyecto no es complicado si la documentación se ha preparado correctamente a lo largo de todo el proyecto. Si no, suele ser un quebradero de cabeza, en especial porque el jefe de proyecto y los equipos acostumbran a estar ya asignados a otro trabajo o a la preparación de ofertas y esto es lo último que pueden y quieren hacer.
Mantener la documentación completa y al día es un elemento crítico que posibilita la auditoría y revisión de los resultados intermedios por personas externas al equipo de proyecto y asegura la calidad de la ejecución. La documentación de proyecto debería ser planificada al inicio del proyecto, en el mismo momento en el que se planifican los entregables.
La documentación tiene dos aspectos:
1) La documentación administrativa del proyecto, compuesta por todos los informes, actas, contratos y cualquier documento que justifique las decisiones tomadas (lo que podríamos llamar, con Snyder y Parth (2008), cierre administrativo).
2) La documentación técnica de los entregables o productos TIC, que incluye la documentación de diseño (funcional y técnico), la documentación de operaciones, la documentación de uso y el plan de mantenimiento.
La documentación debe permitir al cliente hacerse cargo del proyecto y de los productos obtenidos, operarlos normalmente en producción y mantenerlos. Si no es así, la documentación no es válida ni útil. Por eso la entrega de esta documentación es un acto formal de transferencia al cliente de la responsabilidad sobre el resultado.
Con relación al proyecto, los documentos mínimos que debe incluir la documentación de cierre se muestran en la tabla 2.
Tabla 2

Documento de cierre

Acta de constitución del proyecto

Plan de proyecto:

  • Definición detallada del alcance

  • Calendario base

  • Presupuesto base

  • Plan de riesgos

  • Plan de calidad

Organización del proyecto

Plan de pruebas y resultados

Informes de progreso

Peticiones de cambios

Informes de aprobación de cambios

Presentaciones e informes significativos del proyecto

Correos y correspondencia relevante

Contratos

Fuente: Snyder y Parth (2008), modificado

Si somos una empresa externa, tenemos que guardar copia de toda la documentación en una base de datos propia.
Un ejemplo de formulario de cierre se presenta en la figura 4.
Figura 4. Ejemplo de formulario de Informe de cierre
Figura 4. Ejemplo de formulario de Informe de cierre
76527_m7_06.gif

3.4.Informe de post-implantación

La valoración del proyecto es una de las actividades cruciales del cierre de un proyecto, aunque objetivamente los resultados finales de negocio y operativos del proyecto queden sujetos a una revisión posterior cuando el nuevo sistema o aplicación ya lleve un tiempo funcionando desde su puesta en producción.
En el momento del cierre, el proyecto se considera exitoso si se han cumplido las condiciones de alcance, calidad, tiempo y coste que se establecieron en el momento de la aprobación del proyecto y si los entregables han sido aceptados por el cliente. Pero, como hemos dicho, el cierre del proyecto es también un momento de aprendizaje para el cliente, para el equipo de proyecto y para sus miembros.
Este objetivo incluye dos tipos de actividades:
1) La recopilación de lecciones aprendidas y su inclusión en una base de datos de conocimiento.
2) La evaluación de los participantes y la formulación de recomendaciones de desarrollo.
3.4.1.Lecciones aprendidas
Una de las actividades principales de la fase de cierre es la recopilación, almacenamiento y utilización del conocimiento obtenido en el proyecto para nuevos proyectos. Los proyectos de la organización son una parte central de lo que ahora se denomina gestión del conocimiento.
Recordemos que la gestión del conocimiento es un proceso que forma parte de la ejecución del proyecto, en el sentido de que el jefe de proyecto debe estar atento, en el día a día, a lo que sabe la organización y se puede usar, y todo lo que aprende en el proyecto en curso y se podrá utilizar en el futuro. La utilización del conocimiento recabado en la gestión de un proyecto puede apoyar todas las fases de un nuevo proyecto, desde la aprobación y definición hasta el cierre. En el ámbito comercial, la inclusión de la referencia "inteligente" del proyecto realizado en una propuesta puede hacer que sea la seleccionada por el cliente entre varios competidores, ya que demuestra una experiencia elaborada que puede ser muy útil en el transcurso del nuevo proyecto.
El conocimiento que conviene recopilar y almacenar tras la finalización del proyecto se puede desglosar en los siguientes bloques de información:

  • La descripción del proyecto según los objetivos de negocio, el alcance, el enfoque y los resultados obtenidos.

  • La clasificación de los proyectos en éxitos y fracasos, y el conocimiento de las razones de los mismos (condiciones externas, efectividad en la implantación, etc.).

  • La elaboración de recomendaciones para evitar los fracasos y asegurar los éxitos.

  • Los indicadores de necesidades de tiempos, recursos y presupuesto para trabajos específicos, que puedan aprovecharse en proyectos de naturaleza similar.

  • La documentación de materiales relevantes del proyecto a los cuales se puede acceder.

La información del conocimiento del proyecto, una vez finalizado, puede almacenarse en una base de datos de proyectos a la que pueden acceder dentro de la organización personas que no tuvieron nada que ver con el proyecto. En la tabla 3 se muestra una estructura de base de datos de conocimiento del proyecto.
Tabla 3

Elementos de la base de datos de conocimiento del proyecto

1) Descripción del proyecto

  • Beneficios para el negocio

  • Objetivos del proyecto

  • Alcance del proyecto

  • Enfoque del trabajo: hitos y entregables

  • Organización del proyecto

2) Valoración del proyecto

  • Razones de éxito o fracaso

  • Lecciones aprendidas

3) Indicadores de gestión del proyecto

  • Tiempo de realización

  • Recursos utilizados

  • Costes incurridos

4) Índice de la documentación disponible

  • Tipo de documento

  • Referencia de documentos disponibles

  • Mecanismos de acceso

5) Personas de contacto del proyecto

  • Nombre

  • Vías de contacto

6) Bases de datos en las que hay información del proyecto

7) Administración de la base de datos

Fuente: Rodríguez, García, Lamarca (2007)

La gestión del conocimiento adquirido en los proyectos es crucial en las empresas de servicios y productos TIC y en la gestión de proyectos. En palabras de Lew Platt, que fue presidente de Hewlett Packard, citadas por Snyder y Parth (2008): "Si HP supiera lo que sabe HP, seríamos tres veces más rentables".
3.4.2.Evaluación del equipo
Otro ámbito de aprendizaje aún mayor que el anterior es la evaluación de los miembros del equipo. El proyecto, en organizaciones orientadas por proyectos o en las empresas convencionales, es una oportunidad de desarrollo y crecimiento personal y profesional, de aprendizaje de nuevas habilidades técnicas y de trabajo en equipo, y también de las habilidades específicas de la gestión de proyectos. En muchos casos, una persona se dedicará única o principalmente a un proyecto, durante una larga temporada, a veces años.
En el inicio del trabajo, los objetivos de ejecución del trabajo pero también los objetivos de crecimiento individual deberían ser establecidos por el responsable de línea, por la dirección de recursos humanos, por el jefe de proyecto o, aún mejor, por una combinación de los tres. También se debería efectuar una realimentación rápida y directa a lo largo de la realización del trabajo por el jefe de proyecto o, en proyectos muy grandes, por el supervisor de un área determinada del trabajo. Y recibir una evaluación al final del proyecto, que se transmita también a su responsable de línea (al departamento o al staff al que se reintegra, en su caso), a la dirección de personal de la compañía y a su próximo jefe de proyecto.
En las empresas de servicios profesionales y servicios tecnológicos, esta evaluación es el principal componente del desarrollo de la carrera y de la retribución, al menos, variable.

3.5.Celebración

Aunque parece exótica su inclusión en un manual y su estudio en una asignatura universitaria, coincidimos con Rodríguez, García y Lamarca (2007) en que los proyectos se deben celebrar cuando acaban.
Siempre que sea posible, debe celebrarse el enorme esfuerzo personal, económico y organizativo; debe reconocerse públicamente el trabajo bien hecho, y se debe compartir con el equipo y con el cliente. Es una oportunidad de cohesión para las personas y las empresas.
La celebración
"La celebración es un reconocimiento del trabajo bien hecho, de las relaciones personales y profesionales que se han construido y de un producto o servicio que quedará en la organización para mejorar sus resultados y su forma de trabajar. Finalmente, es una invitación para nuevos proyectos exitosos y para extender la cultura de proyecto dentro de la empresa.
Existe un nivel de celebración formal en el ámbito de la empresa o empresas participantes y de los equipos de proyecto, incluyendo el personal directivo. Existen otras oportunidades y formas de celebración que dejamos a la imaginación del lector."
Fuente: Rodríguez, García y Lamarca (2007, pág. 196)

4.Cierre abrupto del proyecto

En general, los proyectos finalizan cuando han tenido éxito o cuando han fracasado. El éxito implica que se han cumplido los objetivos marcados en tiempo, resultados y coste. El fracaso se da cuando se han sobrepasado las expectativas de tiempo y coste, cuando los resultados no son tan satisfactorios como se esperaba o cuando los objetivos ya no tienen sentido empresarial en un contexto o situación que ha cambiado.
Cerrar un proyecto antes de su finalización es la decisión más dura y difícil de la gestión de proyectos.
Sea como sea, muchas veces los proyectos terminan antes de cumplir todas las actividades e hitos que se habían marcado. Las principales razones para la terminación abrupta de proyectos se indican en la tabla 4.
Tabla 4

Razones para la terminación abrupta de un proyecto

  • El proyecto sobrepasa los objetivos de coste y tiempo previstos para los hitos.

  • El proyecto ya no tiene un encaje estratégico u operativo en el futuro de la organización.

  • La estrategia de la organización ha cambiado y se ha reducido la necesidad de la solución que se proponía.

  • El principal impulsor (patrocinador) del proyecto ya no está, y los resultados del proyecto son ahora menos prioritarios.

  • Existe un deseo de reducir los recursos destinados a un proyecto y destinarlos a otro.

  • El tiempo de puesta en el mercado (time to market) se ha retrasado u otros competidores han actuado más rápido y han reducido el impacto del proyecto en el mercado.

  • Los adversarios del proyecto dentro de la organización han ganado posiciones y han creado una corriente de opinión negativa.

Fuente: Rodríguez, García y Lamarca (2007)

Muchas de estas razones tienen una lógica de negocio o de proyecto impecable y que no debería admitir grandes réplicas. Sin embargo, pocas cosas son tan difíciles en grandes proyectos TIC como cerrar un proyecto una vez se ha comenzado (Royer). Muchas veces se produce una tendencia psicológica a continuar destinando tiempo y esfuerzos a proyectos que han dejado de tener sentido. Entre las razones principales de este fenómeno, se encuentra la tendencia a ver las desviaciones de proyectos como una situación de normalidad, la tendencia de los gerentes a perseverar y minimizar los obstáculos que se afrontan, la tendencia a no revisar y gestionar de manera flexible los objetivos del proyecto en función de las vicisitudes durante su ejecución, la tendencia a no aceptar que posiblemente los recursos destinados no tendrán ningún fruto y el miedo a perder la posición y el reconocimiento de los que se ha dispuesto dentro de la organización.
Se producen diferentes estados psicológicos de entusiasmo colectivo, que llevan a minimizar los problemas y a exagerar los progresos y los beneficios potenciales.
También se entrelazan en ocasiones intereses comerciales, de poder o de influencia de alguna de las partes, o el miedo a perderlos.
Por este motivo, siempre es importante revisar durante todo el periodo de ejecución que los objetivos del proyecto siguen siendo realistas, que los resultados seguirán dando los beneficios que se esperaban para la organización, que el proyecto continúa siendo prioritario y alineado con el futuro de la organización y que los beneficios esperados siguen justificando los esfuerzos de tiempo y recursos dispuestos y tener la claridad, voluntad y decisión para detener un proyecto si es necesario.
Recordemos de nuevo el enfoque de gestión de proyectos orientados a objetivos: un proyecto no consiste en la producción de una serie de entregables, sino en la obtención de una serie de objetivos del cliente.
Se puede pasar a la historia por acabar un proyecto exitoso, pero raras veces por cerrar un proyecto fracasado. Isabelle Royes, profesora del INSEAD, ha sugerido que, de la misma manera que hay un jefe o champion de proyecto, los proyectos complicados o que se complican deberían tener una contrafigura, prestigiada y prestigiosa dentro de la organización, encargada de analizar y facilitar la salida (un exit champion) de un proyecto fracasado o ruinoso. El texto siguiente muestra algunos consejos para evitar estas situaciones.
Cómo evitar los peligros de la fe ciega

  • ¡Cuidado con los entusiastas! Un buen equipo tiene una sabia combinación de entusiastas, realistas y acaso también pesimistas, o al menos escépticos. Identificar pronto la emergencia y el desarrollo de la cultura de "fe ciega" dentro del proyecto o de la empresa.

  • Establecer un sistema de alarma anticipada. El trabajo por subproyectos e hitos permite, si se hace correctamente, identificar en cada fase del trabajo los signos de incumplimiento o desviaciones muy significativas. Si éstas alcanzan una proporción en tiempo, calidad o coste significativos, si constituyen una tendencia, si se sobrepasan los niveles de riesgo y contingencia autorizados o si no se activan los planes de contingencia... todos estos son motivos de alarma.

  • Establecer un plan de salida. No basta realizar preguntas o registrar los motivos de alarma, se trata de recoger evidencias y ponerlas de manera sensible pero clara delante de los órganos de dirección del proyecto o, si no es suficiente, de la gerencia de la empresa, y a continuación elaborar y ejecutar un plan de salida.

  • Poner un champion, o responsable del plan de salida, dotado de gran credibilidad interna, capaz de enfrentarse al nivel de hostilidad que se producirá en la organización y de afrontarlo sin miedo. El responsable de la salida no es un crítico o un intelectual, es un ejecutivo que se pone manos a la obra para cerrar un proyecto fallido.

Fuente: I. Royer (2003). "Why Bad Projects are So Hard to Kill". Harvard Business Review (vol. 81, núm. 2, págs. 48-56). Boston.
A veces, se puede decidir una suspensión o cierre temporal.
Desengañémonos. Si un proyecto va mal y no se puede enderezar razonablemente, lo más sensato y responsable es liquidarlo.
En cuanto a los procesos de gestión del cierre no son muy distintos de los que hemos analizado para el cierre ordinario. Incluso recomendamos un mayor cuidado en su preparación, ya que por la delicadeza y sensibilidad de la situación, las situaciones de cierre abrupto están sujetas a tensiones y litigios que deben anticiparse con una buena comunicación y deben atenderse con un conjunto de procesos y documentos preparados rigurosamente:
1) La entrega y documentación del proyecto, tanto técnica como administrativa.
2) El informe de post-implantación, incluyendo un ejercicio reflexionado de lecciones aprendidas.
A veces puede ser recomendable elaborar preventivamente una auditoría de calidad y una auditoría técnica de los entregables producidos o del estado de desarrollo técnico del trabajo y de su documentación.

5.Evaluación de un proyecto después del cierre

Los resultados últimos del proyecto no se pueden valorar sino algún tiempo después de su finalización, y no forman parte propiamente del proyecto ni del equipo que los ha realizado. Los valora el cliente, cuando lo hace, o evaluadores o investigadores externos.
La cultura de evaluación no está muy extendida en las empresas y organizaciones (salvo en algunos sectores como la sanidad o la universidad, aunque tampoco se suelen evaluar las actividades de gestión en sentido estricto).
Las empresas externas que monitorizan el resultado de los proyectos a través de encuestas, como la consultora Standish Group en Estados Unidos, suelen presentar resultados desoladores. Apenas un tercio de los proyectos TIC acostumbran a obtener beneficios netos y aún menos cumplen las promesas económicas de sus promotores. Por no hablar de los proyectos fracasados, cuestionados o desviados significativamente en calidad, tiempo y coste, que superan las dos terceras partes en todas las revisiones que realizan diferentes estudios externos. Esto ha sembrado la desconfianza entre empresarios y directores generales sobre la inversión en TIC frente a otras inversiones en capital.
Aparte de los métodos de encuesta, que tienden a ser superficiales, la evaluación del éxito de un proyecto debería medirse bajo diferentes parámetros, desde los más técnicos y de operación hasta los más estratégicos y de negocio. Rodríguez, García y Lamarca (2007), proponen la siguiente clasificación:

  • Resultados de operación.

  • Resultados de adopción ("de aceptación", para estos autores).

  • Resultados técnicos.

  • Resultados de negocio.

En la medición de los resultados de la operación de un sistema de información, se monitorizan resultados que pueden tener un efecto directo o indirecto sobre los resultados de negocio de la compañía y que, por lo tanto, nunca se pueden desvincular de los indicadores descritos con anterioridad.
Gybson y Hammer reunieron en un esquema los dominios de beneficios y beneficiarios de un sistema de información. Este esquema se puede visualizar en la tabla 5. Los indicadores de operación suelen medir las eficacias y eficiencias operativas del nuevo sistema sobre cada uno de los beneficiarios que aparecen en la tabla. Ejemplos de esto pueden ser los nuevos tiempos de realización de las tareas, los errores en la entrada y tratamiento de los datos en el sistema, los tiempos de servicio a un cliente, etc.
Tabla 5. Matriz de beneficio / beneficiario de los sistemas de información

Beneficio

Beneficiario

 

Individuos

Departamentos funcionales

Organización

Eficacia

Mejoras en el trabajo

Mejoras funcionales

Mejoras en el servicio

Efectividad (transformación)

Extensión de los diferentes roles

Redefiniciones funcionales

Innovaciones en el producto

Pastor, sobre una adaptación de Gibson y Hammer

Una de las razones principales de fracaso en los proyectos de sistemas de información es la resistencia de los usuarios al cambio. Las nuevas tecnologías afectan directamente a los métodos, procedimientos y relaciones personales. Una resistencia al cambio por parte de los usuarios en el uso de la nueva aplicación puede tener consecuencias nefastas en la operación del sistema y en los resultados de negocio que se esperan del mismo. Una solución TIC no puede considerarse exitosa si quienes tienen que utilizarla (usuarios internos o externos a la organización) no la usan. Esto hace que cada vez adquieran más importancia los sistemas de monitorización de la aceptación y uso de la nueva aplicación (los resultados de adopción de la tecnología), así como los programas de gestión del cambio de los que hablaremos en el módulo "El lado humano de la gestión de proyectos".
En la medición de la aceptación del nuevo sistema por parte de los usuarios, se pueden utilizar indicadores objetivos de medición –por ejemplo, el tiempo de utilización de la nueva aplicación, el porcentaje de utilización de la misma en los procesos de gestión, el porcentaje de usuarios que la utilizan habitualmente, etc.– e indicadores más subjetivos de medición –por ejemplo, el índice de satisfacción con la nueva aplicación, la preferencia respecto al sistema anterior, las sugerencias de modificación, etc.
Por ejemplo, uno de los proyectos del Plan estratégico de sistemas de información del Ayuntamiento de Barcelona era la implantación de una plataforma móvil para la Guardia Urbana basada en dispositivos móviles, que permite a los agentes acceder a información corporativa, proporcionar información al ciudadano, realizar trámites y poner denuncias. En el momento de su puesta en marcha, se diseñó un sistema de información para monitorizar día a día el nivel de utilización, el tipo de utilización, averías, mal uso, etc., para identificar sus causas y establecer acciones de corrección. El seguimiento del nivel de adopción y el conjunto de acciones simultáneas permitieron un nivel de utilización superior al 70% de los usuarios en el 60% de su trabajo cotidiano, en los tres meses siguientes a su puesta en marcha, dentro de un colectivo de edad madura y reactivo a la tecnología.
Durante el periodo de post-implantación del sistema, se siguen haciendo controles técnicos, como por ejemplo los tiempos de respuesta del servidor, pruebas de carga y estrés, etc. Otros elementos a considerar son los problemas aparecidos durante el mantenimiento correctivo y evolutivo o la escalabilidad de la solución, es decir, su capacidad en el tiempo de adaptarse y evolucionar con mayores cargas de trabajo, nuevos requisitos o necesidades de integración en nuevos sistemas más complejos. Estos aspectos nos permiten evaluar los resultados técnicos de la solución TIC.

5.1.Los resultados del negocio

Evaluar los resultados de negocio de un proyecto es mucho más complicado. En principio, la evaluación debería hacerse de forma parecida a los análisis que se hicieron (o se debieron haber hecho) en el momento de su aprobación y compararse con los mismos, y examinar también en qué medida los riesgos, cambios y la gestión de proyecto en su conjunto han modificado la valoración inicial, o lo han hecho circunstancias relacionadas con la implantación o post-implantación, como los procedimientos operativos, la adopción por los usuarios o el rendimiento de las plataformas o las comunicaciones.
Finalmente, la empresa ha podido recibir beneficios o perjuicios intangibles, difíciles de reflejar en la valoración cuantitativa.
Para calcular los beneficios económicos de un proyecto, se debe monitorizar el beneficio real del proyecto (ahorros de coste e ingresos suplementarios generados) a lo largo de toda la vida del sistema o aplicación implementado, y compararlo con el coste de inversión que supuso su construcción y el coste de mantenimiento y operación posterior. Sin embargo, una posible vía de análisis previo de la rentabilidad es analizar en un primer periodo lo suficientemente significativo los resultados del proyecto, extrapolarlos a lo largo del ciclo de vida de la aplicación y calcular el valor del proyecto mediante la utilización de fórmulas como las del valor actual neto (net present value) u otros indicadores financieros.
En todo caso, el indicador último del éxito del proyecto no es la obtención de beneficios o un buen retorno en la inversión, sino el balance positivo de este retorno respecto a las expectativas y los objetivos fijados al principio del proyecto.
Proyectos tecnológicos y proyectos de negocio
Una de las conclusiones que se extraen de los proyectos de negocio modernos es que, en cualquier sector –petróleo, construcción, producto farmacéutico, producto de consumo, servicios financieros, etc.–, la tecnología ha dejado de ser parte del problema para ser parte de la solución. Una segunda conclusión es que la solución tecnológica es parte de la solución, pero sólo una parte de la misma (Feeny). Esto hace que un proyecto informático sólo pueda medirse muchas veces en los términos más amplios del conjunto de la solución empresarial propuesta, que incluye desde el diseño de procesos y el diseño de la nueva organización, hasta la implantación del nuevo sistema de información. Como hemos venido señalando desde el comienzo, casi todos los proyectos informáticos son actualmente proyectos "mixtos".
Fuente: Rodríguez, García y Lamarca (2007, pág. 198)

6.Resumen

La última etapa del proyecto es la de cierre. Los buenos proyectos acaban de forma controlada, resolviendo los problemas y flecos que surgen inevitablemente en la entrega, retirando ordenadamente los recursos y asegurando la satisfacción del cliente y su capacidad de usar los nuevos sistemas y recuperar los beneficios que se aspiraba obtener.
En la etapa de cierre, aspiramos a cumplir cuatro objetivos:
1) Asegurar la aceptación de los productos.
2) Asegurar la transición del proyecto y los productos al funcionamiento ordinario en explotación de los nuevos sistemas.
3) Cerrar toda la documentación administrativa y los contratos.
4) Documentar las lecciones aprendidas para las personas y la organización.
El proceso que comprende la gestión del cierre del proyecto es únicamente:
a) La gestión del cierre del proyecto (o fase de proyecto), incluido en el área de conocimiento de "integración", y que incluye básicamente la comprobación de que se han realizado las tareas incluidas en el plan y entregado los productos comprometidos en el alcance.
Los principales documentos que se obtienen en esta etapa son:

  • El acta de aceptación.

  • El Informe de cierre.

La gestión del cierre comprende la validación, verificación y aceptación por el cliente de los productos entregados y del proyecto en su conjunto. Deben cuidarse especialmente las pruebas de usuario y las pruebas de disponibilidad operativa.
También se incluye en esta etapa la gestión de la transición entre el proyecto y las operaciones ordinarias de la empresa, tanto a nivel funcional (la operación de los sistemas por los usuarios de negocio o los usuarios externos) como a nivel técnico (la explotación y mantenimiento de la solución por parte del departamento de IT de la organización). Es una operación que debe planificarse y gestionarse cuidadosamente, incluidas acciones de lo que se llama la "gestión del cambio".
En la entrega y cierre del proyecto, debe recogerse o producirse gran cantidad de documentación, tanto administrativa como técnica. Además de la documentación del proyecto, deben proporcionarse al cliente documentación técnica, operativa y de uso y un plan de mantenimiento de la solución TIC implantada.
El momento del cierre es un momento de aprendizaje y para compartir las lecciones aprendidas para su uso futuro por parte de otras personas. Es bueno dedicar tiempo a preparar un buen informe de post-implantación y disponer de una buena base de datos de conocimiento, que otras personas puedan usar provechosamente en el futuro.
Es también momento para la evaluación de los participantes y análisis de sus oportunidades de mejora y desarrollo profesional.
Finalmente, es momento de celebración y reconocimiento del esfuerzo de todos.
En ocasiones, un proyecto debe de suspenderse temporalmente o de terminarse antes de cumplir sus objetivos, por diferentes causas. Esto no es fácil de reconocer y de aceptar, pero es lo más inteligente y sensato. En esos casos, deben desplegarse estrategias de alarma anticipada para detectar estas situaciones, prever y gestionar la salida y realizar todos los procesos de cierre aún con más rigor de lo habitual.
Sólo es posible valorar el verdadero éxito de un proyecto con el paso del tiempo, si se han aprovechado las ventajas operativas, los usuarios han adoptado plenamente la nueva tecnología y se han realizado los beneficios de negocio que se pretendían conseguir. Existen métricas y técnicas de evaluación para medir estos resultados, aunque normalmente quedan fuera del alcance y el tiempo de duración del proyecto.