Cómo realizar la Gestión de la Demanda en Project Server 2013

La Gestión de la Demanda (o Demand Management) es el proceso mediante el cuál se filtran y seleccionan las peticiones de nuevos proyectos antes de pasarlos definitivamente a la cartera. Este proceso puede ser más o menos complejo, dependiendo de las necesidades de negocio de cada empresa u organización. Incluso, en ocasiones, la frontera del mismo con la gestión de la cartera de proyectos es un tanto difusa. Por regla general, la gestión de la demanda comprende los siguientes elementos:

  1. Registro de peticiones de proyectos nuevos
  2. Evaluación de la pertinencia de la peticiones (PMO o Gestor de la Demanda)
  3. Si se superan ciertos umbrales de costes y/o de tiempos para la petición, evaluación adicional por comités
  4. Si se ha superado todo el proceso, se convierte la demanda en un nuevo proyecto dentro de la cartera.

Project Server 2013 nos proporciona algunas nuevas herramientas para poder abordar la gestión de estas peticiones y, a continuación, pasaremos a analizarlas brevemente.

Lista de Ideas

Project Server 2013 nos ofrece la opción de gestionar las peticiones de proyectos a partir de una lista de Sharepoint. Cualquier lista que se encuentre dentro de la colección de sitios de Project Server tiene la capacidad de convertir los elementos de la misma en un nuevo proyecto mediante el botón de la Cinta de Opciones “Crear un proyecto”. Una vez pulsado este botón, aparece una ventana modal desde la que se puede realizar un mapeo entre los campos de la lista y los campos disponibles para los proyectos y, finalmente, convertir la petición en un nuevo proyecto. Esta nueva funcionalidad ofrece las siguientes ventajas:

  • Definir los campos que se necesiten de forma personalizada para recoger la demanda de proyectos
  • Recolectar las propuestas entrantes de forma centralizada.
  • Generar un nuevo proyecto casi automáticamente a partir de las mismas.

Sin embargo, la lista de ideas no proporciona ninguna lógica de negocio o de análisis de las demandas. Para ello, es necesario otro elemento que realice esa tarea y que pueda tener acceso a los datos introducidos por el demandante y/o, adicionalmente, por la persona encargada de completar la información necesaria para evaluar la petición. Y este segundo elemento es el flujo de trabajo, que puede ser de lista, reutilizable o de Project Server

Flujo de trabajo (Workflow) con Sharepoint Designer 2013

La evaluación de una petición puede ser un proceso relativamente sencillo o sumamente complejo, dependiendo de las necesidades de negocio de cada empresa. En todos los casos necesitará de un flujo de aprobación de la petición para que el demandante sepa si ha sido aprobada o no. Sin entrar en detalles técnicos, con Sharepoint y Project Server 2010 los flujos de trabajo estaban incrustados dentro de la plataforma, formaban parte de la misma. A partir de la versión 2013 se ha separado la ejecución de los flujos de trabajo a través del servicio Workflow Manager, lo que ha permitido una mejora de la arquitectura y el poder diseñar los flujos de Project Server 2013 mediante Sharepoint Designer, sin la obligación de recurrir necesariamente al desarrollo de los mismos con Visual Studio. Esto último facilita el diseño y mantenimiento de la lógica de negocio por parte del usuario final, aunque por mi experiencia no sea una práctica habitual, manteniéndose el diseño e implementación de los flujos en el equipo técnico. El análisis de la demanda puede realizarse tanto con flujos sobre la propia lista de ideas como con flujos de Project Server asociados a un tipo de proyecto empresarial, o con una combinación de ambos, según nuestras necesidades.

Gestión de la demanda con un flujo en la lista de Ideas

Esta sería una de las primeras aproximaciones al análisis de la demanda, centralizar la misma en un flujo sobre la lista de ideas. Este flujo sería un flujo de lista o reutilizable, preferiblemente del segundo tipo porque facilita su migración a otro entorno. No se realizaría la gestión de la demanda con un flujo de Project Server asociado a un tipo de proyecto. Ventajas

  • La gestión de la demanda se realiza con un solo flujo.
  • La gestión de la demanda es independiente de la gestión de la cartera, lo que facilita su mantenimiento.
  • Al poder mapear campos de la lista de ideas al nuevo proyecto, se pueden llevar al mismo aquellos campos interesantes de la gestión de la demanda, con lo que se podrían mostrar en el centro de proyectos.

Inconvenientes

  • Si se utilizan muchos campos lookups a otras listas de Sharepoint probablemente habrá que crear el mismo número de Enterprise Lookup Tables en Project Server y habrá un doble mantenimiento de información.
  • Si, para evitar este doble mantenimiento, no se crean Enterprise Lookup Tables en Project Server si no que se mapean los valores de los campos lookups de la lista de ideas en campos básicos de texto o numéricos, no se debería poder editar la información proveniente de la demanda. Esto puede no encajar con el proceso de negocio.
  • Los campos calculados de una lista de Sharepoint son mucho más limitados que los de Project Server lo que podría suponer un problema si hay algún cálculo imprescindible que no se pueda realizar y no fuera posible realizar un desarrollo para obtenerlo.
  • La aprobación de cada uno de los actores (Gestor de la Demanda, Comités, PMO…) se realizaría mediante tareas de flujo de trabajo y no dentro de un flujo de Project Server, es decir, dentro de una PDP (Página de Detalle de Proyecto). Esto puede ser algo no deseado por parte de algún usuario de negocio.

Escenario Esta opción está recomendada si la gestión de la demanda es muy sencilla y no hay excesivo doble mantenimiento de información entre listas de Sharepoint y Entreprise Lookup Tables de Project Server.

Gestión de la demanda y de la cartera en el mismo flujo

Otra opción sería realizar el grueso de la demanda con un flujo de Project Server. Además, este flujo contendría la parte correspondiente a la gestión de la cartera de proyectos. No obstante, esto no estaría reñido con tener un flujo más sencillo en la propia lista de ideas, un simple flujo de aprobación para descartar peticiones sin demasiado fundamento. Tras finalizar este proceso, se crearía el proyecto en Project Server y arrancaría el flujo de gestión de la demanda y de la cartera. Ventajas

  • Cualquier campo de la demanda se puede presentar en el Centro de Proyectos
  • Se pueden utilizar en los campos las fórmulas de Project Server, lo que aumenta la potencia de cálculo, sobre todo a nivel de tareas de proyecto.
  • Se rebaja notablemente el doble mantenimiento de información en listas de Sharepoint y Enterprise Lookup Tables al llevarse el grueso de la demanda a Project Server.

Inconvenientes

  • Si existen muchos tipos de proyectos diferentes, al estar unida la gestión de la demanda con la de la cartera en el mismo flujo cualquier cambio de la demanda obligaría a modificar cada uno de los flujos asociados a cada tipo de proyecto, lo cual dificultaría mucho el mantenimiento.

Escenario Esta es una aproximación bastante adecuada a la gestión de la cartera de proyectos. El inconveniente principal es que si hay muchos tipos de proyectos diferentes, los cambios en la demanda se deben replicar en cada uno de ellos. Si la gestión de la demanda es un proceso sencillo, puede ser asumible. Pero si es un proceso complejo, con idas y vueltas a comités, su mantenimiento se complica muchísimo.

Gestión de la demanda en un flujo independiente al de la cartera

La tercera aproximación es crear un tipo de proyecto en Project Server para manejar la gestión de la demanda exclusivamente. Como en el apartado anterior, de forma complementaria se puede utilizar la lista de ideas para una primera criba de peticiones. Una vez aprobada la gestión de la demanda, para continuar con la gestión de la cartera de proyectos es necesario cambiar el tipo de proyecto actual (demanda) al que se requiera. Esta modificación puede realizarse de forma manual desde la Cinta de Opciones mediante el enlace “Cambiar tipo de proyecto” o automáticamente desde el propio flujo de trabajo. Una vez realizada esta acción, el sistema cambia el tipo de proyecto empresarial asociado y se lanza el flujo correspondiente al mismo, en este caso el de gestión de la cartera de proyectos. Cuando a un proyecto se le cambia el tipo de proyecto asociado se mantiene toda la información ya introducida para el mismo. Lo que sí se pierde es la información asociada al flujo de trabajo anterior, es decir, el histórico del flujo de trabajo de la gestión de la demanda. Este inconveniente se puede soslayar mediante la creación de una lista de Sharepoint auxiliar en la que ir almacenando la información relevante durante la ejecución del flujo, una suerte de lista de historial del flujo de trabajo personalizada. De esta forma, la información relevante de la demanda que no se hubiera almacenado en algún campo de proyecto podría consultarse en el flujo de gestión de la cartera mediante una PDP con un simple filtro por URL a partir del parámetro querystring ProjUID. Ventajas

  • Todas las del apartado anterior
  • La gestión de la demanda está separada de la de la cartera, facilitando el mantenimiento de ambas.

Inconvenientes

  • El cambio manual del tipo de proyecto puede resultar extraño a nivel de negocio
  • Si los sitios documentales de cada proyecto empresarial tienen una estructura diferente (librerías,listas, páginas…), será necesario crear un tipo de proyecto de demanda por cada uno de los sitios empresariales, teniendo como plantilla de sitio documental la misma que la del proyecto empresarial con el que se correspondería. Sin desarrollo, es la única forma de poder cambiar de tipo de proyecto al finalizar la demanda y mantener el sitio documental con la estructura necesaria.

Escenario Esta separación de gestión de la demanda y de la cartera en tipos de proyectos independientes es aconsejable cuando el proceso de gestión de la demanda es muy complejo y existen bastantes tipos de proyectos diferentes para la gestión de la cartera, lo que la integración de ambos en uno sólo dificultaría bastante su mantenimiento. La lista de Sharepoint auxiliar evita la pérdida de información al cambiar de un tipo de proyecto a otro.

Conclusiones

En este primer post he tratado de mostrar diferentes técnicas utilizadas para gestionar la demanda en Project Server/Online 2013 en varios clientes. Haciendo uso de dos de las novedades para la versión 2013 del producto (la lista de ideas y la posibilidad de realizar flujos de Project mediante Sharepoint Designer) y combinando ambas, se han podido ver tres maneras de recolectar, analizar y aprobar o rechazar las peticiones de proyectos recibidas desde la PMO.

Anuncios