Christian A. Estay-Niculcar's research blog

Improving the design of innovation, knowledge, and learning projects through people, computing, ICT, processes, and systems.

Ingeniería del proyecto: Modelos de madurez de gestión de proyectos: Capability maturity model (CMM), Trillium model, Project Management Assesment (PMA), Management Maturity Model (PM3), e Innovation Maturity Model (IMM)

Desde el área de proyectos, se ha planteado que las prácticas de gestión han de usarse según las competencias que requiera un proyectista conforme madura a nivel de experiencias. En este sentido se han presentado varios niveles de madurez en la forma de modelos de madurez, muchos de ellos tomados del ámbito de la Ingeniería de Software, y por ende toman como punto de partida el Capability Maturity Model del Software Engineering Institute en Estados Unidos.

Un modelo de madurez de gestión de proyectos en el área de Proyectos, aglutina y organiza en niveles de madurez un conjunto de criterios de gestión con el fin de orientar las actuaciones de los proyectistas. Estos niveles, sirven de base, tanto para aprender y asimilar prácticas de gestión de proyectos como para ser metas a conseguir las organizaciones desde el punto de vista de la calidad de su gestión de proyectos.

A continuación se presentará el CMM para luego pasar a revisar algunos modelos de madurez en gestión de proyectos. Cabe destacar que ahora existe el CMMI o CMM Integrated, no obstante para los efectos de este post sirve de buena base para comprender los otros a describir en el contexto de la gestión de proyectos.

a. Capability Maturity Model

El CMM es un marco que representa recomendaciones para organizaciones de software que desean mejorar la calidad y capacidad de sus procesos de software. En este sentido, el CMM describe las prácticas de ingeniería de software y de gestión que caracterizan a las organizaciones conforme mejora (madura) su proceso para desarrollar y mantener software.

La mencionada madurez se valora en función de cinco niveles de madurez. Un nivel de madurez es una plataforma en el camino de conseguir una mejora en un proceso de software. Cada nivel de madurez considera un conjunto de objetivos de procesos que una vez satisfechos estabilizan una componente del proceso de software. A continuación se describe cada uno de los niveles de madurez del CMM:

  • Inicial. En este nivel el proceso de software es ad-hoc y ocasionalmente caótico. Pocos procesos son definidos y el éxito depende del esfuerzo y heroicidad de los individuos;
  • Repetible. En este nivel se establecen procesos de gestión de proyectos básicos para hacer seguimiento del costo, la programación y la funcionalidad;
  • Definido. En este nivel las actividades de gestión e ingeniería del proceso de software son estandarizadas y documentadas en uno o varios procesos de software estándar para la organización;
  • Gestionado. Mediciones detalladas del proceso de software y calidad del producto son registradas. En este nivel, el proceso y el producto de software son cuantitativamente comprendidos y controlados; y,
  • Optimizante. En este nivel se habilita la mejora continua del proceso.

A su vez, los niveles de madurez se componen de áreas de proceso claves (Key Process Areas), que contienen prácticas clave (Key Practices) organizadas a su vez en rasgos comunes (Common Features).

  • Las Key Practices Areas (KPA) indican las áreas en que una organización debería concentrarse para mejorar su proceso de software.
  • Las Common Features (CF) son un conjunto de prácticas agrupadas dentro de un área clave o necesidad.
  • Las Key Practices (KP) son las actividades e infraestructura que contribuye de manera más efectiva a la implementación e institucionalización de cada área clave.

Cabe añadir que el carácter organizador del CMM ha dado lugar a toda una serie de variaciones ligadas al desarrollo de software como un producto. Por ejemplo, la versión del CMM para la adquisición de software, o aplicaciones más concretas acerca de cómo mejorar la capacidad de gestión del conocimiento. Hoy en día, estas aportaciones y versiones, están integradas en el CMMI.

No obstante el CMM presenta la peculiaridad de describir la madurez por niveles y,  además, plantea un camino para conseguirlas. Sin embargo, como modelo es un patrón que plantea lo que hay que medir por nivel, no distinguiendo si existen mejoras parciales. Como instrumento de medición posee un carácter excesivamente evaluativo más que formativo y, además, deja a las organizaciones sin capacidad de mejoras parciales por temas, por procesos críticos o más robustos.

b. Modelos de madurez de gestión de proyectos

Del área de gestión de proyectos se han considerado en este estudio los siguientes modelos de madurez de proyectos escogidos por accesibilidad, relevancia e impacto:

  • Trillium model (Trillium),
  • Project Management Assesment 2000 (PMA),
  • Management Maturity Model (PM3), e
  • Innovation Maturity Model (IMM).

b.1. Trillium model

El modelo Trillium es un producto usado por Bell Canada para dar valor al desarrollo de un producto y apoyar las capacidades de proveedores de telecomunicaciones o productos basados en tecnologías de la información existentes o futuros. El modelo ha sido diseñado para ser aplicado a sistemas de software ‘empotrados’ tales como sistemas de telecomunicaciones, no obstante buena parte del modelo puede ser aplicado a otros segmentos de la industria del software como sería  el área de Management Information Systems.

Con respecto al CMM, el modelo Trillium, se distingue en que:

  • define roadmaps en lugar de áreas clave; tiene una perspectiva orientada al producto, haciéndolo más general y de amplio uso;
  • da amplia cobertura a los aspectos que inciden o impactan en la capacidad del proceso; y,
  • se enfoca al cliente en lugar del desarrollo mismo.

Esto consigue que se definan prácticas que guían al proyectista sobre cómo conseguir lo que desea un usuario/cliente donde, en lugar de señalar determinadas metas que se deben alcanzar con ciertas prácticas de diseño, se buscan aquellas prácticas que habiliten la consecución de lo que desea el usuario.

A semejanza del modelo CMM, el modelo Trillium presenta una escala de cinco niveles de madurez:

  • Nivel 1. Desestructurado. En este nivel el proceso de desarrollo es ad-hoc. Los proyectos frecuentemente no pueden satisfacer objetivos de calidad o de programación. El éxito posible se basa  más en el trabajo de los individuos que en la propia estructura e infraestructura organizacional.
  • Nivel 2. Repetible y orientado al proyecto. El éxito individual del proyecto se consigue a través de una férrea planificación y control de gestión del proyecto, dando especial énfasis a los requerimientos de gestión, técnicas de estimación y configuración del cambio.
  • Nivel 3. Definido y orientado al proceso. Aquí los procesos son definidos y utilizados al nivel organizacional, no obstante se acepta que el proyecto sea adaptado a las circunstancias. Los procesos son controlados y mejorados. Se incorporan requerimientos ISO 9001 como procesos de entrenamiento y auditoria interna.
  • Nivel 4. Gestionado e integrado. La monitorización y análisis del proceso es usado como mecanismo clave de mejora. Procesos de gestión del cambio y programas de prevención de defectos son integrados. Las herramientas CASE se integran dentro del proceso.
  • Nivel 5. Completamente integrado. Metodologías formales son extensivamente usadas. Repositorios organizacionales son usados para soportar y mantener la historia del proceso de desarrollo.

La arquitectura de Trillium (ver siguiente figura) igualmente plantea una descomposición pero con una diferencia sustancial con el CMM: CMM: no se comienza la descomposición desde los niveles de madurez, sino desde ocho áreas de capacidad (Capability Areas), cada una de las cuales contiene varias roadmaps y estos últimos a su vez contienen prácticas (Practices), usados paulatinamente por niveles de madurez.

De esta forma, la arquitectura de Trillium se caracteriza por poseer:

  • Capability Areas (CA), que son áreas centrales de preocupación del modelo Trillium y que encuentran contenidas por prácticas;
  • Roadmaps (RM), que son un conjunto de prácticas relacionadas, enfocadas sobre un área o necesidad organizacional, o un elemento específico, dentro del proceso de desarrollo del producto; y,
  • Practices, que son las acciones a desarrollar para conseguir una mejor capacidad del proceso, cada una de las cuales se vincula a un nivel de madurez.

Para completar estar descripción, la siguiente Tabla muestra la relación entre estos elementos:

b.2. Project Management Assessment

El Project Management Assessment 2000 es una metodología holística y una herramienta de software para la mejora de procesos de gestión en un medio ambiente de gestión de proyectos. Se ofrece para dar soluciones a problemas de inflexibilidad, de tiempo, de “no saber hacer” y, de falta de una mejora incremental.  Se basa en un modelo donde deben integrarse prácticas genéricas y específicas, para lo cual se cuenta con un software.

b.3. Management Maturity Model

El  Management Maturity Model se orienta a mejorar prácticas de gestión de proyectos. El modelo se ha construido a partir de encuestas a organizaciones que han llevado, obviamente, proyectos, buscando definir las prácticas de gestión que aplicaban. Según la última información disponible, el modelo se ha modificado hasta alcanzar unas 300 lecciones sobre gestión de proyectos en el ámbito corporativo.

Estas prácticas se han organizado en niveles de madurez. De estos niveles: ad-hoc, abreviado, organizado, gestionado y adaptativo; se conocen 51 preguntas que permiten saber el nivel de una organización.

b.4. Innovation Maturity Model

El Innovation Maturity Model (IMM)  no es un modelo como tal, sino una propuesta para el desarrollo de productos. Es una visión sobre cinco niveles de innovación: superficial (Superficial), mejoras en rasgos (Feature Enhancements), mejoras en soluciones (Solution Enhancements), soluciones impactantes (Breakthrough Solutions) y ‘rompedora’ (disruptive).

c. Implantación de la madurez

Todos los modelos previos de una u otra manera buscan medir o alcanzar un determinado nivel de competencia en gestión de proyectos. Conseguir esta competencia requiere algunas precisiones de detalle y consecución.

En cuanto a detalle, se ha propuesto un modelo de madurez basado directamente en el PMBOK de ocho (8) niveles de madurez, cuya cantidad solamente se justifica en la medida de conseguir una competencia paulatina. A grandes rasgos, tales niveles se caracterizan por lo siguiente:

  • Nivel I. No conocedor (non-awareness). No existe conocimiento alguno sobre gestión de proyectos.
  • Nivel II. Inicial. Se comienzan a introducir prácticas de gestión de proyectos.
  • Nivel III. Básico. Comienzan algunas tareas de gestión como asignación de responsabilidades, documentación, hitos y manejo formal de información.
  • Nivel IV. Repetible. Se establecen algunos procesos de gestión y se formaliza el uso de determinadas herramientas. Ya existe algún plan de entrenamiento en gestión de proyectos y se llevan algunas auditorias.
  • Nivel V. Avanzado. El entrenamiento y, las auditorias o seguimientos, son totales, igualmente algunos procesos y herramientas son incorporados en su totalidad.
  • Nivel VI. Bien-definido. Los niveles de autoridad y experiencia son completos, el entrenamiento es avanzado, los procesos se integran introduciéndola  documentación y el uso de métricas.
  • Nivel VII. Gestionado. Se promueven los incentivos, se introduce la certificación en gestión de proyectos. Se persigue un buen desempeño y mejorar la eficiencia y efectividad.
  • Nivel VIII. Optimizante. La mejora es continuada y sostenible.

Lo importante de esta propuesta es el Nivel VIII al dejar explícito que los niveles de madurez no son un fin en sí mismas, sino un medio para garantizar una mejora adaptativa y sostenida a lo largo del tiempo.

Respecto de la consecución de la competencia, una manera de introducir técnicas de gestión que satisfagan los niveles de madurez del CMM es siguiendo ciclos iterativos. En este sentido, algunos autores han propuesto un mecanismo para sensibilizar a los proyectistas en la conveniencia de aprender a mejorar. Para ello se deben seguir ciclos de mejora de forma paulatina, por ejemplo, comenzar con un ciclo As-Is donde se presentan las primeras prácticas de gestión, pasando luego a un ciclo de actualización de procesos e infraestructura para alcanzar un nivel 2 y así, ejecutar un tercer ciclo orientado a conseguir el nivel 3 del CMM.

————————-
Para ver más consultar en:

Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

about.me

Christian A. Estay - Niculcar

Christian A. Estay - Niculcar

Higher Education / Innovation & Informatics & ICT / Action-Researcher / e-government

Innovation in ICT-based Strategies

Change management through e-learning & off-shore learning

More on Twitter

Follow Christian A. Estay-Niculcar's research blog on WordPress.com

Posts Más Vistos en 24-48 hrs.

Estadísticas del blog

  • 118,063 hits

Categorías

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 1.467 seguidores

%d personas les gusta esto: