¿Cuánto dura un proyecto Salesforce? Plazos, dependencias y lo que realmente lo retrasa

La respuesta corta

No existe una respuesta única a la pregunta de cuánto dura un proyecto de Salesforce, pero sí hay rangos realistas que conviene conocer antes de firmar un presupuesto. Un proyecto enfocado de "Quick Win" —una automatización, un Object adaptado, un informe avanzado— a veces se cierra en 3-4 semanas. Una implementación completa de Sales Cloud para un equipo de ventas mediano oscila entre 8 y 14 semanas. Un proyecto Multi-Cloud con integraciones a un ERP y sistemas externos puede durar de 6 a 9 meses, y en ocasiones más si involucra varias unidades de negocio.

El factor que determina la duración real no es la magnitud del código, sino el ritmo de toma de decisiones en la organización: quién es el Responsible (Owner) de cada proceso, cuánto tiempo toma aprobar el alcance (Scope) y cuándo los datos están realmente listos para ser validados. Antes de fijar una fecha de lanzamiento (Go Live), es recomendable consultar la guía completa para la implementación de Salesforce en su organización, que detalla las etapas de trabajo detrás de cada semana en el cronograma.

Por qué los plazos varían tanto entre proyectos aparentemente similares

Dos organizaciones que solicitan una "implementación de Sales Cloud para un equipo de ventas de 20 personas" pueden recibir presupuestos con una diferencia de tiempo de ejecución de hasta tres veces, y ambas ofertas podrían ser correctas. La diferencia casi siempre radica en lo que no está explícitamente en el documento de requisitos: cuántas fuentes de datos existen, cuán complejos son los procesos de aprobación internos y con qué rapidez la organización toma decisiones que afectan a más de un departamento.

Un proyecto con un único Product Owner que tiene autoridad para firmar un Scope avanza significativamente más rápido que un proyecto donde cada cambio requiere la aprobación de un comité directivo. Esta no es una diferencia técnica, es una diferencia organizacional que impacta directamente el cronograma, a veces más que cualquier decisión de arquitectura.

Plazos según el tipo de proyecto

La siguiente tabla presenta estimaciones de semanas de trabajo reales (transcurridas, no de esfuerzo) según la etapa y el tipo de proyecto. Se trata de rangos promedio basados en la experiencia, no de un compromiso; cada proyecto concreto requiere una evaluación individualizada.

Es importante recordar que las cifras en la tabla asumen una disponibilidad razonable de las partes interesadas y datos de una magnitud manejable. Cualquiera de estas suposiciones, si no se cumple, puede añadir semanas enteras a cada etapa.

Lo que realmente retrasa los proyectos, y no es lo que piensa

Cuando un proyecto de Salesforce se desvía del cronograma, la causa más común no es la complejidad técnica, sino uno de estos cinco puntos:

• Decisiones dependientes que no se toman a tiempo - Una pregunta de negocio que permanece abierta durante dos semanas porque no hay nadie autorizado para responderla, mientras el equipo técnico espera.
• Datos que no están realmente preparados - Una fuente de datos "existente y lista" resulta contener duplicados, campos faltantes o dos fuentes contradictorias.
• Disponibilidad de personal clave y propietarios de procesos - El personal de ventas o servicio que debe probar y aprobar está ocupado con el trabajo diario y no se le concede tiempo con antelación.
• Integraciones con terceros - Dependencia de un proveedor externo, de una API con limitaciones, o de un equipo de IT interno que no trabaja al mismo ritmo.
• UAT que se alarga - Porque las pruebas comienzan solo cuando el sistema está "casi listo" y no en paralelo con el desarrollo.

De todos estos, las decisiones dependientes son la causa más fácil de prevenir y la más común en la práctica. Una organización que define de antemano quién aprueba qué, y en cuántos días una respuesta se considera un "retraso", ahorra en promedio dos o tres semanas en un proyecto mediano. Este tema se discute ampliamente también en MVP Salesforce, que explica cómo reducir el número de decisiones dependientes desde el principio, delimitando una primera versión más pequeña.

La ruta crítica: lo que determina la fecha final

En todo proyecto hay una cadena de actividades que determina la fecha mínima de finalización: esta es la ruta crítica. En un proyecto típico de Salesforce, la ruta crítica casi siempre pasa por tres cuellos de botella:

1. Aprobación del modelo de datos y permisos: Mientras esto no esté cerrado, no se puede iniciar la integración o migración con confianza.
2. Disponibilidad de la fuente de datos para la migración: Aunque el desarrollo esté listo, no se puede lanzar a producción sin datos limpios y validados.
3. Disponibilidad de los propietarios de procesos para UAT: Este es a menudo el cuello de botella más estrecho, ya que se trata de personas con funciones completas en la organización y que no tienen disponibilidad de tiempo del equipo del proyecto.

Un retraso de una semana en cualquiera de estos tres puntos se traslada directamente a la fecha de Go Live, incluso si el resto del equipo cumple con los plazos. Por lo tanto, una buena PMO supervisa específicamente los elementos de la ruta crítica y no solo el porcentaje de finalización general del proyecto. Esta idea se refleja en el proceso de UAT para Salesforce, que detalla cómo planificar la fase de pruebas para que no se convierta en un cuello de botella adicional.

Por fases (Phased) vs. Gran Estallido (Big Bang): cómo la elección afecta el cronograma

La cuestión de si salir al aire en una sola fase (Big Bang) o en varias etapas (Phased) es una de las decisiones más significativas para el cronograma, y no solo para el riesgo operacional.

Big Bang es adecuado cuando el alcance es relativamente pequeño, cuando existe una fuerte dependencia entre los componentes (por ejemplo, un proceso Lead-to-Cash unificado que no se puede dividir), y cuando la organización prefiere una inversión de tiempo concentrada en lugar de un período de transición prolongado. La ventaja en el cronograma: una única fecha límite clara. El inconveniente: cualquier retraso en un componente detiene toda la fecha.

Phased es adecuado cuando el alcance es amplio, cuando hay varias unidades de negocio o procesos que se pueden separar, y cuando la organización busca obtener valor temprano y aprender de una etapa antes de avanzar a la siguiente. La ventaja: una primera etapa entra en producción más rápidamente, y las lecciones aprendidas se aplican en las etapas posteriores. El inconveniente: una duración total más larga y, a veces, un costo de coordinación más elevado entre las etapas.

Como regla general, si se espera que el proyecto exceda los 4 meses o incluye más de dos departamentos independientes, un enfoque Phased casi siempre acorta el tiempo hasta el primer valor comercial, incluso si la duración total del proyecto es similar o más larga.

Cómo acortar el cronograma sin comprometer la calidad

Existen maneras reales de acortar el cronograma, y hay atajos que parecen ahorrar tiempo pero en realidad solo posponen el costo al Hypercare o al año siguiente.

Lo que realmente acorta:

• Delimitación estricta del alcance (Scope) para una primera versión, con una lista explícita de "no ahora" aprobada de antemano.
• Nombramiento de un único Product Owner con autoridad real para aprobar o rechazar, a fin de eliminar retrasos de comités.
• Inicio del trabajo de limpieza de datos en paralelo con la fase de definición, y no después.
• Liberar con antelación tiempo en la agenda de los propietarios de procesos para el UAT, no cuando llegue la fase.
• Uso de componentes estándar de Salesforce en lugar de desarrollo personalizado siempre que sea posible.

Lo que parece un atajo, pero no lo es:

• Omitir el UAT completo y pasar directamente a la "prueba de desarrolladores”: esto ahorra una semana y genera un mes de correcciones en producción.
• Migración de datos sin limpieza, con la intención de "limpiar después”: los datos sucios se convierten en un problema de adopción.
• Comprimir la capacitación en un solo día antes del Go Live: lleva a que el sistema sea evitado en las primeras semanas.

Cuando se trata de un proyecto en el que el cronograma es realmente crítico para el negocio, el acompañamiento profesional a través del servicio de implementación de Salesforce se enfoca precisamente en esta combinación: qué acortamientos son seguros y cuáles solo posponen el costo.

Escenario organizacional de ejemplo

Una empresa de logística planificó la implementación de Service Cloud en 10 semanas, para estar lista antes de la temporada alta. En la segunda semana, se descubrió que el sistema ERP existente no estaba preparado para exponer una API estable y que el equipo de TI interno solo estaba disponible a tiempo parcial para el proyecto. En lugar de retrasar todo el proyecto, el equipo adoptó un enfoque por fases (Phased): la primera etapa incluyó enrutamiento básico de solicitudes y SLA, sin la integración con el ERP, y se lanzó en 7 semanas, tres semanas antes de la temporada. La integración completa se pospuso para una segunda etapa, que se ejecutó en paralelo con la temporada alta y se lanzó dos meses después.

La lección principal: cuando se descubre un obstáculo real en la ruta crítica, la pregunta correcta no es "cómo comprimir el tiempo restante", sino "qué se puede separar en una fase nueva sin afectar el valor inmediato". La planificación del Hypercare después de cada etapa se detalla en Salesforce Hypercare, que muestra cómo estabilizar cada etapa antes de pasar a la siguiente.

Lista de verificación para una planificación realista del cronograma

• ☐ Se ha definido un alcance (Scope) cerrado para la primera versión, incluyendo una lista de "no ahora".
• ☐ Se ha designado un único Product Owner con autoridad de aprobación.
• ☐ Se ha verificado la calidad de los datos en la fuente, no solo asumido que están "listos".
• ☐ Los propietarios de procesos han liberado tiempo con antelación para los períodos de UAT planificados.
• ☐ Las integraciones con terceros se han verificado con respecto a la API y la disponibilidad del proveedor.
• ☐ Se ha decidido explícitamente: Phased o Big Bang, y por qué.
• ☐ La ruta crítica se identifica y monitorea por separado del porcentaje de finalización general.
• ☐ Existe un margen (Buffer) integrado del 10-15% para el cronograma, no una promesa de "todo a tiempo".
• ☐ Se capacitó a los usuarios finales antes del Go Live, no el día anterior.
• ☐ Se ha definido un plan de Hypercare con un criterio de salida.

Recursos profesionales

• Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html
• HPI Pro – Implementación de Salesforce — https://hpi.pro/salesforce-implementation
• HPI Pro – Metodología de trabajo — https://hpi.pro/methodology