El​ ​documento​ ​de​ ​expectativas:  
la​ ​definición​ ​del​ ​proyecto​ ​de​ ​BI 
 
   
 
 
 
Definición​ ​del​ ​proyecto​ ​de​ ​BI 
La planificación incluye la creación de un Documento de Expectativas del       ...
 
realizado​ ​correctamente​ ​o​ ​no. 
 
Alcance​ ​del​ ​Proyecto 
Es imposible crear estimaciones válidas para un proyect...
 
● El plan de mitigación especifica las acciones que el equipo del                     
proyecto puede tomar para evitar ...
 
alcance, presupuesto y recursos (por lo general en ese orden). La calidad                       
está​ ​en​ ​​ ​la​ ​par...
 
tarde.  
● El​ ​​ ​1​ ​de​ ​julio​ ​Enrique​ ​Barragán​ ​Rivera​ ​sale​ ​de​ ​la​ ​organización.  
● El nuevo producto D...
 
Algunos cambios también afectan a las otras dos restricciones                 
(presupuesto y recursos). Cuando uno camb...
 
desarrolló​ ​por​ ​primera​ ​vez. 
Esta es la secuencia de actividades para la preparación de un plan de                ...
Próxima SlideShare
Cargando en…5
×

El documento de expectativas: La definición del proyecto de BI

59 visualizaciones

Publicado el

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.

Publicado en: Empresariales
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

El documento de expectativas: La definición del proyecto de BI

  1. 1.         El​ ​documento​ ​de​ ​expectativas:   la​ ​definición​ ​del​ ​proyecto​ ​de​ ​BI         
  2. 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. 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. 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. 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. 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. 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. 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 

×