610S17-PDF-SPA

610 - S 1 7 MAY 3,2006 FRANCESCA GINO GARY PISANO

Teradyne Corporation: El Proyecto Jaguar Jack O’Brien 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,

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 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). 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— 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


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

610-S17


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


610-S17

recursos suficientes y adecuados. Aunque aparentemente era una herramienta simple para usar, la Planificación Agregada de Proyectos requería mucho cambio de conducta y disciplina. 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

610-S17


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


610-S17

Desde el principio, se reconoció que el proyecto tenía que ejecutarse a la perfección. Como lo señaló Mike Bradley, entonces presidente de la División de Prueba de Semiconductores: Fue una escogencia estratégica simple pero monumental. Teníamos una sólida base instalada de clientes comprometidos con nuestras plataformas existentes. Pasar a una sola plataforma de control significaba perturbar esta base instalada. Esto era riesgoso, por decir lo mínimo. Y significaba que la escogencia del momento era absolutamente crítica. Si nos hubiéramos quedado con nuestras arquitecturas existentes, podríamos haber argumentado ante nuestros clientes que valdría la pena esperar nuestros nuevos productos. Pero una vez que nos comprometimos con una estrategia de control y una nueva arquitectura de plataforma única, ya no podíamos argumentar eso. Esto significaba que teníamos que llevar el nuevo probador al mercado tan rápido como fuera posible o dejaríamos a muchos de nuestros clientes expuestos a la competencia. Se decidió que por ahí de junio de 2004 sería una fecha objetivo crítica para empezar a despachar el probador. En vista de lo mucho que estaba en juego en el éxito del proyecto, la división y los altos líderes corporativos se interesaron activamente y desde el principio en el proyecto. Un área de atención temprana fue el establecimiento de un ámbito claro para el proyecto. Bradley explicó: Las decisiones más críticas en la fijación del tamaño del productos no tienen que ver con lo que se hace, sino con lo que no se hace. En el pasado tendíamos a “apostarlo todo” al dimensionamiento inicial, y luego quitábamos características al sistema, cuando no podíamos cumplir con el cronograma de trabajo. Con el Jaguar, tuvimos que hacer lo contrario para cerciorarnos de aprovechar la ventana de mercado. Este fue un cambio incómodo, pero que tuvimos que hacer. En la práctica, esto significó pasar más tiempo de lo usual en las primeras etapas del proceso de desarrollo (desarrollo conceptual y planificación de productos). Bradley y otros altos gerentes presionaron a O’Brien y a su equipo para que identificaran claramente las necesidades del cliente y se comprometieran con especificaciones clave de productos. Además, la alta gerencia también impulsó

610-S17


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




610-S17

Análisis de valor devengado, un método para medir el progreso del proyecto mediante la

comparación de los recursos (o el tiempo) reales y esperados que se han invertido. O’Brien 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

610-S17


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


610-S17

Repetían constantemente que iban a ponerse al día“. Cuando se preguntó por qué la gerencia del equipo básico o la alta gerencia no intervenían, Giebel dijo: ”Una de las razones era que el equipo de gerencia no prestó suficiente atención a los datos debido a su escepticismo en torno a la medida“. Conner agregó: ”El problema del software surgió gradualmente. No lo vimos sino hasta muy tarde, pero todos sabíamos que el asunto estaba mal“. La capacidad del equipo para adaptarse fue puesta severamente a prueba en septiembre de 2003, cuando Teradyne recibió la noticia de que una de las mayores empresas de semiconductores del mundo, llamada AlphaTech, un enorme cliente potencial, estaba a punto de comprometerse con un sistema de la competencia. La alta gerencia vio esto como un fuerte golpe potencial a todo el programa. El tamaño de AlphaTech, y su estatura en el mercado, significaban que su escogencia tendría una poderosa influencia en el resto de la industria. Bradley comentó: “La idea de poner un nuevo producto o un cliente estratégico en riesgo no era algo que fuéramos a tomar a la ligera. Nuestro equipo de desarrollo tenía que apoyar plenamente el esfuerzo para tener el Jaguar listo a tiempo para este importante cliente, y así lo hizo”. El desafío era que Teradyne no esperaba tener un sistema listo para su evaluación hasta junio de 2004, a casi 10 meses de distancia. Mientras tanto, el sistema de la competencia ya estaba terminado y en los laboratorios de evaluación de AlphaTech. Rogas, que había trabajado estrechamente con AlphaTech por más de 20 años, comentó: 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

610-S17


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 elsoftware”. 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


610-S17

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

610-S17


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

T h is d

610-S17 o c u m e n a

is

t

Anexo 1 th

u

Estados financieros de Teradyne

o d

e

z

ri

Resumen de resultados operativos (en millones de dólares, excepto ingresos p or acción) r

fo u s e o n u

L

in

ly

Ventas netas

a

C

e

u

q

ri

n

E

is

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

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

(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

s 's E v a lu a

Ingreso neto (en millones) y g e s ti o

2004 n d p

e

Sistemas de pruebas de semiconductores Sistemas de conexión Sistemas de prueba de montaje Otros sistemas de pruebas n

U

t

a

e

rs

u

o

c

s

to

c

e

y

ro

$1.146,3 381,7 155,2 108,7 $1.791,9

iv e id

rs

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

.

8

1

0

2

h

rc

a

M

to

7

1

0

2

r

e

b

to

c

O

m

o

fr

,

o

ic

if

c

a

P

l

e

d

d

a

633,1

(186,2)

o

n

777,7

188,0

p

io

1993

Ingreso antes de imp. m

c

1994

2003 735,4 357,2 151,6 108,7 1.352,9

2002 557,5 397,0 170,8 96,9 1.222,2

-16-

T h is d

610-S17 o c

-17-

u m e n t is a u th d

e

z

ri

o

Anexo 2 fo r u

Modelo de revisión por fases. Fuente: Información de la empresa. Fase I: Desarrollo de concepto

s e in

ly

n

o

Fase II: Planificación de proyecto y producto

Fase III: Diseño y desarrollo detallados

Fase IV: Prueba, verificación y validación de producto

Fase V: Lanzamiento y aumento del producto

Objetivo

Definir oportunidad de mercado, necesidades de los clientes y viabilidad del producto

Perfeccionar concepto de producto y crear plan de desarrollo

Desarrollo de producto hasta el punto de unidad funcional

Verificar que el producto se ajuste a las especificaciones y prepararse para enviarlo a los clientes

el producto y los procesos a producción, ventas y apoyo de rutina

Productos del proyecto

Evaluación preliminar de mercado

Especificación detallada de producto y necesidades funcionales

Unidad funcional

Primer envío al cliente, producto listo

Ejecutar plan de aumento

Plan de prueba / verificación

Ejecutar plan de prueba

Publicar documentación

Documentación final de diseño

Definición de reporte de problemas y mecanismo de acción correctiva

Evaluar proyecto

L u is

C

e

u

q

ri

n

E

a

Evaluación técnica preliminar

Plan de desarrollo que incluye matriz de estrategia de ejecución de proyecto

Evaluación financiera preliminar 's

s

p

m

Armonización del plan a mediano plazo

Plan de negocios

Documentación preliminar

a

Matriz preliminar de estrategia de ejecución de proyecto (MEEP)

Evaluaciones de riesgo

Necesidades del cliente, especificaciones y análisis de laguna de costos

o E v lu a c io n y

Documentos de usuario final

Análisis de armonización de llevar producto al mercado

Curso de capacitación de usuario

Plan clave de gestión de cuenta

Capacitación de apoyo de campo

Actualización de hoja de ruta de producto

Prueba de manufacturabilidad o

ti

e

g

Materiales finales de ventas y mercadeo e

Plan de aumento de producción

Aumentar, sostener, mejorar necesidades de recursos

s n d p ro to

c

e

y

Equipo s c o u rs e

Plan de mejora/actualización (si es necesario)

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 mínimo

Transfuncional (Ingeniería, Mercadeo, Manufactura, Ventas y Apoyo.)




Revisión de productos de fase



Planes de medida correctiva

Confirmar capacidad de despacho por volumen

a

Nombrar líder de proyecto t e

iv

n

U

Punto rs


id

Revisión de productos de fase Revisión del comité ejecutivo

a d d e l P

Resolver problemas clave abiertos a o

ic

if

c

Resultado fr

,

Financiamiento y recursos para la Fase II

o m

Financiamiento para desarrollar el producto El equipo se compromete a desarrollar el producto

O c to b e

Listo para primera prueba de piezas

Producto listo para despacharse en volumen

Listo para verificación de sistema

Aprobación para primer envío al cliente (PEC) Primer cliente capacitado y listo Apoyo listo

r 2 0 to

7

1

Fuente: Información de la empresa.

.

8

1

0

2

h

rc

a

M

Se fabrica el producto en el volumen requerido Acuerdo en que se han logrado los objetivos del proyecto Se liberan todos los recursos de desarrollo

T h is d

610-S17 o c

-18-

u m e n a

is

t

Anexo 3 th

u

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

o ri d

e

z

Dimensión de proyecto o

e

s

u

r

fo

Definición de proyecto ly

n in L u is E n ri q u e C a m p o s 's E v a lu a c y

n

io

Gobernabilidad y personal del proyecto ti

s

e

g o n d

s

to

c

e

y

ro

p

e

Principios

- El proyecto tendrá objetivos muy contrapuestos en las áreas de costo vs. cronograma vs. funcionalidad de la plataforma común. Se definirá para optimizar la “combinación apropiada” de estos intercambios contrapuestos. - Se favorecerá la amplitud de cobertura del mercado y la optimización de mediados del SOC por encima de la optimización para los extremos de costo o desempeño del mercado SOC. - La arquitectura de lugar universal será el capacitador clave para brindar la flexibilidad necesaria del mercado SOC. - Consideraremos las necesidades del segmento de mercado independiente de 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. - Se supone que la dotación de personal es de tiempo completo y dedicada al proyecto. - El equipo básico es responsable por el éxito del programa.

Estructura de tareas y actividades del proyecto

- El proyecto usará un proceso único e integrado de desarrollo de productos. - Las tareas solo se asignarán a personas que están activas dentro del proyecto.

t

a

e

rs

u

o

Diseño, prototipo y prueba

- Se utilizará simulación siempre que sea posible como el primer paso en la creación de prototipos. - Se requerirán prototipos físicos para cualquier tecnología que no se haya reducido a práctica en Teradyne. - La revisión de la alta gerencia serán impulsadas por el tiempo más bien que por los eventos. - El análisis de laguna de medidas del programa será el núcleo de las revisiones de la alta gerencia. - La definición del proyecto se considera cerrada al concluir la Fase 2 a menos que haya un cambio importante en las necesidades, el riesgo o el panorama competitivo. - Los intercambios se rastrearán formalmente y se resumirán cada mes.

c

U n id

rs

e

iv

Revisión y control de la alta gerencia d

d

a e l P ic

if

c

a

Correcciones a medio camino en tiempo real

r

e

b

to

c

O

m

o

fr

,

o


.

8

1

0

2

h

rc

a

M

to

7

1

0

2

Proceso

- La actual tecnología y elementos básicos se aprovecharán mientras exista un mínimo de componenda contra los objetivos priorizados del programa.

Estructura

- El equipo básico es responsable de la definición del proyecto. - Equipo de arquitectura a tiempo completo dirigido por George Conner.

- Las decisiones serán impulsadas por el impacto cuantificado contra las medidas de los objetivos priorizados del programa. - Objetivos jerárquicos priorizados—( objetivos priorizados para Jaguar y para cada subproyecto)

- Integración del equipo básico jerárquico. - La planificación agregada de proyectos es la principal herramienta de gestión de dotación de personal. - El proceso se armonizará con el marco de revolución en el desarrollo de productos y se basará en las mejores prácticas por consenso que existan en STD. - Resumidos mensualmente como parte del resumen de riesgos.

- Equipo de peso pesado organizado en áreas clave de subproyecto. Líderes de subproyecto organizados en un equipo básico dirigido por Jack O’Brien.

- La alta gerencia analizará el programa en una reunión mensual de patrocinio. - Tablero del programa para empleo de medidas.

- Revisión entre el equipo básico de Jaguar y Mike Bradley y su personal.

- Actualización trimestral de PLA competitivos y necesidades de segmentos de mercado. - Resumen mensual de medidas clave, riesgos y VIT.

- Revisiones mensuales en persona con el equipo básico - Reuniones regulares de integración con equipos de mercado de STD.

- Equipo de gerentes de programa a tiempo completo con un recurso a tiempo completo por subproyecto. - Estrategia para cada área que es responsabilidad de los líderes de subproyecto.


Anexo 4

610-S17

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

610-S17


5.000

CPTP (Planeado)

CRTE (Real)

$

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.


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


610-S17

610-S17

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

Verificación de sistema

0

0

26

30

30

29

25

25

23

21

11

5

2

Administ.

4

4

5

5

5

5

5

5

5

5

5

5

5

140

167

234

271

273

273

270

266

262

246

220

200

168

Total

Necesidades de personal de Jaguar (4T01-- 4T04)

300 250 200

200 s o so d

T h is d

610-S17 o c u m e is

t

n

Anexo 7 u

a

Cronograma de principales fases del proceso de desarrollo para el Proyecto Jaguar

th o ri z e d fo r u s e o n ly u

L

Se recibe la noticia de que AlphaTech revisó un sistema de la competencia

in

Se inicia el Proyecto Jaguar u

q

ri

n

E

is

Fase II Revisión del proyecto

Se reconoce retraso en el software por segunda vez; se posterga la revisión de la Fase IV a abril de 2005

Envío a AlphaTech (versión 1), fin de Fase III

Primera revisión modificada de Fase IV

Tercera revisión modificada de Fase IV

e C a m p o

Primer envío al cliente originalment e planeado

Fase II: Se concluyen las revisiones de subproyecto s 's E v a lu a c io n y g e s ti o n d ro

p

e

Mayo 01 e

y

Mayo 02

Sep. 02

Sep. 03

Nov. 03

Mar. 04

Abril 04

Junio 04

Ag. 04

Dic. 04

En. 05

Abril 05

Junio 05

c to s c o u rs e a t U n iv e rs id

Revisión de Fase IV originalmente planeada a d d P

l

e

Decisión de Teradyne de proceder con AlphaTech fr

,

o

ic

if

c

a

o m O e

b

to

c


.

8

1

0

2

h

rc

a

M

to

7

1

0

2

r

Se reconoce retraso en el software por primera vez; se posterga la revisión de la Fase IV a enero de 2005

Se reconoce retraso en el software por tercera vez; se posterga la revisión de la Fase IV a junio de 2005

Segunda revisión modificada de Fase IV

-23-

6

1

0

-

S

1

7

-

2

4

-

T h is d

610-S17 o c u m e is

t

n

Anexo 9 u

a

Ejemplo de datos proporcionados por el análisis de valor deve ngado

th o ri z e r

fo

d

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

30000 30000 s

u e ly

n

o

25000 25000 u

L

in

Valor Deveng. CUM CUM (CPTR) (CPTR)

O JO J A A B B A A 20000 20000 R R T T E E D D S 15000 S A A 15000 R O OR H H lu

a

v

E

's

s

o

p

m

a

C

e

u

q

ri

n

E

is

CUM Real Real (CRTR) (CRTR) Última Última Estim. Realiz. (UER) (UER) Real Pronóstico EAC Pronóst. VD

10000 10000 io

c

a n y e

g

5000 5000 o

ti

s n d e p

0 c

03 En. u

o

c

s

to

e

y

ro

rs e a t U rs

e

iv

n


.

8

1

0

2

h

rc

a

M

to

7

1

0

2

r

e

b

to

c

O

m

o

fr

,

o

ic

if

c

a

P

l

e

d

d

a

id

CUM Planeado (CPTP)

-0 y3

-03 ar M

a M

-03 ul J

-03 Sep FECHA

-03 ov N

- 04 En

- 04 ar M

-25-

610S17-PDF-SPA

Recommend Documents