Los proyectos de tecnología fallan en todo el mundo. Pero en Argentina fallan por razones adicionales que los frameworks internacionales no contemplan.
Después de años gestionando y asesorando proyectos de tecnología en empresas argentinas, estos son los errores que aparecen con más frecuencia.
Error 1: Presupuestar en pesos sin considerar la devaluación
Es el error más costoso y el más evitable.
Un proyecto de tecnología en Argentina casi siempre tiene costos en dólares: licencias de software, servidores en la nube, consultores especializados, hardware importado. Si el presupuesto se aprueba en pesos al tipo de cambio del momento de inicio, y el proyecto dura seis meses, el presupuesto puede quedar desactualizado antes de llegar a la mitad.
Cómo evitarlo: presupuestá los componentes dolarizados en dólares desde el inicio. Separé claramente qué parte del presupuesto es en pesos (recursos humanos locales, servicios locales) y qué parte es en dólares. Revisá el presupuesto mensualmente, no al final del proyecto.
Error 2: No documentar las decisiones tomadas
En proyectos locales, mucho se acuerda de forma oral: en una reunión, por WhatsApp, en un pasillo. Cuando hay rotación de personal — que en tecnología es alta — el conocimiento se va con la persona.
El nuevo integrante del equipo empieza desde cero, pregunta cosas que ya se decidieron, y en el peor caso toma decisiones contradictorias con las anteriores sin saberlo.
Cómo evitarlo: documentá las decisiones clave en un registro simple. No hace falta una herramienta sofisticada — un documento compartido con fecha, decisión tomada, alternativas descartadas y responsable es suficiente. Cuando alguien nuevo entra al proyecto, ese documento es su primer punto de referencia.
Error 3: Subestimar el impacto de la rotación
Argentina tiene una de las tasas de rotación de personal tecnológico más altas de la región. Un desarrollador senior puede irse en cualquier momento — a otra empresa local que paga más, a una empresa del exterior que paga en dólares, o simplemente porque encontró algo mejor.
En proyectos que dependen de una o dos personas clave, la salida de esa persona puede paralizar el proyecto por semanas o meses.
Cómo evitarlo: identificá las dependencias de personas clave desde el inicio del proyecto. Para cada rol crítico, definí quién puede cubrirlo parcialmente si esa persona no está. Asegurate de que el conocimiento técnico no viva solo en la cabeza de una persona — revisiones de código, documentación técnica mínima y sesiones de transferencia de conocimiento reducen el riesgo.
Error 4: Ignorar la diferencia de huso horario en equipos distribuidos
Muchos equipos de tecnología argentinos trabajan con colaboradores o proveedores en España, México, Colombia o EEUU. La diferencia horaria parece menor hasta que empezás a coordinar reuniones.
Con España hay 4-5 horas de diferencia. Con la Costa Oeste de EEUU, 4-5 horas en sentido contrario. La ventana de overlap real puede ser de 2-3 horas al día.
Cómo evitarlo: definí desde el inicio cuáles son las horas de overlap y protegelas para reuniones de equipo. Todo lo que puede resolverse de forma asíncrona (revisión de documentos, aprobaciones, actualizaciones de estado) no debería ocupar ese tiempo de overlap.
Error 5: Cambiar el alcance sin registrarlo
El scope creep —la expansión gradual del alcance sin control— es un problema universal. En Argentina tiene un agravante: la cultura de “sí, lo hacemos” antes de evaluar el impacto.
El cliente pide un cambio. El equipo lo acepta sin analizar el impacto en tiempo, costo y recursos. Tres meses después el proyecto está retrasado y nadie entiende bien por qué.
Cómo evitarlo: cualquier cambio de alcance, por pequeño que sea, pasa por un proceso mínimo de evaluación: qué implica en tiempo, qué implica en costo, quién lo aprueba. No hace falta un proceso burocrático largo — un mensaje documentado con el análisis de impacto y la aprobación del responsable es suficiente.
Error 6: No gestionar las expectativas del cliente interno
En proyectos internos (implementación de un sistema, desarrollo de una herramienta para uso propio), el cliente es el área usuaria. Esa área tiene expectativas que muchas veces no están escritas en ningún lado.
Cuando el proyecto termina y la herramienta no hace lo que el área esperaba — aunque haga exactamente lo que se definió al inicio — el proyecto se percibe como un fracaso.
Cómo evitarlo: involucrar al área usuaria desde la definición del alcance, no solo al final para la validación. Demostraciones intermedias del avance permiten detectar desalineaciones antes de que sean costosas de corregir.
Error 7: Arrancar sin sponsor real
Muchos proyectos se inician con el impulso de un área técnica o de un gerente de nivel medio, sin un sponsor de nivel directivo que tenga autoridad para resolver conflictos de recursos y prioridades.
Cuando el proyecto necesita una decisión que cruza áreas — cambiar una fecha, reasignar un recurso, resolver un conflicto de prioridades — no hay nadie con poder real para resolverla.
Cómo evitarlo: antes de arrancar el proyecto, identificar quién es el sponsor real — la persona que tiene autoridad para tomar decisiones ejecutivas y que asume la responsabilidad del resultado. Si ese rol no existe, el proyecto tiene riesgo alto desde el inicio.
¿Tu empresa está por arrancar un proyecto de tecnología y querés evitar estos errores desde el inicio? Escribime a [email protected] o agendá una llamada en Calendly.
Para evitar estos errores desde el inicio, leé cómo implementar gestión de proyectos en tu empresa. Si el problema es estructural, cómo armar una PMO en una empresa argentina te da el camino. Y si evaluás contratar ayuda externa, cómo elegir una consultora de gestión de proyectos.