El teléfono Bat: notas del producto

El título de estas notas del producto hacen referencia al uso excesivo que hacía el Comisionado Gordon del batiteléfono siempre que Ciudad Gótica estaba en una situación desesperada (de la serie de televisión "Batman" de los años 1970).

Estas notas del producto forman parte de nuestra colección "Desde las trincheras". Se relaciona la historia ficticia de "Batman" con la forma en que, durante una implementación de EPM, podríamos desear en algún momento tener acceso a un batiteléfono cuando estamos en problemas. También se describen muchas formas para evitar meterse en problemas durante la implementación.

Para descargar la versión en Word de estas notas del producto, consulte El batiteléfono.

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

El batiteléfono

En 1966, salió al aire la serie de televisión original Batman. Duró solo 120 episodios, pero cambió la cultura en formas que han durado hasta hoy. En el mundo de Batman y Robin (interpretados por Adam West y Burt Ward), había una "batisolución" para todo. No importaba cuál fuera el problema, Batman siempre tenía la solución. Había lugar para el batimóvil, el batibarco, el batiavión y la baticueva. Y si alguien necesitaba ayuda, por difícil que resultara, ¿cómo podía acudir a Batman? ¡Con el batiteléfono, por supuesto! Con solo tomar el batiteléfono la ayuda se ponía en camino.

Imagen de un Batphone rojo (de la serie de televisión "Batman"

El Comisionado Gordon recurría al batiteléfono cuando las cosas no tenían esperanza, lo cual por supuesto sucedía cada episodio. No importa cuán difícil fuera el desafío, bastaba con tomar el batiteléfono para que en 22 minutos (más el tiempo destinado a los anuncios publicitarios) se derrotara al villano y volviera la paz a Ciudad Gótica.

Todas las soluciones en el mundo de Batman tenían el aspecto de un murciélago. ¿Esposas? En forma de murciélago. ¿Cinturón de servicio? Logotipos de murciélago. ¿Rezón? Por supuesto, parecía unas alas de murciélago. Para mi sorpresa, al volver a ver las imágenes del batiteléfono, este parecía terriblemente normal. Un teléfono rojo con disco de marcar (¿los recuerda?). No estoy seguro de por qué tenía un disco de marcar. Solo se usaba para llamar a un lugar: la baticueva, donde la salvación estaba cerca.

Por más nostálgico que sea pensar en los teléfonos con discos de marcar y en los antiguos episodios de Batman, realmente no es el objeto del artículo de hoy. Han pasado 40 años desde que se retiró el batiteléfono, pero las personas siguen llamando a los consultores de EPM diariamente con la esperanza de que el batiteléfono funcione para una última llamada.

Los villanos son variados. Algunos son técnicos: necesitan actualizar de la versión X a la versión Y. Algunos son arquitectónicos: necesitan hacer que su sistema de EPM interno se comunique 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 estar dando los resultados previstos.

No importa cuál sea el desafío, la solicitud a la empresa de consultoría es la misma: ¿puede solucionarlo en 22 minutos?

Es una situación en la que se encuentra un sorprendente número de usuarios de EPM: una situación en la que necesitan urgentemente asistencia para salir de una situación difícil. A menudo se trata de una emergencia y la dirección necesita la solución desde ayer. Las personas que hacen estas llamadas (yo recibo un par cada semana) no son tontas. Son directores sumamente inteligentes, capaces y competentes.

Por supuesto, no hay ningún batiteléfono. Me gustaría que hubiera uno. Lo usaría para todo tipo de retos personales. Por lo tanto, las personas que hacen estas llamadas rara vez se quedan satisfechas con las respuestas que obtienen. Así que vamos a dedicar unos minutos a hablar sobre cómo las personas terminan en una posición tan delicada que sienten que necesitan tomar el teléfono de color rojo y sobre cómo usted puede evitar ser una de esas personas.

Meterse en problemas

Primero, vamos a hablar sobre cómo las personas se meten en problemas cuando llevan a cabo una implementación de EPM. Hay un par de causas comunes:

  • Subestimar el desafío    Este es, por mucho, el error más común en una implementación de EPM. Esto no quiere decir que cada implementación debe ser grande y difícil. Ciertamente, no es siempre el caso. Sin embargo, quizá debido a meras ilusiones, es increíblemente común subestimar lo que se necesitaría para obtener los beneficios de una implementación de EPM. El primer error de subestimación está en la elección del objetivo. Algunas personas eligen la instalación de la herramienta como un proyecto exitoso. No lo es, por supuesto. Algunas personas eligen el primer uso de la herramienta o el primer informe que se genera a partir de la herramienta como el objetivo. Tampoco lo es. Adonde hay que apuntar es hacia la resolución de los problemas para los que se eligieron las herramientas de EPM. Esto significa que la cultura ha cambiado, el entrenamiento se ha completado, el uso se encuentra en producción, las herramientas están funcionando y los datos están ahí. Sí, eso puede ser fantástico, pero si por un centímetro no llega a la meta, no habrá obtenido nada. (Bueno, casi nada, de todos modos).

  • Hacer que sea un proyecto técnico    La mayoría de las personas que estamos en el negocio de la tecnología somos culpables de esto y, realmente, la mayoría somos más sensatos. Sin embargo, de alguna manera, la tentación de creer que la disponibilidad de tecnología significa que el problema está resuelto es difícil de resistir. Muchas de las organizaciones que visitamos dicen alguna variación de "pero hemos instalado Project Server, ¿por qué nuestro personal está sobrecargado?" Como hemos dicho desde hace tiempo, el trabajo de administración de proyectos empresariales es una combinación de personas, tecnología y procesos y una cantidad considerable de administración de cambios que viene a completar el cuadro. Eso no llega automáticamente cuando el DVD del software atraviesa la puerta.

  • No involucrar a la dirección    Esto también sucede muy a menudo. Después de todo, las personas que entienden mejor las ventajas de un sistema de administración de proyectos empresariales son más probablemente las que están luchando para analizar grandes volúmenes de datos provenientes 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 en conflicto y una combinación de innumerables habilidades y experiencias. Probablemente piense que la dirección se involucraría de forma natural en tal proyecto, pero a menudo no es el caso. El desafío de cambiar la cultura corporativa de la mentalidad de un solo proyecto a la mentalidad de un proyecto empresarial es casi imposible de superar sin ellos. Sin embargo, la dirección suele pasarse por alto debido a la preocupación de que no puedan apreciar lo que se necesitaría para completar una implementación de EPM.

  • Realizar programaciones poco realistas    Nadie desea que una implementación de EPM tome mucho tiempo. Y es frecuente esperar que el proyecto pueda realizarse en unos días o un par de semanas en lugar de meses, que es lo más común. También hay un desafío común de no recibir los recursos para un proyecto "interno" como EPM tan fácilmente como para un proyecto comercial o basado en clientes. Por estas y otras razones, es habitual hacer una programación del proyecto con requisitos de recursos que lamentablemente no son suficientes.

  • No aplicar administración de proyectos al sistema de administración de proyectos    Si ha leído algo de lo que he escrito, es muy posible que ya haya visto esto antes. Los jefes de proyectos son susceptibles al síndrome "en casa del herrero, cuchillo de palo". El resultado es la falta común de una carta del proyecto, un presupuesto aprobado, una programación rastreada, recursos dedicados y todos los demás equipos para su propio proyecto que son comunes a todos los demás proyectos que administran.

¿Qué estaban esperando?

Bien, así es cómo las personas suelen meterse en problemas. Los beneficios esperados por la dirección respecto de la implementación de un sistema EPM generalmente vienen directamente de los desafíos empresariales. Es la promesa de resolver esos problemas lo que lleva a la dirección a autorizar los gastos de software, hardware, infraestructura y posiblemente hasta servicios. El más común de estos retos puede sonar familiar:

  • Los recursos están sobrecargados    Es posible que no esté claro a qué se están dedicando los recursos, pero es muy común darse cuenta de que los recursos están sobrecargados. Un problema más común es encontrar que algunos recursos están sobrecargados y otros están subcargados, lo que a menudo indica una falta de coincidencia entre las habilidades y la experiencia disponible frente a lo que se requiere.

  • Los proyectos críticos no se están completando de forma oportuna    Debería ser obvio que los proyectos críticos deben finalizar cuando se planean, pero la vida parece interrumpir esos planes. Esto puede deberse a requisitos de recursos en conflicto, a la elección de demasiados proyectos que necesitan una gran cantidad de la misma habilidad o simplemente a una mala forma de establecer prioridades. A veces, las organizaciones creen que es una falta de habilidades del jefe de proyectos, pero en un entorno de matriz de varios proyectos en varios departamentos, el culpable más probable es de naturaleza organizativa.

  • Los proyectos se no se están completando dentro del presupuesto    Lo que se aplica a la programación también se aplica a los costos. En el sector de la 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 usa en este. Si uno tarda mucho más tiempo con las mismas personas, se van a agregar costos al proyecto. Un impresionante número de proyectos de cuello blanco aún permanecen sin seguimiento. Están previstos, pero el costo real por proyecto no está registrado.

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

  • No hay visibilidad de las tareas en las que los recursos de un proyecto están invirtiendo su tiempo ni ninguna forma de saber cuánto tiempo están dedicando a cada proyecto    A veces, la ausencia de respuesta es peor que una mala respuesta. Si usted es un alto directivo, esto es particularmente cierto. Si sabe que los resultados son malos, puede aplicar sus habilidades y los recursos a su disposición para el problema que le ocupa. Si sabe que hay algo que no está bien pero no sabe exactamente qué, tiene las manos atadas. No hay manera de saber dónde intentar solucionar algo.

¿Cómo evito meterme en problemas?

No le conviene tener que llegar al punto en el que siente que necesita usar el batiteléfono. Por lo tanto, ¿qué puede hacer con su entorno de EPM para asegurarse de que no termine allí?

Bien, todo lo que dije en la primera sección es obvio:

  • Hacer una buena estimación

  • No creer que EPM es solo un proyecto técnico

  • Involucrar a los altos directivos desde el principio

  • Hacer un calendario realista y comprobar su realidad comparándolo con otros en el sector

  • Hacer una programación y carta del proyecto, y hacer todo lo que normalmente haría con los demás proyectos

¿Qué más puede hacer?

Primero, inicie el proyecto reconociendo que, en algún momento en el futuro, deseará usar el batiteléfono. Lo deseará. Sabiendo esto, algo que puede hacer es un presupuesto de consultoría para la que no tiene ningún plan actual. Recomendamos que nuestros clientes presupuesten entre 10 % y 20 % del proyecto en "requisitos no asignados". "¿Para qué es esto?" siempre nos preguntan. "Usted nos lo dirá más adelante", siempre contestamos. Es común no usar todo ese dinero. Pero también es increíblemente común usar una parte. Tener a un experto ya asignado y presupuesto para su proyecto hace una gran diferencia más adelante.

Empiece con la expectativa de que el plan y las personas van a cambiar. Mi cita favorita sobre administración de proyectos es de Napoleón Bonaparte, quien dijo: "Un plan de batalla dura hasta hacer contacto con el enemigo." Esto también es cierto para los planes de EPM. Dado que una implementación probablemente durará algunos meses, la posibilidad de que una parte del personal cambie en el plan es enorme. Por lo tanto, planee la redundancia.

Los sistemas de EPM evolucionan. Es frecuente durante estos días en una aplicación de empresa pensar en el "costo total de la propiedad". Creo que deberíamos incluir el ciclo de vida total de la aplicación en nuestros planes de proyectos de EPM. ¿Ha pensado en la versión de la herramienta que está a punto de implementar? ¿Ha pensado de qué otras herramientas depende? ¿Qué hay de las actualizaciones periódicas de esas herramientas? ¿Ha hecho personalizaciones? ¿Qué hay del entrenamiento personalizado? ¿Ha pensado cómo esos elementos migrarán a una nueva versión si la implementa?

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

Póngalo por escrito

Uno de las retos más comunes y más fáciles de solucionar proviene de una mala documentación. Es el elemento más fácil de cambiar a corto plazo, pero la existencia de dicha documentación puede hacer la diferencia entre volver a una referencia escrita y buscar el batiteléfono. Además, no es suficiente escribir un documento y guardarlo en un algún cajón. Los documentos deben formar parte de un registro continuo y el proceso de EPM debería consultarlos como parte de un proceso de revisión normal. Estos son algunos de los documentos para un entorno de EPM que creo que son los más críticos:

  • Caso de negocios    No sé qué pasa con el caso de negocios original que parece tan poco atractivo, pero lo más común es perder la pista y, en muchos aspectos, es el meollo de por qué se tiene un entorno de EPM en primer lugar. El caso de negocios observa cuáles son los beneficios esperados por la organización. ¿Qué espera la empresa del sistema EPM? Cuando recibimos una llamada al batiteléfono, una de las primeras cosas que preguntamos es "¿Qué se espera que le proporcione el sistema? No solo se lo preguntamos al director. También se lo preguntamos al departamento de administración, a los usuarios y a los beneficiarios del negocio. La respuesta más común es una respuesta diferente de cada parte. Esto se debe a que la premisa original del negocio se ha perdido.

  • Roles y responsabilidades    En la última versión de roles y responsabilidades, a menudo resolvemos por el nombre de una persona y no pasa mucho tiempo antes de que se olvide el rol que esa persona desempeña en el sistema EPM. Mantener un documento sobre los roles y las responsabilidades permite ajustar los parámetros de quién hace qué en el proceso de EPM a medida que la organización atraviesa naturalmente cambios de personal o incluso cambios en la estructura organizativa.

  • Diagrama de flujo y guía del proceso    Esto se nos suele olvidar cuando abordamos las guías de procedimiento. Las personas se quedan con los pasos "¿qué hacer" de un manual de procedimiento, pero no con el contexto de por qué esos pasos son importantes y qué hacemos con el resultado de cada paso. Una guía del proceso y, lo mejor de todo, un diagrama de flujo visual permitirán a los futuros directores comprender qué ofrece el sistema y qué hace que sea mucho más fácil adaptar el sistema en el futuro.

  • Criterios de selección del sistema    Cuando elige un sistema EPM y las herramientas de terceros que puede haber seleccionado a lo largo del proceso, informe a las generaciones futuras en qué se basó su decisión. Hemos ido a organizaciones 5, 7 o incluso 10 años después de haber implementado un sistema y hemos visto un sistema con varias herramientas asociadas a él y preguntado "¿por qué hacen eso? ¡Sería mucho más fácil hacer esto!" Las razones de estas decisiones no se pueden encontrar en ninguna parte. En algunos casos el cliente ha pasado varios años haciendo algo de una manera extremadamente complicada que podría haber sido mucho más fácil dada la existencia de versiones más recientes de las herramientas. No pueden tomar una decisión fácil para cambiar una herramienta o usar una versión más reciente porque ya no tienen acceso a la razón por la que decidieron hacer algo de determinada manera hace años.

Realmente no hay un batiteléfono.

Cuando digo eso, parece como si estuviera diciendo que no existe el Conejito de Pascua o Santa Claus. Es una mala noticia. Pero realmente no hay un batiteléfono. Sin embargo, estoy seguro de que la sola ausencia de ese teléfono mágico no evitará que la gente me esté llamando mañana para pedirme que derrote al villano más reciente de Ciudad Gótica. Si se mete en problemas y siente la necesidad de llamar a un experto, estas son algunas recomendaciones:

  1. Escuche los consejos que recibe. No tiene sentido pagarle a un experto para que le dé consejos y después decidir que usted sabe más que él. Si va a pedir consejos y está tratando con un experto, intente escucharlo y tener en cuenta sus consejos. Batman no habría seguido acudiendo con el Comisionado Gordon una y otra vez si cada vez que lo hacía Gordon le hubiera dicho: "Ahora que estás aquí, Batman, por favor haz lo mismo que hacen mis demás policías".

  2. Batman podía hacerlo en 22 minutos, pero probablemente usted no pueda. Si le está llamando a un experto, permítale que le diga cuánto tiempo tomará poder solucionar su problema. Puede optar por no solucionarlo después de que haya terminado, pero la resolución de problemas de EPM, incluso los técnicos, rara vez toma solo unos minutos. Después de todo, Batman tenía que hacerlo en 22 minutos porque 8 minutos estaban asignados a los anuncios publicitarios y estos son esenciales.

  3. El Comisionado Gordon nunca le dijo a Batman la solución, solo el problema. Con demasiada frecuencia recibimos una llamada de un administrador de EPM en pánico que sabe que tengo que aplicar un parche, escribir un informe y entrenar a dos personas. Siempre lo escucho pacientemente y después le pido al cliente que me describa el problema, ya que me acaba de describir la solución. Antes de usar el teléfono para llamar a un experto, piense primero en el problema que le gustaría poner sobre la mesa.

Conclusión

En realidad, sí necesita usar el batiteléfono. Consúltelo con otros. No le pregunte a un solo experto en consultoría y no obtenga una sola solución posible. Consulte con sus colegas u otras personas en el sector a quién conocen que pueda contestar una llamada de batiteléfono y hable al menos con dos de ellos. Una buena manera de comprobar la realidad es ver cómo dos expertos diferentes resolverían su problema. Recuerde: tal vez Batman haya sido increíble, ¡pero hay muchos superhéroes entre los que elegir!

Acerca del autor

Chris Vandersluis es presidente y fundador de la empresa HMS Software, establecida en Montreal, Canadá, un asociado certificado de Microsoft. Cuenta con unos estudios en Economía en la Universidad McGill y más de 30 años de experiencia en la automatización de sistemas de control de proyectos. Es miembro del Project Management Institute (PMI) y participó en la creación de las secciones de Microsoft Project Users Group (MPUG) en Montreal, Toronto y Quebec. Entre las publicaciones en las que ha escrito Chris se encuentran Fortune, Heavy Construction News, Computing Canada Magazine y PMNetwork de PMI; también es columnista habitual en Project Times. Enseña Administración avanzada de proyectos en la Universidad McGill y con frecuencia habla en funciones de la asociación de administración de proyectos en Norteamérica y en todo el mundo. HMS Software es el proveedor del sistema de control para los proyectos de TimeControl y es asociado de la solución Microsoft Project desde 1995.

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

Si desea leer más artículos relacionados con EPM de Chris Vandersluis, consulte el sitio de orientación 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.

×