RFP de software: cómo lo leen, evalúan y presupuestan los estudios

RFP de software: cómo lo leen, evalúan y presupuestan los estudios

Un RFP de software lo leen personas que deciden si dedicar una semana del tiempo de ingeniería sénior a una oferta que quizá no ganen. Durante los primeros quince minutos, un estudio normalmente ya ha decidido si responder, con qué nivel de seriedad y con qué riesgo de precio. En este artículo analizamos esa decisión desde el punto de vista del proveedor, para que pueda enviar un RFP de software que consiga propuestas mejores y precios más justos de las empresas que realmente le interesan.

Esta no es una guía sobre cómo redactarlo. En nuestra guía ya abordamos la estructura, las plantillas, la evaluación y la seguridad de los RFP de desarrollo de software. Aquí explicamos qué ocurre después de pulsar «Enviar».

Conclusiones clave

• Los estudios hacen una evaluación inicial rápida de los RFP de software. Un alcance poco claro, la ausencia de una referencia presupuestaria y la falta de acceso a las personas responsables de decidir son los motivos habituales por los que las empresas sólidas declinan participar.
• Los requisitos vagos no producen ofertas más baratas. Producen ofertas infladas, porque el proveedor tiene que presupuestar el riesgo de aquello que no puede ver.
• Los criterios de evaluación indican a los proveedores qué deben redactar. Si da más peso a la colaboración y al enfoque, recibirá propuestas sobre colaboración y enfoque.
• Un intervalo presupuestario, un periodo para preguntas y respuestas y una persona responsable identificada contribuyen más a la calidad de las propuestas que cualquier página adicional de requisitos.
• Una propuesta escasa de un proveedor suele ser una señal sobre su RFP, no solo sobre el proveedor.

Índice

• Qué debe conseguir un RFP de software
• Cómo se ve un RFP de software desde el punto de vista del proveedor
• Cómo evalúan los estudios los requisitos
• Cómo influyen los criterios de evaluación en las propuestas que recibe
• Cómo presupuestan los estudios un RFP de software
• Señales de alerta en un RFP que detectan los proveedores
• Qué revelan las propuestas sólidas sobre su RFP
• Cómo leer las respuestas de los proveedores de forma justa
• ¿Necesita realmente un RFP de software?
• Cómo abordamos un RFP de software en Ridiculous Engineering
• Envíe un RFP de software que merezca una respuesta
• Preguntas frecuentes
• Fuentes

Qué debe conseguir un RFP de software

Una solicitud de propuesta pide a varios proveedores ofertas formales basadas en los requisitos que usted define y resulta especialmente útil para proyectos complejos con elementos diversos, según la explicación general de TechTarget sobre los RFP. Esa definición describe el objetivo del comprador. El objetivo del proveedor es distinto: decidir si este es un proyecto por el que merece la pena presentar una oferta y, en caso afirmativo, cuánto costará realmente entregarlo.

Ambos objetivos convergen en el documento. Un buen RFP facilita los dos. Uno deficiente obliga al proveedor a adivinar, y las suposiciones se reflejan en el precio.

Cómo se ve un RFP de software desde el punto de vista del proveedor

Piense en la persona que lo recibe: un responsable principal, un líder de ingeniería o un arquitecto de soluciones que también tiene proyectos de clientes en curso. No lo lee por placer. Hace una evaluación rápida y las preguntas son siempre parecidas.

Las preguntas de la primera evaluación

1. ¿Existe un problema real y una persona responsable real? Un patrocinador empresarial identificado y un resultado definido indican que el proyecto llegará a buen puerto. Un documento que carece de ambos sugiere un ejercicio exploratorio.
2. ¿El presupuesto está en el mismo orden de magnitud que el alcance? Pocos compradores publican una cifra, pero un intervalo o un límite máximo permite al proveedor decir rápidamente si el trabajo encaja. Sin esa información, el proveedor puede omitir la licitación o presupuestar una versión grande del proyecto para cubrirse.
3. ¿La RFP es un proceso de selección real? Los estudios suelen detectar cuándo ya se ha elegido a un proveedor y la RFP no es más que documentación de compras. Tienden a rechazarlas, porque redactar una propuesta seria resulta caro.
4. ¿Podemos hablar con alguien? Un periodo de preguntas y respuestas, junto con una persona de contacto que pueda responder a preguntas sobre el producto, es una señal muy positiva.
5. ¿El calendario es razonable? Un plazo de respuesta de unos pocos días para una implementación compleja indica a los proveedores que el comprador valora más la rapidez de la documentación que la calidad de las respuestas.

Preparar una oferta requiere un esfuerzo considerable. Las hipótesis de descubrimiento, los esquemas de arquitectura, la asignación de personal y un modelo de precios requieren atención sénior. Las empresas que tienen mucha demanda solo dedicarán ese esfuerzo cuando las probabilidades sean razonables.

Por qué esto es importante para usted

Las empresas con más probabilidades de rechazar una RFP vaga suelen ser también las que tienen más opciones. Si desea recibir una respuesta a una RFP de software de un equipo con una trayectoria sólida, el documento debe respetar su tiempo. Eso significa menos secciones genéricas y más información que modifique el precio.

Cómo evalúan los estudios los requisitos

Los proveedores dedican la mayor parte de su tiempo de lectura a los requisitos, porque es ahí donde se oculta el coste.

El detalle ayuda, pero debe ser el adecuado

Los requisitos detallados ayudan a obtener respuestas comparables, y una RFP de software puede incluir de forma útil requisitos, información sobre el proveedor, referencias, licencias y costes del proyecto, tal como describe la guía del Project Management Institute sobre el proceso de RFP . Para un estudio, el detalle útil es el que modifica el esfuerzo:

• Cuántos roles de usuario existen y qué puede hacer cada uno
• Qué sistemas deben integrarse y si disponen de API documentadas
• Dónde se encuentran actualmente los datos y cuál es su calidad
• Qué obligaciones de cumplimiento normativo o accesibilidad se aplican
• Quién operará el software después del lanzamiento

Menos útil es una lista de funcionalidades de 200 líneas sin prioridades. Marcar los elementos como imprescindibles o deseables, idealmente redactados como historias de usuario con criterios de aceptación, permite al proveedor separar la implementación principal de la lista de deseos. Sin prioridades, un proveedor meticuloso presupuesta todo como obligatorio.

Prescribir la solución frente a describir el problema

Algunas RFP dictan la arquitectura, la pila tecnológica y las pantallas. Otras describen el problema y las medidas del éxito. Las directrices de PublicCode.net sobre la redacción de RFP recomiendan criterios orientados al problema que dejen el qué y el cómo en manos de los proveedores, lo que abre espacio para nuevos enfoques.

Desde la perspectiva del proveedor, se trata de una diferencia real. Si su RFP prescribe una solución, obtendrá cumplimiento, no criterio. Todos los proveedores dirán que sí a su diseño y las propuestas se parecerán entre sí. Si describe el problema, podrá ver cómo piensa cada equipo, que es la información que necesita para seleccionar un proveedor de software.

La excepción es una restricción estricta. Si debe operar en una nube específica, integrarse con un ERP concreto o cumplir una norma determinada, dígalo claramente. Las restricciones son útiles. Las preferencias disfrazadas de restricciones no lo son.

Cómo los criterios de evaluación determinan las propuestas que recibe

Los proveedores leen su rúbrica de puntuación como un briefing de redacción. Destacarán aquello que otorgue puntos.

Los sistemas de evaluación publicados muestran la variedad existente. Un tribunal superior de California puntuó las propuestas en una escala de 100 puntos que incluía experiencia, coste, asistencia, colaboración, disponibilidad presencial, un equipo dedicado y aceptación de las condiciones. Una asociación regional de observación oceánica, en su RFP de gestión de datos, ponderó las cualificaciones técnicas y el enfoque operativo con un plan de transición, con un 30 % cada uno, y la capacidad de establecer una alianza estratégica, con un 10 %.

Ninguno de los dos es necesariamente adecuado para usted. Lo importante es lo que el proveedor aprende de ellos. En el segundo ejemplo, el proveedor sabe que la forma en que asume el control y opera el sistema importa tanto como el código. La propuesta dedicará sus páginas a ello.

Una matriz ponderada transmite rigor

Una matriz de evaluación de requisitos, que puntúa las respuestas según elementos imprescindibles, deseables y convenientes ponderados, es una herramienta habitual, y la Guía de PMI lo describe como una comparación transparente basada en hojas de cálculo. Cuando un proveedor ve una en la solicitud de propuestas (RFP), entiende dos cosas: el comprador ha pensado cómo decidir y es menos probable que la decisión se reduzca a la cifra más baja.

El problema del peso del precio

La ponderación del coste es el factor que los compradores suelen calcular peor. Si asigna el 60 % de la puntuación al precio, recibirá ofertas agresivas de proveedores dispuestos a asumir que todo irá bien, y ofertas más meditadas de proveedores que prefieren no participar. Si lo sitúa en el 20 o el 30 %, invita a presentar propuestas que expliquen los riesgos con honestidad. Ninguno de los dos extremos es necesariamente incorrecto, pero debe actuar deliberadamente. Su ponderación es una instrucción sobre el tipo de proveedor que desea.

Cómo calculan sus precios los estudios para una RFP de software

Esta es la parte que menos ven los compradores. El precio de una respuesta a una RFP de software rara vez es un cálculo único. Es una estimación a la que se añade el riesgo.

Paso 1: Dimensionar el trabajo

El equipo divide el alcance en componentes, estima el esfuerzo de cada uno y tiene en cuenta el diseño, la ingeniería, las pruebas, la gestión del proyecto y la puesta en producción. Todo lo que la RFP deja poco claro queda asociado a una hipótesis.

Paso 2: Calcular el precio de lo desconocido

Cada ambigüedad se convierte en una hipótesis explícita o en una contingencia. Si la RFP dice «integrarse con nuestros sistemas existentes» y no especifica ninguno, el proveedor debe decidir si eso significa una única API sencilla o cinco bases de datos heredadas. Un proveedor prudente asume el caso más complejo, o incluye la hipótesis en la propuesta y calcula el precio de un proceso de cambios asociado.

Por eso los requisitos imprecisos no permiten ahorrar dinero. La incertidumbre no es gratuita y alguien paga por ella. El proveedor la incorpora al precio o se protege mediante el contrato.

Paso 3: Elegir un modelo comercial

El precio fijo, el tiempo y materiales, y los modelos por fases trasladan el riesgo a partes diferentes. Un precio fijo para un alcance poco claro traslada el riesgo al proveedor, que lo incorpora al precio. El modelo de tiempo y materiales lo devuelve al comprador, que obtiene flexibilidad y menos certeza. Muchos estudios proponen una breve fase de descubrimiento remunerada seguida de una estimación de construcción, porque sustituye las conjeturas por pruebas. Si su RFP lo prohíbe, está pidiendo a los proveedores que adivinen.

Para hacerse una idea de qué factores determinan las cifras del mercado, consulte nuestro desglose del coste del desarrollo de software a medida.

Paso 4: Decidir hasta qué punto competir

A continuación, el proveedor analiza el conjunto de participantes. Un intervalo presupuestario resulta útil aquí: permite al estudio proponer la mejor versión del proyecto dentro de sus posibilidades, en lugar de la versión ideal que no puede permitirse. Tras recibir las propuestas, el proceso suele continuar con una preselección, negociaciones de precios y técnicas, ofertas finales y definitivas, y la adjudicación basada en los criterios indicados, como señala TechTarget. Los proveedores lo saben. Algunos dejan margen para negociar. Otros presentan su cifra real y la mantienen. Indicar claramente si celebrará una ronda de ofertas finales y definitivas permite que todos jueguen con las mismas reglas.

Señales de alerta en las RFP que detectan los proveedores

Estos son los patrones que llevan a los estudios con experiencia a rechazar participar o a presentar ofertas defensivas. La mayoría son fáciles de corregir antes del envío.

Ninguno de estos aspectos es fatal por sí solo. Varios juntos indican a un estudio que debe dedicar su tiempo a otra cosa.

En cuanto al lenguaje contractual, las directrices del PMI sugieren que el área jurídica o de administración de contratos debería proporcionar el texto estándar para las instrucciones a los licitadores, los términos y condiciones y la confidencialidad. Hágalo pronto. Los términos que aparecen por primera vez en la fase contractual le cuestan buena voluntad y tiempo.

Lo que las propuestas sólidas revelan sobre su RFP

Si las propuestas de los proveedores que recibe son superficiales, genéricas o casi idénticas, resista la tentación de culpar primero a los proveedores. Revise la RFP.

• Propuestas genéricas normalmente significan que la RFP no ofrecía nada concreto a lo que responder.
• Precios muy diferentes normalmente significan que el alcance era ambiguo y que cada proveedor hizo suposiciones diferentes. Pídales que enumeren sus suposiciones y compárelas antes de comparar los totales.
• Pocas respuestas normalmente significan que había un problema de calendario, presupuesto o condiciones que las empresas serias detectaron.
• Propuestas que repiten sus requisitos sin comentarios significan que el proveedor no tenía margen, o motivo, para aplicar su criterio.

Una respuesta sólida a una RFP de software hace algo más útil. Cuestiona una suposición, propone una división en fases, plantea una pregunta difícil sobre una integración o señala que uno de los requisitos genera la mayor parte del coste. Esa es la propuesta que merece la pena encontrar, y es el tipo de propuesta para el que su RFP debe dejar margen.

Cómo leer las respuestas de los proveedores de forma justa

Una vez recibidas las respuestas, la perspectiva del proveedor puede ayudarle a evaluar.

1. Compare las suposiciones antes que los totales. Dos precios solo son comparables si se basan en el mismo alcance.
2. Fíjese en las personas. ¿Quién hará realmente el trabajo y participará en las preguntas y respuestas? Nuestro marco para elegir una empresa de desarrollo de software a medida profundiza en las señales relacionadas con el equipo y el proceso.
3. Valore la honestidad sobre los riesgos. Un proveedor que señala lo que podría salir mal normalmente le está mostrando la experiencia por la que está pagando.
4. Pida una sesión de trabajo. Una hora de conversación en directo con el equipo de ejecución le dice más que otra ronda de preguntas por escrito.
5. Mire el precio más bajo con desconfianza y el más alto con curiosidad. Pida a cada proveedor que explique detalladamente qué está incluido y qué no.

Los compradores del sector público deben cumplir reglas adicionales, que se explican en nuestra guía de contratación de software para organismos públicos.

¿Realmente necesita una solicitud de propuestas de software?

A veces, la respuesta honesta es no. Una solicitud de propuestas formal es adecuada para compras complejas y de alto riesgo, en las que varios proveedores cualificados podrían tener éxito y usted necesita un registro comparable y que pueda justificar. No resulta tan adecuada cuando aún está determinando qué debe crear, cuando el presupuesto es reducido o cuando ya confía en un socio. En esos casos, un breve servicio de descubrimiento o una conversación con dos o tres empresas preseleccionadas suele permitirle llegar más rápido a una respuesta mejor.

También conviene poner a prueba la premisa. Todo sistema personalizado conlleva una responsabilidad a largo plazo en materia de alojamiento, seguridad y actualizaciones, así que confirme que el desarrollo personalizado es la respuesta adecuada antes de iniciar el proceso. Nuestro artículo sobre software de código abierto frente a software propietario puede ayudarle a resolver esa cuestión.

Cómo abordamos una solicitud de propuestas de software en Ridiculous Engineering

Leemos las solicitudes de propuestas tal como se describe en este artículo e intentamos ser un buen proveedor participante. Buscamos el resultado empresarial, la persona responsable y las limitaciones, y le diremos claramente cuándo un requisito está incrementando los costes o cuándo una primera fase más pequeña le serviría mejor. Los clientes trabajan directamente con ingenieros sénior, desde el descubrimiento hasta la mejora a largo plazo.

Si está preparando el envío de una solicitud de propuestas de software, o ya tiene propuestas y quiere que alguien más las revise, nuestro equipo de desarrollo de software personalizado puede ayudarle, y nuestro servicio de consultoría y apoyo a la entrega de software incluye la revisión, desde la perspectiva del proveedor, del alcance y las estimaciones. El alcance del software personalizado se define individualmente y el precio se facilita previa solicitud. Los proyectos de sitios web sencillos parten de 3.000 USD, y el precio final depende del alcance y la complejidad.

Envíe una solicitud de propuestas de software que merezca una respuesta

Una solicitud de propuestas de software funciona mejor cuando está redactada para las dos personas que la leerán: el evaluador que la puntúa y el ingeniero que calcula su precio. Plantee a los proveedores un problema real, una indicación del presupuesto, las prioridades, una forma de hacer preguntas y criterios que coincidan con lo que usted valora. Recibirá menos propuestas, pero de mayor calidad, con precios que reflejen el trabajo y no las incógnitas.

Preguntas frecuentes

¿Por qué los buenos estudios de software declinan responder a una solicitud de propuestas?

Normalmente, porque el coste de preparar una oferta seria supera las probabilidades de ganarla. La falta de información presupuestaria, no tener la posibilidad de hacer preguntas, un plazo muy breve o la sospecha de que ya se ha preseleccionado un proveedor son los motivos más habituales. Si corrige esos aspectos en el documento, conseguirá que vuelvan a participar empresas sólidas.

¿Debería incluir mi presupuesto en una solicitud de propuestas de software?

Por lo general, merece la pena incluir un intervalo o un límite máximo. Esto permite a los proveedores proponer la mejor solución dentro de sus posibilidades, en lugar de hacer suposiciones, y facilita la comparación de las propuestas. Si no puede compartir una cifra, indique al menos si el proyecto cuenta con financiación y cómo se fijó el presupuesto.

¿Por qué son tan diferentes los precios de las propuestas de mis proveedores?

Lo más habitual es que cada proveedor haya partido de supuestos diferentes sobre un alcance poco claro, las integraciones o la responsabilidad tras la puesta en marcha. Pida a cada licitador que enumere sus supuestos y exclusiones, y después compare los totales en condiciones equivalentes.

¿Qué es una mejor y última oferta?

Es una ronda posterior a la evaluación inicial en la que se invita a los proveedores preseleccionados a ajustar sus precios o condiciones antes de adjudicar el contrato. TechTarget la incluye entre las posibles fases posteriores a la presentación de propuestas. Si tiene previsto llevarla a cabo, indíquelo en la solicitud de propuestas para que los proveedores calculen sus precios en consecuencia.

¿Puedo enviar una solicitud de propuestas para un trabajo que no he definido completamente?

Sí, pero estructúrela en torno al problema y solicite un enfoque por fases, idealmente con una etapa de descubrimiento remunerada. Exigir un precio fijo para un alcance indefinido da lugar a ofertas infladas o a que las empresas prudentes no presenten ninguna.

Fuentes

• ¿Qué es una solicitud de propuestas (RFP)? | TechTarget
• Gestión del proceso de solicitud de propuestas para la adquisición de software | PMI
• Redacción de solicitudes de propuestas, código de proceso para la contratación de software | PublicCode.net
• Tribunal Superior de California, condado de San Francisco: solicitud de propuestas de TI
• Solicitud de propuestas para el desarrollo, las operaciones y el mantenimiento del sistema SECOORA

Recomendado

• Solicitud de propuestas de desarrollo de software: plantilla, criterios de evaluación y guía de seguridad
• Desarrollar o comprar software: lista de comprobación para líderes
• Cómo elegir una empresa de desarrollo de software a medida: marco de 12 puntos
• Estimación de proyectos de software: guía práctica para gestores de proyectos