Oficina de Proyectos (PMO)

En artículo pasados presenté el tema de los proyectos tecnológicos y su débil comportamiento desde el punto de vista del desempeño de estos, es decir, el cumplimiento de plazos, recursos y expectativas de los stakeholders.

Recordando algunas cifras menos del 20% son exitosos y en el caso del desarrollo de software estas cifras son aún peores.

Producto de lo anterior muchas organizaciones han buscado mejorar sus prácticas, para lo cual han desarrollado metodologías y procesos más rigurosos y finalmente establecer una institucionalidad que permita abordar de mejor forma los proyectos de la organización.

Hoy en día hay preguntas que resultan claves que una organización pueda responder:

• ¿Que tan alineados están mis proyectos con los objetivos estratégicos del negocio?
• ¿Tengo un entendimiento adecuado del valor ganado de los proyectos de mi organización?
• ¿Cuáles son los riesgos claves de mis proyectos?
• ¿Cómo interactúan (se complementan) los proyectos en mi organización?
• ¿Cómo mi organización prioriza los proyectos?
• ¿ Cuál es el nivel y capacidad de absorción de mi organización al cambio?
• ¿Cuáles y porqué son los proyectos con bajo desempeño en mi organización?

Una de las formas más eficientes de abordar este tema es a través del establecimiento de una organización estructurada de gestión de proyectos, denominada "oficina de proyectos" (PMO - Proyect Management Office).

Una definición que me atrevo a proponer de oficina de proyectos es:

Marco institucional en el que se establecen las prácticas, herramientas y mecanismos de control unificados que le permiten a la organización gestionar sus proyectos en las distintas etapas en las que estos se encuentran.

A continuación me gustaría comentar una estrategia de implementación para establecer una oficina de proyectos al interior de la organización.

En primer lugar debemos definir el tipo de PMO que queremos desarrollar. La oficina de proyectos como una organización con un rol consultivo, rol de gestión de conocimientos o bien de definición y gestión de estándares. Las principales actividades que se desarrollan en cada rol son las siguientes:

Consultivo

• Mentoring Gerentes de proyecto
• Consultoría a proyectos en problemas
• Asistencia en la puesta en marcha de "best practices"
• Difundir las lecciones aprendidas
• Auditorías de proyectos
• Apoyo a las unidades de negocios en el diseño de proyectos, selección de proveedores y en el proceso de desarrollo de los proyectos

Gestión del Conocimiento

• Recopilar el conocimiento organizacional y estructurar el aprendizaje
• Identificar y documentar las "best practices" de la organización
• Generar y proveer acceso a repositorios de conocimiento
• Generar material de entrenamiento
• Capacitar a los gerentes de proyecto
• Desarrollar repositorio documental (libros, papers, journals, conferencias y otros)

Gestión de Estándares

• Definir los estándares del proceso de proyectos
• Crear las herramientas (artefactos) para utilizar en las diferentes disciplinas de los proyectos: estimación, diseño, seguimiento y control
• Definición y puesta en marcha de los tableros de mando de los proyectos

El proceso de puesta en marcha de una oficina de proyectos debe además debe además definir el modelo de la misma, es decir

• Fuerte: En este modelo la organización PMO opera como una organización central de administración de los proyectos. Este tipo de modelos maneja la cartera de proyectos (portfolio) a su interior y los gerentes de proyectos dependen del administrador de la oficina.

• Consultivo/Staff: En este modelo la oficina de proyectos entrega capacitación, acompañamiento, coaching y mentoring a los gerentes de proyecto de las diferentes unidades de negocio de la organización. La ventaja de este modelo es que es menos invasivo a la organización.

• Mixto: En el cual la PMO toma control de algunos proyectos (más críticos, en problemas, u otro criterio) y otros quedan en las unidades de negocio utilizando un modelo más consultivo

El proceso de establecimiento debe considerrar todas las componentes necesarias:


En resumen una buena forma de mejorar el gobierno corporativo de las TIC en cualquier organización es establecer una oficina de proyectos con la modalidad que más se adecua a la cultura organizacional particular.

La consultora KPMG a través de su encuesta global de gestión de proyectos concluye que una de las buenas prácticas pasan por contar con una oficina de proyectos PMO de buen nivel. Dicha encuesta concluye los siguientes elementos como prácticas esenciales para una gestión de proyectos de clase mundial.

• Tienen una PMO que gestiona los proyectos de la organización y que está en un buen nivel dentro de la organización
• Reportan al directorio regularmente el estado de los proyectos relevantes
• Cuentan con gerentes de proyectos calificados y con incentivos claros
• Realizan rigurosos análisis de riesgos en la fase inicial de planificación y en muchos casos monitoreo externos

En nuestro país cada vez más se introduce la práctica de establecer oficinas de proyecto, creo honestamente que esto debe potenciarse si queremos tener un mejor resultados de los proyectos en los cuales nuestras instituciones se embarcan, más aún cuando los niveles de complejidad aumentan.

Bibliografía

1. Fundamentos de la Dirección de Proyectos, (Guía del PMBok), 3ra Edición, Project Management Institute
2. The Program Management Office, Craig Letavec, Editorial J. Ross Publishing, 2006
3. KPMG: Global IT Project Management Survey

Proyectos de alto riesgo

Uno de los problemas más frecuentes vinculados a fracasos en proyectos TIC, particularmente dentro del Estado, es cuando estos se abordan utilizando algún esquema de externalización; es un mal diseño del proyecto y fundamentalmente de los procesos licitatorios que lo acompañan.

Es muy frecuente en esos casos encontrarse con bases y términos de referencia mal diseñados, en los cuales los problemas más habituales son:

• Objetivos y alcances poco claros, esta área de las bases es fundamental y la que entrega el marco referencial de lo requerido, su ámbito y áreas que se espera cubra el proyecto.

• Producto y entregables no especificados del todo. Cuando existen productos claros el proveedor puede dimensionar esfuerzo y validar su oferta, esto es particularmente cierto en el caso de servicios (implantaciones, consultorías y asesorías, desarrollos de software, etc.). Es importante que el comprador no se entusiasme pidiendo más de lo razonable por el presupuesto asignado.

• Tiempos, con mucha frecuencia se observan bases en las cuales se expresa la urgencia del comprador de tener terminado el proyecto pero se olvida que el desarrollo de un proyecto TIC como cualquier otro requiere de sus tiempos. Creo que un dicho que aplica en estos casos es nueve mujeres no gestan una guagua en un mes y el problema no se resuelven poniendo equipos de trabajo más grandes como lo esperan algunos compradores.

• Presupuestos que no dicen relación con los productos/servicios requeridos, ya sea por desconocimiento o bien por no realizar un estudio acabado de costos.

Como una manera de graficar esto, quiero mencionar sólo dos ejemplos de procesos licitatorios recientes en los cuales se produce algunas de las situaciones señaladas anteriormente.

Ejemplo Nº 1: Evaluación diagnóstica del soporte tecnológico para la gestión de recursos humanos en Servicios Públicos.

Presupuesto asignado: $ 30.000.000 (aproximadamente 1.634 UF o 55.587 dólares)

Realizando una estimación rápida de recursos sobre la base de los objetivos y alcances y considerando unos 180 servicios públicos potenciales para la evalución, los recursos destinados para la referida evaluación es de 9 UF's por servicio, si consideramos el siguiente esfuerzo por actividad a realizar

(a) Preparación de entrevista/pauta = 30 minutos
(b) Realización de entrevista de levantamiento = 2 horas
(c) Evaluación de antecedentes = 2 horas
(d) Informe final = 2 horas

Lo que corresponde a 6.5 horas-hombre por institución, lo que algunos de ustedes me dirán es un número ridículamente bajo, el valor de la hora-hombre estimada por el servicio público para realizar el diagnóstico es de 1.38 UF/hora-hombre, esto sin considerar ningún otro costo, recordemos que muchos de los servicios públicos están en regiones por lo que al valor anteriomente estimado hay que restarle costos de traslado y estadía.

Ejemplo Nº 2: Desarrollo de un sistema en ambiente web con múltiples usuarios de gran transaccionalidad, los objetivos específicos son: "Diseñar e implementar un sistema de información basado en servicios de Internet, que permita rescatar, almacenar y gestionar los documentos electrónicos, de forma tal que permita al Servicio Público cumplir con su rol" (se han omitido los nombre de instituciones y aquellos detalles que permitan identificarla pero la idea central del objetivo se mantiene)

Presupuesto asignado: $ 12.000.000 (aproximadamente 654 UF o 22.195 dólares)
Tiempo: 16 semanas

Considerando los valores de obtenido en una reciente licitación de desarrollo de software realizada por la Dirección de Compras Públicas, los valores jornada de un equipo de desarrollo estándar compuesto por (0.3 jefe de proyecto, 1 analista, 3 programadores y 1 especialista en QA) los valores obtenidos es de 11 UF/día por equipo de desarrollo, lo anterior significa que el sistema en cuestión para desarrollarse debiera hacerse en 59,4 jornadas.

Si el proyecto tiene asignada 16 semanas esto equivale a 80 jornadas (16*5) el presupuesto es insuficiente.

Por otro lado las bases son absolutamente elementales para describir el problema y claramente llevarán a confusión a quien quiera analizar el requerimiento.

Lo peor de todo es que muy probablemente para ambos casos existirán proveedores que se presenten y finalmente lo que tendremos son dos proyectos en que expectativas y resultados no coincidirán, presentando un potencial de fracaso al menos utilizando la definición de proyecto exitoso (cumplimiento de plazos, recursos y los productos requeridos originalmente) y la probabilidad de tener al final del camino dos proyectos fracasados es alta

Es de esperar que algún día aprendamos la lección!!

Proyectos TIC en el Sector Público

Proyectos TIC en el Sector Público

“Esfuerzo temporal emprendido para proveer un producto o servicio únicos” - Project Management Institute

Algunas cifras
El estado chileno según un estudio desarrollado por la Dirección de Presupuestos con cifras presupuestarias del año 2003, gasta en tecnologías de información y comunicaciones (TIC) aproximadamente 205 millones de dólares anuales, lo cual representa un 2.3% del gasto total del estado y aproximadamente 0.2% del PIB. Lo cual si bien es un buen porcentaje comparado con el gasto promedio en TIC a nivel nacional correspondiente al 1.66% de la facturación, está muy por debajo del gasto en tecnologías de información en otras latitudes como en el caso del Reino Unido donde llega al 1% del PIB. Según el mismo informe se demuestra que el gasto se concentra mayoritariamente en el ítem servicios computacionales.

¿Qué ocurre con los proyectos?
Las cifras respecto del desarrollo y comportamiento de proyectos TIC existentes no son muy alentadoras, según estudios realizados por Standish Group en USA y la Universidad de Oxford en el Reino Unido, sólo el 16% de los proyectos TIC son exitosos (se considera exitoso, proyectos que han terminado utilizando los recursos y tiempos inicialmente planificados). Si el análisis se restringe sólo a proyectos de desarrollo de software esta cifra baja al 1%.

Otro elemento interesante de destacar de dicho estudio es que tanto el sector privado como público mantienen tasas de éxito equivalentes.

Estructura de Proyecto
El ciclo de vida de un proyecto podemos identificar básicamente tres grandes fases, diseño, ejecución y operación. Los factores de riesgo los podemos visualizar en un espacio tridimensional en el cual los ejes son: tamaño del proyecto, calidad de la definición de los requerimientos y nivel de conocimiento de la tecnología necesaria. En la medida que al momento del diseño del proyecto pueda situar mi proyecto en dicho espacio, esto me va a dar ciertas luces del riesgo asociado.

Caracterísiticas de Proyectos TIC en el Estado
Los proyectos TIC tienen singularidades propias dentro del sector público, las cuales deben ser atendidas y analizadas al momento del diseño y análisis del mismo. Estas se pueden segmentar en tres áreas:

Gobierno:

• Los gastos en el estado tienen el escrutinio público (accountability)
• Con mucha frecuencia se promocionan proyectos antes de su puesta en marcha, lo que pone una presión excesiva para su término
• El ámbito público tiene un marco jurídico y regulatorio bastante rígido. El derecho público regula lo que se puede hacer (sólo lo que está dicho)
• En muchos proyectos se requiere de coordinaciones interinstituciones lo que complejiza los proyectos.

Tecnológicos:

• La velocidad del cambio tecnológico es extremadamente acelerada, lo que no está de acuerdo con las velocidades de cambio en el sector público.
• En general las soluciones tecnológicas en el estado están asociadas a grandes volúmenes transaccionales y de procesamiento, lo que plantea un gran desafío al momento de definir las arquitectura tecnológicas necesarias
• El nivel de desarrollo tecnológico dentro del estado es muy heterogeneo, lo que hace muy complejo definir soluciones de carácter global.

Gestión:

• Se requieren habilidades de gestión y administración de proyectos tecnológicos complejos
• Los contratos son de alta complejidad, tanto en su diseño, como en su posterior administración.
• Existe una pobre administración de proveedores, ya sea por desconocimiento y/o por restricciones reglamentarias

Causas de Fracasos de Proyectos TIC
Entre las principales causas de fracasos de los proyectos tecnológicos puedo mencionar:

• Falta de vínculo entre el proyecto y las prioridades estratégicas de la institución
• Falta de habilidades de gestión de proyectos y administración del riesgo
• Falta de liderazgo y ownership del proyecto
• Poco conocimiento de la industria TI local y de lo que realmente puede proveer.
• Presupuestos mal definidos
• Evaluación de propuestas con mirada de corto plazo sustentado en oferta económico y no en valor del gasto
• Pocas iniciativas para segmentar los proyectos en tamaños más manejables
• Arquitectura tecnológica mal definida
• Niveles de servicio (SLA's) mal definidos y/o no administrados

Iniciativas de Mejora
Creo que el estado debe abordar iniciativas de mejora que apunten a reducir los riesgos asociados a los proyectos TIC, entre ellas puedo mencionar:

• Aumentar el esfuerzo en las etapas tempranas del proyecto (diseño) considerando todas las etapas
• Conformación de los equipos de trabajo con las competencias y habilidades requeridas
• Establecer owner de los proyectos complejos al más alto nivel de la institución
• Compartir experiencias (éxitos y fracasos) a nivel de ejecutivos TI del estado
• Establecer programas de certificación y competencias en gestión de proyectos tecnológicos
• Establecer centros de competencia que puedan servir de referencia y apoyo
• Establecer relaciones adecuadas con proveedores