Las propuestas comparables empiezan con una descripción clara del encargo: 12 datos que conviene aportar

El Sourcing Playbook actual del Reino Unido señala que una especificación clara debe dar a los oferentes información suficiente para decidir de forma informada si quieren presentar una propuesta. También indica que, sin una comprensión común de los requisitos, resulta difícil relacionar los precios propuestos con los costes y resultados previstos por el comprador. [1]

La Government Commercial Function lo expresa de forma aún más directa: una buena especificación debe contener la información necesaria para que los proveedores calculen correctamente el coste y para que el comprador pueda comparar ofertas sobre una base equivalente. [2]

Al mismo tiempo, el Digital, Data and Technology Playbook británico advierte contra definir en exceso la solución. Recomienda centrarse en el usuario, el problema y el resultado esperado, dejando a los proveedores margen para proponer una forma eficaz de conseguirlo. [3]

La conclusión no es "describe todo con el máximo detalle posible". Una regla mejor es:

describe con precisión lo que debe ser común a todas las propuestas, no aquello que un especialista competente puede diseñar razonablemente por su cuenta.

Dos propuestas profesionales nunca serán idénticas, y no deberían serlo.

Comparabilidad significa que los especialistas responden al mismo problema con supuestos aproximadamente equivalentes.

Por tanto, deberían conocer de forma similar:

• el objetivo,
• el alcance,
• el punto de partida,
• el resultado esperado,
• las limitaciones importantes,
• el plazo,
• las responsabilidades del cliente,
• la forma de presentar el precio,
• los criterios con los que se evaluará la propuesta.

En cambio, pueden diferir en:

• el enfoque propuesto,
• el orden de las actividades,
• el método,
• la composición del equipo,
• las herramientas,
• la división en etapas,
• la forma de reducir riesgos.

Estas diferencias suelen aportar valor y deben seguir siendo visibles.

Empieza por el problema, no por una lista de funciones.

En lugar de:

"Necesito una aplicación con panel, notificaciones e informes."

prueba con:

"Actualmente cinco personas gestionan el proceso con hojas de cálculo y correo electrónico. Es difícil conocer el estado actual de cada caso, quién es responsable y cuál es la siguiente tarea. Queremos reducir el seguimiento manual y tener un único lugar con el estado actualizado."

La segunda descripción todavía no decide qué aplicación debe construirse.

Sí permite al especialista entender por qué existe el proyecto.

La Federal Acquisition Regulation para servicios basados en resultados recomienda describir el trabajo principalmente mediante los resultados requeridos, no mediante la forma de ejecución o el número de horas. En una declaración mínima de objetivos incluye elementos como finalidad, alcance, contexto, resultados requeridos y restricciones operativas. [4]

Por eso, describe qué debería ser posible al terminar el trabajo.

Por ejemplo:

• el usuario puede completar un proceso definido por sí mismo,
• el equipo puede ver el estado actual de todos los casos,
• el cliente recibe un análisis con prioridades,
• el sistema se traslada a un nuevo entorno y funciona según criterios acordados,
• el material preparado está listo para publicarse en un canal determinado.

El resultado debe ser suficientemente concreto para que ambas partes entiendan la dirección del trabajo.

No tiene por qué significar garantizar un resultado empresarial dependiente del mercado, del comportamiento de usuarios o de otros factores fuera del control del proveedor.

La misma necesidad final puede requerir esfuerzos muy distintos según el punto de partida.

Conviene indicar:

• qué existe ya,
• qué funciona y debe conservarse,
• qué no funciona,
• si existen archivos fuente,
• si existe documentación,
• si hay datos que migrar,
• si hay que trabajar sobre un sistema existente,
• qué materiales ya están preparados.

"Una nueva web" puede significar crear desde cero o reconstruir un sitio existente conservando contenido, direcciones, analítica, integraciones y datos.

Son trabajos diferentes aunque el resultado visual final pueda parecer parecido.

El alcance no debería obligar a los especialistas a adivinar qué partes del problema deben valorar.

Por ejemplo:

Incluido:

• análisis de la solución actual,
• diseño de nuevas vistas,
• implementación,
• migración de una parte definida de los datos.

Fuera del alcance:

• creación de contenido nuevo,
• compra de licencias,
• mantenimiento después del primer mes,
• reconstrucción del sistema de pagos.

Los Terms of Reference de ejemplo del Banco Mundial destacan que los requisitos y expectativas de los servicios deben expresarse con claridad y adaptarse al proyecto concreto. [5]

Los límites son especialmente importantes cuando dos tareas están relacionadas de forma natural y es fácil suponer que una incluye la otra.

Si esperas materiales o resultados concretos, indícalos.

Pueden ser:

• una solución funcional,
• archivos fuente,
• un informe,
• documentación,
• un diseño visual,
• un conjunto de materiales,
• configuración de un entorno,
• formación,
• una grabación,
• transferencia del código y de los accesos.

Palabras como "diseño", "análisis" o "implementación" pueden interpretarse de formas distintas.

Una lista común de entregables principales evita que una propuesta incluya mucho más que otra sin que la diferencia sea evidente por usar nombres de servicio parecidos.

No todas las limitaciones son detalles técnicos.

Pueden ser relevantes, por ejemplo:

• un sistema o entorno obligatorio,
• integración necesaria con un servicio concreto,
• requisitos de accesibilidad,
• normativa del sector,
• restricciones sobre almacenamiento de datos,
• obligación de conservar la infraestructura actual,
• dispositivos o navegadores concretos,
• trabajo en determinados horarios,
• acceso limitado a datos.

La FAR incluye expresamente restricciones operativas en la declaración de objetivos, mientras que el Digital, Data and Technology Playbook británico muestra por qué no conviene imponer una solución cuando no existe una limitación real. [4] [3]

Una buena regla es:

indica lo que el especialista no puede cambiar, pero no inventes una limitación solo porque estás acostumbrado a una solución concreta.

El especialista debe saber en qué nivel de colaboración puede basar su propuesta.

Indica si proporcionarás:

• una persona con capacidad de decisión,
• acceso a sistemas,
• materiales existentes,
• datos,
• cuentas de prueba,
• información del equipo,
• acceso a usuarios,
• contenidos,
• reuniones periódicas,
• respuestas dentro de un plazo definido.

Si todavía no sabes qué podrás proporcionar, también conviene decirlo.

La falta de acceso a datos, materiales o personas puede cambiar el método, el coste y el plazo. No es un detalle administrativo menor. Forma parte de las condiciones sobre las que se construye la propuesta.

No todas las fechas tienen el mismo carácter.

Distingue entre:

• fecha preferida de inicio,
• fecha límite no negociable,
• fecha vinculada a un acontecimiento externo,
• fecha orientativa,
• etapas que deben producirse en un orden concreto.

Si una fecha es realmente inamovible, explica por qué.

Si es flexible, indícalo también.

Esto permite al especialista proponer otro alcance, otro orden o una ejecución por etapas en vez de asumir que todas las fechas son requisitos absolutos.

No existe una regla única que diga que el cliente siempre deba revelar todo el presupuesto.

Según la situación, puedes indicar:

• presupuesto máximo,
• intervalo presupuestario,
• presupuesto para la primera etapa,
• que primero esperas una propuesta de alcance y después el precio,
• cómo quieres que se desglose el precio.

Para comparar, lo más importante es que los especialistas presenten el coste con una estructura parecida.

Por ejemplo:

"Indica por separado el precio de análisis, diseño, implementación y mantenimiento mensual. Señala también los costes de servicios externos que no estén incluidos."

Este formato se compara mucho mejor que cuatro cifras distintas que cubren cosas diferentes.

La incertidumbre no desaparece porque no se escriba.

Si no sabes:

• cuántos datos hay que migrar,
• si una interfaz externa permite realizar la operación necesaria,
• si todo el contenido estará preparado,
• si el código actual puede ampliarse razonablemente,
• si una aprobación necesaria llegará a tiempo,

dilo.

La guía de GAO sobre estimaciones fiables de costes destaca la importancia de hacer explícitos los supuestos y analizar el riesgo y la incertidumbre. [6]

Un buen especialista puede entonces:

• incluir una reserva,
• proponer una etapa inicial de análisis,
• valorar alternativas,
• indicar una condición que cambiaría el precio,
• negarse a fingir una precisión que todavía no puede alcanzarse honestamente.

Una incógnita explícita es mejor que un supuesto oculto.

Si ya sabes qué será importante para elegir, indícalo antes de recibir las propuestas.

Puedes valorar:

• adecuación del enfoque propuesto,
• experiencia con problemas similares,
• calidad de las pruebas de trabajos anteriores,
• realismo del calendario,
• disponibilidad,
• forma de gestionar riesgos,
• competencias de las personas que trabajarán realmente en el proyecto,
• precio,
• coste de mantenimiento,
• calidad de la comunicación.

La guía actual del Banco Mundial sobre Rated Criteria señala que los criterios no relacionados con el precio pueden incluir la calidad de la metodología y el plan de trabajo, la gestión de riesgos, la capacidad de ejecución y el personal clave. Los criterios se adaptan al encargo y se ponderan según su importancia relativa. [7]

Esto no significa que un encargo pequeño necesite una puntuación formal.

Basta con poder responder antes de enviar la solicitud:

"¿Qué, además del precio, hará que una propuesta sea mejor para mí que otra?"

Si realmente quieres comparar propuestas, pide a todos que respondan al mismo conjunto básico de preguntas.

Por ejemplo:

1. ¿Cómo entiendes el problema y el resultado esperado?
2. ¿Qué enfoque propones?
3. ¿Qué incluye exactamente tu propuesta?
4. ¿Qué queda fuera?
5. ¿Qué supuestos estás utilizando?
6. ¿Cuál es el calendario?
7. ¿Qué necesitas del cliente?
8. ¿Cuáles son los principales riesgos?
9. ¿Cuál es el precio y qué incluye exactamente?
10. ¿Qué experiencia o pruebas de trabajo similares son relevantes para este encargo?

En contratación pública, normalizar las respuestas, los criterios y la presentación del precio sirve precisamente para poder evaluar propuestas sobre una base común. La Government Commercial Function subraya la necesidad de aportar información suficiente para una valoración correcta y una comparación equivalente. [2]

Un formato común no debería borrar las diferencias entre especialistas. Solo debería hacer que esas diferencias sean visibles en los mismos lugares.

Depende del objetivo de la solicitud.

Compartir el presupuesto puede ayudar cuando:

• el alcance puede adaptarse a los fondos disponibles,
• quieres una recomendación del mejor enfoque dentro de un límite,
• quieres descartar rápidamente propuestas que no encajen con la realidad financiera del proyecto.

No compartir todo el presupuesto puede tener sentido cuando:

• primero quieres una opinión independiente sobre el alcance adecuado,
• todavía no conoces el coste realista,
• estás comparando distintos modelos de solución,
• el proceso requiere otra forma de recoger precios.

La peor situación no es necesariamente no dar presupuesto, sino no explicar qué tipo de respuesta económica esperas.

El especialista debe saber si debe dar una cifra, un intervalo, variantes, precios por etapas o supuestos necesarios para una estimación más precisa.

Una buena descripción del encargo no tiene que responder a todas las preguntas.

Puede decir honestamente:

• "Todavía no sabemos si el sistema actual puede ampliarse de forma segura.",
• "No conocemos el número exacto de registros que habrá que migrar.",
• "Todavía no hemos decidido si la segunda versión lingüística estará en la primera etapa.",
• "Necesitamos ayuda para elegir la mejor opción."

Es información valiosa.

La incertidumbre debe influir en la forma de preparar la propuesta, no desaparecer del documento.

En algunas situaciones, el mejor primer servicio no será la ejecución completa, sino una breve etapa inicial que termine con una decisión, un alcance más preciso o una estimación más fiable.

1. Dar a cada especialista un conjunto distinto de información.

2. Enumerar funciones sin explicar el problema y el objetivo.

3. No indicar qué existe ya.

4. Ocultar limitaciones que después cambian la forma de ejecución.

5. Pedir un único precio final sin explicar qué debe incluir.

6. Evaluar propuestas con criterios que ni tú habías definido previamente.

7. Confundir una descripción detallada del problema con imponer una solución detallada.

1. ¿He descrito claramente el problema y no solo la solución que imaginé?
2. ¿Está claro el resultado que quiero conseguir?
3. ¿El especialista entiende el estado actual?
4. ¿Está claro qué debe conservarse?
5. ¿Están claros los límites del primer alcance?
6. ¿He nombrado los entregables más importantes?
7. ¿He indicado las limitaciones reales?
8. ¿Está claro qué proporcionaré por mi parte?
9. ¿El plazo incluye información sobre su flexibilidad?
10. ¿El formato del precio permitirá comparar propuestas?
11. ¿He descrito abiertamente las principales incógnitas?
12. ¿Sé qué evaluaré además del precio?
13. ¿Responderán todos los especialistas a un conjunto parecido de preguntas?
14. ¿He dejado espacio para una solución mejor que la que yo había imaginado?

Una buena descripción del encargo tiene dos objetivos que parecen opuestos.

Debe ser lo bastante concreta para que varios especialistas valoren el mismo problema.

Y debe ser lo bastante abierta para que cada uno pueda proponer su propio enfoque, quizá mejor.

Un orden útil es:

problema -> resultado -> estado actual -> alcance -> entregables -> limitaciones -> responsabilidades del cliente -> plazo -> formato del precio -> incógnitas y riesgos -> criterios de elección -> formato común de respuesta.

Si al recibir las propuestas descubres que una persona ha valorado todo el proyecto, otra solo el análisis y una tercera ha supuesto integraciones adicionales, el problema quizá no esté en los presupuestos.

Puede que cada persona haya recibido un encargo diferente aunque todos recibieran el mismo texto.

[1] UK Government - The Sourcing Playbook
Abrir fuente

[2] Government Commercial Function - How to write a procurement specification
Abrir fuente

[3] UK Government - The Digital, Data and Technology Playbook
Abrir fuente

[4] U.S. Federal Acquisition Regulation - Subpart 37.6, Performance-Based Acquisition
Abrir fuente

[5] World Bank - Sample Consultants Terms of Reference
Abrir fuente

[6] U.S. Government Accountability Office - Cost Estimating and Assessment Guide, GAO-20-195G
Abrir fuente

[7] World Bank - Rated Criteria
Abrir fuente

Nota metodológica: las fuentes proceden principalmente de la contratación pública y la gestión de costes. No se presentan como reglas directas para un mercado privado de especialistas. El artículo utiliza solo los principios que realmente respaldan: claridad de requisitos, enfoque en resultados, supuestos y riesgos explícitos, información de precios comparable y evaluación de la calidad con criterios adicionales al precio.