Cierre del proyecto
-
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é
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 y MGPI de las ingenierías de Informática, así como de Gestión de proyectos en el máster TIC, y en la UAB.
PID_00153550
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 escrita
de los titulares del copyright.
Índice
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 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 adecuadamente cobra aún
más importancia.
La figura 1 representa la posición del cierre en el ciclo de gestión 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 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:
-
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.
-
Explicar las situaciones y momentos que pueden generar un cierre abrupto de un proyecto y cómo deben manejarse.
-
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.
Fuente: Rodríguez, García, Lamarca (2007), modificado
|
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.
|
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 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:
Fuente: PMBOK (2008)
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.
Ejemplo
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.
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.
Fuente: Snyder y Parth (2008), modificado
|
Documento de cierre
|
|---|
|
Acta de constitución del proyecto
|
|
Plan de proyecto:
|
|
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
|
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.
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.
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.
Fuente: Rodríguez, García, Lamarca (2007)
|
Elementos de la base de datos de conocimiento del proyecto
|
|---|
|
1) Descripción del proyecto
|
|
2) Valoración del proyecto
|
|
3) Indicadores de gestión del proyecto
|
|
4) Índice de la documentación disponible
|
|
5) Personas de contacto del proyecto
|
|
6) Bases de datos en las que hay información del proyecto
|
|
7) Administración de la base de datos
|
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.
Fuente: Rodríguez, García y Lamarca (2007)
|
Razones para la terminación abrupta de un proyecto
|
|---|
|
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.Cierre de los contratos
El segundo proceso formal de la gestión del cierre es el cierre de los contratos,
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 participantes hayan sido
departamentos centrales de contenido jurídico, financiero o de compras, con una intervención
menor por parte del jefe de proyecto. Sin embargo, 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.
Fuente: PMBOK (2008)
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 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.
Pastor, sobre una adaptación de Gibson y Hammer
|
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
|
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 tipo PDA, 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.
6.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)
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 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.
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 resolució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 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.