Necesita gestionar los proyectos digitales para obtener resultados, no para obtener resultados

¿Cuándo termina un proyecto? Para la mayoría de nosotros, parece bastante sencillo: cuando enviamos el producto o lanzamos el servicio. Pero tenemos que dar un paso atrás y considerar lo que realmente significa «hecho».

La mayoría de los equipos de negocios trabajan para crear una salida. Pero el hecho de que hayamos terminado de hacer una cosa no significa que vaya a crear valor económico para nosotros. Si queremos hablar del éxito, tenemos que hablar de resultados, no solo salidas. Y a medida que el mundo se sigue digitalizando y casi todos los productos y servicios se basan más en el software (o al menos se integran con él), esta necesidad se hace aún más fuerte.

Por ejemplo, podemos pedirle a un proveedor que cree un sitio web para nosotros. Nuestro objetivo podría ser vender más de nuestros productos en Internet. El vendedor puede crear el sitio web, entregarlo a tiempo y dentro del presupuesto e incluso hacer que sea bonito a la vista y fácil de usar, pero puede que no logre nuestro objetivo, que es vender más de nuestros productos en Internet. El sitio web es el resultado. El proyecto puede estar «hecho». Pero si el resultado (vender más productos) no se ha conseguido, entonces no lo hemos conseguido.

La mayoría de las empresas gestionan los proyectos en términos de resultados, no de resultados. Esto significa que la mayoría de las empresas se conforman con «hecho» en lugar de con hacer el arduo trabajo de centrarse en el éxito.

Definir hecho como exitoso

En algunas situaciones, estas ideas son lo mismo o tienen una relación tan clara y bien entendida que bien podrían ser lo mismo. Este es el caso con frecuencia en la producción industrial. Por la forma en que se diseñan y fabrican los productos industriales, ya sabe que cuando su línea de producción produzca coches modelo T, puede estar razonablemente seguro de que funcionarán según lo diseñado. Y gracias a los años de historial de ventas, puede estar bastante seguro de que tendrá éxito: venderá aproximadamente la cantidad de coches que esperaba. Se puede perdonar a los directivos que trabajan en este contexto por pensar que su trabajo es simplemente terminar de crear algo.

Sin embargo, con el software, la relación entre hemos terminado de construirlo y tiene el efecto que pretendíamos está mucho menos claro. ¿Nuestro sitio web recientemente rediseñado fomentará realmente compartir, por ejemplo, o el rediseño tendrá consecuencias no deseadas? Es muy difícil saberlo sin crear y probar el sistema. Y, a diferencia de la producción industrial, no fabricamos muchos ejemplares de un solo producto. En cambio, estamos creando un sistema único (o un conjunto de sistemas interconectados que se comportan como un solo sistema) y, a menudo, no sabemos si lo que estamos creando funcionará según lo previsto hasta que terminemos.

Este problema de incertidumbre, combinado con la naturaleza del software, significa que gestionar nuestros proyectos en términos de resultados simplemente no es una estrategia eficaz en el mundo digital. Sin embargo, nuestra cultura y herramientas de gestión están configuradas para funcionar en términos de resultados.

Uso de la alternativa a la producción: resultados

El viejo cliché del marketing es cierto: los clientes no quieren un taladro de un cuarto de pulgada. Quieren un hoyo de un cuarto de pulgada. En otras palabras, les importa el resultado final y no les importan realmente los medios. Lo mismo ocurre con los gerentes: no les importa cómo logren sus objetivos empresariales, solo quieren alcanzarlos.

En el mundo de los productos y servicios digitales, la incertidumbre se convierte en un actor importante y rompe el vínculo entre la perforadora de un cuarto de pulgada y el pozo de un cuarto de pulgada. Algunos directivos intentan superar los problemas causados por la incertidumbre planificando cada vez con más detalle. Este es el impulso que lleva a documentos detallados de requisitos y especificaciones, pero, como hemos llegado a entender, esta táctica rara vez funciona en el software.

Resulta que este problema —la forma en que nuestros planes se ven interrumpidos por la incertidumbre y la falacia de responder con planes cada vez más detallados— es algo que los comandantes militares han entendido durante cientos (si no miles) de años. Han desarrollado un sistema de liderazgo militar llamado mando de misión , una alternativa a los rígidos sistemas de liderazgo que especifican con gran detalle lo que deben hacer las tropas en la batalla. Mission Command es un sistema flexible que permite a los líderes fijar metas y objetivos y dejar la toma de decisiones detallada en manos de las personas que luchan. Escribiendo El arte de la acción, Stephen Bungay traza estas ideas tal como se desarrollaron en el ejército prusiano en el siglo XIX y describe el sistema que esos líderes desarrollaron para hacer frente a la incertidumbre del campo de batalla.

El mando de la misión se basa en tres principios importantes que guían la forma en que los líderes dirigen a su pueblo.

• No ordene más de lo necesario ni planifique más allá de las circunstancias previsibles.
• Comunique a cada unidad la mayor intención que sea necesaria para lograr el propósito.
• Asegúrese de que todos conserven la libertad de decisión dentro de los límites.

Para nuestros propósitos, esto significa que dirigimos a nuestros equipos especificando el resultado que buscamos (nuestra intención), permitiendo a nuestros equipos perseguir este resultado con un gran grado de discreción (pero no ilimitada) y esperando que nuestros planes tengan que ajustarse a medida que los persigamos.

Caso práctico: Poner esto en práctica

En 2014, la Fundación Taproot quería crear un servicio digital que conectara a las organizaciones sin fines de lucro con profesionales cualificados que quisieran donar sus servicios. Piense en ello como un servicio de búsqueda de pareja para voluntarios. Taproot tuvo que trabajar con vendedores y al final eligió nuestra empresa para el proyecto.

En nuestras primeras conversaciones, los líderes de Taproot describieron el sistema que querían crear en términos de sus funciones: Tendría una forma de que los voluntarios se inscribieran, una forma de que los voluntarios enumeraran sus habilidades, una forma de que las organizaciones sin fines de lucro buscaran voluntarios en función de estas habilidades, etc. Nos preocupaba esta lista de funciones. Era una lista larga y, aunque cada artículo parecía razonable, pensamos que podríamos ofrecer más valor y más rápido con un conjunto de funciones más reducido.

Para alejar la conversación de las funciones, preguntamos: «¿Qué logrará un sistema exitoso? Si tuviéramos que demostrar que el sistema vale la pena invertir, ¿qué datos utilizaríamos?» Esta conversación dio lugar a respuestas claras y concretas. En primer lugar, el sistema tenía que estar en funcionamiento en una fecha específica, dentro de unos cuatro meses. La fundación participa en un evento anual para celebrar la industria, y los ejecutivos querían tener un éxito demostrado del que pudieran presumir ante los financiadores en ese evento. Preguntamos: «¿Qué hace en funcionamiento ¿quiere decir?» De nuevo, las respuestas fueron concretas: necesitamos que X participantes activos por parte de los voluntarios e Y participantes activos por parte de la organización. Porque el objetivo del servicio sería unir a los voluntarios con las organizaciones para que pudieran trabajar juntos en proyectos, deberíamos haber hecho Z coincidencias y un porcentaje determinado de esas coincidencias deberían haber dado lugar a proyectos terminados y exitosos.

Esta era nuestra métrica de éxito: X e Y participantes; Z coincidencias; porcentaje de proyectos finalizados. (De hecho, establecemos objetivos numéricos específicos, pero aquí utilizamos variables).

Luego, preguntamos: «Si podemos crear este sistema y alcanzar estos objetivos sin crear ninguna de las funciones de su lista de deseos, ¿está bien?» Fue una conversación más difícil.

Los ejecutivos que firmaron el contrato estaban preocupados, comprensiblemente. ¿Qué garantía tenían de que completaríamos el proyecto?

Este es el problema al que se enfrentan los ejecutivos y los directivos. Al negociar con los socios, están obligados a proteger sus organizaciones. Tienen que encontrar un lenguaje contractual que garantice que los socios cumplirán. Sin embargo, el problema con los contratos es que, para que funcionen, los gerentes se ven obligados a conformarse con la protección que encuentran en el lenguaje concreto de los rasgos: usted crea la característica A y le pagaremos la cantidad B. Pero esta certeza lingüística es una falsa esperanza. Solo garantiza que su proveedor llegue a «listo», es decir, «La función está lista». No garantiza que el conjunto de características que puede describir en un contrato le dé éxito. Por otro lado, es comprensible que los vendedores duden en apuntarse para lograr un resultado, sobre todo porque los proveedores rara vez controlan todas las variables que contribuyen al éxito o al fracaso del proyecto. Por lo tanto, ambas partes se conforman con un compromiso que ofrezca la seguridad de «hecho» y, al mismo tiempo, cree restricciones que tienden a predecir el fracaso en lugar de a crear la libertad que genera el éxito.

Nuestro contrato con Taproot, entonces, contenía no solo una lista de las características deseadas sino también una lista de los resultados deseados. Incluía: El sistema conectará a los voluntarios con las organizaciones [al siguiente ritmo]; permitirá a estas partes encontrarse, comunicarse bien entre sí e informar sobre el éxito de sus proyectos; lo hará a [los siguientes ritmos] y antes de [la fecha siguiente]; etc. Por supuesto, también había algo de jerga legal. Pero este compromiso —enumerar las características que considerábamos importantes, pero tener claros los resultados y acordar de antemano que los resultados son más importantes— es la clave para gestionar con resultados en lugar de con productos.

El equipo decidió que el hito más importante era poner en marcha el sistema. En lugar de esperar cuatro meses, la duración del proyecto, decidieron lanzarlo lo antes posible y emitirlo en directo para el público piloto en el plazo de un mes. Lanzaron una versión del servicio radicalmente simplificada, con muy pocas funciones automatizadas. El equipo de Taproot sabía que necesitaría más automatización si quería que el sistema escalara, pero también sabía que la automatización podría llegar más adelante. El lanzamiento anticipado logró dos objetivos. En primer lugar, garantizó que el equipo tuviera algo que mostrar a los financiadores en el evento anual. Era un objetivo de marketing y ventas muy importante. Pero el lanzamiento anticipado abordó un objetivo aún más importante: permitía al equipo aprender qué funciones tendría en realidad necesidad para operar el sistema a gran escala. En otras palabras, permitió al equipo establecer un ciclo de detección y respuesta, una conversación bidireccional con el mercado que guiaría el crecimiento del servicio.

Los planificadores del proyecto habían imaginado, por ejemplo, que los voluntarios cualificados necesitarían poder crear perfiles en el servicio. Las organizaciones consultaban entonces los perfiles para encontrar a los voluntarios que les gustaran. Resultó estar exactamente mal. Cuando el equipo intentó conseguir voluntarios para crear perfiles, respondieron con indiferencia. El equipo se dio cuenta de que, para que el sistema funcionara, los voluntarios tenían que estar motivados para participar; tenían que encontrar proyectos que les apasionaran. Para ello, el sistema necesitaba listas de proyectos, no listas de voluntarios. En otras palabras, el equipo tuvo que invertir la mecánica del sistema, porque los planes iniciales estaban equivocados.

Al segundo mes del proyecto, el equipo había creado el sistema con la mecánica revisada. Luego se concentraron en ajustar el sistema, identificar los detalles de los procesos empresariales necesarios y crear el software que respaldara esos procesos. ¿Cómo facilitaría el equipo a las organizaciones la publicación de sus proyectos? ¿Cómo se asegurarían los miembros del equipo de que los anuncios motivan a los voluntarios? ¿Qué tan sencillo podrían hacer el sistema de contactos? ¿Qué tan sencillo podrían hacer la agenda de reuniones? Al final del proyecto de cuatro meses, el equipo tenía un sistema que llevaba tres meses en funcionamiento y que superaba con creces los objetivos de rendimiento establecidos en el contrato.

Este proyecto funcionó porque el equipo siguió los principios del mando de la misión, que se basa en los resultados, no en los productos. Ofrezca a los equipos una estrategia y un conjunto de resultados que lograr, junto con un conjunto de restricciones, y luego deles la libertad de utilizar su conocimiento de primera mano de la situación para resolver el problema. Este enfoque del liderazgo de proyectos no es común, pero lo vemos con más frecuencia en los equipos de empresas emergentes y en las organizaciones más pequeñas. Ampliar el enfoque a varios equipos y a organizaciones más grandes puede ser un desafío difícil y sutil, que requiere un equilibrio cuidadoso entre la planificación central y la autoridad descentralizada. Pero se está convirtiendo rápidamente en un cambio necesario en nuestro mundo impulsado por el software.

Este post está adaptado del libro Harvard Business Review Press Detectar y responder: cómo las organizaciones exitosas escuchan a los clientes y crean nuevos productos de forma continua.