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.

Demandan a consultora de desarrollo web por $35 millones de dólares | PlatziLive

Accenture vs. Hertz.pdf

El Ciclo de Vida de la Tecnología en las Empresas

Tienes una idea o un problema que quieres solucionar y muy probablemente lo quieres solucionar con tecnología. Antes de ponernos a planear cómo solucionar con tecnología tenemos que crear un proceso de especificación