Las 7 preguntas que me hago
antes de aceptar cualquier
proyecto — y por qué nunca
las negocio.No importa si el cliente tiene presupuesto, urgencia y todo el sentido de apuro del mundo. Si estas preguntas no tienen respuestas honestas, no hay proyecto que valga. Esto es lo que aprendí en 15 años y más de una docena de sectores regulados.
McKinsey documentó que los proyectos donde el problema se define correctamente antes de buscar la solución tienen 2.4 veces más probabilidad de éxito. PMI calcula que por cada $1,000 millones invertidos en proyectos, $122 millones se desperdician por ejecución deficiente — y la causa más frecuente no es la tecnología ni el presupuesto. Es que nadie hizo las preguntas correctas al inicio.
Hay algo que aprendí trabajando en entornos regulados — CNBV, COFEPRIS, IATA, ASEA, SENASICA, BANXICO — que no aprendí en ningún libro: los problemas más costosos de resolver no son los técnicamente más complejos. Son los que nadie definió correctamente antes de empezar a resolverlos. He visto proyectos de arquitectura empresarial con presupuestos de millones naufragar porque el directivo que lo aprobó y el equipo que lo ejecutó nunca tuvieron la misma conversación sobre qué era lo que se estaba resolviendo. He visto implementaciones de core bancario paralizadas no por fallas técnicas sino porque nadie había mapeado el proceso de negocio que el sistema debía soportar. He visto iniciativas de IA construidas sobre datos que nadie había verificado — modelos entrenando sobre la versión incorrecta de la realidad. He visto implementaciones de ERP, CRM, SCM, entre otras que se encarecen y no solucionan lo esperado. He visto monolitos y muchos secuestros de información, procesos y tecnología. En todos esos casos, alguien aceptó el proyecto sin hacer las preguntas que habrían revelado el problema real antes de que el dinero empezara a moverse. Yo también lo hice al inicio, al inicio. Aprendí rápido de esto.
Por qué estas preguntas — y por qué en este orden
No son preguntas de screening. Son un diagnóstico. La diferencia importa porque un proceso de screening filtra clientes según criterios del consultor. Un diagnóstico revela la realidad del problema según lo que existe — y con frecuencia lo que revela es diferente de lo que el cliente cree que tiene. La primera conversación con un cliente potencial es la información más valiosa de todo el proyecto: el cliente habla sin filtros, sin la presión de que el proyecto ya está en marcha, sin el sesgo de haber invertido meses en una dirección. Si no sé escucharla correctamente, pierdo la única oportunidad de ver el problema sin el ruido que lo rodeará después.
Trabajo en sectores donde el margen de error tiene consecuencias regulatorias, operacionales y financieras directas. En fintech regulado bajo CNBV, un sistema de monitoreo PLD mal diseñado es una sanción. En farmacéutica bajo COFEPRIS, un proceso de trazabilidad con huecos es un riesgo de retiro de producto. En aviación bajo IATA, una falla en el sistema de operaciones es un incidente de seguridad. En esos contextos, la pregunta correcta no es un lujo metodológico. Es el primer control de riesgo del proyecto.
La primera cosa que el cliente describe siempre es el síntoma. La app se cae en quincena. El reporte de morosidad llega tarde. Los clientes se quejan del tiempo de atención. Los costos de cloud subieron 40% sin explicación. Eso es lo que hace que el problema sea visible. Pero el síntoma y el problema raramente son la misma cosa.
En doce años trabajando en más de quince sectores regulados, he aprendido que el problema real suele estar dos o tres niveles más abajo del síntoma inicial. La app que se cae en quincena no tiene un problema de infraestructura — tiene un problema de arquitectura de escalamiento que nadie diseñó para la carga predecible. El reporte de morosidad que llega tarde no tiene un problema de velocidad de proceso — tiene un problema de datos que no fluyen correctamente entre tres sistemas que nadie integró. Encontrar el problema real toma entre quince y cuarenta minutos de las preguntas correctas. Y cambia completamente qué se tiene que hacer.
McKinsey documentó que el 85% del valor en resolución de problemas complejos está en el diagnóstico correcto — no en la solución. El consultor que llega con la solución antes de entender el problema ya decidió cuál es el problema que su solución resuelve. Eso no es diagnóstico. Es venta.
Esta pregunta tiene dos partes y ambas importan por igual. La primera: ¿quién tiene el ownership? La segunda, que casi nunca se hace: ¿está dispuesto a ejercerlo? He visto proyectos perfectamente diseñados morir porque el directivo que los aprobó no estaba dispuesto a tomar las decisiones difíciles que el diseño requería. El ownership sin disposición de ejercerlo produce exactamente lo que Gallup documenta: el 27% de los managers globalmente está comprometido con su trabajo — y ese número cayó tres puntos en un año. El proyecto cuyo dueño no está comprometido con él es un proyecto que vive de los recursos del equipo técnico hasta que ese equipo se agota.
En entornos regulados, esta pregunta tiene consecuencia directa. En una implementación de sistema de PLD bajo CNBV, el Oficial de Cumplimiento que no tiene ownership real sobre el proyecto produce un sistema que técnicamente funciona y regulatoriamente es un riesgo. Porque las decisiones de configuración de alertas, de umbrales de monitoreo, de criterios de escalación requieren a alguien que entienda tanto el marco regulatorio como el proceso de negocio — y que tenga la autoridad para decidir cuando los dos entran en tensión. Si esa persona no existe o no está comprometida, el proyecto necesita ser rediseñado antes de comenzar.
Esta pregunta produce la respuesta más reveladora de las siete — y la que más frecuentemente cambia el alcance del proyecto antes de empezar. En quince años trabajando con datos en sectores regulados, he aprendido que las instituciones sobreestiman sistemáticamente la calidad de sus datos y subestiman el trabajo que requiere llevarlos a un nivel operacional.
La razón es simple: los datos malos producen resultados que parecen correctos durante mucho tiempo. El reporte que sale todos los meses con los mismos números puede estar procesando datos con errores de clasificación que nadie ha detectado porque el error es consistente. El modelo de crédito que funciona "bien" puede estar tomando decisiones sobre datos de ingreso que tienen una inconsistencia en la fuente que solo se descubre cuando se compara contra el estado de cuenta bancario real. En CNBV, en COFEPRIS, en IATA — los reguladores tienen acceso a los datos reales. La institución que lleva años reportando sobre datos incorrectos descubre el problema en la auditoría, no en la implementación.
Gartner estimó que los datos de mala calidad le cuestan a las organizaciones entre $9.7 y $15 millones anuales. Antes de proponer cualquier solución que dependa de datos — y en 2026, casi toda solución depende de datos — hago el diagnóstico de calidad. Si los datos no están en condiciones, eso cambia el alcance, el tiempo y el costo del proyecto. Y es mejor saberlo antes de firmarlo que descubrirlo tres meses después.
Esta pregunta es la que más diferencia mi trabajo de quien no ha operado en entornos regulados. En sectores como fintech (CNBV, Banxico, UIF), salud (COFEPRIS, NOM-024, LFPDPPP), aviación (IATA, AFAC, FAA), energía (ASEA, CRE), farmacéutica (COFEPRIS, SENASICA, FDA) o banca de desarrollo — la solución técnicamente correcta puede ser regulatoriamente inoperable. Y la solución que cumple la regulación puede ser técnicamente más compleja de lo que el cliente anticipó.
El costo de descubrir una restricción regulatoria durante la implementación es entre tres y cinco veces mayor que el costo de mapearla antes de comenzar. He trabajado en implementaciones donde una cláusula del artículo 115 de la Ley de Instituciones de Crédito cambió el diseño de un sistema que llevaba dos meses de desarrollo. He visto proyectos de trazabilidad farmacéutica rediseñarse completamente porque nadie había leído la NOM que aplica antes de definir la arquitectura de datos. Esos rediseños tardíos son costosos. Son evitables. Y la única forma de evitarlos es hacer la pregunta antes, no durante.
Fintech regulado, banca, aviación, farmacéutica, alimentos, retail, ecommerce, hospitalidad, electricidad, petróleo y gas, salud, seguros, manufactura, logística, sector público. En cada uno de esos sectores hay un marco regulatorio específico que define lo que la solución puede y no puede hacer. La experiencia real en entornos regulados no es un diferenciador de CV. Es la diferencia entre proponer una solución que se puede implementar y proponer una que va a colapsar en la auditoría.
Perfil comprobado · CNBV · COFEPRIS · SENASICA · IATA · ASEA · FDA · PCI-DSS · ISO 27001 · ITIL · COBIT · TOGAF · BIAN · DAMA DMBOK · ISO 42001 · ISO 31000 · NISTEsta es la pregunta que más incomoda a los clientes que llegan con certeza sobre lo que necesitan. Porque obliga a separar las condiciones del éxito de las suposiciones del éxito. La diferencia es que las condiciones se verifican y las suposiciones se creen.
En una implementación de core bancario, para que el sistema funcione tienen que ser verdad que los procesos de originación de crédito están documentados correctamente, que el equipo que va a operar el sistema tiene la capacitación adecuada, que los datos históricos se pueden migrar en el formato que el nuevo sistema requiere, y que el área de cumplimiento tiene los criterios regulatorios mapeados contra las funcionalidades del sistema. Cuántas de esas cosas son verdad hoy — antes de firmar el contrato — define si el proyecto dura seis meses o dieciocho. En mis quince años he aprendido que en la mayoría de los proyectos que fracasan, entre el 40% y el 60% de las condiciones de éxito no eran verdad el día que comenzaron. Y nadie lo preguntó.
Esta pregunta separa los proyectos de actividad de los proyectos de resultado. Un proyecto de actividad entrega: un sistema implementado, un proceso documentado, un equipo capacitado. Un proyecto de resultado entrega: cartera vencida reducida del 18% al 6% en nueve meses, tiempo de resolución de siniestros de 22 días a 5 días en seis meses, costo de nube reducido de $15,000 a $5,500 USD mensuales en doce semanas. La diferencia no es semántica. Es la diferencia entre poder evaluar si el proyecto funcionó y tener que confiar en que funcionó.
En sectores regulados, esta pregunta tiene una dimensión adicional: el regulador evalúa resultados, no actividades. A la CNBV no le importa que implementaste un sistema de monitoreo PLD — le importa que el sistema detecta las operaciones que debe detectar con la precisión que la norma requiere. A la COFEPRIS no le importa que rediseñaste el proceso de trazabilidad — le importa que cada lote tiene trazabilidad completa del insumo al paciente. Si el proyecto no puede definir el éxito en los términos que el regulador va a usar para evaluarlo, el proyecto no está bien definido.
Esta es la pregunta más directa y la que más directivos interpretan como descortesía cuando en realidad es respeto. Respeto por su tiempo y el mío. Porque he aprendido — después de proyectos donde la primera conversación con el director de tecnología fue seguida de cuatro meses de "alineación interna" antes de llegar a quien realmente decidía — que el proyecto que empieza sin el tomador de decisión real en la primera conversación frecuentemente termina siendo un proyecto diferente al que se diseñó.
En entornos regulados esto importa todavía más. La decisión de implementar un sistema de gobierno de datos que cruza todas las áreas de una institución financiera requiere a alguien con autoridad para que finanzas, tecnología, cumplimiento y negocio compartan la misma fuente de verdad. Esa autoridad rara vez vive en el director de tecnología. Vive en el CEO o en el consejo. Si el proyecto se diseña sin esa autoridad en la conversación inicial, se diseña para el nivel de poder que se tiene — que frecuentemente no es el nivel de poder que la solución requiere.
No es una pregunta sobre jerarquía. Es una pregunta sobre qué tan ambicioso puede ser el proyecto — y quién tiene que estar en la sala para que esa ambición sea ejecutable.
Lo que revelan las respuestas — y qué hago con ellas
Cuando las siete preguntas tienen respuestas honestas, una de tres cosas ocurre. La primera: el proyecto es exactamente lo que parecía y está listo para comenzar — lo que ocurre aproximadamente el 30% del tiempo. La segunda: el proyecto necesita redefinición de alcance, de objetivo, de condiciones de éxito o de quién está en la sala — lo que ocurre aproximadamente el 50% del tiempo. La tercera: el problema real no es el que describió el cliente y la solución que tienen en mente no lo va a resolver — lo que ocurre aproximadamente el 20% del tiempo.
Ese 20% es el más importante. No porque sea el más frecuente — no lo es. Sino porque es el que más valor produce decir en voz alta. El cliente que escucha "el problema que describes no es el problema real, y esto es por qué" en la primera conversación no pierde tiempo, no pierde presupuesto y no pierde meses de proyecto en una dirección incorrecta. Ese cliente, con frecuencia, regresa — porque la honestidad en la primera conversación es más rara de lo que debería ser.
No son un filtro para proyectos fáciles. Los proyectos más complejos que he ejecutado — migraciones de core bancario, implementaciones de plataformas de salud reguladas, transformaciones de sistemas de aviación, despliegues de IA en entornos de misión crítica — tienen respuestas difíciles a estas preguntas. Pero las tienen. Y tener respuestas difíciles es mejor que no tener respuestas.
No son un proceso de ventas. A veces revelan que el proyecto no necesita lo que el cliente creía que necesitaba. A veces revelan que hay una solución más simple, más barata y más rápida que la que se tenía en mente. Decir eso no es perder un contrato. Es ganarse la confianza del cliente — que vale más que el contrato.
No son rígidas. Se adaptan al sector, al contexto regulatorio, al tamaño de la organización y a la naturaleza del problema. Pero el principio que las une es invariable: el tiempo invertido en diagnosticar correctamente nunca es tiempo perdido. El tiempo invertido en ejecutar la solución incorrecta siempre lo es.
"Si tuviera una hora para resolver un problema, pasaría cincuenta y cinco minutos pensando en el problema y cinco minutos pensando en la solución."— Albert Einstein · Citado en HBR "Are You Solving the Right Problems?" · Thomas Wedell-Wedellsborg · 2017
Llevó años entender que el valor de estas preguntas no está en las respuestas que producen. Está en el proceso de buscarlas — en la conversación que generan entre el cliente y yo, en los detalles que emergen cuando alguien tiene que articular exactamente qué quiere resolver, con qué recursos, bajo qué restricciones y con cuál definición de éxito. Esa conversación es el proyecto. Todo lo que viene después es ejecución.
Y la ejecución, cuando el diagnóstico es correcto, resulta ser considerablemente más simple de lo que parecía cuando la urgencia era el único marco disponible para entender el problema.
Fuentes: PMI "Pulse of the Profession 2024" · McKinsey "Decoding Leadership" y "Problem-Solving Research" 2023–2024 · Gartner AI in Production Statistics 2025 · BCG "Flipping the Odds of Digital Transformation" 2024 · Deloitte Project Management Survey 2024 · Gallup State of the Global Workplace 2025 · HBR "Are You Solving the Right Problems?" Wedell-Wedellsborg 2017 · Harvard Business Review Knowledge Management Statistics 2026 · Gartner Data Quality Research 2024 · IBM Ponemon Cost of a Data Breach 2025 · Bloomfire Enterprise Intelligence Report 2025 · Stanford d.school Design Thinking Methodology · CNBV · COFEPRIS · IATA · ASEA · BANXICO · Marcos regulatorios: PCI-DSS · ISO 27001 · ITIL · COBIT · TOGAF · BIAN · DAMA DMBOK · ISO 42001 · NIST · ISO 31000.
No hay comentarios.:
Publicar un comentario
Nota: sólo los miembros de este blog pueden publicar comentarios.