Project Management Institute

Implementación de una oficina de control de proyectos

Implementation of a project control office

Abstract

Muchas empresas, actualmente han comenzado a ordenar las tareas que desarrollan, diferenciándolas por el tipo de actividades que llevan a cabo, los productos que generan, y los recursos que emplean en las mismas. Este ordenamiento interno da origen a la definición de proyectos. Estos proyectos son actividades con características homogéneas (generan un producto, no se repiten sistemáticamente, utilizan recursos humanos y materiales, y tiene un claro inicio y final). Si esta forma de ordenar las tareas se despliega en toda la organización, da lugar a la gestación de una importante cantidad de proyectos. Bajo este concepto, la planificación y control de proyectos, la forma en cómo se realizan, la visualización del estado de los mismos, el conocimiento de las principales variables que indican su normal desenvolvimiento, empieza a transformarse en un proceso complejo que debe definirse, soportarse, comunicarse, e implementarse adecuadamente. Es allí donde surge la figura de la Oficina de Control de Proyectos en un sector, y/o en la organización como un todo.

El presente caso de estudio es la experiencia de la implementación de una oficina de control de proyectos en una empresa de servicios (Dirección de desarrollo de software) de Costa Rica.

Introducción

Lidersoft, empresa de desarrollo de software de Costa Rica, es una organización de aproximadamente 100 personas. La empresa ha venido creciendo de manera sostenida en los últimos años, contando con un portfolio de importantes clientes en Costa Rica, su pais, y en el exterior, a donde se encuentra actualmente enfocando sus servicios.

A partir de un proyecto interno de mejora de sus procesos de producción y mantenimiento de software, la empresa obtuvo el nivel 3 del CMM® (Capability Maturity Model) (CMM, 2001), con un appraisal realizado en diciembre de 2003. Posteriormente, durante el 2004, la compañía logró la certificación ISO 9001:2000 (ISO, 2000).

Esta mejora continua de sus procesos, y sus certificaciones asociadas, definieron un marco de base más que significativo, sobre todo en los procesos relacionados a la planificación de proyectos, el control y seguimiento, la calidad asociada a dichos procesos, y demás aspectos que consolidaron un ámbito maduro para el desarrollo de proyectos de software.

Cada proyecto que se iniciaba en la compañía seguía un proceso claramente definido, el cual podía particularizarse de acuerdo al tamaño del mismo. Cada integrante de la empresa conocía claramente su rol y sus responsabilidades dentro de cada proyecto.

Se poseía una metodología de estimación, según las características del proyecto, que se basaba principalmente en una derivación del método de puntos funcionales (Puntos funcionales, 2004) para la estimación de tamaño del software, y en esfuerzo “bajo criterio de expertos”, para los casos en que la estimación de tamaño no era adecuada.

Existía un estricto control de los proyectos, el cual se sustentaba principalmente en un informe de avance, donde se registraban los logros del proyecto, la evolución de los riesgos, los participantes y su dedicación, las fechas estimadas de finalización de las etapas y del proyecto completo, y por último observaciones que los administradores de proyectos podían comunicar, sobre el estado de los mismos.

Adjunto al informe, se presentaba un cronograma actualizado del proyecto.

Estos informes de avance, junto al cronograma del proyecto, eran presentados semanalmente en una reunión de seguimiento al Director de Desarrollo quien, a partir de la lectura de los mismos, evaluaba conjuntamente con los administradores el estado del proyecto a su cargo.

Los esfuerzos insumidos en cada tarea eran registrados en una herramienta de desarrollo propio, mediante la cual la dirección generaba un conjunto de indicadores de estado (esfuerzos insumidos contra planificados).

Estado de la PMO.

Si bien estos procesos descriptos cumplían con los requerimientos, tanto de la norma ISO como del modelo CMM, los mismos no lograban los resultados esperados por los directores de la compañía, principalmente por la dirección general y la de desarrollo de software.

Algunos de los inconvenientes que se identificaban eran:

• La información del informe de avance de los proyectos era algunas veces más retrospectiva que prospectiva, ponía más énfasis en “lo que había pasado”, y menos en “lo que se esperada para el futuro”.

• La generación de los informes de estado demandaban una gran cantidad de esfuerzo, lo cual algunas veces hacía que la información no estuviera disponible en el tiempo oportuno.

• No se poseía una herramienta que brindara información en línea, tanto hacia los niveles directivos, como hacia los integrantes de los equipos de proyectos.

• Si bien la dirección contaba con un conjunto de indicadores, los mismos no se consolidaban y actualizaban dinámicamente sobre la base de estado de cada uno de los proyectos, sino que requerían un procesamiento manual para su generación.

Objetivos de la empresa respecto de la PMO.

En el relevamiento inicial, se puso especial énfasis en identificar los principales objetivos que tenían los directores de la compañía respecto de la implementación de una Oficina de Control de proyectos, y qué esperaban que pudiera mejorar con la implementación de la misma, respecto de sus procesos de planificación y control de proyectos asociados.

Cómo resultado de ello se obtuvieron los siguientes objetivos, entre las distintas direcciones de la compañía:

img

Proceso de implementación de la PMO

Definición del Proyecto.

Para implementar la PMO se definió un proyecto, el mismo contemplaba 4 etapas bien diferenciadas, desde el análisis de situación actual, hasta la propia implementación de la PMO.

Etapa de Inicio

Esta etapa tuvo por objetivo el obtener información de las prácticas en uso en la organización, sus fortalezas y debilidades asociadas. Luego, a partir de ello, realizar la planificación del proyecto y lograr el acuerdo entre los distintos stakeholders acerca de los objetivos, los alcances y la estrategia a llevar a cabo en el proyecto. Posteriormente, y a través de la validación y aceptación del plan, se logró el compromiso de los recursos de las distintas áreas de la Gerencia que participarían en el proyecto, y colaborarían en el mismo para lograr los objetivos planteados. En esta etapa además, se procedió a comenzar con la instalación de las herramientas requeridas para implementar el proceso.

Etapa de Elaboración

Esta etapa tuvo como objetivo la elaboración de los procesos necesarios para la Administración de Proyectos, mediante la PMO.

En ella se definieron los procedimientos y los tipos de proyectos a ser incluidos en la PMO, y los estados por los que los mismos podían transicionar, desde prospectos, hasta su finalización. Se procedió luego a configurar las herramientas según las definiciones establecidas, se definió el pool de recursos de la organización, se elaboró un tablero de mediciones, surgidas desde los procesos de la PMO, y a ser usada por la misma para monitorear el estado de los proyectos.

Además, se analizó y elaboró la arquitectura de herramientas, básicamente la manera en como iban a relacionarse las mismas en la PMO.

Etapa de Construcción

Esta etapa tuvo como objetivo la construcción de los diferentes activos de procesos necesarios, templates y ajustes a la librería de procesos impactada por las nuevas definiciones.

Se desarrollaron también los accesos a las BD necesarios para la generación de los indicadores de gestión.

Etapa de Implementación

Esta fase tuvo como objetivo lograr la implementación del esquema que permitía el registro, control y seguimiento de los proyectos a nivel global estableciendo un workflow que permitió la coordinación entre la Oficina de Proyecto, los líderes y los recursos asignados a tareas de proyectos, y a partir de lo cual se permitía la publicación de los proyectos en un área centralizada en la Intranet de la empresa.

Además, se llevó a cabo la implementación del esquema que posibilitaba la publicación de los cronogramas a nivel detallado (visualización de asignaciones a tareas).

Esto permitía, por un lado, visualizar en forma centralizada el uso de recursos por proyecto, y por el otro, se establecía un workflow que permitía la coordinación entre el líder de cada proyecto y su grupo, pudiendo delegar tareas y conocer el estado de las mismas en todo momento.

Organización del equipo de proyecto

El equipo de proyecto estuvo conformado por:

• Un consultor Senior de la consultora, con el rol de líder de proyecto.

• Un consultor semisenior de la consultora.

• Una contraparte técnica de la empresa.

• Un sponsor de la empresa.

• El sector de calidad, como receptor de los nuevos procesos, y encargado de realizar los ajustes a las librerías de procesos actuales de la organización.

Riesgos del Proyecto

Los principales riesgos identificados fueron los siguientes:

img

Estos riesgos sirvieron para, en primer tiempo comunicar y concienciar a los interesados y al sponsor del proyecto en los potenciales problemas que podían ocurrir en el proyecto si no se tomaban acciones tempranas para mitigarlos, y por el otro, fueron de suma importancia para monitorear el avance del proyecto. Para mitigarlos se realizaron reuniones de validación de alcance de la PMO, se llevaron a cabo worshops de difusión de los procesos y de uso de las herramientas, y se puso en marcha un proyecto piloto, el cual fue monitoreado hasta el fin del proyecto, y del cual se sacaron numerosas lecciones aprendidas que fueron incorporadas a los procesos finales.

Assessment de la PMO

El primer paso, luego de realizada y aprobada la planificación del proyecto, fue conocer el estado de las prácticas de planificación y control de proyectos, y específicas de oficina de control de proyectos, existentes en la empresa. Para ello se analizaron e identificaron los principales hallazgos, divididos en debilidades y fortalezas, y en base a ello se elaboraron las recomendaciones de mejora.

Como complemento, se realizó un mapeo de las prácticas que se realizaban en la organización, en lo referente a procesos de una PMO, contra un estándar de procesos que LIVEWARE considera debieran existir en una PMO.

Descripción del proceso de assessment.

El proceso de assessment consistió de los siguientes pasos: El primer paso fue relevar, consensuar y elaborar un conjunto de objetivos comunes de la organización, respecto de la implementación de la PMO. El foco estuvo puesto en analizar las expectativas, visualizar la factibilidad de que fueran cubiertas mediante la implementación de una PMO, y congeniar y balancear los objetivos entre los diferentes sectores.

img

El segundo paso consistió en realizar un exhaustivo relevamiento de los procesos definidos de la organización relativos a planificación y control de proyectos, control de calidad, administración de la configuración, y aspectos relacionados directa o indirectamente con una PMO.

Este paso fue fundamental, ya que al tratarse de una empresa con un nivel de madurez importante en sus procesos, el objetivo claramente estaba situado en complementar las definiciones existentes, para dotarlas de carencias relacionadas con la coordinación centralizada y homogénea de proyectos en la empresa, y no a modificar procedimientos que funcionaban adecuadamente en cada uno de los proyectos que se estaban llevando a cabo en la compañía.

El tercer paso consistió en identificar aquellos procesos y activos que estaban dando un valor agregado a la organización, en lo relativo a planificación y control del portfolio de proyectos. Esto fue de suma importancia, ya que permitió identificar aquellos aspectos que debían ser mantenidos, y aquellos que debían ser revisados, modificados o eliminados, e identificar prácticas que debían ser cubiertos mediante la definición de nuevos procesos.

A partir de ello, se realizó un mapeo entre prácticas específicas que se esperaba tuviese una PMO que funciona adecuadamente, contra las prácticas que se realizaban en la organización.

Los aspectos contrastados fueron los siguientes:

img Existencia de un Pool Común de Recursos

img Existencia de uno o más “Master planes”, vinculados dinámicamente con los cronogramas detallados de cada proyecto.

img Existencia de un tablero para control de gestión de proyectos que brindara visibilidad de los proyectos, e información para la toma de decisiones.

img Existencia de una estructura de PMO.

img Existencia de herramientas para el control de proyectos: carga de esfuerzos insumidos, administración de cronogramas y proyectos, administración centralizada de proyectos y herramientas para la administración de los riesgos.

Resultados del assessment.

El resultado del assessment realizado fue el siguiente:

img La empresa poseía procesos maduros de planificación y control de proyectos, no olvidemos que se trataba de una empresa en nivel 3 del CMM.

img Si bien existía procesos de coordinación entre grupos, no se visualizaba una PMO como tal. No existían procesos relativos a:

img Definición de un master plan de la empresa (si bien existían cronogramas globales de proyectos, los mismos no estaban implementados de manera óptima, y para todos los casos).

img Vínculos dinámicos entre cronogramas de detalle y cronogramas globales.

img Estructura de PMO, roles y responsabilidades claramente definidas.

img Herramientas colaborativas. Sí se contaba con una herramienta que centralizaba y administraba la carga de esfuerzos insumidos, y tracking de requerimientos.

img No se poseía un pool común de recursos.

img No se contaba con un tablero de control, aunque se encontraba en desarrollo un Balanced Score Card de la empresa al momento del assessment.

Etapa de Elaboración

Como primer paso, se analizaron los tipos de proyectos, y sus características particulares, que iban a estar bajo la esfera de la PMO.

Para cada uno de ellos se analizaron sus características, tales como:

img Ciclos de vida posibles.

img Estados por los que podían pasar “transitar” los proyectos.

img Datos relacionados (que luego serían explotados en un tablero de control).

Todo ello fue plasmado en un Manual de procedimientos de la PMO. Este manual además incluía la definición de estructura de PMO, procedimientos de desarrollo y mantenimiento de un pool de recursos, controles asociados, roles y responsabilidades, y herramientas necesarias.

La arquitectura de herramientas definida fue la siguiente:

img

Pool de recursos

El pool de recursos se desarrollo incluyendo en él la nómina completa de recursos asignables a proyectos de la empresa.

Junto al nombre de cada recurso se agregó información relacionada con disponibilidad, habilidades, conocimientos específicos, rol, y en base a esto último se administró la seguridad en Project Server®. Cada uno de los recursos, con la información antes mencionada, fue incorporado en Project Server®, como Recursos de la Empresa.

Esta funcionalidad permite que los mismos puedan ser compartidos entre varios proyectos, que se pueda conocer en todo momento el grado de asignación y disponibilidad, y además, participar del sistema de mensajería de MS Project® (asignación a tareas, información de trabajos realizados y grado de avance de tareas, ingreso de nuevas tareas por parte de los recursos, delegación de actividades., etc.).

MS Project 2003®, junto a Project Server®, usan un esquema de comunicación entre el administrador del proyecto (o líder) y los recursos asignados a tareas, el cual se describe brevemente a continuación:

1. El líder de proyecto desarrolla el cronograma, y asigna los recursos desde el pool común de recursos de la empresa.

2. El líder Publica el cronograma y solicita a los recursos asignados que acepten o no las tareas.

3. Los recursos aceptan las tareas, o le informan comentarios al líder.

4. El líder solicita estado de las tareas a los recursos asignados.

5. Los recursos asignados, informan el avance de las tareas, pudiendo hacerlo a través del porcentaje de avance de las mismas o la cantidad de horas trabajadas en ellas, y la cantidad de horas que aún son necesarias para terminarla (pudiendo ser cero en caso de que la mismas estén concluidas).

6. El líder de proyecto puede aceptar el informe enviado por de recurso, a partir de lo cual se impacta automáticamente el avance comunicado en el cronograma del proyecto; o no aceptarlo, con lo que debería devolver el mensaje al recurso con las observaciones pertinentes.

Modelo de indicadores

Para desarrollar un tablero de indicadores que le resultara de utilidad a las direcciones operativas, a los líderes de proyecto, y a la dirección general; se realizó un relevamiento de “Necesidades de Información” de los diferentes roles involucrados.

A partir de ello se definieron las mediciones necesarias, y los indicadores que consolidarían dichas mediciones, brindando información útil para la toma de decisiones.

Para desarrollar el modelo, se utilizó el PSM (Practical Software and System Measurment).

Cada una de las mediciones fue definida, y se analizó el lugar desde donde podían ser obtenidas, como así también se desarrollaron los mecanismos de extracción desde las bases de datos de las herramientas utilizadas.

A continuación se ilustra el esquema de arquitectura de extracción utilizado:

La BD

img

LW_indicadores permite integrar los diferentes esquemas de BD, definiendo un único canal de ingreso a las mediciones.

El Excel LW_Indicadores contiene los indicadores los cuales están implementados mediante pívot tables de Excel® desde donde el usuario puede jugar con los datos que integran el indicador, cambiando el tipo de gráfico, modificado los ejes, escalas, colores, y filtrando la información resultante, de acuerdo a sus necesidades puntuales.

Algunos de los indicadores definidos fueron los siguientes:

• Evolución de entregables.

• Desvíos en los proyectos (de fechas planificadas versus reales).

• Evolución de los riesgos.

• Evolución del tamaño, y relación esfuerzo/tamaño.

• Productividad.

• Esfuerzo por fases, y proyectos.

• Tasas de utilización de los recursos (pico y efectiva).

• Earned Value.

• Indice de retrabajo.

Identificación y lanzamiento de un piloto

En paralelo que se iban desarrollando los activos antes mencionados, se puso en marcha un proyecto piloto. El mismo estaba en proceso de inicio, y cumplía con las condiciones requeridas para usarlo como prueba, tanto de los procedimientos que ya estaban definidos, como de las herramientas implementadas.

Antes de su lanzamiento, se llevó a cabo un workshop, en donde se describieron, tanto las funcionalidades de las herramientas implementadas, como los procesos mínimos que debían ser seguidos por los diferentes roles en el proyecto.

Etapa de Construcción

En la fase de construcción, se desarrollaron los indicadores, con sus mecanismos de extracción de información, se desarrollaron los templates de cronograma para cada tipo de proyecto, se realizaron los ajustes sobre Project Server® necesarios, se desarrolló el soporte para la información de habilidades de los diferentes recursos, y la interface entre el CDS (herramienta de carga de esfuerzos insumidos propia de la empresa) y MS Project®.

Como paso final, se definió un plan de despliegue, el cual contemplaba los pasos a ser seguidos para proyectos en ejecución, respecto de si se iban a incluir dentro del nuevo esquema de PMO, o si sólo iba a ser ingresados bajo este esquema los nuevos proyectos.

Etapa de Implementación

Como primer paso se implementaron los templates, y el tablero de indicadores. Para ellos se realizaron los ajustes y configuraciones necesarias, para integrar la información de las diferentes bases de datos. También se implementaron las interfaces entre CDS y Project Server®, y se llevaron a cabo los ajustes necesarios sobre las diferentes herramientas.

Luego, se llevó a cabo una capacitación integral con todos los recursos. Esta capacitación estaba dividida en dos partes, según la audiencia destinataria de la misma. A los líderes de proyecto se les dio una capacitación completa, que incluía conceptos teóricos de la administración de proyectos, y su visión práctica dentro del esquema definido de la PMO. A los recursos en general se les dio coaching sobre su forma de integración en los procesos implementados, se les explicó su rol en el nuevo esquema, las formas de obtener información de los proyectos en los que participaban, y de informar avances e issues a sus líderes.

Tanto el workshop inicial, como esta capacitación más intensiva, son de suma importancia en el proceso de implementación de la PMO, ya que debe partirse de proyectos individuales, adecuadamente definidos y administrados para que la PMO funcione correctamente, brinde información de estado y sea de suma utilidad para coordinar y administrar los proyectos de la compañía.

Es por ello que el líder de proyecto se transforma en una pieza fundamental de todo el esquema, y su trabajo se convierte en la base sobre la cual se decidirá, comunicará, y medirá la performance de los proyectos de la compañía.

Una vez capacitados los recursos, se procedió a realizar el despliegue de acuerdo al plan establecido. Para ello se tomaron los siguientes lineamientos, respecto a qué proyectos serían incorporados y en qué momento:

• Se incorporarían todos los proyectos nuevos, y

• Los proyectos comenzados desde el lanzamiento del piloto, que no estuvieran próximos a ser finalizados.

Actualmente el esquema de PMO se encuentra en funcionamiento siguiendo los lineamientos definidos. Se están comenzando a obtener las primeras mediciones y a utilizar las mismas para el monitoreo y control de los proyectos.

Los resultados de las lecciones aprendidas del proyecto piloto fueron muy entusiastas. Algunos de los principales beneficios que ya se empezaron a visualizar fueron los siguientes:

• Mayor visibilidad por parte de todos los interesados, del estado del proyecto, y del el detalle del por qué de dicho estado.

• Mejor uso de los tiempos, gracias a los procesos y a las herramientas usadas en ellos, que permite coordinar el flujo de comunicación entre el líder y los ingenieros, y por la automatización de los impactos sobre el cronograma del proyecto.

• Se ha logrado un cronograma de proyecto mucho más confiable, actualizado continuamente, y que refleja tanto lo que está pasando en el proyecto, como lo que se espera que pase.

• Mejor control por parte del Líder de las tareas del proyecto, y de la asignación de los recursos a las mismas.

• Mejor control y visibilidad de los riesgos.

Conclusiones

La implementación de una PMO depende claramente de la madurez e institucionalización de los procesos de Planificación y Control de Proyectos. Si en el ámbito donde se va a implementar la PMO ya se poseen procesos definidos y en uso, si los líderes trabajan organizadamente, y siguen esquemas comunes definidos para la empresa, entonces la implementación de la PMO consiste en definir procesos por arriba de estos, que coordinen, sincronicen, brinden una visión de alto nivel del portfolio de proyectos de la organización.

En caso contrario, si no se poseen procesos maduros a nivel de planificación y control de proyectos, se debe trabajar en capacitar e instaurar los procesos básicos necesarios como primer paso, para lograr luego que la PMO reciba la información necesaria sobre la cual establecer el esquema descripto en el presente trabajo.

Hoy día se cuenta con herramientas de mercado, o desarrolladas por las mismas empresas, que nos permiten lograr mayor eficiencia para administrar y coronar un gran número de proyecto. El problema que se ve a menudo es que no se definen e implementan procesos que le den a la organización un marco de trabajo sobre el cual implementar, de manera integrada, dichas herramientas. Esta falta de visión de procesos, junto con a la creencia de que la sola implementación de las herramientas resolverá los problemas existentes en la organización, son la fuente de fracaso más común que he visto a la hora de implementar oficinas de control de proyectos.

En síntesis, con las herramientas adecuadas y la definición e implementación de un proyecto que analice, defina, integre e implemente los procesos necesarios de una PMO, se logran resultados que brindan enormes beneficios a la organización.

Referencias

CMM (2004), Getting Started with CMMI® Adoption, http://www.sei.cmu.edu/cmmi/adoption/cmmistart.html

ISO (2004), ISO 9001:2000, http://www.iso.org/iso/en/iso9000-14000/iso9000/iso9000index.html.

PSM (2004), Practical Software and System Measurements, http://www.psmsc.com/.

Puntos Funcionales (2004), Internacional Function Point User Group, http://www.ifpug.org/.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

© 2004, Esteban A. Zuttion
Originally published as a part of 2004 PMI Global Congress Proceedings – Buenos Aires, Argentina

Advertisement

Advertisement

Related Content

Advertisement