Project Management Ecuador

Frameworks de Gestión de Proyectos

Metodologías para la Gestión de Proyectos

Una metodología de gestión de proyectos es "un sistema de prácticas, técnicas, procedimientos y reglas utilizados por quienes trabajan en una disciplina". #T800IT #ProjectManagementEcuador Clic para tuitear

Una metodología, o un sistema de gestión de proyectos, ayuda a aquellos en la organización involucrados con los proyectos a saber qué esperar. La definición de mejores prácticas y plantillas normalmente acelerará un proyecto y mejorará su calidad general.

Una organización crea una metodología de gestión de proyectos para establecer un patrón para un tipo de proyecto. Si su proyecto se ajusta a ese tipo, debe seguir el patrón o la metodología.

Cómo desarrollar una metodología

Para desarrollar una metodología, considere las mejores prácticas de la industria para el tipo de proyecto que está administrando. Además, busque ejemplos de ese tipo de proyecto que funcionó bien en su organización anteriormente.

No adopte automáticamente las mejores prácticas publicadas en libros o blogs. Debe usar el buen juicio porque hay una cultura que debe acompañar cualquier metodología para que tenga éxito.

Si su organización tiene una cultura “basada en el héroe”, no adopte una metodología que requiera una estricta disciplina de proceso. Si su cultura se basa en datos, confíe en enfoques analíticos de gestión de proyectos, no en uno que requiera reuniones de equipo y colaboración extensas.

Para que una metodología tenga éxito, la Alta Gerencia debe comprender la metodología y cómo ellos están involucrados con los proyectos.

Los gerentes senior, que habitualmente dirigen a los equipos del proyecto a hacer cosas que violan la metodología, se asegurarán de que no se cumpla. Si la Alta Gerencia quiere cambiar la metodología, cámbiela.

Es mejor tener una metodología imperfecta que se siga, que ninguna metodología en absoluto.

Marcos de Trabajo (Frameworks)

Secuencial (cascada)

Una de las metodologías de gestión de proyectos más destacadas es la metodología secuencial (o en cascada).

Enfoque de cascada

Método de Cascada (Waterfall) o Secuencial
Método de Cascada (Waterfall) o Secuencial

El modelo de cascada es un proceso de diseño secuencial (no iterativo), en el que se ve que el progreso fluye constantemente hacia abajo (como una cascada) a través de las fases de concepción, iniciación, análisis, diseño, construcción, prueba, producción / implementación y mantenimiento.

Esto significa que los miembros del equipo no pueden pasar al siguiente paso del proceso hasta el paso anterior a su finalización. Este proceso va en un orden específico. Por tanto, los miembros del equipo no pueden volver a un paso anterior sin comenzar desde cero. Esto significa que significa que no hay espacio para errores o cambios.

El modelo de cascada no deja espacio para cambios o errores; por lo tanto, los gerentes de proyecto deben planificar ampliamente al principio y luego seguir cuidadosamente el plan.

Ventajas de la cascada

  1. Debido a que el enfoque en cascada requiere un registro detallado, los proyectos futuros pueden mejorarse.
  2. Todo es claro para el cliente desde el principio. Saben exactamente lo que obtendrán y por cuánto.
  3. Gracias a la sólida documentación de cascada, no tiene que preocuparse de que la rotación de empleados arruine un proyecto.
  4. Más fácil de administrar.

Desventajas de la cascada

  1. Los miembros del equipo no pueden volver a una etapa anterior, una vez que se ha completado una fase.
  2. Debido a que esta metodología depende en gran medida de los requisitos iniciales, si los requisitos son malos en algún aspecto, el proyecto fallará.
  3. Si se detecta un error de requisito o debe ocurrir un cambio, el proyecto debe comenzar desde el principio.
  4. Todo el proyecto no se prueba hasta el final.
  5. Este método no tiene en cuenta las necesidades cambiantes del cliente. ¿Qué sucede si un cliente se da cuenta de que necesita más funciones de las que inicialmente pensó? El proyecto se entregará tarde y aumentará el presupuesto.
  6. Toma mas tiempo.

¿Cuándo debería usar el enfoque tipo cascada?

  1. Cuando tiene una imagen muy clara de lo que es el producto.
  2. Cuando los clientes no pueden cambiar el alcance del proyecto, una vez que comienza el proyecto.
  3. Cuando la velocidad no es clave para el éxito del proyecto.

Rational Unified Process (RUP) 

Fue creado por la inicialmente separada de IBM división Rational Software Corporation desde 1993. Se caracteriza por utilizar extensivamente UML. Se definen como mejores prácticas: 

  1. Desarrollar software iterativamente. 
  2. Administrar requerimientos 
  3. Arquitectura basada en componentes 
  4. Software visualmente modelado. 
  5. Verificar calidad de software  
  6. Controlar cambios en el software 

Adicionalmente se definen los siguientes elementos de contenido en el desarrollo de software: 

  • Roles: Se definen perfiles, competencias y responsabilidades, quién se va a dedicar a qué dentro del flujo de trabajo. 
  • Productos de trabajo: Representa los resultados de una tarea, incluyen documentos y modelos producidos a través de todo el proceso. 
  • Tareas: Unidad de trabajo asignado a un rol y cuyo resultado es un producto de trabajo. 

El desarrollo de software pasa por las siguientes fases: 

  • Incepción, se validan costos y presupuestos, modelos de casos de uso, plan de proyecto, restricciones y características clave.  Al terminar esta fase se concuerda el alcance, riesgos y costos expuestos por los interesados en el proyecto. 
  • Elaboración, el proyecto en esta etapa comienza a tener forma y la arquitectura obtiene una forma básica. El modelo de casos de uso en el que se identifican claramente los actores debe estar completado por lo menos en un 80%. 
  • Construcción, aquí se construye el software, se desarrolla el código y en proyectos grandes se dividen iterativamente los casos de uso produciendo prototipos demostrables. 
  • Transición, Es el paso a producción en sí, las actividades incluye el entrenamiento de los usuarios finales y pruebas del sistema para validar las expectativas de los usuarios. 

Se definen asimismo seis disciplinas de ingeniería: 

  • Disciplina de modelamiento del negocio: Se establece el valor que la tecnología puede aportar por medio de TI.  Explica como describir una visión de la organización en que el sistema será implantado y como entonces se usará esta visión como una base para soportar el proceso, roles y responsabilidades. 
  • Disciplina de Requerimientos: Explica cómo establecer las peticiones de los accionistas e interesados y transformarlas en productos de trabajo que enmarcan el sistema a ser construido y proveen requerimientos detallados de lo que el sistema debe hacer. 
  • Disciplina de Análisis y Diseño: La meta es demostrar cómo el sistema que será realizado cumplirá todos sus requerimientos, en un ambiente específico, las tareas y funciones especificadas en los casos de uso.  Es fácil de cambiar cuando los requerimientos funcionales cambian.  Sirve como una abstracción del código fuente y describe como las clases, agrupadas en paquetes, con interfaces bien definidas, desarrollarán los casos de uso. 
  • Disciplina de Implementación, sus propósitos son definir la organización del código en términos de clases, código fuente, archivos binarios, ejecutables, componentes como unidades, e integrarlos como un sistema ejecutable. 
  • Disciplina de Pruebas, sus propósitos son: verificar la interacción con objetos de negocio y con otros componentes de software, que todos los requerimientos sean implementados correctamente, identificar defectos antes de que sean puestos a producción, y que estos sean arreglados, probados nuevamente y cerrados.  Estas pruebas, así como el resto, tienen un enfoque iterativo, esto implica que se pueden detectar defectos tan pronto como esto sea posible, reduciendo costos de corregirlos.  Estas pruebas se pueden efectuar en cualquiera de las cuatro fases, en la que se apunta a medir cuatro principales dimensiones: confiabilidad, funcionalidad, rendimiento de la aplicación y rendimiento del sistema. 
  • Disciplina de despliegue o puesta en producción, Su propósito es producir lanzamientos de productos, y entregar software a usuarios finales. Cubre las actividades de: empaquetamiento, distribución e instalación de software, proveyendo ayuda y asistencia a los usuarios. 

Finalmente existen tres Actividades de Apoyo: 

  • Administración de Cambios, en concordancia con lo que recomienda ITIL  (en su versión 3.0), en la que se lleva rastro de los requerimientos de cambios que se presenten a lo largo del proyecto. 
  • Gestión de Configuración, se incluyen actividades como por ejemplo, lo que ITIL 3.0  denomina CMDB (Configuration Management Database), en la cual se establecen a través de “artefactos”, tales como documentos que detallan los modelos bajo control de versiones cuyos cambios necesitan ser visibles. 
  • Manejo de proyecto, en la que se describe como se cambia de una fase a otra y dentro de una iteración a otra, y los documentos o “artefactos” entregables resultan de cada etapa. 

La siguiente gráfica mide las disciplinas a través de las diferentes fases del desarrollo de software, midiendo las fases como la organización a través del tiempo (eje X), y las disciplinas a través del contenido (eje Y). 

RUP. Fases y Disciplinas
RUP. Fases y Disciplinas

Cada fase se visualiza como un conjunto de iteraciones y como una secuencia de “microproyectos”, ajustados al modelo tradicional de cascada dentro de cada iteración.
Puede verse que la acción de cada rol en cada disciplina se traslapa entre sí en un determinado momento, y esto se presta para que por ejemplo en un determinado momento del tiempo en que la codificación ha llegado hasta un cierto nivel de completitud, el modelamiento o los requerimientos funcionales del sistema puedan variar, haciendo que se haya perdido parte del tiempo empleado en la implementación del sistema basado en las anteriores especificaciones.  Adicionalmente, no tiene cabida el concepto de manejo de incidentes, ni aprendizaje de los mismos por medio de una base de conocimientos (KB en ITIL). 

Capability Maturity Model Integration (CMMI) 

Desarrollado en sus primeras versiones alrededor desde 1987 (como CMM) y continuada hasta 2006 y 2007 en su versión 1.1 y 1.2.  Fue creado por miembros de la industria, el gobierno de los EE.UU. y el Instituto de Ingeniería de Software (SEI). 

CMMI 1.2 comprende 3 grandes áreas:  

  • CMMI-DEV (Desarrollo),  
  • CMMI-ACQ (Adquisición)  
  • y CMMI-SVC (Servicios en general, aún en borrador). 

En CMMI-DEV existen dos modelos: CMMI-DEV y CMMI-DEV + IPPD (Integrated Product and Process Development).  A su vez contiene a 22 Áreas de Proceso: 

  1. Análisis de Causas y Resolución (CAR) 
  2. Gestión de la configuración (CM) 
  3. Análisis de Decisiones y Resolución (DAR) 
  4. Gestión Integrada de Proyectos (IPM) 
  5. Medición y Análisis (MA) 
  6. Innovación y Despliegue Organizacionales(OID) 
  7. Definición de procesos organizacionales (OPD) 
  8. Enfoque Organizacional en Procesos (OPF) 
  9. Rendimiento de Procesos Organizacionales (OPP) 
  10. Formación Organizacional (OT) 
  11. Monitorización y Control de Proyecto (PMC) 
  12. Planificación de proyecto (PP) 
  13. Aseguramiento de calidad de Procesos y Productos (PPQA) 
  14. Integración de Producto (PI) 
  15. Gestión Cuantitativa de Proyectos (QPM) 
  16. Gestión de Requerimientos (REQM) 
  17. Desarrollo de Requerimientos (RD) 
  18. Gestión de Riesgos (RSKM) 
  19. Gestión de Acuerdos con Proveedores (SAM) 
  20. Solución Técnica (TS) 
  21. Validación (VAL) 
  22. Verificación (VER) 

Como guía para efectuar las actividades respectivas se representan de dos formas, en cada una se expresa una magnitud de nivel de mejoramiento de cada área de proceso: 

Representación ContinuaRepresentación Escalonada
NivelNIVEL DE CAPACIDADNIVEL DE MADUREZ
0Incompleto
1RealizadoInicial
2ManejadoManejado
3DefinidoDefinido
4Manejado cuantitativamenteManejado cuantitativamente
5OptimizandoOptimizando

Cada área tiene su respectivo conjunto de niveles de madurez.  La mejora consiste entonces en definir: Componentes Requeridos, que deben ser obligatoriamente satisfechos, agrupados en Objetivos Genéricos y Específicos; y Componentes Esperados, que pueden ser utilizados para
obtener los componentes requeridos, y son las Prácticas Genéricas y Específicas. 

La siguiente gráfica muestra las relaciones entre varias de las 22 áreas de proceso en la categoría de Ingeniería de Software (CMMI-SE): 

CMMI Relación entre las 22 Áreas de Proceso en la Categoría de Ingeniería de Software (CMMI-SE)
CMMI Relación entre las 22 Áreas de Proceso en la Categoría de Ingeniería de Software (CMMI-SE)

Relación entre Áreas de Proceso de Ingeniería 

La siguiente gráfica muestra las relaciones entre varias de las 22 áreas de proceso en la categoría de Ingeniería de Software (CMMI-SE): 

Desarrollo de Requerimientos (RD) identifica las necesidades del cliente y las transforma en “requerimientos del producto” para ser suministrados a  Solución Técnica (TS), quien produce la arquitectura del producto, el diseño del producto en sus componentes, y el diseño de cada componente. TS utiliza a Verificación (VER) para la verificación de ese diseño, mismo que será entregado a Integración del Producto (PI) para su implementación. Validación (VAL) es un área incremental que valida el producto, sus componentes, los “artefactos” intermedios y los procesos respecto a las necesidades de los clientes.  Los conflictos que son descubiertos son usualmente resueltos entre RD y TS.  Los requerimientos son cubiertos por REQM, que describe las actividades para obtener y controlar los cambios, dados por los clientes o incluso por otras áreas del proceso de ingeniería. Esta última área es recursiva, dinámica y transversal a las demás categorías. 

A continuación las actividades Genéricas y Específicas de estas áreas involucradas: 

  • Administración de Requerimientos 
    • SG1. Administrar Requerimientos, e identificar inconsistencias con el plan de proyecto. 
      • SP1. Obtener una comprensión común de los requerimientos, por fuentes oficiales. 
      • SP2. Crear compromisos en los involucrados en el cumplimiento de los mismos. 
      • SP3. Administrar cambios en los requerimientos, aplicando métricas apropiadas de volatilidad de requerimientos para juzgar si se requieren nuevos controles o modificar los actuales. 
      • SP4. Mantener trazabilidad bidireccional entre requerimientos y artefactos. 
      • SP5. Identificar inconsistencias entre artefactos del proyecto y los requerimientos. 
  • Desarrollo de Requerimientos 
    • SG1. Desarrollar requerimientos del cliente, necesidades, expectativas, restricciones e interfaces son recogidas y traducidas en requerimientos del cliente 
      • SP1. Obtener necesidades de todas las partes interesadas para todas las fases del ciclo de vida del producto. 
      • SP2. Desarrollar los requerimientos del cliente. 
    • SG2. Desarrollar requerimientos de productos, en los que los requerimientos del cliente son refinados y elaborados. 
      • SP1. Establecer requerimientos del producto y de componentes del producto. 
      • SP2. Destinar requerimientos de componentes del producto. 
      • SP3. Identificar requerimientos de la interfaz, en el caso de integración entre productos existentes. 
    • SG3. Analizar y validar requerimientos, desarrollando una definición de funcionalidad requerida. 
      • SP1. Establecer conceptos operacionales y escenarios asociados. 
      • SP2. Establecer una definición de funcionalidad requerida. 
      • SP3. Analizar requerimientos, jerarquizándolos, y si ellos cumplen con los objetivos de los niveles más altos de la jerarquía del producto, y a su vez proveen mayor definición de niveles más bajos y detallados. 
      • SP4. Analizar requerimientos para lograr balance. Costos, cronogramas, funcionalidades, componentes reutilizables, mantenimiento o riesgos. 
      • Validar requerimientos tempranamente que dé certeza de una validación final exitosa. 
  • Solución Técnica 
    • SG1. Seleccionar soluciones para componentes del producto. 
      • SP1. Desarrollar alternativas de solución y criterios de selección. 
      • SP2. Seleccionar soluciones para componentes del producto. 
    • SG2. Desarrollar el diseño. 
      • SP1. Diseñar el producto o los componentes del producto. 
      • SP2. Establecer un paquete de datos técnicos. 
      • SP3. Diseñar interfaces de componentes del producto utilizando los criterios establecidos. 
      • SP4. Ejecutar análisis de hacer, comprar o reutilizar (make-or-buy analysis). 
    • SG3. Implementar el diseño del producto. 
      • SP1. Implementar el diseño del producto en el siguiente nivel de la jerarquía: asignación, refinamiento y verificación. 
      • SP2. Desarrollar la documentación de apoyo del producto, para instalar, operar y mantener el producto. 
  • Integración de Productos 
    • SG1. Preparación para la Integración del producto. 
      • SP1. Determinar la Secuencia de Integración 
      • SP2. Establecer el Ambiente de Integración del Producto. 
      • SP3. Establecer Procedimientos y Criterios de Integración del Producto. 
    • SG2. Asegurar la compatibilidad de la interfaces. 
      • SP1. Revisar descripción de interfaces para completitud. 
      • SP2. Gestionar Interfaces. 
    • SG3. Ensamblar los componentes del producto y liberarlo. 
      • SP1. Confirmar componentes para integración preparados. 
      • SP2. Ensamblar los componentes del producto. 
      • SP3. Evaluar Componentes del Producto emsamblados 
      • SP4. Empaquetar y Entregar Productos o Componentes del Producto. 
  • Verificación 
    • SG1. Preparar la verificación. 
      • SP1. Seleccionar artefactos para verificación. 
      • SP2. Establecer ambiente para verificación. 
      • SP3. Establecer procedimientos y criterios de verificación. 
    • SG2. Realizar revisión de pares de artefactos. 
      • SP1. Preparar la revisión de pares. 
      • SP2. Conducir la revisión de pares. 
      • SP3. Analizar los datos de la revisión de pares. 
    • SG3. Verificar artefactos seleccionados, contra sus requerimientos específicos. 
      • SP1. Realizar la verificación 
      • SP2. Analizar los resultados de la verificación, identificando acciones correctivas. 
  • Validación 
    • SG1. Preparar la validación 
      • SP1. Seleccionar productos para la validación 
      • SP2. Establecer el ambiente para la validación 
      • SP3. Establecer procedimientos y criterios de validación. 
    • SG2. Validar Productos o Componentes del Producto. 
      • SP1. Realizar la validación. 
      • SP2. Analizar los resultados de la validación. 

Puede darse cuenta que se establece una fuerte separación y distinción entre las Areas de Proceso, definiendo claramente sus roles, alcances, competencias y limitaciones.  Cabe resaltar la diferenciación entre VER y VAL, como áreas que se entienden respectivamente con TS y PI, efectuando verificaciones y validaciones sobre componentes o “artefactos” que tienen que ver con un mismo proyecto pero que comprenden diferentes elementos. Lo mismo ocurre con REQM y RD, teniendo a REQM como un facilitador que interactúa entre áreas, las cuales actúan tomando la posta de un “artefacto” terminado. 

Lamentablemente, hasta este momento, este modelo no contempla ni Control de Configuraciones ni Base de conocimientos, a menos que estos sean adjuntados al modelo de manera implícita a alguna(s) de las áreas del proceso. 

Adicionalmente, este modelo recomienda con tanta especificidad los procesos que llega a ser un poco complejo y rígido en cierto modo ponerlo en práctica.  Para proyectos pequeños presenta mayores dificultades y trabas que para proyectos grandes, en los cuales es ideal. 

Six Sigma (6σ) 

Es una metodología implementada en 1982 por Bill Smith, como una estrategia de negocios y mejora de la calidad, y posteriormente mejorado y popularizado por General Electric y Motorola. 

Six Sigma: Porcentaje de Aciertos y Fallos, y Defectos por Millón de Oportunidades (DPMO) desde 1σ hasta 6σ
Six Sigma: Porcentaje de Aciertos y Fallos, y Defectos por Millón de Oportunidades (DPMO) desde 1σ hasta 6σ

Se centra en la eliminación de defectos y fallas en la entrega de un producto o servicio al cliente.  Se basa en un estudio estadístico de un valor o conjunto de valores cuantificables que representen a las “fallas” o “defectos”, tales como histogramas o diagramas de Pareto.  La meta de 6σ es llevar el control de un proceso para llevarlo desde el punto de partida hasta el punto Six Sigma (o desviaciones estándar), es decir, a un nivel de 3.4 defectos por millón de productos producidos.  Esto se da mediante un proceso de: definición, medición o muestreo, análisis, mejoramiento y control. 

Six Sigma: Análisis Estadístico de su Distribución Normal (X-Ẍ)/σ
Six Sigma: Análisis Estadístico de su Distribución Normal (X-Ẍ)/σ

Como se dijo anteriormente, esta técnica se centra en la corrección de problemas y no precisamente en el desarrollo de nuevos requerimientos. Además, sólo puede darse una vez que el producto esté en producción y sea evaluado en número apropiado para una muestra válida, o existe un número suficiente de unidades puestas en producción para su muestreo.  Es más bien un ideal o una meta a cumplir con el software desarrollado que una técnica en sí misma. 

Microsoft Solutions Framework (MSF) 

La siguiente fue un marco de trabajo cuya descripción corresponde a la versión 3.0, la cual fue la primera que yo aprendí. De hecho, relacionada con este marco de trabajo, se centró mi Tesis de Maestría en Sistemas de Información Gerencial.

Es un conjunto de principios, modelos, disciplinas, conceptos y líneas guía para entregar soluciones de Tecnología de Información, patentada por Microsoft.  No se limita a desarrollo de aplicaciones solamente, sino a despliegue e infraestructura. 

Consiste principalmente en dos modelos y tres disciplinas: 

Los modelos son los siguientes: 

  • El Modelo de Equipo, el cual organiza gente para hacer el trabajo del proyecto y asegura que las metas se cumplan a través de unir cada rol del equipo con una mayor responsabilidad del proyecto. 
  • El Modelo de Procesos, el cual organiza los procesos necesitados para crear y entregar una solución, a través del ordenamiento del tiempo, dividiéndolo en distintas fases marcadas como hitos. 
MSF. Modelos y Disciplinas
MSF. Modelos y Disciplinas

Las disciplinas son las siguientes: 

  • Disciplina de Administración de Proyectos, que asegura que las actividades de gestión de proyectos sean encaminadas, y que ellas ayuden en lugar de entorpecer el éxito del equipo. 
  • Disciplina de Administración de Riesgos, que es usada para minimizar sorpresas, “apagado de incendios”, y otras actividades caras para proactivamente manejar riesgos. 
  • Disciplina de Administración de Predisposición y Disponibilidad, que es usada para identificar las destrezas requeridas por cada equipo para cada proyecto, y para usar los proyectos como oportunidades para aprender. 

El Modelo de Equipo 

MSF. Modelo de Equipos
MSF. Modelo de Equipos

Se definen inicialmente los siguientes participantes externos al equipo: 

  • Socios externos: Individuos o grupos que están interesados o preocupados en el resultado de un proyecto. 
  • Auspiciante del proyecto. Quien inicia o aprueba un proyecto y su resultado. 
  • Cliente. Individuo que espera ganar valor de negocio de la solución.
  • Usuario Final, quien usa o interactúa con la solución. 
  • Operaciones, que es la organización de TI responsable de la operación pendiente de la solución después que sea entregada. 

Modelo de procesos

MSF. Modelo de Procesos
MSF. Modelo de Procesos

En la figura puede verse las diferentes etapas en las que el modelo de proceso se fundamenta. Inicia con un visionado, en el que se definen las metas a alto nivel del proyecto. Una fase de planeación en la que se definen como se construirá la solución y cómo será desplegada. Una fase de desarrollo, en la que se construye y prueba la solución.  Una fase de estabilización, en la que la solución es probada, estabilizada y preparada para su lanzamiento a producción, cuyas tareas se establecen en la última fase.  

Empieza nuevamente el ciclo si se revisan los objetivos estratégicos, en cuyo caso la funcionalidad del sistema aumentará a través del tiempo por medio del versionamiento. 

Se establece una relación directa y de intercambio o trueque mutuo entre tres elementos. Recursos, Cronograma, y Características de la solución, bajo las cuales debe existir el respectivo equilibrio. 

Triángulo de Negociación MSF
Triángulo de Negociación MSF

Disciplina de Manejo del Riesgo 

Su función inicial es diferenciar entre riesgo e inconvenientes y problemas. Se encarga de identificar, declarar el riesgo, analizar y priorizar, planificar y calendarizar, reportar y
rastrear y finalmente controlar.  Este ciclo lleva luego al aprendizaje registrado en una Base de Conocimientos (ITIL) conceptos y procesos. 
Cada riesgo es identificado, su causa y consecuencia, midiendo el costo de oportunidad y pérdida total, para determinar el impacto en el proyecto. 

MSF tiene la particularidad de ser una metodología perfectamente adaptable a proyectos grandes y pequeños; es decir, es escalable.  Adicionalmente, dado su flexibilidad y adaptabilidad, puede convertirse en una metametodogía, al permitir utilizarla en conjunción con otras metodologías afines a su esencia. 

Ágil

El enfoque ágil se ha vuelto cada vez más popular, como una solución a las desventajas de la metodología de cascada. Este enfoque favorece un proceso incremental e iterativo, en lugar de uno secuencial.

Enfoque ágil

PMBOK 6ta. Ed. más ágil (Agile) ahora
Agile

En lugar de una extensa planificación y diseño inicial, las metodologías ágiles permiten cambiar los requisitos a lo largo del tiempo mediante el uso de equipos multifuncionales, que incorporan planificadores, diseñadores, desarrolladores y evaluadores, que trabajan en sucesivas iteraciones o ciclos del proyecto durante períodos de tiempo fijos. El trabajo se organiza en una cartera de pedidos que se prioriza en un orden de prioridad exacto basado en el valor del negocio (o usuario).

Ventajas de las metodologías ágiles

  • Este enfoque permite realizar cambios después de la fase de planificación inicial.
  • Es más fácil agregar funciones para que pueda mantenerse actualizado en su industria.
  • Los bucles de retroalimentación cortos aseguran que no estás construyendo algo que la gente no querrá.
  • Debido a que las pruebas se realizan al final de cada sprint, los errores se corrigen antes del final del proyecto.
  • Debido a que los proyectos ágiles están tan bien probados, el proyecto se puede lanzar al final de cualquier ciclo, lo que hace que sea más probable que cumpla su fecha de lanzamiento.

Desventajas

  • Si un PM pobremente capacitado está a cargo, el proyecto puede convertirse en una serie de muchos sprints cortos, lo que hace que el proyecto llegue tarde y supere el presupuesto.
  • Al comienzo de un gran proyecto, puede ser difícil evaluar el esfuerzo y los recursos necesarios por adelantado.
  • Debido a que el proyecto no tiene un plan definitivo, el proyecto final puede ser muy diferente de lo que se pretendía inicialmente.

¿Cuándo debería usar una metodología ágil?

  • Cuando la velocidad triunfa sobre la calidad.
  • Cuando los clientes quieren cambiar el alcance del proyecto.
  • Cuando no hay entregables perfectamente definidos.
  • Cuando tienes un equipo experto que es flexible y puede pensar de forma independiente.
  • Cuando el proyecto es para una industria que cambia rápidamente.
Más sobre Metodologías Ágiles

Máster en Sistemas de Información Gerencial de la Escuela Superior Politécnica del Litoral (ESPOL). Project Management Professional (PMP®). Miembro activo del Project Management Institute (PMI®), Capítulo Ecuador, desde el mismo año. Tiene más de 10 años de experiencia en el Sector Financiero y Banca, en el área de Tecnología de Información y Comunicaciones y Desarrollo de Aplicaciones y Sistemas, y más de 6 años en Administración Estratégica de Proyectos Institucionales. Ha trabajado desde el 2006 en dos de los mayores bancos de la ciudad de Guayaquil como Director de Proyectos. Ha liderado y culminado diversos proyectos, entre otros: Migración de Contact Centers, físicamente y actualización de su infraestructura tecnológica, Implementación de módulos completos de ERPs para varios departamentos, con su correspondiente adaptación y entrenamiento. Lanzamiento de nuevos canales financieros y Corresponsales No Bancarios. Nuevos productos para personas naturales y jurídicas. Actualización y optimización de la plataforma de Interaction Voice Response (IVR). Otros de complejidad similar. Ha dictado clases de Project Management y el uso de Microsoft Project Professional 2013, entrenamiento y formación profesional en Centros de Educación Continua en todo el país.

1 comentario en “Metodologías para la Gestión de Proyectos”

  1. Pingback: Una Breve Historia del Project Management • Project Management Ecuador

Deja un comentario

Translate »
A %d blogueros les gusta esto: