¿Cuál es la mejor manera de desarrollar una línea de base del proyecto?

Creo que está confundiendo dos cosas separadas aquí: línea de base y programación.

Creo que una línea de base es una instantánea de un plan de proyecto en un momento específico con el que puede comparar planes futuros para evaluar la desviación del plan.

Esto es cierto ya sea que cargue la programación de su proyecto por adelantado, la cargue de nuevo o algo intermedio.

¿Parece que está intentando crear algún tipo de plantilla genérica para el proyecto que pueda reutilizarse en el futuro? Eso no es una línea de base.

¿Quizás tienes dos objetivos aquí? 1) Programe el proyecto de hoy para entregar el resultado de la manera más eficiente posible 2) construya una plantilla de programación de proyecto reutilizable

Como ha señalado, estos objetivos pueden entrar en conflicto. Lo que es un buen cronograma para este proyecto puede no serlo para un proyecto futuro similar. Si fuera yo, me concentraría en entregar el proyecto de hoy de la manera más eficiente posible y definitivamente adelantaría el cronograma para hacer todo lo posible antes de encontrarte con los inconvenientes inevitables.

Luego, aprendería de eso para crear una plantilla que sea lo más flexible posible y, al mismo tiempo, conservar la mayor cantidad posible de eficiencias básicas sin volverse poco práctico para proyectos futuros. Probablemente haría lo suyo tratando de mantener los bloques de actividades del proyecto en un nivel bastante abstracto y no atascarme demasiado en tareas granulares. A partir de ahí, puede construir una visión de cuál es el contorno de recursos más eficiente para proyectos similares y luego asignar los recursos adecuados para los proyectos futuros cuando sea posible. O vuelva a planificar la plantilla de resumen según corresponda para el recurso disponible en ese momento.

Siempre va a haber una compensación entre la reutilización del plan frente a la flexibilidad del grupo de recursos.

No controlas tu flotador de esa manera. Float es el resultado de los valores de planificación que elige por paquete de trabajo y la lógica de la red que crea en función de las dependencias de tareas y recursos. Los paquetes se programan según esa lógica y sus valores de planificación de duración. Anular eso arbitrariamente tratando de programar tarde o temprano es simplemente cambiar la duración de sus paquetes, creando así nuevos valores de inicio temprano y tardío.

No hay dos proyectos iguales, no importa cuán similar parezca el proyecto. Puede tener una plantilla inicial, pero no debe tener una política que exija que el PM de un nuevo proyecto se ciña de alguna manera a esa plantilla con poco o ningún cambio. Esa es una receta para el desastre. En su lugar, debe evaluar la condición de riesgo de cada proyecto: su entorno, su cliente, problemas legales, problemas de trabajo, problemas de personal como la disponibilidad, si está compitiendo por el trabajo, y así sucesivamente, que en última instancia dictarán el valores de planificación que utilice.

Esta postura de riesgo del nuevo proyecto también dicta los valores de planificación con los que se termina. Por ejemplo, si su proyecto es de alto riesgo, sería prudente elegir valores de planificación en el lado derecho de la distribución estimada; viceversa, si su postura de riesgo es baja.

Existe un método para crear holgura e integrarla en su proyecto. Creo que esto se llama Gestión de Proyectos de Cadena Crítica. Este método requiere reducir los valores de planificación a la mitad y luego usar el saldo como holgura en algún lugar de su programa. Eso es prácticamente todo lo que sé sobre este método y podría estar equivocado. Buscalo en Google. Es muy interesante.

Supongo que ha trabajado con su equipo para generar estimaciones de cuánto tiempo llevará producir cada entregable. Además, asumo que le han dado un escenario de caso más probable y una estimación del peor de los casos para cada uno.

Tome el escenario de caso más probable y cree su horario. Revise esto con su equipo en comparación con el cronograma maestro de recursos y confirme que tiene el equipo disponible para lograr este cronograma. Si una parte suficiente del equipo NO está disponible, tendrá que ajustar su horario para tener en cuenta esto, o sacar a los miembros del equipo de otros proyectos a favor de su proyecto, o introducir en su plan actividades para conseguir nuevas contrataciones y capacitarlas.

Una vez que haya alineado el cronograma de su caso más probable con la disponibilidad del equipo, haga lo mismo para el peor de los casos. El propósito de hacer esto es permitirle informar a sus patrocinadores un rango de fechas para la finalización del proyecto. Esto realmente lo ayudará a largo plazo en términos de manejo de expectativas.

Finalmente, ejecute el cronograma más allá de su equipo y obtenga su aceptación. Documente que están de acuerdo en que el cronograma es razonable y alcanzable, lo ideal es que lo aprueben formalmente. Distribuya el horario y listo.

En respuesta a sus opciones específicas:

1. Programe todas las tareas "lo más tarde posible" dejando todo el flotador al frente del proyecto. Esto supondría recursos infinitos.

Probablemente no sea una buena idea porque la gente tenderá a posponer las cosas hasta el último momento posible. También las cosas malas suelen ocurrir en el último momento. El uso de "lo más tarde posible" para la programación plantea un riesgo significativo para el proyecto al no permitir la entrega tardía.

Y asumir recursos infinitos es una suposición muy mala.

2. Programe todas las tareas "tan pronto como sea posible" dejando flotar al final del proyecto. También suponiendo recursos infinitos.

Mejor que el n.° 1, pero tendería a asociar el búfer con entregables particulares para que cuando haya traspasos internos, el equipo receptor sepa que es posible un rango de fechas. Por ejemplo, el equipo de desarrollo debe tener en cuenta que la recopilación de requisitos y la documentación deben estar completas en la fecha XX, pero podrían demorarse hasta 5 días.

Nuevamente, asumir recursos infinitos no es bueno.

3. Programe cada nuevo proyecto de acuerdo con un programa maestro de recursos. Esto significaría que cualquier proyecto idéntico futuro tendría potencialmente una línea de base diferente a la anterior.

Por definición, un proyecto es una empresa única. Incluso si es "cortador de galletas", tendrá diferentes líneas de base. Por ejemplo, un proyecto en los EE. UU. que tarda 3 meses en completarse si empiezo en septiembre probablemente llevará más tiempo si empiezo en noviembre (la gente está fuera durante la temporada de vacaciones) o en junio (temporada de vacaciones de verano).

Tampoco veo por qué no consultaría su cronograma maestro de recursos para poder asegurarse de que su cronograma sea realista y factible.

4. Algún híbrido de n.° 1 y n.° 2 con flotación distribuida algo uniformemente antes de hitos significativos en el ámbito de trabajo.

Esto es más lo que suelo hacer, vea los comentarios en su opción #2