SciELO - Scientific Electronic Library Online

 
 número74Modelo de pesquisa em gestão de projetos para investigação em engenhariaO entorno competitivo para o empreendimento na região Caribe da Colômbia: caso de Barranquilla, Cartagena, Santa Marta e Sincelejo índice de autoresíndice de assuntospesquisa de artigos
Home Pagelista alfabética de periódicos  

Serviços Personalizados

Artigo

Indicadores

Links relacionados

  • Em processo de indexaçãoCitado por Google
  • Não possue artigos similaresSimilares em SciELO
  • Em processo de indexaçãoSimilares em Google

Compartilhar


Revista EAN

versão On-line ISSN 0120-8160

Rev. esc.adm.neg  no.74 Bogotá jan./jun. 2013

 

Programación reactiva en la administración de proyectos: aproximación conceptual y aplicaciones prácticas

Reactive programming in project management: conceptual approach and practical applications

Programmation réactive en gestion de projets: approximation conceptuelle et applications pratiques

Programação reativa na administração de projetos: aproximação conceitual e aplicações práticas

Alexander Garrido*
Julián Carrillo**

*Mágister en Economía de la Universidad Nacional de Colombia; Ingeniero Industrial de la Universidad Distrital Francisco José de Caldas; profesor del Departamento de Ingeniería Industrial de la Universidad Militar Nueva Granada.
**Doctor en Ingeniería de la Universidad Autónoma de México; Mágister en Ingeniería Civil de la Universidad de Los Andes; Ingeniero Civil de la Universidad Militar Nueva Granada; Director del grupo de investigación de Estructuras y Sísmica de la Universidad Militar Nueva Granada.

Fecha de recepción: 8 de marzo Fecha de aprobación: abril 20


Resumen

La incertidumbre en los proyectos es usualmente un aspecto inevitable. Los gerentes de proyectos se previenen de ella gestionando oportunamente los riesgos conocidos en las fases previas a la ejecución del proyecto. Pese a estos esfuerzos, los riesgos no identificados o incontrolables pueden surgir durante la fase de ejecución del proyecto, lo cual afecta negativamente sus Indicadores Claves de Desempeño (ICD) y el objetivo propuesto. Bajo estas circunstancias, el gerente de proyecto es forzado a responder a los riesgos incontrolables o no identificados. Una revisión de la literatura actual sobre administración de proyectos, no proporciona ninguna orientación frente al tema. En este artículo se estudia el enfoque de la programación reactiva a través de un proyecto real, como un modo estructurado de afrontar y medir el efecto de los riesgos incontrolables o no identificados en un proyecto y mantener la consistencia de su línea base.

Palabras claves: Programación reactiva, Administración de proyectos, Incertidumbre, Gestión de riesgos, Riesgos incontrolables, Riesgos no identificados.


Abstract

Uncertainty in research projects is usually inevitable. Project managers get rid of it when identifying appropriately the risks identified in the early stages of project development. In spite of all efforts made, the undetected or uncontrolled risks may arise during the execution stage, which negatively affect the Performance Key Indicators and the stated aim or achievement. Under these circumstances, the Project Manager must respond to those undetected or uncontrolled risks. A revision of the current bibliography about project management doesn´t provide any guideline to solve this problem. In fact, this article is intended to describe the reactive programming focus through a real project made as a well- structured way to face and measure the effects of undetected or uncontrolled risks, as well as to keep up consistency in its line bases.

Key words: Reactive programming, Project management, Uncertainty, Risk management, Undetected and uncontrolled, risks.


Resuméé

L'incertitude est un aspect généralement inhérent aux projets. Les responsables de gestion de projets essaient de contrôler opportunément cet aspect en maitrisant les risques connus des phases préalables à l'exécution du projet. Malgré ces efforts, des risques non identifiés ou incontrôlables peuvent surgir lors de la phase d'exécution risquant d'affecter négativement les Indicateurs Clés de Réussite (ICR) et les objectifs à atteindre. Dans ces circonstances, le responsable de la gestion de projets se voit forcé de maitriser et de contrôler ces risques non identifiés ou incontrôlables. Une étude de la littérature actuelle en gestion de projets n'offre cependant aucune ébauche de solution à notre thème. Dans cet article, nous étudierons l'approche de la programmation réactive au travers d'un projet réel et sa capacité structurée pour affronter et mesurer les effets des risques non identifiés ou incontrôlables du projet et maintenir ainsi sa ligne directrice.

Mots clefs: Programmation réactive, Gestion de projets, Incertitude, Risques non identifiés, Risques non contrôlés.


Resumo

A incerteza nos projetos é usualmente um aspecto inevitável. Os gerentes de projetos evitam-na gerindo oportunamente os riscos conhecidos nas fases anteriores à execução do projeto. Contudo, os riscos não identificados ou incontroláveis podem surgir durante a fase de execução, isto afeta negativamente seus Indicadores Chaves de Desempenho (ICD) e o objetivo proposto. Nestas condições, o gerente de projeto está obrigado a responder aos riscos incontroláveis ou não conhecidos. Uma revisão da literatura atual sobre administração de projetos não providencia orientação nenhuma frente a este tema. Neste artigo estuda-se o enfoque da programação reativa a través de um projeto real, como uma maneira estruturada de afrontar e medir o efeito dos riscos incontroláveis ou não conhecidos em um projeto, e manter a consistência de sua linha base.

Palavras-chave: Programação reativa, Administração de projetos, Incerteza, Gestão de riscos, Riscos incontroláveis, Riscos não identificados.


1. Introducción

La administración de proyectos enfrenta en la actualidad una gran paradoja. De un lado, todos los proyectos del mundo real son sujetos de incesante incertidumbre que se manifiesta de diversos modos (Vose, 2008; Xiang, et al., 2012), tales como recortes no previstos de presupuestos, entregas retrasadas de materiales, sobrecostos, condiciones climáticas adversas, errores humanos, cambios en la precedencia de las actividades, ausentismo laboral, requisitos legales, y en general, asimetrías de información. Desde hace más de una década, desarrollos teóricos formales en el área de administración de riesgos aplicados a proyectos reales (ver por ejemplo a Schuyler, 2001; Hillson, 2009; Cretu, et al., 2011; entre otros) han permeado el modus operandi de los gerentes de proyecto y mitigado los efectos nocivos de la incertidumbre. Sin embargo, en la práctica, es usual que los proyectos sigan siendo planificados y desarrollados bajo supuestos deterministas y estáticos, y las manifestaciones anteriores sean la constante antes que la excepción.

Una explicación plausible a este problema se centra en dos aspectos: primero, según Atkinson, et al. (2006), los gerentes de proyecto pierden el foco de la incertidumbre al estar agobiados por aspectos de planeación y control operativos del proyecto; y segundo, existe un relativo desconocimiento de las herramientas y técnicas de evaluación de riesgos (White y Fortune, 2002). Adicionalmente, aún en el evento en que los gerentes de proyecto identifiquen, evalúen, mitiguen y documenten diligentemente todos los riesgos del proyecto, los riesgos aquellos incontrolables o no identificados permanecen (Collyer y Warren, 2009; Wideman, 1992).

Lo anterior implica indefectiblemente que los gerentes de proyecto se vean abocados de un modo u otro, durante las fases de inversión y ejecución del proyecto, a reaccionar frente a riesgos incontrolables o no identificados. La revisión de la literatura sobre la práctica moderna de la administración de proyectos (Kerzner, 2013; Cleland e Ireland, 2007; Meredith y Mantel, 2011; Badiru, 2011; Bazerman y Moore, 2012) no presenta ninguna orientación o metodología acerca de cómo hacer frente a este tipo de riesgos. Adicionalmente, la revisión de la literatura supone que el gerente de proyectos debe simplemente improvisar alejándose del plan previsto (línea base), con el fin de acelerar la ejecución de las acciones (actividades), o acudir a su intuición a partir de experiencias previas o corazonadas (Leybourne y Sadler-Smith, 2006).

De esta manera, el objetivo principal de este artículo es mostrar, a través del análisis detallado de un proyecto real y del empleo de Indicadores Claves de Desempeño (ICD), un modo estructurado y metódico de afrontar y medir el efecto de los riesgos incontrolables o no identificados en un proyecto, durante la fase de ejecución. Para este propósito recurrimos al enfoque de programación reactiva (Reactive Scheduling), originalmente empleado en el piso de la fábrica para eliminar o mitigar la incertidumbre en la programación de sistemas de producción y más recientemente, en cadenas de suministro (Aytug, et al., 2005; Ivanov y Sokolov, 2012), pero con escasas aplicaciones prácticas en la administración de proyectos. Así mismo, se describen y discuten brevemente los conceptos de proyecto, administración de proyectos y responsabilidades del gerente de proyectos, enfatizando no sólo los supuestos (erróneos) a partir de los cuales se desarrolla regularmente la función de planeación, sino también la necesidad de incluir la incertidumbre en el análisis. Adicionalmente, se definen los fundamentos, estrategias e ICD propuestos para la programación reactiva y se presenta y evalúa críticamente, un caso de aplicación práctico de las dos estrategias fundamentales de la programación reactiva.

2. La incertidumbre en los proyectos

De forma simple, un proyecto es un trabajo que debe ser hecho. De forma elaborada, un proyecto es un esfuerzo de carácter temporal, sujeto a recursos limitados, que se realiza para obtener un resultado particular (producto, servicio, o ambos). En este sentido, administrar un proyecto significa aplicar conocimientos, habilidades y herramientas a las actividades que hacen parte del proyecto, en procura de obtener el objetivo esperado (Duffy y O'Meara, 2002). Esto implica que, en la medida en que el ciclo de vida del proyecto se desarrolla, el gerente del proyecto debe garantizar la administración adecuada de los indicadores claves de desempeño (ICD) asociados a la consecución del objetivo esperado.

La administración eficaz y eficiente de un proyecto consiste en la realización de un conjunto de actividades (interrelacionadas, en serie o en paralelo) involucradas en un proceso de consecución de recursos (físicos, humanos y financieros, principalmente). Estas actividades son llevadas a cabo por miembros de un equipo interdisciplinario, dirigido por un gerente de proyecto, para alcanzar objetivos relacionados con la programación, los costos, el desempeño técnico y los entregables del proyecto. Según Maylor (2010), tales actividades pueden agregarse en cinco funciones representativas: planeación, organización, gestión de personal, dirección y control. En la toma e implementación de decisiones relacionadas con el uso de los recursos aplicados a los propósitos del proyecto, estas funciones se convierten en los principales elementos considerados por el gerente del mismo.

En el marco de la función de planeación de un proyecto, las principales funciones que debe desempeñar el gerente, están relacionadoas con el desarrollo de varias actividades, tales como los objetivos, metas y estrategias; la Estructura en Desglose del Trabajo (EDT); los diagramas de precedencia para establecer la relación lógica de las actividades del proyecto (tecnología del trabajo en el proyecto); la gestión de recursos, y en general, el desarrollo de los requerimientos del plan original del proyecto o línea base (Badiru y Kovach, 2012).

Normalmente, al inicio del proceso de planeación de un proyecto, una de las actividades principales se relaciona con el desarrollo de la línea base (fechas de inicio y finalización planeadas, costo estimado de las actividades y disponibilidad y asignación de recursos), en la cual se supone, en la mayoría de casos, completitud de la información y un ambiente determinístico estático. Es decir, la programación de proyectos se centra en la optimización del desempeño bajo supuestos idealizados de estabilidad del entorno y ejecutabilidad de la solución. Estos supuestos implican, entre otras cosas, aceptar que, (a) el tiempo originalmente estimado de las actividades se cumple cabalmente, (b) los recursos están siempre disponibles, (c) los materiales e insumos siempre llegan a tiempo, (d) las fechas de inicio y finalización de las actividades no cambian, (e) nuevas actividades no son incorporadas, y (f) ninguna actividad previamente programada es eliminada (Herroelen y Leus, 2004).

En la práctica real, no obstante, las actividades de proyectos están sujetas a considerable incertidumbre, que es gradualmente resuelta durante la ejecución del proyecto (Herroelen y Leus, 2005). Según Chapman y Ward (2002), la incertidumbre se define como la ocurrencia de eventos futuros desconocidos que no pueden ser predichos cuantitativamente dentro de límites útiles. Por otro lado, Miller y Lessard (2001) definen la incertidumbre como la diferencia entre la cantidad de información requerida para ejecutar una tarea y la cantidad de información disponible. Si un proyecto es capaz de absorber la ocurrencia de eventos inesperados, este será considerado robusto y, por tanto, es imprescindible incorporar la incertidumbre al proceso de administración de proyectos para minimizar sus efectos y alcanzar la robustez.

De acuerdo con Smith (1995), la administración de proyectos en la práctica es un proceso reactivo donde las circunstancias evolucionan y cambian continuamente, forzando la reconsideración y revisión de los planes preestablecidos. Indudablemente, como se discute en la siguiente sección, la programación reactiva de proyectos es un enfoque que permite incorporar la incertidumbre al proceso de administración de proyectos.

3. La programación reactiva

La programación reactiva se fundamenta en la concepción de la línea base. Según Policella y Rasconi (2005), una línea base consiste en la asignación de tiempos iniciales y finales a un conjunto de actividades de un proyecto en un orden predefinido, sujeto a restricciones. Concretamente, la programación reactiva revisa o reoptimiza la línea base cuando ocurre un evento inesperado (Leus, 2003). De esta manera, en la fase de planeación del proyecto (inversión), el gerente del mismo y su equipo de trabajo, diseñan esta línea base y establecen como prioridad el propósito particular que desean alcanzar (entregable principal en el nivel 0 de la EDT). Luego, en la fase de ejecución (operación), ante la "segura ocurrencia de eventos imprevistos" o ante situaciones anómalas detectadas durante revisiones periódicas, el gerente del proyecto debe reaccionar para minimizar los efectos negativos de tales eventos en los costos del proyecto, y en lo que Hopp y Spearman (2000) denominan Makespan o tiempo total de ejecución del proyecto.

Una acción reparadora es una técnica simple de restauración de la consistencia de la línea base. Por la simplicidad de esta estrategia, es considerada un extremo del conjunto de posibles estrategias de la programación reactiva, en la medida en que, cada vez que ocurre un evento inesperado, la acción reparadora consiste sólo en desplazar hacia adelante (empujar), en el tiempo, la ejecución de las actividades subsecuentes del proyecto, siempre que la holgura de tiempo entre las actividades lo permita. En la literatura de proyectos este concepto es conocido como Right Shift Rule o regla de desplazamiento a la derecha (Sade, 1991; Smith, 1995).

Los tipos de actividades que hacen parte de un proyecto pueden facilitar las acciones reparadoras de una línea base. Así, si se tienen tareas de unidades fijas, es decir, actividades que están en función de los recursos asignados (por ejemplo, un trabajador invierte cuatro horas en limpiar una casa, dos trabajadores necesitarán sólo dos horas), se reducirá su tiempo de ejecución al destinar más recursos a ese tipo de tareas. Esto no sería posible si se tienen actividades de duración fija (por ejemplo, la realización de un trámite legal ante una autoridad), o no se dispone de recursos adicionales.

Los tipos de dependencias entre las tareas también pueden facilitar las acciones reparadoras. Si un proyecto presenta dependencias del tipo "fin a comienzo", esto es, si una tarea sucesora no puede comenzar antes de que la predecesora termine, entonces el gerente del proyecto tiene menos restricciones para empujar las tareas subsecuentes hacia adelante en el tiempo; contrario a lo que sucedería si las dependencias fuesen del tipo "comienzo a fin", "comienzo a comienzo" o "fin a fin". Adicionalmente, según la Ley de Parkinson (1955), en la fase de inversión, el gerente del proyecto normalmente sobredimensiona los tiempos de duración de las actividades del proyecto para enfrentar la incertidumbre, y luego, debido a la "naturaleza humana" (síndrome del estudiante), ese mismo gerente desperdicia el tiempo ganado al iniciar las actividades en el tiempo de inicio más tardío (Goldratt, 1997).

El otro extremo del conjunto de posibles estrategias de la programación reactiva, es la reprogramación total de las actividades posteriores a la ocurrencia de un evento inesperado, o a la revisión periódica de la línea base. Para Demeulemeester y Herroelen (2002), la reprogramación total es un enfoque dinámico que responde a eventos inesperados, considera información futura y al mismo tiempo, crea un nuevo programa. Esto significa que, ante la imposibilidad de implementar una acción reparadora, el gerente del proyecto es obligado tanto a cambiar por completo la secuencia de las actividades de la línea base, como a incluir nuevas tareas, o incluso, a eliminarlas. El nuevo programa (que el gerente espera sea la mejor decisión) será aquel que minimice los ICD L del proyecto (Atkinson, 1999; Pinedo, 2008). En este caso, la consistencia de la línea base no podrá ser mantenida. Los índices y los Indicadores Claves de Desempeño (ICD) que permitirán evaluar ambas estrategias se describen a continuación en la tabla y tabla 2, respectivamente.

En el contexto de la administración de proyectos, según la clasificación propuesta por Vieira, et al. (2003), el ambiente de reprogramación es, por una parte, estático, dado que el número de actividades por realizar es finito, y por otra, estocástico, debido a que existe algún nivel de incertidumbre. Así mismo, las políticas de reprogramación pueden ser determinadas por la ocurrencia de eventos inesperados, por revisiones periódicas, o por una mezcla de ambas. En resumen, la programación reactiva en la administración de proyectos puede ser esquematizada (figura 1).

4. Estudio de aplicación y discusión

En este caso se considera la línea base de un proyecto de instalación de tuberías (proyecto real), bajo condiciones de completitud de la información y un ambiente determinístico estático (tabla 3)

La red del proyecto (figura 2), bajo el esquema AOA (Activity- On-Arc) y numerada según la regla de Ford-Fulkerson (1962), complementa la tabla 3. Esta tabla describe 16 actividades reales (n) y 1 ficticia (S_1), además de sus tiempos de inicio y finalización (más próximo y más tardío). La ruta crítica del proyecto es A-C-F-G-H-K-M-O-P (resaltada), con una duración de 25.68 semanas (tP) y un costo de $47 millones (crcP). Igualmente, en la tabla 4 se presenta el análisis de criticidad de las actividades del proyecto. El costo total del proyecto se calcula en $79 millones (cP).

En la tabla 5 se indican los ICD del proyecto previstos después de las estrategias de reparación y reprogramación total. Estos ICD se calculan a partir de las ecuaciones presentadas anteriormente (tablas 1 y 2). Con base en la programación indicada en la figura 1, se supone que en la fase de ejecu-ción del proyecto (finales de la semana 21; figuras 3 y 4), la consistencia de la línea base (robustez del proyecto) planteada a partir de los ti Pse de la tabla 2 es afectada por la ocurrencia de un evento inesperado (riesgo incontrolable o no identificado).

El gerente del proyecto dispone de dos alternativas (figura 1): (a) reparar las actividades del proyecto, esto es, aplicar la regla Right Shift; o (b) reprogramar totalmente las actividades. En el primer caso, debido a que las actividades M y O son críticas, y dado que su naturaleza (rellenar y limpiar) depende de los recursos asignados (tareas de unidades fijas), la única opción que puede reparar la consistencia de la línea base del proyecto consistirá en acortar la duración de M, O, o ambas, en al menos una semana (magnitud del retraso), lo cual implicará intercambiar recursos financieros y de personal por tiempo. El costo de quiebre o incremento promedio de los costos de las actividades M y O se estima en ΔcM,O =$5 millones (figura 3).

En el segundo caso, se parte de la premisa de que no puede mantenerse la consistencia de la línea base como consecuencia de la ocurrencia de un retraso imprevisto en la actividad M. Con base en estas circunstancias, el gerente puede reprogramar las actividades del proyecto al romper las relaciones de precedencia entre las actividades M y O.

El retraso en la actividad M será corregido en periodos posteriores. Es importante notar (tabla 5) que, a pesar de que varios ICD no fueron afectados (tP,R, tP,R, cP y crcR), la programación del proyecto no es consistente con respecto de a la línea base originalmente prevista (figura 4).

La ocurrencia de un evento inesperado a finales de la semana 21 se ha dispuesto convenientemente para que afecte a las actividades M y O, debido a que no poseen holgura de tiempo (tM,OPfe-Pse = 0) y por tanto, no pueden ser reprogramadas sin afectar la consistencia del programa base del proyecto. El análisis de la estrategia reparadora (figura 3), ha supuesto para el gerente del proyecto dos aspectos. Por un lado, que el objetivo de política de mantener la consistencia del programa base originalmente previsto, es el aspecto más importante del proyecto, es decir, que no hay costos prohibitivos para redu-cir la duración prevista (ti P) de las actividades señaladas. Por otro lado, que el gerente del proyecto dispone de medidas especiales que incluyen, entre otras, el empleo de horas extras, la contratación temporal de cuadrillas de trabajadores y el uso de maquinaria y equipos especiales o materiales determinados que ahorren tiempo. La elección entre reducir la duración de la actividad M o reducir la duración de la actividad O depende del análisis de costo marginal (Glover, et al., 1992), que para el caso analizado se estima indiferente (ΔcM,O =$5 millones).

De otra parte, el análisis de la estrategia de reprogramación total (figura 4), involucra en general el cumplimiento de un supuesto fuerte, es decir, la eliminación de la relación de precedencia de las actividades de un proyecto, las cuales fueron determinadas en la etapa de planeación (fase de inversión). Como se mencionó en la descripción de las actividades (tabla 3), la M corresponde a labores de "relleno", mientras que la actividad O se asocia con labores de "limpieza", lo que obliga a preguntarse si esta relación de precedencia puede o no ser simplemente eliminada en la práctica. Para algunos autores (Kerzner, 2013; Pryke y Smyth, 2006), la respuesta depende del tipo de interrelación entre las actividades de un proyecto (obligatoria, discrecional o externa). En el caso práctico analizado, se considera que la relación de precedencia entre las actividades M y O es de tipo discrecional, debido a que no puede establecerse entre ellas una condición de precedencia necesaria y suficiente, o en otras palabras, la actividad de "limpieza" del proyecto puede iniciar aun cuando la actividad de "relleno" no haya finalizado totalmente.

5. Conclusiones

El análisis del desempeño del proyecto aquí estudiado frente a la aparición de un evento imprevisto en la fase de ejecución, ha evidenciado importantes lecciones para los gerentes de proyectos. En primer lugar, los procesos de gestión de riesgos en los proyectos particularmente, aquellos asociados a la planificación, determinación, caracterización y documentación de los riesgos que pueden afectar un proyecto, no son en modo alguno infalibles, y por el contrario, son proclives a errores y fallas (Thamhain, 2013). Los manuales de proyectos destacan que, "los riesgos desconocidos específicos no pueden gestionarse de manera proactiva, lo que sugiere que el equipo de proyecto debe crear un plan de contingencia" (Project Management Institute, 2008). Sin embargo, cabe preguntarse si es posible crear un plan de contingencia frente a un riesgo desconocido o inesperado. Los autores consideran que esto no es posible bajo estas circunstancias, al menos un plan adecuado.

Consecuentemente, los gerentes de proyecto deben responder, pero no de cualquier modo; deben hacerlo empleando el enfoque racional de la programación reactiva.

La programación reactiva es un recurso de contingencia estructurado ante la ocurrencia de eventos inesperados que impactan la ejecución normal del proyecto. Su objetivo es claro: mantener la consistencia de la línea base del proyecto. En el entorno real de los proyectos, su aplicación está supeditada a la disponibilidad de recursos financieros y humanos (plan de contingencia), en el caso de estrategias reparadoras; o a la capacidad del proyecto para ser ágil, flexible y adaptable (Schroeder y Hatton, 2012), en el caso de la estrategia de reprogramación total.

Finalmente, la programación reactiva no reemplaza la gestión de riesgos proactiva en las fases de preinversión e inversión de un proyecto. El enfoque de programación reactiva debe ser utilizado por los gerentes de proyecto como complemento en la planificación de los procesos de gestión de riesgos no identificados o incontrolables en un proyecto.


6. Referencias

Atkinson, R., (1999). Project management: cost, time and quality, two best guesses and a phenomenon, it''s time to accept other success criteria. International Journal of Project Management, 17 (6), 337-342.         [ Links ]

Atkinson, R., Crawford, L., y Ward, S. (2006). Fundamentals uncertainties in projects and scope in project management. International Journal of Project Management, 24, 687-698.         [ Links ]

Aytug, H., Lawley, M., McKay, K., Mohan, S. y Uzsoy, R. (2005). Executing production schedules in the faces of uncertainties: A review and some future directions. European Journal of Operations Research, 161 (1), 86-110.         [ Links ]

Badiru, A. (2011). Project Management: Systems, Principles and Applications. Boca Ratón, FL: CRC Press.         [ Links ]

Badiru, A. y Kovach, T. (2012). Statistical Techniques for Project Control. Boca Ratón, FL: CRC Press.         [ Links ]

Bazerman, C. y Moore, D. (2012). Judgment in Managerial Decision Making. Baffins Lane, UK: John Wiley & Sons, Ltd.         [ Links ]

Chapman, C. y Ward, S. (2002). Managing Project Risk and Uncertainty: Constructively Simple Approach to Decision Making. Baffins Lane, UK: John Wiley & Sons, Ltd.         [ Links ]

Cleland, D. y Ireland, L. (2007). Project Management: Strategic Design and Implementation. (5th ed.). New York, NY: The McGraw-Hill Companies, Inc.         [ Links ]

Collyer, S. y Warren, C. (2009). Project management approach for dynamic environments. International Journal of Project Management, 27 (4), 355-364.         [ Links ]

Cretu, O., Stewart, R. y Berrends, T. (2011). Risk Management for Design and Constructions. Princeton, NJ: John Wiley & Sons,         [ Links ] Ltd.

Demeulemeester, E. y Herroelen, W. (2002). Project scheduling. A research handbook. New York, NY: Kluwer Academic Publishers.         [ Links ]

Duffy, M. y O'Meara, M. (2002). Harvard Manage Mentor on Project Management. Boston, MA: Harvard Business School Publishing Corporation.         [ Links ]

Ford, L. y Fulkerson, D. (1962). Flows in Networks. Princeton, NJ: Princeton University Press.         [ Links ]

Garrido, A. (2010). Metodología de Valor Ganado (EVM) y CPM-PERT en el control presupuestal de un proyecto de inversión: estudio de caso de un proyecto de la construcción. Notas Gerenciales Universidad Javeriana, 20, 60-66.         [ Links ]

Glover, F., Klingman, D. y Phillips, N. (1992). Networks Models in Optimization and Their Applications in Practice. New York, NY: John Wiley & Sons, Inc.         [ Links ]

Goldratt, E. (1997). The Critic Chain. Great Barrington, M.A.: The North River Press.         [ Links ]

Herroelen, W., y Leus, R. (2004). Robust and reactive project scheduling: a review and clasification of procedures. International Journal of Production Research, 42 (8), 1599-1620.         [ Links ]

Herroelen, W., y Leus, R. (2005). Project scheduling under uncertainty: Survey and research potentials. European Journal of Operational Research, 165, 289-306.         [ Links ]

Hillson, D. (2009). Management Risk in Projects: Fundamentals of Project Management Farnham, Surrey, UK: Gower Publishing Company.         [ Links ]

Ivanov, D. y Sokolov, B. (2012). Dynamic supply chain scheduling. Journal of scheduling, 15 (2), 201-216.         [ Links ]

Kerzner, H. (2013). Project Management: A System Approach to Planning, Scheduling and Controlling. (11th ed.). Hoboken, NJ: John Wiley & Sons, Ltd.         [ Links ]

Leybourne, S. y Sadler-Smith, E. (2006). The role of intution and improvisation in project management. International Journal of Project Management, 24 (6), 483-492.         [ Links ]

Leus, R. (2003). The generation of stable project planning: Complexity and exact algorithms (Doctoral dissertation Tesis doctoral, Katholieke Universiteit Leuven). Recuperada de http://www.econ.kuleuven.be/public/ndbac96/phd%20Roel%20Leus.pdf.         [ Links ]

Maylor, H. (2010). Project Management. (4th ed.). Harlow, England: Pearson, Ltd.         [ Links ]

Meredith, J. y Mantel, S. (2011). Project Management: A Managerial Approach. (8th ed.). New Jersey, USA: John Wiley & Sons, Ltd.         [ Links ]

Miller, R. y Lessard, D. (2001). Understanding and managing risks in large engineering projects. International Journal of Project Management, 19, 437-443.         [ Links ]

Parkinson, N. (1955). Parkinson´s Law. The Economist. Recuperado de http://www.economist.com/node/14116121.         [ Links ]

Pinedo, M. (2008). Scheduling. Theory, algorithms, and systems. (3th ed.). New York, NY: Springer.         [ Links ]

Policella, N. y Rasconi, R. (2005). Testsets Generation for Reactive Scheduling. Workshop on Experimental Analysis and Benchmarks for AI Algorithms, Ferrara, Italy, 29-36.         [ Links ]

Prike, S. y Smyth, H. (2006). The Management of Complex Projects: a relationship approach. Oxford, UK: Blackwell Publishing Ltd.         [ Links ]

Project Management Institute, Inc. (2008). A Guide to the Project Management Body of Knowledge: PMBoK® Guide. (4th ed.). Newton Square, PA: Autor.         [ Links ]

Sadeh, N. (1991). Look-ahead techniques for micro-opportunistics job shop scheduling (Tesis Ddoctoral dissertation, Carnegie Mellon University). Recuperado de http://search.library.cmu.edu.         [ Links ]

Schroeder, K. y Hatton, M. (2012). Rethinking risk in development projects. Development in Practice,. 22 (3), 409-416.         [ Links ]

Schuyler, J. (2001). Risk and Decision Analysis in Projects. (2th ed.). Newton Square, PA: Project Management Institute, Inc.         [ Links ]

Smith, S. (1995). Reactive scheduling systems. In Brown, D., y Scherer, W. (Eds.), Intelligent Scheduling Systems (ch. 11). New York, NY: Kluwer Academic Publishers.         [ Links ]

Thamhain, H. (2013). Managing risk in complex projects. Project Management Journal,. 44 (2), 20-35.         [ Links ]

Vieira, G., Herrmann, J., y Lin, E. (2003). Reschedulig manufacturing systems: A framework of strategies, policies, and methods. Journal of Scheduling, 6, 39-62.         [ Links ]

Vose, D. (2008). Risk Analysis. A Quantitave Guide (3th). Great Barrington, West Sussex, England: John Wiley & Sons, Ltd.         [ Links ]

Wideman, R. (1992). Project and program risk Management. A guide to project risk and opportunities. Newton Square, PA: Project Management Institute.         [ Links ]

White, D. y Fortune, J. (2002). Current practice in project management-An empirical study. International Journal of Project Management, 20 (1), 1-11.         [ Links ]

Xiang, P., et al, (2012). Construction Project Risk Management Based on the View of Asymmetric Information. Journal of Construction Engineering & Management, 138 (11), 1303-1311.         [ Links ]