Las Claves para gestionar Proyectos TI by Miguel Angel Navarro Hellín

Esta publicación está sujeta a cambios sin previo aviso y no representa compromiso alguno por parte del autor ni editor. No está permitida la reproducción total o parcial de este libro, ni su tratamiento informático, ni la transmisión de ninguna forma o por cualquier medio, ya sea electrónico, mecánico, por fotocopia, por registro u otros métodos, sin permiso previo y por escrito de los titulares del copyright. ISBN-13: 978-84-614-5633-8 Depósito legal: M-41584-2011 Autor:

Miguel Ángel Navarro Hellín

La imagen de la portada es propiedad de © Bobyramone

La web y el blog del autor son: www.lasclavesparagestionar.es www.manavarroh.blogspot.com.es

¿A quién va dirigido? Este libro va dirigido a todas las personas que van a participar en un Proyecto en el ámbito de los Sistemas de Información, ya sea con la figura de Cliente o la de Proveedor. Las personas que tienen la figura de Cliente, creen que sus objetivos son opuestos a las personas que componen la figura del Proveedor, pero ciertamente, nada más lejos de la realidad, ambos quieren que el Proyecto se realice, con las características necesarias y en el plazo y coste previsto, por eso es necesario describir con el máximo detalle posible todo el contenido del Proyecto y acordarlo. Este libro, no pretende ser una metodología de Gestión de Proyectos, ya que existen muchas, lo que se pretende es poner encima de la mesa una serie de reglas, formas de hacer y reflexiones, que permitan que la gestión y ejecución de Proyectos en el ámbito de los Sistemas de Información sean más eficientes y con menos nivel de estrés, desavenencias y desviaciones. Para las personas que no están acostumbradas a participar regularmente en Proyectos relacionados con los sistemas de información encontrarán en este libro un buen soporte para la toma de contacto con los diferentes factores relacionados con los Proyectos de este tipo. Para las personas que están acostumbradas a participar en este tipo de Proyectos y se ha encontrado con problemas, tendrán unas reglas y actuaciones que han servido de guía para obtener Proyectos con éxito.

Si está en el lado del Cliente, conocerá que hacer y cuando, además de valorar el impacto que tienen las decisiones en el resto de actuaciones relacionadas con el Proyecto. Si está en el lado del Proveedor, entenderá porqué hay que ser a veces exigente en ciertos aspectos de las relaciones con los Clientes. Y para ambos, entenderá porque es más provechoso trabajar en Equipo con objetivos, riesgos y seguimiento compartidos y controlados.

El autor, Desde el año 1.993 realiza diferentes roles y trabajos en el mundo de la Informática de Gestión. Una parte de su carrera la realiza en un Distribuidor de implantación de soluciones ERP y CRM internacional, donde pasa por diferentes puestos, desde Consultor Funcional, Formador, Consultor de Negocio (consiguiendo el reconocimiento por parte de la empresa, como mejor consultor de negocio del año 2002 a nivel nacional) y finalmente como Jefe de Proyectos, donde participa en Proyectos de implantación de soluciones tanto de ERP con verticales como de soluciones horizontales en un abanico de sectores industriales. Es Técnico en Informática de Gestión y Técnico Superior en Informática Empresarial, realiza la Diplomatura en Empresariales y tiene un Postgrado en Gestión de Proyectos Informáticos, además de varias Certificaciones. Coautor de un manual funcional de un conocido Programa de Gestión Empresarial (ERP) y en la actualidad es el Director de la Unidad de Negocio de Proyectos de una empresa de asesoramiento empresarial en el entorno de las empresas TIC a nivel nacional y latinoamericano. Aunque en su etapa inicial formaba parte de Proyectos de implantación de soluciones tipo ERP, CRM y SAT en clientes finales, realizando diferentes roles de los mismos, tal como se ha comentado anteriormente, en los últimos años se ha centrado en confeccionar, mejorar e impartir parte de una metodología internacional, que en la actualidad ha sido adquirida por un importante fabricante de software a nivel mundial, a la confección e impartición de cursos de productos ERP y al soporte a Proyectos, mediante empresas de tecnología a nivel de Consultoría de Negocio, Análisis de procesos y Dirección de Proyectos, tanto a nivel nacional como en algunos casos a nivel internacional. Es ponente desde el 2007, a nivel nacional de una metodología de Gestión de Proyectos internacional y realiza estudios tecnológicos y codirige Proyectos a nivel de Comunidad Autónoma para el Plan Avanza desde el año 2007.

Las claves para gestionar Proyectos de sistemas de informaciﾃｳn Por Miguel ﾃ］gel Navarro

Índice Capítulo 0: Introducción Capítulo 1: ¿Qué información se necesita para empezar el Proyecto? Capítulo 2: ¡Equipo de Proyecto! Capítulo 3: El Kick-Off del Proyecto, el nacimiento de un nuevo Proyecto Capítulo 4: Evaluación de riesgos del Proyecto Capítulo 5: ¿Todos los Proyectos son iguales? Capítulo 6: ¿”Fasear” el Proyecto? Capítulo 7: ¿Cada Proyecto requiere las mismas etapas? Capítulo 8: ¿Cómo Gestionamos el Proyecto? Capítulo 9: ¡Psicología en los Proyectos! ¿Qué me estás contando? Bibliografía y Nota

Capítulo 0 Introducción ________________________________________________ ***** Los personajes Para amenizar la lectura de este libro y por otra parte darle más realismo y facilidad de comprensión, se han incorporado personajes ficticios que forman parte del Equipo del Cliente, del Proveedor o de un Externo y que aparecen esporádicamente en alguno de los Capítulos y que son: La empresa Cliente es Productos XYZ S.A y dentro de su Equipo encontramos a las siguientes personas: Carlos  Responsable de Informática. Raúl

 Director Comercial.

Arturo  Director Servicio Postventa

La empresa Proveedor es Implantación de soluciones SL y dentro de su Equipo encontramos a las siguientes personas:

Daniel  Responsable Comercial. Mario  Jefe de Proyectos. Marcos  Consultor Funcional o Implantador

La empresa Consultora externa es Profesionales para Estudios y Proyectos SL y dentro de su Equipo encontramos a las siguientes personas: Francisco  Especialista en CRM. ***** Las viñetas de humor gráfico Otro de los recursos que he utilizado para amenizar la lectura de este libro, son las viñetas de humor gráfico, que podremos encontrar en algunos capítulos, relacionadas con el tema que se trata en cada caso.

***** Los gráficos Los gráficos, permiten ver en una sola imagen, las características o contenidos más importantes de una idea, de un proceso o de una tarea concreta, permitiendo así una mayor comprensión o visión general de sus partes más importantes de un vistazo. 14

Capítulo 1 ¿Qué información se necesita para empezar el Proyecto? ________________________________________________ ***** Los Proyectos informáticos no salen de repente como los champiñones, lo habitual es que un Proyecto sea la consecuencia lógica de unas necesidades previas, que pueden generar un desarrollo de una solución, o un proceso de compra / venta de una solución depende de si es el Cliente o el Proveedor de la misma. En este libro no vamos a analizar ni las necesidades ni la compra / venta que puede generar un Proyecto, pero sí que vamos a analizar qué información necesitamos para poder empezar un Proyecto de sistemas de información informático. Es importante saber qué objetivos y alcance aproximado queremos cubrir con la solución informática que queremos implantar, qué recursos humanos, materiales y económicos internos y/o externos necesitamos y con qué plazo de tiempo contamos o queremos contar. Sin esta información a un cierto nivel de detalle, difícilmente podemos plantearnos el siguiente paso, para empezar o simplemente para tener un Proyecto de sistemas de información informático.

Una vez tengamos esto, debemos analizar que aplicación o aplicaciones informáticas existen en el mercado y que empresas pueden proveérnoslas o desarrollárnoslas. Si por otra parte tenemos un departamento de Informática en la propia empresa, que es la que se va a encargar de desarrollar e implantar la solución, el entorno es muy distinto. Debemos buscar varios Proveedores de la solución o soluciones que creamos inicialmente que nos pueden cubrir las necesidades que tenemos y que ellos sean los que nos aconsejen y nos guíen. Para que puedan guiarnos adecuadamente, es importante que transmitamos el máximo de información a los posibles Proveedores de una forma ordenada, concreta y clara, esto facilitará muchísimo la efectividad de las respuestas de los posibles Proveedores de la solución. Si por otra parte, lo que tenemos es un departamento de Informática capaz de desarrollar e implantar una solución, deberíamos solicitar toda la información y pasos necesarios y por lo tanto, tratar a este departamento como si fuera un Proveedor externo, creando incluso el Equipo de Proyecto con las dos partes, la del Proveedor y la del Cliente, como se explica en el capítulo siguiente. *****

Consejos generales 16

Desarrollar una solución completamente a medida para cubrir las necesidades, es bajo mi punto de vista un error, creo que hoy en día hay soluciones informáticas para todos los sectores y áreas de negocio, por lo tanto voto más por una solución estándar y con calado en el mercado, eso no quita para que se desarrollen funcionalidades o módulos sobre estas plataformas estándar para completar la solución. En el caso de no haber ninguna solución estándar que cubra un porcentaje importante de las necesidades no nos queda más remedio que acudir a una solución a medida. Los inconvenientes más importantes que veo en una solución a medida, son varios: o Su propio nombre ya lo dice, a medida, es decir hecho específicamente para mí, de entrada puede sonar bien, pero a mí lo que me dice, es que soy el único que la tiene y por lo tanto todo el proceso de pruebas y estabilización de los procesos los tengo que sufrir yo. o Los cambios tecnológicos y legales que surjan se han de actualizar y esa solución solo la tengo yo o un volumen relativamente pequeño de empresas, otra vez a sufrir las pruebas y la estabilización de los procesos. o Dependo de la empresa o incluso de la persona que ha desarrollado la solución, con lo que tengo todos mis procesos informáticos de la solución pendientes de esa empresa, o lo que es peor de esa persona. Pienso si esa empresa cierra o no me da 17

buen servicio o esa persona desaparece ¡Que será de mí! En cambio, si es una solución más o menos estándar, con un fabricante más o menos grande, con un volumen importante de Proveedores que la venden y lógicamente con un volumen de expertos trabajando en estos Proveedores, “el cuento es totalmente diferente” a la hora de afrontar los inconvenientes que he comentado antes y otros que no he comentado. Muchos de vosotros me diréis que no tengo en cuenta más ventajas que tiene una solución a medida, que si hace exactamente lo que yo necesito, que me sale mucho más económico, en muchos casos no tengo gastos de licencias ni de mantenimientos, etc., pero si fuésemos capaces de valorar cuánto cuesta, si nos ocurre alguno de los inconvenientes en su parte más extrema en nuestras carnes de los que he comentado antes, seguramente nos sale bastante más cara la solución a medida, retraso en todo tipo de procesos, nueva formación, falta de información para tomar decisiones de todo tipo, etc. Cambiando el tercio, otra de las cosas a tener en cuenta antes de empezar un Proyecto, por muchas ganas que tengamos de hacerlo y llegar al máximo alcance y en el menos tiempo posible, es “fasear” el Proyecto, pensando en esto desde el principio, nos permitirá conseguir nuestros objetivos más fácilmente, reducir lo traumático del Proyecto de una forma importante y optimizar mejor los recursos en general, no quiero extenderme más en este tema ya que el Capítulo 6 está dedicado exclusivamente a 18

esto, pero sí que es algo en lo que debemos pensar desde el principio. Permitirme un consejo más, si sois el Cliente, es imprescindible tener un Jefe de Proyecto que se pueda dedicar al Proyecto, que haya vivido directamente algún Proyecto informático de una u otra forma y que tenga un nivel jerárquico en la empresa mediano alto, para tener una cierta autonomía de decisión en aquello que compete directamente sobre el Proyecto, si esto no lo tenemos “lo que tenemos es un montón de problemas”, pero no os preocupéis porque no saldrán todos los problemas de golpe, “irán saliendo de uno en uno y en el momento más inoportuno”. Siguiendo con este último consejo, que ha conseguido sacar mi parte más poética, recomiendo que contratéis a un externo con estas cualidades para que os ayude en el Proyecto y os haga el trabajo de esta figura, “ya que, si no es muy caro os saldrá barato”.

Capítulo 2 ¡Equipo de Proyecto! ________________________________________________ ***** ¿Qué características tiene el Equipo de Proyecto? Para poder especificar claramente los perfiles y cualidades de los componentes del Equipo del Proyecto por ambas partes, lo asociaremos a cada uno de los posibles roles principales. Según el Proyecto o los componentes del Equipo de Proyecto por ambas partes, puede cambiar la necesidad o importancia de una cualidad o capacidad en función del carácter o predisposición de cada situación durante el Proyecto, pero en general las características y cualidades principales serían las que vamos a pasar a describir a continuación. Para empezar repasaremos los componentes del Equipo del Cliente: Las características y cualidades del Jefe del Proyecto por parte del Cliente son principalmente las siguientes: o Tener un nivel jerárquico en la estructura de la empresa suficiente como para liderar el Proyecto, teniendo en cuenta que hay que tomar decisiones 21

o o

del Proyecto muy relacionadas con los procesos empresariales y que por lo tanto este nivel jerárquico es importante. Tener una visión general del Proyecto para no dejarse influenciar por decisiones o necesidades puramente departamentales o de área concreta. Tener capacidad resolutiva y de toma de decisiones con relativa agilidad, para evitar desviaciones importantes sobre la planificación. Tener conocimientos generales de todos los procesos de la compañía. Ser extrovertido y comunicativo para poder gestionar con el resto del Equipo del Proyecto las diferentes situaciones propias del Proyecto.

Las características y cualidades del Responsable de departamento o de área por parte del Cliente son principalmente las siguientes: o Tener un nivel jerárquico en el departamento o área suficiente como para liderarlo en el Proyecto. o Tener capacidad resolutiva y de toma de decisiones con relativa agilidad para los temas que surjan del departamento o área, para evitar desviaciones importantes sobre la planificación. o Tener amplios conocimientos de todos los procesos del departamento o área. o Ser extrovertido y comunicativo para poder gestionar con los usuarios finales del departamento o área las diferentes situaciones propias del Proyecto.

Seguiremos con los componentes del Equipo del Proveedor: Las características y cualidades del Jefe del Proyecto por parte del Proveedor son principalmente las siguientes: o Tener capacidad resolutiva y de toma de decisiones con relativa agilidad, para evitar desviaciones importantes sobre la planificación. o Tener capacidad para gestionar Equipos en situaciones de relativa tensión y exigencia. o Ser extrovertido y comunicativo para poder gestionar con el resto del Equipo del Proyecto las diferentes situaciones propias del Proyecto. o Tener “don de gentes”, ser disciplinado, meticuloso, calculador, ordenado y previsor. o Experimentado en implantación de soluciones y consultorías de negocio. Las características y cualidades del Consultor de Negocio o de Sistemas son principalmente las siguientes: o Ser extrovertido y comunicativo para poder gestionar con el resto del Equipo del Proyecto las diferentes situaciones propias del Proyecto. o Tener “don de gentes”, ser disciplinado, meticuloso y ordenado. o Experimentado en implantación de soluciones. o Conocimientos de procesos de negocio. o Conocimientos funcionales de aplicaciones informáticas relacionadas con el Proyecto. o En el caso del Consultor de Sistemas las dos anteriores se sustituyen por esta (Conocimiento de redes y comunicaciones). 23

o Capacidad de escuchar y de analizar lo que se escucha. o Legibilidad y fluidez en la escritura. Las características y cualidades del Analista Programador son principalmente las siguientes: o Capacidad de Análisis a nivel técnico. o Capacidad de gestionar pequeños Equipos. o Experimentado en la programación y desarrollo de soluciones y /o funcionalidades. o Capacidad para la valoración de desarrollos. o Conocimientos funcionales de aplicaciones informáticas relacionadas con el Proyecto. o Claridad y fluidez en la escritura. o Ser disciplinado, meticuloso, calculador, ordenado y previsor. Las características y cualidades del Programador son principalmente las siguientes: o Experimentado en la programación. o Capacidad para la valoración de desarrollos. o Ser disciplinado, meticuloso, ordenado y previsor. Las características y cualidades del Implantador son principalmente las siguientes: o Ser extrovertido y comunicativo para poder gestionar con el resto del Equipo del Proyecto las diferentes situaciones propias del Proyecto, principalmente con el Equipo del Cliente. o Tener “don de gentes”, ser disciplinado, meticuloso y ordenado. 24

o Experimentado en implantación de soluciones. o Conocimientos de procesos de negocio. o Conocimientos funcionales profundos de aplicaciones informáticas relacionadas con el Proyecto. o Dotes formativas. o Capacidad de escuchar y de analizar lo que se escucha. ***** Responsabilidades de los diferentes roles Dependiendo del tipo de Proyecto por parte del Equipo del Proveedor, se podrán incorporar unos roles u otros, pero en este capítulo enumeraremos los diferentes roles con independencia del tipo de Proyecto. Empezaremos con los roles del Equipo del Cliente, que está compuesto tal como hemos visto antes, principalmente por dos roles, el Jefe de Proyecto y los Responsables de departamento o área: El Jefe del Proyecto por parte del Cliente, es el máximo responsable del Proyecto por parte del Cliente y sus responsabilidades principales son las siguientes: o Velar por la correcta realización de las tareas asignadas al Equipo del Cliente y cumplimiento de fechas. o Participar en la formación a responsables de departamento o de área. 25

o Participar en las sesiones de consultoría de la etapa de análisis. o Revisar el documento de Análisis del Proyecto y firmarlo. o Realizar las reuniones de seguimiento tanto con el Equipo del Cliente como con el Jefe del Proyecto del Proveedor. o Revisar y confirmar cada uno de los Hitos establecidos en el Proyecto. o Mediar en todos los litigios entre personal del Equipo de Cliente relacionados con el Proyecto. o Recoger todas las problemáticas que vayan surgiendo durante el Proyecto y darles una solución, individualmente o en colaboración con el Jefe del Proyecto del Proveedor, dependiendo de la naturaleza del problema. o Velar por los intereses generales del Proyecto sobre los intereses departamentales o de área. El Jefe de departamento o de área por parte del Cliente, es el máximo responsable del departamento o del área del Proyecto por parte del Cliente y sus responsabilidades principales son las siguientes: o Velar por la correcta realización de las tareas asignadas a su departamento o área y cumplimiento de fechas. o Participar en la formación a responsables de departamento o de área. o Participar en las sesiones de consultoría de la etapa de análisis relacionadas con su departamento o área y aportar toda la información posible.

o Realizar las reuniones de seguimiento con el Jefe del Proyecto del Cliente. o Revisar y confirmar los Hitos establecidos en el Proyecto relacionados con su departamento o área. o Mediar en todos los litigios entre los usuarios finales de su departamento o área relacionados con el Proyecto. o Recoger todas las problemáticas que vayan surgiendo durante el Proyecto y darles una solución, individualmente o en colaboración con el Jefe del Proyecto del Cliente, relacionadas con su departamento o área.

Continuamos con los roles del Equipo del Proveedor, que está compuesto tal como hemos visto antes, principalmente por seis roles, el Jefe del Proyecto, Consultor de Negocio, Consultor de Sistemas, Analista Programador, Programador e Implantador: El Jefe del Proyecto por parte del Proveedor, es el máximo responsable del Proyecto por parte del Proveedor y sus responsabilidades principales son las siguientes: o Crear el Equipo del Proyecto del Proveedor. o Velar por la correcta realización de las tareas asignadas al Equipo del Proyecto (tanto del Proveedor como del Cliente), pero principalmente las del Proveedor y cumplimiento de fechas. o Preparar toda la documentación necesaria para el Kick-Off y ser el ponente del mismo.

o Revisar el documento de Análisis del Proyecto y firmarlo. o Revisar y confirmar cada uno de los Hitos establecidos en el Proyecto. o Mediar en todos los litigios entre personal del Equipo de Proveedor relacionados con el Proyecto. o Recoger todas las problemáticas que vayan surgiendo durante el Proyecto y darles una solución, individualmente o en colaboración con el Jefe del Proyecto del Cliente, dependiendo de la naturaleza del problema. o Revisar periódicamente las imputaciones de los trabajos realizados para el Proyecto en el sistema de control de gestión de Proyectos existente. o Convocar, preparar y liderar todas las reuniones de seguimiento, tanto las que se realizan con el Equipo del Proveedor como con el Cliente. o Velar por la rentabilidad del Proyecto.

El Consultor de Negocio, es el responsable de tomar todos los requerimientos del Proyecto durante las sesiones de consultoría y reflejarlas en el documento de Análisis del Proyecto y sus responsabilidades principales son las siguientes: o Revisar toda la documentación que se tiene del Cliente para conocerlo lo mejor posible. o Realizar las sesiones de consultoría previamente pactadas y planificadas con cada uno de los responsables de departamento o área. o Documentar todos los requerimientos y procesos del Cliente que afectan al Proyecto. 28

o Valorar el Proyecto en colaboración con el Jefe del Proyecto del Proveedor y el Analista Programador y plasmarla en el documento de Análisis. o Planificar el Proyecto en colaboración con el Jefe del Proyecto del Proveedor y el Analista Programador y plasmarla en el documento de Análisis. o Pasar el borrador del documento de Análisis a todo el Equipo del Proyecto, tanto del Proveedor como del Cliente. o Recoger y plasmar todas las modificaciones que se soliciten en el documento de Análisis consensuados con los dos Jefes del Proyecto. o Dar soporte al Analista Programador, Programador e Implantador en todas las dudas que les puedan surgir sobre el documento durante todo el Proyecto.

El Consultor de Sistemas, es el responsable de tomar todos los requerimientos de sistemas del Proyecto durante la\s sesión\es de consultoría y reflejarlas en el documento de Análisis del Proyecto y sus responsabilidades principales son las siguientes: o Revisar toda la documentación que se tiene del Cliente para conocerlo lo mejor posible. o Realizar la\s sesión\es de consultoría previamente pactadas y planificadas con el responsable de sistemas del Cliente. o Documentar todos los requerimientos y estructura del sistema informático del Cliente que afectan al Proyecto. 29

o Valorar los requerimientos de sistemas del Proyecto en colaboración con el Jefe del Proyecto del Proveedor y el Analista Programador y plasmarla en el documento de Análisis. o Recoger y plasmar todas las modificaciones que se soliciten en el documento de Análisis consensuados con los dos Jefes del Proyecto. o Dar soporte al Implantador o Técnico de sistemas en todas las dudas que les puedan surgir sobre la parte de sistemas del documento durante todo el Proyecto.

El Analista Programador, es el máximo responsable de la parte de Diseño Técnico y Programación del Proyecto y sus responsabilidades principales son las siguientes: o Participar en las sesiones de consultoría previamente pactadas en las que los requerimientos sean muy complejos o requieran mucha programación. o Realizar el Diseño Técnico de la solución. o Repartir que desarrollos realizará cada Programador, darles soporte y controlar la calidad y las fechas de entrega de los mismos. o Programar los desarrollos que él crea conveniente. o Valorar los desarrollos y validación de los mismos de todo aquello que afecta al diseño técnico y programación. o Leer todo el documento de Análisis y dar su conformidad.

o Validar todos los procesos de la solución desarrollados o que se les haya modificado o añadido funcionalidad. o Recoger todas las problemáticas que vayan surgiendo durante el Proyecto sobre temas del diseño técnico o desarrollo y darles una solución, individualmente o en colaboración con el Jefe del Proyecto del Proveedor, dependiendo de la naturaleza o envergadura del problema.

Programador, sus responsabilidades principales son las siguientes: o Leer y aceptar la parte de desarrollos del documento de Análisis. o Programar los requerimientos que se le hayan asignado en el tiempo y calidad solicitada. o Dar soporte al Implantador durante la validación e implantación de los requerimientos. o Solucionar las incidencias de sus requerimientos.

El Implantador, es el máximo responsable de la implantación de la solución y sus responsabilidades principales son las siguientes: o Leer todo el documento de Análisis y dar su conformidad. o Validar todos los procesos de la solución desarrollados o que se les haya modificado o añadido funcionalidad.

o Realizar la formación a los responsables de departamento o área del Cliente. o Instalar el software en las instalaciones del Cliente. o Dar de alta y configurar todo lo necesario para la puesta en marcha inicial de la solución. o Validar cada uno de los desarrollo y reportar todas las incidencias que encuentre. o Presentar los desarrollos y/o procesos al Equipo del Cliente. o Recoger las incidencias detectadas por el Cliente y gestionarlas con el Equipo de desarrollo del Proveedor hasta su resolución final. o Impartir la formación a los usuarios finales. o Dar soporte durante la puesta en marcha de la solución.

Tal como hemos visto cada rol tiene unas responsabilidades perfectamente definidas y diferenciadas, pero esto no quita para que una persona no pueda realizar más de uno de estos roles en el mismo Proyecto, dependiendo de la duración del Proyecto y del alcance, pero siempre que se pueda hay que mantener por lo menos tres figuras, por aquello que dicen que “ven más cuatro ojos que dos”. Es fácil pensar en compartir roles del Equipo del Proveedor, como por ejemplo el del Jefe del Proyecto con el Consultor de Negocio, o el del Analista Programador con el Programador, ya que son perfiles parecidos o que antes de tener un rol se ha pasado por el otro, el que no se aconseja compartir es el del Jefe del Proyecto con el 32

Implantador ya que son roles que se complementan en situaciones difíciles durante la implantación del Proyecto y si es la misma persona esta opción desaparece y es mucho más difícil afrontar esos posibles problemas. En cuanto a la estructura jerárquica, tanto del Equipo del Cliente como la del Proveedor, me voy a vasar en un diagrama, ya que como dice el refrán “Una imagen vale más que mil palabras”:

La estructura jerárquica para el equipo del Proveedor no tiene por qué ser una estructura jerárquica a nivel de Empresa, (diría más, mejor que no lo sea) sino que solo a nivel de todo lo relacionado con el Proyecto, cosa que en el Equipo del Cliente normalmente esa jerarquía es igual para el Proyecto que para la Organización Empresarial del trabajo diario, cosa que beneficia al Proyecto.

Capítulo 3 El Kick-Off del Proyecto, el nacimiento de un nuevo Proyecto ________________________________________________ ***** Introducción al concepto de Kick-Off del Proyecto Este es el primer acto donde el Cliente va a ver “en acción” al Jefe del Proyecto del Proveedor, y va a conocer el detalle de los siguientes pasos a seguir, tener una visión general de la metodología a utilizar en el Proyecto, y las líneas generales del mismo, como se dice coloquialmente “la primera impresión es la que cuenta”, por lo tanto nos tenemos que asegurar de que esta impresión sea buena y demuestre que el Equipo del Proveedor, representado en este acto por el Jefe del Proyecto, es profesional, responsable, disciplinado y sabe lo que tiene entre manos. ***** Lo que hay que hacer antes del Kick-Off Utilizando la información obtenida en la preventa, tanto la que ha recopilado el Jefe del Proyecto del Proveedor si ha participado en algún momento de la preventa, que debería, como la del Comercial, confecciona una

presentación de unos 30 minutos de duración, donde por lo menos se debería reflejar: o La importancia del Equipo del Proyecto. o Las características principales de los participantes del Equipo. o La implicación del Equipo del Proyecto y la dedicación aproximada que han de tener en las diferentes etapas del Proyecto. o La metodología de gestión del Proyecto, con sus etapas e Hitos. o El objetivo de la formación a responsables de departamento. o El objetivo de la etapa de Análisis. o El alcance del Proyecto. o Los objetivos del Proyecto. o La importancia de la planificación y el seguimiento. o Presentación de la planificación aproximada del Proyecto a alto nivel. o Ruegos y Preguntas

Preparar la planificaci贸n para la formaci贸n a responsables de departamento donde nos aseguremos de que el formador tenga disponibilidad y se reserva las fechas que vamos a proponer y que tengamos todo el material necesario para esas fechas, tales como sala, Proyector, etc. Y finalmente preparar una agenda tentativa para la consultor铆a de negocio y de sistemas para el An谩lisis, dependiendo del tipo de Proyecto para presentar al Equipo del Cliente y acabar de cerrar las fechas con ellos, de igual modo nos aseguraremos de que los consultores tengan disponibilidad en esas fechas y se las reserven.

***** Lo que hay que hacer durante el Kick-Off ***** Si soy el Proveedor El Jefe de Proyecto del Proveedor tiene que dar la imagen de que es el líder del Proyecto, de que tiene las riendas del Proyecto y de que es un profesional en la dirección de Proyectos, para transmitir con todo esto al Cliente la tranquilidad y seguridad de que están en buenas manos. Es importante que durante el Kick-Off se repasen todos los puntos mencionados anteriormente para no dejar nada de las reglas generales del inicio del Proyecto en el tintero, y si hay algún tipo de problema con estos temas que salgan lo antes posible a la luz, para conocerlos y tomar las medidas necesarias a la mayor brevedad. Entre otras cosas es importante que queden claros en el Kick-Off, temas como, el alcance del Proyecto, los objetivos, el tiempo previsto, la repercusión que tiene el Proyecto sobre el Equipo del Cliente, etc., ya que si no tenemos claros estos temas desde el principio en un momento u otro saldrán, con una repercusión incierta pero con repercusión, y no precisamente positiva. *****

Si soy el Cliente Si cualquiera de los temas mencionados anteriormente como importantes durante el Kick-Off, no se tratan por parte del Jefe de Proyecto del Proveedor, el Jefe de Proyecto del Cliente debe sacar estos temas y se le deben dar respuesta a cada uno de ellos, si es posible en ese mismo Kick-Off. Si es necesario, por la importancia de los mismos, se debe exigir repetir el Kick-Off teniendo en cuenta los temas pendientes demandamos por el Cliente.

***** Si soy el Cliente o el Proveedor indistintamente Puede ayudar mucho hacer una presentación inicial del Proyecto a toda la compañía, donde participen en la ponencia, el Director General del Cliente y los dos Jefes de Proyecto por lo menos, este acto ayuda a que los empleados se sientan partícipes e informados del Proyecto que se avecina y por lo tanto la predisposición y colaboración sea mayor. El contenido de esta presentación no es el mismo que el del Kick-Off, aunque sí que hay muchas cosas iguales, como por ejemplo el Objetivo y Alcance del Proyecto, la planificación General aproximada, pero donde hay que hacer más hincapié, es en la importancia de la participación y el esfuerzo añadido que se necesita para tener éxito en el Proyecto por parte de todos y lo imprescindibles que son todos los usuarios para conseguir el éxito del mismo.

Capítulo 4 Evaluación de riesgos del Proyecto ________________________________________________ ***** Introducción a los riesgos del Proyecto Los riesgos a los que se está sometido en un Proyecto de sistemas de información, son muy dispares y variables en función de cada Proyecto, por muy parecido que sea un Proyecto de otro. Los riesgos son de diferentes naturalezas, pueden estar relacionados con la tecnología que utiliza el Cliente y/o la que utiliza el Proveedor, con el Equipo del Cliente y/o con el Equipo del Proveedor y otras propias del propio Proyecto. Vamos hacer una relación de posibles riesgos de diferentes naturalezas para asegurarnos de que tenemos claro a que nos referimos, hay que tener en cuenta que seguro que hay muchos otros posibles riesgos y que no se pretende hacer una relación de todos los riesgos posibles, sino de centrarnos en los conceptos básicos de posibles riesgos y para ello vamos a enumerar unos cuantos: Un posible riesgo tecnológico es el tener que pasar datos de una aplicación a otra sin tener herramientas tecnológicas existentes y probadas para poder hacerlo, con lo que en el Proyecto se tendrá que desarrollar una 41

herramienta para traspasar estos datos, el riesgo está en la incertidumbre de saber exactamente cuánto tiempo se necesita para tener esta herramienta y por lo tanto difícil de valorar y planificar, con el consiguiente riesgo de costes no previstos y desviación en tiempo sobre lo planificado. Otro posible riesgo tecnológico es el implantar una aplicación nueva, donde no hay expertos en la implantación de esta aplicación ni otras implantaciones comparativas, y normalmente no existe la documentación y soporte maduro de la misma ya que es nueva, el riesgo está en la incertidumbre de no saber exactamente los tiempos necesarios para la mayoría de trabajos de implantación, los posibles problemas que surgen en la aplicación por falta de madurez, la preparación previa necesaria para poder realizar la mayoría de tareas por ser algo nuevo, etc., que van a tener una repercusión en los costes y tiempos sobre la planificación, difíciles de prever y repercutir. Un posible riesgo del Equipo del Cliente es su falta de experiencia en Proyectos de implantación de sistemas de información, ya que no son conscientes del trabajo que se les viene encima, no son conscientes del impacto que un Proyecto de este tipo tiene sobre su día a día, además de la importancia de sus tareas dentro del Proyecto, imprescindibles para la buena marcha y consecución de los objetivos del Proyecto. Otro posible riesgo del Equipo del Cliente es que el Jefe de Proyecto no tenga el nivel jerárquico adecuado ni la visión general del Proyecto en cuanto a objetivos y alcance, esto comporta diferentes problemas, como dilatación en las tomas de decisiones porque ha de consultar 42

continuamente cada paso importante a la persona que sí que tiene el nivel jerárquico para tomar las decisiones, tener tendencias departamentales con lo que pierde de vista el objetivo principal del Proyecto, pretender un alcance diferente del pactado con la consecuencia de paros continuos en la marcha del Proyecto por reuniones aclaratorias o de nuevos acuerdos, etc. Un posible riesgo del Equipo del Proveedor, es la inexperiencia de alguno de sus componentes en las tareas asignadas dentro del Proyecto, tanto porque son inexpertos o porque la aplicación es nueva. Otro posible riesgo en el Equipo del Proveedor, es el nivel de presión sicológico y de carga de trabajo de otros Proyectos, que alguno de los componentes pueda tener. Y para finalizar, un posible riesgo del propio Proyecto, es la participación de terceros o cuartos autores en el Proyecto, o sea que en el Proyecto hubieran varios Proveedores y que cada uno realiza una parte del Proyecto y que los trabajos dependen unos de otros sobre la planificación global del Proyecto. Otro posible riesgo del propio Proyecto, está relacionado con el volumen de desarrollos a medida que se hagan en el Proyecto o por lo contrario el volumen de estandarización del mismo, si se trata de una aplicación ya desarrollada por un fabricante y que sus procesos están probados en muchas implantaciones o realizamos un proceso a medida específicamente para este Proyecto. ***** 43

¿Cómo podemos darle un valor económico al riesgo? Una vez que tenemos claro que son los riesgos del Proyecto y de qué tipo podemos encontrarnos, podemos afirmar que es necesario conocen en la medida de lo posible todos los riesgos que nos vamos a encontrar en el Proyecto para poder valorarlos y tener en cuenta su repercusión tanto en los costes como en la planificación del Proyecto. La mejor forma de hacer esto, ya que todos los riesgos no se detectan en el mismo momento del Proyecto, varían para cada Proyecto, tipo de Proyecto, y son difíciles de valorar es tener una herramienta que nos permita varias cosas, principalmente las siguientes: o Podamos tener una lista de riesgos posibles, clasificados por su naturaleza, esta lista ha de estar viva y se ha de actualizar con los diferentes riesgos que nos vayamos encontrando en los diferentes Proyectos. o Para poder pasar del riesgo como un concepto “sui generis” a poder valorarlo, es imprescindible tener varios indicadores, y la suma de los mismos nos darán la objetividad que necesitamos para que ese riesgo pase de ser algo subjetivo a objetivo. Los indicadores pueden ser los siguientes:  ¿Este riesgo afecta a todo el Proyecto o solo a una parte?  Cuantas veces puede surgir este riesgo en el Proyecto.  ¿Puedo solucionar el riesgo con mis medios? 44

Si marcamos unos valores en función de lo que pensemos para cada uno de estos indicadores (por ejemplo entre 1 y 5), y luego sumamos estos tres indicadores, ya podemos pasar al paso siguiente, que es por ejemplo, el clasificar los resultados en tres grupos:  De 1 a 5  Riesgo asumible  De 6 a 10  Riesgo a repercutir  De 11 a 15  Riesgo a repercutir y comunicar a Dirección General. Estos valores nos sirven, por ejemplo para: 



Riesgo asumible  asumir el riesgo sin repercutirlo ni en la valoración ni en la planificación o solo en la planificación, es decir, dar un tiempo de margen por si este riesgo surge que no afecte a la planificación pactada. Riesgo a repercutir  Se repercute el coste y el tiempo estimado en los costes del Proyecto y en la planificación respectivamente. Riesgo a repercutir y comunicar a Dirección general Se repercute el coste y el tiempo estimado en los costes del Proyecto y en la planificación respectivamente, y se comunica el riesgo al responsable máximo para que tome la decisión de qué hacer con el riesgo, ya que aunque lo valoremos y lo planifiquemos, puede tener repercusiones aún mayores y por lo tanto es el responsable máximo el que ha de tomar la decisión adecuada. 45

o Finalmente, hemos de dar un valor económico a estos riesgos ya clasificados y decidir si se lo repercutimos o no al Cliente en función de la clasificación anterior, para esto debemos establecer una relación entre clasificación de riesgo y %, por ejemplo:  Riesgo asumible  el 0,5 % del valor total de los servicios del Proyecto.  Riesgo a repercutir  el 1 % del valor total de los servicios del Proyecto.  Riesgo a repercutir y comunicar a Dirección general el 1,5 % del valor total de los servicios del Proyecto. Estos porcentajes han de estar vivos y se han de actualizar con la experiencia en los diferentes Proyectos. Como se puede ver, ni los riesgos son una ciencia exacta, ni los indicados, ni la clasificación de los mismos, ni él % a aplicar, pero sí que con sistemas como el expuesto podemos “pasar de algo tan subjetivo como es un riesgo a algo tan objetivo como es un importe económico exacto.” Pero lo más importante de todo esto, no es el sistema a utilizar, ni la clasificación, ni todo lo demás que hemos comentado, lo realmente importante de los riesgos del Proyecto es conocerlos, analizarlos, valorarlos y finalmente tenerlos en cuenta en la valoración y planificación, porque son hechos que nos encontraremos en el Proyecto, y que “la diferencia entre tener en cuenta los riesgos o no, repercute de una forma importante en los costes y cumplimiento de fechas del Proyecto”. 46

En el caso de que no tengáis en cuenta los riesgos en los Proyectos habitualmente, os aconsejo que empecéis hacerlo, se trata de ir progresivamente avanzando en la gestión de los riesgos Proyecto tras Proyecto, llegando hasta el punto de gestión en el que os encontréis cómodos, no hace falta llegar hasta la valoración económica de los mismos.

Solo el hecho de pensar en ellos, analizarlos y tenerlos en cuenta, nos van a poner en una predisposición involuntaria, que nos va a permitir valorar y planificar de otra forma muy distinta a la que haríamos sin hacer estas reflexiones, y esto sí que es importante para el resultado final de esa valoración y planificación. 47

Capítulo 5 ¿Todos los Proyectos son iguales? ________________________________________________ ***** Tengo que reconocer que durante los años que llevo gestionando Proyectos informáticos, independientemente del rol o roles que haya desempeñado en cada uno de ellos, nunca, ya sé que es una palabra extremista y que se ha de utilizar con cuidado, así que vuelvo a afirmar nunca he participado en dos Proyectos iguales, como mucho he participado en dos Proyectos poco parecidos, ese es el adjetivo más cercano que soy capaz de utilizar para describir la similitud entre dos Proyectos. La verdad es que aunque en dos Proyectos en los que he participado fueran para Clientes del mismo sector industrial, con la misma aplicación base y con características parecidas, realmente los dos Proyectos eran, como he dicho antes poco parecidos como mucho. Permitidme que con lo explicado en los dos párrafos anteriores realice una serie de comentarios, reflexiones o recomendaciones, etiquetarlas como queráis, pero sobre todo tenedlas en cuenta tanto Proveedores como Clientes a la hora de afrontar el Proyecto, en la etapa o etapas relacionadas con las mismas:

o Aunque el Cliente diga que sus procesos son totalmente estándar y por lo tanto los gestiona igual que el resto de empresas de su sector, no es cierto, y no porque el Cliente nos quiera engañar sino porque lo cree realmente. Por lo tanto Sr. Cliente, olvídese de esto porque aunque no lo crea sus procesos son diferentes a los demás del sector, lo suficiente como para tener que analizarlos con detalle y adaptárselos específicamente para usted. Por lo tanto Sr. Proveedor, analice con detalle los procesos del Cliente y tome la actitud de estar oyendo ese proceso por primera vez, después ya veremos qué proceso o parte del proceso podemos aprovechar de la aplicación base, de otro Cliente o lo que sea. Teniendo claro este punto por ambas partes y con la actitud adecuada sobre este tema nos quitamos de en medio unos cuantos problemas del Proyecto, “ya sé que he dicho unos cuantos, siento deciros que hay muchos más”. o Ya se ha dejado claro en otros capítulos, que el Proveedor es el experto en desarrollar e implantar soluciones informáticas, pero no pensemos que por este motivo, el Proveedor es capaz de implantar la solución “él solito” y por lo tanto como Cliente podemos olvidarlos del Proyecto, solo tenemos que dedicarnos a realizar un seguimiento y a pagar la parte del Proyecto que toque siempre y cuando el Proyecto vaya bien.

Nada más lejos de la realidad, en el Capítulo 2 hemos hablado de los roles del Jefe de Proyecto y Responsable de área del Cliente, y de sus responsabilidades, pero las personas que toman estos roles tiene que dedicar una parte muy importante de su tiempo al Proyecto, ya que son los que entre otras cosas han de: 

  

   

Liderar el Proyecto desde la perspectiva del Cliente, coordinando todas las tareas de su responsabilidad y a las personas necesarias para la buena ejecución de las mismas. Participar en la Presentación del Proyecto. Participar en la formación inicial para la preparación de la Consultoría posterior. Participar en las sesiones de Consultoría que les pertenezca llevando todo lo necesario para el buen acometido de la misma, como por ejemplo: o Equipo del departamento o del área. o Tareas que se realizan. o Procesos. o Muestras del reporting que utilizan. o Etc. Revisar y aceptar el documento de Análisis del Proyecto. Validar todos los procesos de su competencia de la solución propuesta. Coordinar todos los trabajos relacionados con su área o departamento. Asegurarse de que todo su Equipo está formado con las funciones del nuevo sistema y que todos los procesos están OK. 50



Realizar el seguimiento de que todos los procesos y tareas se realizan correctamente en la puesta en marcha de la nueva solución. Solucionar todos los problemas que surjan relacionados con su área o departamento si le es posible y si no escalarlo a un nivel superior.

Por lo tanto, es responsabilidad del Proveedor establecer los controles adecuados en el Proyecto para conseguir que el Cliente realice todas y cada una de sus tareas, ya que son imprescindibles para la correcta realización del Proyecto y como profesional de la implantación de soluciones es su obligación hacer ver al Cliente la necesidad insalvable de realizar todas y cada una de sus tareas. Cuando estas tareas no se realizan porque no se ha concienciado correctamente al Cliente o no se han seguido con la correcta disciplina, esto genera un desajuste importante sobre el resultado del Proyecto que finalmente acaba saliendo en un punto u otro del Proyecto, normalmente en el momento más inoportuno, que hace que la relación entre Cliente y Proveedor se deteriore seriamente y que no se alcancen los objetivos establecidos previamente en el Proyecto, con consecuencias de diferente índole, como desviaciones en tiempo y en coste, marcha atrás en el Proyecto, e incluso la disolución del contrato entre ambas partes con el consiguiente perjuicio para ambos.

Por eso, el Proyecto se ha de tomar con un Equipo formado por ambas partes, con responsabilidades claras para cada componente, con lĂderes de ĂĄrea y con una meticulosidad y firmeza excepcionales.

Capítulo 6 ¿”Fasear” el Proyecto? ________________________________________________ ***** Siempre que se pueda es conveniente “Fasear” el Proyecto, es decir, crear todas las fases del Proyecto que sean necesarias, ni más ni menos que las necesarias, esto es bueno tanto para el Cliente como para el Proveedor, vamos a analizar los principales motivos: o Es mucho más fácil abordar un Proyecto con menos áreas que analizar, parametrizar, formar, validar, poner en marcha, etc. o Sobre todo, si la primera fase del Proyecto consiste en poner en marcha un sistema informático que es nuevo para el Cliente, los requisitos de este sistema, no se verán de la misma forma antes de empezar con el nuevo sistema que después de llevar un tiempo trabajando con él, ya que no se ven las cosas de la misma forma. o Incluso habrán requerimientos que al analizarlos antes de trabajar con el sistema nuevo se verán de una forma y después de trabajar con el sistema se verán de otra o incluso no serán necesarios. o Además si el Proyecto se alarga en el tiempo, por su complejidad o por su volumen, es posible que nos encontremos cambios tecnológicos que serán

muy difíciles de incorporar si no hemos “Faseado” el Proyecto. Creo que son suficientes razones como para tener una mentalidad orientada a “Fasear” los Proyectos siempre que sea necesario y teniendo en cuenta tanto que es responsabilidad del Proveedor trasmitir esta mentalidad al Cliente, ya que puede ser que él no sea consciente de este tema, porque en muchas ocasiones, su negocio no está orientado a Proyectos. No podemos inventarnos fases del Proyecto “sin ton ni son”, las fases del Proyecto deben estar analizadas y consensuadas y con el contenido adecuado para que pueda funcionar por sí sola, pero teniendo en cuenta la fase o fases siguientes.

Debemos documentar claramente cuantas fases tiene el Proyecto, que alcance y objetivos tiene cada una de ellas y su contenido, así como la planificación y valoración económica de cada una de ellas, para dejar establecidas las reglas del juego tanto para el Cliente como para el Proveedor. Es posible que de alguna de las fases siguientes no tengamos un detalle lo suficientemente grande como para dar una planificación o valoración, hecho que deberíamos hacer constar en el documento de acuerdo, pero sí que deberíamos tener en cuenta que es lo que tenemos pensado hacer en la segunda fase, para que en la primera tengamos en cuenta aquellas cosas que le puedan afectar, y así en cada una de las fases que detallemos con referencia a la siguiente o siguientes.

Capítulo 7 ¿Cada Proyecto requiere las mismas etapas? ________________________________________________ ***** Introducción En este capítulo se detallan cada una de las etapas que pueden comprender el desarrollo e implantación de un Proyecto de Sistemas de Información, dependiendo de las características de cada Proyecto las diferentes etapas cobran mayor o menos importancia y pueden duran más o menos tiempo, e incluso puede ser que alguna de estas etapas no tenga sentido o importancia alguna, depende del Proyecto, en esos casos es mejor no utilizar esa etapa ya que no se trata de hacer todas las etapas por hacerlas, sino las justas y necesarias, ni una más ni una menos. Hemos de tener en cuenta que cada una de estas etapas conlleva un consumo de recursos (tiempo y coste entre otros). Hay que tener muy en cuenta a la hora de planificar cada una de estas etapas, que alcance tiene, quien la va a realizar, no es lo mismo que la haga alguien del Equipo del Proveedor, o que la hagan algunos recursos del Proveedor y algunos del Cliente a la vez, y no digamos si la realiza alguien de un tercero (subcontrata), dependiendo de esto,

la planificación, el riesgo y “los colchones” de recursos a prever son totalmente diferentes. Por otra parte, es muy importante que en estas etapas quede constancia escrita de cada paso que damos y que esa constancia escrita este consensuada y aceptada por las dos partes, es decir, por la totalidad del Equipo de Proyecto, representado por los Jefes de Proyecto, esto permite ir certificando el avance del Proyecto y el ir resolviendo las incidencias que puedan surgir en cada etapa antes de pasar a la siguiente, esto que se dice tan pronto y tan fácil, es una de las Claves para conseguir que el Proyecto tenga éxito, y la firmeza o debilidad en estas certificaciones marcan una parte muy importante de la calidad del Proyecto (cuando digo calidad del Proyecto, no me refiero únicamente al significado estricto de la palabra sino a un sentido mucho más amplio, coste en recursos de diferente índole, tiempo, calidad de la formación, desarrollo, parametrización, análisis, etc.) así que ojo con saltarse esta regla, nos costará caro seguro, por ambas partes. ***** Formación antes del Análisis, ¿Para qué? En cuanto a esta etapa, es importante tener en cuenta desde que punto partimos, en cuanto a lo relacionado con la solución a implantar, si tenemos una aplicación informática ya desarrollada, que nos sirve de punto de partida, y que muchas de sus funcionalidades y/o procesos nos sirven y los vamos a utilizar para la solución final, es recomendable hacer esta formación. 59

Si por lo contrario, no contamos con una aplicación base inicial o si contamos con ellas pero no se va a aprovechar prácticamente nada de lo existente, es mejor no hacerla. Con esta premisa aclarada, vamos a ver a quien hay que hacer esta formación, que contenido debe tener y porque es importante hacer esta formación a parte de los motivos psicológicos que veremos en el Capítulo 9 ¡Psicología en los Proyectos! ¿Qué me estás contando?: Esta formación hay que impartirla única y exclusivamente al Jefe de Proyecto del Cliente y a las personas que vayan a participar en las sesiones de Consultoría de la etapa de Análisis, que normalmente serán los Responsables de Área del Cliente, pero no tienen por qué ser estas personas imprescindiblemente. Recomendar que esta formación se haga fuera de las instalaciones del Cliente, que se marquen horarios con tiempos de descanso y que se prohíba el uso de móviles o internet u otros que puedan reducir la atención de los asistentes a la formación. La formación deberá ser de las áreas, módulos o funcionalidades que ya existen en la aplicación base que se vaya a implantar, estas áreas de han de ver a un nivel general y con la intención de mostrar que procesos y componentes tiene la aplicación base, por otra parte dar formación también de la tecnología que utiliza la aplicación, por ejemplo (entorno de trabajo, cambio de pantallas, navegación por la aplicación, integración, herramientas de búsqueda, filtrado, exportación, etc.). 60

Con esta formación de módulos, áreas o procesos funcionales a “vista de pájaro” más la formación tecnológica, conseguimos varias cosas dentro del Equipo del Cliente que participa en dicha formación: o Ver con que funcionalidad, módulos o procesos pueden contar inicialmente y así no pedir cosas que ya tiene la nueva solución, quitando de en medio posibles demandas necesarias durante mucho tiempo por parte de Cliente y que ya están incorporadas, centrando sus requerimientos en otras cosas más importantes y/o necesidades no cubiertas. o Tener una visión global de la solución base y viendo la repercusión que tiene una acción de un proceso o módulo en otro. o Con respecto a la parte tecnológica, ver la potencia o ventajas que tiene la solución base sabiendo utilizar las reglas del juego de la aplicación. o Y finalmente acercar “el argot” del Equipo del Cliente al del Equipo del Proveedor, facilitando el entendimiento en las conversaciones entre ambas partes del Equipo, “reduciendo los malos entendidos por llamar las cosas por dos nombre diferentes o identificar dos cosas diferentes con el mismo nombre”.

Comentar que para dejar constancia de que esta formación se ha realizado correctamente es importante hacer una encuesta de satisfacción, teniendo en cuenta cual es el objetivo de la misma y evitando que posteriormente se pretenda echar la culpa de algo a esta formación, si hacemos esta encuesta de satisfacción y se obtiene una buena respuesta por parte de los asistentes, se entiende que la formación ha estado bien impartida y bien recibida, además de tener una constancia documental de que se ha realizado. ***** ¿Qué es y para qué sirve el Análisis? El Análisis, es la etapa del Proyecto donde vamos a recopilar toda la información que nos ha de traspasar el Cliente a través de las sesiones de consultoría, mediante 62

sus interlocutores (Jefe de Proyecto del Cliente, Responsables de área o usuarios finales, que crean necesarios sus Responsables de área que participen en las sesiones de consultoría), la esencia de esto es que el Cliente transmita al Proveedor toda la información de los procesos que quiere poner en marcha en el Proyecto de la forma más clara y precisa posible. El Análisis, sirve para establecer en un documento todo lo relacionado con el Proyecto, desde los componentes del Equipo hasta el Plan de formación, todo (o sea las Sagradas Escrituras para un Creyente, o el Vademécum para un Farmacéutico), donde se recojan detalladamente por lo menos lo siguiente: o Objetivos y Alcance del Proyecto. o Objetivos del documento. o Equipo del Proyecto, con nombre y roles (recordad que el Equipo lo forma personal del Cliente y del Proveedor). o Áreas de negocio o de gestión que forman parte del Proyecto: o Dentro de cada área a de aparecer, diagrama de cada proceso detallado. o Identificar que partes de cada proceso es estándar y cual no. o Detallar de las partes que no son estándar o que hay que desarrollar, como se van a desarrollar, mediante una descripción funcional. o Plan de formación. o Los Hitos del Proyecto y como se van a controlar y conseguir. 63

o Metodología de implementación del Proyecto. o Valoración en horas por etapas y/o Fases. o Planificación detallada del Proyecto por etapas y/o Fases. o Firma y fecha de conformidad por parte del Cliente y Proveedor, de que en este documento está todo lo relacionado con el Proyecto y que estamos de acuerdo (Aquí es donde firman los Jefes de Proyecto).

Bien, una vez que he contestado directamente a las preguntas del título de este apartado, permitidme que os cuente unas cuantas cosas más sobre el Análisis. Es muy importante que las sesiones de consultoría se preparen previamente a conciencia, para conseguir la efectividad que hablábamos anteriormente, de ahí que en el Kick-Off se entregue una Agenda tentativa para estas sesiones. ***** Si soy el Cliente No se debe esperar a llegar a las sesiones de consultoría para ver que cuenta el Consultor de Negocio, recordemos que como Cliente debe trasmitir de la forma más clara y rápidamente posible que quiere que haga la solución del Proyecto, y para esto debe llegar a la sesión o sesiones de consultoría “con los deberes hechos”, me refiero a llevar a la sesión cosas como, el organigrama del Departamento, las principales tareas de los componentes del Departamento o Área, cuales son y como son los procesos, que documentación y con qué formato se emite, cuales son los listados o informes habituales, etc. Parece obvio decir, pero pasa muchas veces, que el Cliente explica que hace ahora o que informes realiza ahora, esta información no tiene la menor importancia para el Proyecto si no se va a seguir haciendo, o no forma parte del Proyecto, por lo tanto el Cliente debe centrarse en explicar que es lo que necesita que haga la solución dentro del Proyecto, se esté haciendo ahora o no, porque el resto 66

de información si no es vinculante con el Proyecto que queremos acometer solo hace que ocupar tiempo que no tenemos y despistar.

***** Si soy el Proveedor No se pueden establecer sesiones de consultoría “maratonianas”, tenemos que tener en cuenta varias cosas relacionadas con esto, después de unas horas

escuchando, se pierde el nivel de concentración y por lo tanto se pierde información de la propia conversación. Por otra parte el Cliente además del Proyecto tiene su “día a día”, que mientras nos explica está pensando en todo lo que tiene que hacer y tal como pasan las horas está más pendiente de eso que de explicarnos, con lo que la calidad de la explicación cae proporcionalmente con la duración de la sesión de consultoría. Para evitar estas situaciones, de repercusiones incalculables sobre el Proyecto, propongo hacer sesiones de consultoría con el Cliente de media jornada, con un descanso a media mañana para tomar un café, tentempié, llamar por teléfono, etc. Y por la tarde dedicarlo a documentar, avisando al Cliente que esté localizable por si se tiene alguna consulta poder aclararla, ya que al escribir y meditar sobre lo que nos han dicho, suelen salir preguntas o dudas. Con esto evitamos los posibles problemas que he mencionado antes, además de que al finalizar la jornada el Consultor tiene toda la información documentada (o por lo menos lo más importante), ya que otro problema que existe es que lo que nos han explicado si no lo plasmamos, tal como va pasando el tiempo, también se pierde progresivamente. Imaginad un entorno donde llevamos varios Proyectos y hoy estoy en uno y mañana en otro, donde he estado todo el día escuchando al Cliente y dejo la documentación para el final de todas las sesiones de consultoría, ¿Qué % de la conversación se ha perdido cuando voy a documentarla? más de la que me gustaría perder, seguro. 68

Una tarea nada fácil en la generación del documento de Análisis para el Consultor de Negocio que lo documenta, es utilizar un lenguaje lo suficientemente llano para que lo entiendan las personas del Equipo del Proyecto por parte de Cliente, y que a la vez recoja lo más detallada y “atadamente” posible el contenido y funcionamiento de todo lo relacionado con el Proyecto. Permitidme aclarar que cuando digo esto, no quiere decir que los participantes del Equipo del Proyecto por parte del Cliente no sean capaces de entender lo que se escribe, pero sí que no tienen por qué saber “tecnicismos específicos del sector informático”, ya que en la mayoría de los casos estas personas no tienen nada que ver con el sector informático.

***** Si soy el Cliente o el Proveedor indistintamente Con la importancia que tiene el AnĂĄlisis dentro del Proyecto y despuĂŠs de ver las consecuencias que tiene, el no hacer 70

correctamente esta etapa sobre todo el Proyecto, es imprescindible establecer un equilibrio entre la duración de las sesiones de consultoría, el nivel de preparación de las mismas, el buen funcionamiento del día a día del Cliente y la calidad del documento de Análisis del Proyecto por parte del Proveedor, y esto solo se puede conseguir teniendo en cuenta y aplicando las cosas explicadas en los dos párrafos anteriores a este. Una vez finalizado el documento de Análisis, en estado borrador, se ha de pasar a TODO EL EQUIPO DE PROYECTO para que lo revise lo critique y una vez revisado y corregido se firme por el Cliente y el Proveedor. De esta forma conseguimos que los participantes directos del Proyecto, o sea el Equipo, asuman el contenido total del documento de Análisis. ***** ¡Diseño Técnico! El Diseño Técnico, es el Análisis Técnico que realiza el Responsable de los desarrollos de la solución, y que por suerte siempre hace en mayor o menor medida, aunque debería hacerlo más en mayor que en menor medida. La importancia del Diseño Técnico es comparable con la etapa del Análisis anterior, pero el problema es que hay un % muy elevado de Proyectos donde no se documenta el Diseño Técnico y queda solo en la mente del Responsable de los desarrollos.

El Diseño Técnico es de vital importancia para conseguir funcionalidades, procesos o módulos de la solución con una integridad de datos adecuada y con una fluidez de la información y lógica de procesos también adecuada. La documentación del Diseño Técnico es imprescindible para cualquier cosa que venga después, como por ejemplo un cambio de Responsable de los desarrollos, una nueva versión de la solución, o simplemente un cambio en alguna de las funcionalidades, procesos o módulos. La no existencia de esta documentación o la documentación inadecuada o incompleta, genera problemas añadidos a la no fácil tarea de los Responsables de los desarrollos o los Analistas Programadores y directamente a la calidad y costes del propio Proyecto sin lugar a dudas.

*****

Calidad y Control del Desarrollo Como punto de partida, para conseguir una calidad alta en los desarrollos, es imprescindible tener el correcto Diseño Técnico del punto anterior, sino ya empezamos mal y difícilmente los desarrollos acabaran con el nivel de calidad aceptable por mucho que nos esforcemos. Teniendo en cuenta esto, en líneas generales los desarrollos más complejos los tendrían que hacer los Analista Programadores y los más sencillos los Programadores, y para conseguir un nivel de calidad adecuado tanto unos desarrollos como los otros, deberían ser validados por otra persona, que propongo que sea el Implantador, ya que “cuatro ojos ven más que dos”, además de que cada persona tiene una forma concreta de comprobar las cosas y por lo tanto si los validan dos personas (Programador e Implantador), el volumen de pruebas y el abanico de opciones probadas es mucho mayor, por estadística pura, el volumen de incidencias detectadas es mayor y mayor es la calidad de los desarrollos.

Si por esta regla de tres fuera, pondr铆amos infinidad de recursos para validar, pero l贸gicamente hay que establecer un equilibrio entre costes, tiempo y calidad, que determinan el n煤mero de validaciones y de recursos. Para complementar estas acciones y seguir trabajando por el bien de la calidad y tratar el tema del control de los desarrollos a la vez, se han de establecer sesiones de presentaci贸n interna, entre los Programadores y el 75

Responsable de los desarrollos, y entre el Responsable de los desarrollos y el Jefe de Proyecto del Proveedor. Con estas presentaciones planificadas con antelación, conseguimos principalmente dos cosas, una es que tenemos una presión de fechas para la presentación interna que nos obliga a tener los desarrollos a tiempo y otra es que nos obliga a validar los desarrollos para poder presentarlos internamente, con lo que se incrementa la calidad. Como habréis visto en el párrafo anterior, he comentado el tema de presentaciones internas, con esto quiero decir que son presentaciones internas entre el Equipo del Proveedor, para asegurarnos de que cuando presentemos y entreguemos estos desarrollos, procesos o módulos al Cliente, hayan pasado un doble control de calidad, con las modificaciones necesarias durante la validación interna por un lado, y un control para el cumplimiento de las fechas pactadas por otro. ***** ¿Cómo realizar una implantación exitosa? La verdad es que para conseguir una implantación exitosa, no solo hay que hacer bien esta etapa del Proyecto, sino que hay que hacerlas bien todas, por lo tanto llegados a esta etapa si todas las etapas anteriores no tienen un nivel de cumplimiento muy alto, seguramente el Proyecto a estas alturas ya va bastante mal y seguramente no nos hemos dado cuenta o nos hemos dado cuenta de muy poco, por desgracia no tardará en salir todo. 76

¡Pero seamos positivos!, supongamos que hasta el momento lo estamos haciendo bastante bien y tenemos todas las etapas anteriores finalizadas con un nivel de cumplimiento muy alto, en este punto es donde vamos a empezar a presentar al Cliente todo aquello que hemos establecido en el documento de Análisis y que llevamos cierto tiempo preparando como Proveedores durante las etapas de Diseño Técnico, Desarrollo y Validación interna. ***** ¿Qué pasos hay que seguir? Lo primero que tenemos que hacer es preparar unas presentaciones al Cliente de todo lo que hemos desarrollado o preparado en las etapas anteriores, los asistentes a estas presentaciones deberían ser, los dos Jefes de Proyecto, el Responsable de área del Cliente y el Implantador del Proveedor, si además asisten usuarios finales del Cliente que han de validar las funcionalidades que se van a presentar mucho mejor. Es aconsejable para ahorrar tiempo y mejorar la calidad de las validaciones, presentar procesos completos, no funcionalidades sueltas, para conseguir ver como fluye la información durante todo el proceso y evitar que funcionalidades que por sí solas puedan ser correctas dentro de un proceso puedan no serlo al validarlo en su conjunto. Por lo tanto se realizarán tantas presentaciones como Responsables de área y procesos existan. 77

El siguiente paso es dejar que los Responsables de área y sus usuarios finales, realicen todas las pruebas de validación que sean necesarias para el correcto funcionamiento de cada proceso, reportando las incidencias que encuentren. Una vez finalizadas todas las validaciones y solucionadas todas las incidencias detectadas, se pueden dar por correctos todos los procesos de todas las áreas relacionadas con el Proyecto. Existen una serie de desarrollos que no se pueden considerar funcionalidades, sino que son, procesos de importación o exportación de datos o documentos que se han de emitir desde la solución con un formato concreto. Para estos casos debemos establecer unas reglas del juego diferentes, es decir una forma de desarrollar y validar específicas que paso a definir: o Para los procesos de importación / exportación de datos, debemos tener ficheros estructurados con los que preparar y validar los procesos antes de la puesta en marcha y que una vez realizados los procesos de importación / exportación el Cliente deberá validar que los datos de prueba son correctos. o Para preparar los documentos que se han de emitir, es importante realizar los últimos ajustes del formato, directamente en las instalaciones del Cliente y con su supervisión y validación, para evitar realizar un ir y venir de formatos, además de hacerlo con sus papeles pre impresos, si existen y 78

sus impresoras o cualquier otro hardware de emisión de documentos. Una vez que tenemos todos los procesos y áreas validadas por el Cliente y tenemos su visto bueno, lo siguiente es dar la formación a todos los usuarios finales de aquellas funcionalidades que van a utilizar de la nueva solución, ni más ni menos; una vez impartida esta formación ya estamos listos para arrancar, pero esa es otra etapa que veremos más adelante. Para tener un control adecuado de que todos los procesos están validados, es importante dejar constancia escrita de la consecución de los mismos y firmada por ambas partes, de igual forma con la formación a los usuarios finales. Un tema importante sobre la formación a usuarios finales, es el tiempo que transcurre entre la finalización de la formación y la puesta en marcha o arranque de la nueva solución, este periodo de tiempo ha de ser el MENOR POSIBLE, ya que hay que tener en cuenta que los usuarios finales, hasta que empiecen a trabajar con la nueva solución, siguen trabajando con la anterior y por lo tanto cada día que pasa entre la formación y la puesta en marcha de la nueva solución la formación adquirida se va perdiendo rápidamente. En la etapa del Proyecto de las validaciones de los procesos por parte del Cliente, es una de las etapas que más tiempo se pierde sobre lo planificado, por lo tanto el Cliente tiene que ser consciente de que tienen un tiempo concreto y establecido para validar, y tiene que darle la prioridad adecuada para conseguirlo si quiere tener su solución en marcha en las fechas acordadas. 79

Por otra parte el Proveedor sabedor de este problema, a de trasmitir la información necesaria al Cliente y a de establecer los controles adecuados para que el Cliente sepa que le puede pasar esto y asegurarse de que tenga los recursos necesarios y controlar y perseguir la realización de dichas validaciones en el tiempo acordado. Si no se tiene clara esta problemática y se actúa en consecuencia por ambas partes, esta etapa puede generar una desviación sobre la fecha planificada muy importante. Aprovecho este punto para decir algo que aunque es muy obvio no se le presta la atención ejecutiva que implica, y que afecta no solo a esta etapa sino a la totalidad de etapas del Proyecto, y es que “semana que pasa o se pierde sobre la planificación del Proyecto no se recupera”. En la etapa de la validación de procesos por parte del Cliente, la resolución de las incidencias detectadas y la formación a los usuarios finales, es donde se hace latente la importancia del Equipo de Proyecto y si realmente trabajamos como un Equipo o como dos Equipos enfrentados y trabajando con diferentes objetivos. Después de ver esto, se puede “palpar” la importancia del Capítulo 2: ¡Equipo de Proyecto! y el recalcar esta importancia del Equipo en el Kick-Off.

***** ¿Qué pasa si salen requerimientos nuevos? Tengo que reconocer que durante los años que llevo gestionando Proyectos informáticos, independientemente del rol o roles que haya desempeñado en cada uno de ellos, siempre, ya sé que es una palabra extremista y que se ha de utilizar con cuidado tal como me pasó al principio del libro, así que vuelvo a afirmar siempre me han requerido funcionalidades nuevas durante la implantación de la solución informática. Este es un apartado peligroso y en el que voy a intentar explicarme lo mejor posible, “aunque no lo creáis, llevo intentándolo durante todo el libro”, para poder transmitir lo que quiero, y para dejar muy claro que son requerimientos de verdad y que son “caprichos que si el Cliente puede colar gratis perfecto”, me explico. Durante las etapas de validación y formación de los usuarios finales principalmente, por parte del Cliente aparecen peticiones de todo tipo para mejorar funcionalidades existentes o para crear nuevas, por lo general no es que el Cliente tenga una mala intención en esto pero como es lógico “siempre puede estar mejor”, el problema es que hay un presupuesto y unos plazos establecidos en el documento de Análisis que marcan estas dos cosas y por lo tanto hay que atenerse a ellas. Lo que se debe hacer es ir recogiendo todos estos requerimientos triviales o casi triviales para valorarlos, planificarlos y ponerlos en marcha en otra fase del Proyecto o en otro Proyecto. 82

En el caso de que realmente aparezca una funcionalidad, que es imprescindible que esté en la solución que estamos desarrollando en el Proyecto y no la tengamos recogida, deberíamos seguir los siguientes pasos: o Los Jefes de Proyecto han de parar el Proyecto de mutuo acuerdo. o Analizar la funcionalidad o funcionalidades detectadas. o Ver cómo afectan al proceso o procesos relacionados. o Valorar las modificaciones. o Replanificar el Proyecto desde ese punto, teniendo en cuenta el nuevo entorno del Proyecto. o Documentar un anexo de cambios con todos estos cambios. o Firmar el anexo de cambios por ambas partes. o Seguir con el Proyecto.

Si no realizamos estos pasos y seguimos con el Proyecto, “metiendo con calzador” los nuevos requerimientos, afectará al Proyecto de una forma incalculable y tendremos que ir improvisando sobre la marcha, tirando por la ventana todo el buen trabajo realizado hasta el momento. 83

Y aunque alguna de las partes, Cliente o Proveedor crea que siguiendo adelante sin hacer estos pasos puede salir ganando de una u otra forma, estoy convencido de que ambos saldrán perdiendo con esta decisión. ***** ¿Estamos preparados para la Puesta en Marcha? Si hemos seguido todas las etapas correctamente, con un nivel muy alto de calidad, de control, de documentación y de consenso entre todo el Equipo antes de pasar de una etapa a otra, posiblemente estemos listo para la siguiente etapa de Puesta en Marcha, para comprobar todo esto es imprescindible que leáis el apartado ¡Hitos!, ¿Qué son y para qué sirven? del Capítulo 8: ¿Cómo Gestionamos el Proyecto?, ya que es lo suficientemente importante como para dedicarle un apartado completo. ***** ¿Arrancamos? La decisión de arrancar, de empezar a trabajar en real con la solución nueva, es una decisión que han de tomar conjuntamente los dos Jefes de Proyecto, no es una decisión de nadie más ni de nadie menos, es de ellos y la han de pactar y consensuar. Si todas las etapas anteriores están correctamente implantadas y estamos seguros de que todos los procesos 84

están validados, la formación a los usuarios finales impartida correctamente y las integraciones entre aplicaciones, los traspasos de datos, etc. (si es que los hay) están correctos, entonces podemos empezar a trabajar en real. Este Arranque se ha de preparar y comunicar a todo el personal implicado en el Proyecto y se ha de dotar de los recursos necesarios para el mismo, como por ejemplo el personal de soporte, que comentaremos en el apartado siguiente. Antes de dejar este apartado quiero hacer una reflexión sobre los paralelos que se realizan en algunas ocasiones en este tipo de Proyectos. Lo primero es comentar que es un paralelo, es seguir trabajando con el sistema anterior y con el sistema nuevo y comparar los resultados durante un cierto tiempo o período, para mí esto es UN GRAVE ERROR, denota una falta de confianza enorme sobre el Equipo del Proyecto y de la propia metodología del Proyecto, complica aún más la puesta en marcha del Proyecto en real y carga de una forma importante el trabajo diario de los responsables de área y los Usuarios finales. Si el Cliente o el Proveedor piensan en este paralelo, debemos quitarle esta idea de la cabeza y pensar en hacer un proceso de pruebas durante la implantación lo suficientemente férreo y de calidad, como para garantizar un “Arranque Exitoso” eliminando las dudas sobre el paralelo, ya es lo suficientemente complejo y requiere mucha dedicación un Proyecto como para sobrecargarlo aún más, hagamos correctamente cada una de las etapas 85

del Proyecto y no tendremos que optar por este tipo de cosas, que solo el pensar en ello “me pone los pelos de punta”.

***** ¿Qué soporte es necesario durante la Puesta en Marcha? El soporte que se presta durante la puesta en marcha es muy variado, dependiendo del volumen del Proyecto, de los usuarios finales, de las áreas de negocio que se pongan en marcha, de la complejidad del Proyecto, por eso la experiencia en Proyectos nos irá marcando unos criterios para establecer dicho soporte. Una de las reglas que se han de establecer para este soporte, independientemente de las variaciones en los diferentes parámetros que hemos comentado en el párrafo anterior, es que el soporte se ha de establecer de una forma escalonada y no todo de golpe, me explico, si consideramos que el soporte ha de ser inicialmente de 5 días, no es bueno que estemos los 5 días seguidos, es decir de lunes a viernes, ya que es posible que estemos algunas horas o incluso algunos días de este soporte sin nada que hacer, ya que los problemas, dudas o consultas no salen todas de golpe y es posible que al final de los 5

días, estemos al 50% de las necesidades de soporte inicial y ya hallamos consumido el 100%. Para este ejemplo es mejor marcar un soporte de 3 días la primera semana, por ejemplo, lunes, miércoles y viernes, y 2 días la segunda semana, martes y jueves, esto permite escalonar el soporte, abarcar un espacio de tiempo más largo y más acorde con la aparición de estas dudas, consultas o incidencias que puedan surgir durante la puesta en marcha.

***** ¿Cerramos el Proyecto? Dejemos claro desde el principio que conseguir finalizar esta etapa con éxito no es nada fácil, pero eso no significa que no lo consigamos, el Proyecto se ha de cerrar. Para conseguir cerrar el Proyecto, tenemos que ir buscando el cierre desde antes de empezarlo, o sea desde la propia preventa del mismo, un refrán que viene “como 87

anillo al dedo” es que “el que no siembra no recoge”, pues bien el cierre hay que sembrarlo para poder recogerlo. Es difícil separar en esta etapa que parte es operativa y que parte psicológica, sobre este tema se explica largo y tendido en el Capítulo 9 ¡Psicología en los Proyectos! ¿Qué me estás contando? Permitirme comentar en este capítulo, que el cierre ha de venir después de unas semanas de soporte, y que tenemos que estar dispuestos por ambas partes del Equipo de Proyecto a ceder en las pequeñas cosas que puedan faltar, que no son importantes, no están recogidas en el documento de análisis o no han quedado claras. Una buena tarea a tener en cuenta, es que la persona que ha realizado el Diseño Técnico de la solución, dé un repaso general al finalizar el Proyecto, lo que llamamos un Análisis de Cierre, para asegurar la integridad de los procesos y de los datos, pero ha de estar el documento de cierre firmado por ambas partes para realizar este trabajo. Esta es una buena forma de presionar, condicionando el Análisis de Cierre a la previa firma del cierre del Proyecto, dejando constancia en este documentado de las cosas pendientes y de la situación al cierre del Proyecto, como posibles cambios en las fechas pactadas inicialmente y las conseguidas finalmente, etc.

Capítulo 8 ¿Cómo Gestionamos el Proyecto? ________________________________________________ ***** ¡Hitos!, ¿Qué son y para qué sirven? El diccionario da como significados de Hito los siguientes, entre otros: Hito  Poste de piedra u otra señal que se clava en el suelo y señala el límite de un terreno o indica la dirección o distancias de una vía o un camino. Hito  Acontecimiento muy importante y significativo en el desarrollo de un proceso o en la vida de una persona. Si trasladamos estos significados al entorno de la implantación de soluciones o Proyectos informáticos y lo convertimos en definición como punto de partida para desarrollar este capítulo, podríamos decir que: El Hito es el Punto de control de objetivo establecido en la planificación del Proyecto, conocido y pactado por todo el Equipo de Proyecto, para comprobar y justificar que se están cumpliendo satisfactoriamente o no los objetivos de cada uno de los pasos críticos del Proyecto. Los Hitos del Proyecto se han de establecer en los puntos estratégicos de la planificación del Proyecto, para 90

asegurarnos que tenemos una etapa finalizada correctamente antes de seguir con la siguiente, por ejemplo: -

Hasta que no tengamos completamente documentado todo el Análisis del Proyecto y consensuado entre el Proveedor y el Cliente, con el acto de firma del mismo, no podemos seguir con la siguiente etapa del Proyecto.

Otro ejemplo seria: -

Hasta que no estén todos los procesos finalizados y validados por Cliente y Proveedor y la formación a los usuarios finales, impartida y aceptada por los mismos no se puede pasar a la etapa de puesta en marcha.

Este control de Hitos permite al Proveedor ir “certificando” cada una de las etapas del Proyecto, justificando la entrega de los servicios relacionados con cada una de ellas, no olvidemos que estamos entregando servicios, o sea algo intangible y que esta “certificación” de servicios nos permite justificar documentalmente la entrega de los mismos. Por parte del Cliente permite comprobar que el Proveedor está realizando las tareas relacionadas con cada etapa que se pactaron y el nivel de calidad de las mismas, con lo que tiene un control de la situación del Proyecto, además de “certificar” de igual modo que las tareas asignadas dentro de su Equipo y relacionadas con cada etapa también se están realizando y como.

Este control y seguimiento de Hitos permite, si algo no va bien, poder rectificar en el sentido o parte que sea, Cliente o Proveedor, antes de seguir adelante, rectificando y/o encaminando la situación acorde con las necesidades del Proyecto, independientemente de la repercusión que esto tiene en tiempo y coste, repercusiones muy importantes pero que se analizan en otro apartado. Con este control de Hitos conseguimos no realizar tareas posteriores hasta asegurarnos que las actuales están correctas y consensuadas por ambas partes. “Todo aquello que permitamos que pase a otra etapa sin asegurarnos de que está correcto y consensuado genera un impacto negativo sobre el Proyecto, de proporciones incalculables, y que seguro que nos encontraremos, teniendo que subsanar, con un coste y tiempo mayor cuanto más adelante del Proyecto nos lo encontremos” Mario ha presentado a Carlos y Francisco una planificación del Proyecto con una serie de Hitos establecidos, tales como: 1. Formación Usuarios Clave impartida correctamente. 2. Documento de Análisis del Proyecto firmado por ambas partes. 3. Aplicación y licencia instalada correctamente. 4. Configuración de la base de datos finalizada. 5. Personalizaciones entregadas y validadas. 6. Formación a Usuarios finales impartida correctamente. 7. Traspasos finalizados correctamente. 8. Puesta en marcha de la solución. 92

9. Cierre del Proyecto. Carlos no dio demasiada importancia al tema de Hitos y le parecía bien la propuesta de Mario, pero en cambio Francisco, prestó más atención en los Hitos y le comentó a Mario, “Me parecen bien los Hitos que propones para que comprobemos como vamos en cada punto crítico de la parte que nosotros vemos del Proyecto, pero echo en falta algún hito para controlar los trabajos que hacéis vosotros y que nosotros inicialmente no vemos, como por ejemplo el diseño técnico de la solución y la evolución de los desarrollos de las personalizaciones”. No es que Mario no ha previsto esos Hitos, sino que no los presenta al Cliente, pero sí que los tiene previstos internamente, se los guarda para tener un margen de maniobra interno, Francisco lo que pretende con esto es controlar más pasos clave del Proyecto y ejercer más presión para asegurarse el cumplimiento de fechas y costes. ***** Si soy el Cliente Hay que intentar controlar y supervisar el estado de cada uno de los pasos importantes del Proyecto tanto del Equipo del Cliente que el Proveedor no ve, como los pasos que se comparten entre los dos, y también los que hace el Equipo del Proveedor que normalmente no ve el Equipo del Cliente. 93

***** Si soy el Proveedor Se han de establecer dentro de la planificación, sobretodo en cada uno de los Hitos, colchones de tiempo de margen para cubrir posibles imprevistos (Buffers), que normalmente se acaban necesitando y que si no se tienen previstos en la planificación inicial y pactada con el Cliente, automáticamente provocan un retraso en la planificación, prácticamente imposibles de remediar. La duración de cada (Buffer) depende de la complejidad de las tareas que preceden al hito y por lo tanto del riesgo que se corre en la ejecución de las mismas y de la diversidad de participación en la ejecución de estas tareas, me explico, si estas tareas dependen de personal de mi Equipo solamente, o depende de personal de mi Equipo, de personal del Cliente o incluso de personal de un tercero. ***** Si soy el Cliente o el Proveedor, indistintamente En el momento que llega la fecha en la que revisamos un Hito y no se han finalizado satisfactoriamente las tareas que permiten el cumplimiento de ese Hito, no podemos seguir adelante sin analizar que tareas faltan y porque y cuando se van a realizar y finalizar, si esto afecta a la planificación de las tareas e Hitos siguientes se tendrá que 94

replanificar y ajustar las asignaciones de todos los recursos implicados tanto por parte de las tareas del Proveedor como de las del Cliente.

***** ¿Cómo va el Proyecto? La mejor forma de saber cómo va el Proyecto es teniendo en cuenta los 4 pilares necesarios para el control y seguimiento del mismo. Los pilares normalmente sujetan algo y en este caso lo que sujetan es el Proyecto, así si convertimos los 4 pilares en patas de mesa y el Proyecto en el tablero de la misma podemos hacer que el control de Proyectos se comporte como una mesa. Mario para saber cómo va el Proyecto, es decir controlarlo y seguirlo, utiliza la teoría de la mesa, por una parte tiene el Proyecto dado de alta en una aplicación de gestión y control de Proyectos, donde se ha dado de alta el presupuesto desglosado al nivel necesario y donde los recursos que participan en el Proyecto por parte del Proveedor, van imputando los trabajos que van realizando. Por otra parte Mario realiza reuniones periódicas con Carlos y Francisco para ver cómo va el Proyecto según el Cliente. Además Mario también realiza reuniones periódicas con su Equipo de Proyecto. Finalmente Mario, con la información que le da la aplicación de gestión de Proyectos, las reuniones con el Cliente y con su Equipo, le permite poner la 4ª pata de la mesa, con sus actuaciones según su criterio y experiencia que han de permitir que el Proyecto siga 97

correctamente su camino, o lo que es lo mismo que el tablero de la mesa siga estable y firme. ***** Si soy el Cliente Hay que exigir al Proveedor que realice reuniones de seguimiento periรณdico conjuntamente con nosotros para poder controlar y revisar cรณmo va el Proyecto. ***** Si soy el Proveedor Hay que ser muy disciplinado ยกy cuando no! con las reuniones de seguimiento tanto con el Cliente como con nuestro Equipo, ya que estas reuniones nos permiten poder hacer correctamente el control y seguimiento del Proyecto, no debemos olvidar que semana que pasa semana que no se recupera y problema que no resolvamos en el momento que aparece, problema que nos encontraremos mรกs adelante y seguramente mรกs grande y complejo. *****

Teoría de la mesa Ya hemos hablado sutilmente de la teoría de la mesa en el apartado “¿Cómo va el Proyecto?”, en este apartado hablaremos con más detenimiento de cada una de las patas de la mesa que sostienen el tablero. La primera pata de la mesa es tener un sistema de gestión de Proyectos donde poder dar de alta el Proyecto con su presupuesto desglosado, donde los recursos del Equipo de Proyecto puedan imputar los trabajos realizados periódicamente y el Jefe del Proyecto pueda revisarlos, además de poder comprobar la situación del Proyecto comparando lo presupuestado con lo consumido.

La segunda pata de la mesa son las reuniones peri贸dicas de seguimiento con el Cliente, que han de estar planificadas con antelaci贸n, se ha de levantar acta de lo comentado y si son para revisar o confirmar alg煤n Hito se comprobar谩 que se han cumplido correctamente todas las tareas precedentes y que cumplen el Hito.

100

La tercera pata de la mesa son las reuniones periódicas de seguimiento con el Equipo del Proveedor, que han de estar planificadas con antelación, se ha de levantar acta de lo comentado y el Jefe del Proyecto ha de tener la precaución de realizar con la máxima antelación posible a la entrega de algún paquete de servicios al Cliente, para tener tiempo de maniobra si las cosas no van como se establecieron en la planificación del Proyecto, en cuanto a las tareas responsabilidad del Equipo del Proveedor.

101

La cuarta pata de la mesa son los seguimientos individuales que realiza el Jefe del Proyecto, donde analiza toda la información obtenida en las otras tres patas de la mesa, y según el resultado de este análisis toma las acciones correctivas necesarias para que el tablero de la mesa vuelva a estar firme y estable, la verdad es que después de este análisis siempre hay acciones correctoras que realizar, aunque si se están siguiendo correctamente todos los pasos de la gestión de Proyectos deberían ser de poca envergadura y alcance.

102

Si no se tiene una de estas cuatro patas el tablero se cae. Si tenemos las cuatro patas pero no se cuidan ni se revisan periĂłdicamente, puede ser que una o varias de las patas se afloje y se caigan con lo que tambiĂŠn se caerĂĄ el tablero. Si tenemos las cuatro patas pero no las cuidamos ni revisamos con la periodicidad adecuada, puede ser que al revisarlas tengamos que hacer reparaciones o ajustes con 103

un coste elevado económicamente y en tiempo, cosa que provocará inestabilidad y falta de firmeza en el tablero, con las consecuencias que eso pueda tener, ya que en el tablero está sentado el Cliente y notará los golpes y zarandeos. ***** Método Integrado para la Gestión del Proyecto Si utilizamos las diferentes Etapas del Proyecto que hemos definido anteriormente en el Capítulo 7 ¿Cada Proyecto requiere las mismas etapas?, y lo superponemos con los diferentes Hitos que hemos definido en este capítulo, obtendremos un Método Integrado para la Gestión del Proyecto, donde se establecen cronológicamente las diferentes Etapas e Hitos del Proyecto, que nos servirán como base Metodológica para la Gestión y el Control de los Proyectos en general. El diagrama que obtenemos es el siguiente:

104

105

***** El Proyecto va mal, ¿Y ahora qué hago? Si por desgracia hemos llegado al punto en el que el Proyecto está totalmente descontrolado, lo más razonable es pararse, analizar la situación entre Cliente y Proveedor y de una forma objetiva, clara, transparente y honrada, establecer documentalmente las directrices de cómo devolver el Proyecto a su cauce. Seguro que encontrándonos en esta situación del Proyecto las expectativas tanto del Cliente como del Proveedor en el Proyecto han de ser diferentes en la medida que sea necesario para que el Proyecto se pueda encauzar, por lo tanto si se quiere llegar a un acuerdo, es imprescindible que ambas partes estén dispuestos a ceder en alguna cosas, ya que llegada esta situación no hay mucho donde elegir para volver al buen camino. Una vez aclarados todos los puntos y teniendo claras las acciones a realizar, tal como comentaba antes, se ha de documentar cada una de las acciones, sus responsables, su coste, la planificación exhaustiva y firmar este documento como un anexo al documento de Análisis que se realizó inicialmente. Con esto y siguiendo los pasos adecuado de la gestión de Proyectos “de la que no nos teníamos que haber salido”, tenemos una nueva y última oportunidad de hacer el Proyecto como es debido, ya que si se vuelve a fallar difícilmente saldrá otra oportunidad para hacer el Proyecto con este Cliente o Proveedor. 106

107

Capítulo 9 ¡Psicología en los Proyectos! ¿Qué me estás contando? ________________________________________________ ***** Introducción a la Psicología de Proyectos Hay una parte muy importante en la gestión de Proyectos ¡y qué parte no la es!, donde la psicología juega un papel decisivo, con diferente intensidad y con cambio de actores en función de la etapa del Proyecto, donde los mayores “oteadores” de estos temas psicológicos son los Jefes del Proyecto, principalmente del Proveedor, y si se presta atención a esta parte y se obra en consecuencia puede resolver muchos problemas anticipadamente y reducir costes y tiempo que ayudan al cumplimiento de costes y fechas previstas en el Proyecto. Vamos hacer hincapié en algunas áreas y etapas del Proyecto centrándonos en la parte psicológica, que en algunos casos se realiza pero no se presta atención a este tema y por lo tanto no se aprovecha esta información, y en otros casos simplemente no se realiza y por lo tanto se obtienen los mismos resultados, o sea nada. ***** En el Equipo del Cliente 108

A la hora de seleccionar el Equipo de Cliente, ya hemos hablado en el Capítulo 2 ¡Equipo de Proyecto!, de los roles y responsabilidades de los mismos, pero imaginaros el supuesto siguiente: Carlos a la hora de seleccionar el Equipo de Proyecto, como responsable del área Comercial lógicamente piensa en Raúl, pero resulta que Raúl está completamente en contra de implantar un sistema CRM nuevo en la empresa, el da sus motivos pero los motivos reales son que no quiere que la información comercial deje de ser de su dominio exclusivo y no quiere dedicar tiempo al Proyecto porque lo encuentra una pérdida de tiempo que él no tiene ni quiere tener. Sí que es cierto que conoce perfectamente todos los procesos comerciales y sabe cuáles son las necesidades de su departamento además de ser el máximo responsable del mismo. Carlos decide comentar este tema con el Director General y con Arturo, finalmente toman la decisión de incorporar al Equipo de Proyecto a un Comercial con experiencia en cambios de sistema informático en otra empresa en la que estuvo y que lleva el tiempo suficiente en la empresa como para conocer perfectamente todos los procesos y necesidades, sin que esto prive de que las decisiones más importantes sobre procesos las tome Raúl.

109

El Director General explica a Raúl que como él no tiene tiempo de dedicarse al Proyecto que se asigna a este Comercial en su nombre pero que Raúl es el que tomará lógicamente las decisiones que afecten a su departamento. En estos casos es mejor buscar alternativas de este tipo o parecidas desde el principio ya que el tener a Raúl en el Equipo de Proyecto durante todo el Proyecto seguro que tendría consecuencias en costes y tiempo incalculables, muy superiores a las necesarias para realizar este ajuste en la confección del Equipo del Cliente, que normalmente se produce antes de empezar el Proyecto. Esto no significa que con esto ya nos hemos quitado de encima el problema ya que no es cierto, lo que conseguimos con esto es eliminar algunos problemas y reducir otros, es decir reducir riesgos. Hay que contar que el Equipo del Proyecto por parte del Cliente, además de su actividad laboral principal, recae sobre ellos un trabajo adicional importante del que hay que ser consciente, del que la mayoría de veces no se es y de la importancia que tienen sus tareas para la buena marcha del Proyecto. *****

110

En el Equipo del Proveedor El Equipo del Proveedor no tiene el problema de que su actividad laboral habitual es una y además recaen sobre ellos las tareas propias de Proyecto, sino que su actividad laboral habitual es hacer Proyectos; pero tienen un problema psicológico que les afecta continuamente, porque es propio de trabajar en Proyectos de sistemas de información y a esto es precisamente a lo que se dedican todos los días del año. La palabra Proyecto tiene varios significados parecidos según el ámbito en el que se utilice, una posible definición que se acerca al entorno de los Proyectos informáticos del caso que nos acontece puede ser la siguiente: “Un Proyecto es un conjunto de pasos o tareas, ordenadas cronológicamente y siguiendo criterios de precedencia para la consecución de un objetivo predeterminado. El Proyecto asigna recursos a cada tarea y considera los factores de riesgo que están en juego de forma tal de evitar los retrasos en los plazos previstos.” Teniendo en cuenta que para cada Proyecto hay unas tareas concretas y que varían en función de la solución y requerimientos de cada Proyecto. Teniendo en cuenta también que cada Proyecto cuenta con un Equipo del Cliente diferente y que en muchos casos también cambia el Equipo del Proveedor por lo menos en alguno de sus actores.

111

Nos encontramos que el Equipo del Proveedor está sometido a una presión continua importante, ya que lo que están haciendo en su día a día “es crear” algo nuevo y crear no es fácil, “aunque te dediques todos los días”. Por lo tanto teniendo en cuenta estos factores, la presión psicológica de estas personas es muy alta y tenemos que cuidar mucho que esta presión psicológica no les afecte seriamente. Para ello el Jefe de Proyecto tiene un papel importante ante el Equipo y frente a este problema cotidiano. El mayor problema que se presenta con los participantes en Equipos de Proyectos, y que va creciendo de la mano del volumen de Proyectos que realizan y de la complejidad de los mismos, es la sensación de realizar mal las tareas relacionadas con los mismos, y como esta es su actividad principal acaban por pensar que son malos técnicos “permitirme que diga que hay veces que somos malos de verdad, pero solo a veces”, y este es un problema contra el que tenemos que luchar con uñas y dientes. La primera cosa que tenemos que conseguir es un Equipo de Proyecto que sea un Equipo de verdad, donde se fomente la colaboración y el apoyo y cada uno sea responsable de sus tareas asignadas y documentadas correctamente claro está. Que expliquemos a todo el Equipo el Proyecto con detalle y que todos puedan participar dentro del nivel de responsabilidad que cada uno tiene en el Proyecto. 112

Que todo el Equipo tenga la información y documentación necesaria para conocer y ejecutar el Proyecto en la parte que sea responsable. Realizar reuniones de seguimiento con el Equipo para explicar la evolución del mismo y para recoger posibles quejas o solicitudes de los participantes y obrar en consecuencia de las necesidades. Realizar reuniones individuales con las personas del Equipo a las que veamos agobiadas para intentar ayudarles de una u otra forma. Fomentar la colaboración y apoyo entre el Equipo. Al finalizar los Proyectos analizar las cosas que se han realizado mal para intentar mejorarlas en el próximo Proyecto. Felicitar al Equipo al finalizar el Proyecto por el esfuerzo realizado y publicitar internamente el cierre del Proyecto exitoso.

Con todas estas medidas conseguiremos que el Equipo se mantenga a un nivel de “agobio y estrés” soportable y que la rotación de personal sea más baja, a su vez estos factores afectan positivamente a los Proyectos, ya que se realizan con la cabeza más fría y con recursos más experimentados, lo que a su vez ayuda a reducir el nivel de agobio y estrés, en fin “la sardina que se muerde la cola”.

113

***** Al implantador/es de la solución principalmente La presión psicológica a la que nos hemos referido en el apartado anterior, se denota principalmente en el recurso o recursos que realizan la implantación de la solución en el Cliente (depende de para quien puede cambiar este nombre, Consultor Funcional, Implantador, etc.). Esta persona recibe una presión especial, ya que es la “cabeza visible habitual” en las oficinas del Cliente y el que va a dar forma “física” a la solución y por lo tanto se encuentra de primera mano con las aceptaciones o reacciones adversas del Equipo del Cliente cuando ven el funcionamiento de la solución. Además en muchos casos el Equipo del Cliente les pide tareas adicionales o diferentes de las previstas a realizar por estos recursos y difícilmente pueden acabar la jornada habiendo realizado única y exclusivamente las tareas que tenían previsto realizar. Carlos comenta a Marcos durante una de las sesiones de implantación de la solución, que ya que está importando los contactos a la base de datos del CRM, porque no añade un campo nuevo que no estaba previsto pero que le iría muy bien tenerlo. También se encuentran con dificultades a la hora de que el Equipo del Cliente realice tareas propias del Proyecto de las que son responsables con el consiguiente

114

enfrentamiento para conseguirlo o el retraso que genera el no conseguirlo. Marcos comenta a Carlos durante una de las sesiones de implantación de la solución, que necesita el fichero de tareas de los vendedores para poder importarlos a la base de datos del CRM tal como estaba previsto para hoy, pero Carlos le comenta que no lo tiene preparado porque está acabando de preparar el portátil nuevo del Director General y que hasta que no acabe no puede hacer nada más, ya que tiene prioridad absoluta. La primera cosa que tenemos que conseguir para evitar estas cosas tan habituales como Jefe del Proyecto del Proveedor es dejar planificada cada una de las sesiones de implantación en la planificación y con las tareas a realizar en cada una de ellas, dejando un margen de tiempo sin planificar de cada jornada para cubrir pequeños imprevistos que siempre hay. Y por otra parte y relacionado con el párrafo anterior, concienciar al implantador y al Equipo del Cliente, que no se hará nada que no esté en el documento de Análisis del Proyecto y que el implantador no tiene permiso para realizar nada que no le diga el Jefe del Proyecto del Proveedor, por lo tanto cualquier cambio o petición pasará siempre por el Jefe del Proyecto del Proveedor.

***** En el Kick-Off del Proyecto

115

El Jefe del Proyecto del Proveedor no se dedica simplemente a presentar el Proyecto, que ya hemos comentado en el Capítulo 3 El Kick-Off del Proyecto, el nacimiento de un nuevo Proyecto, sino que está buscando la aprobación o no de cada uno de los participantes del Equipo del Cliente en varias cosas, en los objetivos y alcance del Proyecto, en la necesidad de crear un Equipo entre el Cliente y el Proveedor colaborativo, que el Proyecto no lo puede hacer solo el Equipo del Proveedor y que es necesario el Equipo del Cliente, que hay muchas tareas que las ha de realizar el Equipo del Cliente y que han de estar listas en un momento concreto, que estas tareas suponen una dedicación importante en algunos momentos del Proyecto y que supone una carga adicional para el que las realiza, etc. Normalmente alguno de los participantes del Equipo del Cliente pone “caras raras” en alguno de estos comentarios o hace algún comentario del tipo, “Pues yo no tengo tiempo, no sé cómo lo voy hacer” o “Pues yo pensaba que vosotros lo hacíais todo”. Esta “observación” por parte del Jefe del Proyecto del Proveedor permite detectar en un porcentaje muy elevado a lo que en las escuelas de negocios se llaman vulgarmente como “Francotirador” y/o “Bombardero” y también va bien para detectar, ya que estamos en estos derroteros y para demostrar que no todo es malo al “Aliado” que hace comentarios como: “Cuando empezamos” o “Ya era hora que nos pusiéramos con un sistema nuevo que resuelva algunos problemas”, etc. 116

La actitud del Jefe del Proyecto por parte del Proveedor ha de ser diferente en cada caso, frente al “Aliado” hacerle partícipe al máximo nivel dentro del Proyecto y mimarlo para conseguir que nos ayude todo lo posible, para que el Proyecto vaya bien y con respecto al “Francotirador” y/o “Bombardero” hablar con el Jefe del Proyecto del Cliente para intentar cambiarlos o que los controle el mismo, normalmente al comentarles este tema el mismo reconoce la complejidad de tratar con ellos y no solo en este tema sino en la relación laboral en general. Esto como se puede deducir es un problema que hay que valorar y controlar tanto en la valoración de riesgos como en la ejecución de todo el Proyecto donde estos actores participan, si es que no los cambian. ***** En la Formación a los responsables de área Durante esta formación la función de “oteadores” no solo es para el Jefe del Proyecto del Proveedor sino que también es para la persona del Equipo del Proveedor que imparte la formación, el formador además de dar la formación tal como se establece en el Capítulo 7 apartado Formación antes del Análisis, ¿Para qué?, debe estar atento a la actitud de cada uno de los participantes en la formación por parte del Equipo del Cliente y de cómo se desenvuelven, por ejemplo: Marcos se da cuenta de que Arturo no maneja el ratón con soltura y que le cuesta mucho moverse por la 117

aplicación. Cuando termina la sesión de formación Marcos comenta a Mario que hay que prever más formación de la habitual para Arturo y le cuenta los motivos, Mario agradece la apreciación y dice que lo tendrá en cuenta en la valoración de servicios. Otro ejemplo puede ser: Durante el descanso de la jornada de formación Mario está pendiente y se acerca al Equipo del Cliente que está tomando café y les pregunta ¿Cómo va la formación? ¿Qué os parece la aplicación? ¿Os encajan los procesos a alto nivel o no? ¿Dónde veis más diferencias en comparación con vuestra forma de trabajar? ¿Os podéis adaptar? Con estas preguntas y sus respuestas Mario va viendo varias cosas, como por ejemplo, como están encajando la aplicación cada uno de ellos, en que procesos vamos a encontrar más problemas, donde se tiene que poner más hincapié en el Análisis posterior, seguir detectando si hay “francotiradores” y/o “bombarderos” y/o “aliados”, etc.

118

***** Para el cierre del Proyecto Hay que tener en cuenta que para cerrar el Proyecto la solución tiene que estar implantada y funcionando correctamente, esto es algo imprescindible lógicamente, pero aun así es muy difícil cerrar el Proyecto y esto es un objetivo final que hay que ir persiguiendo desde el principio y que requiere ir “sembrando” desde el inicio para poder finalmente “recoger” el cierre, tal como comenté en el apartado ¿Cerramos el Proyecto? del Capítulo 7: ¿Cada Proyecto requiere las mismas etapas? 119

Por lo tanto es importante por lo menos resaltar el tema del cierre del Proyecto en las siguientes etapas del mismo: o En la etapa de preventa se explica la metodología de la gestión del Proyecto donde uno de los puntos es el cierre del mismo. o En el Kick-Off, una de las cosas que explica el Jefe del Proyecto es la metodología de la gestión del Proyecto donde aparecen los principales Hitos y por supuesto uno de ellos es el Cierre del Proyecto. o En la planificación del Proyecto que se adjunta al documento de Análisis una de las tareas e Hitos que aparecen es el cierre del Proyecto. o Al reservar las agendas de las reuniones de seguimiento entre los Jefes del Proyecto del Cliente y el Proveedor una de las citas es el cierre del Proyecto. Con esto que se pretende, pues lo mismo que los anuncios de televisión, que a base de ver un producto una y otra vez al ir a comprar, compres ese producto y no otro, con un porcentaje muy elevado, lógicamente no al cien por cien, con el cierre del Proyecto pasa algo parecido. Tal como se ha comentado anteriormente para poder cerrar el Proyecto la solución tiene que estar implantada y funcionando correctamente, pero si no hemos comentado, documentado, pactado, establecido y no sé cuántas cosas más sobre el cierre, difícilmente se puede cerrar el Proyecto cuando llegue la fecha de este Hito. 120

Hay que tener en cuenta que “si pudiéramos tomar la temperatura del Proyecto” durante cada una de sus etapas nos encontraríamos el símil siguiente: o En la firma del contrato del Proyecto la temperatura es de unos 23º. o Tal como va evolucionando la etapa de Análisis la temperatura va desde unos 24º a unos 28º, volviendo a los 25º en el Hito de firma del documento de Análisis. o Durante la etapa de Diseño Técnico y Desarrollo la temperatura puede subir uno o dos grados por la incertidumbre de no saber qué es lo que está haciendo el Equipo del Proveedor. o Durante la etapa de Implantación o Despliegue se pasa de los 26º al principio de la Implantación hasta los 30º justo antes de la Puesta en Marcha. o Durante la puesta en Marcha en pocos días se pasa de los 30º a los 40º, si la cosa va bien al final del Soporte a la puesta en Marcha se han bajado unos grados, tres o cuatro como mucho. Eso significa, que para el Hito de cierre de Proyecto, hay “mucho calor” y todo el Equipo está “sofocado y acalorado”, sobre todo el Equipo del Cliente, esto supone que no sea fácil cerrar el Proyecto en este momento, “como para no tenerlo preparado y anunciado con antelación, premeditación y alevosía”.

121

122

123

Dedicatoria y Agradecimientos

________________________________________________ Dedicatoria Quiero dedicar este libro a mi padre, José Navarro Grau, que aunque ya hace unos años que no está físicamente, estoy seguro de que donde esté, estará orgulloso de la autoría del mismo.

T’estimo.

Agradecimientos No ha sido nada fácil escribir este libro, y no hubiera sido posible sin la colaboración de muchas personas de mi entorno familiar y profesional, y quiero agradecer a todos ellos su aportación a mis vivencias y conocimiento, a la vez que el tiempo que les he robado para conseguir realizar este Proyecto personal, de plasmar parte de mi experiencia en este libro. Quiero agradecer a mi mujer Mari Carmen la complicidad con la que hemos llevado adelante todos estos años que estamos juntos, compaginando la vida personal con la profesional y afrontando con éxito las diferentes etapas y retos que se nos han presentado, también a mi hija Judit, por su participación en este libro con las viñetas dibujadas electrónicamente entre otras cosas, con la que por otra parte, me estoy graduando como persona y con la que lleno un hueco de mí que antes de que ella estuviera no sabía ni que existía.

Gracias.

Miguel Ángel

124

125

Bibliografía y Nota Pongo unos cuantos libros que he leído y que me han ayudado de una u otra forma o en menor o mayor medida a gestionar los Proyectos un poco mejor cada día.

La Meta de Eliyahu M. Goldratt La Cadena Crítica de Eliyahu M. Goldratt Dirigir Proyectos de Andy Bruce y Ken Langdon

“La Vida” el autor somos cada uno de nosotros, la editorial es nuestra mente y la edición impresa es nuestro conocimiento.

Nota del autor Una vez leído el libro, como es natural, seguro que no compartes conmigo la totalidad de las cosas que digo, aconsejo o comento, “aunque espero que por lo menos compartas alguna”, pero si te he hecho reflexionar, abrir los ojos, o cualquier otra sensación de este tipo, en alguna de las cosas relacionadas con la Gestión de Proyectos, que te ayude a mejorar en el próximo Proyecto en el que tengas que actuar con cualquier papel o guión, ya ha valido la pena editar este libro. Gracias. Miguel Ángel

126

127

128