Asistencia de GPS en la planeación de una implementación de EPM: notas del producto

Estas notas del producto forman parte de la colección "Desde las trincheras". Aquí se describe cómo realizar un plan de implementación de la administración de proyectos empresariales cuando planea implementar EPM. Únicamente se describen los factores que se deben tener en cuenta al planear la ruta de implementación.

Para descargar la versión de Word de estas notas del producto, vea Asistencia de GPS en la planeación de una implementación de EPM.

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

Asistencia de GPS en la planeación de una implementación de EPM

En mi última columna, he hablado acerca de usar un enfoque por fases para realizar sus planes para una implementación de la solución Enterprise Project Management (EPM) de Microsoft. Hoy vamos a tratar cómo realizar un plan de implementación de EPM como parte de su plan de proyecto.

Si ha usado Microsoft Live Maps sabe que las indicaciones requieren dos cosas: un destino y un punto de origen. Cuando aplicamos esta analogía a una implementación de EPM tenemos que pensar en términos similares:

  1. Punto de origen definido en términos tecnológicos, de procesos y personales

  2. Destino definido en términos de negocios y prioridades

También podemos definir algunas "estaciones de paso" o "paradas interinas" en las que puede reagruparse, tomar fotografías, disfrutar del paisaje por un momento y reponer su suministros para el siguiente tramo del viaje.

Cuando se idea un plan o indicaciones, es bastante común que tenga dos escalas. Conservamos el siguiente tramo del viaje con gran detalle en una ruta paso a paso. Sin embargo, también es posible conservar un mapa de nivel más alto de todo el viaje con menos detalles para mantener el tramo actual en el contexto de todo el viaje. En los términos de la administración de proyectos, eso se denomina "planeación gradual".

"Indicaciones"

Cuando se realiza un plan de implementación de EPM, siempre comenzamos con la visión o la intención que tiene en mente la empresa en términos de sus esfuerzos de EPM. Esto nos proporciona el destino que necesitamos para realizar las indicaciones tal como lo haría Microsoft Live Maps.

Mapa que muestra la ruta de Seattle a Montreal

Si solo preguntáramos: "¿Qué desea?", la respuesta casi siempre sería en términos de una solución. Es probable que las personas digan "Necesito un informe que sea similar a esto" o "Nuestra empresa necesita análisis de cartera".

Para aquellos de nosotros que estamos en el negocio de las soluciones, sabemos que estos tipos de notas de diseño están cargados de riesgos. Entrenamos a nuestros consultores para que escuchen a clientes que describen su problema como una solución. Por lo general, les decimos "Eso es una solución a un problema, no el problema. Vamos a definir el problema".

Por lo que no tendemos a preguntar "¿Qué desea?". En su lugar, las preguntas que pueden ser útiles durante una visualización pueden incluir:

"¿Qué decisiones empresariales no puede tomar en este momento o es capaz de tomar solo con gran dificultad, y cuya realización sería más sencilla como resultado de esta implementación de EPM?"

O:

"¿Qué aspecto de la organización cree que podría ser más eficaz a través de un aumento en el rendimiento o un descenso en el esfuerzo a través de esta implementación de EPM?"

Ahora, ¿a quién hay que hacerle estas preguntas? ¿Por qué? Desde luego, a las personas que toman estas decisiones. Supongamos que tiene una camioneta llena de niños y se gira a preguntarles a ellos a dónde debería ir, lo más probable es que reciba 50 respuestas.

Del mismo modo, es necesario asegurarse de que los encargados de tomar decisiones en la organización sean una parte clave de este proceso o corremos el riesgo de elegir una dirección hacia la cual el "conductor" no está preparado para conducir. Hay un beneficio adicional de incluir personal directivo en el proceso de planeación de EPM en este momento. Además de ser participantes fundamentales al elegir la dirección en la que debe ir la implementación de EPM, también pueden obtener una idea de la magnitud del proyecto. Uno de los desafíos más comunes y difíciles para una implementación de EPM correcta es el apoyo de la administración a largo plazo. Algunos altos ejecutivos no han considerado hasta qué punto esto podría cambiar las prácticas y los procedimientos existentes y cuán molesto, aunque sea temporalmente, puede resultar. Es probable que tampoco tengan conocimiento del esfuerzo que puede demandar un proyecto de cambio de cultura como EPM.

Durante nuestro trabajo con la administración ejecutiva así como con la administración de proyectos y, quizás, el personal de la línea, tratamos de conectar decisiones empresariales o eficiencia de la empresa con procesos y tecnología. ¿Hay un proceso que debe crearse a fin de cumplir este requisito? ¿Qué se necesita para llevarlo a cabo? ¿Hay una función del sistema que existe o deba crearse para acompañar esa decisión empresarial? ¿Qué debe ofrecer?

El análisis de sistemas básicos es clave en esta fase. Comenzamos a partir del "resultado" de las decisiones empresariales y trabajamos en sentido contrario hacia los elementos de datos necesarios para tomar esas decisiones. En algunos casos, nos encontramos con que los datos básicos simplemente no están allí y esto genera que se marque ese elemento del plan como de "riesgo alto". Después de todo, ahora debemos incluir los datos recopilados en un nuevo formato o estructura para capturar esos nuevos elementos de datos antes de poder siquiera entregar el mejor proceso empresarial, y eso puede resultar un verdadero desafío en algunos casos.

Existe otra cosa que debe hacerse antes de cerrar el proceso de destino y es clasificar por prioridad los diferentes elementos de la visión final. Es muy frecuente pensar al principio del proceso de planeación que las prioridades tendrán un rumbo pero luego encontrarse con que cuando va a registrarlas, el rumbo es muy diferente. Es interesante que, en el momento en el que todos acuerdan los objetivos que se incluyen en nuestro destino, existe un notable consenso sobre cuáles deben ser las principales prioridades.

Lo primero que se necesita para elaborar indicaciones es un punto de origen y lo conseguimos a través de un inventario de dónde se encuentra la organización ahora en relación con los objetivos que ha elegido.

Mapa que muestra la ruta de Seattle a Montreal

Analicemos el personal existente. ¿Se entrenaron en la administración de proyectos para sus roles particulares? ¿Contamos con suficiente personal con experiencia pertinente para alcanzar los objetivos que se han establecido? Recuerde que debemos analizar varias medidas aquí porque distintas personas tendrán un rol diferente en el proceso de administración de proyectos empresariales eventuales. No tiene ningún sentido entrenar a cada empleado para que sea un programador de proyectos si, de hecho, nunca serán los encargados de crear programaciones. De forma predeterminada, pensamos en cuatro roles: administrador, jefe de proyecto, recurso individual y ejecutivo. Si también se usan planillas de horas trabajadas, también pensamos en los supervisores como quinto rol. Por supuesto, según el destino que ha definido en nuestro proceso de visualización original, los roles pueden ser bastante diferentes. Eso cambia el proceso de inventario de aptitudes profundamente, por lo que siempre comenzamos por definir el destino antes de pensar en el punto de origen.

Asimismo, analizamos el proceso existente. ¿Hay un proceso de administración de proyectos documentado o establecido? ¿Cómo se mantiene? ¿Quién está a cargo de él? Si ya hay una oficina de administración de proyectos establecida, entonces gran parte del esfuerzo se centra allí. Después de todo, no tiene sentido crear nuevos procedimientos si ya existen procedimientos y procesos que ya son eficaces. Es posible que los procesos existentes de inventario estén dentro del proceso de administración de proyectos actual y fuera de él, según los objetivos finales del entorno de EPM.

Por ejemplo, podríamos haber decidido que la gestión de contratos va a ser un elemento importante de nuestro nuevo entorno de EPM, y nunca antes esto ha sido parte de los procesos de administración del proyecto dentro de esta organización. No obstante, si miramos un poco más lejos, podemos encontrar que la organización tiene un sólido conjunto de controles para administrar documentos y un flujo de trabajo existente que ya mueve documentos, quizás en SharePoint. Este sería un proceso ideal para empezar a adoptar y, si es necesario, podría ajustarse para asegurarnos de que habilitará este aspecto del nuevo entorno de administración de proyectos empresariales. Al hacerlo, se obtiene un triple beneficio. En primer lugar, nos evitamos el esfuerzo de tener que crear un proceso nuevo. Segundo, sabremos que el personal ya tiene las aptitudes y los hábitos para usar el proceso de esta forma, lo que significa no tener que realizar el esfuerzo de aprendizaje o el esfuerzo para lograr que el personal cumpla. Por último, no tenemos la difícil situación de tratar de crear un proceso separado, que podría estar en contradicción con un proceso existente para administrar documentos, como contratos.

Sabemos que uno de nuestros mayores desafíos va a ser el cumplimiento. No construir el sistema, sino lograr que todo el mundo lo use y lo use regularmente. Cuanto más podamos adoptar hábitos, prácticas y procedimientos existentes que ya están incorporados en la organización, más fácil será el cumplimiento.

Finalmente, necesita una lista de inventario de la plataforma de tecnología. Puesto que la solución Microsoft EPM está integrada en una plataforma de tecnología, es probable encontrar parte de esa tecnología ya implementada, pero también es posible que la organización tenga que actualizar algunas de sus plataformas para que la solución que está diseñando funcione. SQL Server y SharePoint son elementos evidentes de la implementación de Microsoft Office Project Server, pero es posible que también tenga que comprobar la compatibilidad del explorador (¿todos los usuarios están usando la última versión de Internet Explorer?), el estado de seguridad (¿el sistema está orientado hacia el exterior?), qué versión de SQL Server está implementada (¿ya se usan los Servicios OLAP o SQL Server Reporting Services?). Es posible que también tenga que contemplar otros sistemas que deberá integrar o con los que tendrá que realizar interfaz. ¿Cómo se tiene acceso a esos sistemas en producción?

El tamaño del sistema previsto puede requerir analizar también el hardware, la red y otros elementos de la infraestructura para garantizar que el sistema tendrá la estructura que requiere cuando lo reciba.

Al igual que con cualquier sistema de empresa, querrá planear un área de producción y de ensayo para que las actualizaciones y las mejoras se puedan crear en el laboratorio en lugar de en el sistema activo a lo largo del tiempo. Es posible que también tenga que hacer planes para un programa piloto o una fase de prueba de concepto (le proporcionaré más información sobre esto en mi próxima columna).

"Recalculando la ruta"

Cuando el GPS de mi automóvil detecta que he perdido el rumbo, una voz muy agradable de una señorita dice "Recalculando la ruta". Momentos después, el trayecto de mi mapa cambia y aparecen nuevas indicaciones. En una implementación de EPM tenemos que estar listos para una desviación o un giro que esté bloqueado por obras. Quizás nos pasamos de la salida de la autopista. ¿Qué podemos hacer con la replanificación? Hay dos aspectos que debe plantearse al desviarse del camino: en primer lugar, ¿seguirá yendo de todos modos al mismo lugar? Segundo, ¿cómo podemos llegar desde aquí? Una de mis citas favoritas sobre administración de proyectos pertenece a Napoleón Bonaparte, quien dijo una vez: "Un plan de batalla dura hasta hacer contacto con el enemigo".

Mapa que muestra la ruta de Seattle a Redmond

En una implementación de EPM, ¿cómo podemos aplicar este mismo principio? Primero, necesita una medida para determinar si se desvía del camino. Si un miembro del equipo tiene una cita de emergencia con el dentista mañana y está ausente de la oficina durante cuatro horas, ¿debe permitir que esa discrepancia cambie todas las tareas que siguen en la cadena, es decir, debe reprogramar las tareas de todos desde la mañana hasta el final del proyecto y, luego, enviarles por correo electrónico a todos los nuevos horarios de asignación?

Por supuesto que no.

Una discrepancia de cuatro horas para un recurso de más de seis meses de un proyecto que comprende decenas de personas no es suficiente para justificar el cambio de camino. Lo que necesitamos hacer al iniciar cualquier tipo de proyecto empresarial es establecer umbrales de progresos aceptables. El mundo aeroespacial y de defensa está buscando un nuevo término para esto, "cuerda de trampa", que es muy descriptivo. Podemos establecer qué criterios nos indican que debemos recalcular nuestra ruta. Hay varias métricas o medidas típicas para tener en cuenta. En primer lugar, si el coste de la terminación prevista varía en más del X por ciento del presupuesto original, eso podría constituir una revisión del plan de proyecto. Puede realizar la medición del costo en horas de trabajo o dinero. Ambos son eficaces. Por ejemplo, si la fecha de finalización prevista varía por más de X días de la fecha de finalización planificada originalmente, eso podría constituir una revisión del plan de proyecto.

Es posible que también decida que la falta de ciertos hitos clave durante más de un determinado número de días sea una cuerda de trampa, o es posible que haya identificado algunos riesgos como una cuerda de trampa, o bien, puede determinar que un cambio de determinados miembros clave del equipo del proyecto como el patrocinador ejecutivo es una cuerda de trampa. Es más importante establecer algunos criterios que llegar exactamente a ellos. Además, recuerde que va a necesitar realizar mediciones en función de estos criterios durante la vigencia del proyecto, por lo que, si opta por 50 o 100 mediciones diferentes, podría terminar dedicando más tiempo a medir el proyecto que a realizar el proyecto.

Una vez que haya determinado que está fuera del camino, la mejor manera de retomar el rumbo consiste en realizar una revisión del plan de proyecto. Le recomendamos incluir la representación tanto del grupo original de los directivos que ayudó a establecer nuestro destino en primer lugar como del grupo del equipo de administración de proyectos que ayudó con el inventario original. Las revisiones del plan del proyecto pueden quedar atrapadas en echar la culpa de por qué el proyecto está fuera de rumbo y por qué se ha desencadenado una determinada cuerda de trampa. Este tipo de esfuerzo puede ser muy contraproducente. Le recomendamos centrarse en las siguientes preguntas:

  1. ¿Qué ha ocurrido?

  2. ¿Dónde hemos terminado? ¿Cuál es nuestro punto actual de origen?

  3. ¿Todavía estamos comprometidos con nuestro destino original o hay una razón de peso para revisar ese proceso o incluso rehacer el proceso de visualización?

  4. ¿Es necesario restablecer alguno de nuestros hitos o fases intermedias?

  5. ¿Es necesario cambiar algún miembro del equipo de proyecto?

  6. ¿Es necesario restablecer algunas de las mediciones de cuerdas de trampa?

Las preguntas que hemos encontrado que son menos productivas incluyen:

  • ¿De quién es la culpa de que estemos aquí? ¿Quién es responsable? ¿Quién es el culpable?

  • ¿Cómo retomamos el rumbo al plan antiguo?

La razón más común para realizar una revisión del plan de proyecto es el cambio de prioridades de la organización. Por ejemplo, los elementos que se diseñaron para la fase 3 se exigen en la fase 2. Este suele ser un indicio de una buena dinámica dentro de la organización y el resultado de personas que comienzan a pensar seriamente en las consecuencias de la implementación del sistema de EPM.

Mal tiempo

Antes de salir de viaje es probable que compruebe el Canal del tiempo (o weather.msn.com) para asegurarse de que ningún mal tiempo afectará a su viaje. Los riesgos son parte de la vida. Recuerde que si no hubiera riesgos, no habría necesidad de disponer de jefes de proyecto. Planear para los riesgos más evidentes no es un proceso complicado. Empiece desde el principio del proceso de visualización y a medida que mire cada uno de los elementos del destino que está diseñando, pregúntele al grupo qué barreras creen que pueden encontrar para llegar a ese destino. En algunos casos los riesgos serán importantes. No es raro para una organización querer un resultado en particular, solo para encontrarse con que los datos sin procesar requeridos para obtener ese resultado nunca se han recopilado y que puede haber una resistencia considerable a la recopilación de los datos.

Página de MSN que muestra la previsión meteorológica para Montreal

En un ejemplo había una organización que quería llevar a cabo la planeación de capacidades de recursos. Eso iba a requerir una contabilidad completa de la disponibilidad de todos los recursos de todo el personal de proyectos y una contabilidad completa de todas las planillas de horas trabajadas que se podían aplicar al personal. Cuando les preguntamos si ambos estaban disponibles, nos dijeron que seguramente sí, que estaban disponibles pero solo para dos quintas partes de la organización. Luego, cuando nos dimos cuenta de que tres quintas partes de la organización para las que no estaban los datos disponibles ni siquiera estaban representadas en la reunión de visualización, dijimos, "Déjennos adivinar. Los problemas que experimentan con la planeación de capacidades de recursos se encuentran en aquellas tres divisiones". Naturalmente, ahí radicaba el problema. Hubo que identificar la inscripción de los líderes de esas divisiones como una etapa distinta del proyecto, lo que generaba un riesgo muy alto.

A medida que comience a trabajar con la administración de proyectos y el personal de la línea en el proceso de inventario, pregúnteles durante las entrevistas por los riesgos que son capaces de identificar.

Una vez que se han identificado los riesgos, es importante organizarlos. Si no ha hecho esto antes, la información más básica será la más valiosa. Incluya:

  1. Una breve descripción del riesgo

  2. El área o la fase del proyecto que puede verse afectado

  3. La gravedad del riesgo si se cumplen los criterios

Por último, una de las cosas más importantes que puede hacer es agregar algunos detalles sobre la mitigación de riesgos. Tan solo pensar en un riesgo es un gran factor de mitigación, pero aunque la implementación de EPM esté en sus inicios, escribir algunas notas sobre cómo es posible abordar un riesgo en particular durante el proyecto puede ser sumamente útil. Es frecuente que cuando surgen los riesgos las decisiones se toman de prisa en un contexto emocional. Tener algunas notas de pensamientos fríos puede ser útil.

Vamos a conducir el automóvil que estamos construyendo

Un consejo sobre cómo hacer que su plan dé buenos beneficios: use Project Server y la solución Microsoft EPM para realizar y administrar su plan básico. Parece obvio tal vez, pero es raro que las organizaciones hagan lo que mencionamos aquí.

Sitio de SharePoint que muestra una lista de entregas del proyecto

Un director senior una vez me dijo que su personal del proyecto le había preguntado si él no consideraba usar la solución Microsoft EPM para implementar la solución Microsoft EPM como un exceso. "Si creáramos aviones de reacción para ganarnos la vida, no los utilizaríamos para ir a trabajar", dijeron. "¿Es broma?", respondió. "Si pudiera venir a trabajar en un avión de reacción, lo haría todos los días".

De hecho, usar la solución Microsoft EPM para el equipo de implementación es una magnífica idea.

Instalar Project Server y los demás elementos de la solución Microsoft EPM no es un enorme desafío técnico, y con el mínimo absoluto de configuración, puede ponerlo en funcionamiento para un pequeño equipo de implementación que haría de usuario en un par de días. Esta es una buena forma para aquellos usuarios que se convertirán en los campeones de la implementación puedan familiarizarse con el uso y las ventajas del sistema antes de que llegue a los escritorios de la mayor parte del personal.

Esta implementación no debería estar en su entorno de producción. Casi seguro que usted la va a configurar y personalizar para cumplir la visión del destino original. Seguramente no va a trabajar en cosas como programación de múltiples proyectos o planeación de capacidades de recursos o la optimización de carteras en la iteración de la implementación de EPM de Project Server, pero podrá entregar un sistema que puede ofrecer grandes ventajas. Le recomendamos:

  1. Realice una programación gradual como un proyecto publicado.

    Una programación gradual resalta la fase actual con gran detalle y las fases futuras como un resumen. Esto permite que los miembros del equipo tengan la información necesaria sobre lo que están haciendo e incluso puedan ver el proyecto en un contexto más amplio.

  2. Administre el documento sobre la visión en el área de trabajo del proyecto.

    El área de trabajo del proyecto es un sitio de SharePoint ligado al proyecto que, de forma predeterminada, incluye un área para problemas, riesgos y documentos. ¿Por qué no colocar todos los documentos del proyecto aquí para el proyecto de implementación de EPM y establecer el control de versiones de SharePoint para que siempre pueda volver a la versión original?

  3. Coloque las aprobaciones de hitos y las "puertas" en los resultados del área de trabajo del proyecto.

    Esta es una simple lista de tareas que puede vincular a las tareas en Project Server. Le proporcionará una vista de alta calidad del proyecto y es una herramienta fácil de usar para la administración de umbrales para determinar cuándo "se va de rumbo".

  4. Coloque la administración de cambios en el área de trabajo del proyecto como problemas.

    La administración de cambios es uno de los grandes desafíos de los proyectos tecnológicos. A medida que surjan nuevas sugerencias para los cambios del proyecto, agréguelas al área de problemas como un posible cambio que deba administrarse. Al agregar algunos campos en esta área puede obtener una lista de los elementos de prioridad alta y saber quién es responsable de ellos en cualquier momento.

  5. Coloque los riesgos del proyecto en el área de trabajo del proyecto.

    Además de los documentos y los problemas, el área de riesgo del área de trabajo es el lugar ideal para agregar sus riesgos y planes de mitigación. De hecho, en la pantalla predeterminada tiene todos los campos allí listos para usarlos.

¿Ya llegamos?

"Casi. Pronto llegaremos".

Una implementación de EPM puede llevar a una organización a numerosos lugares, por lo que no se puede simplemente publicar la programación predeterminada para todos los usuarios. Pero si busca unos minutos en Internet puede obtener una gran cantidad de posibles ejemplos de distintas partes del proyecto. Si resumo el ejercicio de planeación anterior, es probable que se encuentre con un proyecto que tiene unas cuantas fases obvias:

  1. Ejercicio de planeación

    1. Visualización (elegir el destino)

    2. Inventario de procesos existentes (identificar el punto de origen)

    3. Inventario de personal existente (identificar el punto de origen)

    4. Inventario de tecnología (identificar el punto de origen)

  2. Implementación de la solución EPM para un equipo de EPM

  3. Fase 1

    1. Diseño

    2. Configuración, personalización, documentación

    3. Piloto

    4. Cursos

    5. Lanzamiento

    6. Revisión de la fase 1 y ajuste de la fase 2 según sea necesario

  4. Fase 2

  5. Fase 3

  6. Fase 4

  7. Conclusión del proyecto

Aplicar un ejercicio de planeación a su implementación de EPM puede cambiar la experiencia de una situación caótica a algo que se puede administrar muy rápidamente. Simplemente recuerde elegir su destino en primer lugar, luego averiguar su punto de origen y dibujar la ruta entre ellos.

¡Buen viaje!

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.

×