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

Ejercicio sobre Terminología de Gestión de Proyectos

Ejercicio: Haga 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.

 

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:

Principios Ágiles en Dirección de Proyectos

Según el Project Management Institute, un Director de Proyectos Ágil, en su día a día, debería explorar, fomentar y aplicar principios ágiles en el contexto del equipo del proyecto y la organización. Esto implica, entre otras, estas 9 tareas:

1. Fomentar los principios ágiles modelándolos y discutiendo los valores ágiles para desarrollar un entendimiento común dentro del equipo y entre el equipo y los interesados.
2. Ayudar a asegurar que todos tengan un entendimiento común de los valores y principios ágiles, de las prácticas ágiles y la terminología empleada para trabajar de manera efectiva.
3. Apoyar el cambio en la organización educando e influenciando sobre los procesos, comportamientos y personas para hacer la organización más eficaz y eficiente.
4. Practicar la visualización por medio de radiadores de información muy visibles que muestren el progreso y desempeño real del equipo para fomentar la transparencia y la confianza.
5. Fomentar un entorno de seguridad y confianza, permitiendo que todos experimenten y cometan errores para que puedan aprender y mejorar continuamente la forma de trabajar.
6. Mejorar la creatividad experimentando con nuevas técnicas e ideas sobre los procesos, para descubrir formas de trabajar más eficientes y eficaces.
7. Fomentar que los miembros del equipo compartan el conocimiento colaborando y trabajando juntos para reducir los riesgos de islas de conocimiento y cuellos de botella.
8. Estimular el liderazgo emergente dentro del equipo estableciendo un entorno respetuoso y seguro en el que puedan probarse nuevos enfoques para producir mejoras y fomentar la auto-organización y el facultamiento.
9. Practicar el liderazgo servicial soportando y estimulando a otros en sus esfuerzos, de manera que puedan trabajar a su máximo nivel y continuar mejorando.

En el centro de estas tareas se encuentra el verdadero entendimiento de los valores y principios ágiles expresados en el Manifiesto Ágil publicado en 2001. Los 4 valores del Manifiesto Ágil se enuncian así:

Detrás de estos 4 valores se detallan 12 principios, que se transcriben a continuación:

Unidad de esfuerzo FTE

En este post, a través de un sencillo ejercicio, veremos cómo calcular los FTE (Full Time Equivalents –FTE-) o equivalentes en personas a tiempo completo durante un plazo determinado. FTE es una unidad de esfuerzo tan válida como personas-mes.

Imaginemos una actividad que dura dos años, se empleará un programador sénior, dos programadores junior a dedicación completa y un analista al 30%. ¿Cuál debe ser la dedicación del programador sénior si el coste total es de 300.960 € y la tarifa media es de 30 €/h?

En la tabla de abajo se puede comprobar que multiplicando las horas de trabajo en 2 años por la carga de cada recurso en porcentaje (FTEs), se obtiene el esfuerzo por perfil, en horas-persona. Nótese que los FTE, como cualquier otra unidad de esfuerzo, se pueden sumar (de ahí que pueda usarse la estimación ascendente): esta actividad emplea 2,85 FTEs, o 10.032 horas-persona.

La dedicación del programador sénior debe ser de un 55%, o bien 0,55 FTEs, lo que puede calcularse iterando en la hoja de cálculo, o también directamente, como se describe a continuación.

• La carga total de recursos para esta actividad es: 300960€ / 1760 h/año / 2 años / 30 €/h = 2,85 FTEs. Podemos restar la carga conocida del analista y los programadores junior para obtener la carga del programador sénior: 2,85-0,3-2 = 0,55 FTEs, o lo que es lo mismo, el programador senior trabajará a un 55% de su capacidad.

Gestión Eficaz de las Adquisiciones

Imaginemos un equipo de gestión del proyecto que gestiona eficazmente las adquisiciones. ¿Qué actividades realizaría?

Ejercicio: Describa cómo gestionó las adquisiciones el equipo de dirección del proyecto, en cinco párrafos, usando las siguientes palabras clave:

1. Interesados, alcance, cronograma, presupuesto, riesgos.
2. Expertos, análisis hacer o comprar, plan de gestión de las adquisiciones, enunciado del trabajo relativo a las adquisiciones, RFP.
3. Proveedores cualificados, propuestas, criterios de valoración, adjudicación, contrato.
4. Administrar el contrato, evaluación del desempeño, registro, pago, cambios, reclamaciones.
5. Aceptación, documentación de la adquisición, cierre de la adquisición.

One strategy to face the PMP Exam

Do you want to take the PMP® exam easily and confident? Then you have to practice a lot of tests. Practicing tests is good to keep on learning (you learn much by knowing why the good answer is the good one and the others are wrong) but also to get the mark of one minute per question (in the PMP® exam you have to answer 200 questions in 4 hours). There are no shortcuts here: to pass the PMP® exam, once you have the fundamentals and every concept is clear, then you have to get into the habit of practicing a lot of tests, the more the better. This is a matter of practice. You have to practice, practice and practice again. Practice until you get exhausted! There are lots of tests available: complete exams or part of them, free and for payment, interactive or in books, etc. Before the day of the exam, you have to plan a constant effort to do tests, more intense as the exam is coming closer. Common advice is more than 2 hours a day practicing tests during the 2 weeks before the exam.

Only after felling confident by practicing tests, this is the moment to schedule the date of the exam. If you are not a native English speaker, you can request the translation aid to read quickly the long text introducing the question, in order to separate the relevant information and recognize which of the 47 processes is the one you need to focus on.

The biggest challenge for the PMP® candidate is the limited time. You have 4 hours to answer 200 questions and you always need more time. People failing the exam always complain about the insufficient time. When they have only one our left, they realize they have more than 60 questions to answer, for instance, and they get into panic. To get the average pace of one minute per question you have to do the homework: learn the fundamentals, practice many tests, sleep well the previous day, etc. All this done, however, does not guarantee passing the exam.

In order to have a good performance during the computer based testing, my advice is to follow a certain strategy. I will appreciate any of your comments with your thoughts on this. Thank you very much for continue reading.

El Ciclo de Vida de la Venta de Proyectos

Profundizando aún más en la terminología de ventas que suele seguirse en las empresas que se dedican a vender proyectos, la actividad comercial suele estructurarse según el siguiente ciclo de vida de cinco fases:

• Prospectos: es la fase en la que se realiza la búsqueda de nuevos clientes, se cualifica a los potenciales clientes, o prospectos y se determinan las necesidades del mercado. En esta fase se realiza visitas a eventos comerciales, a ferias, a empresas, entre otros. Además, en esta fase se realiza alianzas comerciales.
• Ofertas: en esta fase se toma la decisión de ofertar y se entrega las propuestas a los clientes. Se participa en las licitaciones. Se entrega la planificación del proyecto en su versión inicial. Se realizan las aclaraciones sobre toda consulta que pueda surgir, se hace una revisión de las lecciones aprendidas para tener una base para ofertar a los nuevos proyectos.
• Contratos: Una vez que el cliente se decide por el mejor candidato, se lleva a cabo el proceso de negociación, se establece el tipo de contrato a utilizar, se definen las cláusulas, se plantean los requisitos iniciales y se firma el contrato.
• Ejecución: Se crea la línea base de requisitos y se lleva a cabo el proyecto. En esta fase es importante la comunicación con los interesados, el registro de todos los hechos significativos, el proceso de reclamaciones y auditorías para asegurar el cumplimiento del proyecto, y la gestión de los cambios.
• Cierre: Una vez que el proyecto se ha realizado, se lleva a cabo la fase de cierre en la cual se registra el contrato, se hace auditorías de cumplimiento del contrato y se hace una encuesta de satisfacción al cliente.

Gestión de las Adquisiciones desde el punto de vista del Proveedor

El término adquisición (procurement, en inglés) se utiliza para referirse al contrato desde el punto de vista del comprador. Sin embargo, en todo acuerdo hay dos partes: una de ellas actúa como cliente y la otra como proveedor. Si el objeto del acuerdo es un proyecto para externalizar ciertas actividades dentro del proyecto del cliente, siempre es conveniente distinguir los procesos de gestión del proyecto del cliente y del proyecto del proveedor, proyectos que estarán ligados mientras esté en vigor el acuerdo. En el caso del proveedor, suele emplearse una doble terminología: por un lado, la Guía del PMBOK® puede emplearse porque se trata de un proyecto que hay que gestionar; por otro lado, en cuanto que se trata del objeto de una venta regulada por un contrato, suele distinguirse la fase de pre-contratación, contratación y post-contratación.

Veamos cómo estas fases se relacionan con la terminología de la Guía del PMBOK^® y con la gestión del proyecto por parte del cliente:

Terminología de Adquisiciones

Ejercicio: Haga corresponder los términos de la izquierda con las definiciones a la derecha (si prefiere realizar este ejercicio de forma online, en español o en inglés, puede hacerlo en el siguiente enlace):

1	Conferencia de Oferentes	A	Proceso para observar el desempeño del trabajo contratado o de un producto prometido frente a los requisitos acordados.
2	Reclamación	B	Una revisión estructurada del avance del proveedor para cumplir con el alcance y la calidad del proyecto, dentro del coste y en el plazo acordado, tomando el contrato como referencia.
3	Honorarios	C	El proceso de recopilar y organizar datos acerca de los requisitos del producto y analizarlos frente a las alternativas disponibles, incluida la compra o fabricación interna del producto.
4	Honorarios con Incentivos	D	Describe el artículo que se planea adquirir con suficiente detalle como para permitir que los posibles proveedores determinen si están en condiciones de proporcionar los productos, servicios o resultados requeridos.
5	Inspecciones y Auditorías	E	Un conjunto de incentivos financieros asociados a los costes, cronograma o desempeño técnico del proveedor.
6	Análisis de Hacer o Comprar	F	Un subsistema del sistema de dirección de proyectos general. Es un conjunto de procedimientos formalmente documentados que define cómo se autorizará el trabajo del proyecto (comprometido) para garantizar que la organización identificada realice el trabajo en el tiempo asignado y con la secuencia correcta. Incluye los pasos, documentos, sistema de seguimiento, y niveles de aprobación definidos necesarios para emitir las autorizaciones de trabajo.
7	Investigación de Mercado	G	El proceso de alcanzar un acuerdo definitivo y equitativo de todos los incidentes, reclamaciones y controversias pendientes a través de la negociación.
8	Acuerdos Negociados	H	El proceso de recopilar información en conferencias, reseñas en línea y una diversidad de fuentes para identificar las capacidades del mercado.
9	Sistemas de Pago	I	Las reuniones con posibles proveedores previas a la preparación de una licitación o propuesta para asegurar que todos los posibles proveedores comprendan de manera clara y uniforme la necesidad de adquisición. También conocidas como conferencias de contratistas, conferencias de proveedores o conferencias previas a la licitación.
10	Auditorías de la Adquisición	J	Una solicitud, demanda o declaración de derechos realizada por un proveedor con respecto a un comprador, o viceversa, para su consideración, compensación o pago en virtud de los términos de un contrato legalmente vinculante, como puede ser el caso de un cambio que es objeto de disputa.
11	Documentos de las Adquisiciónes	K	El sistema utilizado para proporcionar y dar seguimiento a las facturas y pagos de proveedores por servicios y productos.
12	Revisiones del Desempeño de las Adquisiciones	L	Representa el beneficio como un componente de la compensación a un proveedor.
13	Enunciados del Trabajo Relativo a Adquisiciones	M	El proceso de revisar las propuestas presentadas por los proveedores para fundamentar las decisiones de adjudicación de contratos.
14	Técnicas de Evaluación de Propuestas	N	Los documentos que se usan en actividades de oferta y propuesta, que incluyen la Invitación a Licitación del comprador, Invitación a Negociar, Solicitud de Información, Solicitud de Cotización, Solicitud de Propuesta y Respuestas de los Participantes.
15	Sistema de Autorización de Trabajo	O	La revisión de contratos y procesos contractuales en cuanto a su completitud, exactitud y efectividad.

Los tipos de Contratos y sus Definiciones

Ejercicio: Haga corresponder los términos de la izquierda con las definiciones a la derecha (si prefiere realizar este ejercicio de forma online, en español o en inglés, puede hacerlo en el siguiente enlace):

1	Acuerdos	A	Un tipo de contrato de precio fijo en el cual el comprador paga al proveedor un monto establecido (conforme lo defina el contrato), independientemente de los costes del proveedor.
2	Contrato	B	Un contrato de precio fijo con una disposición especial que permite ajustes finales predefinidos al precio del contrato debido a cambios en las condiciones, tales como cambios inflacionarios o aumentos (o disminuciones) del coste de productos específicos.
3	Contrato de Coste más Gratificación por Cumplimiento de Objetivos (CPAF)	C	Un tipo de contrato que implica el pago al proveedor por los costes reales del mismo, más un incentivo que, por lo general, representa la ganancia del proveedor. Suelen incluir cláusulas de incentivos en virtud de las cuales, si el proveedor cumple o supera los objetivos seleccionados del proyecto, como metas del cronograma o coste total, entonces el proveedor recibe del comprador un pago de incentivo o bonificación.
4	Contrato de Coste más Incentivos Fijos (CPFF)	D	Un acuerdo vinculante para las partes en virtud del cual el proveedor se obliga a proveer el producto, servicio o resultado especificado y el comprador a pagar por él.
5	Contrato de Coste más Incentivos (CPIF)	E	Un acuerdo que fija los honorarios que se pagarán por un alcance definido del trabajo independientemente del coste o esfuerzo para entregarlo.
6	Contrato de Coste Reembolsable	F	Cualquier documento o comunicación que defina las intenciones iniciales de un proyecto. Puede adoptar la forma de un contrato, memorándum de entendimiento (MOU), cartas de acuerdo, acuerdos verbales, correo electrónico, etc.
7	Contrato de Precio Fijo Cerrado (FFP)	G	Un tipo de contrato de costes reembolsables en el que el comprador reembolsa al proveedor su coste permitido correspondiente (según se defina coste permitido en el contrato) y el proveedor obtiene sus ganancias si cumple los criterios de desempeño definidos.
8	Contrato de Precio Fijo más Incentivos (FPIF)	H	Una categoría de contrato que implica efectuar pagos al proveedor por todos los costes legítimos y reales en que incurriera para completar el trabajo, más una bonificación que representa la ganancia del proveedor.
9	Contrato de Precio Fijo con Ajuste Económico de Precio (FP-EPA)	I	Un tipo de contrato en el cual el comprador paga al proveedor un monto establecido (conforme lo defina el contrato) y el proveedor puede ganar un monto adicional si cumple con los criterios de desempeño establecidos.
10	Contratos de Precio Fijo	J	Un tipo de documento de adquisición por el cual el comprador solicita al posible proveedor que proporcione una determinada información relacionada con un producto, servicio o capacidad del proveedor.
11	Invitación a Licitación (IFB)	K	En general, este término es equivalente a solicitud de propuesta. No obstante, en algunas áreas de aplicación, es posible que tenga una acepción más concreta o más específica.
12	Solicitud de Información (RFI)	L	Un tipo de contrato de costes reembolsables en el que el comprador reembolsa al proveedor por su coste permitido correspondiente (según se defina coste permitido en el contrato) más una cantidad fija de ganancia (incentivo).
13	Contrato por Tiempo y Materiales (T&M)	M	Un tipo de contrato que es un acuerdo contractual híbrido, el cual contiene aspectos tanto de contratos de costes reembolsables como de contratos de precio fijo.

Tipos de contratos según el PMI

 
PMI distingue tres tipos de contratos principales:

• Contrato de precio fijo: El proveedor recibe una cantidad fija por sus servicios.
• Contrato de coste reemborsable: El proveedor cobra sus costes incurridos más un beneficio.
• Contrato por tiempo y materiales: Se acuerdan unas tarifas fijas para los recursos humanos y materiales. El proveedor cobra en función de las unidades incurridas.

Como puede apreciarse en la figura, estos tres tipos básicos dan lugar a siete tipos de contratos específicos, según se combinen con estos cuatro calificadores:

• con beneficio fijo (fixed fee): El beneficio del vendedor se acuerda al inicio y no varía.
• con incentivos (incentive fee): El vendedor cobra una bonificación según su coste o desempeño.
• con gratificación por cumplimiento de objetivos (award fee): El vendedor cobra una bonificación según la satisfacción subjetiva del cliente.
• con ajuste económico del precio: Se pactan modificaciones del precio en contratos plurianuales.

Punto de Asunción Total

Como se ha visto en el post anterior, los elementos a determinar desde un principio en un contrato FPIF son cinco: 1) el coste objetivo (target cost); 2) el margen objetivo (target fee); 3) el precio objetivo (target price); 4) el precio techo (ceiling price) y 5) el Punto de Asunción Total (Point of Total Assumption –PTA-).

En el caso del ejemplo, saber que el PTA es de 121.400€ permite elaborar fácilmente el rango de resultados posibles, sabiendo que cuando el coste final es superior al PTA, entonces el precio final va a ser el precio techo:

La fórmula para calcular el precio final en un contrato FPIF es la siguiente:

• Final Price = Min (Ceiling Price; Actual Cost + Target Fee + (Target Cost – Actual Cost) * Seller Share)

La fórmula para calcular el PTA puede deducirse de esta ecuación:

• Ceiling Price = PTA + Target Fee + (Target Cost – PTA) * Seller Share

Despejando queda:

• PTA = (Ceiling Price – Target Fee – Target Cost*Seller Share) / (1-Seller Share)

En el ejemplo, el valor de PTA se obtiene: PTA = (125-10-100*30%)/70% = 121,4

Analizando un Contrato de Precio Fijo con Incentivos

En este post vamos a imaginar un equipo de gestión del proyecto que gestiona un Contrato de Precio Fijo con Incentivos (Fixed Price Plus Incentive Fee -FPIF-). Supongamos que el equipo está analizando si hacer o comprar una parte del proyecto. Si estas actividades se realizasen dentro de la organización, se estima un coste objetivo de 100.000€. Si el proyecto se externaliza, el mercado responderá con un margen objetivo del 10%, con lo que el precio objetivo para un contrato a precio cerrado sería de 110.000€.

Para estimular el buen desempeño, un experto propone utilizar un contrato de precio fijo con incentivos, con un precio techo de 125.000€ y un reparto de incentivos del 70/30. El equipo quiere calcular el precio final que habría que pagar al proveedor en los siguientes casos:

1. el coste final del proveedor asciende a 70.000€.
2. el coste final del proveedor asciende a 115.000€.
3. el coste final del proveedor asciende a 130.000€.

Los datos de este contrato FPIF se representan en la figura: El coste objetivo es de 100.000€, el margen objetivo es de 10.000€ y el precio objetivo es de 110.000€.

Veamos cómo se calcula el precio final en los tres casos.

¿Hacer o Comprar?

Una de las primeras decisiones que debe tomar el equipo de gestión del proyecto es si es necesario que el equipo del proyecto realice todas las tareas del alcance o es conveniente externalizar ciertos esfuerzos, ya sea porque resultaría más barato, más rápido, de mejor calidad, de menor riesgo, con recursos más capacitados, etc., adquirir a un tercero cierta parte del producto, servicio, o resultado final de nuestro proyecto.

Cuando una parte del trabajo del proyecto se subcontrata, esto ya no se gestiona igual. Lo primero que hay que tener en cuenta es que el fracaso se puede pagar muy caro: en el peor escenario ¡hay que ir a juicio!

Dado que se trata de algo muy serio, con implicaciones legales, el director del proyecto no suele tener el papel principal en la decisión de contratar, en la negociación, en la firma del contrato ni en su cierre formal. Aquí nuestro papel es de soporte a la dirección. En las grandes organizaciones hay muchos perfiles especializados en la gestión de contratos: departamento legal, departamento de compras, directores de contratación, etc.

Is Microsoft Project a de facto standard?

Microsoft Project is for sure the most extended tool for planning and controlling predictive individual projects. Could we say that it has become a de facto standard? As we cannot imagine a CFO or an accountant not using Microsoft Excel, could we say the same thing of project managers and their knowledge on Microsoft Project?

If we knew which is the highest version of Microsoft Project installed in the computer of a given project manager, could we know for how long he is not managing projects? Let's imagine he has Project 2003. Project 2007 was released in 2007, and most active project managers had it upgraded in 2008 as the latest, but this one has still 2003 in his computer: Does it mean he is not managing projects since 2008, or even longer? If he has Project 2007, is he not managing projects since 2011, or longer?

Let's assume he has Project 2010 or 2013. Can we say that he is an active project manager now? The answer is no, we can't. Most people update Project just because it is part of the Microsoft Office. Many people think they can learn Project as they do with PowerPoint, or Word. They install the software and think: “I will learn how to use it when I need it”. Shouldn't they learn project management fundamentals before?

If you need to know if a project manager is using Project properly, don't ask him about screens, menu items, or features like manually scheduled tasks, for instance.

It would be far better if you ask him about project management with Microsoft Project: Is he using the project summary task? Does he use it for tracking? Where is the critical path of a project? Where is the total slack and the free slack for a given task? Does he know how to filter milestones, how to enter planned and actual work? Does he manage resources? costs? ¿earned value? Does he know how to set a project buffer?

¿Es Microsoft Project un estándar de facto?

Microsoft Project es sin duda la herramienta más extendida para la planificación y el seguimiento de proyectos individuales de tipo predictivo. ¿Podría decirse que se ha convertido en un estándar de facto? De la misma forma que hoy día nadie se imagina un gestor financiero, un contable o un administrativo ignorando cómo se usa Microsoft Excel, ¿podría asegurarse lo mismo de los Project Managers y su conocimiento de Microsoft Project?

¿Se podría saber cuánto tiempo lleva un Project Manager sin dirigir proyectos por la versión de Project que tiene instalada en su portátil? Imaginemos que tiene instalada la versión de Project 2003. Project 2007 se liberó en 2007, la gran mayoría de Project Managers en activo ya habían cambiado su versión como muy tarde en 2008, pero este tiene todavía la versión de 2003, ¿significará eso que no gestiona proyectos desde 2008, por lo menos? Si tiene Project 2007, ¿llevará sin gestionar proyectos desde 2011, por lo menos?

Si por el contrario si tiene instalado Project 2010 ó 2013, ¿podemos deducir que en la actualidad se dedica a esto? La respuesta es no. Mucha gente actualiza la versión del Project porque forma parte de la familia Office. Tenerlo instalado no implica que lo usen bien. Mucha gente piensa que Project se aprende igual que PowerPoint, o Word. Se lo instalan y piensan: “bueno, cuando me toque usarlo, ya aprenderé”. ¿No deberían saber ciertos fundamentos de gestión de proyectos antes de usar Project?

Para saber si un Project Manager usa Project con propiedad, no le pregunten si conoce las pantallas, o las nuevas funcionalidades, por ejemplo si sabe manejar tareas manuales, etc.

Es mejor que le hagan preguntas sobre fundamentos de gestión de proyectos: ¿Usa la tarea cero? ¿Hace seguimientos? ¿Cómo se ve el camino crítico? ¿Dónde está la holgura total y la holgura libre de una tarea? ¿Sabe filtrar los hitos? ¿Cómo se entra el esfuerzo previsto y el real? ¿Sabe gestionar recursos? ¿costes? ¿valor ganado? ¿Sabe configurar un buffer de proyecto?

Ya ha salido “El Compañero de Bolsillo de la Guía del PMBOK®”

En el periodo de septiembre a diciembre de 2013 tuve el privilegio de dirigir un proyecto de voluntariado para la traducción al español del libro: A Pocket Companion to PMI's PMBOK® Guide. Autores: Paul Snijders, Thomas Wuttke y Anton Zandhuis. Editorial: Van Haren Publishing.

La traducción de este libro fue posible gracias a la labor desinteresada del siguiente equipo de voluntarios del PMI: Jose Daniel Esterkin (capítulo de Buenos Aires); Javier Martín (capítulo de Barcelona); Ariana Cisilino, Jose Ramón Arlandis, Fernando Lucas y José Lopezosa (capítulo de Valencia); Mercedes Martinez y un servidor (capítulo de Madrid). Adicionalmente participaron 13 revisores externos de PMI, entre los que se encuentran Óscar Úbeda y Rafa Pagán. No menos importante fue la inestimable ayuda de Anton Zandhuis, uno de los autores, y Bart Verbrugge, Director Editorial. En nombre de la comunidad de Directores de Proyectos de habla hispana: ¡Muchas gracias!

How to use Evernote as an agile virtual story board

I'm sure you are familiar with Evernote, the most famous tool for taking notes on a computer, laptop, tablet, smart phone, etc. Your notes are now stored “in the cloud”. You don't need physical notebooks any more. You can take notes everywhere and every time. As a knowledge worker, student, etc., you are so used to it that you can afford the premium cost of $5 per month (being the free version completely functional).

However, have you ever thought using Evernote as an virtual story board on agile projects? I have to say that Evernote is my favorite tool for agile teams (precisely: for not collocated teams). Think of all those features related to writing notes, labeling notes, moving notes from one notebook to another, searching, clipping, etc. Don't you think this is the “low-tech, high-touch” style we are always demanding for agile projects tools? For a collocated team, the best tool is a big wall in a comfortable dedicated room, of course. However, if two or three of the team members are in another sites, or the team is entirely virtual, a centralized repository for requirements and management information is the most useful.

If you are interested in the way I use Evernote as an agile virtual story board, please keep on reading...

Contabilidad para Project Managers

Muchos directores de proyecto ignoran los costes hasta que ya es demasiado tarde y el proyecto se hace económicamente inviable. En todo proyecto, el director del proyecto tiene la responsabilidad de conocer el desglose presupuestario, el margen previsto, el presupuesto de cada cuenta de control a lo largo del tiempo, la financiación aprobada, los hitos de facturación, etc. El objetivo de coste del proyecto es sin duda uno de los más importantes en todos los proyectos de cualquier empresa.

El director de proyectos quiere saber cuánto cuesta su proyecto, pero no simplemente para satisfacer su curiosidad, sino porque sabe que cuando su proyecto arroje pérdidas, él será el máximo responsable.

Como director de proyectos, usted debe conocer la terminología que utiliza el departamento de contabilidad de su organización en lo relativo a la gestión de proyectos.

EVM con Microsoft Project

Es importante elegir bien la herramienta para los cálculos EVM y registrar la información. Muchos directores de proyectos usan Microsoft Excel® y acaban frustrados cuando deben registrar mucha información sobre costes incurridos por los distintos recursos. Cuando se animan a usar Microsoft Project® también hay frustración porque no se usa adecuadamente.

Yo descubrí una forma rápida para introducir a los directores de proyectos en el uso de EVM con Microsoft Project, a partir del famoso ejercicio de “La Valla”, de Rita Mulcahy.

El siguiente vídeo explica cómo puede ayudarnos la herramienta Microsoft Project para controlar los costes del proyecto mediante el estándar EVM.

Análisis de Monte Carlo en la práctica

El siguiente ejercicio no tiene que ver con gestión de proyectos, pero sí con el fundamento matemático que se utilizará después. El ejercicio consiste en estimar el número pi.

• Como es sabido, el área de un cuadrante circular de radio 1 es pi/4. Si pudiéramos generar 10.000 puntos aleatorios de coordenadas (x,y) variando x e y aleatoriamente entre 0-1, la probabilidad de que cayesen dentro del cuadrante circular sería exactamente de pi/4.
• Con la herramienta Microsoft Excel podemos generar esos 10.000 puntos aleatorios y contabilizar aquellos que caen dentro del cuadrante circular: aquellos que cumplan x²+y²<1.
• Si dividimos este número entre 10.000 y multiplicamos por 4, obtenemos un valor sorprendentemente aproximado a 3,1415.

Esta capacidad computacional que tienen los ordenadores personales hoy día para generar números aleatorios, es la base de la técnica de modelado denominada “análisis de Monte Carlo”, que sirve para obtener un diagrama de riesgo agregado a partir de otros riesgos causales.

Generalmente, entre los activos de procesos de una organización con alta madurez en gestión de riesgos, se encuentra información histórica tabulada sobre proyectos previos similares. Cada riesgo puede tener una gráfica de probabilidad indicando su efecto sobre el objetivo de plazo o coste. A partir de estas gráficas, si nuestro proyecto se ve afectado por uno o varios de estos riesgos, puede usarse la técnica de Monte Carlo para elaborar la gráfica del riesgo agregado.

Gestión Eficaz de los Riesgos del Proyecto

 
Ejercicio: Describa cómo gestionó el riesgo el equipo de dirección del proyecto en siete párrafos, usando estas palabras clave:

1. organización ejecutora, aversión al riesgo, interesados, comité de gestión de riesgos, solo amenazas no oportunidades, RBS, plantillas de registro de riesgos-problemas-supuestos, reuniones de identificación, reuniones de seguimiento
2. brainstorming, 25 riesgos, 10 supuestos, riesgos categorizados, problemas ocurridos en el pasado
3. análisis cualitativo, matriz de probabilidad e impacto, versión inicial del registro de riesgos, riesgo R: probabilidad-impacto-importancia
4. análisis cuantitativo, valor monetario esperado, reservas de contingencia
5. aprobar acción de respuesta, actividades de mitigación-contingencia
6. el riesgo R se materializó, impacto minimizado, disparadores
7. cierre del proyecto, versión final del registro de riesgos