Rodolfo Torres-Rabello.

Hay dos tipos de cosas en las que un Gerente de Operaciones llena su agenda: las del día a día, tales como supervisar las entregas a los clientes. Y los proyectos. En Gestión de Operaciones, estos son la oportunidad para realizar mejoras que exceden la administración rutinaria (por ejemplo, la automatización de una fábrica o la remodelación de una tienda), pero, además, existen en Operaciones actividades de cierta complejidad y poca frecuencia que son tratadas como un proyecto, como el transporte de cargas sobredimensionadas.

Para el PMI (Project Management Institute), un proyecto es un esfuerzo temporal llevado a cabo para crear un producto, servicio o resultado único. Un conjunto de proyectos afines es un programa. Un portafolio es un conjunto de programas y proyectos.

Son ejemplos de proyectos en el área de Operaciones:

• Implementación de una fábrica de tolvas para camiones mineros.

• Rediseño de una planta de producción de papel.

• Diseño, construcción e implementación de un CD.

• Implementación de un WMS y tecnología de radiofrecuencia.

• Diagnóstico e implementación de mejoras a los procesos de abastecimiento de una empresa de casinos.

• Proyecto de Six Sigma para reducir el tiempo de reparación de motores de barcazas utilizadas para transportar alimentos para salmones.

• Implementación de las 5S en una maestranza.

• Rediseño de la red de distribución de una empresa en América Latina.

• Diagnóstico y rediseño de la Cadena de Suministro de Servicios para un servicio pú- blico.


En una empresa grande o mediana existen jefes o gerentes de proyectos. Pues bien, el gerente de proyectos es un tomador de decisiones, al que se le exige cumplir los objetivos, los plazos y el presupuesto, gestionando eficientemente los recursos disponibles. Las decisiones que el gerente de proyectos adopta dicen relación con:

• Gestionar eficaz y eficientemente cada etapa del proyecto, desde el inicio al cierre, privilegiando las decisiones informadas y evitando la improvisación.

• Negociar objetivos, plazos y presupuesto, mostrando al mandante cómo afecta la variación de un factor en el resto. Los proyectos están afectos a una triple restricción: Alcance, Tiempo y Costo. Si se varía una de ellas se afecta el resto. Por ejemplo, si se exige reducir el tiempo a la mitad el proyecto puede encarecerse y el alcance o la calidad puede verse afectada.

Todo lo anterior está bien y es lo que enseñamos en los cursos de proyectos. Pero, a pesar de décadas de estos cursos y de grandielocuentes modelos, los proyectos en general se atrasan y terminan costando más que el presupuesto. Cuando esto ocurre a menudo se recurre a la “Ingeniería de Explicaciones” (ver recuadro).

Examinemos por qué nos pasa lo que nos pasa. Cuando nos piden estimar el tiempo que ocuparemos en cumplir una actividad lo pensamos dos veces. Si decimos “para mañana” ese plazo será casi un compromiso de honor. Entonces, algo en nuestro interior nos dice que multipliquemos por dos o por tres; entonces decimos “dentro de cinco días”. Nuestro jefe nos mira seriamente y nos pregunta si podemos hacerlo en menos tiempo, pero movemos la cabeza y decimos que de ninguna manera, que el mínimo tiempo en que podemos hacerlo es de aquí a cinco días.

Tenemos que hacerlo así porque esto no es lo único que hacemos. Seguramente participamos en más de un proyecto y somos los reyes de las multi-tareas. Entonces nos cubrimos y estimamos más tiempo del necesario. Sabemos, con Goldratt, que cada vez que hay recursos compartidos la capacidad del sistema está limitada.

Pero aquí viene la segunda parte: una vez que quedó establecida la fecha de término de la actividad, no lo ejecutamos de inmediato. Sabemos que tenemos cinco días de plazo, pero podemos hacerlo en uno, así que nos dedicamos a otra cosa. Cuando se acerca el plazo corremos y lo hacemos, al igual que el estudiante que espera al último día para preparar su examen (Síndrome del Estudiante).

Sin embargo, esto no significa que estuvimos desocupados los otros cuatro días. Seguramente estuvimos muy ocupados. La llamada Ley de Parkinson dice que el trabajo se expande hasta ocupar todo el tiempo disponible. Así que en retrospectiva nosotros mismos justificamos los cinco días y tal vez pensamos que la próxima vez deberíamos estimar un par de días más. De modo que la estimación de tiempos en un proyecto complejo, con múltiples actividades, podría estar contaminada por estos efectos. Lo que parte mal puede terminar mal. Una mala programación puede esconder la semilla de su fracaso. Una vez que los proyectos comienzan (¡a menudo hay más de un proyecto!) viene la etapa de pasar del PowerPoint y del Microsoft Project a la acción. Entonces, el jefe de proyectos debe reportar su progreso. En parte de su informe podría decir: “Informamos que el cumplimiento de tareas de esta semana es un 95%”. Aplausos. ¿Qué hay de malo en esa afirmación? Todo. Puede que sean tareas irrelevantes, pero cumplidas. Es posible que esté comprometida la fecha de término del proyecto o no, pero no lo sabemos hasta que es demasiado tarde, porque -en la experiencia de muchos jefes de proyectocuando falta el 10% para terminar el proyecto, falta el 90% del trabajo.

¿Hay remedio? Sí lo hay. Comencemos por reconocer que una persona no puede estar en dos lugares al mismo tiempo. En otras palabras, cuando hay recursos compartidos el portafolio de proyectos debe ajustarse en forma escalonada. Imagine una multitud intentando entrar por una puerta; es más práctico que entren uno a uno. Lo mismo ocurre con los proyectos: programe sus proyectos considerando sus recursos compartidos. Y, de paso, mire con atención las estimaciones de tiempo: seguramente hay tiempo de sobra escondido en sus Gantts.