La Gestión de Proyectos ha cambiado de Outputs a Outcomes
Todo el mundo puede cocinar, pero no todo el mundo es cocinero. Todos podemos cantar, pero no todos somos cantantes. Nuestra profesión no es diferente: todo el mundo puede coordinar las tareas de un equipo, pero eso no les hace project managers. Para saber si un cocinero es buen profesional, no necesitamos evidencias certificando que sigue unos procecimientos. Vamos al resultado de valor: probamos su comida. Los 8 dominios de desempeño de PMBOK7 sirven para que cualquier persona puedan decir si el proyecto está siendo bien gestionado.
Lecciones Aprendidas en Proyectos
El registro de lecciones aprendidas suele exigir que el equipo del proyecto genere documentación formal. Discuten las lecciones aprendidas durante la reunión de cierre del proyecto, cuando ya no recuerdan bien los detalles, no quieren escribir sobre los errores, y están pensando en el siguiente proyecto. Debatir sobre lecciones aprendidas es útil para el crecimiento personal y las futuras relaciones profesionales entre los miembros del equipo, pero no queda un registro reaprovechable de conocimiento explícito. En PMPeople, el equipo gestor puede registrar las lecciones aprendidas cuando ocurren, reaprovechar lecciones de otros proyectos y preparar las propias para el reúso posterior.
Gestión de Proyectos sin Procesos
Los jefes no compran la gestión de proyectos. Aprueban proyectos, pero no asignan a nadie para visualizar el cuadro completo, anticiparse a los problemas, hacer pronósticos, rendir de cuentas y, en última instancia, responsabilizarse de alcanzar el éxito. Ven que el equipo del proyecto se autogestiona a base de reuniones, a las que a veces asisten para informarse y otras para resolver problemas sobre la marcha. Un profesional de proyectos sabría cómo hacerlo mejor, pero como tenemos fama de burócratas (documentos, procesos, flujos de aprobación y más reuniones), prefieren las crisis: reaccionar improvisando ante los problemas cuando es demasiado tarde.
Evaluar el desempeño del Project Manager con PMBOK7
Todo el mundo sabe cocinar, pero no todo el mundo es cocinero. Nuestra profesión no es diferente: Todo el mundo puede coordinar tareas, pero no todos son project managers. La gente debería poder opinar, sin tener que ser PMP®, si un project manager es buen o mal profesional. PMI® tiene un estándar de práctica denominado Project Manager Competency Development Framework (PMCDF), basado en los procesos de PMBOK5. Es previsible que la siguiente edición de PMCDF esté alineada con PMBOK7, que persigue que los interesados puedan comprobar el buen o mal desempeño del proyecto en 8 dominios.
Practicando la Guía del PMBOK® 7ª edición con PMPeople
PMPeople puede verse como un marco tecnológico para aquellos profesionales que quieren seguir la nueva versión del PMBOK: Como project manager profesional, puedo seguir los 12 principios más fácilmente porque tengo el hábito de actualizar la información de gestión en PMPeople. Como interesado, puedo comprobar el buen o mal desempeño del proyecto en los 8 dominios porque encuentro las evidencias directamente en PMPeople.
Controlar Proyectos Ágiles
En los proyectos software hay una complacencia alarmante sobre los incumplimientos. Es habitual escuchar la frase «Yo no he visto ningún proyecto software que cumpla fechas o que no cueste más del doble». ¿De verdad te parece que esto es un problema sin solución? Si dejas que los técnicos realicen sus tareas, pero nadie rinde cuentas sobre el proyecto, ¿por qué te sorprende que no se cumplan las fechas, o que el coste final sea muy superior? Los proyectos ágiles también se deben controlar.
El Project Manager Ágil
Un Project Manager Ágil debería tener como referencia en su día a día el rol de agile practitioner delineado por PMI®. En el texto que usa PMI® para especificar el examen PMI-ACP® se describen 7 dominios que resumen las principales áreas de responsabilidad del Director de Proyectos Ágil….
Caso de Estudio Ágil (5/5): Fin de la Primera Release
Quinta y última entrega de la traducción capítulo 23 del libro Agile Estimating and Planning, de Mike Cohn. En el post anterior, dejábamos al equipo a punto de comenzar la primera iteración de 2 semanas, que habían planificado en 4 historias de 18 puntos. También habían previsto que…
Caso de Estudio Ágil (4/5): Release Planning
Cuarta entrega de la traducción capítulo capítulo 23 del libro Agile Estimating and Planning, de Mike Cohn. En el post anterior, el equipo del proyecto Havannah estaba manteniendo una reunión con una agenda de tres puntos: Planificar la primera iteración. Revisar los resultados de la investigación de mercado. Hacer una…
Caso de Estudio Ágil (3/5): Planificar el primer Sprint
Tercera entrega de la traducción capítulo capítulo 23 del libro Agile Estimating and Planning, de Mike Cohn. En el post anterior, el equipo del proyecto Havannah había escrito 32 historias de usuario, que tenían un tamaño de 146 puntos en total. En este post, los miembros del equipo dedican dos semanas…