Skip to main content

Hoy en día, los líderes de proyecto no se apegan a una sola metodología de gestión de proyectos. En cambio, se vuelven informan sobre varias metodologías y combinan sus características dependiendo del proyecto en turno.

Mi objetivo hoy es ayudarte a identificar estas metodologías y en particular aspectos de ellas que puedas llevar a tu trabajo para entregar proyectos de manera efectiva en agencias digitales.

En este artículo encontrarás una reseña sobre qué son las metodologías de administración de proyectos, descripciones de las más metodologías más populares, ejemplos de la vida real y pasos que debes seguir para escoger tú metodología.

Sigue leyendo o elige una de estas opciones para ir directo a una sección específica.

Qué es una metodología de proyecto?

Vamos a ver si podemos definir qué es una metodología de gestión de proyectos. De acuerdo al Project Management Institute, una metodología es

Un sistema de prácticas, técnicas, procedimientos y reglas utilizada por aquellos que trabajan en una disciplina

Sin embargo! Ahora necesitamos agregarle algo particular a nuestra profesión y para ello sugiero que agreguemos marcos de trabajo.

Como PM’s necesitamos entregar proyectos que incluyan diferentes principios, procesos, marcos de trabajo y estándares que proporcionen estructura a la manera en la que desarrollamos proyectos.

Tipos de metodologías de gestión de proyectos

Algunas metodologías de gestión de proyectos simplemente definen principios, como Agile. Otras definen un marco de metodología completa o ‘full-stack’, con temas, principios, procesos y pasos para elaborar un proyecto, como Prince2. Algunas otras, son una lista extensa de estándares con algún proceso, como PMBOK o XP de PMI y algunas más son muy ligeras, y simplemente definen el proceso, como Scrum.

“En lugar de debatir qué es una metodología y qué no, yo uso una visión más generalizada de las metodologías de gestión de proyectos que simplemente significa los marcos de mejores métodos que combinamos para desarrollar proyectos.”

En otras palabras, no creo que una metodología necesite ser un sistema completo con procesos, marcos y demás para ser considerado una metodología.

Me gusta este enfoque porque como gestores de proyectos utilizamos una combinación de principios, temas y procesos adaptados para nuestros clientes y proyectos.

Y aclaremos una cosa antes de comenzar, si bien hay muchas metodologías, no existe una metodología de proyecto que sea la 'correcta'. No existe una metodología única que se adapte a todo y siempre deba ser utilizada.

Al final, la mejor metodología es la que tiene sentido y es más adecuada para tú proyecto, equipo y cliente. 

Ahora echemos un vistazo a algunas de las metodologías de administración de proyectos más populares y entendamos algunas de las valiosas lecciones aprendidas para entregar proyectos en el mundo digital.

Cómo escoger una metodología de gestión de proyectos

Escoger una metodología es importante porque va a definir cómo trabajamos, la estructura y nos guía rumbo a un cierre exitoso.

Como ya sabes, existen múltiples metodologías por lo que es importante dedicarle un rato a decidir cuál es la adecuada para tú contexto.

Te dejo algunos pasos que puedes seguir.

  1. Considera los factores del proyecto por su complejidad.

Esto incluye el proyecto mismo, asi como el cliente, los recursos disponibles y las limitantes del proyecto. Estos límites incluyen propensión al cambio y riesgo, tiempos de entrega, herramientas y recursos. Enlista estos elementos de menos complejo a más complejo.

  1. Determina la flexibilidad de tu ambiente de trabajo.

Si trabajas en un ambiente dinámico donde hay hambre por evolución y cambio, una metodología Ágil te será útil. Por el contrario, si tabajas en un ambiente rígido que requiere requerimientos fijos, tiempos y presupuestos definidos, te beneficiará más usar una metodología de Cascada.

En ambos casos, es bueno que te cuestiones si tu organización se podría beneficiar de una metodología híbrida o permanecer tal y como está. Escoger una nueva metodología puede empujar la organización en la dirección que quieres pero tiene que ser posible usarla con el estado actual del equipo.

  1. Piensa en qué proporciona más valor agregado.

Pregúntate qué le trae más valor al cliente, las partes interesadas o el usuario. Haz una lista de sus necesidades y adopta una manera de trabajar que mejor satisfaga esas necesidades.

Por ejemplo, si tus clientes te piden cosas constantemente y esperan que les estés actualizando a cada rato, una metodología iterativa con ciclos cortos les va a gustar más. Usar esta metodología te va a ayudar a dar valor agregado y mantener una buena relación con el cliente.

  1. Apóyate en los objetivos de tu organización.

Usa los objetivos de tu compañía o los objetivos de tu proyecto para escoger la metodología que mejor te acerquen a cumplir los objetivos estratégicos con el menor número de riesgos posibles.

  1. Haz una lista de los valores organizacionales y de equipo.

Por último y lo más importante es hacer una introspección. Al final, la metodología que escojas va a ser utilizada por humanos. Gente con ciertos hábitos, opiniones y valores. En lugar de escoger el marco de trabajo que está de moda y forzar a que tu equipo se adapte, escoge una metodología que se ajuste a su manera de interactuar y pensar, en la medida de lo posible.

Cuál es la mejor metodología para agencias digitales?

En corto? Depende.

Creo que en este punto estamos claros que depende del cliente, tu organización, equipo y demás. No hay una metodología correcta y necesitas hacer un análisis antes de responder esta pregunta.

Sin embargo, tenemos un artículo que habla sobre el debate entre Ágil y Cascada. Para no hacerte leer todo eso, aquí te resumo algunos de los puntos importantes.

Los pros y contras de usar Cascada en agencias digitales

Generalmente en una agencia, poner tu cabeza fuera de la trinchera y sugerir que un modelo de Cascada podría ser un buen enfoque para un proyecto es equivalente a pedir que te disparen. Cascada es algo que ningún cliente o equipo quiere escuchar: todos queremos que se nos vea como vanguardistas, y este método definitivamente no demuestra eso.

No solo no es cool, sino que además es un desafío porque requiere una planificación inicial exhaustiva antes de iniciar cualquier trabajo que resulte valioso. La planificación es a veces necesaria porque los clientes necesitan aprobar el costo, cronograma y alcance, pero generalmente el cliente no quiere pagar por esa planificación. Incluso en casos en que agencias han transicionado de un método de Cascada a uno Ágil, ¿qué sucede si tu planeación de un proyecto no está a la altura?

La verdad es que en el mundo digital luchamos regularmente con estimaciones precisas. Normalmente trabajamos en proyectos vagos con nuevas tecnologías. Entonces, a menos que estés realizando el mismo tipo  de proyectos una y otra vez, tan pronto como comiences tu proyecto, tu plan probablemente esta desactualizado. Es por ello que mientras que a los clientes les gustan los resultados, presupuestos y cronogramas predecibles, un enfoque en cascada es inherentemente inflexible.

Entonces, ¿qué pasa si usamos alguna variación de Ágil?

Sign up to get weekly insights, tips, and other helpful content from digital project management experts.

Sign up to get weekly insights, tips, and other helpful content from digital project management experts.

  • This field is hidden when viewing the form
  • By submitting you agree to receive occasional emails and acknowledge our Privacy Policy. You can unsubscribe at any time. Protected by reCAPTCHA; Google Privacy Policy and Terms of Service apply.
  • Este campo es un campo de validación y debe quedar sin cambios.

Los pros y contras de usar Ágil en agencias digitales

Entre las agencias y los clientes, tiende a haber una comprensión bastante fluida de Agile. 

Agile es alabado en gran medida por “no ser Cascada” y se mal entiende que significa hacer más, con menos, más rápido y más barato que nunca. ¿Quién no querría todo eso?

Los clientes tienden a amar la idea de Ágil debido a su aparente flexibilidad para hacer pivotar un proyecto y ofrecerles más oportunidades para proporcionar retroalimentación o cambiar de opinión continuamente a lo largo del proyecto.

Regularmente piensan que significa que harán más trabajo por menos o que en realidad nunca tienen que tomar una decisión final porque pueden cambiar de opinión sobre lo que quieren hasta el último minuto.

Eso es cierto de alguna manera, pero eso no completamente. Ágil podrá ser mejor pero viene con sus costos y complejidad.

Aunque pueden cambiar de parecer hasta el último minuto, esos cambios y esa flexibilidad implican tiempo y dinero.

Otro reto es que para ser exitosos y verdaderamente ágiles, los clientes deben estar disponibles y tener la capacidad de tomar decisiones (lo cual es raro en organizaciones orientadas en jerarquías y juntas directivas). El nivel de involucramiento del cliente requiere proporcionar constante retroalimentación y priorización sobre la marcha para mantener el proyecto en movimiento. Tú y yo sabemos que eso es complicado.

Datos fundamentales sobre la mejor metodología para una agencia

Fundamentalmente, las agencias quieren que se les pague por su trabajo y los clientes quieren que las agencias hagan su mejor trabajo, bien y a la primera. Tiene que existir un punto medio.

Al final del día, mucho tiene que ver con confianza. Saber si el cliente confía en que la agencia entregará un proyecto exitoso y de valor y están dispuestos a pagar por las fallas a lo largo del camino.

La magia sucede en aquellas relaciones con clientes en las que existe confianza y ganas de experimentar. Requiere madurez por parte del cliente pero recuerda que tú también juegas un papel importante.

9 metodologías de administración de proyectos

1. Ágil - Colaboración para tener entregables funcionales en iteraciones.

Comencemos con la palabra de moda, Ágil. La verdad es que Ágil no es en realidad una metodología de un proyecto, sino un conjunto de principios para desarrollar software. Los principios se describen en el manifiesto ágil que describe cuatro valores: 

  • Individuos e interacciones por encima de procesos y herramientas 
  • Software de trabajo por encima de documentación completa 
  • Colaboración del cliente por encima de negociación de contratos
  • Responder a los cambios por encima de  seguir un plan

Ser ágil es más una filosofía y un conjunto de valores a seguir que un proceso que hay aplicas directamente a un proyecto.

Los proyectos ágiles se caracterizan por una serie de tareas que se conciben, ejecutan y adaptan dependiendo de la situación, en lugar de un proceso pre-planificado. Ser ágil ayuda a los equipos a responder a imprevistos mediante procesos de trabajo incrementales e iterativos.

De la misma manera en que un buen cocinero prueba la comida a medida que la cocina y agrega ingredientes faltantes sobre la marcha, un proceso ágil de gestión de proyectos requiere que los equipos de proyectos pasen por un proceso de planificación, ejecución y evaluación a medida que avanzan.

A diferencia de otros métodos de administración de proyectos que generalmente asumen que las cosas que afectan al proyecto son predecibles, Ágil enfatiza la adaptabilidad a situaciones cambiantes, la comunicación adecuada y continua entre el equipo del proyecto y con el cliente. Las metodologías ágiles son excelentes para usar en entornos dinámicos donde existe la posibilidad de cambiar requisitos, como el desarrollo de juegos y software.

Como conjunto de principios, Agile es el paraguas que abarca diferentes variantes de Ágil, como Scrum, Extreme Programming (XP), Kanban y Scrumban. En la administración de proyectos ágiles, puedes usar cualquiera de estas variantes.

Más sobre Agile | Herramientas ágiles | Aprendiendo Agile: Entendiendo las metodologías Scrum, XP, Lean y Kanban

2. Scrum: permitiendo que un equipo pequeño, multifuncional y autogestionado entregue rápido

Scrum es una metodología de administración de proyectos que propone principios y procesos para mejorar tus entregas. Dentro del desarrollo de software, Scrum es uno de las estructuras más populares y sencillas para poner en práctica los principios ágiles que revisamos en la sección anterior.

El objetivo de Scrum es mejorar la comunicación, el trabajo en equipo y la velocidad de desarrollo. Si escuchas a la gente hablar sobre sprints, reuniones scrum, backlogs y gráficos de trabajo pendiente, probablemente estén hablando de Scrum, o alguno de sus derivados.

Scrum es un marco de trabajo para el desarrollo y mantenimiento de productos complejos. Scrum es un enfoque ligero y define lo siguiente.

  • Roles (dueño de producto, Scrum master y equipo de desarrollo)
  • Reuniones llamadas ceremonias Scrum
  • Conjunto de herramientas para guiar incrementos.

Scrum propone usar un equipo pequeño y multifuncional de hasta 9 personas que trabajan en tareas de un backlog (una colección de historias de usuario o requisitos) que han sido definidas y priorizadas por el dueño de producto.

El trabajo se divide en sprints o iteraciones, un ciclo de desarrollo de 2 a 4 semanas, durante el cual se llevan a cabo reuniones scrum diarias donde el equipo reporta sobre el progreso y los obstáculos. Al final de cada sprint, el trabajo se revisa en una reunión de revisión de requisitos donde en conjunto con el dueño del producto se determina si el producto cumple con la definición de completado (DoD - definition of done).

Scrum es facilitado y atendido por el Scrum Master, quien habilita y dirige los scrums, demostraciones y las reuniones de revisión, y la sesión de retrospectiva (scrum retrospective) después de cada sprint. Esto para garantizar que el equipo esté en continua mejora y optimización.

Scrum se diseñó originalmente para el desarrollo de software, por lo que si bien hay artefactos ágiles de scrum que se pueden aprovechar, Scrum no encaja perfectamente en el mundo de las agencias, el cual usualmente es más estratégico y creativo. Incluso en los proyectos web de la agencia, los presupuestos fijos, los plazos y el alcance proporcionan una falta de flexibilidad para un equipo de scrum autogestionado, en un proyecto con un principio y un final definidos.

Esto no quiere decir que no funcione en proyectos de desarrollo: los PM’s de las agencias pueden actuar como facilitadores y los clientes como propietarios de productos en un equipo híbrido. Pero normalmente es más complicado que eso, con presupuestos y alcance fijos que brindan fuertes restricciones. Es por eso que muchas agencias toman algunos de los conceptos de scrum: equipos pequeños, autoorganizados, multifuncionales, presentaciones diarias, demostraciones de progreso y retrospectivas, y los utilizan en algún tipo de enfoque híbrido.

Más sobre Scrum | Herramientas ágiles | Scrum: una introducción breve y ágil.

3. Kanban: mejorando la velocidad y calidad de entrega al aumentar la visibilidad del trabajo en progreso y limitando multitasking.

Kanban es una metodología de gestión de proyectos centrada en los principios Lean y un proceso estricto para aumentar la eficiencia. Es similar en muchos aspectos a Scrum: busca lanzar los proyectos pronto y, a menudo, con un equipo colaborativo y autogestionado. Pero en comparación con Scrum, Kanban es un cambio más evolutivo, y es un aterrizaje más suave en el mundo ágil, ya que es menos prescriptivo.

Kanban es ligero en procesos, flexible, no tiene roles definidos y simplemente intenta mejorar el rendimiento aumentando el enfoque del equipo en las cosas realmente importantes. Las prácticas principales son visualizar el flujo de trabajo, limitar el trabajo en progreso, medir el tiempo de entrega, hacer que las políticas de proceso sean explícitas y evaluar continuamente las oportunidades de mejora.

El enfoque de Kanban está en que el trabajo que se libere continuamente, más rápido y con mejor calidad. Es ideal para entornos operativos o de mantenimiento donde las prioridades pueden cambiar con frecuencia. Kanban se centra en medir el tiempo de entrega: cuánto tiempo demoras en entregar, después de ser informado.

Con Kanban, los PM’s suelen usar post-its en una ‘pizarra Kanban’ o en una herramienta en línea como Trello, para representar el flujo de trabajo del equipo con categorías como “Tareas pendientes”, “En proceso” y “Completadas”.

Esto muestra visualmente lo que quieres hacer, la secuencia de tareas y limita el trabajo en progreso (WIP) para que el flujo de trabajo mejore a medida que mides y optimizas el tiempo promedio para completar tareas.

Kanban está bien adaptado para trabajos que requieren un rendimiento constante, como producción o soporte y mantenimiento. Dentro del mundo de las agencias, también puede ser una herramienta útil, ya que es más complaciente con los cambios, y a los clientes les gusta cambiar de opinión constantemente. Si Scrum te parece un enfoque demasiado rígido para el desarrollo de un proyecto, pero quieres ser ágil’, Kanban es una alternativa más simple.

Más sobre Kanban | Kanban vs Scrum | Herramientas de Kanban | Kanban: cambio evolutivo exitoso para su tecnología empresarial

4. Scrumban: limitando el trabajo en progreso como en Kanban con una reunión diaria de Scrum

Scrumban es una metodología híbrida relativamente nueva que combina un enfoque mixto de scrum y Kanban para la gerencia de proyectos. Toma la flexibilidad de Kanban y agrega parte de la estructura de scrum para crear una nueva forma de administrar proyectos.

En lugar de trabajar en iteraciones con tiempo limitado y potencialmente restrictivas, Scrumban utiliza un principio de planificación bajo demanda para completar el backlog y las tareas son asignadas por el equipo que las realiza conforme les vaya acomodando, como en Kanban. Esto significa que el trabajo en progreso es limitado y el equipo de desarrollo se mantiene enfocado en la tarea en cuestión en lugar de preocuparse por la reunión de revisión y por lo que el equipo se comprometió a entregar en la iteración.

Sin embargo, no todo es Kanban: Scrumban conserva el “scrum diario” con revisiones y retrospectivas para mejorar el proceso que solo se usan cuando es necesario. Además, sin la restricción de las iteraciones, la planificación se realiza según sea necesario en lugar de alrededor de una iteración, lo que ahorra tiempo.

Scrumban realmente sólo agrega algo de flexibilidad a Scrum eliminando las iteraciones y permitiendo un enfoque adaptado a la planificación. O podrías verlo también como añadir una estructura muy necesaria a Kanban con reuniones que pueden ayudar con la colaboración y la optimización del proceso.

Scrumban puede ser bueno para el desarrollo de proyectos o productos donde hay una visión poco clara, donde hay requisitos en evolución o no hay una hoja de ruta clara y si el proceso necesita incluir trabajo de soporte y mantenimiento en el proceso.

Más sobre Scrumban | Herramientas Scrumban | La evolución de Scrumban [R]: sacar el máximo provecho de Agile, Scrum y Lean Kanban

5. Lean: optimizando flujos de trabajo y eliminando desperdicio para entregar más con menos

Lean es una metodología de gestión de proyectos centrada en el tema de la eficiencia. A veces conocido como “el padrino del método Ágil”, Lean se trata de hacer más con menos. Comienza por identificar valor agregado y luego lo maximiza a través de la mejora continua al optimizar el flujo de valor y eliminar desperdicio.

Lean es un conjunto de principios, más que una metodología de proyecto que dicta procesos y cosas que hacer. Sugiere que puedes hacer más con menos abordando las tres disfunciones que generan desperdicios; Muda, Mura y Muri, también conocidos como las 3Ms. Todas palabras japonesas.

Muda se trata de eliminar desperdicios - Eliminando procesos o cualquier cosa que, en última instancia, no agregue valor al cliente. En el mundo digital, esto podría ser eliminar las rondas de revisiones.

Mura se trata de eliminar variaciones: eliminar la sobrecarga que crean las variaciones en el proceso estándar. Para nosotros, esto podría significar la estandarización de informes y procesos de aprobación.

Muri trata de eliminar la sobrecarga: la capacidad óptima es trabajar al 60-70%; Más que eso, y todo se alenta. Podríamos aplicar esto para minimizar la cantidad de proyectos que intentamos ejecutar a través de la agencia.

Lean se enfoca en cambiar la forma en que operamos para concentrarnos en la entrega de valor. Se trata de cambiar el enfoque desde la optimización de tecnologías separadas, activos y departamentos verticales hasta la optimización del flujo de proyectos a través de cadenas de valor que fluyen horizontalmente a través de tecnologías, activos y departamentos para los clientes.

Lean puede ser una mentalidad útil a adoptar cuando revises el proceso de entrega de tu proyecto: piensa cómo puedes volver a desviar el proceso de tu proyecto a lo esencial que ofrece valor y eliminar las cosas que son solo relleno, o la forma en que siempre lo has hecho – y estarás pensando en Lean.

Más sobre Lean | Ejecutar Lean: Iterar de un Plan A a un Plan Que Funcione

6. Programación eXtrema: Desarrollando de manera robusta para garantizar calidad

Programación Extrema (XP, por sus siglas en inglés) es una metodología de administración de proyectos de desarrollo de software que define valores y procesos para mejorar la calidad del software y garantizar la capacidad de respuesta a la evolución de requerimientos del cliente. Los valores o principios son muy similares a Scrum, entorno a simplicidad, comunicación, retroalimentación, respeto y audacia.

Donde realmente se desvía de Scrum es en la definición de reglas o procesos prescriptivos. Algunos de estos son similares a Scrum, pero existen reglas en torno a las prácticas técnicas relacionadas con el diseño, programación y pruebas que lo hacen específico para proyectos de desarrollo. Estas reglas incluyen hacer obligatorio el incluir historias de usuario, desarrollo impulsado por pruebas (TDD), programación en pares e integración continua, entre muchos otros.

Más sobre programación extrema | Herramientas de programación extremas | Guía de bolsillo de programación extrema

7. Cascada:  planificación completa de proyectos que luego son ejecutados en fases

Waterfall, a menudo denominada “Ciclo de Vida del Desarrollo de Software” (SDLC, por sus siglas en inglés) es una metodología de gestión de proyectos con un enfoque muy simple que valora la planificación sólida y hacer las cosas bien y a la primera, en lugar del enfoque ágil de la entrega incremental e iterativa. Es fácil de entender, pues simplemente tienes que hacer un buen plan y ejecutarlo.

El administrador del proyecto tiende a estar a cargo, y el trabajo se planifica ampliamente por adelantado y luego se ejecuta, en estricta secuencia, cumpliendo con los requisitos, para entregar el proyecto en un único y normalmente largo ciclo.

Los requisitos se definen en su totalidad al principio, en la parte superior de la cascada, antes de comenzar cualquier trabajo. El trabajo luego cae en cascada, como el agua en una cascada a través de las fases del proyecto. En un modelo de Cascada, cada fase debe completarse antes de que la siguiente pueda comenzar y no haya superposición en las fases. Normalmente, en un enfoque de Cascada, el resultado de una fase actúa como entrada para la siguiente fase de forma secuencial.

Una vez que se aprueba el plan, hay poco margen para adaptarlo, a menos que sea absolutamente necesario, y los cambios generalmente requieren de solicitudes. El proyecto luego fluye a través del proceso desde los requisitos, hasta el diseño, la implementación, las pruebas y el mantenimiento.

Debido al enfoque de ciclo único, en un proyecto de Cascada, hay poco margen para reflejar, revisar y adaptar una vez que haya completado algo. Una vez que estás en la etapa de prueba, es muy difícil regresar y cambiar algo que no estaba bien diseñado en la etapa de concepto. Tampoco hay nada que mostrar al cliente a medida que avanzas por lo que tendrás que armar una fiesta de fin de proyecto o algo extremo y rezar para que al cliente le guste.

El método de Cascada generalmente es visto con cierto desdén dentro de las agencias como un enfoque de gestión de proyectos tradicional, ineficiente y obsoleto. Pero Cascada puede ser un enfoque útil y predecible dependiendo de la naturaleza del proyecto: si los requisitos son fijos, están bien documentados y son claros, la tecnología se entiende y está madura, el proyecto es corto y no se gana ningún valor adicional al “ser ágil”. Un enfoque de Cascada en realidad puede proporcionar un resultado final más predecible para el presupuesto, el calendario y el alcance.

Más sobre este método | Herramientas de gestión de proyectos en Cascada | El administrador de proyectos de TI: cómo gestionar los proyectos en Cascada

8. PRINCE2: gestión de proyectos controlada que no deja nada al azar

PRINCE2 es una metodología completa de gestión de proyectos en cascada que incluye principios, temas y procesos. Fue creada por el gobierno del Reino Unido en 1996 originalmente para proyectos de TI. “PRINCE” significa “Proyectos en entornos controlados”. Es una metodología muy orientada a los procesos, que divide los proyectos en múltiples etapas, cada una con sus propios planes y procesos a seguir. La metodología define entradas y salidas para cada etapa de un proyecto para que nada quede al azar.

El sistema enfatiza la justificación del curso realizado por una empresa, por lo que el primer paso es identificar una necesidad clara para el proyecto, quién es el cliente al que va dirigido, si existen beneficios realistas y una evaluación de costos exhaustiva. Una junta de proyecto es propietaria del proyecto y es responsable de su éxito. Esta junta define las estructuras para el equipo, mientras que el gerente de proyecto supervisa las actividades diarias de nivel inferior. Esta metodología se basa en ocho procesos de alto nivel y brinda a los equipos un mayor control de los recursos y la capacidad de reducir el riesgo de manera efectiva.

Como metodología de proyecto, es increíblemente exhaustiva: es una estructura excelente para ejecutar proyectos empresariales grandes y predecibles. Aclara lo que se entregará, asegura un enfoque en la viabilidad del proyecto, define claramente los roles y responsabilidades, las partes de un proyecto, respalda la gestión por excepción (posiblemente un principio ágil) y de manera similar a PMBOK, proporciona un vocabulario común que podemos aplicar a otras metodologías. Por otro lado, mientras que los principios y los temas son excelentes, el proceso puede hacer que sea laborioso y oneroso para proyectos pequeños.

PRINCE2 está diseñado para proyectos de TI a gran escala, por lo que nunca funcionaría en una agencia como una metodología de gestión de proyectos. Sin embargo, el énfasis en desarrollar un buen modelo comercial con KPI’s y el valor ganado, roles y responsabilidades claras, administrar cambios y riesgos es útil cuando consideramos administrar proyectos para nuestros clientes.

Más sobre PRINCE2 | Herramientas de PRINCE2 | Gestión de proyectos exitosos con PRINCE2

9. PMBOK del PMI: aplicando de estándares universales a la gestión de proyectos en cascada

El PMBOK del PMI no es realmente una metodología. Es un marco de referencia con estándares, convenciones, procesos, mejores prácticas, terminología y guías que son aceptados como estándares en la industria de administración de proyectos. Aún así, el marco de trabajo del PMBOK es considerado como una metodología tradicional.

El PMBOK habla sobre el proceso en 5 fases de un proyecto: inicio, planeación, desarrollo, control y monitoreo y cierre. Contiene muchos procesos y técnicas de administración de proyectos con las cuales evaluar y completar la manera en la que ejecutas tus proyectos o escoges una metodología.

Implementar esta metodología requiere que definas qué procesos vas a usar, quién va a usarlos, cuándo y hasta qué punto. También tienes que considerar tú estructura organizacional, flujos de trabajo y demás para adaptarlo correctamente.

Por lo tanto, el PMBOK es más teórico, una guía de referencia, en la que te puedes certificar y que aún siendo popular en TI, realmente no va bien en el mundo de las agencias. Realmente no puedes ejecutar un proyecto PMI o PMBOK, pero puedes aprovechar los estándares para crear un lenguaje universal y los mejores prácticas alrededor de un proyecto. Al comparar con PRINCE2, considera PMBOK y PRINCE2 de PMI como complementarios entre sí en lugar de dos enfoques de cascada diferentes o separados.

Más sobre PMI | Una guía para el conocimiento de la gestión de proyectos

3 ejemplos de metodologías de proyecto en la vida real

1. El método Kanban en Vanguard

Hay una selección amplia de prácticas Lean, Kanban y Ágil en Vanguard, una de las compañías de manejo de inversiones más grande del mundo. Al día de hoy, llevan más de 15 años con prácticas ágiles, incluyendo 5 años de operaciones de desarrollo.

En un caso de estudio de su modelo de operaciones Lean, podemos leer los beneficios y retos que vivieron 24  de sus equipos ágiles de trabajo, junto con la descripción de cómo la organización usó la información para adaptar su modelo basado en Kanban para ajustarse a sus objetivos y necesidades. Curiosamente, la mayoría de los equipos empezaron con Scrum y eventualmente migraron a Kanban. Muchos de ellos lo hicieron porque se encontraron estancados en Scrum con un embotellamiento tremendo y una inmensa carga de trabajo.

Qué lecciones aprendió Vanguard? Reportan en el estudio que al implementar el enfoque Kanban para planificación de servicios corporativos, pudieron acelerar flujos de trabajo, retroalimentación y aprendizaje. Para ellos esto significa revisiones mensuales de operaciones con todos los equipos, junta de alineación y reabastecimiento con gerentes de nivel medio, juntas Kanban diarias para cada equipo, mejor colaboración entre equipos en paralelo, revisión de riesgos con la PMO y diversas juntas de planeación y revisión de riesgos más.

Encontraron que las juntas mensuales y las de alineación con gerentes fueron las que más impacto tuvieron en la aceleración de flujos de trabajo.

2. El método Ágil en Cisco

La compañía de tecnología multinacional, Cisco se ha ido alejando del método de Cascada en proyectos digitales de TI y cambiando a un enfoque Ágil. 

En un caso de estudio sobre su plataforma de cobros y desarrollo de la aplicación WebEx registraron los efectos de adoptar el marco ágil escalable (SAFe). Los resultados? Una reducción del 40% en defectos mayores y críticos, junto con un incremento del 15% en la eficiencia de eliminación de defectos. Esto a su vez impactó la satisfacción de sus empleados al reducir el número de horas extra que estaban trabajando ya que había menos llamadas y juntas que atender.

3. Programación extrema en un proyecto de desarrollo del gobierno de Estados Unidos.

Este era un proyecto para agregar una nueva funcionalidad al sistema de administración de conocimiento del comando estratégico de USA, llamado SKIWeb. El proyecto involucraba 2 desarrolladores, un líder de desarrollo, un gerente funcional del gobierno y un ingeniero de factores humanos. El caso de estudio de este proyecto nos puede ayudar a entender como todas las prácticas de Programación Extrema (planeación incremental, pequeñas entregas, diseño simple, desarrollo a base de pruebas, etcétera) se traducen en la vida real. Esto porque los participantes registraron cuánto se uso cada práctica durante el proyecto.

Qué lecciones aprendieron? El estudio encontró que la mayoría de la gente involucrada estaba preocupada por la comunicación. Muchos de ellos hablaron sobre la importancia de tener comunicación completa, frecuente y correcta dentro del equipo de desarrollo.

Debido a la rápida evolución que es parte de los proyectos de programación extrema, era importante tener una respuesta rápida a correos electrónicos y obligar a que todos los miembros atendieran las juntas para poder tomar decisiones adecuadas y mantener a todes actualizades con la información más reciente.

Otras metodologías de proyecto

Esta no es, de ningún modo, una lista exhaustiva de metodologías de gestión de proyectos. Existen metodologías como el Método Crystal, en el que los procesos del proyecto reciben una prioridad baja, mientras que se enfatiza en la comunicación del equipo, las habilidades de los miembros del equipo, las personas y la interacción.

Otra metodología es la del Marco Adaptativo, en la que el alcance del proyecto es variable, pero el tiempo y el costo son constantes, lo que hace posible ajustar el alcance del proyecto durante la ejecución para obtener el máximo valor de negocio del proyecto. Otros como PRiSM, Critical Path, PERT y muchos más existen, pero no son tan relevantes para el mundo de la gestión de proyectos en las agencias.

En conclusión

Elegir la metodología de un proyecto más adecuada puede ser complicado. Depende de tantas variables, muchas de las cuales están fuera de nuestro control.

Pero lo que realmente importa es mirar más allá de la “guerra territorial” entre las metodologías de la industria. Las metodologías de gestión de proyectos son solo herramientas para ayudarnos a entregar proyectos. Realmente no vale la pena discutir sobre los detalles de cada una; en lugar de eso, deberíamos centrarnos en el panorama general. Ya sea Kanban, Waterfall o algún otro método, en realidad no importa.

Lo que importa es el compromiso de hacer un trabajo de calidad, que satisfaga las necesidades de los usuarios y ofrezca un gran valor a nuestros clientes.

La mejor metodología de un proyecto es aquella que mejora continua y orgánicamente, se adapta y, a través de una colaboración sólida, aumenta el valor de la producción, por lo que la suma es mucho mayor que las partes.

Es una metodología que sorprende y deleita al cliente al entregar valor con frecuencia y hacerlo bien. Y para hacer esto, debes ser pragmático, en lugar de dogmático acerca de la metodología que utilizas.

¿Qué Opinas?

¿Cómo eliges tu metodología de un proyecto? ¿Hay alguna metodología que prefieras sobre otras? Si es así, ¿por qué? Por favor, compártelo en los comentarios.

Si hablas inglés y quieres recibir información semanal sobre administración de proyectos digitales, reflexiones, atajos y trucos para ser un rockstar, suscríbete a Insider Membership.