6
Mar

la triple restricción

Escrito el 6 Marzo 2010 por José Luis Portela en General

En todo proyecto se dice que existe una triple restricción, que es el tiempo el coste y el alcance. Digámoslo de otra forma, la modificación de cada una de ellas tiene un claro impacto en las otras dos.  Esto es algo que todos podemos experimentar incluso en pequeños ámbitos de nuestra vida cotidiana cuando nos afrontamos a realizar un cambio, estamos condicionados por estos tres factores: Tiempo, Coste y Alcance

Basado en mi experiencia y fruto de compartir esto con muchos alumnos y profesores, he llegado a la conclusión que realmente lo que existe es una quíntuple restricción. En concreto hablo de Objetivo, Coste, Alcance, Tiempo y Organización / recursos.  El objetivo del proyecto si creo que es claro una restricción ya que condiciona a las demás, sobre todo si este esta bien definido (ya sabéis técnica SMART) y los recursos que dispongamos para la realización del proyecto es otra restricción clave, ya que nos condicionará bastante en la forma en la cual decidamos realizar el proyecto.

Finalmente un factor adicional y clave para entender la complejidad de los proyectos, es que estos 5 factores no son estáticos y que por tanto cambian a lo largo del recorrido de un proyecto derivados tanto de los condicionantes internos del proyecto como de los condicionantes externos, es decir del entorno tan cambiante que nos rodea

Comentarios

Raúl 6 Marzo 2010 - 19:23

No entiendo que el Objetivo cambie a lo largo del recorrido de un proyecto. De hecho, diría que es el único punto de la figura que sería fijo respecto al resto que sí rotarían/girarían (cambian a lo largo del tiempo).
Puede poner una situación en la que cambie el Objetivo a lo largo del proyecto? No sería entonces otro proyecto diferente?

José Luis Portela 6 Marzo 2010 - 21:34

Raul

Llevas toda la razón. El objetivo se debe definir y no debe en principio ser modificado a lo largo del proyecto. Ahora bien te hago una pregunta, podría darse el caso que uno o varios objetivos inciales del proyecto se tuvieran que modificar por causa de que hayan variado los otros condicionantes?.

Javier 7 Marzo 2010 - 13:30

El objetivo de un proyecto debe de cumplir unos requerimientos especificos, y es verdad, que cualquiera de los otros condicionantes hace que alguno de los requerimientos iniciales puedan cambiar. ¿Podemos decir que un cambio en los requerimientos, es un cambio en el objetivo? Me hago esta pregunta porque en el caso de proyectos IT, el objetivo es construir o dar solución a una problematica con una serie de requerimientos, pero es posible prescindir de algún requerimiento sin que el objetivo final cambie.

También quiero destacar el impacto tan grande que tiene dentro de un proyecto el cambio de organización y sobre todo, de los recursos asignados al proyecto.

José Luis Portela 7 Marzo 2010 - 16:36

Un cambio en los requerimientos no tiene porque significar un cambio en el objetivo del proyecto. En el caso que un cambio en los requerimientos de un proyecto afectase a los objetivos del mismo, habría que hacer un replanteo dependiendo de que sea un objetivo adicional que se une y que no modifica los actuales o bien un objetivo que si modifica o contradice algunos de los objetivos actuales del proyecto.

El tema de los proyectos IT, sin lugar a dudas la gestión de stakeholders, en especial los usuarios finales y la gestión del cambio, es crítico para contribuir al éxito del proyecto. Los continuos cambios de alcance, la no alineación de los objetivos del proyecto con los objetivos y la estrategia de la compañía hacen que muchos de ellos terminen siendo un fracaso.

Adolfo Añino 7 Marzo 2010 - 18:03

Yo estoy con un proyecto que, al cambiar su director por parte del cliente, ha cambiado radicalmente justo cuando estaba a punto de concluirse. Ahora el alcance es otro, el objetivo es otro, es en realidad otro proyecto. El problema es que para el nuevo director de proyecto (del lado del cliente), sigue siendo el mismo.

Tengo muy claro que el objetivo no debe cambiar en ningún caso y que los demás elementos que influyen en el proyecto hay que valorarlos seriamente antes de variarlos por la razón que sea.

Oscar 7 Marzo 2010 - 18:21

Jose Luis, posiblemente uno de los condicionantes externos o entorno que puede influir en el desarrollo de un proyecto es el “criterio de competencia”. Se trata de la referencia que todo proyecto debe perseguir para ubicarse adecuadamente en un entorno concurrente. En la práctica y en mi experiencia, muchos de los proyectos en los que he participado han estado condicionados o “limitados” por la actuación o posible acción de las empresas competidoras. Se trata en ocasiones de un límite de mínimos que debe considerarse para poder dotar al proyecto de valor añadido sobre otros de competidores o, simplemente, un límite que obliga a ajustar el proyecto en la medida que se observe que un competidor ya ha superado un benchmark establecido en mi proyecto. Creo que dada su relevancia en ciertos proyectos, podríamos valorar la competencia como un nuevo factor de restricción.

Soledad Martínez Muñoz 7 Marzo 2010 - 18:53

¡ Qué pronto cambia el objetivo cuando la ilusión se convierte en realidad!!
Muchos objetivos caprichosos solamente se sostienen por vanidad, problema usalmente potenciado por una “venta” anticipada del proyecto. Desde mi punto de vista, una de las labores del director del proyecto es desviar el objetivo si es incorrecto.
¡¡ Cúanto nos agradecería la humanidad si lo inconstruible no se construyera o lo invendible no se pusiera a la venta!!

Jose M. Ovando 7 Marzo 2010 - 20:41

Hola,

Después de la clase del Viernes y viendo la triple y quíntuple restricción, me acordé de un pasaje de un libro que leí hace ya tiempo sobre la exploración en Marte en las décadas de los ’90 y ’00 cuando la NASA lanzó aquellos dos robots Spirit y Opportunity que se pasaron meses haciendo fotos y analizando muestras del suelo marciano.

El libro se llama “Roving Mars” y el autor es el director de los proyectos de ambos rovers Steve Squyres.

En un momento del relato, Steve cuenta como intentos pasados de llevar un rover a Marte habían fracasado una y otra vez debido a que la NASA había “forzado” al límite las tres restricciones tradicionales de un proyecto dejando al JPL (el laboratorio que ejecutaba los proyectos) a la merced de poder gestionar y dirigir solamente lo que pienso puede ser una cuarta (sexta) restricción: El riesgo.

“Like any big technological project, a mission to Mars has four basic elements: cost, schedule, performance, and risk. With all their restrictions, NASA had dictated to JPL exactly what the cost, schedule, and the performance of every Mars mission had to be. What that meant was that when things went wrong – when time and money got tight, as they always do – there was nothing JPL could do but to let the risk increase. Everything else was nonnegotiable. NASA’s rules meant that cutting corners and taking chances were JPL’s only management tools.”

Pienso que si hay una cierta tolerancia al riesgo en un proyecto, el objetivo, tiempo, coste, alcance, y recursos, pueden moverse en sus diferentes escalas. Sin embargo si el riesgo admisible o deseable es cero o próximo al mismo, las 5 restricciones se ven alteradas igualmente (normalmente al alza todas).

Ya digo… Me pareció interesante.

Saludos,

José Luis Portela 7 Marzo 2010 - 22:59

muy buen comentario Jose M. Ovando

Miguel Angel Gómez 7 Marzo 2010 - 23:08

Enhorabuena por el artículo.
Sólo una apreciación, amigo Portela, no consideras el “factor humano”, como la mayor de las restricciones, créeme, no hay nada como enfrentarse a un equipo desmotivado para que cualquier buen proyecto, perfectamente planificado y con los objetivos claramente determinados, se vaya al carajo… o, no…

José Luis Portela 8 Marzo 2010 - 08:54

Miguel Angel

A mi el factor humano no me gusta llamarlo la mayor restricción, prefiero llamarlo el mayor facilitador. En mi experiencia, sin lugar a dudas es el factor más importante a tener en cuenta. Las metodologías y pasos a seguir, están ahí y la mayoría de los directores de proyectos las conocen, por lo que llego al punto que lo que realmente hace distinto unos proyectos de otros son las personas. De todo lo que enseñamos en el programa, yo enseño todo lo relativo a las personas, por lo que te puedes imaginar que explicar aquí todo lo que conozco se me queda corto, por lo que te invito a que participes en nuestro programa algún día para que puedas participar de las conversaciones que tenemos en clases al respecto

Pablo Márquez 8 Marzo 2010 - 09:55

Enlazando con todos los comentarios creo que el objetivo varía cuando se inician los proyectos sin que estén suficientemente estudiados. Es muy habitual iniciar proyectos muy poco madurados y que cambian de objetivo una y otra vez porque no se han realizado los estudios de mercado o cambia la opinión del “jefe”, por ejemplo. Tiene mucha razón el comentario de Soledad.
Respecto al tema del factor humano el Director del Proyecto es el responsable de crear un equipo motivado y con personas capaces, en caso contrario es posible que no sea el Director adecuado.
Enhorabuena por el blog José Luis, realmente es muy interesante.

Arturo Gayoso 8 Marzo 2010 - 12:48

Yo sólo haría una matización: en vez de llamar Objetivo a ese vértice le llamaría Objetivos. Ese ligero matiz es para tener bien presente que cada actor que se ve involucrado en un proyecto tiene diferentes objetivos en él, y sobre los comunes diferentes prioridades. En la práctica se traduce en que el director de proyectos ha de establecer los del proyecto teniendo muy presente esas circunstancias, y hacer seguimiento de cómo evolucionan éstos durante la ejecución del proyecto para que todos los intervinientes sigan alineados y su contribución sea la deseable.

En el ejemplo de los rovers a Marte: los del laboratorio prefieren incrementar los riesgos para no perder dinero porque su objetivo particular incluye mantener el margen económico, y la Nasa que se mantengan los costes que negoció porque uno de sus objetivos es mantenerse en el presupuesto. Si el responsable del proyecto de la Nasa supiera que existen esos riesgos los valoraría para analizar qué le aleja más del objetivo del proyecto: aceptar el riesgo sobre la misión o asumir un coste adicional.

saludos

Juan Luque 8 Marzo 2010 - 12:57

Dos comentarios. El primero sobre el objetivo. Para mí, el problema es que se pide lo que se cree que se quiere / necesita pero en forma del CÓMO y no del QUÉ. El QUÉ no suele cambiar aunque el CÓMO puede hacerlo en el transcurso del proyecto, como fruto de él mismo. Los pasos clásicos que recuerdo son (para un proyecto IT, pero puede extrapolarse a otras áreas): necesidad -> requerimientos usuario -> diseño orgánico – > diseño funcional -> diseño técnico -> desarrollo -> pruebas individuales -> pruebas integradas -> implantación…
¿Cuántas veces se saltan estos pasos y un usuario va al funcional, pidiendo el CÓMO y no el QUÉ? Ahora bien, es complicado cuando el usuario es también cliente o jefe, ya que no le suelen gustar las correciones ni que nadie le diga lo que él/ella quiere.

El segundo comentario, sobre las x fuerzas. Yo englobaba todas las fuerzas de recursos (incluido el coste) bajo este nombre. Creo que en realidad no importa demasiado siempre que se tomen en cuenta todas y que hay interrelaciones entre ellas. Sí me ha gustado la reflexión sobre el tiempo como entorno y parámetro de cambio. Es muy real y tendemos a olvidarlo o incluso a culparlo. Las situaciones de entorno, competencia, personas… cambian y nos afectan. Más que criticarlo, hay que valorarlo.

José Luis Portela 8 Marzo 2010 - 13:39

Juan

Aunque suene “duro” lo que voy a tratar de decir, el usuario no tiene que dar los requerimientos en un proyecto IT. Me explico:

IT tiene que hacer una reingeniería de procesos, y elegir la mejor forma de soportar dichos procesos con un sistema IT teniendo en cuenta el TCO (Total Cost of Ownership) en el cual se incluyen no solo todos los costes implicados sino una visión a medio plazo de cuales son los futuros costos de mantenimiento. Si dejas en manos de un usuario de cualquier sistema la libertad de hacer una carta a los reyes magos diciendo como tiene que ser definido el sistema, no solo tendras un sistema carisimo sino ademas que no este pensando desde un punto de vista de reingenieria de procesos

Prometo hacer una entrada dedicado solo a esto

Lurdes 8 Marzo 2010 - 14:04

Quiza lo que sucede en muchos casos es que los objetivos marcados dejan de ser prioritarios para la organización (empresa), por causas ajenas a los propios directores de proyecto ….En estos casos los proyectos pierden “protagonismo”. Esto supone reducción de recursoa y costes asignados, incluso una demora en el tiempo….En mi caso nos ha pasado tener que preparar un proyecto, trabajar sobre el con un plazo y recursos determinados…y al final ser imposible su implementación….No se si pasa frecuentemente pero es verdaderamente frustrante, sobretodo para las personas que afecta este cambio que no se llega a producir y que ya lo has comunicado…..

Adolfo Añino 8 Marzo 2010 - 16:32

Contestando a Juan, lo que dice respecto del cliente y los requerimientos en un Proyecto de IT, es aplicable a muchos proyectos de otros tipo. En la edificación o en la obra civil, salvo que tu cliente sea experto en esas materias (pasaría lo mismo si es experto en IT), el cliente debe decir qué quiere, con qué características, qué funciones ha de cumplir, cuánto quiere pagar por ello, etc., pero no puede inmiscuirse en los requerimientos hasta ciertos niveles, ya que eso llevaría a que el Proyecto fuera difícilmente realizable.

En fin, que estoy muy de acuerdo con lo que dice Juan.

Santos Garcia 8 Marzo 2010 - 17:10

Comparto las bases y tengo una inquietud sobre el corazón del triangulo, “la organización y los recursos”, creo que en determinados proyectos aportamos una complejidad tremenda cuando trabajamos con organizaciones y recursos compartidos en los proyecto para minimizar los costes. A menudo, desgastamos bastante esfuerzo en alinear distintas areas o recursos en objetivos que no son los suyos…me refiero a organizaciones con dobles o triples jefes.

Mi experiencia es que solo se arregla escalando el asunto ? hay alguna receta para mejorar el funcionamiento en estas situaciones?.

José Luis Portela 8 Marzo 2010 - 18:26

A eso se le llama saber trabajar en equipo. Sobre esto amigo Santos hay mucho escrito y en el programa superior de direccion vemos muchas cosas relacionadas precisamente sobre este tema.

Mariano Saúca Blattner 8 Marzo 2010 - 18:30

Como en muchos ámbitos de la vida, trabajamos con imperfecciones. El mundo no es perfecto y los proyectos, desde que nacen (y sobre todo en este momento) hasta que finalizan, no lo son. Un proyecto casi siempre nace con la fecha fin asignada, y eso es así porque seguramente detrás hay un objetivo de negocio que lo requiere, y no por el capricho de alguien que lo “vende”. Y el arte de la gestión de proyectos es precisamente conseguir el objetivo, teniendo menos grados de libertad de los que nos marcan las metodologías “ideales”, que hablan alegremente de gestión de riesgos, retrasos, etc. Desde mi punto de vista creo que las metodologías deben enfocarse más a los aspectos “imperfectos” de la situación de contexto, y ver cómo poder minimizar riesgos, impactos, etc. Obviamente es importante la “teoría” para el caso de que todo vaya rodado, pero poner más énfasis en pensar en lo que puede ir mal al definir una metodología creo que sería bueno.

Pablo Sagaseta 8 Marzo 2010 - 20:10

Buenas tardes a todos:

Sobre el asunto de la triple vs quíntuple restricción. Creo que en ocasiones, estamos pasando características de una restriccón a otras. En este sentido Lurdes, Arturo G. y Juan Luque dicen un poco lo que yo intento aglutinar, creo. Hay casos en que hablar del objetivo como restricción o hacerlo del coste (vs recursos) nos confunde (ojo, a mi el primero) por cuanto puede ser que una característica (entendiendo por “característica” una parte de una de las restricciones) puede cobrar tanto protagonismo como para ser apreciada (o consderada) una restricción en si misma. La parte por el todo.

Creo que con la quintuple restricción, sacamos del “coste” los que ahora son “recursos”, y sacamos el “objetivo” de lo que eran “alcance” y “tiempo” y “costes” (afectaría a los tres, o a dos o a uno, según casos). Creo que esto ocurre, por que son características que prevalecen, y que por tanto, son restricciones en si mismas en un gran número de casos, y sobresalen solas. Pienso por ejemplo en el proyecto de “ser los PRIMEROS en llegar a la luna”. Si no eres el 1º, el proyecto no vale, por lo que el objetivo es casi la mayor restricción. Si tenemos un proyecto en en que el grado de cumplimiento nos permite no tener que cumplir el 100%, podría ser un proyecto de investigación en que a falta de solución total, te puede valer un paliativo (simplificando mucho, claro), el objetivo pierde prioridad (enlanzando con el concepto de Lurdes).

En cualquier caso, supongo que lo importante es tener las limitaciones o restricciones limitadas e identificadas.Identificando en cada caso el origen de las limiticaciones que sufre nuestro proyecto podremos hablar de 3, 5, 2, 1…. lo importante es identificarlas. Como herramienta de identificación, la quintuple restricción me parece que te obliga a pensar en mas restricciones, aunque luego queden desestimadas.

Espero no haberme enrevesado mucho.

Pablo S.

Juliana 9 Marzo 2010 - 20:20

He acabado de leer la nota técnica para la próxima clase de “organización de recursos” y me resulto muy interesante el “stakeholder satisfaction” . El texto comenta que además de la triple o quíntuple restricción que son importantes en una planificación/gestión de un proyecto hay otros factores evaluados por los stakeholders : Learning, Value, Use. Y eso determina si un proyecto ha tenido éxito o no.
Comenta ejemplos de proyectos de IT y también la importancia de las lecciones aprendidas.

La próxima clase estará interesante.

Juan González 11 Marzo 2010 - 15:21

Creo que las restricciones de un proyecto, ya sean tres o cinco, pueden diferenciarse en función del grado de actuación que sobre las mismas tengamos. Bajo este punto de vista las diferenciaría entre variables endógenas (sobre las que podemos actuar) y exógenas (aquellas que nos vienen dadas por el modelo y nuestro margen de actuación es limitado o nulo):
1. Objetivo: creo que es la más difícil de todas ellas por su definición y características SMART. No obstante (a no ser que sea por contrato externo), el objetivo lo fijamos nosotros, por lo que sería considerado una variable endógena al proyecto la cual podemos ajustar a nuestro antojo en la fase inicial, condicionando las restantes variables.
2. Alcance: entendido como metodología del proyecto, somos nosotros quienes lo fijamos, por lo que podemos actuar sobre ella y modificarla para ajustarla a las necesidades según evolucione el proyecto. Sería una variable endógena.
3. Tiempo: determinado a priori por el objetivo a lograr y la metodología a emplear, depende de los costes del proyecto y de los recursos humanos y organizativos asignados, por lo que tiene un componente exógeno considerable.
4. Coste: si el proyecto está bien planificado, el coste fijo mínimo del mismo es una variable endógena que controlamos sin problemas. Sin embargo, a partir de ese coste mínimo podemos sufrir variaciones que vienen determinadas por el entorno (variación en el precio de materias primas, precios de los rrhh, etc.) y sobre las cuales nuestro margen de actuación es limitado a no ser que nuestra provisión para imprevistos tenga cuantiosos fondos.
5. El factor humano: aunque con la motivación y directrices adecuadas podemos encauzarlo a la consecución del objetivo, queda sujeto siempre a la decisión del individuo, la cual es una variable claramente exógena al proyecto. Influye directamente en los costes del proyecto y en los plazos de ejecución del mismo, así que si la definición del Objetivo es fundamental, no es lo es menos la organización, motivación y asignación clara de tareas de los stakeholders que intervienen en el mismo.

Juan Luque 15 Marzo 2010 - 14:56

Un poco tarde, contestando a Jose Luis: no, el usuario no debe dar requerimientos sino necesidad. Tiene que habe alguien que analice y traduzca esto, incluyendo un análisis de viabilidad. Eso es lo que quería destacar, ya que hay ocasiones en los usuarios ni siquiera se quedan en este paso sino más allá (como en el análisis técnico: ponme esto en esta pantalla o haz así esta extracción…). Deja que el usuario pida lo que quiera pero no cómo. Eso sí, que revise los requerimientos para saber que está alineado con su necesidad. Si es caro, habrá que ver el balance coste / beneficio. Peor es hacer algo que es maravilloso pero que el usuario no utilizará o que no entenderá, son situaciones mucho más caras, no sólo en coste directo sino en esfuerzo dedicado.
Intento ver siempre al usuario como cliente: tiene una necesidad y valorará si se le cumple, tendrá que pagar por el coste del proyecto (y su mantenimiento) y me volverá a contratar no si he hecho lo que me ha dicho, sino si está satisfecho. Siempre es un proceso de venta y compra.
Creo que me he salido un poco del tema, pero lo veremos en otro hilo.

Ruth Ganado 26 Marzo 2010 - 18:47

Mucho más tarde, cuando he tenido un poco de tiempo, tras las sesiones del programa, soy de las que me he dado cuenta que estoy involucrada continuamente en pequeños proyectos y nunca lo había pensado… Sólo un comentario a algunas frases que he leído en comentarios anteriores respecto al tiempo. Decía Mariano, por ejemplo, que “un proyecto casi siempre nace con la fecha fin asignada”. Efectivamente, me veo como parte culpable en esa afirmación pero en el mundo financiero, y desde la parte comercial donde yo me encuentro, es imposible solicitar de otra forma que no sea urgente, por ejemplo un lanzamiento de un producto, porque la realidad del mundo comercial se impone. Sinceramente, nos damos cuenta que se exigen plazos vertiginosos para proyectos ambiciosos pero no es por capricho. El tiempo de reacción de los competidores marca la actividad así como la imposición del negocio propio de la compañía. Siempre tienes en la cabeza la solicitud de un desarrollo para alguna necesidad futura de producto que sabes podrá llegar, pero el día a día se impone y por tanto obliga a los implicados directamente en la gestión del proyecto a abandonar desarrollos “ideales”. Por tanto, según para qué tipo de negocio, parece más importante estar preparado para gestionar proyectos de forma rápida y adaptada a modificaciones posteriores que bajo criterios teóricos de gestión…

[…] restricción del proyecto, tiempo, costes y alcance, aunque a mi personalmente me gustar hablar de la quintuple restricción del proyecto, añadiendo recursos (refiriéndome al tipo de recursos y su actitud) y añadiendo los objetivos […]

Sergio 7 Mayo 2013 - 19:11

1. Un proyecto tiene 2 alcances, el alcance del proyecto y el alcance del producto. Cuando se habla de cambiar el/los objetivos ¿a cuál de ellos se refieren?
2. Si soy el project-manager ¿Debo estar preparado para aceptar cambios en ambos alcances? ¿o debo resistirme con mayor o menor grado a alguno de ellos?

[…] En todo proyecto se dice que existe una triple restricción, que es el tiempo el coste y el alcance. Digámoslo de otra forma, la modificación de cada una de  […]

Ramón 25 Julio 2016 - 17:07

estoy de acuerdo con lo que dice Raul, si se tiene un objetivo bien definido y con la firme convicción de resolver un problema en particular no debe ser una restricción. La organización/recursos si puede ser una restricción excluyendo el recurso humano.

Dejar un Comentario

*

Utilizamos cookies propias y de terceros para mejorar nuestros servicios y mostrarle contenido relacionado con sus preferencias mediante el análisis de sus hábitos de navegación. Si continua navegando, consideramos que acepta su uso. Puede cambiar la configuración u obtener más información aquí. Aceptar