¿Proyectos dentro de otros proyectos?

Estoy en la fase de cierre de un tedioso, largo, desgastante y retrasado proyecto.
Es dificil frente a un usuario mencionar las palabras "de acuerdo", "aprobación", "conclusión", "visto bueno", etc. cuando se culmina un proyecto con aquellas características. Pero es mas dificil vender la idea de una celebración para dar por terminado el esfuerzo de meses de varios equipos de trabajo.
Como sea, estoy planeando la junta formal de cierre y la posterior celebración.
Para no hacer el ridículo frente a toda la gente reunida, me aseguré de hablar previamente con todos para ver si "habría algún inconveniente o pendiente aún abierto que impidiera que tuvieramos esa reunión". Afortunadamente recibí la aceptación de todos (dado que el producto se ha entregado y ha pasado un proceso de mas de 2 semanas de estabilización sin presentar problemas importantes).
Dentro de la presentación estoy incluyendo al inicio una explicación de "qué no es esta reunión"; aquí incluyo cosas como "no es una junta de revisión de avances, mucho menos una de análisis de requerimientos", etc.
Una vez aclarado el asunto, vamos a los objetivos del proyecto, el status, como manejaremos los problemas que se presenten con el producto, los siguientes pasos y un espacio para dudas y preguntas.
Finalmente, una vez terminada la presentación de la junta de cierre, me dediqué a planear la reunión de celebración de fin de proyecto. Hice el plan de quienes vamos a invitar, la agenda para ese día, el lugar, la invitación, los snaks y bebida, etc. Me encontré que esta fiestecita ¡es todo un proyecto! Tengo que obtener la autorización de cierre del usuario (charter), planear qué componentes tendrá la celebración (wbs), qué actividades se llevarán a cabo (scope planning), a quienes invitaremos (stakeholder analysis, human resource planning), cómo les mandaré la invitación (communications plan), con qué presupuesto contamos (cost estimation), planear qué vamos a comprar (plan purchases and acquisitions), cuándo la llevaremos a cabo (milestone list), ¿qué haremos si el cliente no puede? (risk analysis), ¿hasta qué punto queremos agasajar a los invitados? (quality planning)...

¿Será que es todo un proyecto? o... ¿¿¿será que todo lo veo como un proyecto???...

Lección 1.- Si vas a celebrar al final, asegurate de reservar parte del presupuesto de tiempo y costo para esta actividad.

Lección 2.- Aquí se puede ver con claridad la naturaleza iterante del ciclo de vida de un proyecto: Inicio, Planeación, Ejecución, Monitoreo y Control y Cierre.

A ti, ¿cómo te gusta celebrar el fin de un proyecto?

¿Cuánto estás dejando de ganar por no concluir el proyecto?

Estuve en un proyecto grande en el que teníamos al patrocinador muy involucrado en la definición de los requerimientos y en la revisión de los entregables. Dada su alta jerarquía en el organigrama funcional y la estructura de discusión y toma de decisiones de ese tipo de ejecutivos, todas las reuniones de revisión se convertían en "sesiones de captura de necesidades" (como si estuvieramos en etapa de planeación y análisis) y, obviamente, el alcance se extendía casi al mismo ritmo que el tiempo que pasábamos en su oficina.
El usuario que se supone definiría la funcionalidad apoyaba ciegamente los cambios de alcance y funcionalidad sin oponerse.
Los nuevos requerimientos iban siendo autorizados sin problemas, pero el proyecto se "barrió" mas de 4 meses más de lo planeado. El argumento siempre fué "la inversión en la nueva funcionalidad se justificará en 1 mes cuando el producto esté en operación". El proyecto se alargó a mas del doble de tiempo, el equipo se desgastó, el usuario quedó molesto y el equipo de administración del proyecto igualmente.
¿Qué aprendí?

Lección 1: ¿Realmente se hizo un análisis exahustivo de los entregables y del beneficio que traería el alcance definido al inicio del proyecto? ¿Por qué no se detectó toda esa nueva funcionalidad y se integró como parte del proyecto original? ¿Es que el patrocinador se "coló" entre el grupo de usuarios definidores sin ser notado (error en el análisis de stakeholders)? El patrocinador no fué identificado en su rol de definidor: error en el análisis de stakeholders.

Lección 2: Si hubieramos hecho un análisis de los beneficios que producirían los entregables planeados podríamos haber tenido un argumento sólido para detener el alargamiento del proyecto. Hubiéramos dicho "ok, construiremos eso también pero quiero recordarles que estamos dejando de ganar X miles de pesos este mes dado que no hemos salido a operación". Estoy seguro que la primera vez probablemente no tendría el impacto deseado, pero cuando le reportemos que ya no son X sino 2X lo que se ha dejado de ganar, reaccionarían (hopefully).

¿Encuentras otra lección en esta experiencia?

Planear la planeación...

Acabo de cometer un error. Pero cobijado con ese dicho de "las lecciones se aprenden con los errores cometidos" y con aquel que dice "se aprende mas de los errores..." les transmito esta Lección APrendida.
Estoy adminsitrando un proyecto tratando de apegarme al estándar del PMI. En este proyecto hay fechas fijas y no negociables: no podemos ir mas allá de la fecha definida.
Empecé dividiendo en fases el proyecto y arranqué con la fase de Inicio. Después de un kickoff apresurado, empalmado entre fases pero exitoso, continué con la fase de Planeación. Fuí exhaustivo en el seguimiento a los procesos de planeación que dicta el PMI. Llegó el momento de entrar en detalles técnicos y, como es mi costumbre, involucré a aquellos especialistas que pudieran ahondar en los "tecnicismos". Hasta entonces teníamos claro el objetivo del proyecto y las actividades (a alto nivel) necesarias para generar los entregables. Hasta hicimos un documento de análisis que se suponía nos ayudaría a prever cualquier problema en potencia. Yo insistí en llegar a un siguiente nivel de detalle en el análisis técnico dado que es un proyecto muy importante, pero no insistí. Finalmente confié en que el personal tecnico tenía todo bajo control y dada la prisa dado que las fechas se estaban cumpliendo, acepté poca profundidad en el detalle y acepté arrancar con un "si terminamos para esa fecha" y sin un cronograma detallado de esas actividades específicas.
La planeación de lo demás iba muy bien, llegamos a profundidades casi inecesarias y esto justificó en mi mente la falta de profundidad del análisis técnico.
La "venta" se hizo y se comprometieron fechas. En la ejecución todo empezó bien. Yo hice monitioreo de avances pero no en una base de entregables y dado que no teníamos un nivel de detalle aceptable ni fechas ligadas a entregables, me limité a preguntar "¿si terminamos para esa fecha?" a lo que siempre recibí un "si".
Finalmente 3 días inhábiles antes de la entrega la gente técnica descubre algunas actividades que eran necesarias y que llevarían alrededor de 2 días de trabajo.
Finalmente tuvimos que trabajar esos 2 días y los entregables se terminaron a un 97%.
El punto aquí es que no cumplimos con el 100% ni lo hicimos en horarios hábiles sino que sacrificamos tiempos de descanso por cumplir con la fecha establecida.
La administración exitosa de un proyecto no es entregar cuando dije que entregaría, sino que debemos cuidar del desgaste al equipo. Desde esta perspectiva y muchas otras que habrás identificado, el proyecto no fue excelentemente administrado. ¿Qué aprendí?

Lección 1: Empalmamos fases de planeación entre planeación de la administración del proyecto y la fase de planeación o análisis del proyecto. Es decir, la fase de ejecución de la administración del proyecto debe incluir toda la metodología de desarrollo: análisis, diseño, construcción, pruebas, liberación. En esta metodología, el análisis y diseño son las fases de planeación, pero caen dentro de la fase de ejecución del plan de administración de proyectos.
En otras palabras, la planeación de la administración del proyecto fué exhaustiva, pero la planeación técnica fué deficiente.

Lección 2: También es posible que se empalmen las metodologías y que la fase de planeación tecnica tenga parte dentro de la planeación de la administración del proyecto, pero ambas deberán ser exhaustivas. Lo completo de una no reemplaza el ejercicio de completar la otra.

Lección 3: Nunca la prisa reemplaza la necesidad de la planeación, la creación de un cronograma ni la definición de entregables.

Lección 4: La mala planeación desgasta al equipo.

¿Encuentras más lecciones en este caso?

¿Qué variable le interesa MAS a tu usuario o cliente?

Un usuario (cliente) siempre va a tener preferencia por alguna variable del proyecto: Calidad, Tiempo, Costo, Alcance, etc. Casi todas las preguntas que haga, las empezará con preguntas sobre esa variable. Ejemplo: Si la variable "favorita" es el tiempo, sus preguntas serán "¿cuándo empiezan con mi proyecto?", "¿cuándo lo acaban?", "¿cuánto falta para terminar este entregable?", etc.

Procura siempre tener a la mano los dos o tres indicadores del área de mayor interés para tu usuario: Si le importa más el tiempo, ten lista la fecha de inicio, la de fin, milestones, forecasts acerca del calendario, SPI, etc.

¿Industria o AP?

¿Qué habilidades son mas necesarias en un proyecto?

a) El conocimiento en la industria en la que se desarrolla el proyecto
b) Al conocimiento en administración de proyectos

¿Qué opinas?

¿Quién es el Patrocinador?

El Patrocinador del proyecto es ese integrante del equipo de proyecto que define qué quiere y sugiere cómo hacerlo.

Hay que hacerle caso en lo primero y cuestionar lo segundo.