610 - S 1 7 MAY 3,2006 FRAN CES CA GINO GARY PISANO Teradyne Corporation: El Proyecto Jaguar Jack O’Brien miró el reloj
Views 188 Downloads 1 File size 502KB
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 2
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.
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 3 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
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
4
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.
Teradyne Corporation: El Proyecto Jaguar
610-S17
recursos suficientes y adecuados. Aunque aparentemente era una herramienta simple para usar, la Planificación Agregada de Proyectos requería mucho cambio de conducta y disciplina. 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.
5 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
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 “.
6 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.
Teradyne Corporation: El Proyecto Jaguar
610-S17
Desde el principio, se reconoció que el proyecto tenía que ejecutarse a la perfección. Como lo señaló Mike Bradley, entonces presidente de la División de Prueba de Semiconductores: Fue una escogencia estratégica simple pero monumental. Teníamos una sólida base instalada de clientes comprometidos con nuestras plataformas existentes. Pasar a una sola plataforma de control significaba perturbar esta base instalada. Esto era riesgoso, por decir lo mínimo. Y significaba que la escogencia del momento era absolutamente crítica. Si nos hubiéramos quedado con nuestras arquitecturas existentes, podríamos haber argumentado ante nuestros clientes que valdría la pena esperar nuestros nuevos productos. Pero una vez que nos comprometimos con una estrategia de control y una nueva arquitectura de plataforma única, ya no podíamos argumentar eso. Esto significaba que teníamos que llevar el nuevo probador al mercado tan rápido como fuera posible o dejaríamos a muchos de nuestros clientes expuestos a la competencia. Se decidió que por ahí de junio de 2004 sería una fecha objetivo crítica para empezar a despachar el probador. En vista de lo mucho que estaba en juego en el éxito del proyecto, la división y los altos líderes corporativos se interesaron activamente y desde el principio en el proyecto. Un área de atención temprana fue el establecimiento de un ámbito claro para el proyecto. Bradley explicó: Las decisiones más críticas en la fijación del tamaño del productos no tienen que ver con lo que se hace, sino con lo que no se hace. En el pasado tendíamos a “apostarlo todo” al dimensionamiento inicial, y luego quitábamos características al sistema, cuando no podíamos cumplir con el cronograma de trabajo. Con el Jaguar, tuvimos que hacer lo contrario para cerciorarnos de aprovechar la ventana de mercado. Este fue un cambio incómodo, pero que tuvimos que hacer. En la práctica, esto significó pasar más tiempo de lo usual en las primeras etapas del proceso de desarrollo (desarrollo conceptual y planificación de productos). Bradley y otros altos gerentes presionaron a O’Brien y a su equipo para que identificaran claramente las necesidades del cliente y se comprometieran con especificaciones clave de productos. Además, la alta gerencia también impulsó al equipo a identificar todos los riesgos técnicos críticos y los planes de contingencia para manejar esos riesgos. Como parte del proceso de desarrollo de Teradyne, no se harían grandes compromisos de financiamiento para un proyecto hasta que la alta gerencia accediera a apoyar la Fase 2. Pasar esta puerta requería una serie de análisis detallados y una expresión clara de los requisitos del producto. En el Proyecto Jaguar, esto causó inicialmente cierta frustración, ya que el equipo estaba ansioso por proceder con la ingeniería detallada. [George] Conner comentó: Tenemos la tendencia a acumular todo en la Fase II debido a que la alta gerencia espera un alto nivel de certidumbre antes de comprometerse con el programa. Terminamos por tener que presentar planes detallados, cronogramas y especificaciones en ese punto y esto deja menos espacio para la experimentación en la Fase III. Quizás yo sea el único con esta perspectiva, pero creo que la Fase II debe limitarse a identificar riesgos y a entender si se pueden resolver en la Fase III. En mayo de 2002 el equipo Jaguar regresó a la alta gerencia con una presentación de 75 páginas que detallaba la arquitectura del sistema propuesto, el diseño y las especificaciones funcionales para los subsistemas críticos, las especificaciones objetivo de desempeño y el plan de ejecución del proyecto. Satisfechos de que el alcance del proyecto estaba claramente definido, enfocado y alineado con el mercado, los altos gerentes aprobaron formalmente la Fase 2.
7 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
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).
8 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.
Teradyne Corporation: El Proyecto Jaguar
610-S17
Análisis de valor devengado, un método para medir el progreso del proyecto mediante la comparación de los recursos (o el tiempo) reales y esperados que se han invertido.
O’Brien 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.
9 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
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 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.
Teradyne Corporation: El Proyecto Jaguar
610-S17
Repetían constantemente que iban a ponerse al día“. Cuando se preguntó por qué la gerencia del equipo básico o la alta gerencia no intervenían, Giebel dijo: ”Una de las razones era que el equipo de gerencia no prestó suficiente atención a los datos debido a su escepticismo en torno a la medida“. Conner agregó: ”El problema del software surgió gradualmente. No lo vimos sino hasta muy tarde, pero todos sabíamos que el asunto estaba mal“. La capacidad del equipo para adaptarse fue puesta severamente a prueba en septiembre de 2003, cuando Teradyne recibió la noticia de que una de las mayores empresas de semiconductores del mundo, llamada AlphaTech, un enorme cliente potencial, estaba a punto de comprometerse con un sistema de la competencia. La alta gerencia vio esto como un fuerte golpe potencial a todo el programa. El tamaño de AlphaTech, y su estatura en el mercado, significaban que su escogencia tendría una poderosa influencia en el resto de la industria. Bradley comentó: “La idea de poner un nuevo producto o un cliente estratégico en riesgo no era algo que fuéramos a tomar a la ligera. Nuestro equipo de desarrollo tenía que apoyar plenamente el esfuerzo para tener el Jaguar listo a tiempo para este importante cliente, y así lo hizo”. El desafío era que Teradyne no esperaba tener un sistema listo para su evaluación hasta junio de 2004, a casi 10 meses de distancia. Mientras tanto, el sistema de la competencia ya estaba terminado y en los laboratorios de evaluación de AlphaTech. Rogas, que había trabajado estrechamente con AlphaTech por más de 20 años, comentó: 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 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
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
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.
Teradyne Corporation: El Proyecto Jaguar
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 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 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
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
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.
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
Anexo 1
Estados financieros de Teradyne
Resumen de resultados operativos (en millones de dólares, excepto ingresos por acción)
Ventas netas
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
1994
1993
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 Sistemas de pruebas de semiconductores Sistemas de conexión Sistemas de prueba de montaje Otros sistemas de pruebas
$1.146,3 381,7 155,2 108,7 $1.791,9
Fuente: Sitio web de Teradyne, www.teradyne.com.
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-
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
Anexo 2
-17-
Modelo de revisión por fases. Fuente: Información de la empresa. Fase I: Desarrollo de concepto
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
Plan de desarrollo que incluye matriz de estrategia de ejecución de proyecto
Documentación final de diseño
Definición de reporte de problemas y mecanismo de acción correctiva
Evaluar proyecto
Plan de negocios
Documentación preliminar
Evaluaciones de riesgo
Necesidades del cliente, especificaciones y análisis de laguna de costos
Evaluación técnica preliminar Evaluación financiera preliminar Armonización del plan a mediano plazo Matriz preliminar de estrategia de ejecución de proyecto (MEEP)
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 Materiales finales de ventas y mercadeo
Equipo
Plan de mejora/actualización (si es necesario)
Plan de aumento de producción
Aumentar, sostener, mejorar necesidades de recursos
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.)
Transfuncional (Ingeniería, Mercadeo, Manufactura, Ventas y Apoyo.)
Transfuncional (Ingeniería, Mercadeo, Manufactura, Ventas y Apoyo.)
Transfuncional (Ingeniería, Mercadeo, Manufactura, Ventas y Apoyo.)
Revisión de productos de fase
Revisión de productos de fase
Revisión de productos de fase
Planes de medida correctiva
Confirmar capacidad de despacho por volumen
Nombrar líder de proyecto Punto
Revisión de productos de fase
Revisión de productos de fase Revisión del comité ejecutivo
Resolver problemas clave abiertos Resultado
Financiamiento y recursos para la Fase II
Financiamiento para desarrollar el producto El equipo se compromete a desarrollar el producto
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
Fuente: Información de la empresa.
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
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
Anexo 3
-18-
Matriz de estrategia de ejecución de proyecto (MEEP)
Dimensión de proyecto Definición de proyecto
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.
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)
- 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 personal del proyecto
- 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.
- 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.
- 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.
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.
- 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.
- Equipo de gerentes de programa a tiempo completo con un recurso a tiempo completo por subproyecto.
Diseño, prototipo y prueba
- Se utilizará simulación siempre que sea posible como el primer paso en la creación de prototipos.
- Resumidos mensualmente como parte del resumen de riesgos.
- Estrategia para cada área que es responsabilidad de los líderes de subproyecto.
- La revisión de la alta gerencia serán impulsadas por el tiempo más bien que por los eventos.
- La alta gerencia analizará el programa en una reunión mensual de patrocinio.
- Revisión entre el equipo básico de Jaguar y Mike Bradley y su personal.
- El análisis de laguna de medidas del programa será el núcleo de las revisiones de la alta gerencia.
- Tablero del programa para empleo de medidas.
- 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.
- Actualización trimestral de PLA competitivos y necesidades de segmentos de mercado.
- Revisiones mensuales en persona con el equipo básico
- Resumen mensual de medidas clave, riesgos y VIT.
- Reuniones regulares de integración con equipos de mercado de STD.
- 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 alta gerencia
Correcciones a medio camino en tiempo real
- Los intercambios se rastrearán formalmente y se resumirán cada mes.
Fuente: Información de la empresa.
Teradyne Corporation: El Proyecto Jaguar
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 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 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
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.
20 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.
Teradyne Corporation: El Proyecto Jaguar
Anexo 5
610-S17
Organigrama del proyecto
Jack O’Brien: Líder del proyecto Kevin Giebel: Gerente de programa Paul Roush: Software George Conner: Arquitectura del sistema Joe Carbone: Analog Instrumentation Porting Peter Breger: Sistema Básico Simon Longson: Interfaz DUT Ben Brown: Calibración y Exactitud, Digital Tempe ASIC, Ferrari ASIC Ray Mirkhani: Mecánica Tony George: Proyecto Miata (el nuevo instrumento digital que era parte de Jaguar) Brian Davie: Gerente Funcional Global de ASIC
Fuente: Preparado por los escritores del caso con base en información de la empresa.
21 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
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
Empleados
200 200 s o d e a l 150 p m 150 E
Admin. Verific. de sist. Verific. de sist. Software Software Hardware
100
50
4 0 T 4
4T04
4 0 T 3
3T04
4 0 T 2
2T04
4 0 T 1
1T04
3 0 T 4
4T03
3T03
3 3 0 0 T T 2 3 Trimestre
2T03
3 0 T 1
1T03
2 0 T 4
4T02
2 0 T 3
3T02
2 0 T 2
2T02
2 0 T 1
1T02
1 0 T 4
4T01
0
Fuente: Información de la empresa.
22 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.
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
Anexo 7
Cronograma de principales fases del proceso de desarrollo para el Proyecto Jaguar
Se inicia el Proyecto Jaguar
Se recibe la noticia de que AlphaTech revisó un sistema de la competencia
Fase II Revisión del proyecto
Mayo 02
Sep. 02
Primera revisión modificada de Fase IV
Tercera revisión modificada de Fase IV
Primer envío al cliente originalment e planeado
Fase II: Se concluyen las revisiones de subproyecto
Mayo 01
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
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 de proceder con AlphaTech
Fuente: Preparado por los escritores del caso con base en información de la empresa.
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-
-24-
Información de la empresa. Fuente:
Anexo 8
Prueba Ultra Flex
610-S17 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.
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 JO A B A 20000 R 20000 T E D S 15000 15000 A
Valor Deveng. CUM CUM (CPTR) (CPTR)
HORAS DE TRABAJO
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
CUM CUM Real Real (CRTR) (CRTR) Última Última Estim. Realiz. (UER) (UER) Real Pronóstico EAC Pronóst. VD
OR H 10000 10000
5000 5000
0 03 En.
Fuente: Información de la empresa.
0 y- 3
0 -3 ar M
a M
0 -3 ul J
-03 Sep FECHA
0 -3 ov N
- 04 En
- 04 ar M
-25-