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

Gestión Eficaz del Tiempo del Proyecto

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

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

1. penalización por retrasos, método del camino crítico, herramienta de programación
2. umbral de desviación, comité de seguimiento, Gantt de seguimiento, variaciones, hitos alcanzados
3. definir actividades, acta de constitución del proyecto, enunciado del alcance, EDT, diccionario de la EDT, trazabilidad, descomposición, atributos de las actividades
4. secuenciar actividades, dependencias, diagrama de red, lógica dura, lógica blanda
5. organigrama del equipo, estructura de desglose de recursos, recursos asociados a las actividades: recursos humanos, materiales y costes
6. estimar las duraciones de las actividades, juicio de expertos, estimación por tres valores, duración más probable, duración estimada, margen del 95%
7. línea base del cronograma, restricciones, horas extra, límites de la financiación, compresión del cronograma, aplicar adelantos, nivelación de recursos, intensificación, ejecución rápida 

Gestión Eficaz del Alcance de un Proyecto

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

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

1. taller de requisitos, prototipos, documento de requisitos, matriz de trazabilidad de requisitos
2. generación de alternativas, entregables, enunciado del alcance del proyecto
3. miembros del equipo, paquetes de trabajo, EDT, cuentas de control
4. plantilla EDT, diccionario de la EDT, línea base del alcance
5. miembros del equipo, códigos de cuentas
6. scope creep
7. control del alcance, grado de avance, desviaciones sobre la línea base, sistema de control de cambios
8. sistema de gestión de la configuración, validación del alcance, aceptación del cliente
9. entregables aceptados

The Agile Project Manager (and III)

... read the previous post

Agile methods will not fade away. They have been practiced for more than 15 years with outstanding results, not only on software projects but on many other fields. Some projects, especially knowledge worker projects occurring in fast-moving or time-constrained environments, call for an agile approach. If you take a course in Scrum, for instance, you will have solid resources to face an adaptive project. Being invented in the product management arena, agile methods can also be used in project management.

By means of the new credential PMI-ACP (PMI Agile Certified Practitioner), PMI is getting back the Project Manager on stage as the main character, also for adaptive projects. In order to get the credential, the candidate has to demonstrate they have real experience on agile projects, and also that they are capable to apply the whole set of tools, techniques, knowledge and skills needed on agile projects.

So far, PMI has not published a new standard to manage agile projects (there is no Agile Project Management Body of Knowledge), and there is no communication implying that. Instead, PMI recommends a series of 11 reference books, true master pieces on agile practices. With so good literature available, maybe this is the right approach (but those books are quite focused on software, though). On the other hand, unfortunately for those not having a good level of English, those 11 books are not translated to any language, and even worse, currently the PMI-ACP exam does not have translation aids. Nowadays, the candidate has to study lot of books and practe a lot of tests, in English.

Moreover, as far as I know, there are not many books aimed to PMI-ACP exam takers and also for those not needing the certification but to learn how to manage agile projects. Those books will come. Meanwhile, you cannot wait. Sooner or later, an agile project is going to cross your path. You better get prepared.

There is no other profession in the world more goal oriented than project management. Project Management is definitely not quite a rewarding profession: If goals are met, as they have to be, that is the reason you are in charge, then no one praise you. But if goals are not met, then the fault is only yours. While everything is doing okay, nobody says a thing, but if the outcome is not good, suddenly, everyone is talking about risk management, poor documentation, poor leadership, quality audits, communication problems, lack of social skills, convenience of coaching, etc. The result is always the same for the poor Project Manager: Everybody blames us and we don’t have good defense.

Project Managers don't need to reinvent the wheel. All they may need is already invented yet. This is the same case for adaptive projects. We don't need to invent methods to manage them. You need to adapt yourself to this new way of managing. If you don't, the next time somebody blames you for managing an adaptive project the traditional way, you will have to admit it this is entirely your fault!

Click here to read the Spanish version for this article

Click the label English to read other English written articles

The Agile Project Manager (part II)

... read the previous post

So, finally the project was a success, not because of you, but despite you. You wanted to impose unwise methods, now you realize that. Fortunately your team did not obey you. Now you know they were right, and you were not. You are also worried about the near future. Nowadays it is not very uncommon that projects are under continous change by nature. Knowledge workers have to give the most within the least time, adapting efforts to the changing needs from customers. Moreover, you feel this is not only a trend: this is like business as usual more and more. You recently did some research about agile methods. To your surprise, these methods are simple and easy to understand (the challenge is not about knowing them, but practicing them properly). You enjoy specially practical videos explaining the job of a product owner: http://goo.gl/NHYZWL; and this other one on daily stand-ups: http://goo.gl/EiXCGo

Why not using your project management knowledge, skills and experience on this kind of projects? 

The Agile Project Manager (part I)

Imagine this: You are a project manager with a lot of experience managing projects. You really love your job and consider it as a profession. You got your PMP® more than 10 years ago. Your boss and clients are used to congratulating you at project closures. You are a regular speaker on congresses about risk management, Microsoft Project, etc. You volunteer from time to time for PMI® projects and events. Everything seems to show that you are a highly rewarded professional: When you talk about project management, everybody listen. Many colleagues appreciate your expert judgment.

Now you have just closed your last project, but you are not happy at all. It was a consulting project for a big company, aimed to beat the competition through a new technology. Client representatives knew for sure that they could not remain as-is, but they did not know how to change what. Dissapointed by the poor progress of an internal SME team, they decided this was a case for procurement. Your company won the bid thanks to a project plan based on flexibility, adaptation and collaboration with the customer team throughout the project. Your company also included some experienced agile CVs.

From the very beginning, you were aware it was going to be easy to complete the requirements baseline. Very soon you realized that the client team would never sign off a document like that, not to mention the scope statement, WBS, cost baseline, detailed schedule, etc. How on earth could you avoid scope creep? The only planning information you had was about some given milestones and the final project deadline in nine months!

Regarding costs, the contract specified person-days by category, that's all. Having so much uncertainty, how would you develop the project plan? The customer wanted biweekly follow-up meetings. How would you report progress? Comparing to what baselines? Your boss told you not to worry because the team members had succeded on analogous projects before. You could trust them. They should do a great job...

However, you wonder: So, what am I supposed to do?

ISO 21500 vs. PMBOK

En el post anterior Navegando por la Norma ISO 21500, les proponía descargarse un fichero pdf con enlaces dentro del mismo fichero para navegar por los procesos. Esta forma de representar los procesos está basada en un estándar de modelado de procesos llamado IDEF0. IDEF0 es un método sencillo de especificación formal de procesos, que permite la descomposición de procesos a través de un análisis descendente (top-down). Yo ya utilizaba este modelo para representar la Guía del PMBOK®. En el enlace http://goo.gl/XQeIeB pueden descargar un fichero PDF titulado “Navegador de la Guía del PMBOK”. Una de las primeras diferencias entre ISO 21500 y la Guía del PMBOK®, es que los procesos de ISO 21500 se representan mejor.