Una empresa con varios proyectos en marcha no necesita un Delivery Manager porque esté de moda el título. Lo necesita cuando los plazos se acercan y nadie tiene autoridad real para decidir qué se sacrifica. Cuando cada equipo apaga su propio incendio sin que nadie vea el mapa completo. Cuando el cliente pregunta «¿para cuándo?»
Reviso un incidente con el equipo técnico y pregunto si el problema está solucionado. La respuesta llega rápida: «Sí, ya hemos parcheado.» Repito la pregunta de otra forma: «¿Sabemos qué ha pasado antes de parchear?» Ahí cambia la conversación. En las últimas semanas varias herramientas que sostienen el ciclo de vida del software —control de
Incidente parcheado, ¿pero realmente cerrado? Leer entrada »
En ¿Eres un adicto al email? he tratado el primer nivel del problema: revisar el correo de forma compulsiva, confundir disponibilidad con responsabilidad y permitir que la bandeja controle tu atención. Ese hábito personal importa, pero no explica todo lo que ocurre. El problema cambia de escala cuando la organización también depende de que tú leas, interpretes
El riesgo de gestionar tu empresa desde el correo electrónico Leer entrada »
Hay un patrón claro: un piloto de Industria 4.0 arranca, funciona, el equipo lo celebra, dirección lo enseña como prueba de que «la transformación avanza» — y ahí se queda. Nadie lo replica en la siguiente planta. Nadie lo convierte en algo que la empresa pueda repetir sin reunir otra vez al mismo equipo de
Tu piloto de Industria 4.0 funciona. ¿Por qué eres incapaz de escalarlo? Leer entrada »
Tu equipo de IT trabaja todo el día. Eso lo ves. Pero cuando miras al negocio y te preguntan «¿qué hemos avanzado?», puedes comentar que has avanzado en algo pero sigues sin cerrar nada. Cada semana aparece algo urgente, cambias prioridades por presión y el backlog sigue creciendo sin que te salte ninguna alarma real.
Imagínate un CIO preparando una reunión decisiva con la junta de dirección: meses atrás lanzó un ambicioso proyecto de transformación IT, con plazos ajustados y recursos limitados. Hoy, negocio pregunta por resultados, pero surgen dudas: ¿cumplen sus soluciones las nuevas normativas? ¿Están protegidas frente a ciberamenazas? Esta historia es familiar para muchos líderes IT. En
Ciberseguridad y cumplimiento normativo en la gestión de proyectos Leer entrada »
«Está hecho» no significa «está terminado». En muchos proyectos el go-live se aprueba por inercia: IT despliega, el negocio asume que ya está, y el proyecto queda oficialmente «cerrado». Dos semanas después aparecen los síntomas: nadie sabe cómo operarlo, los usuarios tienen que inventarse atajos, y cuando falla algo un viernes por la tarde no
El riesgo no es «pagar poco» o «pagar mucho». El riesgo es tomar una decisión salarial sin saber qué se rompe mañana. Cuando lo haces así, conviertes cada revisión en una negociación emocional y te quedas sin criterio replicable. El impacto real no aparece el mismo día: aparece cuando la persona que sostiene el delivery
Mantener un proyecto vivo durante años no es difícil. Lo difícil es hacerlo crecer sin que te consuma más tiempo, más energía o más foco del que devuelve. En IT lo sabemos bien: cuando algo empieza a escalar, lo primero que falla no es la tecnología. Es la operación. Procesos que ya no aportan valor
Uno de los dilemas más comunes que me comparten otros managers es este: «Quiero estar al tanto de lo que pasa en mi equipo, pero no quiero convertirme en ese jefe que lo revisa todo.» Y es que el micromanagement no siempre empieza con malas intenciones. Me sucedió con una persona que me llegó a
Control sin micromanagement: cómo liderar equipos tecnológicos Leer entrada »
