Herramientas de innovación: resistencia al cambio y plan de comunicación

Escribía en un post anterior que quizás la mejor de todas las  herramientas de innovación que conozco de reducir la resistencia al cambio que existe en cualquier organización es a través de la comunicación.

Y la comunicación, como cualquier tarea dentro de un proyecto, debe ser planificada, gestionada y evaluada. Y si eres de los que me sigues desde hace tiempo, el modelo de plan de comunicación que utilizo no es nada sofisticado ni voluminoso: apenas una tabla excel donde identificar los elementos clave de la comunicación: emisor, receptor, mensaje (o contenido) y frecuencia.

Cómo planificar la comunicación en un proyecto de innovación

Olvídate de completar grandes documentos que luego solo te llevan a la pereza de tener que abrirlos y no son nada prácticos en la realidad del proyecto. Pero sí dedica cierto tiempo de calidad antes de empezar al proyecto para pensar cómo lo harás. Esta reflexión es válida para cualquier herramienta de innovación: parar – pensar – actuar. Evitarás pérdidas de tiempo posteriores y conflictos internos o externos. Porque la falta de comunicación es la principal causa de los conflictos en las organizaciones y en los proyectos.

En primer lugar, es necesario identificar quiénes son los grupos de interés que se verán afectados por el proyecto. Un error muy habitual en la gestión de los proyectos de innovación es creer que solo tenemos dos públicos objetivo: los clientes o jefes, que pagan el proyecto y el equipo del proyecto. Error. Aquí tienes un conjunto de los diferentes tipos de públicos con los que deberás planificar la comunicación del proyecto:

– Clientes (internos, los jefes; externos, la dirección / propiedad de la empresa). En definitiva, el que paga. Le interesa conocer cómo va el proyecto en grandes titulares (retrasos, cumplimiento de objetivos, desviaciones, barreras…). Es imprescindible una reunión de kick-off (o inicio de proyecto) y otra de cierre. Con un informe de seguimiento periódico (semanal o mensual, depende del tamaño del proyecto) y reuniones para toma de decisiones clave (lanzar o no lanzar el desarrollo del proyecto, y las stage – gate de las que hemos hablado aquí) sería suficiente. Una reflexión interesante: en los proyectos de I+D europeos, los clientes son los project officers y las reuniones de seguimiento existen, además de los informes. Hay que tratarlos no como auditores, sino como clientes que quieren conocer el resultado de su «inversión» (aunque sea con dinero público). Este cambio de enfoque es fundamental, porque nos hace adoptar una posición proactiva en lugar de reactiva. Si has participado en algún proyecto europeo, seguro que te sonará lo que estoy diciendo.

– Equipo de proyecto. Por supuesto, todas las personas involucradas en tareas de proyecto deben conocer el estado del proyecto y deben participar activamente en las discusiones y tomas de decisiones. El nivel de información es de mucho más detalle, sobre la actividad diaria del proyecto. Son imprescindibles reuniones semanales de seguimiento y actualizaciones de los planes. Las actas de la reunión pueden ser la actualización de la planificación del trabajo.

– Usuarios. En casi todas las ocasiones nos olvidamos de las personas que tendrán que ejecutar el nuevo proceso de trabajo o lanzar al mercado el nuevo producto. Dentro de los usuarios, yo distinguiría dos niveles: el nivel directivo, es decir los responsables de los departamentos que se verán afectado por el proyecto y los propios usuarios, los técnicos que lo utilizarán. La forma de tratarlos es diferente. Con los directivos debemos tener en cuenta que vamos a «tocar» su área, que el proyecto puede afectar, a peor, los resultados a corto plazo, que vamos a utilizar recursos de su departamento y que vamos a cambiar su forma de trabajar. En definitiva, que vamos a ser un incordio para ellos y les vamos a tocar las narices. Son uno de los elementos clave que debemos tener de nuestro lado, especialmente en proyectos de implantación de tecnología o consultoría. En este sentido, debemos trabajar con ellos en la distancia corta, en el uno a uno, gestionando las «politics».  Comentarles previamente las acciones, la disponibilidad de sus recursos para el trabajo e incluir, cuando sea posible sus sugerencias en el proyecto es una forma de reducir su resistencia al cambio.

Una vez conseguido el apoyo, o por lo menos, evitar los palos en las ruedas, de los directivos de las áreas de usuarios, hay que enfocarse también en los técnicos que utilizarán los resultados del proyecto. En mi experiencia profesional, a la hora de reducir la resistencia al cambio de los técnicos (una de las claves para el éxito o fracaso del proyecto) es fundamental centrar la comunicación en dos puntos: por qué es necesario el cambio y cuál será su papel en el nuevo escenario. En el caso de que empeoren sus condiciones de trabajo (más horas, más velocidad de máquina, más presión…) podemos argumentarlo con el primer punto, por qué es necesario el cambio. Un ejemplo: hace años dirigí un proyecto de implantación de la historia clínica informática en una empresa sanitaria, con muchos doctores seniors. La resistencia al cambio por los técnicos (los médicos) era absoluto, ya que suponía cambiar su forma de trabajar y de pasar consulta. Para superar la resistencia al cambio organizamos varias sesiones previas con los médicos en las que explicábamos los motivos del cambio, los ahorros en tiempo en búsqueda de información y la disponibilidad incluso en su casa de la información de los pacientes. Y permitimos que los doctores hicieran sugerencias sobre detalles de las pantallas, lo que les hizo aceptar de mejor grado la aplicación.

Herramientas de innovación para superar la resistencia al cambio

Como decía al principio, yo utilizo una herramientas de innovación muy sencilla, en excel, como plan de comunicación. Os pego aquí un ejemplo (ojo, no está completo a propósito), para que podáis utilizarla si lo creéis interesante.

[hr]

[hr]

[related_posts limit=»3″ image=»30″]