Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Teradyne
Teradyne
MAY 3, 2006
FRANCESCA GINO
GARY PISANO
El Proyecto Jaguar había marcado una especie de culminación del esfuerzo de ocho años de
Teradyne por mejorar su proceso de desarrollo de productos. El equipo de Jaguar había utilizado una
serie de prácticas de gestión de proyectos, incluyendo un intensivo planeamiento inicial de proyectos,
herramientas formales para rastrear el progreso de los proyectos y un proceso más estructurado de
desarrollo. La mayoría de los aspectos del Proyecto Jaguar fueron extraordinariamente buenos. Por
ejemplo, todo el hardware de más importancia se había desarrollado en un tiempo récord y con una
desviación mínima del plan. El producto se había ajustado a la gran mayoría de sus especificaciones
objetivo. Sin embargo, al mismo tiempo, el software, un importante componente del programa, se
había retrasado mucho en comparación con el cronograma y todavía no estaba terminado. Además,
los costos totales de desarrollo resultaron ser un 35% más altos de lo inicialmente presupuestado.
Aunque algunos miembros del equipo Jaguar adoptaron las herramientas de gestión de proyectos,
otros ofrecieron una fuerte resistencia, o simplemente las ignoraron. O‘Brien explicó:
Pero otros se mostraban más escépticos. George Conner, arquitecto del sistema Jaguar, pensaba
que las herramientas podrían ser una distracción:
________________________________________________________________________________________________________________
El caso de LACC número 610-S17 es la versión en español del caso de HBS número 606-042. Los casos de HBS se desarrollan únicamente para su
discusión en clase. No es el objetivo de los casos servir de avales, fuentes de datos primarios, o ejemplos de una administración buena o
deficiente.
Copyright 2007 President and Fellows of Harvard College. No se permitirá la reproducción, almacenaje, uso en planilla de cálculo o transmisión
en forma alguna: electrónica, mecánica, fotocopiado, grabación u otro procedimiento, sin permiso de Harvard Business School.
This document is authorized for use only in Magda Graciela Briones's PER 6034-MBA-MODULO3-5 at Universidad International De la Rioja SA from Apr 2022 to Oct 2022.
610-S17 Teradyne Corporation: El Proyecto Jaguar
De acuerdo con la profunda creencia de Teradyne en la mejora continua, O‘Brien y la alta gerencia
empezarían ahora un proceso de disección de la historia del proyecto y aprovechamiento de las
lecciones aprendidas. El resultado del proceso afectaría la forma en que Teradyne ejecutaría los
proyectos de desarrollo en los años venideros. Como el tráfico avanzaba poco a poco, O‘Brien se
impacientó. Odiaba llegar tarde.
Durante este tiempo Teradyne también se había diversificado hacia otros mercados conexos de
pruebas electrónicas. En 2004, Teradyne tenía cinco unidades principales de negocios —Prueba de
Semiconductores, Prueba de Ensamblaje. Prueba de Banda Ancha, Sistemas de Conexión y
Soluciones de Diagnóstico— que estaban organizadas por los productos que desarrollaban y
brindaban. Prueba de Semiconductores era la unidad de negocios más grande de la corporación y
representó el 64% de todos los ingresos de la empresa en 2004. La unidad de Prueba de
Semiconductores tenía importantes operaciones de ingeniería ubicadas en Boston (Massachusetts),
North Reading (Massachusetts), Minneapolis (Minnesota), Tualatin (Oregon), San José (California) y
Agoura Hills (California). Boston, North Reading y Agoura Hills también albergaban las operaciones
de manufactura de la empresa. La manufactura interna de la empresa se concentraba en ensamblaje
final y prueba (los subsistemas y componentes se subcontrataban). Además, la empresa tenía ventas y
organizaciones más pequeñas de ingeniería dispersas en sus principales mercados mundiales,
incluyendo Japón, China y Alemania.
This document is authorized for use only in Magda Graciela Briones's PER 6034-MBA-MODULO3-5 at Universidad International De la Rioja SA from Apr 2022 to Oct 2022.
Teradyne Corporation: El Proyecto Jaguar 610-S17
Cultura de Teradyne
Teradyne mantuvo la fuerte cultura de ingeniería que le imprimieron sus fundadores. Muchos de
sus altos gerentes eran ingenieros bien capacitados. La posición jerárquica estaba impulsada por el
desempeño, especialmente la aptitud técnica. El vestido era casual. Los espacios de oficina eran
cubículos, incluso para los ejecutivos de más alto rango de la empresa. La cultura estimulaba la
iniciativa individual. A los nuevos reclutas se les advertía que nadie les diría qué hacer, sino que era
su responsabilidad “meterse a profundidad” y “hacer las preguntas correctas”. Las largas horas de
This document is authorized for use only in Magda Graciela Briones's PER 6034-MBA-MODULO3-5 at Universidad International De la Rioja SA from Apr 2022 to Oct 2022.
610-S17 Teradyne Corporation: El Proyecto Jaguar
trabajo eran la norma. En general, a la empresa le iba bien en el reclutamiento de ingenieros de las
mejores escuelas tales como el MIT y en la retención de este talento durante varios años. La mayoría
de los altos ejecutivos de la empresa había pasado la mayor parte de sus carreras con Teradyne.
En ese momento, los problemas de la empresa entraban en dos categorías. En primer lugar, las
organizaciones de ingeniería en toda la empresa estaban excesivamente comprometidas con diversos
proyectos (la utilización de la capacidad se estimaba en hasta un 300%). Para abordar este problema,
la empresa implementó un proceso más estructurado y riguroso de planificación de capacidad de
proyectos conocido como Planificación Agregada de Proyectos (PAP). Dicho proceso seguía dos
principios orientadores: (1) emprender solo los proyectos que se alinearan con la estrategia general de
la empresa y (2) no comprometerse excesivamente y solo empezar proyectos cuando se dispusiera de
This document is authorized for use only in Magda Graciela Briones's PER 6034-MBA-MODULO3-5 at Universidad International De la Rioja SA from Apr 2022 to Oct 2022.
Teradyne Corporation: El Proyecto Jaguar 610-S17
recursos suficientes y adecuados. Aunque aparentemente era una herramienta simple para usar, la
Planificación Agregada de Proyectos requería mucho cambio de conducta y disciplina.
Debido a que era contra la cultura de Teradyne imponer el uso de cualquier herramienta
específica, se dejaba a cada división y a cada gerente decidir qué recomendaciones seguir. Algunas
divisiones de la empresa adoptaron rápidamente el método, mientras que otras parecían resistirlo o
simplemente ignorarlo. Esto último era a menudo una fuente de tensión en las reuniones mensuales
de equipo de mejora de procesos de ingeniería donde se esperaba que los gerentes de ingeniería
informaran sobre el progreso de sus divisiones. Incluso dentro de las divisiones, el progreso era
sumamente variable. Algunos gerentes de proyecto seguían el modelo de revisión por fases, se
ocupaban de una planificación más detallada de proyectos y hacían rigurosas inspecciones a
posteriori, mientras que otros no. Rogas se sentía cada vez más frustrado con lo que él veía como
comportamiento “pasivo agresivo”. Más preocupante para Rogas era la falta de cambio de conducta.
Él se lamentó diciendo: “Algunas personas cumplían con utilizar las herramientas pero no estaban
cambiando realmente su comportamiento. Todavía estaban comprometiéndose en exceso. Todavía
estaban generando cronogramas poco realistas de trabajo. No eran intelectualmente honrados“.
1 La matriz de estrategia de ejecución de proyectos (MEEP) sirvió de marco para crear un entendimiento común y decisiones
críticas controladas y bien ejecutadas. Se desarrolló identificando las seis aptitudes inherentes a cualquier proyecto de
desarrollo de producto y los principios, procesos y estructuras subyacentes que influyen esas aptitudes.
This document is authorized for use only in Magda Graciela Briones's PER 6034-MBA-MODULO3-5 at Universidad International De la Rioja SA from Apr 2022 to Oct 2022.
610-S17 Teradyne Corporation: El Proyecto Jaguar
Para mediados de los 90, los cambios en el mercado empezaron a erosionar la lógica de esta
estrategia. En particular, al diversificarse los fabricantes de semiconductores hacia una gama más
amplia de tipos de dispositivo, pedían cada vez más una plataforma de probador que pudiera poner
a prueba múltiples tipos de dispositivos. Esta tendencia se aceleró a finales de los 90 con el
crecimiento de los fabricantes de semiconductores por contrato, cuyo modelo de negocio era ofrecer
una amplia gama de servicios de prueba de dispositivos. Para estos clientes, las tasas de utilización
de probadores para dispositivos específicos eran demasiado bajas para ser económicamente viables.
Aunque Teradyne había ofrecido previamente probadores flexibles en el extremo de desempeño
mediano/bajo del mercado de prueba de dispositivos, la empresa no tenía una plataforma con el
desempeño necesario para hacer frente a todo el mercado. Tal como lo explicó Joe Wrinn,
vicepresidente de Ingeniería de Plataforma: “Para finales de los 90 era evidente que esta estrategia no
estaba funcionando. El desarrollo de las plataformas se estaba volviendo más complicado y costoso.
Se estaba haciendo cada vez menos factible desarrollar múltiples plataformas“.
Varios de los competidores de Teradyne habían empezado a desarrollar una plataforma única de
probador a finales de los 90. Mark Jagiela, jefe de mercadeo para sistemas de prueba de
semiconductores, recordó:
Teradyne había estado atendiendo bien el mercado con una variedad de productos
optimizados y adaptados a las necesidades de diversos segmentos. Cuando vimos la
oportunidad de pasar a una estrategia de plataforma más flexible y consolidada, varios
competidores ya estaban avanzando en esa dirección. Por tanto, aunque teníamos la ventaja de
aplicar tecnología más nueva a la arquitectura, íbamos a llegar más tarde al mercado.
En 2001, la alta gerencia de Teradyne tomó una decisión estratégica fundamental de adoptar una
estrategia de plataforma flexible. La empresa se reorganizó, suprimió las organizaciones de ingeniería
de plataforma concentradas en segmento de mercado y las fusionó en un solo grupo de ingeniería de
plataforma. En 2001 se inició un proyecto fundamental de este nuevo grupo —cuyo nombre en
código era “Jaguar” — dirigido a crear una plataforma altamente flexible de probador que pudiera
adaptarse fácilmente a las necesidades de diversos segmentos de dispositivos. Se esperaba que esta
constituyera una importante parte de los ingresos de la empresa durante los próximos 10 años.
El Proyecto Jaguar
O’Brien, un veterano de 25 años en la organización de ingeniería de Teradyne, fue nombrado
líder de proyecto. Casi de inmediato se enfrentó con un asunto espinoso. Antes de la reorganización,
las organizaciones de ingeniería de Teradyne en Boston y Agoura Hills, tenían sus propios proyectos
de probador flexible en marcha. La decisión de lanzar el Proyecto Jaguar significaba fusionar los
esfuerzos de estos dos equipos. Sin embargo, los equipos de legado tanto de la Costa Este como de la
Costa Oeste de los equipos tenían sus métodos favoritos y surgieron tensiones respecto a cuál método
“ganaría”. Tal como lo dijo Joe Carbone, gerente de Analog Instrumentation Porting: “La fusión de
los equipos creó ciertas tensiones. Este no fue un grupo que se unió voluntariamente, y hubo algunas
batallas sobre enfoques técnicos “.
This document is authorized for use only in Magda Graciela Briones's PER 6034-MBA-MODULO3-5 at Universidad International De la Rioja SA from Apr 2022 to Oct 2022.
Teradyne Corporation: El Proyecto Jaguar 610-S17
Desde el principio, se reconoció que el proyecto tenía que ejecutarse a la perfección. Como lo
señaló Mike Bradley, entonces presidente de la División de Prueba de Semiconductores:
Fue una escogencia estratégica simple pero monumental. Teníamos una sólida base
instalada de clientes comprometidos con nuestras plataformas existentes. Pasar a una sola
plataforma de control significaba perturbar esta base instalada. Esto era riesgoso, por decir lo
mínimo. Y significaba que la escogencia del momento era absolutamente crítica. Si nos
hubiéramos quedado con nuestras arquitecturas existentes, podríamos haber argumentado
ante nuestros clientes que valdría la pena esperar nuestros nuevos productos. Pero una vez que
nos comprometimos con una estrategia de control y una nueva arquitectura de plataforma
única, ya no podíamos argumentar eso. Esto significaba que teníamos que llevar el nuevo
probador al mercado tan rápido como fuera posible o dejaríamos a muchos de nuestros
clientes expuestos a la competencia.
Se decidió que por ahí de junio de 2004 sería una fecha objetivo crítica para empezar a despachar
el probador. En vista de lo mucho que estaba en juego en el éxito del proyecto, la división y los altos
líderes corporativos se interesaron activamente y desde el principio en el proyecto. Un área de
atención temprana fue el establecimiento de un ámbito claro para el proyecto. Bradley explicó:
Las decisiones más críticas en la fijación del tamaño del productos no tienen que ver con lo
que se hace, sino con lo que no se hace. En el pasado tendíamos a “apostarlo todo” al
dimensionamiento inicial, y luego quitábamos características al sistema, cuando no podíamos
cumplir con el cronograma de trabajo. Con el Jaguar, tuvimos que hacer lo contrario para
cerciorarnos de aprovechar la ventana de mercado. Este fue un cambio incómodo, pero que
tuvimos que hacer.
En la práctica, esto significó pasar más tiempo de lo usual en las primeras etapas del proceso de
desarrollo (desarrollo conceptual y planificación de productos). Bradley y otros altos gerentes
presionaron a O’Brien y a su equipo para que identificaran claramente las necesidades del cliente y se
comprometieran con especificaciones clave de productos. Además, la alta gerencia también impulsó
al equipo a identificar todos los riesgos técnicos críticos y los planes de contingencia para manejar
esos riesgos. Como parte del proceso de desarrollo de Teradyne, no se harían grandes compromisos
de financiamiento para un proyecto hasta que la alta gerencia accediera a apoyar la Fase 2. Pasar esta
puerta requería una serie de análisis detallados y una expresión clara de los requisitos del producto.
En el Proyecto Jaguar, esto causó inicialmente cierta frustración, ya que el equipo estaba ansioso por
proceder con la ingeniería detallada. [George] Conner comentó:
Tenemos la tendencia a acumular todo en la Fase II debido a que la alta gerencia espera un
alto nivel de certidumbre antes de comprometerse con el programa. Terminamos por tener que
presentar planes detallados, cronogramas y especificaciones en ese punto y esto deja menos
espacio para la experimentación en la Fase III. Quizás yo sea el único con esta perspectiva, pero
creo que la Fase II debe limitarse a identificar riesgos y a entender si se pueden resolver en la
Fase III.
En mayo de 2002 el equipo Jaguar regresó a la alta gerencia con una presentación de 75 páginas
que detallaba la arquitectura del sistema propuesto, el diseño y las especificaciones funcionales para
los subsistemas críticos, las especificaciones objetivo de desempeño y el plan de ejecución del
proyecto. Satisfechos de que el alcance del proyecto estaba claramente definido, enfocado y alineado
con el mercado, los altos gerentes aprobaron formalmente la Fase 2.
This document is authorized for use only in Magda Graciela Briones's PER 6034-MBA-MODULO3-5 at Universidad International De la Rioja SA from Apr 2022 to Oct 2022.
610-S17 Teradyne Corporation: El Proyecto Jaguar
Los miembros del equipo básico eran principalmente veteranos de Teradyne. Como lo comentó
O’Brien: “El proyecto empezó con una mezcla de a quién necesitábamos y quién estaba disponible. Al
pasar el tiempo, la organización se mejoró constantemente conforme se disponía de talento. La
mejora más notable, tanto en talento como en capacidad, se produjo cuando Teradyne decidió salir
del negocio de memoria, lo que liberó a varios líderes así como unos 60 ingenieros”. La parte de
ingeniería del equipo básico estaba bajo las órdenes de O‘Brien. Los miembros del equipo básico
sabían que tenían que rendirle cuentas por los resultados. Giebel, que acababa de empezar a trabajar
para O‘Brien al principio del Proyecto Jaguar, señaló: “Jack podía ser muy intenso en estas reuniones.
Si su parte del proyecto se presentaba en forma tardía, él quería saber por qué y más valía tener una
buena explicación. Era excelente para buscar las causas fundamentales. Sin embargo, eso podía
incomodar a algunas personas. Él no proporcionaba mucha seguridad sicológica.
Carbone, quien también había trabajado en estrecha colaboración con Jack por muchos años,
señaló: “Yo no consideré que Jack fuera una persona estresante en absoluto para trabajar con él. De
los gerentes de Teradyne, considero que es el más fácil para trabajar. Es totalmente honesto. Y es un
gran pensador estratégico“. Incluso los que pensaban que O‘Brien podía a veces ser grosero quedaron
impresionados con su capacidad para guiar un proyecto tan complejo a través del desarrollo bajo una
intensa presión. En las palabras de Peter Breger, gerente de Ingeniería de Hardware de Jaguar: “No
había nadie mejor que Jack en esta organización para sacar adelante un proyecto como este”.
Estructura de división del trabajo, una descripción detallada de todas las tareas necesarias para
completar un proyecto, y su relación entre sí.
Estimación de tres puntos, una técnica para estimar el tiempo mínimo (mejor de los casos),
máximo (peor de los casos) y los tiempos esperados necesarios para completar cada tarea.
Análisis de ruta crítica, que utilizaba la estructura de división del trabajo y las estimaciones de
tres puntos para identificar las tareas ‘cuello de botella‘ en el proceso de desarrollo (es decir,
aquellas tareas que determinaban el tiempo total de antelación del proyecto).
This document is authorized for use only in Magda Graciela Briones's PER 6034-MBA-MODULO3-5 at Universidad International De la Rioja SA from Apr 2022 to Oct 2022.
Teradyne Corporation: El Proyecto Jaguar 610-S17
Análisis de valor devengado, un método para medir el progreso del proyecto mediante la
comparación de los recursos (o el tiempo) reales y esperados que se han invertido.
O’Brien estaba convencido de que estas metodologías proporcionarían un sólido medio para
comunicar el estado del proyecto a la gerencia y para identificar problemas críticos (tales como
posibles retrasos) que requería medidas o apoyo de la alta gerencia. A fin de facilitar el uso de las
herramientas en el proyecto, se estableció una función separada de “gestión de programa” como
parte del equipo básico. Giebel fue nombrado gerente del programa como subalterno directo de
O’Brien. Giebel era responsable de cerciorarse de que se usaran las herramientas de gestión de
proyectos y que los datos pertinentes sobre progreso del proyecto, programación y ruta crítica se
analizaran y estuvieran a disposición del equipo. Tal como lo describió un miembro del equipo,
Giebel también era responsable de “mantener la integridad del equipo”. Cada subequipo tenía
también su propio gerente de programa. Estos gerentes de programa eran responsables de rastrear el
progreso y analizar datos para las tareas de su subequipo particular. Para asegurar la convergencia
de los cronogramas de trabajo de todos los subequipos, los datos se introducían en un programa
maestro de planificación basado en la Web llamado Primavera, que podía incorporar unas 15.000
tareas separadas.
El uso de las herramientas implicaba diferentes desafíos para el hardware y el software del
proyecto. Giebel explicó:
La relación intertemporal entre cada tarea se especificaba de antemano para que el programa
pudiera calcular el impacto del retraso en una tarea sobre la otra tarea, así como el cronograma
general de trabajo. El programa Primavera se usaba para identificar la ruta crítica (RC) en cada punto
del proyecto. Giebel explicó:
Nos reuníamos cada semana para analizar la ruta crítica. Nuestra reunión implicaba debate
y discusión acerca de la ruta crítica. Primero se establecía y luego era revisada por los
miembros del equipo. Se esperaba que todos supieran lo que estaba en su reporte de ruta
crítica. Y no era nada fácil, puesto que teníamos una profundidad de diez estratos en el
informe ruta crítica. De esta manera, la mayoría de las áreas del proyecto se mantenían visibles.
En la creación del cronograma de trabajo usamos estimaciones de tres puntos. Esto significaba
que para cada tarea del proyecto, se tomaban en cuenta tres escenarios: el optimista, el más
probable y el pesimista. Ejecutamos el proyecto con las duraciones “más probables”. Nuestra
fecha comprometida de envío era el 30 de junio de 2004, pero el cronograma de trabajo se
impulsaba con una fecha anterior (31 de marzo de 2004). Esta fecha se utilizaba en el informe
del ruta crítica y mantenía mucha tensión en los primeros hitos.
This document is authorized for use only in Magda Graciela Briones's PER 6034-MBA-MODULO3-5 at Universidad International De la Rioja SA from Apr 2022 to Oct 2022.
610-S17 Teradyne Corporation: El Proyecto Jaguar
Una de las áreas clave de atención gerencial fue el desarrollo de los cinco circuitos integrados para
aplicaciones específicas (los ASIC) que formaban el núcleo del sistema. Estos circuitos integrados
estaban a la vanguardia en términos de complejidad, sofisticación y costo. En proyectos anteriores,
los problemas con el desarrollo de circuitos integrados para aplicaciones específicas habían sido una
importante fuente de retrasos (a menudo de seis meses a un año). En particular, el descubrimiento de
problemas de diseño a finales del proceso a menudo tenía como resultado en “reelaboraciones” de
todo el chip. Para reducir el potencial de estos retrasos, el equipo de circuitos integrados para
aplicaciones específicas de Jaguar hizo fuertes inversiones simulación y otras metodologías de
prueba al comienzo del ciclo de desarrollo. Wrinn comentó: “Históricamente, en el desarrollo de
circuitos integrados para aplicaciones específicas gastábamos la mayor parte de nuestros recursos en
desarrollo y muy pocos en prueba. En el Proyecto Jaguar invertimos la proporción“. Este enfoque dio
sus frutos, ya que prácticamente todos los circuitos integrados para aplicaciones específicas se
terminaron a tiempo y sin problemas importantes de diseño.
Mientras que los subsistemas de hardware en gran medida fueron capaces de mantenerse según
lo programado, el desarrollo de software se convirtió en un problema. (Véase en el anexo 7 un
cronograma del proceso de desarrollo para el Proyecto Jaguar.) La nueva plataforma utilizaría un
sistema operativo basado en Windows NT llamado IG-XL, que se había desarrollado en el sitio de
Boston de Teradyne para usarlo en la plataforma llamada FLEX. Debido a que el grupo de software
de Boston estaba ocupado en desarrollar extensiones para la línea existente de producto de Flex y en
corregir imperfecciones, el desarrollo del software de Jaguar tuvo que dotarse principalmente de
personal de Agoura. Paul Roush, quien encabezó este esfuerzo, señaló que esto causó algunos
problemas desde el principio:
La mayoría de los desarrolladores de Jaguar nunca antes habían trabajado con IG-XL. Unos
pocos tenían un conocimiento limitado de una generación más antigua de IG-XL. Los expertos
en la plataforma IG-XL se encontraban en Boston y se concentraban en ampliar y fijar la base
de código FLEX. Estos expertos tenían poco tiempo para dedicar al desarrollo del Jaguar. En
ese momento la prioridad de la empresa era Flex, con frecuentes declaraciones en el sentido de
que “si Flex no tiene éxito, no habrá un mercado para Jaguar”. El equipo de desarrollo de
Jaguar subestimó el grado de la curva de aprendizaje de la nueva plataforma. Incluso con lo
que se creía y se pretendía que fueran cálculos prudentes, estábamos retrasados.
Diversas medidas de proyectos indicaban un problema. Por ejemplo, para el primer año del
programa, el software se estaba ejecutando a aproximadamente el 50% del valor devengado por mes.
Si esto era cierto, significaba que el software estaba realizando solo la mitad de las tareas que se
habían previsto originalmente. Kevin Giebel señaló: “El departamento de software no lo admitía.
10
This document is authorized for use only in Magda Graciela Briones's PER 6034-MBA-MODULO3-5 at Universidad International De la Rioja SA from Apr 2022 to Oct 2022.
Teradyne Corporation: El Proyecto Jaguar 610-S17
Repetían constantemente que iban a ponerse al día“. Cuando se preguntó por qué la gerencia del
equipo básico o la alta gerencia no intervenían, Giebel dijo: ”Una de las razones era que el equipo de
gerencia no prestó suficiente atención a los datos debido a su escepticismo en torno a la medida“.
Conner agregó: ”El problema del software surgió gradualmente. No lo vimos sino hasta muy tarde,
pero todos sabíamos que el asunto estaba mal“.
La capacidad del equipo para adaptarse fue puesta severamente a prueba en septiembre de 2003,
cuando Teradyne recibió la noticia de que una de las mayores empresas de semiconductores del
mundo, llamada AlphaTech, un enorme cliente potencial, estaba a punto de comprometerse con un
sistema de la competencia. La alta gerencia vio esto como un fuerte golpe potencial a todo el
programa. El tamaño de AlphaTech, y su estatura en el mercado, significaban que su escogencia
tendría una poderosa influencia en el resto de la industria. Bradley comentó: “La idea de poner un
nuevo producto o un cliente estratégico en riesgo no era algo que fuéramos a tomar a la ligera.
Nuestro equipo de desarrollo tenía que apoyar plenamente el esfuerzo para tener el Jaguar listo a
tiempo para este importante cliente, y así lo hizo”.
El desafío era que Teradyne no esperaba tener un sistema listo para su evaluación hasta junio de
2004, a casi 10 meses de distancia. Mientras tanto, el sistema de la competencia ya estaba terminado y
en los laboratorios de evaluación de AlphaTech. Rogas, que había trabajado estrechamente con
AlphaTech por más de 20 años, comentó:
AlphaTech decidió darle a Teradyne una oportunidad de ofertar por el negocio, pero dejó claro
que tendría que tener un sistema listo para el 30 de marzo de 2004 y que no se toleraría ninguna
desviación en el cronograma. Teradyne se comprometió con un detallado cronograma, con revisiones
mensuales con la gerencia de AlphaTech previo a la fecha del 30 de marzo. A Teradyne no se le
permitiría dejar de alcanzar ni un hito. Además, ahora tenía que incorporar una funcionalidad muy
específica requerida por AlphaTech que no era parte del plan original de desarrollo. En vista de lo
que estaba en juego en el pedido de AlphaTech, no había otra opción que comprometerse. Los
subequipos más afectados fueron los que tuvieron que incorporar la nueva funcionalidad requerida
por AlphaTech. Carbone recordó: “El envío de AlphaTech puso una enorme presión sobre el equipo
que era responsable por el gran instrumento de suministro de energía. Se vieron obligados a terminar
su parte en la mitad del tiempo previsto inicialmente. Esto no tenía nada que ver con el proceso. Era
puro orgullo. Allí la gente estaba trabajando 80 horas por semana.
El impacto del pedido de AlphaTech fue profundo. Todos señalaron que tener un “cliente real”
con una fecha límite concreta fue un enorme motivador, pero el acelerado cronograma perturbó el
proyecto. Aunque todos los subsistemas de hardware se las arreglaron para alcanzar sus nuevos
hitos, el software sufrió aún más retraso. En enero de 2004, la alta gerencia asignó otros 15 ingenieros
de software al proyecto para contrarrestar el problema. Roush, quien dirigía el equipo de software en
ese momento, reflexionó sobre la intensa presión:
Adelantar la primera fecha de envío al cliente requirió sacar características antes de que
estuvieran listas. Tuvimos inquietudes y estas se discutieron, pero el consenso del equipo
básico fue que era mejor aceptar cierto riesgo y tratar agresivamente de capturar el negocio de
AlphaTech que apartarnos. Hubo mucha presión por cumplir con el plazo. No fuimos
11
This document is authorized for use only in Magda Graciela Briones's PER 6034-MBA-MODULO3-5 at Universidad International De la Rioja SA from Apr 2022 to Oct 2022.
610-S17 Teradyne Corporation: El Proyecto Jaguar
Al acercarse la fecha de cierre, el equipo de software cambió su esfuerzo casi por completo y se
dedicó a corregir errores y a producir un software aceptable y funcional para AlphaTech. Carbone
señaló: “El equipo de software estaba bajo una enorme presión y seguía empeorando al cometer
errores. Los niveles de estrés eran mucho mayores de lo usual. Hubo mucho agotamiento. El hecho
de que perdieran a muy pocas personas es un homenaje al liderazgo de Paul [Roush]. Ese equipo fue
increíblemente leal a Paul.
Carbone, que había trabajado tanto en el desarrollo de hardware como de software durante sus 27
años en Teradyne, reflexionó sobre los desafíos que enfrentó el equipo de software: “Cuando uno
trabaja con hardware hay puntos fijos en el proceso, el primer tablero, el arte, etc. Estos son puntos
objetivos y tangibles del proceso. Si no se completan, uno lo sabe. Uno no se puede mentir a sí
mismo. Con el software, es mucho más difícil. Uno no tiene estos puntos“. Conner pensaba que los
problemas eran mucho más endémicos en la empresa:” En Teradyne, tenemos una sensación intuitiva
de cuáles son los problemas de hardware. Sin embargo, no tenemos esa sensación en el software”.
El 30 de marzo de 2004, tal como se había prometido, Teradyne envió el primer sistema completo
a AlphaTech para su evaluación. Todos los subsistemas de hardware cumplieron con sus
especificaciones. El software no incorporaba todas las características solicitadas inicialmente por
AlphaTech y estaba cargado de errores, pero era funcional. Durante los siguientes seis meses, el
equipo de software se concentró exclusivamente en mejorar el software y corregir errores para
AlphaTech. Roush señaló: “Básicamente dejamos de hacer desarrollo en ese punto y solo trabajamos
en errores”. Y Carbone recordó: “Tuvieron que cambiarse a solo la modalidad de apagar incendios.
Cualquier sentido de proceso desapareció. Ya no se ocupaban en desarrollo; solo estaban tratando de
corregir errores para AlphaTech. Al final estaban codificando día a día y cargando el software para
AlphaTech a través de la Web“. En junio de 2004 se agregaron más ingenieros de software al
proyecto.
El desafío de software del programa Jaguar resultó ser mayor de lo previsto. En diciembre de
2004, los componentes de hardware de la plataforma ahora denominada “Ultra Flex 1” ya se habían
concluido en gran medida a tiempo y dos grandes clientes accedieron a comprar el sistema ahora
denominado “Ultra Flex” (véase el anexo 8). Sin embargo, debido a los retrasos en conseguir el
software en línea, el aumento de volumen de producción del producto se postergó seis meses. Jagiela
comentó: “Los primeros indicios señalan que tenemos el producto adecuado para el mercado. Los
puntos de referencia competitivos están poniéndose a favor de la Flex Ultra y tenemos una serie de
adiciones posteriores a la plataforma previstas en 2005 para mantener el impulso. Postergar el
aumento de volumen seis meses más allá de lo planeado fue una decisión difícil, pero debemos
madurar más el software antes de distribuirlo ampliamente”.
12
This document is authorized for use only in Magda Graciela Briones's PER 6034-MBA-MODULO3-5 at Universidad International De la Rioja SA from Apr 2022 to Oct 2022.
Teradyne Corporation: El Proyecto Jaguar 610-S17
Giebel era un fuerte defensor del uso continuo de herramientas de gestión de proyectos y veía los
problemas en gran medida en términos de uso indebido. Él comentó: “Con mucha frecuencia, los
miembros del equipo no sabían ‘cómo sacar valor de las herramientas que estaban utilizando’ y
pensaban que ‘podían haber descubierto lo que estaba mal sin ellas’”. Giebel creía que, con más
experiencia, y tal vez con un poco más de capacitación, se podía corregir este problema.
O’Brien era también un firme creyente en el valor de las herramientas del proyecto. Consideraba
funcionales las herramientas, pero se autocriticaba y criticaba a los otros miembros de la organización
por no reaccionar siempre a los datos. Él señaló: “Nuestro problema no era la falta de datos, sino
tener los datos en frente y no responder”. Carbone, quien también creía en el valor de las
herramientas, estuvo de acuerdo con el punto de O’Brien. Al recordar las luchas del equipo de
software, Carbone señaló: “Las herramientas permitieron a los miembros del equipo de software
mentirse a sí mismos. Siguieron haciendo arreglos a la ruta crítica, poniendo las cosas en paralelo,
agregando recursos, etc. para lograr ajuste. Algunas personas muy fuertes se dejaron engañar por los
datos. Jack dejó que la medida lo engañara. El desastre del software fue evidente gracias al VD2, pero
la ignoramos (véase el anexo 9)”.
Simon Longson, jefe del subequipo de Interfaces de Ingeniería, que había estado en Teradyne por
unos 13 años al principio de Jaguar, pensaba que las herramientas habrían funcionado mejor de no
haber encontrado una fuerte resistencia: Él explicó: “Las personas se oponían a las herramientas
porque estas las obligaban a comprometerse. La gente tiene miedo de comprometerse en un mundo
incierto. Es vergonzoso estar equivocado“. Rogas también consideraba que las herramientas de
gestión de proyectos agregaban valor. Mencionó específicamente su impacto sobre el esfuerzo
AlphaTech: “Las herramientas dieron al proyecto una visibilidad que no solíamos tener. Esto nos
permitió responder a AlphaTech y estar seguros de poder alcanzar todas las metas “.
Otros expresaron un tono de más cautela. Les preocupaba que el creciente énfasis en la
planificación de proyectos, seguimiento, medición y presentación de informes pudieran distraer a los
miembros del equipo de los problemas reales. Ben Brown, gerente de ingeniería que había estado en
Teradyne durante 21 años al comienzo del Proyecto Jaguar, explicó:
Era natural que con el tiempo algunas personas se preocuparan más acerca de la medida en
sí misma y no por lo que una medida insatisfactoria les decía. Además, cualquiera puede hacer
que un indicador parezca bien. Hay que tener cuidado: la medida podría convertirse en el
objetivo, de modo que la gente se concentra en manipular la medida más que en el proyecto.
Las personas caen en esta trampa, no porque quieren hacerlo mal sino porque se sienten
presionadas a manejar la medida. La gente necesita herramientas, pero, más importante aún,
13
This document is authorized for use only in Magda Graciela Briones's PER 6034-MBA-MODULO3-5 at Universidad International De la Rioja SA from Apr 2022 to Oct 2022.
610-S17 Teradyne Corporation: El Proyecto Jaguar
necesita la actitud. No creo que las herramientas más sofisticadas sean necesariamente mejores.
Las herramientas mejoran las cosas mejor si las personas que las utilizan aceptan y entienden
para qué son y cómo funcionan.
Esto no siempre fue el caso para las metodologías que implementamos. A veces, la
herramienta se interponía en el camino. Piense por ejemplo en Primavera. Primavera es una
herramienta torpe. La interfaz es terrible. Muchos de los gerentes de ingeniería de primer nivel
la odiaban. Primavera requiere una estructura muy estática de división del trabajo, una vez
que se entra en ella es muy difícil de modificar. El problema es que, a medida que se ejecuta un
proyecto como este, se descubren cosas que hay que hacer en forma distinta. Sin embargo, el
cronograma se produce y se actualiza utilizando la estructura original de división del trabajo.
Por tanto, el cronograma reportado se vuelve menos significativo con el tiempo. Algunos
grupos tenían una lucha semanal con Primavera. Se esforzaban por alcanzar la fecha
programada de terminación mediante la constante reorganización de la ruta crítica, pero
pasaban por alto el hecho de que los productos del proyecto en general estaban fallando y que
el trabajo no se estaba haciendo al ritmo planeado. El valor devengado es otro buen ejemplo de
herramientas que no siempre funcionan bien. Hay cosas que no aparecen en esa herramienta.
Se sabe cuántas horas se han trabajado, pero no se sabe cuánto queda. Uno puede progresar en
la herramienta de valor devengado sin avanzar en el proyecto.
Brown hizo una breve pausa y luego confesó: “Yo quería desafiar constantemente a mi gente a
pensar en nuevas maneras de ejecutar el proyecto. Los dejé utilizar Microsoft Project, pero luego hice
que mi secretaria digitara sus datos en Primavera para poder informar de ese modo”. Breger también
se mostró escéptico. Le preocupaba que las herramientas estuvieran eliminando algunos de los
comportamientos positivos que eran fundamentales para el éxito:
En el pasado, un sitio como Agoura Hills era responsable de todo el sistema. Ahora, el
desarrollo se extiende por varios lugares. Esto le da a uno una sensación muy diferente. Uno
no consigue ese sentido de responsabilidad que lleva a la gente a venir los fines de semana. Por
primera vez en mis 26 años de carrera en Teradyne, no me sentí responsable por el éxito de
todo el proyecto. Me sentí responsable de reportar datos. Para esto servían las herramientas:
para proporcionar muchos datos. La gente se concentraba en rastrear datos, pero no siempre se
preocupaba por rastrear los datos correctos.
También le preocupaba que las herramientas se vieran como un sustituto fácil de la gestión
directa: “Las herramientas le dicen a uno si llega tarde, pero uno no debería necesitar una
herramienta para decirle eso. Si usted tiene que averiguarlo a través de la herramienta, ya es
demasiado tarde. Además, las herramientas no me ayudaron a manejar lo más importante: las cosas
inciertas. El valor devengado, por ejemplo, funciona muy bien si se sabe exactamente lo que se
necesita hacer. Pero el desarrollo no es así. Hay mucha incertidumbre “.
14
This document is authorized for use only in Magda Graciela Briones's PER 6034-MBA-MODULO3-5 at Universidad International De la Rioja SA from Apr 2022 to Oct 2022.
Teradyne Corporation: El Proyecto Jaguar 610-S17
15
This document is authorized for use only in Magda Graciela Briones's PER 6034-MBA-MODULO3-5 at Universidad International De la Rioja SA from Apr 2022 to Oct 2022.
610-S17 -16-
Resumen de resultados operativos (en millones de dólares, excepto ingresos por acción)
2004 2003 2002 2001 2000 1999 1998 1997 1996 1995 1994 1993
Ventas netas 1.791,9 1.352,9 1.222,2 1.440,6 3.043,9 1.790,9 1.489,2 1.266,3 1.171,6 1.191,0 777,7 633,1
Ingreso antes de imp. 188,0 (186,2) (561,0) (326,2) 739,6 273,8 145,9 193,3 139,7 249,9 114,0 57,3
Ingreso neto 165,2 (194,0) (718,5) (202,2) 517,8 191,7 102,1 127,6 93,6 159,3 76,4 48,1
Sistemas de pruebas de
semiconductores $1.146,3 735,4 557,5
Sistemas de conexión 381,7 357,2 397,0
Sistemas de prueba de montaje 155,2 151,6 170,8
Otros sistemas de pruebas 108,7 108,7 96,9
$1.791,9 1.352,9 1.222,2
This document is authorized for use only in Magda Graciela Briones's PER 6034-MBA-MODULO3-5 at Universidad International De la Rioja SA from Apr 2022 to Oct 2022.
610-S17 -17-
Objetivo Definir oportunidad de mercado, Perfeccionar concepto de producto y Desarrollo de producto hasta el punto Verificar que el producto se ajuste a las el producto y los procesos a producción,
necesidades de los clientes y viabilidad crear plan de desarrollo de unidad funcional especificaciones y prepararse para enviarlo a los ventas y apoyo de rutina
del producto clientes
Productos del Evaluación preliminar de mercado Especificación detallada de producto y Unidad funcional Primer envío al cliente, producto listo Ejecutar plan de aumento
proyecto necesidades funcionales
Evaluación técnica preliminar Plan de prueba / verificación Ejecutar plan de prueba Publicar documentación
Plan de desarrollo que incluye matriz de
Evaluación financiera preliminar estrategia de ejecución de proyecto Documentación final de diseño Definición de reporte de problemas y mecanismo Evaluar proyecto
de acción correctiva
Armonización del plan a mediano plazo Plan de negocios Documentación preliminar Análisis de armonización de llevar
Documentos de usuario final producto al mercado
Matriz preliminar de estrategia de Evaluaciones de riesgo Necesidades del cliente,
ejecución de proyecto (MEEP) especificaciones y análisis de laguna de Curso de capacitación de usuario Plan clave de gestión de cuenta
costos
Capacitación de apoyo de campo Actualización de hoja de ruta de
producto
Prueba de manufacturabilidad
Plan de mejora/actualización (si es
Materiales finales de ventas y mercadeo necesario)
Plan de aumento de producción Aumentar, sostener, mejorar necesidades
de recursos
Equipo 2–6 personas Equipo básico (4–10) Equipo completo de desarrollo Equipo completo de desarrollo Equipo de desarrollo
Ingeniería de diseño, mercadeo como Transfuncional (Ingeniería, Mercadeo, Transfuncional (Ingeniería, Mercadeo, Transfuncional (Ingeniería, Mercadeo, Transfuncional (Ingeniería, Mercadeo,
mínimo Manufactura, Ventas y Apoyo.) Manufactura, Ventas y Apoyo.) Manufactura, Ventas y Apoyo.) Manufactura, Ventas y Apoyo.)
Punto Revisión de productos de fase Revisión de productos de fase Revisión de productos de fase Revisión de productos de fase Revisión de productos de fase
Revisión del comité ejecutivo Planes de medida correctiva Confirmar capacidad de despacho por
volumen
Resultado Financiamiento y recursos para la Fase II Financiamiento para desarrollar el Listo para primera prueba de piezas Producto listo para despacharse en volumen Se fabrica el producto en el volumen
producto requerido
Listo para verificación de sistema Aprobación para primer envío al cliente (PEC)
El equipo se compromete a desarrollar Acuerdo en que se han logrado los
el producto Primer cliente capacitado y listo objetivos del proyecto
Apoyo listo Se liberan todos los recursos de
desarrollo
This document is authorized for use only in Magda Graciela Briones's PER 6034-MBA-MODULO3-5 at Universidad International De la Rioja SA from Apr 2022 to Oct 2022.
610-S17 -18-
Dimensión de
proyecto Principios Proceso Estructura
Definición de proyecto - El proyecto tendrá objetivos muy contrapuestos en las áreas de costo vs. - La actual tecnología y elementos básicos se - El equipo básico es responsable de la
cronograma vs. funcionalidad de la plataforma común. Se definirá para aprovecharán mientras exista un mínimo de definición del proyecto.
optimizar la “combinación apropiada” de estos intercambios contrapuestos. componenda contra los objetivos priorizados del - Equipo de arquitectura a tiempo completo
- Se favorecerá la amplitud de cobertura del mercado y la optimización de programa. dirigido por George Conner.
mediados del SOC por encima de la optimización para los extremos de costo o
desempeño del mercado SOC. - Las decisiones serán impulsadas por el impacto
cuantificado contra las medidas de los objetivos
- La arquitectura de lugar universal será el capacitador clave para brindar la priorizados del programa.
flexibilidad necesaria del mercado SOC.
- Objetivos jerárquicos priorizados—( objetivos
- Consideraremos las necesidades del segmento de mercado independiente de priorizados para Jaguar y para cada subproyecto)
memoria para futuros productos derivados, pero no haremos ningún
intercambios significativo contra nuestros objetivos clave de proyecto.
- El equipo de proyecto es responsable de garantizar una línea completa de
instrumentación SOC un año después del primer envío al cliente.
Gobernabilidad y - Se supone que la dotación de personal es de tiempo completo y dedicada al - Integración del equipo básico jerárquico. - Equipo de peso pesado organizado en áreas
personal del proyecto proyecto. - La planificación agregada de proyectos es la clave de subproyecto. Líderes de subproyecto
- El equipo básico es responsable por el éxito del programa. principal herramienta de gestión de dotación de organizados en un equipo básico dirigido por
personal. Jack O’Brien.
Estructura de tareas y - El proyecto usará un proceso único e integrado de desarrollo de productos. - El proceso se armonizará con el marco de - Equipo de gerentes de programa a tiempo
actividades del - Las tareas solo se asignarán a personas que están activas dentro del proyecto. revolución en el desarrollo de productos y se basará completo con un recurso a tiempo completo por
proyecto en las mejores prácticas por consenso que existan en subproyecto.
STD.
Diseño, prototipo y - Se utilizará simulación siempre que sea posible como el primer paso en la - Resumidos mensualmente como parte del resumen - Estrategia para cada área que es
prueba creación de prototipos. de riesgos. responsabilidad de los líderes de subproyecto.
- Se requerirán prototipos físicos para cualquier tecnología que no se haya
reducido a práctica en Teradyne.
Revisión y control de la - La revisión de la alta gerencia serán impulsadas por el tiempo más bien que - La alta gerencia analizará el programa en una - Revisión entre el equipo básico de Jaguar y
alta gerencia por los eventos. reunión mensual de patrocinio. Mike Bradley y su personal.
- El análisis de laguna de medidas del programa será el núcleo de las revisiones - Tablero del programa para empleo de medidas.
de la alta gerencia.
Correcciones a medio - La definición del proyecto se considera cerrada al concluir la Fase 2 a menos - Actualización trimestral de PLA competitivos y - Revisiones mensuales en persona con el
camino en tiempo real que haya un cambio importante en las necesidades, el riesgo o el panorama necesidades de segmentos de mercado. equipo básico
competitivo. - Resumen mensual de medidas clave, riesgos y VIT. - Reuniones regulares de integración con
- Los intercambios se rastrearán formalmente y se resumirán cada mes. equipos de mercado de STD.
This document is authorized for use only in Magda Graciela Briones's PER 6034-MBA-MODULO3-5 at Universidad International De la Rioja SA from Apr 2022 to Oct 2022.
Teradyne Corporation: El Proyecto Jaguar 610-S17
La estructura de división del trabajo (EDT) divide un proyecto en sus tareas individuales e
identifica las relaciones entre ellas. La estructura de división del trabajo tiene dos objetivos
principales. En primer lugar, asegurar que el proyecto tenga todo el trabajo necesario para
completarlo con éxito. En segundo lugar, asegurar que el proyecto no incluya trabajo innecesario. Al
definir el proyecto de este modo, la estructura de división del trabajo permite al gerente del proyecto
describir claramente la naturaleza jerárquica de los trabajos que se deben realizar y establece una base
para otros elementos del plan formal del proyecto, incluyendo el plan de recursos del proyecto, el
presupuesto, el plan de organización y un cronograma maestro. La estructura de división del trabajo
se desarrolla antes de identificar dependencias y de estimar la duración de las actividades. A menudo
se utiliza para identificar las tareas para el análisis de ruta crítica.
Ruta crítica
El análisis de ruta crítica (ARC) es una metodología para identificar el conjunto de “actividades
limitantes” que determinan la duración total del proyecto. Este análisis identifica las tareas que, si se
retrasan, harán que la fecha final de terminación no se cumpla. El principal beneficio del análisis de
ruta crítica es que ayuda a una empresa a determinar el período mínimo necesario para realizar un
proyecto. Cuando la empresa debe ejecutar un proyecto acelerado, le ayuda a identificar los pasos del
proyecto que se deben acelerar para terminar el proyecto dentro del tiempo disponible.
Esta es una técnica para incorporar la incertidumbre en las estimaciones de cronograma. Para cada
tarea, se estima un mejor caso, un peor caso y un tiempo de antelación esperado. Esta técnica puede
ser usada en conjunto con el análisis de ruta crítica para identificar las actividades del proyecto que
tienen más probabilidad de causar un retraso.
El valor devengado (VD) es una metodología para medir el progreso de un proyecto. Compara la
cantidad real y prevista de trabajo realizado (en distintas etapas) en términos de tiempo o costos. El
valor devengado utiliza tres indicadores: 1) Costo presupuestado del trabajo programado (CPTP), el
costo planeado de la cantidad total de trabajo previsto para ejecutarse a la fecha hito, 2) Costo real del
trabajo realizado (CRTR), el costo en que se incurre para completar el trabajo realizado a la fecha y
3) Costo presupuestado del trabajo realizado (CPTR), el costo planeado para completar el trabajo que
se ha realizado hasta la fecha. Al comparar las diferencias en estos tres parámetros, es posible
identificar dos fuentes de variación: variación de costos (VC) y variación en cuanto a programa de
trabajo (VP).
19
This document is authorized for use only in Magda Graciela Briones's PER 6034-MBA-MODULO3-5 at Universidad International De la Rioja SA from Apr 2022 to Oct 2022.
610-S17 Teradyne Corporation: El Proyecto Jaguar
5.000
vc
$ vp
TIEMPO 5 meses
Fuente: Preparado por los escritores del caso con base en información de la empresa.
20
This document is authorized for use only in Magda Graciela Briones's PER 6034-MBA-MODULO3-5 at Universidad International De la Rioja SA from Apr 2022 to Oct 2022.
Teradyne Corporation: El Proyecto Jaguar 610-S17
Tony George: Proyecto Miata (el nuevo instrumento digital que era parte de Jaguar)
Fuente: Preparado por los escritores del caso con base en información de la empresa.
21
This document is authorized for use only in Magda Graciela Briones's PER 6034-MBA-MODULO3-5 at Universidad International De la Rioja SA from Apr 2022 to Oct 2022.
610-S17 Teradyne Corporation: El Proyecto Jaguar
4T01 1T02 2T02 3T02 4T02 1T03 2T03 3T03 4T03 1T04 2T04 3T04 4T04
Hardware 112 139 184 217 221 223 226 225 223 209 197 183 157
Software 24 24 19 19 17 16 14 11 11 11 7 7 4
Verifica- 0 0 26 30 30 29 25 25 23 21 11 5 2
ción de
sistema
Administ. 4 4 5 5 5 5 5 5 5 5 5 5 5
Total 140 167 234 271 273 273 270 266 262 246 220 200 168
300
250
200
Empleados
Admin.
Verific. de sist.
150
Software
Hardware
100
50
0
3T03
2T04
1T02
4T02
2T03
4T03
1T04
3T04
4T04
2T02
3T02
1T03
4T01
Trimestre
22
This document is authorized for use only in Magda Graciela Briones's PER 6034-MBA-MODULO3-5 at Universidad International De la Rioja SA from Apr 2022 to Oct 2022.
610-S17 -23-
Anexo 7 Cronograma de principales fases del proceso de desarrollo para el Proyecto Jaguar
Primer envío
Fase II: Se concluyen al cliente
las revisiones de originalmente
subproyecto planeado
Mayo 01 Mayo 02 Sep. 02 Sep. 03 Nov. 03 Mar. 04 Abril 04 Junio 04 Ag. 04 Dic. 04 En. 05 Abril 05 Junio 05
Revisión de Fase IV
originalmente planeada
Fuente: Preparado por los escritores del caso con base en información de la empresa.
This document is authorized for use only in Magda Graciela Briones's PER 6034-MBA-MODULO3-5 at Universidad International De la Rioja SA from Apr 2022 to Oct 2022.
-24-
610-S17
Información de la empresa.
Prueba Ultra Flex
Anexo 8
Fuente:
This document is authorized for use only in Magda Graciela Briones's PER 6034-MBA-MODULO3-5 at Universidad International De la Rioja SA from Apr 2022 to Oct 2022.
610-S17 -25-
30000
PLATAFORMA SW – VALOR DEVENGADO – Estimación a Terminación-CPI
CUM Planeado
(CPTP)
25000
Valor Deveng.
CUM (CPTR)
20000 CUM Real
(CRTR)
15000 Última
Estim. Realiz.
HORAS DE TRABAJO
(UER)
10000 Real -
Pronóstico -
EAC
5000 Pronóst. VD
0
3 3 3 3 03 3 4 4
.-0 -0 -0 l-0 p- v -0 -0 -0
ar ay J u e ar
En M M S No En M
FECHA
This document is authorized for use only in Magda Graciela Briones's PER 6034-MBA-MODULO3-5 at Universidad International De la Rioja SA from Apr 2022 to Oct 2022.