Su Entrenador de la EDT
por Josh Nankivel
Traducido por Ángel Águeda Barrero
Copyright © 2010 Josh Nankivel
Smashwords Edition
Todos
los derechos reservados. Ninguna parte de esta publicación puede ser
reproducida o transmitida en cualquier forma o por cualquier medio,
mecánico o electrónico, de fotocopia o grabación, o por cualquier
sistema de almacenamiento y recuperación, sin permiso por escrito de
la editorial, a excepción de breves citas en reseñas en
artículos.
Si bien se han hecho todos los intentos para verificar
la información proporcionada en esta publicación, el autor no asume
ninguna responsabilidad por errores, omisiones o interpretación
contraria de la materia en el mismo.
El editor quiere insistir en
que la información aquí contenida puede no estar de acuerdo con las
diferentes prácticas dentro de organizaciones específicas. El
material representa una práctica y proceso preferido del autor
basado en su experiencia profesional en diferentes organizaciones e
industrias.
El autor no asume ninguna responsabilidad u obligación
alguna por parte de cualquier cliente o lector de estos materiales.
Cualquier molestia a personas u organizaciones específicas no son
intencionadas.
~~~~~~~~~~
pmStudent
405 S 3rd Ave, Suite 100F
Sioux Falls, SD 57104
(605) 610-8055
~~~~~~~~~~
Para
Tamara, Mazaryk, Draven y Ryker
~~~~~~~~~~
Contenido
Introducción
Acerca de Josh Nankivel, BSc PM, PMP
Acerca de Ángel Águeda, PMP, PRINCE2, Scrum Manager
Capítulo 1 - ¿Qué es una EDT? ¿Qué no lo es?
Capítulo 2 – ¿Por qué necesito una EDT de todos modos?
Capítulo 3 - ¿Qué necesito antes de empezar?
Capítulo 4 - ¿Cómo estructuro mi EDT?
Capítulo 5 - ¿Qué herramientas puedo utilizar para mi EDT?
Capítulo 6 – En realidad, ¿cómo se crea una EDT?
Capítulo 7 - ¿Cómo utilizo mi EDT?
Capítulo 8 – Ejemplo de proyecto
Capítulo 9 – Errores habituales
Recursos
adicionales
Introducción
Gracias
por tú interés en una de las herramientas de gestión de proyectos
más importante, la Estructura de Desglose del Trabajo.
¿Por qué
formar en la Estructura de Desglose del Trabajo?
En mi carrera he
visto a muchos directores de proyecto y organizaciones trastabillar
en proyectos en los que se podía haber evitado con un uso adecuado
de la herramienta EDT. He creado “El entrenador de la EDT” para
ayudar a combatir este problema. Además de este documento, hay
vídeos formativos y grabaciones de audio disponibles, en inglés, en
el paquete de formación digital que puedes encontrar en
http://WBSCoach.com.
Los que hayan comprado este libro tienen un descuento en este curso
a través del código de descuento que aparece en la última página
de este documento.
He escrito este libro para el aspirante o el
nuevo director de proyecto, el director de proyecto accidental, que
puede no tener referencias sobre cómo abordar la dirección de
proyectos como una disciplina formal, y para el director de proyecto
experimentado que está buscando cómo mejorar su habilidad para
dirigir proyectos con éxito.
¿Por qué éste no es cómo otros
libros?
Otros libros de gestión de proyectos de tipo “cómo…”
se leen como libros de texto. Mi estilo de escritura incluye una
conversación directa contigo, el lector. Me imagino que tú y yo
estamos trabajando para la misma organización y que estamos sentados
juntos en una de nuestras mesas hablando sobre el tema. Puede ser
útil para ti imaginar este mismo escenario al leer el libro. Te
recomiendo empezar por el principio y leer los capítulos en orden.
No te saltes capítulos porque las lecciones se basan unas en
otras.
Puesto que has comprado este libro te voy a considerar mi
alumno por el momento. Como tal, te debes sentir libre para contactar
conmigo en josh@WBSCoach.com
con tus preguntas y opiniones. Pueden ser sobre este tema o sobre
gestión de proyectos en general. Te invito también a que veas mis
boletines gratuitos disponibles en http://pmStudent.com.
Hay varios para elegir y es posible que alguno de ellos se ajuste a
tu situación.
Me doy cuenta de que las personas aprenden y
asimilan la nueva información de diferentes maneras. Me he toma el
trabajo de organizar este libro para que tus notas adicionales no
sean necesarias. Al final del capítulo 6 hay una lista de
comprobación que puedes imprimir y utilizar al aplicar los conceptos
que abordaremos.
También he tratado de hacer fácil utilizar como
referencia este eBook cuándo lo necesites. Habrás notado que muchos
ficheros pdf tienen un desfase entre los números en el pie de página
y la página real del archivo. Si quieres ir a la página 112 y lo
indicas así en la barra de navegación terminas en la página 111 o
en la 115. En este eBook irás a la página correcta escribiendo el
número de página.
Además, puedes utilizar la barra de
herramientas de marcadores para navegar a través de los capítulos.
He estructurado este documento para que todos los capítulos y
subtítulos aparezcan como favoritos para que sea lo más fácil
posible navegar.
Mira la imagen en la página siguiente como un
ejemplo de lo que quiero decir. Es una captura de pantalla con el
programa Adobe Reader. He rodeado en verde los diversos modos en los
que puedes navegar por el documento. A mí me gusta especialmente
navegar a través del panel de marcadores. Puedes abrirlo haciendo
clic en el icono de la izquierda que parece una cinta marcador de
cinta sobre la página. También puedes utilizar el menú superior
haciendo clic en Vista >> Panel de
navegación >> Favoritos.
La siguiente sección
trata un poquito sobre mí. Utilízala como un modo de imaginar que
tú y yo estamos sentados en una mesa manteniendo una discusión. Es
importante para ti estar al tanto de mis antecedentes para que
podamos tener una buena conversación a lo largo de este libro. Te
ayudará a recordar las lecciones que he aprendido y los conceptos
que debatiremos.
Acerca de Josh Nankivel,
BSc PM, PMP
He estado gestionando
proyectos de TI y no TI en informática, servicios financieros,
telecomunicaciones y aeronáutica durante más de una década.
También he participado en proyectos como miembro del equipo a veces
con competencias técnicas (como desarrollador de base de datos) y
otras no, y también como patrocinador del proyecto. He trabajado en
proyectos gestionados en cascada, con Scrum y con varias mezclas
incluyendo algunos elementos de gestión de proyectos con cadena
crítica.
Un tema importante en mi carrera son los proyectos de
mejora de procesos. Mi pasión por los procesos me ha llevado a
liderar muchas iniciativas de organización y automatización de
procesos. Inicié una parte considerable de éstos como patrocinador
o simplemente como “ciudadano preocupado” queriendo hacer que las
cosas funcionasen mejor. Esa pasión también me hace evaluar
constantemente mis propios procesos de gestión de proyectos y
mejorarlos de manera continua.
Me encanta enseñar y, antes de
dirigir proyectos, he sido formador profesional durante varios años.
Mientras trabajaba para Gateway Computers obtuve varios premios y
certificaciones técnicas de formación interna antes de cambiar de
carrera hacia la gestión y gestión de proyectos. Mi formación
académica incluye un licenciatura en Gestión de proyectos y la
certificación como PMP®.
Me encanta escribir y hablar sobre
gestión de proyectos. Mi blog http://pmstudent.com/
tiene el objetivo de ayudar a los aspirantes y nuevos directores de
proyecto a aprender sobre gestión de proyectos y alcanzar sus metas
profesionales. Puedes encontrar mis publicaciones y entrevistas en
docenas de sitios y publicaciones impresas. Soy un ávido voluntario
en varias organizaciones de gestión de proyectos incluyendo el
Consejo de nuevos medios del PMI, ex-vicepresidente de proyectos
especiales de los estudiantes del grupo de interés específico de
gestión de proyectos del PMI. Hablo de vez en cuando, tanto en
grandes conferencias como en eventos locales sobre diversos temas de
gestión de proyectos.
Vivo en Sioux Falls, Dakota del Sur, en los
Estados Unidos de América con mi esposa y nuestros tres hijos. ¡Ah,
y también soy un geek de la ciencia y la tecnología!
¡Adelante!
Josh
Nankivel, PMP
Formador en buenas prácticas de dirección de
proyectos JoshNankivel@pmStudent.com
Acerca
de Ángel Águeda, PMP, PRINCE2, Scrum Manager
Desde
antes de finalizar mis estudios universitarios en informática estoy
haciendo proyectos de TI. Al principio, allá por 1989, pensaba que
el camino del éxito en los proyectos se encontraba en la
programación estructurada y por ello hice mi proyecto fin de carrera
en métodos con nombres que suenan ahora algo lejanos como Jackson y
Warnier. Fue un muy buen punto de partida que posteriormente me ha
servido para mantener el interés por todo lo que sonase a ingeniería
de software y formas de hacer mejor los proyectos.
Tuve además la
suerte de trabajar casi 12 años en una empresa donde esto se lo
tomaban muy en serio, Informática El Corte Inglés. Allí profundicé
en el uso de la programación estructurada haciendo y revisando
programas COBOL. Luego trabaje siguiendo MÉTRICA 2, vi cómo se
elaboraba MÉTRICA 3, hice mis pinitos con SPICE y dediqué un año
de mi vida a ISO 9001. Posteriormente llegaron los viajes, la vida
fuera de España y los proyectos internacionales en Argentina, Suiza,
Italia, Francia,… donde pude ver que los proyectos tienen las
mismas dificultades en todos los sitios e idiomas, y que las
personas, y su compromiso con sus compañeros, la calidad y el
proyecto, son siempre la clave del éxito.
Pero ha sido mi etapa
en Microsoft la que más me ha marcado como Director de proyectos. Ha
sido en esos años cuándo he obtenido mi certificación como PMP®,
he conocido otros enfoques de gestión de proyectos con Microsoft
Dynamics Sure Step y Microsoft Solution Framework (MSF) y dónde más
intensamente he vivido, sufrido y disfrutado, la realización de
proyectos en grandes organizaciones.
Pero ya antes de incorporarme
a Microsoft había decidido que mi carrera profesional iba a
transcurrir por los senderos de la dirección de proyectos. En 2006
empecé a escribir el blog Legnita Press ahora trasladado a
EvergreenPM. El blog me motivó a leer, estudiar y conocer a muchas
personas que con el tiempo se han desvirtualizado y convertido en
queridos compañeros en este camino que cómo free agent ahora
transito. Entre ellos Juan Palacio, Mario López de Ávila, Miguel
Santiago, Alfonso Bucero, Luis Carrasco, Albert Cubeles, Kay Ways,
Pablo Lledó, José Esterkin, Pablo Zarbo… y, por supuesto, Josh
Nankivel a quien estoy especialmente
agradecido por el gran trabajo que está realizando para divulgar y
apasionar en la disciplina de Dirección de proyectos, y por haberme
permitido traducir uno de los pocos libros que sobre Estructura de
Desglose de Trabajo se han escrito.
No quiero finalizar esta
presentación sin agradecer a María Jesús Jiménez y a Ricardo
Martínez su contribución imprescindible a esta traducción. Sin
ellos, ni hubiera sido posible ni el resultado final hubiera sido el
mismo. ¡Gracias!
Tampoco quiero olvidarme de los que más quiero
y soportan mis largas jornadas de trabajo y mis viajes. Mi mujer
Magüi y mis hijos Itziar y Luis. ¡Gracias por vuestro cariño y
apoyo! Desde Madrid, España, espero que disfrutéis y aprendáis con
este libro, casi seguro, el más entretenido y didáctico que sobre
este tema se ha escrito.
Ángel
Águeda Barrero, PMP®, PRINCE2®, Scrum Manager
Senior Project Manager Instructor
angel.agueda@evergreenpm.com
Capítulo
1 - ¿Qué es una EDT? ¿Qué no lo es?
Recuerdas
algún momento en el que tuvieras que hacer algo tan grande y
complejo que no supieras por dónde empezar?
Muchos proyectos son
exactamente así cuando empiezan. Sólo tienes una idea vaga de lo
que se supone ahora que tienes que producir y de lo que te supondrá
hacerlo. La Estructura de Desglose del Trabajo (EDT) es esencialmente
un tipo especial de esquema, uno que se utiliza para planificar y
ejecutar tu proyecto.
¿Has empezado a trabajar en algo y después
has tenido que cambiar tus planes repetidamente por todas las cosas
que habías olvidado que tenías que hacer?
Los cambios de alcance ocurrirán en tus proyectos y olvidarás planificar y realizar las actividades muy tarde. Una EDT ayuda a minimizar estos problemas y hace más fácil gestionarlos cuando ocurren.
Figura A – Ilustración
gráfica de la estructura de una EDT
La EDT
es un esquema
Es importante destacar que
la EDT es un esquema del trabajo que sólo pretende especificar el
QUÉ y no el CÓMO. Al igual que en cualquier esquema estándar hay
un nivel 1, nivel 2, nivel 3, etc. Cada nivel descompone el nivel
superior con más detalle.
La EDT debe centrarse en
los resultados (productos o servicios) y no en las tareas (cómo los
producirás / proporcionarás) ni en los recursos (personas y otros
recursos que hacen el trabajo). No te equivoques con tu EDT tratando
de especificar tareas individuales ya que hay otros pasos posteriores
dónde lo podrás hacer.
La EDT se compone
de un gráfico y un diccionario
Puedes
representar una EDT de muchas maneras, siempre que incluya estas dos
cosas:
Una descomposición
jerárquica que sea fácil de entender por las partes interesadas de
tu proyecto. Proporcione detalles suficientes para describir con
precisión los componentes de la EDT.
La mayoría de las
organizaciones utilizan una representación gráfica de las EDT que
son similares al organigrama de una organización. También he visto
las EDT en un formato de esquema y como mapa mental.
El
diccionario de la EDT es esencialmente una colección de
descripciones más detalladas de los elementos de la EDT. Es
necesario porque describir completamente un componente y
representarlo gráficamente de forma sencilla son dos objetivos
opuestos. Mediante el uso de un esquema numérico y un título breve
en el gráfico, y posteriormente proporcionando más detalle en un
diccionario de la EDT, obtienes los mejor de ambos mundos.
Yo
siempre incluyo la EDT y el diccionario de la EDT en el mismo
documento. Nunca hagas que tu equipo de proyecto y las partes
interesadas tengas que buscar la información. Si están mirando la
EDT, todo lo que tenga la EDT debe estar accesible fácilmente en el
mismo lugar.
Figura B – Gráfico y
diccionario de la EDT
La EDT define tu
proyecto
Si un producto o servicio no está
en tu EDT no forma parte de tu proyecto. Este esquema de tu proyecto
contiene el 100% de todo el alcance en cuestión. Todo lo que está
en tu EDT es una parte de tu proyecto. Por lo tanto, en cualquier
momento durante el proyecto debes ser capaz de mirar tu EDT como una
definición de todo el alcance de tu proyecto.
Cuando alguien
solicita un cambio en cualquier momento del proyecto (y lo harán),
tu primer paso es recuperar tu EDT y comprobar si realmente es un
cambio o no. El gráfico de la EDT es un modo rápido y fácil para
ayudar a las partes interesadas, patrocinador y equipo de proyecto a
entender qué y qué no es parte del alcance del proyecto. También
les ayudará a entender por qué tienes que parar y seguir un proceso
para ampliar el alcance (o reducirlo) y por qué no puedes
simplemente “encajarlo” una vez que el trabajo ha empezado.
No
olvides los servicios del proyecto cuando definas tu EDT. Éste debe
tener su propio componente en tu EDT. Incluso si es solo tu trabajo
como director de proyecto, es fundamental y debes incluirlo. Lo mismo
aplica para los servicios de soporte que el proyecto utilizará y se
relacionan directa o indirectamente con el producto que estás
creando. Puedes crear un componente de EDT en el nivel 2 que se llame
“Servicios del proyecto” y descomponerlo un poco más en el nivel
3.
Aquí tienes algunos ejemplos de servicios del proyecto.
Dependiendo del tamaño y complejidad de tu proyecto puedes no tener
todos o puedes tener que añadir alguno más:
Gestión del proyecto
Gestión de activos
Gestión de la configuración
Gestión de la calidad
Gestión documental
Administración del sistema
Copias de seguridad (Backups)
Seguridad
Asistencia
administrativa
La
EDT ayuda a todos a entender
Un gran
beneficio de la EDT (especialmente su versión gráfica) es que ayuda
a cualquiera que sea una parte interesada en el proyecto a compartir
un entendimiento común del alcance.
Cada persona está
interesada en una parte distinta de la EDT. Por ejemplo, tu director
general puede querer conocer sólo el alcance a alto nivel y quiere
conocer lo que vas a entregar desde una visión a 3.000 metros. Tu
desarrollador de software está sobre todo interesado en el nivel más
bajo. Él quiere saber exactamente qué código se espera que escriba
y qué funcionalidad debe entregar. Tu ingeniero puede “vivir”
entre ambos, siendo el responsable de la integración de diversos
componentes no le preocupan los detalles de menor importancia ni todo
el proyecto.
Además, puedes tener equipos independientes que se
preocupen de una rama en particular de la EDT, pero no tanto sobre el
resto. Si tus proyectos tienen 10 subsistemas que tienen que trabajar
juntos, al equipo encargado del desarrollo del subsistema 1 puede que
no le preocupe mucho el resto de subsistemas exceptuando las
integraciones con ellos. Puedes tener una de las partes interesada
para 4 subsistemas y otra parte interesada para el resto. Estas
partes interesadas se preocupan mucho en los informes de situación
de sus piezas en el proyecto, pero no prestan atención a lo
demás.
La EDT no es una lista de
tareas
Cuando empecé a dirigir proyectos
pequeños utilizaba una lista de tareas para planificar y recordar lo
que debíamos hacer. Esto no es una EDT ni es tan efectiva como una
EDT.
Una lista de tareas no
tiene niveles de descomposición que claramente muestren como las
piezas más pequeñas del alcance se juntarán y producirán el
producto final de tu proyecto. Con una lista de tareas:
Perderás
la visión sobre el alcance real de tu proyecto
No pensarás en las cosas que tienes que hacer hasta que las eches de menos, “ah, ¿cómo hemos podido olvidar eso?”
Perderás el resto de
beneficios que proporciona una verdadera EDT
El grado de rigor que
debes tener dependerá del tipo y tamaño de tu proyecto. He
gestionado proyectos que duraron solo unas pocas semanas y utilizado
una EDT en ellos. La EDT es menos compleja y más pequeña en
proyectos simples y puede ser muy grande y compleja en proyectos
grandes. La complejidad y tamaño de la EDT se correlaciona
directamente con tu(s) producto(s).
La EDT
no es un organigrama
Perry me miró
fijamente a los ojos. “¿Quieres decir que no puedo organizar mi
EDT de esta manera? Es mi EDT, ¡puedo hacer lo que quiera!”
“Muy
cierto Perry”, le dije. “Es tu EDT y puedes hacer lo que quieras.
Te estoy diciendo que organizar tu EDT artificialmente para alinearlo
con la estructura de tu organización, es un error. Te arrepentirás
más tarde.”
Perry decidió hacerlo a su manera. Yo sabía que
iba a descubrir trabajo que su equipo debía hacer y en el que no
había pensado. ¿Por qué?
En lugar de estar centrado en los
productos del proyecto, tal y como una EDT debe ser, él lo organizó
para una de las entradas y los recursos que debían hacer el trabajo.
Esto desvió la atención del proyecto a un único producto y dio
lugar a la omisión inesperada de alcance.
¡También puede llevar
a hinchar el alcance! Cuando intentas planificar un proyecto de esta
manera, el alcance puede derivar en lo que no es realmente una parte
del producto que estas produciendo y/o no es necesario para conseguir
los requisitos de tus entregables.
La EDT
no tiene fases
Al crear una EDT estarás
tentado a organizarla por fases. Durante el proceso de tormenta de
ideas que tendrás más adelante, encontrarás que es natural que las
personas piensen en el trabajo de forma secuencial. “Después de
que hagamos esto, el siguiente paso será…”
stá bien. Cuando
construimos una EDT encuentro natural tender a seguir una línea
cronológica ordenada de izquierda a derecha, lo que es muy práctico
ya que el esquema de numeración probablemente vaya también de
izquierda a derecha.
Algunas personas dicen que es correcto
organizar tu EDT siguiendo las fases de tu proyecto. De hecho,
incluso en la 4ª edición del PMBOK hay un gráfico ilustrando de
una EDT que utiliza fases en el segundo nivel de organización. Estoy
totalmente en desacuerdo con esta aproximación.
He visto como este tipo de planificación de proyectos puede llevar a
asunciones no declaradas y a olvidos en el alcance en tu EDT. De
nuevo, te debes centrar sólo en el producto que tu proyecto va
entregar para así obtener todo el alcance de la forma más completa
posible.
Hay una diferencia entre organizar tu EDT por fases y que
tenga una cronología general. Por ejemplo, el sistema A puede tener
que desarrollarse antes que el sistema B pueda iniciarse, por lo
tanto los componentes de nivel 2 de tu EDT podrían ser el “sistema
A” y el “sistema B” ordenados de izquierda a derecha. Eso está
bien.
Si pones el “sistema B” antes del “sistema A”
también es correcto. Puede ser más conveniente que el “sistema A”
sea tu componente 2.0 y el “sistema B” sea el componente 3.0 sólo
por estética, pero no es necesario.
Lo que no es correcto es
organizar tu EDT por “Fase 1” y “Fase 2”. Las fases no son
entregables o servicios, son períodos de tiempo.