¿Qué significa aportar valor en un proyecto?

En el artículo anterior explicamos una forma de establecer prioridades cuando no es posible realizar todo el trabajo previsto. Propusimos cinco criterios: valor, urgencia, riesgo, dependencias y esfuerzo. En este artículo nos centraremos en el primero de ellos y analizaremos qué significa aportar valor en un proyecto.

El valor es el criterio más importante, pero también uno de los más difíciles de definir: hablamos habitualmente de «aportar valor» o «centrarnos en lo que aporta más valor», sin tener siempre claro qué queremos decir con ello.

Pero el problema aparece cuando intentamos relacionar el valor con la entrega del proyecto. Para entender mejor la diferencia entre ambos, veamos un ejemplo concreto.

Una empresa de mantenimiento decide desarrollar una aplicación para mejorar la gestión de sus averías. Después de varios meses de trabajo, el equipo entrega todas las funcionalidades acordadas: programación de órdenes de trabajo, gestión de repuestos, geolocalización, reportes de servicio y firma del cliente.

La aplicación funciona, pero los técnicos apenas la utilizan y los tiempos de respuesta no han mejorado. La pregunta es inevitable:

El proyecto ha entregado el producto previsto, pero ¿ha aportado realmente valor?

La octava edición de la Guía PMBOK recoge esta idea al definir un proyecto como una «iniciativa temporal en un contexto único que se emprende para crear valor». El entregable deja de ser el propósito final: importa por los resultados que permite conseguir.

1. Del entregable al valor

Durante mucho tiempo, el éxito de un proyecto se ha relacionado con el cumplimiento del alcance, el plazo y el presupuesto. Y aunque siguen siendo criterios muy importantes, no bastan para saber si el proyecto ha merecido realmente la pena.

Para entender cómo se genera el valor, debemos considerar cuatro conceptos relacionados:

• El entregable es el producto, servicio o resultado producido por el proyecto. En nuestro ejemplo, sería la aplicación desarrollada para gestionar las averías.
• El resultado es el cambio que se produce cuando ese entregable empieza a utilizarse. La aplicación debería permitir que los técnicos dispusieran de información más completa y comunicaran con mayor rapidez el avance de cada intervención.
• Esto podría generar beneficios como una reducción de los errores, menos trabajo administrativo o tiempos de respuesta más cortos.
• Finalmente, podremos hablar de valor si esos beneficios justifican el tiempo, el esfuerzo y los recursos invertidos.

Por tanto, el valor no está en la aplicación, sino en las mejoras que permite obtener. Una aplicación terminada y técnicamente correcta puede ser un buen entregable, pero no necesariamente una solución valiosa.

2. El valor no significa lo mismo para todos

El valor no es una cualidad fija del producto. Depende de las necesidades, los objetivos y las expectativas de cada interesado:

• La empresa puede esperar que la aplicación reduzca los tiempos de respuesta y los costes administrativos.
• Para los técnicos, puede significar disponer de información completa, evitar llamadas innecesarias y comunicar fácilmente el resultado de cada intervención.
• Para el cliente, lo importante será que la avería se resuelva antes y conocer en todo momento su estado.

Además, el valor no siempre es económico. También puede consistir en mejorar un servicio, facilitar el trabajo, aumentar la seguridad o cumplir una obligación normativa.

Las diferentes expectativas de los interesados no tienen por qué ser incompatibles, pero obligan a acordar qué resultados son prioritarios. No se trata de incorporar todas las funcionalidades, sino de identificar cuáles contribuyen realmente a conseguir esos resultados.

3. Priorizar lo que más valor aporta

Una vez identificado el resultado que buscamos, conviene preguntarse qué parte de la solución puede contribuir antes a conseguirlo.

La aplicación prevista podría incluir planificación de rutas, geolocalización, gestión de repuestos, estadísticas, informes automáticos y firma del cliente. Sin embargo, ninguna de estas funciones tiene necesariamente la misma importancia para resolver el problema inicial.

La empresa podría comenzar por un flujo mucho más sencillo que permitiera a los técnicos consultar una intervención, acceder a la información necesaria, registrar el trabajo realizado y comunicar su finalización.

De esta forma, empezaría a obtener resultados sin esperar al desarrollo de toda la aplicación. También podría descubrir antes qué necesitan realmente los técnicos, qué dificultades encuentran y qué funciones inicialmente previstas aportan menos de lo esperado.

La prioridad no debería ser terminar cuanto antes todas las funcionalidades, sino poner en uso aquellas que puedan producir antes un resultado útil.

4. MVP: aprender antes de desarrollar la solución completa

Esta primera versión podría plantearse como un producto mínimo viable o MVP: la versión más reducida de una solución que puede utilizarse para comprobar con usuarios reales si responde al problema, obtener información y decidir cómo continuar.

En nuestro ejemplo, el MVP podría permitir a los técnicos:

• Consultar las intervenciones asignadas.
• Acceder a los datos de la avería.
• Añadir observaciones y fotografías.
• Comunicar la finalización del trabajo.

Otras funciones, como la planificación de rutas, la gestión de repuestos, las estadísticas o la firma digital, podrían incorporarse posteriormente si la experiencia demuestra que realmente son necesarias.

🧐 La palabra «mínimo» puede llevar a confusión. Un MVP no es un producto de baja calidad. Debe funcionar correctamente y permitir a los usuarios realizar las tareas esenciales, probar la solución y aportar información útil. En un MVP no se reduce la calidad, sino el alcance de la primera versión.

Su finalidad no es simplemente lanzar algo antes, sino comprobar si la solución resuelve el problema antes de comprometer más recursos.

El MVP no pretende demostrar cuánto puede construir el equipo, sino comprobar si está construyendo algo que merece la pena.

5. Cómo comprobar si estamos aportando valor

Antes de que los técnicos utilicen la aplicación, solo podemos estimar el valor que podría aportar. Su uso en situaciones reales permitirá comprobar si consigue los resultados esperados.

No hace falta crear un sistema de medición complejo, basta con definir algunos indicadores relacionados con el problema inicial y hacer un seguimiento:

• Porcentaje de técnicos que utiliza la aplicación.
• Tiempo necesario para gestionar una intervención.
• Número de errores provocados por información incompleta.
• Tiempo dedicado a tareas administrativas.

Estos indicadores permiten comprobar qué está cambiando, mientras que la opinión de los técnicos ayuda a entender por qué.

Que la aplicación permita consultar y cerrar una intervención demuestra que funciona.

Que reduzca errores y tiempos de respuesta demuestra que está generando el resultado esperado.

Con esta información podremos decidir qué funcionalidades desarrollar, modificar o descartar. Incluso podríamos llegar a replantear la solución inicial.

Conclusión

Aportar valor no consiste en completar más tareas ni en entregar todas las funcionalidades previstas, sino en conseguir resultados relevantes para los usuarios y la organización. Pero no todas las funciones tienen la misma importancia, por eso, es preferible comenzar por las que permiten obtener antes un resultado útil.

Un MVP permite poner esa primera versión en manos de los usuarios, comprobar qué sucede en la práctica y aprender antes de invertir en la solución completa.

La entrega, por tanto, no representa el final del proceso, sino el momento en el que podemos empezar a verificar el valor y decidir cómo continuar.

Antes de construir toda la solución, conviene hacerse una última pregunta:

¿Qué es lo mínimo que podemos entregar para empezar a obtener un resultado útil?

---