Mini y micro proyectos

¿son los principios de gerencia de proyectos aplicables a pequeñas empresas o pequeños proyectos? = Mini and micro projects: are the principles of project management appropriate for managing small companies or small projects?

Extracto

Not all projects are big projects; better yet, small companies usually have very small projects. There is a general agreement on how to manage big and complex project, but what about those small ones that can make a difference? This presentation will show the general principles applied in some small and medium IT and software development companies to manage projects between 8 and 120 hours of work and it will also show that accepted PM principles like the ones proposed in the PMBOK® are a very effective tool to keep those projects under control.

Resumen

No todos los proyectos son grandes; más aún, las compañías pequeñas y medianas usualmente ejecutan pequeños proyectos. Existe un acuerdo general acerca de cómo manejar proyectos grandes y complejos. Sin embargo, ¿qué sucede con aquellos pequeños proyectos que pueden hacer la diferencia? Esta presentación mostrará principios generales extractados de pequeñas y medianas compañías y tecnología y desarrollo de aplicaciones para administrar proyectos entre 8 y 120 horas, y demostrara cómo los principios de gerencia de proyectos presentados en el PMBOK® proporcionan excelentes herramientas para mantener este tipo de proyectos bajo control.

Una historia corta, Capítulo 1

Advertencia: Esta es una historia ficticia. Cualquier similitud con personas, compañías o proyectos reales es pura coincidencia.

“Hola José”, saludo mi jefe, “tu eres uno de nuestros mejores gerentes de proyecto y sé que tienes algún tiempo libre en tu agenda”. Me senté en su escritorio para escuchar su petición. “El área de Mercadeo acaba de comprar esta aplicación para ayudarles a mantener bajo control sus campañas y necesitamos a alguien que esté pendiente de la instalación del paquete. No requiere de mayor trabajo pues es una de esas aplicaciones ya empaquetadas, la instalación es muy sencilla y no esperamos mayores requerimientos. Te pido tu ayuda porque el VP de Mercadeo esta un poco preocupado y se sentiría mejor si asignamos a alguien para que supervise el proceso.” Después de unos segundos, mi procesador de gerente de proyectos empezó a trabajar y pregunté: “¿Tenemos las especificaciones técnicas del software? ¿Tenemos el servidor? ¿La aplicación estará en red o estará en el escritorio de alguien en mercadeo?” (Demasiadas preguntas, pensé en silencio). Mi jefe sonrió y me dijo: “Todo está arreglado, es un proyecto insignificante”. Yo contesté: “Esta bien; hablaré con Mercadeo.” Mi suerte estaba echada.

¿Existen pequeños proyectos?

Los gerentes de proyecto tienden a pensar en un proyecto de forma diferente al resto de los miembros del equipo que lo integra. Tal vez por razones históricas, los proyectos se ven como grandes esfuerzos para producir un producto o servicio único. Cuando se usa la palabra “proyecto”, el adjetivo “grande” casi siempre se asocia a él. Sin embargo, el PMBOK en su definición de proyecto no menciona nada acerca del tamaño del mismo. Sólo menciona que es un “esfuerzo temporal”.

Asumamos, como parte de la discusión, que los proyectos son “grandes esfuerzos” por definición. Parece muy apropiado establecer una serie de fases muy bien estructuradas, las cuales toman cierto tiempo para ser completadas. Adicionalmente, es obvio que deben usarse procesos muy estructurados para asegurar el éxito del proyecto. Todo el contenido del PMBOK está creado bajo la premisa de que un proyecto bien manejado tiene todo el tiempo requerido para completar algunos, si no todos, los procesos. O al menos, ésa es la impresión.

Si eliminamos este supuesto y decimos que existen esfuerzos temporales donde, o bien el tiempo es un recurso escaso o bien el proyecto mismo es de corta duración, la situación cambia radicalmente. ¿Será que este proyecto necesita la aprobación de los ejecutivos? ¿Será que el gerente de proyecto debe planificar las tareas? ¿Será que estas tareas deben ser controladas? ¿Es necesario que el gerente de proyecto evalúe los riesgos? La respuesta a todas estas preguntas debería ser sí. Las temáticas tras cada una de ellas son parte del cuerpo de conocimiento de la gerencia de proyectos y sí, todas ellas son importantes. En una palabra: el concepto de proyecto no puede estar limitado en el tiempo; así pues es posible hablar de pequeños proyectos.

Si aún existe alguna sombra de duda acerca de la existencia de pequeños proyectos, es muy sencillo adicionar otra dimensión a la discusión: recursos. ¿Tienen todas las compañías equipos de proyectos dedicados a ellos? ¿Tienen suficientes recursos para asignar cada uno de ellos a un único proyecto o para manejar y ejecutar múltiples proyectos a la vez? La respuesta claramente es NO. Como resultado, ¿están las pequeñas compañías condenadas a desarrollar sus esfuerzos tipo proyecto en una forma que afecte su habilidad de crear excelentes productos o servicios? No debería ser así. Incluso las compañías muy pequeñas deberían poderse beneficiar de un cuerpo de conocimiento bien concebido en el área de gerencia de proyectos. Por supuesto, sus proyectos serán mas pequeños que aquellos de las grandes compañías, pero este hecho no debería ser una desventaja en el mundo de los negocios. Las pequeñas compañías muy probablemente ejecutarán pequeños proyectos.

Un ejemplo real de pequeños proyectos

Durante los años de explosión de Internet, una pequeña compañía se encontró con el predicamento típico de la época: la velocidad lo es todo. Docenas de compañías con los mismos modelos de negocio estaban luchando por sus ciber-compradores en todo el mundo. Necesitaban hacer las cosas rápido. “Cosas” llamadas proyectos. Y entonces la burbuja explotó. Esta compañía fue muy afortunada de poseer un buen modelo de negocios que le permitió sobrevivir a la debacle mundial de las punto-com. Todos pensaron que la presión había pasado y que las cosas podían hacerse ahora más despacio; había más tiempo para pensar, actuar y salir al mercado. Pero estaban equivocados.

En la medida en que los usuarios de Internet se hacían más exigentes, la situación para las empresas que sobrevivieron a la catástrofe cambió dramáticamente. Las pocas que quedaron TENÍAN que ser excelentes, tenían que innovar, tenían que demostrar que eran merecedoras de la lealtad de sus clientes. Proyectos pequeños y rápidos eran la norma y no la excepción. Y estos proyectos eran tan pequeños que el concepto de gerencia no estaba siendo aplicado.

Por lo general, las áreas de negocio generaban una idea para un nuevo producto. Alguien (en ocasiones, el mismo usuario, y en otras, un desarrollador) creaba un “alcance” y escribía los “requerimientos”. Estos requerimientos eran entregados a un desarrollador o un equipo de desarrolladores quienes programaban y entregaban el producto final, usualmente en producción. Allí era validado por las áreas de negocio (por supuesto, si había problemas, los usuarios finales los veían antes de que los detectara la gente en la compañía) y el proyecto se cerraba.

Considerando los productos que eran entregados como fueron concebidos, la tasa de éxito era, por supuesto, muy baja. Debido a que no existían métricas, era imposible saber qué tan grave era el problema, pero todos sabían que se estaba haciendo peor en la medida que esos pequeños proyectos aumentaban.

Cuando una nueva administración llegó a la empresa, era obvio que, para poder sobrevivir, algo tenía que hacerse y rápido. La primera etapa fue separar las áreas de negocio de los aspectos técnicos del proyecto. Desde la perspectiva de la gerencia de proyectos, una de las entradas más importantes de cualquier proyecto es el caso de negocio y los objetivos del proyecto, usualmente reflejados en los documentos de iniciación del mismo. Al separar a la gente de negocio de la responsabilidad técnica del mismo (asociada, por ejemplo, con los requerimientos), fue evidente que se necesitaba que alguien manejara realmente a los equipos que ejecutaban los proyectos. Estas personas serían responsables de dar el alcance al proyecto y hacer lo necesario para entregarlo a tiempo y dentro del presupuesto.

La segunda mejora se estableció al dar a los proyectos un tamaño específico. La compañía decidió usar una medida estándar tipo “prenda de vestir”. Los proyectos fueron clasificados entonces como grandes, medianos y pequeños. Los grandes proyectos eran llamados “proyectos”, los medianos fueron llamados “mini-proyectos”, y los pequeños “micro-proyectos”. Un micro-proyecto era un proyecto cuyo estimado era entre 8 y 40 horas de trabajo, un mini-proyecto tenía entre 40 y 120 horas de trabajo y un proyecto era un esfuerzo mayor.

Una propuesta

La aproximación propuesta en el ejemplo anterior ha probado ser muy efectiva en situaciones similares. Con base en datos obtenidos de experiencias personales y sesiones de trabajo con áreas de negocio y gerentes de proyecto de pequeñas y medianas organizaciones, es posible llegar a plantear un modelo práctico (muy cercano a un marco de referencia) para manejar pequeños proyectos. (Nota: Los rangos 8-40 y 40-120 fueron usados porque tenían sentido en el contexto de esta compañía. El mérito de estos números no será discutido en este documento. Sin embargo, cada compañía debe encontrar sus propios números en la medida que apliquen los principios generales). La clasificación de micro y mini proyectos se mantiene, pues existen diferencias muy importantes en estos dos sub-tipos de proyectos.

Ciclo de vida del proyecto

Tal y como lo propone el PMI (Project Management Institute, 2004, p 23), cada proyecto debe tener una fase inicial, intermedia y final, y la ejecución de procesos de gerencia de proyectos es especifica a cada uno de ellos. Dado que muchas compañías tienen que ejecutar proyectos pequeños y muy ágiles, ¿es esto posible?

Mini-Proyectos

El ciclo de vida típico de los mini-proyectos comienza cuando una idea es presentada por los ejecutivos de negocio. Los ejecutivos califican estas ideas en una variedad de factores (impacto inmediato en la satisfacción de los clientes, crecimiento de los ingresos, reducción de costos, riesgos, fuente de la idea, etc.). Una vez que las ideas son priorizadas, se les asignan espacios de tiempo para ser ejecutadas. Estos espacios de tiempo están directamente relacionados con consideraciones de negocio y con disponibilidad de recursos. El paso final de este proceso previo es la creación de un documento llamado la “visión”; éste se puede asimilar a un “alcance de negocio” y se le llama el documento del “por que” (¿por qué queremos hacer este proyecto?). Para un mini-proyecto, este documento no debe tener más de dos o tres páginas de longitud. Es un documento que se correlaciona muy bien con el resultado de la fase inicial propuesta por el PMI.

En este punto, el proceso cae en manos de un gerente de proyecto. Incluso si la organización no tiene una asignación formal para este cargo, es importante que alguien tenga el rol de gerente del proyecto. Un gerente de proyecto puede tener en un momento dado varios pequeños proyectos. Cuando el gerente del proyecto recibe el documento (firmado por los ejecutivos, por supuesto) que describe el por qué, su primera tarea consiste en crear un documento llamado el “qué” (¿qué es lo que queremos construir?). Este documento es el alcance del proyecto y puede contener algunos de los componentes típicos de un documento de alcance de un proyecto más grande. Cuando el documento es aprobado (usualmente por las áreas de negocio involucradas o el gerente del producto), se inicia la ejecución. Una vez que el proyecto se completa, existe un cierre formal (basado en una valuación de calidad del producto) y el producto se entrega a operaciones. Estas fases también son muy similares a las fases intermedia y de cierre del ciclo de vida del proyecto propuesto por el PMI.

Micro-Proyectos

Bajo el modelo propuesto, un micro-proyecto es cercano a una semana de trabajo. Es muy difícil lograr pasar por todo el ciclo de vida en tan corto tiempo. Una posibilidad es usar principios de Administración Total de la Calidad (TQM, por sus siglas en Inglés). El área de negocio responsable de la definición y el desarrollo del producto crea una idea en borrador (usualmente una mejora o adición a un producto existente) en conjunto con todos los afectados. Esta idea se presenta entonces en forma de un requerimiento (alcance). Por definición, el alcance ya está firmado por las áreas de negocio. El requerimiento es entonces presentado al gerente del proyecto quien es responsable (junto con los recursos técnicos requeridos) de revisarlo y encontrar cualquier zona gris. Una vez que las dudas son resueltas, el gerente de proyectos asigna las tareas a los recursos, usando alguna herramienta de seguimiento de tareas, y hace el seguimiento del desarrollo. Por experiencia, el número de tareas requeridas no debería superar a 10. El ciclo de vida de este tipo de proyectos, desde la idea inicial hasta la entrega del producto desarrollado, es cercano a las dos semanas (asumiendo que existen los recursos para ejecutar el trabajo).

Ésta es claramente una aproximación diferente a la propuesta por el PMI. Sin embargo, es una propuesta lógica dado que los micro-proyectos no están orientados a revolucionar la manera en que la compañía hace negocios sino a realizar mejoras incrementales en sus productos. Sin embargo, incluso en estos casos, el rol del gerente de proyecto es instrumental en el éxito final del trabajo realizado.

Procesos de la gerencia de Proyectos aplicados a pequeños proyectos

Una vez que se ha definido el ciclo de vida del proyecto, el siguiente problema es encontrar cuánta gerencia de proyectos es necesaria para que éste sea exitoso. Usando el PMBOK® como guía, es posible encontrar una aproximación práctica: qué elementos deben ser utilizados y cuáles deben ser abandonados o probados en el contexto de la empresa para saber si son útiles o no.

Mini-Proyectos

El gerente de proyecto es claramente responsable por su ejecución. Esto significa que, bajo cualquier circunstancia, se requiere cierto grado de control del mismo. En un mini-proyecto, es evidente que el gerente del mismo debe crear el alcance y el plan del proyecto, controlarlo, monitorearlo y administrar los controles de cambio. En un mini-proyecto, se requiere crear un alcance formal y un WBS básico. Estos elementos deben ser socializados con los recursos, especialmente los líderes técnicos, quienes usualmente pueden proporcionar información valiosa en esta etapa.

Para poder crear un WBS, se genera una secuencia Entregable > Tareas > Sub-tareas, basada en el consenso experto del alcance. En esta etapa, una herramienta que permita estructurar ideas disímiles (MindManager®, por ejemplo) puede resultar muy útil. De esta forma, se puede llegar a un acuerdo rápido acerca de los entregables y los criterios de aceptación del mini-proyecto. No se recomienda el uso de herramientas de administración de proyectos, ya que la sobrecarga de trabajo para documentar la plantación es muy grande.

Para definir las actividades, realizar el secuenciamiento y desarrollar un cronograma, el equipo del proyecto puede usar una metodología similar a la utilizada en el Scrum: la planeación de un “sprint”. (El sprint se define como un intervalo de tiempo definido e inmodificable dentro del cual se realizan ciertas actividades). Dado que el proyecto debe ser completado en menos de 120 horas, se planean pequeños hitos (usualmente cada dos semanas). Usando la secuencia generada en el paso anterior, el equipo extracta las actividades relacionadas con los entregables y lista las tareas en orden de prioridad. Aquellas con mayor prioridad serán desarrolladas primero y las de menor prioridad son almacenadas en un “backlog”. El backlog se visita en la siguiente reunión de planeación. Si se presenta un control de cambios y se generan nuevas tareas (entregables), el proceso se repite con el fin de priorizar, de manera objetiva, las tareas existentes. Las dependencias son analizadas en este paso y, de esta manera, se crea un cronograma de trabajo. En este proceso, es de vital importancia contar con la opinión de los dueños del producto, por lo cual se recomienda que asistan a las reuniones de planeación y den su opinión en cuanto a la prioridad de las tareas. Estas actividades son almacenadas en una herramienta de control de tareas y las actividades se secuencian de manera que se ejecuten antes del final del hito.

Como parte de este proceso, se realiza también una reunión de estimación. En esta reunión, cada entregable es analizado y se le asigna un tiempo de ejecución “ideal”. Como parte de la historia del proyecto, el tiempo real es anotado y la correlación entre el tiempo “ideal” y el tiempo “real” se extracta para ser usada en futuros proyectos.

El control del cronograma se realiza de dos maneras diferentes: por un lado, el gerente de proyecto es responsable de mantenerlo actualizado pero cada miembro del equipo de trabajo es responsable de actualizar su propia lista de tareas y anotar el tiempo utilizado. La herramienta de seguimiento debe permitir funciones de reporte por recurso y por hito, de tal manera que se puedan encontrar las fuentes de retraso y efectuar procesos de recuperación muy efectivos.

Como parte de este proceso, un miembro del equipo de control de calidad es asignado desde el inicio del proyecto y debe crear el plan de control de calidad del proyecto. Todo este proceso debe ser considerado dentro del esfuerzo requerido.

Los mini-proyectos usualmente funcionan mejor con equipos de trabajo pequeños. Incluso se ha encontrado que el uso de equipos virtuales es muy efectivo. Los miembros del equipo virtual están asignados a áreas funcionales, pero la asignación de los recursos es realizada por el gerente de proyecto con base en las habilidades y necesidades del proyecto. De esta manera, un recurso está usualmente asignado a varios mini-proyectos simultáneamente, haciendo un uso efectivo de su tiempo en función de su capacidad profesional. Es responsabilidad del gerente o los gerentes de proyecto que este recuso no esté sobre-asignado.

La comunicación es una de las áreas de mayor preocupación en los pequeños proyectos. Los documentos son parte integral del proyecto y, dentro del cronograma, siempre se debe presupuestar el tiempo para crearlos. Una herramienta muy poderosa que ha demostrado ser útil en este tipo de ambientes es el concepto de un “wiki” donde los documentos son almacenados de una manera abierta pero efectiva y, por definición, son creados por la persona responsable pero mantenidos por el equipo del proyecto. Otra herramienta útil en el proceso de comunicación son las reuniones cortas y efectivas (conocidas en ciertas metodologías como “scrum meetings”). Éstas son reuniones de 15 minutos (usualmente de pie y en un área abierta) donde cada miembro del equipo cuenta su avance de las ultimas 24 horas, qué espera hacer en las siguientes 24 horas y, lo más importante, si existe alguna circunstancia inesperada o perniciosa que afecte el progreso del proyecto. Estas reuniones diarias se complementan con una reunión semanal de 30 minutos con los clientes del proyecto en la cual se informan los progresos y se toman las decisiones requeridas.

Se han dejado fuera de esta discusión los procesos de costo, riesgo y administración de contratos. Usualmente, estos procesos no aportan mayor valor agregado al producto final en pequeños proyectos. Sin embargo, el gerente de proyecto debe estar muy vigilante en estas áreas y detectar cualquier anormalidad que pueda afectar el desarrollo del proyecto. Si la organización considera que alguna de estas áreas es de gran importancia, se deben seguir las políticas existentes al respecto. Por ejemplo, en el área de gobierno, se deben tener en cuenta los aspectos legales de la contratación.

Micro-Proyectos

Los micro-proyectos tienen una aproximación completamente diferente. Como se explicó anteriormente, las áreas de negocio responsables crean el alcance. Debido a su corta vida, realmente no se usan los procesos descritos. Sin embargo, debe haber un gerente de proyecto a cargo de la ejecución. La principal razón es que no es inusual que los recursos asignados a estos micro-proyectos estén también asignados, al mismo tiempo, a proyectos y mini-proyectos. En consecuencia, los gerentes de proyecto tienen un interés específico en que estos proyectos sean ejecutados y entregados a tiempo.

La práctica más común es que las tareas requeridas para completar un micro-proyecto se deben incluir como parte de una planeación y deben tener una prioridad asignada. De esta manera, los recursos tienen un tiempo garantizado para poder ejecutar lo necesario para entregar el producto final. Para algunas personas (por supuesto, contradiciendo de manera clara la definición de un proyecto comúnmente aceptada), los micro-proyectos se convierten en proyectos de duración infinita con un grupo de tareas incrementales que entregan pequeños resultados o mejoras a productos cada cierto tiempo. Esta aproximación ha demostrado ser altamente efectiva.

Los Resultados

El uso de este marco de trabajo para mini y micro proyectos ha sido adoptado por varias compañías de tecnología y desarrollo de software en todo el mundo en los últimos dos o tres años, con algunas variaciones menores. A pesar de que no se ha hecho una investigación formal para documentar las mejoras, algunos estimativos informales colocan la tasa de eficiencia (definida como un proyecto entregado dentro de un rango definido de fechas, asociadas a un sprint, unos hitos, más o menos unos días) cercana al 95%.

La efectividad de este marco también lleva a mejorar el número de mejoras que se pueden entregar en el producto en un tiempo determinado.

Lecciones Aprendidas

Como es de esperarse en compañías que ejecutan pequeños proyectos, la curva de aprendizaje es un poco dolorosa pero los resultados han probado que el esfuerzo lo vale. Éstas son algunas de las lecciones compartidas por empresas que han seguido este proceso de adopción:

  • Propiedad del proyecto: Incluso los proyectos más pequeños requieren algún grado de propiedad y responsabilidad. Un balance adecuado entre el gerente de proyecto y las áreas de negocio es clave cuando no se tienen muchos recursos y el tiempo es un factor importante.
  • Hay que mantener las cosas simples y prácticas: Los principios básicos de gerencia de proyectos pueden ser aplicados a cualquier proyecto, sin importar su tamaño. Sin embargo, las organizaciones deben ser muy cuidadosas de no generar un ambiente desproporcionado para la gerencia de pequeños proyectos. Debe usarse aquello que genera valor, nada más ni nada menos.
  • Herramientas: Incluso las herramientas que aparentemente son muy sencillas dentro del portafolio de ofertas para la gerencia de proyectos, son demasiado complejas para mini y micro proyectos. Se recomienda investigar este aspecto. Existen herramientas de código abierto muy interesantes. También resulta útil buscar herramientas con funcionalidades específicas (seguimiento de tareas, por ejemplo) como su gran fortaleza.
  • No se asusten al tratar de innovar: Es evidente que un marco de trabajo como el propuesto no sigue una metodología específica, sino ciertas líneas de pensamiento (excepto, por supuesto, los principios básicos propuestos por el PMI). Si hay algo que, tomando elementos de diversas metodologías, tiene sentido para las áreas de negocio y el tipo de proyectos que se ejecutan, será bienvenido. Los mejores resultados aparecen dos o hasta tres iteraciones posteriores al primer intento de colocar las piezas juntas.
  • Soporte ejecutivo: No hay manera de que un proceso, un estándar o una práctica sean exitosos si el equipo ejecutivo no se involucra de manera temprana. Especialmente, si el equipo ejecutivo es pequeño, encontrar el mensaje adecuado y mostrar resultados va a generar un soporte inmediato en toda la organización.

Una historia corta, Epílogo

“Afortunadamente,” me contaba después José, “no creí todo lo que me dijo mi jefe”. “Cuando fui a hablar con mercadeo, me comentaron que la aplicación no había sido probada en los computadores de la compañía y que alguien les había dicho que era muy probable que no funcionara por algún requerimiento técnico. Decidí volver a hablar con mi jefe.” Puesto que José es un excelente gerente de proyectos, hizo que mercadeo firmara un documento de una página donde se describía qué era lo que ellos esperaban al final del proyecto, habló con el departamento de TI y averiguó cómo era el proceso para instalar una nueva aplicación; contrató entonces un recurso externo para que hiciera una evaluación técnica de la herramienta y especificara los cambios requeridos en las estaciones de trabajo; logró que el fabricante entrenara a los usuarios en mercadeo y documentó el proceso para futura referencia. En dos semanas, mercadeo tenía su aplicación instalada y en funcionamiento. José, su jefe, el área de mercadeo y el equipo de TI de la compañía vivieron felices para siempre…

Cohn, M. (2005) Agile estimating and planning. New York, NY: Prentice Hall PTR.

Gorchels, L. (2003) The product manager's field guide: practical tools, exercises and resources for improved product management. New York, NY: McGraw-Hill.

Middleton, P., Sutton J. (2005) Lean Software Strategies. New York, NY: Productivity Press.

Phillips, J. (2004) IT project management: On track from start to finish. Emeryville, CA: McGraw-Hill/Osborne.

Project Management Institute. (2004) A guide to the project management body of knowledge (PMBOK®) (2004 ed.). Newton Square, PA: Project Management Institute.

Rakos, J. (2005) The practical guide to project management documentation. Hoboken, NJ: John Wiley & Sons.

Rowe, S. (2006) Project management for small projects. New York, NY: Management Concepts.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

© 2007, Ivan Daniel Rincon
Originalmente publicado como parte de las Actas del Congreso Global del PMI de 2007 – Cancún, Mexico

Advertisement

Advertisement

Related Content

Advertisement