
Anteriormente hablamos de los supuestos del proyecto, en esta ocasión miramos hacia las restricciones. Ambos temas afectan o podrían afectar directamente el desempeño y planificación del proyecto, así como su cumplimiento. Las restricciones son, en sí, la camisa de fuerza que nos limita.
Según el PMBOK, las restricciones (constrains) son “el estado, calidad o sentido de estar restringido a un determinado curso de acción o inacción. Una restricción o limitación aplicable, sea interna o externa al proyecto, que afectará el desempeño del proyecto o de un proceso“.
Estoy seguro que habrán visto más de una vez el triángulo de la “triple restricción”. Los limitantes básico de los proyectos dados por el tiempo, los recursos y el alcance, corresponden al día a día de las negociaciones con clientes, proveedores, equipo y stakeholders.
Por lo anterior, es muy importante y mandatorio dejar las reglas e identificar las restricciones desde el inicio del proyecto. Mejor dicho, desde la conceptualización o propuesta comercial, si vale el término. Así como los supuestos, las restricciones tienen un alto impacto en temas como: costos, cronograma, fechas de entrega, etc.
Las restricciones vendrán dadas en temas como:
Con los puntos anteriores se podrán negociar escenarios como:
Como bien dijo alguna vez un profesor : “No te adelantes a decirle al cliente que no se puede, en cambio, negocia con las restricciones“.
En resumen, es importante desde el inicio saber exactamente cuáles son las restricciones que limitan el proyecto, y de esas, conocer cuál es la más importante para saber por donde poder negociar… Y si para el cliente “todo es importante”, entonces, le cuentan el ejemplo del globo. ![]()
Hola,
Solo quería hacer una pregunta, quizás no sea muy importante, pero llevo un tiempo dándole vueltas y al leerlo aquí se me ha ocurrido plantearla. Es tan solo a cerca de la palabra “requerimiento” hace algún tiempo yo defendía su uso pero tras una discusión con alguien del ambiento jurídico me hizo ver que el significado de requerimiento no es exactamente el de requisito, ya que según RAE requerimiento implica el acto de realizar una petición jurídica, lo que a mi entender, abarca algo que no se ciñe a los requisitos establecidos para un proyecto. Así que, resumiendo ¿es requerimiento un termino correcto en estos ambitos de proyectos, o es simplemente una rápida traducción del termino en inglés “requirement”?
Muchas gracias y un saludo
Hola joe,
Puede que te parezca un poco atrevida mi pregunta…pero cual es el ejemplo del globo?? que lo hinchas…lo hinchas…y lo hinchas??
saludos
Q tal Joe, un complemento a tu idea:
Este tema de las restricciones podría ser manejado con negociaciones de alcance corto, más que nada si es que el cliente te “exige” contratos de precio fijo (hecho muy común en el medio local). Este problema lo tuve hace algún tiempo cuando negocié el alcance de un proyecto de software y el cliente no tenía muy clara la idea de hasta donde llegar y qué hacer, en aquella ocasión la rentabilidad del proyecto cayó casi a pérdida.
El tema de las restricciones, y otros como las asunciones e incluso los objetivos del proyecto, se puede manejar con un adecuado plan de comunicaciones. Qué pasaría si trabajas por tu cuenta, has incurrido en costos y el cliente de pronto te dice q el objetivo del proyecto ya no es necesario? R. Comunicaciones efectivas.
Totalmente de acuerdo con tu enfoque de negociación.
Saludos.
Hola Joe, un gusto estar en contacto y saber que alguien en Ecuador fomenta metodologias para el desarrollo de proyectos. Muy bueno tu blog lo tendre presente y espero poder compartir ideas y experiencias en proyectos (en mi caso los proyectos informaticos son mi fuerte)
Saludos
Amigo, no me dejes con la curiosidad , cual es el ejemplo del globo?
Que tal Ernesto:
Mira, el ejemplo del globo quizá te parezca muy sencillo pero para mi fue muy “gráfico”.
Un profesor nos decía que un proyecto es como un globo. Este globo imaginariamente está dividido por 9 partes (comunicacion, RRHH, Costos, Tiempo, etc.).
Él nos decía que cuando viene el usuario o cliente a pedir un cambio imaginemos al globo hundiendose por un lado. Luego cuando se quita un recurso, se hunde otro lado mas del globo. Cuando el jefe pide disminuir el tiempo, se aprieta más el globo… hasta que explota!
En ocasiones uso este ejemplo básico para explicarles a los clientes qué puede pasar si se juega sin control con las diversos elementos que tiene un proyecto.