PRACTICAS NO RECOMENDADAS EN LA OFICINA PROYECTOS

Introducción

Constantemente las empresas u organizaciones generan más y más proyectos, los cuales tienen distintos impactos e importancia dentro del entorno empresarial y en algunos casos, ante la comunidad.  Dichos proyectos requieren de recursos que son escasos y que en ocasiones se les da seguimiento inadecuado y desorganizado. “La solución que está tomando más aceptación, es la creación de una PMO (Project Management Office) que cumpla con una función integradora, organizadora, coordinadora y de control” (Shimomura, 2007).

“Cada proyecto tiene su ciclo de vida –lifecycle- en función de sus objetivos y características particulares. Comienza por una propuesta o “caso de negocio” para dar solución a un problema o necesidad, o mejorar algún aspecto de la compañía” (Shimomura, 2007).

Una Oficina de Proyectos participa en todas las etapas del ciclo de vida de cada proyecto. Por ejemplo, dada su capacidad, coordina, prioriza, optimiza la asignación de recursos compartidos, aplica las mejores prácticas y estandarización, da seguimiento respecto de lo planificado.

La Oficina de Proyectos puede recibir diferentes nombres como: Project Office, Program Office, Program Management Office, Project Control Centre, Oficina de Gestión de Proyectos, Oficina de Administración de Proyectos.

Pero también hay riesgos que pueden rondar a una Oficina de Proyectos y que se deben considerar para su efectivo funcionamiento.  Este documento tratará sobre desventajas, errores y peores prácticas que deben evitarse en una Oficina de Proyectos.

Errores que deben evitarse

Tomado de “Top 10 PMO Worst Practices: Pitfalls to Avoid”, by Daptiv.

La empresa Daptiv ha asesorado a cientos de clientes empresariales y ha encontrado que más del 50% de las PMO fracasan en su primer intento, debido a errores comunes que podemos minimizar. El objetivo de este documento es enumerar algunos de dichos errores y así disminuir ese porcentaje de fracaso.

A continuación se enumeran las 10 peores prácticas en una Oficina de Proyectos que Daptiv ha podido detectar:

  1. Adoptar una actitud Policiva. La Oficina de Proyectos es la encargada de hacer cumplir las metodologías, pero cuando se convierte en un policía, lo que hace es crear descontento dentro del equipo. En lugar de convertirse en ayuda y en guía para los jefes de proyectos, se convierte en el peor enemigo del Gerente de Proyectos.
  2. Implementar una metodología sin un Marco General de Gestión de Proyectos. Muchas Oficinas de Proyectos tratan de implementar el modelo de Ciclo de Vida de Desarrollo de Software (SDLC, Systems Development Life Cycle) o proceso de desarrollo de software, en su organización. Esto puede ser beneficioso para equipos de Tecnología de Información, pero no serlo tanto para otros equipos, tales como infraestructura, mejoramiento de procesos. El modelo más adecuado es el Marco General de Gestión de Proyectos que contiene entre otros:
  • El ciclo de vida de los proyectos. Lo qué hay que hacer en cada etapa.
  • El Ciclo de control. Describe cómo cada etapa es planeada y gestionada.
  • Las Herramientas y las plantillas. Herramientas y plantillas simples para apoyar la gestión.
  • También es conocido como Ciclo de vida de Desarrollo de Proyectos (PDLC).
  1. No implementar una metodología. La Oficina de Proyectos debe implementar el marco general sobre el cual se base una metodología, para garantizar la coherencia de la ejecución del proyecto y para reducir los riesgos derivados de la participación de los jefes de proyecto sin experiencia. Por lo tanto, una metodología o las metodologías establecidas son esenciales bajo un marco general.
  2. No cruzar la demanda con la oferta. En las reuniones del comité de dirección, la atención se centra casi siempre en la priorización de la demanda de proyectos. Pero cuando se trata de decidir cuáles o cuántos de los proyectos en realidad se pueden hacer, si no se tiene métricas de capacidad de recursos, esta discusión se convierte en pura conjetura.
  3. No registrar el tiempo. Sin el seguimiento del tiempo real en los proyectos y en otros trabajos, es imposible conocer la verdadera capacidad de cualquier departamento.
  4. Recopilar información innecesaria. Las Oficinas de Proyectos son buenas en la recopilación de todo tipo de estadísticas. Si esa información no se utiliza para tomar decisiones ¿por qué recogerla? Esto solo crea una carga adicional para el equipo del proyecto sin generar ningún resultado útil.
  5. Mantener el proceso de solicitud de proyectos ad-hoc. Si se evalúan solicitudes de manera aislada, el próximo proyecto importante puede superar a un proyecto ya en curso, hasta que es superado por el siguiente proyecto en emergencia. La solución es la recepción de solicitudes cíclicas (al menos trimestralmente) que tengan en cuenta, todas las solicitudes de lado a lado y seleccionar las más importantes para la empresa.
  6. No contar con el apoyo de la dirección. El equipo de ejecutivos se da cuenta que hay un problema y que los proyectos no se ejecutan correctamente, compiten por muy pocos recursos, o simplemente no entregan los resultados. Pero llegando el momento de la reunión del comité de dirección envían funcionarios de nivel inferior y nos les dan autoridad para tomar decisiones. O, aún peor, ellos pasan por encima de las decisiones de la Oficina de Proyectos. Entonces, cuando los proyectos están una vez más, con bajo rendimiento debido a la falta de recursos y los conflictos de priorización, culpan a las Oficina de Proyectos y las terminan disolviendo.
  7. Implementar Herramientas sin procesos. Este es un problema que se encuentra a menudo. Los departamentos de TI son particularmente propensos a pensar, que implantar una herramienta es la solución completa y es sorprendente la cantidad de organizaciones que caen en esta trampa. La excusa habitual, es que la herramienta ya ha incorporado las mejores prácticas pero cada organización es diferente y requiere su propia adaptación.
  8. Implementar Procesos sin Herramientas. Implementar todos los procesos y luego la herramienta. Lo recomendable es la implementación del proceso y la herramienta al mismo tiempo. Ventajas:
  • Se puede diseñar el nuevo proceso para aprovechar las ventajas de la herramienta de software elegido.
  • Los usuarios aprenden el nuevo proceso en la nueva herramienta, lo que significa que hay una curva de aprendizaje en lugar de dos.
  • El nuevo procedimiento tiene la mejor oportunidad de su adopción por la racionalización y la automatización desde el principio.
  • Sin embargo, hay que tener en cuenta un serio problema: si algo sale mal se necesita verificar si el problema es del proceso o de la herramienta (Blumhorst, 2010).

Otras posibles desventajas.

Una Oficina de Proyectos puede presentar varios obstáculos; los cuales pueden terminar convirtiéndose en riesgos o inconvenientes que afecten sus funcionalidad (Miñana, 2013). Dichos riesgos o inconvenientes se pueden mitigar o controlar. Veamos algunos de ellos:

  • Burocracia Adicional. La Oficina de Proyectos introduce procesos, metodología, niveles de control y supervisión, que pueden aportar mucho a la administración. Al agregar nuevos flujos de trabajo y la aprobación para realizar cualquier tipo de actividad, puede generar la percepción de que habrá más lentitud.
  • La Oficina de Proyectos se ve como una imposición. Muchos se comportan a la defensiva, cuidan sus departamentos/territorios frente al “intruso”.
  • La Oficina de Proyectos puede considerarse como un servicio no productivo. Aumentan los costos de soporte, formación y otros; pueden ser considerados como críticos frente a los beneficios que se puedan obtener.
  • Obstáculo Profesional. La Oficina de Proyectos puede ser vista como obstáculo en la carrera profesional del personal, que conforma los equipos de desarrollo.
  • Torre de Marfil. Existe el riesgo de que la Oficina de Proyectos se considere como una torre separada, que no se alinea a las necesidades de la organización.

Conclusiones

Una de las causas por la cual la metodología adaptada por una Oficina de Proyectos falla, es por la incapacidad de sus “certificados” de apropiarse de una idea sólida y concisa de las buenas prácticas.  Las cuales pueden guiar una Empresa y no, como suele ocurrir, ceñirse a un manual, quizá a la memoria, y más aún quedarse en un “discurso”, sin dar paso a la evolución, concretamente a la actualización.

No se trata de una receta, es decir, responsabilizarse de un proyecto es más que dirigirlo. El título de Gerente de Proyecto requiere tanto de habilidades demostradas como de un toque de visión y también de experiencia.

Si bien las buenas prácticas y recomendaciones de la constitución de un proyecto se encuentran inmersas en la Oficina de Proyectos, la cotidianidad nos lleva también a identificar ciertas prácticas que hay que evitar, entre las cuales están:

  • Adoptar una actitud policiva.
  • Implementar una metodología sin un marco general.
  • No implementar una metodología.
  • No cruzar la demanda a la oferta.
  • No registrar el tiempo real utilizado en los proyectos.
  • Recopilar información innecesaria
  • Mantener el proceso de solicitud de procesos ad-doc.
  • No contar con el apoyo de la dirección.
  • Implementar herramientas sin procesos.
  • Implementar procesos sin que éste incluya herramientas.

Es así, que la Oficina de Proyectos debe contar con una planificación y orientación clara, fundamentada en las buenas prácticas, de una metodología y herramientas que aporten a la administración de los proyectos de la organización.  Buscando con esto, el mejoramiento continuo en la Gestión de Proyectos para generar beneficios.

Por último, el liderazgo de la Oficina de Proyectos en este aspecto, podría entonces inspirar a sus subalternos con una mentalidad abierta al cambio, dispuesta a modificar sus rutinas y hábitos. Esto implica, refrescar los recursos y tecnologías para mantenerlas vigentes, evaluando si no diaria, si periódicamente, el resultado de dichas medidas y que tan fieles nos mantenemos al ideal y desarrollo del proyecto.

Tomado de http://expertconsulting.com.co/Articulos/Proyectos/Peores%20Practicas%20PMO.html

OFICINAS DE GERENCIA DE PROYECTOS (PMO)

Una oficina de gestión de proyectos, también conocida por sus siglas OGP o PMO (del inglés project management office), es un departamento o grupo que define y mantiene estándares de procesos, generalmente relacionados a la gestión de proyectos, dentro de una organización. La PMO trabaja en estandarizar y economizar recursos mediante la repetición de aspectos en la ejecución de diferentes proyectos. La PMO es la fuente de la documentación, dirección y métrica en la práctica de la gestión y de la ejecución de proyectos.

Una PMO puede basar sus principios de gestión de proyectos en metodologías y estándares en la industria, tales como PMI, Prince2, ISO 9001 y requisitos reguladores de algunos gobiernos como el Acta Sarbanes-Oxley en los Estados Unidos, han propulsado a las organizaciones a estandarizar sus procesos.

Organizaciones alrededor del mundo están definiendo, compartiendo y recogiendo buenas prácticas en la gestión de procesos y proyectos. Cada vez más, se está asignando a las PMO la responsabilidad de ejercer una influencia total sobre ellas, y de lograr una evolución de pensamiento que lleve hacia la continua mejora de la organización.

Las PMO pueden operar en aspectos que van desde proporcionar las funciones de respaldo para la dirección de proyectos bajo la forma de formación, software, políticas estandarizadas y procedimientos, hasta la dirección y responsabilidad directas en sí mismas para lograr los objetivos del proyecto.

Las responsabilidades de PMO pueden abarcar desde el suministro de funciones de soporte para la dirección de proyectos hasta la responsabilidad de la dirección directa de un proyecto. La PMO puede ser un interesado si tiene alguna responsabilidad directa o indirecta en el resultado del proyecto. Entre sus funciones, la PMO puede proporcionar:

  • Servicios de apoyo administrativo, tales como políticas, metodologías y plantillas.
  • Capacitación, mentoría y asesoría a los directores del proyecto.
  • Apoyo al proyecto, lineamientos y capacitación sobre la dirección de proyectos y el uso de herramientas.
  • Alineación de los recursos de personal del proyecto.
  • Centralización de la comunicación entre directores del proyecto, patrocinadores, directores y otros interesados.1
  • Actualizar la aplicación de gestión de proyectos

GERENCIA DE PROYECTOS

Gerencia de proyectos es la disciplina de organizar y administrar los recursos, de forma tal que un proyecto dado sea terminado completamente dentro de las restricciones de alcance, tiempo y coste planteados a su inicio.

Dada la naturaleza única de un proyecto, en contraste con los procesos u operaciones de una organización, administrar un proyecto requiere de una filosofía distinta, así como de habilidades y competencias específicas. De allí la necesidad de la disciplina Gerencia de Proyectos.

La gerencia de proyectos implica ejecutar una serie de actividades, que consumen recursos como tiempo, dinero, gente, materiales, energía, comunicación (entre otros) para lograr unos objetivos pre-definidos.

La gerencia de proyectos se practicaba de manera informal, pero a mediados de los años 20 comenzó a surgir como una profesión distinta. Entonces el PMI crea el estándar más reconocido para el manejo y la administración proyectos, La Guía de los Fundamentos para la Dirección de Proyectos (PMBOK®).

CICLO DE VIDA DE PROYECTOS

El ciclo de vida de un proyecto es el conjunto de fases en las que se organiza un proyecto desde su inicio hasta su cierre. Una fase es un conjunto de actividades del proyecto relacionadas entre sí y que, en general, finaliza con la entrega de un producto parcial o completo. Hay proyectos sencillos que sólo requieren de una fase, y otros de gran complejidad que requieren un importante número de fases y sub-fases.

El ciclo de vida de cada proyecto está definido por el modelo de fases que se utilice y este suele estar determinado por la organización, la industria o, incluso, la tecnología empleada en el proyecto. No es posible determinar de forma genérica las fases de todos los tipos de proyecto, aunque en ocasiones se hace referencia a una estructura genérica del ciclo de vida que se compone de las fases de:

  • Inicio:
    • Estudio inicial de viabilidad técnica, económica, comercial, etc.
    • Estimación de necesidades y posibles problemas para realizar el proyecto.
    • Análisis de posibles alternativas para cubrir las necesidades y deficiencias.
    • Estudio de alternativas para realizar el proyecto.
    • Primeras estimaciones de recursos necesarios, costes y plazos.
    • Primera aproximación de la planificación del proyecto.
    • Primera definición del objetivo del proyecto.
    • Normativa y legislación aplicable.
  • Definición:
    • Definición del objetivo junto con el cliente (si procede).
    • Especificación de requisitos.
    • Evaluación de las distintas alternativas contempladas.
    • Cálculo de recursos, costes y plazos y planificación del proyecto.
    • Elaboración de la oferta para su aceptación por parte del cliente.
    • Realización de estudios de viabilidad y de evaluación de riesgos.
    • Toma de decisión: realizar el proyecto, no realizarlo, dejarlo pendiente.
  • Diseño:
    • Diseño técnico del proyecto.
    • Identificar las soluciones tecnológicas a aplicar para cada funcionalidad.
    • Asignación de los recursos materiales.
    • Validación del diseño.
    • Identificación y selección de subcontratas.
    • Ajuste de las especificaciones técnicas
  • Planificación:
    • Identificación de tareas y actividades.
    • Secuenciación de tareas y actividades (determinación de actividades paralelas, secuenciales e interdependencias).
    • Estimación de duración y de los recursos materiales y humanos.
    • Estimación del coste de las actividades.
    • Programación temporal mediante cronograma.
    • Optimización de la planificación: duración (asignando más recursos), costes (usando recursos más económicos, eliminando tareas innecesarias), sobreasignación (cambiando orden de las tareas, poniendo más recursos, etc.)
  • Ejecución:
    • Realización del trabajo planificado.
    • Control e integración del trabajo subcontratado.
    • Integración de los elementos adquiridos externamente.
    • Comprobación de que cada elemento desarrollado y el conjunto, cumplen los requisitos previamente definidos con el nivel de calidad acordado.
    • Realización de las correcciones necesarias para que el diseño corrija los problemas e imprevistos que hayan podido surgir.
    • Validación de esta fase
  • Control:
    • Seguimiento técnico
    • Seguimiento económico:
    • Generación de informes periódicos, concisos y objetivos con propuestas de solución ante desviaciones o riesgo de desviaciones
    • Toma de decisiones.
  • Operación:
    • Puesta en marcha, despliegue, distribución o lanzamiento del resultado.
    • Cursos de formación a los usuarios, al centro de atención al cliente, al departamento de operación y mantenimiento, al cliente, etc.
    • Medición de indicadores para ver las mejoras conseguidas con respecto a la situación anterior a la puesta en marcha (si aplica).
    • Toma de datos de control para verificar el funcionamiento, detectar fallos y disponer de información para mejoras futuras.
    • Comienzo de las actividades de mantenimiento, atención al cliente, soporte postventa, etc. (las que sean de aplicación).
  • Finalización:
    • Actualización de datos tanto técnicos como de gestión para incorporar las últimas modificaciones introducidas en el proyecto.
    • Revisar y actualizar la documentación
    • Realizar un pequeño informe de conclusiones con lo aprendido (errores y aciertos) durante la ejecución del proyecto.
    • Archivo del proyecto para que la información esté disponible para toda la empresa.
    • Reasignación de recursos y cierre contable del proyecto.

En la práctica no existe una única organización de fases ideal que se pueda aplicar a todos los tipos de proyectos. Aunque existan modelos habituales en algunas industrias, los proyectos pueden presentar variaciones muy significativas. Algunos proyectos tendrán una sola fase, otros, en cambio, pueden constar de dos, tres, cuatro o más fases.

  • Independientemente de la cantidad de fases que compongan un proyecto, todas ellas poseen características similares:
  • Cada fase está focalizada en un trabajo concreto.
  • Las fases suelen tener como objetivo el disponer de un entregable que debe estar disponible al finalizar la fase.
  • El cierre de una fase termina con la revisión del entregable y, en ocasiones, con la aprobación de esa entrega.

TIC EN LA GERENCIA DE PROYECTOS

En cualquier proyecto, la organización de las tareas y el tiempo es fundamental. Aunque sea algo pequeño, es necesario organizar muy bien tiempos y prioridades para alcanzar el objetivo, y esto se hace más complicado a medida que se añaden miembros al equipo. Afortunadamente hay varias opciones en software de gestión de proyectos que nos simplifican muchísimo el problema.

El software de gestión ayuda a organizar mejor las actividades ya que permite ver de forma gráfica y sencilla los diferentes proyectos, los miembros del equipo que participan en cada uno, las tareas asignadas a cada uno y el progreso en la ejecución de las mismas.

Herramientas más populares:

  • BASECAMP: Tiene un escritorio muy gráfico y muy bien diseñado donde se muestran todos los proyectos y clientes a la vez. Al entrar a cada proyecto se puede ver fácilmente si hay tareas nuevas o pendientes.
  • TRELLO: Trello es otra herramienta muy eficaz para gestionar proyectos y trabajos en equipo. Permite ver qué tareas hay en cada proyecto de forma bien detallada, quién las tiene asignadas y determinar la fecha límite para cada tarea. También se pueden hacer checklists e incluso votaciones y aportes para cada actividad.
  • BLIMP: El escritorio de Blimp es muy cómodo, y en un momento se pueden ver los diferentes proyectos, quiénes participan en cada uno, la fecha límite y el grado de avance
  • ASANA: Este software está pensado específicamente para el trabajo en equipo. Asana tiene un excelente diseño y está organizado en espacios de trabajo, que permite tener por separado los proyectos personales de los profesionales, por ejemplo.
  • REDBOOTH: Este software de gestión, que nació bajo el nombre de Teambox, es muy intuitivo, y es una herramienta útil y sencilla para proyectos colaborativos.
  • GANTTPROJECT: GanttProject es un programa gratuito bastante diferente a los anteriores que requiere la instalación en el ordenador. Pero es muy sencillo de usar, con una gran interfaz y se pueden organizar las tareas para cualquier proyecto de forma muy gráfica.

CRITERIOS PARA LA EVALUACIÓN DE PROYECTOS

La evaluación de proyectos, en sus distintos tipos, contempla una serie de criterios base que permiten establecer sus conclusiones. En función del campo, empresa u organización de que se trate, es que se emplearán una serie de criterios u otros que guarden relación con los objetivos estratégicos que se persigan.

  • Pertinencia o relevancia: Observa la congruencia entre los objetivos del proyecto y las necesidades identificadas y los intereses de la población e instituciones (consenso social). Se observa especialmente en la evaluación ex-ante pero también en los demás tipos de evaluación.
  • Eficacia: Medida en que se lograron o se espera lograr los objetivos de la intervención, tomando en cuenta su importancia relativa. Se observa en las evaluaciones de tipo continuas y ex-post.
  • Eficiencia: Medida en que los recursos/insumos fondos, tiempo, etc.) se han convertido en los resultados del proyecto. Este criterio es usual en el análisis costo-beneficio realizado en la evaluación ex-ante.
  • Impacto: Efectos a largo plazo positivos y negativos, primarios y secundarios, producidos directa o indirectamente por una intervención para el desarrollo, intencionalmente o no.
  • Sostenibilidad: Medida en que los cambios logrados por el proyecto continúen y permanecen en el tiempo a favor de la población y/o las instituciones, una vez que la intervención ha finalizado. Suele considerarse en las evaluaciones de impacto.

Es fundamental considerar la evaluación desde las propias necesidades, y alcances de las acciones para con la población meta.

PAPEL QUE DEBE TENER UN GERENTE DE PROYECTOS EN CADA UNA DE LAS FASES DE EJECUCIÓN DE ESTOS

El gerente de un proyecto desempeña generalmente las mismas funciones, independientemente del entorno tecnológico en el que se desarrolle el proyecto, con el objeto de satisfacer unos requisitos específicos, de acuerdo con los objetivos de alto nivel del proyecto y teniendo en cuenta las limitaciones de tiempo, coste y recursos impuestas por el cliente, el propio proyecto o por la empresa. Según AEIPRO, Asociación Española de Ingenieros de Proyectos, las funciones que desempeña el gerente de un proyecto son:

  • Planificar y programar el proyecto, que básicamente consistirá en la identificación y descomposición de los trabajos a realizar en el proyecto, considerando las dependencias y ligaduras de cada actividad y los recursos necesarios para su ejecución;
  • Organizar y supervisar el proyecto, es decir identificar y atribuir responsabilidades de ejecución y supervisión de cada una de las tareas que componen el proyecto;
  • Dirigir el proyecto, mediante la autorización, la priorización y la coordinación de la ejecución de cada una de las tareas del proyecto.
  • Controlar y realizar el seguimiento del proyecto, con el objeto de comparar el progreso del desempeño del proyecto con las referencias establecidas en las fases de inicio y definición, con el objeto de tomar medidas si aparecen desviaciones significativas.

Por otro lado, el gerente de un proyecto debe poseer unas cualidades determinadas con el objeto de garantizar el desempeño eficaz y eficiente del proyecto. Por regla general, el responsable de proyectos:

  • Debe conocer el entorno tecnológico en el que se realiza el proyecto y en particular las tecnologías y los procesos utilizados en el proyecto.
  • Debe conocer la organización en la que se desarrolla el proyecto.
  • Debe estar familiarizado con los principios de dirección y en particular debe tener competencia en las metodologías y herramientas propias de la gestión de proyectos, con el objeto de definir, planificar, programar, dirigir, coordinar, controlar y supervisar de la forma más eficaz y eficiente posible los recursos necesarios para la ejecución de los trabajos del proyecto.
  • Debe tener una gran capacidad de negociación, con el objeto de acordar contratos, resolver conflictos, plantear soluciones con clientes y otros participantes involucrados.
  • Debe tener gran capacidad de comunicación. El Director de Proyectos debe facilitar y fomentar el intercambio de información entre los integrantes de la organización del proyecto y debe comunicar de forma adecuada a todos los participantes involucrados en el proyecto.
  • Debe tener liderazgo y capacidad de trabajo en equipo, con el objeto de obtener resultados de los integrantes de su equipo al mismo tiempo que crea un equipo compacto con sus colaboradores directos.
  • Debe tener capacidad de dirigir y resolver conflictos y crisis, de tal forma que sea capaz de manejar conflictos de manera creativa, canalizando los conflictos de modo que los resultados sean positivos y preferiblemente sinérgicos más que destructivos.
  • Debe ser capaz de resolver problemas y eliminar barreras. La realización de un proyecto implica trabajar en múltiples y diferentes problemas. Por ello, el responsable de los proyectos debe considerar la eliminación de barreras como una actividad más utilizando las metodologías generales de resolución de problemas de las que disponga.
  • Debe ser ético y profesional. La asunción de principios éticos por parte de los responsables de los proyectos y su comportamiento respetuoso con la deontología profesional, es imprescindible para la convivencia normal entre las entidades involucradas en el proyecto. Los responsables de los proyectos deben desarrollar principios básicos como la legalidad, la profesionalidad, integridad y respeto a las personas.