Proyecto pequeño

La mayoría de las metodologías de gestión de proyectos consideran proyectos grandes, lo que difiere de la realidad en muchas organizaciones o directores de proyectos. Lo más habitual es trabajar con proyectos pequeños. En este artículo se tratan las principales diferencias entre gestionar un proyecto grande y uno proyecto pequeño. Haciendo hincapié en cómo adaptar las metodologías y los retos y dificultades que estos presentan.

Si te gusta este post y te interesa aprender más sobre la gestión de proyectos. Te sugerimos que descargues nuestra guía o nuestro set de plantillas profesionales. Así, de paso, nos ayudas a seguir creando contenido de valor para ti 😉 Gracias!!

¿Qué es un proyecto pequeño?

El PMI define los grandes proyectos como aquellos que duran más de un año, con un presupuesto mayor a un millón de dólares, y con un equipo de más de cien personas. Por lo tanto por analogía podríamos decir que el resto de proyectos serían los proyectos pequeños.

En muchos casos los proyectos tienen duraciones de pocos meses, presupuestos por debajo del medio millón de euros, y con un equipo reducido. Estos suelen ser los más habituales en las pequeñas y medianas empresas.

Llegados a este punto, algunos lectores pueden decir que hay algunas metodologías más aplicables a pequeños proyectos que otras, caso de PRINCE2 o AGILE. Estas no entran en tanto detalle en los procesos, por lo que son más adaptables, o directamente están pensadas para grupos de trabajo reducidos.

En proyectos de IT, AGILE puede ser una buena solución. Pero cuando entramos en proyectos tradicionales (industriales, construcción, etc.), debemos recurrir a las otras metodologías o estándares como PMBOK (visitar la página del PMI ), PRINCE2, IPMA ( visitar la página del IPMA ), etc. que están pensadas para proyectos de cualquier tamaño.

¿Qué diferencias hay entre un proyecto pequeño y un proyecto grande?

A parte de las diferencias reflejadas en la definición anterior, podemos destacar otras diferencias que tienen un efecto importante en las necesidades y forma de gestionar estos proyectos:

• Al ser proyectos con un plazo y un volumen de recursos reducidos, la dedicación que permiten para la planificación y gestión del mismo es también reducida. Por ello no es posible aplicar completamente y en profundidad los procesos definidos en las metodologías. Lo que en algunos casos lleva al engaño de decir que la teoría no es aplicable, y por tanto acabar no gestionando el proyecto.
• El punto anterior también suele implicar que el director del proyecto debe asumir parte de labores técnicas. Esto le resta tiempo para las tareas propias de planificación y gestión, e incrementa el riesgo de caer en la micro gestión.
• Los proyectos pequeños habitualmente se desarrollan entornos multiproyecto, por lo que suelen estar más afectados y limitados por las dependencias con otros proyectos.
• A nivel organizativo también suele ser habitual que estos se desarrollen dentro de organizaciones funcionales o matriciales. Esto implica una menor autoridad del director del proyecto, y en algunos casos una cultura de dirección de proyectos débil, más centrada en la ejecución (eficacia) que en la gestión (eficiencia).
• Aunque cuantitativamente son proyectos con un riesgo menor que los grandes proyectos, porcentualmente no tiene por qué ser así. Lo que se une a una menor capacidad de reacción debido al bajo presupuesto y plazo. Un atraso de dos semanas en una tarea dentro de un proyecto de dos años es recuperable, pero en un proyecto de dos meses posiblemente no lo sea.
• Una ventaja de estos proyectos es que suelen tener un componente de repetitividad y reaprovechamiento superior a los proyectos grandes. Esto es debido a que suelen ser encargos con un alcance acotado a la actividad de la empresa, y por lo tanto más próximos a lo que sería operaciones. Esta mayor repetitividad hace que sean proyectos más simples de planificar, ya que es posible disponer de más información histórica.

En general se puede decir que son proyecto más simples y con menores necesidades a nivel de dirección de proyectos. En contra, que suelen desarrollarse en entornos más “hostiles”, lo que al final acaba generando dificultades que no suelen presentarse en los proyectos grandes.

¿Cómo tratar los proyectos pequeños?

Aunque lo más obvio sería decir que es necesario aplicar los procesos definidos en las metodologías de gestión de proyectos. La realidad es que esto es inviable por los pocos recursos disponibles para ello.

Lo primero a remarcar es que aunque no se puedan seguir rigurosamente los procesos, estos tampoco se pueden obviar. Como en cualquier otro proyecto, existe la necesidad de planificar y controlar los diferentes aspectos que lo componen. Por lo tanto la cuestión es cómo combinar esta necesidad con unos recursos reducidos.

Aunque pueden haber diferentes soluciones, la que se propone en este artículo es la de traspasar parte de las tareas de gestión del proyecto a la organización y aprovechar el hecho de que habitualmente estamos hablando de proyectos con un nivel alto de repetitividad. Con ello se reduce el volumen de recursos destinados a gestionar dentro del proyecto, y se sustituyen por recursos compartidos aprovechando las sinergias.

Cómo hacerlo

En la práctica esto se puede resumir en los siguientes puntos:

• Aunque no se puedan aplicar los procesos en profundidad, es necesario aplicar los puntos principales de estos. Sustituyendo cuando se pueda las estimaciones por datos históricos o valores estándar. La ventaja de esto es evidente cuando hablamos de estimar el margen por riesgos. Donde es mejor poner un porcentaje basado en experiencia que no poner nada por falta de tiempo.
• Cuando los proyectos se realicen en un entorno multiproyectos es muy recomendable la creación de una PMO, la cual debe asumir la labor de planificación del conjunto de proyectos. Esto también es más coherente con la forma de funcionar en organizaciones funcionales o matriciales débiles, donde las áreas funcionales tienen más peso que los directores de proyectos.
• El hecho de disponer de una PMO permite colectar y almacenar datos históricos de forma más eficiente, lo que reduce el tiempo necesario para completar la fase de planificación.
• Parte de la planificación debe traspasarse a la fase comercial, de tal forma que cuando se reciba el pedido, este ya contemple las necesidades más importantes desde el punto de vista de la gestión del proyecto, y en cierta forma haya completado el proceso de inicialización. De nuevo esto se puede hacer considerando los datos históricos proporcionados por la PMO.