proyecto Cierre del - GitLabuoc.gitlab.io/2015/gestion proyectos/modulo 7.pdf1. Mostrar los...

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


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.


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.


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.


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


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.


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.


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).


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).


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


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.


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).


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.


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.


Figura 4. Ejemplo de formulario de Informe de cierre


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).


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.


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


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)


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.


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.


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).


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.


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)


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


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".


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.


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).


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)


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


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.

proyecto Cierre del - GitLabuoc.gitlab.io/2015/gestion proyectos/modulo 7.pdf1. Mostrar los...

Documents

Transcript of proyecto Cierre del - GitLabuoc.gitlab.io/2015/gestion proyectos/modulo 7.pdf1. Mostrar los...