NOVEDADES DE MICROSOFT PROJECT 2013
sábado, 4 de mayo de 2013
De la página de PMHut (http://www.pmhut.com/)
traigo ahora un artículo titulado "Is-pmbok-overkill?" por Otterholt
Barry.
Barry inicia su
entrega con esa pregunta: ¿Es el PMBOK una norma excesiva?
El considera que una
respuesta simple es que sí, la mayoría de las veces, debido que no se le aplica
en forma correcta.
Barry señala que
normalmente la pregunta refleja falta de comprensión al PMBOK.
Este conjunto de
normas son aplicadas en mayor o menor medida por la mayoría de quienes
practicamos la Administración de Proyectos (certificados o no), por que agrupa
algunas de las mejores (o más ampliamente reconocidas) prácticas en un único
punto de referencia.
De todo el artículo,
la afirmación que más resaltante es que el PMBOK no es una metodología y no
pretende ser una guía de "cómo" se debe dirigir un proyecto. Destaca
Barry, en las primeras páginas de la referencia los autores señalan claramente
sobre el PMBOK "... no significa que los conocimientos se deban aplicar de
manera uniforme a todos los proyectos...", y explican que se trata de un
marco de referencia, con herramientas y técnicas que pueden aplicarse con mayor
o menor rigor a las situaciones que surgen durante la ejecución de un proyecto.
Barry también señala
que los autores del PMBOK usan el término "adaptación" para animar al
lector a adaptar las herramientas de sugeridas por el PMBOK a las circunstancias
particulares de cada proyecto.
Entonces, ¿Es el
PMBOK una norma excesiva? Barry considera que puede serlo, si no se adaptan sus
recomendaciones a las necesidades específicas del proyecto.
Finalmente, Barry
lista algunos de los beneficios que encuentra en el uso del PMBOK:
· Proporciona un lenguaje común para que
administradores de diferentes proyectos y/o áreas geográficas puedan tener
conversaciones productivas, y para que los equipos recién formados puedan ser
productivos rápidamente.
· Sugiere protocolos probados que pueden
seguirse en el proyecto.
· Ofrece una serie de mejores prácticas
que pueden aplicarse a situaciones comunes y no comunes.
· Recomienda técnicas para delimitar los
problemas, a fin de facilita su solución.
· Proporciona mecanismos de prevención,
para evitar problemas en lugar de tener que reaccionar a ellos.
Barry reconoce que
cuanto más conoce el PMBOK, más se beneficia de él. Inicialmente lo concebía
sólo como un libro de referencia apto sólo para los proyectos más abstractos,
pero ahora se da cuenta de que está repleto de material útil que puede aplicar
incluso en el proyecto más pequeño, siempre y cuando se haya tomado el tiempo
para entender y adaptar las recomendaciones y sugerencias a sus necesidades.
Sugiere algunos
libros que considera útiles para pone el PMBOK en términos más humanos y
situacionales, como los libros de Rita Mulcahy
, de Heldman y de Verzuh.
, de Heldman y de Verzuh.
¿REALMENTE NECESITO UN CRONOGRAMA PARA MI PROYECTO?
Ahora vamos a revisar la explicación en
la que Ben Ferris, desde el Blog de Cobalt, nos da su punto de
vista de para que necesitamos el cronograma en nuestros proyectos.
Como señala Ben, todos los que hemos
trabajado en un proyecto sabemos que tiene que haber un cronograma del
proyecto. El Administrador del Proyecto requiere de una planificación.
Pero a veces los miembros del equipo se preguntan por qué es necesario contar
con un cronograma.
Las razones que Ben señala son las siguientes:
Organizar el Plan de Proyecto.
Pero un plan de proyecto toma la lista
de tareas, la organiza y le agrega información mucho más valiosa:
·
Fechas de inicio y fin de cada tarea
·
Duración de cada tarea
·
Dependencias entre las tareas (predecesores y sucesores)
·
Jerarquía de la organización de las tareas mediante la Estructura
Detallada de Trabajo
- Work Breakdown Structure (de la que hemos comentado su utilidad en esta estrada y algunos consejos sobre cómo construirla en esta otra).
· Una gráfica de Gantt que muestra los intervalos de fechas de las tareas
en forma de barras con el tiempo.
El resultado es un plan de proyecto que ofrece una
vista jerárquica de las tareas, permite ver fácilmente las dependencias entre
ellas, los intervalos de fechas para cada tarea, y una visualización gráfica de
los plazos para cada actividad.
Además Ben apunta en forma acertada que
el programa del proyecto no es sólo para proyectos complejos. Incluso un
proyecto con sólo unas pocas tareas se pueden beneficiar de la elaboración del
cronograma, y Ben además nos recuerda que el software de planificación también
permite la programación de recursos para que las tareas se puedan asignar a los
recursos apropiados. Todo esto permite a los miembros del equipo saber cuáles
son las tareas que se les asignan y en qué momento deben ejecutarlas.
Comunicar el Plan del Proyecto.
Una vez que ha creado el programa, es
fácil usarlo para comunicarse con los interesados, los miembros del equipo y
cualquier otra persona que necesite ser informada del plan y el estado del
proyecto.
El cronograma puede ser impreso y
distribuido en las reuniones, y la naturaleza gráfica del diagrama de Gantt
hace que sea fácil de entender con un simple vistazo.
Seguimiento de los Progresos contra el Plan del Proyecto.
El cronograma del proyecto es una
herramienta que debe ser actualizada periódicamente en función de las
condiciones que se producen durante la ejecución del proyecto.
La mayoría del software de programación
de proyectos por lo general permite una tomar una instantánea que sirve para
indicar como estaba planeado el proyecto al arranque (la línea base) que se usa
para comparar con el estado actual del proyecto. Esto permite que el
Administrador del proyecto pueda monitorear el progreso a través del ciclo de
vida del proyecto.
El establecimiento de dependencias
entre las tareas en el plan de proyecto da visibilidad a los retrasos en tareas
futuras (y, potencialmente, todo el proyecto) por cada tarea que se retrase.
Sin él es muy difícil determinar cómo los retrasos en las tareas individuales
afectaran a otras tareas.
Los elementos expresados por Ben pueden
ser de mucha ayuda la próxima vez que se deba explicar a un miembro del equipo
cual es el uso del cronograma en nuestros proyectos.
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:
- La medición del porcentaje completado para cada "paquete de
trabajo" debe ser definida de manera que realmente mida el porcentaje
físico completado.
- Para calcular el valor ganado se deben definir
los "elementos de costo", sus relaciones y sus entregables
- Debe existir un proceso de administración del riesgo. Más
importante aún, debe aplicarse.
- Se debe determinar la Ruta Crítica del Proyecto
- Se deben establecer Medidas de Rendimiento Técnico - ¿Cómo miden
los interesados (comprador y vendedor) el progreso del proyecto?
- ¿Se tienen procesos que agreguen valor al proyecto?
- Se deben controlar las asignaciones de personal - ¿Donde está la
gente que necesita?
- Horas extras - ¿El equipo esta sobre trabajado? ¿Como se establece
lo que significa sobretrabajado?
- Hay una estimación clara de la conclusión - ¿se tiene alguna idea de lo que el proyecto costará cuando se haya terminado? ¿Se tiene determinado con claridad cuando acaba el proyecto?
Debemos aprovechar la
EDT para responder estas preguntas en forma precisa, esto debe ayudar a
mantener controlados los riesgos de nuestros proyectos.
REFLEXIONES SOBRE
LA VERSIÓN PRELIMINAR DE LA QUINTA EDICIÓN DE LA GUÍA PARA ADMINISTRACIÓN DE
PROYECTOS
Ante la inminente aparición de la 5ª
Edición del PMBOK(C), algunas personas que ya han tenido oportunidad de revisar el documento
preliminar comienzan a compartir sus comentarios.
Dice Andy que los grupos de procesos
tradicionales de inicio, planificación, ejecución, seguimiento y control, y el
cierre no se han modificado. Este sigue siendo el marco para el flujo de los
procesos y actividades.
Cuando se publique la 5ª edición,
contemplará 47 procesos según el documento preliminar. Esto representa un
aumento del 12% con respecto a la 4ª edición y hay alguna reorganización para
dar coherencia. Andy presenta un par de gráficos en su artículo, que no voy a
reproducir aquí pero que invito a leer.
Lo importante del artículo es el análisis que sigue:
Esta propuesta alcanza un nuevo récord,
con 614 entradas, herramientas y salidas, que representa un aumento
impresionante de 19% respecto a la 4ª edición. Otra curiosidad es que sólo se
ha encontrado la palabra "ágil" un total de seis veces en el cuerpo
del documento y no aparece glosario.
Andy se pregunta por qué ocurre esto,
considerando la relevancia que los métodos ágiles han tomado en los últimos
tiempos (incluso al interior del PMI).
Y esto plantea una pregunta
interesante: ¿el PMBOK pretende ser una guía a toda la gestión de proyectos o
solo de los proyectos en los que aplique el método de la cascada?
Si se pretenden abarcar los conceptos
ágiles, entonces es curioso que las palabras “planning poker”, “Fibonacci”,
"auto-organización", "osmótica", y
"desagregación" no aparezcan en ninguna parte en la versión
preliminar del documento, mientras que técnicas tradicionales como "Delphi",
y "WBS" están bien representadas.
Andy se pregunta si habrá la necesidad
de un cuerpo de conocimiento independiente para métodos ágiles.
Cierra su evaluación con un juicio: el
PMBok sigue aumentando de tamaño, y en la misma proporción aumenta la
complejidad de su uso. Las organizaciones tratan de desarrollar metodologías de
esto, y cada cuatro años, estas sufren cambios importantes. Si el cambio se
debe a nuevas prácticas que están surgiendo, entonces bienvenido sea, pero si
se trata simplemente de otro comité dejando su marca, entonces no es tan
bienvenido.
LOS 5 PRINCIPIOS DEL ÉXITO DE UN PROYECTO
Glen B. Alleman es
un prolífico escritor sobre temas de proyectos, dice que los cinco principios
inmutables de éxito del proyecto deben ocurrir para tener cualquier oportunidad
real de terminar a tiempo, dentro del presupuesto, y cumpliendo con las
especificaciones.
Estos son los 5 principios propuestos
por Glenn:
Y la evidencia de que estos principios se están cumpliendo, son los
documentos concretos que representan una forma de medir el éxito de los mismos.
Los documentos propuestos por Glen son:
1. La estructura detallada del trabajo - ¿Cuáles son los productos que se
producen y los procesos necesarios para producir estos productos? La EDT no
muestra los procesos como elementos independientes. Los procesos se muestran
como parte de los elementos de la EDT.
2. La estructura de desglose de la Organización - ¿quién va a hacer el
trabajo?
3. La integración de la EDT y la EDO permite que todo el mundo sepa de lo que
es responsable.
4. Programar el trabajo - es una forma de mostrar cuando se está realizando
el trabajo y las dependencias entre los esfuerzos realizados.
5. Los entregables identificados - lo que el cliente va a obtener durante
la ejecución y al final del proyecto.
6. El presupuesto - ¿cuánto estamos pensando gastar en el trabajo del
proyecto?
7. Los costos - ¿cuánto estamos gastando realmente comparado contra el
presupuesto?
8. ¿Cuáles son las varianzas? - ¿Cuáles son las diferencias entre el gasto
previsto y el gasto real? Y más importante, ¿cuáles son las variaciones en el
calendario?
9. Sume a todo esto - Glen sugiere totalizar todas las variaciones en costo
y calendario, para ayudar a la toma de decisiones.
10. Tomar acción - para corregir las desviaciones de costo y tiempo.
11. De ser necesario, incorporar cambios - para que el proyecto pueda volver
al camino correcto.
El acta del proyecto se puede considerar la luz verde para que el proyecto arranque. Las actividades del proyecto puede comenzar una vez que el acta del proyecto ha sido desarrollada y aprobada. El propósito de este documento es describir las razones y objetivos del proyecto, los elementos que podrían considerarse dentro del alcance o fuera del él, los beneficios esperados del proyecto, y lo más importante: un presupuesto de alto nivel y quién tiene la autoridad para gastar estos recursos.
Una vez que el proyecto está en marcha el acta del proyecto también sirve como fuerza estabilizadora. Van a presentarse opiniones e ideas sobre qué aspectos del proyecto se debe conservar y cuales deben ser eliminados. Estas opiniones e ideas de la gerencia y el equipo de trabajo se basan en preferencias personales. El acta del proyecto debe servir como punto de referencia del propósito original del proyecto y para asegurar que el proyecto no sucumba ante la corrupción del alcance.
El Cronograma del Proyecto
El cronograma del proyecto es el
siguiente documento que se debe tener el para ejecutar con eficacia un
proyecto. La misma definición de "proyecto" (un esfuerzo temporal con
un principio y un final definidos realizado para cumplir con metas y objetivos
únicos) habla de la importancia del cronograma.
El cronograma del proyecto toma el
inicio y el final del proyecto, lo divide en fases, y en tareas. A cada tarea
se le asigna una duración, recursos, y su dependencia de alguna tarea o
actividad anterior. Entonces este documento sirve como base para saber si el
proyecto está avanzando y cumpliendo con sus plazos o si se tienen que hacer
ajustes.
El Reporte de Estado.
Una vez que el proyecto se pone en
marcha es importante mantener a todos los involucrados informados sobre cómo
van las cosas. No hay mejor manera de hacerlo que la elaboración de informes de
estado. Este informe debe contener las respuestas a estas cuatro preguntas:
¿Que se ha logrado en el proyecto desde
el último informe de situación?
¿Qué sigue por hacer?
¿Qué se interpone en el camino del
proyecto?
¿Hay alguna necesidad especial de este
proyecto que deba ser discutida?
Elaborar un reporte de estado no tiene
por qué ser abrumador y el resultado siempre debe ser fácil de leer. Es
recomendable acordar algún tipo de código de estado que pueda proporcionar
rápidamente una idea del estado general del proyecto (Verde, Amarillo y Rojo
siempre funcionan bien). Si un ejecutivo ve todo esta en verde sabrá que no
debe preocuparse. Y si el estatus se desliza hacia el amarillo o rojo, el
ejecutivo sabrá que tiene que intervenir.
El Registro de Riesgos
El trabajo como administrador del
proyecto es conseguir que el proyecto se concluya. Sin embargo existen fuerzas
poderosas cuyo único propósito es evitar que el proyecto termine. Estas fuerzas
se denominan "riesgos". Estos riesgos pueden ir desde un recurso
crítico que se enferma, hasta un proveedor clave que se va a la quiebra.
Es necesario vigilar estos riesgos en
forma regular y evitar que se conviertan en problemas que puedan causar
estragos en el proyecto. No hay mejor lugar para hacerlo que el Registro de
Riesgos. Este documento identifica los riesgos potenciales y los clasifica por
la probabilidad de ocurrencia y la severidad de impacto en el proyecto si es
que ocurren. Además, es necesario que haya una estrategia de mitigación, para
cada riesgo.
Nota del traductor: Vale la pena
recordar que el PMI considera que existen riesgos "positivos" para
los que debe buscarse que ocurran ya que esto representa un potencial beneficio
para el proyecto.
El Plan de Comunicación
El documento final que cada proyecto
debe tener es un plan de comunicación. Ocurren tantas cosas alrededor del
proyecto que avanza a todo vapor que es difícil recordar que tiene que saber
qué persona y cuándo debe saberlo. Un plan de comunicación bien pensado minimiza
cualquier malentendido que pudiera ocurrir y ayuda a mantener a todos los
interesados en la misma línea.
Suscribirse a:
Entradas (Atom)