Lecciones aprendidas en la gestión del cambio

[00:00:00] Genial. Muchas gracias a todos por unirse hoy. Eh, vamos a estar hablando sobre la gestión del cambio. Este es un tema que ha surgido mucho en nuestro chat últimamente. Así que pensé que ya era suficiente y quería reunir a algunas personas y hablar sobre algunas de las cosas que estaban sucediendo.

Lo que quiero que hagamos es tener un momento para compartir y ayudar a construir el conocimiento colectivo aquí porque todos hemos pasado por gestión del cambio en nuestros propios proyectos y organizaciones, y hemos estado en ambos extremos, el de dar y recibir el cambio. Así que quería usar este tiempo para compartir algunas de las historias y también hablar sobre cosas que hemos aprendido a lo largo del camino y ayudar a otros, estén donde estén en sus propios procesos o su propio tipo de cambio.

Esa es un poco la belleza de la comunidad de todos modos: construir ese conocimiento colectivo. Por eso, he pedido a un par de personas que traigan historias. Y si no tienes una, está [00:01:00] bien. Si recuerdas una durante la sesión, también está bien. Pero lo que quiero hacer es poder compartir algunas de estas historias.

Y luego, a medida que surjan preguntas, siéntanse libres de ponerlas en el chat o decirlas en voz alta. Esto va a ser totalmente una discusión. Y podemos compartir algunas de las cosas que hemos aprendido en el camino. La idea es que cuando nos vayamos hoy, ojalá tengamos más herramientas e ideas para afrontar el cambio en nuestros propios proyectos.

Una de las personas a las que pedí que trajeran una historia para empezar fue Fred. Así que, Fred, si no te importa, liderarnos aquí y comenzamos. Como mencioné, preguntas en el chat, preguntas, pueden levantar la mano incluso, y decirlas en voz alta y nos divertiremos.

Sí, seguro. Gracias. Antes que nada, gracias [00:02:00] por armar esto. Creo que no solo es genial ver eventos así, sino aún más cuando son una respuesta directa a personas que tienen preguntas y cosas, porque realmente construye comunidad. Pienso que sí.

Y gracias por invitarme a compartir una historia. Así que, mi formación es en diseño de sistemas instruccionales y de hecho tengo un doctorado en ello. Así que he visto toda la teoría y los modelos y parte del diseño de sistemas instruccionales es el desarrollo organizacional. Y una gran parte de eso es la gestión del cambio.

Así que, aunque no tengo mucha experiencia con la gestión del cambio formal, como estar en un equipo de cambio y ese tipo de cosas, donde la organización de aprendizaje es algo real a lo que la gente aspira, sí he hecho algo de investigación en el área, por ejemplo, la organización de aprendizaje de Peter Senge, ¿verdad?

La quinta disciplina, mirando, por ejemplo, el modelo de Kotter de 8 pasos [00:03:00] y el modelo de Lewin de congelar-descongelar-recongelar, y esos modelos son útiles como objetos para pensar el cambio, ¿verdad? Es como: ¿Cuáles son los procesos por los que hay que pasar? ¿Cuáles son las cosas que puedes hacer en ese espacio? Incluso con trabajos de implementación.

Así que, por ejemplo, Everett Rogers tiene mucho trabajo sobre la difusión de innovaciones y la adopción. Y esta idea de que alcanzas una masa crítica. Cuando una tecnología se está adoptando, tienes estos innovadores que se aferran a cualquier cosa y llevan la bandera durante un tiempo, pero una vez saturado ese mercado, necesitas expandirte más allá de eso.

Así que empieza a ir a los primeros adoptantes y después alcanza una masa crítica donde todos saben lo que es, empiezan a pensar en ello y luego avanza hasta esta etapa de los rezagados. Como: ahora todos usan Microsoft Teams o lo que sea en la organización.

Y siempre hay unas pocas personas al final, los rezagados, que dicen: No, yo no voy a hacer eso. No va a pasar. [00:04:00] Vengo de educación superior y aunque toda la escuela usa Google o Microsoft o lo que sea, siempre hay 3 profesores que dicen: Yo no uso ese correo, uso el mío porque me gusta más. ¿Y cómo sabes de reuniones? ¿Cómo pueden los estudiantes agendar con usted? Tienen que pasar por una máquina de Rube Goldberg, descifrar mi agenda y mandarme una paloma mensajera, y todo eso.

Así que hay modelos y teorías al respecto, pero para no alargarme, compartiré rápidamente una experiencia. He tenido muchas diferentes a lo largo de los años y la que pensé que aplicaba más aquí: Trabajo mucho ayudando a organizaciones a actualizarse con monday.com y herramientas similares. Tuve un cliente que producía e-learning, eran una empresa que generaba capacitaciones para otras grandes compañías. Uno de mis clientes había usado [00:05:00] Monday antes, pero era de esos casos donde alguien lo implementó, pero no estaba bien mapeado.

Muchos de los desafíos—muchos de los proyectos de Monday que tengo en realidad no son proyectos de Monday, son proyectos de procesos de negocio. Lo que pasa es que la gente no tiene definidos sus procedimientos operativos estándar, o no han mapeado el flujo de trabajo, o no han pensado en cómo.

Esos son los procesos ideales. Si no sabes dónde estás, no puedes cambiarlo. Nada va a funcionar como quieres. Así que para ese cliente, me tomó como un año, pero trabajé mucho para rediseñar sus sistemas y mejoramos mucho su rendimiento y entrega de proyectos, reduciendo problemas de calidad. Pero todo requirió muchos ciclos iterativos de ¿cómo debería realmente ser? ¿Cómo está ahora? ¿Cómo acercar ambos?

Creo que ese proceso es tan simple como parece, pero es el que todos esos modelos de cambio tratan de alcanzar.

Y eso es bastante universal. Si quieres adelgazar, ganar fuerza, aprender una habilidad o incluso en tu casa o cualquier cosa, existe esa parte fundamental de análisis: ¿cómo es el ideal y dónde estamos ahora? Algunos aprendizajes prácticos de ese proyecto, lecciones que ahora llevo conmigo, pasé mucho tiempo mapeando procesos y descubrí que el reto era que el problema no estaba definido.

No podíamos resolverlo. Y al mirar los diferentes flujos de trabajo de proyectos, a veces no estaban conectados.

Porque había casos donde una consultora, por ejemplo, decía: Oye, ¿en qué va este proyecto? Y yo: Lo dejé con el cliente. ¿Cuándo fue eso? Hace tres semanas. ¿Dónde está ahora? No sé, no he tenido respuesta. ¿Le diste seguimiento? Todavía no. Esos traspasos, mapear ese proceso, saber dónde están. Así que ahora, cuando empiezo con un nuevo cliente, siempre trato de definir el problema por adelantado y asegurarme de haberlo analizado bien y saber exactamente qué intentan conseguir.

Ni siquiera toco Monday o la herramienta que sea. Incluso la programación es así. No abres el VS Code y empiezas a codear sin saber qué buscas. Es planificación y es la parte que no me sale natural, pero he aprendido a planificar pues es muy útil.

Como cuando haces un esquema de un trabajo. También, me aseguro de trabajar con ellos para que describan el proceso que desean. Si quieren que pase algo, ¿cómo debería verse? ¿A quién le toca después? ¿Qué pasa después?

¿De dónde salen los insumos? El objetivo es hacer un mapa. Quizá esto sea un poco fuera de tema, pero puedo expandirlo, aunque no quiero robar todo el tiempo. Más bien, tengo la primera pregunta:

Si entraste ahí y tuviste que crear procedimientos para ellos porque no tenían nada, ¿había resistencia de esas personas? Me refiero a que seguro tenían su SOP personal, entonces ¿cómo logras que se sumen? Sí, muy buen punto. Me alegra que lo nombres. En este caso, trabajé principalmente con los propietarios. Eso fue bueno porque era la principal interesada. El reto era que todo eso existía, pero solo en su cabeza. Y no necesariamente se practicaba. Los otros eran consultores, no empleados fijos. Su interés era entregar su proyecto rápido y listo. No invertían en el negocio más allá de un buen producto. Tenían su proceso, quizás bien definido, quizás no, según el tiempo que llevaran de contratistas. Pero esos procesos no siempre coincidían con el de la dueña. Entonces ella dice: este es el proceso, ahora quiero que lo sigas. El contratista puede o no estar de acuerdo. Ahí entra la política: horas por proyecto, defines puntos de control. Si no se cumple, puedes cortar el proceso antes. Todo se trata de equilibrios.

Siempre hay resistencia. Vuelve el modelo de difusión de la innovación: algunos lo adoptan enseguida, tienes autoridad que define el proceso y otra parte es ser abierto a sugerencias, permitir que colaboren en el proceso contigo. Encontrar el equilibrio es algo caso por caso.

Me gustaría saber si para otros aquí, las dificultades y enfoques que han visto o usado son similares.

Quizá hay experiencias completamente distintas.

Ciertamente nos hemos topado con gente resistente a ideas, cambios o procesos nuevos.

Algunos tienen las cámaras apagadas, quizá solo están escuchando, eso está bien. Gracias. Tengo una pregunta, Fred: en esos casos donde la dueña tenía todo en su cabeza y necesitabas extraerlo, ¿cómo haces para transmitir que es importante y que debe dedicar tiempo para contarte?

Yo lidio con lugares caóticos y a veces no tienen ni un minuto y por ahí haces cosas que no te pidieron. ¿Qué haces ahí? Hay muchas cosas que pienso ahora. Una es que, como project managers, no manejamos el volante. Vamos en el asiento del copiloto con el mapa, diciéndole que doble a la izquierda dentro de medio kilómetro, ponga la intermitente, etc. Pero si pasa el giro y sigue, tu labor es decir: Ok, nos pasamos, lo mejor es volver y retomar el camino. Pero no tienes el volante. Al final del viaje dirá: ¿por qué tardamos tres horas extra? Y te mira como si fuera tu responsabilidad. Y tú le dices: Todas esas veces que te pedí que giraras y no lo hiciste tuvimos que compensar. Uso mucho esa analogía. Mantengo eso presente. A veces no lo saben o están ocupados, creen que ya está todo claro, pero lleva tiempo mapearlo. Muchas veces piensan que está hecho y no es así. Creen que la gente lo entiende, pero no siempre es el caso. En este caso, muchas reuniones eran ella contando sus cosas, mandando mensajes, difícil lograr atención. Al final solo podía decirle: Okey, dijiste esto, ¿puedo tomar esto como tarea? Si no, yo propongo esto, ¿te parece? Si no, ¿qué más te gustaría que hiciera? A veces tenía reuniones de una hora y lo único que lograba era proponerle dos o tres tareas y buscar feedback. Largo proceso. Si cobras por hora, bien, si es por proyecto debes tomar otra ruta, pero yo les digo: soy un terapeuta caro. Si quiere gastar sus horas así, perfecto, pero te diré cómo debemos trabajar. Si no giras a la izquierda, yo voy contigo pero lo aviso. ¿Eso te ayuda, Robin? Espero que no esté fuera de lugar.

Claro que ayuda, quiero ese título de terapeuta caro. A veces es así. Y cuando ves que a veces es información contradictoria: haz A, trabajas en A y luego dice: mejor haz B, y luego pregunta: ¿por qué hiciste B? Porque tú me lo dijiste. Hay que ir y venir. Si cobro por hora, lo haré todo el día y te diré que no deberíamos hacerlo, pero lo hago si lo necesitas. Si cobro por proyecto, debo cortarlo de inmediato porque he perdido cientos de horas con clientes así. Porque a mitad del proceso todo cambia y ¿qué pasó? Solo puedo decir, hay clientes que quieren un coche rápido, pero no saben si es un Porsche o un Lamborghini hasta verlo. Pero ser de pago por hora es lo mejor. Hay personas que deben hablar para procesar, solo dejas que lo hagan y al final dices: Esto es lo que entendí, corrígeme si me equivoco. Estas son mis tareas, estas son las tuyas. Siempre lo resumo por correo también. Lo envío cada vez, así semanas después pueden repasar qué había que hacer. Llevo ese registro antes de cada reunión. Las grabaciones también ayudan, especialmente si incluyen tareas.

Robin, la pregunta que mencionaste sobre la persona que tiene todo en su cabeza, ¿te pasa por algo? ¿Relata alguna dificultad tuya con la gestión del cambio? A veces hay un proyecto caótico y quieres crear procesos o SOPs para cuando vuelva a pasar, pero no tienes tiempo de recabar información de esa persona. Me ayuda, pero también me confunde en qué es gestión de cambio versus gestión de proyecto porque siento que todo puede ser un proyecto. Si pudieran aclararlo, me sentiría mejor. Gran pregunta.

Sí, puedo intentar explicarlo. Definicionalmente, un proyecto es un esfuerzo temporal que lleva a un resultado. Cambiar es gestionar cómo se realiza el cambio. Por ejemplo, si estamos como gestores digitales y el resultado es un nuevo sitio web, ¿qué sucede al entregarlo?

Habrá cambios en sus procesos. Tal vez actualizaste su formulario de contacto, ahora ingresan los leads de forma diferente. Tal vez conectaste su CRM y tendrán nueva información. Todo esto es bueno y útil, pero es cambio. Hay que pensar cómo comunicamos el cambio, cómo preparamos a la gente. Fred antes explicó bien la resistencia al cambio. Estoy en un proyecto donde heredé el rol de PM y tuve que informar al cliente que cometieron un error de seis o siete cifras que retrasaría el lanzamiento y habría que poner mucho más dinero para arreglarlo.

Parte viene de lo que hablaba Fred, a gran escala. Reemplazan un software de 20 años que la gente personalizó mucho. Nos dijeron que solo habláramos con un pequeño grupo de interesados y ellos nos dieron info sobre la que actuó el equipo, no yo. Al llegar a las pruebas de usuario, vimos que todo lo que se había hecho estaba mal. Surge el desastre financiero. Había razones válidas para no abrir la consulta a todos, pues si el proveedor anterior reaccionaba y quitaba su software antes de tiempo, no podrían trabajar. Así, en retrospectiva tiene sentido, pero si yo hubiese estado desde el principio habría manejado mejor el riesgo, habría hecho que firmaran un aviso de riesgos indicando que entienden las consecuencias de esa decisión.

Hay que dejar constancia de los riesgos asumidos. Al final del proyecto hacemos lanzamientos blandos, permite feedback, lo que ayuda mucho en el cambio. Si alguien se siente escuchado, acepta mejor el cambio que si lo imponen. Usamos presión amistosa: Un grupo va probando y todos reciben el mismo correo así ven quién colabora y quién no.

Muchos cambios en el software y en el equipo, y pronto en la compañía del cliente. Fred preguntó: cuando debes comunicar un error enorme así, ¿suavizas la situación para protegerte? Justamente Galen y yo conversamos sobre eso hoy. Soy PM contratada, todos lo saben, y eso ayuda. Vine del sector externo y pude decir: Este es el problema, veamos cómo salir. No fui la que tomó las decisiones malas. Algunas opciones requieren mucho dinero extra. Como PM externa y neutral, puedo proponer soluciones sin cargar con toda la responsabilidad.

Robin, ¿te quedó clara la diferencia gestión de proyecto y gestión del cambio?

Sí, agradezco sus aportes. Me ayuda que lo expliquen sencillo: cuando buscas gestión del cambio, salen toneladas de cosas y certificaciones. Me ayudó mucho cuando lo simplificó a “has terminado una web, ahora hay que saber cómo actualizar y mantener eso”…

Es el mismo enfoque: la gestión de proyectos es planificar proyectos y todo lo que implica. La gestión del cambio es aplicar ese enfoque al cambio necesario por los proyectos, que suelen ser algo distinto de las operaciones…

¿Alguien aquí ha trabajado como PM junto a un equipo de gestión del cambio?

Porque habría solapamiento y me pregunto cómo sería la coordinación allí.

Yo estuve en una consultoría grande donde sí había departamento de gestión del cambio para el cliente. Mucho sobre comunicaciones, conseguir apoyo, unir las piezas, porque al crear una campaña, es una parte de todo un proceso. Tiene que haber alguien que supervise que el cambio sea prioridad. Muchas veces nadie piensa en eso y tu proyecto fracasa. No es bueno. Así que fue interesante, aunque político.

A mí me pasó igual en Aramark, con una transición de CRM. Yo era líder de comunicaciones y había otra persona de cambio. Ella definía si debíamos hacer emails, reuniones, capacitaciones; yo producía esos elementos. Así es donde separábamos funciones. Si no estamos de acuerdo, lo hablamos. Era un lujo tener ese grupo. Aprendí muchísimo, es algo raro en agencias digitales y estaría genial certificarse, pero cuesta mucho.

Quería compartir otra historia sobre gestión del cambio. Sarah, ¿quieres compartir tu perspectiva?

Claro, en una agencia pequeña de menos de 20 personas. Sufrimos varias olas de despidos. Perdimos el equipo creativo tras cambios en las necesidades del cliente. De pasar a grandes proyectos creativos pasamos a estrategia e investigación. Las herramientas y la documentación quedaron desfasadas, y no ayudaban al equipo actual. Yo acabé siendo la única de operaciones, sin tiempo para nada extra.

El equipo no sabía usar Asana (nuestra herramienta de gestión de proyectos), y había confusión con Slack. Así que una meta fue hacer una nueva capacitación. Primero, revisar qué había y definir lo importante. Como dijo Fred, lo clave era definir el problema antes. Si no tienes la misma definición, el resto pierde eficacia. También, la moral era baja por los despidos y había poca atención. La gente no quería leer un documento de 40 páginas ni asistir a muchas reuniones. Tenía que ser algo breve, útil y sin sobreinformar.

Segundo paso: revisar qué recursos ya existen, como videos breves de Asana. No iba a producir todo yo, así que usé lo que encontré y armé un programa de mini-capacitación. Era un proyecto en Asana, que duplicaba para cada persona, y cada tarea era un bloque de 5 minutos. Era controlado sólo conmigo y su gerente viendo avances. No tuve muchos problemas porque el equipo pequeño era muy colaborador. Con el equipo creativo antes, sí había más resistencia.

Michael preguntó cómo hago para que la gente realmente use eso en el día a día y no lo ignore. Yo acompañaba, hacía presentaciones breves y explicaba que era para crear estabilidad y facilitar el día a día, no una simple formalidad. Al ser una necesidad del equipo, se comprometieron. Si alguien no lo cumplía, dejaba el registro y después les recordaba con amabilidad y evidencia cuándo había comunicado y pedido algo.

Luego preguntó si tras implementarlo la gente volvía a viejos hábitos. No ocurrió, más bien hubo avances. Aclaré que ya no había coordinador de proyectos que hiciera esas tareas extras, así que si yo necesitaba información, debía estar en el sistema.

¿Alguna otra pregunta?

Marissa: Pregunta sobre la fatiga del cambio. Cuando tienes un proyecto largo y el cliente va cambiando prioridades todo el tiempo, alguien ha lidiado con la fatiga del cambio y cómo ayudar al equipo (o a uno mismo) a sobrellevarlo?

Fred: En educación superior, hay cambios de emergencia a corto plazo, como el paso masivo a virtualidad en COVID. Mucha resistencia, algunos creen que su clase no puede enseñarse en línea, aunque pienso que casi cualquier cosa es posible online con los recursos adecuados. Mi enfoque ahí es ayudarles a encontrar lo familiar en el cambio, ver que siguen enseñando, responsabilizando estudiantes, solo cambia el canal. Eso ayuda a corto plazo. A largo plazo, si el cambio es constante, la gente deja de confiar y piensa que aprender algo nuevo es perder el tiempo si luego cambiará. Así que termina volviéndose un tema cultural, no solo de procesos.

Sarah: Fatiga real, reducción y expansión del equipo varias veces. Cuando hubo despidos, tocaron clientes grandes y los recortes obligaron a despedir a la mitad. Decidí ser realista: antes de iniciar cambios, hay que legitimar la situación, reconocer que es difícil, simplemente humanizar la gestión. Eso ayuda mucho y genera sensación de estabilidad.

Michael: Hay que aceptar que durante muchos cambios todo tarda más y la productividad baja hasta que se asientan los procesos. Es normal y hay que transmitirlo para no frustrar al equipo o a uno mismo.

Fred: El ritmo de trabajo suele ajustarse comparándonos con otros, pero uno debe saber poner límites y también perdonarse días productivos limitados; tres cosas destacadas pueden ser suficiente. Hay que aceptarlo.

Cerrando la llamada: Muchas gracias a todos por participar y compartir. Es bueno conocer otros enfoques y retos. Ojalá haya algunas ideas para llevar a nuestro día a día. La próxima sesión será el 23 de mayo, tipo foro abierto para traer cualquier reto laboral. Ojalá puedan asistir.

Gracias y que tengan un excelente día. Nos vemos en Slack. [00:55:00] [00:56:00] Gracias.