¿Actualiza su documento de estructura de desglose del trabajo una vez que se han definido los requisitos?

Creo que hay una falta de coincidencia de marcos aquí, y no creo que la pregunta pueda responderse con autoridad a menos que se aclaren los marcos. Mi discusión a continuación es muy explícita para no desafiar o discutir con OP. La forma en que administra proyectos es la forma en que administra proyectos y debe juzgarse solo por la eficacia con la que le permite cerrar proyectos. Dicho esto, si escribo y hay suposiciones contradictorias, la única forma de responder a la pregunta es articular mis suposiciones y luego separar dónde difieren las metodologías.

(Aparte: sospecho que la respuesta es que, como muchos procesos de PMI, existe un diálogo continuo entre los grupos de procesos. La razón por la que la planificación es difícil es que la creación de la EDT puede resaltar la necesidad de una mayor claridad y precisión en los requisitos. Eso la aclaración puede entonces forzar una revisión de la EDT, pero esto tiene que ocurrir en el contexto de la gestión del cambio).

OP escribe:

Al escribir "WBS" me refiero a un documento similar a la estructura de una organización que enumera los entregables, los paquetes de trabajo (y no la columna "Nombre de la tarea" en MS Project). Por lo general, esto se usa para inicializar el trabajo antes de definir los requisitos durante la fase de análisis.

En la metodología de gestión de proyectos, los requisitos se descomponen en una EDT; esto asegura que el 100% del trabajo esté planificado y estimado. El trabajo no se inicializa hasta que se completa la planificación y la planificación se basa en los requisitos.

Ver los grupos de Procesos del PMI ; la creación de la WBS ocurre muy temprano en la fase de planificación y antes de la fase de ejecución.

Al iniciar el proyecto, el gerente del proyecto debe comprender las razones por las que se inició el proyecto, definir los objetivos que logrará el proyecto y las métricas que se utilizarán para medir su éxito. Estos se denominan "Requisitos comerciales", que describen las necesidades de la organización en su conjunto (no de los grupos o partes interesadas dentro de ella) y el valor comercial que el proyecto debe ofrecer. La identificación adecuada de estos requisitos le dará al proyecto el comienzo correcto. biblioteca PMI

Si la WBS va a representar todo el trabajo requerido para llevar a cabo el proyecto, entonces la WBS debe basarse en/derivarse de los requisitos. Si crea la EDT antes de crear los requisitos, no hay forma de asegurarse de que la EDT incluya todo el trabajo. No sé identificar los entregables si no conozco los requisitos; debe haber trazabilidad desde cada paquete de trabajo y cada entrega hasta un requisito. OP claramente sigue una metodología diferente con una trazabilidad diferente, pero no me queda muy claro cómo se relaciona eso con el marco de PMI.

Basado en este desajuste de marco, nada de lo que he aprendido sobre la gestión de proyectos me permitiría ofrecer algún consejo útil sobre una metodología en la que la WBS precede a los requisitos.

Traté de dar una respuesta concisa (me cuesta ser concisa y fallo con frecuencia). Necesito más tiempo para abordar el comentario capturado a continuación; Creo que esta es una observación muy importante, pero actualmente creo que es tangencial al desajuste de marco entre la pregunta de OP y mi respuesta. Creo que las suposiciones de OP sobre el orden de los requisitos y la WBS son diferentes de mi comprensión de la metodología de gestión de proyectos.

¿No es el trabajo capturar y desarrollar los requisitos, que podrían incluir diseños de ingeniería, dibujos de arquitectura e incluso productos preliminares de prueba de concepto? Espero que se pueda desarrollar una EDT muy detallada para ese trabajo con algunos elementos de nivel superior de la EDT y paquetes de planificación para el trabajo restante. @davidespina

Para responder a este comentario voy a tener que discutir el proceso de iniciación del proyecto. Eso corre el riesgo de ser argumentativo. Mi respuesta anterior simplemente establece que OP y yo ordenamos los dos procesos de manera diferente, y que las suposiciones diferentes dificultan responder a la pregunta: resalta el desafío del marco para un análisis posterior. Para responder al comentario, necesito discutir lo que percibo como el proceso de iniciación del proyecto "ortodoxo", que podría parecer criticar el proceso de OP.

Esto se complica aún más por el hecho de que, en mi opinión, el inicio del proyecto es una de las fallas críticas del modelo moderno de gestión de proyectos. Me encantaría que alguien me corrigiera/educara; Estaría muy feliz de estar equivocado.

Una gran cantidad de los procesos de iniciación normalmente se realizan fuera del alcance de control del proyecto por parte de los procesos de la organización, el programa o la cartera y esos procesos proporcionan información al grupo de procesos de iniciación del proyecto. pmi.org

El modelo del proyecto PMI es un poco como la discusión física del universo antes del Big Bang, lo único autorizado que se puede decir es "Eso está fuera del modelo", que es una declaración formal de que luego ocurre un milagro .

En una de mis PMO anteriores, definimos cinco productos/procesos analíticos diferentes que debían completarse antes del inicio del proyecto. El acta de constitución del proyecto tenía que estar respaldada por un caso de negocios que tenía que estar respaldado por un modelo de costo formal, que tenía que estar respaldado por una regresión infinita de tortugas , cada una de las cuales tenía que estar firmada por CxO. Empecé a sospechar por qué > 50 % de las PMO fallan en un año. El nuestro lo hizo. Descubrir cómo explicar eso claramente no es importante para responder la pregunta fundamental de OP. La respuesta a eso es "Construir la WBS antes de los requisitos es un enfoque novedoso, y nada en la metodología del PMI es útil".

Pensaré en esto un poco más y trataré de volver y ser sucinto y receptivo.

A través de un proceso de gestión de cambios, la WBS y otros artefactos de referencia de gestión del rendimiento pueden cambiar cuando se produce un cambio. Si bien muchos parecen implicar que el cambio no ocurre si no está haciendo Agile, el cambio ocurre utilizando otros métodos de entrega. Muchos vendedores de servicios desarrollarían su WBS antes de comenzar el trabajo y el trabajo puede incluir trabajo adicional sobre los requisitos para llegar a una línea de base de requisitos; puede llamarlo final o lo que sea, pero la línea de base puede cambiar. Si los requisitos cambian o evolucionan de manera significativa, entonces puede conducir a un cambio en la WBS y otros PMB en consecuencia. Si su proceso de cambio hace parecer que tal cambio es demasiado arduo, entonces su proceso de cambio está roto.

Con respecto a PBS versus WBS, le aconsejo que elimine PBS de su repertorio de PM. Puede establecer una WBS orientada al producto, tener un solo artefacto de proyecto, actualizar solo un solo artefacto y no preocuparse por garantizar que los dos productos coincidan y se asignen.

Para mí, una "estructura de desglose del trabajo" es: "planos de la casa". En otras palabras, "no te atrevas a intentar construir una casa sin ellos". Los documentos WBS que se establecen antes de que se hayan "finalizado" los requisitos son, en el mejor de los casos, documentos de trabajo... y, adivinen qué, la palabra "finalizado" siempre puede ser maleable. Así que va. Pero, la WBS debe ser una luz de guía.

La "estructura de desglose del trabajo" intenta diseñar al menos una estrategia de alto nivel sobre lo que se debe hacer, en qué orden y qué miembros/habilidades involucran tanto dentro como fuera del equipo. En mi opinión, debe mantenerse constantemente actualizado y compararse cuidadosamente con el progreso real (o la falta del mismo). "Por supuesto que no puedes hacerlo bien la primera vez", pero los cambios pueden ser muy instructivos. Mantenga todo actualizado, incluso mientras observa "lo que hizo bien y lo que no".

Todo esto, incluidas específicamente todas las revisiones (!) y la cronología completa de las mismas , debe convertirse en parte de la historia permanente del proyecto, y debe revisarlo cuidadosamente ex post facto en busca de "lecciones aprendidas".

Especialmente (!) en proyectos de software de computadora, es muy fácil para los trabajadores "encontrarse rodeados de árboles", de modo que se pregunten: "¿En qué bosque estoy, de todos modos? Lo olvidé". Hay tantos detalles, todos los cuales deben ser atendidos técnicamente, que "el 'desglose del trabajo' total" se pierde. Por lo tanto, este documento puede ser "el hilo delgado" que lo guíe de regreso a casa.

Es posible que los desarrolladores de "lobos solitarios" que se han acostumbrado a "sumergir y hacerlo" necesiten que se les muestren los méritos de: "mirar antes de saltar". Tales cosas no siempre les salen naturalmente.

Por lo tanto: revise la EDT inmediatamente después de que se autorice el proyecto, luego manténgala actualizada y use la tecnología de control de versiones para preservar todas y cada una de las versiones . ("Idem" todos los documentos de requisitos.) Que siempre sea la representación más precisa de: "The Big[gest] Picture.™" Y conserve cuidadosamente su historia en curso.

Si usa una WBS, espero que la actualice con la mayor frecuencia posible.

No mencionaste qué tipo de trabajo es. Si el contexto es el desarrollo de software, una EDT no suele ser una buena idea. Los equipos de desarrollo de software suelen trabajar mejor con un enfoque basado en PBS o Product Backlog en lugar de WBS. Además, los requisitos no se pueden considerar "definitivos" hasta que decida dejar de usar el producto de software.