Pmi Resumen Egv
Pmi Resumen Egv
¿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.
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.
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.
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.
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.
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.
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:
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:
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.
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
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.
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.
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 ]
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.
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.
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
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 ].
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.
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.
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:
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
Proyecto
Administración de Proyectos
1. Iniciación,
2. Planificación,
3. Ejecución,
4. Seguimiento y Control, y
5. Cierre.
Conocimiento
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
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.
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.
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
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.
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 ].
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.
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
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.
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 ].
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.
Inicio
Planeación del alcance
Definición del alcance
Verificación del alcance
Control de cambios del alcance
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
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
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
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.
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.
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.
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.
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 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:
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?
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.
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.
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.
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.
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.
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 ].
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.
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
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.
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.
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
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.
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.
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á
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
Para contestar, la segunda pregunta hay que preguntarse varias más, las cuales se muestran en la tabla a
continuación.
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.
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.
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.
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.
En la preparación del documento de constitución formal, se deben hacer las siguientes consideraciones:
Entre las responsabilidades Ing. Antonio Castro Lopez están las siguientes:
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.
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.
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
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.).
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.
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.
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.
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.
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:
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.
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:
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:
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.
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 %.
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 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.
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.
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.
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.
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 guía del PMBOK nos propone los siguientes pasos para poder desarrollar un cronograma de manera
eficaz.
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.
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.
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
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.
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.
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.
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.
Nivelación de Recursos:
La nivelación de recursos se utiliza para optimizar la distribución del trabajo entre los recursos.
Estimar los Costos es el proceso que consiste en desarrollar una aproximación de los recursos
monetarios necesarios para completar las actividades del proyecto.
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:
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.
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:
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:
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.
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 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.
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.
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.
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.
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.
R= Responsable
A= Autoriza
S= proporciona Soporte
I = Informado
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.
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.
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á?
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.
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 ]
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.
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:
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.
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.
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 ]
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.
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.
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.
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.
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.
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.
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
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
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.
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.
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 ].
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
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.
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.
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.
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.
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.
Los procesos que incluye el cierre del proyecto son los siguientes: