Buscar este blog

Cargando...

14 de diciembre de 2014

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).

7 de diciembre de 2014

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).


30 de noviembre de 2014

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.


23 de noviembre de 2014

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.
 

16 de noviembre de 2014

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 CohnAgile Estimating and Planning, Prentice Hall, 2012.

9 de noviembre de 2014

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).

2 de noviembre de 2014

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.

26 de octubre de 2014

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é?

19 de octubre de 2014

Ejercicio sobre Terminología de Gestión de Proyectos


EjercicioHaga corresponder los términos de la izquierda con las definiciones a la derecha:
1 Ciclo de Vida Adaptativo A Una empresa cuyo personal está directamente involucrado en realizar el trabajo del proyecto o del programa.
2 Supuesto B Un ciclo de vida de proyecto, también conocido como método orientado al cambio o método ágil, que busca facilitar el cambio y requiere un alto grado de participación continua de los interesados. Estos ciclos de vida de proyecto son iterativos e incrementales, pero siendo las iteraciones muy rápidas (normalmente 2–4 semanas de duración) y fijas en tiempo y recursos.
3 Restricción C Proyectos, programas, subportafolios y operaciones gestionados como un grupo para alcanzar los objetivos estratégicos.
4 Factores Ambientales de la Empresa D Una estructura de organización en la cual el director del proyecto comparte con los gerentes funcionales la responsabilidad de asignar prioridades y de dirigir el trabajo de las personas asignadas al proyecto.
5 Organización Funcional E La serie de fases que atraviesa un proyecto desde su inicio hasta su cierre.
6 Elaboración Gradual F Un artículo producido que es cuantificable y que puede ser un elemento terminado o un componente.
7 Ciclo de Vida Iterativo G Un factor limitante que afecta la ejecución de un proyecto, programa, portafolio o proceso.
8 Ciclo de Vida H Un grupo de proyectos, subprogramas y actividades de programas relacionados cuya gestión se realiza de manera coordinada para obtener beneficios que no se obtendrían si se gestionaran en forma individual.
9 Organización Matricial I Planes, procesos, políticas, procedimientos y bases de conocimiento que son específicos de la organización ejecutora y que son utilizados por la misma.
10 Activos de los Procesos de la Organización J Una organización jerárquica en la cual cada empleado tiene definido claramente un superior y el personal está agrupado por áreas de especialización dirigidas por una persona con experiencia en esa área.
11 Madurez de la Dirección de Proyectos de una Organización K Condiciones que no están bajo el control directo del equipo y que influyen, restringen o dirigen el proyecto, programa o portafolio.
12 Organización Ejecutora L El nivel de capacidad de una organización para producir los resultados estratégicos deseados de un modo predecible, controlable y confiable.
13 Portafolio M El proceso iterativo de incrementar el nivel de detalle de un plan para la dirección del proyecto a medida que se cuenta con mayor cantidad de información y con estimaciones más precisas.
14 Producto N Un factor que a efectos de planificación se considera verdadero, real o cierto, sin prueba ni demostración.
15 Programa O Un ciclo de vida del proyecto donde habitualmente el alcance se determina, tempranamente en el ciclo de vida del proyecto, pero cuyas estimaciones de tiempo y coste se modifican periódicamente conforme aumenta el entendimiento del equipo del proyecto sobre el producto. Las iteraciones desarrollan el producto a través de una serie de ciclos repetidos, mientras que los incrementos se añaden sucesivamente a la funcionalidad del producto.
 

12 de octubre de 2014

Agile Principles to Project Management

30

According to the Project Management Institute, an Agile Project Manager, on a regular basis, should explore, embrace, and apply agile principles and mindset within the context of the project team and organization. This implies some typical tasks included below:
  1. Advocate for agile principles by modeling those principles and discussing agile values in order to develop a shared mindset across the team as well as between the customer and the team.
  2. Help ensure that everyone has a common understanding of the values and principles of agile and a common knowledge around the agile practices and terminology being used in order to work effectively.
  3. Support change at the system or organization level by educating the organization and influencing processes, behaviors, and people in order to make the organization more effective and efficient.
  4. Practice visualization by maintaining highly visible information radiators showing real progress and real team performance in order to enhance transparency and trust.
  5. Contribute to a safe and trustful team environment by allowing everyone to experiment and make mistakes so that each can learn and continuously improve the way they work.
  6. Enhance creativity by experimenting with new techniques and process ideas in order to discover more efficient and effective ways of working.
  7. Encourage team members to share knowledge by collaborating and working together in order to lower risks around knowledge silos and reduce bottlenecks.
  8. Encourage emergent leadership within the team by establishing a safe and respectful environment in which new approaches can be tried in order to make improvements and foster self-organization and empowerment.
  9. Practice servant leadership by supporting and encouraging others in their endeavors so that they can perform at their highest level and continue to improve.

In the center of these common tasks is the real understanding of the values and principles expressed on the Agile Manifesto published in 2001. The 4 values of the Agile Manifesto are stated as:


Behind these 4 values, there are 12 principles, which are transcribed below: