INGENIERÍA Y SERVICIOS IT

PMBOK SEXTA EDICIÓN: 5 GRUPOS DE PROCESOS Y 10 ÁREAS DE CONOCIMIENTO

41KOdeGvtdL._SX383_BO1,204,203,200_.jpgLa sexta edición de la Guía PMBOK se publicó en septiembre del 2017 y desde entonces los cambios han sido comentados por las personas que estamos involucradas en el apasionante mundo de la Dirección de Proyectos.

Los procesos de la Dirección de Proyectos se agrupan en 5 categorías conocidas como Grupos de Procesos de la Dirección de Proyectos, los cuales se definen a continuación:

1.- Grupo de procesos de Inicio.

En este grupo encontramos los dos procesos que permiten definir un nuevo proyecto o una nueva fase de un proyecto ya existente. Estos procesos son: Desarrollar el Acta de Constitución del Proyecto e Identificar a los Interesados.

2.- Grupo de procesos de Planificación.

En este grupo encontraremos aquellos procesos requeridos para establecer el alcance del proyecto, refinar los objetivos y definir el curso de acción necesario para que dichos objetivos, por los cuales se emprendió el proyecto, sean alcanzados.

3.- Grupo de procesos de Ejecución.

Encontramos aquellos procesos que son ocupados para completar el trabajo definido en el plan para la Dirección del Proyecto a fin de cumplir con las especificaciones de este.

4.- Grupo de procesos de Monitoreo y Control.

En este grupo encontramos aquellos procesos requeridos para dar seguimiento, analizar y regular el progreso y el desempeño del proyecto, además de identificar áreas en las que el plan requiera cambios e iniciar los cambios correspondientes.

5.- Grupo de procesos de Cierre.

Con esta nueva edición de la Guía PMBOK este grupo se queda solo con el proceso Cerrar el proyecto o Fase. Un proceso empleado para finalizar todas las actividades, a fin de cerrar formalmente el proyecto o una fase de este.

10 Áreas de Conocimiento:

1.- Gestión de la Integración del Proyecto.

Define los procesos y actividades que integran los diversos elementos de la dirección de proyectos. Incluye los procesos y actividades necesarios para identificar, definir, combinar, unificar y coordinar los diversos procesos y actividades de la dirección de proyectos dentro de los grupos de procesos de la dirección de proyectos.

2.- Gestión del Alcance del Proyecto.

Incluye los procesos necesarios para garantizar que el proyecto incluya todo el trabajo requerido para completarlo con éxito. El objetivo principal de esta área, es definir y controlar qué se incluye y qué no, en el proyecto.

3.- Gestión del Cronograma del Proyecto.

Con la actualización en la Guía PMBOK, el nombre de esta área cambió, ya que antes se llamaba: “Gestión del Tiempo del Proyecto”.

Incluye los procesos que se utilizan para garantizar la conclusión a tiempo del proyecto.

4.- Gestión de los Costos del Proyecto.

Incluye los procesos involucrados en estimar, presupuestar y controlar los costos de modo que se complete el proyecto dentro del presupuesto aprobado.

5.- Gestión de la Calidad del Proyecto.

Contempla los procesos y actividades involucradas en planificar, dar seguimiento, controlar y garantizar que se cumpla con los requisitos de calidad del proyecto.

6.- Gestión de los Recursos del Proyecto.

En la versión anterior de la Guía PMBOK esta Área tenía el nombre de “Gestión de los Recursos Humanos del Proyecto”.

Esta Área describe los procesos involucrados en la identificación, adquisición, desarrollo y gestión de los recursos necesarios para la culminación exitosa del proyecto.

7.- Gestión de las Comunicaciones del Proyecto.

Contempla los tres procesos necesarios para garantizar que la planificación, recopilación, creación, distribución, almacenamiento, recuperación, gestión, control, monitoreo y disposición final de la información del proyecto sean adecuados y oportunos.

8.- Gestión de los Riesgos del Proyecto.

Describe los procesos involucrados en la planificación de la gestión, identificación, análisis, planificación de las respuestas, implementación de las respuestas y control de los riesgos para el proyecto.

9.- Gestión de las Adquisiciones del Proyecto.

Incluye los procesos de compra o adquisición de los productos, servicios o resultados que es necesario obtener fuera del equipo del proyecto. Se describe cómo serán gestionados los procesos de adquisición desde el desarrollo de la documentación de adquisición hasta el cierre del contrato.

10.- Gestión de los Interesados del Proyecto.

Incluye los procesos necesarios para identificar a las personas, grupos u organizaciones que pueden afectar o ser afectados por el proyecto, para analizar las expectativas de los interesados y su impacto en el proyecto.

INGENIERÍA Y SERVICIOS IT

STAKEHOLDERS

Stakeholder es una palabra del inglés que, en el ámbito empresarial, significa ‘interesado’ o ‘parte interesada’, y que se refiere a todas aquellas personas u organizaciones afectadas por las actividades y las decisiones de una empresa.

En toda organización, además de sus propietarios, participan diversos actores claves y grupos sociales que están constituidos por las personas o entes que, de una manera y otra, tienen interés en el desempeño de una empresa porque están relacionadas, bien directa, bien indirectamente, con ella.

En estos grupos podemos contar a los empleados, clientes, proveedores, accionistas, inversores, entes públicos, organizaciones no gubernamentales, sindicatos, organizaciones civiles, la comunidad y la sociedad en general.

El término stakeholder fue acuñado por primera vez por R. Edward Freeman en su libro Strategic Management: A Stakeholder Approach, publicado en 1984, en el cual su autor sostenía que estos grupos de interés son un elemento esencial que debe ser tomado en cuenta en la planificación estratégica de los negocios.

Así, el éxito o el fracaso de una empresa afecta o concierne no solo a sus dueños, sino también a los trabajadores y a sus familias; a los proveedores, a los competidores, así como a la comunidad donde se encuentra inserta, entre otros.

Existen dos categorías fundamentales de stakeholders.

  • Los stakeholders primarios, que son aquellos imprescindibles para el funcionamiento de la organización, es decir, todos aquellos que tienen una relación económica directa con la empresa, como los accionistas, los clientes o los trabajadores.
  • Los stakeholders secundarios, que son aquellos que no participan directamente en las actividades de la empresa, pero que, sin embargo, se ven afectados por ella, como, por ejemplo, los competidores o la comunidad, entre otros.

https://www.significados.com/stakeholder/

INGENIERÍA Y SERVICIOS IT

GERENCIA DE PROYECTOS

La gerencia de proyectos es la aplicación del conocimiento, habilidades, herramientas y técnicas para conseguir o exceder las necesidades y expectativas de los “stakeholders” a través de un proyecto. Para conseguir o exceder las necesidades y expectativas de los “stakeholders” es indefectiblemente necesario balancear: alcance, tiempo, costo y calidad de las diferentes necesidades y expectativas para requerimientos identificados y no identificados.

Project management Institute, PMI

INGENIERÍA Y SERVICIOS IT

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

INGENIERÍA Y SERVICIOS IT

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