Como usar la EDT en el control de riesgos del proyecto

Siguiendo con los artículos sobre el uso de la Estructura Detallada de Trabajo (EDT) en los proyectos, Glen B. Alleman nos sugiere en un artículo de su blog algunas ideas para usarla EDT en el control de riesgos.

El artículo se titula: "Connecting Risk and the WBS". En él, Glen señala que en ocasiones la administración del riesgo no se maneja en el contexto adecuado y propone ideas para usarla en la administración y control de riesgos del proyecto:

1. La medición del porcentaje completado para cada "paquete de trabajo" debe ser definida de manera que realmente mida el porcentaje físico completado.

Como manejar el estrés en los proyectos. Algunas ideas rápidas

Oscar Ceceña escribe una interesante entrada en su blog Palabras necias para oídos sordos: "Una mala manera de despertar" en el que nos platica sobre como se puede volver estresante la vida de un administrador de proyectos.

Para Oscar y todos los administradores que nos encontramos en situaciones similares, justo acabo de encontrar un artículo con ideas sobre como manejar el estres en los proyectos.

Es de Simon Cleveland  y se encuentra en dos partes aquí y aquí.

Espero que le sirva a Oscar y a todos.

¿Hay futuro para la administración de proyectos en la metodología ágil?

photo © 2007 Danny Hope | more info (via: Wylio)

El pasado mes de junio escuche un webcast de Michele Sliger en el que comparte su opinión sobre el futuro de la administración de proyectos dentro de las metodologías ágiles, organizado por la AGILE COMMUNITY OF PRACTICE del PMI.

Antes de compartir mis notas, un poco de información necesaria. Wikipedia define:

"El desarrollo ágil de software es un marco de trabajo conceptual de la ingeniería de software que promueve iteraciones en el desarrollo a lo largo de todo el ciclo de vida del proyecto. Existen muchos métodos de desarrollo ágil; la mayoría minimiza riesgos desarrollando software en cortos lapsos de tiempo. El software desarrollado en una unidad de tiempo es llamado una iteración, la cual debe durar de una a cuatro semanas. Cada iteración del ciclo de vida incluye: planificación, análisis de requerimientos, diseño, codificación, revisión y documentación. Una iteración no debe agregar demasiada funcionalidad para justificar el lanzamiento del producto al mercado, pero la meta es tener un demo (sin errores) al final de cada iteración. Al final de cada iteración el equipo vuelve a evaluar las prioridades del proyecto".