Human in the lead: El algoritmo propone, el humano dispone

En un modelo Human in the Lead, el humano define el propósito: establece qué problema se quiere resolver y qué resultados se esperan. La IA potencia las capacidades: analiza información, propone alternativas, automatiza tareas y genera recomendaciones. El humano es quien toma las decisiones; evalúa las propuestas de la IA con criterio, experiencia y contexto. El humano asume la responsabilidad: responde por las decisiones y sus consecuencias. La tecnología complementa, no reemplaza; permite que las personas se concentren en actividades de mayor valor.

Entonces, debemos diferenciar claramente entre tres conceptos:

• Human in the Loop: el humano interviene en determinados momentos del proceso.

• Human in the Lead: el humano dirige, establece el propósito y conserva el liderazgo.

• Human in Command: el humano mantiene el control absoluto y la autoridad sobre el sistema.

En las organizaciones que están incorporando inteligencia artificial, el enfoque Human in the Lead ayuda a evitar cinco riesgos cruciales:

1. Delegar decisiones críticas completamente a los algoritmos.

2. Perder el criterio profesional por confiar excesivamente en la IA.

3. Deshumanizar las relaciones con clientes y colaboradores.

4. Automatizar procesos sin comprender realmente el problema de fondo.

5. Confundir mera eficiencia tecnológica con generación real de valor empresarial.

El modelo Human in the Lead, aplicado hoy en las organizaciones y especialmente en la gestión de proyectos, opera bajo esta lógica:

1. El Delivery Manager lidera: define prioridades, objetivos, restricciones, estrategia y criterios de éxito.

2. La IA potencia: identifica desviaciones, predice riesgos, analiza presupuestos, propone escenarios y genera informes ejecutivos.

3. Las personas deciden: el equipo y sus líderes evalúan las recomendaciones, negocian alternativas y toman decisiones estratégicas.

Considero que Human in the Lead debe convertirse en un principio fundamental para el futuro de la gestión de proyectos. En mi caso ya la utilizó para muchas de las actividades diarias, como el seguimiento a los proyectos, valoraciones técnicas y como asistente. La evolución no debería ser pasar de Project Manager a IA Manager, sino pasar de un gestor que dedica gran parte de su tiempo a controlar actividades, actualizar cronogramas y elaborar informes, a un verdadero líder que utiliza la IA para potenciar su capacidad de anticipación, análisis y toma de decisiones. En otras palabras: no se trata de poner humanos a gravitar alrededor de la inteligencia artificial, sino de poner la inteligencia artificial al servicio estricto de las personas.

La quimera del proyecto híbrido: Cómo terminar con lo peor de dos mundos

Nos encontramos en la época en que el cliente quiere construir un entregable utilizando "lo mejor de los dos mundos" en proyectos. Deliran con las bondades de los proyectos predictivos —hablan de alcance, costo y tiempo fijos—, pero a la vez exigen que la construcción se realice de manera adaptativa utilizando metodologías ágiles, buscando una flexibilidad y adaptabilidad mas con el deseo que con la realidad. Sin embargo, mi experiencia revisando estos escenarios me demuestra otra realidad.

Es cierto que los proyectos híbridos son hoy una de las tendencias más fuertes en gestión porque prometen combinar el enfoque tradicional con el agile. En el papel, es un ecosistema donde algunas partes se gestionan de forma planificada y secuencial, y otras se manejan con flexibilidad e iteraciones; la premisa es que no todo el proyecto debe usar la misma metodología. Del enfoque predictivo, los híbridos suelen conservar los cronogramas base, presupuestos definidos, hitos, gestión contractual, gobierno corporativo, control de riesgos, documentación formal y fechas regulatorias. Del enfoque adaptativo, incorporan iteraciones cortas, entregas frecuentes, priorización continua, feedback constante, refinamiento del backlog, equipos autónomos y adaptación al cambio.

Actualmente, la mayoría de las empresas grandes NO trabajan 100% agile puro ni 100% waterfall puro. Lo que domina es el híbrido, simplemente porque las organizaciones necesitan control financiero y regulatorio, pero también velocidad y adaptación. Las PMO ahora mezclan métricas ágiles y tradicionales, usan Jira + MS Project + Power BI, manejan roadmaps adaptativos y gobiernan releases en vez de proyectos rígidos.

Sin embargo, muchas empresas fallan estrepitosamente porque mezclan metodologías sin la menor claridad, crean un exceso de ceremonias, no definen quién toma las decisiones o sostienen un doble gobierno donde lo ágil y lo tradicional compiten a muerte.

Dentro de los problemas que devoran a este tipo de proyectos, podemos mencionar:

• Confusión metodológica: Es el problema más frecuente. El equipo no sabe qué se maneja bajo Agile, qué bajo Waterfall, quién aprueba ni cómo medir el avance. Ahí es donde aparecen los famosos eufemismos: “somos ágiles, pero…”, “hay sprint, pero todo ya está definido” o “hacemos daily, pero nada puede cambiar”. ¿El resultado? Caos operativo, frustración y pérdida absoluta de velocidad.
• Doble gobierno: Sucede muchísimo en la banca y en los grandes corporativos. El proyecto termina sepultado bajo ceremonias Agile, comités tradicionales, reportes de PMO, estatus ejecutivos, dashboards y aprobaciones múltiples. El equipo pasa más tiempo reportando que construyendo.
• Stakeholders con expectativas bipolares: Algunos esperan fechas exactas, alcance cerrado y un cronograma rígido, mientras el equipo Agile pretende iterar, ajustar el backlog y cambiar prioridades. Los choques son constantes.
• Agilidad falsa (“Fake Agile”): Una epidemia muy común hoy en día. La empresa se llena la boca diciendo ser Agile, pero todo está previamente definido, no existe autonomía, no se puede cambiar nada y todo requiere aprobación. Solo cambian los nombres: la reunión ahora es “ceremony”, el jefe es “scrum master” y el plan es “roadmap”. La cultura sigue siendo totalmente tradicional.
• Problemas de priorización: En los híbridos suele haber demasiados stakeholders, prioridades cambiantes, presión política y urgencias de negocio. El backlog se vuelve incontrolable, especialmente en programas de gran envergadura.
• Sobrecarga al equipo: El equipo termina obligado a cumplir con la velocidad de una entrega ágil, pero arrastrando la documentación predictiva, las fechas rígidas y los reportes corporativos del modelo tradicional. Los resultados son predecibles: burnout, baja moral y una alta rotación.
• Métricas incompatibles: El mundo predictivo mide porcentaje de avance, cumplimiento de cronograma y desviación presupuestal. El ágil mide valor entregado, velocity, lead time y flujo. Muchas empresas intentan mezclarlas a la fuerza y generan reportes que son un monumento a la incoherencia.
• Dependencias organizacionales: El equipo de desarrollo puede pretender ser muy ágil, pero las áreas de infraestructura, seguridad, arquitectura, compras, legal y aprobaciones siguen funcionando al ritmo lento y predictivo de siempre. Al final, el cuello de botella jamás está en el desarrollo.
• PMs y líderes no preparados: Muchos managers saben de waterfall pero ignoran el agile, o viceversa, conocen de agilidad pero no tienen idea de gobernanza corporativa. El híbrido exige dominar ambas capacidades, y ante esa carencia, muchas iniciativas van directo al fracaso.
• Tailoring mal hecho: Muchas organizaciones mezclan procesos sin el menor criterio; copian frameworks, agregan ceremonias innecesarias y crean una burocracia híbrida. Terminan con lo peor de ambos mundos: la lentitud del waterfall sin la verdadera flexibilidad del agile.

Las empresas más maduras están entendiendo, por fin, que no existe una metodología “religiosa” perfecta, que el contexto manda y que el éxito depende más del diseño operativo y del liderazgo que del framework de moda. Por eso ahora se habla mucho de delivery models, flujo, product operating model, lean governance y adaptive delivery, más que de simplemente sentarse a "hacer Scrum".

Medir y se os dará

Los proyectos se enredan, en su mayoría, por la falta de control y monitoreo. Las mediciones son esenciales y, sin embargo, muchas veces se obvian o ni siquiera se definen desde el inicio. Una buena práctica, sin lugar a dudas, es tener claras y establecidas las métricas con las que se hará el control del proyecto desde el primer día.

Medir en los proyectos es fundamental porque permite gestionar de manera efectiva los recursos, el tiempo, los entregables y los resultados. Decirlo parece sencillo, pero no siempre lo es en la práctica, sobre todo en proyectos con alcances complejos y cierto grado de incertidumbre.

¿Por qué medir?

• Permite tomar decisiones informadas. Sin mediciones, todo queda en percepciones. Los datos objetivos son los que muestran si el proyecto va por buen camino o si necesita ajustes.

• Controla el avance real vs. lo planeado. Así se identifican desviaciones en cronograma, costos o calidad, y se pueden aplicar medidas correctivas antes de que los problemas crezcan.

• Evalúa el desempeño del equipo. Medir evidencia quién está entregando resultados, qué tareas se estancan y por qué. Esto facilita reasignar funciones o brindar apoyo donde se necesita.

• Fortalece la rendición de cuentas. Con indicadores claros, cada miembro del equipo sabe qué se espera de él y por qué se le mide.

• Facilita el aprendizaje y la mejora continua. Se mide, se corrige, se aprende y se mejora. Sin métricas no hay forma de saber si las acciones fueron efectivas.

• Justifica inversiones y decisiones. Ante stakeholders, clientes o directivos, los datos respaldan la toma de decisiones.

Cuando no se mide, como gerentes de proyecto podemos:

• Perder el control del proyecto.

• Tomar decisiones subjetivas.

• Desmotivar al equipo por falta de claridad.

• Repetir los mismos errores.

• Y, lo más grave, perder la confianza de los stakeholders en la ejecución.

Qué medir según el tipo de proyecto

Proyectos de Tecnología 

Categoría	Métrica	Descripción
Avance	Velocidad (Story Points/Sprint)	Cuánto trabajo entrega el equipo en cada iteración.
Calidad	Tasa de errores (bugs/sprint o release)	Mide la calidad del producto entregado.
Entrega	Lead Time / Cycle Time	Tiempo desde que inicia una tarea hasta su entrega.
Valor	Feature Completion Rate	% de funcionalidades clave entregadas frente a lo planeado.
Satisfacción	Encuesta de usuario (NPS)	Nivel de satisfacción del cliente o usuario final.
Costo	Burn Rate	Presupuesto consumido semanal o mensualmente.

Proyectos de Infraestructura 

Categoría	Métrica	Descripción
Avance físico	% de obra ejecutada	Ejecución real vs. cronograma.
Avance financiero	% de presupuesto ejecutado	Gasto real vs. planeado.
Tiempo	Variación de cronograma (SPI)	Índice de adelanto o atraso.
Costo	Variación de costos (CPI)	Valor ganado vs. costo real.
Seguridad	Incidentes por mes	Indicador crítico en obra.
Calidad	Reprocesos o defectos	Errores que impactan tiempo y costo.

Proyectos Sociales 

Categoría	Métrica	Descripción
Cobertura	Nº de beneficiarios alcanzados	Personas que reciben el servicio o beneficio.
Impacto	Cambio en indicadores sociales	Ej.: reducción del desempleo, aumento de escolaridad.
Participación	% de participación comunitaria	Nivel de involucramiento de la comunidad.
Satisfacción	Encuesta a beneficiarios	Percepción del cambio o mejora.
Eficiencia	Costo por beneficiario	Inversión por persona impactada.
Sostenibilidad	Continuidad de resultados	Si los logros se mantienen tras el proyecto.

Reglas de oro para medir en cualquier proyecto, medir y se os dará, tener siempre presente:

• Líneas base claras.

• Definir la frecuencia de medición (quincenal, mensual).

• Usar herramientas visuales: dashboards, tableros, informes.

Como salir de un proyecto en la eterna crisis

Los proyectos en eterna crisis requieren de una intervención en todos los frentes, pero a eso se le debe agregar la atención y el deseo de todos los stakeholder incluyendo sponsor para tomar decisiones en el momento adecuado, una comunicación clara y frentera en la que no se realicen vetos de parte del cliente permitirá tener mejores resultados, acciones para la intervención que incluyen: 

Pausar para diagnosticar, debemos entender qué está fallando realmente, en ese pare se busca realizar una radiografía del proyecto: Debemos entender qué está fallando realmente. Esta pausa busca realizar una radiografía completa del proyecto: objetivos, entregables, presupuesto, equipo, roles, cronograma, riesgos y problemas actuales.  El objetivo es diferenciar síntomas de causas raíz (por ejemplo: una “falta de entregas” puede deberse a un mal liderazgo y no necesariamente a problemas técnicos). En este punto es fundamental realizar entrevistas rápidas con el equipo, los stakeholders y los usuarios, con el fin de obtener diferentes perspectivas. Si no hacemos este diagnóstico, el proyecto continuará atrapado en un ciclo constante de desgaste y permanecerá en una crisis permanente. Entre las herramientas a utilizar para diagnosticar, Matriz de causa raíz (Ishikawa), Canvas del proyecto, Sesiones de retrospectiva con todo el equipo.

Redefinir el propósito y los entregables mínimos: Es probable que se deban buscar victorias tempranas, entregables que puedan ser visibles y que garanticen esas victorias pequeñas que ayuden al equipo a ganar confianza y al cliente a tener visibilidad del trabajo que ha pagado durante meses. Para esto se debe alinear expectativas y establecer un camino viable, revisar si el objetivo original sigue siendo válido, definir un entregable mínimo de valor que puedas entregar en el corto plazo (4–8 semanas) y negocia con los stakeholders un “pivote controlado” del proyecto: menos alcance, más foco. Como consejo clave  “Haz menos, pero bien. Luego crece.”

Reestructurar el equipo y la forma de trabajar: En las entregas anteriores he dicho que los proyectos en eterna crisis requieren poner en orden y crear condiciones para ejecutar,   por eso es parte importante revisar el equipo y hacer luego una reasignación de roles según fortalezas reales del equipo. Se debe designar un líder claro y empoderado (project manager o delivery lead). Implementa una metodología concreta y ligera (Scrum, Kanban, Scrumban), todo esto debe ir acompañado de un ritmo de trabajo fijo: dailies, sprint reviews, retro. Algo que seguramente se viene haciendo mal. Como herramienta, es importante tener un tablero visible (Jira, Trello, ClickUp) para que todos vean avances, bloqueos y prioridades.

Implementar control de avances y rendición de cuentas, es importante medir para controlar, de esto depende el avance claro y poder hacer una rendición de cuentas al cliente, la idea es recuperar la confianza a través de resultados concretos, para ello se deben establecer entregas quincenales o mensuales, incluso parciales. El gerente del proyecto debe aplicar principios de gestión por valor ganado (qué prometí vs. qué entregué). Se exige la rendición de cuentas claras (qué hizo cada responsable, qué se bloqueó y por qué). Pasamos a  medir lo que importa, Velocidad (story points entregados),  SPI (índice de rendimiento de cronograma), Stakeholder satisfaction (encuesta simple cada mes).

Crear una cultura de aprendizaje, no de castigo, se debe evitar que nos vuelva a pasar, por eso es importante el aprendizaje en todos los stakeholder y miembros del equipo. Después de cada enregable, se deben hacer retrospectivas serias, no simbólicas, retros que generen planes de acción cumplibles por el equipo. Se deben documentar los errores, aprendizajes y mejoras aplicadas, y algo muy importante, celebra los pequeños logros ayuda a reparar la moral de un  equipo vapuleado. 

“No salvas el proyecto solo con más esfuerzo, sino con mejor dirección.”

Causas y consecuencias de un proyecto en eterna crisis

Un proyecto que se encuentra en eterna crisis suele compartir causas fundamentales, que van desde su concepción hasta la deficiencia en el control y seguimiento. A menudo, da la impresión de que el proyecto avanza siempre y cuando se pueda facturar mensualmente, sin que existan hitos claros que se estén cumpliendo.

Las reuniones de seguimiento, que al inicio se realizan de forma protocolaria, se transforman en escenarios de confrontación, con gritos y reclamos, cuando la situación se agrava y los interesados (stakeholders) sienten que los acuerdos no se están respetando.

A continuación, analizamos algunas causas comunes:

• Mal diseño inicial (objetivos poco claros o inalcanzables): El proyecto se presenta como un reto ambicioso, con plazos que parecen inviables. Sin embargo, en un principio, todos asienten y se muestran optimistas sobre la posibilidad de cumplir algo que, a todas luces, es irreal. La falta de seguimiento de hitos es recurrente, y los planes se incumplen una y otra vez.

• Falta de gobernanza: En este tipo de proyectos, la gobernanza es deficiente. Al inicio, pueden existir demasiadas cabezas o muy pocas; luego, en medio de la crisis, el proyecto carece de una estructura de gobierno clara que establezca los límites y defina roles y responsabilidades de manera inequívoca.

• Intervención excesiva de un stakeholder sin disciplina de gestión: Un interesado se convierte en un micromanager, inmiscuyéndose en el detalle de las actividades y exigiendo informes constantemente. El equipo, en lugar de generar avances reales, se dedica a producir reportes.

• Ausencia de una cultura de planificación, seguimiento y mejora continua: La planificación no es realista; se elabora para complacer al stakeholder, quien exige fechas sin considerar impedimentos o bloqueos. El mensaje del cliente es claro: "el proyecto requiere fechas y las fechas no se mueven". Todo esto ocurre bajo la mirada de un equipo que no se escucha para aprender y que no lleva a cabo lecciones aprendidas.

• No aplicar metodologías de proyecto o hacerlo solo de forma simbólica: Se implementan prácticas metodológicas de forma superficial, alejadas de una metodología real. Se realizan eventos o se formalizan tareas que denotan ser más un cumplimiento formal que sesiones que enriquezcan el día a día del equipo.

Consecuencias:

• El proyecto puede alargarse indefinidamente: No hay fecha de terminación en un proyecto en eterna crisis, el cansancio se refleja en un  equipo que se desgasta y se va quemando con el tiempo, ante un cliente que exige resultados pero que solo sabe pedir y no dar.

• Se generan sobrecostos y pérdidas de valor: El proyecto termina costando el doble o el triple de lo estimado al inicio, se generan trabajos adicionales en todo el equipo para intentar cumplir con el proyecto.

• El equipo sufre desgaste y desmotivación: El equipo queda desgastado, muchos ven como su vida normal comienza a normalizar los horarios extendidos, los fines de semana se vuelven trabajo si o si. No hay motivación, todo es un desgaste y la gente espera que termine el proyeco o muchos estan en busqueda de un nuevo empleo.

• El producto o servicio final puede ser irrelevante o nunca llegar a lanzarse. A la hora de salir o terminar el proyecto para el cliente han cambiado las condiciones, en un entorno incierto y volatil, el alcance ha sufrido variaciones ante un mundo que tiene mayor velocidad que el del mismo proyecto. Quizas lo que imaginó el cliente ya es irrelevante, o el comportamiento del proyecto requiere que se haga todo nuevo diferente a lo contratado.

El Proyecto en Eterna Crisis: Un Diagnóstico Urgente

Un proyecto en eterna crisis es aquel que, a lo largo del tiempo, no logra estabilizarse ni avanzar de manera sostenida hacia sus objetivos. A diferencia de los ciclos normales de incertidumbre, correcciones y mejoras, este tipo de proyecto vive en un estado permanente de urgencia, caos y reacción. Es común que sea manejado por un stakeholder que, quizás dolido, carece de criterios claros para la solución de problemas, exigiendo siempre más de lo que aporta, dejando a los ejecutores en una constante sensación de deuda.

Características de un Proyecto en Eterna Crisis

Los proyectos en eterna crisis comparten varias características recurrentes:

• Cambios constantes de alcance: Se presentan modificaciones frecuentes sin justificación clara o sin análisis de impacto. El cliente insiste en que no hay cambios, enfocándose únicamente en la fecha de entrega, ignorando las alteraciones "ocultas" que surgen del "cómo" en lugar del "qué".
• Retrasos crónicos en las entregas: La planificación no es realista y los hitos no se cumplen. La planeación se basa en lo que el cliente "quiere" más que en lo que se "puede" lograr. Aunque los proyectos tienen variables negociables (como la triple restricción: alcance, costo y tiempo), para el dueño de un proyecto en crisis, las fechas son inamovibles.
• Desgaste emocional del equipo: El equipo se somete a jornadas laborales excesivas (10-12 horas diarias, incluyendo fines de semana), lo que provoca un agotamiento total. Esto suele derivar en renuncias masivas o en la desmotivación de los miembros, quienes buscan otras oportunidades fuera del proyecto.
• Falta de liderazgo efectivo y decisiones contradictorias: No hay una gobernanza clara del equipo, ya que todas las peticiones del stakeholder son aceptadas sin cuestionar. El equipo se acostumbra a la crisis y a someterse a un cliente que solo exige y no reconoce sus propias fallas, lo que resulta contradictorio porque el ejecutor siempre es el que queda en evidencia.
• Reuniones reactivas y decisiones improvisadas: La dinámica se convierte en una serie de "salas de emergencia" para "apagar incendios". Se asigna personal a resolver problemas derivados de la mala planificación de todos los actores del proyecto, incluyendo al cliente.
• Repetición de errores sin aprendizaje: Los errores son el pan de cada día. No hay tiempo para analizar la causa raíz; solo se reacciona para corregir, sin evitar que vuelvan a ocurrir. No se implementan lecciones aprendidas, impidiendo la mejora continua del equipo.
• Desconfianza entre actores clave: La desconfianza es el actor principal. Los stakeholders no creen en las promesas incumplidas, y los ejecutores son incapaces de ofrecer nuevas fechas o asumir compromisos. Se genera una espiral de discusiones y amenazas por la falta de resultados

Con este blog, inicio una serie de escritos enfocados en proyectos que viven en la eterna crisis. En la próxima entrega, profundizaremos en las causas y consecuencias de esta problemática.

Una plantilla que envejeció

Antes soñábamos con conseguir un trabajo formal, en el que nos hicieran un contrato indefinido y en esa empresa esperar la vejez y pensionarse, antes era más difícil buscar un empleo para las generaciones que estudiaban, nuestro país vive una época emergente de empleo difícil de conseguir. Hoy  la situación ha cambiado mucho en algunos sectores, algunos mercados se encuentran con muy poca oferta de empleados para la alta demanda de empleos. Este es el caso de las empresas que se mueven en el sector de las Tecnologías de información, desarrollo de software.

Hace 25 años nos decían que la carrera del futuro eran las tecnologías, en especial ser Ingeniero de sistemas.... Muchos lo creímos, otros tantos no. Y esos que creímos nos damos cuenta del mercado y como está. 

Las empresas de tecnología están viviendo un verdadero desgaste en la consecución de recursos con la capacidad para enfrentar los retos en desarrollo de software. El mercado laboral en este ámbito se encuentra muy competitivo, y los retos de las empresas de tecnología pasan por formar equipos capaces de resolver problemas y desarrollar software a las necesidades de los clientes.

 “La plantilla envejeció y las directivas se dan cuenta cuando no quedan indios sino caciques, no hay manos para hacer la misión”

Algunas compañías han envejecido en su plantilla, el mercado ha hecho que se genere una alta rotación de personal para la cual muchas empresas no estaban preparadas, otras no se han preparado y siguen viviendo penurias, dolores, aunque para los líderes pueda parecer alivianar la carga laboral con menos recursos. Terminan sobrecargando a los recursos que siguen en las compañías, lo que conlleva a que estos terminen en el bazar llamado mercado buscando una mejor oferta, todo contrario al sueño de antes de querer pensionarse en una empresa en la que se entraba desde joven. La plantilla envejeció y las directivas se dan cuenta cuando no quedan indios sino caciques, no hay manos para hacer la misión, o  deciden que lideren técnicos sin las capacidades requeridas, no hay un equilibrio entre talento y liderazgo. En ese momento esa compañía navega a la deriva, total lo más importante es y será el estilo del líder para la toma decisiones y para llevar a cabo una transformación que seguramente ha evitado y ya no puede más.