La mayoría de los RFPs de software son escritos por personas que nunca han tenido que responder uno. El resultado es un documento que es demasiado detallado donde no importa y demasiado vago donde sí importa.
El error más común del RFP es poner los requisitos técnicos al frente antes del contexto. Un proveedor que lee una especificación técnica sin contexto no tiene idea de qué problema resuelve, quiénes son los usuarios o cómo se ve el éxito. Sin ese contexto, están optimizando para cumplir con la especificación, no para resolver el problema.
Comienza el RFP con una descripción en lenguaje claro del problema de negocio. ¿Quién tiene este problema, con qué frecuencia y cuánto les cuesta hoy?
Los compradores a menudo escriben RFPs que implican más certeza de la que realmente existe. Un proveedor que ve a un comprador reconociendo incertidumbre propondrá un enfoque que gestione esa incertidumbre — entrega en fases, una fase de discovery, puntos de decisión explícitos.
Los proyectos de software son esfuerzos conjuntos. Incluye: quién en tu equipo será el punto de contacto principal, qué tan rápido puede tu equipo revisar entregables, qué acceso tendrá el proveedor a tus sistemas, y cómo se toman las decisiones internamente.
Calificar a los proveedores por precio y años de experiencia produce un proceso que premia quien cotiza más bajo. Los factores que sí predicen el éxito: qué tan bien el proveedor diagnosticó el problema real, si su enfoque refleja las restricciones reales de tu contexto, y si las personas que harán el trabajo formaron parte del proceso de propuesta.
Un RFP que especifica cada decisión técnica no deja espacio para que un proveedor aplique su experiencia. Especifica resultados y restricciones, no detalles de implementación.
Tres patrones predicen proyectos problemáticos: una propuesta que acepta todos los requisitos sin calificación, un precio significativamente más bajo que todas las demás propuestas, y un equipo descrito diferente al equipo que realmente haría el trabajo.
%20(1)-2.svg)
