Teradyne Corporación: El Proyecto Jaguar Jack O'Brien miró el reloj en su coche, que era 7:38 de la mañana y sabía que iba a necesitar un poco de suerte para llegar a las 08 a.m. a una reunión en la sede de Teradyne Harrison Avenue. El tráfico en la arteria central de Boston se asfixió en medio de la persistente construcción del interminable "Big Dig". O'Brien estaba esperando a la reunión de hoy con los altos directivos de Teradyne para reflexionar sobre las lecciones aprendidas del proyecto Jaguar, que O'Brien había dirigido por más de tres años. El proyecto había sido uno de los esfuerzos más importantes en 45 años de historia de Teradyne. Se había propuesto crear una nueva plataforma de sistema de prueba de semiconductores. El sistema Flex Ultra, diseñado 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 había marcado la culminación de este tipo de proyectos, fue un esfuerzo de 8 años para Teradyne para mejorar su proceso de desarrollo de productos. El equipo Jaguar había utilizado una serie de prácticas de gestión de proyectos, incluida la planificación intensiva por adelantado proyectos, herramientas formales para el seguimiento de los avances del proyecto, y un proceso de desarrollo más estructurado. La mayoría de los aspectos del proyecto Jaguar fueron excesivamente bien. El equipo importante, por ejemplo, que el producto se haya desarrollado en un tiempo récord, y con una mínima desviación del plan. El producto había cumplido la gran mayoría de sus especificaciones de destino. Sin embargo, al mismo tiempo, el software, un componente importante del programa, se había quedado gravemente retrasado y todavía no se ha completado. Además, los costos totales de desarrollo han aumentado en un 35 % más de lo presupuestado inicialmente. Mientras que algunos miembros del equipo Jaguar incluyeron las herramientas de gestión 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 información
“
proporcionados por las nuevas herramientas que utilizábamos, hemos sido cap aces de saber si un equipo estaba leseando o sí tenía el trabajo realizado al ritmo adecuado. Por supuesto, se necesita algo más que simples herramientas: Necesita los líderes adecuados en las posiciones correctas, esos líderes están facultados y aquellos líderes que aceptan la responsabilidad ”
y la rendición de cuentas por su pedazo de proyecto.
Pero otros eran más escépticos. George Conner, arquitecto del sistema de Jaguar, pensaba que las herramientas pueden ser una distracción : “
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 programación, usted tiene que especificar la secuencia y estructura de tareas con antelación. Pero este es claro que las herramientas se ponen más complicadas, que gasta más 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 dirección ya comenzarían un proceso de investigación de la historia del proyecto y seleccionando lecciones aprendidas. El resultado del proceso podría afectar la forma en que Teradyne ejecuta los proyectos de desarrollo en los próximos años. A medida que el tráfico avanzó poco a poco, O'Brien se impacientó. Odiaba llegar tarde.
Teradyne y la División 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 más 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 compañeros de clase en el Instituto de Tecnología de Massachusetts (MIT), Teradyne se centraron inicialmente en la fabricación de equipos para probar transistores
y otros componentes electrónicos. Su negocio involucrado una nueva clase de "calidad industrial" en equipos de prueba electrónicos, conocidos por su fiabilidad, velocidad de la prueba, y el rendimiento técnico. Durante los próximos 30 años, se volvió una tarea complejidad ya que el volumen de producción de semiconductores aumentó exponencialmente, Teradyne continuó invirtiendo fuertemente en I+D para mantenerse a la vanguardia de la tecnología de prueba. Durante este tiempo, Teradyne también había diversificado hacia otros mercados de prueba electrónicos relacionados. En 2004, Teradyne organizó cinco principales unidades de negocios - Prueba Semiconductor, Prueba de la Asamblea, de Prueba de Banda Ancha, Sistemas de Conexión, y de Soluciones de diagnósticos- por los productos que elaboran y entregan. Prueba Semiconductor fue la unidad de negocios más grande de la sociedad, la cual entrega el 64 % de los ingresos totales de la compañía en 2004. La unidad de prueba de semiconductores tuvo importantes operaciones de ingeniería ubicada 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 alojan las operaciones de fabricación de la empresa. La fabricación interna de la empresa se centró en el montaje final y la prueba (subsistemas y componentes fueron subcontratadas). Además, la compañía contaba con organizaciones de ventas y de ingeniería más pequeños dispersos en sus principales mercados mundiales, incluyendo Japón, Chi na y Alemania.
Tecnología de Ensayos Semiconductor Los semiconductores abarcaron una amplia gama de tipos de dispositivos, que se redujo en dos categorías: (1) la Memoria, y (2) el sistema operativo en un chip (SOC). El SOC incluye microprocesadores (Iogic), procesadores analógicos, procesos de señales mixtas digitales (que combinan circuitos digitales y analógicos), dispositivos especializados para gráficos y sonido, y los circuitos integrados personalizados. Cada tipo de dispositivo realiza un trabajo diferente en un sistema electrónico. Con independencia de su finalidad, los semiconductores eran dispositivos de alta precisión que realizaron manipulaciones complejas de señales electrónicas. La capacidad de un dispositivo para llevar a cabo su función depende de su diseño, todo está en su fabricación. Incluso el defecto de menor importancia en el proceso de producción (por ejemplo, una pieza errante de polvo, o una pequeña desviación en la especificación) podría impedir que un dispositivo funcione correctamente. El trabajo de un probador de semiconductores fue determinar si un chip cumplía o no las especificaciones de destino. Para hacer esto, el probador esencialmente examinó el dispositivo electrónicamente (envió señales y, a continuación, realizó una medición de la respuesta). Esta tarea aparentemente sencilla era, en realidad, uno de los problemas más difíciles en toda la industria de la electrónica. Para trabajar como se especifica, un semiconductor tenía que ser capaz de realizar una amplia gama de operaciones con otros componentes de un sistema electrónico. 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 tenía que simular los entornos de los sistemas electrónicos en los que podría utilizarse el dispositivo. Como los dispositivos BECA me cada vez más complejo y preciso, este desafío se incrementó de forma exponencial. Los precios de los sistemas de Teradyne podrían alcanzar los $ 3 millones o más .
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 líderes 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 cíclico. 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 transición a una nueva generación de tecnología de pruebas cuya requisitos no pudieron satisfacerse con el equipo existente . Dada la tasa rápida históricamente de la innovación tecnológica en los semiconductores, esto hizo imperioso para las empresas de equipos de prueba a una fuerte inversión 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 formación. Por lo tanto, una vez que una empresa tester "ganó una cuenta, " era difícil 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 técnicas y características: ¿el equipo podría probar su dispositivo? También se centraron en gran medida en la economía 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 producción de semiconductores , y que los márgenes en muchos segmentos del negocio de los semiconductores eran relativamente bajos . La fiabilidad fue también una demanda cada vez más 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 técnico rápido se consideró esencial para competir en este mercado.
Teradyne Cultura Teradyne conserva la fuerte cultura de ingeniería que había 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 técnica. Vestido era informal . Oficinas eran cubículos , incluso para la mayoría de los altos ejecutivos de la compañía. 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 compañía tuvo un buen resultado en la contratación de ingenieros de las mejores escuelas como el MIT y retener este talento durante varios años. La mayoría de los altos ejecutivos de la compañía habían pasado la mayor parte de sus carreras con Teradyne . Un hito importante en la evolución de la empresa se produjo en la década de 1990 , cuando el entonces CEO Alex D' Arbeloff decidió transformar la forma en que la empresa opera a través de la puesta en marcha de una "gestión de calidad total" (TQM ) programo En ese momento, D' Arbeloff era cada vez más 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 básicos de funcionamiento de la empresa no estaban bajo control. Su actuación no había sido medido , y no había ningún esfuerzo sistemático para mejorar esos procesos. Para corregir esta deficiencia, D' Arbeloff abrazó TQM ( Total Quality Management ) , un conjunto de principies , filosofías y prácticas que hizo hincapié en la vigilancia permanente y la mejora de los procesos de una organización. Un intenso periodo de formación 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 metodologías de la GCT , principies y prácticas 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 resolución de problemas , análisis de causa raíz , y diagramas de espina de pescado en la comunicación y discusión de los problemas de gestión . A mediados de la década de 1990 , tras cinco años de intenso esfuerzo , Teradyne había incrustado TQM en la mayoría de los aspectos del trabajo en la empresa. Y , lo más importante , los resultados en la mayoría de los aspectos de las operaciones - tales de la compañía como la calidad de fabricación y de servicio al cliente mejorado de forma espectacular.
Desarrollo de Productos en Teradyne Cuando se inició la GCT , D' Arbeloff había esperado que sería transformar la organización de ingeniería también. Por desgracia , en 1996 , estaba claro que la ACT no se está afianzando en la ingeniería, 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 resolución de problemas , y vieron la GCT como una intromisión 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 años . Liderazgo senior de ingeniería de la compañía de varias divisiones se ensambla en un Equipo de Mejora de Procesos de Ingeniería ( 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 categorías. En primer lugar, las organizaciones de ingeniería en toda la compañía se vieron gravemente sobreasignadas en proyectos ( utilización de la capacidad se estima en tan alto como 300 %). Para abordar este problema, la empresa puso en marcha un proceso de planificación de la capacidad del proyecto más estructurado y riguroso conocida como Planificación de Proyectos Aggregate (APP ) . Había 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 sólo comenzar proyectos cuando los recursos adecuados y apropiados están disponibles. Mientras que una herramienta aparentemente simple de usar, la APP requiere una gran cantidad de cam bio de conducta y disciplina. El segundo problema en Teradyne relacionado con la ejecución de los distintos proyectos . Los proyectos fueron mal planeados . Los objetivos y el alcance a menudo no están claramente definidos desde el principio y , como resultado , los proyectos tienden a expandirse a medida que los ingenieros y los comercializadores pensado características adicionales. Hitos no estaban bien definidos , y con frecuencia se perdieron . Project programa fueron puestas juntas con poco rigor . Debido a que no existía un método sistemático para el seguimiento de los avances del proyecto , que fue difícil para la alta dirección para saber cuándo hay que intervenir a menos que aparecieron grandes problemas . Por último , ya que los proyectos fueron manejados por las funciones de ingeniería individuales y no había una sola persona responsable de todo el proyecto, hubo retrasos significativos y problemas de calidad causados por fallos de coordinación y comunicación . Para hacer frente a este segundo problema, la compañía puso en marcha varias iniciativas de mejora. Uno de ellos fue la creación de un modelo de "fase -gate" para proyectos de desarrollo . ( Ver Anexo 2 para más detalles sobre el modelo de eliminación de la puerta de Teradyne , . Ver Anexo 3 para la Ejecución del Proyecto Matriz 1de estrategia desarrollado para el proyecto Jaguar ) El propósito del modelo de eliminación de la puerta era proporcionar bien definido hitos y puntos de revisión . La segunda iniciativa fue la implementación de herramientas de gestión de proyectos diseñados 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 descripción de las herramientas de gestión de proyectos . ) Por último, en consonancia con la filosofía de la mejora continua de Teradyne , una revisión estructurada " después de la acción " se recomienda después de la finalización de todos los proyectos de desarrollo. Estas revisiones deberán 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 específica , se deja a las divisiones y los administradores individuales para decidir qué recomendaciones a seguir. Algunas divisiones de la compañía rápidamente adoptaron el enfoque , mientras que otros parecían resistir o simplemente ignorarlos. Este último era a menudo una fuente de tensión en las reuniones mensuales Epit donde se esperaba que 1
La matriz de la estrategia de ejecución del proyecto (PESM) sirvió de marco para la creación de conocimiento y control común,
bien ejecutada crítica.
los gerentes de ingeniería 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 planificación más detallada del proyecto, y llevaron a cabo rigurosas revisiones posteriores a la acción , mientras que otros no lo hicieron. Rogas creció cada vez más frustrado con lo que vio como un comportamiento " pasivo-agresivo " . Más preocupante para Rogas fue la falta de un cambio de comportamiento . Lamentó : . . "Algunas personas estaban pasando por los movimientos de la utilización de las herramientas , pero no eran realmente cambiar sus comportamientos Todavía estaban exceso de la comisión Todavía estaban dar con horarios poco realistas. No estaban siendo intelectualmente honestos " .
Una nueva estrategia y una nueva estructura Históricamente , Teradyne y otros proveedores de equipos de prueba diseñadas completamente diferentes sistemas de ensayo para cada tipo de dispositivo semiconductor (memoria , digital / lógica , la analogía , la mezcla de señal , etc.) La ventaja de este enfoque es que permite el diseño 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) , lógica ( ETV ), de señal mixta (CIE) , microcontroladores (ITD) , y el sistema en un chip (SOC ) . A mediados de la década de 1990 , los cambios en el mercado comenzaron a erosionar la lógica de esta estrategia. En particular, como los fabricantes de semiconductores se diversificaron en una gama más amplia de tipos de dispositivos , que pedían cada vez más m ás para un plattorm probador que podría po dría probar múltiples tipos de dispositivos. d ispositivos. Esta tendencia se aceleró a finales de la década 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 utilización de los probadores de dispositivos específicos eran demasiado bajos para ser económicamente viable. Mientras Teradyne había ofrecido previamente probadores flexibles en el extremo rendimiento bajo / medio del mercado de prueba del dispositivo , Teradyne no tenía un plattorm con el rendimiento necesario para hacer frente a la totalidad del mercado . Como Joe Wrinn , vicepresidente de la Plataforma de Ingeniería, explicó: " A finales de 1990 , estaba claro que esta estrategia no estaba funcionando Las plataformas fueron cada vez más complicado y costoso para desarrollar Era cada vez más factible para desarrollar múltiples plataformas. . . " Varios de los competidores de Teradyne habían comenzado a desarrollar una plataforma única probador a finales de la década de 1990 . Marcos Jagiela , jefe de marketing de sistemas de pruebas de semiconductores , recordó : Teradyne había estado sirviendo el mercado de bien con una variedad de productos optimizados en sintonía con las necesidades de los distintos causado cierta frustración, ya que el equipo estaba ansioso por empezar a moverse en la ingeniería 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 c erteza 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 experimentación en Fase 111. Puede ser que sea el único con esta perspectiva, pero creo que la fase 11 debe limitarse a la identificación 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 dirección con una presentación de 75 páginas que detalla la arquitectura propuesta del sistema , el diseño y las e specificaciones funcionales de los subsistemas críticos
, las especificaciones de rendimiento objetivo, y el plan de ejecución 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 tamaño de la Jaguar requiere la elaboración de recursos de ingeniería y talento de múltiples sitios, incluyendo Boston, Agoura Hills, San José (CA), Minneapoliss y Portland. Para garantizar los niveles adecuados de integración a través de los diferente Minneapoli diferentess sitios y equipos secundarios, un " equipo básico " se formó a partir de los líderes de cada uno de los equipos del subsistema. El equipo básico incluye también 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 técnicas y organizacionales críticos. 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 veteranos de Teradyne. Como O'Brien comentó: " El proyecto comenzó con una mezcla de lo que necesitábamos, y que estaba disponible Conforme pasó el tiempo, la organización se ha actualizado continuamente a medida que el talento beca me disponible La actualización más notable tanto en el talento y la carne de capacidad cuando Teradyne. Decidió salir del negocio de la memoria, lo que puso a disposición de varios líderes, así como cerca de 60 ingenieros”. La parte de ingeniería del equipo central de todo reportado en O'Brien. La gente en el equipo central sabía que eran responsables ante él por los resultados. Giebel, que acababa de comenzar a trabajar para O'Brien en el inicio del proyecto Jaguar, señaló: " Jack puede ser muy intenso en estas reuniones Si su parte del proyecto era tarde, que quería saber por qué, y que le. Mejor que tengas una buena explicación. Él fue estupendo en la perforación hasta causas profundas. Pero podría hacer que algunas personas se sientan incómodas. No dio mucha seguridad s eguridad psicológica. Carbone, quien también había trabajado en estrecha colaboración con Jack por muchos años, señaló: " 1 no encontró Jack estresante que trabajar para todas las gerentes de Teradyne, lo encuentro el más fácil de trabajar foro Está muerto honesto Y él es un... gran pensador estratégico”. Incluso aquellos que pensaban a veces O'Brien podría ser duras quedaron impresionado con la capacidad de O'Brien para pastorear un proyecto tan complejo a través del desarrollo bajo una intensa presión. En palabras de Peter Breger, gerente de Ingeniería de Hardware Jaguar : " No había nadie mejor en esta organización para sacar un proyecto como este que Jack. "
Herramientas de Gestión de Proyectos y Procesos Uno de los elementos críticos de la estrategia de ejecución del proyecto Jaguar fue el uso de herramientas de gestión de proyectos formales , incluyendo: • Estructura de desglose de trabajo , una descripción detallada de todas las tareas necesarias para completar un
proyecto y su relación entre sí. • Estimación de 3 puntos , una técnica para estimar el mínimo ( mejor de l os casos ) , máximo ( peor de los casos ) , y los
tiempos de espera necesarios para completar cada tarea. • Análisis del camino crítico , 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) .
• Análisis del valor ganado , un método para medir el progreso del proyecto mediante la comparación 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 análisis de la ruta crítica , las estructuras de desglose de trabajo , estimación de 3 puntos , el análisis del valor ganado , y un programa de planificación del proyecto denominado Primavera La mezcla nos ayudó a ver diferentes cosas que estaban pasando pasando . . tamaño no sirve para todos " . O'Brien estaba convencido de que estas metodologías proporcionarían un robusto medios para comunicar el estado del proyecto a la gestión, y para identificar los temas críticos ( tales como los retrasos potenciales) que requerían acción o apoyo de la alta gerencia. Para facilitar el uso de las herramientas en el proyecto , una función separada " gestión 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 gestión de proyectos y que fueron analizados y disponibles para el equipo los datos pertinentes sobre el progreso del proyecto , la programación y la ruta crítica. Como un miembro del equipo describió, Giebel era al modo responsable de " mantener al equipo honesto. " Cada subgrupo tiene su propio director del programa también. 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 programación maestra basada en la web llamada primavera , lo que podría 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 físicos 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 diseñado y construido. construido. En el software , usted no tiene estas limitaciones físicas. En general, usted puede hacer las tareas en casi cualquier orden. Esto le da mucha más flexibilidad ( como ejecutar ) para shuftle gente alrededor para diferentes tareas , y para cambiar incluso el orden de las tareas . La relación 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 identificar la ruta crítica ( 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 Identificación 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 fácil en absoluto, ya que fuimos 10 capas de profundidad en el reporto CP De esta manera , la mayoría de las áreas del proyecto se mantuvieron visible. En la creación de la programación 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 más probable y el pesimista. Corrimos el proyecto contra las duraciones " más 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 montón de tensión 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, independientement independientementee de los retrasos re trasos de las tareas individuales . O'Brien reflexionó:
" Aun estando nosotros constantemente de retraso con respecto a lo que esperamos, nunca cambiamos el punto final Queríamos mantener lo que me tensión en el proceso. ". En la práctica, esto significaba que el equipo tuvo que ser flexibles para responder a los retrasos , especialmente las relativas a los elementos de la ruta crítica . En las reuniones mensuales del equipo central , se toman las decisiones de reasignar recursos a aquellas partes del proyecto que habían sufrido retrasos . Los recursos adicionales también fueron puestos a disposición 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 dirección no reparó en gastos para asegurarse de que el proyecto no se retrasaría . " Una de las áreas clave de la gestión de la atención fue el desarrollo de los cinco circuitos integrados de aplicación específica (ASIC) que formaban el núcleo del sistema . Estos ASICs fueron a la vanguardia en términos de complejidad , sofisticación y costo. En proyectos anteriores , problemas con el desarrollo ASIC habían sido una fuente importante de retrasos de tiempo (por lo general de seis meses a un año) . En particular , el descubrimiento de problemas de diseño 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 simulación y otras metodologías de ensayo temprano en el ciclo de desarrollo . Wrinn comentó, " históricamente , en el desarrollo de ASIC , vamos a pasar la may or parte de nuestros recursos en el desarrollo y muy pocos en la prueba . El Jaguar revocamos la relación . " Este planteamiento dio sus frutos, ya que prácticamente todos los ASICs se terminaron a tiempo y sin may ores problemas de diseño . 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 línea 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 había 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 línea de productos FLEX existentes y de fijación, el desarrollo del software Jaguar tuvo que ser atendido principalmente de Agoura . Paul Roush, quien encabezó este esfuerzo, señaló que esto causó ciertos problemas desde el principio : La mayoría de los desarrolladores en Jaguar nunca habían trabajado con IG- XL antes. Unos pocos habían limitado la familiaridad con la generación anterior de IG- XL . Los expertos en la plataforma IG- XL se encuentran en Boston y se centraron en la ampliación y la fijación de la base de código FLEX . Estos expertos tuvieron poco tiempo para gastar en el desarrollo de Jaguar . En ese momento la prioridad de la compañía estaba en FLEX , con frecuentes declaraciones en el sentido de que : "Si FLEX no tiene éxito, no habrá ningún 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 métricas del proyecto indican un problema. Por ejemplo, para el primer año 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 sólo la mitad de las tareas que se habían previsto en un principio . Kevin Giebel señaló : "Software estaba en negación Siguieron diciendo que ponerse al día. ". Cuando se le preguntó por qué el equipo central de gestión oa la alta dirección no intervinieron , Giebel reflexionó, "Una de las razones fue que el equipo directivo no prestó suficiente atención a los datos debido a su escepticismo en torno a la métrica. " Conner añadió: " El problema del software surgió gradualmente. Simplemente no lo vimos hasta muy tarde , pero todos sabíamos 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 administración superior vio esto como un golpe potencial grave para todo el programa. Tamaño de ALPHATECH , y su estatura en el mercado, hecho que su elección tení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 una idea que íbamos a tomar a la ligera . Nuestro equipo de desarrollo tenía que hacerlo, y no , llegar totalmente detrás 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 evaluación hasta junio de 2004, casi 10 meses de distancia. Mientras tanto , el sistema del competidor ya se completó y en laboratorios de evaluación de ALPHATECH . Rogas , que había trabajado en estrecha colaboración con ALPHATECH durante más de 20 años, comentó: Tuvimos que convencer ALPHATECH que debían esperar para nosotros y para superar su escepticismo. Sabían por experiencia que cuando fijamos una fecha por lo general, no llevamos bien . Esta vez, la única oportunidad que teníamos era dar en el blanco con exactitud. Todos nos llamamos todos los que conocíamos a ALPHATECH -la gente que habíamos trabajado durante años - y les pedimos que nos dé una oportunidad. ALPHATECH decidió dar Teradyne la oportunidad de pujar por el negocio , pero dejó claro que tendrían que tener un sistema listo para el 30 de marzo de 2004, y que iba a tolerar ningún desfase en el calendario . Teradyne comprometido con un programa detallado , con reseñas mensuales con la gestión ALPHATECH previos a la fecha de 30 de marzo de buques. Teradyne no se permitiría perder ni un solo jalón. Además, ahora tenía que incorporar una funcionalidad muy específica 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 había más remedio que cometer . Los equipos secundarios más afectados fueron los que tenían que incorporar la nueva funcionalidad requerida por ALPHATECH . Carbone recordó : " El envío ALPHATECH pone enorme presión sobre el equipo que fue responsable de la gran instrumento de la fuente de alimentación 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 aún más tarde. En enero de 2004 , la Alta Dirección 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 presión : Llevar adelante la primera fecha de envío al cliente requiere empujar características por la puerta antes de que estuvieran listos . Teníamos 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 presión para cumplir el plazo . Nosotros no estábamos 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 límite se cerró en el equipo de software cambió su esfuerzo casi por completo a la fijación de los errores y conseguir una pieza aceptable, operativa de software para ALPHATECH ALPHA TECH . Carbone dijo : "El equipo de software estaba bajo una enorme presión , y que sólo se hacía cada vez peor a medida que se le escapaba . Los niveles de estrés fueron por las nubes. Había un montón de desgaste. El hecho de que perdieron muy pocas personas en el camino es un homenaje a Paul [ Roush de ] liderazgo. Ese equipo era increíblemente leal a Pablo. Carbone , que había trabajado tanto en hardware y desarrollo de software durante sus 27 años en Teradyne , reflexionó sobre los desafíos 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 más endémica de la empresa: " . Al Teradyne , tenemos una sensación intuitiva de lo que los problemas de hardware son No tenemos esa sensación en el software. " El 30 de marzo de 2004, como se había prometido , Teradyne enviado el primer sistema completo de ALPHATECH para su evaluación. AII de los subsistemas de hardware cumple sus especificaciones. El software no ha incorporado todas las características inicialmente solicitadas por ALPHATECH , y fue cargada con los insectos , pero era funcional. Durante los próximos seis meses, el equipo de software enfocada únicamente en la actualización del software y corrigiendo errores para ALPH ATECH . Roush señaló: " Básicamente 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 extinción de incendios pura Cualquier sentido de proceso fue por la ventana Ellos ya no estaban haciendo el desarrollo; . . Sólo estaban tratando de arreglar errores de ALPHATECH ALPHA TECH Al final , fueron codificando día -by. días y cargar el software a través de la Web ALPHATECH ALPH ATECH " . 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 urbanización - que incluye proyecto de características para otros clientes - se retrasó . Además, el software , completamente consumido por la corrección de errores , cayó más tarde. Ingenieros de software adicionales se añadieron una vez más con el proyecto . En julio de 2004 , Carbone fue nombrado para dirigir el desarrollo de software restante. "La situación era un desastre . Las personas estaban quemadas . Tuvimos que añadir 50 más desarrolladores. Sólo utilizamos la fuerza bruta. No fue bonito . Todavía estamos excavando . " El desafío de software en el programa de Jaguar resultó ser más grande de lo previsto . En diciembre de 2004 , los componentes de hardware de la plataforma " Ultra Flex 1 ", ahora llamado - ya se habían 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 línea, la rampa de volumen de producción 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 están 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 después del plan fue una decisión difícil , pero necesaria para madurar el software más a ntes de que nos lanzamos a una amplia distribución . "
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 mayoría de la gente se sentía satisfecha con la primera , hubo cierto desacuerdo sobre la segunda cuestión, especialmente en lo que se refería a proyectar herramientas y prácticas de gestión. Algunos directivos consideraron que , en general , las herramientas de gestión de proyectos trabajaron y contribuyeron al éxito del proyecto . Sus preocupaciones giraban en torno a la ejecución . Otros eran mucho menos convencidos del valor de las herramientas , y les preocupaba que en realidad pudiera ser una distracción . Giebel era un fuerte defensor de la continuación del uso de herramientas de gestión de proyectos y vio los problemas en gran medida en términos de un uso inadecuado. Giebel , comentó: "Con demasiada frecuencia , los miembros del equipo no sabían " cómo obtener valor a partir de las herramientas que utilizaban 'pensando que ' podría haber imaginado lo que estaba mal sin ellos. '' ' Giebel cree que con más experiencia, y tal vez algún tipo de formación adicional, este problema se rectificaría . O'Brien también era un firme creyente en el valor de las herramientas del proyecto . Vio las herramientas como de trabajo , pero fue crítico de sí mismo y de los demás miembros de la organización para la que no siempre reacciona a los datos. Señaló : "Nuestro problema no era la falta de datos , sino que iba a tener los datos fijos en nosotros, y no nos responde. " Carbone , también 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 señaló : "Las herramientas permitieron que el equipo de software para mentir a sí mismos Mantuvieron rejiggering la ruta crítica , poner las cosas en paralelo, la adición de recursos , etc , para que se ajuste Algunos muy fuerte. . Personas se dejaron engañar por los datos. Jack dejó que las métricas se encuentran con él. El desastre de software fue evidente desde el EV, pero nos ignoraron ( ver Anexo 9 ) . " Simón Longson , jefe del subgrupo Ingeniería Interfaces , que había estado en Teradyne por cerca de 13 años al inicio del Jaguar , pensaba que las herramientas habrían funcionado mejor si no se hubieran encontrado con una fuerte resistencia : Él explicó : "La gente se resistieron a la utilización beca herramientas te obligan a comprometerse. La gente tiene miedo de cometer en un mundo incierto . Es vergonzoso que estar equivocado . " Rogas también pensaba que las herramientas de gestión de proyectos añadidos valor . Mencionó, específicamente, su impacto en el esfuerzo ALPHATECH : " Las herramientas que proporciona visibilidad en el proyecto que nunca teníamos Esto nos ha permitido responder a ALPHATECH y estar seguros de que podría golpear a todos los hitos. ". Otros sonaban una nota más de precaución . Les preocupaba que un creciente énfasis en la planificación de proyectos, seguimiento , indicadores e informes pudiera 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 inicio del proyecto Jaguar , explicó : Era natural que con el tiempo algunas personas se volvieran más preocupadas por la métrica en sí mismo y no de lo que un pobre métrica les estaba diciendo . Además, cualquier persona puede hacer cualquier look métrica bueno. Usted tiene que tener cuidado : la métrica podría convertirse en el objetivo, para que la gente se centra en la gestión de la métrica en lugar del proyecto. La gente cae en esta trampa no BECA uso que quieren hacer las cosas mal , sino porque sienten la presión para lograr la métrica. La gente necesita herramientas, pero , más importante aún , que necesitan la actitud . No creo que las herramientas más sofisticadas sean necesariamente
mejores . Herramientas hacen mejor las cosas si la gente que usa los acepta y entienden para qué sirven y cómo funcionan.
Mirando hacia el futuro Como él finalmente salió de su coche, O'Brien estaba pensando lo que aún necesita ser mejorado para proyectos futuros. Sus pensamientos seguían recurriendo a las herramientas de gestión de proyectos y cómo se podría 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 pésimo , mucho se puede hacer. . . "
Esto no fue siempre el caso de las metodologías 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 ingeniería de primera Ievel odiaba. Primavera requiere de una estructura de división del trabajo muy estático, una vez que entras , es muy difícil 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 s e actualiza utilizando utilizando la estructura de desglose del trabajo original. Así que el reportado programada se vuelve menos significativa con el tiempo . Algunos grupos tenían una lucha semanal con Primavera. Trabajaron Trabajaron para obtener la fecha de finaliza finalización ción horario para salir bien constantemente reordenando la ruta crítica , 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 cuántas horas trabajó , pero usted no sabe cuánto queda . Puede avanzar en EV sin avanzar en el proyecto. Brown tomó una breve pausa y luego confesó : "1. Quería desafiar constantemente a mi gente a pensar en nuevas formas de ejecutar el proyecto dejo que mis personas utilizan Microsoft Project, pero entonces yo tendría mi secretaria escriba escriba sus datos en Primavera por lo que podría informar de esa manera. " Breger también se mostró escéptico. 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 dueño de todo el sistema. Ahora, el desarrollo se extiende por todo severallocations . Esto le da una sensación 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 - años de carrera en Teradyne , no me siento responsable por el éxito de todo el proyecto. Me sentía responsable de la presentación 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 . También le preocupa que las herramientas fueron muy fácilmente vistas como un sustituto de la práctica en la gestión de : . "Las herramientas te dicen si llegas tarde , pero usted no debe necesitar una herramienta para decirles que si usted tiene que averiguar a través de la herramienta , ya es demasiado tarde. Además, las herramientas no ayudaron a controlar las más 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 también estaba preocupado con la posibilidad de sobrecarga de información. Relató sus observaciones de las reuniones del equipo central : "La gente se centraban en detalles tanto que no podían ver la imagen completa En general , las herramientas no le ayudan a centrarse en lo que las decisiones de hacer , sólo 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 páginas, y estoy perdido . "
1. 2. a. b. c. 3. 4. 5.
6. 7. 8.
9.
Preguntas: ¿Cuántas son las áreas del conoc imiento que distingue en este caso? Justifique MUY BIEN su respuesta. respuesta. ¿Cuál es el enfoque de la Gestión de Proyectos en Teradyne, con respecto a los siguientes tópicos? Desarrollo intensivo y fases de planificac ión Estructura integrada del equipo del proyecto Planificación del proyecto y herramientas de gestión . Con respecto al proyecto Jaguar , ¿cuáles son las herramientas de gestión propuesta por el líder?, ¿Cómo reaccionaron otros miembros de la organización con respecto a esta propuesta? ¿Cómo evaluaría el desempeño del proyecto Jaguar? ¿Cuál es la expli expl icación del desastre de software? Refiérase a concepto como Info rmación, incentivo, incentivo, compatibilidad del diseño de hardware y software , experiencia y competencia organizacional. Compare y contraste la estrategia de ejecución de proyectos tradicionales de Teradyne, con el enfoque que utili za en Jaguar? ¿Qué era similar? ¿Cuál fue la di d iferencia? ¿Qué impacto tuvieron las herramientas de gestión de proyectos en el p royecto Jaguar? Específicamente, ¿cómo cambiaron el comportamiento? ¿Cómo influyó en su rendimiento? ¿Cuáles fueron las consecuencias no deseadas de la utilización de las herramientas de gestión de proyectos? ¿Qué lecciones aprendidas debe Teradyne sacar del proyecto Jaguar?
¿Qué le aconsejaría a O'Brlen para mejorar la gestión de los pr oyectos? , ¿cómo debía incoporar lo mencionado por Wrinn?
10. Considerando el PRINCE2, plantee gestión del proyecto Jaguar con esta herramienta. Junto con el desarrollo utilice conceptos y diagramas aplicados. aplicados .
