7 razones para crear la WBS/EDT

Soy Iván Rivera, PMP

Soy fan de Starwars, disfruto la Ciencia Ficción y escribo sobre gestión de proyectos (o lo que se me ocurra). Puedes leer un poco sobre mi formación aquí.

Los lectores asiduos del blog saben que la WBS/EDT es un tema del que me gusta comentar (aquí están las entradas).

Hoy vuelvo al tema con este artículo en el que Praveen Malik, PMP nos da 7 razones para crear la WBS/EDT:

Como bien dice Praveen, la WBS/EDT hace la vida del Administrador de Proyectos: es la división del alcance total del trabajo en componentes más pequeños y más manejables, lo que la convierte en una herramienta fabulosa para delimitar y representar el alcance total, el alcance del proyecto y el alcance del producto.

La EDT (WBS) como fundamento del proyecto

Soy Iván Rivera, PMP

Soy fan de Starwars, disfruto la Ciencia Ficción y escribo sobre gestión de proyectos (o lo que se me ocurra). Puedes leer un poco sobre mi formación aquí.

Desde el correo de Method123 propongo hoy esta explicación de porqué la EDT (WBS) es la piedra angular de toda la Adminsitración del Proyecto.

El manejo de la EDT (WBS) en el proceso de Adminsitración de Proyectos ha sido un tema recurrente en este blog. Todas estas entradas tratan, al menos en parte, sobre el uso de esta herramienta. Es un claro indicador de la importancia que personalmente le doy a esta herramienta.

La estructura de desglose del trabajo (WBS - EDT) es una herramienta de Administración de proyectos que, como señala el artículo, a menudo es mal entendida y poco apreciada a pesar de ser pieza fundamental de la base de cualquier metodología de Administración de proyectos. Y es que existen muchos conceptos erróneos sobre qué es una WBS, cómo se usa y por qué es una parte tan importante del proceso de gestión del proyecto.

La WBS es una agrupación jerárquica orientada a la entrega del trabajo que debe ejecutar el equipo del proyecto para lograr los objetivos del proyecto y crear los entregables requeridos. Organiza y define el alcance total del proyecto. Cada nivel descendente representa una definición cada vez más detallada del trabajo del proyecto (es decir, una descomposición del trabajo del proyecto).

¿Qué NO debe incluir?

• Ninguna referencia a QUIÉN está haciendo el trabajo
• Ninguna referencia a CUANDO se está haciendo el trabajo
• Ninguna referencia a CÓMO se está haciendo el trabajo

Para elaborar la WBS se sugiere:

Usar sustantivos y adjetivos para describir el resultado del trabajo

No indicar dependencias, duraciones, ni asignaciones de recursos.

La WBS aborda QUÉ es un proyecto. El siguiente paso para determinar el CÓMO es el trabajo del Diagrama de red. Y finalmente, el cronograma del proyecto se usará para determinar CUÁNDO y QUIÉN hará el trabajo.

Una buena WBS ayuda a mentener el rumbo para entregar el 100% del alcance acordado y evitará la corrupción del alcance.

Una vez que se establece el primer nivel de la WBS, inicia el proceso real de Adminsitración de proyectos .

¿Cuántos niveles se necesitan? Esta respuesta es diferente para cada proyecto. La recomendación es descomponer a un nivel suficiente donde haya una comprensión clara de cuál es el producto entregable, sin llegar a la exageracion. Es un tema que requiere el uso de la experiencia por parte del Adminstrador, patrocinadores y el equipo del Proyecto.

Si requieres ayuda con tus proyectos, puedes contactarme a través de mis redes sociales:

Eliminado mitos de la EDT (WBS)

Retomo (por fin) las entradas del blog, con este post a partir de un correo de Method123 sobre la importancia de la WBS.

Es un tema que ya se ha tratado aquí en estas entradas:

Algunos mitos de la estructura de desglose del trabajo.

La estructura de desglose del trabajo (WBS) es una herramienta a menudo malentendida y subestimada de la gestión de proyectos, a pesar de ser la base de la gestión del proyecto. El autor consdiera, y yo comparto, que es una pieza fundamental de la base de cualquier metodología de gestión de proyectos. 

Pero existen muchos conceptos erróneos sobre lo que es una WBS, cómo se usa y por qué es una parte tan importante del proceso de gestión del proyecto.

Seis reglas para elaborar una buena EDT (WBS)

"WBS" by DoD - DoD. Via Wikipedia.

En el blog de CapTech me he encontrado un artículo de Tim Fite que nos comparte algunas reglas para elaborar una buena EDT.

Como bien reconoce Tim, no se trata de un conocimiento nuevo que vaya a revolucionar el campo de la Administración de Proyectos. Al contrario, se trata de un repaso a cosas que ya se han escrito. (De hecho, apenas unos dias atras una amable lectora platicaba del tema en este post -La EDT (WBS) es una herramienta útil, cuando está bien hecha-).

1. La motivación básica o el Imperativo Existencial

En primer lugar, si no se tiene una EDT, ni siquiera ay que seguir leyendo. Una EDT que no existe no tiene por qué seguir ninguna regla en absoluto.

(En articulos anteriores como este y este hablamos ya de la utilidad de contar con una EDT para el proyecto. Nota del Traductor).

Algunos consejos para construir la Estructura Detallada de Trabajo (WBS)

La Estructura Detallada de Trabajo es para algunos la herramienta clave para iniciar un proyecto (soy uno de ellos). Sin embargo parece ser una herramienta que, en el mejor de los casos no es aprovechada a su máximo potencial.

Para ayudar a comprender mejor la EDT, comparto ahora un artículo de Tom Mochal y notas de un libro de Liliana Buchtik.

Tom nos presenta en este artículo de TechRepublic algunos consejos para la creación de una estructura detallada de trabajo, y complementan la lista otros consejos que he obtenido del libro Secrets to Mastering the WBS in Real-World Projects: The Most Practical Approach to Work Breakdown Structures (Wbs)! de Liliana Buchtik.

Propuesta de esquema híbrido de seguimiento y control de proyectos

Soy Iván Rivera, PMP

Soy fan de Starwars, disfruto la Ciencia Ficción y escribo sobre gestión de proyectos (o lo que se me ocurra). Puedes leer un poco sobre mi formación aquí.

Cada semana participó en una reunión virtual de administradores de proyectos en Twitter que se denomina @PMChat y que se puede buscar también con el hashtag #pmchat.

En una de esas reuniones surgió la conversación respecto a algunas herramientas qué se puede usar en el mundo ágil y en la administración de proyectos tradicional. La charla derivó finalmente a proponer el uso de tableros kanban, reuniones diarias de avance (standups) y la WBS. Esta es mi propuesta sobre cómo podrían usarse juntas estas herramientas.

Elementos minimos de un Sistema de seguimiento al Valor Ganado

Glen B. Alleman escribe en su blog Herdingcats un articulo titulado "Elementos mínimos de un Sistema de seguimiento al Valor Ganado" en el que sugiere los elementos que considera los mínimos necesarios para establecer un Sistema de seguimiento al Valor Ganado.

Definir la WBS

Como ya hemos comentado en esta entrada, "el primer paso para hacer un adecuado cálculo del valor ganado es definir perfectamente el alcance del proyecto y plantearlo en la WBS", como señala Glenn esto es necesario ya que si no establecen cuáles son los componentes de los entregables, no se puede saber cuánto constarán y qué trabajo se requiere para hacerlos.

¿Qué tanto se debe planificar en el proyecto?

Soy Iván Rivera, PMP

Soy fan de Starwars, disfruto la Ciencia Ficción y escribo sobre gestión de proyectos (o lo que se me ocurra). Puedes leer un poco sobre mi formación aquí.

Desde el correo de Method123 traigo ahora este artículo, sobre ¿Qué tanto se debe planificar en el proyecto?

Dice el artículo que la fase de planificación de cualquier proyecto es una de las más críticas, ya que es donde se hacen las suposiciones y estimaciones sobre lo que se debe hacer, quién lo hará y cuánto tiempo tomará. Además, durante el desarrollo del plan se toman en cuenta las dependencias y los riesgos para desarrollar un plan realista y con mayor certeza. Hay que tener claro que mientras más incertidumbre, menos realista será el plan.

Solo que no es fácil determinar cuanto tiempo, energía y dinero debemos poner en la fase de planificación. ¿En donde está el punto de inflexión y el rendimiento decrece? ¿En qué punto debemos admitir que estamos en un nivel de incertidumbre tal que no podemos hacer estimaciones realistas?

Consideraciones previas al uso del Método de Valor Ganado

En los próximos días va a publicarse una nueva colaboración mía en liderdeproyecto.com.

Este es el artículo que da origen a esa colaboración.

Introducción

Durante la ejecución de un proyecto el Administrador de Proyectos debe mantener enterados a todos los interesados sobre todos los temas del proyecto.

Para informar el avance, uno de los métodos de elección es el Análisis de Valor Ganado.

Como hacer la configuración inicial del diagrama de Gantt.

Introducción

En días pasados mis alumnos me preguntaron cual era la forma adecuada de empezar a trabajar con el diagrama de Gantt. Si bién ese tema no es parte de plan de estudios de la clase, dedicamos algo de tiempo a comentar el asunto.

De ahí surge la idea de escribir un post, para comentar las sugerencias de configuración inicial de la herramienta, sin centrarse en una herramienta específica, y luego revisar a datalle como se hace la configuración en Project, Open Proj y Gantter.

Advertencia. Todas las marcas mencionadas en este post son propiedad de sus respectivos dueños y se mencionan aquí solo como referencia.

Además, reconozco que nos soy un experto en alguna herramienta específica, por lo que lo que aquí se escribe solo tiene como respaldo el que son practices que han resultado efectivas en los proyectos que he implementado. Tampoco es el fin del artículo el tartar de explicar la teoría que soporta los conceptos que aquí se mencionen.

Finalmente, en este link se puede consultar el documento en un formato que facilita su lectura.

Observaciones iniciales

Considerando que la elaboración y control del cronograma es escencial para conocer la forma en la que los objetivos del proyecto se van concretando, se sugiere optimizar el diagrama de Gantt para asegurar que proporciona la información mas precisa posible.

¿Como se debe enfrentar un proyecto cuando es imposible definir el alcance total del mismo?

Planificación Gradual

El administrador es asignado a un proyecto recién autorizado y debe iniciar a la brevedad, a pesar de que el alcance total del mismo aun no ha sido definido.

Esta situación es más o menos común dependiendo de la madurez de la organización y de su apego a las mejores prácticas de administración de proyectos y ocurre que aunque están claros los siguientes pasos (la primera fase del proyecto, el primer entregable), no se puede planear mucho más adelante. Para estos casos puede resultar útil una mejor práctica denominada Rolling Wave Project Planning (RWPP).

Y ahora, mitos sobre valor ganado.

Keith Custer, PE menciona en su artículo: The Seven Deadly Myths of Earned Value Methods in Project Management siete mitos sobre la implementación del Análisis de Valor Ganado.


Ellos son:


1. Sólo las agencias gubernamentales y sus contratistas necesitan implementar la Administración del Valor Ganado
2. Administrar el Valor Ganado sólo es útil para proyectos grandes o de largo plazo
3. El método de administración del Valor Ganado es demasiado rígido
4. Existe un método de valor ganado "ligero"

Nuevo listado de herramientas gratuitas de apoyo al administrador de proyectos.

Sin afán de polemizar sobre la influencia de google en la vida del ciudadano común, y siguiendo con la línea que inició en este post y continuó en este otro, ahora escribo sobre un conjunto de herramientas gratuitas útiles en la administración de proyectos, algunas de las cuales operan alrededor las google apps.

Kit de supervivencia para Administradores de Proyectos

En este blog ya se ha tratado el tema del uso de plantillas en la administración de proyectos. Específicamente en este post y en este.

Ahora se me ocurrió la idea de conjuntar mi propia versión de un Kit de supervivencia para Administradores de Proyectos, a partir de un artículo de la revista CIO en donde Gary Hamilton, Gareth Byatt y Jeff Hodgkinson presentan una lista de los elementos mínimos que debe contener un kit de este tipo.

Yo he adaptado esta lista agregando algunos elementos que a mi parecer faltan en la lista original.

¿Qué es la estructura de desglose de objetivos (goal breakdown structure)?

Normalmente el Adminsitrador de Proyectos controla en el proyecto algunas estructuras de desglose: de trabajo (EBS / EDT), de recursos (RBS), de Riesgos (tambien abreviada RBS), de personas (OBS), etc.

En su libro "Improving Your Project Management Skills", Larry Richman propone una esturctura de desglose adicional: la estructura de desglose de Objetivos o Goal Breakdown Structure. (Complemento el artículo con algunas definiciones de Wikipedia

Dice Larry: "La estructura de desglose de objetivos es también una estructura lógica y jerárquica que demuestra, al aumentar los niveles de detalle, los resultados que un proyecto debe lograr". Al igual que en la WBS, el propósito de GBS es definir todos los objetivos y sólo los objetivos necesarios para alcanzar las metas de más alto nivel del proyecto.

Para crearla se siguen reglas de descomposición similares a las usadas para crear la WBS.

Como elaborar la matriz de riesgos del proyecto

En su blog, Glen B. Alleman nos propone un método para elaborar la matriz de riesgos de nuestro proyecto.

Antes de comentar el artículo de Glen, me permito revisar algunos conceptos del artículo "Understanding Project Risk Exposure Using the Two-Dimensional Risk Breakdown Matrix". 

Los proyectos son esfuerzos complejos que implican un conjunto único de tareas y actividades realizadas tomando en cuenta una o más restricciones para cumplir los objetivos definidos. Una de las áreas clave que requieren una gestión proactiva en los proyectos es la gestión de riesgos, que surgen de las incertidumbres que pueden afectar el logro de los objetivos. Los riesgos pueden ser complejos, sobre todo por la amplia gama de orígenes y de posibles efectos sobre el proyecto.

Sin embargo, el proceso de riesgo a menudo no produce nada más que una larga lista de riesgos, que puede ser difícil de entender o manejar. A esta lista se le puede organizar para determinar qué riesgos deben abordarse primero, pero esto no proporciona ninguna información sobre la estructura de la exposición al riesgo en un proyecto.

Para organizar la información sobre la exposición al riesgo en un proyecto se usa la estructura de desglose de Riesgos (RBS).

Enseñando administración de proyectos mediante juegos. Experiencia 2. EDT

Project Management using games. Experience 2. WBS
English version here.  Photos at the end.

Una segunda experiencia buscó ahora familiarizar a los alumnos con el concepto de EDT. Para ello se diseño una actividad que consistió en desarrollar la estructura detallada de trabajo de un proyecto propuesto por el profesor.

La técnica incluyó trabajo en el escritorio, a fin de entender el alcance del del proyecto e identificar entregables y luego construir la EDT usando etiquetas PostIt.

La hoja de ruta: administración de proyectos paso a paso

En la misma línea que el post anterior ahora comparto un post en el que Jason Westland nos propone una metodología que explica paso a paso como administrar proyectos.

Jason nos recuerda que a menudo los proyectos pueden ser caóticos y recomienda que para permanecer centrado y lograr el éxito, se ataquen paso a paso, lo que permitirá tener control total sobre cada acción que se emprenda.

¿Por qué fracasan los proyectos de TI? (Segunda parte: Las razones de Standish Group)

Un segundo artículo titulado “Why a project fails?” de Amit Sarkar refiere a un estudio de Standish Group cuyos resultados muestran que las diez razones más frecuentes por las que fallan los proyectos de TI son:

1. Mala planeación. Los administradores tienden a pensar en la planeación como una pérdida de tiempo con el argumento erróneo de que es mejor ocupar el tiempo actuando que planeando.

2. Objetivos y metas poco claras. Esta causa también aparece en el post anterior. En este caso la causa se atribuye a que muchos proyectos de TI se elaboran en forma progresiva y se planea por oleadas.

10 icebergs que hundirán al proyecto

Soy Iván Rivera, PMP

Soy fan de Starwars, disfruto la Ciencia Ficción y escribo sobre gestión de proyectos (o lo que se me

ocurra). Puedes leer un poco sobre mi formación aquí.

Desde el correo de SmartDraw Software, propongo ahora 10 icebergs que hundirán al proyecto.

Se dijo que el Titanic era insumergible. Sabemos lo que pasó.

Muchos proyectos parecen igual de sólidos al principio, impulsados por el optimismo que naturalmente viene con cosas nuevas. Pero hay una gran cantidad de obstáculos que pueden convertir rápidamente un proyecto en un desastre.

Estos son los diez posibles icebergs que pueden hundir tu nave:

1. Objetivos poco claros

2. Insuficiente detalle.

3. Corrupción de Alcance.

4. Personas equivocadas para el trabajo.

5. Problemas de responsabilidad

6. Procesos inconsistentes.

7. Mala comunicación

8. Plazos poco realistas.

9. Mala (o nula) gestión de riesgos.

10. Apatía de los interesados