¿Por Qué Debería Confiar en Ti? (con Mike Clayton de OnlinePMCourses)

Lee la transcripción:

Estamos probando la transcripción de nuestros pódcast utilizando un programa de software. Por favor, disculpa cualquier error, ya que el bot no es 100% exacto.

Ben Aston:

En Los Siete Hábitos de la Gente Altamente Efectiva, Stephen Covey escribe que la confianza es el pegamento de la vida. Es el ingrediente más esencial en la comunicación efectiva. Es el principio fundamental que sostiene todas las relaciones, y como gestores de proyectos, contar con la confianza de nuestros clientes, equipos y jefes es fundamental.

Es fundamental para nosotros al entregar nuestros proyectos porque tener la confianza significa que podemos avanzar con nuestro trabajo, podemos dedicarnos a la entrega de proyectos sin tener que convencer constantemente a la gente de hacer lo que queremos que hagan.

Pero la confianza es algo que podemos dar por sentado y rara vez pensamos en ganarla, mantenerla o, quizá lo más importante, cómo podemos perderla. Así que sigue escuchando el pódcast de hoy para descubrir cómo puedes construir y desarrollar la confianza para facilitar la gestión de tus proyectos.

Gracias por sintonizar. Soy Ben Aston, fundador de The Digital Project Manager. Bienvenido al Podcast DPM. Nuestra misión es ayudar a los gestores de proyectos a tener éxito, a que quienes gestionan proyectos los entreguen mejor.

Estamos aquí para ayudarte a llevar tu nivel de gestión de proyectos a lo más alto. Visita thedigitalprojectmanager.com para conocer las formaciones y recursos que ofrecemos a través de la membresía. Este pódcast está patrocinado por Clarizen, el líder en software de gestión de portafolios y proyectos empresariales. Visita clarizen.com para más información.

Hoy estoy acompañado por Mike Clayton. Mike es doctor y fundador de onlinepmcourses.com, una web que proporciona cursos, herramientas y recursos para gestores de proyectos en todas las etapas de su carrera. Mike tiene muchos cursos disponibles, también ha escrito 14 libros impresos y durante 12 años fue PM en Deloitte. Hola Mike, gracias por acompañarnos hoy.

Mike:

Ben, buenas tardes. Es un placer estar aquí y feliz año nuevo.

Ben Aston:

Muchas gracias. Entonces Mike, quiero preguntarte para comenzar, ¿qué hay de nuevo para ti? Es un año nuevo, es 2020, ¿qué hay de nuevo para ti?

Mike:

>Muchas cosas en marcha. Ante todo, he decidido que mi principal enfoque para este año será mi canal de YouTube. Algunos de tus oyentes quizá sepan que tengo un canal de YouTube para mi curso de PM online que se ha vuelto mucho más exitoso en los últimos 12 meses, he visto ese crecimiento y he decidido invertir mucho más tiempo allí.

Al final del otoño, pasé de publicar un vídeo por semana a dos, y ahora pretendo continuar así durante todo el año e invertir también en vídeos más grandes y mejores. Por otro lado, también estoy lanzando otro canal de YouTube.

¿Dos canales de YouTube? Sí, porque desde hace tiempo veo que, como gestores de proyectos no sólo administramos nuestros proyectos, también gestionamos a las personas en ellos, y para los gestores de proyectos jóvenes, adquirir conocimientos sobre habilidades básicas de personas es difícil.

No todos tienen la suerte de recibir cursos a través de su empleador y hay mucho material en la web, pero es caro si ves todas las disciplinas de gestión y mucho en YouTube, pero muy desarticulado.

Así que Management Courses, mi nuevo canal, estará dirigido a ofrecer formación en gestión estructurada para cualquiera, pero será especialmente apropiado para jóvenes profesionales y gestores de proyectos sin experiencia en management. Así que se avecina un año ocupado.

Ben Aston:

Parece un buen año, suena a que vas a estar a tope y... Pero quiero volver a algo... Obviamente ahora eres formador, pero no decidiste de repente serlo, primero pasaste un tiempo trabajando “en las trincheras”. Así que, ¿puedes contarme cómo fue tu primer día como gestor de proyectos, cómo llegaste a ello y cómo fue ese inicio?

Mike:

Probablemente no soy el único. Es muy difícil precisar cuál fue mi primer día como gestor de proyectos porque mi primer día en la carrera que me llevó a la gestión de proyectos, mi jefe habría dicho: "Mike no hace gestión de proyectos." Y poco a poco fui ampliando lo que hacía hasta que cualquiera diría, eso es gestión de proyectos.

Pero, supongo que mi... Pienso que el primer día como gestor de proyectos fue cuando trabajaba en un proyecto, era miembro del equipo, hacíamos un proyecto muy especializado y el líder del proyecto no era gestor por formación.

Era un especialista técnico en el tema sobre el que ayudábamos a los clientes a gestionar su proyecto y claramente no escuchaba al cliente, quien se frustró mucho. Cuando regresamos a la oficina quería seguir igual, y tuve que hablar con uno de mis colegas sénior de confianza y decirle que creo que estamos a punto de perder al cliente.

Tras conversar con el cliente, él identificó que sólo una persona de nuestro lado realmente captaba lo que decía: necesitaba a alguien que gestionara el proyecto, no expertos técnicos. Ya tenía muchos en su organización. Y fue muy específico diciendo que quería que yo gestionara el proyecto, ya que era el único que realmente entendía lo que necesitaban.

Así que al día siguiente, ignoré al miembro más sénior del equipo según la jerarquía organizacional; yo era consultor en Deloitte entonces, pero desde ese momento era oficialmente el gestor del proyecto y tenía todas esas responsabilidades sobre mis hombros, con un equipo... Algunos de los cuales, por ser más sénior en la organización, no querían recibir instrucciones mías. Pero el cliente fue claro y, en consultoría, el cliente manda.

Ben Aston:

Sí, totalmente. Entonces, ¿qué le dirías a tu yo más joven mirando atrás a ese primer día en que pasaste de ser miembro del equipo a ser quien gestiona el proyecto, aunque no tuvieras el título de Project Manager? ¿Qué consejo te darías a ti mismo? Para cualquiera que recién comience como PM y se vea en esa situación...

Mike:

Creo que lo que más debía aprender era que, al asumir el rol de gestor de proyectos, debes dejar de lado el deseo de ocultarte en los detalles técnicos en los que eres bueno. Independientemente de si vienes de ingeniería de software, arquitectura, mantenimiento de producto o como ingeniero de obra, una vez que lideras un proyecto, lo técnico pasa a un segundo plano respecto a tu responsabilidad con el proyecto. Eso significa que no puedes hacer lo que hice un tiempo, que era concentrarme exclusivamente en mi área técnica, respondiendo preguntas de colegas o clientes, deseando volver a lo mío, porque ya no es tu trabajo.

Tu trabajo ya no es sólo hacer cosas. Sí, hay cosas que hacer, pero tu tarea principal es gestionar el proyecto y liderar al equipo. Todo lo demás es secundario. Tu éxito depende de cómo lideres a las personas, y si no tienes tiempo para hacer tu parte, debes buscar soluciones que no impliquen que tú lo hagas todo, sino que signifiquen delegar y gestionar, más que ser el especialista, que es donde muchos estamos más cómodos al pasar a gestión de proyectos.

Ben Aston:

Sí, totalmente. Es fácil volver a esas habilidades técnicas que nos trajeron al sector. Así que, empatizo totalmente. Ahora, en tu experiencia gestionando tus propios proyectos y ahora que tienes una consultoría de formación, ¿qué tenías en tu "caja de herramientas" como PM y qué sigues usando ahora? ¿Cómo manejas toda la locura de tantos proyectos y canales de YouTube?

Mike:

Me alegra que uses la expresión "caja de herramientas" porque cuando hablo de gestión de proyectos y formación, pienso en dotar a las personas de herramientas, porque, sea lo que sea, nadie puede enseñarte exactamente lo que necesitarás, porque cada situación es distinta y la aproximación de cada uno a la situación también.

Como formador solo puedo darte el mayor conjunto de herramientas posible para que tengas la mayor flexibilidad. Así que la pregunta no es qué tengo en mi caja de herramientas, porque espero (y realmente es grande), sino qué utilizo más. Creo que, para quienes inician en la gestión de proyectos, la herramienta que más necesitarán pero que más les costará usar es el grupo de herramientas relacionadas con el involucramiento de los interesados.

De verdad, averigua qué quieren tus clientes, usuarios o aquellos a quienes impactas, mantente en contacto, infórmales, porque vamos a hablar de confianza en la gestión de proyectos, y eso es clave.

Otra cosa que me preguntaste es cómo controlo la locura. Tengo una disciplina bastante estricta de gestión del tiempo personal, basada en los fundamentos tradicionales de la gestión de proyectos. Uso lo que llamo el proceso "oats" (avena) para administrar mi tiempo. Pienso en los resultados (outcomes) que necesito lograr en el próximo día o semana, qué actividades (activities) debo hacer, cuánto tiempo llevarán (time), y después lo planifico (schedule), por eso lo llamo oats. Me ha funcionado muy bien, suelo planificar la semana por anticipado, así comienzo el lunes sabiendo lo que tengo que lograr y, a grandes rasgos, qué haré cada día en bloques de media jornada.

Ben Aston:

Correcto.

Mike:

Así sé qué hacer, cuáles son las prioridades.

Ben Aston:

Me resulta interesante porque creo que muchos PMs batallan con esto de estimar tiempos. Cuando tenemos muchas actividades por lograr y gestionamos varios proyectos, ¿cómo gestionas el hecho de que algo lleve más tiempo del que esperabas? Si planificas toda la semana y el martes una tarea programada para media jornada te ocupa todo el día y aún no terminas, ¿cuál es tu proceso de "triaje"?

Mike:

En mi planificación semanal, aplico el mismo proceso que usé en proyectos de clientes. Siempre presumo que nunca he entregado un proyecto tarde y he liderado algunos muy grandes y exigentes en tiempos. Supongo que eso se debe a que me especialicé en proyectos críticos en plazos.

Hice carrera entregando el "proyecto año 2000". Si llegábamos diez minutos tarde era desastroso para el cliente. Lo que hago es, basado en el principio de cadena crítica, planifico todas las tareas necesarias y dejo un bloque de tiempo al final de la semana que llamo "islas de estabilidad" donde no programo tareas críticas, sólo papeleo. Así, si algo se retrasa, uso ese tiempo como cortafuegos. Por ejemplo, no programo nada salvo administración para la tarde del viernes.

Ben Aston:

Correcto.

Mike:

Eso me permite, si todo va bien, terminar el viernes con todo resuelto. O si me siento virtuoso y cansado, tomarme la tarde libre. Pero si algo sale mal, puedo terminar el asunto atrasado ese viernes, o reprogramar, usando el viernes como buffer.

Así, a menos que ocurra algo desastroso, nunca llego al fin de semana sin cumplir lo planeado. Y tienes razón sobre la estimación, es la disciplina más difícil de la gestión técnica de proyectos y creo que se enseña poco. Me preocupa la tendencia del hashtag "no estimates" porque siguen siendo necesarias. No se trata de no estimar, sino de calibrar el grado de precisión según lo que se necesite estimar.

Un consejo es que todos pensamos que lo haremos más rápido que nuestros colegas. Así que, si gestionas tu tiempo, en vez de preguntarte cuánto tardarás en escribir el informe, compáralo con tu colega que hace algo similar. Suele ser una estimación más realista que la tuya propia; tendemos a sobrevalorarnos. Puedes sentirte afortunado si lo terminas antes, pero la probabilidad de ser mucho más rápido que un colega calificado es baja. Ese es mi truco.

Ben Aston:

Eso está genial. Me gusta tu idea del "cortafuegos" al final de la semana y que sea administración lo que sacrifiques si algo va mal, ya que muchas veces lo primero que dejamos de hacer bajo presión es el control y gestión del proyecto.

Vamos a hablar sobre la confianza en un momento. Pero, ¿qué ocurre cuando las cosas empiezan a descontrolarse? A veces, el gestor ni siquiera es consciente de que el proyecto va mal y está diciendo al cliente: “Sí, va todo bien” sin la visión global.

Gestionar el tiempo para poder controlar el proyecto y construir confianza e integridad en lo que decimos es clave. Así que, volviendo a tu artículo sobre gestión de la confianza, hablas de que la confianza es igual a la suma de la credibilidad, más la fiabilidad, más la intimidad con la otra persona, todo ello dividido por la orientación al yo. ¿Puedes resumir esa ecuación y por qué crees que es válida?

Mike:

Primero quiero aclarar que, aunque la compartí con tus lectores, no la inventé. El mérito es de David Maister y sus coautores Charles Green y Robert Galford, quienes escribieron el excelente libro "The Trusted Advisor". Maister se especializa en libros para quienes ofrecen servicios profesionales.

Si eres gestor de proyectos y ves tu rol como un servicio, incluso interno, mucho de lo que dice merece la pena. Creo que "The Trusted Advisor" es su libro más conocido y realmente se me quedó grabado; tengo tres de ellos en mi estantería, aunque no me pidas los títulos exactos.

El libro se centra en que, si vas a aconsejar a alguien —y los gestores de proyectos lo hacen a clientes, patrocinadores, jefes, a la gobernanza de la empresa— necesitas su confianza.

Analizan cuáles son los componentes de la confianza: primero, solo puede haber confianza si tienes credibilidad, si realmente creen que sabes de lo que hablas.

Y para nosotros los PM, eso implica dos cosas: tener conocimientos y experiencia en gestión de proyectos, incluido si tienes titulaciones (una de mis mayores frustraciones fue no certificarme con el PMP cuando Deloitte podía patrocinármelo, que apenas era un libro de 170 páginas). Los títulos, del tipo que sean, acreditan credibilidad. Pero también debes tener credibilidad respecto al tema del proyecto, aunque como profesional nunca fui el experto técnico del contenido, así que se trata de saber vincularte con el equipo para suplir ese conocimiento.

Después, la fiabilidad. Muchos PM dirán “Eso es lo nuestro: cumplir lo que decimos, programar, entregar; somos gente que hace que las cosas ocurran”. Y es cierto.

Así que esto debería ser fácil para nosotros. Pero el problema es que la fiabilidad no es cuán fiables somos, sino cuán fiables nos perciben los demás. Si trabajas duro pero no hablas con tus interesados, ellos se preguntan qué sucede.

Ben Aston:

Correcto.

Mike:

Tú sabes que haces todo bien y todo va según lo previsto, pero si tus partes interesadas no saben nada, piensan que va mal. La fiabilidad es demostrar que realmente estás haciendo lo que dices. La comunicación es vital para establecer esa fiabilidad y tranquilizar a tus interesados.

En ambientes de cambio, la gente se asusta fácilmente si no sabe qué pasa y el peor error es dejar que la incertidumbre dé lugar a rumores. Dar información confiable es parte clave de la fiabilidad.

Ben Aston:

>Un aspecto de esa fiabilidad es la percepción: aunque seamos fiables, esa percepción depende también del equipo u organización. Puede que programemos bien, pero si surge otro proyecto más importante o hay problemas de recursos, la fiabilidad global se ve afectada, aunque no sea culpa directa nuestra.

Mike:

Totalmente de acuerdo, ahí está el fondo de nuestro trabajo como PM: solucionar esos problemas, no decir “no es mi culpa”. Eres el gestor del proyecto. Quizá no sea culpa tuya, pero sí tu responsabilidad: tienes que buscar soluciones y usar tus habilidades de comunicación para escalar el problema y lograr colaboración.

A veces simplemente no se puede, sobre todo con proveedores terceros con intereses propios, pero tu trabajo es intentarlo y la fiabilidad también depende de cómo comunicamos lo que va mal. Cada parte interesada tendrá en cuenta tu fiabilidad también por cómo los enfrentas a los problemas: ¿pueden confiar en la información que les das? ¿Les explicas claramente?

La fiabilidad es fundamental, seguirá siendo parte de la conversación. Ahora, la intimidad. No lo tomes por el lado equivocado: no es tener una relación íntima personal, sino el nivel en que pueden compartirte información.

Primero, que puedan confiarte sus necesidades de negocio. Segundo, que te incluyan en sus aspiraciones profesionales y en lo realmente importante de ese proyecto. Y, con el tiempo, incluso más allá, como lo que valoran de la vida. Así, cuanto mejores relaciones forjes, mayor será la confianza.

El cuarto elemento es la orientación al yo. Lo definen como el grado en que nos movemos por intereses propios. No seamos ingenuos: ninguno trabaja solo por espíritu altruista, también buscamos satisfacción y un sueldo. Pero si actúas —o pareces actuar— por motivación egoísta (si creen que comprometes tu integridad por beneficio propio), la confianza disminuye drásticamente. Maister y cía eligieron dividir la suma por la orientación al yo para que cuanto más aumenta esta, más disminuye la confianza global.

De nuevo, es cuestión de percepción: aunque estés motivado por los intereses del cliente, si sospechan de tu orientación egoísta, tu confianza baja. Debes mostrar integridad y explicar cómo tus acciones buscan siempre el beneficio del cliente y las partes interesadas; no el camino fácil para ti.

En resumen: la confianza depende de tu integridad, la relación que construyas, que cumplas lo que prometes y que demuestres que sabes lo que haces. ¿Por qué creo que la ecuación es válida? Porque para mí es obvio que esos factores son fundamentales en cómo confío y generan confianza.

Ben Aston:

Sí. Es una forma muy clara de ver los componentes de la confianza y creo que la intimidad/transparencia es especialmente interesante. Se trata también de apertura y comprensión de los objetivos de la otra persona y del negocio, de qué necesita lograr para que el proyecto sea un éxito.

Así que pensar cómo ser más creíbles, fiables, transparentes, cercanos, y asegurarnos de buscar el beneficio del cliente (y del usuario final)... Ahí es donde se construye la confianza. ¿Tienes alguna historia donde hayas experimentado menor confianza y su impacto? ¿Por qué es tan importante, más allá de lo supuesto?

Mike:

Sí, lo sé por experiencia. Me asignaron a un proyecto con plazo ajustadísimo. El anterior PM (entonces se llamaba "director de lanzamiento") no era bien visto y a mí me pusieron después de haber entregado con éxito lo del año 2000.

Pero muy poco después de mi incorporación, surgieron problemas importantes y me llamaron ante el cliente y directivos de mi firma. Uno, muy interesado en que su equipo técnico no cargara con la culpa (que en retrospectiva sí tenían), trató de hacerme de chivo expiatorio. El verdadero problema fue que no me había dado tiempo ni a generar credibilidad ni intimidad suficiente. Por tanto, no podían confiar realmente en mi fiabilidad cuando decía que solucionaríamos los problemas heredados. No sé cómo percibían mi orientación al yo, pero está claro que necesitas tiempo para afianzar la confianza, no basta con tener éxito en otros proyectos ni títulos en la puerta.

No había tenido tiempo para crear esa relación, y acabé soportando la culpa, tardando mucho en recuperar confianza y reconducir el proyecto. Curiosamente, fue justo antes del lanzamiento, cuando el director financiero del cliente me invitó a comer: cuando hacen eso es porque tienen algo importante que decirte. Ahí vi que sí había recuperado su confianza y pudimos juntos afrontar un gran problema interno. Así que no es que no pudiera afianzar ese vínculo; es que lleva tiempo.

Ben Aston:

Claro.

Mike:

Con razón a la gente le lleva tiempo confiar. Mi consejo para gestores jóvenes: trabaja en la confianza desde el primer día. Si al segundo no la tienes, no significa que no seas buen PM, simplemente, para ese interesado va a tardar más. Y puede que tarde más de un mes. Debes estar siempre atento porque cualquier cosa, incluso fuera de tu control, puede minar la credibilidad, fiabilidad, intimidad u orientación percibida y debes reaccionar rápido para corregir.

Ben Aston:

Totalmente. Yo también he estado en situaciones sin confianza, por ejemplo en trabajos por horas con el cliente. Debe haber confianza en el buen trabajo, porque si no, cuando facturas, el cliente sospecha. Aunque le envíes reportes semanales, empieza a dudar, solicita explicaciones, y se pierde tiempo en reuniones para justificar horas. Es muy frustrante para todos y ocurre sólo por falta de confianza.

En tu artículo hablas de construir confianza: escuchar al cliente, mostrar que entiendes, visualizar lo que podéis lograr juntos y comprometerte a tu parte. Pero en el ejemplo que he dicho: empiezas con un cliente que, porque ha tenido malas experiencias, desconfía desde el primer día. ¿Cómo abordar esa conversación para recuperarlo?

Mike:

Lo principal es reconocer que si no lo gestionas, la relación sólo irá a peor. Siempre empiezo reconociendo la falta de confianza: "Parece que no confías del todo en estas cifras y lo entiendo. Reconozco que debemos reconstruir la confianza."

Ben Aston:

Correcto.

Mike:

Nombra el problema. Puede que te responda: "En realidad sí confío, pero tengo a alguien detrás presionando", lo que cambia el contexto y te convierte en aliado. Así que declara la brecha de confianza. Después, expresa tu objetivo: "Quiero demostrar que merezco tu confianza, mostrarte dónde tu percepción puede no ser correcta o, si hemos cometido errores, asumirlos y encontrar una solución".

Después, pídeles que expresen qué quieren de este proceso. Pueden pedirte sólo documentos o pueden querer recuperar también una relación de confianza. Si los objetivos coinciden, la brecha ya empieza a cerrarse.

Después, presenta los hechos y compártelos. Asegúrate de entender su versión de los datos y compárala; así logramos un acuerdo sobre hechos documentados.

Ese no es el final, porque la confianza es percepción, no datos, pero es la base. Y si descubres que, efectivamente, se cobró de más, debes comprometerte a solucionarlo: "Vamos a eliminar ese cargo y, por buena voluntad, daremos además un extra..." Así generas compromiso y pides el suyo también. Si no sirve, pregunta qué falta y busca opciones. Si logran un acuerdo, haz un plan y comprométete a cumplirlo.

Lo esencial es cumplir el plan, porque ahí puedes mostrar la fiabilidad. Yo siempre digo: no es la ausencia de errores lo que define una organización o PM, sino cómo responde a los errores. Todos tenemos experiencias de clientes con organizaciones que, tras cometer un error, reaccionan mal y se entierra aún más el problema, perdiendo la confianza de todo el entorno. Pero también de compañías que reconocen el fallo y van más allá para corregirlo. Como PM, tienes que ser de las que lo afrontan bien: reconocer errores y solucionarlos incluso si sólo son percibidos.

Por último, más importante que demostrar que tienes razón es dejar la buena sensación. Si haces sentir mal al cliente por querer tener razón a toda costa, simplemente no confiara en ti. Pero si reconoces su disgusto, lo asumes y le das una pequeña victoria, entonces empezará a confiar de nuevo.

Ben Aston:

Creo que es un consejo sólido. A veces caemos en el error de ganar la discusión rápida mientras erosionamos la confianza. Lo crítico es ver el panorama general de la relación con el cliente. Si queremos mantener la relación más allá de una sola transacción, vale la pena invertir en confianza.

Mike:

Sí.

Ben Aston:

Y creo que en digital especialmente, por el tipo de trabajo puntual que hacemos, podemos a veces no valorar la confianza como deberíamos. Es muy útil pensar cómo podemos construir credibilidad, fiabilidad e intimidad con el cliente y orientarnos a que perciban que somos fiables y dignos de confianza. Gracias, Mike, por acompañarnos hoy y compartir tu experiencia.

Mike:

Ha sido un placer.

Ben Aston:

¿Y tú qué opinas? ¿Cuáles son tus trucos y consejos para construir confianza? Si tienes historias de éxito o fracaso en relaciones de confianza, déjanos tus comentarios abajo y por favor deja también una reseña en Apple Podcasts.

Nos encanta saber tu opinión sobre el programa y, si quieres avanzar en tu carrera, únete a nuestra comunidad con la membresía DPM en thedigitalprojectmanager.com/membership, donde tendrás acceso a nuestro equipo en Slack, plantillas, talleres, "office hours", ebooks y mucho más... Hasta la próxima, ¡gracias por escucharnos!