proyecto cierre del - gitlabuoc.gitlab.io/2015/gestion proyectos/modulo 7.pdf1. mostrar los...
TRANSCRIPT
Cierre delproyecto José Ramón RodríguezPere Mariné Jové PID_00153558
© FUOC • PID_00153558 Cierre del proyecto
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 éste eléctrico,químico, mecánico, óptico, grabación, fotocopia, o cualquier otro, sin la previa autorización escritade los titulares del copyright.
© FUOC • PID_00153558 Cierre del proyecto
Índice
Introducción............................................................................................... 5
Objetivos....................................................................................................... 7
1. Cerrar el proyecto. Temas y aspectos clave................................. 9
2. Los procesos de cierre....................................................................... 12
3. La gestión del proceso de cierre.................................................... 13
3.1. Obtener la aceptación del cliente ............................................... 13
3.2. La transición a operación ........................................................... 16
3.3. La documentación de cierre ....................................................... 17
3.4. Informe de post-implantación .................................................... 21
3.4.1. Lecciones aprendidas ..................................................... 22
3.4.2. Evaluación del equipo ................................................... 23
3.5. Celebración .................................................................................. 24
4. Cierre abrupto del proyecto........................................................... 25
5. Cierre de los contratos..................................................................... 28
6. Evaluación de un proyecto después del cierre........................... 29
6.1. Los resultados del negocio .......................................................... 31
7. Resumen................................................................................................ 33
© FUOC • PID_00153558 5 Cierre del proyecto
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 inevitable-
mente 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 misterio-
samente 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 cerrar los contratos 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 adecua-
damente 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
© FUOC • PID_00153558 6 Cierre del proyecto
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 en-
tregan 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 objeti-
vos 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.
© FUOC • PID_00153558 7 Cierre del proyecto
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 pos-
teriores a su implantación y mostrar algunas técnicas habituales de eva-
luación.
© FUOC • PID_00153558 9 Cierre del proyecto
1. Cerrar el proyecto. Temas y aspectos clave
Entre los profesionales TIC informáticos y las empresas de servicios que ejecu-
tan proyectos, existen dos tendencias contradictorias y las dos muy peligrosas.
Una es pensar que los proyectos no acaban nunca, uno se instala en la orga-
nizació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 ins-
tala 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, normal-
mente por presiones de coste. Entregar, por ejemplo, un software insuficien-
temente 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é dis-
puesto 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 perso-
nas que necesitan usarlos y de los nuevos administradores del sistema, corre-
gidos 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 opor-
tunidad de aprendizaje, a través de la evaluación del proyecto y de sus miem-
bros, y de documentar los procesos, resultados y consecuencias de la evalua-
ció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 pro-
yecto. 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 ha-
ya realizado según el alcance acordado.
© FUOC • PID_00153558 10 Cierre del proyecto
Los elementos que consideramos clave para el cierre de un proyecto impor-
tante 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 ges-tionar 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 ha-cia sus usuarios y el equipo de mantenimiento asignado, que incluirá las tareasque habrá que realizar tras la entrega y las habilidades que se deberán desarro-llar 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 espe-cífico que incluya las revisiones y modificaciones previstas, el enfoque de re-cursos 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 unnuevo puesto de trabajo en la organización.
Finalizar la documentación de proyecto (y del producto) en el cierre, y cubrirtodos los aspectos de diseño, construcción y uso.
Finalizar la formación de usuarios, en tanto que todas las personas y organiza-ciones afectadas por el nuevo sistema han participado de la formación.
Realizar la valoración final de proyecto en dos ámbitos: cumplimiento de losobjetivos propuestos y contraste final del plan con la realización (en términosde alcance, tiempos, recursos y coste final).
Medir el grado de satisfacción del cliente con los resultados producidos por elproyecto.
Medir y valorar la aportación de cada uno de los miembros del equipo segúnlos resultados de las tareas asignadas, las capacidades y habilidades demostra-das, el apoyo personal al éxito colectivo, las lecciones aprendidas y las reco-mendaciones para el plan de carrera profesional.
Realizar el cierre económico del proyecto, firmar el estado de costes finales delproyecto comparado con el presupuesto disponible y proceder al cierre de fac-turación.
Firmar la aceptación final de todos los entregables del proyecto.
Realizar la entrega formal del producto (entregables de producto y documen-tació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 inter-medios.
Identificar nuevos proyectos potenciales a partir de los resultados del proyecto.
Documentar las lecciones aprendidas y la referencia del proyecto para nuevosproyectos.
Fuente: Rodríguez, García, Lamarca (2007), modificado
© FUOC • PID_00153558 11 Cierre del proyecto
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 organi-
zación.
© FUOC • PID_00153558 12 Cierre del proyecto
2. Los procesos de cierre
Formalmente, en PMBOK la fase de cierre no tiene un gran desarrollo, proba-
blemente porque fuera de los sectores TIC y de algún otro las tareas de cierre
no tienen una gran complejidad.
El PMBOK reconoce dos procesos o grupos de procesos:
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.
2) El cierre de los contratos, de acuerdo con las condiciones pactadas y
la resolución, en su caso, de las reclamaciones o litigios pendientes.
Los componentes del proceso de cierre, según PMBOK (2008) se muestran en
la figura 2:
Figura 2. Componentes del proceso de cierre
Fuente: PMBOK (2008)
Por nuestra parte, detallaremos en el apartado siguiente un conjunto de acti-
vidades 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.
© FUOC • PID_00153558 13 Cierre del proyecto
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 es-
tabilizados los productos.
3) Entrega y documentación del proyecto, también llamada cierre administra-
tivo. Consiste en la entrega al cliente y a nuestra organización de la documen-
tación técnica y administrativa de los productos y del proyecto.
4) Informe de post-implantación. Consiste en una reflexión informada y do-
cumentada 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íade calidad, similar a la que se proponía durante la ejecución, en proyectos de ciertaenvergadura. Ciertamente puede tener más sentido en este momento que durante laejecución, excepto en proyectos muy grandes o si se han producido circunstanciasque 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 mo-
mento de cierre de cada hito, ya se ha debido producir un proceso de
aceptación, que habrá quedado documentado en un acta o, alternativa-
mente, 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 re-
copilará 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 acep-
tació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
Nota
Seguimos aquí los manualesde Snyder y Parth (2008) yRodríguez, García y Lamarca(2007).
© FUOC • PID_00153558 14 Cierre del proyecto
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 satisfac-
ció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 co-
municació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 involucra-
ció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 volu-
men, 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, vi-
sual basic, html), o los productos estándar parametrizables permiten obtener
más rápidamente productos que se pueden enseñar al usuario y la involucra-
ción del usuario en el proceso de diseño y construcción (o parametrización).
© FUOC • PID_00153558 15 Cierre del proyecto
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
© FUOC • PID_00153558 16 Cierre del proyecto
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 de-
berían sustituir sus sistemas anteriores con un apoyo limitado. En pro-
yectos TIC, en especial los de sistemas de información y algunos de te-
lecomunicaciones 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 manteni-
miento ordinario. No antes.
© FUOC • PID_00153558 17 Cierre del proyecto
A veces, este bloqueo que se produce para transferir la "propiedad" del proyec-
to a la organización lo causa el propio proveedor, que ve una oportunidad co-
mercial 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 mu-
cho 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 man-
tendrá 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 con-
junto de pruebas (cuya importancia no nos cansaremos de enfatizar) incluir
una prueba de disponibilidad�operativa a la que debe asistir el cliente o spon-
sor 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 insufi-
ciente 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 cam-
bio 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
Disponibilidad operativa
En inglés, operational readiness.
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.
Nota
En este subapartado se sigueespecialmente el manual deRodríguez, García y Lamarca(2007).
© FUOC • PID_00153558 18 Cierre del proyecto
Mantener la documentación completa y al día es un elemento crítico que po-
sibilita la auditoría y revisión de los resultados intermedios por personas ex-
ternas al equipo de proyecto y asegura la calidad de la ejecución. La documen-
tació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 to-
dos 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 documen-
tación de operaciones, la documentación de uso y el plan de manteni-
miento.
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 responsabi-
lidad sobre el resultado.
Con relación al proyecto, los documentos mínimos que debe incluir la docu-
mentació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
Fuente: Snyder y Parth (2008), modificado
Documentación
En inglés, por este motivo, aveces se llama project handoverdocument.
© FUOC • PID_00153558 19 Cierre del proyecto
Documento de cierre
Contratos
Fuente: Snyder y Parth (2008), modificado
Si somos una empresa externa, tenemos que guardar copia de toda la docu-
mentación en una base de datos propia.
Un ejemplo de formulario de cierre se presenta en la figura 4.
© FUOC • PID_00153558 20 Cierre del proyecto
Figura 4. Ejemplo de formulario de Informe de cierre
© FUOC • PID_00153558 21 Cierre del proyecto
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 cuan-
do 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.
Nota
En este subapartado se siguenlos manuales de Snyder y Parth(2008) y Rodríguez, García yLamarca (2007).
© FUOC • PID_00153558 22 Cierre del proyecto
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 proyec-
to para nuevos proyectos. Los proyectos de la organización son una par-
te central de lo que ahora se denomina gestión del conocimiento.
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 "inteligen-
te" del proyecto realizado en una propuesta puede hacer que sea la selecciona-
da 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 im-
plantació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 al-
macenarse 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.
Bibliografía
Snyder�y�Parth (2008, págs.405-408) proporcionan unamás que interesante lista decomprobación de los aspec-tos a examinar a la hora deelaborar un informe de post-implantación y leccionesaprendidas que resulte sufi-cientemente detallado y efec-tivo.
© FUOC • PID_00153558 23 Cierre 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 em-
presas 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 responsa-
ble 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
© FUOC • PID_00153558 24 Cierre del proyecto
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 asig-
natura 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 cohe-
sión para las personas y las empresas.
La celebración
"La celebración es un reconocimiento del trabajo bien hecho, de las relaciones perso-nales 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, esuna invitación para nuevos proyectos exitosos y para extender la cultura de proyectodentro de la empresa.
Existe un nivel de celebración formal en el ámbito de la empresa o empresas partici-pantes y de los equipos de proyecto, incluyendo el personal directivo. Existen otrasoportunidades y formas de celebración que dejamos a la imaginación del lector."
Fuente: Rodríguez, García y Lamarca (2007, pág. 196)
© FUOC • PID_00153558 25 Cierre del proyecto
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 mar-
cados en tiempo, resultados y coste. El fracaso se da cuando se han so-
brepasado las expectativas de tiempo y coste, cuando los resultados no
son tan satisfactorios como se esperaba o cuando los objetivos ya no tie-
nen 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 pro-yecto en el mercado.
• Los adversarios del proyecto dentro de la organización han ganado posicio-nes y han creado una corriente de opinión negativa.
Fuente: Rodríguez, García y Lamarca (2007)
Nota
Para este apartado en generalse sigue a Rodríguez, García yLamarca (2007).
Muchas de estas razones tienen una lógica de negocio o de proyecto impeca-
ble 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 ten-
dencia 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
Bibliografíarecomendada
I.�Royer (2003). "Why badprojects are so hard to kill".Harvard Business Review (vol.81, n.° 2, págs. 48-56). Bos-ton.
© FUOC • PID_00153558 26 Cierre del proyecto
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 lle-
van a minimizar los problemas y a exagerar los progresos y los beneficios po-
tenciales.
Recientemente se ha reconocido la influencia de la percepción individual y las dinámicasde grupo en los grandes desastres humanos y empresariales (Roberto, en su estudio parala Universidad de Harvard sobre el desastre de algunas expediciones al Everest).
También se entrelazan en ocasiones intereses comerciales, de poder o de in-
fluencia de alguna de las partes, o el miedo a perderlos.
Por este motivo, siempre es importante revisar durante todo el periodo de eje-
cución que los objetivos del proyecto siguen siendo realistas, que los resulta-
dos 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 organiza-
ció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 obje-
tivos: 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.
Bibliografíarecomendada
M.�A.�Roberto (2002, oto-ño). "Lessons from the Eve-rest: The interaction of Cog-nitive Bias. PsychologicalSafety and System Comple-xity". California ManagementReview (vol. 45, n.° 1, págs.136-158).
© FUOC • PID_00153558 27 Cierre del proyecto
Cómo evitar los peligros de la fe ciega
• ¡Cuidado con los entusiastas! Un buen equipo tiene una sabia combinación deentusiastas, realistas y acaso también pesimistas, o al menos escépticos. Identi-ficar pronto la emergencia y el desarrollo de la cultura de "fe ciega" dentro delproyecto o de la empresa.
• Establecer un sistema de alarma anticipada. El trabajo por subproyectos e hitospermite, si se hace correctamente, identificar en cada fase del trabajo los signosde incumplimiento o desviaciones muy significativas. Si éstas alcanzan una pro-porción en tiempo, calidad o coste significativos, si constituyen una tendencia, sise sobrepasan los niveles de riesgo y contingencia autorizados o si no se activanlos planes de contingencia... todos estos son motivos de alarma.
• Establecer un plan de salida. No basta realizar preguntas o registrar los motivosde alarma, se trata de recoger evidencias y ponerlas de manera sensible pero cla-ra delante de los órganos de dirección del proyecto o, si no es suficiente, de lagerencia 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 credibilidadinterna, capaz de enfrentarse al nivel de hostilidad que se producirá en la organi-zación y de afrontarlo sin miedo. El responsable de la salida no es un crítico o unintelectual, es un ejecutivo que se pone manos a la obra para cerrar un proyectofallido.
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 razonable-
mente, 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 ma-
yor 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 administra-
tiva.
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.
Ved también
Ved el módulo "Seguimiento ycontrol del proyecto" de estematerial.
© FUOC • PID_00153558 28 Cierre del proyecto
5. Cierre de los contratos
El segundo proceso formal de la gestión del cierre es el cierre de los con-
tratos, que forma parte del área de conocimiento de "Administración de
compras y contratos" y consiste en el cierre de los contratos existentes
de acuerdo con las condiciones pactadas y la resolución en su caso de
las reclamaciones o litigios pendientes.
Es un proceso de naturaleza fundamentalmente legal y económica. Lo normal
es que, tanto en su preparación como a lo largo de la ejecución, los participan-
tes hayan sido departamentos centrales de contenido jurídico, financiero o de
compras, con una intervención menor por parte del jefe de proyecto. Sin em-
bargo, corresponde al jefe de proyecto verificar que los trabajos contratados se
han realizado satisfactoriamente, en tiempo, presupuesto y calidad, según los
términos pactados, y que no quedan trabajos pendientes de realizar o facturas
pendientes de cobro. También le corresponde opinar o a veces negociar sobre
las reclamaciones o litigios que puedan estar encima de la mesa.
Los principales componentes del proceso de cierre contractual, según PMBOK
(2008), se muestran en la figura 5.
Figura 5. Componentes del proceso de gestión de cierre contractual
Fuente: PMBOK (2008)
© FUOC • PID_00153558 29 Cierre del proyecto
6. 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 organiza-
ciones (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 acos-
tumbran a obtener beneficios netos y aún menos cumplen las promesas eco-
nómicas de sus promotores. Por no hablar de los proyectos fracasados, cuestio-
nados 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 ge-
nerales 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 evalua-
ción del éxito de un proyecto debería medirse bajo diferentes parámetros, des-
de 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 informa-
ció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 be-
neficiarios 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
© FUOC • PID_00153558 30 Cierre del proyecto
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 fun-cionales
Organización
Eficacia Mejoras en el trabajo Mejoras funcionales Mejoras en el servicio
Efectividad (transfor-mación)
Extensión de los diferen-tes roles
Redefiniciones fun-cionales
Innovaciones en elproducto
Pastor, sobre una adaptación de Gibson y Hammer
Una de las razones principales de fracaso en los proyectos de sistemas de in-
formació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 apli-
cació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 habitual-
mente, 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 an-
terior, las sugerencias de modificación, etc.
Por ejemplo, uno de los proyectos del Plan estratégico de sistemas de información delAyuntamiento de Barcelona era la implantación de una plataforma móvil para la Guar-dia Urbana basada en dispositivos tipo PDA, que permite a los agentes acceder a infor-mación corporativa, proporcionar información al ciudadano, realizar trámites y ponerdenuncias. En el momento de su puesta en marcha, se diseñó un sistema de informaciónpara 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 delnivel de adopción y el conjunto de acciones simultáneas permitieron un nivel de utiliza-ción superior al 70% de los usuarios en el 60% de su trabajo cotidiano, en los tres mesessiguientes a su puesta en marcha, dentro de un colectivo de edad madura y reactivo ala tecnología.
Durante el periodo de post-implantación del sistema, se siguen haciendo con-
troles técnicos, como por ejemplo los tiempos de respuesta del servidor, prue-
bas de carga y estrés, etc. Otros elementos a considerar son los problemas apa-
recidos durante el mantenimiento correctivo y evolutivo o la escalabilidad de
Ved también
Para más información sobre losprogramas de gestión del cam-bio, ver módulo "El lado hu-mano de la gestión de proyec-tos".
© FUOC • PID_00153558 31 Cierre del proyecto
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.
6.1. Los resultados del negocio
Evaluar los resultados de negocio de un proyecto es mucho más com-
plicado. 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 conjun-
to han modificado la valoración inicial, o lo han hecho circunstancias
relacionadas con la implantación o post-implantación, como los proce-
dimientos 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 ge-
nerados) 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.
Bibliografíarecomendada
Para esta clase de análisis,además del módulo "Inicia-ción del proyecto y trabajosprevios", puede verse el ca-pítulo 2 del libro de Olson(2004); el capítulo 2 del ma-nual de Marchewka (2003),y los materiales de Oliver(2004) en Finanzas para infor-máticos (Barcelona: UOC).
© FUOC • PID_00153558 32 Cierre del proyecto
Proyectos tecnológicos y proyectos de negocio
Una de las conclusiones que se extraen de los proyectos de negocio modernos esque, en cualquier sector –petróleo, construcción, producto farmacéutico, productode consumo, servicios financieros, etc.–, la tecnología ha dejado de ser parte del pro-blema para ser parte de la solución. Una segunda conclusión es que la solución tec-nológica es parte de la solución, pero sólo una parte de la misma (Feeny). Esto ha-ce que un proyecto informático sólo pueda medirse muchas veces en los términosmás amplios del conjunto de la solución empresarial propuesta, que incluye desde eldiseño de procesos y el diseño de la nueva organización, hasta la implantación delnuevo 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)
© FUOC • PID_00153558 33 Cierre del proyecto
7. Resumen
La última etapa del proyecto es la de cierre. Los buenos proyectos acaban de
forma controlada, resolviendo los problemas y flecos que surgen inevitable-
mente 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 or-
dinario 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.
Los procesos que comprende la gestión del cierre del proyecto son:
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.
b) El cierre de los contratos, de acuerdo con las condiciones pactadas y la re-
solución en su caso de las reclamaciones o litigios pendientes.
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
© FUOC • PID_00153558 34 Cierre del proyecto
departamento de IT de la organización). Es una operación que debe planifi-
carse 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 docu-
mentación del proyecto, deben proporcionarse al cliente documentación téc-
nica, operativa y de uso y un plan de mantenimiento de la solución TIC im-
plantada.
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 to-
dos.
En ocasiones, un proyecto debe de suspenderse temporalmente o de terminar-
se antes de cumplir sus objetivos, por diferentes causas. Esto no es fácil de re-
conocer 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 tiem-
po, 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.