Consejos para dirigir proyectos pequeños

Desde ProjectSmart; Simon Buehring nos propone en el siguiente artículo algunas sugerencias para administrar proyectos pequeños.

El autor empieza señalando la importancia de definir si las mejores prácticas de la gestión de proyectos que son aplicables para los grandes proyectos se pueden aplicar en proyectos más pequeños y hace algunas recomendaciones:

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 el proceso, lo que resulta en una cantidad de documentos del proyecto que simplemente no es práctica o deseable en proyectos pequeños. Este es un argumento poderoso y cualquier método que se centre en generar documentación a expensas de la entrega de los beneficios reales de negocio del proyecto será un obstáculo en lugar de un beneficio. Después de todo, la idea detrás de la gestión de proyectos es la entrega de los objetivos de negocio, no producir montones de documentos.

Hay un debate dentro de la comunidad de desarrollo de software sobre la mejor manera de producir software en proyectos. Recientemente algunos profesionales de software han argumentado a favor de métodos más ágiles para producir software en lugar de los pesados métodos tradicionales que se centran en la producción de grandes cantidades de documentación.

Los métodos ágiles se centran en la entrega de software en lugar de generar documentación. Con esto en mente, el autor sugiere que los directores de proyectos pueden aprender algo de los métodos ágiles empleados en el desarrollo de software. En resumen: centrarse en la ejecución del proyecto en lugar de generar documentación. Pero la pregunta crucial sigue siendo ¿cuánta documentación que es realmente necesaria?

Aplicar las mejores prácticas

Simon recomienda solo producir la documentación requerida por el proyecto. Nada más y nada menos. Una simple regla de oro es: si el documento es útil para ayudarnos a conseguir los objetivos de negocio del proyecto, entonces genérelo. Si el documento no es útil para ayudarnos a conseguir los objetivos de negocio del proyecto, no pierda el tiempo con él.

Definir Objetivos y Alcance

Incluso en los proyectos más pequeños habrá objetivos que se deben alcanzar. Como Administrador del proyecto, es de su interés definir estos objetivos ya que es probable que eventualmente se evalúe si el proyecto los cumple o no. Es su responsabilidad asegurar que el proyecto cumple con los objetivos.

Ahora suponga que no define ni registra cuáles son los objetivos del proyecto. Entonces siempre va a estar a merced de cualquier jefe que decidirá lo usted debe hacer. Un conjunto de objetivos definido y documentado es su póliza de seguro cuando alguien alegue que no se están cumpliendo los objetivos.

Sin embargo, hay otra razón por la que se tienen que definir y documentar los objetivos, incluso en un proyecto pequeño. Usted espera satisfacer las necesidades de los interesados, ya que es por lo que se le paga al administrador del proyecto. Si los objetivos no están definidos, entonces usted no será capaz de satisfacer esas necesidades.

Lo mismo ocurre con la definición del alcance. El alcance constituye el límite de su proyecto. Si no se define lo que es, lo más probable es que va a crecer y crecer conforme avanza el proyecto y aunque podría haber comenzado la gestión de un proyecto muy pequeño, en poco tiempo el proyecto podría llegar a ser mucho más grande que lo esperado.

Además usted necesita documentar quienes son los interesados (stakeholders) en un proyecto pequeño. Al definir quiénes son, puede asegurarse de que se cubren todas sus necesidades y expectativas.

Definir los entregables

Alguien va a tener que llevar a cabo el trabajo real necesario para producir el entregable del proyecto. Aun cuando los entregables puedan ser pequeños y no se tenga mucho tiempo para producirlos, deben ser descritos en forma apropiada. Documentar y revisar estas cosas permite detectar errores potenciales. Su objetivo debe ser documentar en forma suficientemente detallada las descripciones de los productos a ser entregados.

Estas descripciones serán utilizadas por la gente que produzca los resultados finales. Incluso si estas descripciones no requieren más de una página de texto, es importante escribirlas de manera clara e inequívoca. Si no se describe un entregable, la persona que lo genera puede interpretar lo que se requiere de manera inesperada, lo que más tarde se traducirá en retrabajo para corregir los errores. Por lo tanto, siempre hay que definir y documentar los entregables.

Planificar el Proyecto

Si considerara escalar el Monte Everest, nunca lo haría sin una cantidad considerable de planificación. Incluso si usted camina por la colina en la parte trasera de su casa, es probable que haya al menos un poco de planificación - ¿A qué hora es mejor hacerlo? ¿Qué debe llevar con usted? Lo mismo aplica incluso para el más mínimo proyecto: tendrá que averiguar qué actividades son necesarias para producir un entregable, estimar cuánto tiempo requieren las actividades, determinar la cantidad de personal y recursos necesarios y asignar actividades y responsabilidades al personal.

Todas estas cosas deben ser registradas por escrito y comunicarse efectivamente a los miembros del equipo de proyecto.

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

Comunicación

Incluso en el equipo de proyecto más pequeño (integrado solo por el gerente de proyecto y otra persona), el administrador del proyecto aún tendrá que asignar tareas y responsabilidades a la otra persona. No se puede suponer que el equipo sabrá lo que debe hacer sin que sea efectivamente comunicado por el administrador del proyecto. Si el administrador del proyecto no les asigna actividades específicas, lo más probable es que van a seguir adelante y trabajar en cosas que no son necesarias para el proyecto. Así que el proyecto terminará con la entrega de las productos incorrectos, o se retrasará ya que se deberá gastar más tiempo en hacer las actividades que se deberían haberse hecho antes.

Puede comunicar los planes a través de correo electrónico, o dar una impresión del plan para cada uno de los miembros de su equipo, o mejor aún, convocar a una reunión y revisar el plan con los miembros del equipo de proyecto. Y recuerde, si cambia el plan, también tendrá que comunicar los cambios a su equipo.

Seguimiento y presentación de informes de progreso

Si seguimos considerando al equipo de proyecto de dos personas - el administrador del proyecto y otra persona - el administrador tendrá que conocer el progreso de las actividades que la otra persona está desarrollando. Esto se puede hacer en una variedad de formas: un breve correo electrónico a diario detallando el trabajo realizado, el trabajo que todavía queda por hacer, y una lista de todas las cuestiones y problemas. En la mayoría de los casos esto será suficiente.

Como alternativa, una reunión de unos 15 minutos puede lograr lo mismo. O mejor una combinación de las dos cosas. En cualquier caso, el director del proyecto todavía tiene que estar plenamente consciente de los progresos para poder realizar un seguimiento eficaz.

Gestión del Cambio

Incluso en el proyecto de dos personas, es probable que ocurran cambios. Las solicitudes de cambio por lo general vienen de los interesados y es responsabilidad del administrador del proyecto evaluar el impacto de aceptarlas. Para ello, necesita una buena estimación del impacto que el cambio tendrá en términos de esfuerzo y costos involucrados. A menudo, esto afectará el calendario, así que mediante un claro entendimiento de cómo el programa y el presupuesto se verán afectados podrá tomar la decisión de aceptar o no el cambio en el proyecto.

En un proyecto pequeño no es necesario un comité de control de cambios para decidir si el cambio es aceptado. Una breve discusión con el (los) interesado(s) clave debería ser suficiente para que se pueda llegar a una decisión.

Una de las cosas que nunca se debe hacer es simplemente aceptar el cambio. Incluso si se piensa que el cambio es pequeño, nunca se debe aceptar sin entender completamente lo que su impacto sobre el costo y el programa. Esa es una receta de lo que llamamos "la corrupción del alcance", donde el proyecto se hace más grande y más grande conforme se aceptan más y más cambios al proyecto. Antes de poder notarlo, un pequeño proyecto se ha convertido en uno mucho más grande e inevitablemente, será imposible entregarlo según el presupuesto y programa originales.

Gestión de Riesgos

Habrá riesgos, incluso en un pequeño proyecto. Hay que asegurarse de que se han considerado todos los riesgos potenciales en el inicio del proyecto, y cada semana se debe dar seguimiento a los diez riesgos principales y seguir identificando los nuevos riesgos. La falta de gestión de riesgos adecuada es una de las causas principales de fracaso de los proyectos.

La sobrecarga en la gestión de riesgos es muy baja. Una técnica sugerida considera elaborar una lista de lo todos los riesgos identificados en el proyecto. De estos, elaborar un plan para evitar o minimizar cada uno de los riesgos severos. Luego, cada semana, dedicar 30 minutos a revisar todos los riesgos y pensar en otros nuevos.

Resumen

En resumen, la aplicación de las mejores prácticas incluso en un proyecto pequeño se puede hacer sin crear demasiado papeleo o sobrecarga. Las mejores prácticas son las cosas que un sinnúmero de administradores han hecho en miles de proyectos y se consideran "mejores prácticas" por que tienden a ayudar a conseguir los mejores resultados.




A raíz de la publicación de este post, en twitter tuve una interesante charla con @fcartu que transcribo con su amable consentimiento:


@fcartu Francisco Cartusciel: Después d todo, la idea dtrás de la gestión de proyecto es la entrega d los objetivos d negocio, no producir montones de documentos


@irivera Ivan Rivera, PMP: Gracias por el comentario. Es un tema que a mi me toca vivir a diario. La clave es encontrar la cantidad precisa de documentos, que claramente es diferente entre organizaciones e incluso puede ser diferente entre proyectos... Saludos desde México


@fcartu Francisco Cartusciel: Interesante artículo, el problema esta cuando #Stakeholders valoran más la documentación que el producto final.
@fcartu Francisco Cartusciel: Actualmente tenemos un contrato AM en donde nos exigen alrededor de 10 documentos por proyecto y donde nos penalizan por no hacerlo


@irivera Ivan Rivera, PMP: Hay organizaciones que exigen hasta 30 documentos por proyecto... El tema se debe negociar entre los tres niveles de la organizacion: Directivo, Táctico y Operativo. Debe ser un tema negociado entre la Gerencia, la PMO y los Administradores


@fcartu Francisco Cartusciel: Es difícil hacerlos entender que la mitad de esos documentos no dan un valor al proyecto y más cuando la documentación entrega por el cliente es mal diligenciada y al final el proyecto es totalmente diferente a esa documentación inicial.


@irivera Ivan Rivera, PMP: Hay mucho trabajo desparovechado. Por eso es bueno que la metodología sea acordada, y se le presente al cliente al inicio del proyecto, para obtener sus comentarios sobre la misma. Al final entonces es un acuerdo entre cuatro partes: Cliente, Gerencia, PMO y Administrador, todos deben estar de acuerdo en la documentación que se va a manejar a lo largo del proyecto