La
ejecución de proyectos se enfrenta actualmente a exigencias cada vez más retadoras
de los clientes en relación con sus expectativas de productos finales de alta
calidad, en menor tiempo y costos. Además, dependiendo del tipo de proyecto,
las expectativas de los clientes en términos de tiempo y costos pueden presentar grandes
variaciones entre un proyecto y otro. Por lo tanto, seria recomendable que las
organizaciones con múltiples y diferentes proyectos los abordasen de la manera
más adecuada para satisfacer las expectativas de los clientes. Para ello, sería necesario
conocer y diferenciar los modelos de ejecución de proyectos más utilizados en
la actualidad y cómo las fases del ciclo de vida de los proyectos interactúan
entre sí.
.
Dependiendo
de cómo progresan las diferentes fases del ciclo de vida de un proyecto (desde
la iniciación hasta el cierre) y cómo interactúan entre sí, podrían
identificarse al menos cuatro modelos principales de ejecución:
1. Ejecución Secuencial
(predictiva): cascada de un solo paso o modelo tradicional.
2. Ingeniería Concurrente
(predictiva, previsible y superpuesta).
3. Desarrollo Ajustado o “Lean”
(predictivo, agregando valor).
4. Desarrollo Agil (iterativo, incremental, adaptable): Scrum, XP, Kanban, otros.
Adicionalmente, se tienen los modelos Híbridos, conformados por combinaciones de los modelos
principales, aprovechando las ventajas de cada modelo. A saber:
Modelos Híbridos más comunes:
1. Secuencial + Concurrente (Ejecución con Solapamiento Optimizado).
2. Ajustado + Agil.
3. Secuencial + Ágil.
Si consideramos que las organizaciones con múltiples proyectos abordaran cada tipo de proyecto con el modelo de ejecución más apropiado (secuencial, concurrente, ajustado o ágil), se sugiere que las organizaciones coexistan estructuralmente con diferentes esquemas de ejecución. Por lo tanto, sería necesario identificar qué modelo se aplica mejor a un proyecto y cliente específico y también sería necesario conocer los fundamentos de cada modelo, sus fortalezas y debilidades.
Como referencia y soporte inicial en la selección del modelo de ejecución más adecuado para un proyecto dado, a continuación se describen brevemente cada uno de estos modelos de ejecución, con sus ventajas y desventajas, además se muestran tres cuadros comparativos de los mismos.
principales, aprovechando las ventajas de cada modelo. A saber:
Modelos Híbridos más comunes:
1. Secuencial + Concurrente (Ejecución con Solapamiento Optimizado).
2. Ajustado + Agil.
3. Secuencial + Ágil.
Si consideramos que las organizaciones con múltiples proyectos abordaran cada tipo de proyecto con el modelo de ejecución más apropiado (secuencial, concurrente, ajustado o ágil), se sugiere que las organizaciones coexistan estructuralmente con diferentes esquemas de ejecución. Por lo tanto, sería necesario identificar qué modelo se aplica mejor a un proyecto y cliente específico y también sería necesario conocer los fundamentos de cada modelo, sus fortalezas y debilidades.
Como referencia y soporte inicial en la selección del modelo de ejecución más adecuado para un proyecto dado, a continuación se describen brevemente cada uno de estos modelos de ejecución, con sus ventajas y desventajas, además se muestran tres cuadros comparativos de los mismos.
El modelo de ejecución
secuencial (desarrollo de cascada o ejecución tradicional) es un proceso de
diseño no iterativo en el cual el progreso está fluyendo de manera constante
hacia abajo (como una cascada) durante el ciclo de vida del proyecto
(concepción, iniciación, análisis, diseño, construcción, pruebas, producción /
implementación y mantenimiento), la secuencia de las tareas conducen a una
entrega final y el trabajo se realiza en ese orden. Una tarea debe ser
completada antes de que comience la siguiente, en una secuencia conectada de
elementos que se suman a la entrega global. Las fases no se superponen, se
procesan y completan uno a la vez.
Ventajas:
• El modelo es simple y fácil de usar.
• Cada paso es planificado y establecido en la secuencia apropiada.
• Es un método ideal para proyectos que resultan en objetos físicos (edificios, computadoras).
• Los planes del proyecto pueden ser fácilmente replicados para uso futuro.
• Como la metodología es bastante rígida, es fácil de manejar porque cada fase consiste en un proceso de revisión y entregas específicas.
• Las metodologías de desarrollo de cascadas son buenas para proyectos pequeños que contienen requisitos claros.
• En este método los clientes saben qué esperar. Ellos tendrán una idea del costo, tamaño y cronograma de sus proyectos.
• Si una empresa tiene rotación de personal, la documentación sólida permite un impacto mínimo en el proyecto.
• El modelo es simple y fácil de usar.
• Cada paso es planificado y establecido en la secuencia apropiada.
• Es un método ideal para proyectos que resultan en objetos físicos (edificios, computadoras).
• Los planes del proyecto pueden ser fácilmente replicados para uso futuro.
• Como la metodología es bastante rígida, es fácil de manejar porque cada fase consiste en un proceso de revisión y entregas específicas.
• Las metodologías de desarrollo de cascadas son buenas para proyectos pequeños que contienen requisitos claros.
• En este método los clientes saben qué esperar. Ellos tendrán una idea del costo, tamaño y cronograma de sus proyectos.
• Si una empresa tiene rotación de personal, la documentación sólida permite un impacto mínimo en el proyecto.
Desventajas:
• Si bien este puede ser el método más sencillo de implementar inicialmente, cualquier cambio en las necesidades o prioridades de los clientes interrumpirá la secuencia de tareas, complicando su ejecución.
• Los diseñadores a menudo no son capaces de prever los problemas que surgen de la implementación de sus diseños.
• Los proyectos reales rara vez siguen el flujo secuencial y las iteraciones en este modelo se manejan indirectamente. Estos cambios pueden causar confusión a medida que avanza el proyecto.
• A menudo es difícil obtener los requisitos del cliente explícitamente. Por lo tanto, las especificaciones no pueden congelarse.
• Los cambios en los requisitos no se pueden incorporar fácilmente y a menudo hay procedimientos de control de cambios laboriosos que se deben seguir cuando esto sucede.
• Incluso un pequeño cambio en cualquier etapa anterior puede causar grandes problemas en las fases posteriores, ya que todas las fases dependen una de la otra.
• Volver a trabajar en una fase puede ser un asunto costoso.
• Si bien este puede ser el método más sencillo de implementar inicialmente, cualquier cambio en las necesidades o prioridades de los clientes interrumpirá la secuencia de tareas, complicando su ejecución.
• Los diseñadores a menudo no son capaces de prever los problemas que surgen de la implementación de sus diseños.
• Los proyectos reales rara vez siguen el flujo secuencial y las iteraciones en este modelo se manejan indirectamente. Estos cambios pueden causar confusión a medida que avanza el proyecto.
• A menudo es difícil obtener los requisitos del cliente explícitamente. Por lo tanto, las especificaciones no pueden congelarse.
• Los cambios en los requisitos no se pueden incorporar fácilmente y a menudo hay procedimientos de control de cambios laboriosos que se deben seguir cuando esto sucede.
• Incluso un pequeño cambio en cualquier etapa anterior puede causar grandes problemas en las fases posteriores, ya que todas las fases dependen una de la otra.
• Volver a trabajar en una fase puede ser un asunto costoso.
El enfoque de Ingeniería Concurrente viene principalmente de la
industria aeroespacial y su premisa básica gira en torno a dos conceptos. El
primero es la idea de que todos los elementos del ciclo de vida del proyecto
deben ser considerados en las primeras fases del diseño, junto con el contacto
temprano con los proveedores. Es decir, manejar por adelantado en las etapas
tempranas del proyecto las preocupaciones posteriores. El segundo concepto es
que las actividades de diseño precedentes deberían estar todas ocurriendo al
mismo tiempo, es decir, simultáneamente. La idea es que la naturaleza
concurrente de estos procesos aumenta significativamente la productividad y la
calidad del producto.
Biren Prasad, en su notable trabajo "Fundamentos de la Ingeniería
Concurrente, Volumen I: Organización Integrada de Productos y Procesos",
describe, entre otros, los siguientes principios fundamentales de la ingeniería
concurrente:
1.
Descubrir
Temprano los Problemas.
2.
Toma
de decisiones temprana.
3.
Estructuración
del trabajo.
4.
Afinidad
de trabajo en equipo.
5.
Aprovechamiento
del conocimiento.
6.
Entendimiento
común.
Ventajas:
• Desarrollo más rápido de productos.
• Maximizar la calidad del producto, gastando más tiempo y dinero inicialmente en el ciclo de diseño y asegurando que la selección del concepto está optimizada.
• Productividad incrementada.
• Toma de decisiones en colaboración.
• Trabajo en equipo, el grupo de trabajo opera junto para un producto común.
• El intercambio de información.
• Reduce Costos (Largo Plazo).
• Reduce el tiempo de desarrollo.
• Minimiza la reelaboración del diseño.
• Desarrollo más rápido de productos.
• Maximizar la calidad del producto, gastando más tiempo y dinero inicialmente en el ciclo de diseño y asegurando que la selección del concepto está optimizada.
• Productividad incrementada.
• Toma de decisiones en colaboración.
• Trabajo en equipo, el grupo de trabajo opera junto para un producto común.
• El intercambio de información.
• Reduce Costos (Largo Plazo).
• Reduce el tiempo de desarrollo.
• Minimiza la reelaboración del diseño.
Desventajas:
• Gran inversión inicial.
• Gran inversión inicial.
• La decisión de comenzar los
componentes subsiguientes sin la información requerida previa trae riesgos
potenciales de cambios en el proyecto y en consecuencia retrabajo.
• La mala planificación y la falta de prudencia
pueden conducir a decisiones deficientes basadas en supuestos erróneos, todo lo
cual puede tener impactos negativos en la ejecución del proyecto, lo que
redunda en reelaboraciones y demoras y, en última instancia, en un aumento de
los costos.
• Dependencia de la comunicación eficiente. Una mala comunicación conlleva al desastre.
• Dependencia de la comunicación eficiente. Una mala comunicación conlleva al desastre.
El enfoque de desarrollo ajustado (lean) viene
de la industria automotriz japonesa y esencialmente se centra en hacer lo que
añade valor desde la perspectiva del cliente y la reducción de los desechos. Es
decir, es el proceso continuo para incrementar la cantidad de ingeniería con
valor agregado producida por tiempo y dinero invertido.
La ejecución Ajustada se basa en:
• Enfocarse en el propósito final.
• Determinar el flujo de trabajo.
• Eliminar los desechos o las fuentes de los mismos.
• Probar el proyecto.
• Empoderar al equipo.
Principios del desarrollo Ajustado:
• Enfocarse en el propósito final.
• Determinar el flujo de trabajo.
• Eliminar los desechos o las fuentes de los mismos.
• Probar el proyecto.
• Empoderar al equipo.
Principios del desarrollo Ajustado:
1.
Identificar el valor.
2. Asignar
el flujo de valor.
3. Crear el
flujo.
4. Establecer
la tracción (pull).
5.
Buscar la perfección
Ventajas:
• Aumenta la productividad y la eficiencia de la organización.
• Evita el desperdicio de movimiento.
• Elimina la producción innecesaria.
• Reducción de tiempo de ingeniería
• Ofrecer mejoras a un costo económico.
• Evita el desperdicio de movimiento.
• Elimina la producción innecesaria.
• Reducción de tiempo de ingeniería
• Ofrecer mejoras a un costo económico.
Desventajas:
• La introducción de los principios del diseño ajustado en la fase de diseño puede ser complicada y larga.
• Diagnosticar e identificar la fuente del desperdicio en el proceso y sus causas por lo general toman largos períodos de tiempo y esfuerzo.
• La introducción de los principios del diseño ajustado en la fase de diseño puede ser complicada y larga.
• Diagnosticar e identificar la fuente del desperdicio en el proceso y sus causas por lo general toman largos períodos de tiempo y esfuerzo.
El enfoque ágil viene del ambiente de desarrollo de software y promueve
un modelo de entrega incremental que rechaza cualquier previsibilidad y
planificación a largo plazo.
En la gestión de proyectos bajo enfoque Agil, el cliente es la prioridad
número uno y por lo tanto, todo el proceso iterativo se organiza y gestiona a
su alrededor. Este enfoque requiere que un equipo pequeño y altamente
colaborativo esté involucrado en el ciclo de vida del desarrollo del producto y
que colaboren en cambios de producto, mejoras y características adicionales
durante sesiones cortas. El "cambio" se considera la fuerza impulsora
de la colaboración del equipo y es así que se debe incorporar en el proceso
ágil para permitir que el equipo explore las oportunidades de mejora y trabaje
en adaptar el producto al propósito del negocio.
La gestión de proyectos Ágil promueve un proceso no determinista en el
que puede utilizar iteraciones regulares para alinear el producto con las
necesidades del cliente. Por el contrario, la gestión de proyectos
tradicionales no dice nada sobre la calidad de su producto hasta que el equipo
de desarrollo entra en la fase de prueba, que suele estar programada para el
final del proyecto.
Agil significa:
1. Individuos e interacciones en
lugar de procesos y herramientas.
2. Software de trabajo en lugar de documentación completa.
3. Colaboración del cliente en lugar de negociación del contrato.
4. Responder al cambio en lugar de seguir un plan.
2. Software de trabajo en lugar de documentación completa.
3. Colaboración del cliente en lugar de negociación del contrato.
4. Responder al cambio en lugar de seguir un plan.
Ventajas:
• Mayor satisfacción del cliente.
• Existe una colaboración más estrecha entre los desarrolladores y el negocio.
• Los cambios en los requisitos pueden ser incorporados en cualquier punto del proceso, incluso tarde en el desarrollo. Da la oportunidad para la mejora continua para los sistemas vivos.
• Productividad incrementada.
• Reducción del riesgo.
• Retroalimentación del cliente.
• Visibilidad y responsabilidad.
• Mayor calidad.
Desventajas:
• Puede ser muy exigente en el tiempo del diseñador.
• La integración al equipo de trabajo de nuevos ejecutores resulta difícil.
• Los costos pueden aumentar ya que las prueba se requieren todo el tiempo en lugar de al final
• Agil puede ser intenso para el equipo.
• Este método resulta deficiente en caso de que no sea lo suficientemente buena la retroalimentación del cliente.
• Las metodologías ágiles son a menudo más difíciles de entender que las lineales, secuenciales, al menos inicialmente.
• Debido al énfasis en el software de trabajo, puede haber una percepción de que la documentación a veces puede ser descuidada. El foco debe estar en la documentación apropiada a la audiencia que la necesita pero, si no se aplica bien, esto no es siempre el caso.
• Cuando se implementa mal Ágil puede introducir ineficiencias adicionales en organizaciones grandes o puede estar trabajando contra procesos organizativos de larga data.
• Se requiere una participación activa del usuario y una estrecha colaboración durante todo el ciclo de desarrollo.
• Todo el equipo debe trabajar en el mismo lugar.
• La flexibilidad puede conducir a malos comportamientos.
• Falta de previsibilidad
• Riesgo de fluencia del alcance.
• Mayor satisfacción del cliente.
• Existe una colaboración más estrecha entre los desarrolladores y el negocio.
• Los cambios en los requisitos pueden ser incorporados en cualquier punto del proceso, incluso tarde en el desarrollo. Da la oportunidad para la mejora continua para los sistemas vivos.
• Productividad incrementada.
• Reducción del riesgo.
• Retroalimentación del cliente.
• Visibilidad y responsabilidad.
• Mayor calidad.
Desventajas:
• Puede ser muy exigente en el tiempo del diseñador.
• La integración al equipo de trabajo de nuevos ejecutores resulta difícil.
• Los costos pueden aumentar ya que las prueba se requieren todo el tiempo en lugar de al final
• Agil puede ser intenso para el equipo.
• Este método resulta deficiente en caso de que no sea lo suficientemente buena la retroalimentación del cliente.
• Las metodologías ágiles son a menudo más difíciles de entender que las lineales, secuenciales, al menos inicialmente.
• Debido al énfasis en el software de trabajo, puede haber una percepción de que la documentación a veces puede ser descuidada. El foco debe estar en la documentación apropiada a la audiencia que la necesita pero, si no se aplica bien, esto no es siempre el caso.
• Cuando se implementa mal Ágil puede introducir ineficiencias adicionales en organizaciones grandes o puede estar trabajando contra procesos organizativos de larga data.
• Se requiere una participación activa del usuario y una estrecha colaboración durante todo el ciclo de desarrollo.
• Todo el equipo debe trabajar en el mismo lugar.
• La flexibilidad puede conducir a malos comportamientos.
• Falta de previsibilidad
• Riesgo de fluencia del alcance.
Tablas Comparativas:
Tabla 1. Modelos de ejecución versus algunas
limitaciones clave de proyectos
Limitaciones
clave de proyectos
|
Secuencial
|
Concurrente
|
Ajustado
|
Agil
|
Cumplimiento con la fecha fin
|
Media
|
Alta
|
Alta-Media
|
Baja
|
Cumplimiento con el presupuesto
|
Media
|
Alta-Media
|
Alta
|
Baja
|
Cumplimiento con calidad
|
Buena
|
Excelente
|
Buena
|
Excelente
|
Cumplimiento con el alcance.
|
Excelente
|
Buena
|
Buena
|
Buena, pero con riesgo de fluencia del alcance
|
Requerimiento de grupo de trabajo experimentado
|
Bajo
|
Alto
|
Alto-Media
|
Alto
|
Retroalimentacion del cliente o de las partes
interesadas.
|
Baja
|
Baja
|
Baja
|
Alta
|
Participacion
del suplidor
|
Baja
|
Alta
|
Baja
|
Alta
|
Nivel
de comunicacion requerido
|
Baja
|
Alta
|
Medio
|
Alta
|
Nivel
del Riesgo
|
Bajo
|
Alto
|
Medio
|
Baja
|
Tabla 2. Modelos de ejecución versus
algunas características clave del proyecto.
Características
clave del proyecto
|
Secuencial
|
Concurrente
|
Ajustado
|
Agil
|
Planning
|
Detallado
|
Detallado
|
Detallado
|
Desarrollado
por iteracion
|
Descripcion
del alcance
|
Detallado
|
Detallado
|
Detallado
|
Minimo
|
Frecuencia de actualizacion del Plan
|
Al final de la fase
|
Al final de la fase
|
Al final de la fase
|
Periodos cortos (ej. Semanal)
|
Gestion
de los cambios
|
Baja
|
Baja
|
Baja
|
Alta
|
Agrega valor
|
Baja
|
Baja
|
Alta
|
Alta
|
Tabla 3. Algunos tipos de
proyectos y modelos de ejecución recomendados
Tipos de proyectos
|
Secuencial
|
Concurrente
|
Ajustado
|
Agil
|
Proyecto
pequeño con requerimientos claros.
|
x
|
|||
Proyecto que
resulta en objetos físicos.
|
x
|
|||
Proyecto con
alcance fijo y contrato a precio fijo
|
x
|
|||
Proyecto restringido a tiempo
|
x
|
|||
Proyecto restringido en
presupuesto.
|
x
|
|||
Proyecto de
innovación de programas.
|
x
|
|||
Proyecto de largo tiempo
|
x
|
|||
Proyecto de lndustria aeroespacial.
|
x
|
|||
Proyectos de desarrollo IT
|
x
|
|||
Proyectos que
requieren adquisición anticipada
|
x
|
|||
Proyectos muy
restringidos en tiempo y presupuesto
|
x
|
|||
Proyectos con
alcance no bien definido
|
x
|