El ciclo de vida de la gestión de proyectos

  • 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 i 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_00199367
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

Introducción

La mayoría de los textos de gestión de proyectos, y muchos manuales generales de gestión de las TIC, comienzan por los fracasos, fallos y errores en los proyectos de BI y TIC en general. Las conversaciones, anécdotas y chistes de los profesionales de las TIC también. Existen webs bastante divertidas dedicadas a ello. Empíricamente, se dice que más del 50% de los proyectos informáticos no responden a los objetivos que tenían planteados o han tenido desviaciones significativas de tiempo o de coste. Según algunos autores, esta cifra llega al 70%, otros autores más moderados, hablan del 30%.
El Standish Group realiza estudios periódicos sobre la salud de la gestión de proyectos en todo el mundo y, aunque es perceptible un cierto proceso de mejora, todavía un porcentaje significativo de proyectos son cancelados y la mayoría presentan desviaciones de tiempo y de coste que para el profano pueden parecer incomprensibles e insoportables.
En efecto, gestionar con éxito proyectos en general, y los que comportan el uso de tecnologías de la información y la comunicación (TIC), particularmente los proyectos de BI, es cada vez más difícil porque supone mayores niveles de exigencia (en términos de tiempo, coste y calidad), pero también de riesgo y complejidad, derivados del tamaño, la multidisciplinariedad y el cambio tecnológico. Al mismo tiempo, requiere no sólo habilidades técnicas, sino de gestión de las personas.
La gestión de proyectos es la disciplina de conocimiento y experiencia que permite planificar, organizar y gestionar proyectos.Esto quiere decir sobre todo dos cosas:

  • Asegurar que los proyectos se completan satisfactoriamente y que se consiguen sus productos y resultados últimos.

  • Hacerlo de manera que se pueda predecir y controlar su evolución, responder a los cambios y explicarlo satisfactoriamente al cliente y al equipo de trabajo.

Para el estudiante y el profesional de las TIC es crucial entender que la gestión de proyectos es una disciplina separada y superpuesta, en parte, al ciclo de producción o de despliegue de un producto de BI, que tendrá sus metodologías de producción específicas, de la misma manera que cuando se hace un puente en ingeniería de puentes, no solo se ha de saber hacer puentes; es decir, dominar las metodologías, técnicas y herramientas de hacer puentes, sino que también se ha de gestionar un proyecto; es decir, se hace el puente para un cliente con unos requerimientos, unos estándares de calidad y unos costes determinados y en un plazo de entrega prefijado.
El marco conceptual y metodológico de estos materials se basa principalmente en el Proyecto Management Body of Knowledge (PMBoK), en su última edición (la cuarta, publicada el 31 de diciembre del 2008) y, parcialmente, para los aspectos de organización, comunicación y gestión de los interesados, en el Goal Directed Project Management, que han sido adoptdos por PRINCE2,el otro estándar de referencia de la profesión. Estas metodologías proporcionan una referencia o lenguaje común para la gestión de proyectos y un conjunto de buenas prácticas, pero el profesional experto ha de reflexionar y adaptarlas a cada situación y proyecto concretos.
PMBoK se estructura en cinco grupos básicos de procesos para la gestión de cualquier tipo de proyecto (que coincide a menudo con las fases del ciclo de vida básico de muchos proyectos TIC), nuevas áreas o ámbitos de conocimiento (temas o grupos de temas que es necesario gestionar dentro del proyecto) y cuarenta y dos procesos específicos. Cada proceso se compone de unos inputs (documentos, planes, resultados de una fase anterior...), unas herramientas y unas técnicas, que se aplican para trabajar sobre estos inputs, y unos outputs (productos resultantes). El resultado es un conjunto de documentos principales, se podría decir que básicos o imprescindibles, y muchos otros documentos o instrumentos complementarios.
Para comprender la gestión de proyectos en cualquier ámbito, y particularmente en el mundo BI, es fundamental diferenciar los dos elementos siguientes:

  • El ciclo general o “gerencial” de la gestión de proyectos, que es común a cualquier tipo de proyecto TIC y que cubre desde el inicio al cierre.

  • El ciclo específico de ejecución de un tipo de producto concreto, en este caso de proyectos BI. En este enfoque, la ejecución es solo una fase específica del ciclo gerencial completo.

Para acabar de complicarlo, el concepto de proyecto BI, comprende muchos tipos diferentes de proyectos, cada uno con sus metodologías específicas, a veces definidas por el propio fabricante o implantador.
En definitiva, como dicen Moss y Autre (2003), autores de uno de los libros de gestión de proyectos de inteligencia de negocio, un buen jefe de proyecto de proyectos de business intelligence, debe ser, ante todo, un jefe de proyecto experimentado.

Objetivos

En este módulo, pretendemos proporcionar una visión general de un proyecto y de la gestión de proyectos como metodología y disciplina, de sus principales componentes y procesos. En concreto, al finalizar su estudio estaréis en disposición de:

  1. Entender qué es un proyecto, sus características y componentes, frente al resto de las operaciones ordinarias de la empresa.

  2. Mostrar las peculiaridades de los proyectos TIC frente a otras clases de proyectos en las organizaciones humanas y las empresas.

  3. Establecer y definir las dimensiones principales de un proyecto: los objetivos o requerimientos, los plazos de ejecución y los recursos y costes asociados.

  4. Establecer los factores que son críticos para el éxito o el fracaso de un proyecto.

  5. Entender las fases del ciclo de vida (o procesos de gestión, según la terminología del PMBOK) de cualquier proyecto, su objetivo, procesos y resultados, y las áreas o ámbitos de conocimiento que incluye la gestión del proyecto a lo largo de su ciclo de vida.

  6. Identificar cuáles son los procesos absolutamente básicos e imprescindibles para ela gestión del proyecto y sus productos, o documentos, resultantes.

1.Introducción a la gestión de proyectos

1.1.Definición de proyecto

En sentido amplio, un proyecto es un conjunto o una secuencia de actividades que desarrolla durante un tiempo un equipo de personas para obtener un resultado único.
Para entenderlo mejor:

  • Un proyecto es un proceso; es decir, un conjunto de actividades interrelacionadas, en las que se transforman un conjunto de recursos (inputs) en un conjunto de resultados (outputs) que tienen un sentido para alguien (un cliente).

  • Un proyecto tiene un objetivo. Normalmente, el resultado u objetivo es también un proceso, o la transformación de uno que ya existe, sea este el cálculo de la nómina, los resultados de las olimpiadas o la producción de una nueva lavadora.

  • Un proyecto tiene una duración, un inicio y un final. La temporalidad es quizá el elemento clave y diferencial de un proyecto frente a otra clase de proceso.

  • Un proyecto es único y diferente. Frente a las operaciones repetitivas, propias de la mayoría de los procesos empresariales, cada proyecto es único e irrepetible.

  • Un proyecto es multidisciplinar, involucra recursos y habilidades de diferentes partes de la organización y diferentes habilidades personales y profesionales.

  • Un proyecto tiene recursos limitados y, por lo tanto, una serie de costes, directos, indirectos y de oportunidad para la organización.

  • Un proyecto es un encargo específico, dirigido y ad hoc, que una organización hace a un grupo interno o externo de personas, que se configura para su ejecución.

El Project management body of knowledge (PMBOK), que será para nosotros la referencia metodológica más importante a lo largo de este material, como lo es actualmente para la profesión, define proyecto de la siguiente manera:
Un proyecto es un empeño temporal llevado a cabo para crear un producto, servicio o resultado único.
Figura 1. Elementos críticos de la gestión de un proyecto
Figura 1. Elementos críticos de la gestión de un proyecto
1.1.1.El Project management body of knowledge (PMBoK)
El PMBoK (1) es un estándar de gestión de proyectos reconocido internacionalmente y que se aplica en diferentes sectores (construcción, ingeniería, automoción...), incluidas las industrias TIC, que se integra con otros estándares de calidad o de producción, como ISO o CMM (el modelo de madurez en la producción de software del Software Engineering Institute). Desde 1987, el Project Management Institute publica, mantiene y actualiza PMBoK y también forma y certifica en el estándar a profesionales de todo el mundo: la certificación PMP es la más reconocida y habitual y empieza a ser exigida para los jefes de proyecto en muchas industrias y países.
En esta asignatura, adoptamos la perspectiva de que la mayoría de los proyectos TIC, y en particular los de BI, son en realidad proyectos “mixtos”, en los cuales, además de fabricar, instalar o implantar un producto técnico (que puede observarse y evaluarse físicamente), se provocan cambios en los procesos de trabajo de la organización cliente (o de la propia organización), en las actitudes, los comportamientos y el conocimiento de las personas y en el propio entorno (la “organización”), en qué el producto, o productos, deberán funcionar.
1.1.2.Goal directed project management (GDPM)
La segunda, pero no menos importante, referencia metodólogica que utilizamos en esta asignatura es GDPM (2) . GDPM fue introducida en Noruega a principios de los 80 por tres consultores informáticos, Erling Andersen, Kristoffer Grude y Tor Haug, se convirtió después en el estándar metodológico de diversas compañías de consultoría de servicio de IT y muchas de sus contribuciones se han integrado en el estándar europeo PRINCE2.
GDPM hace énfasis en la necesidad de alinear los cambios en los sistemas de información con el desarrollo de las personas y la organización (lo que modernamente se ha llamado la gestión del cambio), por lo que pone el acento en el lado humano y organizativo de los proyectos y en la necesidad de desarrollar desde el inicio una comprensión común de los objetivos y enfoque del trabajo, y una involucración y compromiso compartidos entre todos los que participan en el proyecto, en particular, la parte funcional y de negocio.
1.1.3.Proyectos TIC y productos TIC
Para el profesional de las TIC, en especial si tiene el rol de gestor de un proyecto, es crucial distinguir entre la gestión del proyecto a lo largo de todo su ciclo de vida, con toda la complejidad de procesos e interacciones que involucra, y la producción técnica de un entregable determinado. Por tanto, una cosa son las metodologías de gestión de proyecto y otra las metodologías de producción, y de ningún modo deben confundirse. Lo que ocurre es que muchos términos (fases, etapas, ciclo, procesos, entregables...) son comunes y muchas metodologías de producción, sobre todo dentro de las compañías de productos y servicios, están incorporando internamente metodologías o aspectos de las metodologías de la gestión de proyectos, lo que hace que la distinción a veces parezca puramente académica, pero no lo es.
La gestión de proyectos es un conjunto de procesos común, más amplio y separado de la entrega (fabricación, instalación o servicio) de un producto o servicio TIC. En un proyecto, respecto de la producción o instalación de un entregable, se hacen más cosas (gestionar personas, presupuestos, riesgos, facturas, contratos, expectativas...), se hacen de otra manera (con otra clase de procesos y documentos) y se utilizan otras habilidades.
Alerta
Las metodologías que se utilizan para la implantación de diferentes tipos de productos BI (por ejemplo, el road map de implantación del datawarehouse de sap sobre la suite de productos “Business Objects”), en muchas ocasiones recomendadas o facilitadas por los fabricantes, se suelen corresponder con la construcción o parametrización de productos y se corresponderían con la fase de producción o ejecución, pero no cubren el ciclo “gerencial” completo de la gestión de proyectos, tal como se propone en la literatura profesional y científica de gestión de proyectos y en esta asignatura.
Acudiendo a la metáfora, podríamos decir que, en un proyecto TIC, los ciclos de gestión del proyecto y los de creación del producto son como el yin y el yang, o como dos caras de la misma moneda. Y, desde luego, lo es así para el cliente, que difícilmente entenderá que hayamos gestionado fantásticamente el proyecto y el entregable o producto obtenido sea un desastre y no cumpla los requisitos acordados; como tampoco entenderá que el producto sea perfecto, pero los usuarios estén insatisfechos y el proyecto haya duplicado el tiempo y presupuesto acordado.
Figura 2. Relación entre producto y proyecto
Fuente: Marchewka (2003)
Fuente: Marchewka (2003)
En realidad, lo más importante, en nuestra opinión, es entender cuál es la diferencia entre fabricar un producto y hacer un proyecto, y cuáles son los principios de la gestión de proyectos que son intrínsecamente distintos de la fabricación (o la instalación) de productos o la prestación de otra clase de servicios. Y es ahí, en el límite, donde encontramos las diferencias entre unas y otras metodologías:

  • La gestión de proyectos se aplica a cualquier clase de proyecto TIC, sea de desarrollo de aplicaciones, de implantación de productos estándar, de instalación de infraestructuras o de prestación de servicios (siempre que estos tengan la naturaleza de proyecto y no sean simplemente el arrendamiento de una parte de las operaciones ordinarias de la empresa).

  • La gestión de proyectos no es secuencial o por fases (aunque hablemos de fases para explicarla), sino que consiste en la aplicación diferencial de un conjunto de habilidades, herramientas y actividades (que llamamos grupos de procesos o áreas de conocimiento) a lo largo de todo el ciclo de vida de cualquier proyecto. Es, por lo tanto, iterativa y permanente.

  • Cuantitativa y cualitativamente, el esfuerzo más importante de la gestión de proyectos no se produce en los procesos de ejecución, sino en el resto de los procesos involucrados, especialmente en la planificación y en el control. Los procesos de producción (normalmente incluidos en la ejecución) son la parte individualmente mayor, pero sólo representan un 40% del proceso.

  • La gestión de proyectos está orientada, principalmente, a la satisfacción del cliente y de sus objetivos de negocio, mientras que la fabricación de un producto está orientada a la satisfacción de unos requerimientos y el cumplimiento de unos estándares de calidad.

  • La gestión de proyectos involucra habilidades, herramientas y actividades más amplias y variadas, aunque probablemente menos especializadas, que las de la fabricación de un producto. Es probable que estas habilidades, herramientas y actividades tengan más relación con la gestión de empresas que con la ingeniería y que se adquieran más fácilmente con la experiencia que con la formación.

  • Según muestra la experiencia y la literatura de análisis de proyectos con éxito y fracasados, los factores críticos de un proyecto no tienen que ver tanto con la calidad de la producción sino con la calidad de la gestión del proyecto.

1.2.Dimensiones de un proyecto, definiciones

En palabras del PMBoK, la gestión de proyectos (3) es la aplicación de conocimiento, habilidades, herramientas y técnicas a las actividades de un proyecto para alcanzar sus requerimientos o requisitos. El director, gerente o jefe de proyecto (4) tiene la responsabilidad del cumplimiento de los objetivos del proyecto. Para que los objetivos se cumplan, el jefe de proyecto debe mantener un difícil equilibrio entre las exigencias de calidad, de alcance, de tiempo y de coste, y debe hacerlo en condiciones de incertidumbre o riesgo.
(3) En inglés, project management
(4) En inglés, project manager
Examinemos la definición anterior, de la que extraeremos las dimensiones o componentes principales de cualquier proyecto:

  • Objetivos. Un proyecto debe tener objetivos bien definidos. Denominamos objetivos a los resultados que se desean alcanzar. En un proyecto TIC es esencial entender separada y adecuadamente cuáles son los objetivos de negocio que se desean alcanzar y cómo los objetivos del proyecto permiten cumplir aquellos objetivos.

  • Resultados. En un proyecto TIC, los resultados se deben expresar en términos de entregables (productos, aplicaciones, documentación, etc.) que deben cumplir unos estándares de calidad y rendimiento.

  • Calidad. Denominamos calidad, principalmente, a la conformidad de los resultados con los objetivos y estándares establecidos al principio. La calidad tiene una dimensión objetiva (conformidad con las normas) y una dimensión subjetiva (la satisfacción del cliente y usuario, o calidad percibida).

  • Alcance. Denominamos alcance al contenido detallado y limitaciones o exclusiones en los objetivos del proyecto; es decir, la declaración explícita de lo que se hará y lo que no se hará. La gestión del alcance es acaso el componente más crítico de la gestión de un proyecto TIC y al que el PMBoK concede mayor importancia.

  • Coste. Para realizar el proyecto, se requieren recursos humanos y materiales. El valor económico de estos recursos constituye el coste del proyecto.

  • Tiempo. A diferencia de otras tareas repetitivas, el proyecto se desarrolla dentro de un límite temporal, el tiempo de duración del proyecto, desde su inicio a su terminación.

  • Riesgo. El riesgo del proyecto deriva de la incertidumbre de alcanzar los resultados con las limitaciones del tiempo, coste y niveles de calidad acordados. La identificación, gestión y respuesta adecuada frente a la ocurrencia de riesgos es fundamental en un proyecto TIC.

  • Equipo. El equipo de proyecto es el grupo de personas constituido para desarrollar el proyecto. Cada vez más, en los equipos de proyecto intervienen personas a tiempo completo y otras a tiempo parcial. Y personas asignadas por la empresa que gestiona el proyecto (proveedora) de manera estable, cuyo único cometido es el proyecto, y otras designadas por la empresa cliente para representarla.

  • Jefe de proyecto. El jefe de proyecto es el responsable último del éxito o fracaso de un proyecto, tanto desde el punto de vista técnico como económico. Para esto, tiene asignados los recursos del proyecto. El cliente se llama también espónsor del proyecto.

  • Cliente. Todos los proyectos se realizan por encargo o por contrato de alguien, el cliente, ya sea este interno o externo a la organización. El cliente es quien determina y aprueba en último lugar los objetivos, recursos, coste y duración del proyecto, y las modificaciones o revisiones.

  • Usuarios. En el cliente, hay usuarios que serán los que deban utilizar el proceso o sistema que se entrega al término del proyecto. El cliente y los usuarios tienen necesidades y objetivos de negocio que justifican la realización del proyecto, pero también tienen resistencias al cambio que deben gestionarse.

Alcance, calidad, tiempo y coste forman una especie de cuadrilátero de elementos críticos, interdependientes e interrelacionados. Cualquier cambio en uno de estos elementos, afecta a los otros tres. Las decisiones importantes del jefe de proyecto y del cliente, a lo largo de todo el proceso, tienen que ver con estos elementos.

1.3.Ciclo de vida de un proyecto

Las empresas y los autores suelen definir y clasificar de manera diversa las fases de un proyecto o, más propiamente, del ciclo de vida del proyecto. Aquí adoptaremos la clasificación del PMBoK, en la que el proyecto se divide en cinco etapas o grupos de procesos.
Figura 3. Ciclo de vida del proyecto
Figura 3. Ciclo de vida del proyecto
La clasificación del PMBoK intenta mostrar claramente la importancia de las fases anteriores y posteriores a la ejecución y que su peso en el conjunto del proyecto es, y debe serlo cada vez más, muy importante.

  • Iniciación

    En la etapa de iniciación, la dirección de la compañía identifica de diferentes maneras un problema o necesidad, lo interpreta o conceptualiza en forma de proyecto, analiza su viabilidad técnica y económica y los riesgos y, en su caso, lo aprueba.

    Habitualmente, en la agenda de la dirección y en el presupuesto de la compañía, un proyecto compite con otros para ser aprobado. Por lo tanto, esta primera fase suele incluir actividades de priorización y selección de proyectos .El producto de esta fase se documenta en formatos propios del proceso presupuestario general de la compañía o del presupuesto del área de organización y sistemas de información. En otras ocasiones, un proyecto es parte de un plan, programa o proyecto mayor, que gestiona una oficina de proyectos.

    En todo caso, el resultado de esta fase es un mandato, un acta de constitución (5) y una definición inicial del contenido, alcance y requerimientos del trabajo a desarrollar. En la 3.ª edición del PMBoK se utilizaba la expresión preliminary project scope statement y nos parece fundamental mantenerla para proyectos TIC.

  • Planificación

    En la etapa (o grupo de procesos, en la expresión que usa PMBoK) de planificación se debe, en primer lugar, revisar y, sobre todo, obtener un acuerdo o contrato explícito acerca de los temas del proyecto. El resultado principal es un documento detallado de alcance (6) ; es decir, la definición de lo que se hará y lo que no se hará.

    En la asignatura, siguiendo la metodología de gestión de proyectos orientada a objetivos, separamos la planificación estratégica del proyecto (enfocada a hitos y objetivos) de la planificación operativa (enfocada a actividades y tareas) y animamos al jefe de proyecto a manejar permanentemente este salto entre uno y otro ámbito.

    En términos del PMBoK, el resultado principal de la planificación estratégica es la descomposición del trabajo en partes o paquetes de trabajo más pequeños, o EDT (estructura de distribución del trabajo (7) ), que en realidad son entregables (8) parciales o generales.

    Seguidamente, se realiza la planificación operativa, descomponiendo cada EDT en actividades, poniéndolas en secuencia, estimando los recursos necesarios y estableciendo un calendario preliminar. Finalmente, se estiman los costes y se elabora el presupuesto.

    Una de las mayores fortalezas del PMBoK es el ejercicio de formalización del conjunto de procesos de planificación y gestión que se consideraban hasta hace no mucho “auxiliares” o “complementarios” y que la práctica de trabajo en proyectos TIC y en otras disciplinas ha demostrado que son fundamentales. De este modo, la fase de planificación incluye también los planes de calidad, recursos humanos, comunicación, gestión de riesgos y administración y compras.

  • Ejecución

    La planificación es tan importante que la fase de ejecución habitualmente contiene un ejercicio permanente de preparación de planes más detallados, revisión de los planes elaborados y comprobación de su estado de avance, replanificación de trabajos, etc. La gestión y documentación rigurosa de los cambios es otro aspecto central de esta fase. Además de estos trabajos de seguimiento y reporte, la ejecución es un ejercicio de gestión y de manejo de personas e incidentes, que justifican de sobras la dedicación de recursos experimentados sólo para controlar y manejar la ejecución. La ejecución incluye también los procesos de aseguramiento de la calidad, gestión de recursos humanos y técnicos, gestión de la comunicación y administración de las compras y contratos con los proveedores.

    La ejecución es un baño de realidad que se aprende sobre todo con la experiencia, la repetición y retos progresivos bajo la supervisión adecuada.

  • Seguimiento y control

    Los procesos de seguimiento y control puede decirse que son permanentes y paralelos a todo el proyecto (en la etapa de ejecución es cuando más se sufre su incidencia). Todos los aspectos contenidos en los diferentes planes deben ser perseguidos, evaluados y, en su caso, reajustados. Los procesos más críticos en esta fase son los de control de cambios (cualquier petición o incidencia que afecta a la planificación inicial) y los de gestión de riesgos.

  • Cierre

    La etapa de cierre incluye todas las actividades necesarias para finalizar la gestión del proyecto y completar las obligaciones contenidas en el contrato: la aceptación de los productos por parte del cliente, las revisiones posteriores al cierre acordadas, el cierre de los contratos con el cliente y proveedores, la documentación de las lecciones aprendidas, etc.

Las metodologías específicas de producción de cada tipo de proyecto, en nuestro caso de los de inteligencia de negocio, se integran convencionalmente en la fase de ejecución, en la que se llevan a cabo las operaciones técnicas que conducen a la producción de un determinado resultado final, que es el objeto del proyecto.
En la siguiente tabla se muestra un resumen del ciclo de vida de un proyecto TIC y de los diferentes procesos involucrados, que se explicarán más extensamente en los siguientes capítulos:
Principales procesos del ciclo de vida de la gestión de un proyecto TIC
Proceso
Denominación en inglés

1. Iniciación

Initiating

1.0. Estudio de viabilidad

Business case

1.1. Aprobación (acta de constitución)

Develop project charter

1.2. Identificacion de interesados

Identify stakeholders

1.3. Definicion inicial

Develop priliminary project scope statement

1.4. Organigrama del proyecto

Organisation chart

2. Planificación

Planning

2.0. Enfoque y plan de gestion del proyecto

Project management plan

2.1. Alcance detallado

Project scope planning and definition

2.2. Actividades, recursos y tiempo

Activity and time planning

2.3. Costes y presupuesto

Project cost planning

2.4. Plan de calidad

Project quality planning

2.5. Plan de recursos humanos

Human resource planning

2.7. Plan de comunicación

Project communications planning

2.8. Plan de gestion riesgos

Risk management planning

2.9. Plan de administracion y compras

Acquisitions and contracting

3. Ejecucion

Executing

3.0. Gestion de la ejecucion

Manage project execution

3.1. El lanzamiento del proyecto

Kick-off

3.2. Gestión de incidencias

Issue management

3.3. Gestión de cambios

Change management

3.4. Aseguramiento de la calidad

Quality assurance

3.5. Gestion de los recursos humanos

Human resource management

3.7. Gestion de la comunicación

Communications management

3.8. Gestion de compras y contratacion

Acquisitions management

4. Seguimiento y control

Monitoring and controlling

4.0. Seguimiento y control del trabajo

Monitor and control work

4.1. Control de cambios

Integrated change control

4.2. Control del alcance

Scope control

4.3. Control del calendario

Schedule control

4.4. Control de costes

Cost control

4.5. Control de calidad

Quality control

4.6. Informacion del progreso

Perfgormance reporting

4.7. Seguimiento y control de riesgos

Risk monitoring and control

4.8. Administracion y gestion de compras

Contract administration

5. Cierre

Closing

5.0. Cierre del proyecto

Project closing

5.1. Cierre del contrato

Contract closing

2.Las áreas de conocimiento

Dos de los aciertos, que ya hemos comentado, de la aproximación del PMBOK son, por un lado, reconocer que el ciclo de gestión de proyecto es un proceso permanente e iterativo a lo largo de todo el ciclo de producción y, por otro, que la gestión del proyecto involucra un conjunto de procesos, habilidades, herramientas y productos muy diferentes de los que se usan en el proceso de producción o construcció de determinados productos técnicos.
Esto nos lleva a preguntarnos lo siguiente:

  • ¿Qué hay que gestionar para asegurar el éxito del proyecto?

  • ¿Cuáles son las áreas o ámbitos de conocimiento que el gestor de proyecto necesita conocer y gestionar?

  • ¿Cuáles son los componentes de la gestión de proyectos como disciplina separada de conocimiento y de práctica?

Dentro de la disciplina propia de la gestión de proyectos, PMBOK recomienda nueve áreas de conocimiento o aspectos claves de todo proyecto el director del proyecto debe tener en cuenta y analizar para adecuarlo a las necesidades del proyecto. Esto no quiere decir que siempre se tengan que utilizar todos los procesos que describiremos a continuación: según cómo sea la organización, su cultura y madurez, y del tipo de proyecto (grande, pequeño, innovador, conocido,...) harán falta más o menos procesos y, a la vez, con grados de intensidad diversa.
Estos nuevos temas o áreas de conocimiento son actualmente, los siguientes:
1) Gestión de la integración (los trabajos más integrados y directivas del director de proyecto).
2) Gestión del alcance.
3) Gestión del tiempo.
4) Gestión de los costes.
5) Gestión de la calidad.
6) Gestión de los recursos humanos.
7) Gestión de la comunicación.
8) Gestión de los riesgos.
9) Administración de compras y contratos.

2.1.Gestión de la integración del proyecto

El área de conocimiento de gestión de la integración incluye las actividades y los procesos necesarios para identificar, definir, combinar, unificar y coordinar los diferentes procesos y actividades de dirección de proyectos.
Podríamos decir que estos procesos son los propios del trabajo del director del proyecto, puesto que son, básicamente, tareas de coordinación y, mayoritariamente, no se delegan a otros miembros del equipo.
Gestionar la integración, quiere decir tomar decisiones respecto de la asignación de recursos (valorar en qué procesos de gestión serán más necesarios), la concreción de los objetivos (valorándose el peso en el proyecto) y gestionar las interdependencias entre las diferentes dimensiones del proyecto.
La integración también tiene que ver con la documentación y gestión del proyecto (hay que asegurar la coherencia de todos los procesos), con la relación del proyecto y con la operatoria cotidiana del cliente.
Evidentemente, no hay una única manera de dirigir un proyecto, diferentes directores de proyecto, según su experiencia, cultura y conocimientos, aplican unos procesos u otros, y con diferentes niveles de intensidad. Pero lo que sí que reconocen la mayoría de expertos es que hay que considerar todos los procesos y analizar si hace falta o no implementarlos en el proyecto en curso y con qué nivel de detalle.
Finalmente, hay que documentar las decisiones que se tomen.
La gestión de la integración del proyecto incluye los procesos siguientes:

  • Desarrollar el acta de constitución del proyecto (I).

  • Desarrollar el plan de gestión del proyecto (P).

  • Dirigir y gestionar la ejecución del proyecto (E).

  • Hacer el seguimiento y controlar el trabajo del proyecto (SC).

  • Realizar el control integral de cambios (SC).

  • Cerrar el proyecto o fase (C).

2.2.La gestión del alcance

La gestión del alcance incluye los procesos necesarios para asegurar que el proyecto producirá todo lo que haga falta para lograr el éxito del proyecto, y solo lo que haga falta; es decir, identificar qué tiene que estar incluido en el proyecto y qué no.
Por alcance entendemos la suma de productos, servicios y resultados que se entregarán en un proyecto. Por lo tanto, el alcance no afecta solo a los elementos técnicos del proyecto (como por ejemplo, hacer una aplicación web o construis un cuadro de mando) o a la documentación; forma parte del alcance cualquier elemento de producción o gestión que habrá que entregar para completar el proyecto, como por ejemplo la formación, las pruebas, los estudios técnicos, el plan de proyecto (o una parte del mismo) o los informes de seguimiento.
Ya hemos comentado la importancia de diferenciar alcance del proyecto y alcance del producto:

  • Alcance del proyecto se asocia al trabajo que hay que realizar para entregar el producto, servicio o resultado con las funciones y características especificadas.

  • Alcance de producto se centra en las características y funciones que definen un producto, servicio o resultado.

El alcance del proyecto tiene que quedar definido al inicio del proyecto, el alcance del producto, en cambio, requerirá sucesivos trabajos y refinamientos hasta quedar totalmente definido, obviamente, antes de iniciar los procesos que lo tendrán que producir.
El proyecto, o una fase del mismo, se podrá considerar finalizado cuando se haya cumplido la línea base del alcance. Esto quiere decir, en general, una vez producidos, validados, entregados y aceptados todos los entregables del proyecto (o fase), y logrados los objetivos definidos en el enunciado del alcance.
La definición correcta del alcance constituye el proceso de planificación más importante porque el resto de áreas (costes, riesgos, etc.), y sus interacciones dependen de él. También es importante planificar correctamente el alcance porque protegerá el proyecto de modificaciones excesivas sobre las previsiones acordadas.
La gestión del alcance del proyecto incluye los procesos siguientes:

  • Recopilar requisitos (P)

  • Definir el alcance (P)

  • Crear el EDT (P)

  • Verificar el alcance (E)

  • Realizar el control del alcance (SC)

2.3.La gestión del tiempo

La gestión del tiempo incluye los procesos necesarios para asegurar que el proyecto se desarrollará según las restricciones temporales e hitos acordados con el cliente. La gestión temporal del proyecto tiene muchas vinculaciones con el resto de áreas de conocimiento, por este motivo, a menudo hay que revisar y ajustar el plano temporal debido a decisiones en otras áreas.
En proyectos pequeños es normal que los procesos no se desarrollen de manera marcadamente secuencial, acostumbran a interactuar, a encabalgarse avanzando de manera paralela para obtener el resultado final.
Hay que documentar no solo el cronograma o calendario del proceso, sino también lo que se denomina modelo del cronograma, que incluye los datos y el los criterios o métodos que se han utilizado para elaborarlo.
Evidentemente, no habrá que documentar ni el cronograma ni el modelo de cronograma cuando tanto el uno como el otro formen parte de políticas estandarizadas de la organización que se han aplicado en el proyecto en curso.
La gestión del tiempo del proyecto incluye los procesos siguientes:

  • Definir actividades (P)

  • Secuenciar actividades (P)

  • Estimar los recursos de las actividades (P)

  • Estimar la duración de las actividades (P)

  • Desarrollar el cronograma (P)

  • Realizar el control del cronograma (SC)

2.4.La gestión de los costes

La gestión de los costes del proyecto incluye los procesos relacionados con la estimación, preparación y control del presupuesto del proyecto, para que este se ajuste en el presupuesto aprobado.
Como pasa con el resto de procesos de planificación, a menudo hay que revisar y ajustar el presupuesto debido a decisiones en otras áreas (que afecten el alcance, el tiempo o la calidad) hasta que se obtiene una propuesta económica coherente y adecuada a las necesidades del proyecto.
En proyectos pequeños la planificación de alcance, tiempo y costes (e incluso de la calidad) se hace a la vez y de manera iterativa y ni tan formalizada y secuencial.
Por otro lado, cuando se toman decisiones sobre los costes del proyecto, hay que tener presente los costes operativos futuros del producto. Algunas decisiones pueden tener consecuencias en los costes recurrentes subsecuentes del producto obtenido y todo debe quedar convenientemente documentado y acordado.
Costes totales
Considerad el esfuerzo en las pruebas de un producto de software: cuanto más esfuerzo de pruebas, menos incidencias en el producto una vez está en explotación. O, en un proyecto de parametrización de un software estándar, los costes de mantenimiento y licencias y su actualización.
Hay que considerar de manera similar los niveles de calidad exigibles en cada una de las manchas como un factor de coste a evaluar, como, por ejemplo, el nivel de errores de código o el nivel de rendimiento (diponibilidad, tiempo de respuesta).
La gestión de los costes del proyecto incluye los procesos siguientes:

  • Estimar costes (P)

  • Determinar el presupuesto (P)

  • Realizar el control del presupuesto (SC)

2.5.La gestión de la calidad

Los procesos de gestión de calidad del proyecto incluyen todas las actividades que determinan las políticas, los objetivos y las responsabilidades referentes a la calidad, para conseguir que el proyecto cumpla los objetivos fijados.
La calidad tiene dos dimensiones:

  • La dimensión que podemos llamar objetiva o en conformidad con unos requerimientos o estándares. En este sentido, la calidad es “el grado en que un conjunto de características inherentes cumple los requisitos”.

  • La dimensión subjetiva, en lo referente a la satisfacción del cliente o la conformidad con sus expectativas.

La calidad se refiere tanto al producto (resultados), como al proyecto (cómo se gestiona). En general, la calidad del producto es diferente y requiere técnicas diferentes según el sector de actividad; por el contrario, la calidad de la gestión es común a la mayoría de sectores.
Por ejemplo, es necesario, para una buena gestión de la calidad, que las necesidades establecidas o implícitas se transformen en requisitos explícitos, mediante los procesos de “Recopilar requisitos”, una mala definición de la calidad esperada comporta quejas, malentendidos y finalmente insatisfacción.
De igual forma, un proceso de producción que produzca productos de baja calidad, o sea, que incumplen en alguna medida los requisitos, generan frustración, desmotivación, repetición del trabajo y quejas de los clientes y también del propio equipo de trabajo.
En el entorno de las TIC, desgraciadamente no hay muchas normativas de calidad de procesos y, a menudo, las que hay no son suficientemente conocidas. En cambio, comienzan a ser mñas frecuentes las normas de calidad de los productosm, como por ejemplo, las normas ISO.
Se tiene que tener presente, finalmente, la necesidad de encontrar un equilibrio razonable entre los procesos de calidad y las dimensiones de tiempos y costes.
La gestión de calidad del proyecto incluye los procesos siguientes:

  • Planificar la calidad (P)

  • Realizar el aseguramiento de la calidad (E)

  • Realizar el control de calidad (SC)

2.6.La gestión de los recursos humanos

En la gestión de los recursos humanos del proyecto se da una cierta paradoja: todo el mundo está de acuerdo en su importancia y en la necesidad de dedicarle esfuerzos, pero no es habitual encontrar políticas, criterios, normas y todo el que comportaría un plan de gestión de los RR. HH.
Aun así, la gestión de las personas es una de las tareas que ocupa más tiempo al director del proyecto y es crucial, tanto para el éxito del proyecto como para las carreras profesionales de los miembros del equipo.
La gestión de los recursos humanos comprende los procesos orientados a organizar, gestionar y conducir el equipo del proyecto, que está compuesto por todas las personas que tienen asignado un rol y responsabilidades en el desarrollo del mismo, que pueden variar a lo largo del proyecto, dados los diferentes tipos de actividades que se tienen que desarrollar en cada momento.
Es importante destacar que una adecuada gestión de recursos humanos aumenta el grado de compromiso y colaboración en las tareas de planificación si los recursos se incorporan lo antes posible. El director del proyecto tiene que influir sobre las personas del proyecto para asegurar el mejor rendimiento, que su aportación al proyecto sea óptima y su comportamiento profesional y ético.
La gestión de los recursos humanos del proyecto incluye los procesos siguientes:

  • Desarrollar el Plan de RR. HH. (P)

  • Incorporar el equipo de proyectos (E)

  • Desarrollar el equipo de proyectos (E)

  • Dirigir el equipo de proyectos (E)

2.7.La gestión de la comunicación

La gestión de la comunicación del proyecto es el área de conocimiento que incluye los procesos necesarios para asegurar la generación, recogida, distribución, almacenamiento, recuperación y disposición final de la información del proyecto de manera adecuada y oportuna.
Una parte importante del tiempo de los directores de proyectos se invierte en tareas de comunicación, con el cliente, el patrocinador, el equipo, proveedores, personal del cliente, la propia organización y un largo etcétera.
La mejora de las comunicaciones reduce el tiempo de las tareas y las hace más eficaces a la vez que facilita el funcionamiento general del proyecto.
Hay que tener presente las características de las diferentes dimensiones en que se pueden realizar los procesos de comunicación: formal o informal, verbal y no verbal, interna o externa, oficial o no oficial, vertical u horizontal, a quién se envía, de qué forma, etc. La comunicación es un proceso muy complejo.
La gestión de la comunicación del proyecto incluye los procesos siguientes:

  • Identificar a los interesados (I)

  • Planificar las comunicaciones (P)

  • Distribuir la información (E)

  • Gestionar las expectativas de los interesados (E)

  • Informar del rendimiento (SC)

2.8.La gestión de los riesgos

Un riesgo en un proyecto, es un acontecimiento o condición incierta que, si se produce, tiene un efecto positivo o negativo sobre, como mínimo, una dimensión del proyecto (tiempo, coste, alcance o calidad). La gestión de riesgos consiste en manejar proactiva y permanentemente los riesgos reales o potenciasles del proyecto y es uno de los factores clave de la gestión.
Un riesgo puede tener una o más causas y, si se produce, uno o más impactos. Los acontecimientos positivos a menudo se denominan oportunidades. Los riesgos son problemas u oportunidades potenciales, que pueden acontecer y tienen que ver con la incertidumbre de algunos elementos vinculados al proyecto, como pueden ser hipótesis, requisitos, disponibilidad de recursos, incumplimientos de acuerdos de terceros, tecnología disponible, etc.
Todos los proyectos están sujetos a sufrir uno o más riesgos y hay que estar preparados. Los objetivos de la gestión de los riesgos del proyecto son aumentar la probabilidad del impacto de los acontecimientos positivos y disminuir la probabilidad del impacto de los acontecimientos adversos por el proyecto.
Dado el carácter subjetivo que a menudo adopta la gestión de riesgos en muchos proyectos, la tolerancia al riesgo es diversa para organizaciones y personas diferentes. Es recomendable que las organizaciones tengan normas, políticas, procedimientos y métricas que ayuden a los directores de proyectos en el tratamiento más adecuado de los riesgos, evitando en lo posible las subjetividades propias de cada persona.
Hay que disponer de políticas proactivas ante los riesgos. No identificar un riesgo potencial puede tener consecuencias catastróficas para el proyecto, pero identificar más riesgos de los necesarios, puede aumentar los costes de gestión y complicar las tareas de producción.
En este proceso se prudente encontrar el equilibrio entre los perjuicios/beneficios de los riesgos frente a los costes de las respuestas.
Hay que tener presente la existencia de riesgos conocidos y desconocidos:

  • Los riesgos conocidos han sido identificados y analizados y se ha decidido planificar respuestas por afrontarlos.

  • Los riesgos desconocidos no se han identificado y hará falta que el equipo del proyecto los aborde cuando aparezcan mediante respuestas de contingencia. Es habitual, en este sentido, disponer de un margen de gestión que pueda permitir absorber estos riesgos desconocidos (tanto económico como temporal).

La gestión de los riesgos del proyecto incluye los procesos siguientes:

  • Planificar la gestión de los riesgos (P)

  • Identificar los riesgos (P)

  • Realizar el análisis cualitativo de riesgos (P)

  • Realizar el análisis cuantitativo de riesgos (P)

  • Planificar las respuestas a riesgos (P)

  • Hacer seguimiento y controlar riesgos (SC)

Ya lo hemos comentado en otras áreas de conocimiento, pero en el caso de los riesgos es mucho más relevante. Estos procesos interactúan con las otras áreas (el alcance, el coste, el tiempo, la clidad, etc.) de manera que, a menudo, hay que revisar y ajustar el presupuesto, los recursos, el cronograma, etc. debido a decisiones en la gestión de los riesgos. Igualmente, los procesos que se presentan aquí suelen iterarse varias veces hasta que se obtiene una propuesta de riesgos coherente con el resto de áreas y al mismo tiempo se adecua a las necesidades del proyecto.

2.9.Administración de compras y contratos

La administración de compras y contratos del proyecto incluye todos los procesos y actividades que regulan las compras y contratos, tanto entre el proveedor del proyecto y el cliente, como entre el proveedor y los diferentes socios y contratistas de producto, servicios o resultados parciales fuera del equipo de proyecto.
La organización ejecutante puede ser la compradora o la vendedora, en cualquier caso, este proceso incluirá la gestión del contrato y de los cambios necesarios para desarrollar y administrar el contrato u órdenes de compra de miembros del equipo. Incluyendo la administración de cualquier tipo de relación contractual con terceros y con la propia organización ejecutante si esta relación es objeto de contrato.
La administración de compras y contratos del proyecto incluye los procesos siguientes:

  • Planificar las adqusiciones (P)

  • Realizar las adquisiciones (E)

  • Administrar las adquisiciones (SC)

  • Cerrar las adquisiciones (C)

3. Relaciones entre los procesos de gestión del ciclo de vida y las áreas de conocimiento

Una solución brillante de los autores y consultores de PMBoK ha sido relacionar los procesos de gestión del ciclo de vida (las cinco etapas de iniciación, planificación, ejecución, seguimiento y control, y cierre) con las nueve (diez para nosotros) áreas de conocimiento experto y mapear dentro de una matriz de doble entrada todos los procesos de gestión específicos que se pueden desplegar dentro de un proyecto. La tabla siguiente muestra este mapeo con las ligeras adaptaciones que hemos realizado nosotros para los proyectos TIC. Cada actividad o proceso específico se muestra dentro del grupo de procesos en el cual habitualmente pasan la mayoría de las actividades.
Tabla 2. Correspondencia entre grupos de procesos y áreas de conocimiento, según el PMBOK
Áreas de conocimiento
Grupos de procesos de gestión de proyectos
Procesos de iniciación
Procesos de planificación
Procesos de ejecución
Procesos de seguimiento y control
Procesos de cierre

Gestión de la integración del proyecto

1) Desarrollar el acta de constitución

2) Cerrar proyecto o fase

Gestión del alcance del proyecto

1) Recopilar requisitos

2) Definir el alcance

3) Crear la EDT

4) Verificar el alcance

5) Realizar el control del alcance

Gestión del tiempo del proyecto

1) Definir actividades

2) Secuenciar actividades

3) Calcular los recursos de las actividades

4) Calcular la duración de las actividades

5) Desarrollar el cronograma

6) Realizar el control del cronograma

Gestión del coste del proyecto

1) Calcular costes

2) Determinar el presupuesto

3) Realizar el control del presupuesto

Gestión de la calidad

1) Planificar la calidad

2) Realizar el aseguramiento de la calidad

3) Realizar el control de calidad

Gestión de los RR. HH.

1) Desarrollar el plan de RR. HH.

2) Incorporar el equipo de proyecto

3) Desarrollar el equipo de proyecto

4) Dirigir el equipo de proyecto

Gestión de las comunicaciones

1) Identificar interesados

2) Planificar las comunicaciones

3) Distribuir la información

4) Gestionar las expectativas de los interesados

5) Informar del rendimiento

Gestión de los riesgos

1) Planificar la gestión de riesgos

2) Identificar los riesgos

3) Realizar el análisis cualitativo de riesgos

4) Realizar el análisis cuantitativo de riesgos

5) Planificar la respuesta a riesgos

6) Hacer seguimiento y controlar los riesgos

Gestión de compras y contratos

1) Planificar las compras y contratos

2) Realizar compras y contratos

3) Administrar compras y contratos

4) Cerrar compras y contratos

Fuente: PMBOK (2008)

La base de la metodología de gestión de proyectos, es la de cualquier sistema, es decir: el proceso o conjunto de actividades de transformación de unas entradas (inputs) en unos resultados (outputs) utilizando un conjunto de conocimientos, técnicas y herramientas.
Normalmente, cada resultado es al mismo tiempo una entrada (input) para un proceso posterior, excepto cuando se trata del resultado final del proyecto.
Este proceso de transformación se representa en un diagrama de flujo:
Figura 4. Ejemplo de diagrama de flujo básico de cualquier proceso dentro del método de gestión de proyectos
Figura 4. Ejemplo de diagrama de flujo básico de cualquier proceso dentro del método de gestión de proyectos
A diferencia de las metodologías estructuradas propias de las profesiones TIC, en la metodología de gestión de proyectos no se aspira a recogerlo todo y con el máximo detalle, sino sólo los aspectos relevantes para la gestión del proyecto. Y, como ya hemos comentado, tampoco se trata de usar sistemáticamente todos los procesos de gestión y todas las herramientas y técnicas, sino de elegir (si puede ser, al comienzo) cuáles serán realmente útiles y pertinentes para el trabajo que se tiene que hacer.

3.1.Procesos y documentos básicos

codi_m2_004.gif

Resumen

La gestión de proyectos es una disciplina cada vez más importante en el mundo de las TIC y, en general, de la gestión de empresas. La gestión de proyectos proporciona al profesional de las TIC un método general para abordar cualquier clase de proyecto, aunque debe complementarse con las metodologías complementarias de ejecución propias del tipo de proyecto de que se trate en cada caso. En los poryectos de BI, por sus características, se requiere un dominio y experiencia avanzados en la gestión de proyectos.
Un proyecto es un conjunto de actividades llevado a cabo durante un tiempo por un conjunto de personas para crear un producto, servicio o resultado único. La temporalidad, la elaboración progresiva y la creación de un resultado único es lo que distingue el proyecto de las operaciones ordinarias de la empresa.
La gestión de proyectos es la disciplina de conocimiento y experiencia que permite planificar, organizar y gestionar proyectos. Esto quiere decir dos cosas:

  • Asegurar que los proyectos se completan satisfactoriamente y que se consiguen sus productos y resultados últimos.

  • Planificar el proyecto de manera que se pueda predecir y controlar su evolución, responder a los cambios y explicarlo satisfactoriamente al cliente y al equipo de proyecto.

Todo proyecto tiene un cliente o patrocinador y unos objetivos a alcanzar, con un alcance o nivel de detalle determinado, en un tiempo y presupuesto acordado y con unos estándares de calidad establecidos y medibles. Alcance, calidad, tiempo y presupuesto son las cuatro magnitudes más importantes de un proyecto y las cuatro están interrelacionadas.
El director o gerente o jefe de proyecto es el responsable último del éxito o el fracaso del proyecto, tanto desde el punto de vista técnico como económico. Para esto, tiene asignados los recursos del proyecto y las capacidades de decisión por parte del cliente o patrocinador.
El PMBoK es el estándar de gestión de proyectos reconocido internacionalmente y que se aplica en toda clase de sectores y ámbitos técnicos, incluidas las industrias TIC, que utilizamos como referencia metodológica principal en esta asignatura, aunque adaptado a las peculiaridades de la gestión de las TIC, según nuestra experiencia, la de las empresas de servicios y otra literatura académica. La 4.ª edición (2008) se estructura en 5 grupos básicos de procesos, 9 áreas o ámbitos de conocimiento y 42 procesos diferentes, además de una biblioteca de técnicas y herramientas.
Los grupos de procesos que componen la gestión de proyectos son iniciación, planificación, ejecución, seguimiento y control, y cierre. El esfuerzo cuantitativo y cualitativo empleado en la ejecución es menor que en todos los demás sumados.
Es importante distinguir el proceso de gestión de un proyecto TIC del ciclo de producción de un sistema o producto TIC (en nuestro caso, la construcción o implantación de determinados sistemas de inteligencia de negocio. Normalmente las metodologías de desarrollo de productos se integran, en la mayoría de sus componentes, dentro de los procesos de ejecución.
Muchos proyectos fallan por una gestión inadecuada, más que por un producto que no funciona. Las causas más frecuentes de error no son técnicas sino de gestión, especialmente: la falta de participación y compromiso del cliente y los usuarios, la falta de apoyo desde la dirección y la falta de una definición clara de los objetivos y alcance del proyecto.
En la disciplina propia de la gestión de proyectos, PMBOK recomienda nueve áreas de conocimiento o aspectos clave de todo proyecte que el director del proyecto debe tener en cuenta y analizar para adecuarlos a las necesidades del proyecte. Esto no quiere decir que siempre se deban utilizar todos los procesos que se describen a continuación: según la organización, su cultura y madurez, del tipo de proyecto (grande, pequeño, innovador, conocido, etc.) se necesitará ejecuta más o menso procesos y con diversos grados de intensidad. Esta decisión es, pues, una decisión estratégica para la gestión del proyecto.
Estas áreas son actualmente (4.ª edición, 2008), las siguientes:

  • Gestión de la integración (las tareas más integradas y directivas del director de proyecto).

  • Gestión del alcance

  • Gestión del tiempo

  • Gestión de los costes

  • Gestión de la calidad

  • Gestión de los recursos humanos

  • Gestión de la comunicación

  • Gestión de los riesgos

  • Administración de compras y contratos

Para cada una de estas áreas o grupos de procesos, PMBOK propone un sistema bastante integrado, en qué unas entradas (inputs) se transformn en unas salidas, productos, documentos o entregables (outputs), mediante el uso de un conjunto de técnicas i herramienas. Estos outputs son, a su vez, inputs de procesos posteriores.
En este módulo hemos presentado también los productos o documentos principals para la gestión de proyectos, los que consideramos básicos para cualquier tipo de proyectos y otros que recomendamos para proyectos de cierta dimensión i complejidad.