Desarrollo de un proyecto de inteligencia de negocio

  • Pere Mariné Jové

    Pere Mariné Jové

    Ingeniero superior en Informática (UPC), magíster en Gestión pública (UAB), DEA en Sociedad del conocimiento y de la información (UOC) y PMP del Project Management Institut. Consultor de estrategias tecnológicas de negocio y de metodologías de dirección de proyectos. Ha trabajado como director de SI y director de proyectos en diversas organizaciones, públicas y privadas, grandes y pequeñas. Ha sido consultor y formador de metodologías de dirección de proyectos, externalización y calidad, como colaborador externo, desde el 2001 en la UOC en las asignaturas de GP/MGPI y GOPI de las ingenierías de Informàtica y también de Gestión de proyectos en el máster TIC, y también en la UAB.

  • José Ramón Rodríguez

    José Ramón Rodríguez

    Profesor de Dirección de las TIC de los Estudios de Informática, Multimedia y Telecomunicaciones. Es también consultor independiente. Licenciado en Filosofía y Letras, PDG de IESE, Cuerpo Técnico de la Seguridad Social y diplomado por la Harvard Business School. Tiene más de diez años de experiencia en la gestión de servicios públicos y más de veinte como consultor y directivo de compañías de consultoría y de servicios de sistemas de información. Ha sido gerente adjunto y CIO del Ayuntamiento de Barcelona, consejero delegado del Instituto Municipal de Informática, y socio de Ernst & Young (actualmente CapGemini) y PricewaterhouseCoopers (actualmente IBM Business Consulting).

PID_00199368
Los textos e imágenes publicados en esta obra están sujetos –excepto que se indique lo contrario– a una licencia de Reconocimiento-NoComercial-SinObraDerivada (BY-NC-ND) v.3.0 España de Creative Commons. Podéis copiarlos, distribuirlos y transmitirlos públicamente siempre que citéis el autor y la fuente (FUOC. Fundación para la Universitat Oberta de Catalunya), no hagáis de ellos un uso comercial y ni obra derivada. La licencia completa se puede consultar en http://creativecommons.org/licenses/by-nc-nd/3.0/es/legalcode.es

Índice

Introducción

Una vez presentado el marco conceptual de la gestión de proyectos de inteligencia de negocio (TIC); es decir, la terminología y definiciones que utilizaremos aquí, las etapas del ciclo de vida de los proyectos, las áreas de conocimiento o procesos de gestión que debe manejar el jefe de proyecto y el cuerpo metodológico que utilizaremos principalmente como referencia, el Project Management Body of Knowledge (PMBOK), en este módulo iremos siguiendo las diferentes etapas del ciclo de vida de gestión y cómo se aplican los procesos de gestión en cada una de ellas.
Recordemos, una vez más, que el PMBOK, como Prince2 u otras metodologías de propósito general, es una caja de herramientas universal que sirve para cualquier clase de proyectos. Según el tipo y el tamaño del proyecto, y el contexto de la organización, estas herramientas se adaptan a cada situación. En el módulo anterior, hemos señalado qué procesos y documentos consideramos básicos y cuáles complementarios u opcionales.
Figura 1. Etapas del ciclo de vida de proyectos TIC
Figura 1. Etapas del ciclo de vida de proyectos TIC
De modo que, por el límite y las condiciones del módulo, presentaremos aquí de manera muy general el contenido de cada fase de gestión según el método del PMBOK, y veremos la etapa de ejecución de proyectos de inteligencia de negocio más extensamente en el módulo “Ejecución de proyectos de inteligencia de negocio”.
Podríamos decir que PMBOK o Prince2 son métodos de propósito general o guías de trabajo comunes a cualquier proyecto, mientras que hay metodologías para la construcción de determinados tipos de productos. Ocurre que a lo largo del tiempo, las metodologías de ejecución de unos determinados productos (y, a veces, las de los propios fabricantes o implantadores) ya han ido desarrollando a lo largo del tiempo enfoques y herramientas que pueden incluir contenidos de los métodos generales, no siempre coincidentes en su contenido y en su ubicación. Esto puede dar lugar a confusión, pero es como funciona este mercado, y creemos que es preferible que el estudiante lo sepa. Lo que hemos hecho aquí, tanto en el módulo “Desarrollo de un proyecto de inteligencia de negocio” como en el mòdulo “Ejecución de un proyecto de inteligencia de negocio”, y siempre que nos ha sido posible, es llamar la atención sobre estas coincidencias para minimizar en lo posible dicho efecto.

Objetivos

Al término del estudio de este módulo, el estudiante deberá ser capaz de conocer y aplicar el conjunto de procesos necesarios para el desarrollo de la mayoría de los proyectos de inteligencia de negocio desde el punto de vista de su gestión, y más en concreto:

  1. Saber cómo se concibe inicialmente un proyecto, identificando problemas y oportunidades de la empresa y transformándolos en una idea o primer concepto de lo que será un proyecto.

  2. Saber cómo se prepara la documentación necesaria para la aprobación del proyecto y qué es el acta de constitución (project charter).

  3. Saber cómo se identifica a los interesados, su influencia y su interés en el proyecto.

  4. Entender la importancia de la planificación de un proyecto, los diferentes tipos de planificación y el enfoque de la planificación orientada a objetivos, en particular el concepto de hito.

  5. Conocer en profundidad las herramientas y productos de la planificación en las tres áreas clave (llamadas líneas de base o baselines) de la gestión de un proyecto TIC:

    • La planificación detallada del alcance.

    • La planificación de tiempos y la elaboración del calendario de proyecto.

    • La planificación de costes y la elaboración del presupuesto de proyecto.

  6. Conocer el contenido, aplicaciones y entregables del proceso general de control integrado de cambios del proyecto.

  7. Identificar los principales procesos incluidos en la etapa de cierre del proyecto y los aspectos clave de un cierre exitoso, en particular, la aceptación de los productos y la transición a producción.

1.Iniciación

1.1.Etapas previas a la iniciación del proyecto

Un proyecto debería mejorar o transformar procesos de negocio para aumentar la ventaja competitiva de la empresa. No hay proyectos TIC, sino proyectos de negocio, que se apoyan de una u otra manera en herramientas TIC. Y al revés, hoy no se puede pensar en transformaciones de procesos de negocio sin tener en cuenta las tecnologías de la información y las comunicaciones, aún más en un proyecto de inteligencia de negocio que, como su nombre indica, tiene que ver con la inteligencia de la empresa y con el negocio.
En el módulo “Características de los proyectos de inteligencia de negocio”, hemos examinado las razones por las que las empresas adoptan estos sistemas y su utilidad. Un sistema de inteligencia de negocio debe permitir lo siguiente:

  • Medir, o sea, registrar lo ocurrido de forma cuantitativa, lo que incluye establecer una estructura de datos, etiquetas, fórmulas de cálculo, etc.

  • Comparar, o sea, relacionar sucesos con otros, sean internos (por ejemplo, comparar con los objetivos o comparar entre unidades o personas) o externos (por ejemplo, comparar nuestro rendimiento con el de otros, como la cuota de mercado).

  • Reportar, o sea, presentar la información de determinada manera y con diferentes tipos de explotaciones, numéricas y gráficas.

  • Analizar, o sea, establecer procesos cuantitativos y algoritmos para obtener mejores decisiones, a través de la creación de modelos de datos, cruzando diferentes dimensiones y estableciendo pautas y tendencias.

  • Predecir, o sea, a partir del análisis anterior, establecer comportamientos predecibles de determinados sucesos o inducir determinadas decisiones.

  • Avisar, o sea, establecer alarmas, automáticas o no, cuando un suceso se desvía del comportamiento previsto o se requiere una actuación.

  • Colaborar, o sea, intercambiar datos, información y conocimiento entre diferentes ámbitos, dentro y fuera de la empresa.

  • Saber, o sea, documentar la experiencia y aprendizaje adquiridos por la organización o sus prácticas de gestión ante terceros (por ejemplo, a efectos de exigencias de la regulación).

codi_m3_009.gif
Dos nuevos procesos: experimentar y gestionar el talento
En el mòdulo “Características de los proyectos de inteligencia de negocio”, hemos sugerido añadir a estos objetivos, según la investigación y aplicaciones más recientes, los dos procesos siguientes:

  • Experimentar; es decir, utilizar la información para observar la reacción de un fenómeno a cambios en sus condiciones. Por ejemplo, ofertar a un cliente aficionado a un determinado guitarrista de rock de los años 80 una antología de su obra a mitad de precio, para ver su reacción y a continuación replicar este tipo de acciones con éste u otros clientes con una historial de compra similar.

  • Gestionar el talento; es decir, utilizar la información para establecer objetivos individuales y de grupo y facilitar el desarrollo profesional de los que muestran mejores rendimientos.

En el análisis y aprobación de nuevos proyectos, los criterios para la empresa no suelen ser de elegancia técnica o de actualización tecnológica, sino de impacto en los resultados y en el retorno de la inversión. Asimismo, cada vez más se emplean criterios propios de la gestión de proyectos, es decir, de la viabilidad o éxito del proyecto en sí mismo. Los factores concretos y métodos de evaluación y selección varían de una organización a otra.
En el caso que nos ocupa, hemos analizado en el módulo “Características de los proyectos de inteligencia de negocio”, un conjunto de elementos o capacidades que la organización necesita tener presente para lanzar una iniciativa o proyecto de inteligencia de negocio:

  • La necesidad de negocio, o sea, que en la empresa en su conjunto (deseablemente) o en uno o varios departamentos exista una demanda suficiente y sostenible que justifique la inversión.

  • La situación de partida, o sea, el nivel de evolución de la inteligencia de negocio dentro de la organización.

  • La cultura de empresa, o sea, la existencia o no de una filosofía y valores empresariales orientados a tomar decisiones basadas en los datos.

  • La presencia de talento analítico, o sea, personas capaces de entender las necesidades del negocio, convertir las preguntas en modelos de análisis, interpretar los resultados y proponer respuestas.

  • La calidad de los datos de origen en los sistemas transaccionales y la capacidad para establecer procesos de mejora y “limpieza” de la información de base existente.

  • La inversión y el nivel de implantación de los sistemas transaccionales de empresa (ERP y otros) de los que el sistema de inteligencia de negocio tomará los datos.

  • El talento del propio departamento de IT para construir una arquitectura de datos robusta y mantenerla en el tiempo.

  • El liderazgo y patrocinio de una persona de primer nivel dentro de la empresa y los órganos de gobierno de proyecto adecuados.

El resultado de esta fase acostumbra a ser, de una u otra forma, un análisis de la viabilidad de la inversión (o un business case) y una propuesta inicial que se eleva al comité de dirección de la compañía. A continuación mostramos el guión típico de un producto de este tipo:

  • Resumen ejecutivo

  • Descripción del problema e identificación de la oportunidad.

  • Cualificación de la oportunidad. Evaluación económica inicial del potencial de negocio (aumento de los ingresos, reducción de los costes o tiempos, etc.).

  • Evaluación inicial de la tecnología disponible y análisis de otras experiencias disponibles.

  • Evaluación del punto de partida y las capacidades propias u otras que se deban adquirir, en particular, base tecnológica y de recursos humanos.

  • Evaluación inicial de coste-beneficio y retorno de la inversión.

  • Identificación y cualificación de riesgos principales.

  • Objetivos y contenidos del proyecto. Productos a obtener e hitos principales.

  • Evaluación inicial de tiempo y coste. Principales partidas.

  • Identificación del liderazgo y organización preliminar para la gestión del proyecto.

1.2.Desarrollar el acta de constitución del proyecto

El acta de constitución del proyecto tiene como objetivo documentar la autorización formal del inicio del proyecto y de cada una de las fases (si hay) del mismo, a la vez que recoge y documenta las necesidades de negocio y las expectativas de los interesados que lo justifican.
El acta de constitución del proyecto (1) , podríamos decir que es el mandato del proyecto, el encargo que se le hace al director o jefe del proyecto. El proceso de elaboración resumido se muestra a continuación:
codi_m3_002.gif
Los proyectos son autorizados por un patrocinador (espónsor) externo a la dirección del proyecto, por una oficina de proyectos, por el gerente o comité ejecutivo de un portafolio por otros organismos directivo. El patrocinador tiene que tener la autoridad necesesaria para disponer de los recursos que el proyecto necesitará. La autorización incluye el nombramiento del director del proyecto, director que es recomendable que haya participado en la confección del acta, de este modo se asegura tener prous conocimientos del proyecto como para poder participar en las primeras decisiones. En proyectos BI, es deseable que la autorización venga del director general y del comité de dirección de la empresa en conjunto y que el espónsor o patrocinador del proyecto sea un miembro de este comité.

  • El propósito o la justificación del proyecto: valor para el negocio

  • Los objetivos y el criterios de éxito (factores críticos de éxito) del proyecto

  • Requisitos a alto nivel

  • Descripción del proyecto a alto nivel

  • Riesgos a alto nivel

  • Resumen del cronograma de hitos

  • Resumen del presupuesto

  • Requisitos de aprobación del proyecto y quién tiene que aprobar la entrega

  • El director nombrado, sus responsabilidades y nivel de autoridad

  • Otros participantes o afectados por el proyecto y sus responsabilidades

  • El patrocinador (o quien autoriza el proyecto) y su nivel de autoridad

De todos estos componentes, probablemente el más importante es la definición de los objetivos del proyecto. Pensemos que el acta de constitución debe establecer de manera clara cuáles son los objetivos que desea alcanzar el cliente y convertirlos en objetivos del proyecto. La definición de objetivos debería corresponder, según un principio clásico de gestión de proyectos, a las cualidades SMARTT.
Cualidades SMARTT

  • Specific (específicos, sin ambigüedades, ni descripciones difusas).

  • Measurable (cuantificables, tanto como sea posible).

  • Agreed (acordados con los interesados y, en caso de conflicto, con el comprador o director del proyecto por parte del cliente).

  • Realistic (conseguibles dentro de las limitaciones técnicas, de alcance, tiempo y calendario).

  • Traceable (seguibles y evaluables, que se pueda validar su consecución).

  • Testable (que se pueda probar su consecución internamente y por el usuario en el momento de la producción).

A continuación mostramos una plantilla de acta de constitución de un proyecto:
codi_m3_003_1.gif
codi_m3_003_2.gif
codi_m3_003_3.gif
codi_m3_003_4.gif
codi_m3_003_5.gif
codi_m3_003_6.gif
codi_m3_003_7.gif
Este proceso y la documentación que se produce son críticos. Pero probablemente es aún más importante la actitud y condiciones del jefe de proyecto para establecer las condiciones y factores que deben darse para un inicio exitoso del mismo.
Saber abrir: lecciones de Emilio
Una de las cosas que más cuesta que entiendan los informáticos es que el proyecto comienza mucho antes y acaba un poco después de la producción de unos determinados entregables.
Emilio intenta conocer lo mejor posible los procesos de negocio, las costumbres de trabajo y los equilibrios de poder de los clientes (internos) para los que trabaja y, si puede ser, anticiparse a sus necesidades. Intenta establecer una red de contactos y referentes, que le serán de ayuda en muchos momentos, y conocer lo que se cuece en el mercado, lo que están haciendo los fabricantes y proveedores de servicios y la competencia. Sabe que desarrollar, aumentar las capacidades y conocimientos de clientes y proveedores será una clave de los trabajos que vengan y una tranquilidad para su corazón grande.
Emilio sabe también que hay proyectos que no hacen falta, peticiones compulsivas de usuarios estresados, y cambios y vaivenes que se pueden evitar. Sabe también que la informática no puede resolver problemas que son de gestión o de cultura o de organización. Sabe que lo más caro no es lo más útil casi nunca, y desconfía de los vendedores de ilusiones. De manera que lo primero que se pregunta e intenta trabajar con los clientes son cosas como: ¿Hay que hacer esto? ¿Hay que hacerlo así? ¿Hay que hacerlo ahora? Y lo hace con prudencia, con humildad, casi excesiva, en mi opinión.
Fuente: J. R. Rodríguez (2011). “Saber abrir: lecciones de Emilio”.

1.3.Identificar a los interesados

Los interesados en un proyecto son todas las personas y organizaciones que se verán afectadas por el desarrollo del proyecto, sea directamente, porque participan en alguna medida, o indirectamente, porque les afectará de alguna manera en su funcionamiento. En este proceso, pues, se busca identificarlos a todos y, a la vez, documentar una parte de la información que estos podrán aportar al proyecto, en concreto sus intereses, expectativas, participación, importancia e influencia. Ya hemos comentado que la gestión proactiva de los interesados es una de las claves de éxito de un proyecto BI.
Hay que identificar lo antes posible todos los intereses y fuerzas que actúan alrededor del proyecto de manera que el director tenga los elementos suficientes para enfocar adecuadamente el proyecto a la satisfacción de las necesidades del máximo de los interesados, centrándose en el patrocinador y el cliente. Pero también permite identificar ya al inicio posibles conflictos de intereses que, en este momento, se podrán gestionar y resolver con un impacto menor sobre el proyecto.
En un proyecto BI, habitualmente, las principales barreras son los “silos” de información dentro de los departamentos y la pérdida de poder de las personas que los gestionan; dicen que “la información es poder”.
La política de la implantación
Jeffrey Pinto escribió hace más de diez años el que es aún el mejor texto de referencia sobre “el lado humano” de la implantación de sistemas de información. El libro cubre todo el ciclo de la gestión de proyectos según la ortodoxia más rancia (no en vano está editado por el Project Management Institute), pero lo hace desde “el otro” punto de vista, o sea, cómo las personas y los grupos de personas (la organización) diseñan, eligen e implantan sistemas y qué hace que, desde este punto de vista, unos proyectos tengan más éxito que otros.
El capítulo central del manual, “The Politics of Implementation”, es el punto de apoyo sobre el que pivota la tesis. Acabáramos: resulta que implantar sistemas de información es una cuestión política, o sea, tiene que ver con el poder; resulta que los consultores, implantadores y vendedores tienen que aceptar con sencillez, honestidad y neutralidad que en los proyectos hay política; y resulta que hay enfoques, técnicas y herramientas para reconocer y actuar sobre la política en beneficio del cliente y del proyecto.

1.4.Definición inicial del alcance

Si el mandato o acta de constitución del proyecto se centraba en el por qué de un trabajo y su relación con la organización en términos de objetivos de negocio, recursos e interesados, en la definición inicial del alcance necesitamos mostrar por primera vez y con claridad qué se hace (y qué no se hace) y en qué productos se representa lo que se hará; en definitiva, qué resultados o entregables se obtendrán.
Se podría decir que la definición inicial del alcance es una definición de los requerimientos de alto nivel, definidos por los ejecutivos o el patrocinador.
Aún más que otros procesos de la gestión de proyectos, la gestión del alcance es un producto evolutivo, iterativo y permanente a lo largo del ciclo de vida y, por tanto, en revisión continua, en función de los cambios, desviaciones y correcciones que va marcando la vida del proyecto. Con frecuencia, en proyectos BI, el producto se va conociendo a medida que se van haciendo entregas parciales y los ejecutivos “ven” el resultado del trabajo, “lo usan” y determinan hasta qué punto les resulta útil. Definir con precisión el alcance de muchos proyectos BI resulta muy complicado. Sin embargo, es algo que necesitamos para establecer el nivel de esfuerzo, interno y externo y los costes, y para establecer una base de partida para la planificación.
A veces, la definición inicial del alcance forma parte del acta de constitución.

2.Planificación

2.1.¿Qué es un plan de proyecto?

Planificar es determinar qué hay que hacer, quién lo hará, en qué tiempo y con qué recursos para cumplir un objetivo. El plan de proyecto es la herramienta principal, el cuaderno de bitácora, que utiliza un gestor de proyecto para asegurar la consecución de los objetivos del proyecto.
Podemos considerar que el plan de proyecto es:

  • Un mapa de ruta estructurado que establece las actividades que hay que llevar a cabo para alcanzar los objetivos de negocio.

  • Una definición de los tiempos y recursos –tecnológicos y de negocio– necesarios para completar el trabajo.

  • Un mecanismo para monitorizar avances, controlar el alcance y gestionar el proyecto para asegurar los resultados finales dentro del marco del tiempo y presupuesto definidos.

  • Un medio para comunicar los progresos y comprometer a los participantes del proyecto.

2.1.1.Contenidos del plan de proyecto
PMBOK, 4.ª edición (2008) identifica dentro del grupo de procesos de planificación hasta nueve áreas.

  • Plan de gestión de proyecto

  • Plan de gestión del alcance

    • Recogida de requisitos

    • Definición detallada del alcance

    • Creación de la EDT

  • Plan de gestión del tiempo

    • Definición de actividades

    • Secuenciar actividades

    • Estimar recursos para las actividades

    • Estimar duración de las actividades

    • Elaborar calendario

  • Plan de gestión de costes

    • Estimar costes

    • Elaborar presupuesto

  • Plan de calidad

  • Plan de recursos humanos

  • Plan de comunicación

  • Plan de gestión de riesgos

    • Plan de gestión de riesgos

    • Identificación de riesgos

    • Análisis cualitativo de riesgos

    • Análisis cuantitativo de riesgos

    • Plan de respuesta frente a los riesgos

  • Plan de administración y compras

Fuente: PMBOK (4.ª, 2008).
Cada vez más, en proyectos BI se recomienda un ciclo iterativo. O sea, proyectos o subproyectos (paquetes de trabajo o EDT (2) ) más pequeños, que permitan una interacción más continua con los usuarios finales. Como ya hemos comentado, el desarrollo de capacidades es muchas veces más importante que la obtención de productos tangibles e inmediatos para la organización.
El enfoque “Agile” (ágil) de gestión de proyectos, que comienza a estar de moda, especialmente en proyectos de ingeniería del software, presenta una filosofía de trabajo más sencilla, interactiva y dinámica, con una relación más directa con el usuario y menor carga de documentación administrativa.
Agile. Una nueva forma de desarrollar software y gestionar proyectos
Agile acepta con humildad y realismo que las cosas no son predecibles siempre, que habrá cambios que hay que saludar y no maldecir, que la relación con el usuario será complicada pero productiva y que la fatalidad del triángulo virtuoso de alcance, tiempo y coste se puede romper de vez en cuando sin que pase nada.
Agile reniega del desarrollo en cascada y de la transferencia de instrucciones cada vez más precisas entre el usuario, el analista, el desarrollador y el probador, bajo la severa mirada del jefe de proyecto, que finalmente y al cabo de meses o años no tienen nada que ver con lo que el cliente realmente necesitaba. Los desarrolladores producen software en vivo cada semana que el cliente puede usar, aprender y cambiar. La única métrica de progreso del proyecto es la entrega de software que funciona, continuamente.
La relación es simple y directa, basada en la confianza, el diálogo y el trabajo conjunto y autoorganizado del usuario y el desarrollador. Hay pocos jefes, poca documentación y procesos de gestión de proyectos bastante elementales.

2.2.Plan de gestión del proyecto

Según vimos en el módulo “El ciclo de vida de la gestión de proyectos”, PMBOK se estructura en un conjunto de áreas de conocimiento que se aplican de forma variable y según el juicio experto del director de proyecto a lo largo del progreso del ciclo de gestión del mismo.
El director de proyecto es el responsable de la preparación del plan de gestión de proyecto, que establece qué procesos de gestión se aplicarán a un proyecto determinado e incorpora los elementos principales de los diferentes planes parciales.
Se podría decir que el plan de gestión es el trabajo del jefe de proyecto, su “cuaderno de bitácora” y surge de la integración de los componentes parciales del proyecto, que analizaremos a continuación.
Los principales inputs para la preparación del plan de gestión son el acta de constitución del proyecto (el mandato que marca la iniciación formal del trabajo, en respuesta a una necesidad de negocio), la identificación de interesados (quién tiene algo que ver o que decir en el proyecto) y la definición inicial del alcance (qué hay que hacer y qué productos se tienen que obtener).

2.3.Planificar el alcance

La gestión del alcance del proyecto es, acaso, el proceso más crítico de toda la gestión del proyecto. Es donde se producen las mayores desviaciones y, a menudo, absolutos fracasos, en el contenido (qué quería el cliente), el tiempo y los costes, y desde luego, en la satisfacción de clientes y usuarios y, a menudo, en su repercusión pública.
Los procesos de gestión del alcance, en la definición del PMBOK, son “los que se requieren para asegurar que el proyecto incluye todo el trabajo requerido, y sólo el trabajo requerido, para completar el proyecto con éxito. Gestionar el alcance del proyecto se refiere fundamentalmente a definir y controlar lo que está incluido y lo que no está incluido en el proyecto” o, como hemos dicho tantas veces, lo que se hará y lo que no se hará.
En la etapa o grupo de procesos de planificación, la planificación del alcance incluye tres procesos:

  • La recogida de requisitos; es decir, la definición y documentación de las necesidades que, a juicio de los interesados, permitirán cubrir los objetivos del proyecto.

  • La definición detallada del alcance, es decir, la descripción detallada del proyecto y del producto o los productos (entregables) que se obtendrán.

  • La distribución de la estructura del trabajo y el plan de hitos; es decir, subdividir el conjunto del trabajo y sus entregables en partes o componentes menores.

2.3.1.Recogida de requisitos
Si la inadecuada gestión del alcance estaba entre las principales causas de fracaso de los proyectos; a su vez, la causa principal de fracaso en la gestión del alcance es que los requisitos se han tomado mal o que cambian continuamente a lo largo del proyecto. Un estudio reciente de Gartner muestra que la mayor causa de insatisfacción de los usuarios son errores o fallos en la funcionalidad, derivados de una toma de requisitos insuficiente o poco comprometida o incompleta.
Ya se ve que hay muchos tipos de requisitos, de muchos niveles y procedentes de muchas fuentes y partes interesadas. No todos son iguales, ni tienen la misma importancia para el proyecto, ni son asumibles en el alcance, presupuesto y calendario iniciales acordados con el cliente. Es básico recordar esto continuamente y hacérselo recordar al cliente/ comprador.
Los requisitos, como decíamos de los objetivos, deberían ser SMARTT. Además, cada requisito debería ser completo (que no necesite otros requisitos posteriores) y consistente (que no sea contradictorio con otros o estar potencialmente sujeto a cambios permanentes). Estos dos criterios valen para cada criterio por separado y para todos juntos.
Recordemos las cualidades SMARTT

  • Specific (específicos, sin ambigüedades, ni descripciones difusas).

  • Measurable (cuantificables, tanto como sea posible).

  • Agreed (acordados con los interesados y, en caso de conflicto, con el comprador o director del proyecto por parte del cliente).

  • Realistic (conseguibles dentro de las limitaciones técnicas, de alcance, tiempo y calendario).

  • Traceable (seguibles y evaluables, que se pueda validar su consecución).

  • Testable (que se pueda probar su consecución internamente y por el usuario en el momento de la producción).

Los requisitos suelen tener que ver con la funcionalidad requerida, las necesidades de integración con otras aplicaciones y la infraestructura tecnológica (dependiendo siempre de cada tipo de proyecto). El PMBOK, por su carácter general, no resulta muy relevante y útil para una toma de requisitos informada en proyectos TIC, y de BI en particular. Es más útil para el estudiante y el profesional utilizar algunos otros estándares (por ejemplo, para empezar, la ISO 9001) o, aún mejor, cuerpos de conocimiento existentes en las industrias específicas, como el IIBA (International Institute of Business Analysts) en Estados Unidos o el Atlantic Systems Guild en el Reino Unido, para las industrias del software.
La matriz de trazabilidad de requisitos
PMBOK sugiere una herramienta muy recomendable y útil para cerrar esta sección. Se trata de la matriz de trazabilidad de requisitos, mediante la cual relacionamos en una tabla de doble entrada cada requisito con los productos intermedios o finales que se irán elaborando a lo largo del proyecto. Esta tabla permite también priorizar, en caso de conflicto, la importancia de unos requisitos frente a otros, por ejemplo:

  • Requisitos comparados con objetivos de negocio

  • Requisitos comparados con objetivos del proyecto

  • Requisitos comparados con hitos, productos y EDT

  • Requisitos comparados con diseño

  • Requisitos comparados con construcción

  • Requisitos comparados con test

  • Requisitos de alto nivel comparados con requisitos de detalle

2.3.2.Definición detallada del alcance
Alcance es el hecho de disponer de requisitos detallados, de calidad, priorizados, acordados y evaluables, lo que permite transformar la definición inicial del alcance o definición del proyecto sin más, que realizamos en la etapa de iniciación en una definición operativa (que puede plasmarse en acciones), que podemos convertir en un plan.
Normalmente, ni el cliente ni la empresa de servicios admitirá un contrato subordinado a la toma de requisitos de detalle, ni internamente dará un mandato a un director de proyecto con esas condiciones. La realidad es así. Se necesita un presupuesto inicial, un calendario inicial y un alcance inicial para empezar a trabajar. Pero para poder planificar el proyecto, se necesita una definición de requisitos mucho más precisa.
La definición detallada del alcance, por lo tanto, es un producto no muy diferente de la definición inicial, pero sí más refinado, preciso y detallado y que incorpora una descripción precisa del producto o productos a obtener (informes, pantallas, interfaces, etc.) y en ocasiones requisitos de calidad (márgenes de error en el código o en la parametrización, rendimientos, etc.). De algún modo, en la definición detallada del alcance se dibuja lo más ajustadamente posible cómo funcionará el nuevo sistema en la realidad.
2.3.3.Estructura de descomposición del trabajo (EDT)
Recordemos que según el PMBOK, crear la estructura de descomposición del trabajo consiste en subdividir el trabajo y los entregables del proyecto en componentes más pequeños y manejables. Se trata, por lo tanto, de una descomposición jerárquica y orientada a productos. Idealmente, se trata de romper un producto grande en otros más pequeños, que se llaman paquetes de trabajo (work packages), más fáciles de valorar, controlar y colocar en el calendario.
Ejemplo
En un proyecto de construcción e implantación de software a medida (siguiendo la metodología típica de desarrollo estructurado a lo largo del ciclo de vida, system development life cycle), hipotéticamente, podríamos descomponer el total en los siguientes paquetes:

  • Gestión del proyecto

  • Toma de requisitos

  • Diseño de detalle

  • Construcción

  • Integración

  • Pruebas

  • Implantación

Si el proyecto es suficientemente grande, podríamos seguir descomponiendo cada paquete en otros menores, por ejemplo, el diseño podría incluir:

  • Planificación del diseño

  • Diseño lógico

  • Diseño físico

  • Especificaciones de seguridad

  • Especificaciones de interfaz con otros programas

  • Especificaciones de conversión de datos

  • Revisiones de usuario

  • Revisiones de personal técnico

  • Revisiones de documentación

Por lo que respecta al plan de hitos, debemos recordar que el concepto de hito (milestone) no existe en PMBOK ni en otras metodologías y procede del enfoque goal directed project management (GDPM) y se ha adoptado en parte por el estándar británico Prince2.
Los objetivos finales de un proyecto guían la definición de sus estados intermedios, los hitos. Para ser efectivos, los hitos deben:

  • Reflejar el qué y no el cómo

  • Ser fáciles de leer y entender para la dirección

  • Ser puntos de decisión

  • Ser concretos y medibles

  • Ser relevantes y limitados en número

  • Ocurrir en periodos de tiempo manejables

  • Señalar las dependencias con otros hitos

Los hitos son estados intermedios por los que pasa el proyecto hasta su finalización. Frecuentemente, pueden asociarse a la finalización de un paquete de trabajo o EDT.
Establecer un plan de hitos facilita la relación y permite que el diálogo entre la parte de negocio (en particular, el patrocinador del proyecto) y el equipo de proyecto (que suele tener un gran peso técnico), se desarrolle de una forma sencilla, visual y comprensible, antes de entrar en tecnicismos, detalles y complicadas herramientas de gestión. También permite visualizar todos los componentes ajenos al proyecto en sentido estricto (los de gestión del cambio, que se dice ahora) sobre los que el cliente tiene que actuar para asegurar el éxito del trabajo. También permite establecer responsables claros, asignar recursos y establecer fechas de finalización de cada parte del trabajo. Finalmente, establecer hitos, si se liga a los criterios de comprobación de entregables, no deja lugar a dudas: las cosas están o no están, se han hecho o no se han hecho.
Una regla sencilla para conseguir que los hitos sean útiles es redactarlos de manera que reflejen un estado a alcanzar y las condiciones para verificar que se han alcanzado.

2.4.Planificar el tiempo

En los procesos de PMBOK, los grupos de procesos o áreas de conocimiento de tiempo y coste se concentran en la etapa de planificación del proyecto (cuyo seguimiento y control se persigue, obviamente, después). Para muchos directores de proyecto, tiempo y coste se convierten también en una obsesión, que pasa por desgracia por encima de los objetivos del proyecto, la gestión del alcance y la calidad del trabajo.
Los procesos comprendidos en esta área o grupo de procesos son los siguientes:
codi_m3_004.gif
2.4.1.La planificación de las actividades
La planificación de las actividades y tareas es un proceso que deriva de la definición de los hitos del proyecto y, por lo tanto, hasta este momento no se aborda cómo actuar para conseguir los objetivos del proyecto. Los hitos son situaciones, productos, estadios del trabajo. Las actividades son acciones necesarias para alcanzar los hitos. Las tareas son acciones dentro de cada actividad.
La manera más habitual de representar un plan de actividades es mediante un diagrama de Gantt.
El diagrama de Gantt
El diagrama de Gantt muestra el tiempo en el eje de abscisas y en el eje de ordenadas se disponen todas las actividades que forman el proyecto.
En la parte izquierda se escribe el nombre de las actividades y en la parte derecha se traza una línea desde la fecha de inicio hasta la fecha de finalización de cada actividad.
codi_m3_100z.gif
Sin embargo, estas actividades son muy generales y en la planificación del proyecto se necesita un mayor detalle. Por lo tanto, las actividades se desglosan en tareas y grupos de tareas.
Es bueno volver a planificar cada grupo de actividades, al comienzo de cada nuevo hito o fase. Es probable que durante la realización del hito anterior hayan aparecido variables que aconsejen abordar el trabajo siguiente de forma diferente y con una diferente distribución de recursos.
El proceso es un trabajo de descomposición sucesiva, donde el problema habitual es decidir hasta qué nivel de detalle es conveniente llegar.
Planificación top-down y bottom-up
Estamos defendiendo un tipo de planificación iterativa en la que deben confluir dos puntos de vista:
Por una parte, los objetivos, productos y entregables del proyecto se descomponen de arriba abajo (top-down). Esta es la visión directiva.
Por otra parte, para realizar un plan detallado, ponerlo en el tiempo y valorar sus costes, necesitamos una relación de actividades, su secuenciación, la relación entre unas actividades y otras, y la carga de trabajo asociada. Esta es la visión del equipo de trabajo (bottom-up).
En los proyectos BI, usualmente, la visión “top down” se obtiene de la identificación de las necesidades de información y análisis de los directivos, mientras que la visión “bottom-up” se obtiene de la disponibilidad de datos de calidad en las bases de datos operacionales.
Este zoom entre la visión global y el detalle es una de las habilidades principales del jefe de proyecto.
Fuente: Rodríguez, García Mínguez y Lamarca (2007)
2.4.2.La estimación de esfuerzos
Es difícil hacer una estimación precisa del esfuerzo que un proyecto requiere, en especial si se trata de cosas que no se han hecho antes, si incluyen actividades o equipos de naturaleza muy diferente o si tienen muchos componentes de integración. La estimación de esfuerzos tiene mucho más de arte que de ciencia y, como todas las artes, se aprende con la experiencia más que con los libros. Entretanto, preguntar al que sabe o comparar con otros proyectos similares puede ser de ayuda.
Debe tenerse en cuenta que en esta etapa se estima cuánto se tarda normalmente en hacer una actividad (el nivel de tiempo o esfuerzo requerido), no cuándo se completará en el calendario del proyecto (la duración estimada). Una misma actividad, con una misma estimación de esfuerzo, puede ser completada antes o después dependiendo del número de recursos dedicados, las demoras o tiempos muertos o las dependencias respecto a otras actividades.
La unidad de tiempo (insistimos: esfuerzo) que utilizamos para las estimaciones dependen normalmente del tipo y tamaño de proyecto. Un proyecto se puede estimar en horas, días, meses o años/persona. Normalmente, la unidad días/persona es útil para proyectos de diferente tamaño.
El nivel de esfuerzo de un proyecto depende de las actividades a desarrollar y es independiente de la secuencia en la que realicemos las actividades o del equipo de proyecto. Pero el calendario y el coste, como veremos en los apartados siguientes, dependen de estas y otras variables. Es muy importante, para planificar y presupuestar el proyecto, tener en cuenta estas distinciones de concepto.
2.4.3.La secuencia y duración del trabajo
Si descomponemos un proyecto en cinco hitos y cada hito en cuatro actividades y cada actividad en cinco tareas, en teoría podríamos empezar todas las tareas a la vez y el proyecto duraría tanto como la tarea más larga. Pero la práctica no tiene nada que ver con esto:

  • Existen dependencias o relaciones entre actividades que obligan a realizar las actividades en un cierto orden. No todas las actividades pueden hacerse en paralelo, aunque esto sería lo ideal.

  • Los recursos no son ilimitados, en el equipo hay un número limitado de personas que no pueden hacer todas las cosas a la vez. Algunas actividades tienen que esperar a que un miembro del equipo de trabajo esté libre.

Las fases de la planificación del proyecto, que hemos presentado linealmente hasta ahora, son en bastante medida, iterativas e interrelacionadas. Se descomponen las actividades, se examina la carga de trabajo, se ve qué actividades se pueden hacer en paralelo o en serie, se mira el equipo disponible, se reexamina el orden, se revisan las posibilidades de optimizar el proceso, se calculan y recalculan los costes y la duración para que sean aceptables para el cliente y para la empresa. Se discute internamente y con el cliente.
Entre las dependencias, es importante identificar las que no están bajo nuestro control, las que son externas al proyecto. En determinadas circunstancias, un proyecto puede ir más rápido poniendo más recursos en aquellos temas que están bajo nuestro control. Esto no ocurre con aquellas actividades o dependencias externas.
La planificación de las actividades y tareas para alcanzar un hito en un proyecto y la definición de sus interdependencias permiten al gerente establecer cuál es el camino crítico (3) ; es decir, la cadena de actividades que determinan la duración global mínima de un proyecto. Cada retraso en completar una actividad en el camino crítico resultará en un retraso en la finalización general del proyecto.
2.4.4.La distribución del trabajo y recursos necesarios
Una vez establecido en detalle lo que hay que hacer, cómo se hará y el nivel de esfuerzo requerido, ya se está en condiciones de determinar la cantidad de recursos necesarios y qué características deben tener, y establecer el presupuesto de costes del proyecto.
El coste de personal (o sea, la dedicación de tiempo de las personas asignadas al proyecto) acostumbra a ser la mayor componente del coste de cualquier proyecto.
El plan de trabajo de un proyecto incorpora a la tabla los recursos que se requieren y la duración estimada del trabajo, así como la contribución de cada miembro del equipo: ¿qué capacidades, habilidades, experiencia, formación se requieren? ¿Cuánta gente de cada tipo de capacidad o formación o experiencia? ¿Cuánto cuestan o cuánto cobran? ¿Hay presupuesto para eso?
Como ya hemos comentado, una cosa son las necesidades y otra cosa son las disponibilidades y la capacidad del proyecto para costearlo. Una cosa es el plan inicial o teórico de distribución del trabajo y otra cosa es cómo quedará después de confrontarlo con la realidad.
Vale la pena dialogar entre las partes o miembros del equipo a la hora de preparar la distribución del trabajo y asignar tareas y responsabilidades. Este diálogo, como siempre, tiene al menos dos partes: el diálogo entre el cliente y el jefe de proyecto, y el diálogo entre el jefe de proyecto y cada miembro del equipo. Ese diálogo debe asegurar la comprensión y aceptación del compromiso. La dedicación del jefe de proyecto debe figurar en el plan y no se debe subestimar.
Una de las mayores causas de desviación en la gestión de proyectos es la incorrecta estimación inicial de recursos para la realización de actividades. Se han escrito muchas reglas sobre la estimación de tiempos y recursos en proyectos TIC. No existen, a nuestro juicio, recetas mágicas sobre este aspecto más que las que ya se han dado con carácter general. Desafortunadamente para los recién iniciados, en una parte importante las capacidades de estimación se van adquiriendo con la experiencia de los años. Sin embargo, sí se puede efectuar una serie de recomendaciones que creemos que pueden ser útiles para estimar proyectos informáticos complejos.
Algunas recomendaciones prácticas

  • Se debe hacer constar todas las actividades que permiten completar un hito.

  • Se debe comprobar que existen resultados claros y observables para cada actividad.

  • Cada hito no debería descomponerse en más de 10 actividades. Cada actividad no debería suponer más de 10 a 15 días/persona de trabajo.

  • No se puede asumir que si una persona necesita diez días para completar un trabajo, diez personas lo podrán hacer en un día. El tiempo y los recursos no siempre son intercambiables.

  • No se deben asignar muchas tareas en el mismo periodo de tiempo a una misma persona o la misma persona a varios proyectos. No se debe asignar a varias personas para hacer la misma cosa.

  • Nunca se deben planificar los recursos asumiendo una productividad del 100% en el trabajo, es conveniente considerar un 15% de tiempo improductivo: periodos vacacionales, bajas laborales e imponderables.

  • Asignad al mejor profesional las tareas más complejas y, si le sobra tiempo, asignadle las demás.

  • Identificad las actividades que consumen más recursos, que involucran a más personas y en departamentos diferentes y que ocupan más tiempo en el calendario. Planificadlas con más detalle, dejando márgenes de tolerancia y acordando compromisos con las partes.

  • Reducid el número de interdependencias entre las actividades al mínimo, de manera que el camino crítico sea lo más corto posible. Procurad, siempre que sea posible, que las actividades más importantes para completar un hito no estén en el camino crítico.

  • Reservad tiempo suficiente para la toma de decisiones del cliente y para la revisión y evaluación de los entregables y resultados intermedios. Dejad espacios libres en el calendario.

Fuente: Rodríguez, García, Lamarca (2007).
La mayoría de los proyectos de BI, actualmente, se basan en la parametrización o configuración de productos estándar, como veremos más adelante. El conocimiento del producto y la experiencia de su implantación suele hacer un poco más sencilla la planificación de tiempos y esfuerzos.
2.4.5.La preparación del calendario definitivo
En esta etapa, se cierra el círculo o los círculos de la planificación. Se pone en el calendario el plan de trabajo real, teniendo en cuenta los recursos disponibles y las restricciones de tiempo y de coste; se examinan los riesgos y se establece el nivel de contingencias para desviaciones o incumplimientos que puedan producirse; se revisa todo, para ver si existen oportunidades de optimización del proceso o actividades que se hayan olvidado. Y, finalmente, se discute con el cliente y, en su caso, con la propia organización.
Según hemos propuesto, nos inclinamos por una planificación orientada a los objetivos y los hitos, más que a las actividades y cargas de trabajo, aunque esta es imprescindible para desarrollar el proyecto en detalle. Los hitos son los elementos que permiten conocer y comunicar el progreso del proyecto. Normalmente, son estados en los cuales se producen entregables parciales que deben ser aprobadas por el cliente. También será el momento de revisar la planificación y de establecer planes más detallados para el trabajo que nos queda por hacer. Ahora ya se está en condiciones de poner fechas que indiquen la realización de cada hito. Las fechas para completar las actividades pueden variar. Las fechas de entrega o de consecución de hitos deberían variar lo menos posible. Un calendario de hitos facilita también el diálogo con el cliente que, sobre todo si no tiene una formación técnica, no entiende otro tipo de herramientas.
Ejemplo de calendario de hitos
Calendario de hitos
Hito
Fecha

La disponibilidad del entorno de desarrollo y de pruebas

18 de marzo

La aprobación de especificaciones, la aprobación de los diseños funcionales y técnicos

22 de abril

La aprobación del prototipo

22 de abril

La aprobación del sistema en el entorno de pruebas

27 de mayo

La aceptación en el entorno de producción

1 de julio

La aprobación de la formación completa de usuarios y la documentación técnica de operación del sistema

1 de julio

El arranque de la nueva plataforma en un entorno de portal

7 de julio
En cambio, el calendario completo, o al menos por EDT, debe incluir el detalle que se requiera en cada caso de actividades, tareas, su duración, las interdependencias, las fechas de obtención de los productos, etc. Microsoft Project, Open Project y otras herramientas permiten seguir todo el ciclo de planificación de tiempo y recursos y además su representación gráfica (aunque muchas veces, tan solo se están usando como una herramienta de presentación).
El calendario completo es la herramienta habitual de trabajo a nivel del equipo y para el detalle de las actividades y tareas.

2.5.Planificación de costes

El grupo de procesos de planificación de costes incluye la estimación y valoración de los costes de todos los recursos que estarán involucrados en el proyecto (en proyectos TIC, particularmente los recursos humanos) y la preparación del presupuesto.
En la práctica, estos procesos interaccionan con los del grupo anterior (estimación de tiempo) y a menudo se preparan conjuntamente. Debido al peso que tienen los costes de personal en la mayoría de los proyectos TIC, tiempo y dinero, en la gestión de proyectos, son dos maneras de mirar la misma cosa. Y también, como en el caso anterior, son procesos iterativos y permanentes, que se revisan y adaptan con la ejecución y seguimiento del proyecto.
Para la preparación del plan de costes se han de tener en cuenta muchos factores, que normalmente dependen del tipo y tamaño del proyecto, de las características de los recursos que participan y de la organización en la que se trabaja. Los más importantes son los siguientes:

  • La base u objetivo de la medición. Lo más habitual y recomendable es hacerlo al nivel de las EDT, o sea, de las partes o paquetes de trabajo en que hemos dividido el proyecto. Es frecuente y recomendable establecer una cuenta de coste, al menos interna, por EDT, a la que se irán cargando los costes reales incurridos.

  • Identificación del nivel de descomposición (grupos de actividades, actividades, tareas...), que dependerá principalmente de la experiencia de la organización (y de lo bien que estén documentadas sus ‘bases de conocimiento’) o del jefe de proyecto o de la clase de trabajo En todo caso, mientras que la planificación de alcance tiene una visión más estratégica y de arriba abajo (top-down), la planificación de tiempos y costes tiene una dimensión más operativa y táctica y de abajo arriba (bottom-up).

  • Las unidades de medida, que dependen del tipo de recurso. En el caso de los recursos humanos, normalmente se adjudica un coste, precio o tarifa objetivo por unidad de tiempo (hora, día, semana) por persona. En el caso de recursos técnicos, es recomendable disponer de las tarifas o listas de precios, para las estimaciones iniciales, y solicitar de varios proveedores su mejor presupuesto.

  • El nivel de precisión de las estimaciones, u orden de magnitud (rough order of magnitude, o ROM), que acostumbra a ser muy alto al comienzo del proyecto (de hasta un 50% en la etapa de iniciación) y se va acotando a medida que el proyecto avanza (entre un 10% y un 20% cuando se prepara el plan de costes).

  • El nivel de reservas o contingencias necesario para cubrir las incertidumbres (los riesgos) del proyecto. Puede variar de un proyecto a otro, en función del plan de riesgos establecido, al que dedicamos otro apartado en este módulo.

  • Los umbrales de desviación o variaciones aceptables sobre la línea base de coste, fuera de los cuales se deben levantar alarmas y tomar decisiones mayores de tiempo, alcance, calidad, etc.

  • Los formatos de presentación del presupuesto y de los informes o reporting internos y al cliente, que dependen del tipo de organizaciones (la propia y la del cliente) para las que se trabaje.

Otros aspectos a considerar para la estimación de costes

  • La estimación de costes de un proyecto debería cubrir todos los costes en que se incurrirá, también los costes de calidad, comunicación, formación del equipo, etc.

  • La estimación de costes de un proyecto debería cubrir los costes en que incurrirá el cliente por causa del proyecto o, al menos, presentarlos en el capítulo de asunciones y limitaciones de la definición de alcance.

  • La estimación de costes de un proyecto (en especial, si incluye el desarrollo o instalación de un producto) debería incluir todos los costes presentes y futuros, incluidos los de mantenimiento, evolución, formación, etc., en definitiva, lo que se conoce como coste total de la propiedad (total cost of ownership).

En los textos de ingeniería de sistemas de información y en las metodologías específicas para cada tipo de proyectos, podéis encontrar modelos y guías para la estimación de costes de los proyectos informáticos.
A pesar de todo, y con todas las limitaciones y precauciones del caso, cada día las compañías toman decisiones pequeñas, medianas y multimillonarias basadas en sus mejores estimaciones, y en la confianza de que, si las cosas van mal, será posible renegociar el presupuesto con el cliente o que su dependencia respecto al proveedor será tan grande que la renegociación sobre una relación desigual será inevitable, y por tanto, preparan y presentan presupuestos, cuyo formato y nivel de detalle dependen, como hemos dicho, de las exigencias del cliente y de la práctica de cada organización.

2.6.Planificación de la calidad

La calidad es un concepto a menudo malentendido, por eso sean cuales sean las normas de calidad incluidas en el proyecto, hace falta que sean explícitas y consensuadas con el cliente. En el entorno TIC, por el hecho de ser una ciencia immadura y en constante evolución, no resulta sencillo definir estos criterios de calidad, el ejemplo más claro está en la construcción de software. A pesar de existir una norma ISO de calidad del software, la ISO-9126, por ahora no es fácil encontrar empresas que la usen ni internamente ni externamente. Esto hace que en muchos casos, las opiniones de unos y otras sobre “qué es software de calidad”, sean diferentes, con los problemas derivados a la hora de validar el producto.
A menudo la sorpresa del jefe de proyectos es enorme cuando el cliente responde después de una entrega de un aplicativo “he revisado el código y no está muy documentado, ¿qué se puede hacer?”. En cualquier caso, haya o no normas específicas (ISO-9126, CMM, SPACE...) hay criterios y principios general de calidad que son perfectamente aplicables a un proyecto TIC (ISO-9000, EFQM, TQM, y otras).
Hay que definir y acordar (o aconsejar si fuera el caso) con el cliente cuáles son los criterios de calidad más adecuados para cada proyecto y, por supuesto, una vez identificados, producir un producto que los satisfaga plenamente. Esto quiere decir que la calidad tiene que quedar impregnada en el proceso de producción de los entregables del proyecto y, por eso, la necesidad de un plan de calidad que, una vez identificados estos criterios, ajuste los niveles de trabajo de los diferentes equipos.
La calidad tiene una segunda componente tanto o más relevante que la comentada: la calidad percibida o satisfacción del cliente. Dicho de otro modo, el producto resultante tiene que ser útil para el cliente, que le sirva para cubrir la necesidad planteada. No basta con que el producto esté perfectamente producido y ajustado a criterios de calidad técnicos, hace falta también que sea válido, que sirva. Para conseguirlo, hay que identificar bien claramente las expectativas funcionales del cliente y convertirlas en requisitos tangibles y producibles. Si se hace esta conversión, se habrá ganado mucho en el camino hacia la obtención de una solución para el cliente, y no sólo de un producto para el cliente. Esta dimensión muy a menudo es más importante en algunos proyectos BI que la calidad intrínseca o técnica del trabajo hecho.
Finalmente, hablamos de los costes de la calidad. Hay un dicho respecto de la calidad que dice “la no calidad cuesta dinero” (por el retrabajo, la insatisfacción, etc. que provoca), pero también se tiene que tener claro que “la calidad cuesta dinero”, no es el mismo producir un software con una tasa de errores del 0,3 por cada 100 puntos función, que del 0,2, por poner un ejemplo. Lo más importante es entender qué es importante, útil y necesario para el cliente y planificar la calidad en función de esto y documentar tanto como sea posible el resultado esperado y los márgenes de confianza aceptables.

2.7.Planificación de los riesgos

“En todo proyecto hay riesgos y estos pueden llevar el proyecto a una situación de crisis”. Esta frase puede parecer excesivamente dramática, pero es la realidad de la dirección de proyectos. Presuponer que porque un proyecto sea pequeño, sencillo o que ya hemos hecho otros parecidos otras veces, no hace falta ni preocuparse de los riesgos, es una mala idea y trabajar de este modo, una mala práctica.
La planificación y gestión de riesgos es un área clave de la gestión de proyectos grandes y complejos, como lo son muchos de business intelligence
Como en otras áreas de conocimiento que ya hemos comentado, hace falta que el director del proyecto analice los riesgos y, después del análisis, puede decidir no gestionar ninguno, dado que no está justificado dedicar tiempo y dinero en ellos, pero esta decisión tiene que venir de un estudio suficientemente objetivo de la realidad del proyecto y de su contexto. El problema fundamental de la gestión de riesgos está en la incertidumbre asociada a los propios riesgos; en general, es difícil disponer de información suficiente y válida, como para eliminar esta incertidumbre.
Aquí propondremos una visión práctica y simplificada de la gestión de riesgos. Hemos separado la planificación de riesgos en cuatro pasos o procesos diferentes y consecutivos:
codi_m3_005.gif
El objetivo final de la planificación es formalmente sencillo aunque complejo de alcanzar: identificar los riesgos relevantes del proyecto e incorporar las acciones necesarias per enfrentarse a ellos con éxtio.
2.7.1.Planificar la gestión de los riesgos
La planificación de la gestión de riesgos es el proceso que permitirá obtener el plan para la gestión de los riesgos, es decir, la explicación formal de cómo se gestionarán los riesgos del proyecto. La planificación de la gestión de los riesgos asegura que el nivel, el tipo y la visibilidad de los riesgos son adecuados a la importancia del proyecto. Una planificación cuidada ayudará a que el proceso de gestión de riesgos sea más acertado. Hay que recordar el alto grado de subjetividad asociado a los riesgos.
2.7.2.Identificar los riesgos
El segundo paso en el proceso de gestión de riesgos consiste en hacerse una idea de la magnitud de los riesgos que pueden afectar al proyecto. Para hacerlo, hay que empezar por identificar estos riesgos y documentar las características. Con esta información se genera el Registro de riesgos, que se irá complementando y revisando en procesos posteriores, dado que los riesgos dependen de un conjunto de factores interno y externos al proyecto que cambian con el tiempo, razón por la cual el proceso de control de riesgos tiene que incorporar como objetivo la identificación de nuevos riesgos. Para hacer esta identificación, es bueno que, dentro de lo posible, participen todos los interesados, fundamentalmente el director y su equipo de trabajo, pero también el patrocinador, el cliente y otros interesados pueden aportar información relevante sobre riesgos.
La presencia de riesgos, la incertidumbre de no saber qué puede pasar es otra manera de decir que muchos aspectos de los proyectos no se pueden predecir, a pesar de que se hagan todos los esfuerzos posibles en este sentido.
Áreas de incertidumbre
Desde el punto de vista de los procesos de gestión del proyecto, las áreas más comunes de incertidumbre son las siguientes:

  • Estimaciones de costes: las probabilidad de cumplimiento y las limitaciones de presupuesto.

  • Estimaciones de tiempos: las probabilidades de cumplimiento o no de fechas.

  • Ámbito: las hipótesis del proyecto, los entregables y los paquetes de trabajo (EDT) pueden ser fuente de riesgos en función de la capacidad para definir claramente el trabajo y la probabilidad que se den cambios en el alcance del proyecto.

  • Interesados: especialmente aquellos que son clave para la definición del alcance.

  • Planes de gestión de costes, cronograma, calidad: determinadas exigencias o márgenes que los planes pueden aportar.

  • Recursos: cantidad, calidad, disponibilidad, responsabilidad ... de los recursos asignados al proyecto.

  • Documentación del proyecto.

2.7.3.Analizar los riesgos
Cuantificar la magnitud de los riesgos identificados es un proceso costoso que ayuda a limitar adecuadamente la lista de problemas potenciales. La cuantificación permite priorizar los riesgos identificados, en general, a fuerza de combinar la probabilidad y el impacto de estos riesgos: hay que centrarse en los más prioritarios y dejar un poco de lado el resto, que podemos reunir en el epígrafe “Riesgos desconocidos”.
En esta priorización interviene la probabilidad de ocurrencia del riesgo y el impacto que puede tener sobre los objetivos del proyecto (costes, cronograma, alcance, calidad...), pero también pueden utilizarse otros factores, como por ejemplo, el plazo para resolverlo, las tolerancias de la organización ejecutante o las repeticiones posibles del riesgo. Hay que recordar que, a menudo, estas evaluaciones tienen un carácter subjetivo y en este sentido es en el que toman un gran valor las normas y los criterios que la organización haya definido para la gestión de riesgos en orden a minimizar esta subjetividad.
Es bastante habitual concretar este análisis en una matriz de impacto, identificando con colores diferentes las zonas más prioritarias (alta probabilidad e impacto) y las menos prioritarias (baja probabilidad e impacto):
Fuente: Rodríguez, García, Lamarca (2007)
Fuente: Rodríguez, García, Lamarca (2007)
La priorización y los criterios utilizados en el análisis alimentarán y actualizarán el registro de riesgos que será una entrada a los procesos posteriores.
2.7.4.Planificar la respuesta a los riesgos
Una vez identificados, evaluados y priorizados los riesgos, hay que desarrollar opciones y acciones para mejorar las oportunidades y minimizar las amenazas a los objetivos del proyecto por parte de los que se han valorado como más prioritarios. Estas acciones pueden requerir la asignación de recursos económicos y humanos, la modificación del cronograma, o del propio plan de gestión del proyecto, y es habitual asignar una persona responsable de este riesgo que gestionará las respuestas al riesgo y a la evolución del mismo.
Evidentemente, las respuestas tienen que ser congruentes con la importancia del riesgo y, a la vez, realistas y negociadas con todo el equipo, y tienen que estar disponibles en el momento adecuado. A menudo se pueden aplicar varios tipos de respuestas y hará falta que el director de proyecto seleccione la más adecuada, o las más adecuadas en cada proyecto. Igualmente, las organizaciones pueden disponer de información suficiente sobre las respuestas posibles y su aplicabilidad, sea de forma sistematizada, o como información histórica de otros proyectos.
Las respuestas a riesgos se suelen clasificar según el enfoque. En cuanto a los riesgos negativos, se habla de cuatro tipos de respuestas:

  • Evitarlos, cambiando el plan del proyecto de forma que se elimine la amenaza.

  • Transferirlos, en este caso no se elimina el riesgo, se encarga a una tercera persona u organización que le haga frente.

  • Mitigarlos, ya sea con acciones preventivas (para mitigar la probabilidad de que pase), o con acciones de contingencia (4) (para mitigar el impacto).

  • Aceptarlos, cuando no es posible o no es rentable y diseñar respuestas efectivas.

Dentro de la planificación de costes, tal como hemos visto, se habrán establecido las reservas para hacer frente a estas contingencias, que se usarán, se mantendrán o se reducirán, según el avance del proyecto. La contingencia debe ser considerada parte del proyecto hasta que el tiempo y los avances del proyecto no demuestren que el riesgo y la incertidumbre se han reducido o han desaparecido. En este momento, las partidas reservadas para contingencias tienen que volver al presupuesto general del proyecto. Por esto, el plan de contingencias debe ser revisado a lo largo de todo el proyecto.
La planificación en las metodologías de ejecución
Como se verá en el mòdulo “Ejecución de un proyecto de inteligencia de negocio”, es frecuente que las metodologías de ejecución incluyan determinadas actividades previas que se consideran necesarias para la preparación del plan (por ejemplo, la evaluación de la infraestructura técnica y no técnica del proyecto). Y al revés, que se pasen a fases posteriores algunos procesos como el análisis de requisitos y el análisis de datos, que se consideran propios de la fase de diseño.

3.Ejecución de un proyecto de inteligencia de negocio

La etapa de ejecución se compone de los procesos utilizados para completar el trabajo definido en el plan de gestión del proyecto a fin de cumplir con los requisitos del mismo. Ejecutar es hacer que las cosas se hagan, conocer y controlar el progreso y tomar las medidas de corrección que correspondan. Por eso, ejecución y control (que trataremos en el apartado de “Seguimiento y control”) van muy unidos. Los procesos de la etapa de ejecución implican coordinar personas y recursos, así como integrar y realizar las actividades del proyecto.
La ejecución representa la gestión del día a día del proyecto, desde su lanzamiento hasta su finalización, e incluye la construcción e implantación de los productos BI, el aseguramiento de la calidad, la gestión de la comunicación y las relaciones con las partes interesadas, la gestión de los recursos humanos y técnicos y la administración de compras y contratos.
Las metodologías de referencia, como PMBOK, han convenido que el despliegue de los métodos y procesos específicos de cada tipo de proyecto se produce durante la ejecución.
Por todo ello, dedicaremos el módulo “Ejecución de un proyecto de inteligencia de negocio” para tratar más extensamente la etapa de ejecución de proyectos BI.

4.Control y seguimiento del proyecto

Aunque formalmente PMBOK y otras metodologías separan los procesos de ejecución de los procesos de seguimiento y control, como ya hemos comentado, en la práctica están intrínsecamente relacionados. El control es una parte de la ejecución y proporciona elementos y avisos para mejorar la ejecución. Y la ejecución se documenta y revisa a través del control. Se ejecuta y controla lo que se ha planificado. El control se realiza contra las diferentes dimensiones del plan e informa de las desviaciones o cambios que requieren atención o, en su caso, replanificación.
Se compara, se identifican desviaciones, y se identifican sus causas, se proponen correcciones (preventivas y/o correctivas) y, si se aprueban, se actualiza el plan de proyecto y el resto de la documentación afectada.

4.1.Los procesos de seguimiento y control

Los procesos del grupo o etapa de seguimiento y control son los siguientes:

  • Control y seguimiento integrado. La tarea de seguimiento del director de proyectos consiste en tener una visión global y conjunta de todas las variables del proyecto (alcance, coste, tiempo, calidad), poniendo más énfasis (proponiendo acciones para corregir desviaciones), según el proyecto, en unas u otras.

  • Control integrado de cambios. Los cambios, inevitables muchas veces, son una fuente de problemas si no se gestionan como haría falta, este proceso recomienda un tratamiento formal de los cambios para que se integren de manera ordenada en el proyecto.

  • Control del alcance, calendario, costes, calidad y riesgos. Asegurar que se está produciendo lo que se ha acordado y de la forma como se ha acordado puede parecer obvio, pero a menudo no lo es: hay que estar pendientes de la correcta generación de los resultados del proyecto. Los riesgos no son estáticos dentro del proyecto, evolucionan con él y pueden cambiar, mutar, desaparecer (y aparecer de nuevo). El director de proyectos tiene que revisar periódicamente el estado de los riesgos del proyecto.

4.1.1.Seguimiento y control integrado del proyecto
El seguimiento y control integrado del proyecto es la tarea del jefe de proyecto. El objetivo de este proceso es regular el progreso del proyecto para lograr los objetivos de rendimiento definidos en el plan de proyecto. Para hacerlo, habrá que llevar a cabo un seguimiento de la situación real del proyecto y analizar los datos proporcionados por este seguimiento en contraste con las previsiones del plan de proyecto.
A pesar de que aparece como un proceso definido en un momento concreto, el seguimiento y control del proyecto se tiene que hacer a lo largo de toda la vida del proyecto. Este seguimiento permite al director de proyecto conocer la salud del mismo e identificar los puntos a los que hay que dedicar más atención. Concretamente, forman parte de este proceso las actividades siguientes:

  • Comparar el rendimiento real del proyecto con el teórico reflejado en el plan de proyecto.

  • Evaluar los rendimientos para determinar si hay que aplicar acciones preventivas y/o correctivas, y recomendar las más adecuadas.

  • Identificar nuevos riesgos y analizar, revisar y hacer seguimiento de los riesgos existentes.

  • Mantener una información precisa sobre los productos del proyecto.

  • Proporcionar información adecuada para los informes de estado, mediciones de grado avance y proyecciones.

  • Proporcionar proyecciones del cronograma y costes actuales.

  • Hacer un seguimiento de la implementación de los cambios que se produzcan.

4.1.2.Control integrado de cambios
El control inetgrado de cambios consite en revisar todas las solicitudes de cambios, evaluarlas, gestionar los posibles cambios en los entregables, las líneas base, el plan de gestión, los activos de los procesos de la organización y otros documentos del proyecto.
Como los proyectos nunca se desarrollan exactamente como se había planificado, hace falta una gestión rigurosa y continuada de los cambios, de manera que el plan de gestión de proyecto, el enunciado de alcance de proyecto o los productos entregables, se mantengan perfectamente actualizados.
Es especialmente relevante identificar en los procedimientos de gestión de los cambios quién tiene autoridad para aprobar la solicitud de cambios.
4.1.3.Control del alcance, calendario, costes, calidad y riesgos
Estos procesos controlan las dimensiones más críticas del proyecto, tal como las hemos presentado hasta ahora:

  • El control del alcance verifica la situación del alcance (lo que el proyecto tiene que hacer y lo que no tiene que hacer) respecto del plan de proyecto, verifica que los cambios se gestionen mediante el proceso de “Control integrado de cambios” y, si fuera el caso, gestiona las modificaciones de la línea base del alcance.

    Los cambios del alcance por razones de negocio (demandas, errores o temas poco relevantes de cliente) o de tecnología (recomendaciones, errores o carencia de planificación del proveedor) son la causa más habitual de desviaciones de coste y tiempo del proyecto TIC.

    Una de las tareas más relevantes del director de proyecto, y a menudo olvidada, es la de realizar un seguimiento esmerado de los entregables del proyecto asegurando que están alineados con la definición que se ha hecho. Esta tarea se concentra en las reuniones de seguimiento del equipo, pero también en una permanente vinculación del director con su equipo.

  • El control del calendario o cronograma consiste en hacer un seguimiento del estado del proyecto para actualizar el progreso temporal y, si fuera el caso, la línea base de tiempo.

  • El control de costes consiste en hacer un seguimiento del estado del proyecto para actualizar los costes incurridos y, si fuera el caso, la línea base de costes.

  • El control y seguimiento de la calidad comporta supervisar los resultados específicos del proyecto, como por ejemplo, los productos entregables, objetivos, procesos, sistemas de gestión, alcance, coste o cronograma, para determinar si cumplen las normas de calidad y los requisitos acordados. Los resultados del control de calidad se tienen que documentar según el plan correspondiente, de modo que permita asegurar que se están realizando efectivamente los procesos de calidad acordados.

    Muchas metodologías de producción, tanto en proyectos de informática como de telecomunicaciones, y muchas empresas fabricantes o de servicios están certificadas o han adaptado diferentes estándares de la industria, como por ejemplo, la ISO 9000 y el resto de la serie, los de la IEEE Computer Society, ITIL, COBIT, CMMi. Aixó acostumbra a hacer más fácil el seguimiento y control.

  • El seguimiento y control de riesgos es un proceso continuo que se ejecuta durante toda la vida del proyecto. Este proceso implica rastrear los riesgos identificados, hacer seguimiento de los riesgos residuales, evaluar nuevos riesgos, implementar respuestas y evaluar la efectividad de las medidas adoptadas contra los riesgos y si estas (a veces pasa) han añadido otros nuevos. Como ya hemos comentado, la gestión proactiva de los riesgos va unida a la provisión de contingencias (planes alternativos, reservas) que se tienen que adaptar a la evolución del proyecto y al seguimiento actualizado de riesgos. Finalmente, la gestión de los riesgos es una fuente privilegiada de aprendizaje para los gestores de proyectos y para las empresas de servicios y sus clientes, una vez acabado el proyecto.

A diferencia de otras áreas de conocimiento, con los riesgos de un proyecto no solo se tiene que hacer un seguimiento de los que se ha decidido gestionar. Los riesgos pueden cambiar en cualquier momento del proyecto, debido a cambios externos y/o internos y a su contexto, y esto puede alterar las hipótesis bajo las cuales se han considerado estos riesgos y se han descartado otros.
4.1.4.Información sobre el progreso o rendimiento del proyecto (reporting)
El proceso de informar del rendimiento o reporting consiste en recoger, compilar y analizar los datos reales de rendimiento del proyecto respecto de las líneas base del plan, para comunicarlos según se establezca en el plan de comunicación, a las diferentes partes interesadas (stakeholders).
El producto de estos procesos son informes de seguimiento, mediciones de progreso y proyecciones; es decir, información sobre los rendimientos reales conseguidos, comparaciones con los rendimientos teóricos y proyecciones de la situación actual hacia el futuro del proyecto. En realidad, en el proceso de reporting, estamos ordenando, documentando y pasando a limpio la información procedente del resto de los procesos de control que hemos analizado en los apartados precedentes.
Las características de estos elementos de comunicación, los informes, como por ejemplo, formatos, periodicidades, quién los prepara y otros, formarán parte del plan de comunicaciones. Se trata, en definitiva, de proporcionar una comunicación clara y concisa del rendimiento sin información innecesaria. Estos informes se tienen que elaborar con diferentes niveles de detalle y/o formato (por ejemplo, con más o menos gráficos) según las necesidades de información de los diferentes destinatarios.
Un informe de rendimiento puede incluir información sobre los aspectos siguientes:

  • Rendimiento actual y su análisis.

  • Situación de los riesgos y problemas.

  • Grado de avance del proyecto.

  • Próximas tareas.

  • Cambios aprobados en el periodo.

  • Proyecciones sobre la conclusión del proyecto.

A continuación presentamos un ejemplo de informe de seguimiento:
codi_m3_007.gif
codi_m3_007_2.gif
codi_m3_007_3.gif
codi_m3_007_4.gif

5.Cierre del proyecto

El cierre del proyecto es la fase final del trabajo. Esta fase debe cubrir cuatro objetivos principales:

  • Asegurar la aceptación de los productos.

  • Asegurar la transición del proyecto y los productos al funcionamiento ordinario en producción de los nuevos sistemas.

  • Cerrar toda la documentación administrativa y los contratos.

  • Documentar las lecciones aprendidas para las personas y la organización.

Los documentos que consideramos básicos en esta etapa son los siguientes:

  • El acta de aceptación

  • El informe de cierre

El cierre de proyecto en las metodologías de ejecución
En el módulo “Ejecución de un proyecto de inteligencia de negocio”, los procesos que aquí consideramos de cierre se incluyen en la fase llamada de “Implantación”.
Otro aspecto interesante, al que ya hicimos referencia en el mòdulo “Características de los proyectos de inteligencia de negocio” es la visión iterativa de los proyectos de BI. Más que de un proyecto con un principio y un final, estamos hablando de diferentes versiones sucesivas y ampliadas de un sistema. El proyecto BI, podríamos decir, que no se acaba nunca, que siempre está en movimiento y evolucionando en una sucesión de releases.

5.1.La gestión del proceso de cierre

En proyectos TIC, el proceso de cierre suele incluir las siguientes actividades:

  • Obtención de la aceptación del cliente; es decir, la verificación y validación del cumplimiento de los requisitos del producto y del proyecto.

  • Transición a producción; es decir, el traslado del producto a la operación ordinaria de la empresa u organización en la que debe funcionar.

  • Entrega y documentación del proyecto, también llamada cierre administrativo. Consiste en la entrega al cliente y a nuestra organización de la documentación técnica y administrativa de los productos y del proyecto.

  • Informe de postimplantación. Consiste en una reflexión informada y documentada sobre las lecciones aprendidas a lo largo del trabajo y su entrega en una base de datos de conocimiento u otros medios de los que disponga la organización.

5.1.1.Obtención de la aceptación del cliente
En los proyectos TIC, los entregables suelen ser varios y se ejecutan a lo largo del proyecto, en forma de ELT e hitos. Normalmente, en el momento de cierre de cada hito ya se ha debido producir un proceso de aceptación, que habrá quedado documentado en un acta o, alternativamente, en una reunión del comité de dirección del proyecto. En el momento de cierre, el jefe de proyecto revisará la documentación y recopilará las actas de aceptación.
Cuando hablamos de aceptación, normalmente hablamos de varias cosas, que hemos ido presentando a lo largo del material:

  • Aceptación de los productos o servicios TIC que han sido objeto del contrato o que figuran en el acta de constitución. Estos productos deben cumplir unas especificaciones, estándares o requisitos que pueden validarse a través de una comprobación visual y subjetiva y verificarse a través de diferentes procesos de prueba (testing), inspección o análisis. En sistemas de información, las pruebas de usuario suelen ser las más críticas, porque determinan también la satisfacción subjetiva (la calidad percibida).

  • Aceptación del proyecto, que normalmente incluye otra serie de entregables de diferente tipo, la comprobación de la documentación del trabajo y la satisfacción del cliente sobre el proceso de trabajo, sobre “cómo se han hecho las cosas”, la calidad de los profesionales, la interacción con su organización, la comunicación y gestión de problemas, el nivel de servicio... y que es en ocasiones muy subjetiva, pero no por eso menos importante.

El documento básico que certifica la aceptación del entregable o entregables del proyecto es el Acta de aceptación.
codi_m3_008_1.gif
codi_m3_008_2.gif
codi_m3_008_3.gif
codi_m3_008_4.gif
5.1.2.Transición a producción
Supuestamente, una vez realizada la validación y aceptación de los productos, el cliente debería hacerse cargo de su gestión y mantenimiento y los usuarios deberían sustituir sus sistemas anteriores con un apoyo limitado. En proyectos TIC, en especial los de sistemas de información y algunos de telecomunicaciones y multimedia, las cosas no son tan sencillas.
De la misma manera que cuesta obtener la validación de los productos y evitar la frustración de los usuarios, también cuesta que la organización funcional y de IT del cliente se haga cargo del producto y se puedan retirar los equipos y dar por finalizado el proyecto. El apoyo a los usuarios nunca parece suficiente y la corrección de incidencias o reparación de errores de programación (bugs) parece no acabar nunca.
El trabajo acaba cuando los usuarios (internos o externos a la organización) utilizan los nuevos sistemas masiva y satisfactoriamente y la organización de IT ha asumido su mantenimiento ordinario. No antes.
5.1.3.Entrega y documentación del proyecto
Cerrar y documentar un proyecto no es complicado si la documentación se ha preparado correctamente a lo largo de todo el proyecto. Si no, acostumbra a ser un quebradero de cabeza, en especial porque el jefe de proyecto y los equipos acostumbran a estar ya asignados a otro trabajo o a la preparación de ofertas y esto es lo último que pueden y quieren hacer.
Mantener la documentación completa y al día es un elemento crítico que posibilita la auditoría y revisión de los resultados intermedios por personas externas al equipo de proyecto y asegura la calidad de la ejecución. La documentación de proyecto debería ser planificada al inicio del proyecto, en el mismo momento en el que se planifican los entregables.
La documentación tiene dos aspectos:

  • La documentación administrativa del proyecto, compuesta por todos los informes, actas, contratos y cualquier documento que justifique las decisiones tomadas (lo que podríamos llamar, con Snyder y Parth, cierre administrativo).

  • La documentación técnica de los entregables o productos TIC, que incluye la documentación de diseño (funcional y técnico), la documentación de operaciones, la documentación de uso y el plan de mantenimiento.

La documentación debe permitir al cliente hacerse cargo del proyecto y de los productos obtenidos, operarlos normalmente en producción y mantenerlos. Si no es así, la documentación no es válida ni útil. Por eso la entrega de esta documentación es un acto formal de trasferencia al cliente de la responsabilidad sobre el resultado (en inglés, por eso, a veces a este documento se le llama Project handover document).
5.1.4.Informe de postimplantación
La valoración del proyecto es una de las actividades cruciales del cierre de un proyecto, aunque objetivamente los resultados finales de negocio y operativos del proyecto queden sujetos a una revisión posterior, cuando el nuevo sistema o aplicación ya lleve un tiempo funcionando desde su puesta en producción.
En el momento del cierre, el proyecto se considera exitoso si se han cumplido las condiciones de alcance, calidad, tiempo y coste que se establecieron en el momento de la aprobación del proyecto y si los entregables han sido aceptados por el cliente. Pero, como hemos dicho, el cierre del proyecto es también un momento de aprendizaje, para el cliente, para el equipo de proyecto y para sus miembros.
Este proceso incluye dos actividades:

  • La recopilación de lecciones aprendidas y su inclusión en una base de datos de conocimiento.

  • La evaluación de los participantes y la formulación de recomendaciones de desarrollo.

Una de las actividades principales de la fase de cierre es la recopilación, almacenamiento y utilización del conocimiento obtenido en el proyecto para nuevos proyectos. Los proyectos de la organización son una parte central de lo que ahora se denomina gestión del conocimiento.
La utilización del conocimiento recabado en la gestión de un proyecto puede apoyar todas las fases de un nuevo proyecto, desde la aprobación y definición hasta el cierre. En el ámbito comercial, la inclusión de la referencia “inteligente” del proyecto realizado en una propuesta puede hacer que sea la seleccionada por el cliente entre varios competidores, ya que demuestra una experiencia elaborada que puede ser muy útil en el transcurso del nuevo proyecto.
El conocimiento que conviene recopilar y almacenar tras la finalización del proyecto se puede desglosar en los siguientes bloques de información:

  • La descripción del proyecto según los objetivos de negocio, el alcance, el enfoque y los resultados obtenidos.

  • La clasificación de los proyectos en éxitos y fracasos, y el conocimiento de las razones de los mismos (condiciones externas, efectividad en la implantación, etc.).

  • La elaboración de recomendaciones para evitar los fracasos y asegurar los éxitos.

  • Los indicadores de necesidades de tiempos, recursos y presupuesto para trabajos específicos, que puedan aprovecharse en proyectos de naturaleza similar.

  • La documentación de materiales relevantes del proyecto a los cuales se puede acceder.

5.2.Cierre súbito del proyecto

En general, los proyectos finalizan cuando han tenido éxito o cuando han fracasado. El éxito implica que se han cumplido los objetivos marcados en tiempo, resultados y coste. El fracaso se da cuando se han sobrepasado las expectativas de tiempo y coste, cuando los resultados no son tan satisfactorios como se esperaba o cuando los objetivos ya no tienen sentido empresarial en un contexto o situación que ha cambiado.
Cerrar un proyecto antes de su finalización es la decisión más dura y difícil de la gestión de proyectos.
Recordemos de nuevo el enfoque de gestión de proyectos orientado a objetivos: un proyecto no consiste en la producción de una serie de entregables, sino en la obtención de una serie de objetivos del cliente.

5.3.Cierre de los contratos

El segundo proceso formal de la gestión del cierre es el cierre de los contratos, que forma parte del área de conocimiento de “Administración de compras y contratos”, y consiste en el cierre de los contratos existentes de acuerdo con las condiciones pactadas y la resolución, en su caso, de las reclamaciones o litigios pendientes.
El cierre de contratos es un proceso de naturaleza fundamentalmente legal y económica. Lo normal es que, tanto en su preparación como a lo largo de la ejecución, los participantes hayan sido departamentos centrales de contenido jurídico, financiero o de compras, con una intervención menor por parte del jefe de proyecto. Sin embargo, corresponde al jefe de proyecto verificar que los trabajos contratados se han realizado satisfactoriamente, en tiempo, presupuesto y calidad, según los términos pactados, y que no quedan trabajos pendientes de realizar o facturas pendientes de cobro. También le corresponde opinar, o a veces negociar, sobre las reclamaciones o litigios que puedan estar encima de la mesa.

Resumen

En este módulo hemos presentado de manera introductoria y general el ciclo de gestión de proyectos TIC, a partir del modelo de referencia que ofrece el PMBOK (4.ª, 2008).
Iniciación
Un proyecto surge, o debe surgir, cuando se identifica un problema o una oportunidad en el negocio en cualquiera de las áreas de la organización. El proyecto debería mejorar o transformar procesos de negocio para aumentar la ventaja competitiva de la empresa.
Desde el punto de vista de la gestión de proyectos, la etapa de iniciación tiene como objetivo conocer el porqué del proyecto, quiénes son las partes interesadas, y establecer qué hay que hacer. Normalmente, alguien que forma parte de la dirección de la empresa tiene que dar su aprobación formalmente. Es deseable conocer también cómo se medirá el éxito y cuál es el valor o beneficio para el negocio.
La definición preliminar del alcance establece el contenido del proyecto, los entregables o resultados parciales, los hitos y la gestión de configuraciones. Es una etapa intermedia, el eslabón que une la aprobación del proyecto con la planificación detallada.
Planificación
Una vez iniciado (aprobado) el proyecto, la planificación es el mapa de ruta que debe guiar la ejecución. El Plan de gestión de proyecto define cómo se hará, cuáles serán los procesos, técnicas, herramientas y documentos que se utilizarán para ejecutar y llevar a buen puerto el encargo.
Los elementos más críticos de la planificación son la planificación del alcance (qué se hará y qué no se hará), la duración y el presupuesto. Estos tres elementos son la línea base del plan, imprescindibles también para la ejecución y el seguimiento posterior, y se representan en un documento de alcance, un calendario o cronograma y un presupuesto de proyecto.
Otros procesos o planes complementarios son el plan de calidad, el plan de recursos humanos, el plan de comunicación, el plan de gestión de riesgos y el plan de administración y compras.
Ejecución
La etapa de ejecución se compone de los procesos utilizados para completar el trabajo definido en el plan de gestión del proyecto a fin de cumplir con los requisitos del proyecto.
Seguimiento y control
La etapa de seguimiento y control del proyecto está íntimamente enlazada con la de ejecución. Muchas acciones de prevención, seguimiento, gestión de cambios, correcciones y solución de problemas se toman en el día a día de la ejecución.
El seguimiento consiste en medir y analizar la información del proyecto para comparar el progreso y rendimiento actual con el plan, en todas sus dimensiones, y establecer tendencias y proyecciones. El control sería, en este sentido, el análisis de las variaciones, la evaluación y recomendación de las acciones que se han de realizar y su gestión.
El reporting (información del progreso y rendimiento del proyecto) muestra la situación actual, el avance, las previsiones y las alarmas sobre variaciones significativas que requieren acciones de corrección. Es importante disponer de métricas y técnicas que muestren cuantitativamente el progreso y las desviaciones.
Cierre
La última etapa del proyecto es la de cierre. Los buenos proyectos acaban de forma controlada, resolviendo los problemas y flecos que surgen inevitablemente en la entrega, retirando ordenadamente los recursos y asegurando la satisfacción del cliente y su capacidad de usar los nuevos sistemas y recuperar los beneficios que se aspiraba a obtener.
En ocasiones, un proyecto debe terminarse antes de cumplir sus objetivos, por diferentes causas. En esos casos, deben desplegarse estrategias de alarma anticipada para detectar estas situaciones, prever y gestionar la salida y realizar todos los procesos de cierre aún con más rigor de lo habitual.
Sólo es posible valorar el verdadero éxito de un proyecto con el paso del tiempo, si se han aprovechado las ventajas operativas, los usuarios han adoptado plenamente la nueva tecnología y se han realizado los beneficios de negocio que se pretendían conseguir.