PMBOK en proyectos pequeños

0

Lo primero que te aconsejan cuando te vas a preparar para la certificación PMP es “Piensa en proyectos muy, muy grandes cuando vayas a responder las preguntas”, como por ejemplo podemos leer en PMReviews. Incluso llegas a escuchar cosas como que PMBOK está pensado para mega-proyectos, y que es un despilfarro de burocracia cuando se aplica a proyectos pequeños. Por último, encuentras a muchas personas dudado entre aplicar PMBOK o metodologías ágiles, considerando que son mundos diferentes, como en el análisis que hace David Viñuales. Cito de este último:

La diferencia principal entre Scrum y PMBOK es que éste último necesita de una toma de requerimientos previa a la planificación, …

David Viñuales

Creo que esta cita refleja en gran medida esa opinión general a la que me refiero, y con la que estoy en desacuerdo.

PMBOK no es una metodología

Bueno, no me quiero poner purista, pero a veces es inevitable. PMBOK define un marco pero no te dice como tienes que hacer las cosas. Te dice que tienes que generar una serie de documentos y realizar una serie de tareas a lo largo de la gestión de cada fase de tu proyecto, pero no te dice como. Además te recomienda algunas técnicas para conseguirlo, pero no te obliga a ninguna. Como dice Ángel Nájera en Wolf Project:

De hecho, [PMBOK] es un compendio de las experiencias vividas por muchos project managers de todo el mundo en diferentes sectores a la hora de gestionar proyectos.

Ángel Nájera

Esto es importante, porque cuando se comienza a criticar a PMBOK por ser pesado se comienza a comparar con metodologías como SCRUM. Una de esas comparaciones que me ha parecido divertida es la que presenta ITProjectus en la que SCRUM le gusta a los desarrolladores y PMBOK a los gestores.

PMBOK y PMP son conceptos diferentes

PMP es una certificación de que eres un profesional de gestión de proyectos. Las preguntas se basan en su mayoría en PMBOK, pero no es un examen de PMBOK. Por otro lado, el ámbito de esas preguntas no tiene por qué ser reflejo del alcance de PMBOK. En ese sentido el examen de PMP va a los casos complejos, proyectos grandes en los que hay múltiples actores, porque es ahí en donde se puede demostrar tu experiencia y dominio sobre las técnicas de gestión de proyectos. Así, la mayoría de formadores te aconsejan que te plantees responder a las preguntas del examen para PMP como si de mega proyectos se tratase.

El problema está en que mucha gente extrapola esto a PMBOK y no justo. PMBOK puede aplicarse a proyectos pequeños. ¿Pero que gracia tiene preguntar sobre la gestión de riesgos en un proyecto de un mes cuando puedo preguntarte sobre un proyecto de 2 años?

Conclusión: Extrapolar que porque el examen de certificación para PMP esté enfocado a proyectos grandes significa que PMBOK está pensado para proyectos grandes, es un error.

La burocracia de PMBOK

El primer argumento que te dicen para desacreditar a PMBOK en proyectos pequeños es que hay muchos documentos que rellenar y se termina perdiendo más tiempo en burocracia que en ejecutar el proyecto. Desde mi punto de vista esta afirmación es equivocada y sólo la puede decir alguien que de verdad no conozca PMBOK o no haya entendido lo que pone el libro. Es cierto que hay múltiples procesos y múltiples documentos nombrados en PMBOK, pero esto no implica que haya que realizar mucho trabajo. Voy a argumentar como podemos cumplir con estas recomendaciones sin perdernos en burocracia.

Primero, el nivel de detalle de estos documentos debe ser acorde al tamaño del proyecto. Por ejemplo, fijémonos en el acta de constitución del proyecto (que como dice Joan Barceló, necesitas una y lo sabes). Uno de los contenidos del acta es una descripción de alto nivel del alcance del proyecto. ¿Qué significa de alto nivel? Pues es algo relativo. Y debe ser relativo al tamaño del proyecto. Un proyecto para crear una página web de un restaurante a 5.000 € tendrá un alcance de una o dos frases. Algo como “Una página web con descripción del local, listado de platos estrella con fotos y una zona de contacto con mapa incluido. Tendrá un enlace a Restauralia para hacer reservas.” Ya basta. En cambio un proyecto para implantar SAP en una gran organización, valorado en 500.000 € tendrá una descripción “de alto nivel” del alcance que puede cubrir un par de páginas. Lo mismo con el resto de documentación. El EDT de la web tendrá dos o tres paquetes de trabajo y el del proyecto de SAP probablemente tendrá más de 100. Todos estos documentos serán mucho más pequeños en un proyecto pequeño que en uno grande.

Segundo, nadie te obliga a reescribir toda la documentación cada vez. Puedes comer de plantillas. Las organizaciones que ejecutan proyectos pequeños tienden a repetir muchas de las tareas. En algunos casos, estos proyectos pequeños casi se podrían ver desde el punto de vista de operaciones. Es decir, hacer webs pequeñas puede llegar a ser tan mecánico, que lo puedes llegar a ver como peticiones de servicio. Esta repetibilidad de los procesos de los proyectos tiene la ventaja que podemos aprovechar la documentación de un proyecto a otro y llegar a estandarizarla. PMBOK te dice que tengas un plan de gestión del alcance, no te dice que lo reescribas en cada proyecto. Por lo tanto puedes partir la ejecución del proyecto con todos los planes establecidos y simplemente retocar las particularidades del caso en cuestión.

La reunión de kick-off

Vamos a tocar un poco más de cerca lo que he expuesto en el punto anterior. Un proyecto, por pequeño que sea tendría que tener una reunión de kick-off, es decir, una reunión en la que oficialmente se arranca el proyecto. ¿Que se trata en esta reunión?, pues se tratan aquellos aspectos que luego serán necesarios para la gestión del proyecto. Al finalizar una reunión de kick-off en un proyecto pequeños (unas horas) se sale con un acta que contiene:

  • Definición del alcance y cronograma. Compromisos de las partes con respecto a los hitos del cronograma.
  • Definición de los entregables o del producto a recibir.
  • Lista de interesados.
  • Principales riesgos.
  • Cómo se gestionará la aprobación.
  • Cómo se comunicarán los interesados.
  • etc.

Si nos fijamos un poco, lo que realmente hemos hecho es “pulirnos” los procesos de inicio y planificación en unas horas. ¿Me he salido del PMBOK? No. Simplemente he aplicado sentido común y aplicado los procesos de forma que estén adaptados al tamaño de mi proyecto.

¿Seguimos PMBOK sin saberlo?

Primero de todo, volvamos a la cita que he puesto de Ángel Nájera. PMBOK es un compedio de buenas prácticas. Si gestionamos bien los proyectos, aunque no conozcamos PMBOK, es muy probable que estemos siguiendo sus buenas prácticas. Cuando cogí un libro de PMBOK por primera vez, ya tenía experiencia en gestión de proyectos, así que la gran mayoría de las recomendaciones ya las conocía y muchas las aplicaba habitualmente.

Cuando no aplicas PMBOK es cuando haces cosas mal. Por ejemplo, por muy pequeño que sea el proyecto, hay que hacer una gestión de riesgos. Hacer una gestión de riesgos en un proyecto pequeño es fácil. Dura poco tiempo y hay pocas tareas, así que es fácil identificar qué podría salir mal y preparar la respuesta. Y los beneficios son acordes al tamaño del proyecto.

PMBOK ágil

Podemos perfectamente tener un enfoque ágil en el proyecto y seguir PMBOK. No es incompatible. Por ejemplo, si aplicamos SCRUM, podemos perfectamente aplicar las buenas prácticas de PMBOK, sin problemas. Cada sprint de SCRUM es una fase de proyecto según se define en PMBOK. Así que inicio, planifico, ejecuto y cierro en cada sprint. El sprint planning cubre los objetivos de los procesos inicio y parte de la planificación. En la sesión de retrospectiva redefinimos los procesos de planificación de gestión. El backlog, si lo represento como un árbol con épicas arriba, historias de usuario en medio y tareas abajo, obtengo la EDT, y lo mejor de todo es que es una EDT orientada a entregables, como debe ser. Los gráficos de trabajo pendiente son análogos a la gestión del valor ganado, sólo que vistos como lo que falta. Y puedo no parar.

Conclusiones

PMBOK no obliga a gastar tiempo en burocracia.

About author

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert y va en camino de certificarse como PMP. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de proyectos, usando metodologías clásicas y ágiles, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector. Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo. Actualmente trabaja en Idiso, empresa de servicios de distribución hotelera, como responsable del equipo de desarrollo web.

No comments

Te puede interesar...

El Héroe

Alguien que ha conseguido hacerse imprescindible por ser el único que posee determinado conocimiento. ¿Qué hacemos con ellos?