610S17 PDF Spa

610 - S 1 7
MAY 3,2006
FRAN CES CA 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.
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 Luis Enrique Campos's Evaluacion y gestion de proyectos course at Universidad del Pacifico, from October 2017 to March 2018.
610-S17 Teradyne Corporation: El Proyecto Jaguar
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
Teradyne Corporation: El Proyecto Jaguar 610-S17
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
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
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.
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 “.
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.
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).
 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
del ruta crítica y mantenía mucha tensión en los primeros hitos.
Desempeño del proyecto(ANALIZAR)

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.
10
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
11
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”.
12
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 VD 2, 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,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.
2 La herramienta de Valor Devengado (véase el anexo 4).
13
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 “.
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”.
15
610-S17 -16-
Anexo 1 Estados financieros de Teradyne
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
Ingreso neto (en millones)
2004 2003 2002
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
Fuente: Sitio web de Teradyne, www.teradyne.com.

610-S17 -17-
Anexo 2 Modelo de revisión por fases. Fuente: Información de la empresa.
Fase I: Fase II: Fase III: Fase IV: Fase V:

Desarrollo de concepto Planificación de proyecto y producto Diseño y desarrollo detallados Prueba, verificación y validación de producto Lanzamiento y aumento del producto
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.)
Nombrar líder de proyecto
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
Resolver problemas clave abiertos
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
Fuente: Información de la empresa.

610-S17 -18-
Anexo 3 Matriz de estrategia de ejecución de proyecto (MEEP)
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.

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).
19
5.000
CRTE (Real) CPTP (Planeado)
vc
$ vp
CPTE (Valor devengado)
TIEMPO 5 meses
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.
20
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
21
Anexo 6 Necesidades de dotación de personal de Jaguar (planeadas)
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
Necesidades de personal de Jaguar

(4T01-- 4T04)
300
250
s 200
200
Empleados
o
d Admin.
e
a Verific. de sist.
l Verific. de sist.
p 150
m 150 Software
Software
E
Hardware
100
50
0
1 2 2 2 2 3 3 3 3 4 4 4 4
3T03
2T04
1T02
4T02
2T03
4T03
1T04
3T04
4T04
2T02
3T02
1T03
4T01
0 0 0 0 0 0 0 0 0 0 0 0 0
T T T T T T T T T T T T T
4 1 2 3 4 1 2 3 4 1 2 3 4
Trimestre
22
610-S17 -23-
Anexo 7 Cronograma de principales fases del proceso de desarrollo para el Proyecto Jaguar
Se recibe la Se reconoce retraso en el

noticia de que Envío a software por segunda
Se inicia el Fase II AlphaTech revisó AlphaTech vez; se posterga la Primera revisión Tercera revisión
Proyecto Revisión del un sistema de la (versión 1), fin de revisión de la Fase IV a modificada de Fase modificada de
Jaguar proyecto competencia Fase III abril de 2005 IV Fase IV
Primer envío
Fase II: Se concluyen al cliente
las revisiones de originalment
subproyecto e 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
Decisión de Teradyne Se reconoce retraso en el Segunda revisión

de proceder con software por primera vez; modificada de
AlphaTech se posterga la revisión de Se reconoce retraso en el Fase IV
la Fase IV a enero de 2005 software por tercera vez;
se posterga la revisión de
la Fase IV a junio de 2005
-24-
610-S17
Información de la empresa.
Prueba Ultra Flex
Anexo 8
Fuente:
610-S17 -25-
Anexo 9 Ejemplo de datos proporcionados por el análisis de valor devengado
PLATAFORMA SW – VALOR DEVENGADO – Estimación a Terminación-CPI

30000
30000
CUM Planeado
(CPTP)
25000
25000 Valor Deveng.
HORAS DE TRABAJO
JO CUM
A CUM (CPTR)
(CPTR)
B
A
R 20000
20000 CUM
CUM Real
Real
T
E (CRTR)
(CRTR)
D
S 15000
15000
A Última
Última
OR Estim. Realiz.
H (UER)
(UER)
10000
10000 Real -
Pronóstico -
EAC
5000
5000 Pronóst. VD
0
03 0
-3 0
y- 3 0
-3 -03 0
-3 - 04 - 04
- ul Sep En
En. ar a J ov ar
M M N M
FECHA

610S17 PDF Spa

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

610S17 PDF Spa

Transféré par

Droits d'auteur :

Formats disponibles

610 - S 1 7

FRAN CES CA GINO

Teradyne Corporation: El Proyecto Jaguar

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

El 98% del tiempo de las reuniones se pasaba tratando de averiguar si la herramienta

Teradyne y el negocio de probadores de semiconductores

Tecnología de prueba de semiconductores

dispositivo para realizar su función dependía de su diseño y también de su manufactura. Incluso el

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

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

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(ANALIZAR)

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

intelectualmente honrados respecto a la magnitud de los riesgos y las lecciones de la historia

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

Reflexiones sobre el proyecto

2 La herramienta de Valor Devengado (véase el anexo 4).

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

Ingreso neto (en millones)

2004 2003 2002

Fuente: Sitio web de Teradyne, www.teradyne.com.

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

Fase I: Fase II: Fase III: Fase IV: Fase V:

Nombrar líder de proyecto

Resolver problemas clave abiertos

Fuente: Información de la empresa.

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

Fuente: Información de la empresa.

Anexo 4 Herramientas de gestión de proyecto

Estructura de división del trabajo

Estimación de tres puntos

Análisis de valor devengado

CRTE (Real) CPTP (Planeado)

CPTE (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 6 Necesidades de dotación de personal de Jaguar (planeadas)

Necesidades de personal de Jaguar

Fuente: Información de la empresa.

Se recibe la Se reconoce retraso en el

Decisión de Teradyne Se reconoce retraso en el Segunda revisión

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

PLATAFORMA SW – VALOR DEVENGADO – Estimación a Terminación-CPI

Fuente: Información de la empresa.