Malas noticias: notas del producto

Estas notas del producto forman parte de nuestra colección "Desde las trincheras". Aquí se describe de qué manera los jefes de proyecto pueden compartir malas noticias sobre sus proyectos de manera más eficaz y con el menor daño para ellos mismos.

Para descargar la versión de Word de estas notas del producto, vea Último momento, malas noticias: notas del producto.

Para ver más notas del producto, vea las notas del producto de la colección "Desde las trincheras".

Último momento: malas noticias

Siguiendo un artículo (Cancelar un proyecto sin cancelar su carrera: notas del producto) que realicé hace un tiempo, recibí numerosos comentarios de jefes de proyecto que me expresaban su preocupación por compartir malas noticias sobre sus administraciones. Uno me dijo "No importa cuáles pueden ser los posibles beneficios, si comparto noticias tan malas arruino mi carrera".

No importa cuál es su entorno de trabajo, aparentemente algunas personas son mejores para comunicar malas noticias que otras. En el caso de los jefes de proyecto, poder compartir buenas noticias y malas noticias es parte de la descripción del trabajo. Por tanto, analicemos un momento la forma en que un jefe de proyecto puede compartir malas noticias de manera más eficaz y con el menor daño para ellos mismos.

Reciba todas las noticias antes de compartirlas

La primera lección y la más importante es asegurarse de que tiene la noticia completa. Cada vez que un miembro del personal se acerca a mí con algunas noticias molestas inevitablemente me surgen preguntas. Si no se han tomado el tiempo ni siquiera de considerar qué preguntas puedo formular y cuáles son las respuestas, es irritante. Por lo tanto, antes de apresurarse a ir en busca de su jefe a preguntarle cómo se cae el cielo, asegúrese de detenerse un momento para obtener todos los hechos. ¿Está seguro de que la información que tiene es completa? ¿Es precisa? ¿Hay circunstancias atenuantes? ¿Sabe cómo se produjo esta mala noticia? ¿Es una condición temporal o algo más permanente? ¿Tiene una evaluación del impacto de esta noticia?

¡Vaya! Aún no hemos atravesado la marca de salida y ya tenemos una lista de tareas pendientes. No hay nada más molesto para una persona que se ocupa de la administración que alguien de su equipo deje un problema en su escritorio pero sin saber aún si se trata de un problema o no. Debe ser fácil poder determinar las preguntas iniciales que pueden surgir a partir de las malas noticias, por lo que lo mejor es responderse a usted mismo antes de empezar a compartir las noticias.

El pensamiento de avestruz no es productivo

Como los avestruces que esconden la cabeza en la arena ante la primera señal de peligro en la esperanza de que va a desaparecer, algunos jefes de proyecto evitan las malas noticias a toda costa. Evitar las malas noticias rara vez es productivo. De hecho, porque no todas las noticias son buenas los jefes de proyectos deben realizar primero un trabajo. Si todos los proyectos siempre funcionaran de la forma en que se planifican, ¿por qué tendríamos jefes de proyecto? Así que aunque aún no esté listo para compartir las malas noticias no significa que no deba compartirlas en absoluto.

¿Quién es el responsable?

Probablemente esta sea la pregunta menos valiosa y la respuesta seguramente tampoco tenga mucho valor. Sin embargo, muchas personas apuntarán con un dedo a otra como reacción ante la molestia que va a provocar la mala noticia. Alejarse de la culpa le permitirá centrarse en "¿qué sucedió?" y "¿qué debemos hacer a continuación?" en lugar de "¿A quién puedo echarle la culpa de este problema?".

¿Es una mala noticia? ¿Está seguro?

Recientemente uno de mis colaboradores apareció en mi oficina y me informó que debido a limitaciones en los recursos no podríamos satisfacer las expectativas de un cliente que quería varios días de cursos fuera del horario comercial. "¿Nos comprometimos a hacerlo?" le pregunté. Se produjo una larga pausa. El miembro del personal no estaba seguro y resultó ser una pregunta clave. No. Nunca habíamos prometido hacer ese curso. El cliente tenía un deseo de hacerlo pero aún no había pasado por los canales apropiados para programar el curso. En realidad resultó ser que no había necesidad de compartir esa mala noticia y que la acción apropiada era ponerse en contacto con el cliente para programar el curso para una fecha futura.

Problema resuelto.

Un problema normalmente se expresa de esta forma: "Se esperaba esto pero ocurrió esto". A veces, simplemente la semántica puede hacer que piense de manera diferente. Pruebe esto: "Se esperaba esto y ocurrió esto" ¿Hay un conflicto? Quizá no, pero es saludable empezar por ver si se ha roto un compromiso. Si no, quizás no se trate de un problema.

Un resquicio de esperanza

Cuando algo inesperado sucede a menudo hay un impacto o consecuencias como resultado. Si pausa o cancela un proyecto, por ejemplo, una cosa que casi siempre ocurre es que tiene recursos adicionales que no se esperaba que pueda asignar a otro trabajo. Pausar un proyecto puede tener el resultado de volver a centrar más esfuerzo en otro trabajo más crítico.

Cuando tiene que compartir malas noticias, es normal que vea todo lo que lo rodea a través del filtro de "está todo mal", pero rara vez eso es cierto. Algunos efectos de las malas noticias serán buenos y eso se lo debe a su administración o a su cliente o a la persona con la que tenga que compartir no solo el impacto malo, sino también lo bueno.

Mitigación

Supongamos que tiene algunas malas noticias. Una cosa que vale la pena hacer antes de compartirlas es emplear algunos factores de mitigación. Es posible que el proyecto siga una programación. Eso es una mala noticia. Pero, si ya había ocultado algunas reservas de administración en la programación (como hacen muchos buenos directores de proyecto) entonces quizás puede ponerse al día en la programación durante ese período. Las malas noticias se atenúan, se neutralizan.

La mitigación también permite pensar en posibles soluciones para el problema antes de compartirlo. Los administradores apreciamos las descripciones de problemas que se entregan al mismo tiempo con una lista de posibles soluciones. A veces estas soluciones se convierten en oportunidades para abrir una nueva línea de pensamiento. Hace algunos años, yo estaba trabajando con una gran empresa de software y en el medio del desarrollo de su siguiente versión principal, se determinó que necesitaban recortar una función de alto nivel en el ámbito. Eso era una mala noticia. Si no se tomaba ninguna acción más, lanzarían su siguiente versión y sería mucho menos funcional que muchos de sus competidores. La empresa seleccionó uno de los varios planes de mitigación y entró en el mercado y compró una compañía que tenía exactamente la funcionalidad que le faltaba. ¿El resultado final? La compañía cumplió con la fecha de entrega en el mercado, tuvo la funcionalidad apropiada y, además debido a la adquisición, contó con un equipo de personal altamente cualificado que les permitió aprovechar esta funcionalidad para dar un salto cualitativo en el catálogo de soluciones.

Problema resuelto.

La presentación es poder

Como jefes de proyecto a menudo lamentamos que tenemos toda la responsabilidad y nada de autoridad. Después de todo, es raro que se le informe directamente a un jefe de proyecto todos los recursos del proyecto; sin embargo, es el jefe de proyecto a quien nos dirigimos para preguntarle sobre el progreso del proyecto.

Si bien los jefes de proyecto pueden tener poca autoridad, hay algo que controlan que es aún más impactante; controlan la presentación de la información y controlar la presentación es clave.

¿Es extraño que lo llamamos "Power"Point (punto de poder)? La forma en la que se muestra algo puede hacer la diferencia. Hace algunos años, los cineastas Stephen Spielberg y George Lucas compraron un antiguo simulador de vuelo y se asombraron al determinar que el cuerpo humano puede detectar un cambio en el tono (el ángulo en el que está parado) de menos de medio grado. Cuando aumenta por las indicaciones visuales, la mente rellena ellos espacios y el cuerpo reacciona como si el evento estuviera sucediendo realmente aunque es simplemente una planta, una inclinación y una película con algo de sonido.

Los pilotos en entrenamiento que usan un simulador de vuelo tendrán las mismas reacciones corporales (frecuencia cardíaca, respiración, adrenalina, etc.) en una emergencia del simulador que en una emergencia real.

¿Cuál fue el resultado de la investigación de Spielberg y Lucas? El juego Star Tours en Disney World.

Del mismo modo, un jefe de proyecto controla la visualización en pantalla. Muestre una línea de tendencia en lugar de una tabla de cifras y el ojo seguirá la tendencia por su propia cuenta y la mente sacará sus conclusiones.

Los jefes de proyecto controlan normalmente todos los elementos de cómo se muestran los datos. Mostrar datos de paneles o datos analíticos o datos en un formato de gráfico junto con simples viñetas en una diapositiva puede hacer una gran diferencia.

En una contratación reciente he tenido que explicarle al cliente que su volumen de trabajo actual era casi el doble del tamaño de sus empleados y que ninguna clasificación por prioridades daría como resultado que el trabajo se realice a tiempo. Sin embargo, antes de darle esa mala noticia, dediqué tiempo a profundizar en los datos del trabajo que ya se había realizado. Extraje los volúmenes de los datos de la planilla de horas trabajadas a Excel y comencé a realizar gráficos. Por último, un gráfico circular reveló una importante pepita de oro. Se estaba dedicando un porcentaje increíblemente alto de trabajo en mantenimiento de TI. Al examinar aún más determiné que gran parte de este trabajo podría evitarse mediante decisiones estratégicas (por ejemplo, proporcionar soporte técnico de una cantidad elevada inusual de productos de bases de datos y versiones) o a través de la restricción de una práctica de permitir la subdivisión de los proyectos en pequeños mandatos que se pueden controlar operativamente a través de una solicitud de soporte técnico. La organización había tenido tantos desafíos para lograr completar el trabajo que muchos líderes de los equipos habían aprendido a subdividir los proyectos de 30, 40 o incluso 60 días de duración en segmentos de 3 días que lograrían mediante una llamada al servicio de asistencia. Esto era tan común que había tanto trabajo de proyecto no autorizado realizado de esta forma como el realizado a través de la oficina de administración de proyectos real. Al detener esta práctica, los PMO pudieron renovar sus conocimientos en las solicitudes de proyectos y el volumen de solicitudes disminuyó significativamente.

Los datos siempre habían estado allí. Muchos ya conocían esta práctica pero hasta que no mostramos el sector del gráfico circular de un gráfico, nadie era consciente de lo impactante que era la práctica. De hecho, la administración se impresionó con los números.

La perspectiva cuenta

Es importante que no permita que la urgencia del momento o la preocupación sobre cómo compartir las malas noticias nublen su perspectiva. Es fácil dejarse atrapar por el enojo del momento pero si no lo hace, si mantiene la frialdad, puede convertirse en la voz de la razón en un día que de lo contrario sería muy molesto. He usado los siguientes dos gráficos durante años para demostrar la diferencia de perspectiva del director financiero frente al jefe de proyecto y los posibles efectos dramáticos de no ampliar la vista con la que se muestra la información.

Esta es la perspectiva del director financiero:

Vista del director financiero que muestra información de alto nivel

Y esta es la perspectiva del jefe de proyecto:

Vista del Administrador de proyectos que muestra el estado del proyecto durante un período de tiempo más largo

El primer gráfico es de un proyecto que ha sobrepasado su presupuesto previsto hasta la fecha. El presupuesto planeado fue acordado por todas las partes y en el día de hoy el director financiero tiene un muy mal día. El proyecto ha superado claramente su presupuesto previsto a partir de la fecha. Le gustaría realizar acciones de inmediato y exige una revisión de proyectos, el fin del proyecto, un recorte de personal y otras medidas drásticas para intentar retomar el control de este tren descarrilado.

Si extendemos la perspectiva solo un poco e incluimos las proyecciones del jefe de proyecto, la imagen cambia drásticamente. Sí, el importe gastado en el proyecto a partir de la fecha es más elevado que lo que era originalmente el proyecto. Eso es imprevisto y a primera vista parece una mala noticia. Sin embargo, si se incluye la previsión futura, podemos ver que se espera que el proyecto en realidad termine a tiempo o antes y que el proyecto terminará conforme al presupuesto. Tomar medidas para "rescatar" este proyecto sería el peor camino posible.

Problema resuelto.

Es imprescindible analizar lo que uno cree que pueden ser malas noticias desde más de una perspectiva antes de tomar medidas. Solo estamos analizando un proyecto y únicamente desde la perspectiva de coste por tiempo y ya está claro que solo una perspectiva histórica no brinda un panorama completo. ¿Qué ocurre con otras perspectivas como programación, uso de recursos, calidad, impacto en el mercado y demás información? Quizás terminar superando el presupuesto pero antes de tiempo sería más impactante desde una perspectiva de mercado que compensar un gasto adicional no planeado. Eso es imposible de descubrir si no hace una pausa para considerar la noticia que está a punto de informar desde más de una perspectiva.

Conclusión (¿es el final de las malas noticias?)

Las malas noticias son parte de la vida y sin duda parte de la vida de un jefe de proyecto. Si como jefe de proyecto solo esperaba tener buenas noticias, tendrá que pensar de nuevo. Como jefe de proyecto debe ser capaz de afrontar las malas noticias y poder comunicarlas de forma tal que saque el mayor valor y evite el peor daño posible.

Un jefe de proyecto es normalmente el centro de una gran web de información sobre el proyecto y la organización. Casi siempre están en la mejor posición para compartir noticias no deseadas de manera tal que evitan el drama y dejan a las personas en acción. Un jefe de proyecto que puede comunicar este tipo de noticias con eficacia es un activo para cualquier organización.

Acerca del autor

Chris Vandersluis es el presidente y fundador de HMS Software, con base en Montreal, Canadá, un asociado certificado de Microsoft. Tiene una licenciatura en Economía de la Universidad McGill y más de 30 años de experiencia en la automatización de sistemas de control de proyectos. Es miembro desde hace muchos años del Project Management Institute (PMI) y ayudó a fundar los capítulos de Montreal, Toronto y Quebec del Grupo de usuarios de Microsoft Project (MPUG). Entre las publicaciones para las que Chris ha escrito se encuentran Fortune, Heavy Construction News, la revista Computing Canada y PMI’s PMNetwork. Además, es columnista estable de Project Times. Dicta Administración avanzada de proyectos en la Universidad McGill y realiza disertaciones sobre las funciones de la asociación de administración de proyectos en Norteamérica y en todo el mundo. HMS Software es el editor del sistema de planillas de horas trabajadas TimeControl orientada a proyectos y ha sido un asociado de Microsoft Project desde 1995.

Puede ponerse en contacto con Chris Vandersluis al siguiente correo electrónico: chris.vandersluis@hms.ca.

Si quiere leer más artículos relacionados con EPM de Chris Vandersluis, vea el sitio de información de EPM de HMS (http://www.epmguidance.com/?page_id=39).

Ampliar sus conocimientos
Explorar los cursos
Obtener nuevas características primero
Únase a los participantes de Office Insider

¿Le ha sido útil esta información?

¡Gracias por sus comentarios!

Gracias por sus comentarios. Quizá le interese ponerse en contacto con uno de nuestros agentes de soporte de Office.

×