El Batphone

El título de este artículo hace referencia al uso liberal del Comisionado Gordon del Batphone cada vez que la ciudad de Gotham estaba en un estrecho de agua (de la serie de televisión "Batman" de los años 70).

Este artículo forma parte de nuestra colección "From the Trenches". Relata la historia ficticia de "Batman" con cómo, durante una implementación de EPM, en algún momento podríamos desear tener acceso a un Batphone cuando estamos en problemas. También se describen muchas maneras de evitar problemas durante la implementación.

Para descargar la versión de Word de este artículo, consulte The Batphone.

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

El Batphone

En 1966, la serie original de Batman TV salió al aire. Sólo duró 120 episodios, pero cambió una cultura de maneras que perduran hasta el día de hoy. En el mundo de Batman y Robin (interpretados por Adam West y Burt Ward), había una solución "bat" para todo. No importa cuál sea el problema, Batman tendría la solución. Los Batmobile, Batboat, Batplane y Batcave tenían su lugar. Y si fueras alguien que necesitara ayuda, sin importar lo difícil que fuera, ¿cómo podrías llegar a Batman? Bueno, con el Batphone, por supuesto! Recoge el Batphone y la ayuda estaría en camino.

El Comisionado Gordon se dirigiría al Batphone cuando las cosas no esperanzas, que se produjeron, por supuesto, cada episodio. No importaba lo difícil que fuera el desafío, recoger el Batphone y en 22 minutos (más tiempo para comerciales) el villano sería vencido y Gotham City volvió a su estado pacífico.

Todas las soluciones del mundo de Batman se hicieron para parecerse a un murciélago. ¿Esposas? Forma de murciélago. ¿Cinturón de utilidad? Logotipos de murciélagos. ¿Garfio de garfio? Por supuesto, parece alas de murciélago. Para mi sorpresa, mirando hacia atrás las imágenes del Batphone parecía molesto normal. Un teléfono rojo con una marcación (¿recuerdas esos?) No estoy seguro de por qué tenía una marca. Sólo llamó a un lugar: El Batcavo, donde la salvación estaba a mano.

Tan nostálgico como puede ser pensar en teléfonos con esferas y los episodios antiguos de Batman, no es realmente el punto del artículo de hoy. Han pasado 40 años desde que el Batphone se retiró, pero la gente hace llamadas a los consultores de EPM todos los días esperando que el Batphone funcione sólo para una llamada más.

Sus villanos son variados. Algunos son técnicos; deben actualizar de la versión x a la versión y. Algunos son arquitectónicos; necesitan hacer que su sistema interno de EPM hable con los usuarios del mundo exterior. Algunos son culturales; los usuarios se niegan a usar el sistema. Y algunos son de procedimiento; el proceso que siguen no parece entregar el resultado que esperaban.

No importa cuál sea el desafío, la solicitud de la consultora es la misma: ¿Puede corregirla en 22 minutos?

Es una situación en la que se mete un número sorprendente de usuarios de EPM, una situación en la que necesitan ayuda urgente para salir de una situación difícil. A menudo es una emergencia y la solución es requerida por la administración ayer. Las personas que hacen estas llamadas (obtengo una pareja cada semana) no son débiles de mente. Son administradores altamente inteligentes, capaces y eficaces.

No hay batphone, por supuesto. Ojalá lo hubiera. Lo usaría para todo tipo de desafíos personales. Por lo tanto, las personas que realizan estas llamadas rara vez se satisfacen con las respuestas que obtienen. Por lo tanto, vamos a tomar unos instantes y hablar sobre cómo las personas terminan en un lugar tan estrecho que sienten que necesitan recoger el teléfono rojo y cómo se puede evitar ser uno de ellos.

Meterse en problemas

En primer lugar, vamos a hablar sobre cómo las personas se mete en problemas al realizar una implementación de EPM. Hay un par de causas comunes:

• Subestimar el desafío Este es, con diferencia, el error más común en una implementación de EPM. No es decir que cada implementación debe ser grande y difícil. No siempre es así. Pero, quizás debido a un pensamiento deseado, es increíblemente común subestimar lo que se necesitará para obtener las ventajas de una implementación de EPM. El primer error en la infravaloración es seleccionar el destino. Algunas personas eligen la instalación de la herramienta como un proyecto correcto. No es así, por supuesto. Algunas personas eligen el primer uso de la herramienta o el primer informe que sale de la herramienta como destino. Eso no es todo, tampoco. Una resolución de los problemas para los que se eligieron las herramientas de EPM es donde debe dirigirse. Esto significa que la referencia cultural ha cambiado, el entrenamiento está completo, el uso está en producción, las herramientas funcionan, los datos están allí. Sí, eso puede ser algo importante, pero si estás a un centímetro de ese objetivo, aún no tienes nada. (Bueno, casi nada, de todos modos).

• Convertirlo en un proyecto técnico Para los que estamos en el negocio de la tecnología, somos los más culpables de esto y realmente, la mayoría de nosotros sabemos mejor. Sin embargo, de alguna manera, la tentación de creer que la disponibilidad de la tecnología significa que el problema se resuelve es difícil de resistir. Muchas organizaciones que visitamos dicen alguna variación de "pero instalamos Project Server, ¿por qué se sobrecarga nuestro personal? Como hemos dicho durante algún tiempo, hacer que el trabajo de administración de proyectos empresariales sea una combinación de personas, tecnología y procesos, y una buena cantidad de administración de cambios iniciada para una buena medida. Eso no llega automáticamente cuando el DVD de software pasa por la puerta.

• No implicación de la administración Esto también sucede muy a menudo. Después de todo, las personas que mejor entienden las ventajas de un sistema de administración de proyectos empresariales son, probablemente, aquellas que tienen dificultades para analizar las grandes cantidades de datos que proceden de un entorno con muchos proyectos y muchos recursos. La administración de proyectos empresariales es más popular cuando una organización intenta conciliar un conjunto complejo de prioridades conflictivas y una infinidad de aptitudes y experiencia. Pensaría que la administración estaría naturalmente implicada en un proyecto de este tipo, pero a menudo no es el caso. El desafío de cambiar la cultura corporativa de una mentalidad de proyecto único a una mentalidad de proyecto empresarial es casi imposible de superar sin ellos y, sin embargo, toda administración con demasiada frecuencia se omite debido a la preocupación de que no podrán apreciar lo que se necesitará para completar una implementación de EPM.

• Realizar programaciones poco realistas No hay nadie que desee que una implementación de EPM tarde mucho tiempo. Y es común esperar que el proyecto se pueda llevar a cabo en días o un par de semanas en lugar de en los meses más comunes. También hay un desafío común de no obtener los recursos para un proyecto "interno" como EPM tan fácilmente como un proyecto comercial o basado en clientes. Por estas y otras razones, es habitual realizar una programación de proyecto con requisitos de recursos que son lamentablemente insuficientes.

• No aplicar la administración de proyectos al sistema de administración de proyectos Si has leído algo que he escrito, lo más probable es que hayas visto esto antes. Los responsables del proyecto son susceptibles al síndrome de "zapatero cuyos hijos están descalzos". El resultado es una falta común de una carta de proyecto, un presupuesto aprobado, una programación con seguimiento, recursos dedicados y todas las demás aprobaciones para su propio proyecto que son comunes a todos los demás proyectos que administran.

¿Qué esperaban?

De acuerdo, así es como la gente a menudo se mete en problemas. Las ventajas esperadas por la administración de la implementación de un sistema EPM suelen provenir directamente de los desafíos empresariales. Es la promesa de resolver los desafíos que conllevan la administración para aprobar los gastos de software, hardware, infraestructura e incluso servicios. El más común de estos desafíos puede parecer familiar:

• Los recursos están sobrecargados Puede que no esté claro en qué se están gastando los recursos, pero es muy común encontrar que los recursos están sobrecargados. Un problema más complejo es encontrar que algunos recursos están sobrecargados y otros están infracargados, lo que a menudo indica una falta de coincidencia entre las aptitudes y la experiencia disponibles frente a las necesarias.

• Los proyectos críticos no se están completando a tiempo Debería ser obvio que los proyectos críticos deberían terminar cuando estén planeados, pero la vida parece interrumpir esos planes. Esto puede deberse a requisitos de recursos en conflicto, a la elección de demasiados proyectos que requieren demasiados de la misma aptitud o simplemente a una priorización incorrecta. A veces, las organizaciones pensarán que es una falta de aptitudes del administrador de proyectos, pero en un entorno de matriz multiproyecto y de varios departamentos, el culpable más probable es la naturaleza organizativa.

• Los proyectos no se están completando dentro del presupuesto Lo que es válido para la programación puede aplicarse igualmente a los costos. En alta tecnología, así como en muchos otros sectores, el componente más variable del costo de un proyecto es la cantidad de mano de obra que se le aplica. Tómese mucho más tiempo con las mismas personas y va a agregar costos al proyecto. Un número impresionante de proyectos de cuello blanco sigue sin rastrearse. Están planeados, pero no se registra el costo real por proyecto.

• Tu competencia está completando proyectos más rápido de lo que eres En una economía competitiva, ser el primero en comercialización puede marcar la diferencia entre supervivencia y olvido. Por lo tanto, para muchas organizaciones, asegurarse de que la administración de proyectos es al menos tan eficaz como sus competidores es importante.

• No hay visibilidad sobre qué recursos de un proyecto dedican su tiempo o no hay forma de saber cuánto tiempo se está dedicando a cada proyecto . A veces ninguna respuesta es peor que una mala respuesta. Si usted está en la administración sénior esto es particularmente cierto. Si sabe que los resultados son malos, puede aplicar sus habilidades y los recursos a su disposición al problema que se encuentra a su disposición. Si sabes que algo está mal, pero no puedes decir qué, estás esposado. No hay manera de saber dónde intentar arreglar algo.

Cómo mantener fuera de problemas?

No quieres llegar a un punto donde sientas que necesitas el Batphone. Por lo tanto, ¿qué puede hacer con su entorno de EPM para asegurarse de que no termina allí?

Todo lo que dijimos en la primera sección es obvio:

• Hacer una buena estimación

• No pienses que EPM es solo un proyecto técnico.

• Implicar a la alta dirección desde el principio

• Realice una programación realista y asígnele una comprobación de la realidad comparándola con otras personas de su sector.

• Hacer una programación de proyecto y una carta de proyecto, y hacer todas las cosas que normalmente haces con tus otros proyectos

¿Qué más puedes hacer?

En primer lugar, inicie el proyecto con un reconocimiento de que en algún momento en el futuro, va a querer usar el Batphone. Usted. Sabiendo eso, una cosa que puede hacer es presupuestar la asistencia para la que no tiene ningún plan actual. Se recomienda que nuestros clientes presupuestan entre el 10 % y el 20 % del proyecto para "requisitos sin asignar". "¿Para qué es eso?", siempre se nos pregunta. "Nos lo dirás más tarde", siempre respondemos. Es común no usar todo ese dinero. Pero también es increíblemente común usar algunos de ellos. Tener un experto cualificado ya asignado y presupuesto para el proyecto hace una gran diferencia más adelante.

Comience con la expectativa de que el plan y las personas cambien. Mi cita de gestión de proyectos favorita es de Napoleón Bonaparte, quien dijo: "Un plan de batalla dura hasta el contacto con el enemigo". También es cierto en los planes de EPM. Dado que es probable que una implementación dure varios meses, la posibilidad de que algún personal cambie en el plan es enorme. Por lo tanto, planee la redundancia.

Los sistemas EPM evolucionan. Es habitual en estos días en una aplicación empresarial pensar en el "costo total de propiedad". Creo que debemos incluir el ciclo de vida total de la aplicación en nuestros planes de proyecto de EPM. ¿Ha pensado en qué versión de una herramienta va a implementar? ¿Has pensado en de qué otras herramientas depende? ¿Qué tal la actualización o actualización normal de esas herramientas? ¿Ha realizado personalizaciones? ¿Qué tal el entrenamiento personalizado? ¿Ha pensado en cómo se migrarán esas cosas a una nueva versión en caso de implementar una?

Planee también la redundancia de sus expertos. Si tiene un solo consultor trabajando para usted, ¿qué ocurrirá en unos meses a medida que pase a una nueva fase de la implementación o introduzca un nuevo miembro clave de su equipo? ¿Estará disponible ese consultor? (Los consultores pasan de un proyecto al siguiente, por lo que la respuesta suele ser "no"). Si trabaja con una empresa de consultoría, ¿ha hablado de cómo pueden conservar el trabajo de su personal para que otros la repliquen, si es necesario?

Póngalo por escrito

Uno de los desafíos más comunes y fáciles de solucionar proviene de una documentación deficiente. Es el elemento más fácil de cambiar a corto plazo, pero la existencia de dicha documentación puede marcar la diferencia entre volver a una referencia escrita y buscar el Batphone. Tampoco es suficiente escribir un documento y meterlo en un cajón en algún lugar. Los documentos deben formar parte de un registro en curso y el proceso de EPM podría hacer referencia a ellos como parte de un proceso de revisión regular. Estos son algunos de los documentos de un entorno de EPM que creo que son los más críticos:

• Caso empresarial No sé de qué se trata el caso empresarial original que lo hace tan poco atractivo, pero es lo más común perder la pista de y en muchos aspectos, es el kernel de por qué tiene un entorno EPM en primer lugar. El caso empresarial toma nota de cuáles son las ventajas de la organización esperadas; ¿qué espera la organización del sistema EPM? Cuando recibamos una llamada a Batphone, una de las primeras cosas que preguntamos es: "¿Cuál es el sistema que se espera que te entregue?" No se lo preguntamos al administrador. También preguntamos a la administración, a los usuarios y a los beneficiarios empresariales. La respuesta más común es una respuesta diferente de cada parte. Esto se debe a que la premisa empresarial original se ha perdido.

• Roles y responsabilidades En la última versión de roles y responsabilidades, a menudo se resuelve con el nombre de un individuo y no tarda mucho tiempo en olvidarse del rol que desempeña el individuo en el sistema EPM. Mantener un documento de roles y responsabilidades le permitirá ajustar los parámetros de quién hace lo que en el proceso de EPM a medida que la organización pasa naturalmente por cambios de personal o incluso cambios en la estructura de la organización.

• Guía de procesos y diagrama de flujo Esto a menudo se olvida cuando llegamos a guías de procedimientos. Personas quedan con los pasos "Qué hacer" en un manual de procedimientos, pero no el contexto de por qué esos pasos son importantes y qué hacemos con el resultado de cada paso. Una guía de procesos y, lo mejor de todo, un diagrama de flujo visual permitirá a los futuros administradores comprender lo que proporciona el sistema y facilitar la adaptación del sistema en el futuro.

• Criterios de selección del sistema Cuando elija su sistema EPM y cualquier herramienta de terceros que haya seleccionado a lo largo del camino, deje que las generaciones futuras sepan en qué se basa su decisión. Hemos pasado a las organizaciones 5, 7 o incluso 10 años después de que se implementó un sistema y vimos un sistema con varias herramientas asociadas y le preguntamos "¿Por qué estás haciendo eso? ¡Sería mucho más fácil hacerlo!" Las razones de esas decisiones no se encuentran en ningún lugar. En algunos casos, el cliente ha pasado años haciendo algo muy complicado que podría haber sido mucho más fácil dadas las versiones más actuales de las herramientas existentes. No pueden tomar una decisión fácil de cambiar una herramienta o usar una versión más actual porque ya no tienen acceso a por qué decidieron hacer algo de cierta manera hace años.

Realmente no hay batphone.

Cuando digo eso, se siente como si estuviera diciendo que no hay conejo de Pascua ni Santa Claus. Son malas noticias. Pero realmente no hay batphone. Estoy seguro, sin embargo, de que la ausencia de ese teléfono mágico no impedirá que la gente me llame mañana pidiéndome que vaya a vencer al último villano de Gotham City. Si te metes en problemas y sientes la necesidad de llamar a un experto, estas son algunas recomendaciones:

1. Escucha los consejos que recibes. Es una tontería pagar a un experto para que le dé consejos y luego decida que sabe mejor que ellos. Si vas a pedir consejo y estás tratando con un experto, intenta escuchar y al menos considerar el consejo. Batman no habría seguido apareciendo para el Comisionado Gordon una y otra vez si cada vez que lo hacía, Gordon dijo: "Ahora que estás aquí, Batman, por favor haz lo mismo que todos mis demás policías".

2. Batman podría hacerlo en 22 minutos, pero probablemente no lo harás. Si llamas a un experto, deja que te diga cuánto tiempo se debe tardar en solucionar el desafío. Puede optar por no corregirlo después de que haya terminado, pero corregir los desafíos de EPM, incluso los técnicos, rara vez tarda solo unos minutos. Después de todo, Batman tuvo que hacerlo en 22 minutos porque 8 minutos fueron asignados para comerciales, y son esenciales.

3. El Comisionado Gordon nunca le dijo a Batman la solución, sólo el problema. Con demasiada frecuencia, recibe una llamada de un administrador de EPM con pánico que sabe que necesito aplicar un parche, escribir un informe y entrenar a dos personas. Siempre escucho esto pacientemente y luego pido al cliente que describa el problema como acaba de describirme la solución. Antes de recoger el teléfono para llamar a un experto, piensa primero en qué problema te gustaría poner en su mesa.

Conclusión

Realmente necesitas usar el Batphone. Pregunte por aquí. No preguntes solo a un experto en consultoría y no obtengas una sola solución posible. Pregúntele a sus compañeros u otros de la industria a quién saben quién podría llamar a Batphone y hable con al menos dos de ellos. Es una buena comprobación de la realidad ver cómo un experto frente a otro podría tratar su problema. Recuerda, Batman puede haber sido increíble, pero hay muchos superhéroes entre los que elegir!

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).