El documento describe la Estructura de Desglose de Trabajo (WBS), una herramienta útil para organizar y documentar proyectos de TI. El WBS divide un proyecto en paquetes de trabajo más pequeños de forma jerárquica para definir de manera clara los objetivos, alcances y entregables de la documentación. El uso de un WBS puede ayudar a mitigar problemas comunes en la documentación de proyectos de TI como objetivos poco claros, alcances indefinidos, desorden en la generación de documentos y falta de consistencia.

1. WBS, herramienta práctica para presentar la documentación de un
proyecto de TI
Cristina Múzquiz Fragoso

2. Normalmente, una de las causas es que los gerentes de proyecto no otorgan la importancia
necesaria tanto para su administración y control, mediante un repositorio y buenas prácticas, como
para asegurar un buen producto. Una opción práctica para llevar a cabo el proceso de
documentación es mediante una herramienta llamada WBS.
Algunos de los problemas comunes de la documentación de un proyecto de tecnologías de
información (TI) se derivan de los siguientes escenarios:
1. Es poco claro el objetivo específico de la documentación.
2. Se definió como entregable al cliente, pero no se acotaron sus alcances.
3. Careció de un orden claro en su generación, lo que se refleja en documentación duplicada
o insuficiente.
4. La tarea de documentar se delegó a un “documentador”, con poco o nulo conocimiento del
desarrollo del proyecto de TI que se está documentando.
5. Falta de consistencia, con procesos altamente documentados y otros con nula o poca
documentación.
Lo anterior, suele traer como consecuencia que la documentación, evidentemente, sea poca y
pobre, por lo cual no se aprovecha ni percibe como un producto de valor, y en muchos casos,
aunque presente un contenido completo y detallado. Por lo general, los usuarios no acceden a ella
porque se ignora cuál de todos los documentos tiene lo que requieren; es como buscar una
dirección en una guía roji, pero sin claves ni orden.
Para mitigar la probabilidad de ocurrencia de estos problemas, se puede emplear un WBS (Work
Breakdown Structure, es decir, estructura desglosada del trabajo), herramienta para definir el
trabajo de manera jerárquica, que describe los entregables y tareas que deben realizarse para un
proyecto dado. Para el WBS, se hace una de descomposición de tareas, mientras para su
representación gráfica se utiliza un diagrama tipo organigrama, pero en lugar de roles, se
esquematizan paquetes de trabajo. Hacerlo, implica tener lápiz y papel o, Power Point o, un
software para hacer diagramas como por ejemplo, Visio.
Cada caja es un “paquete de trabajo”, es decir, un grupo de actividades en común.
Mismos niveles y paquetes de trabajo que en el WBS
Es importante mencionar que el WBS es un proceso de pensamiento, mediante el cual se pretende
organizar el proyecto; en primera instancia, se requieren organizar las ideas de lo que se pretende
hacer y las metas que se desean cumplir. Para iniciar un WBS, se tienen que definir las grandes

3. áreas de trabajo en que puede ser dividido el proyecto, lo que constituirá los paquetes de trabajo a
desarrollar para lograr la meta. Posteriormente, cada uno de esos paquetes de trabajo se debe
dividir en otros más pequeños hasta lograr el desglose necesario. El nivel de desglose requerido
por el proyecto, estará determinado en función de la complejidad y tamaño del proyecto. Se
recomienda que los paquetes de trabajo, en cualquier nivel, sean independientes unos de otros y
que se refleje un producto o servicio tangible, para poder medir los avances reales.
Con esta representación se tendrá un entendimiento claro de los conceptos, sin necesidad de
explicar complicadas teorías. Aunque su representación gráfica es sencilla, la realidad es que el
poner de acuerdo a todo el grupo de trabajo es un proceso complejo, pero brinda la oportunidad de
lograr un mayor grado de integración, además de tener beneficios durante el desarrollo del proyecto
de TI y, por ende, en su documentación.
Para muchos, el WBS es una herramienta tan sencilla, aparentemente, que se menosprecia su
elaboración y prefieren ir directamente a la obtención de los estimados de costo y tiempo,
frecuentemente, con estructuras diferentes que lo único que garantizan son confusión y conflictos.
Partiendo del supuesto que se tiene de un WBS como un producto de la planeación del proyecto,
veamos cuál es su utilidad en la documentación de un proyecto en TI, para contrarrestar las causas
usuales de problemas en la documentación.
1. Es poco claro el objetivo específico de la documentación. Regularmente, en un proyecto
se consideran los documentos de análisis, diseño, desarrollo y manuales de usuario y
técnicos. Pero cuando el proyecto de TI es más complejo, con varios subproyectos como,
por ejemplo, la prestación de un servicio con varios sistemas, puesta a punto de sitios de
operación, capacitación y soporte, entre otros, se deberá especificar y acordar claramente
cuál es el objetivo de la documentación entregada al cliente. Al desarrollar el WBS del
proyecto, se deben definir por cada paquete de trabajo sus objetivos con respecto a la
documentación, de manera que éstos deberán estar alineados con el objetivo general del
proyecto.
2. Se definió como entregable al cliente, pero no se acotaron sus alcances. Se recomienda
que desde el contrato, convenio o cotización se definan cuáles serán los documentos que
se realizarán, y así brindar una breve descripción de cada uno de ellos. En forma ideal, se
sugiere considerar características objetivas para que el cliente pueda verificar que la
documentación cumple con lo establecido. En el WBS se deberán de plasmar los esfuerzos
en tiempo y costo para cumplir con el alcance acordado, y los entregables específicos que
se desean tener en este rubro.
3. Careció de un orden claro en su generación, lo que se refleja en documentación duplicada
o insuficiente. El WBS no deberá ser sólo una gráfica obtenida al inicio del proyecto para
generar un documento de planeación; el WBS tendrá que ser un eje en la forma de trabajo
durante todo el proyecto. De esta forma, el plan de trabajo también tendrá que estar
alineado con el WBS, y manejar los mismos niveles de agrupación de trabajo.
Mismos niveles y paquetes de trabajo que en el WBS

4. Posteriormente, con base en el objetivo y alcances de la documentación, se sugiere hacer una
matriz, como la siguiente:
Donde se consideren sólo los paquetes de trabajo que nos interesan y se acordaron documentar.
De esta forma, se puede tener una visión clara, sobre el avance y las debilidades en la
documentación. Cuando se continúa con un proyecto de TI, anteriormente desarrollado por otras
personas, esta matriz también suele ser muy útil, para identificar las ausencias de documentación.
4. La importante tarea de documentar se delegó a un “documentador” que tiene poco o nulo
conocimiento del desarrollo del proyecto de TI documentado. Este problema suele agudizarse
cuando es un proyecto de TI complejo, porque el documentador suele ser alguien que no participa
en el desarrollo de las actividades. Con apoyo del WBS se identifica y sensibiliza más a los
colaboradores de la importancia de que ellos sean los que intervengan directamente en la
documentación del proyecto, por su conocimiento profundo de los procesos. Además, este
escenario tiene el valor de que el líder del proyecto puede planear mejor las horas de trabajo
requeridas.
5. Falta de consistencia, con procesos altamente documentados y otros con nula o poca
documentación. Con apoyo del WBS y su relación directa con la documentación de cada “paquete
de trabajo” se puede lograr un mayor equilibrio, porque se identifican cuáles son las áreas que
presentan poca o nula documentación y, por lo tanto, serán las que requieren de mayor apoyo.

5. Presentación de la documentación
Se sugiere un índice general, con objeto de localizar fácilmente los documentos; incluso, se puede
utilizar el mismo WBS como un índice, donde cada paquete de trabajo (cajita), sea un hipervínculo
a un documento.
El WBS es una herramienta tecnológica que ayuda en gran manera para hacer las cosas con orden
y como diría Pitágoras “Con orden y tiempo se encuentra el secreto de hacerlo todo, y de hacerlo
bien”. De esta forma, podremos tener no sólo documentos aislados, sino una estructura sólida de
documentación, con mayores probabilidades de proporcionar un valor agregado al proyecto.
http://www.enterate.unam.mx/Articulos/2007/enero/wbs.htm

6. Se basa en una estructura jerárquica que divide a nuestro proyecto en pequeñas partes, las cuales
llamaremos entregables, e intentaremos que sean componentes de un tamaño lo suficientemente
pequeños, manejables, estimables y controlables. Es por esto último, que
un entregable se podría definir como cualquier producto, resultado o servicios que se tenga que
construir en una fase o proceso de un proyecto, el cual tiene que ser único y tangible (verificable)
por parte del interesado. En esta estructura se define el alcance total del proyecto y todo lo que
en ella aparece tiene que hacerse, y por lo tanto, todo lo que no figure, ni se detalle, no se realizará.
El siguiente es un ejemplo de una WBS para mostrar cómo sería el armado de un concierto de rock,
y como yo no soy un experto en el tema conciertos, seguramente este muy incompleta, pero
tengámosla en cuenta a fin didáctico.
Tal como vemos, y dejemos esto como primera enseñanza, es fundamental para el armado de
la WBS, que la tarea involucre a todo el equipo de trabajo y no solamente del líder de proyectos, ya
que como en este caso, el líder de proyectos no necesariamente es un especialista en el tema.
Esta herramienta nos intenta enseñar que la mejor manera de minimizar los riesgos, la incertidumbre
y entender los costos basados en la dimensión del proyecto, es tomar partes pequeñas del mismo.
Esto se basa en el famoso "Divide y reinaras". No es lo mismo decir cuánto uno tardará y gastará en
armar todo el casamiento como en la pregunta inicial, que ir sumando las sumas de sus partes. El
nivel de detalle que esta herramienta tiene que ser decidido por cada líder de proyecto, en función a
la información que el desea obtener. Igualmente nuestra recomendación es que dependiendo de la
etapa del proyecto en que se encuentre (inicio, planificación, desarrollo, etc.), ir explotando el detalle
de los componentes, siempre en forma de entregables tal y como los definimos.
Más allá de esto último, también nos trae otros beneficios, los cuales podríamos nombrar:

7. 1. El máximo interesado en que el proyecto se realice (Sponsor) vea de forma rápida y
gráfica un alcance de lo que se va a realizar, y por ende, que lo pueda validar, que entiende
lo que hay que hacer y de que forma.
2. Poder minimizar el riesgo de equivocarse en la estimación inicial. Poseer
componentes muy grandes dentro de la WBS será propenso a una estimación errónea. Es
por esto que buscamos tener un nivel de detalle que nos permita realizar de una forma
más fácil esta tarea, estimando cada una de las pequeñas partes, teniendo como resultado
el total de lo que se quiere construir.
3. Controlar a medida que se va avanzando el proyecto, que se van generando los
entregables prometidos, y por tal razón, el avance del mismo. Recordemos que
la WBS orientada a entregables permite la validación tangible de completitud.
4. Permite la identificación de recursos y puestos necesarios para cumplir con el
entregable prometido (Ejemplo para el concierto de rock: iluminador, jefe de seguridad,
sonidista, etc.)
5. A partir de la WBS poder formalizar un calendario de trabajo basándonos en lo que
hay que realizar y sus tiempos.
Es importante aclarar algunas cuestiones. Primero esta WBS no está completa, ya que le falta
su diccionario, el cual detalla de forma más extensa y precisa, cada uno de los componentes
involucrados, incorporando además, el tiempo estimado, el costo, los recursos necesarios, las tareas
y todo lo que el líder de proyecto requiera necesario para su entendimiento. En el ejemplo del
concierto de Rock el componente pirotecnia o luces puede traer confusión ya que no se aclara si es
la adquisición la instalación el control o todo esto junto. Aquí la importancia del diccionario de la
misma, luego de una primera visión general hay que ir al detalle, así todo integrante del proyecto,
sabe de forma fehaciente y sin dobles interpretaciones, que es lo que incluye el componente.
Además quiero aclarar, la explicación del componente Gerenciamiento, el cual se refiere a todas
las horas que el líder de proyectos va a participar en el desarrollo del proyecto. Esta tarea es global
a cada uno de los entregables, pero como las mismas existen y tienen incidencia en el costo total,
hay que imputarlo al proyecto.
Finalmente, si bien la WBS es una herramienta visual, impulsada por las metodologías adaptativas
como ser las que se encuentran en el PMBOK, tenemos que tener en cuenta cuál es el verdadero
valor en si misma, sin necesidad de utilizarla. Hay muchas otras metodologías que ni siquiera la
usan, pero si vemos debajo de la alfombra, podemos detectar que los conceptos que ella nos deja,
igualmente se aplican al pie de la letra y por lo tanto es importante entender su legado, mas allá que
su enseñanza en sí.
http://blog.qualytz.com/2013/03/arrancando-con-proyectos-la-importancia.html