Buenas prácticas en la implementación de Project Server 2010

[ Artículo publicado originalmente en la revista CompartiMOSS número 8: http://jpussacq.me/2011/06/26/compartimoss-nmero-8-junio-201/ ]

Introducción

Microsoft Project server es la herramienta de Microsoft pensada para la implementación de un EPM (Enterprise Project Management).

Según la página oficial de Microsoft en http://www.microsoft.com/project/en/us/solutions.aspx, una solución EPM está compuesta por:

• Gestión de la demanda
• Selección y análisis del portfolio
• Gestión de recursos
• Gestión de planificación
• Gestión financiera
• Gestión de tiempos y tareas
• Colaboración del equipo de trabajo
• Gestión de reportes e inteligencia empresarial
• Administración, escalabilidad y extensibilidad

¿Por qué puede ser compleja una implementación de EPM? Fundamentalmente porque está asociada a procesos centrales de una compañía, tanto los procesos para la gestión de proyectos, como los procesos para la provisión de un servicio o producto. Y además, este tipo de soluciones muchas veces se aplica a corporaciones, en donde los proyectos se ejecutan a través de equipos inter-disciplinados y en distintas locaciones geográficas.

Por ende, la implementación de un EPM, lejos de ser un proyecto tecnológico, se convierte en una iniciativa que modifica procesos organizativos y que genera indefectiblemente un cambio cultural, que deberá ser manejado desde el inicio, para que nuestro proyecto no fracase.

¿Por dónde empezar?

Quizá la recomendación primera es seguir una metodología para implementar una solución EPM. Sí, suena muy obvio, pero la realidad es que existen una serie de pasos que pueden llevarse en un determinado orden para ayudar al éxito de una implementación de este tipo. Y por supuesto, debemos tratar una instalación de un EPM como un proyecto y gestionarlo como tal.

Lista de primeras recomendaciones:

• Gestionar la implementación de un EPM como un proyecto.
• Entender que en la mayoría de los casos, nuestro cliente no tiene definido sus procesos de gestión corporativa de proyectos, y en caso que los tengan, seguro necesitaremos definir la forma en que los procesos interactúan con la herramienta.
• Entender que se trata principalmente de un cambio cultural.
• No podremos encarar un proyecto de este tipo si un sponsor de alto nivel.
• Manejar con cuidado los aspectos políticos, ya que este tipo de proyectos suelen producir algunas vibraciones en las estructuras de poder.
• Saber que la palabra EPM tiene muchos significados distintos según con quién hablemos.
• Y por último, entender que una implementación EPM está relacionada con el nivel de madurez de la organización. Debemos entender en qué nivel está la organización y saber que no se pueden saltear niveles. Dicho de otra manera, no podremos implementar en una primera etapa todo lo que el cliente vio en la demostración del producto.

El equipo de proyecto

¿Qué roles serán necesarios para llevar adelante un proyecto de estas características?
Del lado del cliente:

• Líder de proyecto.
• Sponsor.
• Un conjunto selecto de usuarios, normalmente líderes de proyecto, jefes funcionales y recursos, con quienes trabajaremos en la definición de los procesos y en la parametrización de Project Server.
• El área a cargo de los procesos de gestión de proyectos. Una oficina de proyectos, por ejemplo.
• Las áreas responsables de los aspectos tecnológicos: Base de datos, Sistemas Operativos, Seguridad e infraestructura en general.

Del lado del proveedor o el equipo que realiza la instalación, necesitaremos los siguientes roles:

• Líder de proyecto.
• Consultor experimentado en gestión de proyectos.
• Arquitecto.
• Especialista en Project Server.
• Especialista en SharePoint.
• Desarrollador SharePoint / Project Server.
• Tester.

Independientemente de cuántas personas se necesiten por rol, o si una persona puede cumplir más de un rol, hay algunas situaciones con las que nos solemos encontrar:

• No es tan común encontrar un especialista en SharePoint y en Project Server.
• Una instalación de Project Server necesita ser montada casi siempre en una granja, con lo cual se requiere un arquitecto que conozca como diseñarla, y que maneje aspectos de SharePoint, Project Server y SQL Server.
• El rol de consultor en gestión de proyectos es fundamental, pues es quien trabajará juntos con los usuarios en la definición de los procesos y las mejores prácticas de gestión de proyectos. Es conveniente que tenga conocimientos de Project Server para que pueda alinear los procesos con la herramienta.

El GAP (el primer paso)

La implementación de un EPM requiere una primera etapa, que personalmente me gusta llamar Alcance. ¿Qué tiene de particular un alcance en una implementación EPM? Que se necesita bajar a tierra las expectativas que se han generado sobre el producto.

1) Los requerimientos

Lo primero es tratar de encontrar una respuesta a la pregunta ¿por qué están encarando este proyecto?
A continuación es importante identificar requerimientos de proceso, de herramientas, de organización y de métricas e indicadores. Es un buen momento para presentar Project Server al cliente y poder realizar una primera identificación de los componentes que implementaremos. Por último, lo tradicional: identificar factores críticos de éxito e interesados en el proyecto.

2) La situación actual

Para entender la situación actual, necesitaremos entender qué tipo de proyectos maneja la organización. También es importante entender el ciclo de vida de producción o provisión de servicios para cada tipo de proyecto. Esto nos ayudará a modelar la parametrización de la herramienta, para que esos procesos y sus entregables queden reflejados en la solución.
Debemos relevar además cómo es la organización ejecutora de los proyectos, las prácticas de administración de proyectos y las herramientas que utiliza actualmente la organización.

3) La propuesta de solución

Con lo anterior, ya estaremos en condiciones de desarrollar el análisis GAP entre la situación actual y los requerimientos, y analizar distintas alternativas de solución para finalmente recomendar una. Con esto, ya estaremos en condiciones de acordar el alcance del proyecto con los interesados y validar las expectativas.

El plan

No voy a profundizar en este tema, pero el tamaño y complejidad de una implementación EPM requiere que elaboremos un plan de trabajo, en donde podremos hacer especial hincapié en:

• La arquitectura técnica
• El diseño de la solución
• La implementación de la solución
• Tareas de concientización referidas al cambio cultural
• Capacitación

El lanzamiento oficial

Todo proyecto tiene un Kick Off y este no será la excepción. Este es un buen momento para hacer un lanzamiento importante, porque ya acordamos el alcance del proyecto. Considero fundamental que esta reunión sea conducida o abierta por un sponsor de máximo nivel, de manera de alinear y direccionar el trabajo de todos los involucrados durante la vida del proyecto.

La arquitectura técnica

En mi experiencia, todos los proyectos de EPM tienen un riesgo relacionado con la arquitectura técnica que tarde o temprano se hace realidad. El riesgo es no saber si vamos a contar con la infraestructura en la fecha planificada. ¿Por qué sucede esto? :

• Una instalación de EPM suele necesitar una topología de granja preparada para crecer, lo cual es más complejo y más costoso que una instalación de un sólo servidor.
• Involucra a distintos sectores: Base de Datos, Sistemas Operativos, Seguridad y el sector que afrontará el gasto.
• No es común encontrar dentro de la organización alguien que tome a su cargo el mantenimiento del producto Project Server.
• La implementación puede entrar en conflicto con otros planes de las áreas de sistemas.
• Podremos necesitar permisos especiales, si es que requerimos desarrollar alguna extensión.

¿Cómo nos conviene tratar estos riesgos? :

1. Explicitando el riesgo ante nuestro cliente.
2. Ejecutando las actividades de infraestructura desde el día 1.
3. Encontrando un responsable del tema dentro del cliente que nos ayude a gestionar estas actividades.

1) El plan de arquitectura

El primer paso para encarar la arquitectura técnica es hace un diseño de arquitectura. Este es un tema muy amplio e importante. Les dejo una lista de los puntos que habría que tener en cuenta:

• Dimensionamiento y plan de escalabilidad
• Arquitectura de software
• Estructura de sitio y navegación
• Plan de seguridad
• Arquitectura de hardware
• Plan de extensiones mediante desarrollo de software
• Plan de licencias
• Plan de ambientes
• Requisitos de instalación y plan de instalación
• Instalación de equipos cliente
• Integración con otras aplicaciones
• Plan de prueba de concepto

2) La implementación de la arquitectura

La implementación de la arquitectura consiste en la ejecución del plan que hemos construido en el punto anterior. Independientemente de la implementación en sí, conviene realizar una prueba de concepto de la infraestructura. Esto es importante porque la arquitectura de Project Server es compleja y tiene un amplio conjunto de variables que influirán en su rendimiento. Por ello, mi recomendación es invertir el tiempo suficiente en el dimensionamiento y el plan de escalabilidad, y realizar posteriormente esta prueba de concepto para tener una primera validación y realizar, si corresponde, los ajustes necesarios.

El diseño y la implementación de la solución

Esta es quizá la etapa más extensa del proyecto, en donde deberemos poner sobre la mesa nuestros conocimientos en Gestión de Proyectos, Project Server y SharePoint.

1) El diseño de la solución

La etapa de diseño implica el análisis y la especificación técnica de un conjunto de funcionalidades que pueden estar presentes en una implementación de Project Server 2010. Este diseño podrá implicar luego actividades de parametrización, desarrollo de software  o diseño e implementación de procesos.
El primer paso tiene que ver con entender el ciclo de vida de producto que maneja nuestro cliente, en donde deberemos incluir actividades tales como el diseño de las plantillas de proyecto, el manejo de ante-proyectos y actividades continuas, el diseño de atributos personalizados, flujos de trabajo y la forma en que manejaremos programas y dependencias entre los proyectos que los componen.
En paralelo con esta actividad, tendremos que trabajar con el diseño del proceso de gestión de proyectos (y de cartera de proyectos), sus actividades, roles y entregables. Es posible que en este punto se requiera el desarrollo de plantillas de documentos.
Luego podremos abordar temas de mayor detalle, entre los que resalto:

• Gestión de recursos y gestión de demanda de recursos.
• Método para actualizar el plan y las tareas.
• Carga de horas y manejo de costos.
• Extensiones típicas al EPM de Microsoft: intranet de procesos, encuestas, gestión de requerimientos, gestión de cambios de alcance, entre otras.
• Reporting: vistas, indicadores, reportes y BI.
• Seguridad.
• Look & Feel.
• Manejo de múltiples idiomas.
• Integración con otros sistemas.

2) La implementación de la solución

SI hemos tomado nuestro tiempo en el paso anterior, esta actividad será más sencilla y consistirá principalmente en parametrizar y construir las extensiones necesarias. A esta altura ya será importante contar con nuestros ambientes de desarrollo y prueba separados.

Desde el punto de vista de la parametrización tendremos que trabajar sobre Project Pro, Project Web Application y sobre las plantillas de los sitios de proyectos. Hay que tener en cuenta que en Project Server 2010 podremos tener varias plantillas.

Desde el punto de vista de desarrollo tendremos desde aspectos de look & feel hasta programación de flujos de trabajo, reportes a medida, extensiones a los sitios de proyecto y funcionalidades adicionales.
Un punto importante en esta etapa es la seguridad, que no es un tema menor en Project Server, y que incluso puede requerir la construcción de una extensión.

Validación

Una actividad estándar que por supuesto debemos hacer es la validación y aceptación de la solución por parte del usuario. Mi recomendación es no dejar esta actividad para el final del proyecto, sino que la empecemos a encarar a medida que tengamos funcionalidades intermedias, incluso con los primeros prototipos.

Por supuesto cuando esté toda la funcionalidad disponible, necesitaremos encarar una prueba de integración y realizar los ajustes necesarios.

La puesta en marcha

La puesta en marcha comprende actividades clásicas como la instalación de la solución en producción y la carga de datos iniciales. Claro que previamente debimos haber definido nuestra estrategia de implementación. A modo de ejemplo, se puede encarar un big bang, un paralelo o un piloto, entre otras alternativas.

Desde el punto de vista de la capacitación, suelen existir capacitaciones para líderes, miembros de equipo de trabajo y administradores. Estas capacitaciones abarcan aspectos de proceso de gestión de proyectos y aspectos técnicos.

Un tema muy importante que debemos tener preparado antes del lanzamiento en producción es el de los servicios de operación y soporte. Es decir, quién y cómo dará soporte a nuestra implementación Project Server. En mi experiencia, este ha sido un tema álgido, porque Project Server es una aplicación de nicho, a diferencia de SharePoint, y hay organizaciones que no encuentra la forma de organizar el soporte. Las actividades que recomiendo encarar son:

• Definir la organización de soporte.
• Definir y poner en marcha los procedimientos de respaldo.
• Realizar una primera prueba de recuperación de datos.
• Establecer los procedimientos de monitoreo. Estos abarcan a Windows, SQL Server, SharePoint y Project Server principalmente.
• Establecer los mecanismos de actualización de software: paquetes de servicio, paquetes acumulativos y parches de seguridad entre otros.

Conclusión y agradecimiento

Como hemos visto, una implementación de una solución EPM es un proyecto de una complejidad que debemos respetar. Abarca temas de procesos de gestión de proyectos, procesos de negocio, arquitectura, desarrollo de software y gestión del cambio entre otros.

Si nos toca liderar un proyecto de estas características, debemos lograr el balance perfecto entre el manejo de los aspectos técnicos y los funcionales, contar con todas las especialidades necesarias y con el nivel de sponsor adecuado como para empujar el cambio una vez que se implemente el sistema.

Quiero hacer un especial agradecimiento a Sergio Martínez (http://smartinez.me/) y a Sebastián Torres, colegas con los que trabajo en este tipo de implementaciones, y que aportaron, cada uno en su especialidad, en la detección de las mejoras prácticas de implementación.

Nos mantenemos en contacto y cualquier consulta que implique profundizar en alguno de los temas presentados, pueden contactarse conmigo.

Juan Pablo Pussacq Laborde
http://jpussacq.me/
http://surpoint.blogspot.com/