Teradyne Corporation - El Proyecto Jaguar

Teradyne Corporation: El Proyecto Jaguar 610-S17
FRANCESCA GINO
GARY PISANO
Teradyne Corporation: El Proyecto Jaguar
Jack O’Brien miró el reloj de su carro. Eran las 7:38 de la mañana y él sabía que iba a necesitar
suerte para llegar a tiempo a su reunión de las 8:00 a.m. en las oficinas centrales de Teradyne en Harrison
Avenue. El tráfico en la arteria central de Boston estaba paralizado en medio de la persistente construcción
de la interminable “Big Dig”. O’Brien esperaba ansiosamente la reunión de hoy con los altos ejecutivos de
Teradyne para reflexionar sobre las lecciones aprendidas en el Proyecto Jaguar, que él había dirigido por
más de tres años. El proyecto había sido uno de los esfuerzos más importantes en los 45 años de historia de
Teradyne y había buscado crear una plataforma totalmente nueva de sistema de prueba de
semiconductores. El sistema Ultra Flex resultante, diseñado para ser lo suficientemente flexible para
permitir a los clientes probar toda una gama de dispositivos semiconductores, era crítico para el éxito de la
nueva estrategia competitiva de Teradyne.
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ó:
Usamos estas herramientas para imponer disciplina en el proceso de desarrollo. Con la

información y los datos proporcionados por las nuevas herramientas que estábamos utilizando,
podíamos saber si un equipo estaba perdiendo el tiempo o haciendo el trabajo realizado al ritmo
adecuado. Por supuesto, se necesitan más que herramientas: hay que tener los líderes correctos en los
puestos apropiados, hay que dar poder a esos líderes y ellos deben aceptar la responsabilidad y la
rendición de cuentas por su parte del proyecto.
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.
P á g i n a 1 | 25
This document is authorized for use only in Professor Carla Fernandez's Transformacion Digital -
MBA Profesional 2018 course at INCAE Business School, from December 2017 to June 2018.
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.
El 98% del tiempo de las reuniones se pasaba tratando de averiguar si la herramienta reflejaba
la realidad, en vez de discutir qué hacer. Con las herramientas de programación, hay que especificar la
secuencia y la estructura de las tareas con antelación. Pero esto es un arte. Conforme las herramientas
se complican más, se gasta más tiempo lidiando con ellas, en vez de hacer las preguntas correctas.
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.
Teradyne y el negocio de probadores de semiconductores

Teradyne era el mayor proveedor mundial de equipo para probar semiconductores, con ventas de
US$ 1.800 millones (en 2004) y más de 6000 empleados que trabajaban en todo el mundo (véase en el
anexo 1 el estado financiero de Teradyne). Fundada en 1960 por Alex D’Arbeloff y Nick DeWolf, dos
compañeros de clase del Massachusetts Institute of Technology (MIT), Teradyne inicialmente se concentró
en fabricar equipo para probar transistores y otros componentes electrónicos. Su negocio involucraba un
nuevo tipo de equipo de prueba electrónica de “grado industrial”, conocido por su confiabilidad, velocidad
de prueba y desempeño técnico. Durante los próximos 30 años, al aumentar exponencialmente la
complejidad y los volúmenes de producción de semiconductores, Teradyne continuó haciendo fuertes
inversiones en investigación y desarrollo para mantenerse a la vanguardia de la tecnología de prueba.
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.
Tecnología de prueba de semiconductores
Los semiconductores abarcaban una amplia gama de tipos de dispositivos, que se dividían en dos
categorías: (1) recuerdos y (2) sistema en un chip (conocidos en inglés como SOC). Los SOC incluían
microprocesadores (lógicos), procesadores analógicos, procesos digitales de señal mixta (que combinaban
circuitos analógicos y digitales), dispositivos especializados para gráficos y sonido y circuitos integrados
personalizados. Cada tipo de dispositivo realizaba una tarea diferente en un sistema electrónico.
Independientemente de su propósito, los semiconductores eran dispositivos de alta precisión que
realizaban complejas manipulaciones de señales electrónicas. La capacidad de un
P á g i n a 2 | 25
dispositivo para realizar su función dependía de su diseño y también de su manufactura. Incluso el defecto
de menor importancia en el proceso de producción (por ejemplo, una mota de polvo o una diminuta
desviación en la especificación) podría impedir que un dispositivo funcionara correctamente. La tarea de los
probadores de semiconductores era determinar si un chip se ajustaba o no a sus especificaciones objetivo.
Para esto, el probador esencialmente interrogaba al dispositivo electrónico (enviando señales y luego
midiendo la respuesta). Esta tarea, aparentemente simple, era en realidad uno de los problemas más
difíciles de toda la industria de productos electrónicos. Para funcionar según lo especificado, un
semiconductor debía ser capaz de ejecutar una amplia gama de operaciones en muchas condiciones, en
coordinación con otros componentes de un sistema electrónico. El sistema de prueba de semiconductores
debía determinar si el chip era capaz de realizar estas operaciones en forma aislada. Por tanto, el sistema
de pruebas tenía que simular los ambientes de los sistemas electrónicos en los que el dispositivo podría ser
utilizado. Al volverse más complejos y precisos los dispositivos, este desafío aumentó exponencialmente.
Los precios de los sistemas de Teradyne podían alcanzar los US $ 3 millones o más.
Industria de probadores de semiconductores
En 2004, Teradyne tenía cerca del 35% del mercado mundial de probadores de semiconductores de
sistema en un chip (SOC). Los otros grandes líderes del mercado en esta industria eran Agilent (con una
participación del 10%), Advantest y Credence. El mercado de probadores de semiconductores, al igual que
la industria misma de semiconductores, era sumamente cíclica. Los clientes —fabricantes de
semiconductores tales como Intel, Texas Instruments, IBM, Hitachi y Samsung y los fabricantes por contrato
tales como TSMC—generalmente hacían sus pedidos más grandes de equipos para prueba de
semiconductores cuando hacían la transición a una nueva generación de tecnología cuyos requisitos de
prueba no podían satisfacerse con el equipo existente. Dada la tasa históricamente rápida de innovación
tecnológica en semiconductores, esto hacía imperativo que las empresas de equipos de prueba invirtieran
fuertemente en investigación y desarrollo y aprovecharan las “ventanas de mercado”. Por lo general, los
clientes preferían quedarse con los sistemas existentes para aprovechar la experiencia, el conocimiento y la
capacitación del pasado. De este modo, una vez que una empresa de probadores “se ganaba una cuenta”,
era difícil que otra empresa la desalojara a menos que su servicio o desempeño fuera especialmente
deficiente. Al elegir entre proveedores, los proveedores de semiconductores buscaban desempeño técnico
y características: ¿podía el equipo probar su dispositivo? También se concentraban en gran medida en la
economía de la prueba, que estaba impulsada en gran parte por la velocidad de prueba. Este último
requisito era especialmente importante dado que la prueba era a menudo un cuello de botella en el
proceso total de producción de semiconductores y que los márgenes de muchos segmentos del negocio de
semiconductores eran relativamente bajos. La confiabilidad era también una demanda cada vez más
importante de los clientes, porque el tiempo muerto del equipo era extremadamente costoso para un
fabricante de semiconductores. La capacidad de un proveedor para mantener el equipo y proporcionar
rápido apoyo técnico se consideraba esencial para competir en este mercado.
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
P á g i n a 3 | 25
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.
Un hito importante en la evolución de la empresa se produjo a principios de los 90, cuando el

entonces jefe ejecutivo Alex D’Arbeloff decidió transformar la forma en que la empresa operaba a través de
la puesta en marcha de un programa de “gestión para la calidad total”. En ese momento, D’Arbeloff se
sentía cada vez más preocupado de que, a pesar de su sobresaliente talento, Teradyne corría el riesgo de
perder su ventaja competitiva porque sus productos a menudo llegaban tarde al mercado y sufrían de
problemas de calidad y confiabilidad. Al mirar a su alrededor, D’Arbeloff se dio cuenta de que muchos de
los procesos básicos de funcionamiento de la empresa no estaban bajo control. Su desempeño no se había
medido, y no había ningún esfuerzo sistemático para mejorar esos procesos. Para corregir esta deficiencia,
D’Arbeloff adoptó la gestión para la calidad total, un conjunto de principios, filosofías y prácticas que
enfatizaban el control y la mejora continua de los procesos de una organización. A continuación se produjo
un período intensivo de capacitación en los principios de gestión y herramientas para la calidad total para
todos los empleados, empezando con los altos ejecutivos. D’Arbeloff insistió en que todos, empezando por
él mismo, siguieran las metodologías, principios y prácticas de la gestión para la calidad total al hacer su
trabajo. Él esperaba que sus subalternos directos, por ejemplo, utilizaran herramientas de gestión para la
calidad total tales como procesos de siete pasos para la resolución de problemas, análisis de causa
fundamental y diagramas de espina de pescado en la comunicación y discusión de los problemas
gerenciales. Para mediados de los 90, tras cinco años de esfuerzo intensivo, Teradyne había incorporado la
gestión para la calidad total en la mayoría de los aspectos del trabajo en la empresa. Y, lo más importante,
los resultados en la mayor parte de los aspectos de las operaciones de la empresa—tales como la calidad
de fabricación y el servicio al cliente— mejoraron drásticamente.
Desarrollo de productos en Teradyne

Cuando inició la gestión para la calidad total, D’Arbeloff esperaba que transformara también la
organización de ingeniería. Lamentablemente, para 1996, estaba claro que la gestión para la calidad total
no se estaba afianzando en ingeniería, ya que los proyectos seguían llegando tarde y sus costos excedían lo
presupuestado, a veces por un factor de dos. Los ingenieros resistían los enfoques estructurados para la
resolución de problemas y veían la gestión para la calidad total como una violación de su libertad. En 1996,
D’Arbeloff lanzó una iniciativa separada, concentrada en el desarrollo de productos. La iniciativa,
denominada “revolución en el desarrollo de productos” (RDP), fue puesta bajo la dirección de Ed Rogas,
vicepresidente de alto rango y veterano de 25 años de Teradyne. Los altos líderes de ingeniería de la
empresa provenientes de diferentes divisiones se reunieron en un Equipo de Mejora de Proceso de
Ingeniería (EMPI). A Ed Rogas y al equipo, que se reunía cada mes, se les encargó desarrollar e implementar
un nuevo enfoque para el desarrollo de productos en todo 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
P á g i n a 4 | 25
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.
El segundo problema en Teradyne se relacionaba con la ejecución de proyectos individuales. Los

proyectos estaban mal planeados. Las metas y el alcance a menudo no se definían claramente al principio y,
como resultado, los proyectos tendían a expandirse conforme los ingenieros y comercializadores pensaban
en características adicionales. Los hitos no estaban bien definidos y a menudo no se alcanzaban. Los
cronogramas del proyecto se hacían con poco rigor. Debido a que no había un método sistemático para
rastrear el progreso del proyecto, era difícil que la alta gerencia supiera cuándo intervenir a menos que
menos que se presentaran grandes problemas. Por último, debido a que los proyectos eran manejados por
funciones individuales de ingeniería y no había nadie responsable por todo el proyecto, se producían
significativas demoras y problemas de calidad causados por faltas de coordinación y comunicación. Para
abordar este segundo problema, la empresa lanzó varias iniciativas de mejora. Una de ellas fue la creación
de un modelo “de revisión por fases” para proyectos de desarrollo. (Véanse en el anexo 2 más detalles de
este modelo de Teradyne y en el anexo 3 la matriz de estrategia de ejecución de proyecto1 desarrollada
para el Proyecto Jaguar.) El objetivo del modelo de revisión por fases era proporcionar hitos y puntos de
revisión bien definidos. La segunda iniciativa fue la implementación de herramientas de gestión de
proyectos diseñados para ayudar a los equipos a planear proyectos, gestionar los cronogramas y rastrear el
progreso en comparación con las metas. (Véase en el anexo 4 una descripción de las herramientas de
gestión de proyectos.) Finalmente, en consonancia con la filosofía de mejora continua de Teradyne, se
recomendó una revisión estructurada “a posteriori” tras finalizar todos los proyectos de desarrollo. Esas
revisiones reunirían a miembros del equipo del proyecto y a altos gerentes seleccionados para estudiar las
lecciones aprendidas.
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“.
Nueva estrategia y nueva estructura
Históricamente, Teradyne y otros proveedores de equipos de prueba diseñaban sistemas de

pruebas completamente diferentes para cada tipo de dispositivo semiconductor (de memoria,
digital/lógico, analógico, de señal mixta, etc.) La ventaja de este método era que permitía que el diseño del
probador se optimizara según los requisitos de prueba del dispositivo particular.
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
P á g i n a 5 | 25
Teradyne ajustaba su estructura organizativa a cada mercado y diferentes unidades de negocios se

concentraban en segmentos del mercado de dispositivos: memoria (MTD), lógica (VTD), señal mixta (ICD),
microcontroladores (ITD) y sistema en un chip (SOC).
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“.
P á g i n a 6 | 25
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 producto 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.
P á g i n a 7 | 25
Estructura del equipo del proyecto
El Proyecto Jaguar estaba organizado en un conjunto de equipos de proyecto, cada uno de los
cuales se concentraba en un subsistema o tarea particular. (Véase en el anexo 5 para un organigrama del
proyecto.) El tamaño mismo del Proyecto Jaguar exigió tomar recursos y talento de ingeniería de múltiples
lugares tales como Boston, Agoura Hills, San José (California), Minneapolis y Portland. A fin de garantizar los
niveles adecuados de integración entre los diferentes sitios y subequipos, se formó un “equipo básico” de
líderes de cada uno de los equipos de subsistema. El equipo básico incluyó también un gerente de
programas, Kevin Giebel, y fue dirigido por Jack O‘Brien. Este equipo se reunía por semana mediante
teleconferencia y mensualmente en persona para discutir el progreso realizado por cada equipo y para
tomar decisiones críticas, tanto técnicas como de organización. Los altos gerentes, incluyendo a Mike
Bradley, Mark Jagiela y Ed Rogas, revisaban de manera rutinaria el progreso de los equipos.
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”.
Herramientas y procesos de gestión del proyecto
Uno de los elementos críticos de la estrategia de ejecución del Proyecto Jaguar fue el uso de
herramientas formales de gestión de proyectos, incluyendo:
 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).
P á g i n a 8 | 25
 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 creía firmemente en el valor de estas herramientas, en particular para un proyecto

complejo como el Jaguar: “Usamos una combinación de herramientas, tales como análisis de ruta crítica,
estructuras de división del trabajo, estimación de tres puntos, análisis de valor devengado y un programa
de programación de proyectos llamado Primavera. La mezcla nos ayudó a ver las diferentes cosas que
estaban ocurriendo. Una misma talla no sirve para todos. ‘
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ó:
En el hardware, los atributos físicos de una pieza a menudo determinan la secuencia y la

estructura apropiada de las tareas. Por ejemplo, no se puede probar una parte hasta que se haya
diseñado y construido. En el software, uno no tiene estas limitaciones físicas. Por lo general, se
pueden hacer las tareas en casi cualquier orden. Esto da mucha más flexibilidad (al ejecutar) para
trasladar las personas a diferentes tareas e incluso para cambiar el orden de las tareas.
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 de ruta crítica y mantenía mucha tensión en los
primeros hitos.
P á g i n a 9 | 25
Desempeño del proyecto
Un importante principio establecido por O’Brien y el equipo básico fue mantener fija la fecha de
primer envío a los clientes para el 30 de junio, independientemente de los retrasos de las tareas
individuales. O’Brien reflexionó: “Incluso cuando nos retrasamos sistemáticamente con respecto a lo que
esperábamos, nunca cambiamos el punto final. Queríamos mantener cierta tensión en el proceso”. En la
práctica, esto significó que el equipo tuvo que ser flexible en responder a demoras, particularmente las de
ítems de ruta crítica. En las reuniones mensuales del equipo básico, se decidía reasignar recursos a las
partes del proyecto que habían sufrido retrasos. La alta gerencia también puso recursos adicionales a
disposición del equipo. (Véanse en el anexo 6 las necesidades de personal del Proyecto Jaguar.) Tal como lo
comentó Breger: “El proyecto se dotó de personal de una manera magnífica… La dirección no reparó en
gastos para asegurarse de que el proyecto no se retrasara”.
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.
P á g i n a 10 | 25
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ó:
Debíamos convencer a AlphaTech de que debían esperarnos y superar su escepticismo.

Ellos sabían por experiencia que cuando fijábamos una fecha por lo general no la alcanzábamos.
Esta vez, la única oportunidad que teníamos era dar en el blanco con exactitud. Llamamos a todos
los que conocíamos en AlphaTech —las personas con quienes habíamos trabajado durante años—y
les pedimos que nos dieran una oportunidad.
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
P á g i n a 11 | 25
intelectualmente honrados respecto a la magnitud de los riesgos y las lecciones de la historia de IG-
XL en FLEX.
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 intenso esfuerzo valió la pena. En septiembre de 2004, AlphaTech seleccionó el sistema de

Teradyne. La victoria, sin embargo, tuvo su costo. Gran parte del resto del proyecto —incluyendo el
desarrollo de características para otros clientes—se retrasó. Además, el departamento de software,
totalmente ocupado en la corrección de errores, se retrasó aún más. De nuevo se agregaron más ingenieros
de software al proyecto. En julio de 2004, Carbone fue nombrado para dirigir el desarrollo restante de
software. “La situación era un desastre. La gente estaba agotada. Tuvimos que añadir 50 desarrolladores
más. Simplemente usamos fuerza bruta. No era bonito. Todavía estamos trabajando arduamente“.
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”.
P á g i n a 12 | 25
Reflexiones sobre el proyecto
En Teradyne, el resultado de un proyecto de desarrollo se juzgaba por dos criterios: primero,

¿alcanzó el proyecto sus objetivos? y, segundo, ¿creó nuevas capacidades de la organización para proyectos
futuros? Aunque la mayoría de las personas se sentían satisfechas con el primero, hubo cierto desacuerdo
sobre el segundo asunto, en particular en lo referente a herramientas y prácticas de gestión de proyectos.
Algunos gerentes consideraban que, en general, las herramientas de gestión de proyectos funcionaban y
habían contribuido al éxito del proyecto. Sus preocupaciones giraban en torno a la implementación. Otros
estaban mucho menos convencidos del valor de las herramientas y les preocupaba que pudieran ser una
distracción.
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,
2
La herramienta de Valor Devengado (véase el anexo 4).
P á g i n a 13 | 25
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 “.
A Conner también le preocupaba la posibilidad de sobrecarga de información. Relató sus

observaciones de las reuniones del equipo básico: “La gente se concentraba tanto en los detalles que no
podía ver la imagen completa. En general, las herramientas no le ayudan a uno a concentrarse en las
decisiones que debe tomar, solo le proporcionan datos y detalles sobre el progreso de las tareas. Y la
cantidad de datos que proporcionan puede ser abrumadora. Déme un cronograma de 40 páginas y estoy
perdido “.
P á g i n a 14 | 25
Mirar hacia el futuro
Al salir finalmente de su carro, O’Brien estaba pensando en lo que aún había que mejorar para los
futuros proyectos. Sus pensamientos seguían regresando a las herramientas de gestión de proyectos y a la
forma de mejorar su uso. No podía dejar de preguntarse si las palabras de Wrinn eran correctas: “Con los
mejores procesos posibles, pero con gente incapaz, no pasa nada. Sin embargo, lo opuesto no es cierto.
Con personas capaces y procesos malos se puede hacer mucho”.
P á g i n a 15 | 25
Anexo 1 - Estados financieros de Teradyne
Resumen de resultados operativos (en millones de dólares, excepto ingresos por acción)
P á g i n a 16 | 25
Anexo 2 - Modelo de revisión por fases. Fuente: Información de la empresa.
P á g i n a 17 | 25
Anexo 3 - Matriz de estrategia de ejecución de proyecto (MEEP)
P á g i n a 18 | 25
Anexo 4 - Herramientas de gestión de proyecto
Estructura de división del trabajo
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.
Estimación de tres puntos
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.
Análisis de valor devengado
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).
P á g i n a 19 | 25
El proyecto se ha retrasado si la variación en cuanto al cronograma (VC) —calculada como la

diferencia entre CPTR y CPTP—es un número negativo. El proyecto excede el costo si la variación en cuanto
a costos (VC) —calculada como la diferencia entre CPTR y CRTR— es un número negativo.
Fuente: Preparado por los escritores del caso con base en información de la empresa.
P á g i n a 20 | 25
Anexo 5 - Organigrama del proyecto
Jack O’Brien: Líder del proyecto
Kevin Giebel: Gerente de programa
Paul Roush: Software
George Conner: Arquitectura del sistema
Joe Carbone: Analog Instrumentation Porting
Peter Breger: Sistema Básico
Simon Longson: Interfaz DUT
Ben Brown: Calibración y Exactitud, Digital Tempe ASIC, Ferrari ASIC
Ray Mirkhani: Mecánica
Tony George: Proyecto Miata (el nuevo instrumento digital que era parte de Jaguar)
Brian Davie: Gerente Funcional Global de ASIC
Fuente: Preparado por los escritores del caso con base en información de la empresa.
P á g i n a 21 | 25
P á g i n a 22 | 25
P á g i n a 23 | 25
Anexo 8 - Prueba Ultra Flex
P á g i n a 24 | 25
Anexo 9 - Ejemplo de datos proporcionados por el análisis de valor devengado
P á g i n a 25 | 25

Teradyne Corporation - El Proyecto Jaguar

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Teradyne Corporation - El Proyecto Jaguar

Cargado por

Copyright:

Formatos disponibles

Teradyne Corporation: El Proyecto Jaguar 610-S17

Teradyne Corporation: El Proyecto Jaguar

Usamos estas herramientas para imponer disciplina en el proceso de desarrollo. Con la

Teradyne y el negocio de probadores de semiconductores

Tecnología de prueba de semiconductores

Industria de probadores de semiconductores

Un hito importante en la evolución de la empresa se produjo a principios de los 90, cuando el

Desarrollo de productos en Teradyne

El segundo problema en Teradyne se relacionaba con la ejecución de proyectos individuales. Los

Nueva estrategia y nueva estructura

Históricamente, Teradyne y otros proveedores de equipos de prueba diseñaban sistemas de

Teradyne ajustaba su estructura organizativa a cada mercado y diferentes unidades de negocios se

O’Brien, un veterano de 25 años en la organización de ingeniería de Teradyne, fue nombrado líder

Estructura del equipo del proyecto

Herramientas y procesos de gestión del proyecto

O’Brien creía firmemente en el valor de estas herramientas, en particular para un proyecto

En el hardware, los atributos físicos de una pieza a menudo determinan la secuencia y la

Desempeño del proyecto

Debíamos convencer a AlphaTech de que debían esperarnos y superar su escepticismo.

El intenso esfuerzo valió la pena. En septiembre de 2004, AlphaTech seleccionó el sistema de

Reflexiones sobre el proyecto

En Teradyne, el resultado de un proyecto de desarrollo se juzgaba por dos criterios: primero,

A Conner también le preocupaba la posibilidad de sobrecarga de información. Relató sus

Mirar hacia el futuro

Anexo 1 - Estados financieros de Teradyne

Anexo 2 - Modelo de revisión por fases. Fuente: Información de la empresa.

Anexo 3 - Matriz de estrategia de ejecución de proyecto (MEEP)

Anexo 4 - Herramientas de gestión de proyecto

Estructura de división del trabajo

Estimación de tres puntos

Análisis de valor devengado

El proyecto se ha retrasado si la variación en cuanto al cronograma (VC) —calculada como la

Anexo 5 - Organigrama del proyecto

Jack O’Brien: Líder del proyecto

Kevin Giebel: Gerente de programa

Paul Roush: Software

George Conner: Arquitectura del sistema

Joe Carbone: Analog Instrumentation Porting

Peter Breger: Sistema Básico

Simon Longson: Interfaz DUT

Ben Brown: Calibración y Exactitud, Digital Tempe ASIC, Ferrari ASIC

Ray Mirkhani: Mecánica

Brian Davie: Gerente Funcional Global de ASIC

Anexo 8 - Prueba Ultra Flex

Anexo 9 - Ejemplo de datos proporcionados por el análisis de valor devengado

También podría gustarte