Ejercicio sobre Frontera Eficiente

 
Ejercicio: Su portafolio tiene 5 componentes, con los siguientes datos de presupuesto y valor relativo:

• Proyecto Nº1: presupuesto 25.000 €; valor 30%
• Proyecto Nº2: presupuesto 50.000 €; valor 14%
• Proyecto Nº3: presupuesto 13.500 €; valor 23%
• Proyecto Nº4: presupuesto 32.500 €; valor 22%
• Proyecto Nº5: presupuesto 40.000 €; valor 11%

El proyecto 5 ya se está ejecutando, pero sobre el resto se puede tomar la decisión sobre si aprobarlos, rechazarlos o aplazarlos. Debido a la política actual de recortes en su empresa, le reducen a la mitad el presupuesto necesario para ejecutar toda la cartera. ¿Cuál sería escenario de selección óptimo?

Ejercicio sobre terminología de Gestión del Alcance

Ejercicio: Haga corresponder los términos de la izquierda con las definiciones a la derecha:

1	Sistema de Control de Cambios	A	Documento que provee, para uso común y repetitivo, las reglas, pautas o características que deberían cumplir las actividades (o sus resultados), a fin de obtener un óptimo grado de orden en un contexto dado.
2	Sistema de Gestión de la Configuración	B	Acción tomada para hacer que un componente defectuoso o no conforme cumpla con las disposiciones de los requisitos o especificaciones.
3	Entregable	C	Un subsistema del sistema de dirección de proyectos general. Es un conjunto de procedimientos formalmente documentados que se utilizan para implementar la dirección y supervisión técnica y administrativa para: identificar y documentar las características funcionales y físicas de un producto, resultado, servicio o componente; controlar cualquier cambio a dichas características; registrar e informar cada cambio y su estado de implementación; y brindar apoyo a la auditoría de productos, resultados o componentes para verificar su conformidad con los requisitos. Incluye la documentación, los sistemas de rastreo y la definición de los niveles de aprobación necesarios para autorizar y controlar los cambios.
4	Producto	D	Una condición o capacidad que debe estar presente en un producto, servicio o resultado para satisfacer un contrato u otra especificación formalmente impuesta.
5	Alcance del Producto	E	Un artículo producido, que es cuantificable y que puede ser un elemento terminado o un componente.
6	Alcance del Proyecto	F	Una salida de la ejecución de procesos y actividades de dirección de proyectos. Los resultados incluyen consecuencias (p.ej., sistemas integrados, procesos revisados, organización reestructurada, pruebas, personal capacitado, etc.) y documentos (p.ej., políticas, planes, estudios, procedimientos, especificaciones, informes, etc.).
7	Requisito	G	El trabajo realizado para entregar un producto, servicio o resultado con las funciones y características especificadas.
8	Resultado	H	El proceso realizado para asegurar que un producto, servicio o sistema cumple con las necesidades del cliente y de otros interesados identificados. A menudo implica corroborar la aceptación y conveniencia con clientes externos.
9	Retrabajo	I	Los rasgos y funciones que caracterizan a un producto, servicio o resultado.
10	Alcance	J	La versión aprobada de un enunciado del alcance, estructura de desglose del trabajo (EDT), y su diccionario de la EDT asociado, que sólo puede cambiarse a través de procedimientos formales de control de cambios y que se utiliza como base de comparación.
11	Línea Base del Alcance	K	Cualquier producto, resultado o capacidad de prestar un servicio único y verificable que debe producirse para terminar un proceso, una fase o un proyecto.
12	Especificaciones	L	Un documento que expresa de manera completa, precisa y verificable, los requisitos, el diseño, el comportamiento y otras características de un sistema, componente, producto, resultado o servicio así como los procedimientos para determinar si se ha cumplido con estas disposiciones.
13	Estándar	M	La suma de productos, servicios y resultados a ser proporcionados como un proyecto.
14	Validación	N	Un conjunto de procedimientos que describe la forma en que se gestionan y controlan las modificaciones de los entregables y la documentación del proyecto.
15	Verificación	O	Proceso que consiste en evaluar si un producto, servicio o sistema cumple o no con determinada regulación, requisito, especificación o condición impuesta. A menudo se trata de un proceso interno.

Review of the book “Alpha Project Managers”

In 2005, author Andy Crowe lead The Alpha Study, in order to determine which were the habits of those project managers continuously graded “excellent” by direct reports, managers and customers. This book publishes those study results, interleaving much wise advice by Andy Crowe and by some of the “alphas” (there are opinions by “non alphas” as well). It is an easy to read book, thanks to the summary sections closing each chapter and the final chapter with the conclusions.

The study's sample was chosen from the client base of Velociteach (mostly in North America). Interviews were conducted for more than 860 project managers and more than 4,400 stakeholders (customers, senior managers and team members). Surveys weighted 40% the opinion of customers, 30% for senior managers and 30% for team members.

Out of the 860 project managers, alphas were in the 98th percentile, that is, the 2% of them ranked globally higher than the other 98%. The 18 alpha project managers (6 women and 12 men) were based in the USA (except one Canadian). 

Alpha Project Managers are those who consistently deliver on time, on cost, on scope, meeting quality standards, and properly managing expectations of stakeholders (customer, team, organization).

Comentario del libro “Alpha Project Managers”

El autor Andy Crowe dirigió un estudio en el año 2005, que denominó “The Alpha Study”, para determinar qué hábitos tenían aquellos Directores de Proyectos que eran evaluados como “excelentes”, de forma continuada, por sus subordinados, jefes y clientes. Este libro publica los resultados de aquel estudio, intercalando mucha opinión sabia de Andy Crowe y de algunos “Alfas” (también hay opiniones de los No Alfas). Son unas 200 páginas en inglés (a doble espacio), de fácil lectura gracias a los resúmenes que cierran cada capítulo y el último capítulo de conclusiones.

La muestra del estudio se escogió a partir de la base de clientes de la empresa Velociteach (la mayoría con base en Noteamérica). Se entrevistó a 860 Directores de Proyectos y más de 4400 interesados (entre clientes, directivos de las empresas de los Directores de Proyectos, y miembros de equipo que habían sido dirigidos por dichos Directores de Proyectos). Las encuestas ponderan un 40% la opinión de los clientes, un 30% la opinión de los directivos y un 30% la de los miembros del equipo. 

De los 860 Directores de Proyectos, los Alfa son aquellos que caen en el percentil 98, es decir, aquel 2% que obtuvo una puntuación global superior al 98% restante. En total se seleccionaron 18 Directores de Proyectos Alfa: 6 mujeres y 12 hombres, todos residentes en EE.UU. salvo un canadiense.

Un Director de Proyectos Alfa es aquel que regularmente termina sus proyectos alcanzando los objetivos de plazo, coste, alcance y calidad, gestionando correctamente las expectativas de los interesados (cliente, equipo, organización).

Performance Appraisal for Project Managers

In 2002, PMI® published the first version of the standard “Project Manager Competency Development (PMCD) Framework”. In 2007 PMI® released the second edition. The main goal was to provide a guide to evaluate and manage the professional development of Project Managers.

Evaluando a Directores de Proyecto

En el año 2002, el PMI publicó la primera versión del estándar denominado Project Manager Competency Development (PMCD) Framework, que puede traducirse como “Marco para el Desarrollo de las Competencias del Director de Proyectos”. En 2007 se publicó la segunda edición. El objetivo del PMI es proporcionar una guía para evaluar, planificar y gestionar el desarrollo profesional de los Directores de Proyecto.
 

Calculating the Project Buffer

The Critical Chain Project Management method recommends to make uncertainty explicit using buffers to protect critical and nearly critical paths in the project network schedule diagram. Expliciting buffers is a quite interesting practice for project governance, since KPIs like percent completed buffer can be easily monitored graphically, like this chart shows:

In this post we will see how to calculate the project buffer, following an example proposed by Mike Cohn: Agile Estimating and Planning, Prentice Hall, 2012.

Cómo manejar buffers en Microsoft Project

 

Una aproximación simple al método de cadena crítica con Microsoft Project consiste en añadir buffers de proyecto y buffers de alimentación para proteger el camino crítico y los caminos casi-críticos, respectivamente.

A continuación se describen los pasos para modelar el funcionamiento de un buffer en Microsoft Project:

1) Modelar un buffer como una tarea manual, con precedencia final a inicio después de la última tarea del camino que se desea proteger.

2) Cuando se consume algún día de buffer, esto se verá como una notificación en buffer (borde discontinuo).

3) Para hacer que Microsoft Project recalcule fácilmente el buffer: 1) Copiar fecha fin de buffer (CTRL+C); 2) Pulsar botón respetar enlaces; 3) Sobrescribir fecha de fin (CTRL+V).

Cálculo del Buffer de Proyecto

Como se vio en el post anterior, el método de cadena critica proponía explicitar la incertidumbre a través de colchones (buffers) para proteger los caminos críticos y casi críticos. El concepto de buffer de proyecto es muy interesante para la alta dirección, ya que indicadores clave de desempeño como el porcentaje de buffer consumido pueden monitorizarse de forma gráfica como se muestra en la figura:

En este post veremos a través de un ejemplo cómo calcular el buffer de un proyecto. El ejemplo se ha extraído del libro de Mike Cohn: Agile Estimating and Planning, Prentice Hall, 2012.

Cadena Crítica

La gestión de proyectos por cadena crítica (Critical Chain Project Management –CCPM-) fue introducida por el Dr. Eliyahu M. Goldratt en 1977, en su famosa novela “Cadena Crítica”, en la que se aplicaba la teoría de las restricciones (Theory Of Constrains –TOC-), también ideada por el mismo autor, a la gestión de proyectos.

La tesis principal del libro es que “no se debe estimar con margen de seguridad”. Esto conduce a la “dinámica de la sobre-estimación”. Las estimaciones pesimistas se dan con una confianza del 95%, lo que puede provocar un margen de seguridad del 150% (es decir, si la estimación más probable –la que suele darse con una confianza del 50%- para un proyecto es 4 meses, se acaban proponiendo 6 meses).

Sin embargo, a pesar de que los proyectos se estiman con márgenes de seguridad del 150%, se acaban retrasando, ¿por qué?