El portador de malas... noticias

Este artículo forma parte de nuestra colección "From the Trenches". Describe cómo los administradores de proyectos pueden compartir malas noticias sobre sus proyectos de forma más eficaz y con el menor daño para sí mismos.

Para descargar la versión de Word de este artículo, consulte Breaking Bad... Noticias que son: notas del producto.

Para ver más artículos, consulte las notas del producto "Desde las trincheras".

Breaking Bad... Noticias que son

Después de un artículo (Cancelación de un proyecto sin cancelar su carrera: white paper) hice un tiempo atrás, recibí una serie de comentarios de los directores de proyecto que expresaban su preocupación por compartir esas malas noticias con su dirección. "No importa cuáles sean los posibles beneficios", dijo uno, "Me despedirán si comparto noticias tan malas".

No importa cuál sea su entorno de trabajo, parece que algunas personas son mejores para compartir malas noticias que otras y para los administradores de proyectos, poder compartir tanto buenas tidings como malas es parte de la descripción del trabajo. Así que vamos a buscar un momento en cómo un administrador de proyectos puede compartir las malas noticias de la forma más eficaz y con el menor daño para sí mismo.

Obtener todas las noticias antes de empezar a compartir

La primera y más importante lección es asegurarse de que tiene todas las noticias. Cada vez que tengo un miembro del personal que se acerca a mí con algunas noticias molestos inevitablemente tengo preguntas. Si no se han tomado el tiempo para incluso considerar qué preguntas podría hacer y cuáles son las respuestas, es irritante. Por lo tanto, antes de correr a su gerente para exclamar cómo cae el cielo, asegúrese de pausar un momento para obtener todos los hechos. ¿Está seguro de que la información que tiene está completa? ¿Es preciso? ¿Hay circunstancias atenuantes? ¿Sabes 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?

¡Qué bien! Todavía no estamos fuera de la puerta y ya tienes una lista de cosas que hacer. No hay nada más molesto para una persona en la administración que para tener un problema volcado en su escritorio por alguien en su equipo, pero aún no sabe si it's un problema o no. Debe ser fácil determinar las preguntas iniciales que pueden surgir de cualquier mala noticia es así que obtener que respondan por sí mismo antes de empezar a compartir sus noticias.

El pensamiento del avestruz no es productivo

Como un avestruz que se mete la cabeza en la arena ante la primera señal de peligro con la esperanza de que se vaya, algunos directores de proyecto evitan malas noticias a toda costa. Evitar las malas noticias rara vez es productivo. De hecho, es porque no todas las noticias son buenas para que los jefes de proyecto tengan un trabajo en primer lugar. Si todos los proyectos siempre funcionaban de la forma en que se planearon, ¿por qué tendríamos administradores de proyectos? Así que el hecho de que no estés listo para compartir esas malas noticias aún no significa que no la compartas en absoluto.

¿Quién tiene la culpa?

Esta puede ser la pregunta menos valiosa y la respuesta es casi sin duda de poco valor también. Sin embargo, muchas personas de forma predeterminada señalarán con un dedo a otra persona como una reacción a la molestia que la mala noticia está a punto de causar. Mantenerse alejado de la culpa le permitirá centrarse en "¿Qué pasó?" y "¿Qué debemos hacer a continuación?" en lugar de "¿Quién pone la caída de este problema a los pies de?"

¿Son malas noticias? ¿Estás seguro?

Recientemente tuve uno de mis empleados aparecen en mi oficina, lo que me permite saber que, debido a las restricciones de recursos, no podríamos cumplir con las expectativas de un cliente que hacemos varios días de entrenamiento después de horas. "¿Nos comprometemos a hacer esto?" Lo he preguntado. Hubo una larga pausa. El miembro del personal no estaba seguro y resultó ser una pregunta clave. No. Nunca habíamos prometido hacer este entrenamiento. El cliente tenía el deseo de que lo haríamos, pero ni siquiera había pasado por los canales adecuados para programarlo. Resultó que realmente no había malas noticias para compartir y la acción adecuada era ponerse en contacto con el cliente para programar algún tiempo de entrenamiento en una fecha futura.

Problema resuelto.

Normalmente, un problema se expresa de esta manera: "Esto se esperaba, pero esto es lo que ocurrió". A veces solo la semántica puede hacer que pienses en ello de manera diferente. Pruebe esto: "Esto se esperaba y esto es lo que ocurrió". ¿Conflicto? Quizás no, pero es saludable empezar por ver si había un compromiso que se rompió. Si no es así, tal vez no haya un problema con el que tratar.

Forros plateados

Cuando ocurre algo inesperado, a menudo se produce un impacto o una caída como resultado. Si está pausando o cancelando un proyecto por ejemplo, una cosa que casi siempre ocurre es que tiene recursos adicionales que no se esperaban que se puedan 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 tienes malas noticias que compartir, es común ver todo lo que te rodea a través del filtro de "It's all bad" pero eso rara vez es cierto. Algún impacto de sus malas noticias será bueno y usted debe a su administración, a su cliente o a quien necesite compartir sus noticias con para compartir no sólo el impacto malo, sino también el bueno.

Mitigación

Así que tienes malas noticias. Una cosa que vale la pena hacer antes de compartirlo son algunos factores de mitigación. Tal vez el proyecto esté atrasado. Son malas noticias. Sin embargo, si ya había ocultado alguna reserva de administración en su programación (como hacen muchos buenos administradores de proyectos), quizás pueda ponerse al día con su programación durante ese período. Las malas noticias se mitigan; Neutralizado.

La mitigación también le permite pensar en posibles soluciones al problema antes de compartirlo. Los administradores aprecian enormemente las descripciones de problemas que se entregan al mismo tiempo que una lista de posibles soluciones. A veces esas soluciones se convierten en oportunidades para abrir una nueva línea de pensamiento. Hace varios años, estaba trabajando con una gran empresa de software y en medio del desarrollo de su próxima versión importante, determinaron que tendrían que cortar una función de marqués del ámbito. Fueron malas noticias. Si no se realizara ninguna otra acción, lanzarían su próxima versión y ya serían mucho menos funcionales que muchos de sus competidores. La empresa seleccionó uno de varios planes de mitigación y salió al mercado y compró una empresa que tenía exactamente la funcionalidad que faltaban. ¿Cuál es el resultado final? La empresa hizo la fecha de entrega del mercado, tenía la funcionalidad adecuada y, además, debido a la adquisición, tenía un equipo de personal altamente cualificado que les permitió aprovechar esa funcionalidad para avanzar en el marketplace.

Problema resuelto.

La presentación es Power

Como jefes de proyecto a menudo lamentamos que tenemos toda la responsabilidad y ninguna de las autoridades. Después de todo, es poco frecuente que un administrador de proyectos tenga todos los recursos del proyecto que les informen directamente, sin embargo, es el administrador del proyecto al que recurrimos para preguntar sobre el progreso del proyecto.

Aunque el administrador del proyecto puede tener poca autoridad, sí controlan una cosa que es aún más impactante; controlan la presentación de la información y controlar la presentación es clave.

¿Es de extrañar que lo llamemos "Power"Point? La forma en que se muestra algo puede marcar la diferencia. Hace varios años, los cineastas Stephen Spielberg y George Lucas compraron un simulador de vuelo antiguo y se sorprendieron al determinar que el cuerpo humano puede detectar un cambio de tono (el ángulo en el que se encuentra) de menos de 1/2 de un grado. Cuando se aumenta mediante señales visuales, la mente rellenará los huecos y el cuerpo reaccionará como si un evento estuviera sucediendo realmente a pesar de que se trata solo de un piso inclinable y una película con algún 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 como lo harán en una emergencia real.

¿El resultado de la investigación de Spielberg y Lucas? El paseo Star Tours en Disney World.

Con el mismo token, un administrador de proyectos controla la presentación visual. Mostrar una línea de tendencia en lugar de una tabla de figuras y el ojo sigue la tendencia por sí solo y la mente extrae sus propias conclusiones.

Normalmente, los administradores de proyectos controlan todos los elementos de cómo se muestran los datos. Mostrar datos de panel, datos analíticos o datos en un formato gráfico junto con viñetas simples en una diapositiva puede marcar una gran diferencia.

En un compromiso reciente tuve que explicar al cliente que su carga de trabajo actual era casi el doble del tamaño de su personal y que ninguna cantidad de priorización daría lugar a que todo el trabajo se realizara a tiempo. Sin embargo, antes de presentar esta mala noticia, pasé un tiempo adicional profundizando en los datos de lo que se estaba haciendo realmente. He extraído volúmenes de datos del parte de horas en Excel y he empezado a trazarlos. Por último, un gráfico circular mostró un gran nugget de oro. Un porcentaje increíblemente alto de trabajo se estaba gastando en mantenimiento de TI. La investigación posterior determinó que gran parte de este trabajo era evitable mediante decisiones estratégicas (por ejemplo, apoyar un número inusualmente alto de productos y versiones de base de datos) o mediante la restricción de una práctica de permitir que los proyectos se dividieran en mandatos tan pequeños que se pudieran manejar operativamente a través de una solicitud de soporte técnico. La organización se había visto tan desafiada en lograr el trabajo que muchos líderes del equipo de negocios habían aprendido a dividir los proyectos de 30, 40 o incluso 60 días de duración en segmentos de 3 días que lograrían a través de una llamada al departamento de soporte técnico. Esto era tan frecuente que había tanto trabajo de proyecto no autorizado que se estaba realizando esto era como lo había a través de la oficina de administración de proyectos real. Al detener esta práctica, la PMO renovó la información sobre las solicitudes del proyecto y el volumen de solicitudes se redujo significativamente.

Los datos siempre habían estado allí. La práctica era conocida por muchos, pero hasta que mostramos el segmento del gráfico circular en un gráfico, nadie era consciente de lo impactante que había sido la práctica. De hecho, la dirección se sorprendió por las cifras.

Recuentos de perspectivas

Es importante no dejar que la urgencia del momento o la preocupación sobre cómo compartir la perspectiva de la nube de malas noticias. Es fácil quedar atrapado en el malestar del momento, pero si no lo haces, si mantienes la calma, puedes convertirte en la voz de la razón en un día molesto. He usado los dos gráficos siguientes durante años para demostrar la diferencia en la perspectiva del director financiero frente al director de proyectos y el impacto potencialmente dramático de no ampliar su visión de la información.

Esta es la vista de CFO:

Y esta es la vista del administrador de proyectos:

El primer gráfico es de un proyecto que ha sobresanido su presupuesto esperado hasta la fecha. El presupuesto planeado fue acordado por todas las partes y a partir de hoy, el Director Financiero está teniendo un día muy malo. El proyecto está claramente por encima de su presupuesto esperado a partir de hoy. Le gustaría tomar medidas inmediatamente y exige una revisión del proyecto, una paralización del proyecto, el recorte de personal y otras medidas drásticas para intentar que este tren descontrolado vuelva a estar bajo control

Si ampliamos la perspectiva un poco e incluimos las proyecciones del administrador del proyecto, la imagen cambia drásticamente. Sí, la cantidad gastada en el proyecto a partir de hoy es mayor que la que originalmente se había realizado a partir de hoy. Eso es inesperado y a primera vista parece una mala noticia. Sin embargo, si se incluye la previsión de futuro, podemos ver que se espera que el proyecto finalice a tiempo o antes y que el proyecto finalizará con presupuesto. Tomar medidas para "rescatar" este proyecto sería el peor curso posible.

Problema resuelto.

Es fundamental ver lo que crea que puede ser una mala noticia desde más de una perspectiva antes de tomar medidas extremas. Solo estamos viendo un proyecto y solo desde una vista de costo por tiempo y ya está claro que solo una perspectiva histórica no da una imagen completa. ¿Qué ocurre con otras perspectivas como la programación, el uso de recursos, la calidad, el impacto en el mercado y mucho más? Tal vez terminar por encima del presupuesto, pero antes sería tan impactante desde una perspectiva del mercado que sería más que compensar el gasto adicional no planeado. Es imposible descubrir si no se detiene para tener en cuenta las noticias que va a entregar desde más de una perspectiva.

Terminando (¿Es eso el final de las malas noticias?)

Las malas noticias forman parte de la vida y, sin duda, forman parte de la vida de un jefe de proyecto. Si esperaba como jefe de proyecto solo noticias felices, tendrá que pensar de nuevo. Como jefe de proyecto debe ser capaz de enfrentarse a malas noticias y ser capaz de comunicarse de una manera para proporcionar el máximo valor y evitar los peores daños posibles.

Un administrador de proyectos suele ser 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 una manera que evita el drama y deja a las personas en acción. Un administrador de proyectos que pueda comunicar este tipo de noticias de forma eficaz es un recurso para cualquier organización.

Autor

Chris Vandersluis es el presidente y fundador de Montreal, HMS Software, un asociado certificado de Microsoft con sede en Canadá. 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 un miembro de larga data del Project Management Institute (PMI) y ayudó a encontrar 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 incluyen Fortune, Heavy Construction News, la revista Computing Canada y PMNetwork de PMI, y es columnista regular de Project Times. Enseña administración avanzada de proyectos en la Universidad McGill y a menudo habla en las funciones de asociación de administración de proyectos en Norteamérica y en todo el mundo. HMS Software es el editor del sistema de mantenimiento de tiempo orientado al proyecto TimeControl y ha sido asociado de soluciones de Microsoft Project desde 1995.

Chris Vandersluis puede ser contactado por correo electrónico en: chris.vandersluis@hms.ca

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