Estas conversaciones son importantes porque ayudan a las personas a comprender el valor potencial de la nueva herramienta. Pero, cuando empecé a observar lo que realmente tenía que suceder primero, me encontré con algo interesante. La primera actividad de la implementación era bastante sencilla: diferentes áreas de la empresa tenían que preparar algunas hojas de cálculo y enviarlas al responsable de la nueva aplicación para que la información pudiera cargarse en la plataforma.

Fue entonces cuando me di cuenta de que, a pesar de todas las conversaciones sobre tecnología, algunas preguntas básicas de gestión de proyectos seguían sin respuesta. ¿Quién sería responsable de preparar cada archivo? ¿Cuándo tendría que estar listo? ¿Quién validaría la información antes de enviarla? ¿Podría el proveedor comenzar a trabajar con un archivo mientras esperaba los demás? ¿Cuánto tiempo llevaría cargar los datos? ¿Quién comprobaría que la información se había importado correctamente? Y, quizás lo más importante, ¿quién estaba esperando que esos datos estuvieran disponibles en la nueva aplicación y para cuándo los necesitaba?

Sin estas respuestas, podía comprender muchas de las posibilidades que la aplicación podría ofrecer en el futuro, pero todavía no tenía suficiente información para construir un cronograma inicial confiable ni para definir la primera versión del alcance. Fue entonces cuando empecé a pensar que, en algunas situaciones, quizás estamos confundiendo el conocimiento técnico con el conocimiento del propio proyecto.

¿Un Gerente de Proyectos Necesita Conocimientos Técnicos?

Creo que sí, aunque quizás no de la manera en que solemos imaginarlo. Un gerente de proyectos que trabaja en tecnología necesita comprender suficientemente el entorno para seguir las conversaciones y entender sus consecuencias. Si existe una integración entre sistemas, debemos saber qué se está integrando y por qué. Si se necesita una API, debemos comprender qué función cumple dentro de la solución. Si hay que migrar datos, necesitamos saber de dónde proviene esa información, quién es responsable de ella y qué podría impedir que la migración se realice según lo previsto.

Si es necesario desarrollar o habilitar una API, por ejemplo, necesito entender quién es responsable de ese trabajo, qué actividades dependen de él, cuándo debe estar disponible y qué sucederá con el proyecto si se retrasa. Del mismo modo, si un proveedor necesita recibir hojas de cálculo para cargar información en una nueva aplicación, necesito saber quién preparará esos archivos, qué formato se requiere, cuándo deben entregarse y quién validará el resultado. Para mí, es en este punto donde los conocimientos técnicos empiezan a aportar valor a la gestión de proyectos. El objetivo no es ser la persona con mayores conocimientos tecnológicos de la reunión, sino comprender la tecnología lo suficiente para identificar sus consecuencias para el proyecto.

Comprar un Software No Es lo Mismo que Implementarlo

Esta diferencia resulta especialmente importante cuando una empresa está comprando una aplicación existente en lugar de desarrollar un nuevo sistema. El software ya existe, el proveedor conoce el producto, el contrato puede estar firmado y las licencias incluso pueden estar pagadas. Pero eso no significa que el proyecto esté cerca de terminar. Todavía es necesario definir qué se implementará primero, preparar los datos, revisar las configuraciones, coordinar las actividades con el proveedor, preparar a los usuarios, organizar las integraciones y establecer qué forma parte de la implementación actual y qué quedará para una etapa posterior.

En este tipo de proyectos, buena parte de la complejidad no está en el desarrollo de software, sino en la coordinación de las actividades. El proveedor necesita recibir información de la empresa, un equipo interno depende de otro, los usuarios esperan que la plataforma esté disponible, el área de seguridad puede tener que aprobar accesos, otro sistema puede necesitar proporcionar información y un área de negocio quizás deba validar los datos antes de utilizarlos. Todo esto representa dependencias del proyecto, incluso cuando no se está desarrollando ningún software internamente.

Cuando las Conversaciones Técnicas Empiezan a Afectar el Alcance del Proyecto

Otro desafío aparece cuando las personas comienzan a explorar todo lo que la nueva plataforma podría hacer. Alguien comenta que la aplicación podría integrarse con otro sistema, otra persona propone automatizar una actividad manual y alguien más pregunta si la herramienta también podría utilizarse en otro departamento. Rápidamente, la conversación deja de centrarse únicamente en la implementación actual y comienza a incorporar posibilidades futuras.

No hay nada malo en explorar estas oportunidades. El problema comienza cuando nadie distingue esas posibilidades del alcance que realmente ha sido aprobado para el proyecto. Un gerente de proyectos necesita comprender si una idea forma parte de la fase actual, si representa una mejora futura o si simplemente es algo técnicamente posible. De lo contrario, el alcance termina convirtiéndose en un conjunto de expectativas que nadie se ha comprometido formalmente a entregar.

Por eso, creo que una de las contribuciones más importantes de un gerente de proyectos en entornos tecnológicos es transformar las posibilidades en compromisos claros. Mientras las conversaciones técnicas suelen explorar lo que se puede hacer, la gestión de proyectos necesita establecer lo que se va a hacer.

Un Cronograma de Proyecto Comienza con el Flujo de Trabajo, No con las Fechas

El ejemplo de las hojas de cálculo también me hizo reflexionar sobre otro punto: un cronograma no comienza eligiendo fechas, sino comprendiendo cómo debe desarrollarse el trabajo. Si hay que entregar cinco archivos, primero necesito saber quién preparará cada uno, si pueden elaborarse en paralelo, si alguno depende de información de otra área, si será necesaria una validación y si el proveedor necesita recibirlos todos antes de comenzar la carga de datos.

Después, necesito entender qué sucederá a continuación. ¿El proveedor podrá importar los datos inmediatamente? ¿Será necesaria alguna configuración adicional? ¿Quién revisará el resultado? ¿Cuándo podrán los usuarios comenzar a trabajar con el sistema? Solo cuando esta secuencia esté clara las fechas empiezan a tener sentido. La preparación de los datos, la validación, el envío, la importación, la verificación, la preparación de los usuarios y la puesta en producción pasan a ser actividades conectadas, y no simplemente fechas aisladas en un calendario.

Comprender estas relaciones también es fundamental para identificar la ruta crítica y las dependencias que pueden retrasar un proyecto. Si una actividad solo puede comenzar después de que otra haya terminado, esa relación debe ser visible antes de asumir compromisos. Sin comprender la secuencia del trabajo, las fechas de un cronograma terminan siendo poco más que estimaciones sin una base consistente.

Conocimiento Técnico o Fluidez Tecnológica: ¿Qué Es Más Importante para un Gerente de Proyectos?

Por esta razón, prefiero pensar en fluidez tecnológica, en lugar de especialización técnica, cuando hablamos de las competencias de un gerente de proyectos. Para mí, tener fluidez tecnológica significa comprender el entorno lo suficiente para relacionar lo que se está discutiendo con sus consecuencias para el proyecto. Si una integración requiere la aprobación del área de seguridad, necesito reconocer que esto puede representar una dependencia. Si el proveedor explica que una personalización solicitada no forma parte del producto estándar, necesito comprender que posiblemente estemos introduciendo costos, alcance o riesgos adicionales. Si un equipo no puede proporcionar determinados datos antes de que otro departamento los valide, necesito identificar no solo una restricción técnica, sino también un problema relacionado con las responsabilidades y los plazos.

El detalle técnico importa porque proporciona el contexto necesario para tomar decisiones de gestión. El objetivo no es dominar todos los componentes de una solución, sino comprender lo suficiente para identificar cuándo una decisión, limitación o dependencia técnica puede afectar el proyecto y qué es necesario hacer al respecto. Esta capacidad también ayuda a reconocer las primeras señales de retrasos en los proyectos, especialmente cuando las restricciones técnicas comienzan a comprometer dependencias, estimaciones o previsiones de entrega.

¿Qué Tanto Conocimiento Técnico Necesita un Gerente de Programas?

La profundidad del conocimiento técnico necesario comienza a cambiar cuando pasamos de gestionar un proyecto a gestionar un programa. El gerente de proyectos normalmente trabaja más cerca de la ejecución, donde las restricciones técnicas pueden tener consecuencias inmediatas sobre el cronograma, el alcance y las entregas. El gerente de programas opera en otro nivel. Los problemas técnicos individuales siguen siendo importantes, pero cobra todavía más relevancia comprender cómo esos problemas conectan diferentes proyectos, equipos y resultados.

Imaginemos que tres proyectos diferentes dependen del mismo equipo de integración. Para cada gerente de proyectos, esta situación puede parecer simplemente una dependencia dentro de su propia iniciativa. Para el gerente de programas, sin embargo, representa algo más amplio: una restricción de capacidad compartida que puede comprometer varias entregas al mismo tiempo. O imaginemos que un proyecto está reemplazando una aplicación de la que dependen otros proyectos. En ese caso, la decisión tecnológica deja de afectar únicamente a una iniciativa y pasa a formar parte de la arquitectura del programa, pudiendo influir en la secuencia de actividades, los beneficios esperados, la asignación de recursos y las entregas de diferentes proyectos.

Por lo tanto, un gerente de programas puede necesitar menos detalles sobre la implementación de cada solución, pero una comprensión más amplia de cómo se relacionan los distintos componentes tecnológicos. El enfoque deja de estar únicamente en las consecuencias de la tecnología dentro de un proyecto y pasa a considerar cómo esas consecuencias pueden afectar los resultados de todo el programa.

¿Qué Conocimientos Técnicos Necesita una PMO o un Gestor de Portafolio?

En el nivel de la PMO, la oficina de gestión de proyectos, o de la gestión de portafolios, las preguntas se vuelven todavía más amplias. Un gestor de portafolio probablemente no necesita saber por qué falló una importación de datos o qué API está impidiendo la comunicación entre dos aplicaciones. Pero puede necesitar comprender si varias iniciativas estratégicas dependen de la misma plataforma, si diferentes proyectos compiten por los mismos especialistas técnicos, si distintas áreas de la empresa están adquiriendo aplicaciones con funcionalidades similares o si una decisión tecnológica está generando riesgos para varias iniciativas importantes.

En este nivel, el conocimiento técnico contribuye cada vez más a comprender el negocio. Las decisiones involucran inversiones, capacidad organizacional, priorización, beneficios y riesgos estratégicos. Una limitación tecnológica que parece relativamente pequeña cuando se analiza dentro de un proyecto puede adquirir otra dimensión cuando varias iniciativas dependen del mismo sistema, proveedor o grupo de especialistas.

Quizás esta sea la distinción que considero más importante: el gerente de proyectos necesita comprender cómo la tecnología afecta las entregas. El gerente de programas necesita entender cómo crea dependencias entre diferentes iniciativas. Y una PMO o un gestor de portafolio necesita comprender cómo esas dependencias afectan las inversiones, la capacidad, los riesgos y la estrategia de la organización.

A medida que avanzamos por estos diferentes niveles de gestión, la necesidad de conocer los detalles de implementación puede disminuir, pero la importancia de comprender las consecuencias de la tecnología permanece. Esto también está relacionado con el papel de una PMO moderna, que debe ayudar a la organización a entender no solo si sus proyectos están avanzando, sino si realmente están generando valor para el negocio. Profundicé en esta diferencia en mi artículo sobre cómo utilizar la inteligencia artificial en la gestión de proyectos para construir una PMO que genere valor para la empresa.

Gerente de Proyectos vs. Gerente Técnico de Proyectos: ¿Cuál Es la Diferencia?

Creo que también es importante distinguir entre un gerente de proyectos que trabaja en iniciativas tecnológicas y un gerente técnico de proyectos, frecuentemente llamado Technical Project Manager. La diferencia no consiste simplemente en que uno comprenda la tecnología y el otro no. Cualquier profesional responsable de gestionar un proyecto tecnológico necesita tener los conocimientos técnicos suficientes para dirigirlo adecuadamente.

Un gerente técnico de proyectos normalmente trabaja más cerca de la solución tecnológica y puede participar con mayor profundidad en conversaciones sobre arquitectura, restricciones de ingeniería, entornos, integraciones y decisiones de implementación. Por su parte, un gerente de proyectos puede trabajar con un nivel de detalle menor, apoyándose más en especialistas técnicos mientras concentra su atención en la coordinación de actividades, la gestión de entregas y los resultados de negocio. Esta división varía según la organización y la naturaleza del proyecto, pero el cargo de gerente de proyectos no debería significar que la tecnología se convierta en una caja negra que el profesional no necesita comprender.

Entonces, ¿Qué Tan Técnico Debe Ser Realmente un Gerente de Proyectos?

Quizás sea necesario reformular la pregunta original. En lugar de preguntarnos únicamente cuánto conocimiento técnico debe tener un gerente de proyectos, creo que una pregunta más adecuada sería: ¿cuánto necesito comprender sobre la tecnología para tomar las decisiones de gestión que forman parte de mi responsabilidad?

Un gerente de proyectos necesita comprender la tecnología lo suficiente para reconocer cómo las decisiones, limitaciones y dependencias técnicas pueden afectar el alcance, el cronograma, los costos, los riesgos y las entregas. El objetivo no es necesariamente desarrollar una especialización técnica profunda, sino adquirir suficiente fluidez tecnológica para hacer las preguntas correctas, identificar consecuencias y transformar la información técnica en decisiones de gestión.

Si no puedo comprender la tecnología lo suficiente para identificar cómo puede afectar el proyecto, probablemente necesito profundizar mis conocimientos. Al mismo tiempo, si comienzo a tomar decisiones de arquitectura que deberían corresponder a los especialistas, quizás esté sobrepasando los límites de mi función. El equilibrio se encuentra en algún punto entre estos dos extremos: comprender lo suficiente para interpretar las consecuencias, sin asumir la responsabilidad de decisiones que requieren conocimientos técnicos más especializados.

Y, algunas veces, especialmente cuando una empresa está comprando una nueva aplicación, las preguntas más importantes son mucho más sencillas. ¿Qué estamos implementando exactamente? ¿Quién tiene que entregar qué? ¿Quién está esperando el resultado? ¿Qué actividades dependen de esa entrega y cuándo tiene que estar lista?

Estas preguntas pueden parecer sencillas, pero sin ellas es muy difícil definir un alcance consistente, construir un cronograma realista o comprender si un proyecto realmente está avanzando.

¡Hasta la próxima!

Erik Scaranello