¿Cuál es el enfoque correcto para el tamaño del paquete de trabajo?

Realmente recomiendo usar una WBS solo para lo que desea resumir e informar. En muchos casos, solo necesita unos pocos (¿3?) niveles en una WBS para capturar cosas como centros de presupuesto o departamentos funcionales. He sido parte de los intentos de definir 9 niveles en una WBS donde el nivel 9 tenía las categorías "diseño, implementación, prueba, documentación, reelaboración, etc". La sensación era que en algún momento después de terminar el proyecto, simplemente podía agregar todos los elementos de diseño para obtener un "costo de diseño" del producto. Estos nunca funcionaron. Su utilidad tendía a estar relacionada con el tamaño de los proyectos (a los proyectos más grandes les gustaría más esto, los proyectos más pequeños pueden obtener lo mismo sin él). Pero los proyectos más grandes tienden a reorganizarse y volver a establecer la línea de base, por lo que comienza a recibir cosas extrañas como "no cuente la línea de base 6 en los totales".

Para resolver su problema de "mantenerse al tanto de los subproyectos", siempre pido hitos de su cronograma. Entonces, un subproyecto podría tener un "prototipo de transmisión disponible" sobre el que quiero saber. Entonces, pido informar sobre ese hito. A medida que el "prototipo de transmisión" entra y sale con el cronograma, puedo verlo en el hito. Por lo general, pedía algunos hitos cada mes para cada subproyecto, y no dudaba en consultar el plan o los detalles del proyecto cada vez que me aburría.

Por supuesto, aprendí en mi vejez que la mejor manera de abordar un proyecto de tamaño mediano es trabajar como diablos para descomponerlo en pequeños proyectos que se pueden "terminar" y desarrollar iterativamente/incrementalmente.

hth

No hay una respuesta correcta para la descomposición WBS. Lo que funcionó para un PM en un compromiso similar podría ser desastroso para otro en el próximo compromiso.

Usted descompone su WBS al nivel en el que puede administrar el proyecto. Esta es una de esas cosas en las que sabes que tienes razón cuando la ves. También necesita escuchar su intuición sobre esto. Todos abordamos la gestión de una manera diferente. Una talla no sirve para todos.

Hay compensaciones. Un nivel demasiado alto, la carga administrativa para gestionarlo es menor en términos de costo. Sin embargo, pierde la percepción de lo que está sucediendo en el trabajo y de comprender dónde se están acumulando las variaciones y por qué. Esta falta de conocimiento aumenta el riesgo de tener una capacidad exitosa para mitigar esas variaciones. Disminuye su capacidad para volver a planificar la secuencia del trabajo si tiene que corregir una variación del horario. Y si su WBS está orientada a la entrega, tiene menos capacidad para controlar el avance del alcance con una WBS de mayor nivel.

Un nivel demasiado bajo, todos los riesgos anteriores se reducen o desaparecen, pero los costos de administración se dispararán. Dedicará más esfuerzo a analizar la WBS y el cronograma que a administrar el esfuerzo general. Para cada proyecto y para cada gestor, existe un equilibrio entre estos dos puntos. Tienes que encontrar eso por ti mismo.

Cuando oigo hablar de un director de proyecto que gestiona a directores de proyecto, el "director de proyecto", me hace pensar más en la línea de la gestión de programas que en la gestión de proyectos. Si bien las habilidades son muy similares, parece que está en una posición en la que necesita concentrarse en conceptos de nivel superior, similar a un administrador de programas.

La gestión de programas existe porque las empresas se dieron cuenta de que a veces se necesitaba una fuerza impulsora para impulsar proyectos separados pero complementarios hacia el mismo objetivo de alto nivel.

Los administradores de programas están menos preocupados por los detalles de las tareas individuales y están más centrados en el objetivo estratégico. Como resultado, sus carteras de proyectos contendrán información de muy alto nivel sobre cada proyecto.

Además, existe un fenómeno en el que los aumentos en la cantidad de información disponible son inversamente proporcionales a la capacidad de procesar realmente esa información. En otras palabras, cuantas más tareas intente realizar un seguimiento, peor lo hará para mantenerse al día con el progreso de esas tareas. Después de todo, es por eso que tiene gerentes de proyecto trabajando con usted, para que puedan preocuparse por los detalles mientras usted se preocupa por el panorama general.

Concéntrese en el panorama general, confíe en sus gerentes de proyecto y mida el éxito de la cartera de proyectos desde un alto nivel, y descubrirá que puede concentrarse mejor en sus responsabilidades de alinear las metas de cada proyecto individual con el objetivos de todo el programa.

Realmente depende de la duración del proyecto. Para propósitos de informes, he visto la regla general de que los elementos de la EDT de nivel más bajo no deben abarcar más del 10 % de la duración estimada del proyecto. Y también vio que ningún elemento debe abarcar más que su período de informe (tiempo entre informes de estado).

Como se mencionó anteriormente, también debe sopesar la carga administrativa. Deje el seguimiento del 'guijarro de una pulgada' a los gerentes de proyecto, oa las personas que realmente están haciendo el trabajo. Permítales incluirlo en sus informes de estado.

En su caso, dado que está realizando un seguimiento de varios proyectos, debería centrarse realmente en los entregables y no en tareas discretas. Pero nuevamente, depende completamente de usted cómo desea rastrear las cosas.

Una cosa a tener en cuenta, la WBS debe ser una herramienta para que sus equipos descompongan su trabajo. Permítales ser tan granulares como quieran si les ayuda a descubrir qué se debe hacer. Luego, simplemente enróllelo hasta el nivel adecuado para los informes de estado.