1

2

3

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

4

5

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

6

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.

7

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.

8

9

Las claves para gestionar

Proyectos de sistemas de

información

Por Miguel Ángel Navarro

10

11

Í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

12

13

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:

14

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.

15

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.

16

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

17

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

18

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

19

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

20

21

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

22

del Proyecto muy relacionadas con los procesos

empresariales y que por lo tanto este nivel

jerárquico es importante.

o Tener una visión general del Proyecto para no

dejarse influenciar por decisiones o necesidades

puramente departamentales o de área concreta.

o Tener capacidad resolutiva y de toma de decisiones

con relativa agilidad, para evitar desviaciones

importantes sobre la planificación.

o Tener conocimientos generales de todos los

procesos de la compañía.

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

23

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

24

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.

25

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.

26

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.

27

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.

28

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.

29

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.

30

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.

31

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.

32

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

33

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”:

34

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.

35

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

36

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

37

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.

38

*****

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.

*****

39

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.

40

*****

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.

41

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

42

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

43

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.

*****

44

¿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?

45

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.

46

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

47

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.

48

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:

49

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.

50

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.

51

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.

52

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.

53

54

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

55

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.

56

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.

57

58

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,

59

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.

60

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

61

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

62

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

63

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.

64

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

65

66

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

67

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

68

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.

69

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.

70

*****

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

71

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.

72

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.

73

*****

74

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.

75

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

76

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.

77

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

78

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

79

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.

80

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.

81

82

*****

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

83

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.

84

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

85

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

86

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

87

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

88

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.

89

90

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

91

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.

92

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.

93

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.

94

*****

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

95

replanificar y ajustar las asignaciones de todos los

recursos implicados tanto por parte de las tareas del

Proveedor como de las del Cliente.

96

97

*****

¿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

98

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.

*****

99

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.

100

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.

101

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.

102

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.

103

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

104

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:

105

106

*****

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.

107

108

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

109

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.

110

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.

*****

111

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.

112

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.

113

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

114

*****

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

115

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

116

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.

117

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

118

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.

119

*****

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?

120

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.

121

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

122

123

124

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

125

126

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

127

128