Caso de estudio: Accenture vs. Hertz, equipos de desarrollo internos vs. externos

Errores de Hertz

1. Ceder el control del proyecto a un tercero.
2. No haber creado un equipo interno para controlar el desarrollo del proyecto.
3. No haber valorizado adecuadamente los entregables del Accenture. De haberse asesorado se hubiese protegido de desembolsar millones. En construcción, la ingeniería solo vale el 10% del valor total del proyecto; es decir que en el supuesto de que el proyecto valiera 32 MM USD, solo se deberia haber desembolsado 3.2 MM USD y no 7 MM USD (Item 29. de la demanda).

Errores de Accenture

1. No contratar un leader de proyecto que tuviera claro como realizar la integración de los sistemas de Hertz con la pagina web y el app.
2. Recomendar un producto propio, “Rapid”, que no estuviera probada su eficiencia para este proyecto.
3. Los códigos Java no se redactaron segun estandares Java lo que hizo dificil el mantenimiento del mismo.
4. El FED era inseguro y el AEM su arquitectura no conversaba con el arquetipo.
5. No se hicieron pruebas a los componentes.
6. Se reemplazó al “owner product” y al microservices arquitech en la Fase 2, perdiendose tiempo en la transicion.

Recomendaciones :

En mi opinión Hertz debió contratar un equipo técnico que evaluara a los proveedores para poder elegir a aquel cuyo lenguaje informatico sea mas amigable con su sistema para una rapida implementación.
Una vez elegido el proveedor incorporar a su Staff para que lideraran el control del proyecto mediante metodología " AGILES" o PMI donde se tuviera claro “Alcance, Tiempo y Costos”.

Por el lado de Accenture, hacer un levantamiento de los Stakeholders y de los sistemas que hay que integrar, asi como seleccionar un buen lider y los miembros que le den soporte.

¡Un saludo a todas las personas que trabajan en Accenture! Recuerden que trabajan en una mega corporación inmensa de decenas de miles de empleados en muchísimos países y que los queremos mucho 💚

![](

muchas veces el error es el miedo de hacerlo uno mismo, por ende se pierde plata y damos datos sensibles a terceros.

considero que si Hertz lo hubiera realizado como proyecto in House aprenden y lo logran hacer a su medida,con mucha menos inversión.

Desde mi perspectiva:

Hertz

1. Al no contar con el know-how suficiente y verse en la necesidad de contratar a un tercero para un proyecto estratégico de la organización, debió realizar un proceso de contratación mucho más estricto.

2. Debió solicitar un Project Manager por parte de su proveedor en las bases del proceso de compra, como una cláusula muy específica. Asi mismo, debió contar un PM interno que diera seguimiento en conjunto con Accenture.

3. No se comenta en el video, pero intuyo que, al no existir ninguno de estos dos roles, no existió un plan de dirección de proyecto adecuado, en donde se estipulara como se realizarìa la gestiòn de aspectos como los criterios de aceptación, control integrado de cambios, control de cronograma, presupuesto, gestión de riesgos, etc.

Accenture

1. Debió realizar una muy buena recopilación y registro de requerimientos, tanto funcionales como no funcionales y debió plasmarlos en un documento de alcance de proyecto (Project Charter, SOW, Backlog de proyecto, etc) y especificar como se realizan las solicitudes de cambio.

2. Debió cersiorarse de que contaba con la calidad y cantidad necesaria de recursos (materiales, tecnicos, humanos) para poder entregar el producto que su cliente esperaba.

3. Debió mantener una actitud más prudente y no amenazar con cobros de tarifas adicionales por requerimientos que se supone estaban especificados. Menos cuando se comenzaron a presentar retrasos considerables en la entrega.

4. Debió invertir más tiempo en la planeación de una estrategía efectiva para abordar el proyecto.

Ambos,

1. Debieron mantener un canal de comunicación abierto y cordial, donde se pudieran discutir todas las controversias y se trataran de resolver de la mejor manera posible.

Al tratarse de una ventaja competitiva, Hertz debió construirlo in-house.

Yo trabaje en una Big Four tambien, y todas ellas son super empresas, una gran experiencia profesional, sin embargo en esta y muchas otras empresas vi fracasar proyectos de manera similar, considero que uno de los principales errores es que Hertz (y otros clientes) dejaron en manos del 3ro el ser el product owner, ya que nadie conoce su negocio mejor que ellos, la gerencia del proyecto y conunicaciones debe ser compartida donde un director con poder de desicion de Hertz para mover recursos internos de Hertz, del lado de accenture a veces las compañias de este tipo no suelen escuchar mas que sus propias opiniones y no son dados a la innovacion o a trabajar con tecnologias experimentales, hoy en dia muchos de ellos son digitales y en nube e implementan cloud solo que lo hicieron muchos años despues que compañias de menor tamaño que adoptaron nuevas tecnologias mas rapido

De acuerdo con Freddy, hay muchas formas de abordar la situación.

En mi opinión, para un proyecto de esta magnitud, se debió tener un Equipo de Proyecto conformado por recursos de Hertz y Accenture designados para el Proyecto, donde además de un Product Owner (ojalá del equipo Hertz), se tuviera un gobierno del Proyecto, con Comités Directivos (stakeholders) que se reunieran periódicamente en donde participaran Hertz, Accenture y el equipo Proyecto.

Adicional, se debieron tener Comités técnicos,en donde se debatieran temas de Arquitectura de software y se vigilara que se siguiera el estandar acordado desde el principio, cuestiones operativas y de QA, este Comité debiera reportar sus hallazgos y avances al Comité Directivo junto con los bloquers, los riesgos identificados y su probabilidad de ocurrencia.

Cabe resaltar, que debió implementarse una metodología ágil, y lo primero que debieron planificar fue un MVP del producto que les permitiera aprender, controlar y asegurarse de que estaban por el camino correcto.

Acompáñenme a ver el final de esta triste historia:

https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=2ahUKEwiggt-SztrpAhXMKM0KHQCPD20QFjAAegQIBBAB&url=https%3A%2F%2Fexpansion.mx%2Fempresas%2F2020%2F05%2F23%2Fhertz-se-declara-en-bancarrota-por-el-impacto-del-covid-19&usg=AOvVaw3kSVuhD7aBglKPWeuwjZ5Y

🐱‍💻 Analizando el caso:

Hertz

1.- Contratar un tercero para desarrollo del proyecto.
2.- Aceptar un equipo o proveedor externo.
3.- Confiar en un tercero sin revisar reseñas.
4.- No poder dar sugerencias de implementación del proyecto.

La solución que propondría es contratar un equipo remoto de desarrollo y hacer seguimiento del proyecto.

Accenture

1.- No trabajar con una metodología de desarrollo de software y un cronograma.
2.- No pedir una descripción detallada del proyecto.
3.- No haber realizado un análisis técnico.

La solución que propondría es leer bien las especificaciones y utilizar una o varias mitologías de desarrollo de software.

Análisis resumido del Caso:

PROVEEDOR - ACCENTURE:

• Accenture en primera instancia hace creer al cliente que tiene los medio, el personal y el conocimiento adecuado para hacerse cargo del proyecto.
• Una vez determinado por “Accenture” que el personal no cuenta con los conocimientos adecuados y la capacidad técnica para realizar el proyecto, no se lo comunicaca al cliente y lo trata de cubrir culpando al cliente por la forma en que fue creado el Back-End
• Aprovechando la falta de experticia del cliente, “Accenture” les ofrece solucionar el problema anterior con una nueva “tecnología” conocida por ellos como “Rapid”, lo cual encarece el proyecto y confunde más al cliente.
• Nunca hablan con la verdad y prometen más de lo que pueden cumplir

CLIENTE – HERTZ:

• Entregaron todo el proyecto a manos del proveedor
• No pidieron reportes mensuales, bimestrales o trimestrales con los avances respectivos
• No existe un encargado o un grupo específico de trabajadores de Hertz a cargo de las revisiones y testeo de los posibles avances
• Realizaron adelantos importantes sin tener nada en sus manos

Teniendo en cuenta el tamaño de las compañias, es un caso con un grado alto de complejidad. Tomara bastante tiempo dar un ganador en este juicio.

Teniendo en cuenta la información presente, se puede evidenciar varios fallos de ambas partes:

Hertz

1. Entregar todo el proyecto sin involucrarse estrategicamente en posiciones, decisiones, diseños, seguimientos.
2. Requerimientos incompletos; debio contratar una empresa o un equipo propio para hacer una investigación de su sector (utilizar analytics) para entender como mejorar la experiencia de usuario.
   3.Requerimientos y especificaciones sin metología.
   4.Las expectativas poco realistas, tanto para el proyecto como con Accenture.
   5.Falta de soporte desde la Gerencia de Hertz ,se debio hacer mas seguimiento.

Accenture
1.Pobre inclusión del cliente y los usuarios finales en el proyecto.
2.Falta de planificación y estrategia
3.Los recursos para el proyecto fueron exagerados
4.El proyecto, a medio desarrollo, fue desajustado
5.Problemas con la gestión del IT en el proyecto
6.Desconocimiento de las tecnologías por parte del equipo elegido para el desarrollo y no lograron adaptar sus frameworks propios al desrrollo.

En todo caso para Hertz la mejor solución con ese presupuesto, era armar un equipo de primera y desarrollarlo para si mismos.

“El Riesgo viene de no saber lo que estas haciendo” - Warren Buffett

Los errores de Hertz fueron:

Dejar en manos de terceros la implementación total de su transformación digital.
No haber cuantificado la ventaja competitiva que iban a obtener desarrollando su propio software.
No tener en cuenta que la disrupción que está atravesando su core de negocio en el nacimiento y consolidación de empresas como UBER los iba a llevar a tener cambios constantes en las funcionalidades a crear y por lo tanto iban a experimentar bastantes iteraciones; por lo tanto, el código debe ser construído in house.
Haber dejado los criterios de aceptación de los requerimientos del lado del prestador de servicios enteramente.
No haber tenido la capacidad de decisión sobre las tecnologías que debían usarse para su proyecto.
Sopesar los errores únicamente sobre el prestador de servicios.
No tener conocimientos internos estratégicos en materia tecnológica, las habilidades digitales en una empresa hoy en día no son una opción.

Los errores de Accenture:

Generar falsas expectativas al cliente en su propuesta comercial.
No contar con los recursos adecuados y capacitados que pudiesen orientar al cliente de la mejor manera.
Cubrir todos los roles del proyecto a nivel estratégico y operativo.
Implementar sobre lo ya conocido, no tener la capacidad de analizar las necesidades de su cliente y brindar una solución que les diera una ventaja competitiva real.
Fallas en la gestión del proyecto y el ciclo de servicios IT.
Entrar en discusiones eternas con el cliente sin reconocer la falla retrasando el proyecto y generando cobros adicionales.
La transformación digital no es eso que ocurre al digitalizar tus servicios o contratar una firma de servicios reconocida en el mundo para implementar un sitio web y una app web.

La TD va mucho más allá es cultura; es impregnarse de mentalidad digital, es hacer propio los productos y desde ahí querer transformarlos. Considero que inicialmente Hertz tuvo que haber adquirido capacidades técnicas e implementar una estrategia de innovación abierta que le permitiera conocer cuál era el camino más no pavimentarlo en un terreno ajeno. Con la trayectoria de Hertz hubiese generado un diseño basado en datos que me diera la información suficiente para entender y analizar que requerimientos eran los ideales implementar en mi proyecto.

1. Hertz el error fue haber dado el control total para determinar cómo debería ser su producto cuando ellos más que nadie saben cuáles son sus necesidades.
2. Hertz no tenían claro el funcionamiento de su propia tecnología actual (backend) lo que no colaboro al entendimiento para poder conectarse
3. si pasaron 2 años como es posible que Hertz no se diera cuenta de las falencias en las entregas, lo que me hace pensar que parte de los errores eran de ellos y ellos aceptaban los retrasos de Accenture.
4. Accenture básicamente no tenía un Producto Owner con la suficiente experiencia o habilidades para llevar a cabo y entender el producto que deseaba Hertz.
5. En conclusión para mi Hertz solo pidió que se desarrollara su producto y se desentendió hasta que se lo entregaran, cuando ellos eran los que tenían que estar mas comprometidos con el proyecto.

errores de hertz si querían una ventaja competitiva estos debieron construirlo y tal vez crear un área de desarrollo que pudiera dar solución, hacer un filtro especifico para personal garantizando el resultado, establecer un nuevo organigrama empresarial, definir que mejora iterativa podían delegar a ACCENTUR. como resultado Herzt a mi parecer pensó que saldría mas costoso construir todo el aplicativo, razón para delegarlo…
por otro lado ACCECTURE como compañía debió dar a conocer los limites corporativos que tenían sus desarrolladores, ademas de designar un área especifica que abordara el tema conjuntamente supervisado por los equipos designados de Hertz para poder tener un constante evaluador en el progreso y escalonar lo mas rápido dando a facilitar la toma de decisiones de su cliente, una ves mas esto estipularlo en el contrato, ademas de tomar total responsabilidad del proyecto y haciéndolo propio, forzar al cliente a usar un desarrollo previo sin darle exclusividad de producto único, que tampoco fue especificado en el contrato, por ultimo el no tener un back-up inmediato de personal, suponiendo que esta persona que despidieron puedo ser ese mago de compañía (esto ultimo es conjetura) pero si se asegura que tenia conocimiento si del proyecto desde el inicio una nueva persona puede retrasar la entrega solo por enterarse que han avanzado y decidir volver a empezar de cero. ademas la entrada del el tercero en el negocio que forzó a hertz a entrar esto dice que al no tener comunicación efectiva entre las compañías se les dificultaba plantear un norte claro.

El PRODUCT OWNER!!! no debería estar fuera de la empresa, al final de cuentas accenture es un proveedor que aporta la visión de ingeniería, pero el negocio y el knowhow lo tiene Hertz (“en teoría”) , de igual manera el conocimiento del Backend con el que ya contaban para reservas necesitaba ser transmitido por alguien del equipo de Hertz dentro del desarrollo de las aplicaciones de integración, con un acompañamiento constate.** En resumen, si quieres implementar algo que va a formar parte del CORE de tu negocio, no lo puedes solo encargar a un tercero.**

En primer instancia no hubiese permitido que Accenture tomara el rol the product owner y hubiese ejercido como contratante supervisión a la administración del proyecto (overall project manager) por medio del Estructura de desglose de trabajo, midiendo una entrega trimestral de los adelantos o entregables del proyecto y de esta manera determinar alarmas de incumplimiento o retrasos de manera anticipada para tomar medidas de re-orientación del proyecto o la cancelación del mismo, para evitar perdidas económicas y conflictos judiciales.

Considero es un fallo de ambos lados, por parte de Accenture, el querer imponer sus mecánicas, usar tecnología que quizás no dominaban y no respetar lo indicado en el contrato, para querer extraer más dinero.
Por parte de Hertz, la mejor opción hubiera sido contratar personal y hacerlo ellos mismos, igual salía mucho más barato, desconozco la totalidad del caso pero si pagó por obtener lo que ya venía en el contrato y no daban… ese fue otro error fatal.

Con tal cantidad de dinero, Hertz debía hacer valer su posición y hacer las funciones de dueño de producto y si no tenía la capacidad, debió contratar a una segunda empresa interventora. Artefacto que no cumpliera debía ser regresado de inmediato. Debió establecer métricas de calidad con puntos de control que le permitieran a Hertz decidir si era necesario establecer una sala de crisis e incluso en la medida que el atraso creciera, mostrarle los rottweilers (abogados) para que vieran que no estaban jugando y que ellos tenían el control.

Imagino que en algún momento ya entrada la crisis, tanto Hertz como Accenture, tuvieron la oportunidad de evaluar y analizar si aplicaban lo gastado como un costo hundido para replantear y dar un viraje o incluso abandonar para reducir perdidas.

Creo que Hertz debió contratar a un consultor que sea un product owner y que esté de parte de Hertz. Por otro lado se nota que la falta de buenas prácticas y por querer cobrar más, Accenture fue retrasando el proyecto.

En el 1:25 Freddy comenta “El objetivo no era reconstruir toda la plataforma tecnológica de Accenture, esto ya era un proceso interno de Accenture que les iba tomar aproximadamente 400 MDD. El objetivo era cambiar los sitios web de Accenture para hacer reserva de automoviles por que…” ¿Aquí en lugar de Accenture debe estar hablando de Hertz no es así?

Cadena de errores desde el principio:
Por parte de Hertz:
NO se describe si hubo un RFP como documento standar de necesidades.
Area de compras desentendida de sus funciones y sin apoyo interno entre areas involucradas.
Aceptar un presupuesto sin la autorizacion e implicacin del area de TI

Por parte de Accenture:
Area comercial en direccion opesta al area de desarrolo tecnológico.
Se ofreció un proyecto inalcanzable desde el comienzo.

Recomendacion:
Area de TI o I+D deben ser el eje transversal de todas las areas y proyectos de la empresa.
Creacion de un area de Gestion del cambio : con implicacion directa para el control , seguimiento y fiscalizacion de todo el proyecto en cada fase .

Hertz quería algo muy personalizado de acuerdo a sus propias necesidades pero accenture no lo entendió como tal porque no estaban muy familiarizado desde adentro sobre la cultura de hertz y qué es su ventaja competitiva como empresa por eso no hicieron los controles de calidad indicados para necesidades exactas, al final terminaron sucediendo esos dolores de cabeza. Por otro lado, si observamos la gran ventaja competitiva de tesla, ellos controlan cada milímetro de pieza que desarrollan en cada unidad productiva dentro de tesla, cada equipo esta enfocado en hacer el mejor carro eléctrico del mundo.Con ello hace notar la importancia de analizar con cabeza fria pero tomar rápida la decisión de si trabajamos con un equipo in house o externo.

Desde mi perspectiva y en términos generales, como cliente, debo tener claridad que las tareas son delegables pero la responsabilidad no, por tanto, delegar todo tipo de toma de decisiones a un tercero es un primer error, particularmente por el nivel de inversión del proyecto y segundo porque el resultado, que es la aplicación, estará directamente vinculado a mi marca, pudiendo afectarse mi imagen de marca.

Creo que Accenture no debió haber quedado como el tomador de decisiones respecto a si el diseño entraba o no en los requerimientos del cliente (conflicto de interés).

Pienso que una sana relación comercial, como cliente o como proveedor, se fundamenta en transparentar las expectativas y acordar tempranamente cuales se van a poder cumplir y cuales no, lo que debiera quedar establecido en el contrato como los requisitos mínimos de cumplimiento y lo que no contempla el proyecto, o qué tendrá costo adicional. Transparencia es lo que como cliente se busca.

Para el cumplimiento de lo anterior, creo que es fundamental las pruebas de diferente tipo en distintos momentos del desarrollo de la solución, establecer entregas parciales y por supuesto, pruebas de aceptación, cumplimiento de hitos del proyecto con sus respectivos plazos, y otros puntos que condicionen el pago parcializado como la continuidad del proyecto. Fundamental no pagar todo por adelantado.

Para establecer que se han cumplido los objetivos del proyecto o de las entregas parciales, se deben establecer mediciones objetivas, para determinar fuera de toda opinión personal si se había logrado el objetivo o no, por ejemplo que se sigan estándares de la industria como mínimos de cumplimiento. Esto como proveedor es importante, porque siempre el cliente puede decir que esperaba otra cosa, que es feo o malo, pero se debe dejar establecido como medimos objetivamente eso.

Se podrían haber establecido multas por incumplimiento o atrasos.
Claramente la gestión del proyecto debió mandar luces mucho antes de que no se iba a cumplir las fechas comprometidas dando oportunidad de hacer cambios, ajustes o modificaciones al contrato, antes de llegar al incumplimiento.

Antes de iniciar con el proyecto ambas empresas debieron haber acordado las especificaciones técnicas y funcionales de las aplicaciones a desarrollar, especificaciones que debieron ser muy detalladas. Estas definiciones debieron de haber formado parte del contrato, como el Anexo más importante.

El principal responsable de esa omisión es Hertz, quien al contratar a Accenture asumió que éste iba a hacer más de lo acordado en el contrato. Considero que les faltó un equipo técnico capaz de definir, contratar y supervisar un proyecto de tecnología.

Es probable que Accenture haya actuado de mala fe, especialmente cuando quiso cobrar servicios adicionales, pero lo que es claro es que también tuvo un equipo de proyecto deficiente, tanto en la supervisión como en la ejecución de actividades.

Este tipo de errores es muy común en las empresas, que creen que el otro por ser experto puede darte la solución que quieres.

1. No realizar seguimiento a un proyecto y no tener un Project Manager que lo manejara.
2. No tener en cuentas las integraciones o compatibilidades que se requerían desde el principio o a medida que este fuera avanzando.
3. No definir desde el comienzo los lenguajes que se iban a usar.
4. Incluso dejar los requerimientos desde el principio da lugar a ambiguedades, pues lo que para mi es funcional o estético para otro puede no serlo.

Yo trabajo algo así como “Project Manager”, el tema de estimación de fechas no es para nada fácil, aún así tú sepas desarrollar. Sin embargo, pienso yo que cuando un proyecto empieza a dilatarse tanto, hay decisiones importantes que tomar y pensar cómo hacer las cosas de una manera diferente. A ambos tanto Hertz como Accenture les faltó esto. Para mi como Hertz hubiese contratado a alguien experto en el tema para hacer seguimiento al proyecto, aunque la asesoría de accenture es valiosa, era importante que desde Hertz se hiciera un seguimiento continuo a ambas partes para poder cumplir con los deadlines propuestos.

Lo veo de dos Opciones:

• Al ser un proyecto estratégico, esos $32B era mejor invertirlos en conformar un equipo propio para su desarrollo, utilizando metodologías ágiles de desarrollo.
• Si evidentemente no querían crear esa competencia y delegar al verlo como una mejora interactiva, el equipo de proyecto debió estar conformado por Hertz y Accenture donde el Product Owner debió estar de lado de Hertz y los Scrum Developers y Scrum Master por parte de Accenture.

Sino mal recuerdo en este caso, el equipo de tecnología de Hertz pidió el proyecto, dieron que ellos eran capaz de realizar este proyecto internamente, esto termino en despidos del departamento de tecnología en Hertz.

Al final contrataron a aventure y paso lo que paso, ademas encontré temas como el siguiente:

Despido de empleados:
https://www.ciospain.es/capital-humano/hertz-reducira-su-plantilla-ti-en-estados-unidos-debido-al-outsourcing
Foro de ex-empleados:
https://news.ycombinator.com/item?id=19737070

Desde el punto de vista de Hertz
El proyecto pudo haberse desarrollado internamente, con lo que puede investigar ellos si contaban con un departamento de tecnología. Soltar la tecnología propia de su negocio a manos de un tercero de pronto parecía una buena idea como lo hacían creer las anteriores técnicas de gestión, con la mentalidad de: “Dedíquese a hacer lo que usted sabe hacer”, ejemplo:
https://www.hiberus.com/crecemos-contigo/10-razones-las-outsourcing-conveniente-empresa/
(Hace diez años recuerdo haber recibido varias charlas de este estilo, buscando hoy en día es difícil encontrar esta documentación que recuerdo existió, eso demuestra el dinamismo de Internet y del mundo en general)
Posiblemente Hertz pudó estar mas atento a su proyecto, pero claramente eso no era lo que ellos quería, solo querían pagar por un software que llegara hecho y fuera excelente.

Desde el punto de vista de accenture
Este tema ya es mas sesgado a mi ser, ya que soy proveedor de software personalizado para diferentes empresas, prácticamente lo mismo que se dice el contrato: levantar, diseñar, probar y entregar software de calidad. Con varios proyectos en mi historial he tenido muy buenos aciertos y otros no tanto, pero prácticamente he concluido con mi experiencia que mucho depende del director del proyecto, la capacidad humanada de llevar el proyecto adelante interviene en el resultado y posiblemente (solo suposición) el talento humano que accenture le asignó a ese proyecto no fue el idóneo.

Errores Hertz
Delega la responsabilidad total en el contratista. Al parecer se trataba de hacer unas mejoras de un proceso que ya estaba corriendo.
Es decir, en ese caso es adecuado delegar la construcción de la solución y dejar el équipo propio para crear otras ventajas competitivas de manera in-house.
El costo pareciera muy alto, y cayeron en la trampa de comprar marca, pero quedaron con bajo poder de negociación y exigencia dentro de la ejecución del contrato.
Es importante, hacer claridad en el RFP. Así no se permite que los proponentes le cambien las condiciones originales.
Hertz debió asegurar dentro de la licitación y compromisos que el talento humano persistiera durante todo el proyecto, en sí se trata de un proyecto corto, por lo que creo se hubiera podido lograr esta posible exigencia.
Hertz cede toda responsabilidad en el contratista, “subordinandose” a lo que el externo haga, permitiendole incumplir entregas y fechas.

Errores Accenture
Prometen mucho, seducen, logran la venta y luego a la mejor manera de empresa narcisita incumple, exige más dinero y permite un pleito.
Al parecer, no cumple lo establecido en el contrato.

¿Qué se pudo haber hecho diferente para mejorar las condiciones expuestas?
Hacer un proceso de licitación más riguroso. Aclarar el RFP y definir muy bien la licitación en cuanto a requerimientos.
Auditorías preventivas y exigencia de correcciones inmediatas.
Fortalecer la parte jurídica. “Cuentas claras amigos para siempre”

¿De qué distinta forma este proyecto habría salido bien?
Posiblemente contratar una firma auditora externa de mismo renombre y experiencia que asegurara el éxito del proceso.
Claridad en el contrato. Exigencia de permanencia del RRHH durante la ejecución del contrato.

Entiendo que hay muchas variables a considerar en este caso, y sin dudas una gran lección en cuanto a la adquisición de servicios de terceros para la compañía:
Errores parte de Hertz:

• delegó un proceso crítico de su empresa en manos de un tercero, donde debería de tener influencia y seguimiento
• la falta de acción ante los deadlines (vinculado con el punto anterior de ausencia de seguimiento)
• no tener una planificación clara sobre el proceso, ya que no todo es desarrollo, debería tener una parte de control in company y articular ambas partes en el proyecto.
• no tener una hoja de ruta, procesos y kpi’s claros para evitar/mitigrar los desvios
  En cuanto a los errores de Accenture suscribo lo que dice Karen en un comentario previo.
  Interesante caso de estudio, como para ver de primera mano, la cantidad de cosas que NO se deben hacer!

Creo que el principal error de Hertz fue lo entender que este proyecto hacía parte de su potencial ventaja competitiva hacia el futuro y que por ende debió desarrollarla internamente.
Adicionalmente fue negligente en su propia responsabilidad de gestión del proveedor y por ende en el cumplimento de tiempos y aseguramiento de la calidad de sus resultados.
Por parte de Accenture un error crítico fue la pobre gestión del proyecto, no analizando los desafíos de integración, priorizando sus propios intereses de facturación a las necesidades del cliente, trabajando aisladamente, cambiando el equipo líder (seguramente cómo consecuencia de su pobre desempeño) y reemplazándolo por un equipo de menor experiencia.
En conclusión, este es un buen ejemplo de lo que lo se debe hacer en proyectos de tecnología.

Se debio de haber pensado en hibrido es decir nombrar un equipo de trabajo de Hertz que supervisará los trabajos de Accenture con decisión de Hertz sobre la subcontratada para poder ajustar y controlar el desarrollo en forma permanente

Creo que el error fue delegar totalmente el proyecto a Accenture sin una supervisión de Hertz, al darle la livertad a accenture de hacer todo, obiamente ellos economizaron para sacar el mayor rendimiento al pago entregando un mínimo viable. Por experiencia propia, debes especificar hasta el más mínimo detalle en los requerimientos para desarrollos externos por que siempre se lavan las manos diciendo “Eso no lo solicitaste”

1 Ambas empresas se enfocaron en dos cosas diferentes:
Hertz se enfocó a utilizar la tecnología para solucionar su problema. La tecnología es un medio; no la solución por sí misma. Accenture se enfocó en las ganancias.

2 Parece obvio que Hertz debió crear un grupo de desarrollo. Es obvio para nosotros como observadores. Hay que pensar en las posibles trabas burocráticas para crear un puesto. Ahora; imaginar las trabas burocráticas para crear un departamento completo. No hay binarios. Hay infinidad de matices. Las personas no somos lógicas.

Buen día, yo creo que el error fue de Hertz, ellos quisieron realizar un cambio disruptivo en todo su core de negocio; y tal como se informo en sesiones pasadas los cambios totales en temas de software para ventajas competitivas es mejor buscar un esquema “in house” construyendo su necesidad; ahora bien probablemente tercerizar este cambio podia ser una opcion pero con los respectivos controles por parte de Hertz acompañando a Accenture como PO de su necesidad y con dailys todo el tiempo teniendo en cuenta la escala del proyecto

Hertz debió ser parte fundamental en el proyecto y no debió entregar tanta autonomía a Accenture. El conocimiento sobre el negocio de renta estaba en Hertz y se debía reinventarse era Hertz quién debía echar mano de su experiencia, datos e información para trazar hacía dónde debían ir, cómo oy el papel de la tecnología.

Hertz delegó una parte estratégica de su negocio en un tercero, a un 100%, sin contrapartes efectivas y sin entrenar a su gente para tomar los desarrollos. Otra debilidad en la negociación es la posición en la que se encuentra Hertz versus Accenture. Por otro lado, Accenture como buen vendor gigante, tiene el problema que un cliente más es eso (no es importante), no adaptan su tecnología y esperan que el resto se adapte a ellos, muchas empresas cometen el error de contratar a uno de los grandes por el respaldo que significa si se equivocan tienen una marca detrás que debiera responder (eso, en teoría).
Para evitar esto, muchas compañías lo que hacen es contratar un tercer servicio de monitoreo de plazos, gantt, entregables y van entregando feedback efectivo y oportuno, juegan el rol de mediador calificado para hacerlo. Tienes a Hertz por un lado contratando a Accenture y por contratas a una consultora que tenga la capacidad de ser contraparte de Accenture, y hubiesen logrado todo en los plazos originales.

En resumen, Hertz optó por la opción de “compralo” y se encontró con Accenture que sin feedback y contraparte efectiva en Hertz jugó a “vendedor”, y sin un mediador este problema de agencia nunca termina.

Estudio Ingeniería en Sistemas y estudie la materia de Ingeniería de Software y lo que habla esa materia es que el software no es solo codificación y ya esta, es un ciclo de vida que debe ser podado por un equipo de trabajo: Analistas, diseñadores, codificadores, testers, proyect manager, etc.

a mi criterio:
Errores HErtz, deslindarse por completo del creacion de producto.
En obras civiles grandes se puede contratar un fiscalizador particular. En este tipo de desarollo de software, Hertz debio contratar asesoria de un tercero que pueda dar cuentas del desarrollo del Accenture.

Errores Accenture: subestimar el tamano del proyecto. No tener accountability en sus propios managers, ni de sus proyectos.

En mi concepto Hertz cometió dos errores:1.Desconocer que la solución que buscaba era estratégica para su negocio, y una opción era haberlo desarrollado con un equipo interno q involucrara los diferentes stakeholders y su propio equipo de desarrollo. 2. Si ya tomada la decisión de hacerlo con un tercero, debió involucrar en el proyecto personas de Hertz, que conocieran de las necesidades estrategias, es decir, los propietarios del Productos debían ser de la compañía de Hertz, e incluir igualmente a alguien técnico con poder directivo en el proyecto que fuese de Hertz.

Efectivamente la responsabilidad es compartida,iniciare con Hertz, pues dio el control completo a Accenture de su proyecto,donde el owner manager debio haber sido de su compañia pues este puesto es el puente de conexion entre una empresa y la otra, y ninguna de las dos harian “lo que se les diera la gana”, Accenture en cuanto ser holgazanes y hasta corruptos de venderles mas y mas servicios y Hertz de librarse de la responsabilidad y su seguimiento de su propio producto

La responsabilidad de las fallas es mutua, me parece que Hertz no debió permitir que Accenture tuviera el control total de proyecto. Por otro lado Accenture muestra desorganización y falta dé liderazgo en un proyecto de tal magnitud. Hertz debió de tener por su parte a un equipó supervisando la creación de la app y no esperar a que Accenture fuera presentando las mejoras, para ahí darse cuenta de las fallas.

Un proyecto de semejante tamaño debió integrar de planta por parte de Hertz a uno de sus colaboradores en un rol de auditor o incluso el más adecuado Producto Owner., en las mismas oficinas de Accenture. No tengo muchos detalles pero me baso en el relato de Freddy. así que también hubiera contratado a un consultor externo para mas tranquilidad. ser muy exigente con las diferentes etapas del proceso de desarrollo y sus entregables de los avances. además de tomar los snacks de las instalaciones de accenture. jijijij

Pudieron haber ocurrido muchas cosas distintas en ambos lados…
 Por el lado de Hertz:
 - Apoyar al equipo tecnológico interno.
 - No ceder el control de toma de decisiones.
 - Solicitar entrega de resultados bajo marcos ágiles con periodos de control y aseguramiento de la calidad.
 - Involucramiento de personal estratégico en una transformación clave en el rumbo de la empresa…
Por el lado de Accenture:
 - Brindar la capacitación adecuada al personal encargado del proyecto.
 - Documentación adecuada y  enfocada en resolver los problemas del cliente.
 - Asegurar la calidad del código entregado.
 - Ejecutar las pruebas de software adecuadas para el correcto funcionamiento de la aplicación.
 - No condicionar las tecnologías para el cliente sin fundamento válido.
 - Trabajar en resolver el problema del cliente sin agregar capas de complejidad adicional.
 - Dirigir equipos enfocados y con la consigna de entregar un producto mínimo viable lo antes posible y trabajar para robustecer la aplicación… 
Y un largo hubiera…

Errores de Accenture

• El principal y abismal error de Accenture, en mi opinión, fue estancarse tecnológicamente. Creer que por ser una “gran empresa” no necesito aprender nada nuevo o mejorar mis habilidades con el tiempo te hace obsoleto.

• Accenture debió adaptarse a la infraestructura de Hertz en lugar de forzar a Hertz a adaptarse a ellos. Una vez más, no querían aprender o desarrollar algo nuevo sino vender algo que ya tenían.

Errores de Hertz

• Suponer que el tamaño o la trayectoria de una compañía son garantía de que van a hacer un buen proyecto. Lamentablemente esto es común, pero deberíamos aprender de la famosa frase “las apariencias engañan”.
• No definir con mayor claridad la estructura de lo que esperaban. Debieron tener su jardín dibujado antes de contratar.
• No hacer un seguimiento a los avances o planear en conjunto fechas para revisión de entregas.
• Finalmente, creo que el mayor error de Hertz fue no saber cuando retirarse, debieron darse cuenta en algún punto que esto no iba a funcionar y entonces encontrar una forma de cortar antes para empezar con un nuevo proveedor o, mejor aún, contratar el personal para hacerlo ellos mismos, ya que claramente era algo que les iba a dar ventaja competitiva.

Yo hubiese creado un equipo con representantes de Hertz y de accenture con metas alcanzables de corto plazo. De esta manera se verificarían los errores antes de seguir con el proceso y evitar un producto final inadecuado. En definitiva, considero que hubo problemas de comunicación Expectativa-realidad.

Errores de Hertz

1. Desembolsar el 100% del dinero sin entregas.
2. Tener a alguien (tercero) para que evalue los avances directamente con Accenture.

Errores de Accenture

1. No colocar plazos más realistas.
2. Dejar una documentación para que en caso de un despido o inconveniente la siguiente persona/s puedan continuar (supongo)

Mas allá de los aportes ya hechos queda por decir.
De parte de Hertz la selección de la empresa de desarrollo se baso en el goodwill mas que en los productos desarrollados por accenture y sus practicas de negocios.
No se si Hertz contrato alguna  consultora o profesional especifico para selección que, dado el monto, era bastante prudente.
De parte de Accenture creo que los errores tienen que ver directamente con su modelo de negocio en el cual priorizaban la maximización de las utilidades (típico de los MBA´s), no el desarrollo de producto y ser costumer obsesive, esto se deduce de las respuestas de los ingenieros a la hora de formular el proyecto tanto en hertz como en el otro cliente.

Todo el Mundo Critica a Hertz, Pero es de entender que no era su Core de Negocio el desarrollo, Por eso acudieron a especialistas de Software que tenían gran recorrido en el mercado. No podemos pensar como fabrica de software si somos Hertz.

El fallo Principal Fue no establecer un equipo tecnico minimo por parte de Hertz, para indicarlos patrones de lo que querian. de igual manera un seguimiento respectivo.
Acceder en entregar tanto dinero en un contrato de tan largo alcance, sin evaluar los riesgos que se encuentran en la tecnologia.
Otro error fue no haber atado mediante clausulas, el incumplimiento, en iteraciones de entregables… Por eso Accenture se dio el lujo de prolongar un proyecto a 2 años que no solo fue el valor de los 32 Billion Dollars, si no el retroceso en el negocio y perdida de cambio tecnologico para competir de manera mas rapida a las nuevas plataformas como uber.
Entre Otros

Errores de Hertz

1. No tener un equipo de desarrollo propio que hiciera correcto seguimiento y visualizara todo el proyecto a nivel de código.
2. En un proyecto tan importante, Hertz debió ser más estricto manejando desde casa la especificación funcional, la lista de entregables, los tiempos de desarrollo y las tecnologías a implementar.
3. No Asesorarse de expertos y de un equipo técnico para la valoración total del proyecto.
4. Realizar pagos muy amplios sin tener nada tangible.

Errores de Accenture

1. NO definir correctamente el requerimiento funcional y alcance del proyecto.
2. Por la demora en la entrega y la calidad de la misma puedo suponer que no construyeron un equipo lo suficientemente robusto y especializado para este proyecto.
3. Querer manejar todo el proyecto dejando de lado al verdadero Owner (Hertz)
4. Al parecer no utilizaron una metodología de desarrollo efectiva ni siquiera para la fase de pruebas.
5. Querer aprovecharse del cliente con una tecnología que no es estándar en la industria.

Mi Sugerencia

Dado el tamaño del mercado y negocio de Hertz, yo hubiera sugerido un desarrollo In-house, con un equipo de desarrollo especializado incluso remoto hubieran tenido control sobre todas las fases del proyecto. También hubiera abordado este proyecto de manera modular, así lograría que fuera mas sencillo corregir en la marcha e iterar sobre los avances.

HERTZ

• Cometio el error de confiar en terceros para que desarrollaran su prodcuto. Lo que pudieron haber hecho es crear una área de investigación en donde se desarrollaran todos estos proyectos tecnológicos para así tener el total control de lo que hacen. El ceder el control a alguien más los llevo a seguirse retrasando como empresa, bajar ventas y gastar más dinero por un producto malo.

HERTZ

1. Hertz cuenta con conocimiento especializado dentro de su sector que no debió delegarse a otra empresa, pues el entendimiento de este conocimiento requiere de un mayor esfuerzo. Por el contrario debió haber invertir en el crecimiento de su equipo de ingeniería, cuyo conocimiento de la capa de negoció es mayor, como del stack tecnológico interno; es mayor.

2. Su equipo interno no se vio involucrado fuertemente en la toma de decisiones. Sobre el proveedor del servicio como de los entregables. Una solución pudo haber sido obtener consultoría especializada que le permitiera al equipo de Hertz definir el rumbo que debía tomar con respecto a este gran proyecto.

1.- Una inversion que perfcetamente entra en un proyecto in house
2.- no especificar y decir quiero esto, y poner fechas limites para poder proceder con una demanda legal
3.-No tener la cultura de investigar y desarrollar

Uno de los errores fue que le dejaron la responsabilidad completa del proyecto a manos de un tercero, quien se encargaba de decidir que lo que se habia realizado era correcto y no alguien que conoce el proceso completo en Hertz

Una empresa tan grande como HERTZ debió apostar por su equipo interno le hubiera salido mucho más económico y hubiera fidelizado mucho más a sus colaboradores

No debieron dejar que Accenture sea juez y parte (Product Manager y Product Owner. La decisión final sobre la calidad era de Accenture.
Hertz debió ejercer controles más seguidos sobre el proceso y los entregables.

Jumm que buen dilema, yo creo que si yo hubiera sido Herts desde el principio no pago 32 millones de dolares, me da mucha pena, sea quien sea el programador yo no pago eso, yo prefiero contratar directamente a los mejores programadores y de paso medio tratar de aprender algo de tecnología jajja, por que se tiene que ser muy bruto para contratar a alguien para que programe la aplicación que sabes será tu futuro. JJaja La Tecnología es una herramienta. Si no la dominas tú, te terminará por dominar a tí. Fin.

Para mí el error principal es haber dejado todo en manos de Accenture.

Hertz es una compañía -y está en una industria- en periodo de contracción donde si bien sería difícil que desapareciera en su totalidad en el mediano plazo, sí ha crecido su competencia y es difícil volver a tener la cantidad de clientes de hace 10 años.

Dicho esto, creo que el proyecto entra en la categoría de crear una ventaja competitiva (que más bien suena a proyecto para no morir tan rápido), por lo cual debió haber sido desarrollado in-house y tal vez contratar a Accenture como un asesor externo (con todos los NDA necesarios).

Desde la posición de Hertz:

Tener un acercamiento mucho mayor durante el desarrollo del proyecto y tomar la responsabilidad del proyecto. Por comodidad es fácil delegarla, pero hay que tener un balance

Tener deadlines mucho más estricto a través de penalizaciones incluso: no es aceptable tener un retraso de varios años para algo que es relativamente cotidiano y el know-how es algo conocido en la industria.

Desde la posición de Accenture:

Tener un acercamiento mayor al cliente y buscar feedback continuamente, en periodos cortos. Lo que percibo es que grandes pedazos de la funcionalidad requerida se revisaron en puntos más avanzados:
** Falla rápido, falla barato**
Evitar la sobreconfianza de un proyecto grande: ver tanto dinero de un proyecto/cliente como este puede causar una falsa sensación de confianza y comodidad, tanto técnicamente como en tiempos.

y pensar que al dia de hoy (mayo 30) Hertz se ha declarado en bancarrota porque venia arrastrando una serie de dificultades a la que le tuvo que sumar la pandemia actual que los dejo en esa posición.

Para el caso accenture vs Hertz considero que para el objetivo de lo contratado Hertz debió considerar la implementacción de un equipo de desarrollo interno, y no tercerizar este proyecto que podía ser facilmente un diferenciador o una herramienta importante para su permanencia en el mercado.
Si la decisión fue tercerizar con Accenture, para un proyecto tan ambicioso y problablemente complejo, debió fraccionarse en entregables medibles y alcanzables. El proceso además parece, según apartes de la demanda, que no contempló integración y distribución continuas CI/CD, por lo que el proyecto no terminó de generarle valor a Hertz.

Hertz cometió varios errores

• No realizo una revisión de varios oferentes y creo que se fue porque el que mas pergaminos tenia
• El departamento técnico de hertz no definió un proyecto con sus respectivos hitos, para hacer seguimiento
• no hubo un responsable en hertz de alto nivel para el manejo del proyecto.
• el tema económico fue muy mal manejado puesto que los desembolsos no comparten con el avance del proyecto.
• El retraso de 2 o 3 meses era una linea roja que no se debía pasar
• Accenture cambio el equipo responsable de un rato al otro por otro que no tenia el conocimiento del proyecto y la curva de aprendizaje se hizo cuesta arriba
• el proyecto no tenia clausulas claras de como debía manejarse y que pasaría con los retrasos y sus acciones de remediación.

como resumen: se opto por la opción de las luces mas no por la que daba la solución.

1. No permitir que Accenture sea el product owner del proyecto.
2. separar el proyecto en milestones tangilbes según metodología ágil.
3. finalizaba contrato a menos de 1año de incumplimient

Qué debió haber hecho Heartz?

-Evitar que Accenture fuera el project manager del proyecto
-No tener encargados de hacer el seguimiento del proyecto
-No tener el conocimiento para evitar las recomendaciones que les hacían en cuanto a Front
-No esclarecer con Accenture sus limitantes
-No hacer desde el inicio del proyecto el presupuesto de lo que necesitaban (como por ejemplo lo de RAPED)

No debería delegarse al 100% un proceso tan sensible para una empresa sin tener alguien involucrado desde sus filas, que entienda de TI y que esté al pendiente de temas de UX. Tal parece que sólo verían entregables finales, lo cual tampoco parece acertado. Creería que se debieron ver entregables parciales y el product owner debió estar en Hertz

comparto las lecciones que dejo este caso y que encontré en el siguiente link: https://www.linkedin.com/pulse/análisis-de-un-caso-fracaso-hertz-vs-accenture-víctor-martínez-soto/?originalSubdomain=es

lección 1: tómense en serio sus planes de riesgo
lección 2: revise cómo se transmite el conocimiento en su empresa
lección 3: afine sus políticas de retención, en función de sus ganancias
Lección 4: no permita que su cliente o su arquitecto se pierdan conversaciones técnicas claves.
lección 5: usted no puede estimar algo que no sabe cómo hacer.
Lección 6: conozca sus limitaciones

Errores de Herts:

• Delegar a terceros su estrategia de innovación.
• No apoyarse de segundas opiniones.
• Decidir no ser parte del proceso de desarrollo.

Accenture:

• Estar casado con una tecnología.
• Vender un servicio sin consultar a los equipos de desarrollo.
• No permitir a Herts ser parte del proceso de desarrollo.

Errores de Hertz:

• Delegar la definición del producto y el control de requerimientos que se desarrollarían.
  Errores de Accenture:
• Tomar el control del proyecto como product owner sin tener conocimiento del negocio.
• Filtrar los requerimientos que pedía el cliente teniendo en cuenta solo su punto de vista, no tuvo en cuenta al cliente.
• Ignorar especificaciones solicitadas por el cliente como parte del producto a desarrollar.
• No involucrar al equipo interno de Hertz para entender el negocio.

Que hubiera hecho?.

Hertz

• No despedir a mi equipo interno.
• Interiorizarme en el “stack” en demanda de la época
• Desarrollar un esquema de proyecto (empezando de lo basico y más sencillo ) de avance sobre los objetivos.
• Si la prueba más sencilla sale bien, seguir con el equipo interno y avanzar en los proyectos hasta lograr el objetivo final.

Creo que Hertz debió de haber pensado mejor en su estrategia comercial. Siento que lo que quisieron hacer fue un tech-washing de su producto y ni siquiera se quisieron esforzar en hacerlo ellos mismos o buscar seriamente que el proyecto que contrataran estuviera liderado por alguien capaz dentro de la empresa.

Por otro lado, creo que accenture tuvo este perfil de vendedor del que habló Freddy anteriormente. Primero te dice que todo es posible y presenta una propuesta increíble y después tropieza en lo técnico y “todo esta mal” por su incapacidad de realizar una propuesta que no sea bonita sino funcional.

Algunos errores que veo desde ambas perspectivas:
Hertz:

• Permitir que un servicio core de la compañía sea desarrollado por un tercero
• Permitir que el PO del producto sea de Accenture y no de Hertz. Me supone una falta de liderazgo

Accenture:

• Trabajar bajo un modelo en cascada cuando los cambios en un software se hacen de manera más rápida
• No permitir que el cliente sea el product owner del producto a entregar

Si fuese Accenture hubiese involucrado a Hertz en el proceso , hacer pruebas o pilotos antes, alinear expectativas.
Si fuese Hertz, no soltar todo el proceso al tercero, realizar seguimientos periódicos con entregables claros para ambas partes. El gran problema, como la mayoría en la condición humana, fue la comunicación.

Hertz:

1. Literalmente no había nadie metido en el proceso de elaboración del proyecto.
2. En la demanda denota que contrataron a alguien que sabía para hacer la demanda, pero por qué no estuvo implicada esta persona antes de todo.
3. ¿Será cierto que estaba claramente especificadas las cosas como indican?
4. ¿Por qué tuvieron que hacer una demanda?¿No estaban establecidas multas por incumplimiento en los plazos?
5. No consultaron cómo les iban a integrar su backend con el frontend ofrecido por parte de Accenture.
   Accenture
6. El no utilizar una metodología Agile para el desarrollo en dónde integraran a un miembro del equipo de Hertz sin duda alguna les afectó porque no podían esperar que con tanto dinero invertido, luego no quisieran detalles puntuales que estaban fuera de lo imaginado.
7. La recolección de requerimientos al parecer fue deficiente.
8. Deben realizar una buena documentación de procesos de manera que no se caiga un proyecto si falta alguien en este.
9. Debían saber bien sobre qué iban a montar su proyecto y no hubo esa revisión adecuada de las tecnologías que se debían integrar por parte del cliente con su propio frontend.

Desde **Hertz ** tenia que existir un verdadero talento Humano que supervisara el Desarrollo.

Desde **Accenture ** No hacen uso adecuado de las tecnologías, pues, son lenguajes de programación muy sencillos los que debía usar.

Mi Conclusión:

_Hertz _ no tenia ni idea de que era lo que se debía hacer para integraciones con su Software, y

_Accenture _ al parecer no tenia el personal capacitado para asumir el proyecto…

Así gane Accenture; mi lógica es que mas de 2 años desarrollando con mas de 100mil programadores… no vale!!!, eso me dice que lo que importa para ellos es la plata mas no el desarrollo de software.

Analizando el caso inicialmente se puede decir que:
Hertz
Pudo realizar el contrato con un desarrollo por etapas y de esta manera en etapas tempranas se podrían detectar inconformidades y si fuera necesario detener el proyecto, lo que se conoce como contrato de tracto sucesivo.

Accenture
Tuvo como error principal no incluir a personal de Hertz que fuera validando desde el principio si las necesidades de Hertz estaban siendo satisfechas.

Los dos debieron pactar una forma alternativa de solución de conflictos, ya que los incumplimientos de las partes son comunes en los contratos y es normal pactar que se debe hacer en esos casos. Lo más común es recurrir a un tribunal de arbitramento.

Veo varios punto:

1. Hertz delego todó. Grave. Debian tener un equipo de parte del equipo de Hertz. Minimo un Hertz debia poner al productOwner y un experto tecnico (arquitecto de soluciones o similar).
2. Pareciera que accenture no tenia el equipo tecnico correcto para entender y resolver los problemas de integraciones y/o un equipo muy junior en desarrollo. (Posiblemente un deficiencia en la contratación)
3. Le equipo que presento la iniciativa, no participó del proyecto. Esto es frecuente y un problema grave en TI., porque el vendedor se compromete con cosas que despues el equipo tecnico no puede cumplir.
4. Ademas pareciera que el proceso de desarrollo no era claro, almenos a nivel de pruebas.

Un COMITE de seguimiento constituido por Directores, Accionistas, Lider de Sistemas, abogados etc de la EMPRESA, personal clave de todas las areas de la empresa en involucrarse en el dia a dia hasta finalizar en marcha el PROCESO de mejoras requeridos … y luego el SEGUIMIENTO por un año minimo.
Para darle vista milimetrica del dia a dia de esta negociacion

• Hertz no tenía claro el alcance del proyecto desde el comienzo, y probablemente no tenía el personal adecuado para controlar el proyecto del lado del Cliente
• Accenture no dio buen manejo al proyecto y no supo ofrecer un valor agregado

Desde mi punto de vista existieron oportunidades en ambas compañías para que el proyecto no fuera exitoso.

Oportunidades Hertz
• Al tener la intención de que su página web y sus apps fueran usadas para mejorar sus 3 marcas se vuelve una ventaja competitiva que necesita la flexibilidad de adaptarse a los cambios futuros del mercado. Además, tiene un impacto directo a los 3 negocios de la empresa, por lo que lo ideal era tomar la decisión de desarrollar un equipo interno que le diera vida, mantenimiento e innovación con flexibilidad en adelante.
• Otra oportunidad fué ceder el control completo del proyecto a Accenture sin un Product Owner/Product Manager de Hertz que revisara frecuentemente funcionalidad de los avances mediante procesos de gestión de proyectos como Sprints de la metodología SCRUM|Agile.

Oportunidades Accenture
• Las personas que lideraron el proyecto por parte de Accenture no tenían el conocimiento para el proyecto solicitado. Esto debido a que no realizaron un análisis a profundidad de la petición de Hertz para integrar las mejoras tanto en la página web como en las Apps, ya que de haberlo hecho a ese nivel hubieran identificado las implicaciones reales del proyecto dónde tendrían 2 opciones: 1) No tomar el proyecto por el grado de complejidad debido a que no tenían el talento y recursos para hacerlo posible ó 2) Establecer tiempos y costos adecuados para el proyecto.
• El punto previo se volvió más evidente cuándo el proyecto no estaba caminando y ofrecieron a Hertz una solución previamente diseñada que intentarían adaptar a sus necesidades cuándo la petición fue un desarrollo especifico para cubrir las necesidades de Hertz.
• La programación de los códigos se hizo fuera del estándar de Java y esto generó mayores complicaciones en el proyecto, extendiendo aún más el tiempo de entrega y recursos necesarios para rescatar el proyecto. Trayendo como consecuencia el cambio del líder del proyecto que impactó aún más en retrasos.

En conclusión, ambos contribuyeron al fracaso del proyecto aunque en este caso el que tuvo mayor impacto en su negocio fue Hertz no sólo a nivel económico sino por el tiempo transcurrido sin implementar la solución a su problema dónde Uber y Lift ganaron más terreno en el mercado.

Como Hertz: Ampliar el equipo de desarrollo para afrontar el reto ya que era escalable y muy personalizado al modelo de negocio, esto no seria una solución a corto plazo pero si una solución definitiva a mediano y largo plazo.

Como Accenture: Bueno si te están pagando lo que estas cobrando, si o si resolver todas las necesidades del cliente sea como sea. Si pagas lo que pido hago lo que digas!
Es inaceptable entregar un producto que no sea responsive es algo básico, si prestas servicios como lo que indicas, debes ser un experto en todos los posibles inconvenientes y estudiar muy bien el proyecto.

Siempre el estudio completo de un proyecto es primordial, si es mucho trabajo hacerlo, cobra por levantar ese estudio, pero no esta bien que algo quede a media si tu diste tu precio para ponerlo en funcionamiento.

Si estuviera de lado de Accenture, seleccionar el personal que estará a cargo de realizar el trabajo, es obvio de que en casi todas las organizaciones quedan dinosaurios tecnológicos que se mantienen porque en algún momento dieron buenos resultados a la empresa, pero como dice el dicho, crea fama y échate a la cama, probablemente, quedaron rezagados con las nuevas tecnologías y según relatas la historia, parecía que querían adaptar algo que ya tenían y lógicamente se les complicaba porque lo que trataban de hacer era adaptar su solución a lo que quería el cliente, concluyendo, seleccionaría al personal idóneo para este trabajo con el que cuento actualmente y reemplazaría al que no sirve con recurso humano experimentado en tecnologías agiles y plataformas modernas, con esa información haría una evaluación de costos y plazos para determinar si es factible la realización del proyecto.

Del lado de Hertz:
Incluiría una cláusula de confidencialidad debido a la sensibilidad de la información, analizar con expertos las propuestas presentadas, formar un equipo de apoyo que incluya usuarios finales para que trabaje junto a Accenture y testee los prototipos, esté al tanto de los avances del proyecto e informe tempranamente los inconvenientes encontrados. Hacer desembolsos de dinero, solo cuando se hayan alcanzado las metas y los plazos estipulados en el contrato.

De comprobarse los incumplimientos que Accenture tuvo hacia Hertz, considero que ambos tuvieron fallas, primero Hertz no debió depender casi por completo el desarrollo de su aplicación, luego que Accenture no haya cumplido con una ética profesional informando o justificando la demora en el desarrollo.
Para ambas empresas hubiese prestado más atención en el talento, y tratándose de un desarrollo con poca experiencia y tan importante, preferiría no haber aceptado el proyecto.

Uno de los tantos erroes de Hertz, a mi modo de ver fue entregar todo el proyecto a Accenture y no hacer el seguimiento respectivo del mismo. Se debieron conformar equipos con personas de las 2 empresas para el proyecto.

Esto parece a las clases que tube en la maestría.

Lo mejor es contratar un equipo para que lo desarrolle in house, porque de esa forma pueden iterar los cambios que los usuarios tengan y mantenerse en el mercado.

Hertz como product owner. No Accenture. El desarrollo de la experiencia, ademas es CORE.

En Hertz dieron demasiado poder a Accenture, y aunque no ha terminado, parece que no había expertos en el tema del lado de Hertz.

Pues Hertz pudo haber construido su app inhouse, definitivamente. Y por la forma en que hablan en la demanda suena a que tienen los conocimientos técnicos suficientes para haberlo hecho. Esa aplicación es del core de su negocio, no tenían por qué haber contratado a Accenture in the first place.

De las primeras cosas que podría nombrar es la falta de comunicación efectiva entre los equipos Hertz
y Accenture. Equipos resolutivos tanto proveedor como cliente.

Desde el principio Hertz debió hacer este proyecto in-house y tener a todo el equipo trabajando de su lado y no buscando otros intereses.

SCRUM

Yo solo hubiera hecho una cosa diferente.

1. • Contratar a Jhon Freddy Vega. Como virgin lo hizo…😉

Hertz era dueño de su Backend ellos mismos podrian hacer las modificaciones sin contratar un tercero, quizas mejorando su equipo con una buena contratación.