No se deje vencer por el período de semidesintegración (t 1/2): controlar la solución de PPM después de la implementación
Este artículo forma parte de nuestra colección "From the Trenches". Describe cómo configurar un marco para configurar un modelo de gobernanza para la solución De administración de cartera de proyectos (PPM). También incluye un plan de gobernanza de ejemplo que podría usarse como punto de partida para configurar su propia estrategia de gobernanza.
Para descargar la versión Word de este artículo, consulte Beat the Half-life (t 1/2): Governing Your PPM Solution, Post-Implementation: white paper.
Para ver más artículos, consulte las notas del producto "Desde las trincheras".
Superar la vida media (t 1/2): Gobernar la solución ppm, después de la implementación
Introducción
En física radioactiva, la vida media (t1/2) es la cantidad de tiempo necesario para que una cantidad caiga a la mitad de su valor medido al principio del período de tiempo. (Referencia: https://en.wikipedia.org/wiki/Half-life).
Por lo tanto, ¿cómo se aplica a la nueva solución de administración de cartera de proyectos (PPM) implementada recientemente? La razón por la que se aplica es porque la solución PPM, implementada correctamente, viene con una fecha de expiración. Si no se toma el tiempo necesario para planear, diseñar y ejecutar un proceso de gobernanza en torno a la administración de la solución PPM, puede estar seguro de que la solución se rellenará con datos obsoletos, cambios de diseño incorrectos, procesos que no están sincronizados con los procesos de la organización reales y la lista continúa. Al igual que un coche que nunca recibe mantenimiento, su solución dejará de producir el ROI que se espera fuera de él. Los usuarios se convertirán en pasivos y dejarán de usar la solución o abogarán vociferantemente por una solución diferente.
El objetivo de este documento es analizar un marco para configurar un modelo de gobernanza para la solución PPM. También se proporciona un plan de gobernanza de ejemplo que podría usarse como punto de partida para configurar su propia estrategia de gobernanza.
El qué y el por qué
Aunque la palabra gobernanza podría significar cosas diferentes para diferentes personas, en esencia, un plan de gobernanza es un conjunto de directivas y procedimientos autoimpuestos, para asegurarse de que la aplicación es saludable en todas las áreas y producir el mejor retorno de valor para la inversión realizada en la herramienta.
¿Por qué es necesario tener estas restricciones? Es similar al mantenimiento de la casa en la que vives. Imagine, cada vez que necesite algo para ser fijo o agregado a su hogar, un contratista diferente aparece, y hace el trabajo de manera diferente que el contratista anterior. Muy pronto puede estar seguro de terminar con ventanas que no coinciden, botones de puerta de diseño múltiple, etc. Es por eso que tiene sentido que los constructores tengan todos esos códigos y directrices a seguir mientras crean algo, estándares de componentes que necesitan mantener, etc.
De forma similar, una vez que la solución PPM esté activa, habrá varios cambios, mejoras y eliminación de las características que aparecerán. A menos que establezca un estándar sobre cómo se realizan estos cambios, puede estar seguro de una solución que se encuentra en un caos total por el camino.
Áreas de gobernanza
Cuando empiece a considerar la posibilidad de configurar un plan de gobernanza para la solución PPM, debe tener en cuenta qué áreas quiere gobernar realmente. Hay muchas teorías y modelos para establecer un plan de gobernanza para soluciones empresariales, y es libre de elegir el mejor que se adapte a su organización. En este artículo, analizaremos uno de estos modelos que se ajustará a la mayoría de las implementaciones de PPM.
La manera más sencilla de averiguar las áreas de gobernanza necesarias es considerar las áreas en las que es probable que se produzcan cambios y, a continuación, configurar un plan de gobernanza para administrar esos cambios.
Nota:
Incluso para los elementos que no son "cambios" en sí, y en lugar de mantenimiento estándar (por ejemplo, agregar nuevos usuarios, actualizar períodos de parte de horas, etc.), es importante tener un conjunto de procedimientos estándar registrados.
En general, hay cuatro áreas clave en las que podrían producirse cambios para la solución ppm.
Gobernanza de la información
Cuando se implementa la solución PPM, es razonable suponer que empieza con buenos datos "maestros" en la solución. Por ejemplo, estos incluyen detalles de recursos empresariales, calendarios empresariales, campos personalizados relacionados, etc., básicamente todos los datos "maestros" que le permitirán usar la solución PPM de forma eficaz. Sin embargo, a medida que sigue usando la solución, los usuarios cambian de departamento, algunos abandonan la organización, los calendarios deben actualizarse con nuevos días festivos, deben crearse períodos de informes de tiempo, es posible que sea necesario cambiar los períodos fiscales y la lista continúa y continúa. Obviamente, si estos datos no se mantienen actualizados, todos los informes serán inexactos y también la configuración de seguridad.
La gobernanza de la información es responsable de mantener estos datos actualizados y completos para que el resto de la solución pueda aprovechar si estos datos principales.
Gobernanza del diseño
La segunda área que debe formar parte de su plan de gobernanza es el mantenimiento del "diseño" de la implementación de PPM. A medida que siga usando la solución, habrá solicitudes para ajustar el diseño de la solución. Estos podrían surgir de un grupo determinado que quiera cambiar la forma en que usan la herramienta o que quieran aprovechar las nuevas características. Un ejemplo clásico es cambiar la forma en que se realiza el informe de tiempo. Es posible que haya elegido usar un método % Work Complete, mientras que con un nuevo departamento agregado, es posible que tenga que cambiarlo al método "horas trabajadas por período" para la integración con otras soluciones financieras. Por lo tanto, la pregunta es quién evaluará el impacto de este cambio en la solución y cómo se implementarán los cambios.
La gobernanza del diseño es el plan para administrar los cambios que afectan al diseño general de la solución PPM.
Gobernanza de procesos
Es fácil pensar en esta área de gobernanza como parte de la gobernanza del diseño, ya que la mayor parte del tiempo, el proceso y el diseño van de la mano. Sin embargo, holísticamente hablando, esta área cubre más que solo el diseño. Aborda la gobernanza de los procesos dentro y fuera de la solución PPM que impulsan su eficacia.
Por ejemplo, tome un escenario en el que se supone que su PMO debe enviar un informe a la dirección sénior todos los miércoles a. m. Es posible que haya configurado un proceso para asegurarse de que los partes de horas se envíen todos los viernes a una hora determinada y que todos los administradores de proyectos actualicen y publiquen sus planes de proyecto el lunes a. m., antes de que se produzca el informe. Ahora, supongamos que la alta dirección solicita que los informes se envíen el lunes a. m. en lugar de todos los miércoles a.m. Esto desencadena un cambio en el proceso en cuanto a cómo se usa la solución PPM, en lugar de un cambio en el diseño de la propia solución PPM.
Estos tipos de cambios tendrán que regirse por un conjunto estándar de reglas, definido como parte de la gobernanza de procesos.
Gobernanza de la infraestructura
Esta es otra de las áreas que parece ser fácil de silo, pero puede superponerse a las otras tres áreas mencionadas anteriormente. En pocas palabras, la infraestructura que admite la solución PPM debe mantenerse con la instalación. Algunos ejemplos de los elementos clave que deben incluirse en este tipo de modelo de gobernanza son:
Instalación de Service Pack o actualizaciones acumulativas.
Instalación de nuevos complementos o aplicaciones.
Actualización de la infraestructura (adición de servidores de aplicaciones, servidores web, etc.) para solucionar problemas de rendimiento.
Cambios en la infraestructura debido a cambios en otras aplicaciones de las organizaciones (por ejemplo, virtualización de todos los servidores).
En un lado de la ecuación, la decisión de instalar algo o no se basa exclusivamente en el mérito (por ejemplo, si afectará negativamente a cualquier solución de producción actual). El otro lado de la ecuación de cualquier infraestructura es examinar los cambios de "proceso" o "diseño" causados por la instalación. En algunos casos, el cambio de infraestructura podría ser el resultado de cualquier cambio en las otras áreas. Como se mencionó anteriormente, aunque nuestro intento es clasificar cada cambio como parte de una de estas áreas, es posible que algunos cambios se superpongan completamente en las cuatro áreas.
Preguntas clave
Independientemente del área de gobernanza que intente configurar, hay tres preguntas clave que deben responderse que formarán el núcleo del plan de gobernanza.
¿Cómo sabe el equipo de PPM que debe producirse un cambio (por ejemplo, cuál es el desencadenador de estos cambios?). A veces, estos cambios no se "desencadenan" por sí solos, sino que forman parte del cuidado y alimentación normales de la implementación del PPM (por ejemplo, la adición de nuevas vistas para el Centro de proyectos)
¿Quién aprueba estos cambios, no solo desde el punto de vista del retorno de la inversión empresarial (ROI), sino desde el punto de vista de la gobernanza?
¿Quién realiza realmente estos cambios? En muchos de estos cambios, hay varios equipos implicados. En algunas organizaciones, algunas de las funcionalidades de cambio se transfieren a un subconjunto de usuarios finales, en función de las necesidades empresariales. En este tipo de escenarios, resulta aún más importante definir quién realizará realmente los cambios.
Equipo de gobernanza
Un componente clave de cualquier estrategia de gobernanza es el equipo que realmente trabaja el plan de gobernanza. Aunque hay varias maneras de segmentar y dar dados sobre el aspecto que debe tener este equipo de gobernanza, la única recomendación en la que todas las escuelas de pensamiento estarán de acuerdo es mantenerla simple.
La siguiente es una manera de configurar la estructura del equipo:
Propietarios del área de gobernanza Estos son los propietarios de cada una de las áreas de gobernanza mencionadas anteriormente en este artículo. En general, cualquier solicitud de cambio que afecte al área designada para estos propietarios de gobernanza se convertirá en responsabilidad de estos propietarios. Será su rol evaluar, proporcionar recomendaciones, configurar la gobernanza en torno a las nuevas características, etc.
Comité Central de Gobernanza (CGC) Este sería el equipo de responsables de la toma de decisiones que puede aprobar o rechazar las recomendaciones realizadas por los propietarios de la gobernanza. Tener un comité central de gobernanza no solo ayuda a reducir la burocracia, sino que también ayuda a llevar todas las ideas a una plataforma común y a evaluarlas entre sí.
Como se mencionó anteriormente, en función del tamaño de la implementación y de los procesos actuales que existen en una organización para otras aplicaciones, la definición y estructura de estos roles podría ser más pequeña o mayor. El punto importante es que para tener al menos una estructura mínima en su lugar.
Otros componentes clave
Algunos de los otros componentes clave para una estrategia de gobernanza correcta incluyen, entre otros:
Una solución de solicitud de trabajo, que permite a los usuarios solicitar cambios, características y funcionalidad. Esto puede ser tan sencillo como una lista de SharePoint o una solución de solicitud de trabajo interna que se usa actualmente.
Un proceso para controlar los cambios, que incluye revisiones de TI, gobernanza, CGC y otras funciones empresariales implicadas.
Un proceso para implementar realmente los cambios. Esto podría ser una progresión sencilla de los cambios de Desarrollo a Soluciones de prueba a producción o un Release Management completo según los estándares de su organización.
El proceso
Vamos a tomar todos los componentes descritos anteriormente como parte de la creación de una estrategia de gobernanza y a crear un proceso a su alrededor. Aquí se muestra su aspecto (podría variar en función de los requisitos de la organización).
Conclusión
Aunque es difícil predecir y planear todos los cambios que se pueden producir en la solución ppm, es importante tener una estrategia a un ritmo flexible y escalable a cualquier escenario.
Como pensamientos de despedida, considere los siguientes enfoques básicos de sentido común para crear su estrategia de gobernanza.
Un plan de gobernanza no tiene que ser un tomo con una gran cantidad de terminología oscura y lenguaje que nadie puede usar en la vida diaria. Puede ser tan simple como una hoja de Excel, con respuestas rápidas a las preguntas clave (abordadas en Preguntas clave).
Recuerde que un plan de gobernanza no es una documentación de la configuración. Es un "plan" para proteger, mantener y cambiar (si es necesario) la configuración.
Un plan de gobernanza debe ser fácil de implementar y debe integrarse bien en los procesos existentes de la organización. No es necesario reinventar la rueda.
Comprenda que la gobernanza de la solución PPM es un proceso en constante evolución. Es importante que no se bloquee con la parálisis del análisis. Inicie pequeño, entregue el valor y, a continuación, escale verticalmente.
Autor
Prasanna Adavi (PMP, MCTS, MCITP, MCT) es consultora y instructora de administración de proyectos empresariales sénior (EPM) especializada en las plataformas Microsoft Project, Microsoft Project Server y Microsoft SharePoint. Su principal objetivo es crear y habilitar soluciones empresariales para ayudar a las organizaciones a lograr el mejor rendimiento de sus inversiones.
También tiene una amplia experiencia en proyectos líderes de un extremo a otro en un amplio espectro de dominios y verticales, incluyendo TI, ERP (SAP), Fabricación, Desarrollo de aplicaciones, Automotriz y Creative Services. Es moderador habitual en diversos eventos de Project Server, EPM y SharePoint en todo el país o región, y colaborador habitual en la comunidad de SharePoint y EPM.
Prasanna es un bloguero normal (https://www.prasannaadavi.com) y también ejecuta un podcast quincenal (https://www.msprojectpodcast.com), centrado principalmente en las soluciones de Microsoft Project y Project Server. Prasanna es consultora sénior con EPMA (https://www.epmainc.com).