Algo que he notado recientemente es cómo las expresiones de interés (EOI) suelen convertirse en cartas de presentación genéricas. Las empresas copian y pegan de presentaciones anteriores, cambian el nombre de la compañía y esperan lo mejor. Pero en las licitaciones competitivas, lo genérico no gana: hay que demostrar que se entiende la oportunidad y que se aporta un valor diferencial.

Un colega del área de desarrollo de negocios compartió su historia de éxito con una EOI. Estaba compitiendo por un contrato gubernamental contra 20 competidores. En lugar de una respuesta estándar, incluyó perspectivas específicas sobre los desafíos del organismo y soluciones a medida. "No teníamos el precio más bajo", dijo, "pero demostramos que entendíamos su realidad. Ganamos."

¿El problema? Las EOI se tratan como obstáculos administrativos en lugar de herramientas de posicionamiento estratégico.

El proyecto arrancó un martes. Todos salieron de la reunión de inicio con buenas sensaciones: el cronograma parecía razonable, el presupuesto estaba aprobado y el proveedor daba muy buena impresión. Seis semanas después, el cliente estaba furioso. El proveedor había entregado exactamente lo que decía el SOW. Y ese era el problema.

El SOW describía productos entregables. No decía nada sobre resultados. El proveedor construyó lo que se le pidió. Simplemente no construyó lo correcto.

Hace poco revisé un plan de marketing impecablemente redactado pero completamente desconectado de la realidad. Prometía "volverse viral" sin presupuesto para promoción pagada. Proyectaba una penetración de mercado del 50% para una marca sin ningún reconocimiento. Cuando pregunté cómo medirían el éxito, respondieron: "lo sabremos cuando lo veamos."

Un director de marketing me contó algo similar: "Pasamos semanas diseñando una campaña brillante y obtuvimos el 2% de la respuesta que habíamos proyectado. Resultó que habíamos hecho muchas suposiciones sobre el comportamiento del cliente que no se basaban en nada real. No estábamos midiendo lo que importaba."

Eso es lo que ocurre cuando el marketing se convierte en ficción creativa en lugar de estrategia.

Algo que he observado en conversaciones con equipos de operaciones es que el mantenimiento suele ocurrir de forma reactiva, no proactiva. Un sistema se deteriora hasta que falla, y entonces se apresuran a repararlo. Mientras tanto, otros tres sistemas se están degradando en silencio, esperando su turno para colapsar.

Una gerente de instalaciones compartió su frustración: "Tenemos equipos que deberían recibir mantenimiento mensual, pero eso se pospone constantemente por urgencias. Luego el equipo falla en el peor momento posible, y nos enfrentamos a $200.000 en reparaciones de emergencia que habrían costado $5.000 si lo hubiéramos mantenido correctamente."

Ese es el verdadero costo de omitir la planificación del mantenimiento.

Vi cómo una empresa tardó meses en integrar dos sistemas que deberían haber tomado semanas. ¿El problema? Los dos equipos tenían versiones distintas de lo que significaba "enviar datos de pedido". Uno enviaba XML, el otro esperaba JSON. Uno incluía marcas de tiempo, el otro no. Uno enviaba datos parciales porque asumía que el otro sistema los buscaría por su cuenta.

Un arquitecto de sistemas me habló de un proyecto de integración muy doloroso: "Teníamos a los mejores desarrolladores de ambos lados, pero hicieron suposiciones opuestas sobre lo que debía hacer la API. Cuando descubrimos el desajuste, llevábamos seis semanas de trabajo. Tuvimos que reescribir un sistema entero."

Eso es lo que ocurre cuando las interfaces no se especifican con claridad.

Hace poco supe de un desastre de instalación. Una empresa implementó software nuevo durante el horario laboral sin contar con un plan de reversión. Cuando el proceso falló, no había forma de recuperarse y perdieron transacciones de clientes durante horas. El plan de instalación existía, pero estaba incompleto.

Un administrador de sistemas me contó su peor experiencia: "Instalamos hardware nuevo en nuestro servidor principal sin haber probado el procedimiento antes. A mitad del proceso, descubrimos que los controladores necesitaban actualizarse. Todo el sistema se cayó y estuvimos horas intentando volver a ponerlo en línea. Un plan de instalación adecuado lo habría detectado."

Ese es el precio de saltarse una planificación exhaustiva.

Algo que he observado recientemente es la brecha entre un gran plan estratégico y la ejecución real. Vi cómo una empresa dedicó meses a desarrollar una estrategia operativa brillante, para descubrir semanas después que nadie sabía cómo llevarla a la práctica.

Una directora de programas me contó su experiencia: "Teníamos un documento de estrategia impecable, con cronogramas y presupuestos. Pero al empezar la implementación, descubrimos que el calendario era poco realista, que algunas tareas dependían de otras de formas que no habíamos contemplado, y que la mitad del equipo creía tener prioridades distintas a las que especificaba el plan."

Eso es lo que ocurre cuando se omite la verificación de viabilidad de la implementación.

Hace poco trabajé con una organización sin fines de lucro que tenía dos propuestas de financiamiento. Una fue rechazada. La otra fue aprobada, con el 150% del monto solicitado. ¿La diferencia? La exitosa dedicó la mayor parte de sus páginas a explicar por qué importaban las prioridades del financiador, no por qué la idea de la organización era brillante.

Una amiga gestora de subvenciones me contó su descubrimiento: "Cuando dejé de escribir sobre nuestra organización y empecé a escribir sobre el problema comunitario que resolvemos, los resultados mejoraron de forma notable. Los financiadores no dan dinero por tu idea; lo dan para resolver problemas que les importan."

Esa es la verdadera lección sobre la redacción de propuestas de subvención.

El mes pasado hablé con un equipo de desarrollo sobre sus mayores arrepentimientos. El tema recurrente fue este: construyeron funcionalidades basadas en requisitos vagos y luego tuvieron que reconstruirlas dos veces cuando las necesidades reales quedaron claras. Cada reconstrucción costó tiempo y dinero.

Algo que compartió un product manager me quedó grabado: "Nuestros desarrolladores preguntaron qué debía hacer una funcionalidad, y nosotros dijimos 'que sea flexible.' Seis meses después, la funcionalidad estaba sobrediseñada, era confusa y nadie la usaba. Tendríamos que haber sido específicos sobre lo que necesitaba hacer."

Ese es el costo de los requisitos poco claros.

Vi cómo una empresa pasó tres meses desarrollando un producto que resultó ser técnicamente imposible con su infraestructura. Sin estudio de viabilidad. Solo entusiasmo y optimismo. El proyecto fue cancelado, y tres meses de trabajo se esfumaron.

Un amigo director de proyectos me contó algo similar que le ocurrió a su equipo: "Aceptamos una solicitud de un cliente sin verificar realmente si era viable. A mitad del desarrollo, descubrimos restricciones legales que lo hacían imposible. El cliente se enfureció y perdimos el contrato."

Eso es lo que pasa cuando se omite la evaluación de viabilidad.