Gestionando proyectos pequeños

Como gestor de proyectos, a menudo me preguntan si las mejores prácticas de gestión de proyectos aplicables a los grandes proyectos pueden aplicarse a los más pequeños. Se trata de una cuestión realmente importante a la que todos los gestores de proyectos deben enfrentarse cuando gestionan proyectos pequeños.

Centrarse en la entrega del proyecto

Uno de los argumentos en contra del uso de metodologías de gestión de proyectos es que están muy centradas en los procesos, lo que da lugar a una gran cantidad de documentación del proyecto que simplemente no es práctica ni deseable en los proyectos pequeños. Se trata de un argumento de peso y cualquier método que se centre en la producción de documentación a expensas de la obtención de los verdaderos beneficios empresariales del proyecto será un obstáculo más que un beneficio. Al fin y al cabo, el objetivo de la gestión de proyectos es alcanzar los objetivos empresariales, no producir montones de documentos.

En la comunidad de desarrollo de software hay un debate continuo y activo sobre la mejor manera de producir
software en los proyectos. Recientemente, algunos profesionales del software han abogado por métodos más ágiles de producción de software en lugar de los métodos más tradicionales y pesados que se centran en la producción de grandes cantidades de documentación.

Los métodos ágiles se centran en la entrega del software más que en la documentación. Teniendo esto en cuenta, creo que los gestores de proyectos de todo el mundo pueden aprender algo de los métodos ágiles empleados en el desarrollo de software. En resumen, esto nos lleva a centrarnos en la entrega del proyecto más que en la documentación del mismo, aunque la decisión crítica que deben tomar los gestores de proyectos de todo el mundo
de proyectos de todo el mundo es saber cuánta documentación es realmente necesaria.

Aplicar las mejores prácticas

Soy un firme partidario de producir sólo la cantidad que requiera el proyecto. Nada más y nada menos. Una regla simple es: si es útil para ayudarnos a cumplir los objetivos empresariales del proyecto, entonces prodúcela; si no es útil para ayudarnos a cumplir los objetivos empresariales del proyecto, entonces no pierdas el tiempo en producirla. Teniendo esto en cuenta, creo que en todos los proyectos, como mínimo, es mejor aplicar las mejores prácticas de gestión de proyectos.

Consideremos las mejores prácticas por separado y veamos si los gastos generales que se pierden al aplicar las mejores prácticas valen o no los beneficios que se pueden obtener.

Definir los objetivos y el alcance

Incluso en el proyecto más pequeño habrá objetivos que deben alcanzarse. Como gestor de proyectos, le interesa definir cuáles son esos objetivos, ya que es probable que se le evalúe en función de si el proyecto cumple con ellos. Es su responsabilidad asegurarse de que el proyecto cumple esos objetivos y debe rendir cuentas de ello. En resumen, el libro se detiene en ti.

Ahora bien, si no defines y escribes cuáles son los objetivos, siempre vas a estar a merced de cualquier jefe que decida que la tiene tomada contigo. El conjunto de objetivos definidos y documentados es tu póliza de seguro contra el hecho de que tu jefe venga más tarde y diga que no has cumplido los objetivos.

Sin embargo, hay otra razón por la que hay que definir y documentar los objetivos incluso en un proyecto pequeño. Quieres satisfacer las necesidades de las partes interesadas, ya que para eso te pagan como gestor de proyectos. Si los objetivos no están definidos, no podrás satisfacer esas necesidades a través de tu proyecto.

Lo mismo ocurre con la definición del alcance. El alcance constituye el límite de su proyecto. Si no lo defines, lo más probable es que crezca y crezca a medida que el proyecto avanza y, aunque hayas empezado a gestionar un proyecto muy pequeño, en poco tiempo tu proyecto podría ser mucho más grande que cuando lo empezaste.

También es necesario documentar quiénes son las partes interesadas en un proyecto pequeño. Al definir quiénes son, puedes asegurarte de que cubres todas sus necesidades cuando defines los objetivos y los resultados.

Definir los resultados

Alguien tendrá que llevar a cabo el trabajo real para producir lo que sea que se entregue de su proyecto. Aunque los resultados sean pequeños y no lleven mucho tiempo, deben estar escritos. El hecho de documentar estas cosas y que luego las revisen otros permite encontrar errores. Su objetivo debe ser documentar un conjunto suficientemente detallado de descripciones de los productos que se van a entregar.

Estas descripciones serán utilizadas por las personas que producirán los productos. Aunque estas descripciones no ocupen más de una página de texto, es importante redactarlas de forma clara e inequívoca. Si no escribes una descripción, significa que la persona que hace el entregable puede interpretar lo que se requiere de maneras inesperadas, lo que sólo resultará en un trabajo posterior para corregir los errores. Por tanto, defina y documente siempre los entregables.

Planificación del proyecto

Si subiera el Monte Everest, nunca lo haría sin una cantidad considerable de planificación. Incluso si subes la colina por la parte de atrás de tu casa, es probable que haya algo de planificación: ¿a qué hora vas? ¿Qué debe llevar consigo? Lo mismo ocurre incluso en los proyectos más pequeños, en los que hay que determinar qué actividades son necesarias para producir un producto final, estimar el tiempo que llevarán las actividades, calcular el personal y los recursos necesarios y asignar actividades y responsabilidades al personal.

Todo esto tiene que quedar por escrito y comunicarse de forma eficaz a los miembros del equipo del proyecto. He visto a mucha gente que se ha quedado atascada porque cree que tiene que utilizar algún tipo de software de planificación de proyectos, como Microsoft Project. Se trata de una sobrecarga innecesaria. Me he dado cuenta de que la gente tiende a perder demasiado tiempo haciendo que sus diagramas de Gantt de Microsoft Project parezcan bonitos, de modo que pierden de vista la razón por la que están utilizando la herramienta.

En cambio, para los proyectos pequeños, creo que lo mejor es crear un gráfico de barras en Microsoft Excel. Es sencillo y más que adecuado para proyectos pequeños. Basta con hacer que cada columna sea una fecha secuencial, escribir las tareas en la primera columna y rellenar las celdas para representar el tiempo que dura la actividad.

Además del diagrama de barras, tendrás que documentar los hitos del proyecto. Los hitos son las fechas en las que hay que entregar ciertas cosas, o pueden ser la fecha en la que termina una actividad importante. Las responsabilidades de cada miembro del proyecto también deben estar documentadas en el plan del proyecto.

Comunicación

Incluso en el equipo de proyecto más pequeño, compuesto únicamente por un director de proyecto y otra persona, el director de proyecto deberá asignar tareas y responsabilidades a la otra persona. No se puede dar por sentado que sabrán lo que deben hacer sin que el director del proyecto se lo comunique efectivamente. Si el director del proyecto no les asigna actividades específicas, lo más probable es que sigan trabajando en cosas que no son necesarias para el proyecto. Por lo tanto, o bien el proyecto acabará entregando cosas equivocadas, o bien el proyecto se retrasará, ya que habrá que dedicar tiempo más tarde a realizar las actividades que deberían haberse hecho antes.

Puede comunicar los planes por correo electrónico, o entregar una copia impresa del plan a los miembros del equipo del proyecto, o mejor aún, convocar una reunión y revisar el plan con los miembros del equipo del proyecto. Recuerde que si el plan cambia, también tendrá que comunicar los cambios a su equipo.

Seguimiento e información de los avances

Si seguimos considerando nuestro equipo de proyecto de dos personas -el director del proyecto y otra persona-, el director del proyecto necesitará conocer el progreso de las actividades en las que está trabajando la otra persona. Esto puede hacerse de varias maneras: un breve correo electrónico diario en el que se detalle el trabajo realizado, el trabajo que queda por hacer y una lista de los problemas/imprevistos. En la mayoría de los casos esto será suficiente.

O bien, una breve puesta al día de 15 minutos cara a cara puede conseguir lo mismo. O una combinación de las dos cosas puede ser lo mejor. En cualquier caso, el gestor del proyecto debe ser plenamente consciente de los progresos que se están realizando para poder hacer un seguimiento eficaz de los mismos.

Gestión de los cambios

Incluso en nuestro proyecto de dos personas, es probable que se produzcan cambios. Las solicitudes de cambio suelen provenir de las partes interesadas y, como director del proyecto, es su responsabilidad evaluar el impacto de su aceptación en el proyecto.

Para ello, necesita una buena estimación del impacto que tendrá el cambio en términos de esfuerzo y coste adicionales. A menudo, esto también afectará al calendario, por lo que, si comprende claramente cómo se verán afectados el calendario y el presupuesto, podrá tomar la decisión de aceptar o no el cambio en su proyecto.

En un proyecto pequeño no debería ser necesario ningún consejo de control de cambios para decidir si se acepta el cambio. Un rápido debate con los principales interesados debería bastar para tomar una decisión, siempre que se haya calculado el impacto en el coste y el calendario.

Una cosa que nunca debe hacer es aceptar simplemente el cambio. Aunque piense que el cambio es pequeño, nunca debe aceptar ningún cambio sin comprender plenamente cuál será su impacto en el coste y el calendario.

Esto es una receta para lo que llamamos «ampliación del alcance», en la que el proyecto se hace cada vez más grande a medida que se añaden más y más cambios al proyecto. Antes de que nos demos cuenta, nuestro pequeño proyecto se ha convertido en uno mucho más grande e inevitablemente no conseguiremos entregar el proyecto según el presupuesto y el calendario originales.

Gestión de riesgos

Habrá riesgos incluso en un proyecto pequeño. Asegúrese de haber pensado en todos los riesgos potenciales al principio del proyecto, controle los diez principales riesgos cada semana (o los cinco principales si el número de riesgos es pequeño) y esté atento a nuevos riesgos. No gestionar los riesgos adecuadamente es una de las principales causas de fracaso de los proyectos.

Los gastos generales de la gestión de riesgos son muy bajos. En un proyecto reciente, elaboré una lista de lo que consideraba que eran todos los riesgos del proyecto. Se trataba de unos 10 riesgos en total. De ellos, cinco eran graves. Elaboré un plan para evitar o minimizar cada riesgo. En total, tardé poco más de un par de horas en hacerlo. Luego, cada semana del proyecto, dedicaba, por ejemplo, media hora a revisar todos los riesgos y a pensar en otros nuevos. Al final del proyecto, aunque algunos riesgos se habían materializado, gracias a que había identificado un plan al principio del proyecto para minimizar el impacto de estos riesgos, el impacto de estos riesgos en el proyecto acabó siendo mínimo.

Así que, con poco esfuerzo inicial y continuo, se obtiene una gran recompensa si se gestionan los riesgos a lo largo del proyecto.

Resumen

En resumen, la aplicación de las mejores prácticas, incluso en un proyecto pequeño, puede hacerse sin crear demasiado papeleo o gastos generales. Las mejores prácticas son las cosas que innumerables gestores de proyectos han hecho en miles de proyectos y son consideradas las «mejores prácticas» porque tienden a ayudar a conseguir los mejores resultados.

No pienses que como gerente de proyecto estés manejando un proyecto pequeño puedes prescindir de estas mejores prácticas, porque si lo haces, te arrepentirás más tarde cuando tu proyecto se convierta en un desastre.