implantación de tecnología desde la aportación de valor al negocio

GESTIÓN DE PROYECTOS

Una aproximación a la implantación de

tecnología desde la aportación de valor al

negocio*

*Este documento recoge una serie de ideas y notas extraídas de la experiencia y de la consulta de

bibliografía especializada. Pretende ser una ayuda, que mediante su lectura critica y la comparación

con la experiencia, permita reflexionar a cerca de las mejores prácticas a la hora de gestionar, realizar

o analizar un proyecto tecnológico. Esta formación tiene el objetivo de ser la base de discusión de las

diferentes experiencias en los proyectos Management Intelligence

Notas e ideas para la gestión de proyectos 2 de 24

Preparado por Enric Balcells - 2012

Contenido

INTRODUCCIÓN A LA GESTIÓN DE PROYECTOS ....................................................................... 3

Principales fases de un proyecto tecnológico ..................................................................... 3

DEFINICIÓN DEL PROYECTO ............................................................................................. 4

METODOLOGÍA DE IMPLANTACIÓN ..................................................................................... 5

Planificación de proyectos ........................................................................................... 5

Tareas relacionadas con la planificación .......................................................................... 6

Requerimientos ......................................................................................................... 6

Control y seguimiento del proyecto ................................................................................ 7

Reuniones de Revisión ................................................................................................. 8

Ejemplo de metodología de trabajo ................................................................................ 9

ORGANIZACIÓN DEL PROYECTO ........................................................................................ 13

Funciones y Responsabilidades: .................................................................................... 13

Cualidades del “Analista de Necesidades”: ...................................................................... 14

Cualidades del “Project Manager”: ................................................................................ 14

CARACTERÍSTICAS DE LOS PROYECTOS: CONFLICTOS, FACTORES DE ÉXITO Y CUESTIONES POLITICAS ... 15

Fuentes potenciales de conflictos ................................................................................. 15

Factores de éxito ..................................................................................................... 16

Cuestiones políticas en los proyectos ............................................................................. 16

ACEPTACIÓN Y CIERRE DEL PROYECTO ............................................................................... 18

Pruebas y validación .................................................................................................. 18

Entrega y uso .......................................................................................................... 18

METODOLOGÍA DE PROYECTOS MANAGEMENT INTELLIGENCE .................................................... 19



INTRODUCCIÓN A LA GESTIÓN DE PROYECTOS

La definición tradicional utilizada en los cursos de gestión de Proyectos Tecnológicos dice que:

Un proyecto es un esfuerzo único y planificado para producir resultados específicos, dentro de

unos límites de tiempo, coste y calidad previamente definidos y autorizados.

El proyecto comienza cuando el usuario define lo que necesita y finaliza cuando el usuario acepta

el trabajo realizado.

Existe una triple restricción: tiempo, coste y especificaciones marcadas por las necesidades y el ámbito

del proyecto. En resumen, se trata de:

Cumplir los objetivos y resultados planteados

Realizarlo en tiempo predeterminado

Elegir los recursos acertados consumiendo lo mínimo

Desde una perspectiva más relacional, más humana, la gestión de proyectos es una gestión de

expectativas, una gestión de las necesidades y la satisfacción del cliente.

Es, por tanto, una gestión de expectativas que llevan a la satisfacción del cliente y que nos obliga a

realizarnos las siguientes preguntas, siempre desde una perspectiva amplia, teniendo en cuenta que en

nuestros proyectos tratamos con múltiples clientes y cada uno de ellos puede tener intereses diversos:

¿Quién es nuestro cliente?

¿Qué quiere?

¿Cuándo tiene razón?

¿Cuándo no la tiene?

Principales fases de un proyecto tecnológico

1. Estudio de viabilidad y/o preventa: definición de los objetivos a cumplir por el sistema o

solución

2. Análisis o diseño de la solución: se trata del diseño conceptual, funcional y tecnológico

3. Realización o desarrollo

4. Instalación y puesta en marcha



DEFINICIÓN DEL PROYECTO

La definición del proyecto puede realizarse en 10 pasos:

1. ¿Qué se necesita? Metas y objetivos: definición del problema

2. ¿Qué se quiere conseguir? Composición del equipo. Factores de éxito, descripción del proyecto

y alcance

3. ¿Cuánto costará y cómo se hará? Esquema de las fases. Presupuesto inicial

4. ¿Qué comportará? Tareas y actividades

5. ¿Cuál es el mejor camino? Definir los hitos y los entregables de cada hito

6. ¿Quién hará qué? Plan de proyecto. Esquema de responsabilidades

7. ¿Cuánto se tardará en cada tarea? Duración y tiempo de cada tarea

8. Fecha de terminación

9. Recursos

10. Plan de proyecto definitivo

En resumen, los principales elementos de la definición son:

Alcance: Poner limites en aquello que debe o no se debe incluir en el proyecto. Tan sencillo (y

complicado) como enumerar aquello que está “Incluido o Excluido”

Necesidades: Partiendo de la suposición que los clientes no tienen una visión precisa,

detallada y documentada de lo que realmente quieren y necesitan, será necesario incluir toda

la información posible, las restricciones, suposiciones y contratiempos, relacionando toda la

información que no encaja

Entorno y Ámbito: Viene definido por la parte de la estructura interna de la empresa que esta

afectada en sus funciones por la solución a implantar



METODOLOGÍA DE IMPLANTACIÓN

Se parte de la descomposición del proyecto en FASES, ETAPAS y ACTIVIDADES. Aquí se aplica el

principio de dividir el trabajo a realizar para que sea asumible y sobretodo controlable.

Cada fase y cada etapa dentro de su fase, deben tener unos objetivos definidos y producir unos

resultados tangibles y medibles.

Planificación de proyectos

El ciclo de vida del proyecto se descompone en fases, actividades y tareas, los elementos clave son:

Estimar el contenido del trabajo a realizar, significa definir:

Qué hacer

Quién lo debe hacer

Cuánto tiempo se necesitará

Qué recursos serán necesarios

Estimar la duración, las personas disponibles y % de dedicación, los tiempos improductivos (vacaciones,

aprendizajes,...) y la fecha de terminación de cada actividad y los hitos del Proyecto.

Planificar el trabajo también significará determinar el grado y forma de dependencia entre actividades

e hitos y, el detalle con que se elabore dicho plan, dependerá del tipo de proyecto, de la composición

del equipo y de los requerimientos de la solución a implantar.



Tareas relacionadas con la planificación

1. Definir el ciclo de vida del proyecto y sus fases

2. Definir los puntos de control; revisiones e hitos

3. Descomposición de tareas hasta que todas las actividades puedan ser visibles y medibles,

teniendo en cuenta:

Grado de incertidumbre de las tareas a realizar

Importancia del proyecto y recursos a utilizar

Experiencia en el proceso

Necesidades de información y de control

En general, los trabajos a realizar relacionados con la planificación serán:

Definir la estructura de trabajo del proyecto; grupos, subgrupos y colaboradores. Datos

generales del proyecto

Descomposición de tareas y asignar las actividades a la estructura de trabajo

Definir las interrelaciones y dependencias entre las actividades. Establecer los Hitos del

proyecto

Estimar la duración de cada actividad. Definir tipo y cantidad de los recursos necesarios para

realizarla

Calcular la fecha de finalización más probable. Identificar las actividades críticas. Definir los

puntos de control intermedios y las fechas correspondientes

Realizar la suma de necesidades de recursos por tipo de recurso

Reajuste del calendario (fechas iniciales, fechas intermedias y finales) para una óptima

utilización de los recursos

Reagrupar todas las informaciones de las tareas; actividades y recursos en los puntos de control

Definir los procedimientos: metodología y normas a aplicar durante el proyecto

Definición de técnicas y herramientas de planificación y control necesarios para gestionar el

proyecto: Check List y análisis de riesgos e incertidumbres y Diagrama de Gantt

Requerimientos

Es muy difícil que un proyecto sea un éxito cuando en la 1ª etapa no se han identificado correctamente

las necesidades y no se han establecido correcta y detalladamente los requerimientos y las

especificaciones.

El trabajo de análisis de necesidades no es una tarea fácil, y en la mayoría de los casos no se ha

recibido una formación específica. La mayoría de consultores que participan y gestionan un proyecto,



lo hacen en base a unos conocimientos técnicos del proceso que se quiere mejorar y/o de la tecnología

que se quiere implantar… Nótese que en muchos casos, solo se es experto en una de las dos variables, y

muchas veces, en ninguna de las dos.

Principales problemáticas relacionadas con los requerimientos:

A. Requerimientos Incorrectos

B. Requerimientos imprecisos o ambiguos, por:

Naturaleza del lenguaje humano

Sacrificar precisión por flexibilidad

Consensuar debido a un conflicto humano

Intangibilidad de los recursos

Falta de experiencia del usuario / cliente

Incorrectas verificaciones de los planes

C. Cambios en los requerimientos del proyecto y del producto una vez iniciado el proyecto

Reglas generales para establecer requerimientos:

Establecer requerimientos explícitamente y mantener a los miembros del proyecto y a los

usuarios / clientes informados

Ser realista, asumir que los requerimientos pueden ser malinterpretados. No usar palabras

como; etcéteras, algunas veces, frecuentemente, se intentará, se hará lo posible por, ...

Ser realista, reconocer que habrán cambios en el proyecto y que las cosas no van a suceder

como se anticiparon

Establecer un sistema para monitorizar cuidadosamente los cambios realizados en los

requerimientos (Control de Cambios)

Educar al equipo de proyecto y al usuario / cliente en los problemas de ciertos requerimientos

Control y seguimiento del proyecto

La clave es evitar los informes de situación como algo burocrático o tedioso1. Deben ser los adecuados

para el seguimiento del proyecto y fáciles de cumplimentar. Por lo tanto, es recomendable buscar el

formato más cómodo y adecuado al tipo de proyecto que nos ocupe, asegurando:

Realizar informes de seguimiento de forma regular:

Las Actividades y Tareas: de forma Diaria-Semanal. El “Diario del Navegante” del

consultor. Cada uno debe establecer el formato más cómodo, pero en cualquier caso, el

1 porqué al final nadie los lee y entonces… no sirven para nada!!



redactado y el contenido tiene que ser suficiente para entender el detalle de las tareas y

actividades realizadas

Los Hitos: Control Semanal-Mensual dependiendo del tipo de proyecto.

Emprender las acciones correctivas en el momento adecuado

Las re-planificaciones necesarias para realizar las acciones correctivas, deben pasar por los mismos

procedimientos de revisión y aprobación que la planificación inicial

La opinión “se trata de un pequeño cambio que no tiene que ser comunicado” es una de las

razones principales del descontrol del proyecto. La acumulación de los “pequeños cambios”

incontrolados inducen al fracaso del proyecto

El la categoría “pequeños-cambios” se incluye todas y cada una de las modificaciones que el cliente

(en sus distintas versiones y categorías) solicita o exige y que no estaban contempladas en el plan

inicial

El control y la periodicidad de este, lo marcan el tipo de proyecto y su duración, teniendo en cuenta

que muchas veces es tan o más complicado mantener controlado un proyecto de implantación de 6

semanas cómo uno de 12 meses.

La constancia documentada de lo que sucede realmente, es totalmente necesaria. La única forma de

disponer de una cronología de los hechos, de tener pruebas y, por lo tanto, de mantener un proyecto

bajo control, es documentar el día a día. Es un proceso personal, que requiere tiempo, adaptación y

encontrar las herramientas adecuadas, se trata de un aprendizaje continuo.

La evidencia documental es la redacción fluida de los hechos, con sujeto, verbo y predicado. Consiste

en escribir desde la perspectiva del lector, asegurando la el detalle y la comprensión.

Reuniones de Revisión

La agenda básica a preparar se compone de: (1) Progreso: desviaciones y sus motivos, (2) Posibles

problemas y posibles soluciones y (3) Próximos Pasos. El principal objetivo es mantener informado al

equipo de proyecto (o al Comité específico que se trate) y tomar las decisiones pertinentes

Y, como no podría ser de otra forma trabajando en proyectos, el seguimiento y la revisión implicarán

que aparece la ANSIEDAD

Compartir información es poder y por lo tanto, libera la ansiedad de los individuos

Se toman decisiones con poco tiempo y con poca información

Muchas veces, no se conoce como va a ser el producto hasta que finaliza

En las revisiones, una vez planteados los problemas, discutidos y analizadas las propuestas de solución,

se decidirán las acciones a realizar. En este punto, es importante destacar:



¿Cuántas veces nos preguntamos por qué tomamos una u otra decisión en un momento

determinado del proyecto?

¿Qué variables manejábamos en aquel momento y qué nos llevo a tomar una decisión en un

sentido u en otro?

Por lo tanto, es clave el concepto de “Hoja de Decisión”, como evidencia documental de las

decisiones que se toman. La cantidad de información que reflejará dependerá de muchos factores,

pero en cualquier caso, desde el punto de vista de la gestión, su conveniencia es indiscutible. Una

propuesta de contenido podría ser:

1. Propósito: Facilita la orientación y conocimientos sobre la decisión

2. Decisión: Una frase que comience por: “la decisión a tomar es ...”

3. Opciones: Indicar 2 o 3 alternativas con sus costes, ventajas e inconvenientes

4. Resumen: Reflejar el impacto de cada alternativa

5. Recomendaciones: Proponer una alternativa basada en las conclusiones del trabajo. Reflejando

claramente PROS (+) y CONTRAS (-) de la alternativa propuesta.

Una vez más, la documentación dependerá del tipo de proyecto. Lo que tiene que existir es el

documento, que sea un e-mail con el detalle o un documento cronológico especifico con todas las

decisiones desde el arranque, lo marcará el tipo de proyecto.

Ejemplo de metodología de trabajo

Como resumen de este capitulo, Metodología de Implantación, mostramos dos ejemplos de

descomposición de fases y elementos metodológicos, así como el detalle de un caso propuesto en un

cliente para una solución Board Management Intelligence:



ORGANIZACIÓN DEL PROYECTO

Este apartado trata de aspectos organizativos comunes a todos los proyectos, dónde las diferencias las

marcarán el tamaño de los equipos.

Es habitual en nuestros proyectos, en los que los equipos son pequeños, de 2 o 3 personas, que muchos

roles y responsabilidades recaigan en la misma persona.

Es importante que la organización sea conocida por todos los miembros del equipo, para evitar malos

entendidos, perdida de información o el uso de canales no adecuados a la situación.

Funciones y Responsabilidades:

Quién debe tomar las decisiones

Quién debe ser informado y de qué

Quién tiene cualquier tipo de responsabilidad

Quién debe hacer cada tipo de trabajo

Quién debe ser consultado en la toma de decisiones

El objetivo de la definición de los roles y responsabilidades es la de permitir una comunicación eficaz

mediante:

La correcta información, para las personas adecuadas y en el momento preciso

Control de la distribución de la información

Definición de los canales de comunicación

Organización de los grupos de trabajo:

La responsabilidad del grupo de trabajo recae en el jefe de proyecto

Cada miembro del grupo de trabajo debe estar cualificado para asumir su papel en el Grupo y

en el Proyecto

“Key-User”. Es un usuario de los departamentos afectados por el proyecto, con los

conocimientos necesarios para integrar a su departamento en el proyecto

Responsabilidades de los Key-User:

Aportar la experiencia y el conocimiento de su departamento, al que representa como

responsable de la ejecución del proyecto en el mismo

Realizar las propuestas de procedimientos, normas y procesos de su departamento.



Realizar las acciones que le son encomendadas

Responder al cumplimiento de los objetivos

Motivar y formar a los usuarios finales de su departamento

Cualidades del “Analista de Necesidades”:

En la práctica de gestión de proyectos, el consultor se convierte en un analista de necesidades, con

habilidades personales no siempre fáciles de encontrar en una misma persona:

Fuerte capacidad de tratar con los clientes y extraer de ellos una idea de lo que realmente

necesitan

Habilidad para reconocer que no todos los clientes son iguales … en importancia para el éxito

del proyecto

Competencia técnica, capacidad para proponer soluciones concretas en la tecnología a

implantar

“Open Minded”, es decir, que no se cierre a posibles soluciones solo por tener una “visión muy

parcial” del proceso y la tecnología a implantar (que tenga en cuenta el modelo de negocio y el

entorno tecnológico del cliente: SAP, Oracle, SQL, DWH, …)

Alta tolerancia a la ambigüedad, capacidad para entender los menajes y las apreciaciones de

los clientes

Capaz de expresar sus pensamientos y sentimientos con facilidad y claridad

Cualidades del “Project Manager”:

Incluyendo las anteriores de analista de necesidades, el Project Manager es un rol con las siguientes

características:

Intrínsecas como persona: capacidad de relación y de comunicación

Su formación profesional y capacidad de aprendizaje

La experiencia previa: técnica y funcional

Capacidad de gestión de la incertidumbre

Los conocimientos técnicos sobre las características de la solución a implantar: AUTORIDAD

Deseo de gestionar ese proyecto y lograr los objetivos

Su estilo de gestión en relación con el proyecto:

o Autocrático: Impone su criterio al grupo

o Participativo: Delega las responsabilidades

o Democrático: Acepta los criterios del grupo

Capacidad de anticipación



CARACTERÍSTICAS DE LOS PROYECTOS: CONFLICTOS, FACTORES

DE ÉXITO Y CUESTIONES POLITICAS

Con toda seguridad, en la gestión de un proyecto siempre aparecerán áreas poco claras, diversidad de

opiniones, malentendidos y por tanto en general, conflictos a resolver. La clave es la actitud hacia el

proyecto y la anticipación (en la medida de lo posible!!) evitando la adopción de una postura reactiva,

respondiendo a las dificultades después de que aparezcan.

Fuentes potenciales de conflictos

Prioridades del proyecto en relación a otros

Procedimientos administrativos mal establecidos

Opiniones técnicas contradictorias

Relaciones humanas inexistentes

Recursos no asignados cuando se necesitan

Costos no autorizados

Desviaciones en plazos y en costos

Baja calidad del proyecto y del producto

Cómo afrontar los conflictos que aparezcan y cómo solventarlos dependerá de cada uno y de la

situación, pero en general, se darán alguna de las siguientes situaciones:

Confrontación directa entre las partes

Compromisos y acuerdos entre las partes

Suavización de las áreas de discusión

Imposición en detrimento del opositor

Retirada para volver luego sobre lo fundamental

Contrataque por fundamentos y hechos

Obtener el soporte del comité de seguimiento

Lo mejor es evitar los conflictos, pero es inevitable encontrarlos, por lo que lo importante será

trabajar para minimizarlos:

Planes claramente definidos, acordados y divulgados

Responsabilidades bien definidas y comunicadas

Divulgación de la importancia del proyecto

Procedimientos escritos y detallados

Ambiente de trabajo cómodo y sin tensiones



Hacer que el GRUPO sea tangible (especialmente en proyectos muy largos 6-12 meses, nombre,

ubicación, sistema de recompensas ...)

Apoyo al grupo en sus actuaciones y decisiones

Analizar las causas sin castigar a los responsables

Factores de éxito

Si no es posible definir con claridad los objetivos, es vital que se detecten y documenten todos los

puntos de inseguridad - RIESGOS - y se realice un plan de revisión de los mismos, de forma que lo antes

posible queden totalmente definidos.

Definición de objetivos:

Ámbito

Requisitos que debe cumplir el producto

Actividades y recursos necesarios

Los objetivos deberán ser: cuantificables, medibles y realizables

Establecimiento de criterios de éxito claros

Informes eficaces sobre el estado y los progresos del proyecto

Buena documentación del proyecto

Herramientas de control de desviaciones: informe semanal de situación del proyecto. Resumen

mensual de situación al comité de seguimiento.

Cuestiones políticas en los proyectos

Las 3 áreas que normalmente generan problemas en la gestión de proyectos son:

Organización y estructura del proyecto

Identificación de las necesidades y especificaciones de los requerimientos

Inadecuada planificación y control

Como siempre cada caso es distinto, pero el proceso a seguir a la hora de definir y analizar las

problemáticas es clave para una correcta resolución:

1. Evaluar el entorno

2. Identificar las metas de los “stakeholders”

3. Conocer nuestras propias capacidades

4. Definir el problema

5. Desarrollar la solución

6. Probar y refinar la solución



Los cuatro primeros pasos son para que el Project Manager consiga una visión realista de lo que está

sucediendo, sería un error empezar a dar soluciones sin realizar los cuatro primeros pasos…

En relación a la gestión de los recursos disponibles y las cuestiones políticas, es necesario tener en

cuenta las características de cada uno de ellos:

TIEMPO

Intercambiable

Irrecuperable

Medible

Subjetivamente elástico, tiene márgenes de desviación

Mal utilizado si abunda

EQUIPOS

Poco intercambiables

Medibles

Su uso causa a menudo problemas importantes no previstos

INFORMACIÓN

Como recurso a gestionar (del cliente, del proveedor, del equipo, del sistema,…)

Necesidades de información que debe cumplir el sistema



ACEPTACIÓN Y CIERRE DEL PROYECTO

Formalmente, el cierre de proyecto es un proceso que debería revisar el resultado final en relación a

los objetivos inicialmente establecidos, establecer las lecciones aprendidas, los objetivos incumplidos,

las poténciales modificaciones de la solución a futuro y en general todos los aspectos relacionados con

el efectivo funcionamiento de la solución en la realidad del día a día

El cierre siempre está en el horizonte del proyecto y por lo tanto es labor del PM conducir al cliente al

cierre y la aceptación. Es un proceso que requiere de la preparación de: (1) arranque, (2) la transición,

tanto de los procesos, como de la tecnología y el conocimiento y (3) de la documentación asociada al

cierre: propuesta de soporte y mantenimiento, folow-up de actividades e usuarios, acta, correo y

reunión de cierre.

La aceptación del nuevo sistema y la finalización del proyecto del proyecto están totalmente

vinculadas por lo que las pruebas y la validación del trabajo realizado, son el único paso para la

finalización del proyecto.

Pruebas y validación

Hay que incluir en las pruebas todas las “casuísticas” existentes y realizar todas las simulaciones

necesarias. Una vez realizadas y probadas las adaptaciones, modificaciones y cambios según el diseño

detallado en las especificaciones, se debe realizar una prueba final para aceptar el nuevo sistema o

solución (UAT).

Una vez más, como Consultor y Project Manager la forma más sencilla de asegurar que la solución

cumple con las expectativas generadas, es ponernos en la piel del cliente y hacer un uso “extensivo”

de la solución, asegurándonos que las pruebas y las validaciones quedan reflejadas en una acta o

documento de test y validación.

Entrega y uso

La aceptación del nuevo sistema incluye una revisión que asegure que está disponible todo lo necesario

para que comience la fase de explotación del nuevo sistema, así como una lista de recomendaciones y

de acciones de seguimiento para garantizar el correcto uso y aceptación.

Es necesario reflejar aquí la aceptación del sistema por todas y cada una de las partes implicadas en el

mismo. Esta aceptación debe de quedar por escrito y puede llegar a través de distintos canales: mail,

reunión de cierre de proyecto o el que se establezca con el cliente.

Por último, es recomendable que el documento de cierre sea, de alguna forma, una excusa para

redactar el “Case Study” del proyecto.



METODOLOGÍA DE PROYECTOS MANAGEMENT INTELLIGENCE

Previo a explicar cómo se desarrolla un proyecto y sus diferentes fases, hay que entender de forma

sucinta, qué significa la metodología AGILE.

La metodología AGILE se basa desarrollar proyectos por bloques, de manera que el resultado de un

proyecto no se obtiene al final, sino que durante su desarrollo existen validaciones parciales de cada

uno de los bloques funcionales.

El muy importante que los bloques funcionales sean complementarios, de manera que cada bloque que

sea validado permita el desarrollo del siguiente sin que el anterior tenga sufra modificaciones. De esta

manera, a medida que se validan los bloques también se valida el proceso en su globalidad.

Esta metodología aporta:

CLIENTE:

Visibilidad del avance del proyecto

Compromiso e implicación en el proceso al validar cada uno de los bloques funcionales

Recompensa del tiempo dedicado durante la fase de análisis (se evita la sensación de

tener que esperar al final para validar todo un proceso, con las tensiones generadas por

no estar viendo cómo evoluciona el proyecto)

Identificación de posibles mejoras durante la validación y de adaptaciones a sus

necesidades (que también afectan a la correcta gestión de expectativas y de

desviaciones)

Comprueba el valor que le aportamos durante el desarrollo, además de avanzar en

cierta manera la fase de formación al estar interactuando con la solución

Consultor:

Identificación de nuevas necesidades al validar un bloque funcional. Este punto es

importante porque se identifican desviaciones o variaciones de alcance y permiten

avanzar mejoras para fases posteriores o retrasar requerimientos necesarios a fases

posteriores

Comprender mejor al cliente durante las fases de validación e interpretar sus

necesidades

Identificar riesgos en fases futuras. Al validar un bloque funcional se pueden identificar

requerimientos mal recogidos durante la fase de análisis

Una vez introducido el concepto AGILE, las fases para desarrollar un proyecto son las siguientes:



1.1.1 Kick-Off

Previo al inicio del proyecto, y con el objetivo de definir y presentar los equipos de trabajo y el

proyecto, se mantiene una reunión de Kick-Off o de Arranque de proyecto. Durante dicha reunión, los

temas tratados son los siguientes:

Presentación del proyecto – Alcance y objetivos, implicación del cliente en las diferentes fases

y el calendario estimado de proyecto

Definición y presentación de los equipos de trabajo

Planificación de la periodicidad de las reuniones de seguimiento

1.1.2 Análisis

Durante la fase de Análisis hay que diferenciar dos aspectos importantes:

Análisis Funcional del proceso

Modelo de Datos

1.1.2.1 Análisis funcional del proceso

El Análisis Funcional debe contemplar el proceso de negocio y los requerimientos de la compañía. Para

poder recoger correctamente los requerimientos del cliente, se debe formar un equipo de trabajo en el

cual la persona o personas que tengan el conocimiento del proceso estén implicadas. No contar con la

presencia de dichas personas puede hacer fracasar el proyecto porque el resultado del mismo no cubre

sus necesidades y la solución desarrollada acabará por no ser utilizada.

Habitualmente este equipo de trabajo tiene el siguiente esquema:

CLIENTE

Perfil Funcional: Director financiero, controllers, Director Comercial o personas

designadas por los responsables anteriores que se encargan de recoger y explicar las

necesidades del proyecto a los consultores

Perfil Técnico: En representación del Dept. de IT puede estar el Director de Sistemas o

personas de su equipo para validar si la información necesaria para cubrir los

requerimientos del negocio está disponible en origen o si su dificultad para obtenerla

no es rentable (coste-beneficio)

CONSULTOR

El equipo estará formado por un número mayor o menor de managers, consultores

senior o consultores según la dificultad y alcance del proyecto. El objetivo del equipo

de proyecto es aportar valor al cliente, ya sea en forma de experiencias en otros

proyectos, alertando de los riesgos que pueden suponer ciertos requerimientos de

proyecto y sobretodo, controlando el alcance del proyecto para evitar desviaciones

Las dificultades más importantes de esta fase se centran en:



a. Identificar correctamente las necesidades del cliente, para ello es muy importante entender el

concepto de negocio y ser capaz de visualizar el proceso en su totalidad previamente a entrar

al detalle. En esta fase primero hay que entender el proceso global para desmenuzar cada una

de las diferentes etapas del proceso posteriormente, ya que en caso contrario es imposible

gestionar las desviaciones

b. Realizar un estricto control de versiones de los documentos y de las correcciones realizadas por

el cliente y por el equipo de proyecto

c. Tener presente la valoración y alcance del proyecto en todo momento para evitar desviaciones,

proponiendo fases posteriores al cliente para requerimientos nuevos o requerimientos

inicialmente sencillos que al entrar en detalle se complican. En tales situaciones, el cliente

debe decidir si reduce el alcance para cubrir un requerimiento que se complica o si lo retrasa a

una fase posterior a presupuestar

d. Identificar quien es nuestro cliente, es decir, quien es el impulsor del proyecto y quien está en

el proyecto porque debe estar. Esta diferenciación es importante en caso de conflictos internos

de la compañía cliente

e. Generar la documentación de manera recurrente, no esperar a validar un documento final, sino

tener validaciones parciales en las que el cliente y el “validador” del proceso se compromete

con su visto bueno según se avanza

f. Tener al cliente informado en todo momento de los riesgos y del impacto de las decisiones que

adquiere al no tener en consideración nuestras recomendaciones a través de documentación de

todas las decisiones importantes o que pueden tener un impacto sobre el proyecto

El resultado de esta fase debe ser:

Documento de Análisis Funcional que contemple y cubra los siguientes puntos:

El proceso de negocio – habitualmente la extensión del documento y su complejidad

dependerá del tipo de proyecto, teniendo mayor dificultad aquellos proyectos de

planificación y simulación que los de análisis

Para poder aplicar correctamente la metodología AGILE, el proceso deberá dividirse en

bloques. Esta división debe tener un criterio muy importante: Cada bloque funcional

posterior será complementario al anterior, de manera que a medida que se vayan

validando bloques funcionales, se estará validando el proceso en su globalidad.

Es importante que el documento detalle todos los puntos al máximo nivel de detalle

para evitar conflictos con el cliente durante el desarrollo y por lo tanto evitar

desviaciones

Incluir el máximo número de esquemas para hacer comprensible el proceso en su

globalidad, y en caso de fases futuras, que el cliente tenga presente la escalabilidad de

la solución

NOTA: El equipo de proyecto debe entender el proceso al mismo nivel que el cliente, de lo contrario es

muy complicado que la solución cubra las necesidades de negocio

1.1.2.2 Modelo de datos



Como complemento al Análisis Funcional, es necesario obtener toda la información que hace referencia

a los orígenes de la información.

El modelo de datos tiene como objetivo trasladar el análisis funcional a una estructura que permita

tangibilizar en proceso en la Solución. Para ello, el modelo de datos debe detallar:

Dimensiones, Maestros y Metada: Entidades y jerarquía de la compañía (relaciones)

Métricas o Indicadores a utilizar (cubos y hechos)

1.1.3 Diseño y Desarrollo

El éxito de la etapa de Diseño y Desarrollo está muy relacionado con la anterior, ya que una fase de

Análisis incompleta generará idas y venidas entre la fase de Análisis y la de Diseño y Desarrollo y

viceversa. Este tipo de errores es muy común y garantizan desviaciones en los proyectos.

Para evitar tener que gestionar las expectativas del cliente durante todo el proyecto, es muy

importante haber seguido las indicaciones previamente descritas.

Asumiendo que la fase de Análisis se ha realizado correctamente, durante la fase de Diseño y

Desarrollo, se deberán repetir, para cada uno de los bloques funcionales establecidos el siguiente

procedimiento:

1- Desarrollo o corrección del bloque funcional

Desarrollo del bloque funcional inicialmente o corrección en caso que la validación no haya sido

satisfactoria (ya sea con correcciones de menor nivel o por errores de desarrollo).

2- Validación por parte del cliente

Validación del bloque funcional por los key users del proceso.

3- Análisis de modificaciones o nuevos requerimientos

Desarrollo o corrección del

bloque funcional

Validación por parte del cliente

Análisis de modificaciones o

nuevos

requerimientos

OK?SI

NO

Desarrollo siguiente bloque funcional

1

2

3



Posteriormente a la validación del cliente, se deben identificar si las modificaciones son

debidas a errores de desarrollo o a nuevos requerimientos del cliente. En caso que sean nuevos

requerimientos, el cliente deberá priorizar si quiere incorporarlos en este proyecto o

posponerlas a un proyecto futuro.

Es importante tener en presentes los siguientes puntos durante esta fase:

Realizar un control exhaustivo de las modificaciones y de las decisiones acordadas en cada uno

de los bloques funcionales, con documentación que de soporte a cualquier cambio y a todas las

validaciones intermedias

Aprovechar las validaciones no únicamente para validar el proceso sino para cuadrar la

información y la coherencia de los resultados obtenidos en todo momento. Hay que ser

cuidadoso y curioso para analizar previamente a entregar al cliente las validaciones si existe

coherencia entre el proceso recogido y los resultados obtenidos.

En caso que el proceso a desarrollar tenga simulaciones, que el cliente ha ido introduciendo y

validando durante bloques funcionales previos, se debe ser muy cuidadoso en recuperar la

información introducida previamente para no realizar tareas por duplicado. Además, en un

proceso complejo de planificación, dichas simulaciones pueden ser muy complejas de

recuperar por el cliente.

1.1.4 Validación UAT (Users Acceptance Test)

Una vez entregados y validados todos los bloques funcionales del proyecto, se realiza una validación

global del proceso.

Si se han realizado correctamente las validaciones anteriores, esta etapa debería tener un impacto

menor. El resultado debería ser un funcionamiento correcto tanto del proceso como de la información

obtenida (existan o no simulaciones)

El resultado de esta fase debe ser la validación (firma del documento de validación de UAT) por parte

del cliente o de los responsables definidos.

1.1.5 Roll-Out

La última fase del proyecto es el Roll-Out, que comprende la formación a los usuarios clave en Board y

la divulgación a lo largo de la organización.

Habitualmente los implicados en la formación a usuarios clave de la solución desarrollada son:

Responsable funcional del proyecto: Controllers, Directores Comercial, Financiero, …

Departamento de IT



Para estos perfiles se plantea una formación tanto en el proyecto (más funcional) como técnica (en la

que el departamento de IT toma control sobre la Solución, la Base de Datos, Cubos, y procesos

generados).

Posteriormente, y una vez los usuarios clave han sido formados, se plantean dos posibilidades:

Fase de acompañamiento y formación a los usuarios implicados en el proceso por parte del

consultor

Fase de acompañamiento y formación a los usuarios implicados en el proceso por parte del

cliente

En ambos casos es muy importante cerrar agendas con antelación, ya que habitualmente hay varios

perfiles convocados a estas formaciones.

implantación de tecnología desde la aportación de valor al negocio

Documents