Capítulo 1.

Administración de Proyectos de TI Metodología Clásica

Definición de Conceptos de Administración de Proyectos Metodología Clásica.

¿Qué es un Proyecto?

Un proyecto es un intento por lograr un objetivo específico mediante un juego único de tareas
interrelacionadas y el uso efectivo de los recursos. Los siguientes son atributos de un proyecto que
ayudan a la definición y entendimiento del mismo [ CITATION Som \l 2058 ]:

 Un proyecto tiene un objetivo bien definido, un resultado o producto esperado. Por lo general
el objetivo de un proyecto se define en términos de alcance, programa y costo.

 Un proyecto se lleva a cabo mediante una serie de tareas interdependientes, es decir, un número
de tareas no repetitivas que es necesario realizar en un cierto orden con el fin de lograr el
objetivo del proyecto.

 Un proyecto utiliza varios recursos para realizar las tareas.

 Un proyecto tiene un marco de tiempo específico, o tiempo limitado.

Todo proyecto crea un producto, servicio o resultado único. Aunque puede haber elementos repetitivos
en algunos entregables del proyecto, esta repetición no altera la unicidad fundamental del trabajo del
proyecto. Por ejemplo, los edificios de oficinas son construidos con materiales idénticos o similares, o
por el mismo equipo, pero cada ubicación es única: con un diseño diferente, en circunstancias
diferentes, por contratistas diferentes, etcétera.

Un esfuerzo de trabajo permanente es por lo general un proceso repetitivo, puesto que sigue los
procedimientos existentes de una organización. En contraposición, debido a la naturaleza única de los
proyectos, puede existir incertidumbre respecto de los productos, servicios o resultados que el proyecto
genera. Las tareas del proyecto pueden ser nuevas para el equipo del proyecto, lo que hace necesario
planificar con mayor dedicación que si se tratara de un trabajo de rutina. Además, los proyectos se
llevan a cabo en todos los niveles de una organización. Un proyecto puede involucrar a una sola
persona, una sola unidad o múltiples unidades dentro de la organización.

Conociendo ahora que es un proyecto nos podemos realizar la siguiente pregunta:

¿Qué es la Gesti ón de Proyectos?

Es la formulación de prácticas, las cuales consisten, en la aplicación de conocimientos, destrezas,

procedimientos, controles, herramientas, y técnicas que permitirán generar un secuencia
ordenada de fases, actividades y tareas, para alcanzar el objetivo definido inicialmente en los
márgenes establecidos [ CITATION PMI \l 2058 ].
Actualmente existen diversas prácticas para gestionar los proyectos, pero no se tiene claro que
metodología es conveniente usar o cual es la mejor para administrar proyectos de TI.
Con la definición anterior sabemos que requerimos de ciertos requerimientos para poder gestionar un
proyecto y así finalizar lo mejor posible un proyecto y alcanzar los objetivos planteados, pero a lo
anterior nos queda por responder la siguiente pregunta:

¿Por qué es necesario Gesti onar Proyectos?

La aplicación de la administración de proyectos en una empresa es de gran importancia y se usa en

diferentes áreas de conocimiento, las cuales pueden ir desde la construcción de una nave espacial,
construcción de sistemas computacionales, edificación de algún inmueble, o simplemente para
administrar un proyecto de vida.

Existen varios beneficios, por los cuales es conveniente tener una cultura para la gestión de proyectos
en una empresa, a continuación se darán diez razones, que mostrarán los beneficios de usar una
metodología para la gestión de proyectos.

1. Posibilita respuesta rápida a demandas cambiantes: Proporciona la capacidad para adaptarse a

los cambios y manejar de la mejor manera dichos cambios.

2. Optimiza la capacidad de la organización (costos, tiempos, alcance): Consigue más con menor
costo. La gestión de proyectos identifica todas las responsabilidades funcionales de cara al
cumplimiento de la misión de la empresa, asegurándose que todos los miembros de la
organización conocen su responsabilidad. Así mismo, identifica las posibles mejoras en los
procesos, proporcionando ahorros en tiempos y costos.

3. Coordina los diferentes recursos internos y externos. En muchas ocasiones, un mismo

proveedor tiene contacto con diferentes áreas de la empresa y no se aprovechan las sinergias
que esto puede proporcionar.

4. Aporta una visión de conjunto y mejora la comunicación en la empresa. Permite transferir

conocimientos entre departamentos que, de otra forma, actuarían de forma estanca. Fija
objetivos globales más allá de las visiones particulares de cada grupo, departamento o área.
Maneja presupuestos generales y costes de toda la organización. Permite marcar prioridades
dentro de las distintas acciones pendientes.

5. Permite aprender de las lecciones pasadas. Mediante una correcta Gestión de Proyectos se crea
un “know how” (saber cómo) en la empresa que permite usar esa experiencia para la
planificación y realización de proyectos futuros.

6. Aporta una correcta percepción sobre la auténtica capacidad del equipo, ya que maximiza las
sinergias entre los distintos miembros, es decir, podemos determinar las limitaciones y virtudes
del equipo de trabajo para así concretar el objetivo del proyecto dela mejor forma o prever
riesgos oportunamente y evitar así problemas futuros.
7. Permite identificar los riesgos y problemas en fase temprana, permitiendo que se diseñen
acciones correctivas a tiempo para no perjudicar la ejecución del proyecto y / o aprovechar las
oportunidades cuando se presenten y estas sean un beneficio extra al proyecto.
 8. Aporta una visión centrada en el cliente, ya que el Jefe de Proyecto es, generalmente, el
interlocutor único del cliente y defiende los intereses del mismo dentro de la organización

9. Proporciona información a la Gerencia y reduce la necesidad de que todos los miembros del
equipo estén realizando informes constantemente, ya que se centraliza la información en el Jefe
de Proyecto, esto hace permite que solo haya un solo canal de comunicación, lo cual evita estar
triangulando información y se pierda la comunicación efectiva que permitirá realizar las
actividades correctas.

10. Asegura la calidad, ya que permite proporcionar al cliente un resultado acorde con los requisitos
y con adecuación al uso.

¿Quién lo hace?

Toda la gente gestionamos de algún modo, pero el ámbito de las actividades de gestión varía en función
de la persona que las realiza, por ejemplo un ingeniero de software (miembro de equipo) gestiona sus
tareas diarias que tiene asignadas, planificando, supervisando y controlando estas.

Los administradores de proyecto comúnmente nombrados líderes de proyecto, plantifican, supervisan y

controlan el trabajo en equipo, etc.

Con esta introducción podremos continuar con los capítulos donde se detallará la gestión de proyectos
para TI, y las técnicas usando PMI e PRINCE2, para posteriormente realizar un análisis de ambas para
determinar cuál de estas es conveniente usar para facilitar y mejorar la gestión de proyectos, y
finalmente se mostrará un caso práctico usando herramientas de software de Microsoft para ayudar a la
gestión de proyectos usando las practicas del PMBOK.

Iniciaremos con una frase que cita Meiler Page Jones en el prefacio de su libro sobre gestión de
proyectos de software.

He visitado docenas de empresas, buenas y malas, y he observado a muchos administradores de

proceso de datos, también buenos y malos. Frecuentemente, he visto con horror cómo estos
administradores luchaban inútilmente contra proyectos de pesadilla, sufriendo por fechas límite
imposibles de cumplir, o que entregaban sistemas que decepcionaban a sus usuarios y que devoraban
ingentes cantidades de horas de mantenimiento [ CITATION PCl99 \l 2058 ].

Lo que describe Page-Jones son síntomas que resultan de una serie de problemas técnicos y de gestión.
Sin embargo, si se hiciera una autopsia de cada proyecto, es muy probable que se encontrará un común
denominador constante: una débil gestión.

Actualmente la mayoría de las empresas cuentan con un área de TI, las cuales dan soporte a los
usuarios por medio de sistemas computacionales genéricos y / o sistemas desarrollados a la medida
para satisfacer sus necesidades, muchas de las veces estas áreas de TI no cuentan con las mejores
prácticas para desarrollar y / o administrar estos sistemas, o hasta son desconocidas, por lo anterior
estos se ven afectados, dando al usuario final un resultado negativo, ya sea porque no se entregó a
tiempo o en el peor de los casos no se entregó lo que el usuario necesitaba.
Adicionalmente las áreas de TI, pasaron de ser una área opcional en las empresas a ser un área
necesaria para poder continuar con las labores del día a día de las compañías, actualmente estas áreas
reciben o también generan infinidad de iniciativas, las cuales muy probablemente se deban llevar
acabo, como pueden ser los siguientes casos:

 Desarrollar un producto o servicio.

 Implementar un proceso para control de gestión de TI: atención a usuarios.
 Adquisición, instalación y puesta en marcha de componentes tecnológicos.
 Supervisar la implementación de un producto o servicio adquirido.
 Implementar un aplicativo en una unidad de negocio.

A todas estas iniciativas cuando se empiezan a ejecutar se convierten en PROYECTOS, a los cuales se
les asigna un presupuesto, recursos, tiempo y esfuerzo, para que puedan finalizarlo de la mejor manera
y llegar al objetivo planteado inicialmente.

Independientemente de lo anterior muchas de las veces estos proyectos fracasan debido a diferentes
circunstancias como pueden suele ser el tamaño del proyecto (medido en dinero), tiempo, recursos
humanos, experiencia del personal en gestión de proyectos y tecnologías usadas (curva de aprendizaje),
definición incorrecta o incompleta de los objetivos y / o especificaciones del sistema.
La administración de proyectos de TI, es necesaria debido a que los proyectos de esta índole siempre
están sujetos a restricciones organizacionales como tiempo y presupuesto principalmente y por estas
razones la administración de proyectos es necesaria para que los objetivos planteados se cumplan con
dichas restricciones.

La gestión de proyectos de TI son particularmente diferentes a los de otras áreas, estas particularidades
marcan una diferenciación que los hace más complicados de gestionar, algunas de las diferencias son
las siguientes:

1. El producto es intangible: Un administrador de proyectos de construcciones civiles puede ver el

desarrollo de la obra y determinar más fácilmente el avance del proyecto, para el caso de un
gestor de proyectos de TI, es prácticamente imposible que ocurra lo mismo, la mayoría de las
veces los proyectos de TI, son intangibles (no se pueden ver o tocar), por lo que la
administración del mismo se complica y deberá de confiar en el equipo de trabajo para revisar
el progreso del proyecto.

2. No existen procesos estándar, Existen una enorme cantidad de compañías y estas a su vez
utilizan diferentes procesos para desarrollar proyectos de software, esto a pesar de que se ha
avanzado en la comprensión del proceso de desarrollo de software, aun no se puede predecir
con certeza cuando un proceso en particular puede desarrollar problemas, esto principalmente
cuando un proyecto de desarrollo de software es grande.

3. A menudo los proyectos grandes son únicos, Por lo general los proyectos grandes de desarrollo
de software son diferentes de proyectos previos, por esta razón, la gestión del proyecto aunque
en exista una amplia experiencia en el equipo de trabajo, esta no es suficiente para anticipar y
solucionar los problemas. Más aun los cambios tecnológicos en las computadoras y
comunicaciones hacen más fácil que la experiencia previa sea obsoleta. Las lecciones
aprendidas en esas experiencias pueden no ser transferibles a los nuevos proyectos.

Debido a estos problemas, no es sorprendente que algunos proyectos de TI se retrasen, o sobrepasen el

presupuesto y se entreguen fuera de tiempo. A menudo, los proyectos de TI son nuevos y
tecnológicamente innovadores, aun así es sorprendente ver que muchos proyectos de TI se entregan en
tiempo y forma.

Las principales actividades para la gestión de un proyecto de TI pueden generalizarse principalmente

en las siguientes tareas:

I. Planificación
II. Calendarización
III. Gestión del personal
IV. Gestión de riesgos
V. Estimación de costos
VI. Gestión de la calidad

Gestión de Proyectos Metodología Clásica

Planifi cación del Proyecto.

La administración correcta de un proyecto de TI, depende de planificar completamente el progreso del
proyecto, una actividad muy importante a considerar en esta planeación es la de considerar el peor
escenario es decir, prever los posibles problemas que puedan surgir, así como preparar las soluciones a
estos problemas.

Este plan inicia de proyecto debe ser lo mejor posible con la información inicial discernible, este plan
evolucionará conforme el proyecto avance y se cuente con mayor información.

En un excelente documento sobre proyectos de software, John Reel [REE99] [ CITATION Som \l
2058 ], define diez señales que indican que un proyecto de sistemas de información está en peligro.

1. La gente del software no comprende las necesidades de cliente

2. El ámbito del producto está definido pobremente.
3. Los cambios están mal realizados.
4. La tecnología elegida cambia.
5. Las necesidades del negocio cambian o están mal definición
6. Las fechas de entrega no son realistas.
7. Los usuarios se resisten al cambio.
8. Se pierden los patrocinadores o nunca se obtuvieron adecuadamente.
9. El equipo del proyecto carece del personal con las habilidades apropiadas.
10. Los administradores y los desarrolladores evitan buenas prácticas y sabias lecciones.

Estos pueden evitarse si se lleva a cabo una planificación entre otros puntos, a continuación se muestra
un ejemplo de un pseudocódigo para la planificación de un proyecto.

Establecer las restricciones del proyecto.

Hacer la valoración inicial de los parámetros del proyecto.
Definir los hitos del proyecto y productos a entregar.
Mientras el proyecto no se haya completado o cancelado, repetir
Planificar la programación en el tiempo del proyecto.
Iniciar actividades conforme con la programación.
Esperar por un momento
Revisar el avance del proyecto.
Revisar las estimaciones de los parámetros del proyecto.
Actualizar la programación del proyecto.
Renegociar las restricciones del proyecto y los productos a entregar.
Si surgen problemas entonces
Iniciar la revisión técnica y la posible revisión
Fin de Si
Fin de repetir

Con lo anterior se muestra que la planificación es un proceso iterativo, que solamente termina cuando
se finaliza o cancela el proyecto. A su vez mientras la información se hace disponible, el plan debe irse
revisando regularmente, cuando las metas del proyecto cambian se deberán realizar los cambios
pertinentes al plan de proyecto.

El proceso de planificación se inicia con una valoración de las restricciones que afectaran al proyecto
(fecha de entrega, personal disponible, presupuesto, etc.), posteriormente se lleva a cabo una
estimación de los parámetros del proyecto como son es su estructura, tamaño y distribución de
funciones, para continuar con la determinación de los HITOS de progreso y productos a entregar.

Con este conjunto de actividades el proceso entra en un ciclo, y se podrá preparar un calendario con las
fechas de inicio y termino de las actividades del proyecto, después de un tiempo se revisa el avance del
proyecto y se señalan los desfases en las tareas.

Como las estimaciones de la duración de la tarea casi siempre son aproximaciones a la reales se debe
de ir actualizando el plan de proyecto.

En dado caso que el proyecto se retrase, la mejor práctica es renegociar con el cliente las restricciones y
entregas del mismo, en dado caso que el cliente no acepte esta negociación, se deberá tener una
revisión técnica para encontrar ajuste alternativo, que se adapte a restricciones del proyecto y cumpla
con las metas del calendario.

Plan de Proyecto.

En el plan de proyecto se fijan los recursos, se divide el proyecto y se crea el calendario de trabajo, con
la finalidad de servir como ayuda para el monitorear el avance del proyecto.

El contenido del plan de proyecto varía dependiendo cada organización, pero la mayor parte de los
planes de proyecto incluyen las siguientes secciones:

1. Introducción:
Describe brevemente los objetivos del proyecto y expone las restricciones (Tiempo, costo, etc.) que
afectaran al proyecto.
2. Organización del proyecto:
Describe la forma en que el equipo de trabajo está organizado, con sus roles y responsabilidades.
3. Análisis de riesgo:
Se describirán los riesgos del proyecto, la probabilidad de que surjan otros riesgos, y las estrategias de
mitigación de los mismos
4. Requerimientos de Hardware y Software.
Se describe los elementos computacionales a usarse en el proyecto, tanto como en hardware y software,
en caso de tenerse que comprar nuevos elementos se deberá incluir los costos de los mismos.
5. División del trabajo.
Se detalla cada una de las actividades a realizar en el proyecto, se identifican los hitos y los productos a
entregar
6. Programa del proyecto.
Describe las dependencias entre tareas, el tiempo estimado para alcanzar cada hito y la asignación de la
gente a cada actividad.
7. Mecanismos de supervisión e informe.
Describe la gestión de informes y cada cuando deben realizarse, así como los mecanismos de
supervisión a utilizar en el proyecto.

¿Qué es un Hito?
Un hito, es la representación de la finalización de un conjunto de actividad y estos no tienen duración.
Estos pueden ser informes concretos, documentos como memorias técnicas de instalación, entrega de
hardware, etc., como se menciona anteriormente son representación de un conjunto de actividades
finalizadas [CITATION Ben06 \l 2058 ].
Un entregable es el resultado del proyecto que se entrega al cliente, estos se entregan al final de una
fase principal, como podrían ser la especificación, el diseño, el objeto del programa, etc. [CITATION
Ben06 \l 2058 ]

Ilustración 1: Hitos de Actividades

Como regla general los entregables son Hitos, pero no necesariamente los Hitos son entregables
[CITATION Ben06 \l 2058 ].

Gesti ón del Tiempo “Calendarización”

Esta es una de la tareas de gestión de proyectos más difíciles que hay, en esta parte se deben determinar
los tiempos, recursos y costos que se van a necesitar, para realizar correctamente (tiempo, costo,
alcance) el proyecto, organizando las actividades en una sucesión coherente.
La complicación se deriva a que los proyectos pueden tener diferentes métodos de diseño o
construcción en diferentes lenguajes.
La Calendarización del proyecto implica separar todo el trabajo de un proyecto, en actividades
complementarias y considerar el tiempo de realización, adicionalmente se deben estimar los recursos
que se utilizaran en cada actividad, como pueden ser servidores, recursos humanos, presupuesto,
Una buena práctica es estimar como si todo fuera a salir bien y entonces incrementar la estimación para
abarcar los problemas previstos, regla general es agregar un factor de contingencia (holgura), este
factor de contingencia varía dependiendo el tipo de proyecto, de los parámetros de proyecto (fecha de
entrega, estándares, etc.) anteriormente mencionados, y de la calidad y experiencia del equipo de
trabajo, por lo general para problemas previstos debe agregarse un 30% a la estimación original y otro
20% para situaciones no previstas [CITATION Ben06 \l 2058 ].
Por lo general el calendario de proyecto, va acompañado de gráficos, que muestran la división del
trabajo, las dependencias entre actividades y la asignación del personal, una herramienta muy útil para
facilitar esto es MS Project [CITATION Ben06 \l 2058 ].
 Gesti ón de Recursos Humanos.

La asignación de recursos a la calendarización del proyecto es otra actividad que se debe de realizar,
esta actividad consiste en asignar a una tarea, la persona quien realizara dicho actividad, de acuerdo a
su especialización, Las personas no deben estar asignadas al proyecto en todo momento, en diferentes
momentos puede estar de vacaciones, en otro proyecto, en cursos o realizando otras actividades.
 Ilustración 1: Asignación de Personal – Tarea – Tiempo.

Por lo general las grandes organizaciones, utilizan diferentes especialistas para la realización del
proyecto en diferentes etapas del proyecto o simultáneamente dependiendo de las características del
proyecto, es por ello se debe de gestionar cuando, como y donde deberán emplearse dichos recursos.

Gesti ón de Riesgos.

Una de las tareas más importantes en la administración de proyectos es la de anticipar los riesgos que
podrían afectar a la programación y / o ejecución del proyecto él y con esto emprender acciones para
evitar esos riesgos. Los resultados de este análisis de riesgos se deben de documentar a lo largo del plan
de proyecto junto con el análisis de las consecuencias cuando el riesgo se materialice es decir cuando
el riesgo ocurra. La identificación y la creación de los planes para minimizar sus efectos en el proyecto
se llaman gestión de riesgos (Hall, 1998, Ould 1999) [CITATION Ben06 \l 2058 ].
De forma simple se puede concebir un riesgo como una probabilidad de que una circunstancia adversa
al proyecto ocurra. Los riesgos son una amenaza para el proyecto, para el producto que se está
desarrollando y para la organización, estas categorías de riesgos se muestran a continuación.
1. Riesgos del proyecto: Son aquellos que afectan a la programación del proyecto o de los recursos
del proyecto, por ejemplo, la pérdida de un diseñador experto.
2. Riesgos del producto: Este tipo de riesgos, afectan a la calidad o al rendimiento del producto
que se está desarrollando, por ejemplo los servidores adquiridos funcionan con menor
desempeño al esperado.
3. Riesgos de Negocio: Estos afectan a la organización que desarrolla o suministra los
componentes del producto, un riesgo de este tipo podría ser que salga una nueva versión de
software.
Por supuesto que estos riesgos no son exclusivos entre sí, por ejemplo si un desarrollador experto sale
del proyecto, esto es un riesgo para el proyecto debido a que esto puede afectar en la entrega del
proyecto a tiempo, es un riesgo del producto debido a que el sustituto no puede ser tan experto y esto
ocasione varios errores, y riesgo para el negocio, que debido a esta experiencia pueda contribuir a que
el cliente no quiera volver hacer negocios futuros, con su proveedor.
Los riesgos que pueden afectar al proyecto dependen del propio proyecto y del entorno de la
organización donde el proyecto se realiza. A pesar de esto, existen muchos riegos genéricos o
universales, algunos de estos riesgos pueden ser los que se muestran en la tabla siguiente.

Riesgo Tipo Ejemplo

Rotación de Personal
Cambio de Gestión
No disponibilidad del Hardware
Cambio de requerimientos
Retraso en la especificación
Subestimación del tamaño
Bajo desempeño de la herramienta
CASE
Cambio de tecnología
Competencia del producto
Proyecto Personal de experiencia abandone del
proyecto antes que finalice.
Proyecto Habrá un cambio de gestión
organizacional con diferentes
prioridades.
Proyecto El hardware esencial para el proyecto no
será entregado a tiempo.
Proyecto y producto Habrá más cambios en los
requerimientos de lo esperado.
Proyecto y producto La definición de las interfaces no estará
a tiempo.
Proyecto y producto El tamaño del sistema se subestimo.
Producto Las herramientas CASE que ayudan al
proyecto no tienen el rendimiento
esperado.
Negocio Un producto competitivo se pone en
venta antes de que el sistema se
complete.
Negocio La tecnología fundamental sobre la que
se construirá el sistema se sustituye por
una nueva tecnología.

Tabla 1: Riesgos Genéricos y Universales

La gestión de riesgos es muy importante particularmente para proyectos de Tecnologías de la

información debido a las incertidumbres inherentes con las que se enfrentan muchos proyectos, estas
incertidumbres son el resultado de los requerimientos ambiguamente definidos, las dificultades en la
estimación de tiempos y de recursos, los cambios en las necesidades del cliente.
Por lo anterior es necesario anticiparse a los riesgos: comprender el impacto de estos en el proyecto, en
el producto y en el negocio, considerando los pasos para evitarlos.
En el peor de los casos, es decir que los riesgos ocurran, se deben de crear planes de contingencia para
que sea posible aplicar acciones de recuperación.
La siguiente imagen muestra un proceso para la detección de riesgos [CITATION Ben06 \l 2058 ].
Este proceso de identificación de riesgos contiene varias etapas:

1. Identificación de riesgos: Identificar los posibles riesgos para el proyecto, el producto y el

negocio.
2. Análisis de riesgos: Valorar las probabilidades y consecuencias de los riesgos.
3. Planificación de riesgos: Crear planes para abordar los riesgos, ya sea para evitarlos o
minimizar sus efectos en el proyecto.
4. Supervisión de riesgos: Valorar los riesgos de forma constante y revisar los planes para la
mitigación de riesgos tan pronto como la información de los riesgos esté disponible.

Los resultados de identificación de riesgos se deben de documentar en un plan de gestión de riesgos.

Este debe incluir un estudio de los riesgos a los que se enfrenta el proyecto, si es necesario se pueden
incluir algunos resultados de la gestión de riesgos, por ejemplo planes específicos de contingencia que
se activan si se presentan los riesgos.

Identi fi cación de Riesgos.

Esta es la primera etapa de la gestión de riesgos, comprende el descubrimiento de los posibles riesgos
del proyecto. En principio no hay que valorarlos o darles prioridad en esta etapa, aunque en la práctica,
por lo general no se consideran los riesgos con mínimo impacto o con baja prioridad.
Esta identificación se puede llevar a cabo a través de un proceso de grupo denominado “Lluvia de
Ideas” o simplemente basándose en la experiencia, para ayudar al proceso, se utiliza una lista de
posibles tipos de riesgos, hay al menos seis tipos de riesgos que pueden aparecer, los cuales se en listan
en la tabla siguiente:
 Tipo Riesgo Descripción
Riesgos de tecnología Se derivan de las tecnologías de software o de hardware
utilizadas en el sistema que se está desarrollando.
Riesgos de Personal Riesgos asociados con las personas del equipo de trabajo.
Riesgos organizacionales Se derivan del entorno organizacional donde el software se
está desarrollando.
Riesgos de herramientas Se derivan de las herramientas CASE y de otro software de
apoyo utilizado para desarrollas el sistema.
Riesgos de requerimientos Se derivan de los cambios de los requerimientos del cliente y
el proceso de gestionar dicho cambio.
Riesgos de estimación Se derivan de las estimaciones administrativas de las
características del sistema y los recursos requeridos para el
desarrollo del proyecto.

Tabla 1: Tipo de Riegos

El resultado de este proceso es una larga lista de riesgos que podrían presentarse y afectar el producto,
el proceso y en negocio.
Análisis de Riesgos

Durante este proceso se considera por separado cada riesgo identificado y se describe acerca de la
probabilidad de que ocurra y la seriedad del mismo. No existe una forma sencilla de realizar esto, recae
más bien en la opinión y experiencia del líder de proyecto, no se hace una valoración con números
precisos sino en intervalos [ CITATION PCl99 \l 2058 ].
 La probabilidad del riesgo se puede valorar como muy bajo (<10%), bajo (10 – 25%),
moderado (25 – 50%), alto (50 – 75%) o muy alto (>75%).
 Los efectos del riesgo “Impacto”, pueden ser valorados como Catastróficos, critico, tolerable, o
insignificante.
Categoría de Impacto Ponderación Descripción
Catastróficos 1 Riesgo con más alta afectación al
proyecto
Critico 2 Riesgo con alta afectación al proyecto

Tolerable 3 Riesgo que se puede permitir que ocurra

con baja afectación al proyecto.
Insignificante 4 Riesgo con mínima o casi nula
afectación al proyecto.

Tabla 1: Tabla Impacto de Riesgo

El resultado de este proceso de análisis se debe de incluir en una tabla, la cual debe estar organizada
según la seriedad del riesgo.
En la práctica la valoración de la probabilidad del riesgo, se necesita información detallada del
proyecto, el proceso, el equipo de desarrollo y la organización [ CITATION PCl99 \l 2058 ].
El proceso para la determinación de la probabilidad de un riesgo se puede realizar por medio de una
tabla llamada Tabla de Riesgo, este proceso consiste en que el equipo de proyecto empieza por listar
todos los riesgos (no importa lo remotos que sean) en la primera columna de la tabla. Cada riesgo es
categorizado en la segunda columna (por ejemplo: PS implica un riesgo del tamaño del proyecto, BU
implica un riesgo de negocio).

Ilustración 1: Tabla de Riesgo

La probabilidad de aparición de cada riesgo se introduce en la siguiente columna de la tabla. El valor

de la probabilidad de cada riesgo puede estimarse por cada miembro del equipo individualmente. Se
sondea a los miembros del equipo individualmente de un modo rotativo (round-robin) hasta que
comience a converger su evaluación sobre la probabilidad del riesgo.
Una vez estimadas estas columnas de la tabla de Riesgo, la tabla es ordenada por su probabilidad y su
impacto, con esto se logra la priorización de primer orden de los riesgos dejando los de mayor
probabilidad e impacto hasta arriba.

La atención que se le debe de dar a los riesgos resultantes de la tabla ya priorizados se debe de realizar
en base a la llamada “La línea de Corte”, esta línea de corte se representa en el eje horizontal X de una
gráfica de tres dimensiones donde el eje de vertical Y corresponde al impacto y finalmente el eje Z es
representada por la probabilidad, como se muestra en la figura siguiente.
Donde los riesgos que caigan en la parte superior de la línea de corte “X”, son los que se les deberá
prestar mayor atención y los que caigan por debajo de esta línea, deberán se revaluados en una segunda
priorización [ CITATION PCl99 \l 2058 ].

Este proceso es dinamismo y se debe de estar revisando y actualizando constantemente, ya que la

probabilidad y el impacto van cambiando durante el avance del tiempo y del proyecto.

Planifi cación de Riesgos.

El proceso para la planificación de riesgos considera cada uno de los riesgos clave que han sido
identificados es decir los de mayor probabilidad e impacto, así como las estrategias para gestionarlos.
Nuevamente no existe un proceso sencillo que nos permita establecer los planes de gestión de los
mismos. Mucho depende de la experiencia y del juicio del gestor de proyectos, existen unas estrategias
genéricas que se dividen en tres categorías esencialmente.

1. Estrategias de prevención: Siguiendo estas estrategias, la probabilidad de que el riesgo aparezca

se reduce.
2. Estrategias de minimización: Con estas se reduciría el impacto del riesgo
3. Planes de contingencia: Siguiendo estas estrategias es estar preparado para lo peor y tener una
estrategia para cada caso.
Puede verse una analogía con las estrategias utilizadas en sistemas críticos para asegurar la fiabilidad,
protección y seguridad. Básicamente es mejor utilizar una estrategia para evitar el riesgo, si esto no es
posible, utilizar una estrategia para minimizar los efectos serios de los riesgos, y finalmente tener
estrategias para reducir el impacto del riesgo en el proyecto y en el producto.

Supervisión de Riesgos.

Todas las actividades de análisis de riesgo presentadas hasta ahora tienen un solo objetivo - ayudar al
equipo del proyecto a desarrollar una estrategia para tratar los riesgos.

A medida que progresa el proyecto, comienzan las actividades de supervisión del riesgo. El jefe del
proyecto supervisa los factores que puedan proporcionar una señal sobre si el riesgo se está haciendo
más o menos probable.

Además de supervisar los factores apuntados anteriormente, el jefe del proyecto debería supervisar
también la efectividad de los pasos de reducción del riesgo, es decir deberá asegurarse de cada una de
las acciones planteadas en las estrategias de planificación de riesgos hayan sido ejecutadas
correctamente [ CITATION PCl99 \l 2058 ].

Gesti ón de Costos.

En secciones anteriores se introdujo el proceso de la planificación de proyectos, durante este proceso,

el proyecto se divide en varias actividades que se llevan a cabo en paralelo o de forma secuencial. El
análisis previo sobre la planificación de proyectos se centró en la forma de cómo organizar las
actividades, su dependencia y la asignación del personal, para realizar estas tareas.
En esta sección se volverá al problema de las estimaciones asociadas al esfuerzo y al tiempo de las
tareas del proyecto, a lo cual debemos realizar las siguientes preguntas:

1. ¿Cuándo esfuerzo se requiere para finalizar una tarea?

2. ¿Cuánto tiempo de calendario se necesita para finaliza una tarea?
3. ¿Cuál es el costo total de la actividad a realizar?

Desde las primeras etapas del proyecto se requieren hacer algunas estimaciones básicas de los costos
del proyecto, antes de que se haga la planeación detallada del proyecto.
Existen tres parámetros involucrados en el cálculo del costo total de proyectos de TI.
 Los costos de hardware y software, incluyendo mantenimiento.
 Los costos de viaje y capacitación.
 Los costos de esfuerzo (los costos correspondientes al pago de los integrantes del equipo de
trabajo)
Para muchos los costos dominantes son los costos de esfuerzo, los costos de hardware son
relativamente baratos, aunque los costos por viajes si es que el proyecto se realiza en sitios diferentes
son una pequeña parte comparados a los costos de esfuerzo. Adicionalmente el uso de tecnologías
pueden reducir los costos de viaje y capacitación como son el uso del correo electrónico,
videoconferencias, sitios web compartidos, e-learning, etc.

Algo que se debe de tomar en consideración cuando se estiman los costos de esfuerzo, es que estos no
solamente implican los costos totales de los pagos de equipo de trabajo del proyecto, sino también
incluyen los costos administrativos para hacer funcionar la organización, dividiendo este entre el
número de personas productivas.

Por lo anterior los costos siguientes, son parte de los costos totales de esfuerzo:

1. Costos para proveer, aclimatar e iluminar las oficinas.

2. Los costos del personal de apoyo como administrativos, secretarias, personal de limpieza y
técnicos.
3. Los costos de redes y comunicaciones.
4. Los costos de los recursos centralizados.
5. Los costos de seguridad social, pensiones y seguros privados, etc.

Este factor de sobrecarga por los conceptos anteriores es aproximadamente el doble del costo del
salario de un ingeniero de software, dependiendo del tamaño de la organización. Por lo tanto si aún
ingeniero se le pagan $90,000.00 dólares al año, el costo total de la organización será de $180,000.00
dólares o $15,000.00 dólares por mes, $750.00 por día laboral y finalmente $93.75 dólares por hora
laboral [CITATION Ben06 \l 2058 ].

Independientemente de lo anterior Marie Scotto advierte que en ocasiones los proyectos fracasan
debido a la deficiencia en las técnicas de elaboración de los presupuestos y el control de los costos del
proyecto que conducen a problemas como productos de mala calidad, grupos de trabajo desmotivamos
y caos en los costos del proyecto.

Para prevenir esto, se puede calcular exitosamente los costos del proyecto y Scotto sugiere el procesos
siguiente [ CITATION Som \l 2058 ].
 Entender claramente lo que quiere el cliente.
 Identificar todo el trabajo que se tendrá que realizar.
 Identificar al personal disponible para hacer el trabajo.
 Intentar identificar todos los riesgos posibles.
 Hacer que cada persona le proporcione su mejor estimación del tiempo y los recursos que
necesitará.
 Intentar prever cualquier problema que pudiera interrumpir el proyecto una vez que se haya
iniciado.
 Calcular y publicar las metas de tiempo y costo del proyecto.
Para administrar realmente los costos efectivamente, debe existir una firme supervisión de todo el
dinero que se gaste en el proyecto y una comparación firme de ese importe con la cantidad de trabajo
producido.

Scotto añade que el gerente de proyecto responsabilice a quienes preparen las estimaciones de ajustar
continuamente sus cálculos, que los miembros de equipo informen sus horas reales empleadas en el
proyecto y que los gerentes de proyecto establezcan un método estándar de análisis para identificar
problemas y que permitan una mejora continua.

Cuando se inicial el proyecto es necesario establecer una línea base para los costos, además que será
necesario preparar un presupuesto o plan de cómo y cuándo se gastarán los fondos. Una vez que se
inicia el proyecto, es necesario supervisar los costos reales y el desempeño del trabajo para asegurar
que todo se encuentre de acuerdo con el presupuesto.

Para supervisar el desempeño de los costos se deben de revisar los siguientes tres parámetros
relacionados con el costo:
 Cantidad real acumulada y gastada desde el inicio del proyecto.
 Valor devengado y acumulado del trabajo desde el inicio del proyecto.
 Cantidad presupuestada y acumulada que se plantea gastar, sobre la base del programa del
proyecto y desde inicio del mismo.

Con la comparación entre estos tres parámetros se puede evaluar si el proyecto si la utilización de los
costos está dentro del presupuesto y se el valor del trabajo realizado está de acuerdo con la cantidad
real gastada.

Si en algún momento se determina que se está excediendo el presupuesto o si el valor del trabajo
realizado no corresponde al importe real gastado, se tendrá que llevar a cabo una acción correctiva.

Esti mación de Costos.

La planeación del costo se inicia con la propuesta para el proyecto. Los costos se estiman durante el
desarrollo de la propuesta por el proveedor o el equipo del proyecto.
En algunos casos ésta sólo reflejará el costo final, en otros casos el cliente quizá exija una división
detallada de los precios. La sección de costos de una propuesta puede ser una tabla de los gastos
estimados por el proveedor incluyendo principalmente los siguientes elementos.

1. Mano de obra. Estos costos proporciona los costos estimados por los diversas clasificaciones de
las personas de acuerdo a la especialización de cada una que estarán involucrados en el
proyecto, puede incluir las horas y tarifa por hora para cada persona.
 2. Materiales. Se proporciona el costo de los materiales que se necesitan comprar para realizar el
proyecto, como pueden ser licencias, hardware, etc.
3. Subcontratistas o asesores. Cuando los contratistas o los equipos de proyecto no tienen el
conocimiento o los recursos para hacer ciertas tareas dentro del proyecto, como puede ser un
especialista en interfaces.
4. Alquiler de equipo e instalaciones. En ocasiones el contratista quizá necesite algún equipo,
herramientas o instalaciones especiales para realizar alguna o algunas actividades del proyecto.
5. Viajes. Si durante el proyecto se requiere hacer viajes (que no sean viajes locales) es necesario
incluir los costos de transportación, hospedaje y alimentos.

Además el proveedor puede incluir una holgura en los costos sobre algunas contingencias que surjan en
el proyecto.

Los costos estimados deben ser agresivos pero realistas. No deben ser fuertemente "rellenados" para
que incluyan fondos de contingencia para cualquier cosa que pudiera presentarse o salir mal. Ahora
bien, si los precios son extremadamente conservadores, probablemente el costo total estimado para el
proyecto sea más de lo que está dispuesto a pagar el cliente y más caro que el de otros proveedores
competidores. Por otra parte, si los cálculos son exageradamente optimistas y se necesita hacer algún
gasto inesperado, es probable que el contratista pierda dinero (en el caso de un contrato de precio fijo)
o tenga que pasar la vergüenza de ir con el cliente a solicitar fondos adicionales para cubrir excesos de
costos.

Elaboración del Presupuesto del Proyecto.

El proceso de elaborar un presupuesto incluye dos pasos, en primer lugar el costo estimado del
proyecto se asigna a los diversos paquetes de trabajo en la estructura de división de proyecto. Ahora en
segundo lugar el costo para cada paquete de trabajo se distribuye a lo largo de su duración, con el fin de
determinar cuánto del presupuesto se gastó en cualquier momento.

Asignación del Costo Total Presupuestado.

Asignar los costos totales del proyecto para los diversos elementos como mano de obra, materiales y
subcontratistas a los paquetes de trabajo apropiados en la estructura de división del trabajo establecerá
un Costo Total Presupuestado (CTP) para cada uno. Hay dos enfoques para establecer el CTP.
Uno es un enfoque de arriba hacia abajo en el cual los costos totales del proyecto se revisan en relación
al alcance del trabajo para cada paquete de trabajo y se asigna una parte del costo total a cada uno.

El segundo enfoque es la determinación de los costos de abajo hacia arriba, que se basa en una
estimación de los precios para las actividades detalladas relacionadas con cada paquete. Por lo general,
el valor del proyecto se estima cuando se elabora la propuesta para proyecto, pero normalmente no se
preparan en ese momento planes detallados. Sin embargo, al inicio del proyecto se definen las
actividades pormenorizadas y se desarrolla la red del plan, una vez que se han definido las tareas, se
pueden hacer estimaciones del tiempo, recursos y costo para cada una. El CTP para cada paquete de
trabajo será la suma de los costos de todas las actividades que integran ese paquete.

En la siguiente figura se muestra la asignación de costos a paquetes de trabajo individuales en la

estructura de división del trabajo para un proyecto de 600,000.00 dólares, el importe destinado a cada
paquete de trabajo representa el CTP para terminar todas las tareas relacionadas, cuando se suman
todos los costos relacionados a los paquetes de trabajo no deben de exceder el costo total presupuestado
del proyecto.

Ilustración 1: Asignación de Costos a Paquetes de Trabajo

Desarrollo del Costo Presupuestado Acumulado.

Una vez que se ha establecido el costo total presupuestado para cada paquete de trabajo, el segundo
paso en el proceso de elaboración del presupuesto del proyecto, es distribuir cada CTP a lo largo de la
duración de su paquete. Se determina un costo para cada periodo, sobre la base de cuando están
programadas realizarse las actividades que lo integran.

Cuando el CTP de cada paquete se distribuye por periodos, se puede determinar cuánto del
presupuesto se ha gastado en cualquier momento. Esta cantidad se calcula sumando los costos
presupuestados para cada periodo hasta ese momento. Este importe total, conocido como el Costo
Presupuestado Acumulado CPA, es la cantidad que se presupuestó para realizar el trabajo que estaba
programado para llevarse a cabo hasta ese tiempo. El CPA es la línea base que se utilizará para analizar
el desempeño del costo del proyecto.
 Semanas
CTP 1 2 3 4 5 6 7 8 9 10 11 12
Diseñar 24 4 4 8 8
Construir 60 8 8 12 12 10 10
Instalar y 16 8 8
Probar
Total 100 4 4 8 8 8 8 12 12 10 10 8 8
Acumulado 4 8 16 24 32 40 52 64 74 84 92 100

Tabla 1: Costo presupuestado en Miles dólares por periodos Semanales

En la figura anterior se muestra como se distribuye el CTP para cada paquete de trabajo a lo largo de
los periodos sobre la base de las duraciones estimadas, también se muestra el costo presupuestado,
periodo por periodo, para todo el proyecto, así como su CPA, la figura señala que se presupuestaron
32,000 dólares para realizar en trabajo que debía realizarse en la semana 5, los periodos de tiempo en
los que se distribuye los costos presupuestados se determinan por los tiempos de inicio y finalización
más tempranos a las actividades en el programa de línea base del proyecto.

Conociendo los valores del CTA, es posible dibujar una curva del costo presupuestado acumulado para
mostrar los gastos presupuestados a lo largo de la duración del proyecto. La siguiente figura muestran
el costo presupuestado acumulado para el proyecto total, si se desea se pueden hacer tablas y curvas
acumuladas similares para cada paquete de trabajo.

El CPA de todo el proyecto o para cada paquete de trabajo proporciona una línea base contra la que se
pueden comparar el costo real y el desempeño del trabajo en cualquier momento del proyecto. Seria
engañoso solo comparar los costos reales gastados contra el costo total presupuestado para el proyecto
o para el paquete de trabajo, puesto que el desempeño del costo siempre se verá bien en tanto que los
costos reales estén por debajo del CTP, por ejemplo tomando los datos de las figuras anteriores,
pensaríamos que el valor del proyecto está bajo control siempre y cuando el costo real fuera inferior al
100,000, pero, ¿Qué ocurre cuando un día el costo real excede al CTP y el trabajo aún no ha
terminado?, probablemente sería demasiado tarde para controlar el proyecto, de modo que se termine
dentro del presupuesto ¡Se ha excedido el presupuesto del proyecto y queda trabajo por hacer!, ¡Por lo
tanto se tiene que incurrir en más costos para terminar el proyecto!.

Para evitar estas pesadillas, es importante usar el costo presupuestado acumulado, en lugar del total
presupuestado, como la norma contra la cual se compara el costo real. De esta forma, si el costo real
comienza a exceder al CPA, se puede llevar a cabo la acción correctiva antes de que sea demasiado
tarde.
Determinación del Costo Total.
Una vez iniciado el proyecto es necesario dar seguimiento al costo real y el comprometido para poder
compararlos con el CPA.

Costo Real.

Para mantener el seguimiento del costo real de un proyecto, es necesario establecer un sistema para
recopilar. Sobre una base periódica y oportuna, información sobre los fondos realmente gastados. Este
sistema puede incluir procedimientos y formas para recopilar información. Se debe establecer una
estructura contable sobre la base del sistema de numeración de la estructura de división del trabajo para
que se pueda cargar al paquete de trabajo apropiado cada partida del costo real. Después se puede
totalizar el costo real de cada paquete y compararlo con su CPA.

Con frecuencia se usan hojas de tiempos semanales para recopilar los costos reales de la mano de obra.
Las personas que trabajan en el proyecto señalan los números de los paquetes en los que trabajaron y la
cantidad de horas que dedicaron a cada uno. Después se multiplican estas horas por la tarifa del costo
por hora de cada persona para determinar el importe del costo real. En compañías que usan una
estructura de organización matricial, los empleados pueden ser asignados a varios proyectos al mismo
tiempo. En estos casos, cada individuo tiene que señalar en la hoja de tiempos el número del proyecto
apropiado, así como el número del paquete de trabajo para asegurar que se carguen al proyecto
apropiado los costos reales de mano de obra. Cuando se reciben facturas por materiales o servicios que
se compraron para utilizarlos en el proyecto, también se tienen que cargar al número del paquete de
trabajo apropiado.

Costo Comprometi do.

En muchos proyectos se gastan grandes cantidades de dinero en materiales o servicios (subcontratistas.

asesores) que se utilizan durante un tiempo más largo que el periodo de presentación de informes del
costo. En este tipo de costos es necesario tratarlos de una forma especial, para que el sistema asigne
periódicamente una parte de su costo total al real en lugar de esperar hasta que se terminen los
materiales o servicios para cargarlos a los costos reales totales.

Los costos comprometidos también se conocen como compromisos o costos afectados. Hay valores
comprometidos cuando se ordena un artículo (material, subcontratista), por lo general mediante un
pedido, aun cuando el pago real se realice en algún momento posterior cuando se haya completado,
entregado y facturado el material o servicio, es decir, por ejemplo cuando se emite el pedido de un
artículo a un proveedor o subcontratista, los fondos para esa orden de compra están comprometidos y
ya no están disponibles para gastarlos en otras actividades.

Este momento se tiene que considerar como cargado, o separado, puesto que se necesitará para pagarle
al proveedor o subcontratista cuando este entregue el material o servicio y se reciba una factura. Por
ejemplo, si emplea a un contratista para que le pinte su casa por 5000 dólares, usted ha comprometido
5000 dólares, aunque quizá no le pague realmente al contratista hasta que esté terminado el trabajo.

Para permitir una comparación verídica del costo real con el total presupuestado, se deben asignar
partes de la cantidad comprometida al costo real, mientras se lleva a cabo el trabajo. En algunos casos
el proveedor o el subcontratista quizá exijan algunos pagos de acuerdo al avance del trabajo, en lugar
de esperar hasta que esté terminado para que se le pague. En estas situaciones, cuando se recibe una
factura del proveedor o del subcontratista para un pago parcial o pago de acuerdo al avance del trabajo,
esa cantidad debe cargarse al costo real, para el paquete de trabajo correspondiente.

Por ejemplo, supongamos que hay un proyecto para desarrollar un sistema computarizado de control de
existencias, y se tiene que subcontratar a un asesor para desarrollar seis módulos del sistema
computacional, por un precio de 12,000 dólares. Según se completa y entrega cada módulo el asesor
presenta una factura por 2000 dólares. Cuando se recibe la factura, los 2000 dólares se deben
considerar como un costo real. Ahora consideremos un escenario diferente, en el que el subcontratista o
proveedor no emite facturas por pagos parciales o de acuerdo con el avance del trabajo, sino que más
bien espera hasta que se haya terminado y entregado todo el trabajo y entonces presenta una factura por
la cantidad total, incluso en este caso se debe destinar periódicamente como un costo real una parte del
importe total comprometido, puesto que el trabajo realmente está siendo realizado.

Valor Devengado.

Piénsese en un proyecto con diez actividades iguales a realizar y todas estas se realizan en un total de
diez días, con un costo presupuestado de 2000 dólares, por lo anterior deducimos que son 200 dólares
por actividad.
Al finalizar el quinto día se determina que se han gastado 1000 dólares, cuando se comparan los gastos
contra el costo presupuestado acumulado de 1000 dólares para cinco días se nota que los gastos reales
van de acuerdo con lo presupuestado.

Ahora, ¿Qué sucedería si al final del quinto día solo se han realizado tres actividades?, Vemos que
esto no va bien, puesto que se gastado la mitad del presupuesto en solo tres de las 10 actividades que es
necesario realizar. Por otra parte ¿qué sucede si al final del quinto día se han realizado seis
actividades?, esto sería excelente ya que se ha gastado la mitad del presupuesto y se han realizado seis
de las diez actividades.

Este ejemplo introduce al concepto del valor devengando del trabajo terminado. El hecho de que sólo
se ha gastado la mitad del presupuesto, no significa por necesidad que se haya realizado la mitad del
trabajo. Si éste no está de acuerdo con el costo real, hay problemas, incluso si el costo real está de
acuerdo con el costo presupuestado acumulado.

El cálculo del valor devengado incluye recopilar información sobre el porcentaje de terminación de
cada paquete de trabajo y después convertir este porcentaje en un importe al multiplicar el CTP del
paquete de trabajo por el porcentaje de terminación.

Por lo general la información sobre el porcentaje de terminación se obtiene en cada periodo de la

persona responsable del paquete de trabajo. En muchos casos el estimado es subjetivo. Es en extremo
importante que quien presenta el porcentaje estimado de terminación haga una evaluación honesta del
trabajo realizado con relación a todo el alcance del trabajo para el paquete.

Gesti ón de la Calidad.

La Calidad del Software se ha mejorado significativamente, una de las razones ha sido que las
compañías han adoptado nuevas tecnologías y técnicas, no obstante ha habido una mayor conciencia de
la importancia de la gestión de la calidad y de la adopción de técnicas de gestión de la calidad para el
desarrollo de la industria de Tecnologías de la información.

La calidad en TI, es un concepto complejo que no es directamente comparable con la calidad de la

manufactura de productos. En la manufacturación, la noción de la calidad viene dada por la similitud
entre el producto terminado con la de la especificación (Crosby, 1979). En el mejor de los casos, esta
definición debería aplicarse a todos los productos, pero, para tecnologías de la información existen
algunos problemas:

1. La especificación se orienta hacia las características del producto que el consumidor quiere. Sin
embargo, la organización desarrolladora también tiene requerimientos (como los de
mantenimiento) que no se incluyen en la especificación.
2. No se sabe especificar ciertas características de calidad (por ejemplo mantenimiento) de una
forma no ambigua.
3. Es muy difícil redactar especificaciones concretas, por lo que aunque el producto se ajuste a la
especificación el usuario no lo considera un producto de alta calidad debido a que no responde a
sus expectativas.

En concreto atributos como mantenibilidad, seguridad o eficiencia no pueden ser especificados

explícitamente, sin embargo tienen un efecto importante en cómo es percibida la calidad del sistema.
La gestión de la calidad se estructura en tres actividades principalmente.

1. Garantía de la calidad. El establecimiento de un marco de trabajo de procedimientos y

estándares organizacionales que conduce a un producto de alta calidad.
2. Planificación de la calidad. La selección de procedimientos y estándares adecuados a partir de
este marco de trabajo y la adaptación de estos para un proyecto.
3. Control de la Calidad. La definición y fomento de los procesos que garanticen que los
procedimientos y estándares para la calidad del proyecto son seguidos por el equipo de
desarrollo.

La gestión de la calidad provee una comprobación independiente de los procesos de desarrollo de una
tecnología de la información. Los procesos de gestión de la calidad comprueban las entregas del
producto, para asegurarse que estas concuerden con las especificaciones, estándares y metas de las
organizacionales.

Una característica principal del equipo de calidad es que este debe ser independiente al del equipo de
trabajo del proyecto, para que estos puedan tener una visión objetiva del producto, donde estos
comunicarán los problemas y dificultades al gestor principal del proyecto.

El equipo de calidad no debe estar ligado a ningún grupo de trabajo del proyecto, la razón de esto es
debido a que los gestores del proyecto deben de mantener el la estabilidad del presupuesto y los
tiempos de entrega del proyecto, por ejemplo si aparecen problemas, los gestores del proyecto pueden
verse tentados a comprometer la calidad del producto para mantener su agenda y presupuesto del
proyecto. Un equipo de proyecto independiente de calidad garantiza que los objetivos y la calidad no
sean comprometidos por consideraciones de presupuesto o la agenda.

Calidad de Proceso y Producto.

El desarrollo de una tecnología de información es un proceso más creativo que mecánico, donde la
experiencia y habilidades individuales son importantes, para obtener un producto de calidad, sin
embargo muchas veces esta se ve afectada por factores externos como la novedad de una aplicación, o
la presión comercial u organizacional para sacar un producto rápidamente.

La gestión de la calidad del proceso implica:

1. Definir estándares de proceso, como revisiones a realizar, cuando llevarlas a cabo, etc.
2. Supervisar el proceso de desarrollo del producto para asegurar que se sigan los estándares.
3. Hacer informes del proceso para el gestor del proyecto y para el comprador del producto.

Garantí a de la Calidad y Estándares.

La garantía de la calidad (QA) es el proceso que define cómo lograr la calidad del producto y como el
equipo de trabajo conoce el nivel de calidad requerido en el producto. Como se indicó anteriormente el
proceso de QA (Quality Assurance) se ocupa ante todo de definir o seleccionar los estándares que
deben ser aplicados al proceso de desarrollo o al producto.
Podemos definir dos tipos de estándares como parte del proceso de garantía de la calidad:
  Estándares del Producto. Se aplican sobre el producto que se comienza a desarrollar, se
incluyen estándares de documentación, como las reglas sintácticas a utilizar, esto representará el
producto acabado o al detalle, esto es especifica los requisitos que el producto tiene que o
debiera cumplir.
 Estándares de proceso. Estos definen los procesos que deben seguirse durante el desarrollo del
producto, pueden incluir definiciones de procesos de especificación, diseño, y parámetros de
validación, así como una descripción de los documentos que deben redactarse en el curso de
estos procesos.

Los estándares de producto se aplican a las salidas del proceso de desarrollo y, en muchos casos, los
estándares de procesos incluyen actividades de proceso específicas que garantizan que se sigan los
estándares de producto.

Los estándares para tecnologías de la información son importantes debido:

1. Están basadas en el conocimiento de la mejor o más apropiada práctica de la empresa. A

menudo, este conocimiento solo se adquiere después de seguir un proceso de prueba y error.
Tenerlo constituido en proceso evita la repetición de errores anteriores. Los estándares captan el
conocimiento que es de valor para la organización.
2. Proveen un marco de trabajo alrededor del cual se implementa el proceso de garantía de la
calidad, puesto que los estándares captan las mejores prácticas, el control de la calidad
sencillamente asegura que los estándares se siguen adecuadamente.
3. Ayudan a la continuidad, por ejemplo cuando una persona debe continuar el trabajo que llevaba
a cabo otra persona. Los estándares aseguran que todos los ingenieros de una organización
adopten las mismas prácticas, en consecuencia, se reduce la curva de aprendizaje cuando se
comienza un nuevo trabajo.

El desarrollo de estándares para los proyectos de tecnología, es un proceso largo y complicado, existen
actualmente organizaciones nacionales e internacionales como el departamento de defensa de los
Estados Unidos, ANSI, BSI, OTAN y el IEEE que han estado activas en la producción de los
estándares, estos estándares generales son aplicables a una gran variedad de proyectos.

Se han desarrollado estándares nacionales e internacionales para cubrir la terminología, por ejemplo los
lenguajes de programación como JAVA, C++, Visual Basic, etc., las notaciones como símbolos de los
diagramas, los procedimientos para derivar y redactar los requerimientos de software, los
procedimientos de garantía de calidad y los procesos de verificación y validación.

Los equipos de garantía de la calidad que desarrollan estándares, se apoyan en sus estándares
organizacionales apoyados de los estándares nacionales e internacionales, utilizando estos como punto
de partida, el equipo de garantía de calidad debe crear un “manual” de estándares donde se define los
estándares que son apropiados para la organización.
 Formulario para la revisión del diseño Conducto para la revisión del diseño
Estructura del documento de requerimientos Sometimiento de documentos a CM
Formato del encabezado del método Proceso de entrega de versiones
Estilo de programación en Java Proceso de aprobación del plan de proyecto
Formato del plan de proyecto Proceso de control de cambios
Formulario de petición de cambios Proceso de registro de pruebas
Tabla 1: Ejemplos de Estándares para Manual de Estándares

Aunque por lo general los ingenieros están de acuerdo en que los estándares son necesarios a menudo
tienen buenas razones de que por dichos estándares no son necesariamente apropiados, para su
proyecto en particular.

Para evitar estos problemas, los gestores de calidad que fijan los estándares necesitan estar informados
y tomar en consideración los siguientes pasos.

1. Involucrar a los ingenieros de software en el desarrollo de los estándares del proyecto. Así
comprenderán la necesidad de diseñar los estándares y se comprometerán con ellos. El
documento de los estándares de proyecto no debe especificar solamente que se sigan los
estándares, sino que deben de incluirse las razones de por qué se tomaron las decisiones
particulares.
2. Revisar y modificar los estándares de forma regular con el fin de reflejar los cambios en la
tecnología. Un manual de estándares es esencial, pero debe de evolucionar de acuerdo a las
circunstancias y la tecnología existente.
3. Proveer las herramientas de software necesarias para apoyar los estándares donde sea necesario.
Si se dispone de una herramienta de software de apoyo, no se necesitará mucho esfuerzo para
seguir los estándares.

Si se impone un proceso no practico al equipo de trabajo, los estándares de proceso pueden causar
dificultades. No existe razón para prescribir una forma particular de trabajo si esta es inapropiada para
un proyecto o equipo de trabajo. Los gestores de proyecto tienen la facultad de modificar los estándares
de procesos de acuerdo con las circunstancias particulares. Sin embargo los estándares relacionados
con la calidad del producto y del proceso posterior a la entrega sólo deben cambiarse después de
cuidadosas consideraciones.
Planifi cación de la Calidad.

La planificación de la calidad es el proceso donde se desarrolla un plan de calidad para un proyecto. En

este se definen la calidad del producto deseado y describe como valoras este. Por lo tanto, define lo que
es el producto de “Alta Calidad”. Sin esta definición, los diferentes ingenieros pueden trabajar en
direcciones opuestas para optimizar los atributos del proyecto.
El plan de calidad selecciona los estándares organizacionales apropiados para un producto y un proceso
de desarrollo particulares. Si el proyecto utilizara o cambiara a nuevos métodos y herramientas se
deben definir nuevos estándares.

Humphrey, 1989 en su libro clásico sobre gestión de software sugiere una estructura para el plan de
calidad, la cual comprende o siguiente:

1. Introducción del producto. Contiene la descripción del producto, el mercado al que se dirige y
las expectativas de calidad.
2. Planes de producto. Contiene las fechas de terminación del producto y las responsabilidades
importantes junto con los planes para la distribución y el servicio.
3. Descripción del proceso. Contiene los procesos de desarrollo y de servicio a utilizar para el
desarrollo y administración del producto.
4. Metas de calidad. Contiene las metas y planes de calidad para el producto, incluyendo la
identificación y justificación de los atributos de calidad importantes del producto.
5. Riesgos y gestión de riesgos. Contiene los riesgos clave que podrían afectar a la calidad del
producto y las acciones para abordar estos riesgos.

Los planes de calidad evidentemente difieren dependiendo del tamaño y del tipo de sistema a
desarrollar, sin embargo cuando se desarrollan los planes de calidad es recomendable mantenerlos los
más compactos posibles.

El plan de calidad define los atributos de calidad más importantes para el producto a desarrollar, el plan
también debe de considerar la definición del proceso de evaluación de la calidad.

Control de la Calidad.

El control de la calidad implica la supervisión de desarrollo del producto para asegurar que se siguen
los procedimientos y los estándares de la garantía de la calidad. Este proceso de control de calidad de
proyecto se comprueba que las entregas cumplan los estándares definidos.

Existen dos enfoques complementarios para comprobar la calidad de las entregas de un proyecto:

1. Revisiones de la calidad, donde el producto, documentación y los procesos utilizados en su

desarrollo son revisados por un grupo de personas, estos encargan de comprobar que se han
seguido los estándares del proyecto, del producto y los documentos concuerdan con estos
estándares.
2. Valoración automática del software en la que el software y los documentos producidos se
procesan por algún programa y se comparan con los estándares que se aplican a ese proyecto.
Revisiones de la Calidad.

Las revisiones son el método más utilizado para validad la calidad de un proceso o de un producto. En
este proceso se involucran a un grupo de personas que examinan todo o parte del proceso, los sistemas,
o su documentación asociada, para descubrir problemas potenciales. Las conclusiones de la revisión se
registran formalmente y se pasan al autor o a quien sea responsable de corregir los problemas
descubiertos.

El equipo de revisión debe tener un núcleo de tres a cuatro personas como revisores principales, uno de
ellos debe de ser el revisor principal y este tiene la responsabilidad de tomar decisiones técnicas, los
revisores principales pueden invitar a otros miembros del proyecto como a los diseñadores de los
subsistemas, para que colaboren en la revisión, para que colaboren con la revisión, estos últimos no se
involucran en la revisión de todo el documento, más bien se centran en aquellas partes que afectan a su
trabajo, de forma alternativa el equipo de revisión hace circular el documento a revisar y solicita
comentarios escritos de otros miembros del equipo.
Capítulo 2 Administración de proyectos con PMBOK.

Introducción a PMBOK
La guía de los fundamentos para la gestión de proyectos (Guía PMBOK), es una norma reconocida en
la profesión de la gestión de proyectos. Por norma se hace referencia a un documento formal donde se
describen normas, métodos, procesos y prácticas establecidos [ CITATION PMI \l 2058 ]. Al igual que
en otras profesiones, el conocimiento contenido en esta norma evolucionó a partir de las buenas
prácticas reconocidas por profesionales dedicados a la gestión de proyectos, quienes contribuyeron a su
desarrollo.

La creciente aceptación de la gestión de proyectos muestra que la aplicación de conocimientos,

procesos, habilidades, herramientas y técnicas adecuados puede tener un impacto considerable en el
éxito de un proyecto. La Guía del PMBOK identifica ese subconjunto de fundamentos de la gestión de
proyectos generalmente reconocido como buenas prácticas, entendiendo por “Generalmente
reconocido” a los conocimientos y prácticas descritos se aplican a la mayoría de los proyectos, la
mayor parte del tiempo y que existe consenso sobre su valor y utilidad. El concepto de “Buenas
prácticas” significa que se está de acuerdo, en general, en que la aplicación de estas habilidades,
herramientas y técnicas puede aumentar las posibilidades de éxito de una amplia variedad de proyectos.
Este concepto no debe entenderse como que el conocimiento descrito deba aplicarse siempre de la
misma manera en todos los proyectos; la organización y/o el equipo de gestión del proyecto son los
responsables de establecer lo que es aplicable para un proyecto determinado.

La guía de PMBOK también promueve y proporciona un vocabulario común para la gestión de

proyectos, para analizar, escribir y aplicar conceptos de gestión de proyectos, un vocabulario estándar
es esencial para cualquier disciplina profesional para el entendimiento entre los involucrados.

El Project Management Institute (PMI) considera la norma como una referencia fundamental en el
ámbito de la dirección de proyectos para sus certificaciones y programas de desarrollo profesional.

En su carácter de referencia fundamental, la norma no está completa, ni abarca todos los

conocimientos. Se trata de una guía más que una metodología, se pueden elegir diferentes metodologías
y herramientas para implementar el marco de referencia.

Las normas que establecen las pautas para los procesos, herramientas y técnicas de la gestión de
proyectos, el Code of Ethics and Professional Conduct del Project Management Institute sirve de
referencia a los profesionales en la gestión de proyectos y describe las expectativas que tienen de sí
mismos y de los demás.

Este código precisa las obligaciones básicas de responsabilidad, respeto, imparcialidad y honestidad.
Requiere que quienes se desempeñan en este ámbito demuestren compromiso con la conducta ética y
profesional, implica la obligación de cumplir con leyes, regulaciones y políticas profesionales y de la
organización.
Puesto que los profesionales provienen de culturas y orígenes diversos, el código anteriormente
mencionado se aplica a nivel mundial. En el trato con los interesados, los profesionales deben
comprometerse a realizar prácticas justas y honestas, y a mantener aceptar el código y que es requisito
Para la certificación PMP del PMI.
Ciclo del Proyecto
Existe una gran variedad de formas como subdividir un proyecto en fases, dependiendo de las
características específicas de cada proyecto, como pueden ser tiempo y complejidad, pero generalmente
en todos los proyectos tienen al menos una fase inicial, una o más fases intermedias, así como una fase
final [ CITATION PMI \l 2058 ].
Generalmente todos los proyectos pueden configurarse dentro de la siguiente estructura de ciclo de vida
de proyecto, como se muestra en la siguiente ilustración [ CITATION PMI \l 2058 ].
 Inicio,
 Organización y Preparación,
 Ejecución del trabajo y
 Cierre.

Ilustr
ación 1: Fases del Proyecto

El ciclo de vida del proyecto es un conjunto de fases del mismo, generalmente secuenciales y en
ocasiones superpuestas, cuyo nombre y número se determinan por las necesidades de gestión y control
de la organización u organizaciones que participan en el proyecto, la naturaleza propia del proyecto y
su área de aplicación [ CITATION PMI \l 2058 ].

La gráfica nos indica el nivel de costo y recursos que deben emplearse a lo largo del ciclo de vida del
proyecto, donde se va incrementando estos según avanza en tiempo y alcanza su máximo empleo en las
fases intermedias y disminuyendo en la fase de cierre.

La importancia de cada fase dependerá de cada proyecto según sus características propias e
individuales, a continuación se describe una clasificación de fases con un enfoque común pero
incorrecto de los estados de como sucede en un proyecto [ CITATION PMI \l 2058 ].

 Optimismo exacerbado:
A menudo, al iniciar un proyecto creemos que todo va a salir bien, o que si algo llegara a salir mal, se
encontrará la solución para sacar adelante el proyecto ya sea con poco dinero, poca gente, en poco
tiempo y con magníficos resultados. Y si no me creen pregunten a cualquier gobierno que esté en
campaña, o a algún gerente obstinado con su proyecto [ CITATION PMI \l 2058 ].

 Desorientación progresiva:
Conforme avancemos en el proyecto los problemas se irán acumulando, creando dudas sobre los
problemas que acumulemos por ejemplo ¿qué problema se deberé de atender primero?, ¿Cuál problema
tiene menor impacto en el proyecto?, ¿cual me sale más barato?, ¿cuál se hace más rápido?, entre otras,
creando una incertidumbre sobre si cumplirán con los objetivos planeados.

 Desconcierto Total:
Si los problemas no se atienden o no se toma acciones correctivas en el proyecto, el proyecto corre el
riesgo de cancelarse.

 Búsqueda de Culpables:
Generalmente se suelen buscar a los responsables ya sea de manera objetiva o en el peor de los casos se
busca alguien de menor jerárquica a quien se le responsabilice de los resultados del proyecto.

 Castigo ejemplar a los inocentes:

Es común que en tiempo de crisis no se analiza correctamente las razones del estado del proyecto, y se
toman acciones correctivas (despido, baja del proyecto) comúnmente al personal que menos culpa tuvo,
que generalmente son las de menor jerarquía en la organización o comúnmente a un integrante del
equipo de trabajo.

 Terminación inexplicable del Proyecto:

La finalización para este tipo de proyectos se logra por el involucramiento de gente sumamente experta
en la especialización requerida ya que en poco tiempo logra terminar los pendientes o problemas
surgidos en el proyecto, comúnmente a esto se le conoce con el termino bomberazo [ CITATION
PMI \l 2058 ].

 Premiación a los sobrevivientes:

Es común ver que las personas que ocasionaron los problemas sean las personas sé que sean premiadas
por la finalización del proyecto, aunque este no sea haya cumplido en diferentes formas en términos de
administración de proyecto, y situación esto se convierte en un círculo vicioso en la gestión de
proyectos.

 Optimismo exacerbado para comenzar el siguiente Proyecto:

Nuevamente se repite el ciclo, con los nuevos propósitos, ¡pero ahora si voy a terminar bien!, etc...

Utilizando otro tipo de análisis veremos que cada fase está definida por uno o más entregables que se
deberán concluir al término de esa fase. Para cada tipo de Proyecto se puede definir un Ciclo de Vida
característico.

Cada proyecto puede implementarse en diferentes fases. Por ejemplo, un proyecto para el desarrollo de
un fármaco implica largas fases de investigación, pruebas y validaciones antes de pensar en la
construcción de las instalaciones para su producción.
A continuación se muestra un diagrama en espiral de cómo se van desarrollando las fases de un
proyecto para el desarrollo de un software. Este mismo modelo puede aplicarse para Proyectos en el

que el producto del Proyecto se tendrá que definir mientras el Proyecto se esté ejecutando.

En la siguiente tabla se muestran las fases de un Proyecto desde el punto de vista de una institución
Financiera. Para ellos lo importante es recuperar el capital invertido, por lo tanto, el Proyecto termina
precisamente cuando este capital ha sido recuperado.

Ilustración 1: Diagrama en Espiral

Tabla 1 Ejemplo Fases de un Proyecto

FASES ACTIVIDADES OBJETIVOS

Pre inversión Identificación de la necesidad de
Estudios de gran visión.
Decisión Definir el perfil del Proyecto:
1. estudios de pre factibilidad y
de factibilidad.
Detectar las necesidades y los
Recursos para su satisfacción.
 Generar y seleccionar
opciones, elegir lo más
eficiente para satisfacer la
necesidad y aprovechar los
recursos.

2. Ingeniería del Proyecto.  Utilizar los elementos idóneos

de diseño, especificaciones y
procedimientos constructivos
necesarios.
Inversión Gestión para obtención de los
recursos:
1. asesorías por especialidades.  Definir el grupo de trabajo,
organizarlo formalmente y
2. Ejecución del Proyecto, obtener
supervisión y control técnico- Los recursos.
económico, entrega y puesta
en marcha.  Disposición eficiente de los
recursos humanos, físicos y
financieros.
Recuperación Operación y dirección administrativa Optimización del proceso: sistemas
técnica y financiera. y procedimientos, aseguramiento
de calidad y obtención de
Resultados previstos.

Hasta aquí se han mostrado diferentes tipos de ciclos de vida de un proyecto para diferentes áreas de
trabajo. A continuación, se analizará las fases desde un enfoque de gestión de proyectos basado en el
PMBOK.

El enfoque que PMBOK describe para

Definición de Conceptos de la Administración de Proyectos Basadas en PMBOK

Proyecto

El PMI (Project Management Institute), define a un proyecto con el siguiente concepto:

“Esfuerzo temporal que se lleva a cabo para crear un producto o servicio
UNICO.”[ CITATION PMI \l 2058 ].
Como se nota en la definición anterior, existen tres factores que definen al proyecto.
1. Un periodo de tiempo
2. Un objetivo especifico
3. Tienen la particularidad de ser únicos
Todo proyecto deben establecerse con un inicio y fin bien definidos, adicionalmente deben estar muy
claros los objetivos que se deben alcanzar y finalmente no debe de existir un proyecto igual a otro.

Administración de Proyectos

“La dirección de proyectos es la aplicación de conocimientos, habilidades, herramientas y técnicas a

las actividades del proyecto para cumplir con los necesidades y expectativas del mismo.”[ CITATION
PMI \l 2058 ].

Esto se alcanzará mediante la aplicación e integración correcta de los 42 procesos de la dirección de

proyectos, agrupados lógicamente, que conforman los 5 grupos de procesos.

Siendo estos los siguientes:

1. Iniciación,
2. Planificación,
3. Ejecución,
4. Seguimiento y Control, y
5. Cierre.

El significado de cada uno de estos requisitos (conocimiento, habilidad, herramientas, y técnicas) se

describen a continuación:

Conocimiento

No se puede gestionar un proyecto si no se cuenta con al menos un mínimo conocimiento, PMBOK

clasifica a este en lo siguiente:
 Conocimiento de la Administración de Proyectos
 Conocimiento del área específica de Aplicación
 Conocimiento de la Administración del Negocio
 Cuerpo de conocimientos de la Administración de Proyectos

Conocimiento de la Administración de Proyectos

Este marco establece que para gestionar un proyecto este se deben de dividir en sus componentes
principales, y que cada una de estas partes se debe de gestionar de manera individual, pero al mismo
tiempo de manera integral.
En este marco se incluyen las nueve áreas de conocimiento que define PMBOK para administrar de
manera exitosa un proyecto.
i. Administración Integral
ii. Administración del Alcance
iii. Administración del Tiempo
iv. Administración del Costo
 v. Administración de la Calidad
vi. Administración de los Recursos Humanos
vii. Administración de la Comunicación
viii. Administración del Riesgo
ix. Administración de las Adquisiciones

Estas nueve áreas se verán a detalle en secciones posteriores de este capítulo.

Conocimiento del área específi ca de aplicación

PMBOK establece que para gestionar proyectos de manera adecuada, el equipo encargado de llevarlo a
cabo independientemente de los conocimientos en administración de proyectos, este debe formar parte
de las prácticas y contar con el conocimiento específico del tipo de proyectos en que trabajará. Por
ejemplo, si nuestro proyecto es el desarrollo de un software para controlar un motor, es necesario que el
equipo de proyecto cuente con los recursos humanos que dominen este conocimiento, es decir, que sean
expertos en el lenguaje de programación así como las interfaces que requieran.

Conocimiento de la Administración del Negocio

De la misma forma, el modelo de administración de proyectos establece que debe existir cierto nivel de
conocimiento de la organización, comúnmente llamado conocimiento del negocio, y que además es
necesario conocer a la organización en la que el proyecto se llevará a cabo. Por ejemplo, un proyecto en
el que una firma de consultoría dará servicios a una organización, y de estos servicios una parte los
subcontratará, para poder cumplir con los objetivos del proyecto la firma de consultoría tendrá que
tener cierto nivel de conocimiento tanto del negocio de la organización como del negocio del
subcontratista, es decir debe conocer el “idioma” que hablan ambas partes que PMBOK define como
grupos de interés y que se integrará para sacar adelante al proyecto.

Cuerpo de conocimientos de la Administración de Proyectos

En general todos los proyectos se ven afectados por el contorno en el que se desarrollan. PMBOK
establece que adicionalmente, se requieren conocimientos extras a lo que es específicamente la gestión
de proyectos, como pueden ser las habilidades gerenciales, planeación estratégica, gestión de negocios,
mercadotecnia, finanzas, y todo aquello que el proyecto demande. El núcleo de estos conocimientos es
necesario para garantizar el éxito de los proyectos, por esta razón el equipo de trabajo que se adquiera,
deberá incluir individuos que en conjunto manejen todo este conocimiento.

En conclusión, se requiere de una gran cantidad de conocimientos para llevar a cabo un Proyecto. Hoy
en día es cada vez más difícil que una sola persona posea suficiente conocimiento para hacerlo, por lo
que casi todos los Proyectos tienen que administrarse por equipos multidisciplinarios que deberán ser
capaces de integrar su conocimiento.

Habilidades
El contar con mucho conocimiento, para la gestión de proyectos no es suficiente, esta área implica todo
un conjunto de habilidades, y en particular a lo que se refiere al líder de proyecto se han encontrado
algunas de las siguientes [ CITATION Mer \l 2058 ]:
 Liderazgo
 Comunicación
 Negociación
 Solución de problemas
 Influencia sobre la organización

Para mayor detalle referirse a [ CITATION PMI \l 2058 ].

Técnicas

Las técnicas es el conjunto de saberes prácticos que establecen la forma en cómo se deben hacer las
cosas [ CITATION Loy \l 2058 ]. A menudo estas técnicas se documentan por medio de procedimientos
que describen cada uno de los pasos de lo que hay que realizar. Es común que a veces se conozca la
técnica, pero no se cuente con la habilidad, y en otras, se puede ser hábil, pero si se desconoce la
técnica entonces el resultado no será el óptimo.

Existen algunas técnicas específicas de Administración de Proyectos, como es el caso de la ruta crítica
para la Administración de la duración de un Proyecto, pero existen otras que sin ser exclusivas de la
gestión de proyectos, se utilizan comúnmente para lograr los resultados de los Proyectos.

 Técnicas de Estimación. Métodos Albrecht y MARKII para el Análisis de Puntos de Función

 Staffing Size (Orientación a Objetos)
 Planificación
 Program Evaluation & Review Technique – PERT
 Diagrama de Gantt
 Estructura de Descomposición de Trabajo (WBS – Work Breakdown Structure
 Diagrama de Extrapolación
[ CITATION Mer \l 2058 ]
Herramientas

Las herramientas más comunes para facilitar todo el flujo del proyecto desde su planeación hasta la
finalización del mismo, son las computadoras así como el software específico para la gestión de
proyectos.
Estas herramientas nos ayudaran a realizar actividades con mayor rapidez y exactitud, cabe notar que si
se desconoce la técnica el uso de las herramientas será infructuoso o a veces hasta contraproducente.
Un aspecto muy importante es que las herramientas se tienen que aprender a usar para obtener el
máximo beneficio, si bien se puede dominar la técnica pero si se desconoce la herramienta, el resultado
puede ser igual de malo que en el caso opuesto, antes descrito.
Lo recomendable es primero conocer y tener cierta experiencia la técnica y posteriormente aprender a
utilizar las herramientas, una vez que sé que se alcance cierto dominio en ambas combinarlas para
alcanzar los resultados cada vez con mayor eficiencia y efectividad.

Cumplir

El equipo para la gestión de proyectos el “cumplir” con los objetivos no debe significar que haya hecho
su mejor esfuerzo. Este debe de estar consciente de que está en una competencia continúa y que si
supera “excede” con las expectativas estará en mejor posición para continuar creciendo o por lo menos
para mantenerse con vida (trabajo) [ CITATION Loy \l 2058 ].

Necesidades y Expectati vas

El alcanzar los objetivos marcados en tiempo, costo y en los requerimientos establecidos no siempre
significa que se cumplieron con la necesidades del cliente. Por ejemplo una firma de consultoría la cual
implementó un sistema computacional ERP y estos culminaron el proyecto en tiempo, forma y costo en
base a lo planeado, pero donde salieron peleados con el cliente.
¿Se podría decir que lograron la misión como administradores del proyecto?
Ahora imaginemos el caso contrario a excepción que el cliente termino contento con el trabajo
realizado, de igual forma nos preguntamos si, ¿también se logró alcanzar la misión como administrador
del proyecto?

Para ambos casos ninguno de los dos alcanzaron la misión, puesto que hay que se deben de alcanzar
todos estos aspectos anteriormente mencionados.

Con mucha frecuencia, resulta que las expectativas del cliente son mayores a las del proveedor es decir
por un lado el cliente espera recibir más por menos, y el segundo (proveedor), espera que con menos el
cliente quede satisfecho. Comúnmente esto ocurre en las primeras etapas del proyecto es decir al inicio,
los clientes del proyecto, y aún los administradores del mismo, desarrollan un optimismo exagerado
que les hace pensar que con poca inversión económica y de recursos y que en un lapso muy corto,
lograrán superar con creces los objetivos del Proyecto.

¿Cómo resolver este dilema?

El PMBOK aplica técnicas para tener una comunicación efectiva y para q la definición del alcance y
los objetivos se realicen de forma realista de tal manera que las falsas expectativas de ambas partes
(clientes y proveedores) sean esclarecidas y resueltas lo antes posible y se estén continuamente
monitoreando para garantizar que al concluir el proyecto tanto las expectativas como necesidades
hayan sido cumplidas.

Grupos de Interés

PMBOK define a los “Grupos de Interés” como aquellas “Personas u organizaciones (por ejemplo,
clientes, patrocinadores, la organización ejecutante o el público), que participan activamente en el
proyecto, o cuyos intereses pueden verse afectados positiva o negativamente por la ejecución o
terminación del proyecto” [ CITATION PMI \l 2058 ].
Algunos ejemplos de grupos de interés en el proyecto del desarrollo de software pueden ser los
siguientes:
 El cliente
 El equipo de trabajo de proyecto
 Directores, Gerentes
 Subcontratistas
 Líderes funcionales
 Revisores de Diseño
 Usuarios finales

Introducción a las Áreas de Conocimiento de la Administración de Proyectos

Las áreas de conocimiento que el PMBOK describe, son las entidades en las que el líder de proyecto
debe gestionar de manera efectiva para así poder alcanzar los objetivos del proyecto de manera
satisfactoria.

A continuación se describen brevemente las 9 áreas de conocimiento para la gestión de proyectos, en

seccionas posteriores de este capítulo se profundizará en cada una de ellas.

Ilustración 12 Áreas de Conocimiento

Administración para la Integración del Proyecto

Todas las áreas de conocimiento del PMBOK para la administración de proyectos interactúan entre sí y
cuando ocurre un cambio en alguna de ellas por lo regular se ve reflejado un impacto en las otras.
Sin embargo el área de conocimiento Integración es la que se característica por tener una mayor
interacción con el resto de las áreas ya que el objetivo principal de esta área es la de articular la relación
con las demás áreas.
Es casi imposible que un proyecto no tenga cambios, todos los proyectos sufren cambio a lo largo de la
duración del proyecto, estos cambios pueden tener un impacto positivo o negativo y para ellos el
equipo de proyecto debe estar preparado para estos cambios.
La integración incluye características de unificación, consolidación, articulación, así como las acciones
integradoras que son cruciales para la terminación del proyecto [ CITATION PMI \l 2058 ].

El proceso administrativo de Integración implica los siguientes subprocesos:

 Desarrollo del Plan del Proyecto

 Ejecución del Plan del Proyecto
 Control integral de cambios

Administración del Alcance del Proyecto

PMBOK define a esta área como:

La Gestión del Alcance del Proyecto incluye los procesos necesarios para garantizar que el proyecto
incluya todo (y únicamente todo) el trabajo requerido para completarlo con éxito. El objetivo principal
de la Gestión del Alcance del Proyecto es definir y controlar qué se incluye y qué no se incluye en el
proyecto [ CITATION PMI \l 2058 ].

Como se observa con la definición anterior, en esta área se determinará lo que va hacerse en el
proyecto, y lo más importante lo que NO se va hacer en el proyecto, basándose en la primicia “ Si está
en el alcance se tiene que hacer, si no está, no se debe de hacer” [ CITATION Mer \l 2058 ].
El párrafo anterior se puede llegar a confundir o parecer contradictorio si el alcance llegara a cambiar,
lo que sucede es que mientras ese cambio al alcance no se haya analizado y ver qué impacto tienen en
las demás áreas de conocimiento y mientras no se haya autorizado ese cambio, se deberá realizar
únicamente lo que está aprobado en el alcance.

En caso de que el alcance no sea el adecuado y conlleve a un gran impacto negativo debemos poner
gran empeño para que el cambio sea autorizado, antes de realizarlo.

El proceso de alcance implica los siguientes subprocesos.

 Inicio
 Planeación del alcance
 Definición del alcance
 Verificación del alcance
 Control de cambios del alcance

Administración del Tiempo del Proyecto

La administración del tiempo es una da las áreas que son mayormente monitorizadas, pero si no se le
liga al alcance y costo no nos aportara mayor información.

La guía de los fundamentos de la administración de proyectos nos dice que en esta área se incluyen los
procesos requeridos para administrar la finalización del proyecto a tiempo [ CITATION PMI \l 2058 ].
Existen algunas metodologías relativamente sencillas y aceptadas que nos dan un nivel muy importante
de información que permiten el control integral del Proyecto. Una de estas metodologías, representativa
del enfoque moderno de Administración de Proyectos que integra alcance, tiempo y costo, se le conoce
como “Análisis del Valor Devengado” [ CITATION Mer \l 2058 ].

El proceso para la Administración del Área de Conocimiento Tiempo implica los siguientes
subprocesos.

 Definición de actividades
 Establecimiento de la secuencia de actividades
 Estimación de la duración de actividades
 Desarrollo del programa de trabajo
 Control del programa de trabajo

Administración del Costo del Proyecto

Esta área de conocimiento es la encargada de asegurar de que el proyecto se realice dentro del
presupuesto establecido. Adicionalmente en esta área se incluye el proceso para analizar el beneficio
económico que se va a obtener por el mismo.

Esta área de conocimiento en las organizaciones, les es de mucha utilidad aplicarla ya que regularmente
necesitan saber cómo se han utilizado el presupuesto en sus proyectos.

La Gestión de los Costos del Proyecto incluye los procesos involucrados en estimar, presupuestar y
controlar los costos de modo que se complete el proyecto dentro del presupuesto aprobado [ CITATION
PMI \l 2058 ].

El proceso para la Administración del Área de Conocimiento Costo implica los siguientes subprocesos.

 Planeación de recursos
 Estimación de costos
 Presupuesto de costos
 Control de costos

Administración de la Calidad del Proyecto

Actualmente el cliente tiene un enfoque distinto al de otros años en el pasado, y es un factor

determinante y de gran importancia la gestión de la calidad en los proyectos. Por medio de esta área de
conocimiento se asegurará que el Proyecto satisfaga las necesidades a las que se comprometió
[ CITATION Mer \l 2058 ].

Incluye los subprocesos de:

  Planeación de la calidad
 Aseguramiento de la calidad
 Control de calidad

Administración de los Recursos Humanos del Proyecto

Comúnmente se suele decir, que el recurso más importante de una organización es el recurso humano
ya que de su calidad dependerán los resultados, La Administración de Recursos Humanos hace más
eficiente la participación de este recurso incluyendo a todos los grupos de interés en el Proyecto.

La Gestión de los Recursos Humanos del Proyecto incluye los procesos que organizan, gestionan y
conducen el equipo del proyecto. El equipo del proyecto está conformado por aquellas personas a las
que se les han asignado roles y responsabilidades para completar el proyecto. El tipo y la cantidad de
miembros del equipo del proyecto pueden variar con frecuencia, a medida que el proyecto avanza
[ CITATION PMI \l 2058 ].

Los subprocesos para la gestión de los recursos humanos son los siguientes:

 Planeación organizacional
 Integración del equipo encargado de la administración del proyecto
 Desarrollo de trabajo en equipo

Administración de la Comunicación del Proyecto

Muy a menudo suelen ocurrir problemas por falta de comunicación entre los involucrados en el
proyecto debido a que con frecuencia en los involucrados no se conocen, los periodos de interacción
son muy cortos, entre otros, por tal motivo la comunicación oportuna y correcta es relevante, por otro
lado también se debe de considerar de no saturar de información a los involucrados y /o no hacer llegar
la información de manera oportuna y con esto no poder tomar decisiones correctas.

Cada participante del proyecto debe entender el impacto de las comunicaciones al resto de la
organización e identificar la información que necesitará para realizar su trabajo.
PMBOK nos dice que la gestión de las comunicaciones del proyecto debe incluir los procesos
requeridos para garantizar que la generación, la recopilación, la distribución, el almacenamiento, la
recuperación y la disposición final de la información del proyecto sean adecuados y oportunos. Los
directores del proyecto pasan la mayor parte del tiempo comunicándose con los miembros del equipo y
otros interesados en el proyecto, tanto si son internos (en todos los niveles de la organización) como
externos a la misma. Una comunicación eficaz crea un puente entre los diferentes interesados
involucrados en un proyecto, conectando diferentes entornos culturales y organizacionales, diferentes
niveles de experiencia, y perspectivas e intereses diversos en la ejecución o resultado del proyecto
[ CITATION PMI \l 2058 ]
El proceso para la Administración del Área de Conocimiento Comunicación implica los siguientes
subprocesos.

 Planeación de las comunicaciones

 Distribución de la información
 Reportes de desempeño
 Cierres administrativos

Administración del Riesgo del Proyecto

Hasta donde se conoce todos los proyectos tienen cambios [ CITATION Mer \l 2058 ]. aunque se
desconocen los imprevistos que puedan presentarse en el proyecto, se pueden establecer factores
probabilísticos, que nos permitan dimensionar el posible impacto en la sumatoria de los riesgos y las
oportunidades comúnmente conocidos issues, estos últimos son los que nos pueden generar un
beneficio al proyecto donde se presenten y lo más importante de la identificación de los riesgos y
oportunidades es la respuesta que se dé ante estos, donde se pueden atacar ya sea por la mitigación del
riesgo o el aprovechamiento de las oportunidades donde la primera de esta nos ayudará a que los
riesgos potenciales no afecten el proyecto de manera significativa y en la segunda en cómo podemos
mejorar los resultados que se están buscando.

Este proceso de gestión de Riesgos basados en PMBOK incluye los siguientes subprocesos.

 Planeación de la Administración del riesgo

 Identificación de riesgos
 Análisis cualitativo del riesgo
 Análisis cuantitativo del riesgo
 Planes de la respuesta al riesgo
 Control de riesgos

Administración de las Adquisiciones del Proyecto

La planificación de las adquisiciones es el proceso que consiste en documentar las decisiones de

compra para el proyecto, especificar la forma de hacerlo e identificar a los posibles vendedores.
Identifica qué necesidades del proyecto pueden satisfacerse de la mejor manera, o si se deben
satisfacer, mediante la adquisición de productos, servicios o resultados fuera de la organización del
proyecto, y qué necesidades del proyecto pueden ser resueltas por el equipo del proyecto [ CITATION
PMI \l 2058 ].

Este proceso implica determinar si es preciso obtener apoyo externo y, si fuera el caso, qué adquirir, de
qué manera, en qué cantidad y cuándo hacerlo. Cuando el proyecto obtiene productos, servicios y
resultados necesarios para el desempeño del proyecto fuera de la organización ejecutante, se ejecutan
los procesos desde Planificar las Adquisiciones hasta Cerrar las Adquisiciones para cada elemento que
se va a adquirir [ CITATION PMI \l 2058 ].
La gestión adecuada de las adquisiciones evitará muchos dolores de cabeza y acciones de emergencia
que normalmente redundan en un uso ineficiente de los recursos.

A continuación se listan los subprocesos que forman parte de la gestión de adquisiciones:

 Planeación de las adquisiciones

 Planeación de pedidos
 Pedidos
 Selección de proveedores
 Administración de contratos
 Cierre de contratos

¿Qué Área de Conocimiento es de Mayor Importancia?

Como hemos visto a través de cada una de las áreas de conocimiento que incluye el PMBOK, que cada
una de estas tienen un propósito específico, pero, desconocemos cuál de ellas es más importante o para
casos prácticos en cual de ella debemos poner mayor atención o dedicación.

Probablemente podríamos pensar que la más importante sea la de integración, ya que es la que en ella
se reflejan las demás, o ¿podrá ser calidad? ya que con ella se garantiza que la especificación del
cliente sea satisfecha, por lo anterior ¿cómo podemos saber qué área a la que debemos poner más
énfasis?

La respuesta a esta pregunta es que si existe una área de conocimiento más importante, pero no es
general ni única, ya que depende del proyecto en sí, ya que cada proyecto es único y cada proyecto
tiene características específicas y especiales por lo cual cada el área de conocimiento al que se le dé
mayor importancia dependerá de las características de cada proyecto [ CITATION Mer \l 2058 ].

Por ejemplo para un proyecto de desarrollo de software para el monitoreo de un marcapasos cardiaco,
el área de conocimiento que se le deberá dar mayor atención es el de calidad, para que el proyecto
cumpla exactamente con los requerimientos específicos, pero para el caso de un proyecto de desarrollo
de implementación de un sistema ofimática el área de conocimiento de mayor importancia podría ser
el del tiempo para garantizar que los usuarios tengan el software y puedan realizar sus actividades.

Y así podríamos enumerar gran cantidad de proyectos en donde una o varias de las áreas de
conocimiento fueran las más importantes, es más, resulta que el nivel de importancia de ellas puede
variar a lo largo del ciclo de vida del proyecto. De aquí que lo relevante es que el equipo encargado de
administrar el proyecto, tenga en todo momento muy presente a cuál o cuáles de las áreas les tiene que
dar prioridad.

Cultura de Proyectos
Un tema que no es propio de la guía de los fundamentos para la administración de proyectos, pero que
el Project Management Institute (PMI) también desarrollo es el modelo de madurez en cultura de
proyectos, y que es muy importante para las empresas ya que este modelo da las pautas a seguir para
asistir a las organizaciones en el mejoramiento de sus capacidades para implementar su estrategia a
través de la ejecución de múltiples proyectos conjuntamente con la guía de PMBOK.

Por tal motivo se describirá de manera general este modelo, para tener un marco más amplio en el
conocimiento para la administración de proyectos.

Modelo de Madurez en Cultura de Proyectos

La madurez y la excelencia en la administración de proyectos se describen con el siguiente modelo que

consta de los siguientes niveles de madurez [ CITATION Mer \l 2058 ].

 Nivel 1, Lenguaje Común: En este nivel, la organización reconoce la importancia de la

administración de proyectos y la necesidad de un buen entendimiento de los conocimientos
básicos, así como de su terminología.

 Nivel 2, Procesos Comunes: En este nivel, la organización reconoce que se requiere definir y
desarrollar procesos para asegurar que las prácticas aplicadas en los proyectos exitosos sean
replicadas en el resto de los proyectos de la organización. También en este nivel se reconoce
que los principios de la administración de proyectos se pueden aplicar y pueden soportar otra
metodología de la organización.

 Nivel 3, Metodología Única: En este nivel, la organización reconoce el efecto sinérgico de

combinar todas las metodologías corporativas en una metodología única, cuyo centro es la
administración de proyectos.

 Nivel 4, Benchmarking: Este nivel contiene el reconocimiento de que la mejora de los procesos
es necesaria para mantener una ventaja competitiva. El Benchmarking debe realizarse
continuamente. La organización debe decidir a quién y qué benchmark.

El benchmark es una técnica utilizada para medir el rendimiento de un sistema o componente del
mismo, frecuentemente en comparación con el que se refiere específicamente a la acción de ejecutar un
benchmark. La palabra benchmark es un anglicismo traducible al español como comparativa Wikipedia

 Nivel 5, Mejora Continua: En este nivel, la organización evalúa la información obtenida mediante
el benchmarking y debe decidir cuándo es necesario mejorar su metodología.

El Dr. Kerzner, nos dice que una organización con madurez en la Administración de Proyectos tiene las
siguientes características:

 Adopta una metodología de administración de proyectos y la sigue

 Implementa una filosofía que dirige a la organización hacia la madurez en la administración de
proyectos y lo comunica a todos
 Se compromete al desarrollo de planes efectivos desde el inicio de cada proyecto
 Minimiza los cambios al alcance comprometiéndose a objetivos realistas
  Reconoce que la administración de los costos y programas son inseparables
 Selecciona a la persona adecuada como Líder del Proyecto
 Proporciona a los ejecutivos la información financiera, no la de administración del proyecto
 Se enfoca en los entregables, no en los recursos
 Cultiva la comunicación, la cooperación y la confianza para alcanzar rápidamente la madurez
en Administración de Proyectos
 Comparte el reconocimiento de los proyectos exitosos con todo el equipo del proyecto
 Elimina las reuniones improductivas
 Se enfoca en la identificación y resolución de los problemas oportuna y rápidamente y con
costos eficientes
 Mide el progreso periódicamente
 Utiliza un software de Administración de Proyectos como una herramienta, no como un
sustituto de la planeación efectiva
 Instituye un programa de capacitación con actualizaciones periódicas basadas en las lecciones
aprendidas documentadas

Ilustración 13: Modelo de Madurez en Cultura de Proyectos

Actualmente las organizaciones están optando por tener un proceso bien definido para la gestión de sus
proyectos, porque es necesario tener conocimiento sobre cómo implementar una cultura de proyectos
en la organización, a lo que nos preguntamos ¿Quién la implementa?, y ¿Cómo se implementa?

El responsable de la implementación es el equipo designado por la organización para realizar tal

actividad, con el apoyo de profesionales en la administración de proyectos Project Manager
Professional (PMP) y generalmente a este equipo se le nombra “La Oficina de Proyectos (PMO)”.

El equipo en cuestión deberá contar con las siguientes características:

 Contar con especialistas de las áreas de conocimiento de la administración de proyectos

 Contar con administradores de la organización en donde se implementará la Cultura de
Proyectos (CP)
 Contar con especialistas en las áreas del proyecto en cuestión (en este caso abogados,
contadores, etc.)

La cultura de proyectos se implementa tomando en cuenta los siguientes puntos:

  Administrando la implementación como un proyecto
 Mediante las prácticas de administración de cambios organizacionales
 Iniciando con un proyecto piloto y extendiendo la cultura a un área y de ahí, a toda la
organización.

Retomando el tema de administración de proyectos en lo individual un área de soporte para administrar

proyectos y que actualmente por lo general las organizaciones cuentan con ella es la oficina de
proyectos (PMO) por sus siglas en inglés.

Una PMO un departamento de Servicio que típicamente se le conoce como el "Centro de Calidad de
Administración de Proyectos" [ CITATION Mer \l 2058 ]. Se implementa en las organizaciones para
que por un lado ayuden a los líderes de los proyectos a que cumplan su misión con eficiencia y
efectividad; y por otra parte, administren el portafolio de proyectos de la organización.

En prácticamente todas las organizaciones, frecuentemente los líderes de proyecto se encuentran

saturados por la cantidad de gente con la que tienen que interactuar, que entre otros, incluye a sus jefes,
a su gente, a proveedores internos y externos y gente de las áreas administrativas, adicionalmente
tienen que colaborar en la ejecución y revisión de los proyectos que coordinan. Por otra parte tienen
que dedicar una gran parte del tiempo a resolver los problemas relacionados con su personal y por si
todo lo anterior fuera poco además tienen que administrar sus proyectos.

Por otra parte, los líderes de proyecto tienen típicamente una formación técnica, por lo que de forma
muy natural se sienten mejor resolviendo situaciones técnicas que situaciones administrativas.

Es por esto que una Oficina de Proyectos resulta de gran utilidad para ayudar a que los proyectos
salgan adelante. Por una parte son un recurso que está disponible para ayudar y por otra, son expertos
en lo que hacen por lo que en relativamente poco tiempo pueden avanzar mucho en la administración o
actividades técnicas específicas, permitiendo al líder dedicarse a sus otras responsabilidades.

Por otra parte, la Oficina de Proyectos tiene como misión la transferencia de conocimiento, por lo que
poco a poco los Líderes de Proyecto deben de ir adquiriendo las habilidades de Administración de
Proyectos que les hagan falta, para que día con día sus proyectos sean mejores.

A continuación se detallan las actividades que cuando la Oficina de Proyectos se encuentre totalmente
consolidada.

 Implementación de la Cultura de Proyectos

 Administración del Portafolio de Proyectos
 El sistema de medición de desempeño de Proyectos
 Administrar el conocimiento que se genera en la organización por los proyectos
 Diseminación de las Lecciones Aprendidas
 Desarrollar la Metodología de Administración de Proyectos de la Organización
 El sistema de reportes gerenciales de avance de Proyectos
  Estandarización de las Técnicas de Administración de Proyectos
 Asegurar la aplicación consistente del proceso de Administración de Proyectos
 Definición de políticas de Administración de Proyectos
 Coordinar y/o conducir Programas de Entrenamiento
 Auditorías de procesos
 Identificación de las mejores prácticas de Administración de Proyectos
 Administración de las bases de datos de Proyectos
 Coordinación de Análisis de Riesgos y Oportunidades
 Coordinación de Análisis de Opciones
 "Benchmarking"
 Coordinar la comunicación con instituciones especializadas en Administración de Proyectos
(PMI)
 Estandarización del Software de Administración de Proyectos

Resumiendo, la PMO tiene como misión enfocarse a la efectiva y eficiente gestión de los procesos,
bajo un enfoque de mejora continua, mientras el resto equipo de proyecto se enfoca al éxito del mismo.

Proceso de Administración de Proyectos

El modelo de la Gestión de Proyectos

El modelo para la gestión de proyectos que el PMBOK propone se base en incluir distintas variables
entre las cuales se incluyen el alcance, tiempo, riesgo, costo y calidad, en la cual como la imagen lo
muestra todo está en continuo cambio representado con la variable de riesgo, que es la que determina la
longitud de cada uno de los lado de las demás variables.

Lo importante no es hacer o construir lo que se dijo que se haría, lo importante es lograr los objetivos
del Proyecto. Por ejemplo, si el Proyecto es construir una nave para viajar a Marte, lo importante no es
construir una nave con ciertas características, lo importante es que esas características permitan a la
nave llegar a Marte de la forma más eficientemente y segura posible[ CITATION Mer \l 2058 ].
PMBOK también provee una relación al modelo variables relacionadas con las organizaciones que de
igual forma participan en el desarrollo del proyecto como son en específico el cliente el usuario y o el
comprador.

Con este modelo que PMBOK propone, a el Proyecto ya no se le ve como un proceso aislado en donde
al líder del Proyecto prácticamente sólo le importaba cumplir con un alcance inamovible, sino como a
un proceso que toma muy en cuenta el contexto global en que se desenvuelve.

Algo a considerar y tener muy claro el cual nos evitará problemas posteriores en la comprensión de los
siguientes temas, es saber la diferencia entre el alcance del proyecto y alcance del producto del
proyecto.

Mientras que el alcance del Producto del Proyecto se limita exclusivamente al "producto", el alcance
del Proyecto, además de incluir al del producto, incluye todas las actividades necesarias para que el
Proyecto se pueda realizar.

Un ejemplo que nos muestra más claramente esto es el siguiente caso, el alcance del producto de un
proyecto de software, es la media donde se encuentra el programa desarrollado, pero el alcance del
proyecto implica, negociaciones con el cliente, investigación, trámites, juntas, controles, reportes y
cientos de cosas más, que se tienen que hacer para poder generar el producto del proyecto. Todas estas
actividades implican recursos, tiempo, planeación, control, etc., por lo que deben ser consideradas
como parte del alcance del proyecto.

Como se ha mencionado con anterioridad, en la actualidad el enfoque al cliente es primordial para el

sano funcionamiento de los negocios, por lo tanto sería absurdo que el modelo no considerará integrar
ese factor. El cliente es quien manifiesta la necesidad a satisfacer con el proyecto, así como las
funciones y características del producto del proyecto debe tener, con lo que la calidad y el alcance del
producto del proyecto queden definidos.

Por todo lo anterior, el modelo considera que es muy importante tomar en cuenta las variables
relacionadas con la organización que se encargará de llevar a cabo el Proyecto:

 Recursos Humanos
 Comunicación
 Adquisiciones

Hasta aquí se han identificado ocho variables a considerar en la gestión de proyectos, estas ocho
variables PMBOK las nombre como áreas de conocimiento, estas áreas de conocimiento están
íntimamente relacionadas entre sí, es decir, si el alcance cambiará en una de ellas muy probablemente
en las otras también, por lo que para completar y controlar esto al modelo se agregó el área de
conocimiento llamada Integración [ CITATION Mer \l 2058 ].

A continuación se analizarán los procesos que el PMBOK describe para alcanzar los objetivos del
proyecto.

Procesos para la Gestión de Proyectos

La dirección de proyectos es la aplicación de conocimientos, habilidades, herramientas y técnicas a las

actividades del proyecto para cumplir con los requisitos del mismo. La aplicación de conocimientos
requiere de la dirección eficaz de los procesos apropiados.

Un proceso es un conjunto de acciones y actividades interrelacionadas realizadas para obtener un

producto, resultado o servicio predefinido [ CITATION PMI \l 2058 ].

El proceso administrativo de la gestión de proyecto del PMBOK que incluye las siguientes cinco fases,
como se muestra en la imagen.
 Ilustración 15: Procesos de la Gestión de Proyectos.

Como se puede observar que es una secuencia de procesos, primero es el inicio, y le sigue la
planeación, después la ejecución y el proceso que engloba a todos los procesos es el de control.

El proceso de planeación y ejecución se realiza de manera cíclica y todos los procesos son controlados
y monitoreados por el proceso de control como se mencionó anteriormente, que a través de este
proceso se modificará la ejecución cuando esta no se lleve a cabo en base a lo planeado, así también, si
lo planeado ya resulta ser obsoleto, ya sea por una ejecución distinta a lo planeado o porque las
circunstancias del proyecto han cambiado, la planeación cambiará por influencia del control. Por
último, a través del control, sabremos que se han logrado las necesidades y expectativas del proyecto,
por lo que el proyecto se podrá dar por terminado.

Los Procesos de la gestión de proyectos se vinculan entre sí a través de los resultados que producen.
Los grupos de procesos rara vez son eventos separados o únicos; puestos que son actividades
superpuestas que tienen lugar a lo largo de todo el proyecto. La salida de un proceso normalmente se
convierte en la entrada para otro proceso o es un entregable del proyecto. El Grupo del Proceso de
Planificación suministra al Grupo del Proceso de Ejecución el Plan para la Dirección del Proyecto y los
documentos del proyecto y, conforme el proyecto avanza, a menudo exige actualizar el plan para la
dirección del proyecto y dichos documentos. La siguiente ilustración muestra cómo interactúan los
grupos de procesos y muestra el nivel de superposición en distintas etapas. Cuando el proyecto está
dividido en fases, los grupos de procesos interactúan dentro de cada fase [ CITATION PMI \l 2058 ].

Ilustración 16: Procesos Interactuando con las fases

del Proyecto
Lo que nos muestra la imagen es que en la realidad frecuentemente lo que sucede es la ejecución se dé
antes que la planeación haya sido finalizada, esto no quiere indicar que se ejecutará algo que aún no
este planeado, sino más bien que lo que se va planeando se puede ir ejecutando.

Subprocesos para la Gestión de Proyectos

Imagínense que se va a construir una computadora. Como se conoce, éste proceso requiere de muchos
componentes CHIPS, Memorias, Placas, resistores, etc. Además, requiere de un proceso de
construcción especial y herramientas especiales para este proceso. A semejanza de la construcción de la
computadora, los proyectos también involucran una gran cantidad de componentes que requieren de un
proceso de utilización especial y herramientas propias para este proceso.

Al momento de conseguir los componentes y vas y vas de un lugar a otro según te acuerdas de lo que
necesitas, probablemente estarías dando una gran cantidad de vueltas innecesarias y seguramente algún
componente se te olvidaría, en cambio si haces una lista en donde agrupas los componentes de acuerdo
a una clasificación de en dónde los encontrarás, te ahorrarás mucho tiempo y será muy difícil que algo
se te olvide.

En los proyectos es casi igual. La lista de los componentes de los proyectos no es otra que las Áreas de
Conocimiento y sus subprocesos, es el desglose de cada tipo de componente.

La construcción de la computadora puede realizase construyendo componentes por separado y después

irse integrando a los demás en un orden específico.

En los proyectos sucede exactamente lo mismo. La el diseño, manuales, guías que indica el cómo, no
es otra que el proceso Administración de Proyectos. Por ejemplo, durante el proceso de planeación,
habrá que usar algunos de los componentes de diferentes Áreas de Conocimiento y ensamblarlos de
acuerdo a una secuencia muy específica indicada en la imagen siguiente.

Si este procesos de construcción se realizase por primera, seguramente seguirían los a gran detalle las
indicaciones de los manuales y demás documentos de los componentes, sin hacer grandes cambios. Por
otra parte, si su experiencia fuera muy sólida, seguramente se atreverían a hacer cambios significativos,
con la seguridad de que con ello seguramente se mejoraría el diseño de la computadora otorgándole un
mejor desempeño.

Veamos ahora una breve descripción de cada una de las FASES de nuestra "Guía de Proyecto" que
representa el cómo los componentes serán agregados uno a uno en el momento indicado. En nuestra
Guía, los COMPONENTES están representados por los subprocesos de las Áreas de Conocimiento
mientras que la Guía se refiere a los subprocesos de las fases del Proceso de Administración de
Proyectos.
 Ilustración 16 Interacciones entre Procesos y Subprocesos

Introducción a los Procesos y Subprocesos del PMBOK

Inicio
Este proceso contiene dos subprocesos, como se muestran en la imagen. El proceso de inicio está
compuesto por aquellos subprocesos realizados para definir un nuevo proyecto o una nueva fase de un
proyecto ya existente, mediante la obtención de la autorización para comenzar dicho proyecto o fase.
Dentro de los procesos de iniciación, se define el alcance inicial y se comprometen los recursos
financieros iniciales. Se identifican los interesados internos y externos que van a interactuar y ejercer
alguna influencia sobre el resultado global del proyecto (10.1). Si aún no fue nombrado, se seleccionará
el director del proyecto. Esta información se plasma en el acta de constitución del proyecto (4.1) y
registro de interesados. Cuando el acta de constitución del proyecto recibe aprobación, el proyecto se
considera autorizado oficialmente

Ilustración 17 Proceso de Inicio

La numeración utilizada en estos diagramas, corresponde al número del Área de Conocimiento con la
que se está relacionando el proceso. En este caso, el 4.1 indica que éste es el primer subproceso del área
de conocimiento de integración y 10.1 el primer subprocesos del área de conocimiento de
comunicación.

Cada uno de los subprocesos implica una serie de entradas, técnicas y herramientas para ejecutar los
subprocesos y una serie de entregables tal y como se ilustra en el siguiente diagrama.

A continuación se describirán las entradas, herramientas, técnicas y entregables principales que se

utilizan con mayor frecuencia en un proyecto de la vida real, en la guía de PMBOK se describen a
detalle todas estas.

Planeación

Desde el punto de vista administrativo, la planeación es quizá la parte más importante del Proyecto,
debido a que se pretende realizar algo que no se ha hecho antes y es la sección en donde se encuentran
involucrados más procesos. En este proceso es donde establece el alcance total del esfuerzo, definir y
refinar los objetivos y desarrollar la línea de acción requerida para alcanzar dichos objetivos.

Ilustración 18 Procesos de Planeación

Como parte de los procesos principales, lo primero es la Planeación del Alcance, para la cual entre
otros, requeriremos como entrada la oficialización del proyecto, que se le conoce como acta de
constitución o acta constitutiva del proyecto, que a su vez es el principal producto de la fase de inicio.

A través de la técnica de análisis de proyecto desarrollaremos un plan estratégico del proyecto que
resumiremos en un documento denominado Declaración del Alcance, y que representa la principal
salida de este subproceso.

Después de haber planeado el alcance, podremos llevar a cabo el subproceso de Desarrollo del Alcance,
el cual consiste en construir una Estructura de Desglose del Trabajo, mejor conocida como WBS, por
sus siglas en inglés que significan Work Breakdown Structure.

A partir de la WBS podremos, en paralelo, comenzar la planeación de tiempo, costo y riesgo con la
definición de las actividades, la identificación de recursos y la planeación de la Administración del
riesgo respectivamente, para, posteriormente, continuar con el resto de los subprocesos tanto
principales como de soporte de cada una de las Áreas de conocimiento, integrándolas finalmente en el
Plan de Administración del proyecto.
Ilustración 19 Grupo del Proceso de Planeación
Ejecución

Desde el punto de vista del proceso de Administración de la Administración de Proyectos, el proceso de

ejecución es bastante simple. Implica un solo proceso principal que consiste en hacer en forma integral
lo que dijiste que ibas a hacer en el proceso de planeación. Si planeaste correctamente, el proceso de
ejecución te dará muchos menos problemas que si no lo hiciste.

Este grupo de proceso implica coordinar personas y recursos, así como integrar y realizar las
actividades del proyecto de conformidad con el plan para la dirección del proyecto.

Ilustración 20 Grupo del Proceso de Ejecución

Algunos de los elementos importantes de este proceso incluyen las juntas de revisión de avance, las
requisiciones, selección de proveedores y la Administración de contratos.

Seguimiento y Control

Al igual que en los procesos de planeación, las actividades de control tienen que ver con prácticamente
todas las áreas de conocimiento en donde se incluyen los procesos requeridos para supervisar, analizar
y regular el progreso y el desempeño del proyecto, para identificar áreas en las que el plan requiera
cambios y para iniciar los cambios correspondientes.

El beneficio clave de este grupo de procesos radica en que el desempeño del proyecto se observa y se
mide de manera sistemática y regular, a fin de identificar variaciones respecto del plan para la dirección
del proyecto.
 Ilustración 21 Procesos de Seguimiento y Control

Entre los principales entregables de este proceso tenemos los reportes de desempeño, la aceptación
formal de los productos intermedios del proyecto, planes actualizados y acciones correctivas.

Cierre

Los subprocesos de cierre son sólo dos y los principales entregables son contratos y proyectos cerrados
así como lecciones aprendidas.

Está compuesto por aquellos procesos realizados para finalizar todas las actividades a través de todos
los grupos de procesos de la dirección de proyectos, a fin de completar formalmente el proyecto, una
fase del mismo u otras obligaciones contractuales.
 Ilustración 22 Procesos de Cierre

A continuación se describen a más detalle cada una de los entregables y subprocesos más importantes
de los procesos que PMBOK identifica.

Inicio del Proyecto

Fase Conceptual

Antes de que un proyecto empiece a tomar forma, pasa por una fase conceptual en la que sólo se
manejan ideas. Desde el punto de vista de las organizaciones, oficialmente ni siquiera se considera que
el proyecto existe, sin embargo esta es una fase por la que todo proyecto pasa y durante la que hay
varias cosas que hacer antes de que el proyecto realmente nazca.

Antes de iniciar un proyecto deberemos asegurarnos que estamos escogiendo los adecuados.
Seguramente hay muchas cosas buenas que se pueden hacer, sin embargo, como los recursos son
limitados y no hay suficientes para llevar realizar todos los proyectos, por lo que tenemos que ser muy
cuidadosos en seleccionar correctamente los que llevaremos a cabo. Hay que proponer aquellos
proyectos que están de alienados al plan estratégico de la organización. Imagina que estas en una
empresa que se dedica a vender computadoras pero un vendedor decide también vender también
muebles, probablemente sea una buena idea pero si no está alineada a la estrategia de la empresa esta
no rendirá las ganancias que se esperan y probablemente pierda su empleo. En tal caso se deberá hablar
con los gerentes o directores y presentar una propuesta bien formulada.

En los proyectos que sugerimos no podemos ir en contra del plan estratégico de la organización se
debe de trabajar en conjunto, persiguiendo el mismo objetivo, el cual ha sido plasmado en el Plan
Estratégico de la organización.
 Descripción del Proyecto.

Para iniciar un proyecto lo primero que se debe de realizar es describir el producto que se quiere
obtener. En esta descripción se documentan las características del producto o servicio al que se
compromete el proyecto, así como los beneficios que estén generará

Se incluyen los siguientes puntos:

 Título
 Propósito
 Composición
 Origen / Fuente
 Formato y/o presentación
 Recursos asignados
 Criterio de calidad
 Tipo de verificación de calidad e inspectores requeridos

Análisis de Facti bilidad

El análisis de factibilidad de proyectos es un proceso complejo, El análisis de factibilidad responde

principalmente a dos preguntas:

1. ¿Se puede hacer o construir? y

2. ¿vale la pena?

Para contestar, la segunda pregunta hay que preguntarse varias más, las cuales se muestran en la tabla a
continuación.

Pregunta Pregunta La responde…

¿Se puede hacer o construir? Análisis de Factibilidad Técnica
¿Vale la pena?
¿Es rentable? Análisis de Factibilidad Económica
¿Se pueden obtener los recursos económicos? Análisis Financiero
¿Y qué pasa si…? Análisis de Riesgo / Sensibilidad
¿Está alineado a la estrategia?, ¿Es legal?, ¿Es Análisis de otros factores (varios de
ético? , ¿Lo quiero hacer? los cuales son subjetivos) que
Influyen en la decisión.
Considerando todo lo anterior, ¿Cuál opción es la Análisis de Opciones
mejor?
Tabla 7 Ejemplo Análisis de Factibilidad

Una vez realizado estos análisis y en caso de que las respuestas respondan de manera que si se realice
el proyecto se puede dar inicio al proyecto.
 Proceso de Autorización de Proyectos

Adicionalmente, para pasar por el proceso de autorización del proyecto, durante la fase conceptual se
deberán generar los documentos que justifican la idea, entre los que se encuentran el análisis de
factibilidad.

El hecho de haber contestado afirmativamente a todas las respuestas del análisis de factibilidad, no
garantiza que el proyecto se llevará a cabo. Antes, habrá que hacer conocer a la organización esos
beneficios y pasar por muchas veces un largo proceso de autorización.

Para hacer más fácil este proceso, el apoyo de un “Sponsor” con la suficiente autoridad “Poder”, será
esencial para que la idea sea comprada por la organización y el proyecto sea autorizado.
Cuando el proyecto es de una compañía externa, esta parte del proceso es parte del proceso de venta.

Identi fi cación y Clasifi cación de los Grupos de Interés

Desde la fase conceptual se deben identificar necesidades y expectativas de los grupos de interés que
participarán en el proyecto, para asegurar que cuando se defina el alcance estará alineado con ellas, y
de no ser así, hacer lo necesario para alinear esas necesidades y expectativas con los alcances o
viceversa.

Es conveniente que una vez que se identifica a los grupos de interés se les clasifique en función del
impacto positivo o negativo que tengan con relación al proyecto, y por otra en función del control que
el equipo encargado de administrar el proyecto sobre los grupos de interés como se ejemplifica en la
matriz a continuación.

De esta forma, podremos saber lo que habrá que hacer con los grupos de interés. Por ejemplo, si hay un
grupo de interés que esté en contra del proyecto y nosotros tenemos alto control sobre él, estaremos en
posibilidad de hacer que apoye al proyecto ya sea por convencimiento o a la fuerza, en cambio, si
nuestro nivel de control para con ese grupo de interés es bajo, nos veremos obligados a establecer
planes de contingencia para saber qué hacer en caso de que decida atacarnos.

Tabla 2Matriz de Impacto y Control

Impacto del Grupo de Interés Matriz de Impacto y Control

Alto  Mitigar el impacto o Mayor  Implantación de Sistemas de
Control Control
 Dividir en sus componentes
 Desarrollo de planes de
contingencia con rutas
alternas, sistemas de
monitoreo y disparadores de
acciones al inicio del riesgo
 Ignorar  Control donde se justifique.
 No enfocarse a éstos solo
porque son elementos
controlables
Bajo Bajo Alto
Nivel de Control
 Asignación del líder del Proyecto

Lo ideal es que el líder del proyecto sea asignado desde las fases iniciales del mismo, dde este modo
estará totalmente involucrado en el proyecto.

La realidad es que no siempre se da esta situación ideal, con frecuencia los proyectos son liderados por
personas que no son los autores de la idea original, sino que son asignados para administrar la idea de
alguien más.

El líder de proyecto asignado, profundizará en la comprensión de la idea y de las razones que han
justificado que esa idea se convierta en proyecto oficial, además, deberá comprometerse con ella y si no
es así, deberá ser lo suficientemente honesto para rechazar el cargo de liderar un proyecto del cual no
está totalmente convencido, ya que si lo acepta bajo estas condiciones los resultados probablemente
serán pobres o diferentes a los del objetivo original del proyecto o en el peor de los casos ni se alcance.

En algunos proyectos, lo adecuado es que entre una fase y otra se cambie de líder, por ejemplo: en un
proyecto para un nuevo producto, puede tener un muy buen líder que se encargue de construir la
arquitectura de hardware de una computadora, sin embargo es probable que ese mismo líder no tenga
las habilidades para lanzar el producto al mercado.

También, los proyectos deben estar preparados para cambiar de líder en cualquier instante. Las
organizaciones son dinámicas y es común que los líderes de los proyectos sean reasignados a otras
responsabilidades o cambien de compañía, por esta razones es de suma importancia que se documente
con orden y claridad el conocimiento que se tiene de los antecedentes y avance del proyecto, para que
se dé una transferencia del puesto de líder con la mayor facilidad, rapidez y efectividad posible.

Elementos Relevantes de la Fase de Inicio.

Acta de Consti tución del Proyecto

El acta de constitución que en ingles se le denomina Project Charter establece una relación de
cooperación entre la organización ejecutante y la organización solicitante (o cliente, en el caso de
proyectos externos). El proyecto se inicia formalmente con la firma del acta de constitución del
proyecto aprobada. Se selecciona y asigna un gerente de proyecto tan pronto como sea posible, de
preferencia durante la elaboración del acta de constitución del proyecto, pero siempre antes de
comenzar la planificación.

Principalmente se persiguen los siguientes objetivos con el acta de constitución:

 Da Legitimidad al Gerente de Proyecto.
 Asegura el apoyo de otros Gerentes.
 Indican las responsabilidades y autoridad que se le otorga al líder del proyecto.
 Marca el final de la fase conceptual reconociendo la existencia formal del proyecto.
 Incluyen los requerimientos del negocio y la Descripción del producto del proyecto.
Para que este documento tenga la validez que requiere, es importante involucrar a una figura que está
siempre presente en los proyectos. Sin ser el que lo administra directamente, (actividad que le
corresponde al Líder o Gerente del Proyecto) el patrocinador “Sponsor” tiene recursos y poder en la
organización, que a través de este documento, proporcionará al Gerente del Proyecto, siempre y cuando
justifique que son necesarios. Sin un patrocinador, es decir sin poder, el que un proyecto salga adelante
es muy difícil.

En la preparación del documento de constitución formal, se deben hacer las siguientes consideraciones:

 El “Patrocinador” del Proyecto selecciona al Gerente de Proyecto.

 El Gerente de Proyecto participa en el documento.
 El “Patrocinador” del Proyecto firma el documento.

Ejemplo de Acta de Consti tución de un Proyecto (Project Charter)

Como parte de un nuevo contrato a manejar en CONSULTORÍA DE DESARROLLOS DE

SOFTWARE EMPRESARIALES para CASA DE BOLSA INTERNACIONAL, se ha asignado al Ing.
Antonio Castro Lopez como líder del proyecto Implementación del Sistema de Software de
Priorización de Iniciativas. Por parte de Casa de bolsa internacional, el Lic. Augusto Ferras Medellín
será el contacto oficial y líder de proyecto por el cliente. El Ing. Antonio Castro Lopez será responsable
de coordinar los esfuerzos para ayudar al cliente a definir e implementar el plan motivo de este
proyecto.
Es responsabilidad de cada departamento de CONSULTORÍA DE DESARROLLOS DE SOFTWARE
EMPRESARIALE contribuir con el Ing. Antonio Castro Lopez para sacar adelante a este proyecto y
garantizar un servicio de calidad a nuestro cliente. En caso de identificar algún conflicto de prioridades,
deberá ser notificado de inmediato para definir la mejor solución.

Entre las responsabilidades Ing. Antonio Castro Lopez están las siguientes:

 En estrecha colaboración con la Dirección General definir la estrategia a seguir

 Integrar todos los recursos que se requieran para el desarrollo de este proyecto
 Ayudar al cliente a desarrollar el plan de este proyecto
 Asegurar que las lecciones aprendidas durante este proceso, se compartan con todo aquel en
esta organización que lo necesite
 Emitir un reporte mensual de avance de la implantación del plan, así como de los beneficios
obtenidos a esa fecha
 Coordinar el diagnóstico de la situación actual de la empresa del cliente
 Asegurar que los trabajos se desarrollen de acuerdo a las fechas acordadas, dentro del
presupuesto y conforme a las especificaciones
 Asegurar que cada miembro del equipo del proyecto conoce y está comprometido con sus
responsabilidades
  Mantener la información del proyecto actualizada
 El Ing. Antonio Castro Lopez tiene la autoridad de solicitar a todos los miembros de la
organización de su colaboración para dar un servicio satisfactorio al cliente. Incluyendo:
 Solicitar soporte a los departamentos de CONSULTORÍA DE DESARROLLOS DE
SOFTWARE EMPRESARIALES
 Convocatorias a juntas
 Contratar suministro de productos o servicios siempre y cuando no se sobre utilice el
presupuesto
 Acceso directo a toda la información que requiera para el desarrollo de este proyecto
 Ejercer gastos que no sobrepasen el presupuesto asignado a este proyecto
 Cambiar planes siempre y cuando no impacten los resultados, o sean debidamente autorizados
 Negociar recursos humanos, materiales y económicos tanto interna como externamente
 Tomar decisiones que involucren a varios departamentos y niveles de la organización
 Autoridad para delegar funciones

Invitamos a dar lo mejor de nosotros para que juntos contribuyamos al éxito de tan importante
proyecto.

________________
Ing. Luis Alcázar
Gerente de Planeación - CASA DE BOLSA INTERNACIONAL

Planeación.

Está compuesto por aquellos procesos realizados para establecer el alcance total del esfuerzo, definir y
refinar los objetivos, y desarrollar la línea de acción requerida para alcanzar dichos objetivos. Los
procesos de planificación desarrollan el plan para la dirección del proyecto y los documentos del
proyecto que se utilizarán para llevarlo a cabo.

La fase de planeación comienza una vez terminado el proceso de inicio con la autorización del Acta de
Constitución Formal del Proyecto. Como ya se ha comentado anteriormente, la fase de Planeación, es
la fase que contiene más elementos que cualquiera de las otras fases que menciona PMBOK.

Objetivos de la Fase de Planeación

 Generar un plan integral a través de planes específicos de cada una de las áreas de conocimiento
de la Administración de Proyectos.
  Tener un punto de referencia para comparar los resultados obtenidos a lo largo de la ejecución
del proyecto.
 Asegurar que los grupos de interés conocen y están de acuerdo con sus responsabilidades en el
mismo.
 Asegurar que el alcance específico del proyecto satisfacerá necesidades y expectativas de los
grupos de interés.

Contenido de un Plan de Proyecto

Este documento consiste en documentar las acciones necesarias para definir, preparar, integrar y
coordinar todos los planes subsidiarios. El plan para la dirección del proyecto se convierte en la fuente
primaria de información para determinar la manera en que se planificará, ejecutará, supervisará y
controlará, y cerrará el proyecto.

Al concluir la fase de planeación deberemos haber desarrollado el plan integral de gestión de proyecto,
en el que este deberá contener los siguientes puntos:

 Recopilar Requisitos
 Directorio
 Descripción actualizada del Producto del Proyecto.
 Acta de Constitución Formal del Proyecto (Project Charter)
 Plan Estratégico del Proyecto
 Definición del Alcance
 Estructura de Desglose del Trabajo (EDT)
 Definición de Actividades
 Secuenciar Actividades
 Estimar Recursos de las actividades
 Estimar Duración de las actividades
 Desarrollar Cronograma
 Estimados de costo
 Determinar el Presupuesto
 Plan de Calidad
 Plan de Recursos Humanos
 Plan de Comunicación
 Identificación de Riesgos
 Análisis cualitativo de riesgos
 Análisis cuantitativo de riesgos
 Respuesta a los riesgos
 Plan de Adquisiciones

A continuación se describen cada uno de los elementos anteriormente mencionados.

Directorio .

Este documento contiene los datos más importantes de los integrantes del grupo de interés del proyecto.
  Nombre completo
 Posición
 Participación en el proyecto
 Datos para localizarle (nombre secretaria, horario, celular, e-mail, etc.).

Descripción actualizada del Producto del Proyecto

Este es un elemento de la fase de inicio, que se toma como referencia para la fase de planeación, por
otra parte durante la planeación se ha cuenta con nueva información que deberá actualizarse para
enriquecer la información del documento original.

Acta de Consti tución Formal del Proyecto (Project Charter)

Este documento también es un elemento de la fase de inicio, es como el acta de nacimiento del
proyecto, lo que lo hace un documento relevante, que debe ser considerado como base para la
planeación, ya que este contiene la autorización formal del inicio del proyecto.

Plan Estratégico del Proyecto

La mayoría de los proyectos son procesos engorrosos y para su comprensión es necesario separar cada
uno de sus componentes mayores, a tal grado que, cada uno de los elementos inferiores se pueda
entender con mayor facilidad.

Por lo anterior, una de las herramientas del subproceso de planeación del alcance del proyecto incluye
técnicas de análisis del producto del proyecto, que como todo análisis consisten en separar al producto
del proyecto en elementos que se puedan entender por si solos.

Entre esas técnicas en el PMBOK se mencionan:

 Ingeniería de Sistemas
 Ingeniería de Valor
 Análisis de Valor
 Análisis de Funcionamiento
 Análisis de las Funciones de Calidad (Quality Function Deployment QFD)

Un tipo de análisis que nos ayuda a la definición del plan estratégico del proyecto, el cual puede en
parte definirse desde la fase de inicio, pero que se viene a consolidar precisamente en la planeación del
alcance.
PMBOK no describe el proceso de realización de esta técnica, a continuación se describe de manera
rápida esta técnica.

Este plan sigue prácticamente los mismos principios que la planeación estratégica de una organización.
Con unos pequeños ajustes a esos principios, se puede adaptar bastante bien a un proyecto. Por otra
parte al desarrollar un plan estratégico para el proyecto, tanto el líder como los integrantes del equipo
de proyecto tienen la oportunidad de analizar el proyecto no sólo en cuanto a su alcance sino en general
en todo el contexto bajo el que se llevará a cabo.

Un Plan Estratégico puede incluir: visión, misión, objetivos, estrategias, fortalezas, debilidades, riesgos
y oportunidades. En un principio, es recomendable considerar al menos las primeras cuatro.

Visión

Nos representa la imagen de lo que será el proyecto en el futuro, la visión se puede definir proyectando
al proyecto una vez finalizado y que fue exitoso, entonces se describe lo que uno está proyectando de
dicho proyecto.

Se puede considerar que una buena definición de una visión debe de contener las siguientes
características:

 Motivadora
 Fácil de recordar y repetir
 Indica el rumbo y no necesariamente la meta. La Visión de un proyecto aunque describe un
punto en el tiempo más allá de que el proyecto haya terminado, si puede indicar un cierto logro
específico y no únicamente el rumbo.

Ejemplo:

La Visión de un proyecto podría ser: “Desarrollo de un sistema de software de geo localización móvil
por voz para personas con personas con poca visión”.

Misión

Representada y comúnmente se le describe como la razón de existir del proyecto , es decir, se debe de
entender el para qué existe el proyecto.

Por ejemplo la misión del ejemplo anterior seria lo siguiente:

 Satisfacer las necesidades de localización para personas incapacitadas de la vista.

 Prevenir accidentes
 Prevenir desorientación a personas discapacitadas de la vista.

Objeti vos
Los objetivos es cada uno de los puntos que se deben cumplir o alcanzar para lograr la misión. Por otra
parte hay que validar nuestros objetivos, recordando que estos deben ser "SMART", esto es:

 Simples
 Medibles
 Alcanzables
 Retantes
 y en un marco de Tiempo
Los objetivos del ejemplo que estamos utilizando serían los siguientes:

 No sobrepasar el presupuesto de $100,000.00MN

 Iniciar el proyecto el 5 de marzo 2010
 El sistema de reconocimiento de voz debe de reconocer el idioma español con sus modismos.
 La aplicación debe de funcionar en sistemas Android, Windows Phone e IOS.

Metas
A su vez, los objetivos se pueden subdividir en Metas, que son los pasos a cumplir para poder alcanzar
los objetivos estos deben de establecer de manera secuencial para su realización.

Para el ejemplo anterior la meta del objetivo “El sistema de reconocimiento de voz debe de reconocer
el idioma español con sus modismos”, sería el siguiente:

 Investigar los SDK de Reconocimiento de Voz para cada ambiente, diseñar los algoritmos,
desarrollo de los algoritmos de reconocimiento de voz, etc.

Estrategias

Establece la forma general para alcanzar la visión, mientras que los objetivos se refieren al que, las
estrategias se refieren al cómo.

Tácti cas

De la misma forma que los objetivos se subdividen en metas, las estrategias lo hacen en tácticas, que
son las formas específicas para cumplir con las estrategias.

Defi nición del Alcance

La declaración del alcance del proyecto describe de manera detallada los entregables del proyecto y el
trabajo necesario para crear esos entregables. La declaración del alcance del proyecto también
proporciona un entendimiento común del alcance del proyecto entre los interesados en el proyecto. Esta
declaración puede contener exclusiones explícitas del alcance, que pueden ayudar a gestionar las
expectativas de los interesados. Esto permite al equipo del proyecto realizar una planificación más
detallada, sirve como guía del equipo de trabajo durante la ejecución y proporciona la línea base para
evaluar si las solicitudes de cambio o de trabajo adicional se encuentran dentro o fuera de los límites
del proyecto.

La declaración detallada del alcance del proyecto incluye, ya sea directamente o por referencia a otros
documentos, lo siguiente:

 Una descripción del alcance del producto:

Elabora gradualmente las características del producto, servicio o resultado descrito en el acta de
constitución del proyecto y en la documentación de requisitos.
 Los criterios de aceptación del producto:
Definen el proceso y los criterios para la aceptación de los productos, servicios o resultados
completados.
 Los entregables del proyecto:
Incluyen tanto las salidas, que abarcan el producto o servicio del proyecto, como los resultados
auxiliares, tales como los informes y documentación generados por el proceso de dirección del
proyecto. Los entregables pueden describirse de manera resumida o muy detallada.
 Las exclusiones del proyecto:
Por lo general, identifican lo que está excluido del proyecto. Establecer explícitamente lo que está fuera
del alcance del proyecto ayuda a gestionar las expectativas de los interesados.
 Las restricciones del proyecto:
Enumera y describe las restricciones específicas asociadas con el alcance del proyecto que limitan las
opciones del equipo, como por ejemplo, un presupuesto predeterminado, o fechas o hitos del
cronograma impuestos por el cliente o la organización ejecutante. Cuando un proyecto se realiza en
función de un contrato, las disposiciones contractuales constituyen generalmente restricciones. La
información relativa a las restricciones puede incluirse en la declaración del alcance del proyecto o en
un registro independiente.
 Los supuestos del proyecto:
Enumeran y describen supuestos que se realizan específicamente para el proyecto, asociados con el
alcance del proyecto y el impacto potencial de tales supuestos en el caso que fueran falsos. Como parte
del proceso de planificación, los equipos del proyecto identifican, documentan y validan
frecuentemente los supuestos. La información relativa a éstos puede incluirse en la declaración del
alcance del proyecto o en un registro independiente.

Estructura de Desglose del Trabajo EDT (Work Breakdown Structure, WBS)

La Definición del Alcance del Proyecto incluye el proceso necesario para asegurar que el proyecto
contiene todo el trabajo requerido, y sólo el requerido.

La creación de la EDT es el proceso que consiste en subdividir los entregables del proyecto y el trabajo
del proyecto en componentes más pequeños y más fáciles de administrar. La estructura de desglose del
trabajo (EDT) es una descomposición jerárquica, basada en los entregables del trabajo que debe
ejecutar el equipo del proyecto para lograr los objetivos del proyecto y crear los entregables requeridos,
con cada nivel descendente de la EDT representando una definición cada vez más detallada del trabajo
del proyecto. La EDT organiza y define el alcance total del proyecto y representa el trabajo
especificado en la declaración del alcance del proyecto aprobada y vigente.

El trabajo planificado está contenido en el nivel más bajo de los componentes de la EDT, denominados
paquetes de trabajo. Un paquete de trabajo puede ser programado, monitoreado, controlado, y su costo
puede ser estimado. En algunas ocasiones es necesaria una explicación del elemento, a esta explicación
se le denomina diccionario.

El diccionario de la EDT proporciona una descripción más detallada de los componentes de la EDT,
incluyendo los paquetes de trabajo y las cuentas de control. La información del diccionario de la EDT
incluye, entre otros:

 el identificador del código de cuentas

  la descripción del trabajo
 la organización responsable
 una lista de hitos del cronograma
 las actividades asociadas del cronograma
 los recursos necesarios
 los estimados de costo
 los requisitos de calidad
 los criterios de aceptación
 las referencias técnicas
 la información del contrato

En el contexto de la EDT, trabajo se refiere a los productos o entregables del proyecto, que son el
resultado del esfuerzo realizado, y no el esfuerzo en sí mismo.

Ilustración 23 Ejemplo de Estructura de Desglose de Trabajo

Ilustración 1: Ejemplo de Estructura de Desglose de

El nivel de desglose también depende de qué tanto el equipo de trabajo está familiarizado con lo que
hay que hacer. Si es la primera vez que lo vamos a hacer se requerirá una explicación más detallada,
pero si lo hemos hecho muchas veces, con una breve explicación será suficiente.

La EDT no sólo nos sirve para documentar el alcance del proyecto. Es una magnífica herramienta de
comunicación que no debemos menospreciar.

La EDT representa todo el trabajo necesario para realizar el producto o el proyecto, e incluye el trabajo
de gestión del proyecto. El total del trabajo en los niveles inferiores de la EDT debe corresponder al
cúmulo de los niveles superiores, de modo que no se omita nada y que no se efectúe ningún trabajo
innecesario. Esto se denomina a veces la regla del 100 %.

Defi nición de las Acti vidades

El proceso de definición de actividades es el proceso que consiste en identificar las acciones específicas
a ser realizadas para elaborar los entregables del proyecto, la única diferencia es que en la WBS los
elementos quedan descritos por sustantivos, mientras que en la definición de actividades se habla de
verbos o acciones.

Las actividades proporcionan una base para la estimación, planificación, ejecución, seguimiento y
control del trabajo del proyecto. La definición y la planificación de las actividades del cronograma
están implícitas en este proceso, de modo que se cumplan los objetivos del proyecto.

Lo práctico es desglosar un nivel más la WBS para incluir las tareas necesarias para lograr el
entregable.

Ejemplo:

1 Interfaz de voz
1.1 Realización de algoritmos
1.2 Desarrollo de pseudocódigo
1.3 Desarrollo de Código
1.4 Implementación de interfaz

Secuenciar Acti vidades

Secuenciar las Actividades es el proceso que consiste en identificar y documentar las relaciones entre
las actividades del proyecto. La secuencia de actividades se establece mediante relaciones lógicas.
Cada actividad e hito, a excepción del primero y del último, se conecta con al menos un predecesor y
un sucesor.

La secuencia puede establecerse utilizando un software de gestión de proyectos o empleando técnicas

manuales o automatizadas.

Tipos de Precedencias Método de Diagramación por Precedencia (PDM)

El método de diagramación por precedencia (PDM) es utilizado en el método de la ruta crítica (CPM)
para crear un diagrama de red del cronograma del proyecto que utiliza casillas o rectángulos,
denominados nodos, para representar las actividades, que se conectan con flechas que muestran sus
relaciones lógicas. Esta técnica también se denomina actividad en el nodo (AON) y es el método
utilizado por la mayoría de los paquetes de software de gestión de proyectos.
El método de diagramación por precedencia incluye cuatro tipos de dependencias o relaciones lógicas.

 Final a Inicio (FI). El inicio de la actividad sucesora depende de la finalización de la actividad

predecesora.

 Final a Final (FF). La finalización de la actividad sucesora depende de la finalización de la

actividad predecesora.

 Inicio a Inicio (II). El inicio de la actividad sucesora depende del inicio de la actividad
predecesora.

 Inicio a Final (IF). La finalización de la actividad sucesora depende del inicio de la actividad
predecesora.
Adelantos y Retrasos

El equipo de dirección de proyecto determina las dependencias que pueden necesitar un adelanto o un
retraso para definir con exactitud la relación lógica. No deben utilizarse adelantos y retrasos para
sustituir la lógica de la planificación. Deben documentarse las actividades y sus supuestos relacionados.

 Un adelanto permite una aceleración de la actividad sucesora.

Por ejemplo, en un proyecto para la construcción de un nuevo edificio de oficinas, puede planificarse
que el desmonte del terreno comience dos semanas antes de la fecha programada para completar la lista
de pendientes. Esto debe mostrarse como una relación lógica final a inicio, con un adelanto de dos
semanas.

 Un retraso ocasiona una demora en la actividad sucesora.

Por ejemplo, un equipo de redacción técnica puede comenzar a editar el borrador de un documento
extenso quince días después de haber comenzado a escribirlo. Esto puede mostrarse como una relación
lógica inicio a inicio con un retraso de 15 días.

Esti mar los Recursos de las Acti vidades

La estimación de los recursos de las actividades es el proceso que consiste en calcular el tipo y las
cantidades de materiales, personas, equipos o suministros necesarios para ejecutar cada actividad, este
proceso está estrechamente coordinado al proceso de estimación de costos.

Entre los tipos de recursos más comunes encontramos humanos, materiales, económicos, tecnológicos,
financieros, etc.

Al igual que las áreas de conocimiento de la administración de proyectos, todos los recursos deben
considerarse, ya que si alguno de ellos no se tiene (y no se puede substituir por otro), aunque se tengan
los demás el entregable no podrá ser completado.

Una herramienta que nos permite identificar la disponibilidad de los recursos son los llamados
calendarios de recursos en los cuales estos especifican cuándo y por cuánto tiempo estarán disponibles
los recursos identificados del proyecto durante la ejecución del mismo. Esta información puede
proporcionarse a nivel de la actividad o del proyecto. Este conocimiento abarca la consideración de
atributos, tales como la experiencia y/o el nivel de habilidad de los recursos, así como las diferentes
ubicaciones geográficas de las que provienen los recursos y cuándo pueden estar disponibles.
 Esti mación de la Duración de las Acti vidades.

Una vez que terminada la EDT y se hayan identificado los recursos, en paralelo con la secuencia de
actividades, se pude llevar a cabo el subproceso de estimación de la duración de las actividades, la cual
dependerá del nivel de dificultad de la misma, así como el número y la calidad de los recursos. No es lo
mismo que un recurso especializado realice una tarea a que la realicen personas que por primera vez lo
hacen.

Normalmente esta estimación es una aproximación lo más cercana a la real ya que la mayoría de las
veces las duraciones cambian por diversos factores, para ello también contamos con las siguientes
formas de estimación de las duraciones.

Para estimar la duración de las actividades podemos hacer estimados:

 Análogos:
Como su nombre lo indica, los análogos son los que tienen semejanza con otros proyectos, por lo que
podemos decir que el nuestro, considerando las diferencias, durará tanto más o tanto menos que el
semejante.
 Paramétricos:
La estimación paramétrica utiliza una relación estadística entre los datos históricos y otras variables
(por ej., pies cuadrados en la construcción) para calcular una estimación de parámetros de una actividad
tales como costo, presupuesto y duración.
 El juicio de expertos:
Guiado por la información histórica, puede proporcionar información sobre el estimado de la duración
o las duraciones máximas recomendadas, procedentes de proyectos similares anteriores. El juicio de
expertos también puede utilizarse para determinar si es conveniente combinar métodos de estimación y
cómo conciliar las diferencias entre ellos.
 Estimación por Tres Valores:
La precisión de los estimados de la duración de la actividad puede mejorarse tomando en consideración
el grado de incertidumbre y de riesgo de la estimación. Este concepto se originó con la Técnica de
Revisión y Evaluación de Programas (método PERT). El método PERT utiliza tres estimados para
definir un rango aproximado de duración de una actividad:
 Más probable (tM). Es la duración de la actividad, en función de los recursos que
probablemente se asignarán, de su productividad, de las expectativas realistas de
disponibilidad para la actividad, de las dependencias de otros participantes y de las
interrupciones.
 Optimista (tO). La duración de la actividad está basada en el análisis del mejor escenario
posible para esa actividad.
 Pesimista (tP). La duración de la actividad está basada en el análisis del peor escenario
posible para esa actividad.
▪ El análisis según el método PERT calcula una duración Esperada (tE) de la actividad
utilizando un promedio de estas tres estimaciones:
 tE = (tO + 4tM + tP) /6
 Los estimados de la duración basados en esta ecuación (o aun en un promedio
simple de los tres valores) pueden proporcionar una mayor exactitud, y los tres
valores aclaran el rango de incertidumbre de los estimados de la duración.
 Análisis de Reserva:
Los estimados de la duración pueden incluir reservas para contingencias (denominadas a veces reservas
de tiempo o colchones) en el cronograma global del proyecto, para tener en cuenta la incertidumbre
del cronograma. La reserva para contingencias puede ser un porcentaje de la duración estimada de la
actividad, una cantidad fija de periodos de trabajo, o puede calcularse utilizando métodos de análisis
cuantitativos. A medida que se dispone de información más precisa sobre el proyecto, la reserva para
contingencias puede usarse, reducirse o eliminarse. Debe identificarse claramente esta contingencia en
la documentación del cronograma.

Frecuentemente, uno de los medios más seguros para definir la duración de una actividad es preguntar
a quién ejecutará la actividad, casi siempre, es alguien que al menos ha hecho algo similar varias veces,
por lo que más experta que esa persona, es difícil de encontrar.

La mayor parte del software de gestión de proyectos para planificación manejará esta situación
mediante el calendario del proyecto y los calendarios de recursos de periodos de trabajo alternativos
que, por lo general, se identifican por los recursos que requieren periodos de trabajo específicos.
Además de la lógica de secuencia, las actividades se realizarán de acuerdo con el calendario del
proyecto y los calendarios de recursos correspondientes.

Desarrollar el Cronograma

Este es el proceso que consiste en analizar el orden de las actividades, su duración, los requisitos de
recursos y las restricciones para crear el cronograma del proyecto.

La incorporación de las actividades, duraciones y recursos a la herramienta de planificación genera un

cronograma con fechas planificadas para completar las actividades del proyecto. A menudo, el
desarrollo de un cronograma aceptable del proyecto es un proceso iterativo que determina las fechas de
inicio y finalización planificadas para las actividades del proyecto y los hitos. El desarrollo del
cronograma puede requerir el repaso y revisión de los estimados de la duración y de los recursos para
crear un cronograma de proyecto aprobado que pueda servir como línea base con respecto a la cual se
pueda medir el avance. La revisión y el mantenimiento de un cronograma realista continúan a lo largo
del proyecto conforme el trabajo avanza, el plan para la dirección del proyecto cambia y la naturaleza
de los eventos de riesgo evoluciona.

La guía del PMBOK nos propone los siguientes pasos para poder desarrollar un cronograma de manera
eficaz.

 Análisis de la Red del Cronograma:

Este análisis emplea diferentes técnicas analíticas para calcular las fechas de inicio y finalización
tempranos y tardíos para las partes no completadas de las actividades del proyecto, en las que pueden
ser:
 Método de la ruta critica
 Método de la cadena critica
 Nivelación de los recursos
 El análisis ¿Qué pasa si...?
  Aplicación de Adelantos y Retrasos
 Compresión del Cronograma
 Herramienta de Planificación

 Método de la ruta crítica:

Constituye una red que identifica qué actividades son requisito para que después otras se puedan
ejecutar y con la duración determina la fecha más temprana en que el proyecto puede terminar que
equivale a la serie de actividades con mayor duración, a la cual se le llama Ruta Crítica.

Esta es una herramienta muy práctica tanto para la planeación como para el control ya que es muy fácil
de actualizar, porque al modificar una de las actividades, se puede calcular lo que sucederá con todas
las demás. El uso de las computadoras ha dado gran impulso a esta técnica ahora accesible a muy bajo
costo para cualquier tipo de proyecto.

Con este método permitirá que el enfoque sea a las actividades críticas siguiendo uno de los principios
básicos de la Administración de Proyectos, "la optimización de los recursos", ya que dirige su esfuerzo
a lo más importante no desperdiciando recursos en lo menos significativo.

A través de la Técnica de Ruta Crítica podemos determinar además, la holgura que tienen el resto de las
actividades, lo que nos permite conocer la flexibilidad con que contamos en cada una de ellas.

 Método de la cadena critica:

La cadena crítica es una técnica de análisis de la red del cronograma que permite modificar el
cronograma del proyecto para adaptarlo a los recursos limitados. Inicialmente, el diagrama de red del
cronograma del proyecto se elabora mediante los estimados de la duración, con las dependencias
requeridas y las restricciones definidas como entradas. Entonces se calcula la ruta crítica. Una vez que
se ha identificado la ruta crítica, se ingresa la disponibilidad de recursos y se determina el resultado del
cronograma con recursos limitados. A menudo, el cronograma resultante presenta una ruta crítica
modificada. La ruta crítica con restricciones de recursos se conoce como cadena crítica

 Nivelación de Recursos:
La nivelación de recursos es una técnica de análisis de la red del cronograma que se aplica a un
cronograma que ya ha sido analizado por medio del método de la ruta crítica. La nivelación de recursos
puede utilizarse cuando los recursos compartidos o críticos necesarios sólo están disponibles en ciertos
momentos o en cantidades limitadas, o para mantener la utilización de recursos en un nivel constante.
La nivelación de recursos es necesaria cuando los recursos han sido sobre asignados.

 Análisis “¿Qué pasa si…?”:

Éste es un análisis de la pregunta “¿Qué pasa si se produce la situación representada por el escenario
‘X’?” Se realiza un análisis de la red del cronograma, usando el cronograma para calcular los diferentes
escenarios, tales como un retraso en la entrega de un componente principal, la prolongación de la
duración de un diseño específico o la introducción de factores externos, como una huelga o un cambio
en el procedimiento para la obtención de permisos. Los resultados del análisis del escenario “Qué pasa
si…” pueden usarse para evaluar la viabilidad del cronograma del proyecto bajo condiciones adversas,
y para preparar planes de contingencia y respuesta para superar o mitigar el impacto de situaciones
inesperadas.

 Aplicación de Adelantos y Retrasos:

Los adelantos y retrasos son refinamientos que se aplican durante el análisis de la red para desarrollar
un cronograma viable.

 Compresión del Cronograma:

La compresión del cronograma reduce el calendario del proyecto sin modificar el alcance del mismo,
para cumplir con las restricciones del cronograma, las fechas impuestas u otros objetivos del
cronograma. Las técnicas de compresión del cronograma incluyen:

 Compresión:
La compresión de redes implica asignación de recursos adicionales que hagan que el proyecto termine
más rápido.
El proceso a seguir es el siguiente:
 Se elige a las actividades que estén en la Ruta Crítica
 Se obtiene su pendiente de costo y tiempo, en otras palabras, se identifica que actividades
cuesta menos reducirlas el mismo tiempo que otras.
 Se inicia la compresión de las actividades con menor pendiente de costo.
 Se continúa hasta llegar al límite de tiempo requerido.
 Si se comprimen todas las actividades hasta su mínimo tiempo, se obtiene el Crash-Point del
proyecto
 Se debe revisar en cada compresión, la posibilidad de que surja otra ruta crítica

En la compresión de redes habrá que tener especial cuidado en:

 Que los recursos que se agreguen estén preparados para la tarea por desarrollar, ya que de
no ser así, puede tomar mucho más tiempo prepararlos que el tiempo que podrían ahorrar.
 Además, no se deberán agregar más recursos de los necesarios, ya que demasiados recursos
en vez de ayudar entorpecen y lo que finalmente obtendríamos sería un proyecto que en vez
de durar menos dura más, y para colmo también cuesta más.
 Ejecución rápida (Fast Tracking):
 Consiste en modificar la secuencia lógica de las actividades, empezando por las actividades
subsecuentes, antes que las predecesoras se hayan completado. En otras palabras se
traslaparan actividades. El traslape de las actividades casi siempre implica un riesgo, el cual
habrá que considerar, porque muchas veces este riesgo hace que en vez de concluir antes,
terminemos más tarde que si no hubiéramos realizado el traslape de las actividades.
 Herramienta de Planificación:
Las herramientas automatizadas de planificación aceleran el proceso de planificación, generando fechas
de inicio y finalización basadas en las entradas de actividades, los diagramas de red, los recursos y las
duraciones de las actividades. Una herramienta de planificación puede utilizarse conjuntamente con
otro software de gestión de proyectos, así como con métodos manuales.
 Ilustración 25 Cronograma de Proyecto

El cronograma del proyecto debe contener, como mínimo, una fecha de inicio y una fecha de
finalización programadas para cada actividad. Si la planificación de recursos se realiza en una etapa
temprana, entonces el cronograma mantendrá su carácter preliminar hasta que se hayan confirmado las
asignaciones de recursos y se hayan establecido las fechas de inicio y finalización planificadas.

El cronograma del proyecto puede presentarse en forma de resumen, denominado a veces cronograma
maestro o cronograma de hitos, o presentarse en forma detallada. Aunque el cronograma del proyecto
puede tener forma de tabla, se presenta más a menudo en forma gráfica, utilizando uno o más de los
siguientes formatos:

 Diagramas de hitos. Estos diagramas son similares a los diagramas de barras, pero sólo
identifican el inicio o la finalización programada de los principales entregables y las interfaces
externas clave.
 Diagramas de barras. Estos diagramas, con barras que representan las actividades, muestran
las fechas de inicio y finalización de las actividades, así como las duraciones esperadas. Los
diagramas de barras son relativamente fáciles de leer y se utilizan frecuentemente en
presentaciones de dirección.
 Diagramas de red del cronograma del proyecto. Estos diagramas, con la información de la
fecha de las actividades, normalmente muestran la lógica de la red del proyecto y las
actividades del cronograma que se encuentran dentro de la ruta crítica del proyecto. Estos
diagramas pueden presentarse con el formato de diagrama de actividad en el nodo, o con el
formato de diagrama de red del cronograma en escala de tiempo, que a veces se denomina
diagrama lógico de barras.

Adicionalmente se deben de incluir en el desarrollo del cronograma, algunas características muy

importantes para poder controlar el cronograma las cuales son las siguientes:

 Línea base del Cronograma:

La línea base del cronograma es una versión específica del cronograma del proyecto desarrollada a
partir del análisis de la red del cronograma. El equipo de dirección del proyecto la acepta y aprueba
como la línea base del cronograma, con fechas de inicio y fechas de finalización de línea base, es decir
a partir de cuándo se podrá medir el proyecto, esta línea base nos permitirá calcular las varianzas del
proyecto como en costo, tiempo y recursos.

 Datos del Cronograma:

Los datos para el cronograma del proyecto abarcan, por lo menos, los hitos del cronograma, las
actividades del cronograma, los atributos de las actividades y la documentación de todos los supuestos
y restricciones identificadas. La cantidad de datos adicionales varía según el área de aplicación. La
información suministrada frecuentemente como detalles de soporte incluye, entre otras:

 Los requisitos de recursos por periodo de tiempo, a menudo presentados en el formato de un

histograma de recursos
 Los cronogramas alternativos, tales como el mejor o el peor escenario, sin nivelación de
recursos, con nivelación de recursos, con o sin fechas impuestas.
 La planificación de las reservas para contingencias.

Los datos del cronograma también podrían abarcar elementos tales como histogramas de recursos,
proyecciones del flujo de caja y cronogramas de pedidos y entregas.

 Actualizaciones a los Documentos del Proyecto:

Entre los documentos del proyecto que pueden actualizarse, se incluyen:

 Requisitos de recursos de la actividad. La nivelación de recursos puede tener un efecto

significativo en los estimados preliminares de los tipos y cantidades de recursos necesarios. Si
el análisis de nivelación de recursos modifica los requisitos de recursos del proyecto, estos
últimos son actualizados.
 Atributos de las actividades. Los atributos de las actividades se actualizan para incluir todos los
requisitos de recursos revisados y cualquier otra revisión generada por el proceso Desarrollar el
Cronograma.
 Calendario. El calendario para cada proyecto puede utilizar diferentes unidades de calendario
como base para planificar el proyecto.
 Registro de riesgos. El registro de riesgos puede necesitar actualizarse para reflejar las
oportunidades o las amenazas identificadas al establecer los supuestos de la planificación.

Un proceso que en definitiva permitirá que gestionemos de manera adecuada el cronograma es el que
PMBOK nombra como Control de Cronograma y que entre los cuales se incluyen los siguientes
métodos.

Revisiones del Desempeño:

Las revisiones del desempeño permiten medir, comparar y analizar el desempeño del cronograma, en
aspectos como las fechas reales de inicio y finalización, el porcentaje completado y la duración restante
para el trabajo en ejecución. Se pueden utilizar las técnicas de valor ganado, variación del cronograma
(SV), así como la del índice de desempeño del cronograma (SPI), para que con estas se pueda medir la
magnitud de las variaciones del cronograma.
La importancia del control del cronograma radica en poder decidir si la variación del cronograma
requiere de acciones correctivas, por ejemplo, si alguna actividad fuera de la ruta crítica tiene un
retraso, puede tener un efecto mínimo en el retraso del proyecto, al contrario que si la actividad está
dentro de la ruta crítica o es una tarea critica, el impacto que esta puede tener si tiene un retraso esta
puede retrasar el proyecto.

 Análisis de Variación:
Como se mencionó anteriormente las mediciones del desempeño del cronograma (SV, SPI) se utilizarán
para evaluar la magnitud de variación con respecto a la línea base original del cronograma. Los
aspectos importantes del control del cronograma del proyecto incluyen la determinación de la causa y
del grado de variación con relación a la línea base del cronograma y la decisión de la necesidad de
aplicar o no acciones preventivas o correctivas.

 Software de Gestión de Proyectos:

Existen actualmente diferentes herramientas de software para la gestión de proyectos que nos ayudaran
en la elaboración de cronogramas permite hacer un seguimiento de las fechas planificadas en
comparación con las fechas reales, y de proyectar los efectos de los cambios al cronograma del
proyecto, en los capítulos 5 y 6 de esta investigación se revisaran a fondo como una herramienta para la
gestión de proyectos que Microsoft proporciona, ayuda al seguimiento y control del proceso para la
administración de proyectos.

 Nivelación de Recursos:
La nivelación de recursos se utiliza para optimizar la distribución del trabajo entre los recursos.

 Análisis “¿Qué pasa si…?”:

El análisis “¿Qué pasa si…?” se utiliza para revisar diferentes escenarios para realinear el cronograma
con el plan.
 Ajuste de Adelantos y Retrasos:
El ajuste de adelantos y retrasos se usa para encontrar maneras de realinear con el plan las actividades
retrasadas del proyecto.
 Compresión del Cronograma:
Las técnicas de compresión del cronograma se usan para encontrar maneras de realinear con el plan las
actividades retrasadas del proyecto.
 Herramienta de Planificación:
Los datos del cronograma se actualizan y compilan en el cronograma para reflejar el avance real del
proyecto y el trabajo que queda pendiente. La herramienta de planificación y los datos de apoyo del
cronograma se utilizan conjuntamente con métodos manuales u otro software de gestión de proyectos
para realizar el análisis de la red del cronograma y generar un cronograma actualizado del proyecto.

Esti mados de Costo

De acuerdo al Proceso de Administración de Proyectos del PMI, la Administración de Costo es el

proceso para determinar los recursos y el costo del Proyecto. Incluye el proceso para identificar
alternativas y hacer pronósticos de costos. Incluye también, tanto la determinación de la rentabilidad de
un proyecto como el costo de su implementación.
Uno de los principales productos de la Planeación del Costo es el Estimado de Costo, el cual, además
de calcular el costo de la implementación del proyecto o de la rentabilidad (inversión y sus beneficios),
nos sirve de referencia para medir qué tanto nos acercamos al presupuesto del proyecto, entendiendo
por presupuesto, la cantidad de recursos que tenemos asignados para gastar en el proyecto en cierto
periodo.

Estimar los Costos es el proceso que consiste en desarrollar una aproximación de los recursos
monetarios necesarios para completar las actividades del proyecto.

La estimación de costos es una predicción basada en la información disponible en un momento dado.

Incluye la identificación y consideración de diversas alternativas de cómputo de costos para iniciar y
completar el proyecto. Para lograr un costo óptimo para el proyecto, deben tomarse en cuenta las
concesiones entre costos y riesgos, tales como fabricar en lugar de comprar, comprar en lugar de
alquilar, y el intercambio de recursos.
Por lo general, la estimación de costos se expresa en unidades monetarias (dólar, euro, yen, etc.),
aunque en algunos casos pueden emplearse otras unidades de medida, como las horas o los días de
trabajo del personal para facilitar las comparaciones, eliminando el efecto de las fluctuaciones de las
divisas.

Existen herramientas y técnicas que nos ayudarán en el proceso de estimación de costos, entre ellas
podemos distinguir las siguientes:

 Juicio de Expertos:
Numerosas variables, tales como las tarifas de trabajo, los costos de los materiales, la inflación, los
factores de riesgo, entre otras, influyen en la estimación de costos. Guiado por la información histórica,
el juicio del personal de experiencia aporta una perspectiva valiosa sobre el ambiente y la información
precedentes de proyectos similares. Esta información también puede utilizarse para determinar si es
oportuno combinar métodos de estimación y cómo conciliar las diferencias entre ellos.
 Estimación Análoga:
La estimación de costos por la técnica de analogía en donde se utilizan los valores de parámetros como
el alcance, el costo, el presupuesto y la duración, o también las medidas de escala tales como el tamaño,
el peso y la complejidad de un proyecto anterior similar, como base para estimar el mismo parámetro o
medida para un proyecto actual. Cuando se trata de estimar costos, esta técnica utiliza el costo real de
proyectos similares anteriores como base para estimar el costo del proyecto actual. Es un método de
estimación del valor bruto, que a veces se ajusta en función de diferencias conocidas en cuanto a la
complejidad del proyecto.
La estimación de costos por analogía se emplea frecuentemente para estimar un parámetro cuando
existe una cantidad limitada de información detallada sobre el proyecto, como es el caso, por ejemplo,
en sus fases iniciales. La estimación de costos por analogía utiliza la información histórica y el juicio
de expertos.
Por lo general, la estimación de costos por analogía es menos costosa y requiere menos tiempo que las
otras técnicas, pero también es menos exacta. La estimación análoga es más confiable cuando el
proyecto anterior es similar, no sólo en apariencia sino en los hechos, y cuando los miembros del
equipo del proyecto responsables de efectuar los estimados poseen la experiencia necesaria.
 Estimación Paramétrica:
La estimación paramétrica utiliza una relación estadística entre los datos históricos y otras variables
(por ejemplo, pies cuadrados en la construcción) para calcular una estimación de parámetros de una
actividad tales como costo, presupuesto y duración. Con esta técnica pueden lograrse niveles superiores
de exactitud, dependiendo de la sofisticación y de los datos que utilice el modelo. La estimación
paramétrica de costos puede aplicarse a todo un proyecto o a partes del mismo y en conjunto con otros
métodos de estimación.
 Estimación Ascendente:
La estimación ascendente es un método para estimar los componentes del trabajo. El costo de cada
paquete de trabajo o de cada actividad se calcula con el mayor nivel de detalle. El costo detallado luego
se resume o “acumula” en niveles superiores para fines de información y seguimiento. En general, la
magnitud y complejidad de la actividad o del paquete de trabajo individual influyen en el costo y la
exactitud de la estimación ascendente de costos.
 Estimación por Tres Valores:
La exactitud de las estimaciones de costos de una actividad única puede mejorarse tomando en
consideración la incertidumbre y el riesgo. Este concepto se originó con la Técnica de Revisión y
Evaluación de Programas (PERT). El PERT utiliza tres estimados para definir un rango aproximado de
costo de una actividad:

 Más probable (cM). El costo de la actividad se basa en una evaluación realista del esfuerzo
necesario para el trabajo requerido y cualquier gasto previsto.
 Optimista (cO). El costo de la actividad se basa en el análisis del mejor escenario posible
para esa actividad.
 Pesimista (cP). El costo de la actividad se basa en el análisis del peor escenario posible para
esa actividad.

El análisis según el método PERT calcula un costo Esperado (CE) de la actividad utilizando un
promedio ponderado de estas tres estimaciones:

cE = (cO + 4cM + cP)/6

Las estimaciones de costos basadas en esta ecuación (o aun en un promedio simple de los tres valores)
pueden proporcionar una mayor exactitud, y los tres valores aclaran el rango de incertidumbre de las
estimaciones de costos.

Software de estimación de costos para la dirección de proyectos:

En estas se incluyen las aplicaciones de software de estimación de costos, como las hojas de cálculo
computarizadas, y las herramientas de simulación y estadísticas que son cada vez más empleadas para
ayudar en el proceso de estimación de costos. Estas herramientas pueden simplificar el uso de algunas
de las técnicas de estimación de costos y de esta manera, facilitar la consideración rápida de las
alternativas para la estimación de costos.

Esti mación de Presupuesto

Es el proceso que consiste en sumar los costos estimados de actividades individuales o paquetes de
trabajo para establecer una línea base de costo autorizada. Los presupuestos del proyecto constituyen
los fondos autorizados para ejecutar el proyecto. El desempeño de los costos del proyecto se medirá
con respecto al presupuesto autorizado.

Al igual que la estimación de los costos del proyecto, existen diferentes técnicas como herramientas
para poder estimar el presupuesto, a continuación se describirán las que comúnmente son más
empleadas.
  Suma de Costos:
Las estimaciones de costos se suman por paquetes de trabajo, de acuerdo con la EDT. Las estimaciones
de costos de los paquetes de trabajo luego se suman para los niveles superiores de componentes de la
EDT, tales como las cuentas de control, y finalmente para todo el proyecto.
 Análisis de Reserva:
El análisis de reserva del presupuesto puede establecer tanto las reservas para contingencias como las
reservas de gestión del proyecto. Las reservas para contingencias son asignaciones para cambios no
planificados, pero potencialmente necesarios, que pueden resultar de riesgos identificados en el registro
de riesgos. Las reservas de gestión son presupuestos reservados para cambios no planificados al
alcance y al costo del proyecto.
 Juicio de Expertos:
La experiencia la pueden proporcionar cualquier grupo o persona con una educación, conocimiento,
habilidad, experiencia o capacitación especializada. Este juicio de expertos puede provenir de diversas
fuentes, entre otras:

 otras unidades dentro de la organización ejecutante

 consultores
 interesados, incluyendo clientes
 asociaciones profesionales y técnicas
 grupos industriales

A todo lo anterior debe de existir también un proceso de control de costos el cual se monitoreará la
situación del proyecto para actualizar el presupuesto del mismo y gestionar cambios a la línea base de
costo. La actualización del presupuesto implica registrar los costos reales en los que se ha incurrido a la
fecha. Cualquier incremento con respecto al presupuesto autorizado sólo puede aprobarse mediante el
proceso Realizar el Control Integrado de Cambios.

La clave para un control de costos efectivo es la gestión de la línea base aprobada de desempeño de
costos y de los cambios a esa línea base.

El control de costos del proyecto incluye las siguientes acciones entre las más importantes:

 Asegurarse de que todas las solicitudes de cambio se lleven a cabo de manera oportuna.
 Gestionar los cambios reales cuando y conforme suceden.
 Asegurarse de que los gastos no excedan el financiamiento autorizado para el proyecto, tanto
por periodo como total.
 Monitorear el desempeño de los costos para detectar y comprender las variaciones con respecto
a la línea base aprobada de costo.
 Monitorear el desempeño del trabajo con relación a los fondos en los que se ha incurrido.
 Evitar que se incluyan cambios no aprobados en los informes sobre costos o utilización de
recursos.
 Informar a los interesados pertinentes acerca de todos los cambios aprobados y costos
asociados.
 Realizar acciones para mantener los sobrecostos previstos dentro de límites aceptables.

El control de costos del proyecto busca las causas de las variaciones positivas y negativas, y forma
parte del proceso Realizar el Control Integrado de Cambios
Para fines de la administración del avance del proyecto, la que más nos interesa es la línea base. En la
sección de Control, abordaremos nuevamente esta técnica a la que se le conoce con el nombre de Valor
Devengado o en inglés “Earned Value”.

Existen distintas entradas de información para el control de los costos del proyecto, entre los cuales se
encuentran las siguientes:

 Línea base del desempeño.

Está servirá para poder comparar los costos planeados con los costos reales, con la finalidad de
determinar si será necesario implementar un cambio o una acción preventiva o correctiva.

 Plan de gestión de costos.

Este plan describe la forma en cómo se gestionan y controlan los costos del proyecto.

Adicionalmente las herramientas y técnicas que se emplean para el control de los costos, encontramos
el método de la gestión del valor ganado (EVM).

Este método se utiliza comúnmente para la medición del desempeño, donde este integra las mediciones
del alcance del proyecto, costo, y calendario, para ayudar al equipo del proyecto en la evaluación del
proyecto. Un requisito forzoso para poder utilizar este método es necesario establecer la línea base del
proyecto.
Las dimensiones a monitorear en el cálculo del valor ganado son las siguientes:

 Valor Planificado (PV). Es el presupuesto autorizado asignado al trabajo que se debe de realizar
para completar una actividad o componente de la EDT. El total del PV se conoce por medio de la
línea base para la medición del desempeño (PMB), y al valor planificado total para el proyecto
también se conoce como presupuesto hasta la conclusión (BAC) por sus siglas en ingles Budget at
conclusión.
 Valor Ganado (EV). Es el valor del trabajo completado expresado en términos del presupuesto
aprobado asignado a dicho trabajo para una tarea del cronograma o de igual forma aun componente
de la EDT. El EV es el trabajo autorizado que se ha completado, más el presupuesto autorizado para
dicho trabajo completado. El EV medido debe corresponderse con la línea base del PV (PMB) y no
puede ser mayor que el presupuesto aprobado del PV para un componente. El término EV se usa a
menudo para describir el porcentaje completado de un proyecto.
 Costo Real (AC). Este es el costo total que se gastado realmente y que se ha registrado durante la
ejecución del trabajo realizado para una actividad o elemento de la EDT. Se incluyen todos los
costos directos e indirecto, es decir todos los gastos incurridos en el proyecto
 Variación del cronograma (SV). Es una medida de desempeño del cronograma en un proyecto. En
términos matemáticos esta se expresaría con la siguiente ecuación: SV =EV −PV está métrica es
útil ya que puede indicar un retraso en la EVM, finalmente cuando se complete el proyecto esta
deberá ser igual a cero, porque ya se habrán ganado todo los PV’s.
 Variación del costo (CV). De igual forma es una medida del desempeño del costo en un proyecto.
Esta viene dada por la siguiente ecuación: CV =EV − AC lo que significa que la variación del costo
al final del proyecto será la diferencia entre el presupuesto hasta la conclusión (BAC) y la cantidad
realmente gastada, esta variación es importante debido a que indica la relación entre el desempeño
real y los costos gastados.
Tanto los valores de SV y CV pueden servir como indicadores de desempeño del costo y del
cronograma de cualquier proyecto, estos indicadores serán útiles para determinar la salud del proyecto.
 Índice de desempeño del cronograma (SPI). Este índice es una medida del avance alcanzado en
un proyecto en comparación con el avance planeado. Un valor del SPI inferior a uno indica que la
cantidad de trabajo realizada es menor a la prevista y por lo contrario un valor del SPI superior a 1
indica que la cantidad de trabajo efectuada es mayor a la planeada, esta relación se puede calcular
con la siguiente ecuación algebraica SPI=EV / PV .
 Índice del desempeño del costo (CPI). Esta es una medida de desempeño del valor del trabajo
completado en comparación con el costo o avance real del proyecto, se considera como la métrica
más importante de la EVM ya que mide la efectividad de la gestión del costo para el trabajo
completado. Cuando el CPI es inferior a 1.0 indica que habrá sobrecosto con respecto al trabajo
completado, y cuando el CPI sea superior a 1.0 indica un costo inferior con respecto al trabajo
realizado a la fecha, esta expresión viene dada por la razón entre EV y el AC, es términos
algebraicos queda de la siguiente forma CPI=EV / AC.

Los tres parámetros (valor planificado, valor ganado y costo real) pueden monitorearse e informarse,
por periodos (normalmente semanalmente o mensualmente) y de forma acumulativa.

La siguiente grafica se ve representada por una curva S para representar los valores del EV, para un
proyecto cuyo costo ha excedido el presupuesto y cuyo plan de trabajo está retrasado.

Ilustración 25 Valor Ganado, Valor Planificado y Costos Reales

Existen diferentes técnicas adicionales al EV, que son menos usadas, a continuación se
mencionan algunas.

 Proyecciones.
 Proyección de la EAC basada en el trabajo correspondiente a la ETC,
realizado según la proporción presupuestada.
 Proyección de la EAC basada en el trabajo correspondiente a la ETC,
realizado según el CPI actual.
 Proyección de la EAC basada en el trabajo correspondiente a la ETC,
realizado considerando ambos factores (SPI y CPI).
 Índice de Desempeño del Trabajo por Completar (TCPI)
 Revisiones del Desempeño
 Análisis de variación.
 Análisis de tendencias.
 Desempeño del valor ganado.

Existe de igual forma herramientas de software que nos ayudaran a realizar los cálculos
pertinentes a cada una de estas métricas anteriormente mencionadas una de ellas es el caso
de MS Project Profesional.

Plan de Calidad

El proceso para identificar los criterios de calidad relevantes del proyecto y la forma de
satisfacerlos se le conoce como Plan de Calidad. El objetivo principal de este plan es el de
satisfacer las necesidades del proyecto por las cuales este fue emprendido.

El plan de calidad incluye a el:

 Plan de Aseguramiento de Calidad y
 Plan de Control de Calidad.

El primero se enfocará en las actividades que aseguren que todo se esté haciendo
correctamente y el segundo se enfoca a verificar que una vez hechas, efectivamente se
cumpla con las especificaciones inicialmente planteadas.

Se deben de considerar algunos elementos que debe contener el plan de calidad.

 Los criterios de calidad deben estar claramente definidos en los contratos. Tanto en
los que se firman con los clientes como en los que firman los proveedores.
  Desde el inicio del proyecto se deben identificar a los recursos y actividades
necesarias para garantizar la calidad del proyecto tanto en las especificaciones de
los entregables como en los procesos para generar esos entregables.
 Todo proyecto debe ser revisado por un panel de calidad integrado por las personas
con mayor experiencia en la organización.
 Aunque sin descartar el aspecto correctivo, este panel debe actuar desde las
primeras fases del proyecto para que su enfoque sea mucho más preventivo que
correctivo y así evitar el re trabajo.
 Se debe desarrollar una base de datos de conocimiento, que permita que la
experiencia se tenga correctamente documentada y clasificada, para un mayor
aprovechamiento en nuevos proyectos.
 La oficina de proyectos debe llevar a cabo al menos una auditoria de
procedimientos de administración de proyectos.
Planifi car la Calidad.

Este es el proceso por el cual se identifican los requisitos de calidad y/o normas para el
proyecto y el producto, documentando la manera en que el proyecto demostrara el
cumplimiento con los mismos.

La gestión de la calidad del proyecto abarcara tanto la administración del proyecto como la
del producto del proyecto.

Las medidas y técnicas relativas a la calidad del producto son específicas al tipo de
producto generado por el proyecto. Por ejemplo, mientras que la gestión de calidad de
productos de software implica enfoques y medidas diferentes de los que se utilizan para las
centrales nucleares, los enfoques de Gestión de la Calidad del Proyecto se aplican a ambos.
En cualquier caso, el incumplimiento de los requisitos de calidad del producto o del
proyecto puede tener consecuencias negativas graves para algunos interesados en el
proyecto e incluso para todos.

Existe una diferencia notable entre la “Calidad” y el “Grado de calidad”, mientras que el
primero indica el nivel en el que un conjunto de características inherentes satisface los
requisitos y el grado es una categoría que se otorga a productos o servicios que tienen el
mismo uso funcional pero con características técnicas diferentes.

Por ejemplo, un producto de software puede ser de alta calidad (sin defectos evidentes,
manual legible) y bajo grado (un número limitado de características), o de baja calidad (con
muchos defectos, la documentación del usuario deficientemente estructurada) y alto grado
(numerosas características).
El director del proyecto y el equipo de dirección del proyecto son responsables de
determinar las concesiones necesarias para cumplir con los niveles requeridos, tanto de
calidad como de grado.

Otros atributos que se deben diferenciar son los conceptos de Precisión y Exactitud los
cuales no son equivalentes. La precisión significa que los valores de mediciones repetidas
están agrupados y tienen poca dispersión. A diferencia de la Exactitud esta significa que el
valor medido es muy cercano al valor verdadero.
El enfoque mostrado en el PMBOOK, es una conceptualización básica y que pretende ser
compatible con el de la Organización Internacional de Normalización (ISO), también con
los propietarios de la gestión de calidad tales como los recomendados Deming, Juran,
Crosby y otros, y también se pretender ser compatible con los modelos que no son
propietarios como la gestión de calidad total (TQM), Six Sigma, Costo de la Calidad
(COQ) y mejora continua, entre otros.

La gestión moderna de la calidad complementa la dirección de proyectos y ambas

disciplinas reconocen la importan de:

 La satisfacción del cliente.

 La prevención antes que la inspección.
 La mejora continua.
 La responsabilidad de la dirección.

Algunas de las herramientas y técnicas usualmente más usadas para la determinación de la

calidad son las siguientes:

 Análisis costo – beneficio: Los principales beneficios a cumplir con los requisitos
de calidad pueden incluir un menor re trabajo, una mayor productividad, menores
costos y una mayor satisfacción de los interesados, un caso de negocio para cada
actividad de calidad permitirá comparar el costo del procedimiento de calidad con el
beneficio esperado.

 Costo de la calidad (COQ): Este costo de calidad incluye todos los costos en los que
se han incurrido durante todo el periodo de vida del producto en inversiones para
prevenir el incumplimiento de los requisitos. Los costos por fallos se clasifican
como internos (constatados por el equipo del proyecto), y externos (constatados por
el cliente). Los costos por fallos también se denominan costo por calidad deficiente.

Diagramas de control: Estos diagramas se utilizan para evaluar si un proceso es estable o

no, o si tiene un desempeño predecible. Los límites superior e inferior de las
especificaciones se basan en los requisitos del contrato. El director del proyecto y los
interesados apropiados establecen los límites de control superior e inferior, para reflejar los
puntos en los cuales deben implementarse acciones correctivas para evitar que se
sobrepasen los límites de las especificaciones. Un margen para procesos repetitivos por lo
general se establecen en ± 3 σ.

Aseguramiento de la Calidad

Este proceso consiste en auditar los requisitos de calidad y los resultados obtenidos a partir
de medidas de control de calidad, a fin de garantizar que se utilicen definiciones
operacionales y normas de calidad adecuadas. A menudo estas actividades son supervisadas
por un departamento de aseguramiento de calidad o una organización similar.

Gesti ón de los Recursos Humanos del Proyecto.

La administración de los recursos humanos del proyecto, incluye los procesos que
organizan, gestionan y conducen el equipo del proyecto. El equipo del proyecto estará
conformado por aquellas personas a las que se les ha asignado roles y responsabilidades
para cada una de las actividades del proyecto y sea completado. El tipo y la cantidad de
recursos pueden variar de un proyecto a otro dependiendo de las características del mismo
así como se va avanzando en el mismo.

La intervención y la participación tempranas de los miembros del equipo les aportan su

experiencia profesional durante el proceso de planificación y fortalecen su compromiso con
el proyecto.

El principal entregable de esta gestión es la matriz de responsabilidades, esta matriz es una

herramienta muy simple de preparar y darle seguimiento que contribuirá para dar buenos
resultados.

La colaboración d cada uno de los grupos de interés en la matriz de responsabilidades

puede ser catalogada a diferentes niveles de la EDT, que por cierto, nuevamente como en la
gran mayoría de los documentos de la Administración del Proyecto es el punto de partida.
El manejar diferentes niveles, al igual que en la EDT, permite que según se requiera se
pueda visualizar al proyecto en forma más general o más específica.

En esta matriz se deben establecer diferentes tipos de participación, es decir, diferentes

papeles a desempeñar en el proyecto. Un Ejemplo es la matriz de responsabilidades tipo
RASI, denominada así por sus siglas que indican el tipo de participación.

R= Responsable

A= Autoriza
S= proporciona Soporte

I = Informado

En la Matriz de Responsabilidades, la asignación de participación sigue algunas reglas

sencillas que se listan a continuación.

 Debe haber una y solo una R. Si hubiera más de una “R” los que tuvieran este
papel no sabrían claramente lo que les corresponde o el nivel de autoridad que
tienen sobre la actividad o el entregable, por lo que se causaría caos. En algunas
ocasiones ambos asumirían que el otro se haría cargo y al final resultaría que
ninguno le dio seguimiento.
 Se pueden repetir letras en la misma celda. Como en el teatro, alguna persona
puede desempeñar más de un papel, sin embargo hay que tener cuidado de no
saturar a esa persona y que como consecuencia de esa duplicidad de papeles, no se
cree conflicto de intereses.
 R y A implican que deben ser informados. Obviamente el responsable y el que
autoriza, implica que debe estar informado, por lo que no es necesario indicarlo en
la matriz.
 Limitar número de A’s. En ocasiones es conveniente que más de un nivel autorice,
sin embargo demasiadas autorizaciones entorpecen el desempeño. Hay que
encontrar el junto medio a través del proceso de delegar, asegurando que a quién se
le delega se le otorgan las herramientas necesarias para poder ejercer la autoridad
que se le delega.
 Pueden quedar celdas vacías. Así como no todos los actores participan en todas
las escenas, no todos los participantes del equipo tienen que participar en todas las
tareas. Eso sería muy poco eficiente.

Tabla 3 Ejemplo Matriz RASI

Actividad Director Director del Gerente del Gerente

General Proyecto Proyecto Funcional
Establecer R S S S
Políticas y
procedimientos
departamentales
Integración de I R S S
Proyectos
Dirección del I R
Proyecto
Definición y I A R A
Autorización del
Proyecto
Planeación del S A R S/A
Proyecto
Resolución de I R A
 Conflictos entre
proyecto y
función

Es conveniente incluir a todos los grupos de interés que tengan algún papel activo en el
proyecto, de modo que todos estén enterados de quien es quien en el proyecto.

Gesti ón de las Comunicaciones del Proyecto.

La Gestión de las Comunicaciones del Proyecto incluye los procesos requeridos para
garantizar que la generación, la recopilación, la distribución, el almacenamiento, la
recuperación y la disposición final de la información del proyecto sean adecuados y
oportunos.

Los directores del proyecto pasan la mayor parte del tiempo comunicándose con los
miembros del equipo y otros interesados en el proyecto, tanto si son internos (en todos los
niveles de la organización) como externos a la misma. Una comunicación eficaz crea un
puente entre los diferentes interesados involucrados en un proyecto, conectando diferentes
entornos culturales y organizacionales, diferentes niveles de experiencia, y perspectivas e
intereses diversos en la ejecución o resultado del proyecto.

Como parte de este proceso se debe de identificar la información que se deberá generar en
el proyecto, así responder las siguientes preguntas:

 ¿Cómo a quién?
 ¿Para qué?,
 ¿Por cuánto tiempo?
 ¿En qué formato se distribuirá?

La matriz de responsabilidades, es uno de los mecanismos más prácticos para responder

estas preguntas con respecto a cada uno de los paquetes de trabajo de la EDT, una vez
identificados se determinara específicamente el formato y tipo de información que se le
deberá proporcionar.

En el plan de comunicación deben quedar establecido cuáles serán los reportes de

desempeño que se deberán publicar, así como la frecuencia y contenido de las juntas de
avance. El reporte gerencial es el documento en el que se resume la información anterior y
que es publicado periódicamente para mantener informados a los clientes y/o la alta
gerencia.
También se incluye como parte del plan de comunicación, los formatos que deberán de
utilizarse como parte del proyecto, el archivo y el directorio que se han comentado o se
comentarán en estos apuntes.

Existen varios métodos de comunicación que se emplean para distribuir la información

entre los interesados del proyecto, los cuales pueden clasificarse de manera general en las
siguientes categorías.

 Comunicación interactiva. Entre dos o más partes que realizan un intercambio de

información de tipo multidireccional. Resulta la manera más eficiente de asegurar
entre todos los participantes una comprensión común acerca de temas específicos, e
incluye reuniones, llamadas telefónicas, videoconferencias, etc.
 Comunicación tipo Push (empujar). Enviada a receptores específicos que
necesitan conocer la información. Esto asegura la distribución de la información,
pero no garantiza que efectivamente haya llegado a la audiencia prevista ni que
haya sido comprendida. Este tipo de comunicación incluye cartas, memorandos,
informes, correos electrónicos, faxes, correos de voz, comunicados de prensa, etc.
 Comunicación tipo Pull (halar=). Utilizada para grandes volúmenes de
información o para audiencias muy grandes, que requieren que los receptores
accedan al contenido de la comunicación según su propio criterio. Entre los
métodos, se incluyen sitios de intranet, aprendizaje virtual, servidores de contenido,
etc.

En función de los requisitos de comunicación, el director del proyecto decide qué métodos
de comunicación deben utilizarse dentro del proyecto, cómo y cuándo hacerlo.

Identi fi cación de Riesgos

La Gestión de los Riesgos del Proyecto incluye los procesos relacionados con llevar a cabo
la planificación de la gestión, la identificación, el análisis, la planificación de respuesta a
los riesgos, así como su monitoreo y control en un proyecto. Los objetivos de la Gestión de
los Riesgos del Proyecto son aumentar la probabilidad y el impacto de eventos positivos, y
disminuir la probabilidad y el impacto de eventos negativos para el proyecto.[ CITATION
PMI \l 2058 ]

Los riesgos de un proyecto siempre se ubican siempre en el futuro, donde un riesgo es un

evento o condición incierta que, si sucede, tiene un efecto en lo por lo menos uno de los
objetivos del proyecto.

Un riesgo puede tener una o más causas y, si sucede, puede tener uno o más impactos,
existen riesgos que constituyen una amenaza para el proyecto pueden aceptarse si se
encuentran dentro de los límites de tolerancia y si están en equilibrio con el beneficio que
puede obtenerse al tomarlos, si estos afectan negativamente al proyecto se les llama
normalmente amenazas y si pueden sacar beneficios al proyecto se les conoce como
oportunidades.

La mayor parte de las veces los riesgos tienen un impacto directo en los costos del
proyecto, es decir si existe un riesgo en cualquier área del proyecto (alcance, tiempo,
calidad, RH, etc.) el proyecto se verá afectado en el área de costo.

La planificación de los riesgos viene dado por la elaboración del plan de gestión de riesgos
el donde se describe la manera en que se estructurará y realizará la gestión de los riesgos
del proyecto y este se vuelve parte del plan para la dirección del proyecto.

El plan de gestión de riesgos debe incluir lo siguiente [ CITATION PMI \l 2058 ]:

 Metodología: Se definen los métodos, herramientas, y fuentes de información que

podrán utilizarse para llevar a cabo la administración de los riesgos en el proyecto.
 Roles y responsabilidades: Se define al líder, el apoyo y a los miembros del equipo
de gestión de riesgos y también se les asigna la responsabilidad a cada uno.
 Presupuesto: Asigna recursos, y se estiman los costos necesarios para llevar a cabo
la gestión de riesgos, a fin de incluirlos en la línea base del desempeño de costos y
también se establecerán los protocolos para aplicar la reserva en caso de
contingencias.
 Calendario: Define el ¿Cuándo? y ¿por cuánto tiempo? se realizará la gestión de
los riesgos a lo largo del ciclo de vida del proyecto, se establecen los protocolos
para la utilización de las reservas para contingencias del cronograma y prevé las
tareas de gestión de riesgos que deberán incluirse en el cronograma.
 Categorías de riesgo: Proporciona una estructura que asegura un proceso completo
de identificación sistemática de los riesgos con un nivel de detalle coherente, y
contribuye a la efectividad y calidad del proceso Identificar los Riesgos. Una
organización puede utilizar una matriz de categorización elaborada previamente, la
cual puede consistir en una simple lista de categorías o en una Estructura de
Desglose del Riesgo.
 Definiciones de la probabilidad e impacto de los riesgos: Tanto la calidad como
la credibilidad del proceso Realizar el Análisis Cualitativo de Riesgos requiere que
se definan distintos niveles de probabilidad e impacto de los riesgos. La siguiente
grafica muestra un ejemplo de las definiciones de impactos negativos que podrían
usarse en la evaluación de los impactos relacionados con los objetivos del proyecto.
 Ilustración 26 Definición de Escalas de Impacto

 Matriz de probabilidad e impacto: Los riesgos se clasifican por orden de

prioridad de acuerdo con sus implicaciones de tener efecto sobre los objetivos del
proyecto, la manera más fácil de priorizar los riesgos consiste en utilizar una tabla
de búsqueda o matriz de probabilidad e impacto, donde la empresa u organización
establece las combinaciones de probabilidad e impacto que llevarán a calificar un
riesgo de importancia (alta, moderada o baja).
 Tolerancia revisada de los interesados: Estas se aplican según al proyecto en
específico.
 Formato de los informes: Definen como se documentarán, analizarán y
comunicarán los resultados de los procesos de gestión de riesgos.
 Seguimiento: Documenta como se registrarán las actividades de gestión de riesgos
para beneficio del proyecto, de necesidades futuras y de las lecciones aprendidas.

El proceso para la identificación de los riesgos consistirá en la determinación de los riegos

que puedan afectar el proyecto y se documentan sus características. Las personas que
participan en la identificación de los mismos pueden estar desde el director del proyecto,
los miembros del equipo del proyecto, el equipo de gestión de riesgos, clientes, expertos en
la materia externos al equipo de proyecto, usuarios finales, es recomendable que se
involucre a los grupos de interés del proyecto.

Este proceso se debe de realizar de manera iterativa, debido a que se pueden descubrir
nuevos riesgos o pueden evolucionar conforme se avanza en el proyecto.

Existen técnicas documentadas que sirven de una manera práctica para la identificación de
los riesgos, entre las cuales están las siguientes:

 Tormenta de ideas. El objetivo principal de esta técnica es obtener una lista

completa de riegos de proyecto donde se involucra a todo el equipo de trabajo del
proyecto. Bajo el liderazgo de un facilitador se generan ideas acerca de los riesgos y
estos se van documentando y categorizando y priorizando.
  Técnica Delphi. Esta técnica consiste en lograr un consenso de expertos, estos
trabajan de forma anónima al proyecto donde se emplea un cuestionario para
solicitar ideas acerca de los riesgos importantes del proyecto, las respuestas son
resumidas y enviadas a los expertos para sus comentarios, con un número mínimo
de rondas se puede lograr un consenso, donde se evitaran parcialidades en los datos
y evita que cualquier persona ejerza influencias inapropiadas en el resultado.
 Entrevistas. Se realizan entrevistas a los involucrados experimentados del
proyecto.
 Análisis Casual. Esta técnica es específica para identificar un problema, determinar
las causas subyacentes que lo ocasionan y desarrollar las acciones preventivas.

Análisis Cualitati vo de Riesgos

El análisis cualitativo de riesgos es el proceso que consiste en priorizar los riesgos para
realizar otros análisis o acciones posteriores, evaluando y combinando la probabilidad de
ocurrencia y el impacto de dichos riesgos. Con esto se ayuda a las organizaciones a mejorar
el desempeño del proyecto enfocándose en los riesgos de alta prioridad.

Al realizar este análisis cualitativo de riesgos por lo general es un medio rápido y

económico de establecer prioridades para la planificación de la respuesta a los riesgos y
sienta una base para el análisis cuantitativo de riesgos en el caso de requerirse.

Habitualmente, la evaluación de la importancia de cada riesgo y, por consiguiente, de su

prioridad de atención, se efectúa utilizando una tabla de búsqueda o una matriz de
probabilidad e impacto.

Ilustración 4Matriz de Probabilidad e Impacto

Dicha matriz especifica las combinaciones de probabilidad e impacto que llevan a calificar
los riesgos con una prioridad baja, moderada o alta. El área gris oscuro (con las cifras más
altas) representa un riesgo alto, el área gris intermedio (con las cifras más bajas) representa
un riesgo bajo y el área color gris claro (con las cifras intermedias) representa el riesgo
moderado.

Una organización puede calificar un riesgo por separado para cada objetivo (por ejemplo,
costo, tiempo y alcance). Además, puede desarrollar formas de determinar una calificación
general para cada riesgo. Puede elaborarse un esquema de calificación para el proyecto
global, con el propósito de reflejar la preferencia de la organización por un objetivo
determinado sobre otros y la utilización de tales preferencias para proceder a una
ponderación de los riesgos evaluados para cada objetivo. Finalmente, las oportunidades y
las amenazas pueden manejarse en la misma matriz, utilizando las definiciones de los
diversos niveles de impacto apropiados para cada una de ellas.

La calificación de los riesgos ayuda a guiar las respuestas a los riesgos. Por ejemplo, los
riesgos que, si se concretan (amenazas), tienen un impacto negativo sobre los objetivos, y
que se encuentran en la zona de riesgo alto (gris oscuro) de la matriz, pueden necesitar
prioridad de acción y estrategias de respuesta agresivas. Las amenazas en la zona de riesgo
bajo (gris intermedio) pueden no necesitar una acción de gestión proactiva, más allá de ser
incluidas en una lista de supervisión o de ser agregadas a una reserva para contingencias.

De manera similar, debe darse prioridad a las oportunidades que se encuentran en la zona
de riesgo alto (gris oscuro), ya que pueden obtenerse más fácilmente y proporcionan
mayores beneficios. Las oportunidades en la zona de riesgo bajo (gris medio) deben
monitorearse. Los valores que se proporcionan en la Sección son representativos. El
número de etapas en la escala será determinado por la organización y depende de ella.

Análisis Cualitati vo de Riesgos

Este proceso consiste en analizar numéricamente el efecto de los riesgos identificados sobre
los objetivos generales del proyecto.

Puede utilizarse para asignar a esos riesgos una calificación numérica individual o para
evaluar el efecto acumulativo de todos los riesgos que afectan el proyecto. También
presenta un enfoque cuantitativo para tomar decisiones en caso de incertidumbre.
[ CITATION PMI \l 2058 ]

Este proceso cuantitativo de riesgos se realizará después de haber realizado el análisis

cualitativo de riesgos, y puede darse el caso que también este análisis cuantitativo no sea
necesario realizarlo para una respuesta efectiva a los riesgos.

La disponibilidad de tiempo y presupuesto, así como la necesidad de declaraciones

cualitativas o cuantitativas acerca de los riesgos y sus impactos, determinarán qué métodos
emplear para un proyecto en particular, así también este proceso debe ser iterativo después
del proceso de planificar la respuesta de riesgos así como en el proceso de monitoreo y
control de los riesgos.
Existen algunas técnicas documentadas para realizar el análisis cuantitativo de riesgos
como pueden las que se describen a continuación:

1. Técnicas de Recopilación y Representación de Datos

 Entrevistas. La técnica de entrevista se basa en la experiencia y en los datos
históricos para cuantificar la probabilidad y el impacto sobre los riesgos, sobre los
objetivos del proyecto. La información necesaria depende del tipo de distribuciones
de probabilidad que se vayan a utilizar. Por ejemplo, para algunas distribuciones
comúnmente usadas, la información se podría recopilar agrupándola en escenarios
optimistas (bajo), pesimistas (alto) y más probables.

Ilustración 5 Rango de Estimaciones de Costos Recopiladas durante la entrevista de Riesgos

 Distribuciones de probabilidad. Estas pueden ser:

 Distribuciones continuas de probabilidad usadas frecuentemente en el

modelado y la simulación, representan la incertidumbre de los valores tales
como las duraciones de las actividades del cronograma y los costos de los
componentes del proyecto.
 Distribuciones diferenciadas, estas se emplean para representar eventos
inciertos, como el resultado de una prueba o un posible escenario en un árbol
de decisiones.
 Ilustración 29 Ejemplos de Distribuciones de Probabilidad

2. Técnicas de Análisis Cuantitativo de Riesgos y de Modelado.

Las técnicas que a continuación se describen comúnmente son utilizadas tanto en análisis
orientados a eventos como a los orientados a proyectos, estos incluyen:
 Análisis de sensibilidad. Este análisis ayuda a determinar que riesgos tienen un
mayor impacto potencial en el proyecto adicionalmente este método evalúa el grado
en que la incertidumbre de cada elemento del proyecto afecta el objetivo que esa
siendo examinado, cuando todos los demás elementos inciertos se mantienen en sus
valores de línea base. Una representación típica y muy útil que se usa en este
análisis es el diagrama de forma de tornado, en el cual se compara la importancia y
el impacto relativo de las variables que tienen un alto grado de incertidumbre con
respecto a las que son más estables. [ CITATION PMI \l 2058 ]
 Modelado y simulación. Una simulación de proyecto utiliza un modelo que
traduce las incertidumbres detalladas especificadas del proyecto en su impacto
potencial sobre los objetivos del mismo. Las simulaciones iterativas se realizan
habitualmente utilizando la técnica Monte Carlo. En una simulación, el modelo del
proyecto se calcula muchas veces (mediante iteración) utilizando valores de entrada
(p.ej., estimaciones de costos o duraciones de las actividades) seleccionados al azar
para cada iteración a partir de las distribuciones de probabilidad para estas
variables. A partir de las iteraciones, se calcula una distribución de probabilidad
(por ejemplo, el costo total o la fecha de conclusión). Para un análisis de riesgos de
costos, una simulación emplea estimaciones de costos. Para un análisis de los
riesgos relativos al cronograma, se emplean el diagrama de red del cronograma y las
estimaciones de la duración. [ CITATION PMI \l 2058 ]
 Ilustración 60 Resultados de Simulación de los Riesgos Relativos a Costos

3. Juicio de Expertos.
El juicio de expertos (que idealmente recurre a expertos con experiencia relevante y
reciente) se requiere para identificar los impactos potenciales sobre el costo y el
cronograma, para evaluar la probabilidad y definir las entradas (tales como las
distribuciones de probabilidad) a las herramientas.

El juicio de expertos también participa en la interpretación de los datos. Los expertos deben
ser capaces de identificar las debilidades de las herramientas, así como sus fortalezas
relativas. Los expertos pueden determinar cuándo una determinada herramienta puede o no
ser la más apropiada, teniendo en cuenta las capacidades y la cultura de la organización.

Respuesta a los Riesgos.

Este es el proceso por el cual se despliegan opciones y acciones para mejorar las
oportunidades y reducir las amenazas a los objetivos del proyecto, este proceso se realiza
después de los procesos de Realizar el Análisis Cualitativo de Riesgos y Realizar el
Análisis Cuantitativo de Riesgos (si este llegará a necesitarse).
El proceso a la respuesta a los riesgos debe incluir la identificación y asignación de una
persona (el “propietario de la respuesta a los riesgos”) para que asuma la responsabilidad
de cada respuesta a los riesgos acordados y financiados. Este proceso abordará los riesgos
en función de su prioridad, introduciendo recursos y actividades en el presupuesto, el
cronograma y el plan para la dirección del proyecto, según se requiera. [ CITATION PMI \l
2058 ]

Las herramientas y/o técnicas que se emplean para dar respuesta a los riesgos pueden ser
diversas y se elige la estrategia con mayor probabilidad de eficacia.
A menudo, se asigna una reserva para contingencias de tiempo o costo. En los casos en que
ésta se establece, el plan puede incluir la identificación de las condiciones que suscitan su
utilización, a continuación se describe algunas de las más utilizadas.

1. Estrategias para Riesgos Negativos o Amenazas.

Las estrategias que a continuación se mencionan, abordan normalmente las amenazas o los
riesgos que pueden tener un impacto negativo sobre los objetivos del proyecto en el caso de
que estos se materialicen. La ultima estrategia que se menciona “aceptar” puede utilizarse
para riesgos negativos, amenazas, positivos u oportunidades, en general estas estrategias
permitirán evitar, trasferir, mitigar o aceptar los riesgos.

1. Evitar. Evitar el riesgo implica cambiar el plan para la dirección del proyecto, a fin
de eliminar por completo la amenaza. Un ejemplo de esto podría ser la ampliación
del cronograma, el cambio de estrategia, o la reducción del alcance. La estrategia de
evasión más drástica consiste en anular por completo el proyecto. Algunos riesgos
que surgen en etapas tempranas del proyecto pueden ser evitados aclarando los
requisitos, obteniendo información, mejorando la comunicación o adquiriendo
experiencia.
2. Transferir. Consiste en trasladar todo o parte del riesgo a un tercero, junto con la
propiedad de la respuesta, lo que significa que se trasfiere la responsabilidad de la
gestión del riesgo, por lo general cuando se trasfiere un riesgo, se debe de realizar el
pago de una prima del riesgo de la parte del riesgo que corresponda.
En muchos casos el uso de un contrato de margen sobre el costo, puede transferir el
costo del riesgo al comprado, mientras que un contrato de precio fijo puede
transferir el riesgo al vendedor.
3. Mitigar. Esta estrategia permite minimizar la probabilidad y / o el impacto a un
nivel aceptable. El realizar acciones tempranas o como se dice tomar cartas en el
asunto lo antes posible es la mejor técnica para reducir el umbral.
4. Aceptar. Esta estrategia se toma debido a que en ocasiones es imposible eliminar
todas las amenazas de un proyecto y el equipo de trabajo decide no cambiar el plan
para la dirección del proyecto para hacer frente al riesgo o en su caso no ha podido
identificar la estrategia para dar respuesta a estos. La aceptación de un riesgo puede
ser pasiva o activa.
a. Pasiva, no ha realiza ninguna acción a excepción de documentar la
estrategia, especificando que el equipo de proyecto aborde los riesgos
conforme se presentan.
b. Activa, se establece una reserva para contingencias, en la cual se deberá
considerar la cantidad de tiempo, medios financieros, o recursos necesarios,
para aceptar dichos riesgos.
2. Estrategias para riesgos positivos u oportunidades.

Las estrategias que se presentan a continuación de las cuales 3 de las 4 se usan

específicamente para riesgos positivos sobre los objetivos del proyecto, y la cuarta de ellas
puede emplearse de igual forma para los riesgos negativos o amenazas y los riesgos
positivos u oportunidades.
 1. Explotar. Esta estrategia su objetivo es el de asegurar que la oportunidad se
materialice es decir que se oportunidad se llegue a concretar eliminando toda
incertidumbre existente. Un ejemplo de esto podría ser el de asignar para “explotar”
a todos los recursos más talentosos en un proyecto.
2. Compartir. Significa que se asignara todo o parte del riesgo positivo u oportunidad
a un tercero mejor capacitado y sepa aprovechar mejor esta oportunidad para
beneficio del proyecto. Un ejemplo de esto es el de formar sociedades en las cuales
las partes involucradas se vean beneficiadas.
3. Mejorar. Consiste en aumentar la probabilidad e impacto de que se dé esta
oportunidad.
4. Aceptar. En esta estrategia se plantea el deseo de tomar ventaja de la oportunidad
que se presente pero si buscarla de manera activa.
3. Estrategias de Respuesta para Contingencias

Algunas estrategias están diseñadas para ser usadas únicamente si se presentan

determinados eventos. Para algunos riesgos, resulta apropiado para el equipo del proyecto
elaborar un plan de respuesta que sólo se ejecutará bajo determinadas condiciones
predefinidas, si se cree que habrá suficientes señales de advertencia para implementar el
plan. Los eventos que disparan la respuesta para contingencias, tales como no cumplir con
hitos intermedios u obtener una prioridad más alta con un proveedor, deben definirse y
rastrearse.

4. Juicio de Expertos.
Finalmente en esta se involucra a personas con amplia experiencia y / o sólidos
conocimientos los cuales atañen las acciones que se deben de tomar en el caso de que se
materialice el riesgo. Por lo regular en esta estrategia se involucran a personan que han
trabajado en proyectos similares o es experta en el tema.

Este proceso de gestión de riesgos deberá estarse monitoreando constantemente durante el

ciclo de vida del proyecto, por lo general esta revisión atrae más riesgos los cuales deberán
entrar en el proceso de gestión de riesgos anteriormente mencionado.

Un método que en mayor frecuencia se emplea en el monitoreo de riesgos, son las

reuniones sobre el estado del proyecto, en el cual el equipo de proyecto revisa cada uno de
los riesgos activos del proyecto para determinar los siguientes pasos o estrategias a emplear.

Existen herramientas las cuales ayudaran a documentar y dar seguimiento de los riesgos por
medio de plantillas predefinidas y configurables para amoldarse al cálculo de los riesgos de
cada organización.

Gesti ón de Adquisiciones.

La definición que da el PMBOK para la gestión de adquisiciones, es la siguiente:

Adquirir bienes y servicios del exterior de la organización que está desarrollando el
proyecto [ CITATION PMI \l 2058 ].
La gestión de adquisiciones del proyecto incluye los procesos de gestión del contrato y de
control de cambios requeridos para desarrollar y administrar contratos u órdenes de compra
emitidas por los miembros con autorización de los miembros del proyecto.

Los procesos en lo general para la administración de adquisiciones son los siguientes:

 Planificar las adquisiciones

 Efectuar las adquisiciones
 Administrar las adquisiciones
 Cerrar adquisiciones

Cada uno de estos procesos deben interactuar entre ellos y con los otros procesos de otras
áreas de conocimiento, este procesos al menos ocurre una vez en la vida del proyecto.

Algo importante a considerar es que los procesos de gestión de las adquisiciones del
proyecto implican la realización de contratos, los cuales estos son documentos legales, que
se establecen entre el comprador y el vendedor. Este contrato representa los acuerdos y
obligaciones, en las cuales el vendedor se ve obligado a proveer los productos, servicios o
resultados especificados en dicho contratos y el comprador se obliga a proporcionar el
dinero o cualquier contraprestación valida estipulada de igual forma en el contrato.

Según el área de aplicación, los contratos también pueden denominarse acuerdos,

convenios, subcontratos u órdenes de compra. La mayoría de las organizaciones cuentan
con políticas y procedimientos documentados que definen específicamente las reglas de
adquisición, así como quién está autorizado a firmar y administrar dichos acuerdos en
nombre de la organización.

Es recomendable que el equipo de proyecto busque el respaldo temprano de los

especialistas en contratación, adquisiciones, derecho y asuntos técnicos, esta práctica muy
comúnmente es una política mandatorio para varias organizaciones.

Una buena práctica en la gestión de las adquisiciones es la de administrar activamente el

ciclo de vida de un contrato y adicionalmente el de redactar cuidadosamente los términos y
condiciones de las adquisiciones, con esto se podrá mitigar, transferir o hasta evitar algunos
riesgos.

Los términos más comunes para identificar a un vendedor, puede ser denominado como
contratista subcontratista, proveedor, proveedor de servicios, o distribuidor, así como
dependiendo de la posición de comprador en el ciclo de adquisición del proyecto, este
podrá denominarse como cliente, contratista principal, contratista, organización
compradora, organismo gubernamental, solicitante de servicios, o simplemente comprador.
También de acuerdo al ciclo de vida de adquisiciones el vendedor puede ser inicialmente
nombrado licitador, luego la fuente seleccionada y finalmente proveedor o vendedor
contratado.
El proceso inicial de la gestión de las adquisiciones, es el de la planificación en el cual se
determina si el proyecto requerirá de apoyo externo para alcanzar los objetivos del
proyecto, si este es necesario se deberá a poner en consideración a los posibles vendedores
y se deberá considerar quien será el responsable de obtener o ser titular de permisos y
licencias profesionales que puedan ser exigidos por la legislación o alguna regulación o
política de la organización para ejecutar el proyecto.

Tipos de Contrato

A continuación se muestran algunos tipos de contrato usualmente más usados.

 Contratos de precio fijo. El punto más importante de este tipo de contrato es

que se establece un costo fijo para un producto o servicio definido que se va
prestar, estos también pueden incluir incentivos financieros para quienes
alcancen o superen objetivos seleccionados del proyecto, que pueden ser las
fechas de entrega programadas, el desempeño de los costos y técnico o por
cualquier otra cosa que pueda ser cuantificado y medido posteriormente. En este
marco de contrato fijo, los vendedores se ven obligados por ley a cumplir dichos
compromisos bajo el riesgo de afrontar eventuales daños y perjuicios financieros
si no lo hicieran. En el marco de un contrato de precio fijo, los compradores
deben tener mucha dedicación para poder definir con exactitud el producto o los
servicios que son objeto de la adquisición.
 Contratos de precio fijo cerrado. Este tipo de contrato es el más usado
comúnmente, ya que desde un inicio se fija el precio de los bienes y no
está sujeto a cambios a excepción que el alcance del trabajo se
modifique. Cualquier aumento de costos que se dé por causa de un
desempeño adverso será adsorbido por el vendedor, quien está obligado
a completar el esfuerzo. Cualquier cambio que se dé a las
especificaciones de la adquisición puede derivar en un aumento de costos
para el comprador.
 Contratos de precio fijo más honorarios. En este contrato existe cierta
flexibilidad en las desviaciones del proyecto entre ambas partes,
comprador y el vendedor. Estas desviaciones por lo regular tienen que
ver con incentivos financieros relacionados con la gestión de costos,
cronograma y el desempeño técnico.
 Contratos de precio fijo con ajuste económico de precio. Este tipo de
contrato se utiliza cuando el periodo de tiempo de desempeño del
vendedor abarca un periodo considerable de años. Se trata de un contrato
de precio fijo pero con una disposición especial que permite ajustes
finales predefinidos al precio del contrato debido a cambios en las
condiciones, tales como cambios inflacionarios o aumentos (o
disminuciones) del costo de las materias primas específicas. La cláusula
sobre el ajuste económico del precio debe tomar como referencia algún
índice financiero confiable.

Entre los aspectos más importantes a considerar en un plan de adquisidores se deberán

considerar los siguientes puntos.
  Qué, cuánto y cuándo comprar
 Responsabilidades y autoridad que tiene el equipo responsable de la procura
 Interacción que el equipo encargado de la procura tiene con otros grupos de interés.
 Cómo obtener el soporte de otras áreas de la organización, en especial cuando el
departamento de adquisiciones es externo al Proyecto.
 Cómo conseguir la autoridad que necesita para desarrollar su trabajo con relación a
la
 Procura.
 Integración del equipo encargado de la procura
 Conseguir oportunamente la información de los insumos que requerirán los
Proyectos.
 Clasificar la lista insumos por prioridad.
 De acuerdo al impacto que el insumo tiene sobre el Proyecto.
 De acuerdo a los tiempos en que el insumo deberá estar listo.
 Identificar los criterios para decidir entre comprar u obtener los recursos
internamente.
 Apoyarse en los expertos para obtener y/o validar en forma eficiente la información
que necesita acerca de procura.
 Investigar acerca de las fuentes potenciales de insumos y de la calidad de ellas.
 Programar los procesos de procura.
 Programación de obtención de Insumos
 Proceso de concurso desde el punto de vista del cliente.
 Proceso de Selección de Proveedores
 Criterios de Selección de Proveedores
 Lista de proveedores potenciales
 Gestión de la Tecnología Asociada al Proyecto.
 Para Desarrollar el Proyecto
 Tecnología propietaria.
 Tecnología Comprada.
 Tecnología Desarrollada durante el proyecto

Ejecución del proyecto

En esta fase del proyecto es donde se desarrolla la mayor acción, como se describió en la
sección anterior de la fase de planeación se detalla a precisión todas las partes del proyecto
y mientras mejor este definida esta fase mejor se ejecutara el proyecto.

Esta fase ejecución solo cuenta con un proceso principal, y la regla es sencilla “haz lo que
dijiste que ibas a hacer”
 Ilustración 7 Procesos de Fase de Ejecución

La realidad no es tan simple a como se planifico, durante la fase de la ejecución los

resultados que se estén obteniendo pueden requerir que se ajuste la planificación y se
vuelva a establecer la línea base. Adicionalmente todos los componentes que se realizaron
en la planificación ahora en la fase de ejecución se deben de manejar de forma integral.

Tales variaciones pueden afectar el plan para la dirección del proyecto o los documentos
del proyecto, y pueden requerir un análisis detallado y el desarrollo de respuestas de
dirección de proyectos apropiadas. Los resultados del análisis pueden generar la solicitud
de cambios que, en caso de ser aprobados, podrían modificar el plan para la dirección del
proyecto u otros documentos del proyecto, y requerir posiblemente el establecimiento de
una nueva línea base.

Adicionalmente de ejecutar las actividades identificadas durante el proceso de

planificación, la gestión de la fase de ejecución incluye las siguientes tareas:
 Distribución de la información
o Archivo del Proyecto
 o Juntas de Proyecto
 Juntas de Arranque
 Juntas de Revisión de Avance
o Correspondencia
 Aseguramiento de la Calidad
 Colocación de Requisiciones
 Proceso de Selección y Contratación de proveedores
 Administración de Contratos.
Cada uno de los subprocesos de la fase de Ejecución nos indica lo siguiente:

Dirigir y Gesti onar la Ejecución.

Consiste en ejecutar el trabajo que se definió en el plan para la dirección del proyecto, para
que se alcancen (cumplan) los objetivos planteados en el proyecto.

Realizar Aseguramiento de Calidad.

En este proceso se auditaran los requisitos de calidad así como los resultados obtenidos a
partir de medidas de control de la calidad a fin de garantizar que se utilicen las políticas
operacionales y normas de calidad establecidas.

Adquirir el Equipo del Proyecto.

Es aquí donde se confirman los recursos humanos con los que se dispondrán para realizar el
trabajo que formaran parte del equipo de trabajo del proyecto.

Desarrollar el Equipo del Proyecto.

Este proceso se mejora las competencias, la interacción de los miembros del equipo así
como del ambiente en general del equipo del proyecto para lograr un mejor desempeño en
el proyecto.

Dirigir el Equipo del Proyecto.

Es el proceso que consiste en dar el correcto seguimiento al desempeño de los miembros
del equipo del proyecto, proporcionar retroalimentación, resolver los problemas y gestionar
los cambios a fin de optimizar el desempeño del proyecto.

Distribuir la Información.
En este proceso se pone la información relevante a disposición de los interesados en el
proyecto de acuerdo al plan establecido así como del rol al cual pertenezcan.
Gesti onar las Expectati vas de los Interesados.
Consiste en comunicarse y trabajar en conjunto con los interesados para satisfacer sus
necesidades y abordar los problemas como se vayan presentando.

Efectuar Adquisiciones.
En este proceso consistirá en obtener respuesta de los vendedores, seleccionar un vendedor
y adjudicar un contrato.

Como puede verse en la fase de Ejecución adicionalmente de realizar las actividades

propias del proyecto, en esta también se debe de gestionar de una manera eficaz y correcta
al equipo de trabajo así como el de manejas las adquisiciones del proyecto, de aquí que el
Líder de proyecto debe tener ciertas cualidades para realizar estas tareas, las cuales son:

 Liderazgo
 Comunicación
 Negociación
 Solución de problemas
 Influencia sobre la organización

Seguimiento y Control

El grupo del Proceso de Seguimiento y Control está compuesto por aquellos procesos
requeridos para supervisar, analizar y regular el progreso y el desempeño del proyecto, para
identificar áreas en las que el plan requiera cambios y para iniciar los cambios
correspondientes [ CITATION PMI \l 2058 ].

El beneficio de este proceso radica en que el desempeño del proyecto se monitorea y se

mide de manera sistemática y regular, con el fin de identificar las desviaciones respecto a lo
que se planeó inicialmente en el plan para la dirección del proyecto.

Este seguimiento continuo proporcionara al equipo del proyecto la información necesaria

para saber de la salud del proyecto y así poder identificar las áreas que necesitan mayor
atención.
El control permitirá controlar la totalidad del esfuerzo del proyecto, los subprocesos que
incluye esta fase se describen a continuación:
 Ilustración 32 Procesos de Seguimiento y Control

Dar Seguimiento y Controlar el Trabajo del Proyecto

En este proceso se deben de realizar las siguientes acciones en el avance del proyecto con el
objetivo de cumplir con los objetivos del proyecto:

 Revisar,
 Analizar y
 Regular

El dar seguimiento implica el realizar:

 Informes de estado
 Mediciones del avance y
 Proyecciones.
Los informes de estado suministrarán información sobre el desempeño del proyecto en lo
referente al alcance, cronograma, costos, recursos, calidad y riesgos.

Realizar Control Integrado de Cambios.

En este proceso se revisarán todas las solicitudes de cambio, se aprobaran o rechazarán los
cambios, así como se gestionaran los cambios a los entregables, activos de los procesos de
la organización, a los documentos y al plan para la dirección del proyecto.

Verifi car el Alcance.

Consistirá únicamente en la formalización de la aceptación de los entregables del proyecto
que ya se hayan completado correctamente en base a lo estipulado.

Controlar el Alcance.
En este proceso se da el correcto seguimiento al estado del alcance del proyecto así como
del producto, y además se gestionan los cambios a la línea base del alcance.

Controlar el Cronograma.
En este se da el seguimiento al comportamiento de las actividades del cronograma del
proyecto, con el fin de actualizar el avance del mismo y gestionar los cambios a la línea
base del cronograma.

Controlar Costos.
En este proceso se le da seguimiento a la situación del proyecto, para poder actualizar el
presupuesto y gestionar los cambios a la línea base pertinentes a los costos del proyecto.

Realizar Control de Calidad.

Se realiza el seguimiento y se registran los resultados de la ejecución de actividades de
control de calidad, con el objetivo de evaluar el desempeño y hacer las recomendaciones de
cambios necesarios.

Informar el Desempeño.
Aquí se recopilan y distribuyen la información que contiene información sobre el
desempeño, donde están incluidos los informes de estados, mediciones del avance y las
proyecciones.

Dar Seguimiento y Controlar los Riesgos.

En este proceso se implementan los planes de respuesta a los riesgos, se les da el
seguimiento a los riesgos identificados, se seguimiento a los riesgos residuales, así también
se identifican nuevos riesgos y se evalúa la efectividad del proceso contra los riesgos a
través del proyecto.

Administrar Adquisiciones.
Consiste en administrar las relaciones de adquisidores, supervisar el desempeño del
contrato y efectuar los cambios y correcciones según sea necesario.

Esta fase en lo general se traslapa con todas las demás y su mayor impacto se presenta en la
fase de ejecución, prácticamente esta fase corresponde a la verificación de que se estén
logrando los objetivos de acuerdo a lo que se planeó y de no ser así hacer lo necesario para
lograrlo.

Cierre del Proyecto

En la definición que se dio inicialmente a Proyecto, establece que una característica es la

temporalidad, esto quiere decir que el proyecto tiene un fin, y esto dará inicio al ciclo de
vida del producto.

El cierre del proyecto está compuesto por una serie de procesos para poder realizar el cierre
de todas las actividades a fin de completar formalmente el proyecto, una fase u otras
obligaciones contractuales.

Este proceso verificará una vez completado, que los procesos definidos se hayan
completado dentro de todos los grupos de procesos a fin de cerrar el proyecto o la fase
según sea el caso y establecerá formalmente que el proyecto o fase del mismo ha finalizado.

En el cierre del proyecto o fase puede ocurrir lo siguiente:

 Obtener la aceptación del cliente o del patrocinador,

 realizar una revisión tras el cierre del proyecto,
 registrar los impactos de la adaptación a un proceso,
 documentar las lecciones aprendidas,
 aplicar actualizaciones apropiadas a los activos,
 archivar todos los documentos relevantes del proyecto en el sistema de información
para ser utilizados como datos históricos,
  cerrar las adquisiciones.

Los procesos que incluye el cierre del proyecto son los siguientes:

Cerrar el Proyecto o Fase.

Este proceso consiste en la finalización de todas las actividades a través de todos los grupos
de procesos de la dirección de proyectos para completar formalmente el proyecto o una fase
del mismo.

Cerrar las adquisiciones.

Es el proceso en el cual se da por finalizado cada adquisición del proyecto.
Bibliografía
Loyd Rue, L. (s.f.). Administración, teoría y aplicaciones. Alpha y Omega.
MarketScope de Gartner. (s.f.). Obtenido de MarketScope de Gartner:
http://www.gartner.com/technology/media-
products/reprints/microsoft/vol14/article21/article21.html
Medinilla, Á. (2006). Beneficios de la Gestión de Proyectos en la Empresa. Obtenido de
Beneficios de la Gestión de Proyectos en la Empresa:
http://www.presionblogosferica.com/2006/09/19/beneficios-de-la-gestion-de-
proyectos-en-la-empresa/
Mercado, R. V. (s.f.). Apuntes Administración de Proyectos. (Ramón Vazques del Mercado,
Intérprete)
P. Clements, J., & Gido, J. (1999). Administración Exitosa de Proyectos. Thomson.
PMI. (s.f.). Guía de los Fundamentos de la Dirección de Proyectos PMBOK. Newtown
Square Pennsylvania: PMI.
PMI Site. (s.f.). Obtenido de PMI Site: http://www.pmi.org/About-Us.aspx
S., R. (s.f.). Ingeniería de Software un Enfoque Práctico. Mc Graw Hill.
Sommerville, I. (s.f.). Ingeniería de Software. Prentice Hall.