La gestión de proyectos. Conceptos básicos

  • José Ramón Rodríguez

    José Ramón Rodríguez

    Es consultor independiente en Dirección de Tecnologías de la Información y Gestión de Proyectos TIC, profesor de Sistemas de información y dirección de las TIC de la UOC y autor de artículos y libros sobre estas materias. A lo largo de su carrera profesional, ha alternado la actividad entre el sector privado y el sector público como directivo y consultor. Ha sido ejecutivo de empresas internacionales de servicios de sistemas de información y gerente de organización y sistemas de información en diferentes servicios públicos. Es licenciado en Filosofía y Letras, PDG del IESE y cuerpo técnico de la Seguridad Social. Su último libro es Gestión de proyectos informáticos: métodos, herramientas y casos, publicado por la editorial UOC.

PID_00153554
Ninguna parte de esta publicación, incluido el diseño general y la cubierta, puede ser copiada, reproducida, almacenada o transmitida de ninguna forma, ni por ningún medio, sea éste eléctrico, químico, mecánico, óptico, grabación, fotocopia, o cualquier otro, sin la previa autorización escrita de los titulares del copyright.

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 TIC. 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%.
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 envuelven tecnologías de la información y comunicaciones (TIC) en particular, 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.

En la práctica, cada vez más la gestión de proyectos (project management) aparece como una disciplina, actividad y hasta una profesión separada dentro de la gestión de empresas y de las organizaciones en general. Por otro lado, los buenos gestores de proyectos son profesionales muy apreciados. Por último, las empresas están adoptando la gestión de proyectos como una forma organizativa para muchas funciones y procesos de negocio y para el abordaje de proyectos de cambio de cualquier clase.
La profesión de gestor de proyectos

  • El responsable de proyecto es un profesional cuya especialización consiste en formar, organizar y dirigir el equipo de trabajo.

  • Trabaja en contacto con mucha gente (el equipo propio, el cliente, otros proveedores, partes interesadas en el proyecto, etc.).

  • Su única misión es que el proyecto se haga en los plazos y términos establecidos.

  • Para esto, debe coordinar y supervisar los trabajos (técnica y económicamente) y vigilar y actuar sobre el entorno en el que se realiza el proyecto.

  • El responsable de proyectos está sometido a una fuerte presión, pero a la vez es un trabajo apasionante, lleno de retos y variado.

  • En su perfil, es importante la capacidad analítica y de gestión, ser creativo, activo y personalmente maduro. En algunos países existen escuelas o institutos, sistemas de organización y colegios profesionales de gestores de proyectos.

  • No existen estudios de esta profesión. Muchos conocimientos están incluidos en algunas carreras técnicas (Ingeniería, Arquitectura, Informática, etc.), pero en realidad la puede realizar cualquier profesional.

  • Para la formación de gestión de proyectos, aparte de habilidades y metodologías, la formación en el trabajo y en la práctica es lo más importante y, de este modo, asumir responsabilidades progresivas en proyectos y con la adecuada supervisión y retroalimentación.

Fuente: Varios autores (2002). Descubre las profesiones actuales. Barcelona: Planeta
Desde esta cita del año 2002, muchas cosas han cambiado en España y en todo el mundo. La profesión comienza a estar reconocida, existen estudios específicos, asociaciones profesionales y sistemas de certificación, y las empresas valoran y exigen profesionales con esta formación, habilidades y experiencia.
Todas éstas son razones como para que los conocimientos en gestión de proyectos tengan un papel cada vez más importante entre los profesionales de las TIC y en los planes de estudios.

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:

  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 un proyecto 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 requisitos, los plazos de ejecución y los recursos y costes asociados.

  4. Mostrar los temas característicos de la gestión de proyectos en la actualidad: la gestión de la calidad, la gestión del alcance y limitaciones del proyecto y la gestión de los riesgos.

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

  6. Introducir otros aspectos que se desarrollarán en los capítulos siguientes, como son: el ciclo de vida o etapas principales del proyecto; los aspectos de organización, liderazgo y gestión de los recursos humanos del proyecto, y los aspectos de comunicación y relaciones internas y externas al equipo de proyecto.

1.Qué es un 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 éste el cálculo de la nómina, los resultados de las olimpiadas o la producción de una nueva lavadora.

  • 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.

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

  • Es multidisciplinario, involucra recursos y habilidades de diferentes partes de la organización.

  • 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 encarga una organización a un grupo interno o externo de personas, que se configura para su ejecución.

Muchas actividades de la vida diaria (organizar una excursión, construir una cabaña, realizar una mudanza, estudiar una carrera, etc.) son en realidad proyectos. Y cada vez más, las empresas excelentes organizan sus procesos y funciones en forma de proyectos.

1.1.El proyecto y las demás cosas

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.
Estas tres características (la temporalidad, la elaboración progresiva, y la creación de un resultado que es único, ver figura 1) serían lo más característico de un proyecto, y las tres juntas distinguirían el modo proyecto de las demás actividades o procesos que constituyen las operaciones ordinarias de la empresa:

  • Las operaciones son repetitivas y continuas, mientras que los proyectos son temporales y únicos.

  • Las operaciones son permanentes y sirven para mantener el negocio, mientras que los proyectos son temporales y acaban cuando se ha obtenido el producto.

  • Las operaciones, normalmente, ocupan una parte de la empresa de forma especializada, mientras que los proyectos se constituyen por un equipo ad hoc, del que pueden formar parte miembros de cualquier departamento así como personal externo.

Figura 1. Características únicas del proyecto
El Project management body of knowledge (PMBOK)
El PMBOK (que traduciríamos como 'cuerpo de conocimiento de gestión de proyectos') es un estándar de gestión de proyectos reconocido internacionalmente y que se aplica en toda clase de sectores (construcción, ingeniería, automoción...) y en las industrias TIC. Estos estándares se integran 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). Se publica, mantiene y actualiza desde 1987 por el Project Management Institute, que a su vez otorga formación y certificaciones profesionales en 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). Recientemente (diciembre de 2008) se ha lanzado la 4.ª edición, que es la que utilizaremos, en general, a lo largo de este material.
Como su nombre indica, el PMBOK no es una colección normativa o prescriptiva de estándares académicos, sino un marco conceptual y una colección de lo que los profesionales consideran "buenas prácticas generalmente aceptadas en gestión de proyectos" (de igual modo que los médicos, los abogados o los contables disponen de códigos de buenas prácticas en sus profesiones). Es una guía de buenas prácticas, que el profesional experto necesita reflexionar y adaptar a cada situación, a cada proyecto concreto.
El PMBOK (4.ª edición, 2008) se estructura en cinco grupos básicos de procesos (que tienden a coincidir con las etapas del ciclo de vida básico de un proyecto), nueve áreas o ámbitos de conocimiento (temas o grupos de temas que necesitan manejarse en un proyecto) y cuarenta y dos procesos que ocurren en la intersección de los grupos de procesos. Cada proceso se compone de unos inputs (documentos, planes, resultados de una fase anterior...), unas herramientas y técnicas (que se aplican y trabajan sobre los inputs) y unos outputs (productos del trabajo realizado en cada proceso y que son a su vez documentos, planes o resultados parciales). En el módulo "Componentes de la gestión de proyectos: las áreas de conocimiento" de este material, explicaremos de una forma más detallada el contenido y funcionamiento de esta guía.
El PMBOK no dispone de una adaptación sectorial para proyectos de informática, telecomunicaciones o multimedia, aunque algunos autores, de los que damos cuenta en la bibliografía, han realizado sus propias metodologías utilizando como referencia, más o menos próxima, la estructura, recomendaciones y estándares del PMI, junto con otras metodologías, referencias o prácticas. Este será nuestro caso. Estos materiales no son una adaptación del PMBOK al entorno TIC, sino una metodología de gestión de proyectos TIC que utiliza como una de sus principales referencias el PMBOK, en la medida en que se está convirtiendo paulatinamente en un estándar de hecho dentro de las industrias TIC y poco a poco las empresas demandarán de sus proveedores de servicios y del personal responsable de los proyectos metodologías y probablemente certificaciones basadas en este estándar.
Fuente: Project Management Institute (2008). www.pmi.org

1.2.Los proyectos TIC

Los proyectos TIC tienen una mayoría de características semejantes a las de los proyectos en genérico, pero tienen algunas peculiaridades o especialidades:

  • Son más o menos replicables; es decir, hay muchos parecidos, por los productos (en especial de software) o las metodologías que se utilizan. Muchas metodologías y productos son estándar para resolver determinada clase de problemas o parte de los mismos.

  • Los especialistas son informáticos, ingenieros de telecomunicaciones (y, más recientemente, de otras profesiones nuevas, como multimedia), profesionales que comparten un cuerpo de pensamiento, lenguaje, métodos y aproximación a los problemas más comunes que en otras disciplinas del conocimiento o de la práctica profesional.

  • Algunas características de los productos TIC de hardware y software, referidas a su estabilidad, volatilidad, nivel y extensión del servicio. El cambio tecnológico es más rápido en este entorno que en otros.

Los negocios modernos y la evolución de la tecnología han conducido a que los proyectos TIC tengan cada vez más componentes no tecnológicos y los proyectos de empresa cada vez más componentes TIC. Por este motivo, se produce una convergencia entre cualquier proyecto de empresa, y sus habilidades y técnicas, y los proyectos TIC. Esto puede verse en la tabla 1, en la que se presentan ejemplos actuales de proyectos TIC. En definitiva, cualquier proyecto TIC es un proyecto de negocio.
Tabla 1
Ejemplos de proyectos TIC
Desarrollo de aplicaciones a medida
Construcción de una base de datos
Adquisición e instalación de hardware, software y comunicaciones
Integración de sistemas
Implantación de software estándar
Diseño y construcción de un sitio web interactivo
Migración de aplicaciones
Instalación de una red wi-fi
Reingeniería de procesos y circuitos de información
En este material, adoptamos la perspectiva de que la mayoría de los proyectos TIC 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), ocurren y probablemente deberían ocurrir cambios en los procesos de trabajo de la organización cliente (o de la propia organización informática), en las actitudes, los comportamientos y el conocimiento de las personas y en el propio entorno (la "organización") en el que el producto o productos deberán funcionar.
Los objetivos de los proyectos son, por tanto, compuestos y complejos y la interacción con la organización es continua y cambiante.
Por eso, la aproximación a la gestión de proyectos en el ámbito de las TIC en la actualidad tiene necesariamente que reconocer todos estos elementos y ofrecer un marco general donde las "metodologías", técnicas y herramientas (en el ámbito de la infraestructura de telecomunicaciones, del desarrollo de software o en cualquier otro) son una parte de un todo más complejo.

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 y de 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 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 complementario de la entrega (fabricación, instalación o servicio) de un producto o servicio TIC. En un proyecto se hacen más cosas (gestionar personas, presupuestos, riesgos, facturas, contratos, expectativas...) y se hacen de manera diferente (con otra clase de procesos y documentos) a producir o instalar productos, y se utilizan otras habilidades.
Un buen jefe de producción o un gran analista o jefe de proyecto de desarrollo de sistemas no es necesariamente un buen director de proyecto.
Lo veremos con más detalle cuando comparemos, por ejemplo, el ciclo típico de desarrollo de un sistema de información en las metodologías estructuradas (system development lyfe cycle, o SDLC) y las etapas o grupos de procesos de la metodología de gestión de proyectos TIC.
Aun con el riesgo que tienen todas las metáforas, podemos 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 (figura 2) 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. Proyecto y producto
Fuente: Marchewka, 2003

2.Dimensiones de un proyecto

2.1.Definiciones

En palabras del PMBOK, la gestión de proyectos (project management) es la aplicación de conocimiento, habilidades, herramientas y técnicas a las actividades de un proyecto para alcanzar sus requisitos.
El director, gerente o jefe de proyecto (project manager) es la persona responsable de cumplir los objetivos del proyecto. Para esto necesita manejar el difícil equilibrio entre las exigencias de calidad, alcance, tiempo y coste, que compiten entre sí. Y tiene que hacerlo en condiciones de incertidumbre o riesgo.
Examinemos la definición anterior, de la que extraeremos las dimensiones o componentes principales de cualquier proyecto:

  • 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 con aquéllos.

  • 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.

  • 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).

  • 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.

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

  • 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.

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

  • El equipo de proyecto es el grupo de personas constituido para desarrollarlo. Cada vez más, en los equipos de proyecto intervienen personas a tiempo completo y otras personas a tiempo parcial. Y algunas de ellas serán asignadas de una manera estable al proyecto (que es su único cometido) y otras representarán a la organización usuaria (el cliente).

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

  • Todos los proyectos se realizan por encargo o por contrato de alguien, el cliente, ya sea éste 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.

  • 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 manejarse.

De todos estos componentes, hay un cuadrilátero de elementos críticos, interdependientes e interrelacionados. No se puede manejar uno de ellos sin que afecte a los demás: son los conceptos de alcance, calidad, tiempo y coste. Las decisiones importantes del jefe de proyecto y del cliente, a lo largo de todo el trabajo, tienen que ver con estos elementos. No puede asegurarse el mismo alcance y la misma calidad si disminuye el tiempo o el presupuesto. No puede ampliarse el alcance, sin ampliar el tiempo o los recursos. Si sufrimos una desviación en el tiempo de ejecución, esto afectará al coste, la calidad o el alcance, etc.
Figura 3. Elementos críticos de la gestión de un proyecto
La gestión de proyectos dirigida a objetivos (goal directed project management)
La segunda, pero no menos importante, referencia metodólogica que utilizamos en este material es GDPM (la gestión de proyectos basada en objetivos), introducida en Noruega a principios de los ochenta por tres consultores informáticos, Erling Andersen, Kristoffer Grude y Tor Haug y que se convirtió después en el estándar metodológico de las compañías de consultoría Coopers & Lybrand, PricewaterhouseCoopers y, en parte, de la actual IBM Business Consulting, que adquirió en el año 2002 la división de consultoría de la anterior.
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") y, en consecuencia, 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.
Las herramientas básicas de GDPM son muy sencillas:

  • El plan de hitos (milestones) descompone los objetivos del proyecto en resultados a conseguir, los relaciona entre sí y establece las condiciones para verificar que se han conseguido.

  • La matriz de responsabilidades establece el rol de todos los interesados en el proyecto y la responsabilidad para la toma de decisiones, la participación, comunicación e información en cada hito.

El resto de las herramientas de proyecto (y las diferentes metodologías, incluidas las guías de PMBOK) son fácilmente integrables con estas dos, de manera que los objetivos de cliente y de proyecto desde el punto de vista de negocio y la aportación de cada parte desde el punto de vista de la gestión del trabajo siempre estén presentes y no se pierdan en una maraña de diagramas, donde frecuentemente los árboles no dejan ver el bosque y la documentación del detalle hace perder de vista el porqué y para qué estamos haciendo un proyecto.
Fuente: Andersen y otros (2000). www.gdpm.com/

2.2.Ámbitos de conocimiento experto en la gestión de proyectos

Como se puede observar, estamos integrando con una perspectiva ecléctica definiciones tradicionales en la gestión de proyectos empresariales e informáticos y otras nuevas que tienen una importancia cada vez mayor.
El PMBOK reconoce cinco áreas o ámbitos principales de conocimiento experto que el equipo de proyecto debe adquirir o disponer:
1) Los propios del PMBOK (en su caso), es decir, el conocimiento de los procesos y herramientas de gestión de proyectos conocidos y codificados por la profesión y la experiencia.
2) El conocimiento, estándares y regulaciones propios del área técnica, funcional o sectorial en la que se desarrolla el proyecto (por ejemplo, las normas ISO o las gubernamentales, que afectan a determinadas industrias).
3) El conocimiento del entorno organizativo, físico, cultural, político y social en el que el proyecto se desarrolla.
4) Los conocimientos de gestión de empresas, en general, y los propios de las áreas funcionales o técnicas en las que se desarrolla el trabajo (p. ej., finanzas o atención al cliente).
5) Habilidades interpersonales, o lo que aquí llamaremos "el lado humano de la gestión de proyectos", como son las habilidades de comunicación, motivación, liderazgo, negociación, resolución de problemas, gestión de conflictos, etc.
La gestión de proyectos del siglo XXI
Harold Kerzner, que es un gurú reconocido en esta disciplina, ha hecho ver que a comienzos del siglo XXI la gestión de proyectos como especialidad integra conocimientos y prácticas de varias disciplinas independientes:

  • Gestión de proyecto: planificación, distribución, organización y control de tiempos y costes.

  • Gestión total de la calidad: el proceso de asegurar que el resultado final de un producto o servicio cumple las expectativas del cliente.

  • Ingeniería concurrente: realizar trabajos y proyectos en paralelo, más que en serie, para comprimir el plazo de realización sin incurrir en riesgo.

  • Gestión del cambio: transformación de actitudes y comportamientos de la organización para asimilar nuevos proyectos.

  • Gestión de riesgos: identificar, cuantificar y responder a los riesgos del proyecto, y minimizar el impacto sobre resultados, tiempo y coste.

Figura 4
Fuente: Kerzner (2001)

3.Ciclo de vida de un proyecto

Las empresas y los autores suelen definir y clasificar de varios modos diferentes las fases de un proyecto, o más propiamente del ciclo de vida del proyecto. Aquí adoptaremos la del PMBOK que se muestra en la figura 5.
Según el PMBOK, el proyecto se divide en cinco etapas o grupos de procesos:

  • Iniciación

  • Planificación

  • Ejecución

  • Seguimiento y control

  • Cierre

Figura 5. Ciclo de vida del proyecto
Frente a otras clasificaciones posibles, ésta intenta mostrar y visualizar más claramente la importancia de las fases anteriores y posteriores a la ejecución y el peso que en el conjunto del proyecto tienen y deben tener cada vez más. La que llamamos de iniciación incluye la aprobación y definición preliminar del proyecto. La fase de seguimiento y control es permanente y paralela a todo el ciclo de gestión. Y, como veremos, PMBOK reconoce la necesidad de una replanificación permanente o iterativa a lo largo de la ejecución.
Como se muestra en el diagrama de la figura 6 (elaborado por Kerzner para cualquier clase de proyecto en cualquier clase de sector industrial), del conjunto de recursos dedicado a un proyecto, las fases que no son la ejecución representan más o menos la misma carga de recursos que las que son de ejecución.
Figura 6. Distribución típica de recursos en el ciclo de vida
Fuente: Kerzner (2001)

3.1.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, encarga y 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 (project charter, o "acta de constitución" del proyecto) y una definición inicial del contenido, alcance y requisitos del trabajo a desarrollar (preliminary project scope statement, en la expresión que se usaba en la versión 3 del PMBOK y que nos parece interesante mantener para proyectos TIC.
Nota
En este punto, hemos introducido algunos cambios sobre la 4.ª edición del PMBOK, de acuerdo con otras metodologías, la práctica de las empresas de servicios TIC y nuestra propia práctica como consultores. Para el PMBOK, por ejemplo, las actividades previas a la aprobación no forman parte del proyecto en sí mismo. Asimismo, la definición inicial de alcance, que sí formaba parte de la 3.ª edición, ahora ha pasado a la etapa o grupo de planificación.

3.2.Planificación

La planificación detallada del trabajo es la etapa o grupo de procesos en la que se establece la hoja de ruta que tendrá que seguir el proyecto para alcanzar sus objetivos y producir los resultados o entregables esperados.
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 (scope definition, o documento de alcance), es decir, la definición, como no nos cansaremos de decir, 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 (goal directed project management), 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 zoom 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 (work breakdown structure, o estructura de distribución del trabajo), que en realidad son entregables (deliverables) 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.

3.3.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, en proyectos de cierto tamaño, justifican de sobras la dedicación de recursos experimentados sólo para controlar y manejar su 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.
La ejecución es un baño de realidad que se aprende sobre todo con la experiencia, la repetición y los retos progresivos.

3.4.Seguimiento y control

Como hemos dicho, los procesos de seguimiento y control puede decirse que son permanentes y paralelos a todo el proyecto, especialmente "pesados" en la fase de ejecución. 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.

3.5.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.
Normalmente incluye la aceptación de los productos por parte del cliente, hacer las revisiones acordadas posteriores al cierre, cerrar los contratos con el cliente y proveedores, documentar las lecciones aprendidas, etc.
En la tabla 2 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.
Tabla 2

4.El ciclo de gestión de proyecto comparado con el ciclo de producción

De igual modo que el proyecto tiene un ciclo de vida de gestión del proyecto, los productos que se obtienen en un proyecto TIC tienen su propio ciclo de vida. Una cosa y otra se relacionan, hemos dicho antes que son como el yin y el yang o las dos caras de la misma moneda, pero no son lo mismo, aunque para seguir con la confusión compartan a veces la apariencia o la terminología.
De todos los productos TIC y de todas las metodologías de producción, la más común y conocida es la SDLC, que representa las fases secuenciales por las que pasa un sistema de información a lo largo de su vida útil.
Aunque varía según la metodología que se use, normalmente se reconoce que este sistema sigue las siguientes cinco fases (figura 7):
Figura 7. Fases del ciclo de vida de desarrollo de un sistema de información
1) En la fase de planificación, se identifican los objetivos del producto y se establecen los procesos, actividades, herramientas, métodos de trabajo y recursos, dentro del tiempo y presupuesto disponible.
2) En la fase de análisis, se analiza el sistema tal como funciona en la actualidad (de forma manual o automatizada), o como se dice in inglés as is, se toman los requisitos de las partes interesadas y seguidamente se establece un modelo lógico de funcionamiento futuro o to be.
3) En la fase de Diseño, a partir del análisis de requisitos y del modelo lógico, el equipo de trabajo establece la arquitectura de hardware, bases de datos, comunicaciones, interfaces de usuario, integración con otras aplicaciones y, sobre todo, la arquitectura de software o programas de aplicación.
4) En la fase de construcción se realiza el desarrollo técnico o construcción del sistema, las pruebas y la instalación, además del entrenamiento, soporte a usuarios, soporte técnico y documentación del sistema.
5) La fase de mantenimiento y soporte es parte intrínseca del ciclo de vida del sistema, aunque no siempre forma parte del proyecto, salvo las correcciones de errores y el soporte a usuarios durante un tiempo acordado.
Si comparamos este proceso con el que hemos mostrado en las páginas anteriores para la gestión de proyectos, veremos que la mayoría de sus contenidos (al menos las fases de diseño y construcción, en su casi totalidad) forman parte de los procesos de ejecución. La fase de planificación puede incorporarse como parte de los procesos de planificación de la gestión de proyectos, en tanto que aporta el instrumental técnico y el know-how específico de cada tipo de proyecto. La fase de mantenimiento y soporte suele estar fuera del proyecto.
La visión de PMBOK
Si lo miramos al revés, los procesos de iniciación, seguimiento y control y cierre no están habitualmente dentro de las metodologías de desarrollo estructurado de sistemas. Y desde luego, estas metodologías no contemplan muchísimos de los procesos, subprocesos y actividades que ha ido desarrollando la disciplina de gestión de proyectos, entre ellos algunos tan críticos como la gestión de la comunicación, la gestión de los recursos humanos o la gestión de riesgos.
Algunos autores de la familia del PMBOK (Marchewka, 2003), consideran que todo el ciclo de vida de desarrollo forma parte de los procesos de ejecución. Otros (Snyder y Parth, 2008) consideran que las actividades de análisis y diseño forman parte de las de planificación, mientras que la construcción sería propiamente del mundo de la ejecución. Por lo tanto, para unos y otros, el ciclo de vida de desarrollo es una parte de la gestión de proyectos sin mayor discusión.
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 éstos 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, 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 en todo el conjunto sólo representan un 40% de la gestión del proyecto.

  • 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 requisitos 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 tengan más que ver con la gestión de empresas que con la ingeniería. Y que se adquieran más con la experiencia que con la formación.

  • Según muestra la experiencia y la literatura de análisis de proyectos exitosos y fracasados, los elementos 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.

Esto lo examinaremos a continuación.

5.Factores críticos de éxito en un proyecto

Las expresiones de éxito y fracaso relacionadas con un proyecto, aunque omnipresentes, son en parte subjetivas: dependen del color con que se mira. Es difícil encontrar éxitos y fracasos completos en cualquier clase de proyectos.
En términos generales, un proyecto se considera un fracaso si:

  • no se han alcanzado los objetivos o resultados previstos,

  • se han sobrepasado los tiempos asignados,

  • se han sobrepasado los recursos o costes previstos,

  • no se han alcanzado los estándares de calidad deseados.

  • el cliente y los usuarios principales no están satisfechos.

Según el Standish Group, en el 2009, de los proyectos realizados sólo el 32% alcanzaron sus objetivos, un 24% fracasaron y un 44% obtuvieron resultados dudosos o cuestionados. Estos resultados son peores que los de los años anteriores (Standish Group Chaos Report, 2010).
Se puede pensar que los proyectos fallan porque la gente no sabe hacerlos por un desconocimiento principalmente técnico. No es así, ni es la razón más frecuente. Un proyecto falla por una gran variedad de razones; en la tabla 3 se pueden ver algunas de éstas:
Fuente: Rodríguez, García, Lamarca (2007)
Tabla 3
Causas frecuentes de fracaso en los proyectos TIC
Falta de compromiso de la dirección.
Los usuarios no se involucran.
Falta de conocimiento técnico por parte del equipo.
Falta de madurez o estabilidad de la tecnología.
Malas relaciones con otras partes o departamentos interesados en el proyecto.
Mala gestión administrativa y económica del trabajo.
Falta de supervisión sobre el equipo de proyecto.
Falta de dedicación del gerente y supervisores.
Pocas reuniones de seguimiento y control.
Documentación insuficiente de progreso y seguimiento.
Pésima planificación.
Venta y contratación por debajo de las necesidades de tiempo y recursos.
Plazos de ejecución no realistas.
Mala definición de autoridad y roles dentro del equipo de proyecto.
Mal ambiente de trabajo y falta de comunicación en el equipo.
Asignación inadecuada de personal en cantidad o en los perfiles.
No se identificaron los riesgos.
En la actualidad, por los motivos de contexto que se han mostrado anteriormente (mayor complejidad técnica y organizativa, mayor presión de tiempos de entrega, cambio tecnológico), el riesgo de fracaso es aún más alto, aunque también se reconoce una mayor conciencia de los directivos de empresa y una mejora en la disciplina y profesionalización de la gestión de proyectos, que ha contribuido a reducir los fallos.
Sin embargo, de todas las razones de la tabla, hay tres que aparecen de manera estable como las más importantes o, al menos, las más citadas:
1) Gestión de proyecto deficiente o inadecuada (32% de los proyectos fallidos).
2) Falta de comunicación con el cliente o el equipo de trabajo (20%).
3) Valoración incorrecta del alcance y complejidad del proyecto (17%).
Fuente: Standish Group y KPMG
Denominamos factores críticos de éxito (FCE; en inglés critical success factors, CSF) a las condiciones necesarias individualmente y en conjunto suficientes para que ocurra el éxito.
La literatura, la experiencia de gerentes de proyecto y las metodologías de las firmas comerciales suelen disponer de listas de esta clase. Nosotros hemos preferido aquí una lista más exhaustiva, en la que intentamos balancear los aspectos técnicos, organizativos y de gestión o dirección del proyecto. Como se muestra en la figura 8, un proyecto tiene éxito cuando:
1) Están claramente establecidos el valor y los beneficios de negocio (aumento de ingresos, reducción de costes, etc.) que se obtienen al realizarlo.
2) Se establecen claramente los objetivos, resultados y productos que hay que obtener.
3) Se establecen claramente el alcance y las limitaciones del trabajo.
4) Se realizan, controlan y actualizan planes detallados, en los cuales los hitos, entregables y actividades aparecen bien especificados en el tiempo.
5) Se asegura constantemente el apoyo de la dirección, en términos de autoridad, consistencia de los objetivos y provisión de recursos.
6) Se escuchan e interpretan las expectativas de todos los usuarios y partes involucradas y se planifican y gestionan adecuadamente. Se asegura la aceptación del trabajo por parte de los usuarios y otras partes interesadas.
7) Se asignan los recursos adecuados, con las habilidades necesarias, tanto técnicas como de gestión de proyectos, así como otras habilidades funcionales que se requieran en cada caso.
8) Se monitoriza, evalúa y se obtiene retroalimentación puntual a lo largo de toda la ejecución del proyecto.
9) Existen tecnologías maduras y personal formado y disponible para dar el servicio.
10) Se identifican a tiempo y se gestionan las incidencias, crisis y desviaciones.
Para facilitar su representación gráfica y la fijación de los conceptos para el alumno, hemos llamado a estos factores "Los diez mandamientos de la gestión de proyectos".
Figura 8. Factores críticos de éxito: Los diez mandamientos de la gestión de proyectos
Fuente: Rodríguez, García, Lamarca (2007)

6.La cultura de proyecto dentro de las organizaciones: la gestión por proyectos como modelo organizativo

Desde los años ochenta, muchas organizaciones y autores han encontrado que en la gestión de proyectos y en las empresas que se dedican profesionalmente a hacer proyectos, como las ingenierías y consultoras, existen valores, culturas, costumbres y procesos de trabajo que pueden ser exportados a otras empresas (Drucker, Peters, Waterman).
Algunas industrias, como las de construcción de edificios, barcos o aviones, son inevitablemente industrias de proyecto y orientadas por proyecto. En casi todas las empresas se hacen proyectos, y algunos departamentos como los de informática o investigación y desarrollo o marketing parecen más orientados por proyectos que otros.
De las empresas orientadas por proyectos, y en particular de las de servicios profesionales, se pueden obtener algunas lecciones:

  • Están más orientadas al cliente (costumer focused) que al producto o la función. La opinión y los requisitos del cliente cuentan y son una fuente de desafío y exigencia para la gestión del día a día.

  • Están más orientadas a los resultados e hitos (goal oriented) que a las actividades y los inputs o recursos. Convierten cualquier actividad en un producto final entregable a un cliente que debe cumplir unas especificaciones.

  • Están orientadas por procesos (process oriented) y no por departamentos o funciones dentro de la organización. Cada proyecto se compone de un proceso o conjunto de procesos relacionados.

  • Fomentan el trabajo en equipo (team work oriented) más allá de las barreras funcionales o jerárquicas dentro de la organización. El valor de un miembro del equipo está en su rol dentro del proyecto y en su aportación al conjunto, con independencia de su categoría o grado jerárquico. Un gerente de un proyecto puede ser un miembro de equipo en otro proyecto distinto.

  • Casi nunca existe una función puramente directiva. Los directivos son también productores y miembros de equipos de proyecto.

  • Los recursos humanos se evalúan continuamente según sus competencias y habilidades objetivas que se muestran y visualizan fácilmente a lo largo del proyecto. La retroalimentación (feedback) inmediata por parte de los supervisores y enfrentarse frecuentemente a retos superiores y distintos aumentan el aprendizaje y la satisfacción personal en el trabajo.

  • Trabajan por fechas límite de entrega (deadlines), lo que produce una tensión de logro y productividad normalmente mayor que en otras organizaciones.

  • Cada proyecto es, incluso económicamente y en términos de reporte, una empresa, de la que se espera un resultado de beneficio. Esta situación presiona al gerente de proyecto para optimizar los recursos y genera en el equipo un sentido de propiedad y compromiso.

  • Muchas de estas empresas son o han sido cooperativas con una cultura del mérito profundamente arraigada. La evolución profesional del empleado conduce a ser directivo y socio de la empresa (aunque esto va cambiando a medida que las cooperativas de socios se convierten en corporaciones de empleados a sueldo).

  • Las organizaciones de proyecto son organizaciones orientadas comercialmente. Todo el mundo aspira a vender un proyecto, hacerlo crecer cuando se ha conseguido o replicarlo en otro cliente.

La consolidación y madurez de la gestión de proyectos como materia teórica interdisciplinar y como profesión, la emergencia de un número cada vez mayor y más formado de gerentes de proyectos y las nuevas presiones del entorno económico están llevando a las empresas a adoptar formas organizativas más flexibles y ad hoc, y a reconocer la gestión por proyectos como principio inspirador de estas transformaciones.
Por qué son tan importantes los proyectos en la empresa

"A lo largo de los años de desarrollo de la gestión de proyectos, la alta dirección de las empresas ha reconocido el papel que tienen los proyectos en la gestión estratégica de las organizaciones. Los directivos deberían observar de manera regular el potencial y las contribuciones reales que los proyectos tienen en la gestión del cambio dentro de la empresa. Más aún:

  • Los proyectos son elementos básicos en el diseño y ejecución de las estrategias de la organización.

  • La alta dirección gana mayor visión de la trayectoria estratégica de la empresa cuando observa los proyectos que se están ejecutando en la organización.

  • Los equipos directivos deberían ser conscientes de cómo la gestión de proyectos puede ayudar en el desarrollo de nuevos productos, servicios y procesos organizativos."

D. I. Cleland; L. R. Ireland (2000). Project Manager's Portable Handbook

En grandes organizaciones o departamentos de servicios informáticos recientemente se están integrando metodologías de gestión de proyectos con los modelos de gestión de operaciones (como pueden ser ITIL o CMM). La consultora CSC propone un modelo de madurez progresiva de la función de gestión de proyectos alineado con el CMM (capability maturity model) para el desarrollo de software del Software Engineering Institute.

7.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 ayudarse de las metodologías de ejecución propias del tipo de proyecto de informática, telecomunicaciones o multimedia de que se trate en cada caso.
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:
a) Asegurar que los proyectos se completan satisfactoriamente y que se consiguen sus productos y resultados últimos.
b) 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 proyecto.
Todo proyecto tiene un cliente o sponsor 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 sponsor.
En la actualidad la gestión de proyectos es una disciplina muy amplia y compleja que incluye múltiples áreas de conocimiento experto: las propias de la gestión de proyectos, las del área técnica, funcional o sectorial en la que se realiza el trabajo, conocimientos de gestión de empresas y habilidades interpersonales.
El PMBOK (o cuerpo de conocimiento de la gestión de proyectos) 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 utilizaremos como referencia metodológica principal en este material, aunque adaptado a las peculiaridades de la gestión de las TIC, a nuestra experiencia, la de las empresas de servicios y otra literatura académica. La 4.ª edición (2008) se estructura en cinco grupos básicos de procesos, nueve áreas o ámbitos de conocimiento y cuarenta y dos procesos diferentes, además de una biblioteca de técnicas y herramientas.
Los procesos que componen la gestión de proyectos son:
1)Iniciación
2)Planificación
3)Ejecución
4)Seguimiento y control
5)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. 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:
1)gestión inadecuada del proyecto,
2)falta de comunicación y
3)valoración incorrecta del alcance y la complejidad del proyecto.