El equipo de migración del CRM lleva tres semanas de trabajo y ya acumula retrasos. El responsable de entrega quiere iniciar la migración de datos durante el fin de semana. El responsable de seguridad indica que los accesos no están aprobados. El gerente de operaciones de ventas señala que la capacitación no está programada. Usted, como gestor del proyecto, se encuentra atrapado entre un cronograma al que se comprometió el patrocinador y un plan que parece completo sobre el papel. Fue generado por IA en una sola tarde y todos dieron su visto bueno. Cada día de espera implica costos de soporte para el CRM antiguo e impide que el nuevo CRM asuma la gestión de nuevos territorios. Cada día que se presiona para avanzar sin las debidas precauciones, se acumulan riesgos no evaluados sobre el entorno de producción.
Antes de corregir el cronograma, debe identificar en qué punto el plan dejó de ser una estrategia operativa para convertirse en un simple documento. Este curso le ayudará a desarrollar ese criterio mediante el uso de elementos prácticos concretos. Aprenderá a utilizar un acta de constitución del proyecto (project charter) para definir desde el inicio quién toma las decisiones, una línea base del alcance para frenar la expansión no controlada del mismo, una matriz RACI para evitar vacíos de responsabilidad, un registro de riesgos para transformar preocupaciones vagas en niveles de exposición monitoreados, y un proceso ágil de control de cambios para garantizar que los borradores generados por IA no eludan los procedimientos de aprobación. El objetivo no es utilizar menos IA, sino integrarla donde acelere el trabajo sin eliminar los filtros de control que garantizan la seguridad del proyecto.
Analice el cronograma del proyecto e identifique el momento exacto en que una aprobación o dependencia debería haber detenido el proceso antes de continuar con la ejecución.
El patrón de fracaso es predecible. La IA generó tareas, fechas y una ruta crítica, pero no asumió la responsabilidad de los aspectos complejos. Las dependencias que residen en otros equipos, los controles de acceso que requieren tiempo de gestión previo y las aprobaciones formales —que constituyen verdaderos puntos de decisión— se simplificaron en actividades genéricas. El patrocinador percibió certeza. El equipo interpretó que tenía permiso para avanzar. El proyecto perdió la capacidad de decir “todavía no”.
El ciclo de vida de un proyecto no es un simple calendario. Es una serie de transiciones en las que un entregable o documento de una fase sirve como insumo para la siguiente. Omitir una transición no ahorra tiempo; traslada la incertidumbre a la fase de ejecución, donde resulta más costosa.
La iniciación concluye cuando el acta de constitución (charter) define al patrocinador, el objetivo, el alcance general y quién tiene la autoridad para aprobar cambios. Dicha acta sirve de insumo para la planificación, etapa en la que las intenciones se transforman en compromisos. La planificación finaliza con el establecimiento de líneas base para el alcance y el cronograma, así como con la aprobación de las partes interesadas. Estas líneas base alimentan la ejecución, fase en la que se realiza el trabajo. La ejecución genera datos de rendimiento que nutren el seguimiento y control, donde se comparan los resultados reales con las líneas base y se gestionan los cambios cuando la realidad difiere de lo planificado. El cierre utiliza criterios de aceptación y aprobaciones formales para confirmar que el entregable ha sido aceptado y que el proyecto puede finalizar sus gastos.
Identifique qué transición del ciclo de vida habría evitado que el equipo de CRM iniciara la migración al nuevo sistema (cutover) sin contar con la aprobación de acceso.
Un error común es considerar los puntos de control de fase (o phase gates) como mera burocracia. Puede parecer eficiente dejar que la IA elabore un plan y comenzar la ejecución mientras se tramitan las aprobaciones. La consecuencia es un trabajo que debe rehacerse; algo que aparenta ser progreso hasta que deriva en una interrupción del servicio, un problema de cumplimiento normativo o una escalada ante el patrocinador.
La IA resulta más útil cuando los datos de entrada son estables y el resultado es un borrador. Por el contrario, perjudica los proyectos cuando la información de entrada es incompleta y el resultado se trata como una decisión definitiva.
En la fase de planificación, la IA puede elaborar un borrador de la estructura de desglose del trabajo (EDT), proponer un cronograma o generar una lista inicial de riesgos. Esto ahorra tiempo, pero solo si se le suministran el acta de constitución del proyecto (charter), las restricciones conocidas y los responsables de las dependencias. En la fase de ejecución, la IA puede redactar informes de estado, resumir los bloqueos e identificar patrones en los tickets de incidencias. Esto es de gran ayuda, siempre y cuando se mantenga explícito el punto de aprobación humana. El gestor del proyecto sigue siendo quien decide qué elementos forman parte de la ruta crítica, qué constituye un cambio y qué debe escalarse.
Seleccione los casos de uso de la IA adecuados para la planificación y para la ejecución, e identifique el punto de aprobación humana que garantiza la seguridad en cada uno de ellos.