Este documento define el propósito y contenido de un documento de expectativas para un proyecto de Business Intelligence (BI). Explica que el documento debe definir los objetivos, alcance, riesgos, limitaciones y premisas del proyecto, así como los procedimientos de control de cambios. También destaca la importancia de medir el alcance del proyecto en términos de datos en lugar de funciones, y recomienda que la calidad sea la principal restricción.

1.
El​ ​documento​ ​de​ ​expectativas:
la​ ​definición​ ​del​ ​proyecto​ ​de​ ​BI

2.
Definición​ ​del​ ​proyecto​ ​de​ ​BI
La planificación incluye la creación de un Documento de Expectativas del
proyecto,​ ​que​ ​lo​ ​define​ ​en​ ​términos​ ​de:
● Las​ ​metas​ ​y​ ​objetivos
● Ámbito​ ​de​ ​aplicación​ ​(el​ ​proyecto​ ​prevé​ ​entregar)
● Riesgos
● Limitaciones
● Premisas
● Procedimientos​ ​de​ ​control​ ​de​ ​cambios
● Gestión​ ​de​ ​temas​ ​potencialmente​ ​conflictivos
El Documento de Expectativas del proyecto es un acuerdo entre el
patrocinador del negocio y el personal de TI para el desarrollo de la
aplicación de ​Business Intelligence (BI)​. Si algún componente
Documento de Expectativas cambia, el proyecto tiene que ser reevaluado
y​ ​tienen​ ​que​ ​ser​ ​renegociadas​ ​las​ ​definiciones.
Metas​ ​y​ ​Objetivos​ ​del​ ​Proyecto
Al definir un proyecto de ​BI​, en primer lugar deben estar claros los
objetivos​ ​y​ ​metas.
● ¿Cuál​ ​es​ ​la​ ​razón​ ​de​ ​la​ ​construcción​ ​de​ ​esta​ ​aplicación​ ​BI?
● ¿Cuánto​ ​dolor,​ ​en​ ​términos​ ​de​ ​negocios,​ ​causa​ ​el​ ​problema
● ¿Que​ ​se​ ​supone​ ​que​ ​la​ ​aplicación​ ​de​ ​BI​ ​resolverá?
● ¿Cuáles​ ​son​ ​los​ ​impulsores​ ​estratégicos​ ​del​ ​negocio?
● ¿Los objetivos del proyecto de ​BI ​están alineados con los objetivos
estratégicos del negocio, o es este proyecto es el capricho de
alguien?
Los objetivos del proyecto deben ser declaraciones mensurables. Por
ejemplo:
● "Con el fin de aumentar la cuota de mercado de un 10% el próximo
año, el departamento de ventas debe tener acceso a los datos de
ventas de fin de mes, así como datos de ventas previstos que se
deben fusionar con los datos de prospección dentro de los cinco
días​ ​hábiles​ ​siguientes​ ​al​ ​cierre​ ​del​ ​ciclo​ ​semanal​ ​de​ ​cuentas”.
Los objetivos del proyecto deberían ajustarse al ROI esperado. El negocio
tiene que poder medirse en términos de la eficacia fruto de lo que entrega
la aplicación de BI e informar al patrocinante si el proyecto se ha
2​ ​de​ ​8

3.
realizado​ ​correctamente​ ​o​ ​no.
Alcance​ ​del​ ​Proyecto
Es imposible crear estimaciones válidas para un proyecto sin una sólida
comprensión de su alcance. Tradicionalmente, el alcance se ha medido
por el número de funciones que el sistema realizará (análisis de puntos de
función). En los proyectos de ​BI ​esta es un camino para subestimar el
esfuerzo, el presupuesto y los recursos. Las aplicaciones de ​BI ​son
dato-intensivas, no función-intensivas. Por lo tanto, el alcance debe ser
medido por la cantidad de datos elementales que tienen que ser extraídos
de los sistemas de origen, transformados, depurados y cargados en las
bases​ ​de​ ​datos​ ​de​ ​destino​ ​​BI​.
La​ ​principal​ ​razón​ ​para​ ​concentrarse​ ​en​ ​los​ ​datos​ ​en​ ​lugar​ ​de​ ​las
funciones​ ​es​ ​que​ ​el​ ​análisis​ ​y​ ​la​ ​preparación​ ​de​ ​datos​ ​de​ ​origen​ ​tarda
mucho​ ​más​ ​que​ ​proporcionar​ ​acceso​ ​a​ ​los​ ​mismos​ ​y​ ​permitir​ ​su​ ​análisis​ ​a
través​ ​de​ ​informes​ ​y​ ​consultas.​ ​La​ ​típica​ ​regla​ ​80/20​ ​por​ ​lo​ ​general​ ​se
aplica:
● 80​ ​%​ ​de​ ​esfuerzo​ ​para​ ​los​ ​datos
● 20​ ​%​ ​de​ ​esfuerzo​ ​para​ ​la​ ​funcionalidad.
Riesgos​ ​del​ ​proyecto
Cada proyecto está sujeto a ciertos riesgos que son inevitables. Estos
riesgos podrían afectar gravemente a la programación, así como los
resultados, dependiendo de la probabilidad de que tales riesgos se
materialicen y del impacto que tendrán en el proyecto. Por lo tanto, la
evaluación de riesgos que se realizó en el paso 1, cuando se hizo la
construcción y evaluación del Caso de Negocio, debe revisarse y
modificarse​ ​en​ ​caso​ ​que​ ​sea​ ​necesario.
El director del proyecto debe identificar los factores desencadenantes
para cada riesgo e incorporar, en el Plan general del proyecto, un plan
para​ ​mitigarlos​ ​así​ ​como​ ​un​ ​plan​ ​de​ ​contingencia​ ​.
● Los factores desencadenantes son situaciones que indican un
potencial de materialización inminente de un riesgo. Por ejemplo, si
la administración está revisando el presupuesto para el proyecto
sin ninguna razón aparente, esto indica un posible desencadenante
para​ ​el​ ​riesgo​ ​de​ ​pérdida​ ​de​ ​apoyo​ ​a​ ​la​ ​gestión​ ​de​ ​su​ ​proyecto​ ​de​ ​​BI​.
3​ ​de​ ​8

4.
● El plan de mitigación especifica las acciones que el equipo del
proyecto puede tomar para evitar que el riesgo se materialice.
Continuando con el ejemplo anterior, podría solicitar el apoyo de su
patrocinador y promover la iniciativa de ​BI ​a otros ejecutivos
claves de la organización para mantener el interés de la
administración en el proyecto de ​BI​. Si éste tiene problemas, el
riesgo​ ​de​ ​tener​ ​que​ ​cancelado​ ​se​ ​mitiga​ ​o​ ​previene.
● El plan de contingencia especifica alternativas en caso de que el
riesgo se materialice. Por ejemplo, si usted pierde apoyo a la gestión
para el proyecto de ​BI ​debido a un cronograma largo, el plan debe
contemplar acortar los ciclos de liberación mediante entregas
parciales, es decir, un menor alcance puesto a disposición antes. Si
pierde apoyo por la salida del patrocinador, ya sea por renuncia o
despido, se debe contar con un patrocinador dispuesto a
convertirse​ ​en​ ​alternativa​ ​para​ ​el​ ​proyecto​ ​de​ ​​BI​.
Algunos​ ​riesgos​ ​de​ ​los​ ​proyectos​ ​comunes​ ​incluyen:
•​ ​Falta​ ​de​ ​compromiso​ ​de​ ​la​ ​dirección.
•​ ​Pérdida​ ​del​ ​patrocinador.
•​ ​La​ ​falta​ ​de​ ​participación​ ​de​ ​las​ ​personas​ ​relacionadas​ ​con​ ​el​ ​negocio.
•​ ​Agenda​ ​impuesta,​ ​poco​ ​realista.
•​ ​Expectativas​ ​poco​ ​realistas.
•​ ​Presupuesto​ ​poco​ ​realista.
•​ ​El​ ​personal​ ​no​ ​capacitado​ ​o​ ​no​ ​está​ ​disponible.
•​ ​Cambios​ ​constantes​ ​de​ ​las​ ​prioridades​ ​de​ ​negocio.
•​ ​Gestión​ ​de​ ​proyectos​ ​Ineficaz.
•​ ​Escalabilidad​ ​limitada.
Restricciones​ ​del​ ​proyecto
Todos los proyectos están sujetos a las mismas restricciones: alcance,
esfuerzo (tiempo), presupuesto y recursos (personas capaces y
disponibles).​ ​En​ ​realidad,​ ​hay​ ​una​ ​quinta​ ​restricción:​ ​la​ ​calidad.
Si bien la calidad es una medida de lo bien que el productos satisfagan los
requisitos, también puede ser considerada una restricción que debe ser
equilibrada​ ​con​ ​las​ ​otras​ ​cuatro​ ​limitaciones.
Aunque todos ​quieren calidad, rara vez se otorga tiempo adicional para
lograrla porque calidad y esfuerzo parecen entrar en contradicción.
Mayor calidad requiere más esfuerzo y por lo tanto más tiempo para
entregar​ ​el​ ​resultado.
Dado que el factor tiempo maneja a muchas organizaciones, el esfuerzo a
aplicar es la primera restricción (prioridad más alta), seguido por el
4​ ​de​ ​8

5.
alcance, presupuesto y recursos (por lo general en ese orden). La calidad
está​ ​en​ ​​ ​la​ ​parte​ ​inferior​ ​de​ ​la​ ​lista​ ​de​ ​prioridades​ ​(prioridad​ ​más​ ​baja).
Afortunadamente, las organizaciones tienen un control total sobre la
modificación o cambio de prioridades. Insistir en que el tiempo y el
alcance son las principales limitaciones es aceptable sólo en proyectos
que tienen requisitos relacionados con las regulaciones impuestas por el
gobierno. Pero en la mayoría de los casos, cuando el gobierno impone
plazos, los sistemas operativos e informes operativos son los afectados.
Rara vez esto ocurre con las aplicaciones de soporte a decisiones
estratégicas Le aconsejo que para conseguir la calidad de la parte inferior
de la pila y poner allí ámbito ya que el alcance puede y continuamente se
ampliará a través de futuras versiones de las aplicaciones de BI. La Tabla
3.2​ ​muestra​ ​nuestro​ ​orden​ ​recomendado​ ​de​ ​restricciones​ ​del​ ​proyecto.
La recomendación es que la calidad debe ser la prioridad uno pues es
altamente probable que el alcance se modifique con el transcurso del
tiempo​ ​a​ ​través​ ​de​ ​futuras​ ​versiones​ ​de​ ​la​ ​aplicación​ ​de​ ​BI.
Premisas
Una premisa es algo dado por sentado, es una toma de posición respecto
de ciertos temas. Es importante tenerlas documentadas, porque una
premisa errónea podría, muy rápidamente, convertirse en un riesgo. He
aquí un ejemplo de cómo dos premisas convierten un proyecto en un
fracaso.
Premisa​ ​1
● El vendedor se compromete a entregar un servidor de base de datos
nuevo​ ​en​ ​mayo.
● Para finales de junio, el personal de TI instalará y probará un
sistema​ ​de​ ​base​ ​y​ ​gestión​ ​de​ ​datos​ ​(DBMS)​ ​en​ ​dicho​ ​servidor.
● Esto permite contar con tiempo antes de la fecha límite del
proyecto,​ ​que​ ​es​ ​el​ ​el​ ​cierre​ ​del​ ​ejercicio.​ ​30​ ​de​ ​septiembre.
Premisa​ ​2
Enrique Barragán Rivera será el administrador de la base del proyecto, ya
que él es la única persona en nuestra organización que tiene esa
habilidad especial DBMS, necesaria para el proyecto. Él ya se ha unido el
equipo​ ​del​ ​proyecto.
Problemas
● El 20 de junio llega el nuevo servidor llega, es decir, un mes más
5​ ​de​ ​8

6.
tarde.
● El​ ​​ ​1​ ​de​ ​julio​ ​Enrique​ ​Barragán​ ​Rivera​ ​sale​ ​de​ ​la​ ​organización.
● El nuevo producto DBMS no se instala y no podrá ser probado en el
nuevo​ ​servidor​ ​hasta​ ​el​ ​final​ ​de​ ​septiembre.
Impacto
El proyecto tiene un retraso de tres meses. Hay un sobre costo, con
relación al presupuesto, de USD 45.000. La mayor parte de este adicional
son honorarios de consultoría pagados al consultor que reemplaza a
Enrique​ ​Barragán​ ​Rivera.
Las premisas importantes deben tener una contrapartida de riesgos.
Conocidos los riesgos, se conocen los factores desencadenantes, y
sabiendo cuáles son, se prevén las formas de mitigarlos y se elabora un
plan​ ​de​ ​contingencias.
Si las premisas se cumplen, el plan sigue sin cambios. En cambio si no se
cumplen, como en el ejemplo anterior, hay un plan de contingencia. en
caso​ ​de​ ​que​ ​los​ ​supuestos
Procedimientos​ ​de​ ​control​ ​de​ ​cambios
En las metodologías tradicionales tipo cascada, hay un enfoque de
desarrollo del proyecto por fases que intenta frenar la modificaciçon del
alcance. El modelo mental que subyace es: "​El cambio es malo, los
hombres​ ​de​ ​negocios​ ​deben​ ​someter​ ​sus​ ​decisiones​ ​a​ ​lo​ ​que​ ​fue​ ​pactado.​"
Se supone que las aplicaciones de ​BI ​son catalizadores para la toma de
mejores decisiones. Por eso el modelo mental debe cambiar a "​El cambio
es​ ​bueno,​ ​la​ ​gente​ ​de​ ​negocios​ ​debe​ ​perfeccionar​ ​y​ ​mejorar​ ​sus​ ​decisiones​.​ ​"
Sin embargo, el cambio no controlado puede malograr un proyecto. La
solución consiste en ​gestionar los cambios​. Muchas organizaciones
tienen procedimientos de control de cambios. Esa es una buena práctica,
pero​ ​el​ ​seguimiento​ ​de​ ​los​ ​cambios​ ​no​ ​es​ ​lo​ ​mismo​ ​que​ ​su​ ​gestión.
Para gestionar un cambio, hay que comenzar con un punto de partida: el
acuerdo​ ​entre​ ​el​ ​promotor​ ​del​ ​proyecto​ ​[sponsor]​ ​y​ ​el​ ​personal​ ​de​ ​TI.
Cada solicitud de cambio, una vez iniciada, se somete a un análisis de
impacto y un análisis de costo-beneficio para determinar los efectos del
cambio​ ​en​ ​el​ ​proyecto.
Los cambios, a menos que sean sencillos y rápidos, siempre impactará las
tres limitaciones de esfuerzo (tiempo), ámbito de aplicación, y la calidad.
6​ ​de​ ​8

7.
Algunos cambios también afectan a las otras dos restricciones
(presupuesto y recursos). Cuando uno cambia de restricciones, las
restricciones restantes tienen que ser renegociadas. Por desgracia, los
gerentes de empresas y gerentes de TI ponen los equipos de proyectos
bajo presión indebida para incorporar modificaciones en el alcance sin
ajustar​ ​el​ ​calendario.
Gestión​ ​de​ ​temas​ ​conflictivos
Durante un proyecto siempre surgen temas de negocios o tecnológicos
que son potencialmente conflictivos o son problemas a resolver. Se los
conoce​ ​como​ ​“issues”.
Al igual que sucede con las solicitudes de cambio, los asuntos
potencialmente conflictivos no sólo deben ser seguidos, sino también
gestionados. Cada “issue” debe asignarse a una persona que tiene la
responsabilidad de su resolución. Cualquier actividad en relación con el
“issue” debe ser fechado y descrito en un registro especial. Al final del
proyecto, deben tener una resolución, aunque la misma sea un
aplazamiento de la cuestión con una nueva versión futura del ​Business
Intelligence​ ​(BI).
La​ ​siguiente​ ​tabla​ ​muestra​ ​un​ ​ejemplo​ ​del​ ​registro
Issue
Nro.
Fecha
del
Issue
Descripción Asignado
a:
Acción
realizada
Fecha de la
acción
Resolución Fecha de
cierre
Algunos problemas son menores y pueden ser resueltos sin impacto en el
proyecto. Otros problemas pueden convertirse en riesgos o solicitudes de
cambio y tiene que ser tratados con los procedimientos previstos. Por lo
tanto, la gestión de los temas potencialmente conflictivos incluye el
análisis​ ​de​ ​impacto​ ​y​ ​el​ ​control​ ​de​ ​cambios.
Planificación​ ​del​ ​proyecto​ ​de​ ​BI
La planificación del proyecto no es una actividad puntual. Puesto que un
plan de proyecto se basa en estimaciones, que son, con frecuencia,
conjeturas, los planes deben ajustarse constantemente. La principal señal
de que un proyecto no se está manejando es un plan estático en el que las
estimaciones y los hitos no tienen cambios desde el día en que se
7​ ​de​ ​8

8.
desarrolló​ ​por​ ​primera​ ​vez.
Esta es la secuencia de actividades para la preparación de un plan de
proyecto.
1. Crear un listado de actividades con una estructura tal que pueda
desglosarse​ ​en​ ​tareas​ ​y​ ​subtareas.
2.​ ​Estimar​ ​las​ ​horas​ ​de​ ​esfuerzo​ ​para​ ​estas​ ​actividades,​ ​tareas​ ​y​ ​subtareas.
3.​ ​Asignar​ ​recursos​ ​a​ ​las​ ​actividades,​ ​tareas​ ​y​ ​subtareas.
4.​ ​Determinar​ ​las​ ​dependencias​ ​entre​ ​tareas.
5.​ ​Determinar​ ​las​ ​dependencias​ ​de​ ​recursos.
6.​ ​Determine​ ​la​ ​ruta​ ​crítica​ ​a​ ​partir​ ​de​ ​las​ ​dependencias.
7.​ ​Crear​ ​el​ ​plan​ ​detallado​ ​del​ ​proyecto.
El análisis de cada una de estas actividades será materia de otro
documento.
División​ ​consultoría​ ​de​ ​Evaluando​ ​Software
8​ ​de​ ​8