Sacar el máximo provecho de su proceso de desarrollo de productos

La gestión de procesos ha revolucionado la fabricación. Las empresas de todo el mundo han reducido los tiempos de ciclo en sus fábricas estudiando cada paso del proceso de fabricación y las fluctuaciones de las cargas de trabajo para reducir la variación y eliminar los cuellos de botella. El proceso de desarrollo del producto se puede simplificar prácticamente de la misma manera.

De hecho, sostenemos que los directores generales que necesitan saber cuántos proyectos pueden gestionar sus organizaciones de desarrollo y con qué rapidez esos proyectos pueden lanzar nuevos productos al mercado deben pensar en términos de gestión de un proceso. Sin embargo, la mayoría de los directores piensan en el desarrollo de productos simplemente como una lista de proyectos y no como una operación compleja con una capacidad y una carga de trabajo determinadas.

La reacción inicial de muchos directivos ante la sugerencia de que el desarrollo de productos podría beneficiarse de un enfoque de gestión de procesos es: «El desarrollo de productos no es fabricación. Se trata principalmente de un trabajo de conocimiento. Las tareas no son ni de lejos tan repetibles como en la fabricación, y estandarizar el trabajo acabaría con la creatividad». Sí y no. Cada proyecto de desarrollo implica desafíos únicos que requieren soluciones únicas. Pero hay mucho trabajo en el desarrollo de productos y en muchos otros tipos de trabajo de conocimiento que no es único. Muchas tareas y secuencias de tareas son las mismas en todos los proyectos. La gestión de procesos aprovecha esas similitudes mediante la estandarización y la mejora continua, sin destruir la creatividad.

Durante los últimos ocho años, hemos estudiado una docena de empresas que han empezado a aplicar la gestión de procesos al desarrollo de productos, incluidas Raychem, Motorola, Harley-Davidson, Hewlett-Packard, General Electric, AT&T, Ford, General Motors y NEC. Estos pioneros han hecho tres descubrimientos. En primer lugar, los proyectos se llevan a cabo más rápido si la organización contrata menos a la vez. En segundo lugar, las inversiones para aliviar los cuellos de botella generan beneficios desproporcionadamente grandes en el tiempo de comercialización. En tercer lugar, al eliminar las variaciones innecesarias en las cargas de trabajo y los procesos de trabajo, se eliminan las distracciones y los retrasos, lo que permite a la organización centrarse en las partes creativas de la tarea. El resultado: las unidades de negocio que adoptaron este enfoque redujeron sus tiempos medios de desarrollo entre un 30 y un 50%.

La gestión de procesos es una forma particularmente eficaz de reducir la congestión que afecta a las organizaciones que emprenden muchos proyectos a la vez y comparten personal y equipo en esos proyectos. Sin embargo, el enfoque típico de gestión de proyectos para el desarrollo de productos oculta el proceso general. Tenga en cuenta la experiencia de un importante fabricante de equipos informáticos que estudiamos. Para minimizar el número de iteraciones, o ciclos de reelaboración, en los proyectos de desarrollo, la dirección había creado equipos multifuncionales de ingeniería simultánea para identificar y resolver los problemas de forma rápida y temprana. Pero la organización de desarrollo abordó tantos proyectos al mismo tiempo que personas clave de ingeniería, marketing y fabricación se encontraron trabajando en cinco o incluso diez proyectos a la vez. Para empeorar las cosas, los directores de proyectos trataron de forzar sus propios proyectos consumiendo recursos, lo que retrasó aún más otros proyectos. Como resultado, las personas fundamentales de la organización de desarrollo no pudieron hacer malabares con las numerosas exigencias a pesar de la semana laboral de 60 horas y la mayoría de los proyectos se retrasaron.

Para evitar estos atascos, un gran fabricante de componentes electrónicos fue más allá de crear equipos multifuncionales y elaboró un plan global para todos los proyectos de desarrollo. El plan clasificaba los proyectos propuestos según su importancia estratégica, teniendo en cuenta la naturaleza de cada proyecto (avance, plataforma, derivado) y una estimación aproximada de los recursos que cada uno necesitaría. La empresa utilizó este análisis para reducir y centrar su cartera de proyectos. Sin embargo, la mayoría de los proyectos seguían ejecutándose con meses de retraso y el plan no ayudaba a los directores a entender por qué: en cada fase del desarrollo, los ingenieros tenían que esperar a que los técnicos de soporte realizaran las pruebas críticas de los prototipos. Aunque había suficientes técnicos para soportar la carga de trabajo media, las cargas de trabajo reales eran desiguales y, como resultado, los técnicos solían tener muchos atrasos.

Un plan de proyecto global es una herramienta valiosa para eliminar proyectos marginales y centrar los esfuerzos de desarrollo de la empresa en las prioridades estratégicas. Un plan de este tipo también puede ayudar a garantizar que la organización no asuma más proyectos de los que puede completar, un problema sorprendentemente común. (Consulte Steven C. Wheelwright y Kim B. Clark, «Creating Project Plans to Focus Product Development», HBR, marzo-abril de 1992.) Pero los planes de los proyectos son solo un primer paso hacia un desarrollo más rápido. Para dar el siguiente paso, mucho más grande, los gerentes tienen que pensar en el desarrollo de productos como un proceso de producción en el que los proyectos pasan por el equivalente de conocimiento y trabajo de un taller de trabajo. Esta visión del proceso ayuda a los gerentes a identificar y resolver los problemas de congestión causados por los desajustes entre la carga de trabajo de cada subunidad de la organización de desarrollo y su capacidad para gestionar esa carga de trabajo.

Una visión del proceso también puede ayudar a los gerentes a eliminar la excesiva variabilidad de las cargas de trabajo, otra de las causas de congestión. Las cargas de trabajo variables suelen surgir porque una organización emprende nuevos proyectos cada vez que se presentan buenas oportunidades técnicas o de mercado. Como resultado, en algunos meses se inician muchos proyectos y, en otros, ninguno, un patrón que puede crear cuellos de botella en puntos cruciales del proceso de desarrollo. Hemos visto casos en los que los directores pensaban que estaban siendo prudentes cuando el número de proyectos que habían asignado a la organización de desarrollo exigía que funcionara alrededor del 90% de su capacidad. Sin embargo, si hubieran analizado más de cerca la variación de la carga de trabajo total, habrían descubierto que detrás de esta media anual hay fluctuaciones semanales que oscilan entre el 80 y el 150%. Si esos directores hubieran reducido su tasa de utilización media prevista al 80%, podrían haber reducido los tiempos de desarrollo en un 30% o más.

Por último, un enfoque de gestión de procesos puede ayudar a reducir la variabilidad en la forma en que se ejecutan tareas específicas. Los beneficios de eliminar los ciclos de retrabajo y los pasos anormalmente largos suelen ser desproporcionadamente grandes, ya que esas fuentes de variabilidad retrasan no solo el proyecto en cuestión sino todos los proyectos en marcha.

Algunas organizaciones de desarrollo tratan de evitar la congestión confiando en equipos de proyectos autónomos o dedicados, cada uno de los cuales trabaja en un proyecto a la vez y tiene todos los recursos que necesita. Estos equipos son comunes en el desarrollo de software, por ejemplo. Pero este enfoque es caro porque implica duplicar los recursos en lugar de compartirlos. Además, pueden seguir surgiendo atascos en estos proyectos, especialmente si el plan de personal del proyecto subestima la cantidad de retrabajos que el equipo acaba teniendo que realizar.

El caso ConnectCo

Para ilustrar las medidas que una empresa puede tomar para poner en práctica un enfoque de gestión de procesos, hemos creado un estudio de caso de una empresa ficticia llamada ConnectCo, una combinación de varias empresas que hemos estudiado. Por motivos de competencia, esas organizaciones nos pidieron que no divulguemos los detalles de sus procesos de desarrollo de productos.

ConnectCo, un productor de conectores y adaptadores eléctricos para uso industrial, se vio presionado para acelerar su ciclo de desarrollo tras perder varios posibles contratos a manos de un competidor japonés con un desarrollo de productos mucho más rápido. La principal tarea del grupo de desarrollo de productos de ConnectCo consistía en crear nuevos productos, pero también llevó a cabo ampliaciones más pequeñas de la línea de productos y respaldó los productos que ya estaban en el mercado. Los proyectos de desarrollo de ConnectCo no eran muy complejos. Por lo general, implicaban a un ingeniero de desarrollo, un técnico y el apoyo de varios grupos más. Sin embargo, la empresa llevó a cabo muchos proyectos y los clientes a menudo exigían cambios en los estándares de rendimiento.

ConnectCo había renovado su proceso de desarrollo varios años antes. La dirección había establecido un procedimiento formal de desarrollo de productos que especificaba las actividades necesarias en cada fase del desarrollo. La organización de desarrollo creó equipos multifuncionales e implementó un proceso de planificación para lograr un equilibrio entre los tipos y el número de proyectos que emprendió y el personal disponible.

A pesar de esas medidas, Mark Epstein, director general de ConnectCo, seguía pensando que no sabía realmente cuántos proyectos debía emprender su organización de desarrollo. El procedimiento de desarrollo formal le ayudó a predecir la cantidad de trabajo que requeriría cada proyecto. Sobre esa base, la organización no parecía estar asumiendo demasiados proyectos. Pero Epstein carecía de una herramienta para predecir cuándo se completarían esos proyectos. No importaba el tiempo extra que dedicara a imprevistos, más de la mitad de los proyectos cuya finalización estaba prevista cada año quedaban sin terminar. Algunos proyectos pasaron años en el limbo. Hace poco, el departamento de desarrollo había empezado a utilizar un software de planificación de proyectos y Epstein se quedó consternado al descubrir que el tiempo medio de desarrollo era más de cinco veces el tiempo de la ruta crítica: el tiempo mínimo (sin tener en cuenta los retrasos ni las modificaciones) que la empresa estimaba que necesitaba un proyecto.

¿Por qué los proyectos de ConnectCo tardaron tanto? Epstein le pidió a su director de desarrollo, Steve Gilles, que hiciera una lista de los proyectos recientes y los clasificara por dificultad y duración. No para su sorpresa, Gilles y Epstein descubrieron que la dificultad técnica no era un buen indicador del tiempo de comercialización. Un proyecto de ampliación de producto, el adaptador AD325, solo había requerido dos meses-persona de trabajo y, sin embargo, había tardado más de dos años en llegar al mercado. Un proyecto mucho más grande e innovador, el AD3500, se completó en menos de un año.

El equipo del AD3500 estaba dirigido por una joven ingeniera, Laura Murphy, que había demostrado ser una líder enérgica y creativa. Sin embargo, para llevar su proyecto por delante de los demás, Murphy había necesitado codazos muy fuertes y se quejaron de que la concentración de los recursos de ConnectCo en la AD3500 había ralentizado otros proyectos. Epstein llegó a la conclusión de que las quejas reflejaban un problema real al que se había enfrentado ConnectCo muchas veces antes, y no solo en el desarrollo.

Desarrollar un modelo de red de procesamiento

Epstein recordó haber tenido problemas de entrega similares en su organización de fabricación. Un consultor había ayudado a ConnectCo a desarrollar un modelo de simulación de procesos del flujo de productos por la planta. El modelo, que tenía en cuenta la variabilidad de los pedidos y los tiempos de procesamiento, mostraba que los productos solían pasar la mayor parte del tiempo haciendo cola para recibir el equipo en lugar de ser procesados. Demostró a los gerentes de ConnectCo por qué planificar altos niveles de utilización del equipo generaba congestión y cómo la agilización de las tareas urgentes añadía variabilidad y, por lo tanto, demoras a un sistema ya de por sí sobrecargado.

Epstein envió una circular a su equipo directivo explicando cómo problemas similares estaban provocando los retrasos en el desarrollo del producto. (Consulte la exposición «La congestión en las operaciones y el desarrollo de productos»). Epstein y Gilles crearon entonces un grupo de trabajo multifuncional para la mejora de los procesos para crear un modelo del proceso de desarrollo como el que se creó para la fabricación. Para enviar el mensaje de que la dirección consideraba que el esfuerzo era de vital importancia, Epstein y Gilles eligieron a Murphy como director del grupo de trabajo.

Congestión en las operaciones y el desarrollo de productos

El grupo de trabajo comenzó por desarrollar un diagrama de flujo de proyectos convencional que mostraba las seis tareas principales del procedimiento de desarrollo formal de la empresa. (Consulte «El diagrama de flujo del proyecto».) El grupo se dio cuenta rápidamente de que, dado que el gráfico no identificaba los recursos de la organización, no revelaría cuáles estaban sobreutilizados. Utilizando el modelo de fabricación como plantilla, el grupo de trabajo creó una nueva representación. (Consulte «El modelo de red de procesamiento».) El modelo de red muestra que cinco departamentos contribuyen al esfuerzo de desarrollo del producto: ingeniería, marketing, servicios técnicos, especificaciones e ingeniería de fabricación. Cada departamento es responsable de varias actividades. Por ejemplo, los ingenieros son responsables del desarrollo de los conceptos, los prototipos, las pruebas finales y las actividades administrativas y de apoyo. Las líneas que conectan los departamentos muestran cómo fluyen entre ellos los resultados de las pruebas, las especificaciones, los planos, las autorizaciones verbales y demás información.

El diagrama de flujo del proyecto

El modelo de red de procesamiento

A diferencia del diagrama de flujo de los proyectos, el modelo de red de procesamiento recuerda a los directores que los proyectos suelen residir simultáneamente en varios departamentos en varias fases de finalización. Por ejemplo, los servicios técnicos y de ingeniería pueden estar trabajando en un prototipo para un proyecto mientras el marketing completa su plan. Además, cada departamento de la organización suele tener más de una tarea en cola en su bandeja de entrada. Un día determinado, un técnico puede encontrar solicitudes para realizar pruebas de cualificación y ampliación de la fabricación para tres o más proyectos. Este modelo también puede ayudar a los directores a ver las numerosas iteraciones que se pueden producir en un proyecto.

En lugar de mostrar solo los árboles (los proyectos individuales), el modelo de red revela el bosque (la estructura del proceso). Epstein retó al grupo de trabajo a crear un modelo de simulación cuantitativa que ayudara a la empresa a identificar y evaluar varias opciones de mejora. Los nuevos paquetes de software para ordenadores personales, señaló, han facilitado relativamente la creación de estos modelos de simulación.

Los miembros del grupo de trabajo se pusieron a recopilar los datos necesarios mediante un cuestionario para todos los participantes en el proceso de desarrollo. (Consulte «El cuestionario del proceso».) Los participantes pudieron responder a algunas de las preguntas con facilidad, como cuántas personas había en su grupo en particular. Sin embargo, responder a otras preguntas requería una nueva perspectiva. Estas preguntas incluían «¿Cuántos tipos diferentes de proyectos gestiona su grupo?» y «Dentro de cada tipo de proyecto, ¿cuántas iteraciones se necesitan para realizar cada tarea en un proyecto de complejidad media?» Al hacer un seguimiento de la actividad de desarrollo de ConnectCo, el sistema de control de gestión de la empresa se centró en los proyectos y las personas individuales, no en el tipo de información orientada a los procesos que se requería en el cuestionario. Para ayudar a los participantes a completar el cuestionario, el grupo de trabajo organizó una serie de talleres con personas de cada grupo para analizar la experiencia de desarrollo de ConnectCo durante los tres o cuatro años anteriores. El grupo de trabajo resumió los resultados en la tabla «Recursos y requisitos».

El cuestionario sobre el proceso

Recursos y requisitos

El grupo de trabajo disponía ahora de la materia prima necesaria para determinar las limitaciones de capacidad de cada departamento. Con este fin, el grupo de trabajo calculó la utilización planificada de cada grupo comparando las horas disponibles del grupo al año con las horas requeridas por las tareas del proyecto (el producto de la media de horas-persona requerida por proyecto y el número de proyectos por año) y por otras actividades, como la administración y el apoyo. Los resultados de este análisis de capacidad se muestran en el «Perfil de utilización», en el que se compara el ritmo al que la organización puede desarrollar productos con el ritmo al que comienzan los proyectos.

Perfil de utilización

Los miembros del grupo de trabajo se sorprendieron por lo que encontraron. No sabían la parte de la semana laboral media que consumía el trabajo no relacionado con proyectos. Y lo que es más importante, se enteraron de que varios grupos estaban cerca o por encima de su plena utilización. Los ingenieros, por ejemplo, tenían previsto una utilización media de más del 104%. Cuando se añadieron al panorama las variaciones en las exigencias de los proyectos y en la carga de trabajo, se hizo evidente por qué algunos proyectos tardaban una eternidad.

El perfil de utilización planteó otras preguntas interesantes. Por ejemplo, aunque nadie dudaba de que los técnicos estaban sobrecargados, los datos mostraban que tenían tiempo libre. Las conversaciones de seguimiento con los ingenieros y los técnicos revelaron que los técnicos utilizaban este tiempo para ayudar en varias tareas de ingeniería, incluidas las pruebas. Los directivos no habían prestado mucha atención a estas prácticas informales pero muy eficaces. Los miembros del grupo de trabajo llegaron a la conclusión de que este reparto de tareas evitaba retrasos aún mayores en el desarrollo del producto.

Análisis y opciones

Esta primera fase del análisis indicó que, con un poco de horas extras y un poco de reparto de tareas, la organización de desarrollo debería poder completar el número y la combinación de proyectos existentes. Pero el análisis no predijo cuánto tardarían en completarse esos proyectos. Para estimar la duración del ciclo de un proceso de varios pasos, como el desarrollo, especialmente uno que implicaba tantas iteraciones como el de Connectco, el grupo de trabajo necesitó crear el modelo de simulación que había propuesto Epstein.

Al adaptar el enfoque que la empresa había adoptado en el estudio de fabricación, el grupo de trabajo utilizó los datos del cuestionario para cuantificar la variación entre los proyectos en la secuencia de tareas, el número de iteraciones y el ritmo de inicio de nuevos proyectos. Pronto, el grupo de trabajo tuvo un modelo que simulaba el flujo de proyectos en la organización. Con algunos ajustes, el equipo calibró el modelo para que reflejara el consenso general sobre la distribución de los tiempos de finalización de los dos tipos principales de proyectos. (Consulte la exposición «Los tiempos históricos de finalización de los proyectos de ConnectCo».)

Tiempos históricos de finalización de proyectos de ConnectCo

Estos gráficos destacaban un punto que había surgido en los talleres de recopilación de datos: si bien ConnectCo necesitaba mejorar su tiempo medio de desarrollo, también tenía que hacer algo con los proyectos excesivamente prolongados. En un 10% de los proyectos de nuevos productos, el tiempo de finalización fue de más de 140 semanas y, aunque los proyectos de extensión normalmente solo requerían 365 horas-persona, el 10% de ellos tardaron más de 100 semanas. Hacer seguimiento de esos proyectos era una carga de gestión, e injustificable porque no eran particularmente difíciles ni tenían un alto potencial de mercado.

En una sesión de intercambio de ideas, el grupo de trabajo generó una serie de posibilidades para reducir el tiempo de desarrollo, que luego el grupo evaluó mediante el modelo de simulación. En primer lugar, ConnectCo podía reducir la utilización media de los departamentos en los que había cuellos de botella. Podría añadir recursos a esos departamentos. Podría reducir la media de proyectos en marcha en cualquier momento. Podría capacitar a las personas de los departamentos menos sobrecargados para que realicen las tareas de los departamentos sobrecargados. Podría eliminar medidas innecesarias. Podría automatizar las etapas que se habían convertido en cuellos de botella. Y podría reducir los tiempos de preparación física y mental al mejorar el contenido y la disponibilidad de la documentación del proyecto.

En segundo lugar, la organización podría reducir la variación en los tiempos necesarios para realizar las tareas mediante la creación de plantillas de mejores prácticas. Ampliar el manual de procedimientos de desarrollo para incluir estas plantillas estimularía el intercambio de las mejores prácticas en toda la organización y ayudaría a los recién llegados a ponerse al día más rápidamente.

En tercer lugar, el grupo de trabajo consideró formas de reducir la variación en la carga de trabajo general. Los gerentes podrían fijar un límite al número de proyectos permitidos en el sistema en cualquier momento. Quizás el desarrollo podría operar un sistema de tracción inspirado en el altamente eficaz enfoque de justo a tiempo utilizado en la planta de fabricación. Con un sistema de este tipo, solo se podía iniciar un nuevo proyecto cuando se hubiera completado otro.

Por último, la empresa podría replantearse la forma en que gestiona los proyectos urgentes. Los proyectos acelerados interrumpieron los trabajos en curso, se tradujeron en configuraciones adicionales y aumentaron la variabilidad del proceso. Básicamente, había dos soluciones posibles: reducir el número de proyectos acelerados o aumentar la capacidad de la organización de desarrollo.

El grupo de trabajo desarrolló algunos cálculos aproximados de costo-beneficio para cada una de sus muchas ideas. El grupo cuantificó las ventajas de un desarrollo más rápido en términos de mayor cuota de mercado y mayor vida útil del producto. Los costes asociados a cada escenario incluían los costes directos de los recursos y, en algunos escenarios, los ingresos a los que la empresa renunciaría a corto plazo.

Dadas las presiones presupuestarias actuales, el grupo de trabajo no pensó que la dirección apoyaría una propuesta para añadir equipos caros o personas, como ingenieros, a pesar de que los cálculos basados en la simulación sugerían que esas inversiones generarían altos rendimientos. En cambio, el grupo propuso dos inversiones relativamente modestas que podrían tener grandes beneficios. La primera fue capacitar a los técnicos para que pudieran realizar más pruebas que realizan los ingenieros, que a menudo tardaban horas en programar procedimientos de prueba complejos. Los técnicos ya estaban ayudando, pero con la formación podrían gestionar la mayor parte de esta programación. Los cursos necesarios se ofrecían tanto en la empresa como en la universidad local.

La segunda recomendación era limitar el número de nuevos proyectos en marcha en cualquier momento a 12: nueve nuevos productos y tres ampliaciones. En la actualidad, la empresa comenzaba unos 14 proyectos (diez productos nuevos y cuatro extensiones) al año, pero como cada uno tardaba tanto en completarse, a menudo había más de 30 proyectos en el sistema a la vez. Las simulaciones mostraron que si ConnectCo instituyera un sistema de atracción que permitiera poner en marcha solo 12 proyectos simultáneamente, el inicio de los proyectos probablemente se reduciría entre un 10 y un 20%, pero cada proyecto se completaría mucho más rápido.

El grupo de trabajo de Murphy descubrió que, juntas, esas dos acciones reducirían los tiempos medios de desarrollo de los productos nuevos y de extensión en casi un 40%. Además, el tiempo necesario para completar el peor 10% (el más prolongado) de los proyectos de nuevos productos y de ampliación de productos se reduciría considerablemente. (Consulte la exposición «Mejoras estimadas en los tiempos de finalización»).

Mejoras estimadas en los tiempos de finalización

Como muchas otras empresas, ConnectCo había hecho un seguimiento de las horas que cada persona había dedicado a cada proyecto cada semana. Pero el grupo de trabajo de Murphy llegó a la conclusión de que esos datos no ayudaban a la empresa a supervisar y mejorar el proceso de desarrollo. El grupo propuso que ConnectCo mantuviera una batería de nuevas medidas orientadas a los procesos. Esas medidas incluían la carga (el número de proyectos en curso cada mes); la disponibilidad de los recursos (los recursos de desarrollo disponibles cada mes, sin incluir el tiempo administrativo y de soporte); la utilización (el nivel de utilización mensual de cada departamento); la contribución (el tiempo que cada departamento dedica a cada tarea durante el mes); el rendimiento del proceso (el número de iteraciones necesarias para completar la tarea con éxito); y la eficiencia del proceso (la relación entre el tiempo real dedicado a la tarea y el mínimo tiempo posible según lo estimado mediante un modelo de ruta crítica y el mejor: plantillas de práctica).

Los datos de eficiencia y rendimiento podrían recopilarse de cada proyecto mensualmente y, luego, agregarse para determinar el grado de control de cada tarea. El grupo de trabajo recomendó que los directores hicieran un seguimiento no solo de los promedios sino también del peor decil para controlar los proyectos en el limbo. (Consulte «El formulario de informe del proceso».)

El formulario de informe del proceso

Por último, el grupo de trabajo de Murphy propuso que se ampliara el manual de procedimientos de desarrollo con plantillas de mejores prácticas para cada tarea. Aunque algunas variaciones en el proceso de desarrollo son inevitables debido a la idiosincrasia de cada proyecto, todos los miembros del grupo de trabajo se sorprendieron al descubrir el grado en que el número de iteraciones y el tiempo necesarios para llevar a cabo una tarea determinada variaban de un proyecto a otro.

Decisiones adoptadas

Epstein y sus directivos quedaron impresionados por la propuesta de formación multifuncional y rápidamente dieron el visto bueno. Pero les costaba más aceptar el traslado recomendado a un sistema de tracción. Pasar de más de 30 proyectos en curso a 12 parecía arriesgado. Aunque la simulación finalmente los convenció, Epstein estaba nervioso por la transición. Decidió reducir el número de proyectos en curso a 20 durante el año siguiente y, después, volver a evaluar el número para el año siguiente.

Con ese fin, Epstein instituyó un proceso de revisión más riguroso de las propuestas de proyectos y pidió a sus directores que revisaran todos los proyectos que estaban a punto de terminarse pero que estaban estancados. Epstein sospechaba que, aunque esos proyectos no requerían mucho trabajo adicional, muchos de ellos se habían visto atrapados en un círculo vicioso: una vez que un proyecto se ganaba la reputación de ser un problema, los proyectos más nuevos lo dejaban de lado continuamente, especialmente aquellos cuyos líderes tenían codazos afilados.

En segundo lugar, el equipo de dirección creó un nuevo grupo de trabajo encargado de incorporar plantillas de mejores prácticas para las tareas clave en el manual de procedimientos. Epstein decidió que, en cuanto el nuevo manual estuviera disponible, se evaluaría y recompensaría a los equipos de proyectos no solo por su eficacia en la ejecución de sus proyectos, sino también por las mejoras en las plantillas que sugirieron en las revisiones posteriores al proyecto.

Por último, la dirección pidió a la organización de desarrollo que empezara a informar, a modo de prueba, de los datos de proceso recomendados por el grupo de trabajo. Epstein pensó que necesitaría esos datos para evaluar la eficacia del nuevo enfoque de gestión de procesos durante los próximos meses.

Primeros resultados

Durante los primeros días del grupo de trabajo, algunos directivos y miembros del personal de la organización de desarrollo de ConnectCo estaban preocupados de que la gestión de los procesos socavara la autonomía que necesitaban. Para las personas que se dedican a un trabajo creativo y no repetitivo, los modelos de procesos, las métricas detalladas y las plantillas de procesos sonaban como una receta para la regimentación y la alienación.

Sin embargo, cuando el grupo de trabajo hizo sus recomendaciones, la mayoría de la gente había empezado a ver la gestión de procesos como una forma nueva y emocionante de entender su trabajo. Después de todo, a todo el mundo le importaba el tiempo de comercialización. Además, el grupo de trabajo había implicado a sus colegas en el esfuerzo de gestión de los procesos y Epstein se había comprometido a utilizar las nuevas medidas de los procesos para mejorar los procesos, no a culpar.

Durante el año siguiente, la empresa redujo su cartera de proyectos de 32 a 22 proyectos en curso. Como había previsto Epstein, muchos proyectos estaban a punto de terminarse y podían terminarse rápidamente. ConnectCo completó 18 proyectos ese año, casi un 30% más que su media histórica.

El equipo de alta dirección se mantuvo firme en su compromiso de emprender menos proyectos nuevos. En el pasado, aceptaba proyectos en función de su atractivo empresarial y, luego, los dejaba quedar pendientes. Ahora el equipo adoptó una norma estricta según la cual ningún proyecto podía empezar hasta que no estuvieran disponibles los recursos necesarios. Como resultado, ConnectCo solo aceptó ocho nuevos proyectos durante ese año, el 60% de su media histórica.

Las nuevas normas generaron cierta resistencia. Los directores de marketing temían que los límites estrictos a los nuevos proyectos impidieran su capacidad de responder a las demandas de los clientes. Además, sus bonificaciones estaban vinculadas al valor de los nuevos contratos. Bill Shaw, el director de marketing, planteó este último problema a su personal y ellos crearon un nuevo sistema salarial que reducía las bonificaciones a cambio de salarios base más altos y establecía un conjunto más amplio de objetivos de rendimiento para determinar las bonificaciones.

Al igual que Shaw, a Epstein le preocupaba que rechazar demasiadas solicitudes de clientes antiguos debilitara esas relaciones. Ahora que la dirección conocía mejor las capacidades de la organización de desarrollo, Epstein decidió que, el año que viene, ConnectCo asumiría unos 11 proyectos nuevos y se esforzaría por alcanzar la meta de 16 proyectos en curso.

La mejora del equilibrio entre los recursos y la carga de trabajo alivió muchas tensiones en la organización de desarrollo. Pero algunos hábitos antiguos tardan en morir. De hecho, las colas eran más cortas, pero los líderes del proyecto seguían deseosos de llevar sus proyectos a la primera fila. Un proyecto en particular se convirtió en una especie de causa célebre. La directora del proyecto, Claire Chen, trabajaba con un cliente que tenía una gran presión de tiempo. Cuando Chen intentó acelerar el calendario suplicando a los ingenieros y técnicos, estos se negaron. Hizo un llamamiento al grupo de alta dirección y criticó el nuevo enfoque por considerarlo peligrosamente rígido.

Con el fin de estabilizar el proceso de desarrollo, el grupo de trabajo de Murphy había alentado a los departamentos a adoptar un enfoque de gestión de sus bandejas de entrada, primero en salir. El nuevo plan no proporcionaba directrices para hacer frente a emergencias reales, como el proyecto de Chen. Los altos directivos decidieron que era necesario hacer algunos ajustes: la norma que prohibía agilizar los proyectos era demasiado rígida. De hecho, ahora que se ha reducido la utilización de la capacidad, los proyectos acelerados serían menos disruptivos. Pero los altos directivos no querían dejar que los líderes de proyecto más agresivos volvieran a decidir qué proyectos recibían un tratamiento especial. Decidieron permitir que algunos proyectos se declararan urgentes, pero ordenaron que solo el equipo de alta dirección, no los líderes del proyecto, pudiera conferir ese estatus.

El programa de formación de técnicos se desarrolló sin problemas. La mayoría de los técnicos estaban deseosos de ampliar sus puestos de trabajo. Sin embargo, hubo algunos rumores sobre la necesidad de aumentos salariales acordes con las nuevas responsabilidades. Epstein decidió que los técnicos con habilidades más amplias se merecían una paga más alta. Al principio, algunos ingenieros se mostraron reacios a renunciar a su responsabilidad de programar las pruebas. Pero como la nueva división del trabajo les liberó gran parte de su tiempo, cambiaron de opinión rápidamente.

Este esfuerzo de formación multifuncional también sirvió de piloto para crear plantillas de mejores prácticas. Como los ingenieros eran responsables de la programación de las pruebas, Gilles les pidió que desarrollaran una plantilla para traducir los parámetros de las pruebas en programas de pruebas específicos. Un grupo de ingenieros diseñó un proceso de programación genérico e identificó cinco escenarios de prueba diferentes que requerían enfoques ligeramente diferentes. Durante los tres meses siguientes, los técnicos descubrieron muchas ambigüedades e inconsistencias en las plantillas. Un equipo de ingenieros y técnicos revisó los procedimientos y, finalmente, elaboró un manual de 60 páginas que los técnicos consideraron útil. Pronto los técnicos empezaron a añadir sus propias notas y mejoras al manual.

Aunque algunos proyectos seguían tardando más de lo que a Epstein le hubiera gustado, la duración media del ciclo de desarrollo del segundo año fue un 35% inferior a la media anterior a la iniciativa. (Consulte la exposición «Los resultados de ConnectCo».) Tal como había previsto el grupo de trabajo, había menos proyectos en el limbo. Y al final de los dos años, ConnectCo solo tenía 17 proyectos en marcha, frente a los 32 del principio.

Resultados de ConnectCo

Al ayudar a las personas a identificar los proyectos que se desviaban de las medias, el nuevo sistema de medición les ayudó a entender mejor el proceso. Los proyectos inusualmente largos o cortos se convirtieron en oportunidades de aprendizaje. Las evaluaciones posteriores al proyecto ahora identificaron los cuellos de botella ocultos, la escasez de habilidades y las inadecuaciones de las plantillas, así como las oportunidades de mejora asociadas. La empresa descubrió, por ejemplo, que algunos proyectos se retrasaban durante semanas hasta que la planta tuviera tiempo de realizar pruebas. ConnectCo invirtió en una línea piloto en el laboratorio, lo que acabó ahorrando dos meses más en un proyecto promedio. A través de la gestión de procesos, la mejora continua pasó al desarrollo de productos.