El cambio más importante que determina si una RFP tiene éxito o fracasa

La mayoría de las RFP fracasan por muchas razones.

Se retrasan, consumen más esfuerzo interno de lo planificado, los proveedores prometen de más, la entrega se queda corta y las discusiones comerciales se vuelven conflictivas a los pocos meses de la firma del contrato.

Pero según nuestra experiencia en organizaciones de medios, OTT, radiodifusión y publicaciones digitales, las RFP casi siempre fracasan en el mismo punto, mucho antes de seleccionar a los proveedores y, a menudo, incluso antes de que se emita el documento.

Fracasan en la forma en que se escriben los requisitos.

Si hay un cambio que el autor de una RFP puede realizar y que tiene un impacto desproporcionado en el resultado, es este:

Deje de pedir a los proveedores que describan capacidades y empiece a obligarles a demostrarlas mediante requisitos claros, inequívocos y medibles.

Todo lo demás en el proceso de RFP es secundario.

Por qué las RFP parecen justas pero generan malas decisiones

La mayoría de las RFP con bajo rendimiento no parecen defectuosas a simple vista. De hecho, a menudo parecen minuciosas, estructuradas y razonables.

Contienen preguntas sensatas como:

• Describa su capacidad de búsqueda dentro del CMS

• Explique cómo es compatible su plataforma con la localización

• Háblenos de su enfoque sobre la escalabilidad y el rendimiento

Estas preguntas parecen abiertas, colaborativas y amigables para el proveedor. También parecen informativas.

En la práctica, crean tres problemas sistémicos.

En primer lugar, invitan a la interpretación. Cada proveedor responde a una pregunta sutilmente diferente.

En segundo lugar, recompensan la fuerza del marketing en lugar de la realidad del producto. Las respuestas narrativas resultan convincentes incluso cuando la capacidad es parcial, se basa en la hoja de ruta o es un supuesto.

En tercer lugar, imposibilitan la comparación objetiva. Los debates de evaluación pasan rápidamente de las pruebas a las opiniones, y la puntuación se convierte en un ejercicio de persuasión en lugar de valoración.

Llegados a este punto, el proceso de RFP ya está comprometido, incluso si todos los demás pasos se ejecutan a la perfección.

El momento en que todo sale mal: requisitos subjetivos

El patrón de fracaso más común que vemos comienza con una sola palabra:

“Describa”.

Por ejemplo:

“Describa la función de búsqueda en el CMS”.

Este requisito no se puede puntuar objetivamente. No existe una definición compartida de éxito, ni un umbral medible, ni ninguna forma de determinar el cumplimiento con confianza.

Cada proveedor puede responder positivamente sin comprometerse con nada verificable.

Lo que sigue es predecible:

• Los evaluadores llenan los vacíos con supuestos

• Los talleres se utilizan para aclarar capacidades básicas

• Las negociaciones contractuales intentan cerrar el alcance de forma retroactiva

• La entrega revela expectativas que no coinciden

La RFP no fracasó porque los proveedores fueran deshonestos. Fracasó porque los requisitos les permitieron ser imprecisos.

Qué hacen de manera diferente los grandes autores de RFP

Los autores de RFP experimentados abordan los requisitos de una manera muy diferente.

En lugar de pedir a los proveedores que expliquen cómo funciona algo, comienzan definiendo qué debe cumplirse para que la solución sea aceptable.

Toman una necesidad de producto o una historia de usuario de alto nivel y la descomponen en un conjunto de declaraciones atómicas y comprobables.

Cada declaración es:

• Clara

• Inequívoca

• Medible

• Evaluable de forma independiente

Fundamentalmente, cada declaración solo permite una de dos respuestas: Verdadero o Falso.

Por ejemplo, en lugar de preguntar sobre la capacidad de búsqueda:

• La solución DEBERÁ permitir la búsqueda en todos los atributos de metadatos almacenados dentro del CMS para cualquier objeto dado.

• La solución DEBERÁ permitir la búsqueda en todos los idiomas definidos dentro de un artículo multiidioma.

• La solución DEBERÁ devolver resultados en menos de dos segundos para conjuntos de datos de hasta X millones de objetos bajo condiciones normales de funcionamiento. (¡Y no olvide definir qué son condiciones normales de funcionamiento!)

No hay margen para la interpretación. O la capacidad existe, o no existe.

Este enfoque cambia por completo la naturaleza de la RFP.

Por qué los requisitos binarios transforman los resultados

Cuando los requisitos se escriben como declaraciones objetivas en lugar de indicaciones narrativas, suceden varias cosas de inmediato.

Las respuestas de los proveedores se vuelven más cortas y precisas. El lenguaje de marketing desaparece porque ya no ayuda.

Las brechas de capacidad surgen pronto. Los proveedores se ven obligados a ser explícitos sobre las limitaciones, dependencias o elementos de su hoja de ruta.

La puntuación se vuelve más rápida y defendible. Los debates de evaluación se basan en pruebas en lugar de opiniones.

Los talleres pasan a tratar sobre validación y profundidad, no sobre aclaraciones básicas.

Lo más importante es que los contratos resultan más fáciles de negociar. La matriz de requisitos ya define la capacidad mínima aceptable, lo que reduce la ambigüedad y el riesgo de disputas.

Esta es la forma más eficaz de reducir las solicitudes de cambio posteriores, las fricciones comerciales y las decepciones en la entrega.

Traducir historias de usuario en requisitos, sin condicionar el futuro

Una de las preocupaciones más comunes al redactar requisitos muy específicos y medibles es que limiten demasiado la solución.

Esta preocupación es válida, pero no es motivo para aceptar requisitos imprecisos. Es una señal de que los requisitos deben escribirse con un propósito claro.

Los requisitos específicos y objetivos no deben describir cómo se construye una solución. Deben definir el comportamiento que debe cumplirse, dejando deliberadamente margen para la evolución, la reconfiguración y los cambios futuros.

Esta distinción es fundamental.

Los requisitos mal redactados consolidan los supuestos actuales:

• Prescribiendo arquitecturas internas

• Imponiendo patrones de implementación

• Integrando las limitaciones organizativas actuales como verdades permanentes

Los requisitos bien redactados hacen lo contrario. Definen resultados que respaldan un enfoque de arquitectura para el cambio.

Por ejemplo:

En lugar de:

• La solución DEBERÁ utilizar la tecnología X para permitir la búsqueda multilingüe.

Es preferible:

• La solución DEBERÁ permitir la búsqueda en todos los idiomas definidos dentro de un artículo multiidioma, sin requerir un desarrollo personalizado para cada idioma adicional.

En lugar de:

• El CMS DEBERÁ configurarse con un modelo de contenido fijo definido en la implementación.

Es preferible:

• El CMS DEBERÁ permitir que los usuarios autorizados amplíen y modifiquen los modelos de contenido sin cambios de código ni un nuevo despliegue de la plataforma.

Incluso en ambos casos, el requisito sigue siendo binario y comprobable, pero conserva la libertad de adaptación.

Así es como se gestiona el cambio futuro de manera responsable. No se está prediciendo en qué debe convertirse la plataforma. Se está garantizando que pueda convertirse en otra cosa cuando el negocio inevitablemente cambie.

Las historias de usuario de alto nivel siguen desempeñando un papel importante. Expresan la intención y la dirección. Pero el mecanismo de evaluación sigue siendo el conjunto de requisitos, redactado para probar la capacidad de comportamiento, no las preferencias de diseño.

Lograr este equilibrio es difícil. Requiere experiencia saber qué limitaciones protegen al negocio y cuáles simplemente protegen la forma de pensar actual.

Ese criterio marca la diferencia entre los requisitos que envejecen bien y los que quedan obsoletos antes de firmar el contrato.

Por qué escribir excelentes requisitos es realmente difícil

Hay una razón por la que este enfoque rara vez se ejecuta bien.

Escribir requisitos específicos, claros, medibles y objetivos no es una tarea administrativa. Es una disciplina analítica que se sitúa en la intersección del pensamiento de producto, la ingeniería de sistemas, la realidad operativa y el riesgo comercial.

En la mayoría de las organizaciones, sencillamente no vemos a muchas personas capaces de hacer esto de manera constante.

Por este motivo, las organizaciones que ejecutan programas complejos de plataformas y medios de comunicación a menudo recurren a especialistas en RFP y licitaciones cuando la decisión conlleva un riesgo a largo plazo.

Los autores de los requisitos deben ser capaces de:

• Comprender las necesidades del usuario sin copiar las historias de usuario de forma literal

• Traducir los objetivos comerciales abstractos en un comportamiento del sistema concreto

• Anticipar la escala, los casos extremos y los modos de fallo

• Eliminar la ambigüedad sin limitar excesivamente la entrega

• Escribir declaraciones que sean comprobables, defendibles y listas para el contrato

Esa combinación de habilidades es poco común. Como resultado, los requisitos a menudo se escriben en comités, se diluyen mediante concesiones o se delegan en equipos que no cuentan con la experiencia necesaria. El resultado es predecible: documentos con buenas intenciones que no logran proteger al negocio.

Esta es también la razón por la que los requisitos rigurosos a menudo generan incomodidad a nivel interno. Obligan a tomar decisiones antes de lo que muchas organizaciones están acostumbradas. Exponen la incertidumbre. Eliminan la red de seguridad que proporciona un lenguaje impreciso.

Por qué todo lo demás sigue importando... pero no tanto

Los plazos importan. La gobernanza importa. La comunicación importa. La equidad importa.

Pero nada de esto puede compensar unos requisitos deficientes.

Un proceso de RFP perfectamente ejecutado pero basado en requisitos ambiguos seguirá produciendo un resultado deficiente. Un proceso menos elegante pero basado en requisitos rigurosos y objetivos a menudo tiene éxito a pesar de las imperfecciones en otros aspectos.

Esta jerarquía resulta incómoda, especialmente en entornos liderados por el departamento de compras. Pero refleja la realidad.

Si cambia una sola cosa, cambie esto

Si está a punto de emitir una RFP, revísela con una sola pregunta en mente:

¿Se puede puntuar cada requisito de forma objetiva sin debate?

Si la respuesta es no, ahí es donde debe centrar sus esfuerzos.

Hacer esto bien requiere tiempo y disciplina. Exige resistirse al lenguaje impreciso y obligar a definir la claridad antes de lo que resulta cómodo.

La recompensa es significativa.

Spicy Mango mantiene marcos de RFP y bibliotecas de requisitos muy completos para plataformas OTT, de streaming y de publicación digital, desarrollados a partir de la experiencia real de entrega. Licenciamos material de referencia que ha traducido cientos de requisitos funcionales y no funcionales de alto nivel en miles de declaraciones distintas, claras y medibles. Esta profundidad es una de las razones por las que organizaciones de medios de primer nivel nos contratan para dar forma y ejecutar programas de transformación estratégica, no simplemente para gestionar las compras, sino para definir cómo es realmente el éxito a nivel de requisitos. Si desea acelerar este trabajo sin sacrificar el rigor, póngase en contacto con nosotros para ver cómo se trabaja bien en la práctica.