Por Mike Coyle

Las necesidades de los equipos de proyectos pequeños y disciplinados son en gran medida desconocidas y no atendidas en la comunidad de gestión de proyectos. Comenzamos nuestra empresa para llevar a las pequeñas equipos las personas, los procesos y la tecnología necesarios para que puedan aprovechar sus limitaciones y ofrecer valor a sus clientes de manera predecible y controlada. Demasiados equipos de proyectos pequeños se pierden en el ciclo de vida del proyecto o terminan sofocados bajo una capa pesada e inapropiada de supervisión burocrática que hace que la entrega del proyecto sea más lenta y dolorosa, pero no necesariamente reduce los riesgos tangibles de entrega. Estamos convencidos de que el futuro de la entrega de proyectos son los equipos pequeños y distribuidos. Tenemos la suerte de estar en una posición para acelerar esta tendencia a través de nuestro software, consultoría y redacción. A continuación, se muestra una entrevista imaginaria que destaca las ventajas de los equipos de proyectos pequeños.

¿No es mejor tener un equipo más grande en general?

No. Tener más personas en tu equipo no es como tener más dinero en el banco. Por ejemplo, los cuartetos de jazz no quieren ser orquestas cuando crecen. Son bestias diferentes. Si intentas dirigir un cuarteto de jazz como una sinfonía, obtendrás un mal jazz. Si diriges una orquesta de 20 músicos como una sesión de improvisación, terminarás con caos. Lo mismo ocurre con los equipos de proyectos. Si diriges un proyecto pequeño como un proyecto grande en miniatura, obtendrás… prácticamente lo que ves en los entornos corporativos todos los días. Es decir, demasiadas reuniones, mucha documentación de poco valor y otros gastos administrativos que obstaculizan la resolución de los problemas reales. No me malinterpretes, un equipo de 4 personas aún necesita seguir las reglas, pero es un libro diferente.

¿Por qué importa el tamaño de un equipo? ¿No hay mejores prácticas universales para la gestión de proyectos?

A nivel general, hay una serie de verdades universales que el Project Management Institute y otras organizaciones han categorizado y articulado de manera maravillosa. Sin embargo, cuando llega el momento de implementar tácticamente estas mejores prácticas, se observa todo el espectro de opciones de implementación, desde un exceso de burocracia hasta el caos estilo “Lejano Oeste”. En teoría, la práctica y la teoría son lo mismo. En la práctica, son profundamente diferentes. Por eso es tan importante tener una adhesión estricta a un proceso ligero. Como gestor de proyectos, quieres gastar tu capital de manera inteligente, aplicando documentación y otros protocolos relacionados con el proceso a las áreas específicas de riesgo del proyecto que sean relevantes para tu proyecto.

¿Qué tipos de cosas son más difíciles para los equipos pequeños, aparte de la falta de personal?

Hay tres desafíos generales para un equipo pequeño. En primer lugar, las distracciones y los gastos administrativos pueden ser una carga significativa de tiempo y atención. En segundo lugar, el cambio de contexto puede ser costoso, ya que los miembros de los equipos pequeños a menudo desempeñan múltiples roles. Por último, tener menos miembros del equipo para obtener información puede resultar en una menor diversidad de conocimientos en el dominio.

¿Existen ventajas que provienen de tener un equipo pequeño?

Ciertamente. Los equipos pequeños y efectivos comprenden la claridad ágil que se obtiene al tener pocas partes móviles. Tienen conversaciones en lugar de reuniones. Los equipos pequeños separan el trigo de la paja, ya que no hay lugar para los bajo rendimiento. Como resultado, he descubierto que los recursos más capacitados tienen más probabilidades de preferir trabajar en equipos más pequeños, ya que hay un poco de autoselección en juego. Por ejemplo, las estrellas del rock saben que los malos intérpretes están más interesados en ser la decimosexta persona en un equipo de 16 personas que la tercera persona en un equipo de 3 personas.

¿Qué necesidades especiales tienen los equipos pequeños?

Los equipos pequeños necesitan comportarse como equipos pequeños, no como versiones en miniatura de equipos grandes, porque la burocracia no se reduce de manera particularmente efectiva. Los equipos pequeños deben ser liderados por un gestor de proyectos que comprenda la dinámica de la entrega de proyectos en equipos pequeños. Específicamente, alguien que elija sus batallas cuidadosamente y no le importe ensuciarse las manos de vez en cuando. Además, los equipos pequeños deben utilizar las mejores herramientas disponibles, ya que no pueden permitirse resolver problemas de manera arbitraria.

¿Existen problemas particulares cuando los miembros del equipo están dispersos por todo el mundo?

Los equipos pequeños deben esforzarse por lograr la “transparencia de ubicación”, independientemente de la ubicación física del equipo. La tecnología colaborativa (y las prácticas diarias que respaldan los procesos colaborativos) deben emplearse tanto si los miembros del equipo están separados por un pasillo como por un océano.

¿De qué manera pueden los equipos pequeños trabajar de manera más efectiva para lograr grandes tareas?

Existen cuatro aspectos que impulsan la efectividad de los equipos pequeños: Planificación, Proceso, Automatización y Gestión de Activos. La planificación: los equipos pequeños deben centrar sus esfuerzos en comprender cómo encajan las partes móviles clave de su proyecto para que puedan categorizar y gestionar proactivamente el riesgo de entrega. Esto es mucho más importante que tratar de optimizar la distribución de la carga de trabajo en tu plan de proyecto, ya que no estás tratando de distribuir mucho trabajo entre recursos intercambiables en un equipo grande. Proceso: los equipos pequeños deben mantener una estricta adhesión a un proceso ligero. Los actos heroicos individuales no son escalables ni predecibles a largo plazo. Incluso los equipos pequeños deben seguir las reglas, pero deben asegurarse de que sea el libro correcto para ellos. Automatización: los equipos pequeños deben maximizar la cantidad de trabajo que no hacen y centrar sus esfuerzos en lo importante. Si no se puede evitar el trabajo, debe ser automatizado. Las computadoras son muy buenas haciendo cosas predecibles muy rápido. Gestión de Activos: los equipos pequeños deben gestionar sus datos importantes utilizando algún tipo de mecanismo de control de versiones. Un buen sistema de control de versiones actúa como una máquina del tiempo en caso de que los usuarios necesiten revisar y/o comparar versiones anteriores de un documento u otro artefacto, y como una caja fuerte para proteger una única versión actual de la verdad para cada activo del proyecto.

También encontré interesante el comentario de que los equipos grandes suelen ser bandas de equipos pequeños disfrazados, y me gustaría conocer tus pensamientos al respecto.

Inventamos esa frase para ayudar a los tomadores de decisiones a comprender la verdadera naturaleza y composición de sus organizaciones, y suavizar cualquier connotación negativa que el concepto de “equipos pequeños” tendría en organizaciones más grandes. Al final del día, los proyectos son discutidos por equipos grandes y completados por equipos pequeños (o grupos de equipos pequeños que trabajan juntos). Cualquier equipo puede tomar una decisión. Solo los equipos pequeños toman grandes decisiones. Cualquier equipo puede hacer trabajo. Solo los equipos pequeños hacen un trabajo eficiente. Es cierto que hay fuerza en los números, pero a veces esa fuerza radica en números pequeños.

Nota: El artículo anterior fue ligeramente modificado de su fuente original. Puedes encontrar el artículo original aquí: My PM Network Interview, or Tales from the Cutting Room Floor

Mike Coyle es cofundador de Botonomy LLC. Antes de fundar Botonomy, Mike pasó cinco años en Alliance Consulting en Filadelfia. Mike llegó a Alliance Consulting desde EDS para ayudar en el inicio y la gestión del Solution Center de Alliance. Mike tiene un MBA y una licenciatura en Contabilidad de La Salle University. Antes de embarcarse en una carrera relacionada con la tecnología, aprobó el examen