Por Qué Los Lanzamientos de Proyectos Fracasan Para Quienes Se Unen Más Tarde
El Mito del Lanzamiento: Los lanzamientos de proyectos crean alineación al inicio, pero inevitablemente las cosas cambiarán.
La Importancia de la Propiedad: Cuando quienes se unen a mitad de proyecto carecen de sentido de propiedad, el impulso, la moral y el impacto del proyecto se verán afectados.
El Reto de la Documentación: La documentación tradicional falla en proyectos de ritmo acelerado; se requieren formatos livianos y adaptables.
IA y Neurodiversidad: Las herramientas de IA pueden facilitar la incorporación proporcionando información accesible del proyecto, pero requieren datos precisos.
Una Cultura de Pertenencia: Fomentar un sentido de pertenencia es crucial para integrar equipos eficientemente y lograr el éxito del proyecto.
Por Qué los Kickoffs Son Geniales… Pero Tienen Fallos
Me encantan las reuniones de inicio de proyecto. Son una oportunidad para crear entusiasmo, generar impulso y alinear a todas las personas adecuadas en la sala.
Excepto que... los kickoffs de proyecto son un mito total.
Al menos, esa versión de ellos lo es.
Unlock for Free
Create a free account to finish this piece and join a community of forward-thinking leaders unlocking tools, playbooks, and insights for thriving in the age of AI.
Have an account? Log In
La versión donde reunimos a todos los interesados conocidos, acordamos una Estrella Polar, grabamos nuestro enfoque en piedra y luego nos lanzamos juntos suponiendo que la energía cinética creada ese día impulsará el proyecto de principio a fin por sí sola.
La realidad es que el cambio es inevitable, y el enfoque que tienen la mayoría de los equipos respecto a los kickoffs de proyectos está realmente roto.
Y esto va a empezar a importar mucho en la economía impulsada por IA y trabajadores fraccionados en la que estamos entrando.
Por Qué Un Buen Kickoff No Garantiza Un Buen Proyecto
Solía pensar que mi habilidad para liderar grandes kickoffs era mi ventaja injusta como PM. Cuando iniciaba mis proyectos, los equipos salían disparados con claridad e impulso, en vez de confusión y más preguntas sin respuesta.
De hecho, la gente se me acercaba después de una reunión de inicio para pedirme prestada mi agenda o presentación para usarla en sus propios proyectos. Era un motivo de orgullo para mí.
Pero luego ocurrió algo que cambió completamente mi manera de pensar sobre los kickoffs.
En uno de mis proyectos, miembros clave de mi equipo fueron retirados y reasignados a otros proyectos, todo esto sin tiempo para un traspaso de conocimiento adecuado. Las personas talentosas que se incorporaron también eran muy capaces, pero sentían que empezaban en desventaja, viviendo a la sombra de lo que ya había sucedido. Añadían matices a cada conversación con frases como "pero yo no estaba aquí cuando comenzó el proyecto" o "apenas me estoy poniendo al día, no dejes que mis ideas descarrilen tus planes."
Para los nuevos miembros del equipo, no es que no tuvieran la información, autoridad o incluso las ideas. Era que no sentían que tenían propiedad.
Y sin esa sensación de pertenencia, el viento se iba de las velas. La misión no era suya. Se sentían como profesores suplentes a cargo de la situación — víctimas de las circunstancias, sin mucho poder de decisión o control.
Desafortunadamente, yo aún no me había dado cuenta de esto.
El Problema de la Transferencia del Conocimiento
En ese momento, la solución parecía simple: solo pon al día a las personas nuevas. Transfiere el conocimiento a sus cerebros. ¿Verdad?
Después de todo, hay briefs, declaraciones de alcance y documentos de requisitos abundantes — sin mencionar la presentación de inicio y los resultados de ejercicios de visión.
Pero incluso cuando tienes todos tus documentos del proyecto ordenados y organizados, la experiencia de ponerte al día con una montaña de información poco estructurada puede sentirse como hacer contabilidad forense con una pistola apuntándote a la cabeza.
Claro, los nuevos miembros pueden hacer preguntas, pero no saben lo que no saben. Y la mayoría de las veces no se sienten cómodos haciendo las preguntas “tontas” por miedo a la temida respuesta: “eso estaba en los documentos, ¿no lo viste?”
Esto creó un ciclo en el que los recién llegados permanecían perdidos más tiempo — lo que solo hacía que el proyecto fuera más difícil de orientar.
El Problema de la Higiene
Y además de eso, cada vez que incorporaba a un nuevo miembro al equipo del proyecto, me daba cuenta de que dentro de mis maravillosos documentos, había pequeños detalles — e incluso a veces detalles importantes — que no estaban alineados con el estado actual del proyecto.
Desde el kickoff, se habían tomado cientos de miles de micro-decisiones. No las grandes que apuntas en un registro de decisiones — sino las pequeñas que se escapan en las actualizaciones de la documentación.
Me encontraba explicando discrepancias, elaborando pequeñas diferencias, y transmitiendo conversaciones informales entre miembros del equipo que nunca pensamos en documentar.
El Problema de la Velocidad
¿Pude haber mitigado todo esto usando un “sistema de compañeros” en el que un nuevo integrante sea emparejado con un colega del proyecto? Créeme, lo intenté. Pero eso tampoco resultó porque el proyecto no podía permitirse tener a alguien en apoyo parcial.
Ya íbamos a toda velocidad y no podíamos darnos el lujo de ir más lento. Las fechas límite se acercaban, la presión aumentaba, la visibilidad era cada vez mayor y se esperaba que el equipo trabajara más rápido cuanto más personas se añadían, no al revés.
Así que en lugar de frenar el ritmo, continué con el status quo: la versión donde los que se unen a mitad de proyecto quedan atrapados al saltar a un coche en marcha y meter la mano en el fuego.
El Problema de la Pertenencia
Pero mientras seguía lanzando frenéticamente documentos e invitaciones a reuniones a quienes se sumaban al proyecto — y mientras el equipo repasaba tareas del backlog sin pensar — algo quedó muy claro: no se trataba de información. Se trataba de pertenencia. Y ese es un estado emocional que no puede lograrse solo con documentación.
No podía lograr que los nuevos miembros del equipo se sintieran parte solo tranquilizándolos o hablándoles más. Ningún sistema de compañeros iba a arreglar esto. Ninguna reunión de “pregunta lo que sea” en agenda iba a suavizar la situación. Era necesario contar con espacios seguros y alternativos.
Las personas encuentran el sentido de pertenencia de distintas maneras según el contexto: algunas necesitan un tiempo a solas con la documentación antes de hablar con el equipo; otras quieren un compañero; otras buscan un espacio seguro para hacer las “preguntas tontas”; y algunas simplemente quieren entender el “por qué” de la misión y su papel dentro de ella.
En eso es en lo que debí haber invertido mi tiempo y energía: en crear un marco que permita a los miembros del equipo encontrar su sentido de pertenencia a su manera.
En última instancia, estaba invirtiendo demasiado en la ceremonia de inicio y luego dejando a quienes se unían a mitad del proyecto a valerse por sí mismos.
Este ciclo de incorporación deficiente no solo frustra a las personas, sino que debilita proyectos enteros. Cuando los recién llegados no pueden ponerse al día rápidamente, las decisiones se retrasan, los errores se multiplican y la moral del equipo se resiente.
Y cuando el cambio es inevitable — cuando los miembros del equipo rotan durante el ciclo de vida del proyecto — este enfoque se vuelve insostenible.
Para los nuevos miembros del equipo, no era que no tuvieran información, autoridad o incluso ideas. Era que no sentían que tuvieran apropiación.
Una forma diferente de pensar los inicios: Integración continua
¿Entonces, cuál es la respuesta? Si estamos invirtiendo demasiado en los inicios y poco en manejar los cambios y la integración durante el proyecto, ¿cómo podemos corregirlo?
Yo tenía mis hipótesis, pero también tuve un momento revelador con alguien a quien respeto mucho y que me dijo:
"Siempre estoy repitiendo el punto de enfoque casi en cada reunión porque la 'estrella del norte' siempre cambia. Me recuerda a cómo practicamos en Kung Fu... Hay un punto central al que nos dedicamos a controlar, y fuera de ahí todo es contexto para regresar a esa verdad. Es una conversación, donde ambos lados 'hacen preguntas' y reciben respuestas en tiempo real con todos los sentidos."
En otras palabras, en vez de depender de una gran celebración de inicio, podemos usar cada interacción para reforzar la esencia de lo importante del proyecto. Está integrado en el acto de colaborar en lugar de ser una gran fiesta a la que es fácil sentir que te has perdido si no estuviste ahí.
Esto es lo que he intentado hacer en cada proyecto desde entonces:
1. Una política de documentación ágil y fácil de actualizar
He descartado mis presentaciones bonitas de inicio y artefactos de proyecto muy pulidos (briefs, informes de estado, agendas de reuniones, logs RAID) y, en su lugar, priorizo tener la información en un formato fácil de actualizar y sencillo para que lo lean tanto personas como compañeros con IA.
Luego trabajo con los equipos del proyecto para asignar responsables de actualizar la documentación — igual que haríamos con los encargados de riesgos. Así se reparte la carga y se empodera a los miembros del equipo para ser garantes de la información precisa.
Por ejemplo, tenemos documentos simples y concisos en Notion o Slite para roles y responsabilidades, el brief del proyecto y los planes de comunicación. Nada está bloqueado en hojas de cálculo o PDFs.
2. La integración continua como una realidad aceptada
Junto con la documentación, desde el principio gestiono las expectativas del equipo, dejando claro que los equipos, los objetivos y otras circunstancias alrededor del proyecto pueden cambiar en cualquier momento, y tendremos que adaptarnos.
En otras palabras, en vez de esperar y rezar para que nada cambie, asume que sí cambiará.
Eso implica que haya lo menos posible guardado en la cabeza de las personas o limitado a un momento específico. Las reuniones tienen transcripciones, las notas de los ponentes están accesibles por escrito, la mayoría de conversaciones del proyecto son en canales públicos y las decisiones quedan anotadas cuidadosamente.
Esto ayuda a garantizar que quienes se perdieron el Día Uno del proyecto aún tengan acceso a la información que necesiten. Y también nos ayuda a reaccionar como una bandada de alondras si cambian los objetivos o circunstancias del proyecto.
3. La IA como fuente de la verdad para todos los neurotipos
Junto con lo anterior, mi equipo y yo configuramos chatbots de IA o bases de conocimiento consultables del proyecto lo antes posible.
En muchos casos, no es tan sofisticado como uno soñaría respecto a la IA, pero cumple algo realmente importante para nosotros: crea una manera relativamente privada, segura y menos politizada para que los miembros del equipo accedan a la información sobre el proyecto — a su manera, de acuerdo a cómo prefieren aprender.
Estos chatbots se alimentan desde el principio con datos estructurados y no estructurados del proyecto: briefings, SOWs, informes de estado, actas de reuniones y algunas conversaciones del equipo. Y, como la documentación es lo suficientemente ligera para que los miembros humanos del equipo la mantengan actualizada, resulta relativamente fácil para una IA hacer seguimiento de lo que ha cambiado a lo largo del proyecto: decisiones que se han tomado, presupuesto que se ha añadido, problemas que han surgido, riesgos que se han materializado, escaladas que han ocurrido, etcétera.
Después, cualquier miembro del equipo puede consultar al chatbot en cualquier momento y en un contexto donde no tenga que preocuparse por parecer poco informado ni necesitar pedir una reunión con una figura de autoridad que ya tiene poco tiempo disponible.
Por ejemplo, un miembro del equipo puede preguntar cosas como:
- “¿Cómo contribuye mi tarea al objetivo general del proyecto?”
- “¿Quién depende de que yo entregue mi entregable a tiempo?”
- “¿Dónde debo guardar mis entregables finales y cuál es nuestra convención para nombrar archivos?”
Puede que sepan la respuesta a estas preguntas, pero quieren asegurarse cuando están saltando entre proyectos y otras tareas.
En última instancia, los chatbots de IA simplifican el proceso de acceder a la información, aumentando la eficiencia al eliminar la necesidad de formación exhaustiva o de consultar múltiples fuentes, y además mejoran la accesibilidad gracias a una interfaz amigable que se puede acceder desde cualquier dispositivo con conexión a internet 24/7.
Pero aquí está el punto: se sabe que la IA puede equivocarse.
Y si se equivoca, un proyecto puede desviarse rápidamente. La consecuencia general sería un paso adicional: intentar preguntar al chatbot, analizar la respuesta porque puede no ser correcta, luego usar tu propio juicio para decidir si seguir la respuesta recibida y no preguntar a nadie más, o buscar un compañero a quien consultar—en otras palabras, cuando no confiamos en la IA, volvemos al punto de partida.
Así que los datos deben estar lo suficientemente limpios para no ser contradictorios. Y luego, los miembros humanos del equipo deben de verdad confiar en que es preciso (suponiendo que no le hayamos dado información incorrecta).
Para ayudar a garantizarlo, nuestra prioridad es asegurar la mayor precisión posible, con miembros clave del equipo actuando como campeones y árbitros de calidad usando algunos casos de prueba y verificaciones puntuales que realizamos regularmente.
4. Refuerzo ritualístico de los objetivos
Y para unirlo todo, he intentado tomar algunos de mis elementos favoritos del, trágicamente, "momento puntual" de inicio de proyecto y entretejerlos en el día a día. Cosas como reiterar y desafiar constantemente la visión del producto o el BHAG para que la misión se entienda lo suficiente como para poder examinarla y asegurarnos de que seguimos construyendo lo correcto.
Por ejemplo, trato de recordar a las personas los resultados deseados del proyecto al inicio de cada reunión del equipo. Algo como "como recordatorio, este proyecto ayudará a los usuarios de transporte con diferentes capacidades a llegar a su destino de forma más segura y con menos frustraciones."
Y si ese Norte ha cambiado, intento repetirlo en cada reunión o actualización de estado también: "Como recordatorio, esto comenzó como una iniciativa para usuarios discapacitados del transporte, pero ahora es una oportunidad para mejorar la experiencia de todos los clientes en múltiples redes de transporte."
Lo otro que hago es utilizar mi rol como generalista para hacer preguntas que dirijan las decisiones hacia nuestro objetivo. Por ejemplo, si el equipo estuviera decidiendo entre dos enfoques, preguntaría algo como "¿cuál de los dos nos ayuda a eliminar más fricción de la experiencia del cliente?"
Para cosas como los valores del equipo y las formas de trabajar, suelo terminar las reuniones con un recordatorio: "No olvidéis mantener las comunicaciones importantes en el canal compartido si pueden ayudar a otros a hacer su trabajo."
Esto no solo hace que los que se incorporan a mitad de proyecto sientan que no se han perdido nada del inicio, también ayuda a reforzar continuamente la misión con todos los interesados.
5. Una cultura de pertenencia
Pero, sobre todo, estoy intentando cambiar mi mentalidad de "transferencia de conocimiento" a "transferencia de propiedad" priorizando formas de ayudar a que los nuevos miembros del equipo o interesados sientan que "pertenecen" al proyecto y que pueden aportar todo su potencial.
En mi opinión, no hay una única forma infalible de lograr esto, pero creo firmemente que la respuesta no consiste en abrumar a las personas con más información. Los humanos necesitamos usar nuestra humanidad para abordar los asuntos que son puramente humanos: emociones, ego, comunidad y propósito.
Cuando las personas no sienten que tienen propiedad, es menos probable que hablen si algo les parece mal o que desafíen una decisión que podría desviar el proyecto.
Por Qué Esto Es Más Importante Que Nunca
Hoy en día veo que el problema de la integración a mitad de proyecto se está haciendo cada vez mayor. Miembros de mi comunidad están gestionando proyectos que se han convertido en una puerta giratoria de especialistas fraccionados, freelancers, e incluso empleados de tiempo completo que son movidos fluidamente entre proyectos para mantenerlos ocupados.
Al mismo tiempo, las herramientas de IA están creando expectativas líquidas entre los implicados del proyecto: ahora se espera que los proyectos avancen más rápido, gestionen mejor los cambios y ofrezcan más valor aprovechando el análisis de datos, la automatización y la toma de decisiones autónoma.
En otras palabras, los equipos son más volátiles y el ritmo se está acelerando. Lo que significa que la brecha de pertenencia se amplía cuando todo se mueve más rápido y cambia más frecuentemente.
Y aquí está el verdadero riesgo: no queremos terminar construyendo lo incorrecto más rápido.
Cuando las personas no sienten que tienen propiedad, es menos probable que hablen si algo les parece mal o que desafíen una decisión que podría desviar el proyecto.
Por eso la integración continua ya no es opcional. No es un complemento ni una habilidad blanda. Es una necesidad de negocio. Si queremos equipos que puedan adaptarse y ofrecer verdadero valor en este contexto de proyectos más veloces y fragmentados—necesitamos personas que se sientan comprometidas con la visión, no solo informadas sobre las tareas.
¿Entonces, Se Han Quedado Obsoletos Los Kickoffs?
Definitivamente los kickoffs de proyectos no se han quedado obsoletos. No para mí, ni para muchos equipos de proyectos.
Personalmente, me encantan. Creo que los kickoffs de proyecto son reuniones que pueden crear lazos entre las personas y ofrecer foros para el diálogo en un momento clave del ciclo de vida del proyecto. Me parecen muy humanos. Así que sí, sigo haciendo kickoffs, y van a tener que quitarme ese hábito a la fuerza.
Lo que sí hago diferente es que ya no deposito todas mis esperanzas y sueños en mis kickoffs. Ya no invierto tanta energía en hacer que los kickoffs sean perfectos, relucientes o performativos. No aspiro a que sean la ceremonia definitiva que haga que quienes no estuvieron al inicio se sientan ciudadanos de segunda clase. Y desde luego, no intento que sean algo que nos obligue a mantener la expectativa de un solo camino fijo.
Porque los proyectos no son una línea recta. Son como una cometa al viento, recibiendo sacudidas y que necesita ser guiada activamente, pase lo que pase. El cambio es inevitable. Y es ahí donde deberíamos enfocar nuestra energía en prepararnos.
¿Qué Opinas?
Pero también me gustaría escuchar tu opinión: ¿son los kickoffs tan problemáticos como los he pintado? ¿Cómo enfocas la integración en tus proyectos—especialmente cuando alguien se une al equipo a mitad de camino?
