Por qué el onboarding importa en los proyectos: decidir sin contexto es un riesgo

Pocos equipos de proyecto terminan con las mismas personas con las que empezaron. Si el calendario se retrasa, entra otro desarrollador. Un socio cambia a su gente. Un planificador llega desde otro equipo a mitad de camino. Y cada vez que alguien se suma, el proyecto vuelve a escuchar la misma pregunta: "¿Por qué decidimos hacerlo así?".

Esta serie parte de esa pregunta. En tres artículos voy a hablar de por qué el onboarding importa tanto en los proyectos, de cómo es un buen onboarding y de por qué el juego tiene sitio en el trabajo. Al final de todas esas ideas está lo que construí: First Run, un RPG de onboarding para nuevas incorporaciones y para quienes se suman a un proyecto.

Un proyecto es gente que llega y se va

Cuando escribí sobre qué cambió en mi trabajo después del PMP, cité la definición de proyecto de la 8.ª edición de la Guía del PMBOKPMBOKProject Management Body of Knowledge: Una colección de procesos, mejores prácticas, terminologías y pautas compiladas por el PMI.Read More →: "una iniciativa temporal en un contexto único, emprendida para crear valor". La palabra que yo conecto con el onboarding es temporal.

Los equipos de operaciones acumulan contexto porque las mismas personas hacen el mismo trabajo durante mucho tiempo. En un proyecto es distinto. Se reúne a la gente en torno a un objetivo, los perfiles necesarios cambian de una fase a otra y, al terminar, todos se dispersan. Incorporarse no es la excepción, es lo normal. Y no todos los que llegan son iguales:

• Nuevas incorporaciones: la empresa es nueva y el proyecto también.
• Quien llega a mitad de proyecto: conoce la empresa, pero no el historial de decisiones de este proyecto.
• Proveedores y socios: saben hacer su trabajo, pero no conocen la forma de trabajar de tu organización.
• Quien cambia de rol: conoce a la gente y a la empresa, pero no los criterios del nuevo rol.

Los cuatro necesitan onboarding. Aun así, cuando decimos "onboarding" casi siempre pensamos solo en el primero: la presentación de bienvenida, las cuentas, la explicación de beneficios. El onboarding que necesita un proyecto es mucho más concreto.

Qué pasa cuando alguien nuevo trabaja sin contexto

Imagina esta escena. Es un ejemplo inventado para ilustrar la idea, no un caso real.

Un desarrollador se incorpora a un proyecto tres semanas antes del lanzamiento. El segundo día, la persona de contacto del cliente le escribe directamente: "¿Podrías añadir un filtro a la lista de productos? Es algo sencillo". Con ganas de ayudar, el nuevo lo implementa en media mañana. Pero en este proyecto se acordó que los cambios de alcance pasan por el PM como solicitudes de cambio, y ese filtro amplía el alcance de QA y los escenarios de UAT. Pasa una semana sin que nadie se entere.

¿Hizo algo mal el nuevo? Yo creo que no. Lo más probable es que conociera la regla, pero no se diera cuenta de que se aplicaba justo a esa situación, aunque la documentación de onboarding dijera en una línea: "Los cambios de alcance pasan por el PM".

En esa escena están los tres costes de un onboarding flojo:

Coste	Cómo se nota	Visto por un PM
Explicaciones repetidas	A cada persona nueva se le cuenta el mismo contexto desde cero	El tiempo de los perfiles sénior y del PM se va a trabajo que nadie planificó
Adaptación lenta	Mucho tiempo preguntando y esperando porque no se sabe qué va primero	El tiempo hasta que alguien rinde de verdad no está en los supuestos del calendario
Decisiones sin contexto	Decisiones bienintencionadas que chocan con el alcance y el proceso acordados	Se acumulan en silencio riesgos para el alcance, la calidad y el calendario

Los dos primeros se ven. El que da miedo es el tercero. Repetir explicaciones solo cuesta tiempo, pero las decisiones tomadas sin contexto cambian poco a poco el rumbo del proyecto sin que nadie lo note.

Los números también dicen que el onboarding es difícil

No es un problema exclusivo de los proyectos. En las organizaciones en general, el onboarding suele hacerse mal.

• Gallup informa de que solo el 12% de los empleados está totalmente de acuerdo en que su organización hace un gran trabajo con el onboarding de nuevos empleados.
• Según SHRM, solo el 29% de las nuevas incorporaciones sentía tener la preparación y el apoyo necesarios para destacar en su nuevo rol.

Ambas cifras hablan de nuevas incorporaciones en general, no de quien se suma a mitad de un proyecto. Pero si ni siquiera quien entra en una empresa suele sentirse preparado, imagino que quien cae en un proyecto que ya está en marcha lo siente todavía más.

El onboarding es trabajo de gestión de proyectos

Por eso veo el onboarding de un proyecto no como un evento de RR. HH., sino como algo que el PM debe gestionar. Si pones las responsabilidades habituales de un PM al lado del onboarding, el solapamiento salta a la vista:

Responsabilidad del PM	Qué significa para el onboarding
Gestión de recursos y del equipo	Planificar el periodo de adaptación junto con la fecha de entrada. Decidir quién explica qué la primera semana
Transferencia de conocimiento	Dejar el historial de decisiones, lo que se acordó no hacer y las lecciones aprendidas en una estructura, no en la cabeza de una persona
Alineación con los interesados	Dejar claro el primer día quién decide y a quién preguntar qué
Gestión de riesgos	Tratar el periodo de adaptación como un riesgo y planificar una respuesta
Control de cambios	Mostrar el proceso de solicitud de cambios con situaciones reales, no solo con un documento

La última fila es el núcleo de este artículo. Explicar un procedimiento y ayudar a reconocer cuándo se aplica son cosas distintas. Lo que necesitaba el desarrollador de la escena no era una lista de reglas. Era haber vivido antes ese momento en que el cliente te pide algo directamente diciendo que "es algo sencillo".

5 cosas que debe cubrir el onboarding de un proyecto

Cuando alguien nuevo se suma a un proyecto, yo me aseguraría de cubrir como mínimo estas cinco cosas:

1. Para qué: cuando el proyecto termine, quién podrá hacer qué mejor.
2. Hasta dónde: el alcance acordado y lo que se acordó no hacer.
3. Quién decide: los responsables de decidir, los canales de comunicación y cuándo escalar.
4. Qué pasa cuando algo cambia: el proceso de solicitud de cambios y su porqué.
5. Cómo se decide en las situaciones habituales: qué hace primero este equipo ante un retraso, un choque de requisitos o un problema de calidad.

Los puntos 1 a 4 se pueden transmitir, más o menos, con documentos. El 5 es otra cosa. El criterio se asienta menos leyendo que tomando la decisión tú mismo. Y creo que es justo ahí donde la mayoría de los onboardings flojean.

Por eso construí First Run

Mientras escribía esto, no dejaba de volver al punto 5. El criterio viaja mal en los documentos, y aun así son las decisiones las que suelen sacudir un proyecto. Así que pensé que hacía falta un onboarding en el que se pudieran practicar esas decisiones de antemano. Eso es First Run.

First Run es un RPG de onboarding en el que las nuevas incorporaciones y quienes se suman a un proyecto viven situaciones reales de trabajo como misiones. Entras en Make Feelbetter, una empresa de TI ficticia, eliges uno de cinco roles (desarrollador, PMO, maquetador web, planificador o diseñador) y tomas decisiones en misiones que te encargan NPC mentores. Son situaciones como las del trabajo real: retrasos en el calendario, fallos de API, requisitos, decisiones de UI y problemas de accesibilidad. El rol de PMO incluye gestión de riesgos, coordinación del calendario y control de cambios. La idea era sencilla: vivir momentos como el de la escena de arriba primero dentro de un juego, y no en un proyecto real.

Diseñé First Run a partir de mi experiencia práctica como jefe de proyecto con certificación PMP®, y se puede personalizar para cada empresa o proyecto. Los escenarios de onboarding de un proyecto, los flujos de trabajo internos y las situaciones habituales se pueden convertir en misiones, así que sirve tanto para nuevas incorporaciones como para la formación de arranque de un proyecto o el onboarding de proveedores y socios.

En un proyecto, el onboarding vuelve a empezar cada vez que llega alguien. Si ese comienzo puede ser una experiencia en lugar de una explicación, creo que las primeras decisiones de quien llega serán mucho menos arriesgadas. Por eso construí First Run.

Pruébalo tú — la demo es gratuita y funciona en el navegador, en PC o móvil, sin registro. Jugar a First Run →

En el próximo artículo iré un paso más allá: por qué el onboarding basado en documentos no se queda y cómo es un buen onboarding.

Preguntas frecuentes

¿En qué se diferencia el onboarding de un proyecto del de una nueva incorporación?+

El onboarding de una nueva incorporación ayuda a adaptarse a la empresa y a su cultura. El de un proyecto ayuda a entender rápido un proyecto en marcha: sus objetivos, su alcance, quién decide, el proceso de cambios y cómo se resuelven las situaciones habituales. Incluso quien lleva años en la empresa lo necesita al sumarse a un proyecto nuevo.

¿La demo de First Run es gratuita?+

Sí. Funciona en el navegador, en PC y móvil, sin registro ni pago. El progreso de la demo pública se guarda solo en ese navegador, sin cuenta.

¿Se puede adaptar First Run a nuestro proyecto?+

Sí. Se puede crear una versión a medida a partir de tus escenarios reales de trabajo y las reglas de tus proyectos, con NPC inspirados en tus mentores, el mapa de tu oficina y tu imagen de marca. Se solicita desde la página de contacto de firstrun.fit.

Fuentes

• Gallup: Why the Onboarding Experience Is Key for Retention
• SHRM: Complete Employee Onboarding Guide
• First Run: RPG de onboarding personalizable