Marble Station

Sergi Blanco-Cuaresma

Menu Skip to content

Principal

Blog

Curriculum

Apuntes y prcticas

Administracin de empresas

Astrofsica

Ingenieria Informtica

Contacto

Principio del formulario

Search
Search for:

Final del formulario

PMBOK, Project Management / Gestin de proyectos

Tuesday 13 May 2008Espaol, Negociosmarble

El Project Management Institute (PMI) es una organizacin que intenta establecer un orden y
unos criterios estndares para la gestin de proyectos. Con esa finalidad, PMI mantiene el
libro Project Management Book of Knowledge (PMBOK) donde se establecen todo un conjunto
de herramientas y buenas prcticas que todo jefe de proyecto debe conocer y aplicar.

En contraposicin a otras metodologas (p.ej. las metodologas giles como Scrum), PMBOK se
encuentra orientado a una gestin predictiva de los proyectos. PMBOK presenta diversas fases
de un proyecto de forma lineal (una vez superada una fase, no se volver a ella), donde la
necesidad/solucin, el alcance y la planificacin (p.ej. coste y duracin de cada una de las
tareas a realizar) se establece en las fases iniciales (de ah que sea denominada gestin
predictiva).
Por tanto, podramos considerar PMBOK como perteneciente a la rama ms clsica de la
gestin de proyectos (al igual que el estndar complementario PRINCE2, popular en UK). No
obstante, este hecho no implica que parte de las herramientas que ofrece no puedan ser
utilizadas en combinacin con otras metodologas ms giles y flexibles.

Introduccin

Antes de empezar en materia es necesario establecer la definicin y las caractersticas de un

proyecto segn el PMBOK:

Un proyecto intenta dar solucin a un problema (cubrir una necesidad).

Es temporal

Es nico en el tiempo y no repetible bajo las mismas circunstancias

Conlleva incertidumbre

Consume recursos: Tiempo, dinero, materiales y trabajo.

Los proyectos disponen de su propio ciclo de vida, el cual se divide en las siguientes fases:

Inicio: Se identifica la necesidad y se cuestiona si es posible llevar a cabo el proyecto.

Planificacin:

Se desarrolla una solucin en un mayor detalle.

Definicin de tareas, calendario.

Estimacin de costes en tiempo y dinero.

Se vuelve a plantear si es factible el proyecto.

Ejecucin: Monitorizacin y ajustes a la planificacin.

Cierre: Se comprueba si el proyecto satisface la necesidad a cubrir

Todas estas fases, implican los siguientes proceso generales:

Identificar el problema o la oportunidad

Identificar y definir la solucin idnea

Identificar las tareas y los recursos necesarios.

Preparar el calendario y la obtencin de recursos

Estimar el coste del proyecto y preparar un presupuesto

Analizar los riesgos y establecer relaciones con los stakeholders (toda persona que tenga un
inters directo o indirecto en el proyecto): Gestin del riesgo peridico

Mantener el control y la comunicacin en el nivel adecuado durante la ejecucin: Reuniones

peridicas para detectar y comunicar desviaciones

Gestionar un cierre satisfactorio

Punch list: listado de tareas para poder acabar el proyecto.

Los miembros del equipo tienden a dispersarse dado que el proyecto se encuentra casi
cerrado.

No obstante, un proyecto puede ser visto desde otras perspectivas, como por ejemplo desde el
punto de vista de las relaciones interpersonales:

Motivar al equipo: Crear el clima adecuado

Invertir tiempo en explicar como cada funcin contribuye al proyecto

Invertir tiempo en las reuniones para destacar contribuciones positivas de los miembros.

Confiar en el trabajo delegado

Asignar objetivos a los individuos y permitir que ellos escojan el camino.

Reconocer los esfuerzos que van ms all de lo solicitado.

Predicar con el ejemplo

Gestionar la diversidad

Identificar posibles objetivos personales para minimizarlos o convertirlos en objetivos

grupales.

Buscar la cohesin del grupo (armonizar costumbres, culturas, etc.).

A su vez, aparte de los procesos internos propios de la gestin del proyecto y las relaciones
interpersonales, los proyectos se gestan y ejecutan dentro del mbito de una organizacin.
Actualmente podemos encontrar compaas cuyo negocio principal es la ejecucin de
proyectos, por ejemplo en el sector de la Consultora y la Auditora. Ese es el escenario ms
positivo, dado que toda la organizacin se encuentra orientada hacia la gestin de proyectos.

Sin embargo, la mayora de empresas tienen una estructura jerrquica constituida por
departamentos con funciones diferenciadas y empleados que realizan tareas especficas, cuya
movilidad tiende a ser ms bien espordica. En este tipo de escenario, la ejecucin de un
proyecto (que como se ha establecido es temporal) con empleados internos presenta un
escenario ms difcil de gestionar (esta es una de las razones por las que en multitud de
ocasiones los proyectos son contratados a consultoras y auditoras externas).
Esta segunda situacin puede aportar empleados con Silo Mentality, es decir, personas
cuyos objetivos se encuentran ligados a su rea funcional y no al proyecto al que han sido
asignados; puede que no les importe el xito del proyecto, dando preferencia a cumplir con
sus obligaciones estables de su unidad departamental. Esta problemtica puede bloquear la
cooperacin del equipo de trabajo (horitzontal thinking).

En definitiva, el grado de madurez de la organizacin y los procedimientos internos

establecidos pueden contribuir al xito o fracaso del proyecto:

Si la organizacin trabaja habitualmente en proyectos, se dispone de pautas ya definidas.

Vas de comunicacin formal: Si son muy rgidas pueden entorpecer el trabajo

Vas de comunicacin informal (amistades, conocidos, etc.): Si son muy frecuentes puede
producir desinformacin

Finalmente, PMBOK establece que para poder considerar que un proyecto ha sido exitoso se
deben cumplir las siguientes expectativas:

Nivel I. Alcanzar los objetivos del proyecto

Nivel II. Eficiencia del proyecto.

Nivel de interrupcin del trabajo del cliente.

Eficiencia en el uso de los recursos

Crecimiento del nmero de miembros del equipo

Gestin de conflictos

Nivel III. Utilidad para el usuario/cliente final.

Ha sido solucionado el problema inicial?

Se han incrementado los beneficios o se ha producido ahorro real?

El usuario se encuentra actualmente usando el producto?

Nivel IV. Mejora organizacional: Aprender sobre la experiencia

Jefe de proyecto

Un jefe de proyectos o project manager tiene las siguientes responsabilidades:

El proyecto: Objetivos de coste, calendario, funcionalidad y calidad.

La organizacin

Retorno de la inversin.
Flujo de informacin: proporcionarla de forma proactiva, si un supervisor se sorprende de
algn dato es que no hemos informado correctamente.

El equipo: Proporcionar feedback y reconocimiento.

Sobre l mismo: Crecimiento personal.

Por otra parte, el jefe del proyecto se enfrenta constantemente a retos entre los que se pueden
encontrar los siguientes:

Responsabilidad versus Ausencia de autoridad

Alto nivel de responsabilidad.

Trabajo con personas sobre las que no existe una autoridad directa.

Objetivos no realistas

Es uno de los problemas ms habituales.

Refuerza la idea de analizar y planificar correctamente el alcance del proyecto.

Orientacin funcional

Las personas tender a centrarse en su rea de conocimiento funcional.

Es ms importante su rea funcional que el proyecto dada su temporalidad.

Conflicto fundamental sobre la incertidumbre

Toma de decisiones rpidas con poca informacin.

Estimaciones de rango (e.g. costes)

Intentar hacer entender las dificultades de las estimaciones a los superiores y a los miembros
del equipo.

Con la finalidad de afrontar exitosamente las responsabilidades y retos que presenta la

gestin de proyectos, un jefe de proyectos debe mejorar de forma constante las siguientes
habilidades:

Gestin del proyecto: Herramientas para la planificacin y monitorizacin.

Relaciones interpersonales

Capacidad de liderazgo, negociacin y delegacin.

Capacidad comunicativa oral y escrita

Resolucin de conflictos.
Habilidades para desarrollar el rol de mentor (coaching)

Conocimiento tecnolgico

Conocimiento de la industria y de las reas tecnolgicas

Conocimiento del producto y/o procesos

Habilidades de diseo

Habilidades personales

Honestidad, integridad

Pensar globalmente

Alta tolerancia a la incertidumbre y a la ambigedad

Persuasivo y asertivo

Abierto y accesible

Decisivo

Comercial. Capacidad para vender ideas o las propias virtudes del proyecto.

Profesor. Transmitir conocimiento a los miembros del equipo.

Definicin del proyecto

La definicin del proyecto se encuentra constituida por las siguientes fases:

Fase I. Entender el problema o la oportunidad.

Fase II. Identificar la solucin ms optima

Fase III. Desarrollo de la solucin y elaboracin de un plan

Fase IV. Lanzamiento del proyecto

Fase I. Entender el problema o la oportunidad.

Es fundamental identificar la necesidad real que el proyecto pretende cubrir. El trabajo se

evaluar en funcin de si esta necesidad ha sido cubierta satisfactoriamente o no.

En primer lugar se requiere diferenciar entre necesidad y solucin. Una necesidad:

Describe el fin para cliente

Especifica metas y objetivos

Deja abierta la pregunta de cmo hacerlo.

La respuesta al porque se esta haciendo debe apuntar a una justificacin de negocio.

En cambio, una solucin:

Describe los medios para el equipo

Especifica estrategias e ideas para conseguir las metas y objetivos.

Especifica cmo hacerlo.

La respuesta al porque se esta haciendo debe apuntar al requerimiento del cliente.

Preguntar para identificar la necesidad real puede hacer sentir incomodo a terceros por
desconfiar de su criterio.

En base a estas definiciones, esta fase debe tener como output la generacin del documento de
requerimientos del proyecto, el cual no ofrece una solucin sino que nicamente describe una
necesidad. Este documento debe contener los siguientes apartados:

Descripcin del problema o oportunidad

Impacto o efecto del problema

Identificar quien o que se encuentra afectado por el problema

Impacto de ignorar el problema

Situacin deseada

Beneficios asociados a conseguir la situacin deseada

Alineacin con la estrategia de la organizacin

Conflicto de compatibilidades con otras reas de la organizacin

Incertidumbres

Suposiciones clave

Limitaciones de la solucin

Consideraciones del entorno

Informacin histrica de soporte

A partir de la recopilacin de toda esta informacin, se requiere valorar nuevamente si

merece la pena resolver el problema y determinar si existe una solucin potencial.

Fase II. Identificar la solucin ms ptima

Con objeto de identificar soluciones que cubran la necesidad establecida se puede seguir el
siguiente procedimiento:

Brainstorming grupal con miembros del futuro equipo de trabajo o stakeholders.

Comprobar en que grado satisfacen los planteamientos del documento de requerimientos del
proyecto.

Seleccionar entre 2 y 5 soluciones candidatas.

Para las soluciones candidatas seleccionadas conviene realizar un anlisis detallado para
identificar cual de ellas es la que mejor se adapta a la necesidad a cubrir e implica un coste
asumible.

Anlisis financiero (Costes vs Beneficios):

Para validar la viabilidad financiera del proyecto es necesario identificar los flujos de entrada
de dinero que este puede generar, por ejemplo beneficios obtenidos por la implementacin
del proyecto (incremento en ventas, reduccin en costes, etc) y los gastos que representa la
puesta en marcha y gestin del proyecto.

Por tanto, estimando la magnitud de los diferentes cash flows y calculando los 4 indicadores
bsicos, podemos identificar que proyecto nos aporta una mayor rentabilidad financiera.

Conviene estudiar al menos los siguiente indicadores:

Net Present Value (NPV). Determina cuanto dinero va a generar el proyecto teniendo en
cuenta el valor del dinero en el tiempo.

Internal Rate of Return (IRR). Determina la rentabilidad de la inversin.

Payback period. Determina cuando se recuperar la inversin (NPV = 0).

Cash hole. Determina la mxima inversin necesaria.

Anlisis no financiero (Modelo de puntuacin de factores ponderados Decision matrix)

El anlisis mediante el modelo de puntuacin de factores ponderados (Decision Matrix) se

inicia mediante la elaboracin de un listado de atributos a valorar. Para cada uno de ellos se
establece una ponderacin y se asignan puntuaciones que denoten el nivel de cumplimiento
de cada una de las soluciones candidatas:
Ventajas:

Permite el uso de diversos datos, incluidos los financieros.

Permite la implicacin de gerencia y el anlisis de sensibilidad.

Desventajas:

Proceso altamente subjetivo.

Muestra el atractivo del proyecto pero no representa una justificacin de negocio.

Aparte de los anlisis financieros o de matrices, la decisin final sobre que solucin escoger se
puede basar en el uso de otras herramientas:

Estudios de mercado

Pruebas piloto. Prueba en rea limitada.

Prototyping. Construccin de una pequea parte del proyecto para validar las correctas
predicciones.

Simulacin por ordenador.

En definitiva, los anlisis efectuados no solo ayudaran a elegir una solucin sino que tambin
permitirn determinar si las soluciones son viables y si vale la pena continuar con el proyecto.

Fase III. Desarrollo de la solucin y elaboracin de un plan

En esta fase se desarrollar en un mayor detalle la solucin escogida mediante el uso de un

Logframe (esquema bsico de definicin del proyecto).

El logframe se encuentra dividido en varios niveles:

Objetivo

Propsito

Resultados

Actividades
Para cada uno de estos niveles se debe especificar:

Indicadores que permitan verificar la evolucin.

Medios para obtener la informacin necesaria para constituir los indicadores.

Supuestos clave y el riesgo asociado.

A partir de la presentacin esquemtica de los aspectos clave del proyecto, el logframe

permitir monitorizar y evaluar la evolucin del mismo. Un logframe debe ser conciso y
fcilmente comprensible por personas que se incorporan a mitad de proyecto.

Paralelamente a la elaboracin del logframe, se requiere realizar un anlisis de los

stakeholders del proyecto con el objetivo de gestionar las relaciones y prever oposiciones.

Se considera stakeholders aquellos individuos o instituciones que:

Pueden ganar o perder dependiendo del xito del proyecto.

Proveen fondos econmicos

Proveen recursos al proyecto

Participa/trabaja en el proyecto

Se encuentran afectados por el rendimiento del proyecto

Se encuentran afectados por el resultado del proyecto

Ejemplos:

Stakeholders internos: Cliente interno, Sponsor, El equipo de trabajo, Gerentes, Sindicatos, etc.

Stakholders externos: Cliente externo, Usuarios, Instituciones reguladoras, Organizaciones

(e.g. ecologistas), etc.

Para cada uno de los stakeholders identificados, crearemos la siguiente tabla mediante la cual
podremos definir el objetivo a cumplir con cada uno de ellos:
Finalmente, se realizar el documento de definicin de proyecto (secundario en funcin del
tipo del proyecto) con la finalidad de:

Identificar el trabajo a realizar.

Durante la ejecucin, permite identificar cuando se esta sobrepasando los limites y permite
renegociar el contrato original.

Establece el criterio para considerar completado el proyecto.

Establece los criterios para considerar exitoso el proyecto.

Permite llegar a acuerdos y facilitar la comunicacin.

El nivel de detalle del mismo no tiene que ser excesivo (no se dispone de suficiente
informacin para hacer estimaciones exactas), sino que se recomienda proporcionar
valoraciones mediante rangos (e.g. costes entre 100.000 y 130.000, duracin entre 17 y 19
meses).

En definitiva, el documento debe contener los siguientes apartados:

Breve descripcin del problema u oportunidad

Breve descripcin de la solucin propuesta

Descripcin del trabajo y la estrategia de ejecucin. Identificar las diferentes grandes tareas y
sus interrelaciones. Parte ms importante del documento. Ser la base para el WBS.

Entregables acordados.

Criterios de finalizacin de proyecto.

Riesgos e incertidumbres.
Suposiciones.

Plan preeliminar de ejecucin.

Listado de los stakeholders involucrados.

Criterios de xito del proyecto.

Fase IV. Lanzamiento del proyecto

Antes de realizar el lanzamiento, es importante verificar que dispondremos de todos los

recursos necesarios. Una vez confirmado este aspecto, se requieren dos pasos: obtener la
aprobacin definitiva de la direccin y reunir al equipo de trabajo seleccionado para
informarlos del proyecto en el que van a participar.

De cara a la aprobacin por la direccin, es recomendable la elaboracin de un documento de

propuesta que contenga los siguientes apartados:

Breve descripcin de las necesidades

Acciones recomendadas

Beneficios

Riesgos a asumir si se lleva a cabo la accin

Riesgos a asumir si no se realiza ninguna accin

Costes y ahorros (estimaciones en rangos de valores)

Calendario

Mtricas (como se medir el resultado para valorar el xito)

Incertidumbres

Suposiciones

Limitaciones

Apoyo requerido

Listado de organizaciones que deben involucrarse y en que medida

Impacto en el resto de la organizacin

Sponsorship. Grado de apoyo activo por parte de la direccin.

Factores crticos para el xito.

Por otra parte, la reunin inicial con el equipo de trabajo (Kickoff meeting) debe encontrarse
dirigida hacia los siguiente objetivos:

Reconocer la formacin oficial del equipo.

Indicar cuales son las expectativas.

Promover la cohesin del grupo.

Construir y mantener un equipo efectivo.

El equipo de trabajo es una de las partes claves del proyecto. Antes de iniciar el trabajo, en el
Kick-off meeting por ejemplo, conviene anticiparse a las preguntas y ansiedades del equipo:

Me conviene el proyecto?

Que se espera de mi?

Como ser el trabajo en equipo?

Cada equipo es un mundo y su evolucin depende en gran parte de las capacidades y

experiencias de los miembros del mismo. No obstante, en trminos generales se podran listar
las siguientes fases evolutivas:

Formacin

Los miembros del equipo requieren adquirir conocimientos sobre el proyecto y comprobar su
relacin con el resto.

El jefe de proyecto debe organizar y proveer la mxima informacin.

Reaccin

En base a lo aprendido, los miembros del equipo valoran los objetivos, roles y relaciones
establecidas. Puede dar lugar a conflictos.

El jefe de proyecto debe guiar e intentar llegar a soluciones pactadas para los conflictos
generados.

Normalizacin

Si se superan los posibles conflictos de la etapa anterior, se pasa a la normalizacin mediante

la creacin de normas de conducta.

El jefe de proyecto debe animar a cada uno de los miembros a participar ms activamente.
Potenciar la sensacin de propiedad por parte de los miembros hacia sus objetivos y tareas.

Accin

El equipo funciona con un buen grado de autonoma, produciendo resultados de calidad.

El jefe de proyecto debe ser un facilitador del flujo de trabajo.

Principios de la planificacin y estimacin.

Toda planificacin se ve determinada por las siguientes dimensiones:

Coste

Tiempo

mbito (scope)

Los fallos ms habituales al realizar una planificacin son los siguientes:

No planificar por falta de tiempo o por la presin de los deadlines.

No planificar en suficiente detalle. Se recomienda que el desglose de tareas a realizar llegue
hasta aquellas que tengan una duracin de:

40-80 horas de trabajo

4% de la duracin estimada total del proyecto

No mantener la planificacin actualizada

Las estimaciones nicamente son predicciones aproximadas sobre elementos inciertos. Por
tanto, para llevarlas a cabo pueden emplearse diversas estrategias:

Preguntar a la persona que va a hacer la tarea

Preguntar a un experto en la materia

Usar datos histricos

Utilizar pruebas o simulaciones

Preparar la estimacin tu mismo

Planificacin

Definiciones previas:

Actividades o tareas: Elementos de trabajo que consumen recursos, tienen una duracin
limitada y un coste determinado.

Paquetes de trabajo: Conjunto de actividades que generan un entregable o una meta

significativa.

Toda planificacin de proyectos se inicia mediante la elaboracin del Work Breakdown

Structure (WBS). El WBS es una herramienta visual que permite identificar las diferentes
tareas de un proyecto y consiste en una estructura arbrea de diversos niveles.

La elaboracin debe estar centrada en la definicin de piezas de trabajo, sin tener en cuenta
limitaciones temporales, dependencias, recursos, etc

Ejemplo:
El WBS es una modelo visual ideal para la presentacin a la direccin dado que ofrece una
perspectiva real de todo el trabajo que el proyecto implica. Por otra parte, proporciona una
estructura lgica que facilita la determinacin de la duracin y coste de cada tarea, adems de
la asignacin de recursos y responsables.

Continuando con la planificacin, para cada tarea del WBS se debe estimar:

Duracin

Coste
mbito (Trabajo a realizar)

Responsable

Recursos

Relaciones con otras tareas

En la identificacin de responsables se puede hacer uso de la Responsibility Assignment

Matrix (RAM), mediante la cual se define como los participantes interactan en las diferentes
tareas. En general, permite identificar el tipo de interaccin (responsable, requiere
aprobacin, soporte, etc.). Por ejemplo:

A partir del WBS y la RAM, el siguiente paso es la elaboracin de un diagrama de red.

Definiciones:

Actividad crtica: Aquella tarea que no puede desplazarse en el tiempo.

Camino crtico: El camino ms largo del diagrama lgico de red.

Slack: Margen de tiempo que una tarea se puede adelantar o atrasar.

Forward/Backward pass: Tcnica para analizar la cantidad de slack de cada tarea.

Milestone: hito.

En este punto, se debe elaborar un diagrama de red partiendo de las tareas identificadas en el
WBS. Por una parte se especificaran las relaciones entre actividades y por otra se
considerarn los recursos necesarios y las limitaciones que estos imponen. Para cada tarea se
debe contemplar:

Que actividades deben completarse antes de iniciar la tarea.

Que actividades no pueden empezar hasta que la tarea no este acabada.

Que tareas pueden ser llevadas a cabo en paralelo.

Esfuerzo: horas de trabajo por parte de la persona asignada

Duracin: Ventana de tiempo en la que la actividad se completar, variar en funcin de la

disponibilidad de los recursos, periodos de inactividad, fines de semana, vacaciones, etc

A partir de esta informacin, es posible desarrollar el diagrama de red:

Mediante este diagrama podemos calcular el camino crtico utilizando la tcnica

forward/backward passes. Esto significa la ejecucin de los siguientes clculos en 2 pases:

Forward pass

La primera actividad empieza en el da 0

El da final se obtiene de sumar el inicial ms la duracin.

Para los siguientes bloques se escoge el da de fin mayor de los anteriores.

Backward pass

Se parte del da final de la ltima actividad.

Se calcula el da inicial de la ltima actividad, restando la duracin al da final resultante del

forward pass.

Para los anteriores bloques se escoge el da de inicio menor de los siguientes.

Para cada tarea, la diferencia entre el da de inicio segn el forward pass y el da de inicio
segn el backward pass es el slack. El slack es el margen de tiempo que una tarea se puede
adelantar o atrasar. Las tareas sin slack pertenecen al camino crtico, dado que un retraso de
estas (por mnimo que sea) impacta en todo el proyecto.

Finalmente podremos comparar la fecha de finalizacin resultante con la estimada y evaluar si

es posible cumplir las expectativas.

Ejemplo del diagrama de red con los clculos efectuados:

En este punto, en base a las duraciones de las diferentes tareas, debemos desarrollar el
diagrama de Gantt:

De forma complementaria, se debe llevar a cabo una gestin de los costes en los que el
proyecto va a incurrir. Para ello se identificarn los costes asociados a cada tarea en funcin
de los recursos utilizados:
Coste directo: gasto que se puede identificar rpidamente y es generado por la ejecucin del
proyecto

Mano de obra

Materiales

Proveedores y equipamiento

Formacin

Viajes y otros gastos

Costes indirectos: gastos que dan soporte a los servicios generales, ambiente organizacional,
etc

Instalaciones

Costes administrativos

Gestin de la incertidumbre y el riesgo.

Antes de iniciar esta seccin, es necesario establecer que entendemos por incertidumbre y
riesgo:

Incertidumbre: Ausencia de informacin o conocimiento respecto a una accin, decisin o

evento.

Riesgo. Cantidad de incertidumbre existente.

Una aproximacin vlida para la gestin del riesgo conllevara la identificacin de las
amenazas existentes y la cuantificacin de la severidad de las mismas (probabilidad de
ocurrencia e impacto):

Para las amenazas de mayor severidad se puede optar por disear una respuesta que siga
alguna de las siguientes estratgias:

Evitar la amenaza siguiendo otro camino

Transferir la responsabilidad del riesgo a otra persona

Asumir la existencia del riesgo y solo actuar si este aparece

Prevenir para intentar reducir la probabilidad de ocurrencia

Intentar mitigar el impacto

Realizar un plan de contingencia y definir las acciones a llevar a cabo en caso de

materializarse el riesgo.

Uno de los puntos ms difciles de abordar y que mayor riesgo puede presentar son las
estimaciones de tiempo. Una tcnica comnmente utilizada para intentar reducir este riesgo
es el uso del PERT: Program Evaluation and Review Technique.

El PERT intenta integrar la variabilidad de las estimaciones, obligando a definir para cada
actividad:

Una estimacin pesimista

Una estimacin optimista

La estimacin ms probable

En base a estos 3 parmetros, se realiza el siguiente clculo:

Ajuste al riesgo = (Pesimista + Optimista + 4*Ms probable) / 6

El resultado de la misma se utilizara en la elaboracin del diagrama de red que se ha

presentado en la seccin anterior.

Control y seguimiento del proyecto

El objetivo del control consiste en detectar desviaciones respecto a la planificacin inicial y

realizar estimaciones sobre cual ser la desviacin al final del proyecto.

Desviacin final del proyecto = Desviacin actual calculada + Desviacin futura estimada

En trminos generales, puede llegar a ser ms valioso estimar que al final del proyecto se
habr consumido un 10% ms de lo presupuestado, que indicar que actualmente se lleva
consumido un 7% de lo presupuestado.

Suele ser fundamental focalizarse en la desviacin final dado que permite tomar decisiones en
funcin del objetivo final y no al problema puntual actual.

Por regla general, en cualquier proyecto se deben controlar la siguientes dimensiones:

Calendario

Coste

Funcionalidades

Calidad

Con el objetivo de ejercer las tareas de control se requiere recopilar la siguiente informacin
de forma peridica:

Calendario

Fecha de inicio y fin planificada de cada tarea

Fecha de inicio y fin de las tareas ya realizadas

Fecha de inicio de las tareas en ejecucin.

Progreso realizado de las tareas en ejecucin.

Coste

Gastos o horas de trabajo estimadas para cada tarea

Consumo de las tareas ya finalizadas.

Consumido hasta el momento por las tareas en ejecucin.

Funcionalidades

Resultado planificado (mbito)

Prediccin del resultado (mbito)

Calidad

Resultado planificado (profundidad)

Prediccin del resultado (profundidad)

La recopilacin de la informacin se suele efectuar por alguna de las siguientes vas:

Reuniones peridicas: La periodicidad no debe superar el 4% de la duracin total del

proyecto.

Formularios y plantillas: Proporcionar una hoja de calculo con las tareas del WBS junto a las
variables a controlar (fechas, costes, etc.) a cada miembro del equipo y solicitar que se
mantenga actualizada.
Management by Walking Around (MBWA): Comprobar la motivacin y visin de los
componentes en reuniones informales

El project manager debe analizar la informacin mediante herramientas informticas o

manuales que le permitan:

Disponer de un diagrama de Gantt que muestre:

Baseline de la planificacin inicial

Diagrama segn estado actual (tareas ya realizadas, tareas en ejecucin y nuevas estimaciones
para las tareas pendientes)

Grfica acumulativa del gasto en el tiempo:

Planificada

Actual junto a la nueva proyeccin

Tabla de gastos:

En el momento en el que se detecten desviaciones, el project manager se encuentra obligado a

elegir alguna estrategias de recuperacin, considerando siempre las posibles penalizaciones
que estas suponen:

Recuperar la desviacin en tareas futuras

Aadir recursos

Aceptar substituciones

Utilizar mtodos de trabajo alternativos

Ofrecer incentivos para incrementar el rendimiento

Renegociar el coste y el calendario del proyecto

Reducir el mbito/alcance

Cierre del proyecto

El cierre del proyecto puede llegar a ser confuso y lento dada la habitual perdida progresiva
de recursos.

La mejor forma de afrontar esta etapa es elaborando una lista de tareas a realizar (punch list)
para dar por concluido el proyecto. Es importante validar que los criterios de finalizacin
establecidos al inicio del proyecto se encuentran cubiertos.

Con el objetivo de aportar valor al equipo y habilitar la aplicacin de estrategias de mejora

continua, resulta interesante realizar las siguientes tareas en el cierre del proyecto (o incluso
durante la ejecucin) dado que puede resultar positivo para el rendimiento del equipo y la
satisfaccin del cliente:

Obtener informacin sobre el nivel de satisfaccin del resultado.

Por parte del cliente interno/externo.

Por parte de cada uno de los miembros del equipo.

Reconocer mritos.

Sugerencias de mejora.

Transferir el conocimiento adquirido durante el proyecto.

Finalmente, cabe destacar que la documentacin resultante de la planificacin y del control

pueden servir como base histrica para futuros proyectos con caractersticas similares.

Conclusin

Las herramientas y buenas prcticas ofrecidas por el Project Management Institute mediante
el PMBOK constituyen una aportacin de valor para la gestin de proyectos. Si bien, en su
totalidad no resultan tan giles y flexibles como otras metodologas (p.ej. Scrum, Lean, etc.), si
es posible extraer ideas y tcnicas que contribuyan al xito en la gestin de proyectos y
personas.

Post navigation

La crisis financiera PRINCE2 como complemento a PMBOK para la gestin de proyectos

(project management)

37 thoughts on PMBOK, Project Management / Gestin de proyectos

 n3cr05 says:

Tuesday 27 May 2008 at 12:02:21

Sergio, genial como siempre

Reply

marble says:

Tuesday 27 May 2008 at 22:22:31

Me alegro que te haya gustado!! Sigo aprendiendo metodologias y tcnicas de

gestin de proyectos, a ver si encuentro tiempo para publicar ms cosas al respecto que creo
que es un tema interesante.

Reply

Arnol says:

Friday 15 November 2013 at 1:11:12

Buenas
Estoy en proceso de aprendizaje de project y primavera, agradezco me colabore con
informacin donde se me facilite el aprendizaje de los mismos.

Muchas gracias

Reply

Douglas Mora Arias says:

Sunday 20 July 2008 at 20:03:31

Muchas gracias por la informacion, ha sido de gran ayuda para mis estudios. Tal vez podrias
ayudarme a encontrar la diferencia entre lo que es un cambio en el alcance vrs cambio de
diseo.
Gracias.

Reply

marfi says:

Saturday 7 February 2009 at 20:08:37

Es genial, yo estoy tomando cursos de MBF, MFR Y HOSHING. Estos te pueden servir para
fortalecer tu informacin.

Reply

amedina says:

Thursday 26 March 2009 at 14:46:20

Exelente me sirvi mucho, gracias!!

Reply

Nieves says:

Saturday 30 May 2009 at 1:18:07

Gracias! Detrs de este resumen hay mucho trabjo. Me ha ayudado mucho. Nieves

Reply

Fernando Martinez Wilches says:

Thursday 16 July 2009 at 17:35:27

Exelente me sirvi mucho, gracias!!

Reply

Pablo says:

Tuesday 4 August 2009 at 12:32:46

En el master de Project Management que estoy haciendo se habla de todo esto, y tu resumen
me ayud a comprender bastante mejor toda la informacin.
Por cierto, se llama Master DAP, y en su pgina web (www.master-dap.org) hay bastantes
cosillas interesantes. Si no te importa hablar un poco de tu articulo en alguna de las clases
que tenemos.
Gracias ;).

Reply

Edwin Cisneros says:

Friday 7 August 2009 at 13:35:44

Es posible que me puedan facilitar mayor informacin al respecto?.

Saludos, Edwin

Reply

Roco says:

Monday 24 August 2009 at 5:11:50

Hola! quiero felicitarte Sergi,

wow!.he estado buscando informacin sobre PMBOK y todos me hablan a medias de lo que
es
y de como se puede usar, pero esta web est genial,

muchas gracias por compartir.

Saludos!

Reply
 alfredo says:

Wednesday 18 November 2009 at 8:26:26

Wow. Soy nuevo en esto de los proyectos, PMBOK, Certificaciones de Calidad pero
sinceramente todo, hasta hoy, me ha servido de mucho para hacer mis tareas y creo que ests
dando frmulas aplicables en el campo laboral y no solo informacin Se trata de dejar
puntos te dar los ms elevados y mis agradecimientos.

Reply

Eddysan says:

Thursday 17 December 2009 at 14:48:58

Excelente articulo, estoy tomando los rumbos de gestion de proyectos y tu articulo me parecio
muy concreto, resume muy bien lo que es PMBOK Felicidades!!!

Reply

Israel Garca Real says:

Tuesday 29 December 2009 at 15:28:18

Muy buen resumen. Lo he usado como referencia en mi blog Por si lo quieres ver:
http://www.israelgarciareal.es/?p=22

Reply

Pingback: Tipos de ofertas. El Blog de I. Garcia Real

fer says:

Thursday 18 March 2010 at 19:39:08

buenisimo gracias !
Reply

JESS says:

Friday 19 March 2010 at 22:57:22

BUEENA EXPLICACION QUE BIEN QUE EXISTA PERSONA QUE COMPARTE INFORMACION

CHIDO Y COMO SIEMPRE SE DICE EL COMENTAR ES AGRADECER

Reply

Eduardo says:

Tuesday 23 March 2010 at 22:22:00

Mis felicitaciones. Me sirvi bastante para comenzar en esta area de la gestion de proyectos.
Consulta: Que software recomiendas como apoyo?

Reply

marc ambit says:

Sunday 30 May 2010 at 9:53:27

Magnfico compendio, Sergio. Has conseguido ese difcil equilibrio entre resumen y
exhaustividad. Te he enlazado el post en este post de mi blog de proyectos:
http://gestiodeprojectes.blogspot.com/2010/05/fantastic-resum-de-la-gestio-de.html

Un saludo!

Marc Ambit

Reply
 williams rodriguez constantino says:

Tuesday 8 June 2010 at 17:59:33

Excelente post. Gracias.

Reply

batiste says:

Thursday 24 June 2010 at 11:25:22

Gracias, me has desbloqueado para entender algo. Es un tema que sale a las opos del Cos
Superior de la Generalitat y estaba totalmente perdido.

Reply

Arianna says:

Thursday 22 July 2010 at 13:05:17

Me gust mucho esta pgina! Es prctica y encapsula informacion clave para la gestion de
proyectos!

Si me gustaria tener su opinion en cuanto a las diferentes metodologias de gestion de

proyectos o un cuadro comparativo, aplicabilidad y usos en la practica.. Seria EXCELENTE!!!!

Gracias!!

Reply

Santos Jaimes says:

Thursday 31 March 2011 at 18:11:19

Gracias por la excelente presentacin.

Te agradesco por adelantado, por que lo voy a poner como Lectura Obligatoria de mis almnos
en un curso Gratuito de Induccin al PMBoK. En la Universidad Agraria la Molina (Vistual)
http://www.lamolinavirtual.org/mod/course/view.php?id=14
Te comunicar nuestros avances.

Reply

Carmen says:

Sunday 24 April 2011 at 4:10:17

Gracias por compartir informacion, nos ayudar ampliar conocimientos del curso.

Reply

Carlos Pereira says:

Wednesday 27 April 2011 at 2:09:15

Es un excelente material de consulta, lo voy a leer y aplicar las buenas practicas que
recomienda. Estoy muy agradecido por compartir tan importante informacion. Espero
contrinuar recibiendo este tipo de ayuda.

Reply

Juan Carlos Cardoza says:

Wednesday 27 April 2011 at 3:07:15

Quisiera felicitarlo agradecerle por compartir este buen trabajo realizado, con ejemplos que
nos permiten una mejor comprensin del tema.
gracias
Juan Carlos

Reply
 Hugo says:

Wednesday 27 April 2011 at 4:06:02

Felicitadiones por el curso que se esta realizando ,estare constante en las clases que dictan es
interesante y muy valioso .

Reply

Mara Julia says:

Wednesday 27 April 2011 at 19:59:27

Felicitaciones! y gracias por compartir esta excelente informacin.

Reply

Diana says:

Saturday 18 June 2011 at 23:15:25

Estimado Sergioes valiosisimo tu aporte. He comenzado un curso y con sinceridad, he

entendido su objetivo LEYENDO TU BLOG. Gracias por tanto trabajo despensado!

Reply

Antonio says:

Friday 5 August 2011 at 13:26:53

Hola estimados,
Alguno de l@s forer@s tendr algo a cerca de la elaboracin de documentacin
(procedimiento, manuales, etc) bajo metodologa PMI? ya sea por plantillas o formatologa
propia de la metodologa, es muy importante ya que el resto de fases est bastante clara pero
cmo trabajar en la gestin documental no me ha quedado muy clara.
Gracias.

Reply

Luis Zevallos says:

Thursday 25 August 2011 at 19:17:27

Buenos das Sergio

Excelente resumen, debera ser una lectura obligatoria, para todas aquellos que estamos
inmersos en el mundo de la gestin de proyectos.

Gracias por compartirlo.

Luis

Reply

Drezne says:

Tuesday 25 October 2011 at 17:55:54

Apenas leere esta Informacin,pero a grandes Rasgos se ve muy interesante, ya dare mis
comentarios al terminar.

saludos

Reply

Linder says:

Saturday 12 January 2013 at 4:20:51

excelente trabajo amigo gracias por tu colaboracin, sigue adelante, maana expongo en mi
curso de itil

Reply
 Grace says:

Thursday 14 March 2013 at 17:39:04

Excelente trabajo

Reply

Aldo says:

Wednesday 12 June 2013 at 6:32:11

Excelente trabajo, claro y preciso

Gracias

Reply

Fernando Daza says:

Saturday 14 December 2013 at 8:26:51

Sergio, gracias por publicar tan valiosa informacin, es sencillamente excelente, me ha

ayudado muchsimo. va un abrazo grande y que Dios te bendiga.

Reply

Marco Hernandez says:

Sunday 11 October 2015 at 19:04:34

Muy Bien el documental. Tengo una pequea duda. soy estudiante de gestion de proyectos y
me toca hablar de la planificacion de la direccion de proyectos en general, si bien es cierto
todas las disciplinas que nos aporta el PMBOK poseen un plan de proyecto, pero en general
plan de planificacion de direccion de proyectos el PMBOK no me habla claramente. cual serian
los puntos a tratar cuando se refieren a plan de la planificacin direccin de proyectos ?
Reply

Leave a Reply Cancel reply

Principio del formulario

Your email address will not be published. Required fields are marked *

Name *

Email *

Website

Comment

660 0

ff4608876c

Post Comment

<style type='text/css'>#submit {display:none;}</style> <input name="submit" type="submit"

id="submit-alt" tabindex="6" value="Submit Comment"/>

1448842842178

Final del formulario

Links

Google+

Twitter
Facebook

LinkedIn

Blog categories

Language

Catal

English

Espaol

Topic

Ciencia

Negocios

Otros

Tecnologa

Proudly powered by WordPress