Asistencia de GPS a la hora de planear una implementación EPM
Este artículo forma parte de nuestra colección "From the Trenches". Describe cómo convertir una implementación de Enterprise Project Management en "hoja de ruta" al planear la implementación de EPM. Se describen de forma exclusiva factores que hay que tener en cuenta al planear la ruta de la implementación.
Para ver más artículos, consulte las notas del producto "Desde las trincheras".
Asistencia de G.P.S. en el plan de desarrollo de una implementación de EPM
En mi última columna, hablé sobre el uso de un enfoque por fases para realizar sus planes para una implementación de la solución De administración de proyectos empresariales (EPM) de Microsoft. Hoy abordaremos la elaboración de un plan de implementación de EPM como parte del plan de proyecto.
Si ha estado en Microsoft Live Maps, sabe que las instrucciones 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:
Punto de origen definido en términos de tecnología, proceso y personal
Destino definido en términos empresariales y con prioridad
También es posible que deseemos definir algunas "estaciones de camino" o paradas provisionales donde pueda reagrupar, tomar fotos, disfrutar del paisaje durante un tiempo y reabastecer sus suministros para la siguiente etapa del viaje.
Al hacer una hoja de ruta o instrucciones, es bastante común tener dos escalas. Mantenemos la siguiente etapa del viaje con gran detalle, hasta una ruta paso a paso. Sin embargo, también podríamos mantener un mapa de nivel superior de todo el viaje con menos detalle para mantener nuestra pierna actual en el contexto de todo el viaje. En términos de administración de proyectos, llamamos a este "planeamiento de onda gradual".
"Instrucciones"
Al hacer una hoja de ruta de implementación de EPM, siempre comenzamos con la visión o la intención de hacia dónde se dirige la empresa en términos de sus esfuerzos de EPM. Esto nos proporciona el destino que necesitaremos para hacer indicaciones como lo haría Microsoft Live Maps.
Si simplemente preguntamos, "¿Qué quieres?" la respuesta casi invariablemente viene en términos de una solución. Personas probablemente digan "Necesito un informe similar a este" o "Nuestra firma necesita análisis de cartera".
Para los que estamos en el negocio de soluciones, sabemos que este tipo de notas de diseño están cargadas de riesgo. Entrenamos a nuestros consultores para que escuchen a los clientes que describen su problema como una solución. "Esa es una solución a un problema", diremos, "no el problema. Vamos a definir el problema".
Por lo tanto, tiendemos a no preguntar "¿Qué quieres?" En su lugar, las preguntas que pueden ser útiles durante una previsión pueden incluir:
"¿Qué decisión empresarial es la que ahora no puede tomar o solo puede tomar con gran dificultad, lo que facilitaría la toma de medidas como resultado de esta implementación de EPM?"
O bien:
"¿Qué aspecto de la organización cree que se podría hacer más eficiente a través de un aumento del rendimiento o una disminución del esfuerzo a través de esta implementación de EPM?"
Ahora, ¿de quién deberíamos hacer estas preguntas? ¿Por qué, la gente que toman estas decisiones, por supuesto! Si alguna vez has tenido una minivan llena de niños y te has vuelto a preguntar a dónde deberías ir como destino, sabes que obtendrás 50 respuestas.
Con el mismo token, debemos asegurarnos de que los responsables de la toma de decisiones de la organización son una parte clave de este proceso o corremos el riesgo de elegir una dirección a la que el "conductor" no esté preparado para viajar. En este momento, hay una ventaja adicional para incorporar a la alta dirección en el proceso de planificación de EPM. Además de ser un participante crítico en la elección de la dirección en la que debe ir la implementación de EPM, también pueden hacerse una idea de la magnitud del proyecto. Uno de los desafíos más comunes y difíciles para una implementación correcta de EPM es el soporte técnico de administración a largo plazo. Algunos ejecutivos sénior no han considerado la cantidad que esto podría cambiar las prácticas y los procedimientos existentes y lo perturbador que podría ser, incluso temporalmente. También es posible que no tengan una apreciación de cuánto esfuerzo puede ser un proyecto de cambio cultural como EPM.
Durante nuestro trabajo con la alta dirección, así como con la administración de proyectos y quizás con el personal de línea, intentamos conectar las decisiones empresariales o la eficiencia empresarial con procesos y tecnología. ¿Hay un proceso que se debe crear para cumplir este requisito? ¿Qué tendría que hacer? ¿Existe o debe crearse una función del sistema para atender esa decisión empresarial? ¿Qué necesitaría entregar?
El análisis de sistemas básicos es clave en esta fase. Comenzamos a partir de la "salida" de la decisión empresarial y volvemos a los elementos de datos necesarios para tomar esas decisiones. En algunos casos, encontramos que los datos básicos simplemente no están ahí y esto da lugar a que ese elemento de la hoja de ruta se marque como "alto riesgo". Después de todo, ahora tendremos que incluir la recopilación de datos en un nuevo formato o estructura para capturar esos nuevos elementos de datos antes de incluso pensar en ofrecer el mejor proceso empresarial, y eso puede ser un orden alto en algunos casos.
Tenemos una cosa más que hacer antes de cerrar el proceso de destino y eso es priorizar los diferentes elementos de la visión final. Es muy común pensar al principio del proceso de hoja de ruta que las prioridades van a ir de una manera, pero encontrar que a medida que vaya a registrarlas realmente que van muy diferente. Curiosamente, cuando todo el mundo se ha puesto de acuerdo sobre los objetivos que se incluyen en nuestro destino, hay un notable consenso sobre cuáles deben ser las principales prioridades.
Lo siguiente que necesitamos para las direcciones es un punto de origen y lo administramos a través de un inventario de dónde está la organización ahora en relación con los objetivos que hemos elegido.
Examinamos al personal existente. ¿Están entrenados en la administración de proyectos para sus roles particulares? ¿Tenemos suficiente personal con experiencia suficiente para lograr los objetivos que se han establecido? Recuerde que tenemos que examinar varias medidas aquí porque diferentes personas tendrán un rol diferente en el proceso de administración de proyectos empresariales eventual. No tiene sentido entrenar a todos los empleados para que sean programadores de proyectos si, de hecho, nunca serán responsables de crear programaciones. De forma predeterminada, pensamos en cuatro roles: Administrador, Administrador de proyectos, Recurso individual y Ejecutivo. Si los partes de horas están involucrados, pensamos también en los supervisores como quinto rol. Por supuesto, dependiendo del destino que hayamos definido en nuestro proceso de previsión original, los roles pueden ser muy diferentes. Esto cambia profundamente el proceso de inventario de aptitudes, por lo que siempre comenzamos definiendo el destino antes de pensar en el punto de origen.
También examinamos el proceso existente. ¿Hay un proceso de administración de proyectos declarado o documentado? ¿Cómo se mantiene? ¿Quién está a cargo de ello? Si ya hay una oficina de administración de proyectos establecida, mucho de este esfuerzo se centra allí. Después de todo, no tiene sentido crear nuevos procedimientos si existen procedimientos y procesos que ya son eficaces. Podemos hacer un inventario de los procesos existentes que están dentro del proceso de administración de proyectos actual y fuera, dependiendo de cuáles serán los objetivos finales del entorno de EPM.
Por ejemplo, es posible que hayamos decidido que la administración de contratos va a ser un elemento significativo de nuestro nuevo entorno de EPM y que esto nunca antes ha sido parte de los procesos de administración de proyectos dentro de esta organización. Sin embargo, si miramos un poco más lejos, es posible que descubramos que la organización tiene un conjunto sólido de controles para administrar documentos y flujos de trabajo existentes que ya mueven documentos, quizás en SharePoint. Este sería un proceso ideal para que adoptemos y, si fuera necesario, nos ajustaremos para asegurarnos de que potenciará este aspecto del nuevo entorno de administración de proyectos empresariales. Hacerlo conlleva una ventaja de triple filo. En primer lugar, no es necesario gastar el esfuerzo en crear un nuevo proceso. En segundo lugar, sabemos que el personal ya tiene las habilidades y los hábitos para utilizar el proceso de esta manera, lo que significa que no hay esfuerzo de capacitación ni esfuerzo para lograr que el personal cumpla. Por último, no tenemos la difícil situación de intentar crear un proceso independiente que pueda estar en conflicto con un proceso existente para administrar documentos, como los contratos.
Sabemos que uno de nuestros mayores desafíos va a ser el cumplimiento. No crea el sistema, sino que hace que todo el mundo lo use y lo use de forma coherente. Cuanto más podamos adoptar los hábitos, prácticas y procedimientos existentes insertados en la organización, más fácil será el cumplimiento.
Por último, necesita un inventario de la plataforma tecnológica. Dado que la solución microsoft EPM se basa en una plataforma de tecnología, es probable que encuentre parte de esa tecnología ya en su lugar, pero también es posible que la organización tenga que actualizar parte de su plataforma para que la solución que está diseñando funcione. SharePoint y SQL Server son elementos obvios de la implementación de Microsoft Office Project Server, pero también es posible que tenga que comprobar la compatibilidad del explorador (¿todos usan la versión más reciente de Internet Explorer?), el estado de seguridad (¿estará el sistema orientado hacia fuera?), qué versión de SQL Server se implementa (es OLAP Services o SQL Server Reporting Services ya se está usando). También es posible que tenga que tener en cuenta otros sistemas con los que tendrá que interactuar o integrar. ¿Cómo obtendrá acceso a esos sistemas en producción?
El tamaño del sistema planeado también puede necesitar examinar el hardware, la red y otros elementos de infraestructura para asegurarse de que el sistema tendrá la estructura que requiere cuando llegue.
Al igual que con cualquier sistema empresarial, querrá planear un área de producción y almacenamiento provisional para que se puedan crear actualizaciones y mejoras en el laboratorio en lugar de en el sistema en directo a lo largo del tiempo. También puede que tenga que hacer planes para una fase piloto o prueba de concepto; algo de lo que hablaré más en mi siguiente columna.
"Recalcular ruta"
Cuando la unidad G.P.S. en mi auto descubre que me he perdido un turno, la voz de una dama muy agradable dice "Recalcular ruta". Momentos después, la línea a través de mi mapa cambia y tengo nuevas direcciones. En una implementación de EPM, debemos estar listos para un desvío o un turno que esté bloqueado para reparaciones. Tal vez nos perdimos la salida de la autopista. ¿Cómo nos ocupamos de la replannación? Hay dos cosas que preguntar al salir del curso: en primer lugar, ¿sigues yendo al mismo lugar? Segundo, ¿cómo llegamos desde aquí? Una de mis citas favoritas de gestión de proyectos sobre este tema proviene de Napoleón Bonaparte, quien una vez dijo: "Un plan de batalla dura hasta el contacto con el enemigo".
En una implementación de EPM, ¿cómo aplicamos este mismo principio? En primer lugar, necesita una medida para determinar si ya no está en curso. Si un miembro del equipo tiene una cita con un dentista de emergencia mañana y está ausente de la oficina durante cuatro horas, ¿deberíamos dejar que esa discrepancia cambie todas las tareas de bajada, reprogramar a todos desde mañana al mediodía hasta el final del proyecto y, a continuación, enviar un correo electrónico a todos con sus nuevas horas de asignación?
Claro que no.
Una discrepancia de cuatro horas para un recurso durante los seis meses de vida de un proyecto que involucra a decenas de personas no es suficiente con una interrupción para justificar el cambio de nuestro camino. Lo que debemos hacer al iniciar cualquier tipo de proyecto empresarial es establecer umbrales de progreso aceptable. El mundo aeroespacial y de defensa está encontrando un nuevo término para esto últimamente, "Tripwires", que es muy descriptivo. Podemos establecer qué criterios nos indicarían que es necesario volver a calcular la ruta. Hay varias métricas o medidas típicas que se deben tener en cuenta. En primer lugar, si el costo de finalización proyectado varía en más de X por ciento del presupuesto original, podría constituir una revisión del plan de proyecto. Puede hacer la medida del costo en horas de trabajo o dinero. Cualquiera de ellas es efectiva. Quizás si la fecha de finalización prevista varía en más de X días a partir de la fecha de finalización prevista originalmente, podría constituir una revisión del plan de proyecto.
También puede decidir que la falta de ciertos hitos clave en más de un determinado número de días es un error de tripwire, o puede identificar ciertos riesgos que se están realizando como un tripwire, o puede determinar que un cambio de determinados miembros clave del equipo del proyecto, como el patrocinador ejecutivo, es un tripwire. Es más importante establecer algunos criterios que obtener los criterios exactamente correctos. Además, recuerde que va a tener que medir con estos criterios a lo largo de la duración del proyecto, por lo que si elige 50 o 100 métricas diferentes, podría dedicar más tiempo a medir el proyecto que a realizar el proyecto.
Una vez que haya determinado que está fuera de curso, la mejor manera de volver a la pista es llevar a cabo una revisión del plan de proyecto. Se recomienda incluir la representación del grupo original de alta dirección que ayudó a establecer nuestro destino en primer lugar y del grupo dentro del equipo de administración del proyecto que ayudó a realizar el inventario original. Las revisiones del plan de proyecto se pueden ver inmersas en la asignación de la culpa por el motivo por el que el proyecto está fuera de servicio y por qué se ha desencadenado un cierto cable. Tal esfuerzo puede ser enormemente contraproducente. Se recomienda centrarse en las siguientes preguntas:
¿Qué ha ocurrido?
¿Dónde hemos terminado? ¿Cuál es nuestro punto de origen actual?
¿Seguimos comprometidos con nuestro destino original o hay una razón atractiva para revisar ese proceso o incluso rehacer el proceso de previsión?
¿Es necesario restablecer cualquiera de nuestros hitos o fases intermedios?
¿Es necesario cambiar cualquiera de nuestro equipo de proyecto?
¿Necesitamos restablecer alguna de nuestras métricas de tripwire?
Entre las preguntas que hemos detectado que son menos productivas se incluyen las siguientes:
¿De quién es la culpa de que estemos aquí? ¿Quién es responsable? ¿Quién tiene la culpa?
¿Cómo podemos volver a la pista? ¿Volver al plan anterior?
La razón más común para una revisión del plan de proyecto es que las prioridades de la organización cambian. Por ejemplo, los elementos que se diseñaron para estar en la fase 3 se demandan en la fase 2. Esto suele ser una señal de una dinámica saludable dentro de la organización y el resultado de que las personas empiezan a pensar seriamente en las implicaciones de la implementación del sistema EPM.
Mal tiempo
Antes de salir en un viaje largo, es probable que consulte el Canal meteorológico (o weather.msn.com) para asegurarse de que ninguna inclemencia del tiempo afectará a su viaje. Los riesgos son parte de la vida. Recuerde que, si no hubiera riesgos, no habría necesidad de administradores de proyectos. La planificación de los riesgos más evidentes no es un proceso complicado. Comience al principio del proceso de previsión y, a medida que examine cada uno de los elementos del destino que está diseñando, pregunte al grupo qué barreras para llegar a este destino pueden pensar. En algunos casos, los riesgos serán significativos. No es raro que una organización desee un resultado determinado, solo que descubra que los datos sin procesar necesarios para entregar ese resultado nunca se han recopilado y que puede haber una resistencia considerable a la recopilación de esos datos.
En un ejemplo, encontramos una organización que quería planear la capacidad de los recursos. Eso iba a requerir una contabilidad completa de toda la disponibilidad de recursos de todo el personal del proyecto y una contabilidad completa de todas las cargas de trabajo posibles que se podrían aplicar a ese personal. Cuando preguntamos si ambos estaban disponibles, nos dijeron que, seguro, estaban disponibles, pero solo para dos quintas partes de la organización. Cuando descubrimos que las tres quintas partes de la organización para las que no estaban disponibles los datos ni siquiera estaban representadas en la reunión de previsión, dijimos: "Vamos a adivinar. Los problemas que experimenta con el planeamiento de la capacidad de recursos se encuentran en esas tres divisiones". Naturalmente, eran, y tuvimos que identificar la inscripción de los líderes de división de esas divisiones como una fase separada del proyecto y un riesgo muy alto.
A medida que pasa a trabajar con el personal de línea y de administración de proyectos en el proceso de inventario, solicite durante las entrevistas los riesgos que este personal pueda identificar.
Una vez identificados los riesgos, es importante organizarlos. Si no lo ha hecho antes, la información más básica será la más valiosa. Incluye:
Una breve descripción del riesgo
Área o fase del proyecto que puede afectar
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. Sólo pensar en un riesgo es un factor mitigante enorme, pero mientras la implementación de EPM está en su infancia, escribir algunas notas sobre cómo podría tratar con un riesgo determinado durante el proyecto puede ser muy valioso. Es común que las decisiones se tomen con celerción en un contexto emocional cuando se realizan riesgos. Tener algunas notas que se pensaron mientras prevalecían cabezas más frías puede ser útil.
Vamos a conducir el coche que estamos creando.
Esta es una sugerencia sobre cómo hacer su hoja de ruta que puede pagar grandes dividendos: Use Project Server y la solución microsoft EPM para ayudar a crear y administrar el plan de plan de desarrollo. Parece obvio tal vez, pero es bastante raro que las organizaciones lo hagan aquí.
Una vez tuve un gerente sénior que me dijo que el personal de su proyecto le había preguntado si pensaba que el uso de la solución microsoft EPM para implementar la solución de Microsoft EPM no era excesivo. "Si construyéramos aviones jet para vivir, no los volaríamos para trabajar", dijeron. "¿Está bromeando?", Respondió. "Si pudiera volar un avión jet para trabajar, lo haría todos los días!"
De hecho, el uso de la solución Microsoft EPM para el equipo de implementación de EPM es una buena idea.
La instalación de Project Server y los demás elementos de la solución microsoft EPM no es un gran desafío técnico y, con el mínimo absoluto de configuración, puede estar en funcionamiento con un equipo de implementación pequeño como los usuarios en un par de días. Esta es una excelente manera de que los usuarios que se convertirán en sus campeones de implementación se familiaricen 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 debe ser el entorno de producción. Casi con seguridad lo configurará y lo personalizará para cumplir la visión del destino original. Es casi seguro que no trabajará en cosas como la programación multiproyecto o el planeamiento de la capacidad de recursos o la optimización de carteras en la iteración de implementación de EPM de Project Server, pero podrá ofrecer un sistema que puede ofrecer grandes ventajas. Se recomienda lo siguiente:
Realice una programación de ola gradual como un proyecto publicado.
Una programación de ola gradual resalta la fase actual con gran detalle y futuras fases como más de un resumen. Esto permite a los miembros del equipo saber en qué deben trabajar ahora y les permite ver el proyecto en un contexto más amplio.
Administre el documento de visión en el área de trabajo del proyecto.
El área de trabajo del proyecto es un sitio de SharePoint vinculado al proyecto que, de forma predeterminada, incluye un área para problemas, riesgos y documentos. ¿Por qué no poner todos los documentos del proyecto aquí para el proyecto de implementación de EPM e instituye el control de versiones de SharePoint para que siempre pueda volver a la versión original?
Coloque los signos de hito y las "puertas" en las entregas del área de trabajo del proyecto.
Se trata de una lista de tareas sencilla que puede vincular a tareas en Project Server. Proporcionará una visión muy alta del proyecto y es una herramienta fácil de usar para la administración de umbrales para determinar cuándo se va "fuera del curso".
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 en el proyecto, conséctelos en el área Problema como un posible cambio que se va a administrar. Al agregar algunos campos a esta área, puede obtener una lista de elementos de alta prioridad y quién es responsable de ellos en cualquier momento.
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 los riesgos y los planes de mitigación. De hecho, la pantalla predeterminada tiene todos los campos listos para su uso.
¿Ya hemos llegado?
"Casi. Estaremos allí pronto".
Una implementación de EPM puede llevar una organización a tantos lugares diferentes que no hay manera de publicar simplemente la programación predeterminada para todos. Pero unos minutos de búsqueda en Internet pueden proporcionarle una gran cantidad de ejemplos posibles para diferentes partes del proyecto. Si resumo el ejercicio de hoja de ruta anterior, es probable que termine con un proyecto que tenga algunas fases obvias:
Ejercicio de hoja de ruta
Envisioning (Elegir el destino)
Inventario de procesos existentes (Identificar el punto de origen)
Inventario del personal existente (Identificar el punto de origen)
Inventario de tecnología (Identificar el punto de origen)
Implementación de la solución EPM para el equipo de EPM
Fase 1
Diseño
Configuración, personalización, documentación
Piloto
Formación
Implementación
Revisión de la fase 1 y ajuste la fase 2 según sea necesario
Fase 2
Fase 3
Fase 4
Encapsulado del proyecto
La aplicación de un ejercicio de hoja de ruta a la implementación de EPM puede cambiar la experiencia de caótica a manejable muy rápidamente. Solo tiene que recordar elegir primero el destino, averiguar el punto de origen siguiente y dibujar la ruta entre ellos.
¡Feliz viaje!
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).