10 puntos para entender a Project Server 2010

1. La evolución de Microsoft Project

Microsoft Project es quizá la herramienta de gestión de proyectos más conocida y utilizada por los líderes de proyectos. Posee más de 15 años de historia y ha intentado cubrir siempre funcionalidades como:

· Confección del diagrama de Gantt.

· Identificación de la WBS y las tareas.

· Asignación de recursos.

· Asignación de fechas y estimación.

· Determinación del camino crítico.

· Monitoreo y control del proyecto.

Project es una herramienta que podríamos considerar de oficina, así como Word graba documentos, Project guarda archivos de proyectos individuales.

A pesar de ser una herramienta que resuelve muy bien los temas enumerados, se ha quedado chica a la hora de resolver situaciones de manejo de proyectos algo más complejas como:

· Relaciones entre proyectos.

· Manejo de programas de proyectos.

· Pool de recursos.

· Carga de horas.

· Colaboración.

· Escalabilidad.

La solución de Microsoft a estas necesidades ha sido hacer evolucionar el producto hacia una versión corporativa, creando Project Server, una robusta solución que ya va por su cuarta versión y 10 años de historia.

Al tratarse de una evolución, Project Server es el cambio natural para las organizaciones que vienen utilizando Project.

2. Los pilares de Project Server

Project Server es bastante sencillo de entender si comprendemos sus conceptos principales a los que propongo llamar pilares.

El primero: la información de Proyectos en Project Server se almacena en una base de datos, lo que significa que está centralizada y puede analizarse en forma conjunta. Con Project Server se hace realidad la aplicación del concepto de Cartera de Proyectos.

Lo mismo sucede con los Recursos, al estar centralizados, pueden ser compartidos entre los proyectos, permitiendo responder preguntas como la sobreasignación de recursos.

Vean como con esta centralización se hace posible implementar un sistema de carga de horas y reporte de avance, otro de los pilares de la herramienta. Toda esta información genera la historia de los proyectos, pudiendo construir métricas importantes para las organizaciones.

Si a esto sumamos la creación de un sitio de trabajo para cada proyecto, nos encontramos con una herramienta que lejos de estar orientada a un único proyecto, se focaliza en la organización completa, el manejo de múltiples proyectos y recursos, el manejo de la relación entre los mismos y la gestión de los procesos de administración de proyectos: una solución completa y corporativa.

3. Project Web Application

PWA es la aplicación web de Project Server. Fue pensada para dos objetivos principales:

· Soportar la configuración de Project Server.

· Brindar acceso a la información que no sea exclusiva de un único proyecto.

El primer uso que se le dará a PWA, luego de configurar las opciones, es crear vistas en Project Center. Estas vistas nos permiten agrupar, filtrar y ordenar los proyectos de acuerdo a distintos criterios de organización de nuestra cartera. Desde allí podemos ver el detalle de tareas y Gantt de los proyectos, sin necesidad de distribuir archivos, así como también acceder al sitio de cada proyecto.

El segundo uso más común tiene que ver con la posibilidad de cargar horas o informar el avance de las tareas. Aquí también contamos con información de varios proyectos ya que una persona puede estar asignada a varios. Lo interesante es que un usuario puede acceder a una vista de sus tareas, es decir, sus asignaciones.

Por último, a partir del centro de recursos, podremos analizar las asignaciones de uno o varios, sus disponibilidad y sobre-asignación, además de gestionar los datos de cada uno.

Noten como mientras en Project el usuario principal era el líder de proyecto, con PWA hemos agregado por lo menos tres roles:

· Miembros del equipo de trabajo.

· Jefes de áreas o responsable de recursos.

· Interesados en visualizar y controlar la cartera de proyectos.

4. Los sitios de proyecto

Los sitios de proyecto constituyen la tercera pata de esta solución de EPM (Enterprise Project Management). La idea es sencilla, se crea un sitio web en SharePoint para manejar la información propia de cada proyecto. Fuera de la caja, estos sitios poseen:

· Documentos

· Riesgos

· Asuntos (issues)

· Entregables

Todas estas listas están relacionadas con funcionalidad de Project, por ejemplo se puede vincular un documento a una tarea, se pueden ver los riegos de todos los proyectos en la base de datos de Reportes de Project Server o se pueden vincular proyectos entre sí través de la funcionalidad de entregables.

Pero no sólo eso, cuando se descubre el potencial de los sitios de proyecto, se avanza en el uso de los mismos. Enumero a modo de ejemplo, algunas de las funcionalidades que me ha tocado ver implementadas como extensiones a lo estándar:

· Cambios a los proyectos.

· Plantillas de documentos.

· Indicadores claves de performance.

· Acuerdos.

· Micro blogging.

· Información cualitativa del proyecto.

· Defectos.

· Requerimientos.

· Implementaciones de metodologías ágiles.

· Etc.

El sitio de proyecto se termina convirtiendo en una herramienta súper potente, a veces la más utilizada, entre otras cosas porque está orientada a todo el equipo de proyecto.

image

5. Arquitectura

Project Server está conformado por cuatro herramientas:

· Project Server

· SharePoint Server

· SQL Server

· Project Professional

El modelo es totalmente escalable, pudiendo ser instalado en un único servidor o en forma de granja. También son soportadas las instancias de Project Server, las cuales permiten crear diferentes instalaciones dentro de la misma instalación de SharePoint.

Se trata de un modelo flexible y robusto, pero la arquitectura es lo suficientemente compleja como para dedicarle un tiempo a su diseño.

6. Project Server no es SharePoint

Atención administradores de SharePoint: Project Server no es SharePoint. Si bien podemos decir que utiliza su infraestructura, hay muchas diferencias que si no las tenemos en cuenta, nos pueden hacer cometer errores:

· Project Server posee 4 bases de datos propias.

· Project Server posee un modelo de seguridad propietario.

· Los sitios de proyecto de SharePoint en Project Server poseen particularidades y conexiones con Project Server.

· El modelo de programación de Project Server es propietario.

· Los flujos de trabajo de Project Server sólo se pueden crear con Visual Studio y poseen particularidades como actividades propias o entidades que se configuran desde Project Server.

· Todas las operaciones de Project Server se procesan través de un servicio de cola propietario.

· Las alertas de Project Server son propietarias.

· La forma de dimensionar Project Server se basa en otras variables, distintas a las de SharePoint.

Y hay mucho más. No se puede encarar un proyecto de Project Server como si fuera de SharePoint.

7 ¿Cuánto cuesta Project Server?

Para utilizar Project Server necesitarán las licencias de servidor de SharePoint Enterprise y de Project Server, además de lo que respecta a Windows y SQL Server.

Desde el punto de vista del cliente tenemos dos tipos de usuarios:

· Los que necesitan Project Pro. Esta licencia incluye la CAL de PWA.

· Los que sólo acceden a PWA y necesitan CAL de Project Server, de SharePoint Enterprise y de SharePoint Standard.

8. La incorporación de los flujos de trabajo

Una de las novedades más importante de la versión 2010 de Project Server es el manejo de los portfolios de proyectos y todo el circuito de la gestión de la demanda. El foco principal es que esta herramienta nos permite seleccionar qué proyectos ejecutar, a partir de ciertos parámetros como drivers, costos, beneficios, etc.

En mi opinión, la incorporación de flujos de trabajo es clave, porque entre otras cosas nos permite manejar el proceso de aprobación de los proyectos. Con esto Microsoft ha logrado que el circuito comience mucho antes que el momento de la construcción del Gantt y con otros actores como los solicitantes o las gerencias que aprueban. Sin duda un gran paso que posiciona a la herramienta un escalón más arriba.

9 ¿Para quién está pensado?

Project Server está pensado para las organizaciones que manejen parte de sus actividades por Proyectos. No es necesario que la organización posea implementada una oficina de Administración de Proyectos (PMO). En mi opinión personal funciona mejor en organizaciones no pequeñas, que suelen ser las que manejan los proyectos grandes y con mayor cantidad de involucrados.

10 ¿Cómo se implementa?

La respuesta da para un artículo completo, que escapa al alcance de este, pero dejo algunas ideas. Lo primero que hay que saber es que se trata de un proyecto con fuertes componentes técnicos y más fuertes componentes funcionales y de procesos. Les dejo un primer nivel de WBS posible que por supuesto puede variar de acuerdo a cada caso:

· Alcance.

· Definición del proceso de Administración de Proyectos.

· Diseño de la solución.

· Diseño y acuerdo de la arquitectura técnica.

· Implementación de la arquitectura técnica.

· Configuración y parametrización.

· Desarrollo de customizaciones.

· Pruebas de Aceptación.

· Capacitación.

· Definición de los procedimientos de Soporte, Mantenimiento y Operación.

· Despliegue.

· Puesta en marcha del Soporte y Operación.

· Post implementación.

Conclusión

Espero que estos 10 puntos hayan colaborado en la comprensión del alcance de esta herramienta y los animen a encarar una implementación de la misma. Si su organización va por el camino de la gestión de proyectos, entonces una herramienta EPM como Project Server será de una ayuda increíble.

Hasta la Próxima.

 

Juan Pablo Pussacq Laborde

SharePoint MVP

Blog: http://surpoint.blogspot.com/

Facebook: http://facebook.com/surpointblog/

Twitter: http://twitter.com/jpussacq/

 

Artículo publicado originalmente en CompartiMOSS:

http://surpoint.blogspot.com.ar/2012/06/compartimoss-numero-12.html

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *