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?