Superar la vida media (t ½ ): Gestión de la solución de PPM postimplementación: notas del producto

Estas notas del producto forman parte de nuestra colección "Desde las trincheras". Aquí se describe cómo configurar un marco para la configuración de un modelo de gobernanza para la solución de Administración de carteras de proyecto (PPM). Además, se incluye un plan de gobernanza de ejemplo que puede usarse como punto de partida para configurar su propia estrategia de gobierno.

Para descargar la versión en Word de estas notas del producto, vea Superar la semivida (t ½): gobernar la solución de PPM después de la implementación: notas del producto.

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

Superar la semivida (t ½ ): gobernar la solución de PPM después de la implementación

Introducción

Semivida es el tiempo que tarda una sustancia (droga, nucleido, radiactivo, etc.) en perder la mitad de su actividad farmacológica, fisiológica, o radiológica. (Ref.: http://es.wikipedia.org/wiki/Semivida).

Por lo tanto, ¿cómo se aplica esto a la flamante solución de Administración de carteras de proyecto (PPM) que se acaba de implementar? El motivo por el que se aplica se debe a que la solución PPM, implementada correctamente, se suministra con una fecha de expiración. Si no se toma el tiempo para planear, diseñar y ejecutar un proceso de gobernanza alrededor de la administración de la solución PPM, puede estar seguro de que la solución se rellenará con datos desfasados, con cambios con malos diseños y con procesos que no están sincronizados con los procesos organizativos reales, y la lista continúa. Al igual que un automóvil que nunca recibe mantenimiento, la solución dejará de proporcionar el retorno de la inversión que se espera. Los usuarios adoptarán una actitud pasiva y dejarán de usar la solución, o bien, pedirán abiertamente una solución diferente.

El objetivo de este documento es analizar un marco para la configuración de un modelo de gobernanza para su solución PPM. También se proporciona un plan de gobernanza de ejemplo que puede utilizarse como punto de partida para configurar su propia estrategia de gobernanza.

Qué y por qué

Si bien la palabra governance puede significar cosas diferentes para distintas personas, en sí, un plan de gobernanza es un conjunto de directivas y procedimientos autoimpuestos, para asegurarse de que la aplicación se encuentra en mantenimiento en todas las áreas y que está generando el mejor retorno de valor para la inversión realizada en la herramienta.

¿Se pregunta por qué son necesarias estas restricciones? Es comparable al mantenimiento de la casa en la que vive. Imagine, si cada vez que se necesita reparar o agregar algo en su casa, aparece un contratista distinto y realiza el trabajo de una manera diferente al contratista anterior. Muy pronto se encontrará con ventanas que no coinciden, mangos de puerta de diversos diseños, etc. Por eso, tiene sentido para los constructores tener todos los códigos y las pautas que deben seguir mientras construyen algo, las normas de los componentes que necesitan mantener, etc.

De forma similar, una vez que la solución PPM está activa, surgirán varios cambios, mejoras y eliminación de características. A menos que establezca un estándar sobre "cómo" se realizan estos cambios, puede estar seguro de que la solución estará en el medio de un caos.

Áreas de gobernanza

Cuando empieza a contemplar la creación de un plan de gobernanza para su solución PPM, debe considerar qué áreas realmente desea gobernar. Hay muchas teorías y modelos para establecer un plan de gobernanza para soluciones empresariales, y es libre de elegir la que mejor se ajuste a la organización. En este artículo, expondremos uno de estos modelos que se ajusta 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 donde es probable que sucedan los cambios y después configurar un plan de gobernanza para administrar esos cambios.

Nota:  Incluso para los elementos que no son "cambios" propiamente dichos, sino un mantenimiento estándar (por ej.: adición de nuevos usuarios, actualización de los períodos de las planillas de horas trabajadas, etc.), es importante disponer de un conjunto de procedimientos estándar registrado.

En general, hay cuatro áreas clave donde podrían ocurrir los cambios para la solución PPM.

Cuatro áreas clave para el cambio de la solución PPM: Información, Diseño, Infraestructura y Proceso.

Gobernanza de información

Cuando se implementa la solución PPM, es razonable suponer que empieza con buenos datos "maestros" en la solución. Por ejemplo, entre ellos, se incluyen detalles de recursos de la empresa, calendarios empresariales, campos personalizados relacionados, etc., básicamente todos los datos 'maestros' que le permitirán usar la solución PPM de manera eficaz. Sin embargo, a medida que sigue usando la solución, las personas cambian de departamentos, algunos abandonan la organización, los calendarios deben actualizarse con los nuevos días festivos, deben crearse períodos de presentación de informes de horas, es posible que deban cambiarse los períodos fiscales, y la lista sigue y sigue. Es evidente que si esos datos no se mantienen actualizados, luego, todos los informes serán inexactos, al igual que la configuración de seguridad.

La gobernanza de la información asume la responsabilidad de mantener esta información actualizada y completa para que el resto de la solución pueda aprovechar estos datos básicos.

Gobernanza de diseño

La segunda área que tiene que formar parte de su plan de gobernanza es el mantenimiento del "diseño" de su implementación PPM. A medida que vaya usando la solución, habrá solicitudes para ajustar el diseño de la solución. Estas podrían surgir como consecuencia de un determinado grupo que quiere cambiar la forma en que usan la herramienta o que desean aprovechar las nuevas características. Un ejemplo clásico es cambiar la forma en que se realizan los informes de tiempo. Es posible que haya elegido adoptar el método de porcentaje de trabajo completado, pero al haberse agregado un nuevo departamento, quizás tenga que cambiar al método "horas trabajadas por período" en pos de la integración con otras soluciones financieras. Entonces la pregunta es: ¿quién evaluará el impacto de este cambio en su solución y cómo se van a implementar estos cambios?

La gobernanza de diseño es el plan para administrar los cambios que tienen un mayor impacto en el diseño general de la solución PPM.

Gobernanza de proceso

Es fácil pensar en esta área de gobierno como parte del gobierno de 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 abarca mucho más que solo el diseño. Aborda la gobernanza de procesos dentro y fuera de la solución PPM que controla su eficacia.

Por ejemplo, tome un escenario donde se supone que su PMO debe enviarle un informe a la dirección todos los miércoles por la mañana. Es posible que haya configurado un proceso para asegurarse de que las planillas de horas trabajadas se presentan cada viernes a un determinado horario, y que todos los jefes de proyecto actualizan y publican sus planes de proyectos para el lunes por la mañana, antes de que ocurra la presentación de informes. Ahora, supongamos que el personal directivo superior le pide que se envíen los informes los lunes por la mañana en lugar de todos los miércoles por la mañana. Esto desencadena un cambio en el proceso sobre cómo se usa la solución PPM, en lugar de un cambio en el diseño de la solución PPM en sí.

Estos tipos de cambios tendrán que estar regulados por un conjunto estándar de reglas, definidas como parte de la gobernanza del proceso.

Gobernanza de infraestructura

Esta es otra de aquellas áreas que parecen ser fáciles de aislar, sin embargo, se puede superponer con las otras tres áreas mencionadas anteriormente. En pocas palabras, la infraestructura que admite su solución PPM se debe mantener con la instalación. Algunos ejemplos de los elementos clave que deben formar parte de este tipo de modelo de gobernanza son:

  • Instalación de Service Packs 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 tratar problemas de rendimiento.

  • Cambios en la infraestructura debido a cambios en otras aplicaciones de las organizaciones (por ejemplo, la virtualización de todos los servidores).

Por un lado de la ecuación, la decisión de instalar o no algo se basa puramente en méritos (por ejemplo, si va a repercutir negativamente en cualquier solución de producción actual). La otra cara de la ecuación de cualquier infraestructura es mirar los cambios en el 'proceso' o el 'diseño' que generará la instalación. En algunos casos, el cambio en la infraestructura podría ser el resultado de los cambios en las otras áreas. Tal como se mencionó antes, si bien 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 está intentando configurar, hay tres preguntas claves que hay que responder que serán el núcleo de su plan de gobernanza.

  • ¿Cómo sabe el equipo de PPM que se debe hacer un cambio (por ejemplo, ¿cuál es el disparador de estos cambios?)? A veces, estos cambios no se "desencadenan" en sí mismos, sino que forman parte del cuidado y el mantenimiento regular de la implementación 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 de un retorno de la inversión (ROI) del negocio, sino desde la perspectiva de gobernanza?

  • ¿Quién realiza realmente estos cambios? Para muchos de estos cambios, hay varios equipos implicados. En algunas organizaciones algunas de las capacidades de cambios se transfieren a un subconjunto de usuarios finales, según las necesidades empresariales. En estos tipos de escenarios es aún más importante definir quién realmente hará cada cambio.

Equipo de gobernanza

Un componente clave de cualquier estrategia de gobernanza es el equipo que realmente trabaja en el plan de gobernanza. Si bien hay varias maneras de partir y repartir este equipo de gobernanza, la recomendación con la que todas las escuelas de pensamiento estarán de acuerdo es que sea algo sencillo.

A continuación, se presenta una forma de definir la estructura del equipo:

Propietarios del área de gobernanza    Son los propietarios de cada una de las áreas de gobernanza mencionadas previamente en este artículo. En general, cualquier solicitud de cambio que afectará el área designada para estos propietarios de gobernanza se convertirá en la responsabilidad de estos propietarios. Su rol comprende evaluar, brindar recomendaciones, configurar el gobierno en función de las nuevas características, etc.

Comité de gobernanza central (CGC)    Sería el equipo de personas encargadas de la toma de decisiones que pueden aprobar o rechazar las recomendaciones realizadas por los propietarios de gobernanza. Contar con un Comité de gobernanza central no solo ayuda a reducir la burocracia, sino que además permite aportar ideas a una plataforma común y evaluarlas en conocimiento de todos.

Como se mencionó anteriormente, en función del tamaño de la aplicación y de los procesos actuales que existen en una organización para otras aplicaciones, la definición y la estructura de estos roles podrían ser menores o mayores. Lo importante es tener al menos una mínima estructura implementada.

Otros componentes clave

Algunos de los otros componentes clave para lograr una estrategia de gobernanza correcta incluyen, pero no están limitados a:

  • Una solución de solicitud de trabajo, que permite a los usuarios solicitar cambios, características y funcionalidades. Esto puede ser tan simple como una lista de SharePoint o una solución de solicitud de trabajo que actualmente se usa en la empresa.

  • Un proceso para tratar 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 simple progresión de los cambios desde el desarrollo hasta la prueba de las soluciones de producción o una administración de versiones completa de acuerdo con los estándares de la organización.

El proceso

Tomemos todos los componentes analizados anteriormente como parte de la creación de una estrategia de gobernanza y generemos un proceso. Aquí le mostramos qué aspecto podría tener (puede variar en función de los requisitos de la organización).

Diagrama de la estrategia de gobierno que muestra cómo un usuario envía una petición y se dirige a su revisión y aprobación a través del comité de gobierno

Conclusión

Aunque es difícil de predecir y planear cada cambio que pueda ocurrir en la solución PPM, es importante tener una estrategia de ritmo que sea flexible y escalable para cualquier escenario.

A modo de conclusión, considere los siguientes enfoques básicos de sentido común para crear su estrategia de gobernanza.

  • No es necesario que un plan de gobernanza sea un tomo con una gran cantidad de terminología difícil, que nadie pueda usar en la vida diaria. Puede ser tan simple como una hoja de Excel, con respuestas rápidas a las preguntas clave (más información 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) su 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 su solución PPM es un proceso en constante evolución. Es importante no quedarse enganchado con la parálisis de análisis. Empiece con algo pequeño, ofrezca valor y luego escale.

Acerca del autor

Prasanna Adavi (PMP, MCTS, MCITP, MCT) es entrenador y consultor senior de Enterprise Project Management (EPM) que se especializa en las plataformas Microsoft Project, Microsoft Project Server y Microsoft SharePoint. Su principal enfoque es crear y habilitar soluciones empresariales para ayudar a las organizaciones a lograr el mejor rendimiento de sus inversiones.

Además, posee vasta experiencia en el liderazgo de proyectos integrales en una amplia gama de dominios y verticales, incluidos TI, ERP (SAP), fabricación, desarrollo de aplicaciones, automotrices y servicios creativos. Se desempeña como moderador frecuente en varios eventos sobre Project Server, EPM y SharePoint en todo el país, y como colaborador periódico de la comunidad de SharePoint y EPM.

Prasanna es un blogger asiduo (http://www.prasannaadavi.com) y también realiza un podcast cada dos semanas (http://www.msprojectpodcast.com), que se centra principalmente en las soluciones Microsoft Project y Project Server. Prasanna es consultor senior con EPMA (http://www.epmainc.com).

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.

×