Capítulo 3 .

- Gestión de proyectos

OBJETIVOS

- Comprender la noción de proyectos y el rol que ocupa el PMBOK en la constitución de un cuerpo

doctrinal internacional de gestión de proyectos.

- Conocer algunas de las principales herramientas y técnicas empleadas en la gestión de

proyectos.

- Conocer el rol de los modelos de madurez de gestión de proyectos y comprender la importancia.

3.1. Introducción

La Gestión de Proyectos es una dimensión dentro de un proyecto y no es

el proyecto en si, es decir, por una parte se muestra la dependencia de la
gestión de proyecto al tipo de proyecto dentro del cual participa. Por otra
parte, una serie de limitaciones debidas a la existencia y oportunidad de
determinados recursos, imposiciones, condiciones del medio,
compromisos y restricciones organizacionales.

Todo en su conjunto produce un paquete de documentación, el cual

contiene y refleja la historia del proyecto en todas las áreas en que se
haya desenvuelto, y la evolución del resultado finalmente obtenido con la
metodología de e-business.

En particular, la gestión de proyectos se enfoca en buscar un marco

estructurado para la gestión exitosa, buscando aportar un completo
conjunto de herramientas y técnicas. Motivo por el cual el presente
capítulo parte de la gestión de proyectos según los diversos tipos de
proyectos para después introducirse en la Guía de Fundamentos de la
Dirección de proyectos conocida como Guía del PMBOK.

Por último, se revisan una serie de modelos de madurez de gestión de

proyectos, los cuales permiten tener un marco de referencia que ayuda a
superar la falta de habilidades y competencia, además de ser un medio
para mejorar la calidad en gestión de proyectos.
3.2. Gestión de proyectos

Como ya se mencionó, la Gestión de Proyectos es una dimensión dentro

de un proyecto, por esta razón es conveniente revisar de qué manera el
proyecto influye en la visión de cómo usar la gestión de proyectos.

La gestión de proyectos intenta conseguir una planificación coherente

con los objetivos de una organización y del propio proyecto, igualmente
que el desarrollo del proyecto se acerque a lo planificado y supere las
vicisitudes del medio y del día a día. Como una manera de proveer un
lenguaje universal y común entre los profesionales de proyectos, el
Project Management Institute ha desarrollado el PMBOK, un documento
con el cual se espera que la práctica de gestión de proyectos se
convierta en un cuerpo doctrinal y referencial para los profesionales del
área. Por esta razón se presenta la gestión de proyectos desde el punto
de vista del PMBOK.

3.2.1. Noción de gestión de proyectos

El concepto de proyecto admite varias definiciones por su amplio

significado e integración en múltiples disciplinas. El proyecto es un
sistema dentro del cual coexisten dos dimensiones, la de gestión y la de
construcción. Según esto, la gestión de proyectos es un sistema que
debe construirse y ser adaptado al punto de vista de proyecto que se
maneje.

 Proyecto como producción de artefactos. Por gestión se

entiende la programación de actividades y ver que se cumplan.
 Proyecto como consecución de objetivos. El proyecto es un
conjunto de actividades concretas para un determinado resultado, y
la gestión intenta que tales actividades cumplan con las
necesidades presupuestas de antemano, siendo en esencia una
anticipación a un objetivo o a un estado de realidades predefinidas.
 Proyecto de acción. El proyecto persigue finalidades, sin
necesidad de seguir un plan de trabajo. El proyecto es actuar
siguiendo finalidades o fines y la gestión es poder anticiparse a las
transformaciones o cambios de estado del proyecto y del entorno
 que se producen conforme la finalidad se va alcanzando o
alejando.

Para ilustrar las diferencias entre el tipo de gestión de proyectos que uno
u otro tipo de proyecto requiera, se puede decir lo siguiente:

- En los primeros dos casos, el gestor de proyectos parte de conocer qué

conseguir y para ello busca y se nutre de varios cómo, cuándo,
quién y cuánto;

- En el último caso, el gestor de proyectos debe ayudar a buscar el qué

se desea, para lo cual dispone de varios cómo que le ayudan a
conseguir el qué.

Sin embargo, aceptando cierto grado de formalización respecto de la

gestión de proyectos asociada al proyecto como productor de artefactos,
debido a que es más sencillo controlar y regular recursos respecto
cuando hay una meta clara, que cuando ella no existe (en este caso la
meta es conseguir una meta), existen autores que sugieren que gestión
de proyectos es la planificación, organización, dirección y control de los
recursos de una empresa para un objetivo de relativo corto plazo que ha
sido establecido para completar y conseguir metas y objetivos
específicos.

Siguiendo con esta primera acepción, otros autores señalan que gestión
de proyectos es la aplicación de técnicas, métodos, herramientas y
heurísticas formales e informales, las cuales emplea un gestor de
proyectos en la motivación y guía de un equipo de personas para llevar
un proyecto dentro de un conjunto dado de restricciones.

Visto así, la gestión de proyectos pone a disposición de los gestores de

proyectos un conjunto de instrumentos de trabajo que le permiten asumir
un proyecto y superar sus vicisitudes tal que: se anticipe a los problemas,
mejore el hacer futuro, y actúe de forma adecuada ante eventos no
presupuestados.

En todo caso, debe tenerse claro que la gestión de proyectos es un

medio a disposición del gestor para construir una solución dentro de las
mejores condiciones para quienes están dentro del proyecto y para
quienes se beneficiarán del uso del producto o servicio resultante. Por
este motivo, el gestor de proyectos es una persona cuyo fin es hacer uso
armonioso de una serie de recursos intelectuales (conocimiento,
creatividad) y corpóreos (trabajo físico, esfuerzo mental), con especial
cuidado y atención a las personas. Es una labor donde especialistas
actúan con libertad como parte de un todo.

Generalizando un poco, la gestión de proyectos se debe entender como

un cúmulo de información sobre instrumentos y prácticas que se pone a
disposición de personas para hacer un uso óptimo y robusto de recursos
bajo su responsabilidad frente a restricciones y contingencias para el
cumplimiento de metas trazadas de antemano. Todo lo anterior
relacionado con tres parámetros clásicos de gestión: tiempo, coste y
desempeño, para mejorar la calidad y conseguir un riesgo cero.

No obstante, el valor agregado de esta información dependerá de la

utilidad que le otorgue el gestor del proyecto: conseguir lo que se le pide,
resolver un conflicto, aprender del hacer haciendo y, salir airoso de las
vicisitudes diarias. Esto dependerá de la habilidad que adquiera, tanto
por capacidad personal como resultado de un proceso de formación.

3.2.2. La gestión de proyectos según el PMBOK

La forma de organizar los esfuerzos y experiencia de gestión de

proyectos se han llevado adelante mediante el arte de las personas en el
rol de gestor de un proyecto o varios (programa). Organizar todo aquello
en un cuerpo doctrinal formal se ha visto dificultado por dos razones:

 No se ha manifestado un cuerpo o núcleo central al cual ceñirse los

gestores para recabar experiencias y tener un dominio común de
discusión.
 La gestión de proyectos es cultural, pues depende de las
características y singularidades del grupo de personas que
constituye y se relaciona con el proyecto.

Estas razones han hecho que hoy en día existan diversas asociaciones
dedicadas al estudio de proyectos tales como:

 IPMA. International Project Management Association.

 PMI. Project Management Institute.

Project Management Institute. El Project Management Institute (PMI) es

una organización internacional orientada a la difusión y determinación de
las mejores prácticas de gestión de proyectos. En este afán, produce
documentos que describen prácticas generalmente aceptadas de gestión
de proyectos.

PMBOK. El más importante de los documentos publicados en la

actualidad por el PMI es el PMBOK, A Guide to the Project Management
Body of Knowledge.

El propósito de esta guía es describir el conocimiento y las prácticas

usadas en varios tipos de proyectos. Durante veinte años se han estado
revisando y discutiendo cuáles son los proyectos cuyo conocimiento y
estudio aporta valor y utilidad a la práctica de proyectos. Este esfuerzo se
ha traducido en identificar prácticas de gestión de proyectos aplicables a
cualquier proyecto. La importancia del PMBOK, por sobre toda
compilación y mejora de prácticas, es que provee una base formal para
fundar proyectos, guiando y orientando a gestores de proyectos sobre la
forma de llevar adelante la construcción de resultados. Para ello, no
obstante, es menester adaptar los contenidos del PMBOK al dominio
técnico de cada proyecto en particular.

La utilidad del PMBOK se refleja en ser actualmente el estándar

ANSI/PMI 99-001-2004 (PMI, 2004) y por cumplir, según Welch, con gran
detalle el estándar ISO 10006 de gestión de proyectos. Además, por su
propia concepción, homogeneiza el conocimiento sobre la profesión de
gestión de proyectos, siendo considerado pilar o base de sistemas
internacionales de certificación para Directores de Proyecto promovidos
por el PMI y el IPMA, ambos en asociación con muchas otras
asociaciones de Proyectos locales.

Gestión de proyectos según el PMBOK. Según el PMBOK, la gestión

de proyectos es la aplicación de conocimiento, herramientas y técnicas a
actividades de un proyecto en orden a satisfacer los requerimientos del
proyecto, Todo este conocimiento, habilidades, herramientas y técnicas
se distribuyen y usan a lo largo de varios procesos de gestión de
proyectos.

Cada proceso de Gestión de Proyectos pertenece a un Área de

Conocimiento de Gestión de Procesos y se asocia a un Grupo de
Procesos de Gestión (figura 3.1).
3.2.2.1. Áreas de conocimiento de gestión de proyectos

Las nueve áreas de conocimiento (The Project Management Knowledge

Areas), se describen en la tabla 3.1.

ÁREAS DE
DESCRIPCIÓN
CONOCIMIENTO

#4. Gestión de la Incluye los procesos requeridos para asegurar que todos los elementos
Integración del proyecto son coordinados adecuadamente.

Incluye los procesos requeridos para asegurar que el proyecto incluye y

#5. Gestión del
considera solamente el trabajo requeridos para completar el proyecto
Alcance
satisfactoriamente.

Incluye los procesos requeridos para asegurar el término temporal

#6. Gestión del Tiempo
preciso y adecuado del proyecto.

Incluye los procesos requeridos para asegurar que el proyecto se

#7. Gestión del Coste
concluye dentro del presupuesto aprobado.

#8. Gestión de la Incluye los procesos requeridos para asegurar que el proyecto satisface
Calidad la necesidades para las cuales fue definido.

#9. Gestión de Incluye los procesos requeridos para hacer un uso más efectivo de las
Recursos Humanos personas involucradas en el proyecto.

Incluye los procesos requeridos para asegurar una generación,

#10. Gestión de las
recolección, diseminación, almacenamiento y disposición final en tiempo
Comunicaciones
y de forma apropiada, de la información del proyecto.

#11. Gestión del Es el proceso sistemático de identificar, analizar y responder a los

Riesgo riesgos del proyecto.

Incluye los procesos requeridos para adquirir los bienes y servicios que
#12. Gestión de las
el proyecto requiere para su funcionamiento desde fuera de su
Adquisiciones
desempeño y funcionamiento.

Tabla 3.1. Áreas de conocimiento de gestión de proyectos.

a. Gestión de la Integración

La gestión de integración del proyecto incluye los procesos requeridos,

para asegurar que los diferentes elementos del proyecto sean
coordinados adecuadamente. Se ocupa de encontrar el equilibrio entre
los objetivos posibles y sus alternativas, con el fin de satisfacer o colmar
las necesidades y expectativas de las entidades involucradas en el
proyecto. Mientras que todos los procesos de dirección de proyectos son
de alguna forma integradores, los de esta área lo son de manera
fundamental. La Gestión de la Integración del proyecto se utiliza cuando
se necesita estimar un coste para un plan de imprevistos, o cuando se
deben identificar los riesgos asociados con diferentes alternativas de
personal. Sin embargo, para que un proyecto sea completado con éxito,
también debe producirse la integración de otras muchas áreas. Por
ejemplo:

 El trabajo del proyecto debe ser integrado con las operaciones en

curso de la organización ejecutora, la metodología e-business, por
ejemplo.
 Deben integrarse el alcance del producto y del proyecto (área 5).
  Deben integrarse los resultados de las distintas especialidades
funcionales (como pueden ser las especificaciones de la
arquitectura e-business o los planos eléctricos, mecánicos y civiles
en un proyecto de ingeniería).

b. Gestión del Alcance

La Gestión del Alcance del proyecto comprende los procesos requeridos

para asegurar que el proyecto contiene todo el trabajo necesario y
solamente el trabajo necesario, para completar el proyecto con éxito.

Esta área está relacionada principalmente con la definición y control de lo

que está o no está incluido en el proyecto.

En el contexto del proyecto, la palabra 'alcance' puede referirse a lo

siguiente:

 Alcance del producto: Son las características y funciones que

deben incluirse en la iniciativa o solución e-business.
 Alcance del proyecto: Es el trabajo que debe llevarse a cabo para
entregar una aplicación e-business con las características y
funciones especificadas.

La integración debe considerar lo siguiente:

 Los procesos, herramientas y técnicas empleados para dirigir el

alcance del producto, son diferentes según sea el área de
aplicación y normalmente son definidos como parte del ciclo de
vida del proyecto, el cual puede ser la metodología e-business y/o
el modelo de desarrollo en un proyecto informático.
 Lo que debe tenerse cuidado, es que un proyecto consta de un
único producto, pero este producto puede tener elementos
auxiliares, cada uno de ellos con su propio alcance del producto,
separado pero interdependiente. Por ejemplo, un nuevo sistema
telefónico generalmente incluirá cuatro elementos
auxiliares: hardware, software, formación e instalación. En el caso
de una iniciativa e-business, cuya solución es una aplicación e-
business, ella constará de una serie de hardware, software y
procedimientos de trabajo vinculados a la manutención de la
arquitectura e-business y de un conjunto de aplicaciones de
software específicas y procedimientos de operación ligados que
permiten la operación de la aplicación e-business.
  La comprobación de que se ha completado el alcance del producto
se realiza según los requerimientos del mismo, mientras que el
alcance del proyecto se realiza según el plan del proyecto. Estos
dos tipos de gestión del alcance deben estar perfectamente
integrados para asegurar que los trabajos del proyecto darán como
resultado el producto especificado.

c. Gestión del Tiempo

La Gestión del Tiempo incluye los procesos necesarios para asegurar la

conclusión del proyecto en los tiempos establecidos. En algunos
proyectos, especialmente en los mas pequeños, la secuencia de
actividades, la estimación de la duración de las actividades y el desarrollo
del programa están tan íntimamente ligados que se consideran como un
único proceso (por ejemplo, pueden desarrollarse por una sola persona
en un período de tiempo relativamente corto). No obstante el PMBOK
presenta estos procesos separados y distintos porque las herramientas y
técnicas para cada uno son diferentes. Respecto de esta área, la única
consideración es que no existe consenso entre los profesionales de la
gestión de proyectos sobre la relación entre actividades y tareas, pues:

 En muchas áreas de aplicación, se considera a las actividades

compuestas por tareas. Esto es lo más normal y lo más utilizado.
 En otras áreas, se considera a las tareas compuestas por
actividades.

Sin embargo, la consideración más importante no es el termino que se

utilice, sino si el trabajo a realizar es descrito de forma precisa y si es
comprendido por las personas que deben realizarlo, distinguiendo
claramente cuando algo se compone de otra cosa. Esta consideración es
muy importante en un proyecto e-business, donde el trabajo
interdisciplinario de diversos profesionales, informáticos, economistas,
administradores de empresa, electrónicos, etc., pueden manejar distintas
acepciones de lo mismo. En este caso, lo prioritario es fijar el glosario de
términosoficiales del proyecto.

d. Gestión del Coste

La Gestión de Coste del proyecto incluye los procesos necesarios para

asegurar que el proyecto se finaliza dentro del presupuesto aprobado. La
Gestión de Costes del proyecto está relacionada con el coste de los
recursos necesarios para completar las actividades del proyecto. Sin
embargo, la gestión de costes del proyecto debería considerar también el
efecto que tiene la toma de decisiones del proyecto sobre los costes de
utilizar el producto del proyecto. Por ejemplo, la limitación del número de
revisiones del diseño puede reducir los costes del proyecto, a expensas
de un aumento en los costes operativos del cliente. Esta visión más
global de la gestión de costes del proyecto se suele llamar coste del ciclo
de vida. Este tema es especialmente relevante, por ejemplo, en un
proyectoe-business, pues, por una parte, la iniciativa e-business es un
cambio cultural respecto de cómo enfrentar la gestión de un negocio y en
cómo plantearse una organización de fronteras virtuales y, por otra parte,
la aplicación e-businessfinal es en sí misma la incorporación a una
organización de un tipo de tecnología en muchas ocasiones nueva,
además, de hardware y software cuya gestión requiere tratamiento
especial y de gran cuidado, con los costes que ello significa.

Estos costes involucran, por ejemplo, conseguir profesionales adecuados

para construir la aplicación e-business y profesionales que luego puedan
responder a las contingencias de la operación de la aplicación e-
business. Como parte de la Gestión del Coste:

 En muchas áreas de aplicación, la predicción y análisis del futuro

rendimiento financiero del producto del proyecto se realiza fuera
del proyecto. Cuando se incluyen estas predicciones y análisis, la
Gestión de Costes incluirá procesos adicionales y numerosas
técnicas de dirección general como la tasa interna de retorno (TIR),
el valor actual neto (VAN), período de recuperación del capital y
otros.
 Esta gestión debería de considerar las necesidades de información
de las entidades involucradas en el proyecto: diferentes entidades
pueden medir los costes del proyecto de diferentes maneras y en
distintos momentos. Por ejemplo, el coste de un artículo de un
proveedor puede ser medido cuando se ha autorizado su compra,
cuando se ha pedido, cuando se ha pagado o cuando se ha
contabilizado.
 Cuando los costes del proyecto se utilizan como un componente de
un sistema de recompensa y reconocimiento, deberían estimarse y
presupuestarse separadamente los costes controlables y los
incontrolables, para asegurar que las recompensas reflejan el
desarrollo real del proyecto.
 En algunos proyectos, especialmente en los mas pequeños, la
planificación de recursos, la estimación de costes y el presupuesto
de costes están tan íntimamente ligadas que se ven como un solo
 proceso (por ejemplo, puede desarrollarlas una sola persona en un
período de tiempo relativamente corto). No obstante el PMBOK
presenta estos procesos separados y distintos porque las
herramientas y técnicas para cada uno son diferentes.

e. Gestión de la Calidad

La Gestión de la Calidad del proyecto incluye los procesos necesarios

para asegurar que el proyecto satisfará las necesidades para las que se
ha llevado a cabo. Con esto se incluyen todas las actividades de la
dirección que determinan la política de la calidad, objetivos y
responsabilidades, así como su desarrollo por medios tales como
planificación de la calidad, control de la calidad, aseguramiento de la
calidad y mejora de la calidad, dentro del sistema de la calidad.

El método básico de gestión de calidad a seguir debe ser compatible con

el que la Organización Internacional de Normalización (ISO) ha detallado
en las series de normas ISO 9000 y 10000. Este método generalizado
también debería ser compatible con métodos de gestión de la calidad
vinculados a Deming, Juran, Crosby y otros, y otros como la gestión de la
Calidad Total (TQM) o la mejora continua.

La calidad es el conjunto de características de una entidad que

constituyen su capacidad para satisfacer necesidades implícitas o
evidentes.

La Gestión de la Calidad debe dirigirse tanto a la dirección del proyecto

como al producto del proyecto. Un fallo en el cumplimiento de las
exigencias de la calidad en alguna dimensión puede tener consecuencias
negativas serias para alguna o todas las entidades involucradas en el
proyecto. Por ejemplo:

 Cumplir los requerimientos del cliente mediante un trabajo excesivo

del equipo del proyecto puede producir consecuencias negativas
como un incremento en la rotación de personal.
 Cumplir los objetivos de programación del proyecto, acelerando las
revisiones de la calidad planificadas, puede producir
consecuencias negativas cuando existan errores que no sean
detectados.
Un aspecto crítico de la Gestión de la Calidad en el contexto del proyecto
es la necesidad de convertir las necesidades implícitas en necesidades
evidentes a través de la Gestión del Alcance del proyecto.

El equipo de dirección del proyecto debe tener cuidado de no confundir

calidad con grado. Grado es una categoría o rango dado a entidades
que, teniendo el mismo uso funcional, tienen diferentes requerimientos
de calidad. La baja calidad es siempre un problema; el bajo grado puede
no serlo. Por ejemplo, un producto de software puede ser de alta calidad
(sin errores, manual fácilmente legible) y bajo grado (pequeño número de
aplicaciones), o de baja calidad (muchos errores, documentación del
usuario mal organizada) y alto grado (numerosas aplicaciones).

Determinar y conseguir los niveles adecuados de calidad y grado son las

responsabilidades del gestor del proyecto y del equipo de dirección del
proyecto.

El equipo de dirección del proyecto debe saber también que la gestión de

la calidad moderna complementa a la dirección de proyectos moderna.
Por ejemplo, ambas disciplinas reconocen la importancia de:

La satisfacción del cliente: tratar de cumplir o exceder las expectativas

del cliente. Esto requiere tanto la conformidad con las especificaciones
(el proyecto debe producir lo que se dijo iba a producir), como la
adecuación para su uso (el producto o servicio producido debe satisfacer
las necesidades reales).

La prevención sobre la inspección: el coste de evitar los errores siempre

es mucho menor que el de corregirlos.

Responsabilidad de la gestión: el éxito requiere la participación de todos

los miembros del equipo, pero permanece la responsabilidad de la
dirección de suministrar los recursos necesarios para lograrlo.

Procesos dentro de fases del ciclo reiterativo planificar-ejecutar-

comprobar-actuar.

Además, las iniciativas de mejora de la calidad llevadas a cabo por la

organización ejecutora (por ejemplo, la gestión de la calidad total, TQM),
la mejora continua, y otros) pueden y deben mejorar la calidad de la
dirección del proyecto, así como la calidad del producto del proyecto.
Sin embargo, hay una diferencia importante sobre la que el equipo de
dirección del proyecto debe estar muy precavido: la naturaleza temporal
de los proyectos implica que las inversiones en mejora de la calidad del
producto, especialmente la prevención de defectos y las pruebas, deben
frecuentemente soportarse por parte de la organización ejecutora dado
que el proyecto puede no durar lo suficiente para recoger la recompensa.

f. Gestión de Recursos Humanos

La Gestión de Recursos Humanos del proyecto incluye los procesos

necesarios para aprovechar más efectivamente al personal relacionado
con el proyecto, incluyendo a todas las entidades involucradas en el
proyecto (patrocinadores, clientes, contribuyentes individuales y otros).
Hay gran cantidad de literatura sobre las relaciones interpersonales en
un contexto operativo continuo. Algunas de las muchas ideas extendidas
son:

 Liderazgo, comunicación, negociación y otras más aptitudes clave

en la dirección general.
 Delegación, motivación, enseñanza, apadrinamiento y otros temas
relacionados con el trato personal.
 Creación de equipos, resolución de conflictos y otros temas
relacionados con el trato en grupo.
 Análisis del grado de preparación., reclutamiento, retención,
relaciones laborales, seguridad e higiene en el trabajo y otras
elementos relacionados con la función de administración de
recursos humanos.

La mayor parte de este material es aplicable al liderazgo y a la dirección

de personas en proyectos y el gestor del proyecto y el equipo de
dirección del proyecto deben estar familiarizados con estos conceptos.

Sin embargo, deben ser también sensibles a la aplicación de estos

conceptos en el proyecto. Por ejemplo:

Sin embargo, deben ser también sensibles a la aplicación de estos

conceptos en el proyecto. Por ejemplo:

 La naturaleza temporal de los proyectos supone que las relaciones

personales y de la organización serán, generalmente, temporales y
nuevas. El equipo de dirección del proyecto debe tener cuidado a
 la hora de seleccionar técnicas que sean apropiadas para estas
relaciones temporales.
 La naturaleza y el número de entidades involucradas en el proyecto
cambiarán a menudo según el proyecto va pasando por las
distintas fases de su cielo de vida. Como consecuencia de esto,
técnicas que son aptas en una fase determinada, pueden no ser
efectivas en otra fase. El equipo de dirección del proyecto debe
prestar especial atención en utilizar las técnicas apropiadas a las
necesidades actuales del proyecto.
 Las actividades administrativas de los recursos humanos son rara
vez una responsabilidad directa del equipo de dirección del
proyecto. Sin embargo, el equipo debe conocer suficientemente los
requerimientos administrativos para asegurar su cumplimiento.

g. Gestión de las Comunicaciones

La Gestión de Comunicaciones del proyecto comprende los procesos

necesarios para, en el momento y manera adecuados, asegurar la
elaboración, recopilación, distribución, archivo y disposición definitiva de
la información del proyecto. Proporciona las conexiones clave entre
personas, ideas e información, que son necesarias para el éxito del
proyecto. Esto se hace para que cualquier persona implicada en el
proyecto debe estar preparada para enviar y recibir comunicaciones en el
lenguaje del proyecto, y debe comprender que las comunicaciones que
se realizan entre personas afectan al proyecto en su conjunto.

La aptitud de la dirección general para la comunicación está relacionada,

pero no es lo mismo, que la Gestión de Comunicaciones del proyecto.
Comunicación es un término general y comprende una gran cantidad de
aspectos que no se circunscriben solamente al contexto del proyecto. Por
ejemplo:

 Modelos emisor-receptor (lazos de realimentación, obstáculos a las

comunicaciones, etc.).
 Elección del medio (cuándo comunicar por escrito y cuándo hacerlo
verbalmente, cuándo escribir un memorando informal y cuando
hacer un informe formal, etc.).
 Estilo de escritura (voz activa frente a voz pasiva, estructura de las
oraciones, elección de vocabulario, etc.).
 Técnicas de presentación (lenguaje del cuerpo, diseño de ayudas
visuales, etc.).
  Técnicas de dirección de reuniones (preparación de una agenda,
tratamiento de conflictos, etc.).

Esta área es de importancia ya que muchos proyectos fallan por

problemas de comunicación. Por esta razón, es responsabilidad del
gestor de proyectos crear un ambiente dentro del proyecto propicio para
una efectiva comunicación intra e intergrupal que permita que todas las
partes estén informadas de manera fluida. Lo importante es no dar
sorpresas, menos al cliente. Por esto, las comunicaciones no deben
depender de informes aislados, sino que es bueno aprovechar las
reuniones para comunicar. No hay que olvidar que una buena frase
puede ser mejor que un cuidado informe de estado.

h. Gestión del Riesgo

La gestión de riesgos del proyecto incluye los procesos relacionados con

la identificación, análisis y respuesta a los riesgos de un proyecto. Incluye
maximizar los efectos positivos de los distintos eventos y minimizar las
consecuencias de sus efectos negativos. Las diferentes áreas de
aplicación utilizan, con frecuencia, diferentes nombres para los procesos
aquí descritos. Por ejemplo:

 La identificación y cuantificación de riesgos se tratan, en algunas

ocasiones, como un solo proceso y el proceso combinado puede
llamarse análisis o evaluación de riesgos.
 Al desarrollo de respuestas a riesgos se le denomina algunas
veces Planificación de respuestas o mitigación de riesgos.
 El desarrollo y el control de las respuestas ante el riesgo se tratan
algunas veces como un solo proceso, pudiendo ser denominarse
dicho proceso combinado gestión de riesgos.

Esta área, en muchos casos definida como función, es una de las más
importantes hoy en día debido al entorno cambiante en que se
desenvuelven los proyectos e-business en particular, y cualquier
proyecto en general. Durante la fase de planificación, el gestor de
proyecto necesita realizar una valoración realista de riesgos y desarrollar
un plan para controlarles. Para ello debe considerar como factores de
riesgo:

- El tamaño del proyecto;

- La estructura del proyecto; y,

- La experiencia con las técnicas utilizadas.

Debe tenerse presente que los riesgos de un proyecto aumentan

conforme crece, es poco estructurado (es decir, los requerimientos no se
definen bien y probablemente cambien durante el proyecto) y hay menos
experiencia del equipo en la tecnología a usar. En estos casos adoptar
un enfoque de contingencia es una estrategia adecuada de gestión de
los diversos tipos de riesgo, para las cuales existen diversos tipos de
herramientas de integración externa, interna y de control y planificación
(figura 3.

Figura 3.2: Enfoque de contingencia de Gestión de Riesgo.

 Proyectos con una estructura pequeña se pueden beneficiar de

herramientas de integración externa para crear relaciones efectivas
entre el equipo del proyecto y los clientes de la organización. Por
ejemplo:

- Seleccionar al gestor del proyecto y a los miembros del

equipo del proyecto desde la misma organización que
recibirá el producto;

- Mantener una representación de clientes en todas, o casi

todas, las reuniones de revisión del proyecto; y/o,
 - Mantener una amplia difusión y distribución de los informes
de estado del proyecto dentro de la organización.

 Proyectos que involucran el uso de nueva tecnología deberían

confiar más en herramientas de integración interna, las cuales han
sido diseñadas para mejorar la competencia y operación técnica
del equipo como una unidad integrada. Por ejemplo:

- Seleccionar o disponer de miembros experimentados;

- Contar con un gestor del proyecto con gran dominio técnico

y experiencia probada en gestión de proyectos;

- Mantener frecuentes reuniones de estado del proyecto con

los miembros.

 Grandes proyectos, con una gran estructura deberían ser

gestionados con profusión de herramientas de gestión y de control.
Estas herramientas, representan un esfuerzo sistemático y
disciplinado de planificación y control. Por ejemplo, WBS,
presupuestos, planes y procedimientos de seguimiento. Mientras la
elección de un enfoque adecuado para gestionar el proyecto es de
gran importancia, es importante una valoración de los riesgos, lo
cual incluye:

- El propósito de la identificación de riesgos es desarrollar

una lista de los riesgos que pueden afectar el proyecto y su
producto.

- El análisis de riesgos consiste de valorizar la exposición al

riesgo, la probabilidad e impacto de cada uno de ellos.

- La priorización de los riesgos produce una lista de

riesgos priorizados según el impacto que un riesgo tiene en
el proyecto y el producto.

Con esto se puede planificar según los riesgos de mayor impacto e

incidencia, planteando planes de contingencia para hacerles frente y
monitorearles. Es importante que los riesgos sean valorizados
continuamente cuando se monitorean para mantener actualizada una
lista de, por ejemplo, los 10 riesgos de mayor prioridad e incidencia.
i. Gestión de las Adquisiciones

La Gestión de las adquisiciones del proyecto incluye los procesos

requeridos para la adquisición de bienes y servicios, producto en general,
en el exterior de la organización ejecutora. Esta gestión requiere una
perspectiva de comprador como parte de una relación comprador-
proveedor. Esta relación se puede dar a muchos niveles en un mismo
proyecto. Dependiendo del área de aplicación, al proveedor se le puede
llamar contratista, vendedor o suministrador. El proveedor dirigirá
normalmente su trabajo como un proyecto. En tales casos:

 El comprador se convierte en cliente y es así, una entidad

involucrada en el proyecto clave para el proveedor.
 El equipo de dirección de proyectos del proveedor debe estar
interesado en todos los procesos de dirección de proyectos, no
sólo en aquellos de este área de conocimiento.
 Los términos y condiciones del contrato se convierten en un dato
clave para muchos de los procesos del proveedor. El contrato
puede contener realmente los datos (por ejemplo, entregas
principales, hitos clave, objetivos de coste) o puede limitar las
opciones del equipo del proyecto (por ejemplo, en los proyectos de
diseño se requiere frecuentemente la aprobación del comprador de
las decisiones de asignación de personal).

3.2.2.2. Grupos de procesos de gestión

Los grupos de procesos de gestión (Management Processes Groups),

son agrupaciones de procesos de gestión de proyectos, relacionados con
las cinco fases de un proyecto: Iniciación (IP), Planificación (Pl),
Ejecución (EP), Seguimiento y Control (CoP), y Cierre (ClP).

La figura 3.3 muestra la relación entre estos grupos y la tabla

3.2 presenta su descripción.
El nivel de actividad de estos grupos de procesos durante el proyecto
varía en el tiempo tal como ilustra la figura 3.4.

Figura 3.4: La relevancia de los grupos de procesos de gestión a lo largo del proyecto.
 GRUPO DE
CÓDIGO DESCRIPCIÓN
PROCESOS

Procesos de
IP Autorizar el proyecto o fase.
Iniciación

Definir y refinar objetivos y seleccionar el mejor curso alternativo de

Procesos de
PP acción para conseguir los objetivos que el proyecto persigue
Planificación
alcanzar.

Procesos de
EP Coordinar personas y otros recursos para llevar adelante el plan.
Ejecución

Asegurar que los objetivos del proyecto son conseguidos midiendo y

Procesos de monitoreando el progreso regularmente a través de identificar
CoP
Control variaciones respecto del plan, para así tomar acciones correctivas
cuando sea necesario.

Procesos de Formalizar la aceptación del proyecto fase y colocar todo en un orden

ClP
Cierre coherente.
Tabla 3.2. Grupos de procesos de gestión.

3.2.2.3. Procesos de gestión de proyectos

Los Procesos de Gestión de Proyectos son el eje de toda la propuesta

del PMBOK (tabla 3.3), constituyendo el centro de las mejores prácticas
de gestión de proyectos. En la codificación X.Y de cada proceso, la X
indica el número de área de conocimiento a la cual pertenece, mientras
la Y es un correlativo. A cada proceso se le asocian entradas, salidas,
herramientas y técnicas de gestión. Esta representación de la gestión de
proyectos, ha sido una de las principales aportaciones del PMBOK al
mundo de la investigación y de la profesión de proyectos, al mostrar de
manera clara que existen, por una parte, procesos de gestión y, por otra
parte, herramientas y técnicas donde, los primeros usan las segundas a
conveniencia según necesidades y habilidades del gestor y de los
participantes.

PROCESOS DE
NUM. GESTIÓN DE DESCRIPCIÓN
PROYECTOS

4. GESTIÓN DE LA INTEGRACIÓN DEL PROYECTO

4.1 Desarrollar el Acta de

Desarrolla el acta de constitución del proyecto que autoriza
Constitución del
 Proyecto formalmente un proyecto.

Desarrollar el
Enunciado del Alcance Desarrolla el enunciado del alcance del proyecto preliminar que
4.2
del Proyecto ofrece una descripción del alcance a alto nivel.
Preliminar

Documenta las acciones necesarias para definir, preparar, integrar

Desarrollar el Plan de
4.3 y coordinar todos los planes subsidiarios en un plan de gestión del
Gestión del Proyecto
proyecto.

Ejecuta el trabajo definido en el plan de gestión del proyecto para

Dirigir y Gestionar la
4.4 lograr los requisitos del proyecto definidos en el enunciado del
Ejecución del Proyecto
alcance del proyecto.

Supervisa y controla los procesos requeridos para iniciar,

Supervisar y Controlar
planificar, ejecutar y cerrar un proyecto, a fin de cumplir con los
4.5 el Trabajo del
objetivos de rendimiento definidos en el plan de gestión del
Proyecto
proyecto.

Revisa todas las solicitudes de cambio, aprueba los cambios y

Control Integrado de
4.6 controla los cambios en los productos entregables y en los activos
Cambios
de los procesos de la organización.

Finaliza todas las actividades en todos los Grupos de Procesos

4.7 Cerrar Proyecto
del Proyecto para cerrar formalmente el proyecto.

5. GESTIÓN DEL ALCANCE DEL PROYECTO

Crea un plan de gestión del alcance del proyecto que documenta

Planificación del cómo se definirá, verificará y controlará el alcance del proyecto, y
5.1
Alcance cómo se creará y definirá la estructura de desglose del trabajo
(EDT).

Desarrolla un enunciado detallado del alcance del proyecto como

5.2 Definición del Alcance
base para futuras decisiones del proyecto.

Subdivide los principales productos entregables del proyecto y el

5.3 Crear EDT trabajo del proyecto en componentes más pequeños y más fáciles
de gestionar.

5.4
Verificación del Formaliza la aceptación de los productos entregables
 Alcance completados del proyecto.

5.5 Control del Alcance Controla los cambios en el alcance del proyecto.

6. GESTIÓN DEL TIEMPO DEL PROYECTO

Identifica las actividades específicas del cronograma que deben

Definición de las
6.1 ser realizadas para producir los diferentes productos entregables
Actividades
del proyecto.

Establecimiento de la
Identifica y documenta las dependencias entre las actividades del
6.2 Secuencia de las
cronograma.
Actividades

Estimación de
Estima el tipo y las cantidades de recursos necesarios para
6.3 Recursos de las
realizar cada actividad del cronograma.
Actividades

Estimación de la
Estima el número de períodos laborables que se necesitarán para
6.4 Duración de las
completar actividades individuales del cronograma.
Actividades

Analiza las secuencias de las actividades, su duración, los

Desarrollo del
6.5 requisitos de recursos y las restricciones del cronograma para
Cronograma
crear el cronograma del proyecto.

Control del
6.6 Controla los cambios en el cronograma del proyecto.
Cronograma

7. GESTIÓN DE LOS COSTES DEL PROYECTO

Desarrolla una aproximación de los costes de los recursos

7.1 Estimación de Costes
necesarios para completar las actividades del proyecto.

Preparación del
Suma los costes estimados de actividades individuales o paquetes
7.2 Presupuesto de
de trabajo a fin de establecer una línea base de coste.
Costes

Ejerce influencia sobre los factores que crean variaciones del

7.3 Control de Costes
coste y controla los cambios en el presupuesto del proyecto.
 8. GESTIÓN DE LA CALIDAD DEL PROYECTO

Planificación de Identifica qué normas de calidad son relevantes para el proyecto y

8.1
Calidad determina cómo satisfacerlas.

Realizar Aplica las actividades planificadas y sistemáticas relativas a la

8.2 Aseguramiento de calidad, para asegurar que el proyecto emplee todos los procesos
Calidad necesarios para cumplir con los requisitos.

Supervisa los resultados específicos del proyecto, para determinar

Realizar Control de
8.3 si cumplen con las normas de calidad pertinentes e identifica
Calidad
modos de eliminar las causas de un rendimiento insatisfactorio.

9. GESTIÓN DE LOS RECURSOS HUMANOS DEL PROYECTO

Identifica y documenta los roles del proyecto, las

Planificación de los
9.1 responsabilidades y las relaciones de informe, y también crea el
Recursos Humanos
plan de gestión de personal.

Adquirir el Equipo del Obtiene los recursos humanos necesarios para completar el
9.2
Proyecto proyecto.

Desarrollar el Equipo Mejora las competencias y la interacción de los miembros del

9.3
del Proyecto equipo para lograr un mejor rendimiento del proyecto.

Hace un seguimiento del rendimiento de los miembros del equipo,

Gestionar el Equipo
9.4 proporciona retroalimentación, resuelve polémicas y coordina
del Proyecto
cambios a fin de mejorar el rendimiento del proyecto.

10. GESTIÓN DE LAS COMUNICACIONES DEL PROYECTO

10.1 Planificación de Determina las necesidades de información y comunicación de los

10.1
las Comunicaciones interesados en el proyecto.

10.2 Distribución de la Hace que la información necesaria esté disponible para las
10.2
Información personas interesadas en el proyecto en el momento oportuno.

Recopila y distribuye información sobre el rendimiento, incluido el

10.3 Informar el
10.3 informe de estado de la situación, la medición del avance y las
Rendimiento
proyecciones.
 10.4 Gestionar a los Gestiona las comunicaciones a fin de satisfacer los requisitos de
10.4
Interesados los interesados en el proyecto y resolver polémicas con ellos.

11. GESTIÓN DE LOS RIESGOS DEL PROYECTO

Planificación de la Decide cómo enfocar, planificar y ejecutar las actividades de

11.1
Gestión de Riesgos gestión de riesgos para un proyecto.

Identificación de Determina qué riesgos pueden afectar al proyecto y documenta

11.2
Riesgos sus características.

Prioriza los riesgos para otros análisis o acciones posteriores,

Análisis Cualitativo de
11.3 evaluando y combinando su probabilidad de ocurrencia y su
Riesgos
impacto.

Análisis Cuantitativo Analiza numéricamente el efecto de los riesgos identificados en

11.4
de Riesgos los objetivos generales del proyecto.

Planificación de la
Desarrolla opciones y acciones para mejorar las oportunidades y
11.5 Respuesta a los
reducir las amenazas a los objetivos del proyecto.
Riesgos

Realiza el seguimiento de los riesgos identificados, supervisa los

Seguimiento y Control riesgos residuales, identifica nuevos riesgos, ejecuta planes de
11.6
de Riesgos respuesta a los riesgos y evalúa su efectividad durante todo el
ciclo de vida del proyecto.

12. GESTIÓN DE LAS ADQUISICIONES DEL PROYECTO

Planificar las Compras

12.1 Determina qué comprar o adquirir, y cuándo y cómo hacerlo.
y Adquisiciones

Planificar la Documenta los requisitos de los productos, servicios y resultados,

12.2
Contratación e identifica los posibles vendedores.

Solicitar Respuestas Obtiene información, presupuestos, licitaciones, ofertas o

12.3
de Vendedores propuestas, según corresponda.

Selección de Revisa ofertas, selecciona entre posibles vendedores y negocia

12.4
Vendedores un contrato por escrito con un vendedor.
 Gestiona el contrato y la relación entre el comprador y el
vendedor, revisa y documenta cuál es o ha sido el rendimiento de
un vendedor a fin de establecer las acciones correctivas
Administración del
12.5 necesarias y proporcionar una base para relaciones futuras con el
Contrato
vendedor, gestiona cambios relacionados con el contrato y,
cuando corresponda, gestiona la relación contractual con el
comprador externo del proyecto.

Completa y aprueba cada contrato, incluida la resolución de

12.6 Cierre del Contrato
cualquier tema abierto, y cierra cada contrato.

Tabla 3.3. Procesos de gestión de proyectos (PMI, 2004).

3.2.2.4. Relación entre grupos, áreas y procesos

La relación entre grupos, áreas y procesos se presenta en la tabla 3.4.

En esta tabla, cada "x" indica la pertenencia de procesos de área de
conocimiento en un grupo de procesos. Aunque los procesos en cada
área pueden aparecer como elementos aislados con conexiones bien
definidas, en la práctica pueden solaparse e interaccionar de una manera
no detallada aquí. Estos procesos se interaccionan entre ellos, así como
con los procesos en las otras áreas de desarrollo. Cada proceso puede
requerir esfuerzos de una o más personas o grupos de personas, según
sean las necesidades del proyecto. Generalmente, cada proceso ocurre
al menos una vez en cada fase del proyecto.

IP PP EP CoP ClP

Gestión de la Integración x x x x x

Gestión del Alcance x x

Gestión del Tiempo x x

Gestión del Coste x x

Gestión de la Calidad x x x
 Gestión de Recursos Humanos x x x

Gestión de las Comunicaciones x x x

Gestión del Riesgo x x

Gestión del Abastecimiento x x x

Tabla 3.4. Relaciones entre grupos, áreas y procesos.

Cada uno de los procesos de dirección de proyectos requeridos se

muestra en el Grupo de Procesos en el cual se lleva a cabo la mayor
parte de la actividad, estas relaciones se muestran en la tabla 3.5. A
modo de ejemplo, la figura 3.5 ilustra el Grupo de Procesos de
Seguimiento y Control (CoP).

Figura 3.5: Grupo de Procesos de Seguimiento y Control (PMI, 2004).

Correspondencia de los procesos de Dirección de Proyectos

La tabla 3.5 muestra la correspondencia de los 44 procesos de dirección
de proyectos en los cinco Grupos de Procesos de Dirección de Proyectos
y las nueve Áreas de Conocimiento de la Dirección de Proyectos. En esta
tabla se observa la actividad que se realiza en cada proceso de dirección
de proyectos.

GRUPO DE PROCESOS DE DIRECCIÓN DE PROYECTOS

PROCESOS DE GRUPO DE GRUPO DE GRUPO DE
UN ÁREA DE GRUPO DE
PROCESO PROCESOS PROCESOS GRUPO DE
CONOCIMIENT PROCESOS
S DE DE SEGUIMIENT PROCESOS
O DE
INICIACIÓ PLANIFICACIÓ OY DE CIERRE
EJECUCIÓN
N N CONTROL

Desarrollar
el Acta de
Constitució Supervisar y
n del Controlar el
Proyecto Trabajo del
Dirigir y Proyecto
Desarrollar el
3.2.1.1 (4.1) Gestionar la Cerrar
4. Gestión de la Plan de Gestión
Ejecución del 3.2.4.1 (4.5) Proyecto
Integración del del Proyecto
Desarrollar Proyecto
Proyecto
el Control 3.2.5.1 (4.7)
3.2.1.1 (4.3)
Enunciado 3.2.3.1 (4.4) Integrado de
del Cambios
Proyecto
Preliminar 3.2.4.2 (4.6)

3.2.1.2 (4.2)

Planificación del
Alcance
Verificación
3.2.2.2 (5.1) del Alcance

5. Gestión del Definición del 3.2.4.3 (5.4)

Alcance del Alcance
Proyecto Control del
3.2.2.3 (5.2) Alcance

Crear EDT 3.2.4.4 (5.5)

3.2.2.4 (5.3)

Definición de las
Actividades
Control del
6. Gestión del Cronograma
Tiempo del 3.2.2.5 (6.1)
Proyecto
3.2.4.5 (6.6)
Establecimiento
de la Secuencia
 de las
Actividades

3.2.2.6 (6.2)

Estimación de
Recursos de las
Actividades

3.2.2.7 (6.3)

Estimación de la
duración de las
Actividades

3.2.2.8 (6.4)

Desarrollo del
Cronograma

3.2.29 (6.5)

Estimación de
Costes

3.2.2.10 (7.1)
7. Gestión de Control de
los Costes del Costes 3.2.4.6
Proyecto Preparación del (7.3)
Presupuesto de
Costes

3.2.2.11 (7.2)

Realizar
Aseguramient Realizar
8. Gestión de la Planificación de o de la Control de
Calidad del la Calidad Calidad Calidad
Proyecto 3.2.2.12 (8.1)
3.2.4.7 (8.3)
3.2.3.2 (8.2)

Adquirir el
Equipo del
Proyecto
9. Gestión de Planificación de 3.2.3.3 (9.2) Gestionar el
los Recursos los Recursos equipo del
Humanos del Humanos Proyecto
Proyecto 3.2.2.13 (9.1) Desarrollar el 3.2.4.8 (9.4)
Equipo del
Proyecto
3.2.3.4 (9.3)

10. Gestión de Planificación de Distribución 7.4.

Informar el
las las de la Administrativ
Rendimiento
Comunicacione Comunicaciones Información e Closure (p)
s del Proyecto 3.2.2.14 (10.1)
3.2.3.5 (10.2) 3.2.4.9 (10.3)

Gestionar a
los
Interesados
3.2.4.10 (10.4)

Planificación de
la Gestión de
Riesgos
3.2.2.15 (11.1)

Identificación de
Riesgos

3.2.2.16 (11.2)

Análisis Seguimiento y
11. Gestión de
Cualitativo de Control de
los Riesgos del
Riesgos riesgos
Proyecto
3.2.2.17 (11.3) 3.2.4.11 (11.6)

Análisis
Cuantitativo de
Riesgos
3.2.2.18 (11.4)

Planificación de
la Respuesta a
los Riesgos
3.2.2.19 (11.5)

Solicitar
Planificar las
Respuestas Cierre del
Compras y
de Contrato
12. Gestión de Adquisiciones
Vendedores Administración
las 3.2.2.20 (21.1)
3.2.3.6 (12.3) del Contrato
Adquisiciones 3.2.5.2
3.2.4.12 (12.5)
del Proyecto Planificar la
Selección de
Contratación (12.6)
Vendedores
3.2.2.21 (12.2)
3.2.3.7 (12.4)
Tabla Relación entre grupos de procesos, áreas de conocimiento y procesos de gestión de
3.5. proyectos. p: principal; f: facilitador.

Problemas de Gestión

En la siguiente tabla se describen algunos problemas que diferentes

autores han encontrado durante el proceso de dirección de un proyecto.
 TIPO DE PROBLEMA DE
McCONNELL GLASS PURBA REDMILL
GESTIÓN

Exceso de
requerimientos
(producto)

Incapacidad
de los
Poca claridad
usuarios en
Planificació Usuarios se en los
comunicar
n resisten requerimiento
requerimiento
s
s (elemento
humano)

Abandono de Promotor
tiempo en el está
inicio (proceso) perdido

Pérdida de
tiempo en el
inicio (proceso)

Política
Política antes
organizacional
Ejecución que desarrollo
(aspectos
(personas)
políticos)

Cambiar de
Falla en el uso
GESTIÓN DE herramientas a Cambios
de
INTEGRACIÓN mitad del tecnológico
metodologías
proyecto s elegidos
del desarrollo
(tecnología)

Diseño
inadecuado
(proceso)

Convergencia
prematura o
excesivamente
frecuente
(proceso)

Equip.
políticos
Falta de (aspec.
participación políticos)
del usuario
(personas) Política indiv.
(aspec.
políticos)

Añadir más
personal a un
Ejecución
proyecto
retrasado
 (personas)

Mejores Mala gestión

Tiras y aflojas
prácticas y de las fases Más
en la
lecciones de desarrollo especificació
negociación
son (elemento n
(producto)
olvidadas humano)

Pruebas
insuficientes
(error
humano)

Falta de control
automático del
código fuente
(tecnología)

Cambios
son Cambios en
Falta de
pobrement las
control de
e prestaciones
cambios
Control gestionado (producto)
s

Incapacidad
Cambios de acomodar
en las cambios a
necesidade requerimiento
s de s de negocios
negocio (elemento
humano)

Desarrollo
orientado a la
investigación
(producto)
Iniciación Falta de un
proyecto
efectivo del
proyecto
(personas)

GESTIÓN DEL Incapacidad

ALCANCE de los usarios
Gestores en
no comprender
comprende las
n las implicaciones
Planificació
necesidade de los
n
s de los requerimiento
usuarios s de negocios
(elemento
humano)

Planificación Alcance Mala

 insuficiente mal planificación
(proceso) definido (elemento
humano)

Expectativas
Expectativas
porco realistas
poco realistas
(elemento
(personas)
humano)

Síndrome de la
panacea
tecnológica

Estrategia de
implementació
n débil
(elemento
humano)

Mejoras
prácticas y
lecciones
son
olvidadas

Sobreestimació
n de las
ventajas del
empleo o de
nuevas
herramientas o
métodos
(tecnología)

Limitaciones
técnicas

Políticas de la
unidad
Ejecución informática de
la
organización
(aspectos
políticos)

Mejoras
prácticas y
Control lecciones
son
olvidadas

Control
insuficiente de
la directiva
(proceso)

GESTIÓN DE Planificació Omitir tareas Tiempo y

 COSTES n necesarias en presupuesto
la estimación inadecuado
(proceso)

Estimaciones Estimaciones
erradas erradas

No se hace
estimación

Recursos
insuficientes
Control
(elemento
humano)

Tiempo y
Omitir tareas
presupuesto
necesarias en Plazos
inadecuado.
Planificació la estimación irreales
Estimaciones
n (proceso)
erradas

No se hace
estimación
GESTIÓN DEL
TIEMPO Planificar
poniéndose al
día más
adelante
Control (proceso)

Programa a
destajo
(proceso)

Se carece
del
Planificació personal
n con las
habilidades
adecuadas

GESTIÓN DE LA Oficinas
CALIDAD repletas y
Ejecución
ruidosas
(personas)

Escatimar en el
control de la
Control
calidad
(proceso)

Ilusiones
(personas)
GESTIÓN DE
Planificació Se carece Insuficientes
RECURSOS Motivación
n de personal habilidades
HUMANOS débil
con técnicas
(personas)
habilidades (elemento
 adecuadas humano)
Personal
mediocre
(personas)

Empleados Pobres
problemáticos desarrolladore
incontrolados s (elemento
(personas) humano)

Política
Desarrolladore
individual
s meticulosos
(aspectos
(producto)
políticos)

Hazañas
Ejecución (personas)

Fricciones
entre los
dientes y los
desarrolladores
(personas)

Falta de
participación de
los implicados
(personas)

Insuficientes
habilidades
técnicas
(elemento
humano
Planificació
n
Estrategia de
implementació
n débil
(elemento
humano)

GESTIÓN DE Mejores
COMUNICACIONE prácticas y
S Ejecución lecciones
son
olvidadas

Se carece
del
personal
Control
con las
habilidades
adecuadas

Tiras y aflojas
Cierre en la
negociación
 (personas)

Falta de
participación de
los usuarios
(personas)

Gestión de
Planificació riesgo
n insuficiente
GESTIÓN DEL (proceso)
RIESGO Tiras y aflojas
en la
Control
negociación
(personas)

Incapacidad
para tratar con
Fallos en los
Planificació contratistas y
contratados
n vendedores
(proceso)
(elemento
humano)

Incapacidad
para tratar con
contratistas y
Ejecución
vendedores
GESTIÓN DE LAS (elemento
ADQUISICIONES humano)

Recursos
insuficientes
Control
(elemento
humano)

Se carece
del
personal
Cierre
con las
habilidades
adecuadas
Tabla 3.6. Diversos tipos de problemas de gestión clasificados según el PMBOK.

3.2.3. Estados de una mala gestión de proyectos

Los errores cometidos durante la gestión, mostrados en la tabla 3.6 y

muchos otros más, ocurren y han sido reportados profusamente en la
literatura. No obstante, se han podido determinar algunos estados que
indican una gestión de proyectos inefectiva o de que es prudente
plantearse usarla. Estos estados de un proyecto son:
  Modo ajustado (crunch mode);
 Marcha mortal (death march); y,
 Fuera de control (runaway).

3.2.3.1. Modo ajustado

Para Glass, el modo ajustado describe un proyecto que se encuentra

extremadamente ajustado a la programación. Se habla que existen
fuertes presiones que sienten los participantes del proyecto. Es el estado
cuando el proyecto anda por los límites del programa de trabajo, más
bien superándolo. En este estado, dentro del proyecto informático
comienza a notarse que:

- Las semanas tienen siete días y los días 24 horas";

- Los días son cortos y las noches largas";

- Empiezan las primeras fugas;

- Hay una 'ralentización' de la motivación;

- Se suceden las re-planificaciones de forma frecuente;

- Etc.

3.2.3.2. Marcha mortal

Según Glass, la marcha mortal describe un estado en que el proyecto

tiene una programación difícil de conseguir. Se habla que "hay olor a
fracaso" ("esto huele mal") entre los participantes. Para Yourdon, un
proyecto en marcha mortal posee una valoración de riesgo de falla sobre
el 50 por ciento (incluyendo riesgos técnicos, del personal, legales,
políticos, etc.). Según Ribera este estado es un Modo Imposible de
trabajo debido a que:

 El plazo es inferior a la mitad de lo que racionalmente se precisa";

 El personal asignado es inferior a la mitad que habitualmente se
asignaría a un proyecto de estas características";
 El presupuesto se ha recortado a la mitad", y,
  La funcionalidad, requisitos, y otros aspectos técnicos son
superiores al doble de lo normal".

El mismo Ribera acota, que en estas situaciones surgen preguntas como:

"¿Qué hace un chico como yo en un proyecto como éste" o "¿Cómo
puedo sobrevivir a este proyecto sin perder mi salud física y mental y mi
dignidad?".

3.2.3.3. Fuera de control y escalada

Un proyecto fuera de control, o "Runaway", describe un estado o un

estado de cosas manifestadas cuando un proyecto está cerca o después
de su término. Sencillamente, el proyecto está fuera de sus límites o ya
no tiene límites, según Glass, el proyecto falló o está pronto a fracasar.

Cuando se está fuera de control, se puede decir que estamos ante una
bola de nieve, la cual resulta de una escalada de errores por motivos,
que según Keil y Mixon, se deben a factores psicológicos, sociales y
organizacionales. Estos errores son consecuencia de una gestión
inadecuada, fallida o nula, que pone al personal y especialmente a
gestores, ante una variedad de problemas que supera sus capacidades
de gestión y de resolución de problemas. Esta situación hace que un
error lleve a otro, produciéndose una cadena creciente, una escalada de
problemas de gestión, debido al cansancio, fatiga y desorientación que
supone la tensión de la situación.

Lo anterior es lo que se llama escalada y romperla requiere una alta

capacidad de superar el estrés físico y mental que supone un rescate,
hundimiento o salvamento parcial del proyecto.

3.2.4. Razón de la gestión de proyectos

Se ha dicho que la gestión de proyectos es una manera de hacer frente a

problemas y retos. También hemos añadido los estados de un proyecto
que presenta problemas de gestión. Ahora se presentan razones más
concretas que justifican la gestión de proyectos en un proyecto en
general y en un proyecto de base tecnológica. Ellas son:
- Actuación predictiva y,

- Recuperación.

3.2.4.1. Actuación predictiva

Para varios autores, una forma de actuar predictivamente en los

problemas de gestión, es anticiparse a ellos con una completa y
adecuada gestión de proyectos, la cual puede medirse si con la gestión
se garantizan alcanzar los siguientes Factores Críticos de Éxito
(planteados por Jurison):

 Objetivos claramente definidos.

 Apoyo claro y total de la dirección.
 Presupuesto adecuado y realista.
 Programa coherente, racional y realista.
 Participación y confianza real del cliente y usuarios.
 Buen liderazgo del proyecto.
 Revisiones continuas, constructivas y positivas del proyecto.
 Gestión y control eficiente y eficaz del cambio.
 Buenas comunicaciones entre integrantes del proyecto.
 Anticiparse y solucionar los problemas que surjan con una gestión
de contingencias.

3.2.4.2. Recuperación

Otros autores señalan que la gestión de proyectos permite determinar el

momento y las acciones de recuperación de un proyecto, igualmente de
que estas acciones se lleven delante de manera adecuada. En este caso
se habla de una de-escalación y/o la convocación de un caballero blanco.

a. De-escalar

En una de-escalación se toman acciones que permitan superar los

diversos problemas de gestión ante una escalada. Para Ribera
recuperarse de una escalada puede ser:

- Recortar la envergadura del proyecto;

- Aumentar la productividad mediante mejoras a corto plazo; y/o,

- Asumir que el proyecto no terminará a tiempo, atrasar el plan y adoptar

medidas de control de daños.

Lo que para Glass se traduce en tomar acciones en el siguiente orden de

preferencia:

- Extender las fechas;

- Usar mejores procedimientos de gestión;

- Más personal;

- Más fondos;

- Reducción en alcance del proyecto; -Mejores metodologías de

desarrollo;

- Cambiar tecnología; y,

- Abandonar el proyecto.

Acciones que, para Montealegre y Keil, no tendrían ningún efecto si no

se apela a la colaboración y cooperación de los participantes
involucrados en el proyecto o, sencillamente, des-institucionalizar el
proyecto, dejando la de-escalación como un problema interno de gestión
a superar internamente.

b. El caballero blanco

Una forma posible de superar los problemas de gestión es contratar a un

experto en salvar proyectos, aquella persona milagrosa que viene a
salvar todo mal funcionamiento y a intentar recuperar el proyecto: el
caballero blanco (knight white). En este tipo de solución debe
considerarse la asesoría y la consultoría en proyectos como un medio
válido de conseguir algún caballero blanco.

3.3. Herramientas y técnicas de

gestión
Para completar este capítulo de gestión de proyectos no se deben olvidar
una serie de herramientas y técnicas de gestión. Estas herramientas y
técnicas se presentan a continuación vinculadas a los distintos grupos de
procesos y son de aplicabilidad a un solo grupo. Igualmente, muchas de
ellas se encuentra soportadas por diversas herramientas informáticas.

3.3.1. Iniciación

La iniciación es el proceso de reconocimiento formal que va a desarrollar

y construir de forma material y tangible, una solución de negocio
compuesta de componentes humanos, de hardware y software. El
compromiso aborda el desarrollo de un nuevo proyecto o de un proyecto
ya existente que se va a continuar en la siguiente fase.

Este comienzo formal conecta el proyecto con las operaciones en curso

de la organización ejecutora. En algunas organizaciones, un proyecto no
está formalmente iniciado hasta tener completo un estudio de viabilidad,
un plan preliminar o alguna forma equivalente de análisis. Esto involucra
trabajar con el cliente para identificar las entidades clave en la
organización para luego ser entrevistados.

En particular, algunos tipos de proyectos, especialmente aquellos de

servicio interno y los de desarrollo de nuevos productos (de ingeniería),
inician informalmente y se les realiza una pequeña parte del trabajo para
asegurar los requisitos necesarios para el comienzo formal del proyecto.
3.3.1.1. Motivaciones del proyecto

En la iniciación es importante determinar con claridad el motivo por el

cual el proyecto se inicia, el cual puede deberse a alguna o varias de las
siguientes causas:

 Una demanda del mercado (por ejemplo, una compañía petrolífera

comienza un proyecto para construir una nueva refinería en
respuesta a la continua escasez de gasolina).
  Una necesidad de negocio (por ejemplo, una compañía de
formación comienza un proyecto para crear un nuevo curso y
aumentar sus ingresos).
 La demanda de un cliente (por ejemplo, un suministrador eléctrico
comienza un proyecto para construir una nueva subestación para
abastecer a un nuevo parque industrial).
 Un avance tecnológico (por ejemplo, una empresa electrónica
comienza un nuevo proyecto para desarrollar un videojuego,
después de la generalización del videocassette).
 Una necesidad legal (por ejemplo, un fabricante de pinturas
comienza un proyecto para fijar las directrices del manejo de
materiales tóxicos).

Estas causas también pueden llamarse problemas, oportunidades o

requerimientos del negocio. Lo fundamental de todos estos términos es
que la dirección suele tener que tomar una decisión sobre cómo
responder a ellos.

3.3.1.2. Selección del gestor del proyecto

El gestor del proyecto es habitualmente seleccionado al final de la

conceptualización del proyecto, una vez aprobado. El gestor del proyecto
debe ser una persona responsable a fin de dirigir, gestionar y administrar
todo el proyecto.

Su responsabilidad central es coordinar todas las actividades para

satisfacer los objetivos del proyecto en tiempo y presupuesto. Su rol es
diferente de un líder técnico o un desarrollador, cuyas responsabilidades
se relacionan con la integridad técnica del producto.

Entre sus diversas responsabilidades se puede destacar:

- ser el canal de comunicación entre el proyecto y la dirección;

- comunicar a los usuarios;

- planificar y programar;

- coordinar actividades y tareas;

- controlar el presupuesto, programa, riesgo y calidad;

- gestionar el personal; y,

- presentar a la dirección los documentos, entregables, informes de

rendimiento y actas de constitución y aceptación.

La tarea del gestor es dar visibilidad y gestionar compromisos. Encontrar

una persona para esta tarea no es sencillo, pues pocas personas
cumplen con todas las cualificaciones para proyectos complejos, menos
aún que tenga experiencia y esté disponible. Por este motivo, muchas
empresas crean una Oficina de Proyectos para gestionar mejor los
proyectos y crear un pool de futuros gestores.

Los gestores efectivos deberían tener habilidades de: comunicación,

organización, construcción de equipo, liderazgo, negociación, actuación
por objetivos, capacidad de trabajo bajo presión y competencia técnica.

Se recalca que la competencia técnica es útil y sirve bastante, pero

habilidades de gestión e interpersonales son más importantes para un
gestor de proyectos, de hecho, tener 'roce' en el trato de personas,
puede ser determinante al momento de escoger el gestor de un proyecto,
más que sus cualificaciones y experiencia técnica.

Los gestores exitosos son generalistas, no especialistas técnicos. Aún

más, en muchas ocasiones provienen de muchas áreas de la
organización y no necesariamente del mundo de la informática.

3.3.2. Planificación

La planificación requiere un fuerte esfuerzo de estimación para preparar

las acciones conducentes a conseguir el producto y cumplir con los
objetivos, y de selección de personal para cumplir con las tareas y
actividades definidas. Todo esto da lugar a un informe de alcance y al
plan del proyecto.

Esta es una etapa de comprensión del proyecto que implica:

 Entrevistar directivos para conseguir comprender el modelo de

negocios, la situación de mercado actual los objetivos y metas de
negocio e intenciones iniciales.
  Revisar procesos de negocios claves y la infraestructura que les
soporta.
 Revisar y analizar la situación actual frente al potencial uso de
entrar en Internet (presencia de un sitio web con respecto a la
visibilidad actual, efectividad como medio de comunicación,
facilidad de uso/navegación, desempeño completo, solidez de la
arquitectura técnica, etc.).
 Revisar y analizar el actual uso de redes informáticas para
promover la comunicación interna y compartir datos.
 Revisar políticas y procedimientos establecidos en los procesos
operacionales asociados o con relación a los potenciales objetivos.

Todos estos elementos han de aparecer detallados en el Plan del

Proyecto y en el Informe del Alcance.

3.3.2.1. Estimación

3.3.2.1.1. Estimación del trabajo

La definición del alcance comprende la subdivisión de las principales

entregas del proyecto (identificadas en el informe del alcance) en
componentes más pequeños y manejables con el fin de:

 Mejorar la precisión de las estimaciones de costes, programa y

recursos.
 Definir las bases para la medida y control de la realización del
proyecto.
 Facilitar una clara asignación de responsabilidades.

La adecuada definición del alcance del proyecto es crítica para el éxito

de un proyecto. Cuando hay una pobre definición del alcance, se puede
esperar que se eleven los costes finales del proyecto debido a los
inevitables cambios que interrumpen el ritmo del proyecto, causan
repeticiones de tareas, aumentan los plazos de entrega, y disminuyen la
productividad y las expectativas respecto de la obtención de los
objetivos.

Una herramienta útil para estimar el trabajo a realizar lo constituye la

Estructura de Descomposición del Proyecto (WorkBreakdown Structure,
WBS).
a. WBS

La base de las actividades de planificación lo constituye el WBS. Un

WBS descompone el proyecto en una estructura jerárquica bien definida
de tareas o actividades gestionables, cuya representación puede ser una
tabla o un árbol.

El número de niveles depende principalmente del tamaño del proyecto y

las preferencias del gestor del proyecto. Es importante que se expliquen
todas las actividades necesarias para completar el proyecto y que sean
asignadas a una entidad (persona u organización) de manera clara y
precisa, anulando toda posibilidad de ambigüedad.

Un WBS es una agrupación de elementos del proyecto orientada a las

entregas del mismo que organiza y define su alcance completo: trabajos
que no estén en la EDP quedan fuera del alcance del proyecto. Así, el
WBS provee un marco fundacional para programar, presupuestar y
controlar el proyecto y comienza una vez definido, el proceso de
estimación.

La descomposición comprende la subdivisión de las principales entregas

del proyecto en otros componentes más pequeños y manejables de
forma que las entregas sean definidas con suficiente detalle para
responder a las futuras actividades de] proyecto. La descomposición
comprende los siguientes pasos principales:

1. Identificar los principales elementos del proyecto. En general, los

principales elementos serán las entregas del proyecto y su dirección. Sin
embargo, siempre se deben definir los principales elementos en función
de cómo el proyecto será realmente dirigido. Por ejemplo, las fases del
ciclo de vida pueden constituir un primer nivel de descomposición, con un
segundo nivel determinado por las entregas (figura 3.6) o por algún otro
criterio organizativo (figura 3.7).
 Esta EDP es únicamente ilustrativa. No trata de representar el alcance completo del proyecto de
cualquier proyecto específico, ni supone que sea este el único modo de organizar la EDP para este
tipo de proyecto.

Figura 3.6: WBS de una estructura de descomposición por fases.

 Esta EDP es únicamente ilustrativa. No trata de representar el alcance completo del proyecto de
cualquier proyecto específico, ni supone que sea este el único modo de organizar la EDP para este
tipo de proyecto.

Figura 3.7: WBS de una planta de tratamiento de aguas residuales.

2. Decidir si se pueden realizar las adecuadas estimaciones de

duración y costes al nivel de detalle para cada elemento. El
significado de adecuadas puede variar en el curso del proyecto (la
descomposición de una entrega que se ha de producir en un tiempo
lejano puede que no sea posible). Para cada elemento, hay que pasar al
Punto 4 si se ha logrado el detalle adecuado y al Punto 3 si no es así
(esto quiere decir que los diferentes elementos pueden tener diferentes
niveles de descomposición).

3. Identificar los elementos constituyentes de una entrega. Los

elementos constituyentes se deberían describir en términos de resultados
verificables y tangibles, para facilitar la medida de la realización. Los
elementos componentes- del proyecto deben definirse, como se hace
con los elementos principales, en la misma forma como se terminará
realmente el trabajo del proyecto.

Resultados tangibles y verificables pueden incluir tanto servicios como

productos (por ejemplo, el informe de situación se puede describir
como informe de situación semanal; para un elemento manufacturado,
los elementos constituyentes podrían incluir varios componentes
individuales más el montaje final). Repetir el punto 2 para cada elemento
constituyente.

4. Verificar si se ha realizado la descomposición correcta:

- ¿Son necesarios y suficientes los elementos en el nivel inferior para

completar el elemento descompuesto? Si no es así, se deben modificar
los elementos constituyentes (añadir, eliminar o redefinir).

- ¿Está cada elemento clara y completamente definido? Si no es así, se

deben revisar o ampliar las descripciones.

- ¿Se puede programar correctamente cada elemento?, ¿presupuestar?,

¿asignar a una unidad específica de la organización (por ejemplo, un
departamento, equipo o persona) que aceptará la responsabilidad de
concluir satisfactoriamente el elemento? Si no es así, se requieren
revisiones que proporcionen un adecuado control.
b. Work packages

Cada nivel descendente representa una descripción cada vez más

detallada de los elementos del proyecto. Cada elemento en la EDP es
asignado a un único identificador; el conjunto de estos identificadores a
menudo se denomina código de cuentas. Los elementos de los niveles
más bajos de la EDP se suelen denominar paquetes de trabajo (work
packages). Estos paquetes de trabajo pueden ser descompuestos aún
más.

Las descripciones de los elementos de trabajo se reúnen frecuentemente

en un diccionario de la WBS. Este diccionario incluye generalmente
descripciones de paquetes de trabajo así como otra información de
planificación como fechas del programa, presupuestos de costes y
asignaciones de personal.

c. Otros tipos de WBS

No se debe confundir una WBS con otros tipos de estructuras de

descomposición utilizadas para presentar información del proyecto.

Otras estructuras comúnmente utilizadas en algunas áreas de aplicación

son:

 Estructura de descomposición contractual, que se utiliza para

definir el nivel de información que el proveedor suministrará al
comprador. La WBS contractual tiene normalmente menos detalle
que una WBS utilizada por el proveedor para dirigir su propio
trabajo.
 Estructura de descomposición organizativa, que muestra qué
elementos de trabajo han sido asignados a qué unidades de la
organización. Un organigrama.
 Estructura de descomposición de recursos, que es una variación
de la estructura de descomposición organizativa, y se utiliza
normalmente cuando se asignan los elementos de trabajo a
personas individuales.
 Lista de materiales, que representa una relación jerárquica de los
montajes, submontajes y componentes necesarios para fabricar un
producto manufacturado.
 Estructura de descomposición de tareas, que es prácticamente lo
mismo que una WBS correctamente realizada. La estructura de
descomposición de tareas se utiliza ampliamente en áreas en las
 que el término WBS es incorrectamente utilizado para referirse a
una lista de materiales.

3.3.2.1.2. Estimación de coste y programación

Los enfoques esenciales para estimar el coste y la programación

necesaria de un proyecto son dos.

a. Enfoque arriba-a-abajo y abajo-a-arriba

1. Enfoque arriba-a-abajo.

Esta es una estimación por analogías que significa utilizar el coste real
de anteriores proyectos similares como base para la estimación del coste
del proyecto actual.

Se usa frecuentemente para estimar los costes totales del proyecto

cuando la información detallada sobre el proyecto es escasa (por
ejemplo, en las fases iniciales de un proyecto). La estimación por
analogías es una forma de juicio experto.

La estimación por analogías es generalmente más barata que otras

técnicas, pero también suele ser menos precisa. Es más fiable, cuando
los proyectos anteriores son realmente similares y no sólo en apariencia,
y las personas o grupos de personas que realizan las estimaciones
tienen la experiencia necesaria.

2. Estimación abajo-a-arriba.

Esta técnica comprende la estimación de costes de tareas individuales:

sumando las estimaciones individuales se consigue el coste total del
proyecto.

El coste y la precisión de la estimación de abajo-a-arriba depende del

tamaño de las tareas individuales: cuanto más pequeñas son las tareas
tanto más se incrementa el coste como la precisión. El equipo de
dirección del proyecto debe sopesar si la precisión adicional justifica el
mayor coste.
Ambos métodos o enfoques se usan en conjunto y se requieren varias
iteraciones hasta alcanzar resultados que puedan considerarse
satisfactorios.

b. GANTT, PERT y CPM

Conseguir una buena programación es un reto, no obstante es razonable

y alcanzable. Ella debe tener el compromiso del equipo al completo, para
lo cual se recomienda que cada miembro o grupo del equipo determine
las tareas a realizar y el tiempo para cumplirlas. La programación para
grandes proyectos usualmente comprende un programa master,
mostrando principales actividades e hitos y dejando el detalle en sub-
programas.

La forma más común de presentar un programa es una carta GANTT que

muestra las actividades contra una escala de tiempo horizontal (figura
3.8). Las cartas GANTT son herramientas populares para comprender y
facilitar la creación y revisión del programa. Esto da lugar a una red de
programa que muestra las relaciones internas.

Estas relaciones se muestran habitualmente como redes PERT (Program

Evaluation Review Technique, figura 3.9) y CPM (critical path method).
Ambos métodos son bastante similares en el uso de flujogramas, grafos
o redes de dependencia.
Otra ventaja de las redes de programación (schedule networks) es que
pueden usarse para identificar y seguir el camino crítico del proyecto.
Todas estas técnicas de representación, son instancias de un diagrama
de precedencias.

c. Diagramas de representación

 Método del diagrama de precedencias. Este es un método de

elaborar un diagrama en red del proyecto usando nodos, que
representan las actividades, conectados mediante flechas, que
muestran las dependencias (figura 3.10). Esta técnica se
denomina también actividades en los nodos y es el método
utilizado en la mayoría de los programas de software para la
gestión de proyectos. El método del diagrama de precedencias se
puede realizar manualmente o mediante ordenador.
El método incluye cuatro tipos de dependencias o relaciones de
precedencia:

 Terminación-a-comienzo: la actividad inicial debe terminar antes

de que la actividad final pueda comenzar;
 Terminación-a-terminación: la actividad inicial debe terminar
antes de que la actividad final pueda terminar;
 Comienzo-a-comienzo: la actividad inicial debe comenzar antes
de que la actividad final pueda comenzar; y,
 Comienzo-a-terminación: la actividad inicial debe comenzar antes
de que la actividad final pueda terminar.

En el método del diagrama de precedencias, el tipo más habitual de

relación lógica es el terminación-a-comienzo. Las relaciones comienzo-a-
terminación se utilizan rara vez y cuando se utilizan, es únicamente por
ingenieros de programación profesionales. Usar las relaciones comienzo-
a-comienzo, terminación-a-terminación o comienzo-a-terminación con el
software para gestión de proyectos puede producir resultados no
esperados, ya que estos tipos de relaciones no han sido suficientemente
probados. Otros métodos similares son:

 Método del diagrama de flechas. Este es un método de

elaboración de un diagrama en red del proyecto que utiliza flechas
para representar las actividades y las conecta a nodos que
 muestran las dependencias (figura 3.11). Esta técnica también se
denomina actividades en las flechas y, aunque menos corriente
que el método del diagrama de precedencias, es la técnica que se
elige en algunas áreas de aplicación. El método del diagrama de
flechas utiliza solamente dependencias terminación-a-comienzo y
puede necesitar el uso de actividades ficticias para definir
correctamente todas las relaciones lógicas. El método del diagrama
de flechas se puede realizar manualmente o mediante ordenador.

 Métodos de diagramas condicionales. Las técnicas de

diagramas tales como los modelos GERT (Técnica de Revisión y
Evaluación Gráfica) y sistemas dinámicos, permiten tratar
actividades no secuenciales tales como lazos (por ejemplo una
prueba que se debe repetir más de una vez) o condicionadas (por
ejemplo, una actualización del diseño que sea solamente necesaria
si la inspección detecta errores). Ni el método del diagrama de
precedencias ni el método del diagrama de flechas permiten tratar
lazos o actividades condicionadas.
 Redes patrón. Se pueden utilizar redes normalizadas para facilitar
la preparación de los diagramas en red del proyecto. Pueden incluir
un proyecto completo o solamente una parte de él. A las partes de
una red se las suele denominar subredes o fragmentos de
redes. Las subredes son especialmente útiles cuando un proyecto
incluye varias partes idénticas o casi idénticas, como las plantas de
 un edificio alto de oficinas, los ensayos clínicos en un proyecto de
investigación farmacéutica, o los módulos del programa en un
proyecto de software.

d. Camino crítico

El camino crítico del proyecto es el conjunto de actividades que toma

mayor tiempo completarlo. En esencia, el camino crítico determina
cuándo el proyecto terminará. Las tareas en el camino crítico requieren
atención especial de la gestión debido a que no dejan espacios libres u
holguras en la programación, de hecho no puede atrasarse bajo ningún
concepto.

Debe hacerse notar que un proyecto puede tener muchos caminos

críticos y que las variaciones en la duración de las tareas puede ir de un
camino a otro. El camino crítico resulta también de utilidad para
identificar programaciones de riesgo.

El camino crítico es una técnica matemática que comprende el cálculo

teórico para el comienzo y terminación, con mayor antelación y mayor
retraso, de todas las actividades del proyecto sin tener en cuenta las
limitaciones del conjunto de recursos. Las fechas resultantes no son el
programa, sino que indican los períodos de tiempo dentro de los que la
actividad debe ser programada, dadas las limitaciones de los recursos y
otras restricciones conocidas.

En esencia, el Método del Camino Crítico es un método de optimización

que calcula una fecha de comienzo y terminación -la de mayor adelanto y
la de mayor retraso para cada actividad, basándose en la secuencia de
relaciones lógicas ya especificada y en la simple estimación de
duraciones. El objetivo del método del camino crítico es calcular
el margen con el fin de determinar qué actividades tienen la menor
flexibilidad de programación. Los algoritmos del método del camino
crítico se utilizan a menudo en otros tipos de análisis matemático.

Algunas variaciones ocurren respecto de un GERT y un PERT.

 GERT. Permite el tratamiento probabilístico tanto de las relaciones

lógicas como de las estimaciones de la duración de las actividades
(por ejemplo, algunas actividades pueden no desarrollarse, otras
se pueden desarrollar solamente en parte, y otras pueden
desarrollarse más de una vez).
  PERT. Utiliza las relaciones lógicas secuenciales y una media
ponderada de la estimación de duraciones para calcular la duración
del proyecto. Aunque hay diferencias superficiales, el PERT difiere
del GERT principalmente en que utiliza el concepto de distribución
(valor esperado) en lugar de la estimación más probable
originalmente utilizada en este último (figura 3.12). El PERT en sí
mismo apenas se usa hoy en día, aunque las estimaciones
realizadas para el PERT se usan frecuentemente en los cálculos
del CPM.

Un caso especial de análisis matemático es la reducción de plazos, que

busca la manera de reducir el programa del proyecto sin alterar su
alcance (por ejemplo, lograr las fechas impuestas u otros objetivos del
programa).

La reducción de plazos incluye técnicas tales como:

 Crashing. Es una técnica en la que se analizan el coste y los

cambios del programa para determinar cómo obtener la mayor
reducción de plazos posible con el menor incremento de costes.
El crashing no siempre produce una alternativa viable y da lugar,
frecuentemente, a un incremento de los costes.
 Camino acelerado. Consiste en realizar actividades en paralelo
que normalmente se realizarían en serie (por ejemplo, empezar a
 codificar en un programa de software antes de completar su
diseño, comenzar a construir las cimentaciones para una refinería
de petróleo antes dé realizar el 25 por ciento de la labor de
ingeniería, o empezar a comprar hardware sin tener definida la
infraestructura e-business). Normalmente esta técnica conduce a
repetir tareas y frecuentemente incrementa el riesgo.

e. Programa del proyecto

El programa del proyecto3 incluye al menos las fechas planeadas de

comienzo y las previstas de terminación para cada actividad.

El programa del proyecto se puede presentar en forma de resumen (el

"programa básico") o en detalle. Aunque puede presentarse en forma de
tabla, es más frecuente presentarlo gráficamente, utilizando uno o más
de los siguientes formatos:

 Diagramas en red del proyecto con información añadida sobre

fechas. Estos diagramas normalmente muestran la lógica del
proyecto y las actividades del camino crítico del proyecto.
 Diagramas de barras, también llamados diagramas de
GANTT. Muestran las fechas -de comienzo y terminación de las
actividades así como las duraciones esperadas, pero normalmente
no muestran las dependencias. Son relativamente fáciles de
interpretar y se usan frecuentemente en los informes de dirección.
 Diagramas de hitos. Son similares a los diagramas de barras
(figura 3.13), pero identifican el comienzo o la terminación
programados de las principales entregas y las conexiones externas
clave.
 Figura 3.13: Diagrama de hitos.

 Red dimensionada. Es una mezcla de diagramas en red del

proyecto y de diagramas de GANTT en la que se muestra la lógica
del proyecto, la duración de las actividades y la información del
programa (figura 3.14).
 Figura 3.14: Red dimensionada.

3.3.2.1.3. Estimación de coste y presupuesto

Otras tareas de estimación son las de coste y presupuesto. En un

proyecto, el coste del presupuesto puede medirse en función de las
horas de esfuerzo dedicadas a las tareas. La estimación es un análisis
histórico ajustado a las capacidades y habilidades de cada miembro.

La estimación cubre todas las actividades del WBS, incluyendo la propia

gestión del proyecto y sus funciones de apoyo, como el aseguramiento
de la calidad y el seguimiento de los planes de riesgo, por ejemplo. La
estimación debe incluir costes directos no labores, y los costes indirectos
o de overhead. Los costes directos se calculan de las horas-hombre
multiplicadas por su valor de mercado o acordado. Los costes directos no
laborales incluyen outsourcing, consultores, viajes, cenas, etc.

El presupuesto total del proyecto es determinado agregando todos los

costes directos e indirectos. Es buena práctica incluir salvaguardas de
gestión para contingencias y problemas no anticipados. Una reserva del
5 al 10% no es extraña y puede ser más elevada en proyectos mayores o
de alto riesgo.
El presupuesto debe asignarse a individuos u organizaciones siguiendo
el WBS. El presupuesto marca la línea base (baseline) sobre la cual
medir el desempeño del proyecto. Una herramienta adecuada es la curva
que muestra los costes acumulados, la cual provee la representación
gráfica del presupuesto en función del tiempo según la programación del
proyecto.

Figura 3.15: Curva de coste acumulado.

3.3.2.1.4. Selección de los miembros del equipo

La ejecución de un proyecto es como los deportes, la diferencia entre el

miembro más productivo y el menos productivo puede ser amplia; no
obstante se deberían seleccionar los mejores. Por este motivo es
importante tener en consideración que las habilidades a buscar no son
solamente técnicas, sino habilidades para solucionar problemas e
interpersonales. Aún más, debe recordarse siempre que un buen
miembro tiene una alta auto-estima y un fuerte compromiso hacia el éxito
de un proyecto.

Cualquier test a realizar debe crear equipos con una mezcla equilibrada
de habilidades y personalidades. Muchos programadores o personas del
ámbito técnico son personas introvertidas y pensativas que basan sus
decisiones en hechos en lugar de sentimientos y valores personales.
Ellos tienden a encontrar dificultades en construir relaciones y observar el
proyecto desde el punto de vista del usuario. Por ello, formar un equipo
equilibrado no es una labor sencilla.
1 Fuente: Barceló. M. La gestió d'un projecte informàtic. UOC. Pp. 15-16.
2 Fuente: Barceló. M. La gestió d'un projecte informàtic. UOC. pp. 9-10.
3 El programa del proyecto se considera preliminar hasta que la asignación de recursos ha sido

confirmada. Esto normalmente ocurre antes de la terminación del desarrollo del plan del proyecto.

3.3.2.2. Plan de proyecto

La planificación culmina con el plan del proyecto. Es un documento que

informa a la gestión, a los miembros del equipo y al cliente. Es como un
mapa que sirve para guiar al proyecto y sus involucrados.

El plan del proyecto es un documento formal y aprobado que se utiliza

para dirigir y controlar la ejecución del proyecto. Debería ser distribuido
según defina el plan de Gestión de Comunicaciones (por ejemplo, la
dirección de la organización ejecutora puede necesitar un plan general
con pocos detalles, mientras que un contratista puede necesitar muchos
detalles de un solo tema). En algunas áreas de aplicación, se usa el
término plan integrado del proyecto para referirse a este documento.

Debe establecerse una clara distinción entre el plan del proyecto y las
bases para medir la realización del proyecto. El plan del proyecto es un
documento o conjunto de documentos que debería esperarse que
cambien a medida que haya más información disponible sobre el
proyecto. Las bases para la evaluación de la realización del proyecto
representa un control de dirección que normalmente sólo cambiará
intermitentemente y en estos casos, los cambios serán realizados
únicamente como respuesta a un cambio autorizado del alcance del
proyecto. En este documento se especifican aspectos de desarrollo, los
subproductos a entregar, requerimientos de recursos, programación,
responsabilidades organizacionales y presupuestos y el proceso de
gestión. Además, incluye factores de riesgo y estrategias de gestión del
riesgo y describe de que manera se gestiona y asegura la calidad.
Establece el coste y las bases de la programación para gestionar y
controlar el proyecto. Además en sí mismo es parte efectiva del sistema
de control del proyecto.
Hay muchas maneras de organizar y presentar el plan del proyecto, pero
normalmente incluye lo siguiente (estos puntos se describirán con más
detalle más adelante):

 Justificación del proyecto.

 Descripción de los puntos de vista o estrategia de la dirección del
proyecto (un resumen de los planes de dirección para cada una de
las otras áreas).
 Establecimiento del alcance, que incluye las entregas y objetivos
del proyecto.
 WBS al nivel al que se realizará el control.
 Estimación de costes, fechas programadas de inicio de actividades
y asignación de responsabilidades al nivel de la EDP, en el que
será ejercido el control.
 Bases para la evaluación de la realización del proyecto en cuanto a
programa y costes.
 Principales hitos y fechas objetivo para cada uno.
 Personal requerido o clave.
 Riesgos clave, incluyendo las restricciones y supuestos y las
respuestas previstas para cada uno.
 Planes auxiliares de dirección, incluyendo el plan de gestión del
alcance del proyecto, el plan de dirección del programa, etc.
 Temas abiertos y decisiones pendientes.

Se deberían incluir otros resultados de la planificación del proyecto en el

plan formal, basándose en las necesidades de cada proyecto en
particular. Por ejemplo, el plan del proyecto para un gran proyecto
incluirá, normalmente, un organigrama del proyecto. Para probar la
adecuación del plan, el gestor del proyecto debe preguntarse:

 ¿El plan permite gestionar el proyecto de forma adecuada?

 ¿El plan provee información suficiente para que los miembros del
equipo planifiquen y ejecuten su trabajo?
 ¿Se cuenta con el compromiso de la dirección y del equipo del
proyecto?
3.3.2.3. Informe de alcance

El Informe de Alcance constituye una base documentada para la

adopción de las futuras decisiones del proyecto y para confirmar o
desarrollar entre las entidades involucradas en el proyecto aportando un
entendimiento común del alcance del mismo. Según progresa el
proyecto, puede ser necesario revisar o depurar el informe, para reflejar
los cambios en el mismo. Éste debe incluir, bien directamente o por
referencia a otros documentos, lo siguiente:

 Justificación del proyecto: la necesidad del negocio que debe ser

resuelta por el proyecto. La justificación del proyecto constituye la
base para la evaluación de futuros compromisos.
 Producto del proyecto: un breve resumen de la descripción del
producto.
 Entregas del proyecto: una lista a modo de resumen de los
subproductos cuya completa y satisfactoria entrega marca la
finalización del proyecto.
 Objetivos del proyecto: los criterios cuantificables que deben
cumplirse para que el proyecto se considere un éxito. Los objetivos
del proyecto deben incluir, al menos, medidas de costes, programa
y calidad. Los objetivos del proyecto debe tener un atributo (por
ejemplo, coste), un patrón o unidad fundamental (por ejemplo,
dólares USA) y un valor absoluto o relativo (por ejemplo, menos de
1,5 millones). Los objetivos no cuantificables (por ejemplo, la
satisfacción del cliente) constituyen un riesgo elevado.

En algunas áreas de aplicación, las entregas del proyecto son llamadas

objetivos del proyecto mientras que los objetivos del proyecto son
llamados factores críticos de éxito.

3.3.3. Control y seguimiento

El control es una etapa de valoración del trabajo realizado que pretende

aprovechar buenas prácticas y analizar las debilidades del proyecto
tomando de referencia los datos recogidos durante el seguimiento.

3.3.3.1. Aseguramiento de la calidad

El aseguramiento de la calidad (Quality Assurance, QA) certifica que el
producto cumple con los requerimientos y provee la funcionalidad y
calidad deseada.

La calidad, asi como los requerimientos de desempeño técnico, deben

ser especificada en términos cuantitativos claramente comprensibles por
el cliente y los miembros del equipo. Además, mientras el equipo se
compromete a construir la calidad en el producto, una práctica frecuente
es contar con alguien dedicado y separado del equipo cumpliendo
funciones de asegurador de calidad. El principal propósito del
aseguramiento de la calidad es detectar errores y corregirles
rápidamente. La detección y corrección temprana puede resultar en
beneficios de coste y tiempo significativos.

De hecho, el coste de corregir errores en la etapa de diseño es un 10%

de corregirle en la etapa de prueba.

Las herramientas básicas para el aseguramiento de la calidad son las

revisiones técnicas. Las revisiones técnicas son efectivas ante la
aparición temprana de diferentes tipos de errores a probar. Las prácticas
más comunes de aseguramiento de calidad son loswalkthroughs, las
inspecciones y las pruebas.

Ambos tipos de revisiones son efectivas para la detección temprana de

errores en requerimientos, interfaces, diseño, codificación o manufactura,
y documentación. El seguimiento del proceso de calidad, requiere
métricas precisas.

Walkthroughs

Un walkthrough son reuniones informales en las cuales los miembros del

equipo revisan el diseño o código para identificar mejoras y problemas.

Inspección

Las inspecciones son revisiones más formales donde revisores usan

listas de chequeo (checklists) para estimular la revisión y recurren a
registros de control y retroalimentación sistemática para mejorar el
proceso de desarrollo.

Prueba
La prueba es el medio más común de asegurar la calidad. Es el ejercicio
sistemático de buscar y detectar defectos donde fueron hallados
anteriormente. Conducidos al nivel de unidad y de sistema, sirven para
verificar la funcionalidad y calidad del sistema

3.3.3.2. Tiempo y coste

a. Proceso de control del proyecto

El propósito del control del proyecto es:

- Mantener el proyecto en curso y cercano al plan de trabajo;

- Identificar problemas antes de que ocurran e

- Implementar planes de recuperación antes que los daños sean

irreparables.

El proceso involucra comparar el progreso con el plan y tomar acciones

correctivas conforme existan desviaciones que afecten el desempeño y/o
el plan; y proveer retroalimentación (figura 3.16).
Para un control a tiempo y efectivo, el gestor del proyecto debe tener
completa visibilidad del avance del proyecto. Para ello, se debe efectuar
un monitoreo y seguimiento sistemático. El grado de formalidad y
frecuencia de monitoreo depende del tipo de proyecto, aunque siempre
debe enfocarse en el coste, programación y desempeño técnico.

b. Control del coste y del programa

El seguimiento del coste y de la programación involucra comparar el

estado actual contra lo presupuestado en cuanto coste, tiempo y etapas.

Desviaciones significativas del plan requieren atención prioritaria del

gestor del proyecto para tomar una acción correctiva a tiempo. Conocer
la desviación no es suficiente, hay que identificar la causa del problema.
Si la desviación del plan es grande, se debe decidir si se replanifica.

Para tener visibilidad de estas decisiones, el coste y la programación son

analizados de forma integrada. Estar dentro del presupuesto no es
suficiente si las tareas no se completan a tiempo. Similarmente,
completar tareas de acuerdo al programa no basta si los costes "se han
disparado". En este análisis, disponer de la WBS provee la base
fundamental para comparar coste y programa contra el plan.

c. Valor ganado

Aunque las cartas GANTT y los informes de acumulación de reportes

proveen indicadores útiles del estado del proyecto, presentan
limitaciones. La limitación primaria es que son complejos y difíciles de
analizar, particularmente para grandes proyectos con muchas tareas.
Esta complejidad puede conducir a una percepción distorsionada del
estado del proyecto. Una técnica para proveer una mejor, más holística
visión del progreso del proyecto es la técnica del valor ganado (Earned
Value Technique). Originalmente creada para un mejor seguimiento de
proyectos gubernamentales a gran escala, es hoy en día herramienta
habitual en los proyectos informáticos.

La técnica mide el valor del trabajo realizado en términos del presupuesto

asignado al trabajo. Permite separar las variaciones de coste y
programación en términos monetarios.
La variación en coste se debe a la variación en el precio del trabajo
realizado mientras la variación en la programación se debe al trabajo
realizado fuera de los tiempos programados.

El valor ganado y las variaciones son calculadas para una actividad

simple, un grupo de actividades o el proyecto completo. De las
variaciones de coste y programación es posible determinar indicadores
de desempeño de coste y programación del proyecto.

Estos índices proveen visibilidad instantánea sobre el desempeño del

proyecto. Esto ayuda al gestor del proyecto a estimar el coste para
terminar y el coste actual a la fecha, basado en el desempeño a la fecha.

La técnica se basa en tres parámetros básicos:

 Presupuesto planeado (planned budget): coste presupuestado de

trabajo planificado (budgeted cost of work scheduled, BCWS).
 Coste actual: coste actual de trabajo realizado (actual cost for
work performed, ACWP).
 Valor ganado (earned value): Coste presupuestado de trabajo
realizado (budgeted cost for work performed, BCWP).

Variación del coste (cost variance, CV) se calcula de la siguiente manera:

CV = BCWP - ACWP

Una variante negativa indica un coste excesivo.

Variación de la programación (schedule variance, CV) se calcula de la

siguiente manera:

SV = BCWP - BCWS

Una variación negativa indica que el proyecto esta fuera de

programación. Ambas son expresadas en términos monetarios, pero
también pueden expresarse en porcentajes de la siguiente manera:

% CV = CV / BCWP

% SV = SV / BCWP

El índice de desempeño de coste (cost performance index, CPI) está

calculado como:
CPI = BCWP / ACWP

El CPI puede usarse para calcular el coste del proyecto o el coste

estimado al completarlo (estimate at completion, EAC). Una fórmula
simplificada para EAC es:

EAC = BAC / CPI

Donde BAC (budgeted cost at completion) es el coste básico o

presupuestado para terminar el proyecto.

Similarmente, es posible calcular el índice de desempeño de la

programación (schedule performance index, SPI) de la siguiente manera:

SPI = BCWP / BCWS

Por último, una versión simplificada para estimar la duración del proyecto
o tiempo estimado para terminar el proyecto (estimated time to
completion, ETC) se puede calcular de la siguiente manera:

ETC = OD / SPI

Donde OD es la duración original (original duration, OD).

d. Revisión

1. Encuentros de revisión.

Los encuentros de revisión son instrumentos vitales en el control del

proyecto. El propósito es valorizar el progreso e identificar áreas de
desviación desde el plan para proponer acciones correctivas. Los
mismos son el mecanismo para discutir abiertamente problemas
presentes y futuros y proveer un marco de comunicación habitual, si se
desea.

Estos encuentros:

- Proveen visibilidad a los planes y su progreso, y crean oportunidades

para obtener y reforzar compromisos con los participantes.

- Son más efectivos cuando ellos son programados a intervalos regulares

(semanalmente es lo habitual) y siguiendo una agenda establecida y
acordada por los involucrados.
- Deberían contar con la presencia de personas representativas de las
áreas involucradas para tener respuestas adecuadas, negociar
soluciones y hacer compromisos.

- Son diferentes de una revisión técnica y/o de calidad, donde se dedica

especial atención a detectar y corregir problemas más que revisar el
progreso.

- Son diferentes de una reunión de gestión o de dirección, donde el

gestor de proyecto se reúne con un directivo o un comité de dirección,
para informar del proyecto y su integración en la estrategia
organizacional.

2. Informes de estado.

Los informes de estado son preparados y enviados de forma regular para

informar a las personas externas a la organización. Ellos deben ser
cortos y oportunos.

3. Agenda del proyecto.

Una agenda típica incluye:

- Detalle del progreso programado (principales hitos, programa y costes);

- Avance de actividades específicas;

- Estado de determinados ítems y/o recursos;

- Planificación futura; y,

- Estado de las áreas de alto riesgo.

4. Informe de alcance e informe de realización.

Es conveniente mantener actualizado el informe del alcance con el fin de

mostrar los cambios al plan del proyecto. Las nuevas versiones del
informe de alcance deben ser mantenidas en la biblioteca del proyecto y
los cambios y alteraciones ser gestionadas de manera adecuada e
informadas a las personas pertinentes afectadas.
Asimismo, vinculados al informe de alcance, se encuentran los Informes
de Realización, los cuales organizan y resumen la información reunida a
lo largo del proyecto y presentar resultados de cualquier análisis. Estos
informes deben proporcionar los tipos de información y nivel de detalle
requerido por las distintas entidades involucradas, tal y como establece el
Plan de Comunicaciones.

3.3.3.3. Desempeño y evaluación

a. Control de desempeño técnico

El control del desempeño técnico es el proceso de asegurar que todos

los requerimientos son satisfechos a través de revisiones de diseño.

1. Revisiones técnicas.
Estas revisiones son usualmente mantenidas en los principales hitos (por
ejemplo, al término de las fases del ciclo de vida) pero pueden hacerse
en otros instantes. El propósito de estas revisiones es mostrar el logro
actual o predecir objetivos técnicos potenciales. El progreso de los
objetivos técnicos debería hacerse con métricas apropiadas. Una
práctica útil es contar con representantes de los clientes en las revisiones
técnicas para asegurar criterios comunes de las necesidades y evitar
sorpresas futuras.

2. Métricas.
Las métricas proveen visibilidad de lo conseguido y sus tendencias
ofrecen un medio predictivo para actuación futura. Ellas deben estar
basadas en normas y estándares, esencialmente cuantitativas, además
de las acordadas entre las partes.

b. Cambio y control de la configuración

El control del cambio es un concepto simple, pero complejo en su detalle.

Aún el requerimiento mejor preparado requiere cambios, una vez que se
diseña y se prueba.

Muchos proyectos fallan por cambios incontrolados que van más allá de
los requerimientos definidos inicialmente o acordados previamente. En
varios casos conducen a situaciones de escalada. Para ayudar a la
detección y seguimiento del cambio es esencial contar con un sistema de
control de cambios que incluya herramientas automatizadas, y un núcleo
de gestión del cambio o grupo de control de cambios.

Un sistema de control de cambios es un conjunto de procedimientos

documentados y formales que definen los pasos a seguir para realizar
cambios en los documentos oficiales del proyecto. Incluye formularios,
sistemas de seguimiento y los niveles de aprobación necesarios para
autorizar los cambios.

En muchos casos, la organización ejecutora tendrá un sistema de control

de cambios que podrá utilizarse tal cual para el proyecto. Sin embargo, si
no tienen disponible un sistema adecuado, el equipo de dirección del
proyecto necesitará desarrollar uno como parte del proyecto.

Un proceso de cambio comienza con un requerimiento de cambio,

conocido en ocasiones como una Propuesta de Cambio de Ingeniería
(PCI, Engineering Change Proposal, ECP), que identifica la necesidad de
cambio, la naturaleza del cambio y el impacto del cambio. Este cambio
se remite al núcleo de gestión del cambio para que sea revisado y se
disponga su aprobación o no (figura 3.17).

Los poderes y responsabilidades de dicho grupo deben estar bien

definidos y acordados por las principales entidades involucradas en el
proyecto. El núcleo, usualmente bajo responsabilidad del gestor del
proyecto o su designado se compone de representantes de cada área
afectada por el desarrollo. Este equipo se diseña para que todas las
partes comprendan las consecuencias del cambio antes de hacerlas. En
proyectos grandes y complejos puede haber múltiples grupos de control
de cambios con diferentes responsabilidades.

Después de una revisión, el núcleo asegura que sólo los cambios

aprobados sean realizados de manera controlada y notificados a todas
las partes involucradas.

El sistema de control de cambios debe incluir también procedimientos

para realizar cambios que pueden ser aprobados sin una revisión previa,
por ejemplo, como resultado de emergencias. Generalmente, un sistema
de control de cambios permitirá la aceptación "automática" de
determinados tipos de cambios. Estos cambios deben ser documentados
y organizados de forma que no causen posteriormente problemas en el
proyecto.

c. Evaluación del proyecto

La evaluación del proyecto es el proceso de valorizar periódicamente el

estado del proyecto con relación a sus objetivos. Esto difiere del control
del proyecto en dos aspectos:

 El control del proyecto es responsabilidad del gestor del proyecto,

la evaluación es tarea de la dirección.
 El control del proyecto es un proceso continuo, mientras la
evaluación es periódica.

Las evaluaciones típicamente son realizadas en hitos importantes para

determinar cuando cambios mayores han surgido. Estos cambios pueden
incluir re-valorización de metas y objetivos, re-estructuración del plan o,
aún mas, cancelación del proyecto.

Por último, la evaluación del proyecto juega un rol importante en la

complexión del proyecto. En este caso, evalúa experiencia pasada y
desarrolla las lecciones aprendidas para beneficio de futuros proyectos.

3.3.3.4. Recursos humanos

a. Motivación y construcción del equipo

El desarrollo y construcción del equipo es una labor cubierta por literatura

de ciencias y gestión del comportamiento (comportamiento
organizacional, psicología social) pero a menudo es ignorada en otras
areas.

Muchos gestores de proyectos tienden a enfocar su atención en los

detalles técnicos, ignorando que son personas las que diseñan y también
son personas las que usarán estas aplicaciones.

Pensar así hoy en día es un gran riesgo, pues muchos proyectos fallan
por mal funcionamiento del equipo y no por problemas técnicos.

La construcción del equipo es el proceso de transformar un grupo de

individuos de diferentes orígenes y formaciones en un grupo cohesivo de
alto desempeño, con una alta motivación y enfocados al logro de
objetivos.

Es un proceso que requiere habilidades de liderazgo y una comprensión

de los diversos factores organizacionales que influyen en el trabajo en
equipo y en las relaciones humanas.

Así es necesario:

 Compartir la visión y el objetivo. Una visión compartida es

esencial para el éxito del proyecto, de hecho se le considera un
factor de éxito. Estar de acuerdo en la visión y en los objetivos
ayuda a mantener el equipo centrado y productivo. En estos casos,
la toma de decisiones es más efectiva y se evitan debates efímeros
y que sólo consumen tiempo.
 Compromiso con el proyecto. El compromiso puede definirse
como el sentido de lealtad y dedicación al proyecto. Miembros
comprometidos desean dedicar su tiempo y energía y hacer
sacrificios personales por el proyecto. La visión compartida es la
base del compromiso. Sólo cuando las personas comprenden y
comparten una visión del proyecto, desean comprometerse con el
proyecto.

Gestores efectivos, trabajan duro para construir y afianzar el

compromiso. Buscan vías de crear posibilidades excitantes de
conseguir un proyecto exitoso. Crean ambientes de trabajo
 estimulantes, generando retos de trabajo interesantes con
oportunidades de crecimiento personal. Involucran a las personas
en la toma de decisiones. Hacen visible el esfuerzo de cada
persona informando del progreso a cada miembro. Convierten a
cada miembro en un activo del proyecto.
 Fuerte sentido de identidad. Los miembros de equipos efectivos
son aquellos que se sienten que son especiales, diferentes de
otros. Este sentimiento de identidad el gestor de proyectos debe
reforzarlo por todos sus medios a mano. Una práctica común es
usar símbolos visibles para mostrar la identidad (distintivos en la
ropa, las tazas de café, etc.) Probablemente la mejor manera es
crear un sitio donde los miembros compartan su trabajo. Hitos de
celebración para comunicar y compartir experiencias, son
momentos para reforzar el espíritu. Gestores exitosos crear y
definen culturas en sus proyectos, distintas del resto de la
organización.
 Confianza mutua. Un equipo efectivo requiere colaboración entre
los miembros. La colaboración existe en climas de confianza. A
mayor confianza, el equipo compartirá mayor información,
informará problemas y tomará decisiones efectivas. Buenos
gestores de proyecto crean y nutren una atmósfera de confianza
que a su vez construye y refuerza la confidencialidad y el
compromiso. La confianza solamente existe en equipos donde hay
valores de honestidad y franqueza, donde las personas son
tratadas con imparcialidad, respecto y dignidad.
 Miembros competentes. Los gestores de proyecto efectivos
reclutan personas idoneas según las competencias que requiera el
proyecto; las habilidades de colaboración para el trabajo efectivo
con otras personas son tan importantes como las habilidades y
destrezas técnicas.

Un gestor efectivo continuamente evalúa a su equipo y siempre

está dispuesto a cambiar o reasignar personas con un desempeño
inadecuado. Los gestores de proyecto gestionan relaciones con el
resto de la organización y remueven obstáculos. Los miembros se
motivan cuando ellos saben que la dirección está comprometida
con el proyecto y busca y provee los recursos necesarios. Todo
esto requiere habilidades de gestión superiores a las técnicas, que
incluso pueden carecer y/o desarrollar con el tiempo.

Entre las habilidades para construir un equipo, se cuenta:

- Evitar comprometer los objetivos del equipo con otros tipos de intereses
personales.

- Exhibir un compromiso personal a los objetivos del equipo.

- No diluir el esfuerzo del equipo con muchas prioridades.

- Ser equitativo e imparcial con todos los miembros.

- Estar predispuesto a enfrentar y resolver problemas asociados con el

desempeño inadecuado de miembros del equipo.

- Estar abierto a nuevas ideas e información proveniente de los miembros

del equipo.

b. Resolución de conflictos

Los conflictos son parte de la vida diaria del proyecto. Ellos surgen desde
cualquier sujeto involucrado en el proyecto, tanto puede ser de un
miembro del equipo como de un cliente o promotor. De hecho, la fuente
de conflictos es abundante. La más común es la competencia por los
recursos escasos, las diferencias respecto de los objetivos y los medios
para conseguirlos, y desacuerdos en costes, programación y
tecnicismos. Por supuesto deben añadirse los conflictos que surgen de
las relaciones interpersonales. Independiente de las causas, todo
conflicto debe tratarse, identificando sus motivos y orígenes, comprender
sus causas y resolverlos de manera rápida. Fallar al hacer esto puede
seriamente alterar el proyecto y generar atrasos y gastos excesivos.

3.3.4. Cierre

El cierre comprende dos procesos y, según el tamaño del proyecto, el

volumen de información manejado y/o el grado de desorden sostenido, el
cierre puede ser tan complejo y extensivo que puede considerarse un
proyecto. Además, en el proyecto cobra importancia el hecho que el
cierre es una etapa de recomendación y evaluación de lo aprendido.

3.3.4.1. Cierre administrativo

El proyecto o fase, después de lograr sus objetivos o estar terminado por
otras razones, requiere su cierre. El cierre administrativo consiste en la
verificación y documentación de los resultados del proyecto para
formalizar la aceptación del producto del proyecto por parte de los
patrocinadores o clientes.

El cierre incluye la recopilación de todos los registros del proyecto,

asegurando que reflejan las especificaciones finales, así como el análisis
del éxito y la efectividad del proyecto y el archivo de esta información
para su uso futuro. De hecho es importante aprovechar esta información
para promover un aprendizaje. Esto último no puede hacerse sin una
reflexión del trabajo realizado para ver cuánto se ha aprendido, qué se
pudo haber aprendido, el porqué de los errores, etc. Además es
importante conseguir las aprobaciones finales del trabajo realizado y del
producto entregado.

Es importante hacer notar que las actividades de cierre administrativo no

deben retrasarse hasta la terminación del proyecto. Cada fase del
proyecto debe ser apropiadamente cerrada para asegurar que no se
pierde información útil e importante.

3.3.4.2. Cierre de contratos

Es similar al cierre administrativo. Comprende la verificación del producto

(¿estaba todo el trabajo realizado de forma completa, correcta y
satisfactoria?) y el cierre administrativo (actualización de registros para
reflejar los resultados finales y el archivo de dicha información para su
disponibilidad futura).

Los términos y condiciones del contrato pueden establecer unos

procedimientos específicos para el cierre del contrato. Una terminación
temprana del contrato es un caso especial de cierre del contrato.

3.4. Modelos de madurez de gestión

de proyectos
La gestión de proyectos habitualmente se espera sea aplicada a
cabalidad luego de leer un manual o sencillamente asistir a un curso. No
obstante, en este sentido, desde el área de gestión de proyectos, se ha
planteado que las prácticas de gestión han de usarse según las
competencias que requiera un proyectista conforme madura en su
experiencia en gestión de proyectos. En este sentido se han presentado
en la literatura modelos llamados modelos de madurez de gestión de
proyectos, cuyo fin es proveer un marco que permita reconocer qué tipo
de competencia se requiere en diferentes estados de madurez en gestión
de proyectos.

Un modelo de madurez de gestión de proyectos aglutina y organiza

en niveles de madurez un conjunto de criterios de gestión con el fin de
orientar las actuaciones de los proyectistas. Estos niveles, aparte de
regular las competencias necesarias conforme el gestor de proyectos
aprende y asimila, actúan en sí mismos como metas a conseguir por las
organizaciones desde el punto de vista de la calidad de su gestión de
proyectos.

La literatura muestra que todos estos modelos de madurez han surgido o

se basan directamente en el Capability Maturity Model del Software
Engineering Institute (SEI) en Estados Unidos.

A continuación se presentará el CMM para luego pasar a revisar algunos

modelos de madurez en gestión de proyectos.

3.4.1. Capability Maturity Model

El CMM es un modelo de capacidad y madurez para la evaluación de

procesos en una organización. Fue desarrollado inicialmente para los
procesos relativos al desarrollo e implementación de software y de éste
se derivan varios modelos con otros fines; como ser: ingenieria de
seguridad de sistemas, recursos humanos, mantenimiento y adquisición
de software y desarrollo integrado de productos, entre otros. El CMM
describe las prácticas de ingeniería de software y de gestión que
caracterizan a las organizaciones conforme mejora (madura) su proceso
para desarrollar y mantener software.

Se añade en particular que un proceso de software se puede definir

como un conjunto de actividades, métodos, prácticas, y transformaciones
que las personas usan para desarrollar y mantener software y los
productos asociados.

3.4.1.1. Niveles de madurez

La mencionada madurez se valoriza en función de cinco niveles.

Un nivel de madurez es una plataforma en el camino de conseguir una

mejora en un proceso de software. Cada nivel de madurez considera un
conjunto de objetivos de procesos que una vez satisfechos estabilizan
una componente del proceso de software. A continuación se describe
cada uno de los niveles de madurez del CMM.

 Inicial. En este nivel el proceso de software es ad-hoc y

ocasionalmente caótico. Pocos procesos son definidos y el éxito
depende del esfuerzo y heroicidad de los individuos.
 Repetible. En este nivel se establecen procesos de gestión de
proyectos básicos para hacer seguimiento del coste, la
programación y la funcionalidad.
 Definido. En este nivel las actividades de gestión e ingeniería del
proceso de software son estandarizadas y documentadas en uno o
varios procesos de software estándar para la organización.
 Gestionado. Mediciones detalladas del proceso de software y
calidad del producto son registradas. En este nivel, el proceso y el
producto de software son cuantitativamente comprendidos y
controlados.
 Optimizante. En este nivel se habilita la mejora continua del
proceso.
3.4.1.2. Arquitectura por niveles

A su vez, los niveles de madurez se componen de áreas de proceso

claves (Key Process Areas), que contienen prácticas clave (Key
Practices) organizadas a su vez en rasgos comunes (Common Features).

 Las Key Practices Areas (KPA) indican las áreas en que una
organización debería concentrarse para mejorar su proceso
desoftware.
  Las Common Features (CF) son un conjunto de prácticas
agrupadas dentro de un área clave o necesidad.
 Las Key Practices (KP) son las actividades e infraestructura que
contribuye de manera más efectiva a la implementación e
institucionalización de cada área clave.

3.4.1.3. La madurez por temas

El carácter organizador del CMM da lugar a toda una serie de variaciones

ligadas al desarrollo de software como un producto.

No obstante el CMM presenta una peculiaridad que requiere ser

mejorada según el contexto de este trabajo. El CMM describe la madurez
por niveles y plantea un camino para conseguirlas. Sin embargo, como
modelo es un patrón que plantea lo que hay que medir por nivel, no
distinguiendo si existen mejoras parciales. Como instrumento de
medición posee un carácter excesivamente evaluativo más que formativo
y, además, deja a las organizaciones sin capacidad de mejoras parciales
por temas, por procesos críticos o más robustos.

SPICE es un modelo de madurez de origen europeo similar al CMM, pero

con la diferencia que las mejoras de capacidad del proceso se pueden
conseguir por temas o áreas. Por ejemplo, se puede alcanzar un nivel
dos en documentación y un nivel tres en el uso de métricas. Esta última
cualidad es considerada en muchos de los modelos de madurez de
proyectos que a continuación se presentan.

3.4.1.4. Modelos de madurez

Del área de gestión de proyectos se han considerado en este estudio los

siguientes modelos de madurez de proyectos, por su relevancia, impacto
y presencia:

 Trillium model,
 Project Management Assessment,
 Management Maturity Model, y
 Innovation Maturity Model.
3.4.1.5. Trillium model

El modelo Trillium es un producto efectuado y utilizado por una

Organización (Bell Canadá) para dar valor al desarrollo de un producto y
apoyar las capacidades de proveedores de telecomunicaciones o
productos basados en tecnologías de la información existentes o futuros.
El modelo ha sido diseñado para ser aplicado a sistemas
de software 'empotrados' tales como sistemas de telecomunicaciones, no
obstante buena parte del modelo puede ser aplicado a otros segmentos
de la industria del software como sería el área de Management
Information Systems. Con respecto al CMM, el modelo Trillium, se
distingue en que:

- Define roadmaps en lugar de áreas clave.

- Tiene una perspectiva orientada al producto, haciéndolo más general y

de amplio uso;

- Da amplia cobertura a los aspectos que inciden o impactan en la

capacidad del proceso; y,

- Se enfoca al cliente en lugar del desarrollo mismo.

Esto consigue que se definan prácticas que guían al proyectista sobre

cómo conseguir lo que desea un usuario/cliente donde, en lugar de
señalar determinadas metas que se deben alcanzar con ciertas prácticas
de diseño, se buscan aquellas prácticas que habiliten la consecución de
lo que desea el usuario.

a. Niveles de madurez

A semejanza del modelo CMM, el modelo Trillium presenta una escala de

cinco niveles de madurez:

1. Nivel 1 Desestructurado. En este nivel el proceso de desarrollo es

ad-hoc. Los proyectos frecuentemente no pueden satisfacer objetivos de
calidad o de programación. El éxito posible se basa más en el trabajo de
los individuos que en la propia estructura e infraestructura organizacional.

2. Nivel 2 Repetible y orientado al proyecto. El éxito individual del

proyecto se consigue a través de una férrea planificación y control de
gestión del proyecto, dando especial énfasis a los requerimientos de
gestión, técnicas de estimación y configuración del cambio.

3. Nivel 3 Definido y orientado al proceso. Aquí los procesos son

definidos y utilizados al nivel organizacional, no obstante se acepta que
el proyecto sea adaptado a las circunstancias. Los procesos son
controlados y mejorados. Se incorporan requerimientos ISO 9001, como
procesos de entrenamiento y auditoría interna.

4. Nivel 4 Gestionado e integrado. La monitorización y análisis del

proceso son usados como mecanismos clave en la mejora. Procesos de
gestión del cambio y programas de prevención de defectos son
integrados. Las herramientas CASE se integran dentro del proceso.

5. Nivel 5 Completamente integrado. Metodologías formales son

extensivamente usadas. Repositorios organizacionales son usados para
soportar y mantener la historia del proceso de desarrollo.

b. Arquitectura del modelo

La arquitectura de Trillium igualmente plantea una descomposición pero

con una diferencia sustancial con el CMM: no se comienza la
descomposición desde los niveles de madurez, sino desde ocho áreas de
capacidad (Capability Áreas), cada una de las cuales contiene
varias roadmaps y estos últimos a su vez contienen prácticas (Practices),
usados paulatinamente por niveles de madurez (figura 3.18)1.
De esta forma, la arquitectura de Trillium se caracteriza por poseer:

 Capability Areas: ocho áreas centrales de preocupación o

prioritarias para el modelo Trillium, cada una de las cuales se
encuentra contenida por prácticas;
 Roadmaps: conjunto de prácticas relacionadas, enfocadas sobre
un área o necesidad organizacional, o un elemento específico,
dentro del proceso de desarrollo del producto; y,
 Practices: acciones a desarrollar para conseguir una mejor
capacidad del proceso, cada una de las cuales se vincula a un
nivel de madurez.

La tabla 3.7 detalla y permite cuantificar la relación entre los elementos

de la arquitectura del modelo2.

# OF
TRILLIUM PRACTICES
ROADMAPS BY LEVEL TOTAL
CAPABILITY AREAS
2 3 4 5

Quality Management
Organizational
10 20 5 0 35
Process Quality
Business Process Engineering

Human Resource Human Resource Development and

9 42 1 0 52
Development and Management
Management

Process Definition

Technology Management Process

Process 16 55 24 4 99
Improvement & Engineering

Measurements

Project Management

Subcontractor Management Customer-

Management Supplier Relationship Requirements 74 29 4 0 107
Management

Estimation

Quality Systems Quality System 14 15 2 2 33

Development Process

Development Techniques Internal

Documentation Verification &
Development practices 41 49 15 5 110
ValidationConfiguration Management Re-
Use

Reliability Management

Development
Development Environment 4 6 1 1 12
Environment

Problem Response System

Usability Engineering Life-Cycle Cost

Customer Support Modelling User Documentation Customer 25 30 5 0 60
Engineering

User Training

Total 193 246 57 12 508

Tabla 3.7. Arquitectura del modelo Trillium.

1 Fuente: Recurso público de Trillium, Model Description. Enlace

web: http://www.sqi.gu.edu.au/trillium/t3modc3.html [Leído: 30 de octubre de 2008].
2 Fuente: Recurso público de Trillium, Model Description. Enlace

web: http://www.sqi.gu.edu.au/trillium/t3modc3.html [Leído: 30 de octubre de 2008].

3.4.1.6. Project Management Assessment

El Project Management Assessment (PMA) es una metodología holística
y una herramienta de software para la mejora de procesos de gestión en
un medio ambiente de gestión de proyectos. Se ofrece para dar
soluciones a problemas de inflexibilidad, de tiempo, de "no saber hacer"
y, de falta de una mejora incremental.

En este modelo deben integrarse prácticas genéricas (herramientas,

procedimientos y estándares comunes al ámbito de gestión de proyectos
tomados del PMBOK) y específicas de la propia organización, para lo
cual se cuenta con un software.

El software es un producto orientado a definir y especificar prácticas

genéricas tomadas del PMBOK y otras específicas de cada problema y
unirlas siguiendo el esquema de prácticas que ofrece el mismo PMBOK.

3.4.1.7. Management Maturity Model

El Management Maturity Model (PMM) se orienta a mejorar prácticas de

gestión de proyectos. Es un esfuerzo derivado de considerar la gestión
de proyectos un proceso crítico de la misión organizacional y de
competencia vital a la organización.

El modelo se ha construido a partir de encuestas a organizaciones que

han llevado, obviamente, proyectos, buscando definir las prácticas de
gestión que aplicaban. Según la última información disponible, el modelo
se ha modificado hasta alcanzar unas 300 lecciones sobre gestión de
proyectos en el ámbito corporativo.

Estas prácticas se han organizado en niveles de madurez. De estos

niveles: ad-hoc, abreviado, organizado, gestionado y adaptativo; se
conocen 51 preguntas que permiten saber el nivel de una organización.

3.4.1.8. Innovation Maturity Model

El Innovation Maturity Model (IMM) no es un modelo como tal, sino una

propuesta para el desarrollo de productos. Es una visión sobre cinco
niveles de innovación: superficial (Superficial), mejoras en rasgos
(Feature Enhancements), mejoras en soluciones (Solution
Enhancements), soluciones impactantes (Breakthrough Solutions) y
'rompedora' (disruptive).

3.4.2. Implantación de la madurez

Todos los modelos previos de una u otra manera buscan medir o

alcanzar un determinado nivel de competencia en gestión de proyectos.
Conseguir esta competencia requiere algunas precisiones de mayor
detalle.

Niveles de madurez

En cuanto a detalle, se ha propuesto un modelo de madurez basado

directamente en el PMBOK de ocho niveles de madurez, cuya cantidad
solamente se justifica en la medida de conseguir una competencia
paulatina incremental y más gradual.

A grandes rasgos, tales niveles se caracterizan por lo siguiente:

 Nivel I No conocedor (non-awareness). No existe conocimiento

alguno sobre gestión de proyectos.
 Nivel II Inicial. Se comienzan a introducir prácticas de gestión de
proyectos.
 Nivel III Básico. Comienzan algunas tareas de gestión como
asignación de responsabilidades, documentación, hitos y manejo
formal de información.
 Nivel IV Repetible. Se establecen algunos procesos de gestión y
se formaliza el uso de determinadas herramientas. Ya existe algún
plan de entrenamiento en gestión de proyectos y se llevan algunas
auditorías.
 Nivel V Avanzado. El entrenamiento y, las auditorías o
seguimientos, son totales, igualmente algunos procesos y
herramientas son incorporados en su totalidad.
 Nivel VI Bien-definido. Los niveles de autoridad y experiencia son
completos, el entrenamiento es avanzado y los procesos se
integran introduciendo la documentación y el uso de métricas.
 Nivel VII Gestionado. Se promueven los incentivos, se introduce
la certificación en gestión de proyectos. Se persigue un buen
desempeño y mejorar la eficiencia y efectividad.
 Nivel VIII Optimizante. La mejora es continuada y sostenible.
Lo importante de esta propuesta es el Nivel VIII, al dejar explícito que
alcanzar los niveles de madurez no es un fin en sí mismo, sino un medio
para garantizar una mejora adaptativa y sostenida a lo largo del tiempo.

Implantación

Respecto de la consecución de la competencia, una manera de introducir

técnicas de gestión que satisfagan los niveles de madurez del CMM es
siguiendo ciclos iterativos.

En este sentido, existen mecanismos por medio de los cuales es posible

sensibilizar a los proyectistas en la conveniencia de aprender a mejorar.

Para ello se deberían seguir ciclos de mejora de forma paulatina, por

ejemplo, comenzar con un ciclo inicial donde se presentan las primeras
prácticas de gestión, pasando luego a un ciclo de actualización de
procesos e infraestructura para alcanzar un nivel 2 y así, ejecutar un
tercer ciclo orientado a conseguir el nivel 3 del CMM (figura 3.19).