¿Cómo implementar Project Server sin morir en el intento?

¿Por qué fallan las instalaciones de Project Server? Si usted ha estado en una instalación fallida de Project Server, en una exitosa o se está por embarcar en un proyecto de EPM, creo que este artículo le resultará interesante.

 

La primera parte del problema

Según Chris Vandersluis, el problema empieza cuando el equipo de ventas muestra al cliente los resultados que pueden obtenerse con una solución de EPM sin explicar el esfuerzo requerido para reproducir los resultados en un ambiente de producción.

El otro problema es la historia y la reputación de las aplicaciones de Microsoft: son conocidas en el mercado por la capacidad de insertar un DVD en su PC y esperar sólo algunos minutos hasta que se empieza a disfrutar de los beneficios del software adquirido. A lo sumo se puede requerir un poco de capacitación adicional y no mucho más.

Lo que sucede es que no se asume que una implementación de EPM se trata de un auténtico proyecto de cambio organizacional.

 

Pero... ¿Qué es EPM? ¿la segunda parte del problema?

Permítanme citar nuevamente a Chris Vanderluis. ¿Qué entienden los clientes por EPM (Enterprise Project Management)? Según Chris, las respuestas tienden a estar en línea con lo que se muestra en la siguiente lámina:

El problema no pasa sólo porque el término EPM es usado para definiciones distintas, sino que todas las definiciones son correctas y, lo que es más problemático, los clientes requieren que se implemente todo!!

Y aquí es dónde hay que ponerse firme y asesorar correctamente. Si bien, técnicamente es posible hacer todo, en la práctica esto no lo es. Y esto se debe principalmente a dos razones:

Todo lo que un EPM puede hacer no está necesariamente en la misma dirección, si queremos implementar todo, estaremos a mitad de camino o en caminos incompatibles.

La velocidad en que madura la organización respecto a su proceso de administración de proyectos es menor a la velocidad en que pueden implementarse las funcionalidades EPM. Tendremos la parte técnica resuelta, pero no el cambio cultural. Y no debemos olvidar que un proyecto de EPM, debe tratarse como un proyecto de cambio organizacional.

 

Implementación en etapas

Respecto a la forma de implementar una solución de este tipo debemos saber:

Una implementación big-bang no sirve.

Por lo clásico: demora el retorno de la inversión, por lo no tan clásico: obliga a ejecutar el cambio cultural el día de la implementación y dar un salto demasiado alto.

Una implementación rápida no sirve.

Existen muchos intentos frustrados de implementar EPM rápidamente. Estos intentos no sirven. Aunque al principio "disimulen", terminan siendo fracasos con el tiempo. Y cito nuevamente a Vanderluis, no se trata de instalar un video-game, sino de ejercitar un cambo organizacional.

Implementación en etapas

Funciona, por las razones estándar, como rápido retorno de inversión y menos riesgos.

Fundamentalmente porque la madurez en el cambio cultural es acompañada por la evolución de los procesos y las herramientas.

Es conveniente procurar una primera etapa rápida con alto retorno de inversión, para facilitar el éxito de las próximas etapas.

Pero no se debe creer que una primera etapa se ejecuta en 2 meses. 4 a 8 meses, dependiendo del tamaño de la organización y su situación particular, puede ser un parámetro razonable.

Factores de éxito

Hechas las breves aclaraciones, la siguiente es una lista de factores de éxito, no exhaustiva, pero bastante completa.

Es un proyecto: implementar un EPM es un proyecto, hay que manejarlo como tal.

Proceso de cambio: no es un proyecto tecnológico, hay que manejarlo como un proceso de cambio.

Equipo: se necesitan especialistas técnicos (seguro que se necesitan), pero fundamentalmente especialistas en procesos de administración de proyectos. La tecnología no representa más del 30-40% del proyecto.

Equipo técnico: la herramienta (Project Server) es compleja. Se necesitan profesionales con experiencia certificada. Se debe tener en cuenta que existen al menos 4 certificaciones en Project / Project Server y 4 más en SharePoint otorgadas por Microsoft. Las empresas consultoras también son certificadas por Microsoft en EPM y Colaboración (esto ocurre cuando sus profesionales están certificados y poseen implementaciones exitosas en clientes).

SharePoint es importante: no se trata sólo de Project Server, se necesitan manejar las dos herramientas, Project Server y SharePoint. Una buena solución requiere mucho de SharePoint y esto es más de lo que se ofrece out of the box.

No a los pececitos de colores: la herramienta debe adaptarse al proceso y no la inversa! No se necesita implementar todo lo que hace Project Server, no hay que dejarse llevar por los pececitos de colores, hay que concentrarse en las necesidades y en el nivel de madurez de la organización para soportar el cambio. Este es un error clásico.

De a poco: implementar en etapas, dar tiempo a que el cambio cultural sea asimilado y que las nuevas necesidades aparezcan. No hacer esto puede hacer malgastar el esfuerzo de mejora. Y cómo se suele decir, los procesos de cambio son de única vez, no hay que desaprovecharlos.

Sponsor: cómo todo proyecto, requiere un sponsor. Cuando se trata de un cambio organizacional, se requiere un sponsor de alto nivel, si es posible, representante del negocio.

Preparar un equipo para el futuro: no conviene descansar  en la consultoría. Un consultor puede ayudar en la implementación, pero el proceso debe ser mantenido por la propia organización, debe tener un "dueño del proceso" y un "equipo de mejora".

Prueba tecnológica: es altamente recomendable comenzar desde el día 1 de proyecto con el Plan de Tecnología, una prueba de concepto y una preparación de ambientes. Esto puedo demorar 1 a 3 meses.

Participación del usuario: es importa involucrar y hacer partícipe al usuario desde el día 1. Y esto aplica en todos los niveles: líderes de proyecto, miembros del equipo, jefes funcionales, áreas de Calidad, PMO, Gerencia, etc. Debemos asegurarnos que la solución sea "usable" y que ayude al trabajo del día a día de los equipos. No debe ser impuesta, ni se debe minimizar su impacto.

¿Por qué estamos haciendo esto? siempre será conveniente preguntárselo para obtener los drivers del proyecto. Es la única formar de lograr la satisfacción y poder enfocar mejor los esfuerzos de mejora.

 

Bibliografía

Inicialmente este artículo iba a estar basado en la experiencia y las lecciones aprendidas de nuestra participación en proyectos de EPM. Esto es así, y hay muchas de estas lecciones aquí reflejadas.

Afortunadamente, en el camino, encontré un paper de Microsoft (en inglés), que refleja muchos de estos aspectos y con el que coincido ampliamente. Este es el material y enlace por si desean consultarlo:

• Un enfoque de varias fases para implementar Enterprise Project Management (en inglés)
• Autor: Chris Vanderluis
• Fecha: Junio de 2008

 

Hasta la próxima

Como siempre, espero haber sido útil y también espero feedback.

Saludos!