Teradyne Corporacin: El Proyecto Jaguar

Jack O'Brien mir el reloj en su coche, que era 7:38 de la maana y saba que iba a necesitar un poco de suerte para llegar a las 08 a.m. a una reunin en la sede de Teradyne Harrison Avenue. El trfico en la arteria central de Boston se asfixi en medio de la persistente construccin del interminable "Big Dig". O'Brien estaba esperando a la reunin de hoy con los altos directivos de Teradyne para reflexionar sobre las lecciones aprendidas del proyecto Jaguar, que O'Brien haba dirigido por ms de tres aos. El proyecto haba sido uno de los esfuerzos ms importantes en 45 aos de historia de Teradyne. Se haba propuesto crear una nueva plataforma de sistema de prueba de semiconductores. El sistema Flex Ultra, diseado para ser lo suficientemente flexible como para permitir a los clientes probar una amplia gama de dispositivos semiconductores, fue fundamental para el xito de la nueva estrategia competitiva de Teradyne. El proyecto Jaguar haba marcado la culminacin de este tipo de proyectos, fue un esfuerzo de 8 aos para Teradyne para mejorar su proceso de desarrollo de productos. El equipo Jaguar haba utilizado una serie de prcticas de gestin de proyectos, incluida la planificacin intensiva por adelantado proyectos, herramientas formales para el seguimiento de los avances del proyecto, y un proceso de desarrollo ms estructurado. La mayora de los aspectos del proyecto Jaguar fueron excesivamente bien. El equipo importante, por ejemplo, que el producto se haya desarrollado en un tiempo rcord, y con una mnima desviacin del plan. El producto haba cumplido la gran mayora de sus especificaciones de destino. Sin embargo, al mismo tiempo, el software, un componente importante del programa, se haba quedado gravemente retrasado y todava no se ha completado. Adems, los costos totales de desarrollo han aumentado en un 35 % ms de lo presupuestado inicialmente. Mientras que algunos miembros del equipo Jaguar incluyeron las herramientas de gestin de proyectos, otros se resistieron fuertemente, o simplemente no las tomaron en cuenta. O'Brien explic:
Se han utilizado estas herramientas para forzar la disciplina en el proceso de desarrollo. Con los datos e informacin proporcionados por las nuevas herramientas que utilizbamos, hemos sido capaces de saber si un equipo estaba leseando o s tena el trabajo realizado al ritmo adecuado. Por supuesto, se necesita algo ms que simples herramientas: Necesita los lderes adecuados en las posiciones correctas, esos lderes estn facultados y aquellos lderes que aceptan la responsabilidad y la rendicin de cuentas por su pedazo de proyecto.

Pero otros eran ms escpticos. George Conner, arquitecto del sistema de Jaguar, pensaba que las herramientas pueden ser una distraccin :
El noventa y ocho por ciento de las veces en las reuniones transcurri intentando averiguar si la herramienta refleja la realidad, en lugar de discutir qu hacer. Con las herramientas de programacin, usted tiene que especificar la secuencia y estructura de tareas con antelacin. Pero este es claro que las herramientas se ponen ms complicadas, que gasta ms de su tiempo a tratar con las herramientas, en lugar de hacer las preguntas correctas.

De acuerdo con la creencia profundamente arraigada de Teradyne en la mejora continua, O'Brien y la alta direccin ya comenzaran un proceso de investigacin de la historia del proyecto y seleccionando lecciones aprendidas. El resultado del proceso podra afectar la forma en que Teradyne ejecuta los proyectos de desarrollo en los prximos aos. A medida que el trfico avanz poco a poco, O'Brien se impacient. Odiaba llegar tarde.

Teradyne y la Divisin de Semiconductores de Prueba

Teradyne fue el mayor proveedor mundial de equipos para semiconductores de prueba, con ventas de $ 1,8 mil millones (en 2004) y ms de 6.000 empleados que trabajan en todo el mundo (Ver Anexo 1 Estados Financieros de Teradyne). Fundada en 1960 por Alex D' Arbeloff y Nick DeWolf, dos compaeros de clase en el Instituto de Tecnologa de Massachusetts (MIT), Teradyne se centraron inicialmente en la fabricacin de equipos para probar transistores

y otros componentes electrnicos. Su negocio involucrado una nueva clase de "calidad industrial" en equipos de prueba electrnicos, conocidos por su fiabilidad, velocidad de la prueba, y el rendimiento tcnico. Durante los prximos 30 aos, se volvi una tarea complejidad ya que el volumen de produccin de semiconductores aument exponencialmente, Teradyne continu invirtiendo fuertemente en I+D para mantenerse a la vanguardia de la tecnologa de prueba. Durante este tiempo, Teradyne tambin haba diversificado hacia otros mercados de prueba electrnicos relacionados. En 2004, Teradyne organiz cinco principales unidades de negocios - Prueba Semiconductor, Prueba de la Asamblea, de Prueba de Banda Ancha, Sistemas de Conexin, y de Soluciones de diagnsticos- por los productos que elaboran y entregan. Prueba Semiconductor fue la unidad de negocios ms grande de la sociedad, la cual entrega el 64 % de los ingresos totales de la compaa en 2004. La unidad de prueba de semiconductores tuvo importantes operaciones de ingeniera ubicada en Boston (Massachusetts), North Reading (Massachusetts), Minneapolis (Minnesota), Tualatin (Oregon), San Jos (California), y Agoura Hills (California). Boston, North Reading, y Agoura Hills tambin alojan las operaciones de fabricacin de la empresa. La fabricacin interna de la empresa se centr en el montaje final y la prueba (subsistemas y componentes fueron subcontratadas). Adems, la compaa contaba con organizaciones de ventas y de ingeniera ms pequeos dispersos en sus principales mercados mundiales, incluyendo Japn, China y Alemania.

Tecnologa de Ensayos Semiconductor

Los semiconductores abarcaron una amplia gama de tipos de dispositivos, que se redujo en dos categoras: (1) la Memoria, y (2) el sistema operativo en un chip (SOC). El SOC incluye microprocesadores (Iogic), procesadores analgicos, procesos de seales mixtas digitales (que combinan circuitos digitales y analgicos), dispositivos especializados para grficos y sonido, y los circuitos integrados personalizados. Cada tipo de dispositivo realiza un trabajo diferente en un sistema electrnico. Con independencia de su finalidad, los semiconductores eran dispositivos de alta precisin que realizaron manipulaciones complejas de seales electrnicas. La capacidad de un dispositivo para llevar a cabo su funcin depende de su diseo, todo est en su fabricacin. Incluso el defecto de menor importancia en el proceso de produccin (por ejemplo, una pieza errante de polvo, o una pequea desviacin en la especificacin) podra impedir que un dispositivo funcione correctamente. El trabajo de un probador de semiconductores fue determinar si un chip cumpla o no las especificaciones de destino. Para hacer esto, el probador esencialmente examin el dispositivo electrnicamente (envi seales y, a continuacin, realiz una medicin de la respuesta). Esta tarea aparentemente sencilla era, en realidad, uno de los problemas ms difciles en toda la industria de la electrnica. Para trabajar como se especifica, un semiconductor tena que ser capaz de realizar una amplia gama de operaciones con otros componentes de un sistema electrnico. El sistema de prueba de semiconductores tuvo que determinar si el chip era capaz de realizar estas operaciones en el aislamiento . Por lo tanto, el sistema de prueba tena que simular los entornos de los sistemas electrnicos en los que podra utilizarse el dispositivo. Como los dispositivos BECA me cada vez ms complejo y preciso, este desafo se increment de forma exponencial. Los precios de los sistemas de Teradyne podran alcanzar los $ 3 millones o ms .

Industria de los Semiconductores de Prueba

En 2004, Teradyne posee en torno al 35% del mercado mundial de sistema en un chip (SOC) probadores semiconductores. Los otros principales lderes del mercado en esta industria fueron Agilent (con una cuota del 10 %), Advantest y Credence. El mercado de los probadores de semiconductores, como la propia industria de los semiconductores, era muy cclico. Clientes- fabricantes de semiconductores como Intel, Texas Instruments , IBM, Hitachi , Samsung y fabricantes por contrato como TSMC - generalmente colocan sus mayores pedidos de equipos de prueba de semiconductores cuando estaban haciendo la transicin a una nueva generacin de tecnologa de pruebas cuya requisitos no pudieron satisfacerse con el equipo existente . Dada la tasa rpida histricamente de la innovacin tecnolgica en los semiconductores, esto hizo imperioso para las empresas de equipos de prueba a una fuerte inversin en I+D y para golpear "ventanas de mercado." En general, los clientes prefieren seguir con los

sistemas existentes para aprovechar la experiencia del pasado, familiaridad, y la formacin. Por lo tanto, una vez que una empresa tester "gan una cuenta, " era difcil para otra empresa para desalojarlos a menos que su servicio o el rendimiento era excepcionalmente pobre. Al elegir entre los vendedores, proveedores de semiconductores buscaron prestaciones tcnicas y caractersticas: el equipo podra probar su dispositivo? Tambin se centraron en gran medida en la economa de las pruebas, que fueron impulsados en gran medida por la prueba de velocidad. Este ltimo requisito es especialmente importante, dado que la prueba era a menudo un cuello de botella en el proceso total de la produccin de semiconductores , y que los mrgenes en muchos segmentos del negocio de los semiconductores eran relativamente bajos . La fiabilidad fue tambin una demanda cada vez ms importante de los clientes debido tiempo muerto del equipo era extremadamente costoso para un fabricante de semiconductores. La capacidad de un proveedor para el mantenimiento del equipo y proporcionar apoyo tcnico rpido se consider esencial para competir en este mercado.

Teradyne Cultura
Teradyne conserva la fuerte cultura de ingeniera que haba sido impresa por sus fundadores. Muchos de sus altos directivos eran ingenieros bien entrenados. Estado se vio impulsado por el rendimiento , sobre todo , la competencia tcnica. Vestido era informal . Oficinas eran cubculos , incluso para la mayora de los altos ejecutivos de la compaa. La cultura alienta la iniciativa individual. Los nuevos reclutas se les advirti que nadie les diga qu hacer, pero era su responsabilidad de "buceo en " y ", como k las preguntas correctas. " Largas horas eran la norma. En general , la compaa tuvo un buen resultado en la contratacin de ingenieros de las mejores escuelas como el MIT y retener este talento durante varios aos. La mayora de los altos ejecutivos de la compaa haban pasado la mayor parte de sus carreras con Teradyne . Un hito importante en la evolucin de la empresa se produjo en la dcada de 1990 , cuando el entonces CEO Alex D' Arbeloff decidi transformar la forma en que la empresa opera a travs de la puesta en marcha de una "gestin de calidad total" (TQM ) programo En ese momento, D' Arbeloff era cada vez ms preocupa que a pesar de su talento excepcional, Teradyne estaba en riesgo de perder su ventaja competitiva , ya que sus productos eran a menudo tarde al mercado y sufrieron problemas de calidad y de fiabilidad. Al mirar alrededor, D' Arbeloff dio cuenta de que muchos de los procesos bsicos de funcionamiento de la empresa no estaban bajo control. Su actuacin no haba sido medido , y no haba ningn esfuerzo sistemtico para mejorar esos procesos. Para corregir esta deficiencia, D' Arbeloff abraz TQM ( Total Quality Management ) , un conjunto de principies , filosofas y prcticas que hizo hincapi en la vigilancia permanente y la mejora de los procesos de una organizacin. Un intenso periodo de formacin en principies y herramientas TQM seguido para todos los empleados , empezando por los altos ejecutivos. D' Arbeloff insisti en que todos, empezando por l mismo , siga las metodologas de la GCT , principies y prcticas que hacen su trabajo . D' Arbeloff esperaba que sus subordinados directos , por ejemplo , para utilizar dichas herramientas de TQM , tales como procesos de siete pasos de resolucin de problemas , anlisis de causa raz , y diagramas de espina de pescado en la comunicacin y discusin de los problemas de gestin . A mediados de la dcada de 1990 , tras cinco aos de intenso esfuerzo , Teradyne haba incrustado TQM en la mayora de los aspectos del trabajo en la empresa. Y , lo ms importante , los resultados en la mayora de los aspectos de las operaciones - tales de la compaa como la calidad de fabricacin y de servicio al cliente mejorado de forma espectacular.

Desarrollo de Productos en Teradyne

Cuando se inici la GCT , D' Arbeloff haba esperado que sera transformar la organizacin de ingeniera tambin. Por desgracia , en 1996 , estaba claro que la ACT no se est afianzando en la ingeniera, como proyectos continuaron a llegar tarde y el exceso de presupuesto , a veces por un factor de dos . Los ingenieros se resistieron a

los enfoques estructurados para la resolucin de problemas , y vieron la GCT como una intromisin en su libertad. En 1996 , D' Arbeloff lanz una iniciativa independiente centrado en el desarrollo de productos . El "desarrollo revolucionando producto" de iniciativa apodado (RPD ) , fue puesto bajo el liderazgo de Ed Rogas , vicepresidente senior y veterano de Teradyne 25 aos . Liderazgo senior de ingeniera de la compaa de varias divisiones se ensambla en un Equipo de Mejora de Procesos de Ingeniera ( EPIT ) . Rogas y la EPIT , que se reuni mensualmente, fueron acusados de desarrollar e implementar un nuevo enfoque para el desarrollo de productos a lo largo de Teradyne . En ese momento, los problemas de la empresa se dividen en dos categoras. En primer lugar, las organizaciones de ingeniera en toda la compaa se vieron gravemente sobreasignadas en proyectos ( utilizacin de la capacidad se estima en tan alto como 300 %). Para abordar este problema, la empresa puso en marcha un proceso de planificacin de la capacidad del proyecto ms estructurado y riguroso conocida como Planificacin de Proyectos Aggregate (APP ) . Haba dos principies rectores del proceso de APP : ( 1 ) Llevar a cabo nicamente los proyectos que se alinean con la estrategia general de la empresa , (2 ) no sobre -commit , y slo comenzar proyectos cuando los recursos adecuados y apropiados estn disponibles. Mientras que una herramienta aparentemente simple de usar, la APP requiere una gran cantidad de cambio de conducta y disciplina. El segundo problema en Teradyne relacionado con la ejecucin de los distintos proyectos . Los proyectos fueron mal planeados . Los objetivos y el alcance a menudo no estn claramente definidos desde el principio y , como resultado , los proyectos tienden a expandirse a medida que los ingenieros y los comercializadores pensado caractersticas adicionales. Hitos no estaban bien definidos , y con frecuencia se perdieron . Project programa fueron puestas juntas con poco rigor . Debido a que no exista un mtodo sistemtico para el seguimiento de los avances del proyecto , que fue difcil para la alta direccin para saber cundo hay que intervenir a menos que aparecieron grandes problemas . Por ltimo , ya que los proyectos fueron manejados por las funciones de ingeniera individuales y no haba una sola persona responsable de todo el proyecto, hubo retrasos significativos y problemas de calidad causados por fallos de coordinacin y comunicacin . Para hacer frente a este segundo problema, la compaa puso en marcha varias iniciativas de mejora. Uno de ellos fue la creacin de un modelo de "fase -gate" para proyectos de desarrollo . ( Ver Anexo 2 para ms detalles sobre el modelo de eliminacin de la puerta de Teradyne , . Ver Anexo 3 para la Ejecucin del Proyecto Matriz 1de estrategia desarrollado para el proyecto Jaguar ) El propsito del modelo de eliminacin de la puerta era proporcionar bien definido hitos y puntos de revisin . La segunda iniciativa fue la implementacin de herramientas de gestin de proyectos diseados para ayudar a los equipos de los proyectos del plan , gestionar los horarios y realizar un seguimiento de los avances respecto a los objetivos . ( Ver Anexo 4 para una descripcin de las herramientas de gestin de proyectos . ) Por ltimo, en consonancia con la filosofa de la mejora continua de Teradyne , una revisin estructurada " despus de la accin " se recomienda despus de la finalizacin de todos los proyectos de desarrollo. Estas revisiones debern reunir a los miembros del equipo del proyecto y los altos directivos seleccionados para explorar thelessons aprendido. Debido a que estaba en contra de la cultura de Teradyne para ordenar el uso de ninguna herramienta especfica , se deja a las divisiones y los administradores individuales para decidir qu recomendaciones a seguir. Algunas divisiones de la compaa rpidamente adoptaron el enfoque , mientras que otros parecan resistir o simplemente ignorarlos. Este ltimo era a menudo una fuente de tensin en las reuniones mensuales Epit donde se esperaba que
1

La matriz de la estrategia de ejecucin del proyecto (PESM) sirvi de marco para la creacin de conocimiento y control comn, bien ejecutada crtica.

los gerentes de ingeniera para informar sobre los avances en sus divisiones. Incluso dentro de las divisiones , los avances fueron muy variables. Algunos gerentes de proyecto siguieron el modelo de fase -gate , comprometidos en una planificacin ms detallada del proyecto, y llevaron a cabo rigurosas revisiones posteriores a la accin , mientras que otros no lo hicieron. Rogas creci cada vez ms frustrado con lo que vio como un comportamiento " pasivo-agresivo " . Ms preocupante para Rogas fue la falta de un cambio de comportamiento . Lament : . . "Algunas personas estaban pasando por los movimientos de la utilizacin de las herramientas , pero no eran realmente cambiar sus comportamientos Todava estaban exceso de la comisin Todava estaban dar con horarios poco realistas. No estaban siendo intelectualmente honestos " .

Una nueva estrategia y una nueva estructura

Histricamente , Teradyne y otros proveedores de equipos de prueba diseadas completamente diferentes sistemas de ensayo para cada tipo de dispositivo semiconductor (memoria , digital / lgica , la analoga , la mezcla de seal , etc.) La ventaja de este enfoque es que permite el diseo del probador a ser optimizado para los requisitos de la prueba del dispositivo en particular. Teradyne alinea su estructura organizativa con cada mercado , con diferentes unidades de negocios enfocadas en diferentes segmentos del mercado : el dispositivo de memoria ( MTD) , lgica ( ETV ), de seal mixta (CIE) , microcontroladores (ITD) , y el sistema en un chip (SOC ) . A mediados de la dcada de 1990 , los cambios en el mercado comenzaron a erosionar la lgica de esta estrategia. En particular, como los fabricantes de semiconductores se diversificaron en una gama ms amplia de tipos de dispositivos , que pedan cada vez ms para un plattorm probador que podra probar mltiples tipos de dispositivos. Esta tendencia se aceler a finales de la dcada de 1990 con el crecimiento de los fabricantes de semiconductores del contrato, cuyo modelo de negocio era de ofrecer una amplia gama de servicios de dispositivo de prueba. Para estos clientes , las tasas de utilizacin de los probadores de dispositivos especficos eran demasiado bajos para ser econmicamente viable. Mientras Teradyne haba ofrecido previamente probadores flexibles en el extremo rendimiento bajo / medio del mercado de prueba del dispositivo , Teradyne no tena un plattorm con el rendimiento necesario para hacer frente a la totalidad del mercado . Como Joe Wrinn , vicepresidente de la Plataforma de Ingeniera, explic: " A finales de 1990 , estaba claro que esta estrategia no estaba funcionando Las plataformas fueron cada vez ms complicado y costoso para desarrollar Era cada vez ms factible para desarrollar mltiples plataformas. . . " Varios de los competidores de Teradyne haban comenzado a desarrollar una plataforma nica probador a finales de la dcada de 1990 . Marcos Jagiela , jefe de marketing de sistemas de pruebas de semiconductores , record : Teradyne haba estado sirviendo el mercado de bien con una variedad de productos optimizados en sintona con las necesidades de los distintos causado cierta frustracin, ya que el equipo estaba ansioso por empezar a moverse en la ingeniera de detalle. [George] Conner, coment: Tenemos una tendencia a amontonar todo en la Fase 11 beca utilizan la alta gerencia espera un alto nivel de certeza antes de comprometerse con el programo Terminamos tener que presentar planes detallados, horarios y especificaciones en ese punto, y esto deja menos espacio para la experimentacin en Fase 111. Puede ser que sea el nico con esta perspectiva, pero creo que la fase 11 debe limitarse a la identificacin de riesgos y entender si puede resolver en la fase 111. En mayo de 2002, la carne de equipo Jaguar de nuevo a la alta direccin con una presentacin de 75 pginas que detalla la arquitectura propuesta del sistema , el diseo y las especificaciones funcionales de los subsistemas crticos

, las especificaciones de rendimiento objetivo, y el plan de ejecucin del proyecto. Satisfecho de que el alcance del proyecto claramente definido, enfocado y alineado con el mercado, la alta gerencia firm formalmente fuera de la puerta de la fase 2.

Estructura del Equipo de Proyecto

El proyecto Jaguar fue organizado en un conjunto de equipos de proyectos, cada uno de los cuales se centran en un subsistema o tarea en particular. (Ver Anexo 5 para un organigrama del proyecto.) El tamao de la Jaguar requiere la elaboracin de recursos de ingeniera y talento de mltiples sitios, incluyendo Boston, Agoura Hills, San Jos (CA), Minneapolis y Portland. Para garantizar los niveles adecuados de integracin a travs de los diferentes sitios y equipos secundarios, un " equipo bsico " se form a partir de los lderes de cada uno de los equipos del subsistema. El equipo bsico incluye tambin un administrador de programas, Kevin Giebel, y estuvo encabezada por Jack O'Brien. El equipo central se reuni semanalmente por teleconferencia mensual y en persona para discutir los progresos realizados por cada equipo, y para tomar decisiones tcnicas y organizacionales crticos. Los altos directivos, entre ellos Mike Bradley, Mark Jagiela, y Ed Rogas, comprobar regularmente con los equipos en su progreso. Los miembros del equipo fueron principalmente veteranos de Teradyne. Como O'Brien coment: " El proyecto comenz con una mezcla de lo que necesitbamos, y que estaba disponible Conforme pas el tiempo, la organizacin se ha actualizado continuamente a medida que el talento beca me disponible La actualizacin ms notable tanto en el talento y la carne de capacidad cuando Teradyne. Decidi salir del negocio de la memoria, lo que puso a disposicin de varios lderes, as como cerca de 60 ingenieros. La parte de ingeniera del equipo central de todo reportado en O'Brien. La gente en el equipo central saba que eran responsables ante l por los resultados. Giebel, que acababa de comenzar a trabajar para O'Brien en el inicio del proyecto Jaguar, seal: " Jack puede ser muy intenso en estas reuniones Si su parte del proyecto era tarde, que quera saber por qu, y que le. Mejor que tengas una buena explicacin. l fue estupendo en la perforacin hasta causas profundas. Pero podra hacer que algunas personas se sientan incmodas. No dio mucha seguridad psicolgica. Carbone, quien tambin haba trabajado en estrecha colaboracin con Jack por muchos aos, seal: " 1 no encontr Jack estresante que trabajar para todas las gerentes de Teradyne, lo encuentro el ms fcil de trabajar foro Est muerto honesto Y l es un... gran pensador estratgico. Incluso aquellos que pensaban a veces O'Brien podra ser duras quedaron impresionado con la capacidad de O'Brien para pastorear un proyecto tan complejo a travs del desarrollo bajo una intensa presin. En palabras de Peter Breger, gerente de Ingeniera de Hardware Jaguar : " No haba nadie mejor en esta organizacin para sacar un proyecto como este que Jack. "

Herramientas de Gestin de Proyectos y Procesos

Uno de los elementos crticos de la estrategia de ejecucin del proyecto Jaguar fue el uso de herramientas de gestin de proyectos formales , incluyendo: Estructura de desglose de trabajo , una descripcin detallada de todas las tareas necesarias para completar un proyecto y su relacin entre s. Estimacin de 3 puntos , una tcnica para estimar el mnimo ( mejor de l os casos ) , mximo ( peor de los casos ) , y los tiempos de espera necesarios para completar cada tarea. Anlisis del camino crtico , que utiliza la estructura de desglose del trabajo y las estimaciones de 3 puntos para identificar tareas " cuello de botella " en el proceso de desarrollo ( ie , aquellas tareas que determinaron el tiempo overalllead del proyecto) .

 Anlisis del valor ganado , un mtodo para medir el progreso del proyecto mediante la comparacin de los recursos reales y esperados (o tiempo) gastado. O'Brien era un firme creyente en el valor de estas herramientas , especialmente para un complejo Iike proyecto.

Jaguar: Una "Utilizamos una mezcla de herramientas , como el anlisis de la ruta crtica , las estructuras de desglose de trabajo , estimacin de 3 puntos , el anlisis del valor ganado , y un programa de planificacin del proyecto denominado Primavera La mezcla nos ayud a ver diferentes cosas que estaban pasando . . tamao no sirve para todos " . O'Brien estaba convencido de que estas metodologas proporcionaran un robusto medios para comunicar el estado del proyecto a la gestin, y para identificar los temas crticos ( tales como los retrasos potenciales) que requeran accin o apoyo de la alta gerencia. Para facilitar el uso de las herramientas en el proyecto , una funcin separada " gestin de programas" se estableci como parte del equipo central . Giebel fue nombrado director del programa . En dependencia directa O'Brien, Giebel propiedad responsabilidad de garantizar que se utilizan las herramientas de gestin de proyectos y que fueron analizados y disponibles para el equipo los datos pertinentes sobre el progreso del proyecto , la programacin y la ruta crtica. Como un miembro del equipo describi, Giebel era al modo responsable de " mantener al equipo honesto. " Cada subgrupo tiene su propio director del programa tambin. Estos directores de programas son responsables para el seguimiento de los progresos y analizar los datos de las tareas de su subgrupo particular. Para asegurar la convergencia de los horarios en todos los equipos secundarios , los datos fueron ingresados en un programa de la programacin maestra basada en la web llamada primavera , lo que podra incorporar aproximadamente 15.000 tareas separadas . El uso de las herramientas que participan diferentes retos para las piezas de hardware y software del proyecto. Giebel explic : En el hardware , los atributos fsicos de una parte a menudo determinan la secuencia y la estructura de tareas apropiada . Por ejemplo , no se puede probar una parte hasta que haya diseado y construido. En el software , usted no tiene estas limitaciones fsicas. En general, usted puede hacer las tareas en casi cualquier orden. Esto le da mucha ms flexibilidad ( como ejecutar ) para shuftle gente alrededor para diferentes tareas , y para cambiar incluso el orden de las tareas . La relacin intertemporal entre cada tarea se ha especificado de antemano por lo que el programa puede calcular el impacto del retraso en una tarea a la otra tarea , as como el calendario general . Primavera se utiliz para identificar la ruta crtica ( CP ) en cada punto en el proyecto. Giebel explicit : Nos reunimos cada semana para analizar el CP . Nuestro encuentro particip el debate y las discusiones acerca de la CP . Primero, fue la Identificacin y luego fue revisado por los miembros del equipo. Se esperaba que todos supieran lo que estaba en su PC . Y esto era en realidad no es fcil en absoluto, ya que fuimos 10 capas de profundidad en el reporto CP De esta manera , la mayora de las reas del proyecto se mantuvieron visible. En la creacin de la programacin se utiliz estimaciones de 3 puntos . Esto significa que para cada tarea en el proyecto, tres escenarios se han tenido en cuenta : el optimista , el ms probable y el pesimista. Corrimos el proyecto contra las duraciones " ms probables" . Nuestra fecha comprometida buque era de 30 junio de 2004, pero el programa fue conducido a una fecha anterior (Marzo 31,2004 ) . Esta fecha se utiliza en el informe CP y se mantiene un montn de tensin en los hitos tempranos.

Resultados de los proyectos

Un Principie importante establecido por O'Brien y el equipo central era mantener el 30 de junio la fecha de primera al cliente nave fija, independientemente de los retrasos de las tareas individuales . O'Brien reflexion:

" Aun estando nosotros constantemente de retraso con respecto a lo que esperamos, nunca cambiamos el punto final Queramos mantener lo que me tensin en el proceso. ". En la prctica, esto significaba que el equipo tuvo que ser flexibles para responder a los retrasos , especialmente las relativas a los elementos de la ruta crtica . En las reuniones mensuales del equipo central , se toman las decisiones de reasignar recursos a aquellas partes del proyecto que haban sufrido retrasos . Los recursos adicionales tambin fueron puestos a disposicin del equipo de la alta gerencia . ( Ver Anexo 6 para los requisitos de Jaguar de personal. ) Como Breger coment: " El proyecto fue atendido de lujo .... La alta direccin no repar en gastos para asegurarse de que el proyecto no se retrasara . " Una de las reas clave de la gestin de la atencin fue el desarrollo de los cinco circuitos integrados de aplicacin especfica (ASIC) que formaban el ncleo del sistema . Estos ASICs fueron a la vanguardia en trminos de complejidad , sofisticacin y costo. En proyectos anteriores , problemas con el desarrollo ASIC haban sido una fuente importante de retrasos de tiempo (por lo general de seis meses a un ao) . En particular , el descubrimiento de problemas de diseo al final del proceso a menudo resultaba en " nuevos giros " de todo el chip . Para reducir la posibilidad de que esos retrasos , el equipo de ASICs en Jaguar invirti fuertemente en la simulacin y otras metodologas de ensayo temprano en el ciclo de desarrollo . Wrinn coment, " histricamente , en el desarrollo de ASIC , vamos a pasar la mayor parte de nuestros recursos en el desarrollo y muy pocos en la prueba . El Jaguar revocamos la relacin . " Este planteamiento dio sus frutos, ya que prcticamente todos los ASICs se terminaron a tiempo y sin mayores problemas de diseo . Mientras que los subsistemas de hardware fueron en gran medida capaces de mantenerse en el camino , desarrollo de software surgi como un problema. ( Ver Anexo 7 para una lnea de tiempo del proceso de desarrollo del proyecto Jaguar . ) La nueva plataforma utilizar un sistema operativo basado en Windows NT denominada IG- XL que se haba desarrollado en el sitio de Boston de Teradyne para su uso en la plataforma llamada FLEX . Debido a que el grupo de software de Boston estaba ocupado desarrollando extensiones a los bichos lnea de productos FLEX existentes y de fijacin, el desarrollo del software Jaguar tuvo que ser atendido principalmente de Agoura . Paul Roush, quien encabez este esfuerzo, seal que esto caus ciertos problemas desde el principio : La mayora de los desarrolladores en Jaguar nunca haban trabajado con IG- XL antes. Unos pocos haban limitado la familiaridad con la generacin anterior de IG- XL . Los expertos en la plataforma IG- XL se encuentran en Boston y se centraron en la ampliacin y la fijacin de la base de cdigo FLEX . Estos expertos tuvieron poco tiempo para gastar en el desarrollo de Jaguar . En ese momento la prioridad de la compaa estaba en FLEX , con frecuentes declaraciones en el sentido de que : "Si FLEX no tiene xito, no habr ningn mercado para Jaguar . " El equipo de desarrollo de Jaguar subestimado el grado de la curva de aprendizaje en la nueva plataforma . Incluso con lo que se pretende y se cree que las estimaciones conservadoras , que estaban atrasados . Varias mtricas del proyecto indican un problema. Por ejemplo, para el primer ao del programa , el software se ejecuta en aproximadamente el 50 % del valor ganado por mes . Si esto fuera correcto , esto significaba que el software estaba completando slo la mitad de las tareas que se haban previsto en un principio . Kevin Giebel seal : "Software estaba en negacin Siguieron diciendo que ponerse al da. ". Cuando se le pregunt por qu el equipo central de gestin oa la alta direccin no intervinieron , Giebel reflexion, "Una de las razones fue que el equipo directivo no prest suficiente atencin a los datos debido a su escepticismo en torno a la mtrica. " Conner aadi: " El problema del software surgi gradualmente. Simplemente no lo vimos hasta muy tarde , pero todos sabamos que estaba jodido. "

La capacidad del equipo para adaptarse fue puesta a prueba en septiembre de 2003, cuando recibi la noticia de Teradyne que una de las mayores empresas de semiconductores del mundo , nombrado ALPHATECH , un enorme potencial cliente , estaba a punto de comprometerse con el sistema de un competidor. La administracin superior vio esto como un golpe potencial grave para todo el programa. Tamao de ALPHATECH , y su estatura en el mercado, hecho que su eleccin tena una poderosa influencia en el resto de la industria. Bradley coment: " La idea de poner un nuevo producto o un cliente estratgico en riesgo no era una idea que bamos a tomar a la ligera . Nuestro equipo de desarrollo tena que hacerlo, y no , llegar totalmente detrs del esfuerzo para que el Jaguar listo a tiempo para la un cliente tan importante . "

El reto era que Teradyne no espera tener un sistema listo para evaluacin hasta junio de 2004, casi 10 meses de distancia. Mientras tanto , el sistema del competidor ya se complet y en laboratorios de evaluacin de ALPHATECH . Rogas , que haba trabajado en estrecha colaboracin con ALPHATECH durante ms de 20 aos, coment: Tuvimos que convencer ALPHATECH que deban esperar para nosotros y para superar su escepticismo. Saban por experiencia que cuando fijamos una fecha por lo general, no llevamos bien . Esta vez, la nica oportunidad que tenamos era dar en el blanco con exactitud. Todos nos llamamos todos los que conocamos a ALPHATECH -la gente que habamos trabajado durante aos - y les pedimos que nos d una oportunidad. ALPHATECH decidi dar Teradyne la oportunidad de pujar por el negocio , pero dej claro que tendran que tener un sistema listo para el 30 de marzo de 2004, y que iba a tolerar ningn desfase en el calendario . Teradyne comprometido con un programa detallado , con reseas mensuales con la gestin ALPHATECH previos a la fecha de 30 de marzo de buques. Teradyne no se permitira perder ni un solo jaln. Adems, ahora tena que incorporar una funcionalidad muy especfica requerida por ALPHATECH que no era parte del plan de desarrollo original . Teniendo en cuenta lo que estaba en juego en el orden ALPHATECH , no haba ms remedio que cometer . Los equipos secundarios ms afectados fueron los que tenan que incorporar la nueva funcionalidad requerida por ALPHATECH . Carbone record : " El envo ALPHATECH pone enorme presin sobre el equipo que fue responsable de la gran instrumento de la fuente de alimentacin se vieron obligados a terminar su pieza en la mitad del tiempo programado originalmente Esto no tiene nada que ver con el proceso Era puro orgullo . . . . La gente all trabajaba semanas de 80 horas . El impacto de la orden ALPHATECH fue profundo. Todo el mundo tom nota de que el tener un "cliente real" con un plazo concreto fue un gran motivador, pero el calendario acelerado interrumpi el proyecto. Mientras que los subsistemas de hardware todos lograron golpear a sus nuevos hitos , el software se redujo an ms tarde. En enero de 2004 , la Alta Direccin ha comprometido 15 ingenieros de software adicionales para el proyecto para contrarrestar el problema . Roush, quien encabez el equipo de software en ese momento , que se refleja en la intensa presin : Llevar adelante la primera fecha de envo al cliente requiere empujar caractersticas por la puerta antes de que estuvieran listos . Tenamos preocupaciones , y los que fueron discutidos , pero el equipo de base de consenso fue que era mejor aceptar un cierto riesgo y aplicar estrictamente el negocio ALPHATECH que a pie. Hubo mucha presin para cumplir el plazo . Nosotros no estbamos siendo intelectualmente honestos acerca de la magnitud de los riesgos y las lecciones de la historia IG- XL en FLEX .

A medida que la fecha lmite se cerr en el equipo de software cambi su esfuerzo casi por completo a la fijacin de los errores y conseguir una pieza aceptable, operativa de software para ALPHATECH . Carbone dijo : "El equipo de software estaba bajo una enorme presin , y que slo se haca cada vez peor a medida que se le escapaba . Los niveles de estrs fueron por las nubes. Haba un montn de desgaste. El hecho de que perdieron muy pocas personas en el camino es un homenaje a Paul [ Roush de ] liderazgo. Ese equipo era increblemente leal a Pablo. Carbone , que haba trabajado tanto en hardware y desarrollo de software durante sus 27 aos en Teradyne , reflexion sobre los desafos que enfrenta el equipo de software : "puertas Cuando usted trabaja con el hardware no se fijan en el proceso ; la primera mesa, el arte, etc. estos son los puntos tangibles, duros en el proceso. Si no se hacen , usted lo sabe. Usted no puede mentirse a s mismo . con el software , es mucho squishier . usted no tiene estos puntos " . Conner pens que los problemas eran mucho ms endmica de la empresa: " . Al Teradyne , tenemos una sensacin intuitiva de lo que los problemas de hardware son No tenemos esa sensacin en el software. " El 30 de marzo de 2004, como se haba prometido , Teradyne enviado el primer sistema completo de ALPHATECH para su evaluacin. AII de los subsistemas de hardware cumple sus especificaciones. El software no ha incorporado todas las caractersticas inicialmente solicitadas por ALPHATECH , y fue cargada con los insectos , pero era funcional. Durante los prximos seis meses, el equipo de software enfocada nicamente en la actualizacin del software y corrigiendo errores para ALPHATECH . Roush seal: " Bsicamente dejamos de hacer el desarrollo en ese punto, y acabamos de trabajar en los errores . " Y Carbone record , "Ellos tuvieron que cambiar al modo de extincin de incendios pura Cualquier sentido de proceso fue por la ventana Ellos ya no estaban haciendo el desarrollo; . . Slo estaban tratando de arreglar errores de ALPHATECH Al final , fueron codificando da -by. das y cargar el software a travs de la Web ALPHATECH " . En junio de 2004 , se agregaron los ingenieros de software adicionales para el proyecto. El intenso esfuerzo vali la pena. En septiembre de 2004 , ALPHATECH seleccionado el sistema de Teradyne . La victoria, sin embargo , lleg con su costo. Gran parte del resto de la urbanizacin - que incluye proyecto de caractersticas para otros clientes - se retras . Adems, el software , completamente consumido por la correccin de errores , cay ms tarde. Ingenieros de software adicionales se aadieron una vez ms con el proyecto . En julio de 2004 , Carbone fue nombrado para dirigir el desarrollo de software restante. "La situacin era un desastre . Las personas estaban quemadas . Tuvimos que aadir 50 ms desarrolladores. Slo utilizamos la fuerza bruta. No fue bonito . Todava estamos excavando . " El desafo de software en el programa de Jaguar result ser ms grande de lo previsto . En diciembre de 2004 , los componentes de hardware de la plataforma " Ultra Flex 1 ", ahora llamado - ya se haban concluido en la fecha prevista , y dos grandes clientes acordaron adquirir el sistema que ahora se llama " Ultra Flex" ( ver Anexo 8 ) . Sin embargo, debido a los retrasos en conseguir el software en lnea, la rampa de volumen de produccin del producto fue expulsado seis meses. Jagiela coment: . " Las primeras indicaciones son que tenemos el producto adecuado para el mercado de puntos de referencia competitivos estn recurriendo a favor del Ultra Flex y tenemos una serie de seguimiento de las adiciones a la plataforma prevista en 2005 para mantener el impulso que empuja . el volumen de rampa a cabo seis meses despus del plan fue una decisin difcil , pero necesaria para madurar el software ms antes de que nos lanzamos a una amplia distribucin . "

Reflexiones sobre el Proyecto

En Teradyne , la salida de un proyecto de desarrollo fue juzgado por dos criterios : en primer lugar , surgi el proyecto logre sus objetivos de destino y , en segundo lugar , lo hizo construir nuevas capacidades organizativas para proyectos futuros? Aunque la mayora de la gente se senta satisfecha con la primera , hubo cierto desacuerdo sobre la segunda cuestin, especialmente en lo que se refera a proyectar herramientas y prcticas de gestin. Algunos directivos consideraron que , en general , las herramientas de gestin de proyectos trabajaron y contribuyeron al xito del proyecto . Sus preocupaciones giraban en torno a la ejecucin . Otros eran mucho menos convencidos del valor de las herramientas , y les preocupaba que en realidad pudiera ser una distraccin . Giebel era un fuerte defensor de la continuacin del uso de herramientas de gestin de proyectos y vio los problemas en gran medida en trminos de un uso inadecuado. Giebel , coment: "Con demasiada frecuencia , los miembros del equipo no saban " cmo obtener valor a partir de las herramientas que utilizaban 'pensando que ' podra haber imaginado lo que estaba mal sin ellos. '' ' Giebel cree que con ms experiencia, y tal vez algn tipo de formacin adicional, este problema se rectificara . O'Brien tambin era un firme creyente en el valor de las herramientas del proyecto . Vio las herramientas como de trabajo , pero fue crtico de s mismo y de los dems miembros de la organizacin para la que no siempre reacciona a los datos. Seal : "Nuestro problema no era la falta de datos , sino que iba a tener los datos fijos en nosotros, y no nos responde. " Carbone , tambin es un creyente en el valor de las herramientas , se mostr de acuerdo con el punto de O'Brien . Al recordar las luchas del equipo de software , Carbone seal : "Las herramientas permitieron que el equipo de software para mentir a s mismos Mantuvieron rejiggering la ruta crtica , poner las cosas en paralelo, la adicin de recursos , etc , para que se ajuste Algunos muy fuerte. . Personas se dejaron engaar por los datos. Jack dej que las mtricas se encuentran con l. El desastre de software fue evidente desde el EV, pero nos ignoraron ( ver Anexo 9 ) . " Simn Longson , jefe del subgrupo Ingeniera Interfaces , que haba estado en Teradyne por cerca de 13 aos al inicio del Jaguar , pensaba que las herramientas habran funcionado mejor si no se hubieran encontrado con una fuerte resistencia : l explic : "La gente se resistieron a la utilizacin beca herramientas te obligan a comprometerse. La gente tiene miedo de cometer en un mundo incierto . Es vergonzoso que estar equivocado . " Rogas tambin pensaba que las herramientas de gestin de proyectos aadidos valor . Mencion, especficamente, su impacto en el esfuerzo ALPHATECH : " Las herramientas que proporciona visibilidad en el proyecto que nunca tenamos Esto nos ha permitido responder a ALPHATECH y estar seguros de que podra golpear a todos los hitos. ". Otros sonaban una nota ms de precaucin . Les preocupaba que un creciente nfasis en la planificacin de proyectos, seguimiento , indicadores e informes pudiera distraer a los miembros del equipo de los problemas reales. Ben Brown, gerente de ingeniera que haba estado en Teradyne durante 21 aos al inicio del proyecto Jaguar , explic : Era natural que con el tiempo algunas personas se volvieran ms preocupadas por la mtrica en s mismo y no de lo que un pobre mtrica les estaba diciendo . Adems, cualquier persona puede hacer cualquier look mtrica bueno. Usted tiene que tener cuidado : la mtrica podra convertirse en el objetivo, para que la gente se centra en la gestin de la mtrica en lugar del proyecto. La gente cae en esta trampa no BECA uso que quieren hacer las cosas mal , sino porque sienten la presin para lograr la mtrica. La gente necesita herramientas, pero , ms importante an , que necesitan la actitud . No creo que las herramientas ms sofisticadas sean necesariamente

mejores . Herramientas hacen mejor las cosas si la gente que usa los acepta y entienden para qu sirven y cmo funcionan.

Mirando hacia el futuro

Como l finalmente sali de su coche, O'Brien estaba pensando lo que an necesita ser mejorado para proyectos futuros. Sus pensamientos seguan recurriendo a las herramientas de gestin de proyectos y cmo se podra mejorar su uso. l no pudo evitar preguntarse si palabras de Wrinn estaban en lo cierto : "Con los mejores posibles procesos , pero con gente incapaz , no pasa nada , pero lo contrario no es verdad con gente capaz y procesos psimo , mucho se puede hacer. . . "

Esto no fue siempre el caso de las metodologas que implementamos . A veces , la herramienta se puso en el camino. Piense en Primavera, por ejemplo. Primavera es una herramienta torpe. La interfaz es terrible. Muchos de los responsables de ingeniera de primera Ievel odiaba. Primavera requiere de una estructura de divisin del trabajo muy esttico, una vez que entras , es muy difcil de modificar . El problema es que a medida que se ejecuta un proyecto como este , en realidad se descubre cosas que tiene que hacer de manera diferente . Pero , el horario se produce y se actualiza utilizando la estructura de desglose del trabajo original. As que el reportado programada se vuelve menos significativa con el tiempo . Algunos grupos tenan una lucha semanal con Primavera. Trabajaron para obtener la fecha de finalizacin horario para salir bien constantemente reordenando la ruta crtica , pero se perdi el hecho de que los entregables en general se le escapa y el trabajo no se iba a hacer en el rateo Valor Ganado planeado es otro buen ejemplo de las herramientas que don 't siempre funcionan bien . Hay cosas que no aparecen en la herramienta de EV. Sabes cuntas horas trabaj , pero usted no sabe cunto queda . Puede avanzar en EV sin avanzar en el proyecto. Brown tom una breve pausa y luego confes : "1. Quera desafiar constantemente a mi gente a pensar en nuevas formas de ejecutar el proyecto dejo que mis personas utilizan Microsoft Project, pero entonces yo tendra mi secretaria escriba sus datos en Primavera por lo que podra informar de esa manera. " Breger tambin se mostr escptico. Le preocupaba que las herramientas estaban conduciendo fuera de algunas de las conductas positivas que fueron fundamentales para el xito : En el pasado, un sitio como Agoura Hills dueo de todo el sistema. Ahora, el desarrollo se extiende por todo severallocations . Esto le da una sensacin muy diferente . Usted no consigue que el sentido de propiedad que impulsa a la gente a venir en los fines de semana . Por primera vez en mi 26 - aos de carrera en Teradyne , no me siento responsable por el xito de todo el proyecto. Me senta responsable de la presentacin de datos . Esto es lo que las herramientas eran buenos en : proporcionar una gran cantidad de datos. La gente se centraba en los datos de seguimiento , pero no siempre se preocuparon por si estaban rastreando los datos correctos . Tambin le preocupa que las herramientas fueron muy fcilmente vistas como un sustituto de la prctica en la gestin de : . "Las herramientas te dicen si llegas tarde , pero usted no debe necesitar una herramienta para decirles que si usted tiene que averiguar a travs de la herramienta , ya es demasiado tarde. Adems, las herramientas no ayudaron a controlar las ms importantes cosas - las cosas inciertas. EV , por ejemplo, funciona muy bien si usted sabe exactamente lo que tiene que hacer . Pero el desarrollo no es as . Hay una gran cantidad de incertidumbre " . Conner tambin estaba preocupado con la posibilidad de sobrecarga de informacin. Relat sus observaciones de las reuniones del equipo central : "La gente se centraban en detalles tanto que no podan ver la imagen completa En general , las herramientas no le ayudan a centrarse en lo que las decisiones de hacer , slo le

proporcionan los datos y detalles sobre . el progreso de las tareas. y la cantidad de datos que proporcionan puede ser abrumador. Dame un horario de 40 pginas, y estoy perdido . "

1. 2. a. b. c. 3. 4. 5.

6. 7. 8.

Preguntas: Cuntas son las reas del conocimiento que distingue en este caso? Justifique MUY BIEN su respuesta. Cul es el enfoque de la Gestin de Proyectos en Teradyne, con respecto a los siguientes tpicos? Desarrollo intensivo y fases de planificacin Estructura integrada del equipo del proyecto Planificacin del proyecto y herramientas de gestin. Con respecto al proyecto Jaguar, cules son las herramientas de gestin propuesta por el lder?, Cmo reaccionaron otros miembros de la organizacin con respecto a esta propuesta? Cmo evaluara el desempeo del proyecto Jaguar? Cul es la explicacin del desastre de software? Refirase a concepto como Informacin, incentivo, compatibilidad del diseo de hardware y software, experiencia y competencia organizacional. Compare y contraste la estrategia de ejecucin de proyectos tradicionales de Teradyne, con el enfoque que utiliza en Jaguar? Qu era similar? Cul fue la diferencia? Qu impacto tuvieron las herramientas de gestin de proyectos en el proyecto Jaguar? Especficamente, cmo cambiaron el comportamiento? Cmo influy en su rendimiento? Cules fueron las consecuencias no deseadas de la utilizacin de las herramientas de gestin de proyectos? Qu lecciones aprendidas debe Teradyne sacar del proyecto Jaguar? Qu le aconsejara a O'Brlen para mejorar la gestin de los proyectos?, cmo deba incoporar lo mencionado por Wrinn?

9.

10. Considerando el PRINCE2, plantee gestin del proyecto Jaguar con esta herramienta. Junto con el desarrollo utilice conceptos y diagramas aplicados.