Las Claves para gestionar Proyectos TI
-
Upload
miguel-angel-navarro-hellin -
Category
Documents
-
view
217 -
download
2
description
Transcript of Las Claves para gestionar Proyectos TI
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