1
75
29955) WM. 11
ADMINISTRACIÓN DE PROYECTOS
ADMINISTRACIÓN DE PROYECTOS
TED KLASTORIN Uni1•ersity of Washingron
A
Alfaomega
Traducción al español: María del Carmen Hano Revisión técnica y cuidado de la edición: M. en C. Marcia A. González Osuna Diagrarnación electrónica: Ediámac
Primera edición: México, septiembre 2005 Décima segunda reimpresión: México, febrero 2013
Versión en español de la obra titulada en inglés: Project Managemem: Tools and Trade-0/fs. por Ted Klastorin, publicada originalmente por © John Wiley & Sons, lnc.
© 2005 Alfaom ega G rupo Edito r, S.A. de C.V. Pitágoras 1139, Col. Del Valle, 03100 México, D.f.
Miembro de la Cámara Nacional de la Lndustria Editorial Mexicana Registro No. 23 17 Pág. Web: http:l/www.alfaom ega.com.m x E-mail: atencio na lcliente@a lfabm ega.co m.m x Derechos reservados. Esta obra es propiedad intelectual de su autor y los derechos de publicación en lengua española han sido legalmente transferidos al editor. Prohibida su reproducción parcial o total por cualquier medio sin permiso por escrito del propietario de los derechos del copyright.
NOTA IMPORTANTE La información contenida en esta obra tiene un fin exclusivamente didáctico y, por lo tanto, no está previ sto su aprovechamiento a nivel profesional o industrial. Las indicaciones técnicas y programas incluidos, han sido elaborados con gran cuidado por el autor y reproducidos bajo estrictas normas de control. ALFAOMEGA GRUPO EDITOR, S.A. de C.V. no será jurídicamente responsable por: errores u omisiones; daños y perjuicios que se pudieran atribuir al uso de la información comprendida en este libro y en el CD-ROM adjunto. ni por la util ización indebida que pudiera dársele. IS BN 970-15-1099-2 ISBN 0-471-41384-4, versión original de John Wiley & Sons, Jnc. Im preso en México - Printed in Mexico
A Susan, Rachel y Anna cuyas presencias son mi bendición
CONTENIDO BREVE
xiii
PR6WGO
ACERCA DELAUTOR
xvii
CAPÍTULO 1
INTRODUCCI6N A LA ADMINISTRACI6N DE PROYECTOS
CAPÍTULO 2
INICIO, SELECCI6N Y PLANEACI6N DE UN PROYECTO
CAPÍTULO 3
EQUIPOS DE PROYECTO Y RELACIONES ORGANIZACIONALES
CAPÍTULO 4
REDES DE PRECEDENCIAS Y EL MÉTODO DE LA RUTA CRÍTICA (CPM)
CAPÍTULOs
PLANEACI6N PARA MINIMIZAR COSTOS
CAPITULO 6
PLANEACI6N CON INCERTIDUMBRE
CAPITULO 7
ADMINISTRACI6N DEL RIESGO
CAPÍTULO 8
ADMINISTRACI6N DE RECURSOS
CAPITULO 9
SUPERVISI6N Y CONTROL
CAPITULO 10
ADMINISTRACI6N DE PROYECTOS M0LTIPLES
1
23
62
83
10 7
135
165
·-<>
EPÍWGO
APÉNOICE
fN DICE
175
20 5
218
225
PROYECTO DE UN RADAR MARINO PORTÁTIL COMO COPIWTO
227
231
HD69.P75 K 11
2005 EJ.4 (29955) BIB. NUM.
11 vii
CONTENIDO
PROWGO
xiii
ACERCA DEL AUTOR
CAPÍTULO 1
xvii
INTRODUCCIÓN A LA ADMINISTRACION DE PROYECTOS
¿Qué define un proyecto?
3
No todos los proyectos son iguales
4
Medidas de éxito o fracaso de un proyecto
7
Resullados de un proyecto de tecnología de la infonnación ¿Cuándo "abandonar" un proyecto? Ciclo de vida de un proyecto
12
Trueques en la administración de proyectos Alcance de este libro
10
11 13
16
Administración de los riesgos de un proyecto Historia de la administración de proyectos Software para administración de proyecws Project Management Institute
16
17 18
18
Modelos de madurez en administración de proyectos
19
Apéndice 1A. .Jransacciones Medicare: una lección en administración de proyectos de 50 millones de dólares 19 Problemas para estudio Referencias CAPÍTULO 2
21
22
INICIO, SELECCIÓN Y PLANEACIÓN DE UN PROYECTO
Inicio y selección de un proyecto Medidas numéricas 25 Enfoque de opciones reales
24 33
Métodos de calificación y clasificación Evaluación del portafolio de proyectos Planeación del proyectos
34
37
41
Estructura desglosada del trabajo (EDT) Estimación de costo y duración de las tareas Manejo de la incertidumbre Conclusiones 53 Problemas para estudio
23
43 46
48
54
Referencias 58 Apéndice 2A. Cristóbal Colón. lnc., viaje para descubrir rutas comerciales a Asia
59
ix
29955-
-.- ....
X
CONTENIDO
CAPITULO 3
EQUIPOS DE PROYECTO Y RELACIONES ORGANIZACIONALES
Papel y responsabi lidades del administrador de proyectos y el equipo del proyecto Características de Wl equipo de proyecto efectivo 67 Diversidad en los equipos de proyecto Equipos de proyecto e incemivos Fonnación de equipos de proyecto Programación extrema
69 70
72
Subcontratación y sociedades Conclusiones
CAPITULO 4
72
76 80
80
Problemas para estudio Referencias
80
81
REDES DE PRECEDENCIAS Y EL MÉTODO DE LA RUTA CRITICA (CPM)
Definición de redes de precedencias
83
83
Redes de precedencias de actividades en los nodos (AON) Redes de precedencias de actividades en los arcos (AOA) Comparación de las redes AOA con las redes AON Método de la ruta crítica (CPM): conceptos y cálculos Cálculos con una hoja de cálculo
Programación del proyecto y diagramas de Gantt Cálculos del CPM para redes AOA
84 84
85
86
90
Definición de holguras (jlowmes) 91 Formulaciones de programación lineal
93 95
97
Fom'lulación de programación matemática para las redes AOA Conclusiones
99
100
Problemas para estudio
100
Apéndice 4A. Trazo de un diagrama de Ganu con MS-Excel Apéndice 4B. Relaciones de precedencia alternativas
~CAPÍTULO 5
62
68
Estrucrura organizacional y administración de proyectos Sociedades y alianzas
62
PLANEACIÓN PARA MINIMIZAR COSTOS
Presupuesto del proyecto
103
104 107
108
Incertidumbre en el presupuesto Ejemplo de presupuesto
109
110
Administración de los fluj os de efeclivo
112
Compresión del proyecto: trueques tiempo-costo Trueques lineales tiempo-costo Trueques no lineales tiempo-costo Trueques tiempo-costo discretos
115
117 121 123
Tnteques tiempo-costo con consideraciones de coordinación y comunicación Costos de materiales e inventario Problemas para estudio
129
126
125
CONTENIDO
Referencias 132 Apéndice SA. Relación entre el valor presente neto y los meses-dólar CAPÍTULO 6
PI.ANEACIÓN CON INCERTIDUMBRE
Definición de PERT clásico 135 Limitaciones de/modelo PERT Clásico
133
135
139
Modelos de simulación Monte Cario 14 3 Simulación Monte Cario con distribuciones de probabilidad discretas 145 Ejemplo de desarrollo de un nuevo producto: ciclos en las redes de precedencias Teoría de resticciones y el amortiguador del proyecto 149 Otras implicaciones de la incertidumbre en el proyecto 152 Comportamiento de los trabajadores y duración esperada del proyecto Variación en la tarea y duración esperada del proyecto 155 Compresión del proyecto con duraciones inciertas de las tareas 156 Conclusiones 158 Problemas para estudio
153
158
Referencias 162 Apéndice 6A. Tabla de la distibución normal estándar (valores positivos de z) 163 Apéndice 6A (cont.). Tabla de la distibución normal estándar (valores positivos de z) CAPiTULO 7
ADMINISTRACIÓN DEL RIESGO
Herramientas para analizar el riesgo del proyecto Tipos de contrato y riesgo relativo 168 Caso de estudio de administración del riesgo
1 65 166
170
Uso de un modelo de costos para evaluar y administrar riesgos Riesgos en proyectos de desarrollo de nuevos productos 173 Problemas para estudio 173 Referencias 174 CAPiTULO 8
146
ADMINISTRACIÓN DE RECURSOS
171
175
El problema de nivelación de recursos 175 Problema de asignación de recursos 180 Soluciones factibles para el problema de asignación de recursos renovables 185 Algoritmos heurísticos para el problema de asignación de recursos renovables 187 Algoritmos basados en las tareas (heurísticos en serie) 188 Algoritmos basados en el tiempo (heurísticos en paralelo) 188 Problema de asignación de recursos renovables con solución sencilla 190 Asignación de recursos y la cadena crítica 192 Capacidades del software comercial para la asignación de recursos 193 Problemas de asignación de recursos no renovables 195 Problemas de asignación de recursos con tareas de duración aleatoria 198 Conclusiones 202 Problemas para estudio 202 Referencias 204
164
Xi
XÍÍ
CONTENIDO
CAPÍTULO 9
SUPERVISIÓN Y CONTROL
205
Diseño efectivo de un sistema de supervisión 205 Enfoque del valor ganado 207 Enfoque delmlor ganado: ejemplo 2 210 Actualización de las estimaciones de costo y programa Conclu siones 214 Problemas para estudio 215 Referencias 217 CAPÍTULO 10
213
ADMINISTRACIÓN DE PROYECTOS MÚLTIPLES
Tareas múhiples con proyectos múhiples Juego K&B del clip 219 Equipos de proyecto e incentivos 220
218
Asignación de recursos y designación de fechas de entrega en un entorno de proyectos múltiples Conclusiones 223 Referencias 223 Apéndice 1OA. Pete Moss: contador EPIWGO
APÉNDICE
218
221
223
225
PROYECTO DE UN RADAR MARINO PORTÁTIL COMO CO PILOTO
Antecedentes 227 Mano de obra 227 Técnicos 229 Programadores 229 Trabajadores de la línea de ensamble Ingenieros de dise1io
229
229
Finanzas 230 El Juego 230 El tablero 230 Supervisión del juego 230 Inicio del juego 230 Financiamiento para el proyecto (préstamo a largo p/aw) Para jugar el juego 231 Fusiones y adquisiciones 231 Licencias de tecnología 231 Terminación del juego 231 Hoja de requerimientos para las actividades 232 Remar espacio oficinas/producción 232 Ordenar equipo de laboratorio 232 Comunicados de prensa 232 Preparación de espacio de oficinas/producción Dise1io de unidades físicas 233
233
230
2 27
CONTENIDO
Diseño de partes electrónicas y circuitos Programación
Ensamble de la unidad prototipo Prueba beta del prototipo
234
234
Prueba de mercado 234 Preparación de la instalación de producción Aprobaciones del gobierno Obtención de la certificación Producción y ventas
ÍNDICE
237
....
233
234
235
235 235
234
XÍÍÍ
PRÓLOGO
Durante la mayor parte de mi carrera profesional , he tenido un gran interés en el área de administración de proyectos (AP), pero ese interés en el área se intensificó hace casi 19 años cuando comencé a trabajar con Microsoft Corporation para diseñar la versión original de su software de AP, Microsoft Project. Al mismo tiempo, comencé a trabajar en varios proyectos como administrador y cons ultor. Al continuar mi trabajo en el área de AP, mi frustración creció debido a la "desconexión" que encontré entre las técnicas que se habían desarrollado para ayudar a los administradores de proyectos y los problemas complejos y los aspectos a los que se enfrentaban los administradores de proyectos de la vida real. Como resultado, comencé a desarrollar materiales para manejar estos aspectos complejos y los trueques o intercambios que casi todos los administradores de proyectos se plantean, y para ilustrar cómo y cuándo las técnicas de AP pueden ser útiles. Para probar estos materiales desarrollé un curso optativo de la maestría en administración de proyectos en la Universidad de Washington y comencé a refinar el material del curso con la ayuda de colegas, estudiantes y profesionales. Dada la creciente importancia del modelado en hojas de cálculo en casi todos los planes de estudio de las universidades, basamos muchos de estos materiales en plantillas de hojas de cálcul o. El material que tuvo éxito en los experimentos educativos forma la base de este libro. Además, incluí muchos conceptos nuevos que están explorando tanto académicos como profesionales en la práctica, y relacioné estas ideas (como el concepto de cadena crítica de Goldrall) con enfoques anteriores. Por último, intenté incluir muchas ideas nuevas de investigaciones recientes; mucho de este trabajo ha sido invisible para los administradores en la práctica, pero tiene implicaciones significativas y debe llevarse al salón de clase, a los programas para ejecutivos y a las salas de conferencias. Ha sido muy gratificante ver el éx.ito que ha tenido este curso; es uno de los cursos optativos más populares en la maestría en la Escuela de Administración de la Universidad de Washington (UW). Además, ofrecemos un curso optativo en el programa de licenciatura, así como un curso obligatorio de AP en la maestría en Administración Tecnológica y en nuestro nuevo programa de maestría en ciencias en Sistemas de Información. Otros cursos relacionados con AP se ofrecen en administración de la construcción (arquitectura), ingeniería industrial, administración de servicios de salud (Escuela de Salud Pública y Medicina Comunitaria), comunicación técnica y en recursos forestales. Es evidente que ésta es un área que cobra cada vez más importancia. Espero que este libro y el material relacionado anime y ayude a otros profesores a desarrollar e impartir sus propios cursos de AP. Al escribir este libro, mi meta es describir los fundamentos sobre Jos que se apoyan casi todas las decisiones de administración de proyectos, y relacionar estos fundamentos con las necesidades y objetivos de los profesionales en la práctica. El libro presenta los conceptos fundamentales de la administración de proyectos en una forma concisa, haciendo hincapié en los complejos trueques que deben considerar los administradores de proyectos. Además, subraya la "desconexión" que existe entre las metodologías y herramientas comerciales disponibles, y los proyectos inciertos y riesgosos XV
XVi
PRÓLOGO
q ue los administradores de proyectos deben dirigir en el mundo real. Esta relación entre teoría y práctica se ilustra de varias maneras, incluyendo casos de estudio, juegos y problemas para es tudi o. Además, intenté •
presentar los conceptos fundamentales de la administración de proyec10s de manera concisa, resaltando los intercambios o trueques que deben analizar la mayoría de los administradores de proyectos,
•
describir las técnicas y metodologías que se han desarrollado para ayudar a los administradores de proyectos usando modelos y plantillas de hojas de cálculo,
•
mostrar cómo se pueden ampliar estas técnicas y metodologías para manejar problemas reales más complej os,
•
e integrar la investigación aciUal al material educativo de AP.
El libro usa hoj as de cálculo para ex plicar muchos conceptos y metodologías de AP. Casi todos los estudiantes están famili arizados con las hojas de cálculo y es sencillo que relacionen su uso y aplicación. Traté de incluir todos los modelos que tienen aplicaciones importantes o que presentan ideas valiosas para estudiantes y profesionales. Estos modelos se describen analíticamente usando notación algebraica básica y hojas de cálculo. Todos los modelos en hoja de cálculo se hicieron en Microsoft Excel 200 1 y se encuentran en el CD que acompaña a este libro. Espero que estos modelos en hoja de cálculo permitan al estudiante explorar aspectos de AP que el software comercial no maneja (por ejempl o, el problema de trueque tiempo-costo). Traté de relacionar el material de este libro con otros cursos de adminjstración e ingeniería; por ejemplo, hay material de presupuestos (relacionado con contabi lidad administrativa), impacto del diseño organizacional sobre el éxito de un proyecto (que se relacio na con teoría organizacional), equipos de proyecto (referente al comportamiento organi zacional), programación de proyectos (relacionado con cursos de admi nistración de operaciones), desarrollo de nuevos productos (cursos de mercadotecnia) y un a cantidad considerable de material de administración de proyectos de soft ware en todo el libro (relacionado con cursos de sistemas de información). Como tal, el tema del libro será útil para estudiantes de varias áreas, que incluyen sistemas de información, mercadotecnia, ingeniería industrial y administración de operaciones, entre otras. Existe gran cantidad de investigación reciente relevante para los administradores de proyectos, pero que no aparece en casi ningún libro de AP. Por esta razón, incluí mucho de este material en el libro, que comprende taxonomías de proyecto, trabajos recientes acerca de los efectos de la incertidumbre en la subcontratación y las licitaciones, trabajos de admi nistración de materiales y com pras en los proyectos, trabajos sobre admi nistración de proyectos de software, e investigaciones actuales sobre administración de ri esgo. Por último, traté de incluir varios casos nuevos, juegos y pro blemas de estudio que son útiles para ilustrar algunos aspectos complejos que enfrenta el administrador de proyectos. Entre éstos se cuenta el juego de desarrollo de un nuevo producto, un juego "de mesa" interactivo que desarrollé (con Chris Sandvig) y que he usado en muchas clases y cursos para ejecutivos. El j uego es útil en especial para relac ionar los conceptos de administración de proyectos con el problema del desarrollo de nuevos productos en un entorno de alta tecnología (el juego se basa en el desarrollo de una unidad portátil de radar marino). Este juego se puede jugar en una clase de una sesión o usarse en varias como caso de estudio.
PRÓLOGO
XVii
Este libro está diseñado para usarse en cursos optativos de administración de proyectos, en licenciatura y en maestría, en casi todas las uni versidades. Además, se espera que sirva como una referenc ia general y pueda usarse en programas para ejecutivos. Este libro está escrito de manera q ue sólo tenga una cantidad mínima de prerrequisitos (supuse que el lector ha tenido algú n contacto con programación lineal y entera, comprende conceptos básicos de probabi lidad y estadística, y está fam iliarizado con las hojas de cálcul o básicas). Por último, son bienvenidos los comentarios y sugerencias. Quiero crear un libro que apoye un curso significativo de adm inistración de proyectos, que motive a todos los interesados a analizar aspectos más allá del nivel superficial. Cualquier ayuda que puedan proporcionarme, será apreciada (y reconocida). Pueden ponerse en contacto conmigo por correo electrónico en
[email protected].
ORGANIZACIÓN DEL LIBRO El libro está organizado de manera un poco diferente a la mayoría de Jos libros de AP; por ejemplo, el tema de las duraciones aleatorias de las tareas se estudia en casi todo el libro (y no sólo en un capítulo). Con esto queremos atacar el problema de la posible "desconexión" entre el software para AP (que supone que todo es detenninistico) y los proyectos de la vida real (que están sujetos a la aleatoriedad de tiempo y costo). El texto empieza con una visión general de la administración de proyectos y la importancia de AP en el entorno económico de hoy. El capítulo 2 estudia los aspectos de inicio y selección de un proyecto y se presentan varias herramientas (como la teoría de opciones) para evaluar proyectos propuestos. El capítulo 2 también introduce a la planeación de proyectos, que incluye estructuras de división del trabajo y estimación de tiempo y costo. El capítulo 3 trata temas organizacionales y de comportamiento relacionados con la formación y supervisión de equipos de proyecto. El capítulo 4 presenta los conceptos básicos del método de la ruta crítica (CPM) y muestra su relación con la administración de la programación del proyecto. El capítulo 5 extiende el CPM para tener en cuenta los costos (por ejemplo, flujos de efectivo, "trueques tiempo-costo). El tema de la aleatoriedad se estudia con detalle en el capítulo 6, incluyendo el análisis del modelo PERT clásico y métodos actuales (como la simulación Monte Cario) para evitar los obstáculos relacionados con esa metodología. El capítulo 7 está dedicado a la adm inistración de riesgos, tarea que ocupa gran parte del tiempo y esfuerzo de un administrador de proyectos. El capítulo 8 estudia la nivelación y asignación de recursos, cuando los requerimientos son determinísticos y cuando son inciertos. El capítulo 9 trata de sistemas de supervisión y control, y el último capítulo (capítulo 10) se ocupa de la administración de proyectos múltiples.
SUGERENCIAS PARA LA ENSEÑANZA Este libro pretende proporcionar una visión general concisa de la mayoría de las técnicas y conceptos fundamentales para la AP. Además de los casos y problemas de estudio que se presentan en el libro, generalmente uso varios casos de estudio (reales). He tratado de elegir casos que refuercen trueques analizados en el libro y llevar al salón de clase las complicaciones y los aspectos de comportamiento de la vida real. Harvard Busi ness School Publishing o la European Case Clearing House ofrecen muchos de los casos de estudio que he usado. Además, he encontrado que un conferencista, cuidadosamente ele-
xyjjj
PRÓLOGO
gido, traído de fuera, puede rcfor.uu- muchos de Jos conceptos que resalta el libro y dar a los estudiantes que aún no se han involucrado directamente en la administración de un proyecto complejo, una buena idea de las dificultades y problemas que se presentan en la administración de los proyectos de la vida real.
SOFTWARE QUE ACOMPAÑA EL TEXTO El CD-ROM que acompaña al libro contiene los siguientes recursos para los estudi antes: •
Microsoft Project 2002: versión para estudiantes del popular paquete de software para administración de proyectos.
•
@Risk: complemento de Microsoft Project 2002 que incrementa la funcionalidad de MS Project, permitiendo al usuario construir fácilmente poderosas simulaciones Monte Cario.
•
Diapositivas en PowerPoint: presentación en PowerPoint con más de 200 diapositivas elaboradas por el autor para apoyar el material del libro.
•
Plantillas de hojas de cálculo: hojas de cálculo/plantillas de Excel para todos los modelos estudiados en el libro.
MATERIAL SUPLEMENTARIO PARA EL PROFESOR El siguiente materi al suplementario se proporciona en la página de Internet (www.wiley.com/college/klastorin) que complementa el libro: •
Diapositivas en PowerPoint: presentación en PowerPoint con más de 200 diapositivas elaboradas por el autor para apoyar el material del libro.
•
Manual del profesor/guía de soluciones: solución de todos los problemas de tarea y sugerencias de enseñanza para los casos de estudios.
RECONOCIMIENTOS Es imposible que una sola persona realice un libro o trabajo como é te, que no es la excepción; esto es realmente la contribución de muchas personas a través de muchos años (aunque los errores u omisiones son sólo míos). Aprendí mucho de mis colegas de la Universidad de Washington; un agradecimiento especial a la profesora Karen Brown. Estoy en gran deuda con mis estudiantes de doctorado, a lo largo de muchos años; entre ellos se encuentran Avy Shtub (Technion Israel lnstitute ofTechnology), Chris Sandvig (Western Washington University), Prabhu Aggarwal (College of William and Mary), Mark Cutler (Northwest Airlines), Weiyu Tsai (University of Utah) y Gary Mitchell. Agradezco también las muchas sugerencias y comentarios de los profesores Phil Lederer (U niversity of Rochester), Marty Wilson (University of Minnesota), Genaro Gutiérrez (University of Texas), Charles Franz (University of Missouri), Frank Cesario (Keller School of Management), David Overbye (Keller School of Management), William Shcrrard (San Diego State University), Richard Sheng (De Vry Institute of Technology), Karol Pele (Michigan Technological University), Richard Peschke (Moorhead State Universiry), Steve Ro binson (Uni versity of Idaho), Jeffrey Reed (Marian College of Fond du Lac), Michael Poli (Wesley Howe School of Technology Management), Michael Ensby (Ciarkso n University), Raja Balakrishnan (Cicmson Univcrsity), Michael Vincenti (Central Conneticut State University), William Ibbs
PRÓLOGO
XiX
(University of California at Berkeley), y John Gleason (Creighton University). Como dije, aprendí mucho y desarrollé un gran respeto por los administradores que se encuentran "en el frente" administrando proyectos complejos con costos reales y riesgos reales; dos de los mejores son Steve Levy (Microsoft) y Brian Cline (Boeing Corporation). Muchos de mis alumnos de maestría en administración a través de los años han servido como conejillos de indias para probar este material; estoy en especial agradecido con Jack Eisenhower y Robert Barrick por sus contribuciones. A todos los demás esiUdiantes que hicieron muchas sugerencias y comentarios útiles para este libro les doy las gracias colectiva y sinceramente. Además, agradezco profundamente la ayuda y el apoyo del personal de John Wiley & Sons; si no hubiera sido por Beth Golub, editora por excelencia, tal vez estaría usando este libro como ejemplo de un proyecto que nunca terminó (o incluso inició). La ayuda de Gitú Lindner y Ailsa Manny de John Wiley, y de Michele Chancellor y Lari Bishop de Leyh Publishing, fue también muy valiosa y la agradezco profundamente. Quiero agradecer también a Christ.ianne Thillen por sus valiosas sugerencias. Y finalmente, pero no menos importante, mi familia realmente formó un equipo del proyecto que me dio apoyo y motivación que nunca podré reconocer de manera adecuada .
....-
ACERCA DEL AUTOR
Ted Klastorin es el profesor de administración de operaciones en el Departamento de Ciencias de la Administración (Business School) en Burlington Northern/Burlington Resources, profesor adjunto del departamento de servicios de la salud (School of Public Health and Community Medicine) y profesor adjunto de ingeniería industrial (College of Engineering) en la Universidad de Washington en Seatle. Obtuvo su licenciatura (B.S.) en Carnagie-Mellon University (1969) y el doctorado (Ph.D.) en University of Texas en Austin ( 1973). El profesor Klastorin es investigador del IC2 Institute de University of Texas en Austin. Ha impartido clases en Babcock Graduate School of Management, Wake Forest University (Wiston-Salem, Carolina del Norte), así como en University if Washington y University of Texas. En la UW fue el fundador del Departamento de Ciencias de la Administración y cofundador del programa PEMM (Program in Engineering and Manufacturing Management) un progran1a conjunto de la escuela de ingeniería y de la escuela de administración. Los temas de investigación que interesan al profesor Klastorin incluyen administración de proyectos y admi nistración de la cadena de proveedores en organizaciones de producción y de servicio. Sus proyectos actuales de investigación comprenden el estudio de eventos perturbadores inciertos (como huelgas) en la planeación y coordinación de proyectos para cadenas de proveedores descentralizadas. Sus artículos recientes han aparecido en /lE Transactios, Joumal of Applied Psycology, Management Science y Wisconsin Law Review. El profesor-Klastorin ha sido consultor de numerosas organizaciones como Boeing, Starbucks, Fluke Corp y Microsoft (donde colaboró en el diseño de Microsoft Project). Es miembro de INFORMS (lnstitute for Operations Research and the Management Sciences), IIE (Institute of Industrial Engineers) y POMS (Production and Operations Managernent Society), y colabora con los consejos editoriales de Manufacturing & Sen,ice Operations Management (M&SOM) y l/E Transactions.
xxi
CAPÍTULO
INTRODUCCIÓN A LA ADMINISTRACIÓN DE PROYECTOS ¿Qué
hay detrás de la c reciente demanda de software, asesores, li bros y cursos de administraCión de proyectos? ¿Por qué ahora tantas personas se interesan en la admin istración de proyectos? ¿Qué puede ofrecer la admi nistración de proyectos que otras tecnologías de administración no ofrezcan? Las razones del creciente interés por la administración de proyectos (AP) se hacen evidentes mediante un cuidadoso examen del panorama actual de los negocios. Pero más importante, quizá, administración de proyectos es sinónimo de administración del cambio. Las organizaciones que quieren modificar su e nfoque o dirección reconocen, cada vez más, que implantar verdaderos cambios requiere la introducción de nuevos productos, procesos o programas de manera oportuna y de manera eficiente en costos. El cambio rápido se ha convertido, actualme nte, en un requisito esencial para la supervivencia de casi todas las organizaciones. Conforme el ciclo de vida de los productos disminuye, deben desarrollarse e implementarse nuevos productos y servicios, tan rápida y eficientemente como sea posible. Además. los productos se vuelven obsoletos con mayor rapidez. Griffing y Pagc ( 1993) infom1an que 50% de los ingresos de una empresa típica provienen de productos introducidos en los últimos cinco años en comparación con una estimación de 33% en los 80 y 20% en los 70 (Tak.euchi y Nonaka, 1986). Los ciclos de vida del producto más reducidos requie re n que la selección y el desarrollo de nuevos productos se manejen con eficiencia en costos y que maximicen las posibilidades de éxito comercial. En algunas industrias, los administradores tienen mucho menos de cinco años para desarrollar, producir y vender un nuevo producto. Por ejemplo, Yang (2000) apunta que la industria de la comunicación está sujeta a la regla 4-3-3: cuatro meses para desarrollar un nuevo producto, tres meses para hacer dinero con él y tres meses para sacarlo de los anaqueles. Los asesores de McKinsey & Co. estimaron que la ganancia potencial bruta de un producto de una empresa típica se reduce alrededor de 12% si el producto se introduce con tres meses de retraso, y 25% si se introduce con cinco meses de retraso (Vesey, 1992). Yang expresó la situación del desarrollo de nuevos productos de manera muy sucinta: "el momento para ponerlo en el mercado significa vida o muerte, y todo lo que pueda inclinar la balanza a nuestro favor es preciado". Cada vez más administradores reconocen que una buena administración de proyectos puede proporcionar una parte significativa de esa ventaja. También la naturaleza de los proyectos ha cambiado en la última década. La administración de proyectos se ha usado desde el tiempo de las pirámides de Eg ipto, hace casi cinco mil años. Aunque no sabemos si la construcción de las pirámides de Egipto terminó a tiempo y dentro del presupuesto, sí sabemos que hoy las organi zaciones realizan proyectos rutinarios en entornos globales complejos que hacen la coordinación y la comunicación mucho más d ifíci l que en los tiempos de la construcción egipcia hace ci nco mil años. Muchos de estos proyectos, en especial los de tecnología de la información (TI), representan inversiones significativas para una organización, de modo que el fracaso del proyecto puede ignificar el fin de la organjzación. Los administradores de proyectos deben usar métodos que maximicen la probabilidad de éxito de estos proyectos. Dada la creciente importancia de administrar proyectos complejos, es inquietante ver el gran número de proyectos que no logran satisfacer sus objetivos básicos. En un estudio de vei ntitrés mil proyectos de aplicación, el Grupo Standish informó que e n 1998 sólo 26% de los proyectos tuvieron éxito total, mientras que 46% fuero n cuestionables (esto es, terminaron, pero con presupuesto y/o
1
2
CAPfTU LO 1
INTRODUCCIÓN A LA ADMINISTRACIÓN DE PROYECTOS
tie mpo mayores, con menos fu nciones que las designadas originalmente) y 28% se consideraron un fracaso (Grupo Standish, 1999). Según e l Grupo Standish, estos proyectos que fracasaro n costaron casi 75 000 millones de d ólares en 1998. Las estadísticas presentadas por el Grupo Standish son alarmantemente congruen tes con otros estudios. Bou nds ( 1998) info rma que sólo 26% de los proyectos de tecnología de la información terminaron a tiempo y dentro del presupuesto. Yeo (1999) infom1a que de los doscientos mil proyectos de desarrollo de software puestos en marcha en 1999 por empresas de Estados Unidos, alrededor de 3 1% se cancelaron o abandonaron antes de terminar, lo que representó una pérdida de casi 62 millones de dólares. Yeo también indica que sólo 13% de los proyectos de sistemas de TI fueron considerados proyectos exitosos por los patrocinadores, mientras que sólo 16.2% de los proyectos de desarrollo de software terminaron a tiempo y dentro del presupuesto. Otros ejemplos ilustran la importancia del éxito de la AP, y los altos costos del fracaso. Por el lado del éxito, hace poco BC Hydro terminó a tiempo y 21 % abajo del presupuesto un proyecto de reposición de una planta de poder en British Columbia, Canadá, mediante el uso de técnicas profesionales de AP. Una buena AP no sólo ahorró millones de dólares a BC Hydro, sino que demostró cómo estas "técnicas aseguran que los proyectos te ngan éxito técnico, ambiental y social" (Water Power, 2000). En Alemania, los arqueólogos encontraron que las herran1ientas de AP ofrecen una manera eficiente de adm inistrar las exploraciones y excavaciones de los sitios arqueológicos (Walker, 1996). En otra historia de éxito, los admin istradores de Taco Bell descri ben cómo reconstruyeron completamente un restaurante de Taco Be ll que el fuego había destruido. Los administradores pudieron reducir drásticamente el tiempo normal de este proyecto, de sesenta días a 48 horas, aplicando con c uidado las técni cas de AP en incre mentos de quince minutos (Industrial Engineering, 1992). Estos ejemplos indican lo que la AP puede lograr c uando hay una planeación cuidadosa, una implementación hábil y buena suerte. Por otro lado, ha habido muchos fracasos notables de proyectos. El sistema computarizado para manejo del equipaje en el Aeropuerto Internacional de Denver retrasó la apertura del aeropuerto más de un año y le sumó $85 millones al presupuesto original. El proyecto para la construcción del túnel en el Canal de la Mancha costó f3 000 millones más que la estimación original y necesitó dos años más de lo planeado. Aun Mickey Mouse ha sido incapaz de escaparse de las dificultades impuestas por la administración..,de proyectos complejos, como lo testificarían muchos clientes frustrados (vea el artículo adjunto). Dada esta reciente historia de experiencias en proyectos, la adm inistración de proyectos profesional ofrece un a me todología que ha sido cuidadosamente definida, refinada y aplicada con éxito durante los últimos cinco años. La admin istración de proyectos es un sistema bien desarrollado que puede ayudar a las organizaciones a lograr sus metas con oportunidad. Como resultado, la administración de proyectos se ha convertido en una pru1e esencial de la adm in istración de alta tecnología, un elemento crucial del comercio e lectrónico y una parte importante del movimiento de globalización que ha transformado a la economía mundial en los últimos diez años. Dado el tamaño y el alcance de todos los proyectos que se emprenden anualmente, es claro por qué la administración de proyectos se ha convenido en e l e nfoq ue de las empresas globales y el gobierno. De hecho, ahora se estima que la administración de proyectos es en sí una industria de 850 millones de dólares que se espera c rezca 20% por cie nto por año (Bounds, 1998). Este libro inrroduce los conceptos básicos de la admi nistración de proyectos con el fin de dar a los admini tradores una c lara comprensión de las herramientas y trueques que requieren los proyectos complejos. En el libro nos centramos en los problemas que deben afrontar los administradores que realizan proyectos complicados. En este primer capítulo se consideran los temas siguientes. •
¿Qué es la administración de proyectos y en qué difiere de otras formas de administración (como administración de programas)?
•
¿Qué es un pro)ectO? ¿Cómo se define el é:Uto o el fracaso de un proyecto?
•
¿QUÉ DEFINE UN PROYECTO?
•
¿Cuáles son algunos ejemplos notables de éxito y fracaso de proyectos y qué lecciones se pueden aprender del estudio de estos casos?
•
¿En qué difieren los proyectos de TI de otros proyectos?
• •
¿Qué es un ciclo de vida de AP? ¿Cuáles son algunos modelos de ciclos de vida comunes?
•
¿Cómo se puede considerar el riesgo de un proyecto?
•
¿Cuál es la historia de la administración de proyectos?
•
¿Cuál es la naturaleza del software para AP?
3
¿QUÉ DEFINE UN PROYECTO? ¿Qué es un proyecto y e n qué difiere de un programa? De acuerdo con el Project Management Institute (2000), un proyecto es "una iniciativa temporal que se pone en marcha para crear un producto o servicio único." De manera aJternativa, un proyecto se puede ver como un conjunto bien definido de tareas o actividades que deben realizarse para cumplir las metas del proyecto. Normalmente se considera que estas tareas o actividades que constituyen un proyecto están definidas de manera que: • •
Cada tarea se puede iniciar o detener independientemente de cualquier otra (dentro de una secuencia dada) y Las tareas están ordenadas de tal manera que se deben realizar en una secuencia tecnológica (por ejemplo, las paredes de una casa deben construirse antes que el techo).
Además, en general se supone que una vez que se inician las tareas, no se pueden interrumpir (o detener) y deben de continuar hasta su terminación. De esta definición se derivan varias implicaciones. Primero, los proyectos tienen un tiempo de vida bien definido entre el momento en que inicia la primera tarea y termina la última (aunque en realidad a veces es difícil decir cuándo un proyecto está totalmente terminado). Como los proyectos consisten en tareas bien definidas, suelen existir metas específicas asignadas al proyecto; entre estas metas se encuentr2n las especificaciones de calidad y de diseño, y los objetivos de costo y programación. Es común que estos objetivos estén orientados al cliente meta del proyecto, que puede ser diferente al cliente típico de una organización (es decir, un proyecto designado para un cliente específico). Más aún, los proyectos tienen aJgunas otras características únicas. Casi siempre se caracterizan por el uso de equipos de proyecto multifuncionales. De hecho, e l amplio uso actual de equipos
El constructor de barcos de Disney se retrasó seis meses en la entrega de los barcos crucero y miles de clientes que habían comprado boletos se quedaron plantados. Aun con esta experiencia, también entregó el segundo barco después de las fechas publicadas. Universal Srudios en Orlando, Florida, llevaba dos años construyendo un nuevo complejo de restaurantes y entretenimiento. Anunciaron que la inauguración serfa en diciembre sólo para rectificar a fines de noviembre que tardaría dos o tres meses más. Aun cuando las instalaciones abren cerca de la fecha prevista, rara vez están completamente terminadas y con frecuencia aún les fal tan componentes clave. ¿Por qué pasan estas cosas? Con todas las sofisticadas computadoras y el software para la administración de proyectos existente, ¿por qué no terminan los proyectos a úempo? Fuente: F. Frable, NaJion's Res/aurant News (12 de abril de 1999).
4
CAPÍTULO 1
INTRODUCCIÓN A LA ADMINISTRACIÓN DE PROYECTOS
multifuncionales en la mayoría de las organizaci ones es una extensión de las prácticas de AP anteriores. La ventaja de usar eq uipos de proyecto ahora se reconoce ampliamente, aunque es menos claro cómo organizar y manejar estos equipos. Dado que los proyectos deben terminar en un tiempo finito, los recursos no suelen adquirirse para proyec10s específicos, sino que se obtienen de otras partes de la organización. Una excepción se presenta cuando la empresa contrata empleados eventuales para un proyecto específico o subcontrata parte del proyecw (o todo). De cualquier manera, en general Jos proyectos deben aj ustarse al portafolio global de experiencia y conocimiento disponible en la organización. Todo tipo de organización, sea pública o privada, lucrativa o no lucrativa (y Jos individuos), emprende proyectos; un ejemplo interesante se encuentra en el artícu lo adj unto de Janofsky, "de la política a los pasteles: nueva vida para el ex gobernador de Arizona". Algunos ejemplos de proyectos incluyen: •
Construir las pirámides del rey Keops (Egipto)
• • •
Encontrar un trabajo al salir de la uni versidad Cerrar los registros contables al final del mes Instalar y depurar un nuevo sistema de computación
• • • •
Planear y lanzar un nuevo producto Realizar una campaña política Los proyectos de mantenimiento y reparación Intentar comprar boletos para la serie mundial de béisbol
La definición de un proyecto ayuda a diferenciar los proyectos y los programas; éstos son operacio nes en marcha que continúan de manera indefinida, y su alcance y duración son mayores que la de casi todos los proyectos. A d iferencia de Jos administradores de programas, los administradores de proyectos luchan por quedarse sin trabajo lo más pronto posible. Sin embargo, debe o bservarse que la administración de proyectos puede aplicarse (y con frecuencia se aplica) a programas que están compuestos de proyectos múltiples. Por ejemplo, considere una línea de ensamble de aviones. En un sentido, esta línea se puede ver como un proceso de ensamble continuo; pero en otro, cada avión se puede considerar un proyecto separado, donde se aplican las técnicas de AP a cada avión en la línea de ensamble. Esta relación entre los proyectos y los procesos de producción de Oujo continuo se explorará con más detalle en otros capítulos.
No todos los proyectos son iguales En la mayor parte de este libro se analizan proyectos genéricos. Sin embargo, es obvio que no todos los proyecws son iguales. Un proyecto para el desarrollo de un nuevo software complejo es bastante diferente de un proyecto para la construcción de una carretera. En el primer caso puede ser difícil defi nir con claridad el diseño y alcance del proyecw, el ambiente externo cambia con rapidez y el personal de TI que desarrolla el software suele estar involucrado en otras actividades y proyectos. Por el contrario, la mayoría de los proyectos de construcción se realizan en forrna aislada respecto a otros proyectos; aunque por supuesto contienen muchos factores de incertidumbre, casi todos estarán de acuerdo en que es más probable que un proyecto de construcción cumpla sus metas que la mayoría de los proyectos de desarrollo de software. Además, es mucho más sencillo medir el avance de un proyecto de construcción, donde el progreso (o la falta de él) es visible, que el de un proyecto de IT cuyo avance puede ir de O a 90% en los últimos minutos del proyecto. Varios investigadores (entre los que se encuentran Yao y Souder, 1994; Brown y Eisenhardt, 1997, y Eisenhardt y Tabrizi, 1995) han esrudiado diferentes tipos de proyectos y aseguran que los distintos tipos de proyectos necesitan estructuras organizacionales diferentes al igual que estrategias y estilos de administración diferentes. Por ejemplo, una organización altamente centralizada y
¿QUÉ DEFINE UN PROYECTO?
5
jerárquica, con poca comunicación sería muy efectiva para los proyectos de construcción de carreteras, pero tal vez no sería lo mejor para el desarrollo de un nuevo producto con tecnología compleja en un entorno de gran incertidumbre. Con base en algunos estudios de proyectos de desarrollo de nuevos productos (o procesos o servicios) basados en ingeniería, Shenhar (2001) sugirió que los proyectos se pueden clasificar de acuerdo con dos características: complejidad e incertidumbre. Como se indica en la figura 1.1, una de las características indica el grado relativo de incertidumbre/riesgo tecnológicos en un proyecto, que van desde proyectos de baja tecnología que usan tecnologías ya bien establecidas y estables (proyectos de construcción) hasta proyectos de muy alta tecnología que requieren desarrollar nuevas tecnologías durante el proyecto (el proyecto Apolo de alunizaje). A lo largo de este continuo, Shenhar define proyectos de tecnología media y de alta tecnología. Los proyectos de tecnología media usan una tecnología estable, en una nueva dirección (como mejora de productos); este tipo de proyectos incluye a la mayoría de los proyectos industriales. Por otro lado, un proyecto de alta tecnología representa un proyecto que puede estar aplicando una tecnología nueva por primera vez. La segunda característica empleada para definir la taxonomia de la figura 1.1, es la complejidad del proyecto o alcance del sistema. Según Shenhar, un proyecto de complejidad limitada es "un subsistema que realiza una función bien definida dentro de un sistema mayor, o puede ser un producto independiente que realiza una sola función de escala limitada". Shenhar los llama proyectos de ensamble. En el otro extremo del espectro de la complejidad están los proyectos de integración, proyectos geográficamente dispersos que requieren la combinación de muchos subsistemas complejos, por ejemplo la puesta en marcha de un sistema de planeación de recursos empresariales (ERP, Enterprise Resource Planning), en una empresa multinacional grande. Entre los proyectos de complejidad alta y baja están los proyectos de sistemas; estos proyectos requieren el desarrollo de numerosos subsistemas que, a su vez, definirán un producto (o proceso o servicio). La taxonomia de Shenhar se representa en la figura l. l.
A GURA 1.1 - axonomía de Shenhar de los tipos de proyectos
Grad.,e de incertidumbre/ riesgo Implantación de ERPen una multinacional
Tecnología muy alta
Tecnología alta
Nuevo software con licencia codificada
Tecnolog ía media
Nuevo teléfono celular
Tecnología baja
Construcción
1
Un radar avanzado
Reparación de autos Alt o
Proyectos de ensamble
Proyectos de sistemas
Proyectos de integración
Complejidad/ alcance del sistema
6
CAPÍTULO 1
INTRODUCCIÓN A LA ADMINISTRACIÓN DE PROYECTOS
En todo este libro será útil conservar en mente la taxonomía de Shenhar. Como es de esperarse, Shenhar encontró que la posición de un proyecto en su taxonomía tiene implicaciones significativas en el diseño organiz.acional, los sistemas de comunicación y con trol, la planeación y programación de recursos, la extensión de las pruebas y en la necesidad de construir un prototipo. Conforme aumenta la complejidad y el alcance del proyecto, por ejemplo, los proyectos requieren planeación y control, y sistemas de comu nicación más formales; las organi zaciones relacionadas con estos tipos de proyectos tienden a ser más grandes, más formales y con más burocracia. Estas implicaciones se estudian con más detalle en el capítulo 3. Una taxonomía alternativa para los tipos de proyectos de desarrollo fue sugerida por Wheelwright y Clark ( 1992) quienes también clasifican a los proyectos en dos dimensiones: el grado de cambio del producto y el grado de variación en el proceso de fabricación. Usando este esquema de clasi ficación bidimensional, los autores identificaron varios tipos de proyectos que requieren diferentes niveles de recursos y estilos de adm inistración. Por ejemplo, en el área de poco cambio en el producto y el proceso identificaron proyectos derivados como proyectos que realizan mejoras relativame nte menores a los prod uctos existentes. Según Wheelwright y Clark los proyectos derivados producen mejoras en el producto y/o e n el proceso (por ejemplo, una modificación en el empaque, una característica nueva o mejoras en la calidad). Los proyectos de plataforma realizan modificaciones significativas e n el producto y/o el proceso, pero evitan los cambios importantes que se presentan en los proyectos innovadores. Los dos primeros tipos dan como resultado mejoras significativas en el producto y/o el proceso basadas en tecnologías desarrolladas y probadas (los ejemplos incl uyen la computadora iMac de Apple y algunos modelos nuevos de automóviles); los proyectos de innovación representan productos y procesos radicalmente nuevos (como el trasbordador espacial de la NASA y el desarrollo de los teléfonos celulares). Los proyectos innovadores dan como resultado el desarrollo de nuevos mercados; estos proyectos tienen un al to grado de riesgo y complejidad. La taxonomía sugerida por Wheelwright y Clark se presenta en la figura 1.2.
FIGURA 1.2 · Taxonomía de proyectos su gerida po r Wheelwright y Clar k
Alto Producto de base nueva
Proyectos innovadores
Producto de la siguiente generación
Pro yectos de plataforma Cambio en el producto
Adición a un producto
Proyectos d erivados Derivados y mejoras
Bajo Cambio incremental
Actualización en un solo departamento
Proceso de la siguiente generación
Proceso de base nueva
+ - - - - -- - - Cambio en el proceso - - -- - --+ Bajo
Alto
MEDIDAS DE EXJTO O FRACASO DE UN PROYECTO
7
PHOENIX, 4 de abril- No hace muchos años que Fife Symington consideraba orgulJosamente como su mayor logro el bienestar fiscal de Arizona. Como gobernador durante la mayor parte de los años 90, presidió las acciones para reducir los impuestos, aumentar los ingresos y mejorar las inversiones de capital, una gestión que lo convirtió en una nueva estrella del Partido Republicano. Actualmente, las principales causas de orgullo profesional del señor Symington incluyen un pastel de queso cubierto con queso crema italiano, un merengue helado relleno de crema de amareto y un pastel de chocolate con sabor a café, conocido como el Gobernador, su postre de firma, que promete "bajos impuestos y alto sabor". Mientras otros ex polfticos se integran a la vida como abogados, activistas o ejecutivos corporativos, el señor Symington es ese raro servidor público que se ha convertido en un chef de repostería. Casi todas las mañanas, sale a trabajar a Franco's ltalian Caffé. un nuevo restaurante aquí, donde crea postres; el dueño, Franco Fazzuolli, insiste que son tan populares como los aperitivos, entradas y pizzas que ofrece en sus restaurantes en Manhanan -donde era propietario de Ponte Vecchio, Cent'Anni y Zinno- antes de cambiarse al oeste. "Hay que poner atención en muchas cosas" dijo el otro día. "Siempre hay una ruta critica para lograr un menú o una comida. hay mucha presión. Pero también tiene su encanto trabajar con un maravilloso grupo de personas en la cocina. Hay a quienes no les gustaría. Yo pienso que es mágico." Fue111e: Michael Janofslcy, "De la política a los pasteles: nueva vida paca ex gobernador de Arizona•, New York Times. 6 de abril del 2003.
MEDIDAS DE ÉXITO O FRACASO DE UN PROVECTO Como la mayoría de los proyectos tienen metas de costo y tiempo claramente definidos, es común que se juzgue el éxito de un proyecto según si terminó dentro del presupuesto y antes de la fecha de entrega. Sin embargo, tal juicio puede resultar un poco ingenuo en el sentido de que la mayor parte de los proyectos tienen muchas metas además del presupuesto y la programación. Por ejemplo, ¿satisfizo el proyecto las-especificaciones?, ¿tuvo éxito el proyecto en el mercado?, ¿tuvo éxito en aumentar la participación de mercado, los ingresos, las ganancias, etcétera, a largo plazo?, ¿proporcionó el proyecto a la o rganización el aprendizaje que dará a proyectos futuros una mayor posibilidad de éxito? Por ejemplo considere el desarrollo de la película Tttanic que se presentó en 1997 despué de varios años de trabajo. Cuando finalmente se presentó, la película tenía un retraso significativo respecto a su plazo de entrega y $90 millones arriba de su presupuesto original de $110 millones (un costo 82% superior a lo previsto). Sin embargo, la película claramente tuvo éxito en el mercado, ganó numerosos premios (incluyendo la mejor película de 1997) y se convirtió en la primera pelíc ula de la historia que obtuvo más de mil millones de dólares de ingresos. Este proyecto ¿fue un éxito o un fracaso? En a lg unos casos los proyectos pueden fracasar aun cuando terminen a tiempo y dentro del presupuesto, como ocurrió con el proyecto Mars Lander (vea el artículo adjunto). Aun cuando el Mars se estrelló en el aterrizaje, el proyecto no fue un fracaso total en el sentido de que generó conocimientos nuevos que pueden proporcionar a la NASA una mayor posibilidad de éxito en misiones futuras. En otros casos, los proyectos pueden emprenderse como "líderes de pérdida"; es decir, una organización puede iniciar un proyecto que sabe que tendrá pérdidas con objeto de ganar una ven taja competitiva, cuando concurse por contratos futuros de proyectos similares, o para ejercer una presión competitiva sobre un rival e n un mercado específico. Aun cuando el costo y el tiempo son los objetivos primordiales de un proyecto, tal vez sea difícil o incluso poco realista lograrlos, en especial cuando fueron establecidos por administradores de alto nivel que no están directamente involucrados en el proceso de planeación de proyectos. Según
8
CAPÍTULO 1
INTRODUCCIÓN A LA ADMINISTRACIÓN DE PROYECTOS
Frable (1 990), "establecer plazos cortos en extremo parece haberse convertido en un asunto de honor entre ciertos dueños y administradores de proyectos". No es de sorprender que la empresa asesora de AP, Robbins-Gioia Inc., informe que 44% de todos los administradores de proyectos tienen costos superiores, e ntre 1O y 40%, a lo previsto y que solamente 16% de los administradores c umplen de modo estable sus plazos de terminación. En otro estudio (The Economisr, 2000) se informó que "alrededor de 85% de todos los proyectos de TI del sector público se consideran fracasos". El autor agrega, "esto no significa que sean un desastre total , sino que suele llevar más tiempo ponerlos en marcha, cuestan más y proporcionan menos de lo que se planeó". En un estudio para analizar el desempeño de los proyectos y asuntos organizacionales, M ight y Fischer (1985) definieron seis medidas de éxito de un proyecto: 1.
G eneral: ¿cuál es la percepción general del éxito de un proyecto?
2.
Costo: ¿es el costo final superior o inferior al presupuesto inicial?
3.
Plazo: ¿el tiempo de terminación fue mayor o menor que el programado?
4.
Meta técnica 1: ¿cuál es la percepción general del desempeño técnico del proyecto comparado con las especificaciones iniciales?
5.
Meta técnica 2: ¿cuál es la percepción general del desempeño técnico del proyecto comparado con otros proyectos de la organización?
6.
Meta técnica 3: ¿cuál es la percepción general del desempeño técnico del proyecto comparado con los problemas encontrados durante el proyecto?
Might y Fischer consideraron también la posible correlación entre estas medidas: ¿es más probable que un proyecto que cumple las especificaciones técnicas iniciales se considere un éxito respecto a la segunda y tercera metas técnicas? En su estudio de 103 proyectos de desarrollo, Might y Fischer encontraron una correlación positiva (0.68) entre las metas de costo y de tiempo, lo que implica que es más probable que los proyectos que se retrasan incurran en costos excedentes. Sin embargo, algunas otras correlaciones indican que los administradores tienen que elegir entre las metas técnicas por un lado y las de costo y tiempo por el otro. Los coeficientes de correlación encontrados por Might y Fischer e ntre las medidas de éxito de un proyecto se dan en la figura 1.3. Cuatro de estas sei medidas son más bien subjetivas (sólo las meras de costo y tiempo tienen alguna base objetiva), enfatizándose así la importancia de satisfacer las expectativas para lograr el éxito de un proyecto. ¿Por qué fracasan tantos proyectos en el cumpli miento de las expectativas? Un estudio de Hughes ( 1986) aclara algunas de las causas de fracaso de un proyecto; según Hughes hay tres factores principales: •
Una falta de comprensión de las herramientas de AP y un exceso de confianza en el software para AP
FIGURA 1.3 Correlación ent re las medidas de éxito de un proyecto
Éxito global del proyecto Éxito global del proyecto Costo Programa Meta técnica 1 Meta técnica 2 Meta t écnica 3 Fuente: R. Might yW. Fischer, 1985.
1
Costo 0.55 1
Meta Programa técnica 1 0.54 0.68 1
-
0.68 0.30 0.36 1
Meta Meta técnica 2 técnica 3 0.42 0.32 0.29 0.55 1
0.37 0.41 0.40 0.20 0.28 1
MEDIDAS DE ÉXITO O FRACASO DE UN PROYECTO
•
Problemas de comunicación
•
No se ajusta de modo adecuado a los cambios que ocurren e n el curso de l proyecto
9
Ade más, Hughes observó que muchos administradores pierden de vista el proyecto al concentrarse en el software para AP y administrar la red de precedencias e n lugar del proyecto. La observación de Hughes, tambié n señalada por otros (incluyendo al a utor), es una de las razones por las que este libro no hace énfasis en el soft ware para AP (aunque por supuesto se menciona), sino que se e nfoca en los conceptos básicos y los trueques que los administradores deben compre nder con objeto de terminar con éxito un proyecto. Hughes también observó que muchos administradores de proyectos no recompensan las acciones de los empleados del proyecto que más contribuyen a las metas más importante . Aunque puede ser difícil determinar el bene ficio re lativo a acciones individuales, Hughes hace notar q ue tales recompensas pueden pagar divide ndos significati vos. La comunicación es uno de los factores que más contribuyen a los resultados del proyecto; Michalski (2000) observa en su estudio de proyectos de biotecnología que "la buena com un icac ión es la clave para una exitosa administración de proyectos". Hughes indic a que los proyectos fracasan cuando hay demasiadas personas involucradas en e llos, pues dificulta la comunicac ió n, pero que ningún proyecto ha fracasado por tener muy pocas pe rsonas. El fracaso ta mbién se presenta c uando los administradores no comunican con efectividad las metas del proyecto a los otros partic ipantes y se centran en detalles poco importa ntes. A este respecto, el desarrollo de la tecnología de la información ayuda a resolver los aspectos de comun icación; Inte rnet, las máquinas de fax y aun los teléfonos celulares contribuyen a facilitar la comunicación entre los administradores del proyecto y los equipos, los clientes y Jos contratistas (Schmidt, 2000; Bagli, C ., 200). Los problemas de comunicación y coordinación se revisan co n más detalle en el c apítulo 3. Por último Hughes señala que los administradores no se ajustan a los cambios que siempre se presentan durante la vida de un proyecto. Para administrar con éxito un proyecto, un admi nistrador debe incorporar todos Jos cambios e n los planes, el presupues10 y los program as actuali zados de manera explícita y comunicar estos cambios a todas las personas relacionadas con e l proyecto. Las conclusiones de Hughes son nota ble me nte congrue ntes con los hallazgos de otros autores. Examinando numerosos estudios de casos de AP, P into y Slevin ( 1987) e ncontraron nueve factores cruciales para el éx ito~ muchos proyectos: • •
Obje tivos claramente definidos Administrador de proyecto competente
• •
Apoyo de la alta administración Miembros competentes e n e l equipo de PM
•
Asignación de recursos sufic iemes
• •
Canales de comunicación adecuados Mecanismos de control
• •
Capacidades de retroalimentación Buena respuesta al cliente
Aunque Pinto y Sle vin no indican la importancia re lativa de estos fac tores, según varios estudios parece que tener objetivos c laramente definidos. el apoyo de la alta admini stración, la comunic ac ión adecuada y los mecanismos de control y retroalime ntación son factores esenciales. C ontar con estos fac tores no garantiza e l éxito del proyecto, pero es claro que el no tenerlos aumenta significativamente la posibilidad de fracaso. Muchos de los fac tores relacionados con el é xi to y fracaso están interrelacionados: es decir, cuando mejora un fac tor, con frecuencia mej orarán otros. Por ej emplo, considere el uso de software para AP que o frece la ventaja de ayudar con la program ación, e l presupuesto y el control del proyecto. En este caso, los paquetes de software también pueden mejorar la comunicación entre los
10
CAP ITULO 1
INTRODUCCIÓN A LA ADMINISTRACIÓN DE PROYECTOS
Considerado uno de los mejores parques d e béisbol constru idos en los últimos años, Safeco Field costó en total 350 millon es de dólares, casi 100 m illones más que su presupuesto origina l. Algunos responsables afirman que los excedentes en costo fueron el resu ltado de una mala admin istración y negligencia.
participantes en e l proyecto, en especial e l software para AP basado en Internet que proporc iona también una retroalimentación decisiva y mecanismos de control.
Resultados de un proyect o de tecnología de la información Los proyectos de tec nología de la información (TI) tie nen una tasa de fracaso alta debido a l enom1e rie sgo asociado a estos proyectos. Después de estudiar muchos proyectos de TI, Flowers ( 1994) concluyó que todo proyecto de TI será un fracaso si: •
"el sistema como un todo no opera como se esperaba y si su desempeño global no es óptimo";
•
"al implanlarlo no se comporta como se pretend ía originalmente o si es tan hostil para los usuar ios que lo rechazan y lo usan poco";
•
"el costo de su desarrollo excede cualquier bene ficio que pudiera prod uc ir durante su vida útil ", y
•
"debido a problemas con la complejidad de l sistema o con la administrac ión del proyecto, se abandona el desarrollo de l SI antes de terminarl o".
Un examen de l esfuerzo realizado por la Health Care Financing Administration (HCFA; organi smo que administra el plan Medicare de Estados Unidos), para desarrollar un sistema de TI para administrar las reclamaciones de Medicare, arroja más información sobre las causas de l fracaso de un proyecto de TI (vea el apé ndice al final del capítulo). Frie! (2000) describió recientemente e l desafortunado esfuerzo realizado por HCFA para desarrollar un sistema de tramitación Medicare que al final fue abandonado después de seis años de desarrollo y $50 millones e n costos. Después de estudiar el fracaso del proyecto Friel concl uyó que del caso HCFA podían apre nderse las siguientes lecc iones: • •
Establecer una programación realista. Saber qué se quiere antes de pedirlo .
•
Evilar q ue la misión pase inadvertida.
•
Tener un proceso de rev isión de las inversiones.
•
Manejar las expectativas.
•
Reducir los riesgos tanto como sea posible.
MEDIDAS DE ÉXITO O FRACASO DE UN PROYECTO
11
Frie! señala que HCFA había dado tres años al principal contratista para presentar el producto linal, con poca o ninguna supervisión en el ínterin. Este error de no definir programas adecuados y no vigilar el progreso del proyecto fue uno de los pri ncipales factores para el fracaso. Frie! menciona que los administradores de HCFA no conocían por completo su sistema actual, ni lo que querían que hiciera el nuevo sistema (no hubo objetivos identificados con claridad). Debido a esta falta de entendimiento, los administradores de HCFA hacían numerosas modificaciones a las especificaciones del nuevo sistema, ocasionando retrasos significativos y aumentos en los costos. También por la falta de conocimiento, la HCFA continuamente agregaba nuevos requerimientos al proyecto, conforme sus administradores entendían más el funcionamiento de su propio sistema. La comunicación fue también un problema. Según Frie!, HCFA "prometió la luna y entregó mucho menos". Es evidente que la complejidad del sistema y la cantidad de personas involucradas aumentaron los problemas de comunicación en HCFA. Por último, la HCFA no implantó incentivos y controles adecuados para sus contratistas; Frie! indica que ahora HCFA ha cambiado, en sus proyectos de TI, a contratos basados en el desempeño con la programación y los incentivos adecuados. Muchos de los proyectos de TI se emprenden sin establecer un propósito o visión claros, como se ve en el proyecto de la HCFA. Más aú n, cuando se establecen, con frecuencia no se comunican al resto del equipo o de la organización del proyecto. Un segu ndo tema relacionado que parece común a muchos proyectos de TI, es no establecer metas realistas. No es de sorprender que esto ocurra con frecuencia cuando la alta administración no incluye admjnistradores de proyectos y miembros del equipo en todas las etapas del proceso de planeación. La falta de una comunicación efectiva parece ser un ingrediente importante en la mayoría de los fracasos de proyectos de TI. Por último, el fracaso de muchos proyectos de TI puede atribui rse a factores exógenos a la organización. La tecnología sigue cambiando con paso rápido y las predicciones que Gordon Moore hizo en 1965 se siguen cumpl iendo: cada dieciocho meses la velocidad de los procesadores y la capacidad de la memoria parece duplicarse por el mismo costo. La implicación es clara. En un proyecto de TI que dura más de un año, lo más probable es que la tecnología sea obsoleta al terminar el proyecto, suponiendo que el proyecto termina a tiempo.
¿Cuándo "abandc;:m ar" un proyecto? Relacionado con el tema del éxito o fracaso de un proyecto está saber cuándo abandonar un proyecto en marcha. Suspender un proyecto significa que debe existir un sistema efectivo de control y supervisión, así como métricas que indiquen cuándo el proyecto ha llegado a un punto en el que ya no es eficiente salvarlo. Es claro que esta es una decisión difícil y un reto en la mayoría de las organizaciones donde admi nistradores y empleados están comprometidos con la terminación exitosa de un proyecto.
Las recientes fallas en dos misiones a Marte sugieren que la NASA se está presionando demasiado para hacer más con menos dinero y que está aniesgando el éx.ito al dar una atención inadecuada a los riesgos, dijeron hoy dos paneles de examinadores. En su segundo informe al organismo, el consejo que revisó la falla de la misión Mars Climate Orbiter el año pasado dijo que las lecciones obtenidas de este percance y de otraS fallas con el enfoque de hacerlo más rápido y más barato indicaron que tal vez hubo demasiado énfasis en reducir los gastos y realizar las misiones rápido. "El éxito de 'más rápido, mejor y más barato' se contrarresta por el hecho de que algunos programas y proyectos han dado demasiada importancia a la reducción de costos y tiempos", dijo el panel, el Mars Climate Orbiter Mishap Investigation Board, un grupo de expertos de la NASA presididos por Arthur G. Stephenson, director de Marshall Space Fligh Cemer en Alabama. Fuente: W. Leary, New York Times, 14 de marzo del 2000.
12
CAPiTULO 1
INTRODUCCIÓN A LA ADMINISTRACIÓN DE PROYECTOS
Perder de vista los objetivos de un proyecto puede llevar el proyecto al fracaso.
111E FAR S/l>E"
por 61\Rf
I.AASOH
1 t
J
r=:::::::::i
1
t ~~~~~ i ~
io
) ~
a ~
a ~
lli:Ct"------"'---'-........_._. l "Oí!Jdll -· ~•l'U"n un tnGidoto muuto, -· olvidamos al ganodo"
Staw y Ross (1987) tratan este tema con más detalle, indicando que con frecuencia es benéfico para una organización diseñar un proyecto en fonna modular. De esta manera, es posible que la organización obtenga ganancias de un proyecto que se abandona antes de tiempo. Staw y Ross citan el proyecto del Túnel Profundo en Chicago hace varios años, como un ejemplo de un proyecto así. En ese caso el proyecto (para actuali zar el sistema de drenaje de la ci udad) se diseñó de modo que beneficiara a la ciudad sólo cuando estuviera termi nado por completo. Cuando se interrumpió el proyecto debido a falta de presupuesto, Chicago no tenía nada que mostrar como resultado de sus esfuerzos y gastos considerables. Cuando las fuerzas cambiantes del mercado hacen evidente que el proyecto no puede tener éxito, los administradores deben interrumpir el proyecto prematuramente. Esto es crucial en especial en proyectos de TI debido a la naturaleza de cambios rápidos de la tecnología subyacente. Es comprensible ~ue muchos administradores se muestren renuentes a abandonar un proyecto, ya que carrera y ego se vinculan a los proyectos. También la falacia de los costos no recuperables juega un papel imporlante (¿cómo vamos a tenninar un proyecto cuando ya hemo invertido millones de dólares?). El resultado es que los proyectos continúan mucho más allá de un punto "sin regreso" (o con regreso "negati vo"). Para evitar este problema, los administradores deben supervisar y controlar los proyectos con cuidado. En la etapa de planeac ión es necesario defin ir - y después hacer cumplir-los puntos cruciales donde un proyecto debe de abandonarse si es necesario. Esto se discute ampliamente en el capítulo 8 que se ocupa del tema de supervisión y control.
CICLO DE VIDA DE UN PROYECTO Existen muchas maneras de ver el ciclo de vida de un proyecto. La figura 1.4 presenta una interpretación que define cua1ro etapas: 1.
Fonnulación y selección
2.
Planeación
3.
Programación y control
4.
Implantación y tenninación del proyecto
En la primera etapa (fonnulación y selección), los administradores definen (y refinan) el proyeciO y su alcance, y consideran su impacto en el plan estratégico de la organización. Suponiendo
TRUEQUES EN LA ADMINISTRACIÓN DE PROYECTOS
Etapa 1
Etapa 11
Etapa 111
Etapa IV
Formulación y selección
Planeación
Programación y control
Implantación y terminación
13
que e l proyecto se elige para desarrollarlo, los administradores procederá n a una planeación más detallada en la segunda etapa. En ella definen las tareas específicas que constituirán el proyecto y estiman los recursos (trabajadores, materiales, etcétera) que serán necesarios para terminar con éxito el proyecto. Como parte de la etapa de planeación, los administradores deciden qué tareas se subcontratarán y definen las licitaciones para estas tareas. La etapa de planeación es crítica; es aquí que se define la regla 6P de la administración de proyectos: Prior P lanning P recludes Poor Project Performance (la planeación previa previene un pobre desempeño del proyecLO) El trabajo en e l proyecLO es más intenso durante la tercera etapa; como se indica en la figura 1.4, los recursos asignados al proyecto alcanzan su máximo e n esta etapa. Por último, en la cuarta etapa el proyecto se implanta y se entrega a los usuarios (ésta es la etapa en la que los usuari os ocupan un nuevo edificio o en la que se inserta una nueva componente a l proceso de ensamble). En el segundo capítulo se analiza con más detalle esta perspectiva del ciclo de vida de un proyecto, así como el inicio y selección del proyecto y la etapa de planeación del proyecto. La relación entre planeación, programación y funciones de control se indica en la fi gura 1.5. Como se ve e n la figura 1.5, en la etapa de planeación el equipo del proyecto determi na un pronóstico base para el proyecto que sirve como punto de comparación o evaluación (benchmark) de l desempeño futuro. Después, conforme se realiza el proyecto, el equipo vig ila las desviaciones de este plan de evaluación. El problema de controlar el proyecto se convierte en un problema de determinar si estas variaciones son el resultado de fluctuaciones aleatorias o representan un problema estructural que debe ser atendido por el equipo del proyecto. Cuando ocurre esto último, el equipo , del proyecto debe emprender las acciones necesarias para que el desempeño de l proyecto quede de nuevo bajo control.
TRUEQUES EN LA ADMINISTRACIÓN DE PROYECTOS La administración de proyectos se puede ver como una serie de trueques entre objetivos múltiples; los admini stradores tienen que decidir cuáles on las metas más importantes, y cuáles se pueden re lajar, con objeto de lograr un éxito global para la organización. Por ejemplo. en muchos proyectos de desarrollo de un nuevo producto, el tiempo para lanzarlos al mercado (o sea, la programac ión) es la meta más importante, mientras que la meta de presupuesto puede ser de me nor consideración. En otros proyectos donde e l presupuesto es la mayor preocupació n, tal vez los adm inistradores deban revisar el diseño y las especificaciones del proyecto a fin de terminar e l proyecto a tiempo y dentro del presupuesto señalado. Los administradores de una organización tan1bién tienen que considerar los trueques entre la cartera de proyectos en curso y los futuros, así como el
14
CAPÍTULO 1
FIGURA 1.5 Relación entre planeación, programación y control de un proyecto
INTRODUCCIÓN A LA ADMINISTRACIÓN DE PROYECTOS
Planeación del proyecto
WBS
Prog ramación del proyecto
Control del proyecto
,....----.........- - - - , Red de precedencias 1~
Desviaciones del plan
Datos del desempeño real de la tarea
~
-1 1 1 1 1 1 1
--
1
1 1
Diagrama de Gantt
1 1 1 1 1 1
Tiempo
Selección de programación
Costo¡
y¿
Informes periódicos de costos
.,. 1 1
1 1
Tiempo
1
1 1 1 1
Asignación de recursos Implantación del plan
f¡ 7
rápidamente cambiante entorno tecnológico. Todos estos factores determinan la importancia relativa de cada proyecto y el nivel de recursos que se le pueden asignar. Estos trueques pueden visualizarse si el proyecto se ve como un cubo en el que cada eje representa una meta importante del proyecto: costo, tiempo y alcance, con la calidad como cuarta dimensión. En la figura 1.6 se representa la relación entre estas dimensiones.
TRUEQUES EN LA ADMINISTRACIÓN DE PROYECTOS
FI GURA 1.6 Trueques entre tiempo, costo y diseño de un proyecto
15
Diseño/ Alcance Desempeño requerido
...._Trueque
e
t iempo-cost.o óptimo
LID D Limite de presupuesto
~----------~--------~~----~Costo
Tiempo
Muchos administradores de proyectos experimentados saben que en términos realistas pueden lograr una (o quizás dos) de estas metas en casi todos los casos. Dado que la meta de la calidad es la menos visible y la más difícil de medir, con frecuencia no se logra en los proyectos. Si el alcance se mantiene constante, es comprensible por qué las metas de costo y tiempo a menudo no se satisfacen. En la etapa de planeación del proyecto, los administradores suelen suponer que una o más metas son constantes (como el alcance) y optimizan los objetivos restantes (como el truque tiempocosto). Esto ocurre con frecuencia en situaciones de licitaciones, es decir, el diseño se considera fijo y el cliente propone un presupuesto. El licitador, dado un diseño fijo, sólo puede competir con base en el tiempo y el costo (es raro que se tome en cuenta la calidad en estos intercambios). Sin embargo, cada vez más organizaciones reconocen la necesidad de considerar trueques simultáneos entre las cuatro dimensiones. Para lograr esto, las empresas están usando equipos de proyecto multifuncionales (equipos de diseño-construcción), en los que se involucra al contratista en el proceso de diseño, así como en la determinación del costo y la programación. Las empresas japonesas, así como algunas empresas estadounidenses, han empleado con gran éxito este enfoque. Beck y Cleal (1999) van más allá y sugieren que las organizaciones hagan contratos de "alcance opcional"; estos contratos requieren que el proveedor cumpla las metas especificadas de tiempo, costo y calidad, pero es libre de cambiar el alcance del proyecto. De este modo un contratista, que encuentre problemas ine pcrados, puede modificar el alcance del proyecto, pero deberá mantener las metas de tiempo, costo y calidad establecidas. Beck y Cleal afirman que un proveedor con un contrato de este tipo tendría aún el incentivo de terminar un diseño razonable. con la esperanza de obtener otros contratos. Argumentan que taJes contratos podrían ser efectivos si en ellos se mantienen plazos cortos y si hay un método claro para medir la calidad del proyecto. • ' Algunos opinan que los trabajadores subcontratados por muchas empresas representan de hecho contratos de "alcance opcional".
16
CAP(TU LO 1
INTRODUCCIÓN A LA ADMINISTRACIÓN DE PROYECTOS
ALCANCE DE ESTE LIBRO Este libro se ocupa de los aspectos de trueques o intercambios entre estas cuatro dimensiones y de las herramientas y técnicas disponibles para ayudar a los adrrúnistradores en la toma de decisiones. Una mejor comprensión de trueques conduce a mejores decisiones y mejor administración de proyectos. Además, el libro hace hincapié en las herramientas disponibles para los administradores de proyectos incluyendo la mayor par1e de los paquetes de software para AP. Aunque el uso de estos productos es amplio, tienen limitaciones significativas en su capacidad para analizar muchos de los trueques o intercambios complejos que se presentan en casi todos los proyectos. Para proporcionar un marco más general para el análisis de trueques en AP, se presentan varios modelos en hojas de cálculo a lo largo del libro. El lector debe tener en mente que la mayoría de los paquetes de software disponibles en el mercado hoy en día, son sólo algo más que modelos especializados en hojas de cálculo; todo lo que hace la mayor parte de los productos de software para AP se puede hacer con una hoja de cálculo (aunque tal vez no tan rápido o tan sencillo). Sin embargo, para proyectos pequeños los modelos en hojas de cálculo ofrecen mayor flexibilidad. Por ejemplo, los administradores de proyectos pueden usar las características de optimización de los modelos en hoja de cálculo para analizar los trueques (algo que no suelen incluir los productos de software para AP). También pueden usar el generador de números aleatorios integrado en casi todo el software de hojas de cálculo y construir modelos de simulación Monte Cario para analizar el riesgo de un proyecto. Esperamos que el uso de modelos en hojas de cálculo proporcione al lector una mejor comprensión de las decisiones de truques que deben tomar los administradores de proyectos, así como del software para AP ex.istente como ayuda en la toma de estas decisiones. Por último, debe mencionarse de manera explícita que la administración de proyectos, igual que la admin istración en general, es en esencia una actividad práctica. Es como andar en bicicleta: muy difícil o casi imposible aprenderla en un libro. Sin embargo, el autor espera que este libro sensibilice a los admi nistradores de proyectos en cuanto a los aspectos que deben considerar al admjnjstrar proyectos complejos. Al enfocarse en los trueques y problemas de AP, los administradores de proyectos tendrán una mejor comprensión de los factores que llevan a los distintos resultados (tanto buenos como malos) de los proyectos, y al hacerlo serán más capaces de manejar con efectividad estos factores.
ADMINISTRACIÓN DE LOS RIESGOS DE UN PROVECTO Una parte crucial de la administración de cualquier proyecto es definir y analizar los riesgos asociados con ese proyecto. Los riesgos de un proyecto están definidos por dos elementos: 1) la probabilidad de algú n evento o resultado adverso y 2) la severidad o costo de ese evento o resuhado. La probabilidad de cualquier evento tiene inOuencia de factores tanto exógenos como endógenos; por ejemplo, el mal tiempo (un factor exógeno) o la mala administración (un factor endógeno) pueden retrasar, de igual manera, la terminación de un proyecto. En cualquier caso, los costos para la organización pueden ser los mismos (costos de retraso, pérdida de la confianza del cliente, etcétera); sin embargo, a diferencia del mal tiempo, la mala administración a menudo puede evitarse. Este ejemplo ilustra oLro factor importante en la administración de riesgo. Después de analizar los eventos adversos que pueden presentarse, el administrador de proyectos tiene dos opciones: puede tomar alg unas medidas preventivas antes de empezar el proyecto para reducir la posibilidad de eventos adversos o de sus consecuencias, o puede planear algunas acciones de contingencia en caso de que ocurra un evento adverso. En el caso de mal tiempo, el administrador de proyectos puede colocar cubiertas o resguardos a una construcción (por ejemplo); esta acción preventiva aumentará el costo del proyecto. pero mitigará el impacto negativo si el tiempo se vuelve inclemente. De manera alternativa, el administrador puede planear agregar trabajadores al proyecto en el caso de que el tiempo cause rcLrasos en el programa. Este plan de contingencia se pondrá en marcha sólo si en realidad ocurre el evento negativo (mal tiempo).
HISTORIA DE LA ADMINISTRACIÓN DE PROYECTOS
17
En todos los proyectos hay numerosas fuentes de incertidumbre. como variaciones aleatorias en el desempeño de una componente, datos inexactos o incompletos y no tener la posibilidad de hacer un pronóstico por falta de información, experiencia o prevención. Para reducir el riesgo general de los proyectos, muchas organizaciones usan diferentes enfoques, que incluyen la selección de una cartera de proyectos para minimizar el riesgo, de la misma manera que un inversionista diversifica una cartera de acciones. Subcontratar parte (o todo) el proyecto es otra manera de disminuir el riesgo del proyecto; el tipo de contrato firmado con un contratista tiene implicaciones significativas en cuanto a cómo se distribuirá el riesgo entre los interesados. Los administradores de proyectos también deben reconocer que el reverso del riesgo es el beneficio potencial. El riesgo abre nuevas oportunidades a una organización para expandir su línea de productos, mejorar sus productos y mejorar su base de conocimiento. Entre mayor es el riesgo, mayor será el beneficio potencial. El asunto no es controlar el riesgo, sino manejarlo. Por último, hay que hacer notar que la mayor parte del software de AP no toma en cuenta el riesgo directamente. Sin embargo, al usar los modelos de hoja de cálculo de este libro, los administradores de proyectos podrán aprender cómo analizar el riesgo como parte de un plan del proyecto. Los temas de análisis de riesgo y de administración de riesgo se analizan con más detalle en el capítulo 7.
I STORIA DE LA ADMINISTRACIÓN DE PROYECTOS Desde el comienzo de la historia ha habido administradores de proyectos. De hecho, algunos teólogos dirán que el primer administrador de proyectos creó el cielo y la tierra en siete días (con un día adicional como amortiguador para contingencias inesperadas). Muchos proyectos, como las pirámides egipcias de Giza (2590 AC), el Coloso de Rodas (292 AC- 645 DC) y el Astrodomo de Houston (1965), proporcionan ejemplos de una buena administración de proyectos de construcción masiva. Sin embargo, otros dos proyectos tuvieron quizá el mayor impacto en el desarrollo y práctica de las metodologías de administración de proyectos (Fondahl. 1987). Al final de los años 50, los ingenieros de DuPont Corporation estaban preocupados por el tiempo de paro para mantenimiento en su planta en Louisville, Kentucky, que se había convertido en un cuello de botella e11 su proceso de producción de neopreno. Para evitar la construcción de otra planta, los ejecutivos de DuPont contrataron a la empresa Catalityc Construction Company para que estudiara la planta de Louisville y sugiriera una manera de reducir el tiempo de mantenimiento. El estudio, que indicaba que era posible disminuir significativamente el tiempo de mantenimiento de la planta en Louisville, estuvo basado en una nueva metodología que ahora se conoce como el método de la ruta crítica (CPM, critica[ parh method). Como resultado de este estudio, los ingenieros pronosticaron que la producción en la planta de Louisville podía aumentarse a un nivel tal, que ya no sería cuello de botella ni sería necesaria otra planta. Aproximadamente al mismo tiempo, los asesores de la empresa Booze, Allen y Hamilton desarrollaban un nuevo sistema de AP para el programa Polaris Fleet Ballistic Missile de la Oficina de Proyectos Especiales de la Marina de Estados Unidos (US Navy's Special Proyects Office). El misil Polaris, el primer misil balístico intercontinental que podría ser lanzado desde un submarino sumergido en el agua, representaba el mayor (y uno de los más arriesgados) intento de investigación y desarrollo realizado a la fecha. Dada la incertidumbre involucrada en el proyecto, los administradores querían una metodología que no sólo incorporara la incertidumbre en la planeación, si no que también les permitiera estimar probabilidades de eventos importantes (por ejemplo, si el sistema de propulsión avanza como fue planeado, ¿cuál es la probabilidad de que podamos hacer un lanzamiento de prueba en una fecha determinada?). La metodología desarrollada para ayudar en la administración de este proyecto se conoció como PERT (técnica de revisión y evaluación de programas, o Program Evaluation and Review Technique) e introducía explícitamente la incertidumbre a la programación y el proceso de asignación del proyecto. Los
18
CAPITULO 1
INTRODUCCIÓN A LA ADMINISTRACIÓN DE PROYECTOS
conceptos básicos de PERT. así como sus ventajas. y desventajas y las herramiemas correspondientes se analizan con más detalle en el capítulo 6. El estudio de DuPont y las ventajas potenciales de las nuevas técnicas de CPM y PERT se publicaron en Business Week ( 1959) y en Fortune (1962). En 1963, Levy et al. ( 1963) publicaron un texto sobre CPM en Harvard Business Review. Después de la publicación de este artículo, tanto CPM como PERT se usaron ampliamente en organizaciones públicas y privadas (algunas estaban dispuestas, otras no). Estas tecnologías forman la base de la mayoría de los sistemas de AP que se usan actualmente. Aunque los términos CPM y PERT con frecuencia se usan como sinónimos, este libro usa estos acrónimos según su definición ori ginal. Específicamente, CPM se refiere a casos en los que la duración de las tareas y otros parámetros son determinísticos y se conocen con total certeza, mientras que el modelo de PERT supone que las duraciones de las tareas son variables aleatorias que pueden describirse mediante una distribución de probabilidad adecuada. Es importante hacer notar que la vasta mayoría de los programas de software comerciales para AP se basan en el modelo CPM (aun cuando muchos de ellos usan el término PERT en su documentación o en su tirulo).
SOFTWARE PARA ADMINISTRACIÓN DE PROYECTOS Los paquetes de software para AP tienen hoy una amplia difusión y los hay de muchos precios. Casi todos los programas caen en una de dos categorías: programas de bajo costo, diseñados para un solo usuario en una computadora personal , y programas de mayor costo, diseñados para una red de un conjunto de computadoras. Parece que la tendencia actual va hacia el segundo tipo de programas; dada la importancia de una comunicación efectiva para el éxito de la administración de proyectos, es crucial tener un mecanismo que permita a todos los que participan en el proyecto compartir datos e información en tiempo real. Como se observó, la mayoría de los paquetes comerciales de software para AP se basan en el método de la ruta crítica (CPM); es decir, se supone que todos los parámeLros, como la duración de las tareas, son conocidos y constantes. Casi todos los paquetes de software sirven para dibujar diagramas de Gantt (diagramas de barras), redes de precedencias e histogramas de niveles de recursos, así como para ¿ ealizar cálculos básicos y proporcionar otros diagramas y cálculos para planeación y control. En este libro se demuestran casi todas las funciones empleadas en los productos populares de software para AP, mediante plantillas de hojas de cálculo que renejan esas funciones. El lector podrá to mar los ejemplos dados en el libro e introducir este material en el software de su elección (como Microsoft Project, que se proporciona en el disco compacto que acompaña al libro). Además del software para AP, hay cada vez más "complementos" que incrementan la funcionalidad de los productos para AP. Por ejemplo, hay programas que permiten al usuario incluir simulaciones de Monte Cario en el software para AP. De esta manera se puede incluir directamente la incertidumbre en la etapa de planeación del proyecto y se pueden realizar análisis de sensibilidad. De nuevo, se demostrará la funcionalidad de estos complementos usando plantillas de hoj as de cálculo.
PROJECT MANAGEMENT INSTITUYE El Project Management Institute (Instituto para la Administración de Proyectos) es una organización profesional no lucrativa que promueve la adminisrración de proyectos. Fundado en 1969, el PMI se ha convertido en una organización internacional que tiene actualmente más de siete mil miembros. El PMI patrocina seminarios y talleres, así como un proceso de certificación que cubre sus doce áreas de "conocimientos" (project management body of knowledge, PMBOK®). El PMI ha promovido la idea de que la administración de proyectos requiere un conj unto de habi lidades y un cuerpo de conocimientos que son únicos para administrar proyectos. Puede enconrrar más información sobre el PMI en el sitio www.pmi.org.
APÉNDICE lA. TRANSACCIONES M EDICARE: UNA LECCIÓN EN ADMINISTRACIÓN DE PROYECTOS DE 50 MILLONES DE DÓLARES
19
M ODELOS DE MADUREZ EN ADMINISTRACIÓN DE PROYECTOS Reconociendo que la administración de proyectos es un proceso avanzado que es más que herramientas y software, algunos investigadores han desarrollado metodologías para evaluar el nivel de competencia en AP de una organización. La motivación detrás de estas metodologías es que las organizaciones mejorarán su capacidad para la AP si evalúan con cuidado su competencia actual y tienen lineanUentos para mejorar. Muchos de estos modelos se basan en amplias investigaciones empíricas que sirven como bases de datos para práctica, así como de lineamientos para mejorar procesos. Mucho del trabajo inicial en esta área fue desarrollado por investigadores del Instituto de Ingeniería de Software (SEI, Software Engineering lnstitute) de Carnagie-Mellon University con objeto de mejorar los procesos de desarrollo de software; el Modelo de Madurez de Capacidades del SEI (SEI Capability Maturity Mode[), antecesor de la mayoría de los modelos de madurez, consta de seis niveles de capacidades: • • •
Incompleto Realizado Administrado
• • •
Definido Administrado cuantitativamente Optimizado
Se han construido muchos otros modelos de madurez de AP siguiendo el marco de trabajo de S El. Puede obtener más información de los modelos de madurez de AP en Kert.ner (200 1) así como en los siti os de Internet de SEI y del Project Managementlnstitute (PMI).
A PÉNDICE 1A. TRANSACCIONES MEDICARE: UNA LECCIÓN EN A DMINISTRACIÓN DE PROYECTOS DE 50 MILLONES DE DÓLARES La administración del financiamiento para la atención de la salud (HCFA, Healrh Care Financing Administration), la dependencia que administra Medicare, invirtió seis años, de 1991 a 1997. y por lo menos 50 millones de dólares en el desarrollo del Medicare Transaction System. Hoy, el plan estratégico de ochenta y dos páginas de la HCFA para tecnología de la información en los próximos cinco años, no menciona el desafortunado sistema y sólo hace referencia a Jos "esfuerzos de inversión en TI anteriores de la HCFA". El director de información de la HCFA, Gary Christoph, contratado después de que se canceló el desarrollo del MTS, dijo que la dependencia está cambiando. "Algunos de los conceptos del MTS eran realmente buenos conceptos. Lo que falló fue la implementación" dice Christoph. "Cuando uno crece, primero aprende a gatear, luego camjna, luego corre, luego aprende a andar en bicicleta. Uno no salta de pronto a un Ferrari." La historia de los problemas computacionales de HCFA son problemas típicos de las dependencias federales: a lo largo de los años el Congreso ha creado numerosos programas bajo el dominio de la dependencia. Para cada nuevo programa, la dependencia construye un nuevo sistema de información usando lenguajes de programación, plataformas y contratistas diferentes. Cada sistema parece ser de propiedad exclusiva (lo que dificulta actualizarlo o lograr que compar1a información) y estar escrito en lenguajes populares en los años 50 y 60, como el COBOL. Después, en algún momento de los 80, la dependencia se da cuenta de que su sistema se volvía inmanejable. Así, decide construir un gran sistema integrado para manejar todos los programas de la dependencia, una solución que espera que con el tiempo logre grandes ahorros (por supuesto después de una significativa inversión inicial). Es evidente que manejar un sistema es menos costoso que manejar muchos sistemas. Los gerentes de tecnología se imaginan ya el glorioso día dentro de cinco años cuando corten el listón, desempaquen el nuevo sistema, y disfruten el aplauso del
20
CAPÍTULO 1 INTRODUCCIÓN A LA ADMINISTRACIÓN DE PROYECTOS
administrador de la dependencia, el entusiasmo de los miembros del Congreso y la aprobación de los contribuyentes. Pero usted conoce los resultados. En el caso de la HCFA, la dependencia publicó una solicitud de propuestas para su mega-sistema el 17 de septiembre de 1992. Pero aun antes de qu e se publicara la solicitud, el inspector general del Departamento de Servicios de la Salud y Humanos recomendó a la HCFA que esperara y "siguiera un enfoque más orientado a la estrategia para simplificar, consolidar e integrar el procesamiento de los trámites de Medicare". Cuatro meses después de que saliera la solicitud para propuestas, el inspector general sugirió que la HCFA necesitaba definir con mayor claridad qué quería que hiciera el Sistema de Transacciones de Medicare. El inspector general recomendó también que la HCFA se asegurara que los contratistas comprendieran que Medicare es un programa en cambio constante que necesita un software adapLable y flexible. En respuesta, la HCFA esLableció once grupos de trabajo para examinar los diversos aspectos del procesamiento de Medicare y proporcionar información a los contratistas. Después el número de grupos de trabajo se ampliaría a veinticuatro. Entre tanto, en enero de 1994, la dependencia otorgó a GTE Goverment Service el contrato para el MTS. En abril de 1994 la HCFA contrató a lntermetrics Inc., una pequeña empresa en Virginia, hoy conocida como AverStar, para vigilar independientemente el progreso del contrato. "Este nuevo sistema hará realidad una nueva era de servicio y conveniencia para los beneficiarios de Medicare" anunció la secretaria del HHS, Donna Shalala, en un comunicado de prensa en enero de 1994. "Este nuevo sistema emplea los últimos avances de la tecnología para rempl azar los formatos e inconvenientes que han caracterizado a Medicare en el pasado." El sistema quedará terminado a fines de 1998, decía el comunicado. GTE empezó a planear una estrategia para combinar en un sistema los catorce sistemas de Medicare que se encontraban en sesenLa sitios operados por más de setenta contratistas, mientras los grupos de trabajo intentaban darle sentido a la arquitectura del sistema de la dependencia. Por todos lados había señales de peligro. En diciembre de 1994, e l inspector general indicó, una vez más, a la HCFA que no había proporcionado suficiente información a GTE para ayudarle a planear la complejidad del procesamiento de Medicare. El año siguiente HCFA aseguró al inspector general que)Jabía empezado a proporcionar información amplia a GTE. El sistema estaba bajo control y se implementaría en septiembre de 1999. En noviembre de 1995, la oficina de contraloría general resaltó varias inquietudes respecto al MTS en un informe a la comisión de reformas del gobierno, que incluían falta de claridad en los requerimientos del contrato, un programa muy apretado y falLa de información confiable de costobeneficio. El administrador de la HCFA, Bruce Vladeck, respondió: "estamos conscientes de que se trata de un proyecto de alto riesgo. EsLamos realizándolo con una clara visión de la necesidad de administrar el riesgo involucrado". A mediados de 1996, Intermetrics advirtió a la HCFA y a GTE que la agenda de desarrollo del MTS tenía demasiados eventos imporLantes que se traslapaban, pero esa advertencia no fue escuchada según lo atestiguó un oficial de Intermetrics en una audiencia en mayo de 1997. Un mes an tes de esa audiencia, la HCFA ordenó a GTE suspender 90 días el trabajo en todos los segmentos del MTS, excepto uno, para evaluar las razones del excesivo aumento en los costos y el retraso constante en las fechas de entrega. En mayo de 1997, la oficina de contraloría insisti ó en que el MTS tenía grandes problemas. La HCFA no había planeado una programación adecuada del proyecto, no tenía medidas de desempeño para evaluar el progreso, y no había usado "un análisis costo-beneficio ni otras herramientas para el seguim iento y evaluación continuos de los fondos gastados e n el MTS y si contribuirían para el retorno sobre la inversión", dij o la oficina de contraloría. Además, los costos del proyecto del MTS se habían incrementado de $151 millo nes a $ 1 000 millones. La contraloría estimó
PROBLEMAS PARA ESTUDIO
21
que la HCFA había gastado hasta entonces $80 millones en el proyecto, aunque la HCFA aseguraba que el gasto total en el MTS fue $50 millones. En respuesta, HCFA, GTE e incluso lntermetries prometieron que terminarían el MTS, si bien, quizá no antes del 2000. Tres meses después la HCFA canceló su contrato con GTE. "Cometimos un error importante en la experiencia (del MTS) y quizá fue confiar demasiado en la habilidad de los contratistas para cumplir con su entrega", dice Vladeck, el administrador anterior. Hasta mediados del 1998, la HCFA siguió trabajando para reducir el número de sistemas en los que se apoyaba. Entonces suspendió todo intento de modernización para asegurarse de que los ci ncuenta millones de líneas de código de software no tuvieran fallas técnicas potenciales para el año 2000. La HCFA no salió del proyecto del MTS con las manos vacías. La dependencia red ujo el número de contratistas y de sitios que administraba el sistema de procesamiento de Medicare e integró sus catorce sistemas en seis. Además, el proyecto les dio a los funcionarios de la dependencia una mejor comprensión cómo operan sus sistemas controlados en principio por los contratistas. "La HCFA obtuvo del MTS una estrategia mucho más clara de corto a mediano plazo, para la administración del procesamiento de solicitudes", dice Vladeck. De hecho, Vladeck afinna que tal vez se hubiera podido salvar el MTS después del fracaso de GTE excepto por dos factores. Primero, el Congreso y la administración de Clinton no consideraron muchos de los beneficios que podrían justificar el alto costo de un solo sistema integrado, que incluyen mejor detección de fraudes y mayor eficiencia e n el procesamiento. Segundo, el proyecto fue víctima de la noción que aún prevalece y que fue primero defendida por el director anterior de administración y presupuesto, Frankiln Raines, de que los proyectos tan grandes simplemente no funcionan. El proyecto no logró realizar la visión propuesta por Shalala en 1994. No existe un sistema único para el procesamiento de Medicare. Según el nuevo plan a cinco años para tecnología de la información de la HCFA, su sistema actual aún "refleja claramente la filosofía de negocios y diseño de sistemas de una era en la que, por ejemplo, el procesamiento de solicitudes era en gran parte una función a través de documentos ... a pesar de operar en equipo más nuevo". Fueme: B. Friel , "Medicare Transactions: A $50 Million Lesson In Project Management", Govemment Executive (abril 2000):"
PROBLEMAS PARA ESTUDIO 1. ¿Cuáles serían los beneficios de una aplicación de técnicas de AP en un proyecto en el que ha estado involucrado? Considere cómo definiría las tareas específicas y su duración en este "proyecto". ¿Cuáles fueron las metas del proyecto? ¿Qué restricciones se impusieron al administrador del proyecto? 2. Considere la formación de un equipo de proyecto. ¿Qué características piensa usted que deben tener los miembros del equipo? ¿Debe estar compuesto por miembros con capacitación y antecedentes similares o deben tener habilidades y preparación diferentes? ¿Cómo debe operar el equipo de un proyecto? ¿Quién debe tener la responsabil idad final del desempeño del equipo? 3 . Considere la relación entre el equipo de un proyecto y las partes funcionales de una organización. ¿Quié n debe tener la responsabilidad de aprobar tareas específicas? Si una tarea de ingeniería se extiende más allá de la duración y el presupuesto propuestos, ¿quién es el responsable, el director del área de ingeniería o el administrador del proyecto? En generaL ¿cómo cree que debe manejar los proyectos una compañía organizada por funciones? 4. Suponga que su empresa puede escoger entre más de una docena de proyectos, pero sólo puede elegir un número limitado de ellos. ¿Qué criterios sugeriría para clasificar los proyectos? ¿Cómo decidiría qué proyectos seleccionar?
22
CAPÍTULO 1
INTRODUCCIÓN A LA ADMINISTRACIÓN DE PROYECTOS
5. Investigue los modelos de madurez para AP. Empleando una de las herramientas de autoevaluación que se encuentran en Internet, investig ue cuál es el nivel de capacidades de su organización. ¿Cómo podría mejorar la competencia de su organización en AP?
REFERENCIAS Bagli. C. "Digital! y Speaking. Builders Remain on the Ground Aoor", New York 7imes, 13 de diciembre. 2000, 4. Beck, K. y D. Cleal. "Optional Scope Comracts" ( 1999), URL: www.xprogramming.com/ftp/Opúonal+scope +contracts. pdf. "Beuer Plans Come From Study of Anatomy of an Engineering Job", Business \Veek, 21 de marzo de 1959. 60-66. Boehm, G. A.W. "Helping !he Executive to Make Up His Mind'', Forllme, abril, 1962, 127. Bounds, G. "The Last Word on Project Management", 1/E Solwions (noviembre, 1998). Brown. S.L., y K.M. Eisenhardt. ''The Art of Continuous Change: Linking Complexity Theory and Ttme-paced Evolutioo in Relentlessly Shifting Organinnions", AdmínístratÍI'e Scíence Quarter/y 42 ( 1997): 1-34. Eisenhardt. K.M. y B.N. Tabrizi . "Acceleraúng Adaptive Processes: Product lnnovaúon in the Global Computer lndusuy•·. Administratil'e Science Quarrerly 40 ( 1995): 84- 11 O. Frable, F. "Dclayed Openings Are a Fact of Life in the Foodservice, Hospitality lndusuy", Narion's Restauram News (12 de abril. 1999): 18. Friel, B. "Medicare Transactions: A $50 Mi Ilion Lesson in Project Management", Governmem Executive, Naúonal Joumal (abril, 2000): 68. Griffin, A. y A. Page . ''An Failure", Mwragemem9, núm. 1 ( 1993): 291 - 308. Hughes, M.W. ''Why Projects Fail : The Effects of lgnoring the Obvious''.lndustrial Engineering (abril, 1986): 14-18. Kahneman, O.P.. P. Slovic y A. T versky. "Judgment Under Uncertainty: Hcuristics and Biases", Cambridge, U.K. : Cambridge University Press. 1982. Kerzner. H. Srraregic Planning for Project Managemem Using a Projec/ Managemem Maruriry Model. Nueva York: John Wiley and Sons, lnc., 2001. Levy, F., G.L. Thompson y J.D. Wiest. "The ABC's of the CriticaJ PaÚl MeÚlod'', Han·ard Business Review (sepúenr bre-octubre, 1963): 98-108. A Cuide ro rhe Projecr Mwragemem Body of /(Jroll'ledge (PMBOJ<® Guide). Newton Square. Pa.: Project Management lnstitute (PMI), 2000. Might, R.J. y W.A . Fischer. "The Role of Structural Factors in Dctermining Project Managemem Success", IEEE Transacriorrs on Engineering Managemem EM-32, núm. 2, mayo, 1985. Pinto, J. y D. Slevin. "CriticaJ Factors in Successful Project lmplementaúon", IEEE Transacriorrs on Engineering Managemem EM-34, núm. 1, (1 de febrero. 1987): 22-27. ''Riot-Ravaged Taco Bell Rebuilt in 48 Hours Using Project Planning Software". Industrial Engineering (septiembre. 1992): 18. Shenhar, A. ''One Size Does Not Fit AU Projects: Exploring ClassicaJ Cootingency Domains". Managemem Science 47, núm. 3 (marzo 2001): 394-41 4. "Stave Falls Wins Project of the Year Award", \Varer Power wrd Dam COIIS/ruction. Wilming1on Publishing Ltd. (3 1 de julio. 2000): 3. Staw. B. y J. Ross. "Knowing When to Pullthe Plug'·, Han·ard Business Re111ew (marzo-abril, 1987): 68-74. Sclunidt. E. " Regional Construcúon lndus try ls Going Through a Communieations Revolution", New York Constructiolt 48. núm. 8 (marzo. 2000): 59. P. Slovic, y A. Tversky, Judgmemrmder Uncerrainry: Heuristics and Biases. Cambridge. UK : Cambridge University Press. 1982. Standish Group, 1999. URL: www.standis hgroup.com/. Takeuchi, H. y l. Nonaka. "The New New Product Dcvelopment Game," Hanoard Business Review (enero-febrero. 1986). A. Vazsonyi, '"L' Histoire de Grandcur et de la Dceadence de la MeÚlode PERT', Management Science 16, núm. 8 (abril. 1970): B44~SS . Walker, R. "Dig This: Building Boom Exposes E. Germans· Prc-Communist Past", Clrristiwr Science Moniror ( 12 de agosto, 1996): 6 Wheelwright, S. C. y K. B. Clark. '·Creating Project Plans 10 Focus". Han·ard Business Review (marzo-abril. 1992): 7(}-82. Yap, C.M. y W.E. Souder. "Factors Influencing New Product Succcss and Failure in Small Entrepreneurial High· Techoology E lectronics Ftrms'', Joumal of Producr buro1•arion Management 11 ( 1994): 418-432. Yang, S. "CSOC's Shorten Design Cycles", Copyright Elecrronics News (15 de mayo, 2000): 22. Youker, R. "A New Look atthe WBS: Project Breakdown Structures (PBS)". Projecr Mmragement Joumal (1989): 54-59.
CA PÍTULO
INICIO, SELECCIÓN Y PIANEACIÓN DE UN PROYECTO
e
omo se indicó en el primer capítulo, en general, los proyectos tienen cuatro etapas: inicio y selección, planeación, programación y control, y la implantación (que incluye la terminación y la evaluac ión). Con frecuencia estas etapas se traslapan y en realidad, dicho con más precisión, se encuentran a lo largo del continuo mostrado en la fig ura 1.1 . Este capítulo se dedica a las dos primeras etapas: inicio y selección, y planeación del proyecto. Estas dos etapas son partes cruciales de la administración de proyectos, ya que se ocupan directamente del problema de "hacer lo correcto y hacerlo bien". Respecto al inicio y selección del proyecto, se analiza •
Cómo iniciar nuevos proyectos
•
Métodos para evaluar propuestas de proyectos
•
Selección de un proyecto como un problema de portafolio
•
Por qué los administradores de proyectos deben tener "opciones" en mente
Una vez que una organización empieza a considerar un nuevo proyecto con seriedad, la propuesta pasa a la etapa de planeación, donde los administradores definen con más detalle las especificaciones del proyecto, los requerimientos del usuario y las restricciones organizacionales. Una meta importante de planear u n proyecto es definir los paquetes de trabajo o tareas que constituyen el proyecto. Esto suele lograrse de¡;arrQ\\andQ una es\.ruc\ura óesg,osaóa del trabajo (EDT) que define paquetes de trabajo (tareas) específicos y estima sus costos y duraciones. Este capítulo analizará también el impacto del aprendizaje, la incertidumbre y el riesgo, así como numerosos factores del proceso de estimación de la duración y el costo. A medida que una organizació n avanza en el proceso de planeación, los administradores tienen que diseñar un esquema detallado de tiempos y recursos. Concretamente, la programación y el presupuesto base del proyecto sirven como punto de referencia durante gran parte del resto del proyecto, y con frecuencia se usa para juzgar el éx ito o fracaso final del proyecto. Por último, deben especificar el procedimiento que se usará para vigilar y controlar el proyecto una vez iniciado. Los problemas de programación y de s upervisión y control se estudiarán con detalle en los capítulos 4 y 8, respectivamente. En este capítulo se tratará también el aspecto de la subcontratación; en particular, ¿cómo deciden los administradores qué parte o partes de un proyecto deben subcontratarse?, ¿cuántos subcontratistas deberán emplearse?, ¿qué papel desempeña un subcontratista en la etapa de planeación? y ¿qué trueques deberán hacer los administradores al considerar la posibilidad de subcontratar? Este capítulo concluye con el estudio de un caso, Cristopher Columbus, Inc. Este caso analiza la relación entre la definición de metas y los requerimientos de recursos, e ilustra cómo debe usarse un plan de proyecto para desarrollar una propuesta y concursar en respuesta a licitación.
23
26
CAPITULO 2
INICIO, SELECCIÓN Y PLANEACIÓN DE UN PROYECTO
Valor presente neto (VPN) o flujo de efectivo descontado (FEO) El flujo de efectivo descontado (FED) a lo largo de la vida estimada del proyecto (conocido también como fluj o de efectivo descontado determinístico) se basa e n la suposición fundamental de que un dólar hoy vale más que un dólar mañana. El valor presente neto (VPN) es tal vez la medida más usada que tiene en c uenta e l valor del dinero en e l tiempo. Dada una tasa de interés o de descuento (también llamada tasa crítica de rentabilidad o tasa de corte). se puede calcular el flujo descontado de costos y beneficios futuros. Sea r la tasa de desc uento y F1 el flujo de efectivo pronosticado para el periodo t (es decir, F1 representa los beneficios estimados me nos los costos del periodo t), entonces el VPN o FED de un proyecto se define como
T
Valor presente neto (V PN) =
F.1
L::--
-
t=O(I + ri
donde T denota la vida estimada del proyecto. Por ejemplo, considere un proyecto que tiene seis años de vida esperada. Si se supone que la tasa de descuento anual, r, es igual a 20% y que se incurrirá e n un costo estimado de $750 en el primer año, entonces el flujo de efectivo descontado del primer año (t = 1) es
_ F._I_ (1+ r) 1
=
-$750 = - $ 625 (I .20)
Dados los costos y beneficios pronosticados para los seis años, los cálculos para encontrar el VPN se presentan en la figura 2.1. El año O representa e l momento presente; observe que los beneficios netos de este proyec to propuesto no son positivos hasta e l año 2, cuando e l proyecto empieza a gene rar ingresos y los costos rel acionados con el proyecto disminuyen a $550. Sumando los valores descontados de la última columna, se encuentra que el VPN es igual a $2 912. Como el VPN es positivo, este proyecto sf sería considerado, aunque hay muchas razones por las que una organi zación podría considerar un proyecto con VPN negativo (por ejemplo, para abrir un nuevo mercado o para bloquear a un competidor) o rechazar un proyecw con VPN positivo. Cuando los administr~dores consideran varios proyectos, pueden usar el VPN para calificar las diferentes propuestas. Au nque el VPN tiene menos limitaciones que la medida de periodo de recuperac ión, también ha sido muy c riticado (Faulkner, 1996; Cooper et al., 2000; Hodder y Riggs, 1985). Primero, e l VPN ignora el riesgo de un proyecto (o la incertidumbre que se maneja como riesgo), ya que los cálculos suponen que los flujos de efectivo pronosticados se conocen con certeza. Un problem.!. re lacionado es e l sesgo humano que es parte del proceso de estimación (o, como dijo un administrador, "¿qué números quiere ver?"). El segundo problema es que no se consideran explícitamente los efectos de la inflación al estimar la tasa de descuento r, en especial en proyectos a largo plazo.. Tercero, e l VPN ignora las interacciones con otros proyectos y programas dentro de la organización ya que trata cada proyecto propuesto e n forma individual. Éste es un punto importante; el VP. •
FIGURA 2 .1 Ejemplo de cál c ulo
deiVPN
Año
Beneficios
Costos
o
S S S 1 500 S 2 000 S 2 500 S 2 500 S 2 500
S 1 000 S 750 S 550 S 250 S 150 S 150 S 150
1 2 3 4 5 6
Beneficios - costos
S S S S S S S
(1 000) (750) 950 1 750 2 350 2 350 2 350
Beneficios -costos descontados
S(l 000) S (625) S 660 S 1 013 S 11 33 S 944 S 787
1750
+- (1.2)3
INICIO Y SELECCIÓN DE UN PROYECTO
27
puede no ser una medida efectiva cuando una organización analiza un portafolio de proyectos que compiten por Jos mismos recursos. Por ejemplo, un proyecto con un VPN positivo pequeño y que usa recursos excedentes puede ser más atracti vo que un proyecto con un VPN grande, pero que requiere nuevas instalaciones o empleados. Por esta razón, las organizaciones deben preocuparse por su portafolio de proyectos y no por un solo proyecto. La cuarta crítica se deriva de la suposición de que se usa una sola tasa de descuento para todo el proyecto. Conforme un proyecto evoluciona, es posible que el riesgo del proyecto se reduzca y, por consiguiente, también la tasa de descuento. La sección siguiente presenta un análisis de algunas de estas críticas y muestra cómo pueden mitigarse.
Tasa interna de retorno (TIR)
La tasa interna de retorno es la tasa de descuento que produce un VPN igual a cero. Dadas las incertidumbres asociadas con la estimación de la tasa de descuento y de los fl ujos de efectivo futuros, la TIR simplemente encuentra el valor de r que da un VPN igual a cero. En general, los proyectos con una TIR alta se califican más alto que los que tienen una TIR baja. Además, laTIR casi siempre se compara con el costo de capital de la organización; es decir, en la mayoría de las condiciones, un proyecto debe prometer un rendimiento mayor que lo que la organización tiene que pagar por el capital necesario para financiar el proyecto. LaTIR tiene muchas de las limitaciones del VPN: supone que el flujo de efectivo pronosticado es razonablemente preciso y real, está sujeto a los mismos sesgos de estimación que sufren los pronósticos necesarios para calcular el VPN, etcétera. Un problema más de este método es que con frecuencia no hay un valor único de r que satisfaga la ecuación VPN = O. Por ejemplo, suponga que se espera que un proyecto dure dos años (esto és, T = 2). Encontrar laTIR requiere resolver la ecuación cuadrática: ¡:, +__i_ + F2 =0 O (l+r) (l+r)2
Suponga que el proyecto propuesto requiere una inversión inicial de $100 y producirá un beneficio de $40 (beneficios !!_lenos costos) al final del primer año y $75 al fin al del segundo año. Encontrar laTI R requiere determi nar el valor de r en la ecuación:
-
loo + -40 -+ (1 + r)
75 (1 + r)2
_ - 0
que se convierte en:
r 2 + 1.6r - 0.15=0 Al resolver esta ecuación se encuentra que r puede ser igual a 0.089 o a - 1.689 (ambos valores hacen el VPN igual a cero). Aunque en este caso se puede ignorar el valor negativo de r y suponer que laTIR es igual a 8.9%, la situación se complica cuando hay muchos periodos que pueden dar múltiples valores positivos de r. Cuando esto ocurre, no está claro cómo interpretar estos valores múltiples, ni cuál valor de r debe tomarse.
Va lor comercial e sper a do (VCE) El valor comercial esperado (VCE) es el VPN esperado del proyecto, ajustado por las probabilidades de las diferentes alternativas. Las medidas del tipo VCE amplían el concepto de valor presente neto (VPN) para considerar explícitamente el hecho de que la mayoría de los proyectos constan de múltiples etapas (como diseño, mercadotecnia, prueba e implantación). Por ejemplo, considere un proyecto propuesto para el desarrollo de un nuevo producto que tiene dos opciones de diseño. El VCE considera explícitamente las probabilidades de que ocurran distintos resultados como consecuencia de la opción de diseño que se elige, y usa esas probabilidades para calcular el VPN espe-
28
CAPÍTULO 2
INICIO, SELECCIÓN Y PLANEACIÓN DE UN PROYECTO
rado. El VCE también permite a los administradores emplear distintas tasas de descuento en diferentes etapas del proyecto, con lo que responde a una de las críticas relacionadas con el uso del VPNIFED. Por esta razón las medidas del tipo VCE se emplean cada vez más. El VCE se basa en el concepto de árbol de decisiones que constituye un marco lógico para evaluar una secuencia de decisiones y resultados. En la figura 2.2 se presenta un árbol de decisiones. La "raíz" de este árbol empieza con un to mador de decisiones que el ige una de dos alternativas (A 1 o A2 ) . Si el tomador de deci siones escoge la alternativa A., entonces se pueden presentar tres resultados o situaciones (SI' S2 o S3) con probabilidades respectivas (p 1, p 2 o p 3). Si selecciona la alternativa A2, entonces pueden ocurrir otros tres resultados o estados de la naturaleza (S4, S5 o S6) con probabilidades respectivas (p.¡• p5 o p6 ). Como se ve en la figura 2.2, un rectángulo representa un punto de decisión y los círculos representan las posibles alternativas del tomador de decisiones. Este ejemplo puede extenderse fácilmente a múltiples etapas; en cada resultado (S¡), se puede agregar otro nodo de decisión que representa alternativas o resultados adicionales. Para evaluar e l árbol de decisiones de la figura 2.2, primero suponga que se selecciona la alternativa A 1• Si se elige Al' el resultado esperado es (S 1)(p 1) + (S2)(p2) + (S3)(p3); si se elige la alternativa A2 , entonces e l resultado esperado es (S4)(p.¡) + (S5)(p 5) + (S6 )(p6 ). Trabajando hacia atrás se puede encontrar e l pago esperado de cada alternativa restando el costo de cada una de su respectivo resultado esperado. Si e; denota el costo de la alternativa i (i = 1, 2), entonces el valor esperado de cada alternativa es:
Valor esperado de la alternativa 1: (S 1){p 1) + (S2 )(p2) + (S3)(p3)
-
e,
Valor esperado de la alternativa 2: (SJ(p4) + (S5 )(p 5) + (S6 )(pJ- c2 Por lo general, los valores de los resu ltados, S,, son Jos flujos de efectivo descontados o el VPN que se obtienen de la alternativa dada y los resultados o estados de la naturaleza. El valor comercial esperado (VCE) del proyecto es el valor de la alternativa con el valor esperado más grande. Para ilustrar mejor estos conceptos, considere una compañía de ópera que intenta decidir qué ópera elegir para la presentación inaugural de la temporada. El administrador de la compañía ha estimado las demandas posibles para cada obra {alta, med ia y baja) con sus respectivos re ndimientos y probabil idades. Suponiendo que hay dos opciones (Rigoletto o Falstaff), el árbol de decisiones con el que se-encuentra la compañía se da en la figura 2.3. Si la compañía de ópera se decide por Rigoletto, los ingresos esperados serán $148 000 (0.5 x $200K + 0.3 x $ 120K + 0.2 x $60K). Si la compañía de ópera elige Falstaff, su rendimiento FIGURA 2.2 Ejemplo de árbol de decisiones
Resultado 5 1
Probabilidad = p,
Resultado 5 2
Probabilidad = P2
Resultado~
Probabilidad = P3
Resultado 5 4
Probabilidad = p4
Resultado S5
Probabilidad = Ps
Resultado 5 6
Probabilidad= p6
Alternativas Punto de decisión
Resultados
INICIO Y SELECCIÓN DE UN PROYECTO
Demanda alta: $200K {prob
Demanda baja: $60K (prob
29
=0.5)
=0.2)
Demanda alta: $220K (prob = 0.4)
Demanda baja: $25K {prob
=0.4}
esperado será $128 000 (0.4 x $200K + 0.2 x $150K + 0.4 x $225K). Suponiendo que Rigoletto cueste $75 000 (reparto, escenografía, dirección y otros), la compañía de ópera podrá lograr una ganancia bruta estimada de $148 000-$75 000 = $73 000. Si elige Falstajf (con un costo aproximado de $50 000), la ganancia bruta estimada sería $128 000- $50 000 = $78 000. Entonces, con base sólo en las ganancias esperadas, la compañía de ópera podría esperar obtener $5 000 más si elige Falstaffpara inaugurar su temporada (aunque existen buenas razones por las cuales la compañía podría decidirse por Rigoletto). Para ilustrar la medida del valor comercial esperado (VCE), considere el árbol de decisiones que se presenta en la figura 2.4 para un proyecto hipotético de desarrollo de un producto. En este caso se tienen dos puntos de decisión: l) desarrollar (o no desarrollar) el producto y 2) lanzar (o no lanzar) el producto. Si se desarrolla, puede ser un éxito técnico (con probabilidad p1) o un fracaso técnico (con probabilidad f - p1); si el producto se lanza, puede ser un éxito comercial (con probabilidad Pe) o un fracaso comercial (con probabilidad 1 -Pe). En la figura 2.4 se supone que la organización no lanzará el producto si es un fracaso técnico (de manera que los flujos de efectivo en este caso son cero). Si el producto es un éxito comercial, entonces todos los flujos de efectivo futuros se descuentan al presente; estos flujos de efectivo descontados se denotan por VPN. Suponga que el costo de desarrollo del producto (probar su factibilidad técnica) es e0 y que el costo de lanzar el producto es eL' entonces el valor esperado de lanzar el nuevo producto (suponiendo que es un éxito técnico) es Valor esperado del lanzamiento 1 éxito técnico= VPN (pe) + 0 (1 -Pe)- eL = VPN (pe)- eL Hacia atrás, el valor esperado del desarrollo del producto es entonces, VCE = p1 [VPN (pe)- eL] - e 0 Por ejemplo, suponga que se espera que el diseño de un nuevo producto tomará tres años y costará alrededor de $6M por año. Al final de los tres años la empresa sabrá si el producto fue un éxito técnico; en el momento presente su administrador estima que hay una probabilidad de 80% de que el producto sea técnicamente factible. Si e-S un éxito técnico, el producto puede lanzarse el año 4 con un costo aproximado de $5.5M. Si se lanza, será un éxito comercial con probabilidad 0.6 de obtener ingresos brutos de $ 15M por año durante cinco años, pero sólo $2M por año si es un fracaso comercial.
30
CAPÍTULO 2
INICIO. SELECCIÓN Y PLANEACIÓN DE UN PROYECTO
FIGURA 2.4 Defin ición de valo r comercial esperado (VCE)
Probabilidad =Pe Éxito comercial (con beneficio
neto= VPN}
Probabilidad= p 1 Éxito técnico
Fracaso comercial (con beneficio neto= 0) Fracaso técnico Probabilidad = 1 -Pe Probabilidad= 1- p 1
Suponiendo una tasa de descuento de 10%, los flujos de efectivo esperados en este proyecto se indican en la figura 2.5. En los primeros tres años hay un flujo de efectivo anual negativo de $6M; el año 4 se lanza el producto si es un éxi to técnico (y se incurre en un costo único eL de $5.5M). El flujo de efectivo esperado en el año 4 se obtiene con el cálcul o siguien te: Flujo de efectivo esperado en el año 4 = 0.8 [(15 x 0.6 + 2 x 0.4)- 5.5] = 3.44 E l valor presente neto (VPN) de este proyecto propuesto es la suma de los fl ujos de efectivo descontados que se presentan en la última columna de la figura 2.5 que suman $4.40M. De manera alternativa, se puede encontrar la TIR de este proyecto; es decir, la tasa de descuento que da un valor de cero del VPN. En este caso laTIR es aproximadamente igual a 17.1 %. Este ejemplo ilustra varias ventajas que ofrece la medida VCE. Primero, considera en forma explícita la posibilidad de que el proyecto se suspenda en una etapa intermedia (si el producto es un fracaso técnico). Si el producto es un éxito comercial, usa los flujos de efectivos descontados al presente, con lo que se aj usta a proyectos que tienen un lanzam iento potencial dentro de muchos años. Además, el VCE se puede mu ltiplicar por un factor subjetivo que pondera cada proyecto propuesto según su importancia estratégica relativa para la organización. El VCE puede modificarse con faci lidad. Por ejemplo, los flujos de efectivo pronosticados que se usan para calcular los flujos de efectivo descontados (VPN) se pueden ajustar por sus probabilidades respectivas para reflejar un VPN esperado. De otra manera, el árbol de decisiones de la figu ra 2.4 puede modificarse para reflejar otras alternativas o resultados (por ejemplo, podría haber más de dos resullados posibles si se lanza el producto). Cooper et al. reportaron que algunas empresas dividieron la medida VCE entre un recurso limi tado (como recursos de capital) para definir una
FIGURA 2 .5 Cálculos del VPN Año
¿Qué ocurre?
Éxito comercial
Fracaso comercial
Desarrollo técnico
2 3 4 5 6 7 8
Desa rrollo técnico Desarrollo técnico Lanzamiento del prod. Lanzamiento del prod. Lanzamiento del prod . Lanzamiento del prod. Lanzamiento del prod.
$15 $15 $15 $15 $15
$2 $2 $2 $2 $2
Flujo de Flujo de efectivo anual efectivo esperado descontado
$ $ $ $ $ $ $ $
(6.00) (6.00) (6.00) 3.44 7.84 7.84 7.84 7.84
($5.45) ($4.96) ($4.51) $2.35 $4.87 $4.43 $4.02 $3.66
INICIOY SELECCIÓN DE UN PROYECTO
31
razón que representa el retorno por unidad de recur o limitado. Esta razón se usó después para calificar varios proyectos propuestos. Para ilustrar mejor la métrica VCE considere un proyecto propuesto para el desarrollo de un nuevo producto descrilo por Hodder y Ri ggs (1985). En la primera etapa se desarrollará el producto y se explorará su factibilidad técnica; se ha estimado que esta etapa costará $18 millones por año y durará dos años. Hay una probabilidad de 60% de que la empresa pueda desarrollar con éxito el nuevo producto. Si se tiene éxito, se emprenderá la segunda etapa para explorar la factibilidad de mercado del producto, y desarrollar la mercadotecnia y los canales logísticos; es ta etapa del desarrollo del producto requerirá dos años y costará $ 1O millones por año. Se espera que la investigación de mercado realizada en esta etapa indique las ventas potenciales del nuevo producto; estas ventas potenciales pueden ser altas (con probabilidad de 30%), de nivel medio (probabilidad de 50%) o bajas (probabilidad de 20%). Si se estima que las ventas potenciales serán bajas, se abandonará el producto y no se iniciará la fabricació n y venta. Este proyecto de desarrollo de un nuevo producto se resume en la figura 2.6. Si se calcula una TIR para evaluar este proyecto (basada en el FED "estándar"), se genera la tabla que se presenta en la figura 2.7, con flujos de efectivo esperados para los 24 años de vida estimada del proyecto. La tasa de descuento que da un VPN = O es, en este caso, 10.12%; es decir, según el FED "estándar", se esperaría que este proyecto tuviera un rendimiento de l 0.12% por año. ¿Estaría usted dispuesto a emprender un proyecto tan arriesgado por un rendimiento promedio de 10.12% anual? Como ya se dijo, una crítica que se hace al FED (y a la TlR) es que usan una sola tasa de descuento para toda la vida del proyecto. Para relajar esta suposición y evitar esta crítica se describe una métrica más elaborada, el valor comercial esperado (VCE). Como se indicará, el panorama de proyecto propuesto cambia de manera drástica cuando se aplica una medida más compleja como el VCE.
Etapa 1
Investigación y desarrollo del producto
$18 milk;nes anuales de costos de investigación durante 2 años 60% de probabilidad de éxito Etapa 11
Desarrollo de mercado Se emprende sólo si el desarrollo del producto tiene éxito $10 millones anuales de gastos durante 2 años para desarrollar la mercadotecnia y los canales de distribución (neto de cualquier i ngreso obtenido en la prueba de mercadotecnia)
Etapa 111
Ventas Se realiza sólo si las etapas 1 y 11 verifican oportunidad La producción se subcontrata y todos los flujos de efectivo se dan después de impuestos y ocurren al final del año Los resultados de la etapa 11 (disponibles al final del año 4) identifican el potencia l de mercado del producto como se indica abajo:
Demanda del producto Alta Media Baja
Vida del producto
20 años 10 años Abandonar el proyecto
Ent rada de efectivo neta anual Probabilidad
$24 millones $12 millones Ninguna
0.3
0.5 0.2
29955
32
CAPiTULO 2
INICIO, SELECCIÓN Y PLANEACIÓN DE UN PROYECTO
FIGURA 2 .7 Cálculo de los FEO pa ra el ejemplo del proyecto de I&D presentado en la figu ra 2.6
Año
Flujo esperado de efectivo (en millones de dólares)
1
-18 - 18 0.6(- 10) =-6 0.6(-10) = -6 0.6(0.3 X 24 + 0.5 X 12) = 7.92 0.6(0.3 X 24) = 4.32
2 3 4 5-14 15-24
Ahora, considere la aplicación del VCE en el ejemplo de desarrollo de un nuevo producto, para el cual se calculó una TIR igual a 10.12%. El árbol de decisión se presenta en la figura 2.8. En este caso, se puede suponer que se aplican tasas de descuento diferentes en cada etapa del proyecto; es decir, la etapa de investigación y desarrollo del proyecto tiene más riesgo que la etapa del desarrollo de mercado, ya que en ésta se cuenta con más información. En particular, suponga (sigui endo a Hodder y Riggs) que se puede vender el producto a un tercero, si la investigación de mercado indica que es probable que las ventas del producto sean altas o med ias. ¿Cuán to valdría el producto en este punto? Dado que el producto ya se desarrolló y la investigación de mercado terminó (con éxito), existe mucho menos riesgo asociado con la fab ricación y venta de este producto. Si se supone que un tercero estaría dispuesto a usar una tasa de descuento de 5%, el valor esperado del producto al final del año 4 sería$ 136.06 millones ($24 millones/año durante veinte años y $12 millones/año durante diez años). El !lujo de efectivo de este producto sería entonces el que se muestra en la figura 2.9. En estas condiciones laTIR es 28.5%, un valor que es casi el triple del valor de la TlR inicial estimada. La diferencia se basa en el uso de diferentes tasas de descuento para las distintas etapas del proyecto. La medida del VCE más compleja hace que este proyecto parezca mucho más atractivo.
FIGURA 2 .8 Medida del VCE definida para el ejemplo del proyecto de desarrollo de un nuevo prod ucto
Demanda del producto, alta Probabilidad = 0.6 Éxito del desarrollo
Demanda del producto, media
Fracaso del desarrollo
Demanda del producto, baja
Se aba ndona ._,,_...,....,"""',.,.""" el proyecto Probabilidad = 0.4
FIGURA 2.9 Cálculo de la TIR modificada, en el ejemplo del proyecto de I&D
Salida
Entrada
Neto
Probabilidad
Flujo de efectivo esperado $(18.00) $(18.00)
Año 1
$18.00
$ (18.00)
Año 2
$ 18.00
$ (18.00)
1
Año 3
$10.00
$ (10.00)
Año 4
$10.00
0.6 0.6
$136.06
$126.06
$ (6.00) $75.63
INICIO Y SELECCIÓN DE UN PROYECTO
33
Enfoque de opciones reales Uno de los aspectos más importantes de la medida VCE es el concepto de que los administradores deben pensar en los proyectos propuestos desde una perspectiva de "opciones"; es decir, decidir que proceda la etapa de I&D del ejemplo anterior da a los administradores una opción (pero no un compromiso) de proceder con la etapa subsiguiente de desarrollo de mercado. Una ventaja es reconocer que no es adecuado aplicar una tasa de descuento única durante toda la vida de la mayoría de los proyectos. Algunas organizaciones han dado un paso más allá y aplican la teoría de cálcul o de precios (o tarifación) de opciones (OPT, options pricing the01y) para eval uar formalmente los proyectos propuestos; Faulkner (2000) describe su experiencia en Eastman Kodak con el uso de OPT para evaluar propuestas de I&D y los valiosos conocimientos que obtuvo. Sin embargo, Faulkner hace notar que la aplicación de OPT a propuestas de nuevos proyectos tiene algunas desventajas: la fórmula de Black-Scholes (Brealey y Myers, 1988) es complicada y difícil de entender para la mayoría de los admi nistradores y se basa en la suposición de que la incertidumbre futura puede representarse por una distribución lognormal (que puede ser una suposición inapropiada en la mayoría de los proyectos). Es de suma importancia para el administrador de proyectos tener en mente "opciones" y mantenerse tan flexible como sea posible; la teoría de opciones reales indica que una mayor incertidumbre se traduce en un mayor valor esperado del proyecto. si los administradores tienen la flexibilidad para responder a contingencias (Huchzermeier y Loch, 2001 ). Al mantener la flexibilidad para modificar un proyecto de manera dinámica, aumenta el valor esperado de un proyecto conforme aumenta la incertidumbre asociada con él. Una manera de poner en práctica tener en mente opciones (sin el uso formal de la OPT) es usar un enfoque de "filtro-etapa". Este enfoque requiere que todo proyecto pase un filtro con criterios bien definidos en cada etapa. En la figura 2.1 Ose da un ejemplo del enfoque de "filtro-etapa" aplicado a una división de una empresa de TI. De acuerdo con Cooper et al. (2000) el proceso en cada etapa opera como sigue: [En cada etapa), los vigilantes (alta administración) juzgan el proyecto contra una lista de criterios como adecuación estratégica, factibilidad técnica, atracción de mercado y superi oridad competitiva. Si la discusión centrada en cada criterio resulta en encogimientos de hombros y comentarios como "no estamos seguros", se tiene una clara señal de que la calidad de la información es sub-estándar: el proyecto se regresa a la etapa anterior en lugar de permitir que continúe. Según Cooper et al. (2000), las empresas que usan el enfoque de "filtro-etapa" tienen una tasa de éxito 37.5% mayor que las empresas que no emplean tales enfoques y una posibilidad 72% mayor de lograr los objetivos de ganancias durante la vida del producto.
Diseño
Definición
Diseño de detalle Programación y presupuesto
Definición del trabajo
Plan de contingencia
1
Cambio de admón
=GURA 2.10
.__R.,ev..,i,.,si,.,.on _e""s..d,..el..p""rod""""u""'cto y el desempeño
Mejora
Control
Plan de implantación Preparación de las instalaciones Implementación
Ejemplo del enfoque de "filtro-etapa" para proyectos de TI
Cierre de la producción Lecciones aprendidas
34
CAPITULO 2
INICIO, SELECCIÓN Y PLANEACIÓN DE UN PROYECTO
Una filosofía de opciones basada en un enfoque de "filtro-etapa" puede también ser de ayuda en la difícil decisión de suspender un proyecto. En muchas organizaciones hay un estigma unido a la cancelación de un proyecto (que puede estar relacionado con una reducción percibida (o real) en la evaluación de méritos, la paga o incluso en las plazas de trabajo disponibles). Dado este punto de vista, puede ser difícil cancelar un proyecto ya iniciado aun cuando las condiciones cambiantes del entorno o las nuevas tecnologías lo requieran. Un enfoque de "filtro-etapa" con decisiones defi nidas de "seguir o no seguir" en cada etapa, puede ser de gran ayuda al respecto. Cada vez más, los administradores exploran el uso de la teoría de tarifación de opciones (OPT) en la evaluación de los proyectos de I&D.
Métodos de calificación y clasificación Aunque pueden emplearse muchas medidas numéricas para evaluar propuestas de proyectos, la mayoría ignoran los facwres no cuantificables (así como algunos costos y beneficios secundarios) cuya medición directa puede ser difícil. Para considerar tanto los factores cuantitativos como los no cuantitativos, muchas organizaciones emplean modelos de calificación o clasificación que casi siempre consisten en una lista de atributos y sus pesos correspondientes. Los administradores y trabajadores relevantes califican cada atributo (por ejemplo, en una escala del l al lO). La elección de los atributos, sus pesos respectivos y el método para combinar estas calificaciones y pesos en un solo valor es la clave para diseñar un buen método de calificación que pueda diferenciar entre proyecws que tendrán éxito y proyectos que no lo tendrán.* La figura 2.11 presenta una lista de algunos atributos potenciales que se han usado en estos métodos. Debe observarse que muchos de estos atributos se relacionan; es decir, se esperará que la participación en el mercado (una medida de "valor") y la demanda potencial del mercado (una medida de "riesgo") tengan una correlación alta. Los atributos correlacionados tienen el efecto de aumentar implícitamente el peso del factor o factores asociados. Por ejemplo, en la lista de atributos de la figura 2.11 parece que por lo menos cuatro atributos están relacionados con la demanda del nuevo producto en el mercado. Así, la demanda en el mercado puede ser el factor determinante de la calificación total de esta propuesta. Para eliminar estos pesos implíciws puede valer la pena usar una metodología estadística como el análisis de s;omponcntes (o factores) principales, para identificar los "factores" naturales o subyacentes de los datos. Estos factores ortogonales pueden usarse después como atributos de identificación. Dada una lista de atributos (ortogonales) para cada proyecto propuesto, hay muchas maneras de calificarlos. Por ejemplo, cada atributo evaluarse de acuerdo con una escala (digamos del 1 al 7), con sí o no, o usarse para clasificar cada propuesta (esto es, para determinar una jerarquía forLOsa). La redacción de cada atributo debe cuidarse para que refleje que una calificación más alta representa un valor más alto (o viceversa, siempre y cuando haya consistencia). Por ejemplo, contestar sí a una pregunta de si el proyecto aumentará la rentabilidad es ciertamente positivo (y deberá aumentar la calificación del proyecto); contestar sí a la pregunta de si se necesitarán nuevas instalaciones puede verse como negativo (y debe llevar a una calificación más baja del proyecto). Suponer una calificación alta es más deseable, se puede emplear un esquema lineal simple para convertir todas las calificaciones de los atributos en una escala común (0, 1). En este caso, uponga que U es el límite superior de la escala y L el límite inferior. Entonces, dada una calificación x¡ asignada al i-ésimo atributo, su valor v;(X¡) se define como: V·(X · ) = 1
1
X· -L
1 -U-L --
• En algunos casos. la jerarquía forzada de los atributos puede usarse para aliviar las objeciones establecidas por algunos administradores respecto a que estos modelos no discriminan de manera adecuada los proyectos propuestos.
INICIO Y SELECCIÓN DE UN PROYECTO
--= ~os para modelos
::a.-ficación posibles
35
Nombre del proyecto - - - - - - - - - - - - - - Rentabilidad/Valor 1. ¿Aumenta la rentabilidad? 2. ¿Aumenta la participación de mercado? 3. ¿Proporcionará nuevos conocimientos a la organización que otros proyectos puedan aprovechar? 4. ¿Se estiman VAN, VCE, etcétera? Estrategia de la organización 1. ¿Es consistente con la misión de la organización? 2. ¿Tiene impacto sobre los clientes? Riesgo 1. ¿Qué probabilidad de éxito tiene la investigación? 2. ¿Qué probabilidad de éxito tiene el desarrollo? 3. ¿Qué probabilidad de éxito tiene el proceso? 4. ¿Cuál es la probabilidad de éxito comercial? 5. ¿Cuál es el riesgo global del proyecto? 6. ¿Existe una demanda de mercado adecuada? 7. ¿Qué competidores hay en el mercado? Costos para la organización 1. ¿Se necesitan nuevas instalaciones? 2. ¿Se puede emplear el personal que se tiene? 3. ¿Se necesitan consultores externos? 4. ¿Se requiere contratar más personal? Factores varios 1. ¿Cuál es el impacto sobre los estándares ambientales? 2. ¿Cuál es el impacto sobre la seguridad de la fuerza de trabajo? 3. ¿Qué impacto tiene sobre la calidad? 4. ¿Cuáles son las i mplicaciones políticas/sociales?
Por ejemplo, suponga que se está evaluando la probabilidad de que el proyecto sea un éxito técnico y que esta probabilidad se califica como baja, media y alta. Si calificamos X; como O, 1 o 2, respectivamente, el valor de v;(X¡) se "traducirá" en O, 0.5 y 1, respectivamente (ya que L = O y U= 2). Se obtendrá un resultado similar si se califica un atributo en una escala (1, 10) (en este caso, por ejemplo, un 3 como respuesta se traducirá en un valor de 0.33). Esta transformación lineal sencilla implica que el beneficio marginal de cualquier puntuación más alta es constante; es decir, la diferencia entre la calificación media y la calificación alta tiene el mismo valor que la diferencia entre la calificación baja y la calificación media. Cuando los adm inistradores no desean suponer estos beneficios marginales constantes, se puede emplear una transformación diferente. Una posibilidad es usar una escala exponencial, en la que el valor del atributo está dado por V· (X·) 1 1
1- exp(L - X¡) 1-exp(L-U)
= --"-----'-
Por ejemplo, suponga que las respuestas a cierto atributo se dan en una escala de 7 puntos (por ejemplo, se evalúa la probabilidad de que este proyecto sea un éxito técnico en una escala de 1 a 7). Los valores de este atributo, usando una escala lineal y una escala exponencial se presentan en la fig ura 2. 12. Observe que una respuesta de 1 corresponde a cero tanto en la escala lineal como en la escala exponencial, mientras que un 2 en la escala lineal corresponde a O. 17, y en la escala exponencial corresponde a 0.63, que es mucho más alto. Se pueden definir y usar muchas otras funciones. Como se pueden usar varios de estos esquemas en un solo cuestionario, debe haber un método consistente para convertir estas respuestas en una escala común, si se quiere agregar las respuestas
36
CAPiTULO 2
INICIO. SELECCIÓN Y PLANEACIÓN DE UN PROYECTO
FIGURA 2.12 Valores de los atributos en una escala lineal y una escala exponencial
1.20 1.00
...o ·e: ...
,
0.80
~
.J:l 1:1
0.60
Gi
"C
...
o
0.40
''
.- -. --· -
-
--
,'
•
1 1
-+- Escala lineal - •- Escala exponencial
1 1 1
~ 0.20 0.00 2
4
3
5
6
7
Respuesta
'J·
para obtener una calificación global para el j-ésimo proyecto propuesto. Para calcular la calificación global de cada proyecto considerado, se puede asignar a cada atributo i un peso IV;, donde
oS IV¡ S 1 y
L
IV¡
= 1
Estos pesos reflejan los trueques relativos entre los diferentes atributos. Dados los valores y pesos de los atributos se puede calcular una calificación global para cada proyecto propuesto; usando el modelo aditivo, el valor global Vj de un proyecto se define como
VJ. = L ~. .W·V· , ¡ r(X· rr ) Para ilustrar cómo usar este método para obtener una calificación para cada proyecto propuesto, considere el ejemplo de la figura 2. 13 que presenta cinco atributos con sus pesos correspondientes (w¡); estos atributos comprenden la evaluación de la posibilidad de que el proyecto incremente la participación en el mercado, si son o no necesarias nuevas instalaciones, entre otros. Los atributos primero, cuarto y quinto se calificaron en una escala de S puntos. En el caso del segundo atributo ("¿se necesita la nueva instalación?"), una repuesta de sí se calificó como 2 en la escala de S puntos, mientras que un no se calificó con 4 (observe que esto es arbitrario; se podría haber calificado sí con 1 y no con S). De esta manera, un sí contribuye a bajar la pun tuación del proyecto ya que un a nueva instalación se ve como un atributo negaúvo, mientras que una respuesta de no recibe un valor más alto y más positivo. De manera similar, en el tercer atributo ("¿hay preocupación por la seguridad?"), la repuesta "es probable" se califica con 1, evaluar que "no es seguro" recibe un valor de 3 y la repuesta de que la seguridad no es problema obtiene S. De esta manera, los valores más altos de los cinco atributos contribuyen a una evaluación más favorable de los proyectos correspondientes. Suponga que se están considerando dos proyectos, A y B, y que se calificaron los cinco atributos dados en la figura 2.13. Las calificaciones hipotéticas correspondientes a cada uno así como sus valores convertidos usando una escala lineal y una escala exponencial, se presentan en la figura 2.14. Por úlúmo, dados los peso (IV) de los atributos en la figura 2.13, se calcularon las calificaciones globales (V.) de cada proyecto propuesto, donde (usando la escala lineal) la puntuación del J . proyecto A se calcula como s1gue:
EVALUACIÓN DEL PORTAFOLIO DE PROYECTOS
2
_Incrementa el proyecto la participación de mercado? Improbable
3
4
Si
:.. ._Se necesita una nueva instalación?
5
Probable
5 5
Probable
No
Probable No seguro No
:. ,Hay preocupación por la seguridad? - :>osibilidad de éxito del desarrollo técnico
Improbable
::.. :>osibilidad de éxito del desarrollo comercial
Improbable
;:¡GURA 2 . 13
Peso d el at ributo
Escala de medición
.uributo
2 2
3 3
4 4
37
Probable
30% 15% 10% 20% 25%
Ejemplo de atributos y escalas de medición para un proyecto
Vj =WIVI(xi)+ ... +IVsVs(Xs)
= 0.3(0.75) +
0.15(0.25) + 0.10(0) + 0.2(0.75) + 0.25(0)
= 0.413
Como se indica en la figura 2.14, el proyecto B tiene la cal ificación global más alta con cualq uiera de las dos escalas, lo que indica que al usar este enfoque, el proyecto B será mejor que el proyecto A. Es importante observar que la diferencia entre las calificaciones de los dos proyectos es mayor si se usa la escala exponencial; es decir, la escala exponencial hace que el proyecto B parezca relativamente más atractivo que con la escala lineal. Para obtener más información acerca de las diferentes funciones de calificación de atributos, o acerca de cómo combinar estas calificaciones en una medida global, vea Keeney y Raiffa ( 1976). Una buena descripción de cómo se usaron estas (y otras) funciones para eval uar proyectos propuestos en el acuario no lucrativo de Monterey Bay se encuentra en Felli et al. (2000).
EVALUACIÓN DEL PORTAFOLIO DE PROYECTOS Los administradores siempre deben evaluar los nuevos proyectos propuestos teniendo en cuenta el portafolio de proyectos de la organización. A este respecto surgen varias interrogantes que deberán considerarse como parte de todo proceso para la aceptación de proyectos potenciales: •
¿El proyecto propuesto es consistente con la misión y objetivos de la organización?
•
¿Contribuye el portafolio de proyectos a los objetivos estratégicos de la organización?
•
¿Representan los proyectos una mezcla de proyectos a largo y a corto plazo?
•
¿Cuál es el impacto sobre los fl ujos de efectivo de la organización a través del tiempo?
•
¿Cómo afecta el proyecto propuesto a las restricciones de recursos de la organización?
•
¿Cuál es el impacto del proyecto propuesto sobre sus flujos de efectivo?
=fGURA 2 . 14 := emplo de evaluaciones ;:.= proyectos
Calificación del proyecto (V¡l
Atributo
#1
Proyecto A
4
Si
Probable
4
1
Proyecto B
2
No
No seguro
3
4
0.75 0.25
0.25 0.75
0.00 0.50
0.75 0.50
0.00 0.75
0.413 0.525
0.97 0.64
0.64 0.97
0.00 0.88
0.97 0.88
0.00 0.97
0.581 0.845
#2
#3
#4
#5
Escala lineal Proyecto A Proyecto B Escala exponencial Proyecto A Proyecto B
38
CAPiTULO 2
INICIO, SELECCIÓN Y PLANEACIÓN DE UN PROYECTO
Desde la perspectiva de un portafolio de proyectos, la diversificación de los proyectos se convierte en una consideración primaria; un portafolio de proyectos di versificado minimiza los riesgos de una organización, de la misma manera que un portafolio financiero diversificado minimiza el riesgo de mercado. Por ejemplo, si una organización está considerando varias propuestas de proyectos, los administradores deberán elegir proyectos que representen una mezcla de desarrollo de nuevos productos y procesos, diversificación de mercado y un balance de tecnologías. ¿Qué pasa cuando los administradores no usan la "perspectiva de portafiolio"? Wheelwright y Clark ( 1992) describieron un escenario Lípico en una empresa grande de instrumentos científicos. Motivados por enom1es presupuestos y una disminución en el número de proyectos exitosos, la empresa investigó y descubrió que había treinta proyectos de desarrollo en marcha, mucho más de lo que la empresa podía financiar. Dado que la mayoría de los proyectos estaban retrasados y excedían el presupuesto, los ingenieros y empleados cambiaban de un proyecto a otro con rapidez produciendo una atmósfera de crisis que retrasaba aún más los proyectos y ponía en peligro la calidad. Según Wheelwrigh y Clark, la mayor parte de los proyectos se habían elegido con propósitos específicos, ya fuera por los ingenieros que encontraron retos en los proyectos o por el departamento de mercadotecnia como reacción a las demandas de los clientes. Pocos proyectos contribuían a los objetivos estratégicos de la empresa. Después de un cuidadoso análisis la empresa redujo su portafolio a ocho proyectos de desarrollo comercial. Suponga que se asigna a cada proyecto propuesto una puntuación que representa su valor potencial (por ejemplo, VPN, VPN esperado, una medida Vj de un modelo de calificación o jerarquía, o alguna medida basada en el modelado del comportamiento de acciones como el modelo Black-Sholes). Usando esta medida global (que se supone es una representación no sesgada y razonablemente exacta del valor del proyecto), muchas organizaciones clasifican las propuestas que están considerando• y seleccionan proyectos hasta que las restricciones de recursos ya no se satisfacen. Sin embargo, este método no considera posibles interrelaciones entre los proyectos e ignora el riesgo del portafolio. Un enfoque mejor reconoce que los proyectos deben estudiarse en un espacio multidimensional. Por ejemplo, se puede asociar una medida de riesgo con cada propuesta además de su beneficio estimado; esta medida podría ser la probabilidad de éxito técnico (pr)• de éxito comercial (pe), o alguna combinación de las dos. Dadas estas medidas de riesgo y beneficio (valor), cada proyecto propuesto se puede graficar en estos ejes riesgo-beneficio. Una versión de esta gráfica es un diagrama de burbujas bidimensional que se ilustra en la figura 2.15. Existen muchas variaciones de diagramas de burbujas; algunas emplean tres dimen siones (como VPN, riesgo y duración esperada) o diferentes formas o tipos de sombreado y colorido para representar los diversos tipos de proyectos. Por ejemplo, en la figura 2. 15 los tipos de sombreados repre sentan líneas de productos, mientras que el tamaño de los óvalos representa requerimi entos de recursos (gastos en l&D). Aunque los diagramas de burbujas son útiles para representar un conjunto de proyectos y visualizar un portafolio de proyectos, son poco útiles para seleccionar proyectos propuestos. En ciertas condiciones, el pro blema de elección de proyectos se puede ver como un modelo de programación matemática. Este tipo de formulación supone que los valores de los proyectos inruviduales son independientes y que el valor del portafolio es aditivo (es decir, el valor total del portafolio es la suma de los valores de los proyectos). En algunos casos los proyectos deben seleccionarse o rechazarse (opció n binaria); en OIJ'(h casos se pueden financiar a diferentes niveles. En el primer caso, el problema de selección de portafolio se puede modelar usando variables de deci sión binaria (0, 1). En el último caso e l modelo d.: programación matemática e mplearía variables continuas de decisión entre O y 1 para indicar la proporción de fondos asignada a cada proyecto durante algún horizonte de tiempo. Si e l problema de selección de portafolio se modela usando variables binarias (0, 1). es equr valente al problema multidimensional de la mochila. En este problema de una dimensión , se tiea.. • Algunas organizaciones usan una razón. calc.ulada dividiendo el valor pronosticado del proyecto e nLre algún recurso limitado, para clasificar las propuestaS.
EVALUACIÓN DEL PORTAFOLIO DE PROYECTOS
~ U RA
2.15 de un • ~gra m a de bu rbujas
39
Probabilidad de éxit o comercial
= ~plo
Alto
~o- b e nef i ci o
e o •
o
Alto VPN esperado
o Baj o
una mochila de cien o tamaño o vol umen. Un viajero quiere empacar en la mochila objetos de valor y tamaño conocidos maximizando el valor de los objetos elegidos, pero sin exceder las restricciones de tamaño o vol umen de la mochila. En la versión multidimensional de este problema, se supone que los objetos están determinados por múltiples características; por ejemplo, tamaño, categoría, color, etcétera. En este caso el viajero quiere seleccionar el conjunto de objetos que maximiza el valor de la moch ila satisfaciendo simultáneamente las restricciones en todas las dimensiones (el tamaño total, cantidad de obj etos rojos, etcétera). Se han publicado numerosos casos q ue usan la fomlUlación de la mochila para modelar el problema de selección de proyectos (vea Fox el al., 1984; Martino, 1995; Loch et al., 2001 ) . Beaujon eral. (200 1) describen una aplicación reciente implantada por el centro de l&D de General Motors para evaluar entre doscientos y cuatrocientos proyectos para un horizonte de un año. El modelo de GM usó variables de decisión tanto binarias como continuas; el último modelo se resolvió e implementó como un modelo de hoja de cálculo. Otros modelos comprenden la metodología empleada con éxito por el Gas Research lnstitute durante catorce años (Bumett el al., 1993) y un modelo de programación entera no lineal usado por Bellcore para seleccionar proyectos de I&D (Hoadley et al., 1993). Para ilustrar estos enfoques se considerará un modelo de selección de proyectos simplificado. En este caso, se supone que los proyectos se eligen o se rechazan, aunque el modelo se puede simplificar permitiendo que los proyectos sean fina nciados a diferentes niveles (lo que implica el uso de variables continuas). Las variables de decisión binarias en este modelo son )j donde y . = {1 si se elige el proyecto j 1 Ode otra manera
Suponiendo que la calificación de cada proyecto está dada por ~ · se desea encontrar el portafolio de proyectos que maximice el valor total de los proyectos elegidos. Suponiendo que el valor del portafolio es la suma de los valores de los proyectos elegidos de un con junto P de proyectos posibles, la función objetivo es Maxi mizar
L Vj Y j j EP
Es posible agregar cualquier número y tipo de restricciones. Si la organización está preocupada por los fl ujos de efectivo en los siguientes T años, se pueden incluir las siguientes restricciones de presupuesto:
40
CAPÍTULO 2
INICIO. SELECCIÓN Y PLANEACIÓN DE U N PROYECTO
L Fj,Yj..::; B1 para toda t = 0,1, ... , T jEP
donde Fj, denota el flujo de efectivo pronosticado para el proyecto j en el año t y B, denota la restricción de presupuesto en el año t. De manera similar, si los proyectos se clasifican en varias categorías (por ejemplo, relacionadas con varias estrategias organizacionales), entonces se pueden agregar restricciones adicionales relacionadas con estas categorías. Por ejemplo, suponga que PTI representa el conjunto de proyectos relacionados con TI y que la administración ha especificado que no más de 30% de los proyectos financiados puede relacionarse con TI. Esta restricción se expresa algebraicamente como sigue:
L Yj - 0.3 L Yj
:::;o
jEP
jEP¡
En forma análoga, se pueden agregar restricciones para limitar la cantidad de trabajadores necesarios de varias categorías (ingenieros, contadores, carpinteros), el número de nuevas contrataciones requeridas, Jos gastos en I&D y el equilibrio del portafolio. En el modelo usado por el Centro de l&D de GM se usaron restricciones de precedencia (como el proyecto B no se puede elegir a menos que se elija también el proyecto A), de selección forzosa (cuando compromisos externos dictan que se debe elegir un proyecto) y un tope sobre gastos adicionales. Considere, por ejemplo, el problema sencillo de selección entre dos proyectos presentado en la sección anterior. Suponga que se espera que los dos proyectos generen nujos de efectivo (tanto positivos como negativos) durante cuatro años; es decir, T = 4. En la figura 2. 16 se presentan los flujos de efectivo pronosticados para los siguientes cuatro años, así como las limitaciones de presupuesto en las salidas de efectivo durante el horizonte de tiempo de Jos proyectos. Dadas dos variables binarias de decisión, y A y y8 , se puede formular el modelo de programación lineal para el problema de selección entre dos proyectos. En este caso se evalúa cada proyecto de acuerdo con las calificaciones totales calcul adas con la escala exponencial, dadas en la figura 2. 14; es decir, VA= 0.58 1 y V8 = 0.845. Considerando sólo las restricciones de flujo de efectivo (es decir, las salidas netas de efectivo no pueden exceder el límite de presupuesto en ningún año. donde Jos valores positivos ineiican salidas de efectivo y Jos valores negativos, entradas), el modelo de programación lineal es: Maximizar .581 yA+ .845 y 8 Sujeta a $40 yA + $65 y8 ..::; $ 120 (restricción en el año 1) - S 1O yA + $25 y 8 ..::; $20 (restricción en el año 2) - $20 yA - $50 y 8 ..::; $40 (restricción en el año 3) -$20 yA- $50 y 8 ..::; $55 (restricción en el año 4) y A' y 8 = (0, 1)
FIGURA 2 . 16 Flujo de efectivo para el problema de selección entre dos proyectos
A ño (t)
Proyecto A Proyecto B Lím ite de presupuesto (81)
($40) ($65) $120
2
3
4
$10 ($25) $20
$20 $50 $40
520 $50 $55
PLANEACIÓN DEL PROYECTOS
41
Durante la serie de reuniones para visualizar nuestra oficina. hemos visto cómo los proyectos de diferentes tamaños pueden afectar la entrega, la rentabilidad y otras medidas del éxito de nuestro grupo. Hablamos de los proyectos grandes que usan más recursos de los que tenemos durante algún tiempo, pero que dejan un hueco al principio del proyecto cuando contratamos al personal necesario para una gran carga de trabajo, pero todavfa no tienen tareas asignadas, y al final del proyecto cuando ya no tenemos el trabajo. y debemos comercializar para encontrar más. En el otro extremo del espectro están múltiples proyectos pequeños que requieren una administración agresiva para mantener a todos los miembros del equipo en su tarea y vigilar los presupuestos y la programación, pero que tienden a homogeneizar la utilización global porque existe mayor flexibilidad para la programación. En medio están los proyectos de tamaño mediano, en los que se emplea una buena parte. pero no todo nuestro personal, y que pueden controlarse con una administración adecuada. Me parece que debe haber un tamaño óptimo de proyecto para nuestra oficina y un programa de PL [programación lineal] esperando que se desarrolle el modelo. ¿Alguna sugerencia? Michael R. Shoberg, P.E. Vicepresidente Barr Engineering Company
En este ejemplo se eligen los dos proyectos; aunque se prefiere el proyecto B, la restricción de presupuesto del segundo año requiere que se elijan ambos proyectos ya que la entrada positiva de efectivo del proyecto A compensa la salida relativamente grande de efectivo del proyecto B en ese año. Este tipo de modelo de elección de portafolio puede formularse como un modelo de hoja de cálculo (lo que se hizo para el Centro de I&D de GM) y resolverse mediante un algoritmo de optimización integrado (Solver de Microsoft Excel). Si una empresa sabe c uál es la probabilidad de éxito de cada proyecto, puede emplear los ingresos esperados en lugar de las calificaciones de los proyectos en la función o bjetivo. Una vez identificado un portafolio de proyectos, se puede usar un prog rama de si mulación para identificar una distribución de resultados posibles.
PLANEACIÓN DE PROYECTOS Una vez que una organización decide seguir adelante con una propuesta de proyecto, los administradores deben terminar el plan del proyecto; las partes de la mayoría de los planes de proyecto se dan en el "esquema del plan del proyecto". Como se indicó en el esquema, una organización elabora primero un resumen ejecutivo/definición de trabajo que comprende el establecimiento de los objetivos y restricciones del proyecto, en caso de que esto no se haya hecho como parte del proceso de selección. Todas las especi ficacioncs técnicas del producto final (o producto terminado), incluyendo los requerimientos de desempeño detallados deben describirse con cuidado. También se especifica el papel del equipo del proyecto así como el de los contratistas y subcontratistas. En general, la definición del trabajo estipula cómo se van a cumplir Jos objetivos del proyecto y a satisfacer las restricciones. Debe prepararse una guía de procedimientos que indique todas las reglas y procedimientos del proyecto, como parte de la etapa de planeació n. Esta guía debe contener información acerca de quién es responsable de cada subsistema, así como información detallada de quién debe aprobar cada tarea. Las relaciones entre el proyecto y otras partes de la organización suelen especificarse mediante un diagrama organizacional que indica quién tiene la máxima autoridad en el proyecto. La guía de procedimientos puede especificar también el procedimiento contable que se empleará, los asuntos de personal como contrataciones y las prácticas de trabajo, etcétera.
42
CAPÍTULO 2
INICIO, SELECCIÓN Y PLANEACIÓN DE UN PROYECTO
l. Visión general y organización del proyecto 1.1 Resumen/diagrama del proyecto 1.1.1 Especificar la misión. 1.1.2 Definir objetivos y restricciones. 1.1.3 Definir claramente las especificaciones del producto/servicio final. 1.1 .4 Definir la composición del equipo del proyecto. 1.2 Estructura desglosada del trabajo (EDT) 1.2. 1 Definir tareas o paquetes de trabajo específicos. 1.2.2 Identificar a las personas responsables de cada tarea. 1.2.3 Especificar duración y fecha de terminación de las tareas. 1.2.4 Asignar estimaciones de costo iniciales a las tareas. 1.3 Plan de organización 1.3.1 Especificar cómo se ajusta el proyecto a la misión organ.izacional. 1.3.2 Contemplar imprevistos del proyecto/periodos de informes. 1.3.3 Identificar los informes de eventos importantes. 1.4. Subcontratación 1.4.1 Especificar tipos de contratos y procesos de licitación. 1.4.2 Identificar subcontratistas si es posible.
2. Programación del proyecto 2.1 Tiempos y programación 2.1. 1 Definir relaciones de precedencia de las tareas. 2.1.2 Determinar la ruta crítica e in icio y terminación de la tarea. 2.1.3 Identificar tiempos de holgura. 2.1.4 Especificar un diagrama de Gantt. 2.2 Presupuesto del proyecto 2.2.1 Identifi car los flujos de efectivo. 2.2.2 Determinar un método para el seguimiento y control de gastos. 2.3 Asignación de-recursos 2.3.1 Establecer el equipo definitivo del proyecto. 2.3.2 Determinar cómo asignar empleados y administradores a las tareas. 2.3.3 Especificar las personas responsables de aprobaciones. 2.4 Adquisición de equipo y materiales 2.4. 1 Especificar compras de materiales (tiempo y cantidad). 2.4.2 Determinar compra y renta apropiadas de equipo.
3. Supervisión y control del proyecto 3.1 Métricas de control para costos 3. l. 1. Especificar los tiempos para informes periódicos. 3. 1.2. Indicar documentos de comunicación. 3.2 Órdenes de cambio 3.2.1 Especificar cómo se manejarán instrucciones de cambios. 3.2.2 Procedimientos de actualización de presupuesto y programación. 3.3 lnformes de eventos importantes 3.3. 1 Especificar las revisiones principales y las personas responsables.
4. lerminación del proyecto 4.1 Evaluación posterior al proyecto 4.1.1 Especificar quién realizará las auditorías posteriores. 4.1.2 Especificar méhicas para evaluar el éxito/fracaso del proyecw.
PLANEACIÓN DEL PROYECTOS
43
Estructura desglosada del trabajo (EDT) La parte más importante de la etapa de planeación es el desarrollo de una estructura desglosada del trabajo (EDT). La EDT define un conjunto de tareas independientes (también llamadas actividades o paquetes de trabajo) que constituyen el proyecto, a fin de facilitar las estimaciones de tiempo y costo, la asignación de recursos y los sistemas de monitoreo y control. Una EDT es una j erarquía que empieza con el o los productos finales o terminados y muestra cómo estos productos fi nales se pueden subdividir en tareas o paquetes de trabajo elementales. El o los productos finales (que representan la meta del proyecto, como informes, productos, edificios, software, etcétera) se indican en el primer nivel o nivel más alto de la EDT. Los ni veles ucesivos proporcionan una identificación cada vez más detallada de las tareas individuales que constituyen la producción del o los productos finales. En el proceso para la definición de una EDT se divide un proyecto en subproyectos más pequeños, de manera que la suma de todos estos subproyectos defina el proyecto más grande. Un administrador subdivide los proyectos hasta que siente que comprende por completo la naturaleza de los subproyectos y que los ha definido de manera que los puede controlar y medir. En general, un administrador no subdivide los proyectos en tareas elementales; por ejemplo, un proyecto para escribir la documentación de un nuevo producto de software podría di vidirse en capítulos, pero quizá no deba dividirse en páginas o temas. Una EDT no es una lista de verificación para que un administrador rnicroadministre un paquete de trabajo; es una herramienta importante para definir, supervisar y comprender la naturaleza y avance de un proyecto. Youker (1989) indica que, en la práctica, el proceso de construir una EDT suele ser difícil porque los administradores deben considerar tanto la estructura del producto como la estructura del proceso (las etapas del ciclo de vida).' Además, la definición de los paquetes de trabajo tiene implicaciones significativas en la programación de trabajadores y en la asignación de recursos, así como en el control de costos y presupuesto. Definir mallas tareas puede ocasionar serios problemas una vez que el proyecto está en marcha. Una EDT es semejante a la lista de materiales que se usa en los procesos de fabricación para identificar ensambles, subensambles, componentes, etcétera, que conforman un producto terminado (o a una receta.,gue define los ingredientes para un platillo). Por esto, una EDT también se conoce como árbol genealógico o "diagrama de componentes". Dada esta estructura, es lógico que la mayoría de las EDT se construyan en forma descript iva, donde las tareas y las subtareas forman secciones y subsecciones que indican las partes del producto completo. Siguiendo un formato de lista típico, las secciones que indican tareas y subtareas se colocan con sangría y se numeran en forma secuencial. Estos números suelen asignarse de manera que cada número entero representa cada producto final. Las tareas en la lista de este producto final tienen un número que consta de este número entero, un punto decimal y otro número. Cada subtarea listada bajo una tarea tiene el número de la tarea más un punto decimal y un número. Por ejemplo, las tareas específicas del tercer producto fina l se numeran 3. 1, 3.2, ... , las subtareas de la tarea 3.1 se numeran 3. 1. 1, 3.1.2, ... De es ta manera, cualquier tarea o subtarea se puede rastrear hasta su producto final y relacionarse con otras tareas o subtareas. Ob érvese que la "descripción del plan de proyecto" dada en esta sección constituye una EDT. Un administrador debe empezar el proceso de definición de una EDT identificando primero el o los productos finales que constituyen los encabezados principales. En casi todos los casos, estos productos finales tomarán la forma de un producto completo como un reporte, un programa de computadora, un barco o un edificio. Aunque en general los productos finales se definen en el resumen inicial del proyecto y en la definición del trabajo (o en un contrato), los administradores deben tener cuidado de que todos los productos finales se definan con claridad en términos comprensibles. Observe que la administración (adecuada) del proyecto con frecuencia se considera un pro• Youker opina que el término estruaura desglosada del proyecto (EDP) es más adecuado que elténnino estructura desglosada del trabajo (EDn.
44
CAPÍTULO 2
INICIO, SELECCIÓN Y PLANEACIÓN DE UN PROYECTO
dueto final separado; así, la administración del proyecto, con frecuencia se enumera bajo su propio encabezado. El segundo nivel de detalle en una EDT debe ind icar los subsistemas principales que definen cada producto final. Por ejemplo, si el producto final es la creación de un nuevo programa de computadora, las tareas principales podrían incluir prueba y depuración, documenLación, etcétera. Los niveles subsiguientes (es decir, tercero, cuano, quinto, etcétera) en una EDT reflejan una mayor su bdivisión de los subsistemas indicados en el segundo nivel. En general, la cantidad de niveles en una EDT depende de la complejidad del producto final. Tres niveles pueden definir casi todos los proyectos, au nque los proyectos con productos finales muy complejos pueden necesitar cuatro o aun cinco niveles. Más aún, la cantidad de niveles puede variar entre los d iferentes productos fi nales dentro de un mismo proyecto (es decir, un producto final puede requerir cuatro niveles, rrUentras que otro puede requerir sólo dos). Las subtareas indicadas en el nivel más bajo de una EDT representan los esfuerzos de trabajo más pequeños definidos en un proyecto; estas tareas también se conocen como actividades opaquetes de trabajo. Estos paquetes de trabajo corresponden a las actividades o tareas que se usan en la mayor pane de los paquetes de software para administración de proyectos y constituyen el conjunt
Grupos de empleados y especialistas involucrados
•
Responsabilidad de la administración
•
Facilidad para estimar tiempos y costos
•
Duración
PLANEACIÓN DEL PROYECTOS
•
Valor monetario de la tarea
•
Relación de la tarea con el ciclo de vida del proyecto
45
Al definir las tareas, es importante recordar que los paquetes de trabajo siempre pueden agregarse (por ejemplo, al preparar un informe), pero no desagregarse. También recuerde que se requieren diferentes niveles de agregación para diferentes propósitos; la alta administración se intere a sólo en los eventos importantes y en medidas muy agregadas, mientras que los trabajadores se preocupan por las tareas específicas. Una vez terminada la EDT, el administrador estima la duración de cada tarea definida en la EDT. También los costos directos se estiman algunas veces con los paquetes de trabajo; la estructura desglosada de trabajo que se obtiene se conoce como EDT con costos. En este caso, el administrador supone que la suma de los costos estimados de las tareas representa el costo directo total del proyecto. Para ilustrar una EDT, considere la planeación y ejecución de una subasta para recaudar fondos para un organización caritativa. En estas subastas, individuos y empresas suelen donar artículos y servicios que se subastan al mejor postor la noche del evento. Para planear este tipo de eventos, el administrador puede elaborar una EDT de dos niveles con la descripción de cuatro funciones básicas que definen el evento: •
El evento mismo (lugar, espectáculo, decoración, etcétera)
•
Obtención de los artículos para subastar en el evento
•
Mercadotecnia del evento (venta de entradas, etcétera)
•
Patrocinios de empresas
Esta EDT se representa en la figura 2.17 (observe la definición de los niveles 1 y 2). En la figura 2. 18 se amplía el desarrollo de nuestro evento de caridad hipotético a una EDT de tres niveles. Observe que se pudo ampliar con facilidad a una EDT de cuatro o cinco niveles subdividiendo, por ejemplo, la función de publicidad (1.3.2) en tareas más específicas. De hecho, el proceso de definir este evento se pudo haber continuado hasta cualquier nivel de detalle, pero en algún punto el costo marginal de niveles y detalles adicionales es mayor que los beneficios. Debe observarse también que la EDT presentada en la figura 2.18 está lejos de estar terminada. Primero, los paquetes de trabajo o tareas especificadas en los niveles bajos de la EDT no están bien definidos. Por ejemplo, ¿qué significa en realidad la tarea ( 1.3.2: publicidad)? ¿Qué tipo de publicidad se planea? ¿Será subcontratada? Asimismo, ¿qué significa "patrocinio de empresas" en la tarea 1.4? También es importante observar que muchas EDT no indican relaciones de precedencia. Por ejemplo, en la figura 2.18, los catálogos de la subasta no se pueden imprimir hasta obtener la mayor parte de (o todos) los artículos. Sin embargo, esta relación de precedencia no se indica en la EDT (pero se indicará en la red de precedencias que se estudia en el capítulo 4). En general, un administrador desea definir las tareas de manera que un solo recurso sea responsable de administrar y terminar la tarea. ¿Es una persona (o un grupo) responsable de reunir todos los artículos inertes para la subasta? Si no es así, la tarea debe subdi vidirse. En general, cada R GURA 2 . 17 =:L>T de dos niveles
Nivel 1 de la EDT
1
1. Subasta de caridad
1
1
1
1
1.1 Planeación del evento
1.2 Obtención de artículos
1
1
1.3
1.4 Patrocinio de empresas
Mercadotecnia
Nivel 2 de la EDT
46
CAPÍTULO 2
INICIO, SELECCIÓN Y PLANEACIÓN DE UN PROYECTO
FIGURA 2 . 18 EDT de tres niveles
11. Subasta de caridad 1 1
1
1
1
1.1 Planeación del evento
1.2 Obtención de los artículos
1.3 Mercadotecnia
1.4 Patrocinio de empresas
f-
1.1.1 Contratar al subastador
-
1.2.1 Artículos inertes para subastar
-
1.3.1 Venta de entradas individuales
1-
1.1.2 Rentar el lugar
-
1.2.2 Artículos vivos para subastar
-
1.3.2 Publicidad
-
1.2.3 Artículos para rifa
' 1-
1.1.3 Ordenarla decoración
'--
1.1.4 Imprimir el catálogo
paquete de trabajo/tareas definido en la EDT deberá basarse en la estructura del producto, la estructura de la organización y el ciclo de vida del producto; cada paquete de trabajo o tarea debe incluir lo siguiente: •
Una definición precisa de la tarea a realizar (esta defi nición deberá usar tanto verbos como sustantivos)
•
Una esti mación del tiempo necesario para completar la tarea
•
La o las personas responsables de terminar la tarea
•
La o las personas con autoridad para supervisar la tarea
•
Una estimación del costo de la tarea
•
Protocolos de control para el personal del proyecto
Estimación de costo y duración de las tareas Como parte del proceso de definir las tareas, es necesario estimar el costo y la duración de las tareas identificadas en el nivel más bajo de la EDT. Hay varios métodos útiles para predecir la duración y el costo de una tarea identificada. Al hacer estas estimaciones, muchas personas suelen basar su juicio en su experiencia con tareas similares. Estas estimaciones se pueden hacer mediante un proceso formal de punto de comparación (benchmarking) o se pueden basar informalmente en la experiencia de proyectos anteriores. Para estimar tareas en las que se tiene poca o ningu na experi encia, un administrador con frecuencia se apoya en un enfoque modular (divide la tarea en unidades elementales más pequeñas para simplificar el problema de estimación) o en un enfoque paramétrico (considera los factores que innuirán en el costo y duración de la tarea). Por ejemplo, considere un proyecto que requiere la excavación profu nda de un túnel como parte de un sistema de rieles ligeros propuesto. Dada la información de las condiciones del suelo,
PLANEACIÓN DEL PROYECTOS
47
los requerimientos del túnel, etcétera, un administrador o un ingeniero puede estimar el costo y la duración de una sección del túnel basándose en su experiencia. De manera alternativa, puede subdividir la consLrucción del túnel en "partes" o "elementos" más pequeños si sabe por ejemplo la cantidad promedio de pies que se pueden perforar en ocho horas. Extrapolando esta información puede estimar el costo y la duración de la sección del túnel. Cuando se usa el enfoque modular, se supone que los elementos más pequeños son homogéneos respecto a las condiciones externas y los requerimientos internos. Considere de nuevo como ejemplo la excavación del túnel : el ingeniero puede subdividir la tarea de excavar el túnel en partes elementales donde las condiciones del suelo y las rocas sean iguales y en las que se use equipo de excavación similar. De manera alternativa, el admi nistrador puede usar un enfoque paramétrico. Dado un número suficiente de observaciones de tiempos de excavación y distancias en diferentes tipos de suelo, profu ndidad y otros, puede estimar una ecuación usando análisis de regresión que determine la distancia excavada en funció n de estas variables ambientales (tipo de suelo, etcétera). Una vez que conoce Jos valores de las variables independientes, puede estimar la duració n de la tarea. En ocasiones, un administrador debe considerar el hecho de que haya múltiples tareas similares en un proyecto; estas tareas usan los mismos trabajadores que son cada vez más capaces conforme repiten las tareas. En este caso, la duración (y los costos) de estas tareas debe reducirse cuando ocurre el aprendizaje y los trabajadores son más capaces. Para ilustrar los efectos del aprendizaje, suponga que un administrador quiere estimar la duración de varias tareas similares que requieren a Jos mismos trabajadores. En este caso, el administrador puede denotar por t(11) la duración de la n-ésima repetición de la tarea; es decir, t( 1) es el tiempo para realizar la tarea la primera vez, t(2 ) el tiempo para realizarla la segunda vez, etcétera. La tasa de aprendizaje se indica con el parámetro {3 donde O S {3 S 1; es decir, {3 indica la rapidez con que un empleado puede reducir la duración de la tarea conforme la repite. Dado un valor de {3, un modelo de aprendizaje sencillo establece que el tiempo necesario en la 11-ésima repetición está dado por t(n)
=t( 1) 11-P
Un ejemplo para t( l) = 18 horas, {3 =0.50 y 0.20 se ilustra en la figura 2. 19. Como se indica, la duración de las tareas se reduce significativamente más rápido con val ores grandes de {3 que señalan una mayor velocidad de aprendizaje.
~U RA 2 . 19 :...:ración de una ta rea ..::'"' d if erentes tasas .: aprendi zaje
20 18 Cl
...f
16
Cl
..!
1
14
1
'
~
~
Cl
'1
12
"C
1
•
Cl
E 10 Cll 8 el r::: -o .ü 6
...
l
\
' ''
..
Q
\
4
'
2
o
.. ...
'{J=0.20
f!
:S
o
2
4
.......... _ 6
8
10
12
Número de repeticiones
14
16
18
20
48
CAPÍTULO 2
INICIO, SELECCIÓN Y PLANEACIÓN DE UN PROYECTO
¿Cómo se estima el valor de {3? Si se conoce la duración de la tarea en la primera y segunda repeticiones -esto es, t( 1) y t(2}- el valor de {3 se puede calcular sustituyendo estos va lores en la ecuación anterior; es decir, t(2)
= t{l) 2-13
Por ejemplo, suponga que un empleado necesita diez horas para realizar la tarea la primera vez (esto es, t(J) = JO horas) y nueve para realizarla la segunda vez (esto es, 1(2) =9 horas). Entonces, usando la ecuación anterior se encuentra que 9.0 =
r fi
10(r 13)
= _2._ = o.9 lO
-B In 2 = In (0.9) => {3 =
0 1054 · = 0.152 0.693
Este valor de {3 se puede usar para estimar el tiempo necesario para completar las repeticiones siguientes; es decir, los valores de t(3), 1(4), etcétera, con la suposición de que la tasa de aprendizaje permanece constante en todas las repeticiones siguientes. Sin embargo, este modelo de aprendizaje no es realista en el sentido de que 1(11) tiende a cero cuando 11 se hace muy grande; es decir, el modelo supone que los trabajadores podrán realizar la tarea en un tiempo cero si practican lo suficiente. Para evitar esta suposición no realista, se supone que existe una asíntota o límite sobre la duración de la tarea tal que 1(11 ) tiende a este límite cuando 11 crece. Para expresar esta relación algebraicamente, se puede definir un modelo de aprendi zaje mejorado como sigue: 1(11) = r(I)
[o+
donde 8 se conoce como un factor de incompresibilidad y O :::; 8 :::; l . Si 8 =O, entonces el modelo de aprendizaje es el mismo que en el caso anterior; si 8 = 1, entonces t(n) = 1( 1) y no hay aprend izaj e. En este caso, la asíntota o límite cuando 11 crece es 8 t ( 1) . En la figura 2.20 se dan los valores de 1(11) de cuarenta repeticiones de la tarea suponiendo que {3 =0.152, t( 1) = lO horas, y 8 =.6. Como era de esperarse, la duración de la tarea se aproxima lentamente a 6 horas conforme el número de repeticiones (11) aumenta.
Manejo de la incertidumbre Estimar la duración de las tareas es un ejercicio incien o. Las investigaciones han demosLrado claramente que la mente humana está limitada en aspectos que afectan nuesLra habilidad para estimar costos y duraciones de tareas con precisión, aun cuando una persona tenga una gran experiencia en cierta tarea (Kahneman et al., 1982). Por ejemplo, Silverman ( 199 1) demostró que Jos humanos procesan la información de manera secuencial; así, s i la experiencia más reciente de alguien con una tarea específica no fue buena, es posible que estime costos y duraciones asociados con tareas similares más altos que si su experiencia hubiera sido más positiva. De la misma manera, las personas reciben influencia de los incentivos en el entorno del proyecto. Por ejemplo, suponga que su jefe le pide que estime la duración de una ciena tarea que tendrá que realizar más tarde en algún momento. Sabiendo que puede ser sancionado (ya sea implícita o explíci tamente) si la tarea dura más de lo que estimó, casi todas las personas darán una estimación mayor que la necesaria para concederse un amortiguador para contingencias .. Para reducir este problema, los diseñadores del PERT (técnica de eval uación y revisión de programas) suponen que los tiempos de las tareas son variables aleatorias obtenidas de una diSLribu-
PLANEACIÓN DEL PROYECTOS
=~ o l o
Repetición (n)
t(n)
1 2 3 4 5 6
10.00 9.60 9.38 9.24 9.13 9.05 8.98 8.92 8.86 8.82 8.65 8.54 8.45 8.39 8.33 8.28
49
de la duración
7
8 9 10 15 20 25 30 35 40
ción beta (Malcolm et al., 1959). Parecería que la suposición de la distribución beta fue una decisión arbitraria (si bien, razonable) como indica Ciark ( 1962). Para estimar los parámetros de la distribución beta, los administradores tienen que estimar tres valores para cada tarea: el tiempo optimista, el tiempo pesimista y el tiempo más probable. Con estas tres estimaciones, los diseñadores del PERT dan dos ecuaciones sencillas para calcular la duración esperada (media) y la varianza de cada tarea. Para una tarea dada, si
t' = estimación del tiempo optimista rP = estimación del tiempo pesimista t"' =estimación del tiempo más probable entonces la duración esperada de la tarea (que se denotará por¡..¡.) está definida por
y la varianza está dada por
Una distribución beta es una distribución unimodal que (a diferencia de la distribución normal) llega al eje x. Una distribución beta no es necesariamente simétrica, puede estar sesgada a la derecha o a la izquierda, dependiendo de los valores de los parámetros. La figura 2.21 da un ejemplo de la distribución beta. Suponga, por ejemplo, que una administradora trata de estimar la duración de una tarea de programación. Si supone que la tarea durará 6 días en las mejores circunstancias, 40 días en las peores circunstancias, pero que lo más probable es que requiera 11 días, entonces la duración esperada, llj• de esta tarea será f.Lj
= 6+14+4(11) = 10.67
6 con una desviación estándar igual a
50
CAPÍTULO 2
INICIO, SELECCIÓN Y PLANEACIÓN DE UN PROYECTO
FIGURA 2 .21 Ejemplo de una distribu· ción beta
Fu nción de densidad de probabilidad - - - - -- - T iempo para terminar la tarea j
-----~
~~~----------~--~-------------~~ Tiem po
T iempo optimista =
t'J
~empo más probable= tj
Tiempo pesimista=
t1
Duración espe rada = )1
Han surgido muchas interrogantes acerca de estas ecuaciones, la elección de la distribución beta
y la capacidad de los admi nistradores/expertos para estimar con precisión los tres valores requeridos. Por ejemplo, ¿puede un administrador/experto estimar los tiempos optimista y pesimista para todas las tareas? Dado que estos tiempos son los puntos extremos de la distribución beta, muchos investigadores (Moder y Rodgers, 1968; Lau et al., 1996) han opinado que es dudoso que alguien pueda estimar con exactitud la duración de tareas que nunca ha experimentado (o que no está consciente de haber experimentado). Otro problema surge de la definición del tiempo pesimista tp (Perry y Greig, 1975) que requiere que el tomador de decisiones no considere posibles catástrofes al hacer su estimación. Así, el administrador/experto debe evaluar con precisión los peores tiempos q ue pueden ocurrir en condic iones "normales" (lo que esto quiera decir) para cientos o miles de tareas. Además, también se ha cuestionado si los administradores/expertos realmente entienden la diferencia entre una moda, t"', y la mediana; como indica Trout ( 1989), usar la mediana en lugar de la moda ocasionará una distorsión significativa en los cálculos de la media y la varianza (a menos que se modi fiquen las ecuaciones para calcularlas). En respuesta a estas críticas, algunos investigadores (Moder y Rogers, 1968; Perry y Greig, 1975) han sugerido que los administradores/expertos estimen la duración de las tareas en puntos que ocurran con más frecuencia que los puntos extremos de la distribución beta. Se anal iza con más detalle su sugerencia y las implicaciones con propósitos informativos. Primero observe que los puntos ex tremos de la distribución beta se pueden considerar como fractiles ta donde Prob (t :=::;
t0 )
=a
Usando las suposiciones del PERT, la estimación del tiempo optimista (fJ) corresponde a t0 , mientras que la estimación del tiempo pesimista (tP) corresponde a t 100. Observe que la moda no es una medida de fracti l, mientras que la mediana (150) sí lo es. Moder y Roger ( 1968) contemplan el uso de otros fractiles t 0 y t 1()()..o , en lugar de t 0 and t 100, respectivamente. Ellos suponen que la definición de la media conservaría la misma forma, excepto que se emplearían las medidas del fractil modificado; esto es,
PLANEACIÓN DEL PROYECTOS
JL · =
)
51
'a+ two-u + 4tm 6
Basándose en su estudio de varias distribuciones (beta, triangular, uniforme. normal y exponencial), estos investigadores sugieren modificar la fórmula de PERT para definir la desviación estándar de manera que la relación del intervalo a la desviación estándar (1 100-o - t0 )/a sea más robusta respecto a la forma de la di stribución y a los valores relativos de la media y a la moda. En particular, sugieren que la desviación estándar se defina como
donde K 0 es 3.2 para a= 5 y K 0 = 2.7 para a = 10. Para probar si estos valores funcionan bien e n la práctica, Moder y Rogers presentaron datos de la "experiencia" de restaurar un escritorio a cuatro grupos de sujetos y se les pidió que estimaran los parámetros 10 , t 100-o (para a = O, 5 y 1O) y tm• así como una estimación (puntual) de la media. Los cuatro grupos de sujetos incluían un grupo que tenía experiencia con el modelo PERT (PERT), un grupo con conocimientos de estadística, pero no de PERT (técnjco), un grupo con pocos conocimientos de estadística y sin experiencia de trabajo (no-tecA) y un grupo con pocos conocimientos de estadística, pero con cierta experiencia de trabajo (no-tec 8 ). Los datos de "experiencia" presentados a estos individuos eran valores aleatorios obtenidos de una distribución beta con medja 17.16 y varianza 5.29. Los resultados de los experimentos de Moder y Roger se presentan en la figura 2.22. Como se indica, los sujetos dieron estimaciones más precisas de la media cuando se les pidió que dieran tres estimaciones de la duración de la tarea en lugar de una sola estimación puntual. Estos resultados implican que hacer tres estimaciones obliga a los s ujetos a pensar con más deteninúento acerca de la tarea en cuestión, obteniéndose resultados más exactos. Respecto a la estimación de la media, el valor específico de a no fue significativo. Sin embargo, al estimar la desviación estándar, los sujetos estuvieron significativamente más cerca del valor verdadero cuando se les pidió que estimaran los fractiles 5 y 95 (en este caso la varianza promedio fue 4.4). Así, Moder y Roger concluyen que las ecuaciones originales del modelo PERT para estimar la media y la desviación estándar se modifiquen y que deben ser: :JGURA 2 .22 =.asultados de los ::r.~eri mentos de ooer y Rogers
Estim aciones prom edio de la duración media
PERT Técnico No-tecA No-tec B
CPM
a :: O
a :: 5
a = 10
17.8 17.8 17.8 17.6 17.75
17.2 17.1 17.3 17.2 17.2
17.2 17.0 17.2 17.1 17.125
16.8 17.2 16.8 16.975
Estim aciones promedio de la varianza
a =O PERT Técnico No-tecA No-tec B
2.6 2.6 2.1 2.7 2.50
a ::5 5.1 4.8 3.5 4.1 4.38
a :: 10
3.1 3.2 2.4 2.7 4.38
17.1
52
CAPÍTULO 2
INICIO, SELECCIÓN Y PLANEACIÓN DE UN PROYECTO
Jl.=
(t95 + t5 +4tm)
6
y
Muchos otros investigadores han estudiado cómo definir mejor la media y la desviación estándar de la duración de tareas y han cuestionado las fórmulas sugeW as por Moder y Roger. Con base en un análisis de las distribuciones beta, gama y lognormal, Perry y Greig ( 1975) sugieren que las fórmulas siguientes dan una mejor aproximación para la mayoría de las distribuci ones y formas: J.Lj
=
t95 + t 5 + 0.95t 2.95
111
y
a = (t95-t-) ) 3.25 Algunos investigadores han señalado que para algunos administradores/expertos puede ser difícil estimar la moda (suponiendo que saben cuál es la diferencia entre las dos medidas). Dado que la moda no es un fractil (esto es, su valor cambia según la forma de la di tribución), es inconsi Lente pedirle a un admjnistrador/experto que estime dos fractiles y la moda (la diferencia puede introducir un error considerable en los valores estimados de la media y la varianza). Por lo tanto, estos investigadores sugieren usar la mediana (tso) en lugar de la moda. En este caso, Perry y Grieg observan que la fórmula siguiente sugerida por Pearson y Turkey ( 1965) dará una estimación de la media "extraordinariamente exacta y libre de la distribución": J1. = t 50 + 0.185(r95 + t5 -2t50) que, de acuerdo COQ Perry y Grieg, da errores menores que 0.5% con todas las di stribuciones u nimodales, excepto cuando la distribución es extremadamente Ieptocúrtica (angosta y alta). (La fórmula para estimar la desviación estándar queda igual (t95 - t 5)/3.25.) Los investigadores del comportamiento en campos relacionados han sugerido también que se pueden hacer estimaciones más exactas usando fractiles. Hamption et al. ( 1973) y Solomon ( 1982) analizan el tema de entrenar a los administradores y estructurar preguntas para dar buenas estimaciones de frac ti les. Basándose en esta investigación, Lau et al. (1 996) concluyen que se les pida a los administradores/expertos que den siete estimaciones de fractiles para cada tarea; ellos indican también que cinco fractiles, aunque dan estimaciones menos precisas de f..L y cr, en las apl icaciones prácticas serán suficientes. En la tabla siguiente se dan los fractilcs sugeridos en cada caso (incluyendo la fórmula de tres fractiles propuesta por Pcarson y Turkey). (Pearson y Turkey ofrecen también un método de estimación de cinco fractiles basado en un esquema iterativo que fue mejorado después por Keefer y Bodily.) Según extensos análisis de regresión de datos generados a partir de varias di stribuciones beta, Lau et al. sugieren que las fórmulas siguientes darán estimaciones de f..L y cr que son exactas para cualquier distribución beta. Para cinco fractiles,
y
CONCLUSIONES
53
Para siete fractiles, J.L
=0.4(t99 + r01 ) + 0.11 (t90 + t10) + 0.23(175 + 125) + 0.24 r50
y
a= 0.2(t99 - t01 ) - 0.6(t90 - t 1o) + 1.2(t75 - t25 ) Es útil considerar las ventajas y desventajas de cada método de estimación. Primero, la evidencia empírica indica que los humanos pueden estimar mejor la mediana que la moda, por lo que parece que los esquemas de esti mación deben estar basados en fractilcs. Sin embargo, tres fractiles son pocos porque no proporcionan información acerca deJa .forma (sesgo, c urtosis) de la di stribución de la duración, por lo menos respecto a la distribución beta, ya que toda distribución be ta se puede ajustar a c ualesquiera tres fractiles. Adem ás, ya se dijo que es muy difícil para un administrador/experto esti mar con precisión los punto extremos de una distribución (como 101 y t 99) . Entonces, dado que las evidencias empíricas indican que los administradores/expertos son más precisos cuando estiman fractiles centrales que valores extremos, parece que un método de estimación con cinco fractiles ofrece la mejor solución respecto a exactitud y facilidad de realización. Debe observarse otro punto importante. Toda estimación de la duración o costo de una tarea tiene influencia de los incemivos que enfrenta el individuo que hace la estimación. Considere el caso e n que se pide a una persona estimar una tarea que luego tendrá que realizar, y que será sancionada (implícita o explicitamente) si esta realización le toma más tiempo (o recursos) de lo que estimó origi nalmente. Es obvio que lo más probable es que el individuo "i nfle" su estimación. Aún más, es posible que una organización que tiene un sistema de este tipo también tenga datos históricos que reflejen tales estimaciones infladas. Para evitar estos sesgos e n las estimaciones, los administradores deben observar que las estimaciones de las tareas son variables aleatori as y que, como tales, es posi ble que excedan su duración (o costo) esperada. Si la duración de una tarea sigue una distribución beta, entonces hay una probabi lidad de 50% de que la duración de la tarea en condiciones normales sea mayor que su valor esperado. Si un individuo sabe que no será sancionado si el trabajo excede la duración esperada, es más probable que haga una estimació n exacta de la duración y costo de la tarea. Un administrador puede entonces usar un análisis de riesgo y sensibilidad para determinar el tamaño y ubicación de los amortiguadores de contingencia. Esto se analiza con más detalle e n el capítulo 6.
CONCLUSIONES Quizá el aspecto más importante de la administración de proyectos es elegir el proyecto adecuado. Se analizaron algunas medidas usadas con frecuencia para evaluar proyectos como periodo de pago, tasa interna de retorno y flujo de efectivo descontado (FED)/valor presente neto (VPN). Se analizó el valor comercial esperado (VCE) y se mostró que sólo e l VCE es capaz de incorporar explícitamente diferentes clases de riesgos durante la vida del proyecto. Para un administrador de proyectos es crítico mantener una perspectiva de "opciones"; esto es, conservar la flexibilidad para ajustar los recursos del proyecto (o retrasar o suspender un proyecto) aun después de que ha iniciado. Esta habilidad de responder de manera dinámica a las condiciones cambiantes aumentará el valor esperado de un proyecto conforme aumente la incertidumbre asociada a él. En enfoque de "filtro-etapa" ayuda al admi nistrador de proyectos a instituir esta per pectiva. También se analizaron algunos elementos clave que constituyen la mayor parte de los planes de proyecto: resumen de proyecto/ejec utivo y defi nición del trabajo, cómo usar una estructura desglosada del trabajo (EDT) para de finir los paquetes de trabajo básicos que co nstituyen el proyecto, y cómo estimar el costo y la duración de estos paquetes de trabajo. Comúnmente, la información acerca del personal del proyecto y un plan organizacional también son parte del plan del proyecto; la información de los equipos de l proyecto y la estructura de las organi zacio-
54
CAPÍTULO 2
INICIO, SELECCIÓN Y PLANEACIÓN DE UN PROYECTO
nes se da en el capítulo siguiente. En lo capítulos 4 y 5 se analizan los conceptos de programación del proyecto para minimizar el tiempo de realización y el costo del proyecto, respectivamente. Además, el esquema del proyecto casi siempre contiene información de los sistemas de supervisión que se usarán para controlar el proyecto. Por último se deberá indicar un proceso de revisión que especifique cómo se concluirán los proyectos y cómo, cuándo y quién realizará la audi toría posterior al proyecto.
•
PROBLEMAS PARA ESTUDIO 1.
Suponga que su compañía puede elegir entre más de una d ocena de proyectos, pero sólo puede seleccionar unos cuantos. ¿Qué criteri o sugeriría para ordenar los proyectos por calificaciones? ¿Cómo decidiría al fi nal qué proyecto elegir?
2.
Una métrica popular para evaluar proyectos es la tasa de retorno sobre la inversión (ROl, retum on investment). ¿Cómo se relaciona la ROl con el VPN y el VCE, según se defin ieron en este capítulo? ¿Cuál de estas medidas recomendaría? Argumente su respuesta.
3.
El propietario de los Seattle Seabirds, un equ ipo de badminton local, quiere mudar a su equipo a Los Ángeles donde el mercado televisivo de bádminton es mucho mayor y puede ganar más dinero. Para organizar la mudanza a Los Ángeles desarrolló el diagrama del sistema que se muestra en la figu ra 2.23, indicando las tareas que debe realizar. Use este diagrama para construi r una EDT indicando todas las tareas (esto es, paquetes de trabajo) que deben completarse para mudar a los Seabirds a Los Ángeles. Proporcione su estimación de la duración y costo de cada tarea, y la duración y costo de todo el proyecto.
FIGURA 2. 2 3 Tareas identificadas para muda r u n equipo de bádm i nton
Contratar empresa de RP en Seattle '
'-----
Contratar agencia de publicidad en lA
Publicidad en lA
Control de promoción/daño
1
Cancelar instalaciones de teléfono
Informar
Contratar abogados
1
l
Contrato con el estadio Kay
Cerrar la instalación de entrenamiento actual
-
,_
Despedir al personal
Rescindir el contrato
Mudar a los Seattle Seabinls a Los Ángeles
1 -
Convenio de ingresos con1V
Confi rmar estadio en lA
Equipo y provisiones
Empacar f - - -
Cartas de los aficionados
PROBLEMAS DE ESTUDIO
4.
55
Wilden Wooley ha decidido constru ir un garaje en su casa. Como su presupuesto es limitado, ha decidido ser su propio contratista y contratar a los trabajadores según los vaya necesitando. Wilden quiere saber cuánto tiempo tomará todo el proyecto, y Jo más importante (dado su estado financiero), cuánto le costará el garaje. Además, el arquitecto que q uiere consultar saldrá a un viaje largo dentro de un mes y Wilden quiere estar seguro que todo lo que hará el arqu itecto esté terminado antes de que se vaya. Después de hablar con varios amigos que han hecho proyectos similares, Wilden empieza a hacer los planes para su garaje. Identifica los Q¡;¡s productos principales que constituyen el primer nivel de la EDT: •
el garaje
•
la administración del proyecto
Una vez establecidos estos dos productos principales, Wildcn puede identificar las tres tareas principales a realizar: •
resolución de asuntos legales
•
análisis arquitectónico
•
construcción
Wilden estim a que alg unas partes de las dos primeras tareas pueden ser simu ltáneas, pero no puede empezar con la construcción hasta terminar las dos primeras tareas. Wilden encuentra que la pri mera tarea (resolución de asuntos legales) consiste en dos subtareas: 1. 1.1 verificar las regul aciones en la zona y 1. 1.2 obtener los permisos de construcción necesarios. El análisis arquitectónico también se divide en dos subtareas: 1.2.1 consulta arquitectónica inicial y dibujos y 1.2.2 planos definitivos. Por último, la construcción del garaje se puede dividir en tres subtareas: 1.3. 1 construcción de cimientos, 1.3.2 construcció n de la estructura y 1.3.3 instalación eléctrica. Después de hablar con el arquitecto, Wi lden descubre que tal vez se necesite una variación de zona para el garaje, ya que propone construir el garaje justo al lado del límite de su propiedad. Así, Wilden observa que obtener una variación de zona agregará otra subtarea 1.1.3 bajo la primer'!. tarea (resolución de asuntos legales). Sin embargo, como no es seguro que se necesite una variación de zona, Wtlden decide hacer dos EDT y planear ambas contingencias. La figura 2.24 muestra la segunda EDT que hace Wilden, suponiendo q ue se necesite una variación de zona. Como está preocupado por la asignación de tiempo, tanto suyo como del arquitecto, Wilden divide la subtarea variación de zona en tres paquetes de trabajo: ( 1.1.3.1 ) obtener los dibujos y la solicitud para la variación de zona, ( 1. 1.3.2) esperar la respuesta y ( 1. 1.3.3) recoger la variación. Se definieron tres paquetes de trabajo, ya que el arquitecto sólo se necesitaba para hacer los dibujos y la solicitud; ninguno de los dos se necesitaba durante la espera, y tampoco se podía iniciar ningún trabajo en ese lapso; se necesitaría que Wilden fuera al centro a recoger la variación de zona cuando fuera emitida. ¿Cómo modificaría la EDT de Wilden Wooley, para su nuevo garaje, si las autoridades le pidieran que consultara a un ingeniero en estructuras para darle el permiso de construcción? ¿Cómo modificaría la EDT si, para emitir la vari ación de zona, las autoridades le pidieran obtener la aprobación de su vecino? 5.
Estime el costo de cada tarea en la EDT del problema 4 con objeto de definir una EDT con costos. Usando la EDT con costos, obtenga un intervalo de costos estimados que piense que son estimaciones razonables para el proyecto de Wilden Wooley.
6.
Usted ha decidido pintar una habitación que mide aproximadamente JO' x 20'. Va a pintar las paredes y techos del mismo color con pintura estándar que garantiza cubrir la pintura anterior con una mano. La madera alrededor de las cuatro ventanas y de las dos puertas se pi ntará con
56
CAPITULO 2
INICIO, SELECCIÓN Y PLANEACIÓN DE UN PROYECTO
FIGURA 2 . 24 EDT para el proyecto de construcción del garaje
Proyecto de construcción d el garaje de W ilden Wooley
1 1
1
1
Administración del proyecto
1.1 Asuntos legales
1.2
1.3
Análisi s arquitectónico
Construcción
1
1
1
1
1.1.1
1.1.2
Verificación de regulaciones en la zona
Permiso de construcción
1
..,.1.3 Variación de zona
1
1.2.1
1.2.2
Consultas iniciales
Planos finales
1
1
1.3.1
1.3.2
Cimientos
Estructura
1
1.3.3 Instalación eléctrica
una pintura semibrillante. Al iniciar el trabajo se contará con toda la pintura y utensilios necesarios. Usted ha preguntado a amigos y parientes que han realizado tareas similares cuánto tiempo les llevaron sus trabajos de pintura. La tabla siguiente proporciona infonnación de treinta y dos tareas similares. Horas
M i nutos
Horas
Minutos
27 38 33 17 26 22 14 30 28 21 23 27 23 37
25 25 12
31 19 26 30 25 24 32 32 13 42
52 15 27 27 21 28 58
44
7 1 2 27 30 13 59 44
15 6
17
54
17
13
22
32 32 27 26 21
43 45 57 15 31 15 11 52
Con base en esta información y en su experiencia en tareas sim ilares, estime la media y la varianza de esta tarea. ¿Cómo varían sus estimaciones si usa a) las fórmulas estándar de
PERT, b) el enfoque de tres fracti les, e) el enfoque de seis fractiles y d) el enfoque de siete
PROBLEMAS DE ESTUDIO
57
fractiles? ¿Cuántas horas estimaría si fuera a presentar una oferta fija de costos para esta tarea? 7.
Suponga que ha terminado con éxito la etapa de I&D de un proyecto de desarrollo de un nuevo producto. Esta etapa duró varios años y costó una cantidad estimada de $30 millones, pero fue un éxito que produjo un producto prototipo. Sin embargo, antes de que su empresa pueda iniciar la etapa de investigación de mercado, un antiguo competidor anuncia que en un año presentará un producto similar que competirá directamente con el que acaba de desarrollar. Su empresa estima que hay una probabilidad de 60% de que su nuevo producto sea mejor q ue el del competidor. Si su producto es mejo'*"u compañía tendrá una ganancia neta de $ 10 millones por año; si no lo es, su empresa perderá $6 millones por año. Los gerentes de marketing de su compañia estiman que el producto tendrá una vida de 1O años. Suponga una tasa de descuento de 10% y calcule el VPN de su nuevo producto, suponiendo que procede de inmediato con la etapa de investigación de mercado, que se estima costará $1 O millones por año durante dos años (si n embargo, si después de un año encuentra que el producto de su competidor es mejor que el suyo, interrumpirá la etapa de investigación de mercado). Compare su resu ltado con el caso de que decida esperar un año (para saber más acerca del producto de su competidor) antes de proceder con la etapa de investigación de mercado. Sin embargo, si decide esperar un año y su producto es el mejor, entonces tendrá sólo una vida de nueve años. ¿Cuál piensa que será la mejor estrategia?
8.
Yash B'Gosh es el administrador de una empresa que está considerando cuatro proyectos; dos de ellos (A y B) son proyectos de TI. Yash ha estimado el costo anual de cada proyecto; estas estimaciones se dan en la tabla siguiente. La empresa puede financiar cualquiera de los proyectos total o parcialmente; sin embargo, no podrá modificar el porcentaje de financiamiento una vez iniciado el proyecto (por ejemplo, si el proyecto A se financia a un nivel de 50%, entonces este proyecto costará $20 el primer año, $5 el segundo y $10 el tercero). El valor que cada proyecto tiene para la compañía se indica mediante la calificación del proyecto; si el proyecto se financia sólo parcialmente, la calificación del proyecto se escala proporcionalmente (por ejemplo, si el proyecto A se financia a un nivel de 50%, la empresa gana 0.5 x 0.74 = 0.~05). Yash desea elegir un portafolio de proyectos que maximice la calificación total, sujeta a las restricciones de presupuesto. Además, la alta administración ha establecido que el financiamiento de proyectos de TI no debe exceder el 40% de los fondos totales para proyectos en los próximos cinco años. 1 Proyecto A (IT)
$ 40 $ 65 $ 6 $ 20 Fondos disponibles $120
Proyecto B Proyecto C (IT) Proyecto D
9.
2
3
4
5
$10 $36 $ 8 $10 $40
$20 $30 $10 $20 $40
$20 $25
$30
$20 $55
$60
Calificación del proyecto
0.741 0.845 0.353 0.457
a.
Dadas las restricciones, ¿qué proyecto recomendaría a Yash que financiara? ¿A qué nivel?
b.
Suponga que Yash ha decidido retrasar algunos de los proyectos siempre y cuando todos los proyectos se puedan terminar en cinco años. ¿Recomendaría a Yash que retrase algún proyecto?; si es así, ¿cuál y cuánto tiempo?
En el problema 8, suponga que puede elegir o no un proyecto completo (es decir, puede financiar un proyecto O o 100%). ¿Cómo modifica esto su decisión en el problema 8?
58
CAPÍTULO 2
INIOO, SELECC1ÓNY PLANEACIÓN DE UN PROYECTO
10.
Trid Soap Company emprendió el desarrollo de un detergente rad icalmente nuevo que se espera necesitará tres años y costará aproximadamente $6 mj llones por año. Al final de los tres años Trid sabrá si el producto es un éxito técnico; en este momento, los administradores de Trid estiman una probabilidad de 70% de tener éxito en el desarrollo del detergente. Suponiendo que I&D tiene éxito, Trid puede lanzar el detergente el en año 4 a un costo estimado de $4 millones. El vicepresidente de mercadotecnia estima que la probabilidad de éxito si lanzan el detergente es 0.6; si es un éxito comercial, tendrán ingresos netos de $ 15 mi llones anuales durante cinco años. Si no es un éxito comercial, el nuevo detergente producirá ganancias de sólo $2 millones anuales. Suponiendo una tasa de descuento anual de 12%, ¿cuál es el VPN del proyecto?, ¿aconsejaría que~ conti nuara con este proyecto?
11 .
Suponga que la primera etapa (I&D) del problema 10 se ha desarrollado muy bien: se desarrolló con éxito un detergente prototipo al final del año 3 (a un costo de $6 millones anuales). Al pri ncipio del cuarto año (antes de que la compañía inicie las pruebas de mercado), un competidor anuncia que en un año tendrá un producto similar. Los administradores de Trip estiman que hay una probabilidad de 75% de que su producto sea mej or que el producto del competidor. Si el producto de Trid es mejor, obtendrán ganancias netas de $1 2 millones anuales; si no es así, la empresa perderá $3 millones anuales. La alta administración de Trid anal iza la posibilidad de suspender el proyecto por un año, para obtener más informac ión del producto de sus competidores antes de lanzar su nuevo detergente. Pero si esperan y su producto es mejor, la vida del nuevo producto se reducirá cuatro años. ¿Qué aconsejaría en este caso (el costo de lanzar el nuevo producto sigue siendo $4 mi llones)? (Supo nga una tasa de descuento anual de 12%).
12.
a. Suponga que un trabajador tarda diez minutos en realizar una tarea la primera vez. Si el fac tor de incompresibilidad ó es 0.6 y el parámetro de tasa de aprendizaje .B es 0. 152, ¿cuántas veces tendrá que repetir la tarea para que pueda terminar una tarea similar en ocho min utos o menos? b. Suponga que la persona trabaja un turno de ocho horas y que al d ía siguiente empieza con 95% de la eficiencia que tenía la última vez que realizó la tarea el día anterior. ¿Cuántas veces tendrá que repetir la tarea para alcanzar el objetivo de realizarla en ocho minutos o menos? -
13.
Considere que está planeando una subasta para reunir fondos para una institución de caridad. ¿Existen otras formas, diferentes a las dadas en las figuras 2. 17 y 2. 18, de definir una EDT de dos y de tres niveles? Amplíe su EDT de tres niveles a una EDT de cuatro niveles. Estime los costos de los paquetes de trabajo definidos en su EDT de cuatro ni veles.
REFERENCIAS Brealey, R. y S. Myers. Principies ofCorporate Finance. Nueva York: McGraw·Hill, 1988. C laric, C.E. "T he PE RT Model for the Distribution of an Activiry Time", Operations Research 1O ( 1962): 405-406. Cooper, R.G .. S. Edgell y E. Kleinschmidt. Research Teclmo logy Munagemem (mano-abril, 2000). Faulkner, T. ··Applying ·O ptions Thinking' to R&D Valuation", Research·Teclmology Manageme/11 (mayo-junio, 1996): 50-56. Fox, G.E., N.R. Bake r y J.L. Bryant. '·Economic Models for R&D Project Selection in the Presencc of Project lnteractions", Mwzagemem Science 30. núm. 7 ( 1984): 890-904. Hodder. J. y H.E. Riggs. ''Pitfalls in Evaluating Risky Projects", Han-ard Business Review (enero-febrero, 1985): 128-1 36. Huchzenneier, A. y C. H. Loch. " Project Management Under Risk: Using the Real Options Approach 10 Evaluate Flexibility in R&D". Mwzagemem Scitnce 47, núm. 1 (enero. 2001): 85-101. Krakowski. M. " PE RT and Parkinson's Law'', Interfaces 5, núm. 1 (noviembre. 1974).
APÉNDICE 2A. CRISTÓBAL COLÓN, INC., VIAJE PARA DESCUBRIR RUTAS COMERCIALES A ASIA
59
Loch, C.H., M.T. Pich, M. Urbschat y C. TeiWiesch. -selecting R&D Projects at BMW: A Case Study of Adopting Marhematical Programming Mode/s': IEEE TrlUISOCnims lH1 &tgineenitg Management 48, núm. 1 (200 1): 70-80. Malcolm, D.G., J.H. Roseboom y C.E. Clark. "Applicarion of a Technique for Research and Development Prograrn Evaluation", Operations Research 1. núm. 5 (sep1iembre-«:tubn:. 1959): 646-669. Moder, J.J. y E.G. Rodgers. "Judgment Estimates of the Momenrs of PERT Type Disuibutions··, Managemelll Science 15, núm. 2 (octubre, 1968): 876-883. Parkinson, C.N. Parkinson 's L.aw arul Other Slltdies in Admini.srronon. Nueva York: Random House, Inc., 1957. Wheelwright, S. C. y K. B. Clark. "Creating Project Plans to Focus'", Har.-ard Business Review (marzo-abril, 1992): 7(}..82. Youker, R. ··A New Look at the WBS: Project Breakdown Structures (PBS)". Projec1 Manageme111 Joumal (1989): 54-59.
APÉNDICE 2A. CRISTÓBAL COLÓN, INC., VIAJE PARA DESCUBRIR RUTAS COMERCIALES A ASIA Una máquina del tiempo, inventada recientemente por el doctor Bob N. Waters, lo regresa en el tiempo a enero de 1492 en Palos, España. Para aprovechar los valiosos conocimientos que ha adquirido en su curso de administración de proyectos, está pensando en aceptar un puesto en Cristóbal Colón Inc., una pequeña empresa fundada por Cristóbal Colón para encontrar y explorar rutas comerciales más eficientes a Asia, difundir el Cristianismo y dirigir una expedición a China. Después de considerar algunas otras ofertas de trabajo, usted decide aceptar la oferta de Colón para trabajar como su administrador de proyectos por un salario de $30/día. Colón, que los círculos locales consideran un loco visionario que piensa que la tierra es redonda, quiere comprar tres navíos y navegar hacia el oeste para encontrar la ruta más corta a Asia. Él quiere usar esta idea como base de una propuesta para responder a la licitación (adjunta) publicada recientemente por el rey Fernando y la reina Isabel. Además de usted, C. Colón, Inc. tiene en su nómina un contralor (Arturo Bayliner) y un asistente administrativo (Juan de Puca). Arturo gana $35/día y Juan de Puca $20/día, que son los salarios promedio en el mercado para contralores y asistentes administrativos en 1492 (en dólares corrientes). Aunque Bayliner, de Puca o usted no irán en el viaje, estarán trabajando tiempo completo en tareas administnnivas y de relaciones públicas hasta el regreso de Colón. Colón no acepta salario alguno por el proyecto; en lugar de esto ha pedido ser nombrado caballero, recibir el título de Almirante del Océano y 10% de cualquier tesoro que descubra si tiene éxito. Antes de que Colón presente su propuesta al rey y la reina (y quizá inicie su viaje para encontrar una nueva ruta comercial a Asia), usted recuerda, de su clase de administración de proyectos, que es necesario hacer un plan del proyecto. Antes de empezar, decide entrevistar a Colón con objeto de identificar las principales tareas que deben completarse antes de iniciar el viaje y tener una mejor idea de los tiempos y costos involucrados. De su clase de administración de proyectos recuerda también que en esta situación puede ser útil una estructura desglosada del trabajo (EDT). Colón le informa que él está en bancarrota por lo que no se puede iniciar tarea alguna hasta que consiga el financiamiento del rey Fernando y de la reina Isabel. Sin embargo, una vez asegurado el financiamiento, Colón contratará a tres capitanes; a su vez, los capitanes contratarán a sus navegantes. Juan de Puca contratará a la tripulación. Las leyes españolas establecen que no se puede contratar a nadie hasta que el puesto se haya publicado por lo menos dos semanas en el periódico local y en la espalda de un ánade errante conocido como la "world wide web". Una vez publicado el puesto se pueden iniciar las entrevistas y la contratación. La tarifa actual en el mercado para capitanes de barcos es $60/día, Jos navegantes ganan $45/día y los miembros de la tripulación $20/día. Colón quiere comprar tres barcos para el viaje; según un artículo que leyó recientemente en el World Streer Joumal, tres barcos es el tamaño de flota más efectivo. Colón también indica que
60
CAPITULO 2 INICIO, SELECCIÓN Y PLANEACIÓN DE UN PROYECTO
piensa llamarles la Santa María, la Pinta y la Niña (para honrar los nombres en la familia de su esposa). Después de inspeccionar los periódicos locales y la publ icidad fija, usted ha identificado seis barcos que están a la venta, su respectivo costo, tamaño de tripulación necesaria y probabilidad de que pueda hacer todo el viaje, como se muestra en la figura 2A.l. Luego de veri ficar los barcos que están a la ven ta, Colón detem1ina que ninguno tiene velas adecuadas para ese viaje; deberán mandar a hacer nuevas. El fabricante de velas estima que necesitará aproximadamente un mes para hacer velas primarias y las de repuesto. Dado que la navegación es un asunto crucial, cada capitán será responsable de contratar sus propios navegantes, quienes, a su vez, serán responsjf¡les de adquirir los mapas y herramientas de navegación (brújulas, etcétera). Como el ali mento y la bebida son importantes para la tripulación, ellos serán responsables de comprarlos (en el Costeo español) y almacenar todos los comestibles en la embarcación. Juan de Puca comprará otros artículos (no comestibles) que la tripulación almacenará. Una vez contratados los capitanes, Colón quiere comprar seguros de viaje para él y los capitanes. La compañía de seguros más grande del momento, Lords of London, estima que la prima de un seguro de vida para alguien que va a salir en una exploración marítima al fin del mundo es aproximadamente 40% del salario total. La licitación pide además que Colón asegure los barcos nombrando al rey Fernando y la reina Isabel los beneficiarios. Colón quiere comprar todas las pólizas de seguro a la misma compañía; estima que necesitará una semana para todas las negociaciones. Una vez terminadas las contrataciones y almacenadas a bordo las provisiones, Colón planea llevar a su flota a un viaje de prueba por el Mediterráneo. Estima que este viaje durará alrededor de dos semanas. Después del viaje de prueba cree que necesitará tres semanas o más para hacer las reparaciones y ajustes necesarios y reabastecer las provisiones. Cuano todo esté listo, Colón y sus tres barcos se dirigirán al oeste para buscar rutas comerciales hacia Asia. Colón espera que cada tramo del viaje tomará tres meses, pero sabe que el ri esgo es muy alto y estima que sólo hay 65% de posibilidades de completar cada tramo en menos de cuatro meses. Colón le pide que prepare la propuesta que presentará al rey Fernando y la reina Isabel en respuesta a su licitación. Por favor observe que la licitación pide un resumen ejecutivo, así como la determinación de metas y restricciones, una estructura desglosada del trabajo (EDD con costos y una red de precedencias. Asegúrese de que puede sustentar sus suposiciones porque es sabido que el rey y la reina piden documentació n que sustente las estimaciones de tiempos y costos. Su licitación debe establecer también, clara y brevemente, por qué su proyecto debe ser aprobado y financiado.
Oid, Oid ... Licitaciones Rey Fernando y reina Isabel, por medio de la presente solicitamos propuestas formales para explorar nuevas rutas comerciales a Asia, para difundir el Cristianismo, traer oro y especias, e incrementar el comercio mundial. Toda propuesta deberá proporcionar la información siguiente: 2.
Resumen ejecutivo (incluyendo especificaciones de contrato) Determinación de metas y restricciones
3. 4. 5. 6.
Estructura desglosada del trabajo con costos Red de precedencias Estimación de la duración del proyecto Programación de pagos
1.
Cantidad solicitada: $ _ _ _ _ Todas las propuestas deberán entregarse en la fecha real especificada.
APÉNDICE 2A. CRISTÓBAL COLÓN. INC.• VIAJE PARA DESCUBRIR RUTAS COMERCIALES A ASIA
2A.1 ~azette,
enero
Barco
-=-
Probabilidad de que no se hunda antes de llegar a Asia Tipo de barco
Costo
Tamaño de la tripul ación
$40 000
26
$55 000
40
$30 000 $42 000 $ 10 000
30 40 18
$40 000 .
45
~
1
Goleta
2
Galeón
3 4 5
Carabela Galeón
6
Goleta
Carabela
0.80 0 .95 0.70 0.90 0.30 0.85
l. Nombre del proyecto: - -- - - -- - - - - -- - - -- - - - - - -- - -
2. 3. 4. 5.
Fecha de presentación (dd/mm/aa): - -- - - - -- - - - - - -- - -- - Administrador de proyecto propuesto: - - -- -- -- - - - - - -- - - -División/departamento solicitante: - - - -- - - - - - - - - - - - -- - - - Breve descripción del problema que considera el proyecto: - - - - - -- - - -- -
6. Breve descripción de las ventajas de este proyecto propuesto:
7. Estimación del número total de horas necesarias para terminar el proyecto: - - - - -- 8. Estimación del costo aproximado del proyecto: - - - - - - - - - - -- - -- - 9. ¿Espera usted que todo el trabajo se realice con personal interno? O Sf O No Si la respuesta en (9) es no, ¿cómo se realizaría este trabajo? - - - - -- - - - - - ¿Nuevos empleados contratados? (Indique número, tipo, salario aproximado.) - - - - - -
¿Subcontratación? (Indique aproximadamente el porcentaje subcontratado del proyecto y qué tipo de contratista requiere.) - - - - - - - - - -- -- - - -- - - --
10. ¿Qué productos se obtienen del proyecto? - -- -- - - - - - - - -- - - - - -
11. ¿Habría un aumento significativo en los requerimientos de energía? - - - - -- - - - -
12. ¿Se necesitaría alguna nueva instalación? - - -- -- -- - - - - -- - -- - 13. ¿Habrá algún impacto negativo en la seguridad de la fuerza de trabajo?, ¿en los estándares ambientales? - - - - - - -- - - - - - - - - - - - - - - -- 14. ¿Cuál es el impacto en la imagen de la organización? - - - - - - - - - -- - - - -
Aprobación del proyecto propuesto:
(Administración de supervisión)
Fecha - - - r ..
61
CAPÍTU LO
EQUIPOS DE PROYECTO Y RELACIONES ORGANIZACIONALES
U
na consecuencia de la creciente complejidad tecnológica es la necesidad de tener un liderazgo efectivo y un equipo de proyecto integrado con cuidado, tarea que es un reto si se considera la variedad de habilidades y las ubicaciones geográficas dispares que constituyen la mayoría de los proyectos actuales. La importancia dada a los equipos de proyecto integrados ha sido durante muchos años una piedra angular en la administración de proyectos. En un estudio en veinte proyectos de desarrollo realizados en un lapso de cuatro años en cinco empresas, Bowen et al. (1994) concluyen que los proyectos exitosos ocurren cuando los equipos de proyecto son capaces de trabajar estrechamente unidos para resolver problemas técnicos con eficiencia y transmitir estos conocimjentos al resto de la organización. Los hallazgos de Bowen el al. (así como los de otros) tienen muchas implicaciones para los adrrunistradores de proyectos, los equipos de proyecto y la relación entre un equipo de proyecto y su organjzación. En este capítulo se exploran estas implicaciones y otros temas relacionados con: • • • •
la función y las responsabilidades del administrador del proyecto, la organización y las dinámicas de los equipos de proyecto, la relación entre la estructura organi zacional interna y la administración de proyectos, y las relaciones entre organizaciones y la administración de proyectos.
PAPEL V RESPONSABILIDADES DEL ADMINISTRADOR DE PROYECTOS V EL EQUIPO DEL PROVECTO Es claro que un adrrunistrador de proyectos debe tener un amplio conocimiento y experiencia que abarque múltiples áreas. El administrador de proyectos tiene la responsabilidad primaria de mantener una comunicación efectiva entre los rruembros del equipo, coordi nar su trabajo y mantenerlos centrados en los objetivos del proyecto. El administrador de proyectos interactúa con todos los interesados en el proyecto, es decir, el cliente, los contratistas y las organizaciones reguladoras; estas relaciones se presentan en la figura 3 .l. El administrador de proyectos debe negociar con la alta administración para establecer presupuestos y restricciones de recursos realistas. En muchos casos, el administrador del proyecto no tiene autoridad directa y debe negociar con los funcionarios administrativos los recursos y el financiamiento. El administrador de proyectos debe parúcipar también en la formulación e implantación de cualquier programa de incentivos para el equipo del proyecto. Es evidente que el apoyo de la alta administración es un factor crucial de éxito porque da al administrador de proyectos cierto ni vel de autoridad que de otra manera faltaría. Como se indica en la figura 3.1, el administrador de proyectos y el eq uipo del proyecto trabajan en una relación estrecha. El administrador del proyecto debe mantener al equipo totalmente informado y proporcionarle retroalimentación oportuna y precisa. Como parte de esta información, el administrador de proyectos debe de mantener a los miembros del equipo centrados en los objetivos del proyecto, que es fácil olvidar en proyectos complej os.
62
PAPEL y RESPONSABILIDADES DEL ADMINISTRADOR DE PROYECTOS Y EL EQUIPO DEL PROYECTO
RG URA 3 .1 ~,.ación del administra:.or de proyectos y el _~ui po del proyecto con os o\ros ·m\eresaóos
Cliente
63
Alta administración
Subcontratistas
Organizaciones reguladoras
Funcionarios
El administrador del proyecto debe comunicarse con las personas externas interesadas en el proyecto de manera precisa y oportuna; estas personas externas comprenden al cliente, las organizaciones reguladoras y los subcontratistas, entre otros; la información relevante incluye estado actual del proyecto, información de cambios y modificaciones de diseño, y cambios e n la programación o el presupuesto. El hec ho de que administración de proyectos sea sinónimo de administración de cambios crea tensión, tanto en el administrador del proyecto como en el equipo del proyecto. La tendencia actual de las organizaciones a establecer metas de presupuesto y programación muy estrechas exacerba los niveles de tensión, tanto de los miembros del equ ipo como de los administradores de proyectos. Además, los equipos dentro de una organización con frecuencia compiten entre sí por recursos y otras prioridades. Como resultado, no es raro que surjan conflictos entre los miembros del equipo del proyecto, así como entre los miembros del proyecto y otros miembros de la organización. Tharnhain y Wilemon ( 1977a) identificaron siete áreas básicas que pueden ser fuentes potenciales de conilicto para los equipos y administradores de proyectos: • • • • • •
Programación y secuenciación Procedimientos administrativos Aspectos de mano de obra (personal) Aspectos de presupuesto y costo Conflictos de personalidad Prioridades del proyecto
•
Los trueques, la opinión y el desempeño técnico
Thamhain y Wilemon observaron también que el grado del conflicto ocasionado por estas fuentes varía durante la vida de un proyecto (con excepción de los conflictos de personalidad que parecen ser un factor constante en todo el ciclo de vida del proyecto). En general, parece que el grado de conflicto es más intenso durante la tercera etapa -programación y control- de un proyecto (vea la figura 2.1) cuando se maximiza el empleo de recursos (Posner, 1986). Respecto al curso específico de los conflictos, Posner (1986) informa que los "desacuerdos sobre la programación son resultado de las situaciones de conflicto más intensas en la vida del proyecto". No es de sorprender que Posner y otros hayan encontrado que los temas de programación y presupuesto del proyecto cobran importancia cuando el proyecto se aproxima a la fecha de entrega. Posner también informa que los procedimientos administrativos ocasionan la menor cantidad de problemas debido a la creciente experiencia de las organizaciones e n administración de proyectos como una forma organizacional.
64
CAPITULO 3
EQUIPOS DE PROYECTO Y RELACIONES ORGANIZACIONALES
Varios estudios han analizado la relación entre estilos de manejo de conflictos y éxito o fracaso del proyecto (Thamhain y Wilemon, 1977a; Evan, 1976; Hill, 1977). Hill entrevistó a administradores de cuarenta y dos equipos de proyecto conflictivos considerados de alto rendimiento (veintiséis administradores) o de escaso rendimiento (dieciséis administradores) y encontró que dos factores diferenciaban a Jos administradores de alto rendimiento y los de bajo rendimiento respecto al conflicto interno del equipo: los administradores de alto rendimiento reflejaron un repertorio mucho más amplio de repuestas [a situaciones de conflicto]. Ellos tení~ más ideas y opciones para manejar un conflicto en general. Segundo, parecían tener menos temor a los desacuerdos y se mostraban mucho más dispuestos a enfrentar el conflicto que a evadirlo. Respecto a comportamientos específicos, los administradores de alto rendimiento parecían ser personas que sabían escuchar mejor y que alentaban a sus subordinados a expresar sus inquietudes cuando su nivel de frustración se elevaba. Además, parecían estar genuinamente interesados en el bienestar de sus subordinados y promovían activamente la comunicación y la expresión. En general, los adminisu·adores de alto rendimiento trataban de aprovechar el conflicto para elevar la productividad del equipo del proyecto. Es interesante hacer notar que varios estudios han encontrado una correlación positiva entre el conflicto dentro del equipo y el desempeño del proyecto (Hill, 1975; Brown et al., 1990). Estos hallazgos apoyan a la escuela de pensamiento orientada a la rarea, según la cual los equipos de proyecto en los que hay una gran armonía y camaradería pueden distraerse de Jos objetivos del proyecto y no lograr satisfacer metas o expectativas (es decir, cierto grado de conflicto es benéfico). Por otro lado, la escuela de pensamiento humanista sostiene que equipos que tienen características positivas y relaciones armónicas, tendrán un buen desempeño (es decir, la gente rinde más con menos tensión y conflicto). Para probar estas escuelas de pensamiento opuesto, Brown et al. (1 990) realizaron un experimento en dos universidades con cuarenta y cuatro estudiantes de administración inscritos en cursos de administración de proyectos. Los estudiantes fueron divididos en 14 equipos de proyecto; cada equipo eligió a sus miembros, entre dos y cuatro. El proyecto simulado requería que cada equipo realizara 52 tareas que constituían la etapa de prueba preoperativa de una planta de energía nuclear (una vez terminada la estructura física y antes de iniciar la prueba de bajo poder). El proyecto era razonablemente complejo y requería que los equipos tomaran decisiones que comprendían programación de actividades, asignación de recursos, niveles de personal, tiempo extra, adquisición de equipo y financiamiento del proyecto. El juego había sido calibrado de manera que el costo total (costos de financiamiento, tasas de interés, contratación y despido, multas por accidentes e infracciones de reglamentos, laboratorio, etcétera) fuera una buena medida del desempeño
"Las computaáoras están 5ien, e{perscna{está maf" © 2003 Charles Barsotti de cartoonbank.com. Todos los derechos reservados.
PAPEL Y RESPONSABILIDADES DEL ADMINISTRADOR DE PROYECTOS Y El EQUIPO DEL PROYECTO
65
global del proyecto. Dado que el desemepeño en este proyecto era una componente significativa de la calificación obtenida en el curso, los miembros del equipo tenían un fuerte incentivo para hacer un buen trabajo. Este proyecto simulado proporcionó una oportunidad poco común para examinar procesos y características de un grupo en un entorno controlado durante todo el proyecto (a diferencia de otro estudios que examinan el desempeño de un proyecto sólo en algún momento de la vida del proyecto). Se proporcionaron cuestionariJ a todos lo miembros de los equipos al inicio del juego (antes de comenzar cualquier trabajo), al final del juego (una vez terminado el proyecto) y cada semana durante el proyecto (alrededor de siete semanas). Los cuestionarios consistían en una serie de preguntas acerca de la armonía del equipo, la efectividad en la toma de decisiones, el grado de contribuciones individuales al equipo y atributos individuales. Todas las preguntas tenían una redacción sencilla y se podían contestar en una escala del 1 al 7 (donde 1 = bajo y 7 = alto). La figura 3.2 resume el contenido del cuestionario. Una vez terminado el proyecto, los 14 equipos fueron divididos en dos grupos, según la mediana del costo del proyecto: equipos de alto rendimiento (bajo costo) y equipos de bajo rendimiento (alto costo). Un análisis de varianza con el costo total como variable dependiente, demostró diferencias significativas entre los dos grupos (F =59.46, p < .000 1). Se calcularon las medias agregadas de las preguntas en las tres primeras categorías, de los grupos tanto de alto como bajo rendimiento; los resultados correspondientes en la categoría "armonía en el equipo" se presentan en la figura 3.3. Se obtuvieron resultados similares para las preguntas de las otras categorías. Los resultados fueron algo sorprendentes, pero corroboraban la conjetura de Hill de que cierto grado de conflicto interno puede llevar a un mejor desempeño del equipo. Como se indica en la figura 3.3, los equipos que al fi nal tuvieron un mejor desempeño, inicialmeme tenían medidas bajas de armonía y cohesión en el grupo. Sin embargo, en la segunda semana, el conflicto interno era signifiGU RA 3.2 ':=sumen del contenido cuestionario emplea:.c por Brown et al. "290)
=-
Resumen del contenido del cuestionario Armonía en el grupo Cohesión del grupo Cooperación del grupo Motivación del grupo Capacidades del grupo Contribución de sus miembros Conflicto en el grupo Su pronóstico de la posibilidad de éxito del equipo Efectividad del grupo en la toma de decisiones Calidad de las decisiones tomadas por el grupo hasta ahora Grado de participación del grupo en la toma de decisiones Rapidez del grupo para tomar decisiones Grado de la contribución individual al grupo Experiencia técnica con la que usted contribuye Uso que hace el gru po de su experiencia técnica Su contribución a la experiencia del proceso de grupo Uso que da el grupo a su experiencia del proceso de grupo Atributos individuales ¿Cómo se ve a si mismo dentro del grupo? Se ve a si mismo como el • líder • ca-líder • asistente del líder • miembro muy activo • miembro moderadamente activo • miembro relativamente inactivo • miembro con actividad nula
66
CAPiTULO 3
EQUIPOS DE PROYECTO Y RELACIONES ORGANIZACIONALES
FIGURA 3.3 Medias agregadas pa ra med i r las preguntas en el grupo con a rmon ía
ti.UU
5.80
·2 o ..Ee: ...o
5.60 5.40 5.20 5 .00 4.80 &. 4.60 2 Cl 4.40 4.20 4.00
•'
;
;
'
'
....
'
J.<-"' .,/"""
' '
+:..,
;
,
JI'--
; ;
-...............
.
'~
~
1 1
J
;
--
;
1
J
;
1
1
2
3
4
5
6
7
Semana
-+- Equipos de alto rendi m iento (bajo costo) - • -Equipos de bajo rend imiento (alto costo)
cativamente menor e n los equipos de alto rendimiento, a medida que su cohesión mejoró de manera más o menos constante du rante e l proyecto. Al final no hubo diferencia significativa, respecto a armonía y cohesión entre los grupos de alto y bajo rendimiento. Este patrón fue consiste nte en las otras preguntas acerca de efectividad en la toma de decisiones y grado de contribución individual, es decir, los equipos de alto rendim iento empezaron con ciena baja confia nza en sí mismos, pero mejoraron rápidame nte durante e l proyecto. Por otro lado, es interesante notar que los equipos de bajo rendimiento no parecieron perder mucha cohesión o camaradería, a pesar de recibir reportes informales durante el proyecto de un posible rendimiento in ferior al promedio. El estudio de Brown er al. es imponante porq ue estos investigadores pudieron dar seguimiento y medir la armonía y efecti vidad del grupo durante toda la vida de un proyecto (aunque fuera una simul ación). Es claro que si los resultados sólo se hubieran medido al fin al del proyecto, se hubiera llegado a conclusiones diferentes. Es interesante comparar los resultados de Brown con los de Keller ( 1986), quie n estudió 32 eq uipos de proyecto de la división de I&D de una importante corporación estadounidense. Los proyectos fueron evaluad6s por un panel de 7 administradores con base e n cuatro c riterios: calidad técnica, desempeño de presupuesto y costo, c umplimiento de la programación asignada y val or para la compañía. Para evaluar las características internas de los equipos se usaron cuestionarios. Las características evaluadas incluyeron cohesión del grupo, satisfacción con el trabaj o, autoestima, orientación innovadora, calidad del laboratorio y equipo técnico, influencia del adm inistrador del proyecto e n asuntos administrati vos, influe ncia de los fu ncionarios e n los aspectos técnicos del proyecto y distancia física e ntre los miembros del equipo. Ke ller encontró que la cohesión de l grupo tenía una fuerte correlación positiva con los cuatro criterios evaluados; la distancia física, la satisfacción con el trabaj o y la orientación innovadora tuvieron una correlación positi va por lo menos con uno de los criterios de desempeño. Keller no observó una relación significativa entre desempeño del proyecto y el tamaño del grupo, e l tipo de contratación de sus mie mbros o la naturaleza de la influencia administrativa y técnica. Debe observarse que Keller estudió estos equipos de proyecto dos veces; el primer estudio representó un panorama aleatorio de proyectos en una organización de I&D de alta tecnología, y e l segundo estudi o se realizó un a ño después. Dado que, durante el primer estudio de Ke ller, los proyectos se encontraban e n di ferentes etapas de sus respectivos ciclos de vida, puede ser que las observacio nes de Keller y las conclusiones de Brown et al. no sean contradic torias, en especial dadas las observaciones de Brown de que la cohesión del grupo mejora rápidamente después del inicio del proyecto. De hecho, Keller señala que es posible que "la relación e ntre cohesión y desempeño pueda tener una causalidad inversa, es decir, que un desempeño alto produzca una mayor cohesión" ( Keller, 1986). Por lo tanto, los equipos de alto rendimiento e n el estudio de Keller pueden haber empezado también con medidas baj as de cohesión y armonía del grupo.
PAPEL Y RESPONSABILIDADES DEL ADMINISTRADOR DE PROYECTOS Y EL EQU IPO DEL PROYECTO
67
En resumen, es razonable concluir que cierto grado de equilibrio entre la cohesión y la ho Lilidad del grupo es deseable. Es evidente que demasiado conflicto reduce una comunicación efectiva ) entorpece la capacidad de los miembros del equipo para trabajar juntos. Por otro lado, miembros del equipo con larga antigüedad en la compañía y una cohesión alta tienden a evitar plantearse unos a otros las pregun~ difíciles necesarias para mantener el proyecto en el camino correcto. Un admini trador de proyectos eficiente debe equilibrar estas dos alternativas y asegurarse de que su equipo permanezca armonioso y eficiente.
Características de un equipo de proyecto efectivo Un equipo de proyecto efectivo es más que un grupo de individuos con una meta común. Como en los equipos de baloncesto o en las bandas de jazz, algunos grupos son más efectivos que otros. aun cuando los miembros de un equipo tengan menores habilidades que los de otro. Coordinación, trabajo intensivo, motivación y habilidad para permanecer centrados en las metas importantes pueden ser las cualidades más valiosas de un equipo. Esto también es cierto para equipos de proyectos. Es interesante hacer notar que Keller no observó una relación significante entre el tamaño del grupo y el desempeño en el proyecto. Otros (como Hughes, 1986) han observado que ningún equi po falla por tener muy pocos miembros, pero muchos fallan por tener demasiados miembros. La famosa ley de Brook ( 1974) dice que "agregar personal a un proyecto de software retrasado lo retrasa aún más". ¿Cuál es el tamaño adecuado de un equipo de proyecto? Al considerar el tamaño del equipo de proyecto es útil observar la complejidad interpersonal que aumenta a medida que el número de miembros del equipo aumenta. Por ejemplo, suponga que el número de vínculos interpersonales sea una medida sustituta para la complejidad administrati va de un proyecto; es decir, la comunicación y la coordinación de un proyecto está directamente relacionado con el número de vínculos existentes entre los miembros de un equipo de proyecto. Si en un equipo de proyecto hay dos personas, se tiene un vínculo, como se indica en la figura 3.4. Si hay tres personas, existen tres vínculos. En general, el número de vínculos interpersonales en un equipo de M personas será el número de combinaciones de M personas tomadas de dos en dos o MC2 =0.5M(M - l ). (Si M= 3, entonces 3C2 =0.5(3)(2) =3, como se indica en la figura 3.4.) En general, el número de vínculos interpersonales aumenta en función del cuadrado del número de personas en el equipo, como se ve en Ta figura 3.5. Si la complejidad de la comunicación está relacionada con el número de vínculos interpersonales, no es de sorprender, como lo han notado muchos observadores, que sea más difícil administrar los proyectos conforme aumenta el tamaño del equipo del proyecto.
!¡GURA 3 .4 del equipo de =-oyecto y vínculos --:rperso n ales
-~:TJ año
Equipo de dos personas= 1 vínculo interpersonal
Equipo de tres personas= 3 vínculos interpersonales
68
CAPÍTULO 3
EQUIPOS DE PROYECTO Y RELACIONES ORGANIZACIONALES
FIGURA 3 .5 Número de vínculos i nterpersonales en función del tamaño del equipo
"'G>
'i e:
o
~
G>
e-
--~o., "'5 u e:
'> C> '1:1
e Q)
E
•:S
z
500 450 400 350 300 250 200 150 100 50
•
~
/
'
Á
_.,...
~
!
~
¡ t ¡
~ ~ ~
o 3
5
7
9
11
13
15
17
19
21
23
27
29
Número de miembros del equipo
Este sencillo análisis ilustra los trueques entre la complejidad de la comunicación dentro del equipo y el tamaño del equipo. Un argumento similar es válido respecto a comunicación y coordinación entre el equipo y los otros interesados, tanto internos como externos a la organización. Esto se estudia en el capítulo 5, donde se analizan los trueques tiempo-costo y se introducen los costos de coordinación que varían en función del número de vínculos interpersonales.
Diversidad en los equipos de proyecto Un equipo de proyecto multifuncional reúne a muchos individuos con diversas habilidades, antecedentes y filosofías. Con frecuencia tiene miembros tanto internos como externos a la organización (por ejemplo, los clientes y proveedores pueden estar también representados en el equipo de proyecto). Dada la creciente complejidad técnica actual, es cada vez más importante que un equipo de proyecto incluya indi viduos con diferentes conocimientos y antecedentes. El reto para el equipo es establecer una identidad como una sola unidad, desarrollar una sinergia de grupo que permita un desempeño de un nivel superior a la suma de sus partes. Quedan dos preguntas. Primero, ¿cómo miden los administradores la diversidad al formar los equipos de proyecto? Por lo común, la diversidad se mide con métricas obvias como antecedentes de educación y experiencia profesional, pero ¿hay otras -tal vez mejores- maneras de evaluar la diversidad? Segundo, ¿cuánta diversidad es deseable? Es decir, ¿puede un equipo ser tan diverso que se convierta en disfuncional? Respecto a la primera pregunta, los administradores de proyectos suelen evaluar a los individuos con base en su experiencia, educación, habilidades y antecedentes profesionales. Sin embargo, las personas pueden medirse según otras muchas métricas que incluyen tipo de personalidad, temperamento, antecedentes sociales, género, antecedentes culturales, etcétera. Según muchos observadores (Smith, 2000), la diversidad es un a parte importante de equipos de proyecto efectivos; es más probable que Jos equipos muy diversos hagan contribuciones importantes y que operen con mayor efectividad. La idea de los tipos de personalidad se hizo popular en Jos años 50 con el desarrollo del Indicador de Tipo Myers-Briggs, un mecanismo de evaluación para clasificar a los individuos en 16 tipos de personalidad. Estos tipos de personalidad se basan en cuatro características opuestas: •
Extraversión vs. introversión
• •
Intuición vs. sensación Pensamiento vs. sentimientos
•
Juzgar vs. percibir
Al medir y mezclar los tipos de personalidad en los equipos de un proyecto, los administradores pueden estimular a las personas a usar ambos lados de su cerebro, haciéndolos -y también al
PAPEL Y RESPONSABILIDADES DEL ADMINISTRADOR DE PROYECTOS Y El EQUIPO DEL PROYECTO
69
equipo- más efectivos. Una buena descripción de esras características, el instrumento de evaluación Myers-Briggs, y de los 16 grupos de personalidades se puede encontrar en Keirsey y Bates (1984). A medida que el equipo se hace más diverso. puede ser más difíci l dirigirlo (una razón de la popularidad de los ejercicios de formación de equipos es que promueven la interacción y la interdepende~ a entre sus miembros). Sin embargo. persiste la pregunta de si la diversidad puede ser demasiada; es decir, ¿puede un eq uipo hacerse tan diverso que se convierta en disfuncional? Para probar esta hipótesis Klein y Klastori n ( 1999) estudiaron 188 jurados de casos criminales en California durante siete meses. Los autores exarnmaron si estos j urados eran capaces de llegar a un veredicto (es decir, si se estancaban) como una función de la diversidad del j urado. (No se intentó probar la calidad de las decisiones hechas por jurados que llegaban a un veredicto.) De los 188 casos crinünales examinados, en 146 se llegó a un veredicto (22.3% de los casos tu vieron jurados estancados). Haciendo ajustes según el sexo y categoría étnica del acusado, los autores no encontraron una relación significativa entre la diversidad en el sexo y la posibilidad del jurado de llegar a un veredicto. Sin embargo, sí encontraron una relación positiva significativa entre la composición étnica del jurado y la posibilidad de llegar a un veredicto; con base en la regresión de minimos cuadrados normal, los autores estiman que sólo en ocho casos no se hubiera llegado a un veredicto si el jurado hubiera estado compuesto por un solo grupo étnico (con el ajuste según el grupo étnico del acusado). ¿Qué implicaciones tiene este estudio para los equipos de proyecto? Aunque un jurado es un tipo de equipo de proyecto, es único en muchos aspectos: 1) cualquier miembro del jurado (por lo menos en casos criminales) puede ocasionar que no se logre un veredicto, 2) los miembros pueden no tener objetivos comunes y 3) los miembros del jurado saben muy poco o nada unos de otros. Hay que destacar que este estudio considera la capacidad para llegar a un veredicto (decisión) y no considera la caJjdad de la decisión (otros estudios han indicado que aumentar la diversidad en el grupo produce mejores decisiones). De cualquier modo, el estudio sugiere que en algunas situaciones aumentar la diversidad puede hacer más rufícil que un grupo llegue a una decisión. Es claro que la autoridad del administrador del proyecto y los incentivos dados al equipo de proyecto tienen una gran influencia en la habilidad del equipo para llegar a un consenso. De cualquier manera, para equilibrar la eficiencia y la efectividad del equipo, el admjnistrador del proyecto debe tener en mente estos trueques al determinar la composición. del equipo.
Equipos de proyecto e inc ent ivos Los incentivos tanto directos como indirectos pueden afectar de manera significativa el desempeño de un equipo de proyecto. Sin embargo, existen numerosas preguntas y trueques que se deben considerar. Por ejemplo, ¿se deben dar incentivos individuales por realizar tareas específicas o se deben dar a todo el equipo incentivos por cumplir con los eventos importantes dentro del proyecto? ¿Pueden los incentivos de un proyecto ser perjudiciales para la organización como un todo? (¿por ejemplo, Jos incentivos orientados a proyectos pueden complicar la suspensión de un proyecto que parece fracasar?). ¿Cómo deben estructurarse los incentivos (debe premiarse al equipo del proyecto por terminar un proyecto de software a tiempo y dentro del presupuesto, aunque el producto no tenga éxi to en el mercado)? ¿Cómo deben modificarse Jos incentivos si el alcance del proyecto varía o si la programación del proyecto se comprime? Los incentivos del proyecto proporcionan también un medio para asignar prioridades a los proyectos. Como se analiza en el capítulo lO, las prioridades en Jos proyectos suelen dar como resultado una reducción en la duración esperada o tiempo de realización del proyecto en la mayoría de los entornos de proyectos múltiples. Para obtener más información sobre incentivos, objetivos y motivación, consulte Klein (1991 ), Locke y Lalhan (1990), Mitchel y Silver (1990) y Rigg (1992).
70
CAPÍTULO 3
EQUIPOS DE PROYECTO Y RELACIONES ORGANIZACIONALES
Formación de equipos de proyecto IngeQfrÍa concurrente es un concepto que ha atraído la atención en los últimos años; se refiere a un esfuerzo para reducir el tiempo de desarrollo de un producto basado en el uso de equipos multifun cionales que pueden anticipar -y resolver- problemas difíci les que pueden ocurrir durante el ciclo de vida del producto (como problemas relacionados con la fabricación, capacidad de servicio, mercadotecnia, reciclaje). La clave de la ingeniería concurrente es contar con un equipo de proyecto que refleje todos los aspectos de las características del producto así como de sus procesos de fabricación, la base de clientes y el ciclo de vida. Muchos productos, entre ellos el Ford Taurus, fueron diseñados usando un enfoque de ingeniería concurrente basada en el equipo (Belson, 1994). Como se indicó, se asocian costos significativos a los equipos del proyecto; cuanto mayor sea el equipo, mayores serán los costos de coordinación y comunicación, lo mismo que los costos de mano de obra directa. Sin embargo, menos miembros en el equipo puede dar como resultado que algunas funciones no estén bien representadas en el equipo y ocasionar un proceso de diseño más largo o inadecuado. Para formar equipos en los que se equilibren los trueques entre composición del equipo y características de sus miembros, varios investigadores han sugerido enfoques analíticos (Zakarian y Kusiak, 1999). Para ilustrar uno de estos enfoques analíticos, considere el siguiente ejemplo. Una compañía quiere producir un nuevo tipo de asistente digital personal inalámbrico (PDA, personal digital assistallf) que le permita al usuario tener acceso al correo electrónico e Internet así como disponer de sus citas, directorio, etcétera. Dadas las características de este producto (que se supone se basan en estudios de mercado), el equipo de proyecto que diseña este producto debe tener miembros con conocimiento de tecnología inalámbrica, programación, sistemas operativos para PDA, tecnología de pantallas de cristal líquido (LCD, liquid crystal display), reconocimiento de imágenes y suministro de energía, entre otros. Dados los miembros posibles para el equipo de proyecto, se puede emplear una matriz para identificar a los posibles miembros y sus habilidades asociadas, como se muestra en la figura 3.6 Los coeficientes aij denotan si el i-ésimo miembro potencial del equipo tiene conocimientos sobre la característicaj del producto; es decir O··
-{1
'1 -
si la persona i está calificada para trabajar en la característicaj O de otra manera
Con esto se puede formular un modelo de programación entera para minimizar el número de personas en el equipo como sigue: N
Minimizar
¿x¡ i=l
sujeta a: N
L:aij X¡~ 1 para todo j E J i=l X¡=
FIGURA 3 .6 Ejempl o de conocimientos de los miembros posibles del equipo de proyecto
Jan e Tecnología inalámbrica Lenguajes de programación Sistemas operativos para PDA Tecnología de pantalla (LCD) Reconocimiento de imágenes Suministro de energía
(Ü, l) M oe
X
Larry
Barb
Curly
X
X X X
X X X
X
PAPEL Y RESPONSABILIDADES DEL ADMINISTRADOR DE PROYECTOS Y EL EQUIPO DEL PROYECTO
71
donde X· 1
= {1 si la persona i se elige para el equipo
O de otra manera
y J es el conjunto de índices de las características del producto. Las restricciones en este problema garantizan que por lo meno habrá una persona en el equipo que tenga conocimientos relacionados con cada una de las características del producto. Este tipo de programación entera se conoce como problema para cubrir un conjunto; se ha usado en una gran variedad de problemas, como determinar la ubicación de instalaciones de emergencia, programar el personal en tumos y diseñar exámenes.* Este ejemplo puede formularse como un modelo en hoja de cálculo y resolverse usando la función Solver de MS-Excel; la figura 3.7 presenta el modelo y la solución de este ejemplo. Como se indica, el menor equipo posible que puede proporcionar conocimientos en todas las áreas necesarias co nsta de cuatro personas: Jane, Moe, Barb y Curly. Este modelo se puede extender de varias maneras. Por ejemplo, se pueden formar varios equipos de proyecto al mismo tiempo, se pueden agregar ponderaciones (w;) a la fu nción objetivo, para representar el costo o prioridad de cada miembro potencial del equipo, o se pueden considerar grupos homogéneos de miembros potenciales en Jugar de individuos específicos. Zakarian y Kusiak ( 1999) describen un método más general que considera aspectos tanto tangibles como intangibles al formar equipos multifuncionales e ilustra su metodología para el caso de un proyecto de desarrollo de un nuevo automóvil.
='GURA 3 .7 -- '"lodel o de cu bri - ';110 de conju nto para ar un equipo de pro-
Sel h<9<1Cell: ISG$16
Equel To: Q l10x • MtA By Cbotiog Cello:
~ Q Y•lue ~~·
ulS~BS~1~6:~SF~$~16~_________JI~ Sulj~ctlatl>e
U Solve
1
IL=:J ~ 1 ~ess 1
Custrolota:
$8$16 $f$16 • biMty
$G$10:$G$15 · - 1
* Para obtener más infom1ación acerca de problemas de cubrimiento de conjuntos consuh.: W. Win,ton. Operalious Research: Applicarions a11d A lgorilhms. Boston, Mass: PWS-Kent Publishing Company. 1991.
72
CAPITULO 3
EQUIPOS DE PROYECTO Y RELACIONES ORGANIZACIONALES
Programación extrema Progrfn ac ión extrema (conocida como XP, extreme programming) es una aplicación de equipos de proyecto estrechamente integrados a proyectos de tecnología de la información (TI). El equipo del proyecto define y redefine el alcance de l proyecto mientras trabaja en las tareas de codificación en pequeños incrementos. La programación extrema se caracteriza por una intensa colaboración, pruebas extensas y comunicación continua. Como la comunicación entre los miembros del equipo es más difícil conforme aumenta el número de sus miembros, la programación extrema funciona mejor con equipos medianos o pequeños. Parte de la programación extrema es la "programación en pareja" en la que dos personas escriben juntas una sección del código en una sola terminal de trabajo. Tener dos personas escribiendo juntas una sección del código mejora la calidad del código y lo hace más comprensible para otros miembros del equipo y programadores futuros que tal vez deban modificarlo. El cliente es generalmente parte integral del equipo de proyecto. A medida que se completa el código, se entrega al cliente, quien lo evalúa y prueba. Una vez que el código ha alcanzado cierto nivel de funcionalidad, el cliente empieza la implementación, que ocurre de manera simultánea con el desarrollo y la prueba final del código.
ESTRUCTURA ORGANIZACIONAL V ADMINISTRACIÓN DE PROYECTOS Muchos investigadores han considerado la relación entre la estructu ra de una organización y el impacto de la misma en los resultados de un proyecto, especialmente en el caso de proyectos de r&D más complejos y arriesgados (Allen, 1986; Katz y Allen, 1985; M ight y Fischer, 1985; Larson y Gobeli, 1989; Ross y Staw, 1993). Para analizar esta relación es necesario definir primero cómo se relacionan las estructu ras organizacionales con la administración de proyecws. Como lo definieron Might y Fischer ( 1985), los distintos tipos de estructuras organizacionales se pueden ver como un continuo que va desde una organi zación funcional (donde los administradores funcionales tienen casi toda o toda la autoridad) hasta organizaciones por proyecto (en las que los administradores de proyectos tienen la mayor parte de la autoridad). La figura 3.8 muestra este continuo de estructuras organizacionales. Gran parte del continuo de la figura 3.8 define algú n tipo de organización matricial. Una organi zación matricial es una organi zación con dos (o más) líneas de autoridad o de influencia que compiten, en este caso los administradores funcionales o funcionarios (contabi lidad, ingeniería, etcétera) y los administradores de proyecto. El grado relativo de autoridad dado a cada tipo de administrador define la ubicación de la organización en el continuo de la figura 3.8. Por ejemplo, considere una escuela de administración como una organizació n matricial como se muestra en la figura 3.9. Los jefes de departamento (por decir, el jefe del departamento FIGURA 3 .8 Continuo de la estructura organizacional
Matriz funcional
1Matriz de proyecto 1
~
Organización funcional
1Matriz balanceada ~
1
1
1
- -- - - -- - Continuo Proyecto administrado totalmente por administradores funcionales
Organización de equipo de proyecto
-------~
Proyecto administrado totalmente por el adm inistrador del equipo de proyecto
ESTRUCTURA ORGANIZACIONAL Y ADMINISTRACIÓN DE PROYECTOS
FIGURA 3.9 U na escue la de adm i nis· rrac ión como una organi zación m at ricial
73
Decano • Decano asociado del programa de licenciatura
Decano asociado del programa de maestría en administración
Decano asociado del programa de doctorado
Departamento de mercadotecnia
Curly
Bob
Barby
Departamento de finanzas
Moe
Gloria
Leslie
Departamento de contaduría
de contaduría, el jefe del departamento de finanzas, etcétera) son los administradores funcionales, mientras que Jos decanos asociados sirve n como administradores de proyecto (progra ma). El hecho de que los jefes de departame nto o los decanos asociados tengan autoridad sobre aspectos como contratación, promoción, asignación de materias, diseño de programas, etcéte ra, determina el tipo preciso de organización matricial. Larson y Gobeli (1 989) definieron cinco tipos de organizaciones matriciales existentes a Jo largo del continuo de la figura 3 .8. Entre una organización funcional (donde los administradores funcionales tienen toda la autoridad y Jos administradores de proyectos sirven sólo para coordinar, comunicar y persuadir) y una organización de equipo de proyecto (organizada por proyectos y no tiene depanamentos funcionales) se e ncuentran las organizaciones de matri z funcional, matriz balanceada y matriz de proyecto. Estas tres organizaciones matriciales están definidas como sigue:
•
Matriz funcional. El administrador de proyectos no tiene autoridad directa sobre la distribución de recursos; el administrador funcional dirige el diseño y el trabajo dentro de su depanamento.
•
Matriz balanceada. Los administradores funcional y de proyecto tienen la misma autoridad sobre las decisiones de diseño y asignación de recursos.
•
Matriz de proyecto. Los administradores de proye{:tO tienen la autoridad directa sobre asuntos de asignación de recursos y diseño; los administradores funcionales proporcionan consejo y asesoría.
El problema del tipo de organización es un problema complejo con trueques o intercambios difíciles. Por un lado, los depaname ntos funcionales son la manera más eficiente de mantener a los téc nicos e n contacto con sus respectivas bases de conocimientos (Aile n, 1986). A medida que la tecnología continúa su rápido avance, es crucial para los técnicos no sólo permanecer actualizados en cuanto a nuevos desarrollos, sino también mantener su apoyo dentro de la disciplina. Por otro lado, como se ve en la figura 3.8, la coordinación dentro del proyecto se faci lita con las estructuras organizacionales que se enc uentra n a la derecha del continuo, ya que mejoran la comunicación dentro del proyecto y reducen las barre ras entre disciplinas.
74
CAPITULO 3
EQUIPOS DE PROYECTOY RELACIONES ORGANIZACIONALES
Como observa Allen, la elección de la estructura organizacional deberá depender también de la magnitud de las tareas asignadas a los empleados dentro del proyecto. Por ejemplo, si los papeles d~os empleados en uno de los proyectos son relativamente pequeños (y por ello participan ec muchos proyectos), casi siempre es poco efectivo dar a los administradores de proyectos mucha autoridad sobre los empleados (¿quié n establece las prioridades en este caso?). Algo similar ocurre cuando los empleados están asignados a proyectos dura nte periodos relativamente cortos. Sin embargo, cuando los proyectos están programados para periodos relativamente largos, puede ser adecuado que la organización se desplace en el continuo de la figura 3.9 en dirección de la estructura por equipo de proyecto. En cualquier caso, los administradores deberán recordar la advertencia de Allen ( 1986): En un proyecto largo, los ingenieros se concentran mucho en el problema inherente a ese proyecto y llegan a conocer muy bien la aplicación de su tecnología a esos problemas. Pero dado que se e nc uentran organi zacionalmente separados de otros colegas de su especialidad, pierden contacto con otros desarrollos de su especialidad. Los trueques entre los distintos tipos organizacionales reflejan el equilibrio entre excelencia técnica y desempeño del proyecto. Por lo general, los administradores funcionales se preocupa& por el rendimiento y diseño del producto; los administradores de proyectos se preocupan más por el costo y la programación del proyecto. Esta diferencia puede dar como resultado conflictos y proble mas, que van desde defectos de calidad en el producto (para satisfacer las metas de costo y programación) hasta productos prometidos (los llamados vaporware o software evaporado en la industria de desarrollo de software) que no pueden entregarse (como resultado de tener administradores de proyectos que no comprenden bien la tecnología). Dada la complejidad de estas alternativas, no sorprende que la organización matricial haya tenido fuertes proponentes y oponentes, surgidos en la década de los 60 y que se hicieron populares en los 70. Al principio de los años 80, Texas lnstruments abandonó la organjzación matricial citándola como una de las razones clave de la declinación económica de la empresa (Business Week, 1982). De manera análoga, Xerox Corporation abandonó la fom1a matricial en los 80 argumentando que con tituía un freno para el desarrollo de nuevos productos (Business Week , 1984). Finalmente Peters y Waterman (1982) l}firmaron que la organización matricial es una estructura que no funciona que "... degenera en una anarquía y pronto se convierte en burocrática y no creativa." Peters y Waterman informan que, de las cien "excelentes" empresas que estudiaron, sesenta y una no usan o han reportado malas experiencias con una estructura matricial de la organización. Por otro lado, Stuckenbruck eral. ( 198 1) presentan varios casos de estudio de un banco y dos e mpresas de servicio público e n los que el uso de admjnistración de proyectos y una estructura matricial dieron resultados exitosos (aunque los resultados pudieron ser menos exitosos como observan los autores). Los autores identificaron varios problemas que surgen como resultado de la implantación de una organización matricial; estos problemas incluyen: • •
Conflicto entre algunos administradores (funcionales) medios y el personal del proyecto Dificultades para definir líneas de autoridad (el problema de "dos jefes")
• •
Problemas para elegir los administradores de proyecto Problemas para definir la carrera profesional del administrador de proyectos
•
Tensión entre el personal funcional y del proyecto sobre la elección de la AP y las herramientas de control adecuadas
Algunos otros estudios han comparado el desempeño del proyecto y la estructura organizacional. Katz y Allen ( 1985) estudiaron 86 equipos de proyecto de I&D de nueve organi zaciones grandes de Estados Unidos, que incluían laboratorios y empresas no lucrativas de gobierno, as í como compañias de las industrias electrónica, de procesamie nto de al imentos y aeroespacial. Los investigadores proporcionaron cuestio narios a los individuos de estas organizaciones, en los que hacían
ESTRUCTURA ORGMIZACIONAL Y ADMINISTRACIÓN DE PROYECTOS
75
preguntas acerca de la influencia relativa de los administradores fu ncionales comparados con los administradores de proyectos en las áreas de 1) djseño técnico, 2) aumentos de salario y ascensos. 3) pro_¡sos de asignación del trabajo y 4) conducta general de la organización. En cada organización, los investigadores evaluaron el desempeño del proyecto entrevistando cuatro o cinco administradores, que se encontraban en un nivel superior al ni\el del proyecto, para determinar cómo percibían el desempeño del equipo de proyecto. Katz y Waterman informan que quienes controlaban los aspectos técnico del proyecto no influían en el desempeño del proyecto. Sin embargo, el control obre los salarios y los ascensos sí tenía un impacto significativo sobre el desempeño del proyecto. En este caso. el desempeño del proyecto estaba directamente relacionado con el impacto de los administradores de proyectos: si los administradores funcionales tenían más control sobre salarios y ascensos, el desempeño del proyecto era mucho menor. Además, el control sobre la asignación del trabajo no pareció estar relacionado con el desempeño; sin embargo, se encontró un mayor desempeño del proyecto cuando los administradores de proyecto tenían más influencia en la organización que los administradores funcionales. Might y Fischer ( 1985) estudiaron a los administradores de 103 proyectos de desarrollo en 30 organizaciones, empleando las seis medidas del éJÚto de un proyecto definidas en el capítulo l. Utilizando datos obtenidos de cuestionarios, compararon las respuestas respecto a los tipos de estructuras organizacionales indicados en la figu ra 3.8. (Una organización matricial se definió como una organización en la que el admjnistrador de proyectos es la autoridad en el proyecto. pero los administradores funcionales conservan la autoridad administrativa.) Los resultados de Might y Fischer apoyan los hallazgos anteriores de que existe una relación significativa (aunque pequeña) entre el diseño organizacional y los resultados del proyecto. En particular, ellos reportan una correlación positiva entre algunos tipos de organización matricial y la medida global de éxito del proyecto, así como del desempeño en costos. Es interesante observar que estos investigadores encontraron que el uso de la organización matricial no estaba relacionado con el desempeño respecto a la programación establecida o con el desempeño técnico. De hecho, informan que el éxito técnico no parece relacionarse de manera alguna con la estructura organizacional.. Un estudio similar fue reahzado por Larson y Gobeli ( 1989), quienes obtuvieron datos de proyectos de desarrollo enviando cuestionarios a 855 mjembros del Proyect Management Institute (PMI) elegidos de manera..aleatoria. Entre las 547 personas que respondieron (un porcentaje de respuestas de 64%) se encontraban administradores de proyecto o directores de programas de administración de proyectos (30% ), administradores de alto nivel ( 16% ), administradores funcionales (26%) y especialistas trabajando en proyectos (18%). Las personas que respondieron trabajaban en una sección cruzada de industrias (farmacéutica, aeroespacial, computación y procesamiento de datos) que representaba las cinco estructuras organizacionales indicadas en la figura 3.8 (de quienes respondieron, 13% indicaron trabajar en una organización funcional, 26% en una de matriz funcional, 16.5% en una de matriz balanceada, 28.5% en una de matri z por proyecto y 16% en una organización de equipo de proyecto). El estudio de Larson y Gobeli pedía a los entrevistados que respondieran una serie de preguntas relacionadas con "un proyecto de desarrollo reciente, que les fuera familiar". A cada uno se le pidió evaluar su proyecto como "sin éxito", "marginal" o "exitoso" de acuerdo con cuatro criterios: control de costos, programación, desempeño técnico y resultados globales. Además, los investigadores reunieron información sobre posibles factores de confusión que se sabe tienen influencia en el éxito de un proyecto: complejidad del proyecto, grado de claridad con que se definieron los objetivos, si fueron necesarias nuevas tecnologías, prioridad del proyecto dentro de la organización y si se asignaron recursos suficientes. Después se asignaron valores numéricos a las respuestas (valores más altos representaban mayor éJÚto). Para evaluar las respuestas se usó un análisis de varianza, el cual se resume en la figura 3.10; todos los resultados fueron significativos a un nivel de p < 0.0 l. Como se indica, la estructura de matriz por proyecto parece ser la estructura más efectiva para controlar costos, aunque las estructuras de matriz balanceada, matriz por proyecto y equipo de proyecto fueron significativamente mejores que la
76
CAPiTULO 3
EQUIPOS DE PROYECTO Y RELACIONES ORGANIZACIONALES
FIGURA 3.10 Estructura organizacional y datos de desempeño de proyectos ..
Estructura organizacional
N
Control de costos Prom. (DE)•
A Organización funcional B Matriz funcional e Matriz balanceada o Matriz por proyecto E Equipos de proyecto
71 142 90 156 87
1.76 (0.83) 1.91 (0.77) 2.39 (0.73) 2.64 (0.76) 2.22 (0.82)
1.77 (0.83) 2.00 (0.85) 2.15 (0.82) 2.30 (0.79) 2.32 (0.83)
2.30 (0.77) 2.37 (0.73) 2.64 (0.61) 2.67 (0.57) 2.64 (0.61)
1.96 (0.84) 2.21 (0.75) 2.52 (0.61) 2.54 (0.66) 2.52 (0.70)
546
2.12 (0.79)
2.14 (0.83)
2.53 (0.66)
2.38 (0.70)
10.38..
6.94**
7.42**
11.45**
A,B < C,D,E E
A,B< C< D,E
A,B < C,D,E
A,B < C,D,E
Muestra total Estadístico F Resultados de Scheffe
• DE= desviación estandar
Cu mplimiento del programa Prom. (DE)
Desem p eño técnico Prom . (DE)
Result ados globales Prom. (DE)
••estadísticamente significativo para p
~
0.01
organización funcional o que la estructura de matriz funcional para el control de costos (basándose en Jos resultados de Scheffe). Respecto a satisfacer los objetivos de programación de fechas no hubo diferencia significativa entre las estructuras de equipo de proyecto y matiz por proyecto, las cuales parecieron ser mejores que la de matriz balanceada, que a su vez fue mejor que la matriz funcional o la organización funcional. Con respecto al rendimiento técnico y a los resultados generales, las estructuras de matriz balanceada, de matriz por proyecto y de equipo de proyecto tuvieron la misma efectividad y fueron significativamente mejores que la estructura organizacional funcional o de matriz funcional. Larson y Gobeli informan que en su modelo de regresión sólo un factor de confusión fue significativo: objetivos claramente definidos. Además informan que la estructura organizacional, aunque significativa, explica sólo de 5 a 7% de la varianza total en las medidas de desempeño del proyecto. Aunque todos estos estudios tienen serias limitaciones (como el uso de datos de cuestionarios autocontestados, análisis basados en proyectos en marcha, etcétera), se pueden obtener varias conclusiones. Primera, la estructura organizacional parece tener un impacto significativo -aunque pequeño- en el desempeño del proyecto. En general, un diseño organizacional de matriz balanceada o de matriz por proyecto parece más eficiente; estos diseños dan a los administradores de proyectos niveles más altos de autoridad y responsabilidad mientras co nservan las unidades funcionales. Esto no sólo permite a los administradores de proyecto controlar mejor las dimensiones de sus proyectos, sino que también comu nica la importancia del proyecto desde la alta administración a todos los interesados.
SUBCONTRATACIÓN V SOCIEDADES Como parte de la estructuración de un proyecto, los administradores de proyecto pueden especificar que un conjunto de tareas (un subproyecto) se va a subcontratar (outsourcing) con organizaciones externas. Al tomar la decisión de subcontratar parte de (o todo) un proyecto, el administrador debe considerar los trueques. Por ejemplo, s i subcontrata parte de (o todo) un proyecto puede perder la habi lidad para desarrollar capacidades cruciales para innovaciones futuras, reduciendo con esto ventajas competitivas futuras. Por otro lado, puede reducir los costos a corto plazo al no tener que contratar nuevos empleados o al poder asignar a los empleados internos a otros proyectos. Cuando considera la subcontratación, el administrador de proyectos debe responder a las siguientes preguntas: •
¿Qué parte del proyecto se subcontratará?
SUBCONTRATACIÓNY SOCIEDADES
• • • • • • •
77
¿Cómo determinará a quién subcontratar? ¿Usará un sistema de licitación para elegir al '*subcontratista? Si es así, ¿que tipo de sistema de licitación? ¿Cuál es el impacto del número de licitantes sobre el costo esperado del proyecto? ¿Se usará una lista de precalificación? ¿Qué tipo de contrato se usará? ¿Ofrecerá incentivos por terminar antes de la fecha de entrega? ¿Impondrá sanciones por terminar después de la fecha de entrega? ¿Cómo se comunicarán los miembros del equipo del proyecto con los subcontratistas? ¿Cuál es el impacto del riesgo del proyecto en el costo esperado del proyecto?
En la mayoría de los casos se usa una liciración basada en ofenas selladas para determinar el licitante elegido, dada la asimetría de la información disponible para los interesados. En general, el subcontratista desea entregar una ofena suficientemente baja para ganar el concurso, pero suficientemente alta para tener una ganancia justa. El cliente, por otro lado, quiere asegurar la oferta más baja posible, pero que le garantice que el alcance y la calidad del subproyccto cumplirá sus expectativas. Aunque hay muchas variantes, en general se emplean tres tipos básicos de contratos: • • •
Contrato con precio fijo Contrato de costo con beneficios Contrato por unidad
En el contrato con precio fijo el subcontratista presenta una oferta por el subproyecto; si su oferta es aceptada, se espera que complete las tareas por esa cantidad. Si los costos exceden la cantidad (fija) del contrato, el subcontratista es responsable de cualquier diferencia en el costo que exceda la cantidad en la oferta (suponiendo que el alcance del proyecto no cambia). Como el subcontratista asume todo el riesgo en el contrato con precio fijo, el cliente debe esperar que el costo de este subproyecto sea mayor que si lo realiza internamente. Además, como el subcontratista tiene incentivos para reducir los costos (y tal vez la calidad), es imperativo que el cliente cuente con un sistema efectivo de monitoreo y control de calidad. En un contrato de cósto con beneficios el cliente acepta rembolsar al subcontratista todos los costos documentados (auditados) en los que incurra más un porcentaje correspondiente a gas tos generales y ganancia. En este caso el cliente asume la mayor parte del riesgo; si los costos exceden las cantidades presupuestadas, el cliente es responsable de cualquier excedente en costos. Como los costos del proyecto no están garantizados en un contrato de costo con beneficios, el cliente debe contar con un sistema efectivo de monitoreo y control. El contrato con precio fijo y el contrato de costo con beneficios son dos ejemplos extremos de contratos basados en el riesgo o los incentivos. En general, los contratos de incentivo toman la forma: Pago al subcontratista =pago fijo + (1 - B) (costo del proyecto) donde B es el porcentaje del costo del proyecto que el cliente paga al subcontratista; si B = O, se trata de un contrato de costo con beneficios; si B = 1, se tiene un contrato con precio fijo. En una situación de concurso, Samuelson ( 1986) identifica do tipos de contratos: •
Contratos lineales. Cuando el cliente especifica el valor de By el subcontratista concursa sólo por el pago fijo
•
Contrato gestión. Cuando el subcontratista concursa tanto por el pago fijo como por la tasa B de costos compartidos.
Samuelson (1986) analizó estos contratos con suposiciones que generalmente son congruentes con la mayoría de las situaciones de licitación, y mostró que siempre es preferible un comrato de gestión sobre un contrato lineal. en el sentido de que el primero minimiza el costo esperado para el
78
CAPÍTULO 3
EQUIPOS DE PROYECTO Y RELACIONES ORGANIZACIONALES
cliente. También demostró que O < B < 1 en un contrato óptimo (esto es, los contratos con precio ¡¡.o y los contratos de costo con beneficios no son óptimos). Otro tipo de contrato que se usa en ocasiones es un contrato por unidad; aquí el cliente acepta pagar al subcontratista una cantidad negociada por cada un idad o artículo producido (aunque se pueden usar contratos de incentivo para determinar la tarifa por unidad). Los descuentos por cantidad suelen negociarse como parte de este tipo de contratos; es decir, el clie nte paga un precio más bajo por unidad si ordena un número de unidades superior a una cantidad establecida. Existen muchas variaciones de estos temas contractuales. Por ejemplo, con frecuencia los clientes incluyen un incenti vo por terminar un subproyecto antes de la fec ha de e ntrega establecida, o imponen una multa si el proyecto termina después de esa fecha. En otros casos, un contrato de costo con beneficios puede incluir un límite específico sobre los costos totales del subproyecto. Además. las instrucciones de cambio (enmiendas legales al contrato básico) son un componente común en muchos proyectos; lo normal es que el subcontratista está consciente de que el cliente hará cambios después de firmado el contrato. Como las instrucciones de cambio puede n causar alteraciones (y por lo tanto aumento en los costos) en otros proyectos del contratista, las cantidades asociadas con los cambios con frecuencia llevan a litigios. Muchas veces se usa un sistema de licitación para selecionar subcontratistas. Después de especificar un concurso que especifica las tareas que se subcontratarán, el cliente invita a una licitación. En algu nos casos sólo subcontratistas precalificados pueden presentar sus ofertas; los requisitos para precaJificar pueden ir desde un requerimiento minimo de que el contratista está afianzado, hasta una exigencia más severa de que el contratista haya realizado satisfactoriamente trabajos similares en el pasado. El uso de una lista de precalificación también tiene trueques. Por un lado, puede eliminar licitantes no calificados cuya oferta es baja por ganar el contrato; por otro lado, puede desanimar a nuevos contratistas que recién empiezan. Además, algunos han argumentado que las listas de precalificación se han usado para discriminar a mujeres y minorías étnicas. Una vez recibidas las ofertas selladas para el subproyecto, el administrador de proyectos debe decidir a qué subcontratista(s) seleccionar. Aunque e n muchos proyectos públicos se requiere por ley que se seleccione la oferta más baja, esta práctica ha sido criticada por permitir a licitantes si n escrúpulos hacer una oferta demasiado baja para ganar el contrato, y después elevar el precio del proyecto con grandes demandas contra las instrucciones de can1bios. Como alternativa se ha sugerido seleccionar la oferta media o promedio; se han sugerido también otras variantes adoptadas en algunos casos. Dada la asimetría de la información entre el cliente y el subcontratista, no es de extrañar que el diseño del proceso de oferta y selección de subcontratistas sea un "proceso riguroso, difícil y tardado" (Pells, 1993). En muchos sistemas de licitación/concurso se fijan las especificaciones de diseño; entonces, como se indica en la figura 2.4, el subcontratista sólo puede competir con base en el tiempo y el costo. Para permitir que un subcontratista considere tanto el diseño como el costo y la programación, el cliente debe detallar las especificaciones de diseño con claridad de manera que el producto final o el subproyecto tenga el desempeño deseado. Por ejemplo, un cliente puede especificar las características de operación del suministro de energía (voltajes de entrada y de salida, amperes, etcétera), pero dejar al subcontratista el diseño de los circuitos y de los eleme ntos mecánicos del producto. De otra manera, algunos clientes emplean equi pos de construcción de diseño; es decir, identifican primero a los subcontratistas y los incluyen en el equipo de proyecto junto con los clientes y otros interesados para el diseño del producto, proceso o servicio. De este modo, todo el equipo optimi za los trueques entre di seño, programación y costo. Los equipos de construcción de diseño han tenido éxi to en muchas organizaciones privadas y dependencias de gobierno. Al evaluar una licitación, es importante que los administradores consideren todos los costos relevantes asociados con el subproyecto. Si se permite a un subcontratista considerar el di seño como parte del proceso de licitación, entonces la naturaleza de este di seño --que comprende responsabi lidad legal, costos de mante nimiento, costos de operación y a un costos de di stribucióndebe incluirse e n la licitación del subcontratista. Para evaluar este tipo de licitacio nes algunos clien-
SUBCONTRATAOO Y ~
79
Una empresa constructora de barcos dice que la Washington State Ferries violó sus prop1os ~ tos y reglas de licitación al elegir a una compañía de Anacortes para construir dos uasbord.adores _ para pasajeros al precio más alto. "Hemos estado en el negocio de astilleros durante 72 años } hemos tenido nuestras victorias}
tes han empleado un sistema de puntos o algún otro enfoque similar a las metodologías descritas en el capítulo 2. Un aspecto importante de la subcontratación es decidir cómo estructurar las licitaciones, lo que a su vez afectará el número de subcontratistas elegidos. Si bien algunas decisiones de subcontratación son directas (basadas en la especialización funcional), muchas otras son menos claras. Por ejemplo, considere un pequeño proyecto hipotético que consista en cinco tareas sinúlares {A, B, C, D y E}. En este caso, el cliente puede presentar concursos diferentes para cada tarea, o licitaciones separadas para subconjuntos de tareas (por ejemplo licitaciones para los subconjuntos {A, B}, y {C, D, E}) o una sola para las cinco tareas. Cuando se emiten licitaciones separadas para cada tarea, Gutierrez y Paul (1998) llaman a esta estrategia "fraccionar", si se emite una sola licitación para las cinco tareas, la estrategia se llama "agrupar". El cliente debe de considerar los trueques entre fraccionar, agrupar o alguna combinación de las dos estrategias. Si el cliente emplea más subcontratistas, reduce su rie go al repartir el trabajo; en este caso, la falla de un subcontratista es menos desastroso que al usar un solo subcontratista. Por otro lado, se pueden obtener economías de escala al emplear menos subcontratistas. Además los costos de comunicación y coordinación suelen relacionarse con el número de contratistas; cuando este número disnúnuye, la comunicación es más eficiente. También deben considerarse otros factores (como gastos generales y márgenes de ganancia de los contratistas, el costo de evaluar múltiples licitaciones, los flujos de efectivo)*. Gutiérrez y Paul ( 1986) analizan el problema de agrupar contra fraccionar subcontratistas en un proyecto homogéneo con el objetivo primario de minimizar el tiempo esperado de terminación del proyecto y el objetivo secundario de minimizar la varianza del tiempo de terminación del proyecto (esto es, los administradores de proyectos siempre prefieren el escenario que proporcione el menor tiempo esperado de terminación; si los tiempos de ternúnación son iguales, prefieren el escenario con menor varianza). Los autores suponen también que cada contratista presenta una oferta en respuesta a cada licitación y que la probabilidad de que un contratista gane un contrato (es decir, que presente la oferta más baja) es constante en todas las licitaciones. Los autores consi-
* Si hay una sola licitación, un subconuatista está forzado a concursar por tareas para las que puede no estar capacitado: en este caso, es posible que él subconuate estas tareas. Si se emiten licitac iones múltiples. los subconuatistas sólo tendrán que concursar por tareas para las que se sientan capacitados.
80
CAPÍTULO 3
EQUIPOS DE PROYECTO Y RELACIONES ORGANIZACIONALES
deran dos casos: 1) cuando las tareas pueden realizarse de manera simultánea (no existen relaciones • precedencia entre las tareas) y 2) cuando las tareas deber realizarse e n secuencia. Suponiendo que los contratistas realizan todas las tareas asignadas de manera razonablemente similar (es decir, que los contratistas son consistentes en todas las tareas), Gutiérrez y Paul muestran que fraccionar es la mejor estrategia cuando las tareas deben realizarse en secuencia. Con estas suposiciones, la duración esperada del proyecto es la misma para cualquier estrategia; sin embargo. ellos muestran que la estrategia de fraccionar será mejor que las demás, incluyendo las estrategias mixtas, en c uanto a la varianza del tiempo de terminación del proyecto. Por el contrario, estos autores recomiendan agrupar como la mejor estrategia cuando las tareas pueden realizarse simultáneamente. Aunque este es un caso más complicado (en algunas condiciones, la duración esperada del proyecto puede aumentar), en la mayoría de los casos se obtendrá una varianza menor o una menor duración esperada del proyecto. Por ejemplo, cuando un proyecto paralelo puede dividirse en subproyectos idénticos, Gutiérrez y Paul muestran que agrupar siempre minimiza la duración esperada del proyecto. Aunque puede ser difícil aplicar dúectamente estos resultados a proyectos reales, los autores plantean cuestiones importantes en relación con los procesos de licitación y subcontratación, y proporcionan ideas valiosas acerca de la estructura óptima del esquema de licitación finalmente adoptada. Es claro que el asunto de la subcontratación es un elemento difícil y crucial en casi todos los planes de proyectos, y con frecuencia tiene un gran impacto en el éxito o fracaso del proyecto.
Sociedades y alianzas Cada vez más los administradores reconocen que los contratistas son socios en la administración de proyectos complejos. Estas sociedades pueden proporcionar una ventaja competitiva; las organizaciones forman sociedades donde antes operaban en situaciones competitivas. Por ejemplo, considere el modelo "estándar" en el que el cliente emite una licitación y después elige al contratista con la oferta más baja. El cliente y el contratista se encuentran en una situación competitiva; el cliente quiere minimizar sus pagos mientras que el contratista quiere maximizar su ganancia. De manera alternativa, cliente y contratista pueden formar una alianza en beneficio mutuo; ambos pueden participar en la etapa de diseño y planeación del proyecto, así como en la programación y ejecución del proyecto. Estas alianzas pueden considerarse como una estructura organizacional alternativa. Cowan et al. ( 1992) describen numerosos beneficios que se pueden obtener de las sociedades, como ahorros en costos, reducción de los gastos generales del proyecto, mejoras en el diseño por comparti r conocimientos y mayor satisfacción de todos los interesados. Sin embargo, como observan los autores, las alianzas no están exentas de riesgos. Requieren un alto grado de comunicación y coordinación, y puede haber conflictos cuando los administradores tienen que tratar con culturas corporativas diferentes a las suyas. Cuando los tipos de personalidad son compatibles y puede establecerse la confianza, los administradores de proyecto deben considerar con cuidado las a lianzas.
CONCLUSIONES El factor humano en una organización es siempre un aspecto significativo de toda tarea administrati va incluyendo a la administración de proyectos. Cómo se forman los equipos de proyecto, cómo recompensan las organizaciones a los miembros del equipo de proyecto y cuánta importancia da una organización a un proyecto, son todos factores que contribuyen enormemente al éxito o fracaso del proyecto.
PROBLEMAS PARA ESTUDIO 1.
Considere la fom1ación de un equipo de proyecto. ¿Qué características piensa que deben tener los miembros del equipo? ¿Debe el equipo consistir en miembros con capacitación y
REFERENCIAS
~~~~======~ler-~====~~~~~
~::: Á BIEN Q U(. -; .a.;"-JE MEDIO --:::; ~'...--------"
~
!
~
j §
¿ESTARÍA DISPUESTA A VENIR SUS DÍAS LIBRES PARA TERMINAR PROYECTOS URGENTES?
!
i !
"
81
ENTONCES. BÁSICAMENTE NEGOCIASTE UNA REDUCCIÓN DE 50% EN EL SUELDO
antecedentes similares o deben tener distintos conocimjentos y an tecedentes? ¿Cómo debe operar el equipo del proyecto? ¿Quién debe tener la responsabilidad final del desempeño del equipo? 2.
Considere la relación entre un equipo de proyecto y las partes funcionales de una organización. ¿Quién debe ser el responsable de aprobar las tareas específicas? Si una tarea de ingeniería excede la duración y presupuesto propuestos, ¿quién es responsable, el d irector de ingeniería o el admjnistrador del proyecto? En general, ¿cómo cree que una empresa organizada funcionalmente debe manejar los proyectos?
Allco, T.J. "Organiza1ional SUllcture, lnformation Technology, and R&D Producuvuy... IEEE Transactions on Engineering Management EM-33. núm. 4 (noviembre, 1986). Belson, D. ··concurrent Engineering" in Handbook of Design, Manuf acturing. and Awomation. R.D. Dorf y A. Kusiak, eds. Nueva York: John Wiley & Sons, lnc. Bowen, K. K. Clark, C. Holloway, y S. Wheelwright. "Development Projects: Thc Engine o f Renewal'', Harvard Business Review (septiembre-«tubre, 1994): 108-120. Brooks, F. The Mythical Man -Mónth: Essays on Software Engineering. Addison-Wesley, 1995 (edición de aniversario). Brown, K. T. Klastorin, y J. Valluzzi. "Project Management Performance: A Comparison of Team Characteristics", IEEE Transactions on Engineering Management31, núm. 2 (mayo, 1990): 117-125. Business Week. "Cuts at Texas lnstruments" . 11 de octubre, 1982, 42. Business Week. '·How Xerox Speeds Up the Binh of New Products.., 19 de marzo, 1984, 58-59. Cowan, C.. C. Gray, y E. Larson. ''Project Partnering" Project Management Joumal. Vol. XXII, núm. 4 (diciembre, 1992):
5-11. Evan. W.M. "Conflict and Performance in R&D Organizations", Industrial Managemem Review (otoño, 1%5): 37-46. Gutiérrez. G. y A. Paul. "Analysis of the Effects of Uncenainry. Risk-pooling, and Subcontracting Mechanisms on Project Performance", Operations Researr:h 48 ( 1998): 927- 938. Hill. R.E. " lnterpersonal Compatibility and Work Group Performance" . Joumal of Applied Behaviora/ Science 11 , núm. 2 ( 1975): 2 1(}-2 19. Hill, R.E. "Managing lnterpersonal Conflict in Project Teams", S/oan Managemem Rel•iew (invierno. 1977): 45-61. Hughes, M.W. "Why Projects Fail: The Effects of lgnoring the Obvious", Industrial Engineering (abril , 1986): 14-1 8. Katz, R. y T. Alleo. "Project Performance and the Locus of Influence in the R&D Matrix'', Academy of Management Jouma/ 28, núm. 1 (1985): 67-87. Keirsey, D. y M. Bates. Please Understand Me: Character and Temperamem Types. Del Mar, Calif.: Prometheus Nemcsis Book Company, 1984. Keller, R.T. " Predictors of Lhe Performance of Project Groups in R&D Organizarions". Academy of Managemem Joumal 29 (1986): 7 15-726. Klein, J., "A Reexamination of Autonomy in Light of New Manufacturing Practices", Human Relarions 44, núm. 1 (1 991 ): 21 - 38. Klein, K. y T. Klastorin. " Do Di verse Juries Aid or lmpede Justice?" \ViscoiiSin Law Review 1999. núm. 3 ( 1999): 553-569. Larsoo, E. y D. Gobeli. "Significance of Project Management Structure on Development Success". IEEE Transactions on Engineering Managemem 36, núm. 2 (mayo, 1989). Locke, E.. y G. Latham. A Theory of Goal Selling & Task Perfo rmance. Englewood Cli ffs, N .J.: Prentice-Hall, 1990.
82
CAPÍTULO 3
EQUIPOS DE PROYECTO Y RELACIONES ORGANIZACIONALES
Might. R.J . y W.A. Fische r. ..The Role of Structural Rlctors in Detennining Project Management Success", IEEE TrwJSuc/ions 011 Engi11eering Managemem EM-32. núm. 2 (nta)O. 1985). Mitchell, T. y W. Silver. ..Individual and Group Goals When Workers are lnterdependcnt: Effects on Task Strategies and Perfomtance". Joumal ofApplied Psychology 75, núm. 2 ( 1990): 185-193. Pells, D. The AMA Handbook of Projecl Mwzagemem. ueva York: AMACOM. 1993. Peters. T. y R. Watcnnan. In Search of E:ccellence. Nueva York: Harper and Row. 1982. Posner, B... What's All the Fighting About? Conflicts in Project Management". IEEE TrOJJSacrioiiS on Engineeri11g Ma11a¡::emem EM-33. núm. 4 (noviembre, 1986): 207-211. Rigg, M...Performance-Based Pay: Linking Work Objectives To Personal Interesrs··, lndtwriul Engineering 24, nú m. 10 (1992): 26-27. Ross, J. y B. Staw. "Organizational Escalation and Exit: Lessons from the Shoreham Nuclear Power Plant". Academy of Managemem Jouma/36. núm. 4 ( 1993): 701 - 732. Samuclson, W. "Bidding for Contracts.'' Managemem Science 32, núm. 12 ( 1986): 1533-1550. Smith, K. A. Projecr Managemem and Teamwork. Burr Ridge. 111.: McGraw-Hill Companies, Inc .. 2000. Stuckenbruck, L.D., H.B. Einstein, R.L. Day. y J.N. Salapatas. "The lmplementation of Project Management: Three Case Histories·· in Stuckenbruck, L. D. The lmplemenwlion of Projecr Managemem: The Professional's Handbook, 188-221. Reading, Mass.: Addison-Wesley Publishing Company. 1981. Thaimhain, H.J. y D.L. Wilcmon. "Leadership, Confl ict, and Program Management Effectiveness", Sloan Managemenr Review (otoño, 1977): 69-89. Zakarian, A. y A. Kusiak. ''Fonn ing Teams: An Analytical Approach," 1/E TrwJSacrions 3 1 ( 1999): 85-97.
4 REDES DE PRECEDENCIAS Y EL MÉTODO DE lA RUTA CRÍTICA (CPM)
E
n el capítulo 2 se vio cómo usar una eslructura desglosada de lrabajo (EDT) para defi nir tareas o paquetes de trabajo. Estas tareas forman la base del plan del proyecto, que incluye la programación y el presupuesto usados normalmente para establecer las metas iniciales de tiempo y costo. Corno resultado de la EDT se tiene una lista de tareas con nombres que las identifican y una estimación de la duración de la tarea. Debe tenerse en mente que la mayor parte del software para administración de proyectos (AP) requiere una sola estimación de la duración de cada tarea. Es decir, suponen que se conoce la duración exacta de cada tarea sin variación o incertidumbre alguna. Además, el software para AP supone que las tareas son independientes en el sentido de que pueden iniciar de manera autónoma. Una vez defi nido el conjunto de tareas que establece un proyecto, los adrni nislradores de proyectos definen las relaciones de precedencia que existen entre las tareas; es decir, deben identificar qué tareas preceden (o suceden) a olras tareas. Suponiendo que la tarea A debe preceder a la tarea B, se pueden definir cuatro tipos de relaciones de precedencia: •
Terminación a inicio: la tarea B no puede iniciar hasta que la tarea A haya terminado.
•
Inicio a inicio: la tarea B no puede iniciar hasta que la tarea A haya iniciado.
•
Terminación a terminación: la tarea B no puede terminar hasta que la tarea A se haya termi nado.
•
Inicio a terminación: la tarea B no puede terminar hasta que la tarea A haya iniciado.
La mayor parte de los paquetes de software perrillten al usuario especificar el tipo de relación de precedencia; la relación predeterminada en la mayoría de los casos es la relación terminación a inicio. Además, el usuario normalmente puede especificar un retraso entre el inicio/terminación de la tarea A y el inicio/terminación de la tarea B. Por ejemplo, si hay un relraso de dos días en una relación inicio a inicio, el inicio de la tarea B será al menos dos días después del inicio de la tarea A. (Una relación inicio a inicio es úLil en especial cuando los adrni nislradores traslapan las etapas de un proyecto de desarrollo de un nuevo producto. Por ejemplo, un administrador tal vez quiera iniciar la redacción de la documentación de un nuevo producto de tecnología de la infom1ación (TI) aun cuando el diseño detallado y la programación no hayan terminado.) En este capítulo se supondrá que todas las relaciones de precedencia son del tipo tem1inación a inicio; en el apéndice 4B se explorarán con más detalle las relaciones inicio a inicio y terminación a temunación. Una vez definidas las tareas, estimadas las duraciones y especificadas las relaciones de precedencia, esta infom1ación se presenta en un diagrama o red de precedencias. Las redes de precedencias son herramientas visuales útiles para presentar información acerca de un proyecto, que incluye el estado actual del proyecto, el lrabajo restante y las asignaciones de las tareas. Casi todos los productos de software para AP disponibles generan redes de precedencias.
JNICIÓN DE REDES DE PRECEDENCIAS Actualmente se usan dos tipos de redes; el primer tipo emplea nodos para representar las tareas y flechas (arcos) para representar las relaciones de precedencia, rnienlras que el segundo tipo usa fle-
83
84
CAPITULO 4
REDES DE PRECEDENCIAS Y EL MÉTODO DE LA RUTA CRiTICA (CPM )
chas o arcos para representar las tareas y nodos para represemar los eventos. El primer tipo de red de precedencias se conoce como red de actividades en los nodos (AON, activity on node) y es el que usan la mayoría de los paquetes de software. Además, muchos administradores de proyectos encuentran la notación AON más sencilla de explicar y usar, una ventaja definitiva para comuni carse con usuarios no técnicos.
Redes de precedencias de actividades en los nodos (AON) La notación AON se explica mejor mediante un ejemplo. Considere un proyecto en el que hay cuatro tareas: A, B, C y D. Suponga que las tareas A y B pueden iniciar simultáneamente; es decir, su inicio es independiente de cualquier otra tarea. Suponga además que la tarea C no puede iniciar hasta que las tareas A y B terminen, y que la tarea D no puede iniciar hasta que la tarea B esté completa. La figura 4.1 muestra la red AON que representa estas relaciones. En la fig ura 4.1 , cada tarea está representada por un nodo (etiquetados A, B, C y D), mientras que los arcos indican relaciones de precedencia. Observe que se agregaron dos nodos más que representan el inicio. y fin del proyecto. Estas tareas (señaladas en la red mediante un rombo) son dos ind icadores; los indicadores no toman tiempo y no cuestan, pero representan evemos importantes en la vida de un proyecto y se agregan con propósitos de infom1ación y control. Los indicadores INICIO y FIN deben incluirse de manera explícita ya que toda red de precedencias debe iniciar en un solo nodo y terminar en un solo nodo. Además, estas redes no permiten ciclos entre las tareas, donde un ciclo e,:; una ruta que regresa al punto de partida. Por ejemplo, agregar un arco de la tarea C a la tarea A daría un ciclo obvio entre las tareas A y C; los ciclos indican que hay una inconsistencia lógica en las relaciones de precedencia que debe resolverse antes de continuar con la planeación. En general, en una red grande es difícil determinar por inspección s i existe un ciclo. Por ejemplo, agregar un arco de la tarea Da la tarea A en la figura 4.1 no formaría un ciclo ni agregaría inconsistencias (pero sí agregaría arcos redundantes o innecesarios). Todos los paquetes de software para AP pueden determinar si hay un ciclo en la red de precedencias; sin embargo, sólo el administrador del proyecto puede determinar cómo corregir ese ciclo. Además, algunos paquetes de software para AP pueden determinar qué arcos de precedencia son redundantes y se pueden eliminar. (Si se agrega un arco de la tarea D a la tarea A, entonces el arco del INICIO a la tarea A y el arco de la tarea B a la e se vuel ve innecesario y debe eliminarse.) Suponiendo que la red de precedencias no tiene ciclos, siempre existe en todas las redes una o más ruLas del lNICIO al FIN. Este tipo de red se llama red acíclica dirigida y se requiere para los cálculos que forman la base del método de la ruta crítica (CPM).
Redes de precedencias de actividades en los arcos (AOA) El método alternativo para representar redes de precedencias es el método de actividades en los arcos (AOA, activity on are). En este caso Jos arcos de la red representan tareas, mientras que los nodos representan eventos o pu ntos en el tiempo. En una red de AOA, una tarea arbitraria A se representa, por ejemplo, como se muestra en la figura 4.2, donde el nodo i corresponde al inicio de la tarea A y el nodo
FIGURA 4 . 1
Ejemplo de una red de precedencias de AON
FIGURA 4.2 Representación de tareas en una red AOA
DEFINICIÓN DE REDES DE PRECEDENCIAS
85
j es la terminación de la tarea A. Para ilustrar esto con más detalle, suponga que se espera que la tarea A dure ocho días. Si el evento i ocurre en el tiempo 5, entonces el tiempo más próximo en que puede ocurrir el eventoj (que indica la terminación de la tarea A), es el tiempo (5 + 8 ) = 13. En general, las tareas en una red AOA están representadas por sus eventos de inicio y terminación; es decir, la tarea A estará denotada como tarea (i,J). A primera vista la notación AOA es un poco más complicada que la notación AON. En algunos casos se necesita una tarea ficticia en una red AOA para representar con precisión ciertas relaciones de precedencia; una tarea ficticia no cuesta nada y no toma tiempo. Por ejemplo, si hay dos (o más) tareas con los mismos eventos de inicio y terminación, debe emplearse una tarea ficticia para distinguir las dos tareas reales. Para ilustrar esto, considere una segunda tarea B que tiene los mismos eventos de inicio y terminación que la tarea A, como se muestra en la fig ura 4.4. En este caso, se requerirá una tarea ficticia (indicada por una flecha punteada) para representar adecuadamente las tareas A y B en una red AOA, como se ve en la figura 4.4. La tarea A de la figura 4.4 se denotará como tarea (i, j ), la tarea B como tarea (j, k ) y la tarea ficticia como (k, J). Para ilustrar mejor la ·diferencia entre las notaciones AON y AOA, considere el ejemplo de la red de precedencias dado en la figura 4.1. La misma relación de precedencia expresada en una red AOA se muestra en la figura 4.5. Observe que en este caso es necesario introducir una tarea ficticia del nodo 1 al nodo 2, para indicar de manera correcta que las tareas A y B preceden a la tarea C (pero sólo la tarea B precede a la tarea D). En una red de precedencias AOA, el primer evento es siempre el inicio del proyecto, mientras que el último evento es siempre la terminación del proyecto. Como las redes AON, las redes AOA no deben tener ciclos. Además, siempre se trat~ de numerar Jos nodos (eventos) de manera que las tareas vayan de un evento con número menor a un evento con número mayor (por ejemplo, la tarea ficticia inicia en el evento 1 y termina en el evento 2). En tanto que no haya ciclos en una red, esto siempre puede lograrse. Respecto a las tareas ficticias, siempre es mejor eliminar las que son redundantes o innecesarias. En una red AOA, una tarea ficticia es redundante o innecesaria si es la única tarea que empieza o termina en un evento dado (excepto cuando una tarea ficticia se usa para distinguir dos tareas que tienen Jos mismos eventos de inicio y terminación). Por ejemplo, en la figura 4.5, la tarea ficticia no es la única que inicia en el evento 1 o que termina en el evento 2; por lo tanto, esta tarea en el ejemplo no es redundante, pero proporciona una relación de precedencia única y no puede eliminarse sin modificar la estructura de la red.
Comparación de las redes AOA con las redes AO N Tanto las redes AON como las AOA tienen ventajas y desventajas. Como se dijo, es más sencillo explicar las redes AON y los usuarios no técnicos las comprenden con mayor rapidez. Por otro lado, las redes AOA se usaron inicialmente en Jos modelos de PERT y CPM desarrollados en los años
Tarea B
Tarea B
' , Tarea ficticia '
1 1
1
Tarea ficticia Tarea D
FIGU RA 4 .4 Otra representación AOA de las re laciones entre las tareas en la figura 4.3
FIGURA 4 .5
Ej emplo de AOA
86
CAPÍTULO 4
REDES DE PRECEDENCIAS Y EL MÉTODO DE LA RUTA CRíTICA (CPM)
50, de manera que el concepto de red AOA se estableció desde el principio. Además, el modelo PERT que se analiza en el capítulo 6 se basa en el concepto de eventos como se definen en las redes AOA. Las redes AOA tienen también otras ventajas. Es más fácil guardar y transmitir la estructura de una red AOA que la de una red AON. Para una red AOA basta una simple lista de todas las tareas con sus respectivos eventos de inicio y terminación numerados, mientras que para una red AON será necesario dar una lista de las tareas y sus predecesores inmediatos. Por ejemplo, la siguiente lista de tareas especifica de manera única la red AOA de la figura 4.5.
• • •
• •
A: Tarea (INICIO, 2) B: Tarea (INICIO, 1) Tarea ficticia ( 1, 2) Tarea (2, FIN) Tarea ( 1, FIN)
Además, una red AOA se puede dibuj ar empleando arcos cuyas longitudes corresponden a sus duraciones respectivas. Este tipo de apoyo visual puede ser muy útil para dar seguimiento al avance y presupuesto del proyecto. A pesar de las ventajas de las redes AOA, en este libro se usarán redes AON por dos razones importantes. Como se mencionó, los usuarios no técnjcos encuentran más sencillo comprender y describir las redes AON. Más importante aún es que casi todos, si no todos, los programas de software para AP usan redes AON. Entonces, en este libro se usarán redes AON (aunque al final de este capítulo se proporcionan los cálculos de CPM para una red AOA).
MÉTODO DE LA RUTA CRÍTICA (CPM): CONCEPTOS Y CÁLCULOS Como se indicó, una red o diagrama de flechas puede ser una representación conveniente de las relaciones de precedencia entre las tareas de un proyecto. En estas redes AON se supondrá que Jos arcos representan relaciones inicio a term inación; es decir, todas las tareas predecesoras deben haber terminado por completo antes de que pueda iniciar cualquier tarea sucesora. Para ilustrar Jos conceptos básicos del método de la ruta crítica (CPM), considere el ejemplo dado en la figura 4.6 de la red AON de un proyecto, donde los nodos en forma de rombo representan eventos, los nodos en forma de círculo (con una letra o nombre como identificador) representan tareas y los arcos indican las relaciones de precedencia. Observe también que cada tarea (nodo) indica su duración esperada; en este ejemplo, las duraciones esperadas están dadas en meses. Es importante recordar que el cálculo de la ruta crítica supone que estas duraciones son determinísticas (es decir, conocidas y constantes). En el capítulo 6 se explorarán las implicaciones de los tiempos aleatorios para la duración de las tareas. FIGURA 4.6 Red AON con d os rutas
MÉTODO DE LA RUTA CRiTICA (CPM ): CONCEPTOS Y CÁLCULOS
87
En este pequeño ejemplo, es claro que existen dos rutas en la red desde el nodo INICIO hasta el nodo FIN: INICIO-A-B-AN e lNICIO-C-FIN. Dado que para terminar todo el proyecto deben estar terminadas todas las tareas, es claro que se necesitan once meses para completarlo, suponiendo que los eventos INICIO y FIN no requieran tiempo y que la durac ión de las tareas sea justo la indicada. Asf, el tiempo mínimo necesario para terminar un proyecto es igual a la longitud de la ruta más larga a través de la red. Esta ruta se conoce como ruta crítica y se indica con flec has más gruesas. La duración del proyecto, 11 meses, definida por la ruta crítica, se conoce también como el tiempo d e ej ecución del proyecto. El pequeño ejemplo mostrado en la figura 4.6 ilustra también el concepto de tiempo holgura total o tiempo flotante. Como las tareas en la ruta INICIO-A-E-FIN sólo requieren diez meses, para las tareas A y B pueden retrasarse hasta un mes sin demorar el tiempo de ejecución del proyecto. Asf, la holgura asociada con las tareas A y B es un mes (a este tipo de holgura se le conoce como holgura total o flotante total). Debe notarse que esta holgura es una medida dependiente de la ruta; es decir, si la duración de la tarea A aumenta un mes (a ocho meses), la holgura total de la tarea B. así como la holgura total de la tarea A, se reducirá de un mes a cero. El ejemplo de la figura 4.6 también ilustra otros conceptos. De cada tarea y evento, el admi nistrador del programa suele interesarse en conocer el tiempo más próximo en que cada tarea puede iniciar/terminar, así como el tiempo más lejano en el que cada tarea puede iniciar/terminar sin retrasar el tiempo de ejecución del proyecto. Suponiendo que el inicio del proyecto ocurre en el tiempo O, las tareas A y C pueden iniciar en el tiempo O ya que el evento INICIO requiere un tiempo de cero. El tiempo de inicio más próximo para el evento INICIO y el proyecto, denotado por IC!NICIO' es cero. La tarea B puede iniciar tan pronto haya termi nado la tarea A, por lo q ue IC 8 = 7. De la misma manera, la tarea C puede iniciar en el tiempo O, por lo que ICe = O. Por el contrario, las tareas B y e pueden terminar hasta el tiempo 11 (ya que se requieren 11 meses para termi nar todo el proyecto, suponiendo que el evento FIN también requiere un tiempo de 0). Si TLj es el tiempo de term inación más lej ano para alguna tarea j' TL8 = 11 , mientras que TLA = 8; esto indica que la tarea A, que precede a la tarea B, puede termi nar hasta el tiempo 8. Estos cálculos se presentan en la fig ura 4.7. Para ilustrar estos conceptos en una red de proyecto más grande y definir los cálcul os con más formalidad, considere el proyecto de AON de la fig ura 4.8. En él, las duraciones esperadas se dan en semanas; una vez más se espera que estas duraciones sean conocidas y constantes. Como se indicó, los eventos se representan con rombos y siempre tienen duración cero. Los dos eventos INICIO y FIN indican los puntos inicial y fi nal únicos de la red y del proyecto. En este caso, existen cinco rutas de INICIO a FIN en la red. Estas cinco rutas y sus respectivas duraciones (o sea, la suma de las duraciones de las tareas en cada ruta) se dan en la figura 4.9. =GU RA 4 .7 -:>lo d e red AON qu e 'fe los cálculos de
IC8 TL 8
ICe = O T Lc = 11
=7
=11
88
CAPÍTULO 4
REDES DE PRECEDENCIAS Y EL MÉTODO DE LA RUTA CRíTICA ICPM))
FIGURA 4 .8 Ejemplo de CPM basado en una red AON
=35 = 35
La ruta más larga (crítica) a Lravés de la red (y por lo tanto el tiempo mínimo necesario para completar el proyecto) es la ruta 1, que necesita 35 semanas. Las flechas gruesas y los nodos en blanco señalan esta ruta crítica en la figura 4.8. Observe que puede haber más de una ruta crítica e n un proyecto, pero por definición debe haber por lo menos una. Como los proyectos de tamaño real tienen demasiados nodos para enumerar todas las rutas posibles, los creadores del método de la ruta crítica (CPM) desarrollaron una metodología que puede encontrar la ruta más larga en cualquier proyecto, sin importar su tamaño. De hecho, este es un problema relativamente sencillo que se basa en el proceso de programación dinámica. Los cálcul os para el CPM necesitan dos etapas para encontrar la ruta más larga a Lravés de una red de precedencias. En la primera etapa se empieza en el nodo de INICIO y se avanza hacia adelan te por la red, determinando en cada nodo el tiempo más próximo en que la tarea o el evento puede iniciar. En la segunda etapa de los cálculos se empieza en el nodo FIN y se retrocede por red determjnando el tiempo más lejano e n que una tarea o evento puede terminar. En la primera e tapa de Jos cálculos del CPM el adrrurusrrador supone que el evento INICIO comienza en el tiempo cero, aunque éste puede mapearse o hacerse corresponder a un calendario al acabar los cálculos. Después el adm inistrador se mueve de un nodo al nodo sucesivo, preguntándose en cada paso: ¿cuál es el tiempo más próximo e n que esta tarea o evento puede iniciar? En cada nodo el adminisLrador quiere enconlrar el valor de IC;
=tiempo de inicio más cercano para el nodo i
Al empezar, IC1NICIO = Opor definición. El administrador avanza a las tareas A, B y C que salen del nodo INICIO; es claro que
FIGURA 4.9 Rutas posibles para el ejemplo de la figura 4.7
Ruta
Tarea INICIO-A-D·F·FIN
Du ración esperada (sem anas)
2
INICIO-A-D-E-FIN
35 32
3
INICIO·B-0-F-FIN
30
4
INICIO-B-0-E-FIN
27
5
INICIO-C-E-FIN
26
MElu:X:l :E...;.. ~A CRÍTICA (CPM): CONCEPTOS Y CÁLCULOS
89
ICA =ICg =ICe = o ya que el evento INICIO requiere un tiempo de U. E ~ni rrador igue a la tarea D. De la red sabe que la tarea D no puede iniciar hasta que las ~ .-\. } B hayan terminado . Recuerde que la tarea A puede iniciar en el tiempo O y necesita J.i ~ y que la tarea B puede empezar en el tiempo O y necesita 9 semanas. Entonces, como la ~ D oo puede iniciar hasta que ambas tareas. A y B, hayan terminado, el tiempo de inicio más cercano p:rra la tarea D es igual al máximo entre el tiempo de terminación más cercano de las tareas A y B: esro es: IC 0 = máx (ICA + 1-t IC¡¡ - 9 = máx (O + 14. O ...- 9 =14 De manera similar, el tiempo de inicio más cercano para la U!rea. Fes 26 (IC¡, + 12 ) = 26 semanas, mientras que el tie mpo de inicio más cercano para la tarea E es ICE = máx (IC0 + 12, ICe - 20) =máx (14 + 12, O + 20) =26 El tiempo de "inicio" más cercano para el evento final. FIN. es entonces 1~
= máx (ICF + 9, ICE+ 6)
=máx (26 + 9, 26 + 6) = 35
En genera\ , e\ tiempo de inicio más cercano para \a i-ésima tarea, inmediatamente precedida por las tareasj del conjunto P¡ se calcula con la siguiente fórmula: IC; =máx {ICj +
tj
para todas las tareasj en P;}
donde t . =duración de la tarea j. Co~ base en el valor de ICFIN, el administrador del programa sabe que el proyecto no puede terminar en menos de 35 semanas (el tiempo de ejecución del proyecto) dada la duración estimada de las tareas del proyecto. Los resultados de los cálculos se dan en la figura 4.8. Sin embargo, el admjnistrador no sabe qué tareas definen la o las rutas críticas hasta no real izar la segunda etapa (hacia atrás) de los cálculos del CPM. En esta segunda etapa de \os cá\cu\os (hacia atrás), e\ administrador desea encontrar \os tiempos más lejanos en los que cada tarea o evento puede terminar; denota estos valores por TL¡ =tiempo más lejano de terminación para el nodo i Casi siempre se establece T4rN = 1~ ya que el evento FIN no requiere tiempo ni costo; por lo tanto, T~ = 35. Después el proceso se mueve hacia atrás a través de la red. Como las tareas E y F son precedentes inmediatos del nodo FIN, primero se mueve a estos nodos. En ambos casos es claro que estas tareas pueden terminar hasta el tiempo 35 sin retrasar el tiempo de terminación más lejano del nodo FIN (y del proyecto). Así, TL¡: = ICE = 35, como se indica en la figura 4.8. El administrador considera después la tarea D y se pregunta: ¿cuál es el tiempo más lejano en que esta tarea puede terminar sin que se retrase el tiempo más lejano de terminación de las tareas que siguen (tareas E y F)? Esto es equivalente a calcular los tiempos de inicio más lejanos de las tareas E y F. Como la tarea F puede term inar a más tardar en el tiempo 35, no puede iniciar después del tiempo 35 - 9 = 26. De manera similar, la tarea E no puede iniciar después del tiempo 35 - 6 = 29. Como la tarea D no puede ocasionar que las tareas F o E se retracen, el tiempo de terminación más lejano de la tarea D deberá ser el menor de los valores 29 y 26; es decir
90
CAPÍTULO 4
REDES DE PRECEDENCIAS Y EL MÉTODO DE LA RUTA CRÍTICA (CPM )
TLD = mín (TLF- 9, TLE- 6) = mín (35 - 9, 35 - 6) 26
=
El administrador continúa, de esta forma, calculando los tiempos de tenninación más lejanos de las tareas A, B y C como sigue: TLA = TL0 - 12 = 26- 12 = 14 TLB TLo- 12 = 26- 12 14
=
=
y TLc
=TLE - 9 =35 - 6 =29
Por último calcula el tiempo de terminación más lejano para el nodo lNlCIO del proyecto: TL¡Nrcro
=
mín (TLA- 14, TL8 - 9, TLc- 20) =mín ( l4-14,14-9,29-20) mín (0, 5, 9) =0
=
Es claro que el tiempo de tenninación más lejano del nodo INICIO siempre debe ser igual a cero, ya que los nodos INICIO y FIN deben estar en la ruta crítica (más larga). En general, si la tarea} del conjunto S; sucede inmedia!amente a la tarea i, entonces los cálculos del tiempo de terminación más lejano se encuentran usando la fórmula siguiente: TL; = mín {TLj- tj para todas las tareas j del conjunto S¡) donde
tj
=duración de la tarea}.
Cálculos con una hoja de cálculo Los cálculos del CPM con los datos del ejemplo dado en la figura 4.8 se muestran en la figura 4.1 O. Para cada tarea y evento en el proyecto, el administrador da los predecesores y sucesores inmediatos que constituyen la base de los cálculos. Observe que los valores de los tiempos de inicio más cercanos (IC¡) y de tenninación más lejanos (TL¡) corresponden a los valores dados e n la figura 4.8. Una vez que encuentra el tiempo de inicio más cercano (IC¡) y de terminación más lejano (TL¡) para cada tarea, el administrador calcula el tiempo de tenninación más cercano (TC¡) y el tiempo de inicio más lejano (IL¡) para todas las tareas. Si IC; representa el tiempo más cercano en el que la tarea i puede iniciar, entonces IC; + t; representa el tiempo más cercano en el que la tarea i puede terminar (dado que t; representa la duración de la tarea). De la misma manera, si TL; denota e l tiempo de terminación más lejano de la tarea i, entonces TL; - t; debe ser igual al tiempo más lejano M ás cercano
Inmediato Tarea o evento
Duración (t¡)
INICIO A B
e D E F FIN
FIGURA 4 . 10
Predecesores (P;)
o 14 9 20 12 6 9
o
INICIO IN ICIO INICIO A, B C,D D E, F
Sucesores (S;) A, B,C D D
E E, F FIN FIN
Tiempo d e inicio
IIC;)
o o o o 14 26 26 35
M ás lejano
Tiempo de t enninación
Tiempo de inicio
o
o o
14 9 20 26 32 35 35
5 9 14 29 26 35
Tiempo de tenninación (TL¡)
o 14 14 29 26 35 35 35
Cálculos del tiempo de inicio más cercano y terminación más lejana para un ejemplo de AON
MÉTODO DE LA RUTA CRÍTICA (CPM): CONCEPTOS Y CÁLCULOS
91
en el que la tarea i puede iniciar. Estos valores se muestran en la figura 4.1 O y el trabajo es sencillo en una hoja de cálculo sumando (o restando) la columna de la duración de la tarea (t¡) a los valores de la columna de tiempos de inicio más cercanos, IC; (o a la columna de los tiempos de tenninación más lejanos, TL,).
Definición de holguras (flotantes) La figura 4.10 (y la figura 4.8) indican que la tarea E, por ejemplo, puede iniciar tan pronto como el tiempo 26, pero no puede tenninar sino hasta el tiempo 35. Esto deja un intervalo de 35 - 29 = 9 semanas para tenninar esta Larea. Como la tarea E sólo necesita 6 semanas, hay 3 semanas de holgura o "flotante" en el periodo de ejecución de la tarea. Esto también indica que la duración de la tarea E puede extenderse 3 más antes de tener efectos negativos en el tiempo de tenninación más lejano de la Larea FIN y el tiempo de ejecución del proyecto. La holgura total es una medida empleada por muchos administradores para identificar aquellas Lareas que deben observar con más cuidado con objeto de que el proyecto avance a tiempo. En general, la holgura total es el lapso entre el tiempo de tenninación más lejano de una tarea (TL¡) y su tiempo de inicio más próximo (IC¡) menos la duración de la tarea. La holgura total se define algebraicameme como sigue: Holgura total·de la tarea i = TL;- IC; -
1;
con los valores de holgura total indicados en la figura 4.11. Observe que toda tarea cuya holgura total es igual a cero es una tarea crítica y que se encuentra, por lo tanto, e n la ruta crítica. Existen otras medidas de holgura además de la holgura total. Una medida útil se conoce como holgura libre; esta medida supone que todas las tareas deben comenzar en su tiempo de inicio más próximo. Por ejemplo, considere la tarea e e n la figura 4.8. E n este caso, el tiempo de inicio más próximo de la tarea C es el tiempo O. Como E es la úruca tarea que sigue a la tarea C y el tiempo de inicio más próximo de la tarea E es 26, esto significa que la tarea e debe tenninar en el tiempo 26 para evilar que la tarea E comience después de su tiempo de inicio más próximo. Entonces, la holgura libre de la Larea e se define como (26- O - 20 ) = 6 semanas. En este caso la holgura libre es menor que la holgura total asociada con la tarea C. Observe también que la holgura übre puede ser cero aunque la holgura total sea positiva. Para definir la holgura libre, se defi nirá un valor IC¡ mío' donde Ie; nún = mínimo inicio cercano de todas las tareas sucesoras inmediatas de la Larea i
= min {ICj para todas las tareas} en el conjunto S¡} Entonces, la holgura libre (HL¡) puede definirse como Holgura libre¡= (le¡ mfn - IC¡) -
Tarea o evento
Duración
IN ICIO A B
Tiempo de Tiempo de inicio más tenninación cercano más lejano
(t¡)
(IC¡)
(TL~
o
o o o o
14 14
14
e
9 20
D E
12 6
F FIN
9
14 26 26
o
35
FIGURA 4 . 11
o
t;
= IC¡ nún- TC,
Holgura total
Holgura libre
Holgura de seguridad
o o
o o
o o
Holgura ¿Tarea independiente crítica?
o o
5
5
5
5
29
9
6
9
6
26
o
o
35 35 35
3
3
o o
o o
o o o o
o o o o
Medidas de holgura (flotante) para el ejemplo de AON de la figura 4.8
Sí Sí No No Sí No Sí Sí
92
CAPÍTULO 4
REDES DE PRECEDENCIAS Y EL MÉTODO DE LA RUTA CRÍTICA (CPM )
La holgura libre es una medida útil por varias razones. Primero, muchos administradores sienten aversión al riesgo y quieren iruciar todas las tareas en s us 1iempos de inicio más próximos posibles. La holgura libre es entonces una buena medida de la importancia de las tareas no críticas. Segundo, la holgura libre puede ser úti l algunas veces para determinar qué tanto se puede reducir o "acelerar" una tarea antes de modificar la ruta crítica. Esta relación se analiza con más detalle en el capítulo 5. Una tercera medida de holgura es la llamada holgura de seguridad. Es1a medida s upone que todas las tareas inician en sus tiempos de inicio más lejanos. Por ejemplo, la tarea C puede iniciar hasta el 1iempo 9 si n retrasar las tareas sucesoras. Así, la holgura de seguridad de la tarea C es 9. En este caso, la holgura de seguridad se define como H olgura de seguridad¡ = (TL;- TL; máx) - t; = IL;- TL; máx donde LF; máx = máxima term inación lejana de todas las tareas predecesoras inmediatas de la tarea i = máx { LF~· para todas las tareas j e n P;} Para la tarea D, LFDmáx = máx {TLA, TL8 } = máx{ 14, 14} ridad de la tarea D es Holgura de segurida~D = TLD -
TLo máx -
=14. Por lo que la holgura de segu-
12 = 26 - 14- 12 = O
Los valores de todas las holguras de seguridad se dan en la figura 4. 1 l. Observe que la holgura de seguridad, como ocurre con todos los demás valores de holgura, es siempre cero para las tareas de la ruta crítica. Una cuarta medida de holgura se llama holgura independiente. Note que las otras tres medidas de holgura son medidas que dependen de la ruta; esto es, modificar la duración de una tarea afectará las medidas de holgura de las otras tareas. Por ejemplo. si la durac ión de la tarea E aumenta de seis a siete semanas, no sólo se reducirán la holgura total y la holgura libre de la tarea E de tres a dos semanas, también cambiarán la holgura total y la holgura de seguridad de la tarea C. La duración de la tarea E ti ene un impacto en los valores de holgura de la tarea C porque C y E están en la misma rula de la red y al modificar la duración de una tarea (en este caso de la tarea E) se modifica la duración de toda la ruta. Sin embargo, en algunos casos la duración de una tarea se puede modificar sin afectar las otras tareas del proyecto. Esta información puede ser útil para un administrador de proyectos, que debe considerar estos efectos de interacción. El tiempo que puede aumentarse la duración de una tarea si n afectar la duración de o1ras se conoce como holgura independiente y se define como sigue: Holgura independiente; = máx {O, CIC; mín' - TL; máx - t¡)} donde IC; mín' y TL; máx se definieron para las holguras libre y de seguridad. La de finición de holgura independiente requiere que el valor sea no negativo; como e l valor (ICi mín'- TL; má.,- t¡) puede ser negativo, se define Hl; igual a cero de manera arbitraria. En la tarea B, HI8 = máx {0, (14- O- 9)} = 5. Este valor indica q ue la duración de la tarea B se puede extender hasta 5 semanas sin repercutir en las holguras de las otras tareas del proyecto. En la figura 4.11 se dan todos los valores de holgura. Usando las hojas de cálculo dadas en las figuras 4. 1O y 4.11 se puede modificar la duración de las diferentes tareas del proyecto para observar cómo se modifica la ruta crítica de la red presentada e n la fi g ura 4.7. Por ejemplo, si la durac ió n de la tarea C cambia a 31 semanas, ento nces la ruta c rítica se convierte en INICIO -C-E-FIN con una duración de 37 semanas. Será sencill o explorar otras combinaciones. Excepto por el hecho de que esta hoja de cálculo fue diseñada para una red específica, los cálculos mostrados en las figuras 4.1 O y 4.1 1 so n básicamente los mismos que los que realizan la mayoría de los paquetes de software para AP (M icrosoft Project, etcétera).
MÉTODO DE lA RUTA CRÍTICA (CPM): CONCEPTOS Y CÁLCULOS
93
Formulaciones de programaci ón lineal Como se observó, una rula crítica en una red de proyecto es meramente la rula más larga en la red, del evento INICIO al evento FIN. Una vez identificada la ruta crítica, el admjnistrador del programa puede encontrar los tiempos de inicio más cercanos, los tiempos de inicio más lejanos, las holguras y otras medidas relacionadas con las decisiones de programación de tiempos (pero ignora costos, recursos y trabajadores que se estudiarán en capítulos posteriores). La programación lineal (PL) proporciona una metodología alternativa para encontrar la(s) ruta(s) crítica(s) en una red de precedencias. Aunque es muy poco probable que se use un modelo de PL para encontrar la o las rutas críticas de una red de precedencias, un modelo de PL proporciona una estructura que puede modificarse fácilmente para considerar trueques más complejos y reales con los que se enfrentan casi todos los admi nistradores de proyectos. En esta sección se desarrollará un modelo básico de programación lineal que se ampliará en capítulos posteriores para incluir fac tores adicionales como costos del proyecto, flujos de efectivo, costos de penal ización por terminar un proyecto después de la fec ha de entrega, bonificaciones obtenidas por terminar un proyecto antes de la fecha establecida y otros. Las variables de decisión en este modelo "básico" de PL son los tiempos de injcio de cada tarea (o evento); estas variables se denotan como sigue: INICIO¡ = tiempo de inicio de la tarea (evento)¡ En el modelo de LP deben construirse restricciones que garanticen que hay tiempo suficiente para realizar cada tarea según su duración dada (denotada por t¡). Por ejemplo, suponga que una tarea i precede a una tareaj. Entonces la tarea} no puede iniciar hasta que la tarea i termine; esto es, INICIOj ~TERMINACIÓN¡, donde TERMINACIÓN¡ denota el tiempo de terminación de la tarea i (TERMINACIÓN¡ es igual a INICIO¡ + t¡). Para ilustrarlo mejor, considere el ejemplo de la figura 4.8. si la tarea D se inicia en el tiempo 16, por ejemplo; entonces las tareas E y F que siguen inmediatamente a la tarea D pueden comenzar hasta el tiempo 16 + t0 = 16 + 12 = 28 (es decir, cuando la tarea D termina). Esto se establece algebraicamente como sigue: INICIOE ~ TERMINACIÓN0 (= INICI0 0 + t0 )
y INICIOF ~ TERMINACIÓN0 (= INICI0 0 + t 0 ) Debe hacer una restricción para cada relación de precedencia (arco) en la red; es decir, INICIOj ~ TERMINACIÓN¡ para toda tarea i del conjunto Pj donde pj es el conjunto de las predecesoras inmediatas de la tarea j (por ejemplo, pE = {D, e} ). Este modelo de PL puede incluir otras consideraciones, como un parámetro de retraso entre las tareas; es decir,, retraso1).. denota un retraso mínimo deseado entre la terminación de la tarea i (TERMINACION¡) y el irucio de la tareaj. (Observe que esto se podría lograr también agregando una tarea entre las tareas i y j. ) El modelo de PL para encontrar el tiempo mínimo de ejecución del proyecto se puede establecer como sigue: Minimizar FIN sujeta a INICIOJ . >- TERMINACIÓN.1 + retraso1}.. para toda tarea i en el conJ·unto P.J INICIO¡ ~ O para toda tarea i Este modelo se puede formular en una hoja de cálculo de Excel y optimizar usando la función Solver. En la figura 4.12 se da la hoja de cálculo junto con la ventana de diálogo del Solver, para los datos de la figura 4.8. En la figura 4. 12 se minimiza la variable FIN que representa el tiempo
94
CAPiTULO 4
REDES DE PRECEDENCIAS Y El MÉTODO DE LA RUTA CRÍTICA (CPMI
FIGURA 4.12 Solución de PL para el ejemplo de la figura 4.8 (Min imizar la duración del proyecto)
9 2t
u 3S 3S
ToskE Taskl' END
"'"""
-FZ-
-
-
Solver Parameters
Tar90t !:¿JI. lEN O 1~ Equol To· QMo>c @¡ Mon O Valut of: By &~ugi nt Cells:
-=
_.,._.._
~1
lsr~RTA:EHO Sub jec:t
~
~
11 1 ':::
.
Solve
r
Close
1 1
1 Guess 1
to lbe C.a>tral nu:
[H[) >•.fiHISHE flll> >• fllllSHf STARTA >• SURT STARTB >• SIART STARTC,. START STARTO >• FIHISHA SI ARTO,. fiHISHB - . STARTE •• fiiii St«: STARTf •• riNISHO STARTF >• fiHIS HD
ij
Add
}
1Cllan~e 1 ( Dele le
l
1o t ions 1 IResetAll)
1
He
te )
de ocurrencia del final del proyecto (el tiempo de ejecución del proyecto). Observe que el tiempo de inicio del proyecto (INICIO) no es una variable de decisión; es decir, en la hoja de cálculo se hace lNJCIO = O, de manera que todas las variables de decisión sean mayores o iguales que cero. Como se indica en la ventana de diálogo de Solver, se etiquetó cada celda de la hoja de cálculo que corresponde a un tiempo de inicio (INICIO .), así como los tiempos de terminación de las tareas ' J (TERMINACION) . De esta manera se pueden especificar diez restricciones de precedencia (correspondientes a los diez arcos en la red de precedencias) en la ventana de diálogo de restricciones del Solver. Observe que en este ejemplo todos los valores de retraso son iguales a cero, de manera que la solución de la PL corresponde a los cálculos dados en la figura 4. 10. Sin embargo, es un proceso directo agregar retrasos-distintos de cero y volver a correr el modelo; cualquier valor de retraso menor que los valores de holgura correspondientes no aumentará el tiempo de ejecución del proyecto. El modelo en hoja de cálculo presentado en la figura 4. 12 minimiza el tiempo de ejecución del proyecto (FJN) y, por supuesto, inicia todas las tareas críticas en su tiempo de inicio más cercano. Sin embargo, las tareas no críticas pueden iniciar en cualq uier punto e ntre sus tiempos de inicio cercano y lejano. Considere, por ejemplo, la tarea E de la figura 4.8. Aunque la solución dada en la hoja de cálculo inicia esta tarea en el tiempo 29, también puede iniciar en los tiempos 26, 27 o 28 sin modificar la terminación del proyecto en el tiempo 35. Si la preocupación son las demoras posibles, tal vez se desee asegurar que todas las tareas inicien en su tiempo de inicio más cercano. Para ello puede redeftnirse la func ión objetivo en el modelo de PL para que incluya todos los valores de las variables INICIO;. Usando pesos unitarios, el modelo de PL obtenido será: Minimi zar INICIO A+ INICI0 8 + lNICIOc + lNICI0 0 + lNICIO E + INlCIOF +FIN sujeta a: INICIO; ;::: TERMINACIÓNj para toda tareaj del conjunto P; TNICIO; ;::: O para todas las tareas La solución que se obtiene se muestra en la figura 4.13; la ventana de diálogo de Solver para este problema es la misma que la mostrada en la figura 4.12, excepto que se minimiza (el valor mfnimo es igual a 1O1) una celda distinta (correspondiente a la suma de los tiempos de inicio). Observe que la tarea E ahora inicia en el tiempo 26, su tiempo de inicio cercano. Con los valores
Slattmg'llliJ!!oH~ {Mi!~:
!r~tJ&i~} START
Tei:A Tasi:B TeskC TISI
Tasi. E Task.F END
va.w.rt ·
.•
START STARTA STARTB STARTC STARlD STARTE STARTF lND
--
~
~~
VV..
••
'ñz:iSir
\>u.. .
1
8 8 14
1~
IT\lSll!
14
' ''
fNSHB IT\lSHC JNSBD
2'
íL"iiSHi: FNSHF
35
a u
u
2'
,
:JS
s-. .ecuk rta.rtiJo¡ a-. ·1
w ·y: e{ T:rls
101
'
Zl )1
1
de inicio de tareas dados en la figura 4.12, los valores de la holgura total obtenidos son iguales a los valores de holgura libre dados en la figura 4.11, ya que !odas las tareas inician ahora en sus tiempos de inicio cercanos. De manera similar, quizá se desee establecer todos los tiempos de inicio de las tareas no c ríticas en sus tiempos más lejanos posibles de manera que las holguras resultames sean iguales a la holgura de seguridad para todas las tareas. Aunque puede parecer que la función objetivo Minimizar INICIOA - IN1CI0 8
-
INlCIOc- INICI0 0
-
INICIO E- INICIO F - FIN
logra este objetivo, en realidad esta función no trabaja correc!amente y dará una solución no acotada del modelo de PL. Esto ocurre porque Solver querrá incrementar el valor de todas las variables de decisión sin límite o cota (recuerde que todos los valores deben ser no negativos). Para evitar una solución no acotada, debe cerciorarse de que el valor de la variable FT es mayor que el valor total de (TNlCIOA + IN1CI0 8 + INTCIOc + INICI0 0 + INlCIOE + INICIOF). En general , será suficiente agregar a FIN un peso que sea un orden de magnitud mayor que los pesos de las otras variables; en este ejemplo se puede redefi nir la función objetivo como sigue: Minimizar 10 FIN- INlCIOA -INTCI0 8
-
INICIOc -INTCI0 0
-
INlCIOE- INlC lUF
De esta manera, Solver da la prioridad más alta a minimizar FIN (tiempo de ejecución del proyecto) y prioridades secundarias a minimizar las variables INTCIOA, INICI0 8 , ... La solución que se obtiene se muestra en la figura 4. 14 ; usando estos tiempos de inicio de las tareas, las holguras totales serán iguales a las holguras de seguridad .
ROGRAMACIÓN DEL PROVECTO Y DIAGRAMAS DE GANTT Con las estimaciones de tiempos y los cálculos del CPM, se pueden determinar la programación y el presupuesto planeados (el presupuesto se analizará en e l capítulo 5). Los resultados de la programación sue len representarse en un diagrama de Gantt. Para ilustrar un diagrama de Gantt, suponga que se tiene un pequeño proyecto que consiste en 16 tareas; la hoja de cálculo de la figura 4.15 contiene la información del estado de estas tareas. Un diagrama de Gann es meramente un diagrama de barras en e l que cada tarea está representada por una barra horizontal; se puede incluir información adicional para representar tareas críticas, trabajo restante, etcétera. Con la función de gráficos de Excel se puede trazar un diagrama de Gantt para los datos del proyecto de la figura 4. 15; este diagrama de Ganu e representa en la figura 4.16. El apéndice A4 presenta cómo trazar un diagrama de Gann en MS-Excell. Los diagramas de Gann se pueden personalizar de manera ilimitada. La figura 4.17 contiene parte de un diagrama de Gantt producido por un software comercial para AP (Microsoft Project). Como se ve, las barras grises indican las tareas críticas, la parte en negro dentro de las barras horizontales indica trabajo terminado y las flechas indican las relaciones de precedencia. Observe que se usaron rombos para representar tareas que no requieren tiempo; estas tareas generalmente se llaman eventos y denotan hechos significativos en la vida de un proyecto (como el inicio del proyecto, el final del proyecto).
96
CAPITULO 4
REDES DE PRECEDENCIAS Y EL MÉTODO DE LA RUTA CRiTICA (CPM)
FIGURA 4 . 14 So lució n de PL para el ejemplo d e la f igura 4.8; t iempos de t erm inación más leja nos
10 • ENO - (sum of u.si. sla1t~ tiwt)
FIGURA 4 .15 Informaci ón d e av ance para un eje mplo d e proyecto
•1
,
267
Fech a de Días Días Duración inicio transcurridos restantes (días)
Tareas
o o o o
Desa rrollar sim ulación Recolectar datós Escribir el software Probar el software
3
Prueba de integración Prueba fina l
12
Instalació n
10
Capacitació n
10
Prueba del v ehículo Inicio de la producción
1
3
4
2
6
3
o
3
3
4
4
2
2
12
2
2
10
o
8 4 7 6 5
8 5 7 6 5
1
Primera entrega Producción total
13
o o
11
o
Recolectar datos Escribir el software Probar el software Construir computadora Des. interfaz de usuario
Prueba de integración Prueba final Instalación Capacitación Prueba del vehículo Inicio de la producción Construcción Instalación Primera entrega
Producción total
• •• • •• 11 1 1 1
1 1 1 1 1 1 1 1 1 1
H-
s
4
5 9
8
1 2 3 4
2
9
14
o
1
o o o o
Con strucción
Desarrollar simulación
1
3
Instalación
FIGURA 4 . 16 Diagrama de Gantt en Excel con los datos d el ejem p lo en la figura 4.15
4
o
5
Constru ir co mputadora Desarrollar i nterfaz de usuario
2
6 1
a
9 10
tt
12 13 t 4
1s
16 11 1& 19 20 21
~
r1
1 1 1 1 1 1
11 1 1 1 1 Fm ID 11 11 1 1 11 1 11 1
1 1 1 1 1 1 1 1 1 1
11 1 1 111 1 11 1 1 1 1 1 1 11 1 1 11 1 1 11 1 1 11 1 1
1 1 1 1 1
1
1
t
1
1
1
'
:Hs
•
f
1
nn
CÁLCULOS DEL CPM PARA REDES AOA
97
R GURA 4.17 -:mplo de d i agrama de ~n tt (MS Project 2000)
r: r~
También se indican los días calendario específicos así como el número de trabajadores genéricos asignados a cada tarea. Los diagramas de Gann son útiles para desplegar los resultados de la programación del CPM. También pueden servir como un dispositivo de control efectivo ya que comunican el avance del proyecto en todo momento.
CÁLCULOS DEL CPM PARA REDES AOA Para ilustrar los cálculos del CPM para una red AOA, se considerará la red AOA de la figura 4.5 agregándole la duración estimada de las tareas (en semanas). Esta red se muestra en la figura 4.18. En este ejemplo hay cuatro eventos (nodos): INICIO, 1, 2 y FIN, y cinco tareas que pueden identificarse de manera única por sus eventos de inicio y de terminación: Tarea A =: Tarea (INICIO, 2) Tarea B =: Tarea (INICIO, 1) Tarea C =: Tarea (2, FIN) Tarea ficticia
= Tarea ( 1, 2)
Tarea D = Tarea ( J , FIN) Recuerde que la tarea ficticia no toma ti empo y no usa recurso ; se usa en la red AOA esLrictamente para reforzar las relaciones de precedencia correctas. En el caso de las redes AOA, se quiere enconLrar los tiempos de ocurrencia de los eventos (nodos). Cada evento inicia tan pronto como es posible; por ejemplo, si se supone que el evento INICIO inicia en el tiempo O, el evento 1 no puede ocurrir antes del tiempo 2 (ya que la tarea B requiere 2 semanas), pero puede ocurrir en cualquier tiempo posterior. De manera similar, el tiempo más cercano de ocurrencia del evento 2 es el tiempo 4 ya que hay dos rutas al evento 2 y todas las tareas de ambas rutas deben terminar antes de que el evento ocurra. En este caso, las dos rutas entre el INICIO y el evento 2 son •
Ruta 1: tarea A (cuatro semanas)
•
Ruta 2: tarea B (dos semanas) + tarea ficticia (cero semanas)
Así, el tiempo de ocurrencia más cercano para el evento 2 es el tiempo máximo de las dos rutas que llegan al evento; esto es, el tiempo de ocurrencia más cercano del evento 2 es máx (4, 2 ) =4 - RA 4.18 - ! QA (figura 4 .5) .as duraciones
2 semanas
98
CAPÍTULO 4
REDES DE PRECEDENCIAS Y EL METODO DE LA RUTA CRÍTICA (CPM)
semanas. En general, T; es el tiempo de ocurrencia del evento i y se usa un superíndice e o L para denotar tiempo de ocurrencia más cercano o más lejano, respectivamente. En este ejemplo, Tf = tiempo de ocurrencia más cercano del evento 2 = máx ( 4, 2) = 4 semanas
Para encontrar el tiempo de oc urrencia más cercano de todos los eventos, se recorre toda la red hacia adelante igual que como se hjzo en las redes AON. Suponiendo que T 1NICIO =O, se avanza al evento 1; es claro que el tiempo de ocurrencia más cercano para el evento 1 es el tiempo necesario para realizar la tarea B, que es dos semanas. Para encontrar el tiempo de ocurrencia más cercano del evento final FIN, se deben considerar las dos tareas que terminan en este evento. las tareas e y D. El evento inicial de la tarea e es el evento 2; el tiempo de ocurrencia más cercano de este evento es 4 semanas. Por lo tanto, el tiempo de terminación más cercano de la tarea e es 4 semanas + (duración de la tarea C) = 4 semanas + 7 semanas = 11 semanas. De manera similar, el tiempo de terminación más cercano de la tarea D es el tiempo de ocurrencia más cercano del evento 1 (el tiempo 2) más 10 semanas para la tarea D. El tiempo de ocurrencia más cercano del evento FIN es el mayor de estos dos valores, ya que todas las tareas deben haber terminado antes de que el evento pueda ocurrir; esto es,
T~N = máx (Tr + 1O, Tf
+ 7) = máx (2 + 1O, 4 + 7) = máx
( 12, 11) = 12
En general, si la duración de la tarea {i,J) se denota por t;p entonces la ocurrencia más cercana del evento j está dada por la siguiente fórmula :
T~ = 1
máx
!areas (i,j)
(Te +t·· ) 1
IJ
De los cálculos de la pasada hacia adelante, sabemos que el tiempo de ocurrencia más cercano del evento FIN es el tiempo 12; ésta es la longitud de la ruta más larga o ruta crítica a través de la red. (La pasada hacia adelante permite identificar la longitud de la ruta crítica, pero no las tareas específicas en ella.) Igualando el tiempo de ocurrencia más lejano del evento FIN a su tiempo de ocurrencia más cercano (es decir, rcFtN = TLFIN = 12 semanas), se puede realizar la pasada hacia atrás en la red AOA para encontrar el tiempo de ocurrencia más lejano de todos los eventos. En este ejemplo, si TLFtN = 12, entonces el tiempo más lejano del evento 2 es 12- (duración de la tarea C) = 12- 7 = S semanas. Si el evento 2 ocurre en cualquier momento después del tiempo 5, es claro que el evento final FIN se retrasará más allá del tiempo 12. De igual manera se encuentra el tiempo más lejano del evento l. En este caso, hay dos tareas que empiezan en el evento 1: la tarea ficticia y la D. El tiempo de termjnación más lejano para la tarea ficticia (el tiempo de ocurrencia más lejano del evento 2) es 5, mientras que el tiempo de terminación más lejano para la tarea D es 12. Dado que estos tiempos más lejanos no se pueden retrasar, el tiempo de ocurrencia más lejano del evento 1 es el menor entre (S - duración de la tarea ficticia) y (12- 10); es decir,
T1L =mín (5-0, 12 - 10)-mín (5, 2)=2 En general, el tiempo de ocurrencia más lejano de todos los eventos se encuentra empleando la fórmula recursiva: TL = 1
mín
!areas(i.j}
(T~ 1
- t··) 11
Usando ambas fórmulas recursivas para encontrar el tiempo de ocurrencia más cercano y más lejano de todos los eventos de la red AOA, se pueden indicar estos valores en la red. En este ejemplo, los valores se dan en la figura 4. 19.
CÁLCULOS DEL CPM PARA REDES AOA
FIGURA 4 . 19 Ejem plo con t iempos de ocurrencia más cercanos 1 más lejanos
99
T~= 4 T~= 5 Tarea A
Tarea C
T~ICIO = o
T~IN
=12
T~NICIO =o
T~IN
= 12
Dados los tiempos de ocurrencia más cercanos y más lejanos, es relativamente sencillo calcular los valores de holgura de cada tarea en una red AOA. La holgura total de la tarea (i, j), que se denota por HT;p se define como sigue:
HTu = holgura total de la tarea (i,j) = TJ- TF- tu donde tij es la duración de la tarea (i, J). Las otras medidas de holgura definidas para las redes AON se pueden definir de manera similar: HL¡j
= holgura libre de la tarea (i, j) =
Tf - TF- tij
HS ij = holgura de seguridad de la tarea (i, j) =
TJ - TF - t ij
Hl ij =holgura independiente de la tarea (i, j) = máx (0,
Tf - TF - tu)
La figura 4.20 resume los cálculos de los cuatro tipos de holgura para el ejemplo de la figura 4. 19. Verifique los valores de esta tabla con sus propios cálculos. Como se indica en la figura 4.20, cualquier tarea con una holgura total igual a cero está en la ruta crítica. Observe que las tareas B y D definen la ruta crítica en este caso (con una duración total de 12 semanas).
Formulación de programación matemática para las redes AOA Aquí, los tiempos de ocurrencia de cada evento se definen como las variables de decisión; es decir, X; =
tiempo de ocurrencia del evento i
Como cada tarea (i, j) está definida por un evento inicial i y uno final j, el modelo básico de programación lineal debe garantizar que el tiempo asignado a cada tarea sea suficiente; es decir, X¡ - X;
GURA 4 .20 -:coores de holgu ra -=-ara el ejemplo de gura 4.19
-
Tarea A: (INICIO, 21 S: (INICIO, 11 Ficticia (1, 21 C: (2, FIN ) 0: (1, FIN)
2':
tij
para cada tarea (i, j) de la red
Tiempo de Tiempo de Holgura inicio más tenninación Holgura Holgura Holgura de Duración cercano total libre seguridad independiente más lejano (t¡¡~ HT;¡ HL;¡ Hl;¡ HS,¡ (Tl) (T~}
4 2
o 7 10
o o
5
o o
2
o
2
5
3
4
12 12
1
2 1
o
o
2
1
o
o o
3
2
o o
o o
1 00
CAPÍTULO 4
REDES DE PRECEDENCIAS Y El MÉTODO DE LA RUTA CRÍTICA (CPM)
Si xFIN es el evento (nodo) final de la red AOA y se quiere minimizar el tiempo de ejecu del proyecto, entonces el modelo de PL es simplemente Minimizar xFlN sujeta a x.x.1 > tIJ.. para cada tarea (i,j) de la red j X¡~
0
Para el ejemplo de la figura 4.18, el modelo de PL que minimiza el tiempo de ejecución de proyecto es: Minimizar xFIN sujeta a x 2 - xiNICIO ~ 4 (restricción para la tarea A) x 1 - x1Nrcro ~ 2 (restricción para la tarea B) x2 - x 1 ~ O (restricción para la tarea ficticia) xRN - x 2 ~ 7 (restricción para la tarea C) xRN- x 1 ~ 1O (restricción para la tarea D)
XINICJO• Xp X2, XFIN
~ 0
CONCLUSIONES Casi todos, si no todos, los paquetes de software para AP encuentran la ruta crítica, los valores de holgura total (fl otante), las redes de precedencias y los diagramas de Gantt (así como estimaciones de costos, reportes, etcétera). Dado que la mayor parte del software para AP está orientada al tiempo, funcionan bien como ayuda para programar proyectos y tareas. Sin embargo, casi todos dejan de considerar de manera explícita problemas más complejos relacionados con flujos de dinero, costos de penalización por no cumplir la fecha de entrega, programas de pagos, y otros. Además, aunque casi todo el software para AP tiene cierta capacidad para asignar recursos (dinero, empleados, equipo) a tareas, muchos de los algoritmos que usan para la asignación de recursos son de naturaleza heurística y no garantizan soluciones óptimas (ni siq uiera buenas). Éstos y otros aspectos relacionados se describen con más detalle en los capítulos siguientes.
PROBLEMAS PARA ESTUDIO 1. Construya los diagramas AON y AOA, que comprendan las actividades A, B, C, ... , H y que salisfagan las relaciones de precedencias siguientes:
a . A, B y C, las primeras actividades del proyecto pueden iniciar al mismo tiempo. b. La acti vidad D puede iniciar de inmediato después de terminar las actividades A y B. c. La acti vidad E sucede a la tarea C. d. La actividad F no puede iniciar hasta que la aclividad A termine. e. La actividad E precede a las tareas G y H. f. La actividad D precede a la tarea G.
2. Un pequeño proyecto de investigación está representado por una red AOA definida por las tareas de la tabla siguiente. Construya la red AOA; determine con claridad el tiempo más cercano y más lejano de ocurrencia para cada evento. Encuentre la ho lgura total, holgura libre, holgura de seguridad y holgura independiente de todas las tareas de la red.
PROBLEMAS PARA ESTUDIO
Etiqueta de la tarea
Eventos (i,¡)
Duración
A
(1, 2)
B
(1, 3)
5 3
e
(1. 4)
d
D
(2, 4)
E
(3, 4)
1 2
F
(3. 5)
5
G
(3, 6)
H
(4, 6)
9 4
1
(5, 6)
2
101
3. Para la red del problema 2, construya la red AON equivalente y encuentre los tiempos de inicio más cercano y de terminación más lejano para todas las tareas. Encuentre la holgura total, holgura ·Jibre, ho lgura de seguridad y holgura independiente para todas las tareas de la red. Compare los resultado con los del problema 2. 4. Para la red AON del problema 3, formule y resuelva un modelo de programación lineal (use
Solver de MS-Excel) para encontrar la ruta crítica y los valores de holgura libre, y la ruta crítica y los valores de holgura de seguridad. Compare los resultados con los obtenidos en los problemas 2 y 3. 5. Para la red AON del problema 3, formule y resuelva un modelo de programación lineal (use Solver de MS-Excel) para encontrar la ruta crítica y los valores de holgura de seguridad. Compare los resultados con los obtenidos en Jos problemas 2 y 3. 6. Dada la siguiente red AOA de un proyecto:
T~=10
T ~=?
Dados los tiempos de ocurrencia más cercanos (TF) y los tiempos de ocurrencia más lejanos (T;L) de cada evento i, responda las siguientes preguntas: a. ¿Cuál es la duración de la tarea ( 1, 3)? b. ¿Cuál es la duración de la tarea (2, 3)? c. ¿Cuál es la holgura total de la tarea (3, 4)? d. ¿Cuál es la holgura de seguridad de la tarea (4, 5)? e. ¿Cuál es la holgura libre de la tarea (2, 5)? f. ¿Cuál es la holgura independiente de la tarea (2, 4)?
102
CAPITULO 4
REDES DE PRECEDENCIAS Y EL METODO DE LA RUTA CRiTICA (CPM)
7. Pruebe o rebata las siguientes dos conjeruras respecto a holguras. a . Holgura independiente = mfn (holgura libre. holgura de seguridad) b. Holgura total + holgura libre =holgura de seguridad + holgura independiente 8. La demanda en Wonder Widget Company (W2C) ha disminuido últimamente debido a una baja de la economía. En respuest a, la admin istración de W2C ha cerrado una de sus líneas de producción. No obstante, están preocupados por cuánto tiempo tomará restablecer la línea cuando la demanda aumente (si así es), y deciden pedirle ayuda. Después de realizar un estudio cuidadoso del proceso de producción, usted determina a partir de su estructura desglosada del trabajo que se deben reali zar diez tareas antes de poder restablecer la línea. Estas tareas se dan en la tabla con sus duraciones estimadas (en días). Cada tarea está representada por una letra que la identifica de manera única y el par de números de sus eventos inicial y final , lo que también indica la precedencia. El evento 1 es el evento inicial, el evento lO es el evento final. ldentif. de la tarea
Números de los eventos
Duración (días)
A
(1, 2)
B
(2, 3)
5 2
e o
(2, 4)
4
(4, 5) (4, 7) (3, 5)
8
6
(7, 8)
5
E F
G H J
2
(5, 7)
1
(8, 10)
3
(8, 9)
6
Con esta información responda las preguntas siguientes: a. Si todas las tareas inician tan pronto como sea posible, ¿cuánta holgura quedará para cada tarea? Si cada tarea inicia tan tarde como sea posible, ¿cuánto tiempo de holgura quedará para cada tarea? ¿Cuánta holgura se asocia a cada tarea que es independiente de cualquier retraso en las otras tareas? b. Formule y resuelva un modelo de programación lineal para encontrar la ruta crítica y los valores de holgura libre. Compare su respuesta con los resultados encontrados en el inciso a. c. ¿Cuánto debe aumentar la duración de la tarea D para que se modifique (i)
el tiempo de inicio más cercano de D?
(ii)
el tiempo de inicio más cercano de 1?
(iii)
el tiempo de termi nación más cercano del proyecto?
d. El gerente de producción piensa que usted ha cometido un error y que la tarea C debe ser predecesora de la tarea F. (i)
¿Qué actividad cambiará su tiempo de inicio más cercano? ¿Cuánto cambiará?
(ii)
¿Qué actividad cambiará su tiempo de inicio más lejano? ¿Cuánto cambiará?
9. Un proyecto pequeño consiste en seis tareas; los predecesores inmediatos y la duración de las tareas se dan en la tabla siguiente.
APÉNDICE-..-= -ZD DE UN DIAGRAMA DE GANTI CON MS-EXCEL
ldentif. de la tarea
Númei"O$ de los eventos
A
8
103
Duraci ón (días)
5 2
e
-
~
4
o
.!
5
E
"
-
2 8 6 5 1
F
1 5
G
-a
H
5 -
1
e ·e
J
R9
3 6
a. Dibuje una red de precedencias AO. · • una red de precedencias AOA para este proyecto. b. Para cualesquiera de las redes. encuentre las cantidades siguientes: tiempos de inicio cer-
cano y lejano, tiempos de terminación cercano y lejano, holguras total, libre, de seguridad e independiente.
APÉNDICE 4A. TRAZO DE UN DIAGRAMA DE GANTT CON MS-EXCEL Considere la hoja de cálculo de Excel dada en la figura 4.15. (Observe que la "duración" está definida como "días transcurridos" más "días restantes".) Seleccione los datos que va a graficar; en este caso, se resaltan Jos datos de las primera cuatro columnas (incluyendo Jos nombres de las tareas). Seleccione una gráfica de barras horizontales (barra apilada); también se puede usar una gráfica de barras horizontales con efecto 3-D. Básicamente, ahora tiene un diagrama de Ganu con barras horizontales de tres colores y los nombres de las tareas en el eje vertical. La primera parte de cada barra representa el tiempo desde el día O hasta la fecha de inicio, la segunda parte representa el número de días Lranscurridos y la tercera, el número de días restantes hasta la fecha de terminación programada para la tarea. (Observe que en algunas tareas aú n no comienzan a trabajar.) Como no nos interesa el número de días desde el día O hasta el inicio de cada tarea, se desea que este primer segmento de cada barra sea invisi ble. Para hacer esto, haga clic dos veces con el ratón sobre la primera parte de cualquier barra; esto hará que se abra la ventana de "formato de serie de datos" para la primera serie. En la pestaña de "Lramas" seleccione el color blanco (el fondo también debe ser blanco). Presione "aceptar" y habrá desaparecido la primera parte de cada barra. En este ejemplo se agregaron líneas verticales al diagrama de Gantt para facilitar la lectura de las fechas. Para hacer esto, seleccione "gráfico/opciones de gráfico" en la barra de menú, elija la pestaña de líneas de división y active líneas de división principales para el eje x. Si desea puede cambiar la escala y, por ejemplo, agregar líneas de división para cada día. Para cambiar la escala, presione dos veces sobre la escala horizontal ; esto hará aparecer la ventana de "formato de ejes". Elija "escala" y ponga un 1 en la ventana de unidad mayor. Excel trazará entonces líneas verticales para delimitar cada periodo (días en este ejemplo). Por último, se desea invertir el eje vertical, en el que la primera tarea se encuentra abajo, elija el "eje vertical" y la pestaña de escala. En la ventana de diálogo, active categorías en orden inverso, y presione en "aceptar". Su diagrama de Gann (dado en la figura 4.16) está listo.
104
CAPÍTULO 4
REDES DE PRECEDENCIAS Y EL MÉTODO DE LA RUTA CRÍTICA (CPMI
APÉNDICE 48. RELACIONES DE PRECE DENCIA ALTERNATIVAS En la mayoría de los proyectos, la relación de precedencia terminación a inicio es la más usada al construir una red de precedencias; la relación terminación a inicio implica que si la tarea A precede a la tarea B, la tarea B no puede iniciar hasta que la tarea A haya terminado. En este capítulo los cálculos para la ruta crítica y para las holguras se han basado en la suposición de que todas las relaciones de precedencia son relaciones terminación a inicio. Sin embargo, en muchas situaciones pueden ser útiles las relaciones inicio a inicio o terminación a terminación. En este apéndice se describen estas relaciones con más detalle y se muestra cómo se modifican los cálculos del tiempo de inicio cercano y el tiempo de terminación lejano con estas relaciones de precedencia alternativas. Para ilustrar las diferencias se usará una modificación del ejemplo dado en la figura 4.8 que se muestra en la figura 48.1. En este ejemplo, se supone que la relación de precedencia entre la tarea D y la tarea E ya no es una relación terminación a inicio. Se examinará primero la relación inicio a inicio y después la relación ierminación a terminación.
Relación inicio a inicio Si la relación de precedencia entre la tarea D y la tarea E es una relación inicio a inicio, entonces la tarea E no puede iniciar hasta que la tarea D haya iniciado. Esto implica que ahora las tareas D y E pueden realizarse al mismo tiempo, siempre y cuando la tarea E no inicie antes que la tarea D. El cálculo del tiempo de inicio más cercano para la tarea E se modifica para reflejar que ahora la tarea E puede iniciar tan pronto como la tarea D haya iniciado. Como la relación de precedencia entre las tareas C y E sigue siendo una relación terminación a inicio, la tarea E no puede iniciar hasta que la tarea C haya terminado (en el tiempo ICe + te) y la tarea D haya iniciado (en el tiempo IC 0 ). Como estos dos eventos deben ocurrir antes de que inicie la tarea E, el tiempo de inicio más cercano de la tarea E (ICE) es ICE = máx (ICe + te• ICD) = máx (O+ 20, 14) =20 Recuerde que cuando se usó la relación terminación a inicio, el tiempo de inicio más cercano de la tarea E era 26. En general, el tiempo de inicio cercano de la tarea i se calcula como FIGURA 48.1 Ilustración de la relación de precedencia inicio a inicio
Tarea A
Tarea E S semanas Tarea C 20 semanas
APÉNDICE 48. RELACIONES DE PRECEDENCIA ALTERNATIVAS
105
IC; = máx {ICj + tj para todas las tareas j que preceden a la i en una relación terminación a inicio: ICj para todas las tareas j que preceden a la tarea i en una relación inicio a inicio} Cuando se usan relaciones inicio a inicio, Jos cálculos para encontrar los tiempos de terminación lejanos son los mismos que al usar una relación terminación a inicio (dados en este capítulo). Así, el tiempo de terminación más lejano de la tarea E~) en el ejemplo de la figura 4B. l es igual a 35. Dados el tiempo de termi nación más lejano y el tiempo de inicio más cercano, la holgura total se calcula con el mismo enfoque dado en este capítulo, es decir. Holgura total de la tarea i =TL; - IC; -
t;
Entonces, la holgura total para la tarea E es HTE = 35 - 20 - 6 = 9 semanas. (En comparación con 35 - 26- 6 =3 semanas cuando se usa una relación terminación a inicio entre las tareas D y E.)
Relación terminació n a terminación Si la relación de precedencia entre las tareas D y E es una relación terminación a terminación, entonces la tarea E no puede terminar hasta que la tarea D haya terminado. Esto implica que las tareas D y E se pueden realizar al mismo tiempo siempre y cuando la tarea E no termine antes de que la tarea D esté term inada. Si la relación de precedencia entre las tareas D y E en la figura 4B.J es ahora una relación terminación a terminación, como se muestra en la figura 4B.2, habrá que modificar Jos cálculos del inicio más cercano y de la terminación más lejana. Los cálculos del inicio más cercano de la tarea D deben dejar tiempo suficiente para realizar la tarea E así como todas las tareas que siguen a la tarea D. Para esto se supondrá que hay un arco dirigido de la tarea E a la D ; en este caso se resta la duración de la tarea D al considerar la tarea E. El tiempo de inicio más cercano de la tarea D se encuentra como sigue: ICD = máx (ICA + tA, IC 8 + t 8 , ICE+ tE- t 0 ) = máx (O + 14, O+ 9, 20 + 6 - 12) = rnáx (14, 9, 14) =14 Como se supone que la relación de precedencia entre las tareas D y E está representada por un arco dirigido de E a D, el tiempo de inicio más cercano de la tarea E está definido de la manera usual; es decir, ICE= ICe + te = O + 22 = 22.
Tarea A
Tarea F
Tarea E 6semanas
Tarea C 20semanas
1 06
CAPiTULO 4
REDES DE PRECEDENCIAS Y EL MÉTODO DE lA RUTA CRiTICA (CPM)
El tiempo de terminación más lejano para la tarea D se calcula de la manera usual; es decir. TL0 =~ - tF = 35 - 9 = 26. Para encontrar el tiempo de terminación más lejano de la tarea E. debe quedar tiempo suficiente para que todas las tareas que siguen a la tarea D terminen (ya que la tarea E no puede terminar hasta que la tarea D haya terminado). Entonces, el tiempo de terminación más lejano para la tarea E se calcula como sigue:
TL¡: = mín (TLAN- O, TL0 )
= mín (35 =26
O, 26)
Dados e l tiempo de terminación más lejano y el tiempo de inicio más cercano, se pueden calcular directamente los valores de holgura para todas las tareas.
Problemas de estudio adicional 81 . Use la siguiente red de precedencias AON (y las duraciones dadas de las tareas) para encontrar los valores de holgura que se piden en los incisos a y b. Tarea
Predecesor inmediato
A
B
e
o
B. e
E
A, O
F
Duración
8 5 2 3 10 13
a . Suponiendo que las tareas A, B, C y D sigue n un a relación te rminación a inicio con retraso de 1 día, encuentre los valores siguientes: 8 días
3 días
6 días
8 días
b. Suponiendo que las tareas A , B, C y D siguen una relación inicio a inicio con retraso de O, enc uentre los valores de holgura siguientes: Tarea
Holgura total
A
B
e o 82. Con los datos del ej empl o 4B.l encuentre el tiempo de inicio más cercano, e l tiempo de terminación más lejano y los valores de hol gura total para todas las tareas, suponiendo que ahora la tarea C requiere 22 semanas.
PÍT ULO
PIANEACIÓN PARA MINIMIZAR COSTOS
e
omo se vio en el primer capítulo, con frecuencia los proyectos se evalúan sólo por su costo y tiempo; es decir, ¿tenninó el proyecto dentro del tiempo y el presupuesto planeados? Aunque estos criterios ignoran los aspectos obvios de funcionalidad, calidad, etcétera (recuerde el proyecto de aterrizaje en Marte presentado en el primer capítulo), en este capítulo se considerará la relación entre costo y tiempo con más detalle. Al planear un proyecto, la meta fundamental deberá ser siempre maximizar la diferencia entre las ganancias descontadas del proyecto y su costo. Por ejemplo, considere un proyecto en el que se ofrecen bonificaciones (incentivos) si el proyecto tennina antes de una fecha establecida. En este caso, los costos adicionales de reducir la duración del proyecto para cumplir con esta fecha pueden ser mayores que la bonificación que se ganará. Si es así, no tendrá sentido económico reducir la duración del proyecto para obtener el incentivo ofrecido. Al calcular el costo total, el administrador debe considerar todos los costos relevantes para encontrar el mejor plan del proyecto. Además de los costos estándar, debe considerar los costos de penalización por violar la fecha de entrega establecida, las bonificaciones por tenninar antes de esa fecha y los flujos de efectivo. Estos últimos son importantes no sólo para definir el valor del proyecto, sino también para mantener la liquidez de la organización. En general se supone que los administradores pueden influir en la duració n de una tarea (y del proyecto) asignando recursos adicionales (como personas o equipo) para disminuir la duración de las tareas críticas. Reducir la duración de un proyecto de esta manera se conoce como aceleración del proyecto. Así, la tarea del administrador de proyectos es asignar los recursos adecuados a todas las tareas para minimizar la suma de los costos; es decir, encontrar el trueque óptimo entre los costos señalados. Debe observarse que algunos proyectos parecen violar la regla de "plan de proyecto de costo total mínimo" . Por ejemplo, considere el caso en el que una empresa qui ere desarrollar un nuevo producto tan rápido como sea posible con objeto de max imizar su participación en el mercado; o el caso en el que una empresa pierde dinero en un proyecto de I&D con el que cree que logrará contratos futuros (líder por pérdidas). A corto plazo puede parecer que estos proyectos violan el objetivo de un plan de proyecto de costo mínimo. Sin embargo, en los d os casos la organización sigue la regla del costo total mínimo, porque incurrirá en un costo de penalización alto (retraso) si el nuevo producto no se lleva al mercado en una fecha detenninada o si el proyecto de I&D no termina a tiempo. En ambos ejemplos, minimizar el tiempo de ejecución del proyecto (la duración) es sinónimo de minimizar el costo del proyecto. En este capítulo se analizan los trueques entre tiempo y costo que el administrador de un proyecto debe considerar. También se consideran varios modelos que pueden usarse para analizar estos trueques. En la primera sección se examina el proceso de presupuesto en general y se ve cómo las decisiones de programación pueden afectar los presupuestos. En la sección siguiente se estudia cómo las decisiones de programación pueden afectar de manera drástica los flujos de efectivo y el valor presente neto. En la tercera sección se presenta el problema general de los trueques tiempocosto y se examina un modelo y la hoja de cálculo asociada para analizar estos trueq ues. 107
108
CAPiTULO 5
PLANEACIÓN PARA MINIMIZAR COSTOS
PRESUPUESTO DEL PROYECTO El presupuesto es un documento crucial de la planeación y un vínculo de comunicación entre todos los interesados en el proyecto, incluyendo al equipo del proyecto y los departamentos funcionales de una organización. Un presupuesto establece firmemente los objetivos y la asignación de recursos que suelen afectar a todas las panes de la organización, que incluyen a otros proyectos. Come una herramienta de planeación y comunicación, el presupuesto nunca debe considerarse invariable. sino que debe modificarse conforme se tiene nueva información y se actualiza el plan del proyecto. La mayor parte del software para administración de proyectos (AP) permite mantener una versión base del presupuesto para compararla con el presupuesto actualizado. Como se vio en el primer capítulo, los presupuestos casi siempre juegan un papel importante aJ juzgar el éxito o fracaso de un proyecto. Aunque usar los presupuestos de esta manera puede no ser adecuado, de cualquier manera es una práctica común (¿cumplió el proyecto sus metas de tiempo y costo?). Cuando un proyecto no cumple su meta de presupuesto, es útil tener en mente que este fracaso se puede deber a una mala administración del proyecto, a un mal presupuesto o simplemente a un entorno cambiante. Los presupuestos que se crean empezando con estimaciones de costos para el nivel más bajo de la estructura desglosada del trabajo (EDD se llaman presupuestos de abajo arriba, ya que empiezan con los paquetes de trabajo más pequeños y agregan estas tareas para definir un presupuesto final. Este proceso de agregar tareas de la EDT explica por qué con frecuencia los paquetes de la EDT se consideran los ladrillos para la construcción del presupuesto y la programación del proyecto. Por el contrario, el presupuesto puede empezar con una asignación global y después dividirse y asignarse a las diversas componentes de un proyecto. Por ejemplo, muchas empresas desarrollan presupuestos por líneas de productos y después dividen estas cantidades presupuestadas entre los proyectos específicos dentro de las líneas de productos. Cuando los presupuestos se desarrollan de esta manera se conocen como presupuestos de arriba abajo. En la práctica se usa una combinación de los procesos de arriba abajo y abajo arriba. Es costumbre que la alta administración indique una restricción de presupuesto, mientras que los administradores de proyecto usan el enfoque de abajo arriba para estimar costos agregados. El resul tado es un proceso iterativo que re.fina el presupuesto, así como el alcance y el diseño del proyecto. Por ejemplo, si los administradores de proyecto consideran que la cantidad asignada por la alta ad ministración no es adecuada, deben renegociar el presupuesto o restablecer el alcance y la definición del proyecto para encontrar un punto intermedio adecuado. En general, los presupues tos se establecen en unidades monetari as, pero se puede usar cualquier unidad mensurable (como horas-hombre). Los presupuestos deben indicar también cómo serán asignados los costos de los recursos a las diversas unidades funcionales (por ejemplo, número de horas-carpintero). Además, como parte del presupuesto deben indicar e con claridad los eventos importantes del proyecto. Los presupuestos se actualizan con regularidad. El horizonte de planeación y la frecuencia de las actualizaciones son aspectos importantes; es común usar un horizonte periódico (por ejemplo, cada trimestre de los siguientes 12 meses se actualiza el presupuesto). La cuesti ón de la frecuencia con que debe actualizarse el presupuesto no tiene una respuesta clara y depende de factores como la duración, el costo y la prioridad del proyecto. En el contexto del presupuesto se deben considerar cuatro tipos de costos: •
Costos directos
•
Costos de materiales
•
Costos generales e indirectos
•
Costos de penalización y/o bonificaciones
Los costos directos están relacionados con los costos de los recursos que varían directan1ente con la duración de una tarea específica; casi siempre los costos directos se miden en unidades mone-
PRESUPUESTO DEL PROYECTO
109
Larias (francos, dólares), pero pueden ser medidos en horas-hombre o en cualquier otra unidad, en tanto que sea mensurable y consistente. Las estimaciones de los costos de mano de obra directa se basan con frecuencia en el concepto de costo estándar, que es una esti mación de la administración del número esperado de horas de mano de obra directa y el costo por hora para producir una unidad. Los costos y las horas estándar se pueden estimar a partir de los datos y la experiencia acumulados por la organización, de información compartida por ouas organizaciones (muchas veces a través de organizaciones profesionales o consultores) o de estudios de tiempos y movimientos. Al estimar Jos costos y las horas estándar debe tenerse cuidado de garantizar que los costos sean estimaciones de los recursos que de hecho se asignarán a las tareas. Por ejemplo, cuando se preparan pronósticos de presupuestos en respuesta a muchas licitaciones del gobierno, con frecuencia las regulaciones requieren que quienes planean el proyecto usen el costo promedio de un recurso dado (programadores, personal de apoyo técnico, secretarias). Considere el caso de quien desarrolla la programación del proyecto que supone que ciertos individuos con experiencia (con salarios superiores al sal~o promedio) se asignarán al proyecto, pero después no comunica esta infom1ación a las personas que preparan el presupuesto. En este caso, los costos reales de mano de obra excederán la cantidad presupuestada para todas las tareas en las que intervengan estos empleados. Los costos de materiales reflejan el costo de adquirir los materiales necesarios para realizar los paquetes de trabajos específicos defin idos (materiales como lápices y cuadernos son parte de los costos generales). De nuevo se pueden usar los costos estándar para estimar los costos de materiales para producir una unidad. Estos costos estándar por lo general ignoran aspectos como descuentos por cantidad y costos de mantener invenLarios. Estos y otros aspectos relacionados se anali zan con más detalle en la última sección de este capítulo. Los costos generales son costos admi nistrativos de la organización que se asignan al desarrollo del proyecto (electricidad, personal de seguridad, biblioteca). Estos costos se pueden basar en una tasa de asignación estándar. Por ejemplo, suponga que la empresa incurre en gastos generales de $ 1 millón ($ 1M) en un año y espera tener en total25 000 horas-hombre distribuidas en varios proyectos. En este caso, la organizac ión puede asignar $40 de gastos generales por cada hora hombre empleado ($ 1M dividido entre 25 000); si un proyecto necesita 1 500 horas-hombre de mano de obra directa, se cargarán 1 500(40) = $60 000 de gastos generales a ese proyecto. Existen .otros esquemas de asignación que comprenden sistemas de costos basados en la actividad (ABC, activity-based costing ). Consulte más de ABC e n Jiambal vo (200 1). Los costos indirectos se refieren a aquellos costos que pueden atribuirse al proyecto, pero que no tienen una relación directa con una tarea específica. Por ejemplo, los proyectos de construcción suelen requerir una barda de seguridad en el perímetro del lugar que se renta por la duración del proyecto. Otros costos indirectos comprenden el costo de los administradores del proyecto y del personal de apoyo, los consultores, el personal de seguridad, etcétera. Estos costos se adjudican por periodos (mes, trimestre) duran te la vida del proyecto. Además, los administradores de proyectos deben considerar los costos de penalización por la violación de la fecha de entrega establecida, así como las bonificaciones ofrecidas por terminar antes (de la fecha de entrega establecida). Estos costos son una parte importante del presupuesto.
Incertidumbre en el presupuesto Uno de Jos aspectos difíciles relacionados con la preparación del presupuesto es cómo incorporar la incertidumbre. Dado que siempre existe incertidumbre respecto a factores como retrasos programados, d isponi bilidad de empleados, pedidos de materiales, etcétera, quienes hacen la planeación del proyecto deben tratar de considerar estas incertidumbres de manera explícita en el presupuesto. Un método para incl uir estas incertidumbres es preparar un intervalo de confianza para el presupuesto; es decir, dadas las estimaciones de las diversas incertidumbres, ¿qué es una probabilidad de 99% (o 95 o 90%) de que el presupuesto esté entre ciertos límites, inferior y superior? Cuando se
110
CAPÍTULO 5
PLANEACIÓN PARA MINIMIZAR COSTOS
definen estos límites explícitos, todos los interesados en el proyecto están conscie ntes de los riesgos relacionados con cualquier presupues to/pro nóstico.
Ejemplo de presupuesto Para ilustrar el proceso de abajo arriba, considere e l ejemplo dado por la red de precedencias en la figura 4.8. En este caso, se supondrá que hay dos tipos de recursos, A y B. Los tipos de recursos normalmente se refieren a grupos homogéneos de empleados (programadores, carpinteros, electricis tas, plomeros y otros) o equipo (tipos de máquinas), aunque también pueden usarse trabajadores específicos. Se supondrá que los empleados tipo A reciben $400 por semana, mientras que los empleados tipo B reciben $600 por semana. (Una semana corresponde a una semana estándar de cuarenta horas de trabajo.) Si no se paga lo mismo a los empleados de cada grupo de recursos, entonces el grupo de recursos se puede subdividir en grupos más pequeños -y más homogéneos- . Por ejemplo, considere a los programadores Bob y Zelda. Si sus salarios por hora son diferentes, "Bob" definirá un tipo de recursos y "Zelda" definirá otro tipo de recursos. La cantidad de cada tipo de recurso necesario en cada tarea se indica en la tabla 5 .1. La información de la durac ió n de las tareas y los tiempos de inic io más cercano y más lejano se tomaron directamente de la figura 4 .8. En este ejemplo se supone que todos los materiales deben estar disponibles antes de iniciar cualquier tarea, de manera que se asignan arbitrariamente los costos de materiales de la primera semana de cada tarea. (Observe que los costos de materiales se pueden dividir y asignar a cualquier número de semanas, si se desea.) Se supone también que la cantidad de empleados indicada se necesila durante todas las semanas que dure la tarea; esta suposición es congruente con las heurísticas empleadas para definir las tareas de una EDT. Es obvio que se pueden establecer otras s uposiciones para asignar costos o empleados por semana. Para ilustrar el cálculo de un presupuesto, considere la tarea A. La primera semana esta tarea requiere $340 en costos de materiales, además de $880 para dos trabajadores de recursos tipo A (a $400 por trabajador), dando un costo directo total de $1 140 en la primera semana. En cada una de las 13 semanas siguientes, la tarea A necesi ta sólo $800 (2 trabajadores tipo A x$400/empleado) para costos de mano de. o bra directa. Si se especifica cuándo inic iarán las tareas no críticas, se pueden indicar directamente los costos semanales por tarea. La hoja de cálculo de la figura 5.2 indica los costos directos esperados para las primeras 12 semanas de este proyecto si las tareas no críticas inician en s us tiempos de inicio más cercanos; la hoja de cálculo de la figura 5.3 indica los flujos de efecti vo cuando las tareas no críticas inician en sus tiempos de inicio más lejanos. La hoja de cálculo completa, con los fluj os de efectivo presupuestados para las 35 semanas de duración del proyecto, se encuentra en el CD-ROM que acompaña a este libro. Se puede graficar Jos flujos de efectivo acumulados cuando las tareas no críticas comienzan en su tiempo de inicio más cercano y s u tiempo de inicio más lejano. Aunque las tareas no críticas FIGURA 5 . 1 Requerimientos de recursos para el ej emp lo de la figura 4.8
Tarea o evento
Duración
lt¡;l
INICIO
o
A
14 9 20 12 6
8
e D E F FIN
Inicio más cercano IIC¡l
o o o o
Número de Número de Inicio más empleados empleados lejano IIL¡l del recurso A del recurso B
o o 5 9 14 29
9
14 26 26
26
o
35
35
Costos de materiales
o
S 340 S 125
o
12 14 8
1
o
S 200 S 560
4
10
S 90
2 4 3
PRESUPUESTO DEL PROYECTO
--
3
2
6
5
4
7
8
9
.:.
1 140
800
800
800
-
8 925
8 800 9 600
8 800
8 800
800 8 800
800 8800
8800
800 8300
9 600
9 600
9 600
9600
9600
9600
19 665 19 200 19 665 38 865
19 200 58 065
19 200
19 200
19 200
19 200
19 200
19 200
77 265 96465
115 665
134 865
154 065
173 265
-
9600
800
800 8 800 9 600
10
11
111
12
800
800
800
9 600
9 600
9 600
10 400
10 400
:l
-
= o
10 400 183 665
194 065 204 465
5 .2 Flujos de efectivo del proyecto en las primeras 12 sema nas inician do l as tareas no c rít i cas en sus ::os de i nicio más cercanos
1140
2
3
4
800
800
800
3
7
5
6
800 8925
8800
800 8 800
800 8 800
9600 22 865
9 600 32 465
9 600 42 065
800
8
~ ~
9
10
11
12
800
800
800
800
8800 9 600
8800 9 600
8 800 9 600
8 800 9 600
19 200 61 265
19 200 80465
19 200 99665
118 865
::1
-
= les
~l es
Diado
1 140 1 140
800 1 940
800 2 740
9 725
800 3 540
13 265
19 200
Fluj os de efectivo del proyecto iniciando las tareas no críti cas en sus tiempos de i nicio m ás lejanos
U RA 5.4
450 000
~ acumulados
para :-:-ogramació n de ini· --as cercano y más oO
350 000
.. -;
300 000
..
200 000
o
~
\
E 250 000
:::1
u
o ;; o
(.)
.. ... ··~
Flujos de efectivo acumulado para el programa de inicio más cercano
400 000
_.r
150 000 100 000
•• •• .• Flujos de efectivo acumulado para el programa de inicio máslejano
.• • .-
50000
o 3
5
7
9
11 13 15 17 19 21 23 25 27 29 31 33 Semana
pueden iniciar en cualquier momento entre sus úempos de inicio más cercano y más lejano, estos valores representan los límites de los flujos de efectivo del proyecto (por lo menos basándose en las estimaciones actuales de costo y duración de las tareas). Estos dos fluj os de efectivo acumulados se muestran en la figura 5.4 La gráfica de utilización de recursos acumulada que se muestra en la figura 5.4 es la salida de algún paquete de software de AP. En ésta es usual que se incluya la gráfica de gastos reales, con la implicación de que mientras los gastos reales se encuentren en la región de fluj os de efectivo acumulado "factibles", los costos del proyecto están dentro de límites aceptables. Sin embargo, el lector deberá tener cuidado al interpretar esas gráficas. Por ejemplo, una señal de que los gastos acumulados reales están fuera de la región facúble puede indicar que el proyecto excede el presu-
112
CAPITULO 5
PLANEACIÓN PARA MINIMIZAR COSTOS
puesto. o simplemente que va adelantado respecto a la programación. Esto se estudia más a fondo en el capítulo 9, que se ocupa de aspecto relacionados con los sistemas de vigilancia y control. Además de los costos acumulados, puede ser útil graficar los flujos de efectivo proyectados con base en la programación de inicio más cercano y más lejano de las figuras 5.2 y 5.3. Como se muestra en la figura 5.5, puede haber una diferencia considerable en los flujos de efectivo para estos dos programas; esa diferencia puede ser ignificativa para la liquidez de una organización, así como para el valor presente neto del portafolio de proyectos. En general los administradores deben tener cuidado al programar las tareas no críticas al considerar y planear el presupuesto.
ADMINISTRACIÓN DE LOS FLUJOS DE EFECTIVO Por lo común, los administradores negocian con el cliente un programa de pagos antes de iniciar el proyecto. Por ejemplo, considere un proyecto de consultoría planeado para una organización cliente. Esta organización acuerda con la empresa de consultoría hacer pagos parciales en ciertos eventos (por ejemplo, al presentar ciertos informes de avance); en otros momentos (digamos, al final de cada mes) la empresa consultora tiene que pagar gastos como salarios del personal que realiza el trabajo. Suponiendo un valor del dinero en el tiempo positivo (es decir, el dinero vale más hoy que mañana), el administrador del proyecto tratará de programar las tareas del proyecto de manera que los pagos que hace su empresa sean lo más tarde posible, mientras que los ingresos ocurran lo más pronto posible. De esta manera, el administrador espera maximizar el valor presente neto del proyecto o alguna meta similar. Para examinar el impacto de los flujos de efectivo en el. valor presente neto del proyecto, considere el ejemplo dado en la figura 5.6. Para simplificar, suponga que las duraciones de las tareas son fijas (en meses); es sencillo extender este método a situaciones más complejas. FIGURA 5 .5 Flujos de efectivo semanales para programás de inicio cercano y lejano
25000
........ 1
5000
1
'~Programa
de inicio lejano
......,6
O+o~rrTT.,rrTT,.-rrooo-orrTO"rr"""roo
1
3
5
7
9
11 13 15 17 19 21 23 25 27 29 31 33
Semana E
o
~
¡
. ~
'i
§
LO ÚNICO QUE HICISTE FUE SENTARTE AHÍ. QUIERO MI REEMBOLSO.
•
: ... DE MANERA .. QUE NO ME : PARECE JUSTO ~
i
)
!QUÉ LÁSTIMA! \
ADMINISTRACIÓN DE LOS FLUJOS DE EFECTIVO
GURA 5 .6 de flujo de - :aivo en una red de ~ dade s en los nodos
113
Hacer pago de$5000
=~plo
-.:l )
Recibir pago de$3 000
Recibir pago de$3000 •
Como se indica en la figura 5.6 y la tabla siguiente, hay tres eventos que representan pagos o ingresos de efectivo. Evento
Desc ripción
M1
Pago de $5 000 por salarios y materiales
M2
Recepción de un pago de $3 000
FIN
Recepción de un pago final de $3 000
Continuando con nuestra suposición usual, ninguna tarea puede iniciar hasta que las tareas (o eventos) predecesores hayan terminado; en este caso las tareas C y O no pueden iniciar hasta que se haga el pago de $5 000 en el evento M l. De igual manera, la tarea no puede iniciar hasta recibir el pago de $3 000 en el evento M2. Observe también que en este proyecto la ganancia neta (ignorando el valor del dinero en el tiempo) parece ser $6 000 - $5 000 = $1 000. Si se ignoran las consideraciones de costo, la ruta crítica es de once meses, como indica la figura 5.6. Sin embargo, considerando los flujos de efectivo, se desea tener en cuenta la programación de eventos y tareas de manera que los pagos ($5 000 en M 1) se hagan tan tarde como sea posible y la recepción de pagos ($3 000 en los respectivos eventos M2 y FIN) ocurran tan pronto como sea posible. En la figu ra 5.6 se puede ver que el evento M 1 no está en la ruta crítica, de manera que el pago de $5 000 se puede retrasar hasta el tiempo 3 (tiempo de terminación más lejano de M 1) sin retrasar la terminación del proyecto. Sin embargo. en los proyectos reales no siempre es posible simplemente programar las cuentas por pagar en sus tiempos más lejanos y las cuentas por cobrar en sus tiempos más cercanos. Estos eventos suelen ser in terdependientes, de manera que reprogramar uno, puede afectar otros eventos y tareas. El modelo de programación lineal (PL) desarrollado en el capítulo 4 se puede adaptar fácilmente para considerar estas interacciones.
114
CAPiTULO 5
PLANEACIÓN PARA MINIMIZAR COSTOS
Intuitivamente, se desea programar las cuentas por pagar tan tarde como sea posible y las cuentas por cobrar tan pro nto como sea posible. Deben considerarse dos fac tores: la magnitud del pago y el tiempo. Así, suponiendo que las cuentas por cobrar definen flujos de efectivo positivos y las cuentas por pagar, flujos de efectivo negaüvos, se puede definir una medida llamada meses-dólar (o días-dólar, etcétera) que es simplemente el producto de cada flujo de efectivo por su tiempo de ocurrencia correspondiente. En el ejemplo de la figura 5.6, los meses-dólar para el pago de $5 000 realizado en el evento M 1 son 5 OOOsM 1 ; los meses-dólar totales de este ejemplo se definen como: Meses-dólar =- 5 OOOsM 1 + 3 OOOsM2 + 3 OOOsFIN Al minimizar los meses-dólar totales se intentará programar las cuentas por pagar (pago de $5 000) tan tarde como sea posible y las cuentas por cobrar (pagos de $3 000) tan pronto como sea posible. El modelo de Excel definido en el capítulo 4 se puede modificar para minimizar los mesesdólar; el modelo de hoja de cálculo modificado y la solución obtenida se muestran en la figura 5.7 (las restricciones de precedencia se dan en la ventana de restricciones del Solver). En la hoja de cálcul o, el valor de los meses-dólar totales se da en la columna "meses-dólar". La solución de la figura 5.7 se obtuvo minimizando este valor (que por sí mismo no tiene significado real o interpretación directa). En este caso, los valores de los tiempos de inicio de los eventos (denotados por s) muestran algo interesante; a saber, que la solución que minimiza los meses-dólar retrasa el tiempo de ejecución del proyecto al mes 12. (Recuerde que la ruta crítica era de 11 meses.) Este retraso permite al administrador del proyecto diferir el pago de $5 000 al tiempo 5 y reducir el lapso entre el pago de $3 000 y los $3 000 que se reciben en el tiempo 8. Este resultado no era intuitivamente evidente, aun en este senci llo ejemplo. La medida meses-dólar usada está estrechamente relacionada con la otra mediada más común del valor presente neto (VPN). Con una tasa de descuento mensual, r, igual a 0. 167 (que corresponde a una tasa de descuento anual de 20%), se puede calcular el VPN de los tres flujos de efectivo (basado en los tiempos de los eventos). En este ejemplo, el VPN total del proyecto se define como sigue: VPN = - 5 000 (1 + r)s~ll
+
3 000 (1+ r)sM2
3 000
+---(1 +d~"IN
Los valores de cada. flujo de efectivo descontado se dan en la celda apropiada de la columna VPN. Al resolver el modelo de la figura 5.7 para max imizar el VPN total del proyecto se encontró la misma solución obtenida al minimizar los meses-dólar (es decir, el proyecto se retrasa a 12 meses). De hecho, el criterio de minimizar meses-dólar tiene una relación estrecha con maximizar VPN. La relación entre estos dos criterios se explica con más detalle en el apéndice 5A al final de este capítulo. Como se indica en el apéndice, la medida meses-dólar es una medida que sustituye bastante bien
FIGURA 5 . 7 Hoja de cálculo d e Excel para el ejemplo del fluj o de efecti vo
COMPRESIÓN DEL PROYECTO: TRUEQUES TIEMPO-COSTO
115
al VPN en condiciones donde la tasa de descuento es razonablemente pequeña. Además, permite usar un modelo lineal que en proyectos grandes puede ahorrar mucho tiempo. También es una medida útil cuando es difícil determinar un valor preciso para la tasa de descuento (como en el caso de organizaciones no lucrativas). Muchos investigadores han estudiado la relación entre flujos de efectivo y programación de tareas en proyectos determinísticos; entre ellos Russell ( 1986); Grinold ( 1972); Yang et al. ( 1993); SmithDaniels y Aquilano (1987); Smith-Daniels y Smith-Daniels ( 1987): Elmaghraby y Herroelen (1990), y Rosenblau y Roll ( 1986). Rosenblatt y Buss ( 1997) estudiaron el efecto de retrasar las tareas en un proyecto estocástico y mostraron que retrasarlas en un entorno aleatorio también puede aumentar el valor presente esperado del proyecto en ciertas condiciones. Por último, observe que el método estudiado en esta sección también es útil al negociar los pagos y establecer los eventos en la etapa de planeación (cuando el administrador del proyecto tiene esta flexibilidad). Si se negocia la programación de los eventos, el modelo sugerido aquí puede ser útil al programar las cuentas por pagar y por cobrar.
COMPRESIÓN DEL PROVECTO: TRUEQUES TIEMPO-COSTO Como se vio en el capítulo 1 y se ilustró en el diagrama de la figura 1.2, la administración de proyectos efectiva requiere decidir los intercambios o trueques entre el diseño y las especificaciones de un proyecto, y entre el tiempo y el costo de ejecución. Puede ser difícil tomar estas decisiones de trueques en especial en un ambiente tecnológico incierto y cambiante. En esta secció n, se analizan con más detalle estas decisiones centrándose en el intercambio tiempo-costo con la suposición de que el diseño y las especificaciones del proyecto se mantienen constantes. Existen muchas razones para reducir la duración de un proyecto (incluyendo la necesidad de poner pronto un nuevo producto en el mercado o de equilibrar los requerimientos de recursos entre varios proyectos). En general, los administradores desean programar un proyecto de manera que se minimicen los costos totales esperados. Para reducir la duración de un proyecto deben considerarse varios tipos de costos, entre ellos, los costos de mano de obra directa asociados con cada tarea, los costos indirectos o generales y los costos respectivos de penalización o bonificaciones por terminar el proyecto tarde o antes. Primero se estudiarán los trueques entre los costos directos y los costos generales o indirectos; después se mostrará cómo se puede extender este enfoque a otros costos. Es común suponer una relación inversa entre los costos directos de una tarea dada y la duración estimada de esa tarea. Por ejemplo, el administrador del proyecto puede reducir el tiempo necesario para terminar una tarea asignándole más empleados, comprando o rentando equipo más rápido (supuestamente más costoso), asignando tiempo extra, etcétera. Esta relación inversa casi siempre se cumple, al menos en cierto intervalo. Por ejemplo, considere la observación hecha por Brooks (1995) respecto a proyectos de desarrollo de software: Observe que para un programador, igual que para un chef, la urgencia del patrón puede regir la fecha de terminación establecida de la tarea, pero no puede regir la terminación real. Un omelet, prometido en diez minutos, puede parecer que va bien. Pero, cuando no queda listo en los diez minutos, el cliente tienen dos opciones: esperar o comerlo crudo. Los clientes de software tienen las mismas alternativas. El cocinero tiene otra alternativa: puede aumentar el fuego. El resultado con frecuencia es un omelel con una parte quemada y otra cruda. (p. 21) Es claro que el problema es que los administradores de proyectos siguen agregando recursos a una tarea, aun cuando ya alcanzó el límite de reducción en su duración. El omelet, el concreto y el software necesitan un tiempo específico que ningú n número de cocineros, trabajadores o programadores puede disminuir. En los proyectos reales, estimar cuánto se puede reducir una tarea es una aproximación burda; no siempre es claro cuándo una tarea ha llegado a su "límite de aceleración".
116
CAPÍTULO 5
PlANEACIÓN PARA MINIMIZAR COSTOS
Dada esta incertidumbre, aunada a la presión por cumplir con las fechas de entrega meta, no es de sorprender que los administradores de proyectos con frecuencia igan agregando recursos a una tarea. más allá del punto en el que es económicamente razonable. Para ilustrar el trueque básico entre tiempo y costo directo, considere la red de precedencias que se muestra en la figura 5.8 con la información del costo y duración de cada tarea en condiciones "normales". Este costo y duración normales representan la combinación de cotos directos y duración de la tarea estimados inicialmente en la EDT. Este punto representa el menor costo directo para terminar cualquier tarea; se supone que es técnica o políticamente imposible realizar cualquier tarea por un costo directo menor. En la figura 5.8 se dan también los costos marginales de reducir un a semana la duración de cualquier tarea. Así el costo directo de realizar la tarea B en cuatro semanas es $85 + 2($5) = $95. Suponga en este ejemplo que la duración de todas las tareas se puede reducir a lo más dos semanas. Con la duración normal de las tareas dada en la figura 5.8, el proyecto tomará 22 semanas (como lo indica la ruta crítica INICIO-A-C-FIN). El costo directo total para terminar el proyecto en 22 semanas es $320, que es la suma de los costos normales. Ahora suponga que se quiere reducir una semana la duración del proyecto, a 21 semanas. Es claro que se quiere lograr esta reducción en el programa con el mínimo incremento posible en los costos directos. Aunque la tarea D es la que tiene el menor costo marginal ($4), reducirla no disminuiría la duración del proyecto ya que D no está en la ruta crítica. Así, disminuir la duración de la tarea D sólo daría un aumento en los valores de holgura; la mayoría de las organizaciones racionales evitan esta práctica. Entonces, sólo se puede considerar reducir la tarea A o la tarea C (tareas críticas); como la tarea A tiene el menor costo marginal, se reducirá su duració n de 7 a 6 semanas y aumentarán $8 Jos costos directos del proyecto (a $328). La duración del proyecto se reduce a 21 semanas y se tienen dos rutas críticas: INICIO-A-C-FIN e INICIO-B-C-FIN. Para reducir aún más la duración del proyecto (a 20 semanas), de nuevo deben considerarse todas las tareas críticas: A, B y C (ignorando los eventos pues no pueden reducirse). En este caso la tarea B es la del menor costo marginal ($5) de las tres; sin embargo, al reducir un a semana la tarea B sólo se reduciría una de las rutas críticas. Como la ruta crítica INICIO-A-C-FIN quedaría en 2 1 semanas, no disminuiría la duración del proyecto. Es importante recordar que es necesario reducir todas las rutas críticas para lograr reducir la duración del proyecto. Como la tarea A tiene el siguiente costo marginal más pequeño ($8), se puede considerar reducir tanto la tarea A como la B con un incremento total de $ 13 en los costos directos. Como se reducen las dos rutas críticas, el proyecto se reducirá una semana. Sin embargo, se observa que la tarea C está en las dos rutas críticas y reducirla una semana disminuirá la duración del proyecto una semana
FIGURA 5 .8 Redu cción de la duración de un proyecto aumentando los costos directos
Duración normal
Costo normal
Costo marginal para acelerar una sema na
A
7
B
6 15 10
$ 60 $ 85 $ 55 $120
$ 8 $ 5 $10 $ 4
Tarea
e D
COMPRESIÓN DEL PROYECTO: TRUEQUES TIEMPO-COSTO
1 17
con un incremento de $1 O en el costo marginal. Como este costo es menor que $13, se decide reducir una semana la tarea C y aumentar los costos directos totales del proyecto a $338 (= $328 + $ 10). Se podría continuar reduciendo de esta manera la duración del proyecto hasta llegar a 18 semanas. En ese punto hay por lo menos una ruta crítica (INICIO-A-C-FIN) que ya no se puede reducir. Los pasos para reducir este proyecto de 22 semanas a 18 se resumen en la figura 5. 9. Observe también que los costos marginales directos aumentan a una tasa creciente conforme se reduce la duración del proyecto (es decir, la primera semana de reducción del proyecto cuesta $8, la segunda semana cuesta $10, etcétera), aun cuando los co tos marginales de cada tarea son constantes. Esto se debe a que e reducen primero las tareas de menor costo, dejando para después las más costosas. Como indica este sencillo ejemplo, la elección de la tarea a reducir en cada periodo no es evidente (como elegir qué tareas acelerar al reducir la duración del proyecto de 21 a 20 semanas). En proyectos más grandes y realistas, encontrar qué tareas acelera puede ser un problema de combinatoria complicado. Los programas de software para AP ofrecen poca o ninguna ayuda a este respecto.
Trueques lineales tiempo-costo No obstante, hay una manera de formular un modelo de programación lineal (PL) que encuentre el conjunto de tareas para acelerar en cada iteración. En este caso, suponga que el costo marginal de acelerar una tarea es constante (como en el ejemplo anterior). De manera alternativa, los administradores de proyectos algunas veces estiman tanto un punto normal para cada tarea como un punto acelerado que define la menor duración posible de la tarea (y el costo directo máximo correspondiente). Se supone que en el punto de aceleración es técnicamente imposible reducir más la duración de la tarea, au nque se asigne una cantidad infinita de recursos. Suponiendo una relación lineal entre los puntos normal y acelerado (es decir, un costo marginal constante para acelerar una tarea), la figura 5. 1O da los trueques tiempo-costo para la j-ésima tarea. El costo marginal de acelerar la tarea una unidad de tiempo está representado por la pendiente de la recta en la figu ra 5.10, que se denota por br Como se indica en la lig ura 5.3, se usará la notación siguiente: t j N = duración normal de la tarea
tf
=duración mínima posible (aceleración) de la tarea
C j N = costos directos normales
et ~U RA 5 . 9 :::mp lo de reducción a duración de un
-:;(eCtO
= costos directos en el punto acelerado
Duración del proyecto (semanas)
Ruta(s) crítica(s)
Tarea(s) reducida(s)
Costo de mano de obra directa
22 semanas
INICIO-A-C-FIN
21 semanas
INICIO-A-C-FIN INICI0-8-C-FIN
A
$328
20 semanas
INICIO-A-C-FIN INICI0-8-C-FIN
e
$338
19 semanas
INICIO-A-C-FIN INICI0 -8-C-FIN
e
$348
18 semanas
INICIO-A-C-FIN INICI0-8-C-FIN
A,B
$361
$320
118
CAPÍTULO 5
PLANEACIÓN PARA MINIMIZAR COSTOS
FIGURA 5 .10 Trueques tiempo-costo para la tarea j
Costo Costo de aceleración =
Punto acelerado /
e;
Pendiente (b¡) = costo de reducir la tarea una unidad de tiempo
/ Punto normal
Costo N normal= C¡
- - - - - - - ---- -- - ---- -- ---- - - - --1
/
1
L-----------------------------------------~--•Tiempo
t7
Tiempo acelerado=
Tiempo normal=
tf
Suponiendo una relación lineal entre los puntos nonnal y acelerado, el costo marginal de reducir la duración de la tarea es la pendiente bj, definida como:
bj
=
cr -ct N
tj
A
- tj
Observe que la pendiente es negativa, lo que indica que aumentar los costos directos reduce la duración de la tarea. Usando este trueque lineal tiempo-costo, se puede revisar el problema combinatorio para encontrar qué tareas acelerar para una duración del proyecto dada. Suponga que Tmáx es la duración deseada del proyecto. Entonces el problema de encontrar las duraciones de las tareas que mi nimizan los costos directos totales (sujetos a la restricción de que la duración del proyecto debe ser igual a Tmáx) se puede fonnular modificando el modelo de programación lineal (PL) descrito en el capítulo 4. Este modelo modificado, ahora tiene dos variables de decisión (tiempo de ocurrencia de tareas y eventos y duración de tareas): s . =tiempo de inicio de la tareaj
FIN = tiempo de tenninación del proyecto tj
= duración de la tarea j
Para cada tarea j del proyecto, el tiempo t1 (ahora una variable de decisión) debe estar entre la duración nonnal y la duración acelerada Las restricciones de precedencia empleadas en el modelo anterior de PL no cambian. E l costo directo de cualquier tareaj se puede encontrar si se conoce el valor de t/ De la figura 5.1 O, el costo directo para una duración tj de la tarea es
rt
t/-
C.N + b {t .- / .N) = CN + b.J . -b.t_N J
) )
J
J
))
))
donde bj :5 O. Por lo tanto, el costo directo total del proyecto es Minimizar
Eblj j
tJA
< -
"! para todas las tareas;· del proyecto
t. < t J J
Como el segundo término en esta función de costo es una constante, se puede eliminar de la función objetivo. El problema de programación lineal modificado. para encont rar los tiempos de
COMPRESIÓN DEL PROYECTO: TRUEOUES TIEMPO-COSTO
119
inicio y la duración de las tareas que minimizan los co tos d irectos totales para una duración dada del proyecto Tmáx' puede plantearse entonces como
+ '¿(Cj
'¿ bjtj
- b/j )
j
sujeta a
t/ :=:; tj :=:; sj ~ s¡
t/
+ t,
para todas las tareas j del proyecto para todas las tareas i del conjunto
FIN
:S Tmáx
s¡ ~
O
Pj
para todas las tareas i
La figura 5.1 1 muestra la hoja de cálculo y el modelo de Solver para el problema de la figura 5.8, cuando Tmáx = 19 semanas. (Observe que las variables de retraso fueron omitidas, pero sería sencillo incorporarlas.) La solución para una duración de 19 semanas es la misma que la dada en la tabla de la figura 5.9: los costos directos totales son $348, la tarea A se redujo una semana y la tarea C se redujo dos semanas. Ahora se pueden considerar las alternativas entre costos directos y costos de otros proyectos. Por ejemplo, puede desearse reducir la duración de un proyecto con objeto de reducir los gastos generales o indirectos. Conceptualmente, este trueque se represen ta en la figura 5.12. Como se indica, se desearía programar el proyecto en el punto de costo IOta! mínimo. El modelo de PL que mi nimiza los costos directos puede extenderse para incluir otros costos. Por ejemplo, si cj denota los costos indirectos y generales por semana, entonces la función objetivo para minimizar los costos totales directos e indirectos se puede escribir como sigue: Minimizar '¿ b/j
+c1FIN
j
De manera similar se pueden agregar modelos al costo de penalización por terminación tardía (o bonificación por termin ar antes). De nuevo, sea Tmáx una fec ha de terminación dada. Si P es el
~ URA
5 . 11 elo de Solver -:ara el ejempl o de
.Ee.eració n
T~Sbli>lg
r.....,
t::wafio... (
Yorio•tu
Yolws
START STARTA STARTB STARTC STARTD END
o o o
lA lB
6
te
9 19 19
~
TQ$k Fm!slt TUKS
1J) Vol un
Yorlo•lu
6 6 13 10
t
Normal
-
o
o
6
1
6
6 iS
19 19 19
o
$
Oi rect tostiTuk=
68
$
Te lo l Olrnl Co•h = t
1$
85
1$
75
1t
~
So !ve
1
348 1
: Solver Parameters Set Tarqel Cell·
lrorcosr 1~
Equal lo: QMax ~ Mon By C~aatlll9 Cc ll o:
O Value of· ~
lsTART.HND;tA:tD
lñJ
EllO •• fiiiiS~P
fllliSH.\ >• ST4RT flNIS~B >• START STAIHA >• START
~~
[QO!;J
1 Guess 1
S••Ject to IM CoMtrolab : END • iti24 (liD >• fiNISHC
$ $ $ $ $ $
lO
1
Add
J
1
tlons 1
1Chan~e) [Reset AHI 1 Oelete l [
Het
1
120
Crasb
Cut
Oaroliu
1
Our a tiu
Slofe 0>;)
o 60 85 55 120 320
5
~
4 13 8
S
o
$
8 5 10
S
4
120
CAPÍTULO 5
PLANEACIÓN PARA MINIMIZAR COSTOS
FIGURA 5.12
Costo total contra duración del proyecto
Costo
1
Costos ~ generales 1 1 e indi rectos
'
1
L-----------------------~--------------------+ Tiempo
Tiempo acelerado
Solución de costo mínimo
Tiempo normal
costo de pena lizac ión por semana si e l proyecto se retrasa después de la fecha de entrega Tmáx' entonces la función objetivo se puede modificar de manera que inc luya esta penalización. Minimi zar ¿bjtj+ c1 FIN j
+
PL
donde L = número de semanas que se retrasa e l proyecto respecto a =máx (0, FIN - Tnw.)
T máx
El valor L se conoce como la demora del proyecto. Aunque L se puede definir en un modelo de Solver usando la función máx, también se puede definir L mediante una relación lineal. En este caso, la función objetivo es la misma, pero se agrega una restricción al modelo de PL: F IN -L ~ Tmáx
Como todas las variables (i ncluso L) deben ser no negativas, L representa el número de semanas, después de la fecha de entrega, para terminar el proyecto. Si e l proyecto termina antes de la fecha de entrega (esto es, FIN< Tnw.), entonces L es ig ual a cero, ya que e l objeti vo de este modelo es minimi zar el costo. El modelo modificado en hoja de cálculo que minimi za los costos totales del ejemplo anterior se presenta en la figura 5.1 3. Aunque la fecha de entrega Tmáx sigue en 19 semanas, ya no se usa Tmáx para definir una restricción "dura" (es decir, se elimina la restricción FIN ~ 19). Así, las únicas restricciones que quedan en este modelo son las de precedencia y las que requieren que las duraciones de las tareas estén e ntre los tiempos normal y acelerado. Para de finir los costos, se estableció P (el costo de penalización semanal por no cumplir con la fecha de entrega Tmáx) igual a $5 por semana. El costo general e indirecto, e , es igual a $7. Se usó la función máx para definir los costos de penalización, si los hay. Como s/indica en la figura 5. 13, el costo total mínimo es igual a $48 1. En la solución final se aceleran la tarea A una semana (a 6 sema nas), y la tarea C dos semanas (a 13 trece semanas). Es senc illo agregar una bonificación por termjnar antes de la fecha de entrega al modelo en hoja de cálculo de la figura 5.13, usando un e nfoque parecido al que define el costo de penalizac ión. De la misma manera se pueden incluir otros costos.
COMPRESIÓN DEL PROYECTO: TRUEQUES TIEMPO-COSTO
FIGURA 5.13 ~odel o en hoja de cálculo para m i nimizar os costos totales del proble ma del ej emplo
121
Mo:pnol Cost Norm>l Ourulol\
Tasl:. 8
7 6
o
15 10
A
e
toCras'h~
Wuk
Nom>o!Cosl $60
$8 SS
$85 $55 S1 20
w
=
DecisioiJ >Wñ4bles: ~ Duration of tlsk . STARTj - Slarting time of ta.sk j
PanJmtJus:
Overhead coSIIvA< =
$7
Penalty costlwk •
SS T
Vol uu
ST/>.RT STARTA STilRTB STARTC
. ... : 0 ·.:.:. ~ 0 -' . ···:· ·.: ::: O·.···
:¡
·:?·· ·· 6 ·· ·:
[}/~.:-: _::-:::
Oirect C.•tiT..t •
S
68
$ S
348
1j
Tnl-8
o
o
$
6 6 19 19 19
1 6
S S S
15
S S
10
o
115
!
T•3rC
S
75
1S
T4~r D
120
Ottntioa
Cut
S T•ull
Cr.lsh
Normal 011ratiea
Ver iobl""
sr:¿o
nm...
~ ( l j)
TO!ii.~Tu:vs
SJ..pe (l>j)
o 60 &5 55 120
5 4
$
2
S
13
S
5 10
3
$
4
o
320
1
t33
S 481
Trueques no lineales tiempo-costo En la figura 5.10 se supuso que el intercambio entre el punto normal y el punto acelerado es lineal; es decir, el costo marg inal de reducir la duración de la tarea es constante. Por supuesto, esto no siempre es cierto; algunas veces los costos marginales aumentan o disminuyen al reducir la duración de una tarea. En la figura 5.14 se ilustran dos casos; en el primero, los costos marginale aumentan con una tasa creciente (una función convexa) . Esto ocurrirá cuando la reducción inicial en la duración es relativamente sencilla; por ejemplo, el personal existente puede trabajar horas extra. Sin embargo, é l tiempo extra puede estar limitado (quizá por restricciones sindicales). Entonces, una mayor reducción en la duración de la tarea puede requerir contratar nuevos empleados o comprar equipo más costoso. De cualquier manera, los costos marginales de reducir más la duración de la tarea aumentarán. En el segundo caso ilustrado en la figura 5.14 (función cóncava), el costo marginal decrece conforme disminuye la duración de la tarea. Esto puede ocurrir cuando se re-quiere un equipo valioso para lograr una reducción inicial en el tiempo; por ejemplo, tal vez una empresa tenga que rentar una bomba de concreto para reducir el tiempo necesario para verter el cemento de los cimientos de un proyecto de construcción. Una vez rentada la bomba, se pueden contratar más trabajadores a un costo relativamente bajo, para ayudar en la construcción de obra negra y el trabajo de concreto. G URA 5.14 - _eques no lineales ¿m po-costo
Costo
Costo /Punto acelerado
Punto norma l ~ L------------~Tiempo
Trueque t iempo-costo convexo
'-------------~ Tie mpo
Trueque tiempo-costo cóncavo
122
CAPÍTULO 5
PLANEACIÓN PARA MINIMIZAR COSTOS
Es sencillo cambiar el modelo de programación lineal ilustrado en la figura 5.13 para el ca o del trueque convexo tiempo-costo. Cuando el intercambio e ntre tiempo y costo es cóncavo, es un poco más co mplicado y está fuera del alcance de este libro. El lector interesado debe consultar Levy y Wicst ( 1977). En los dos casos se puede aproximar la c urva no lineal del trueque tiempo-costo usando van.:.:. funci ones lineales. Por ejemplo. considere el trueque convexo tiempo-costo de la figura 5.1 5. Aq se usan dos funciones lineales para aproximar la función convexa no lineal; cada función line<:. define una subtarea que tiene sus propios puntos normal y acelerado. La tarea original j está definida por la suma de estas dos subtareas. En e l ejemplo de la figura 5.15, e n un inicio se desea reducir la subtarea }2 (ya que su cos.. marginal es menor que el de la subtareaj 1) . Después de reducir a cero la duración de la subtarea,csc puede reducir la duración de las subtareas } 1 de )' al punto g lobal de aceleración La figun. 5.16 muestra los puntos normal y acelerado de las dos subtareas. Por ejemplo, considere la modificació n del ejemplo de la figura 5.8. Recuerde que la tarea C se podfa reducir cuando mucho dos semanas (de 15 a 13) con un costo marginal de $ 1Opor seman~ Ahora suponga que el costo de reducir la tarea C la segunda semana a ume nta a $13.50 (el costo de acelerar la primera semana aún es $10). Para incl uir esta nueva información, se modifica la hoja de cálculo de la figura 5.1 3 dividiendc la tarea C en dos subtareas, CJ y C2 (vea la fig ura 5.17). La durac ión normal de la subtarea C2 es igual a 15 - 14 l semana, con una duración de colisión igual a O. La duración nom1al de la subtarea Cl es 14 semanas, con una duración acelerada igual a 13. Como se conocen las pendientes ($10 y $ 13.50, respectivamente), se pueden introducir directamente en el modelo modificado en la hoja de cálculo. Observe que la durac ión de la tarea C ahora se define por la suma de las dos subtareas, 'e• y t C2. El modelo modificado e n la hoja de cálcul o para minim izar los costos totales definidos por la suma de los costos directos y los costos generales e indirectos ($11 por semana) se muestra en la figura 5.17.
t/-
=
FIGURA 5.15
Trueque tiempo-costo convexo
Costo
e¡A --- --
Punto acele rado
¿
'---- - - - ---.1.....- -- - - - - -- - - - - + Tiempo Tiempo acelerado= tj Tiempo norm al =
rf
FIGURA 5 . 16
Puntos norma l y acelerado pa ra las dos subta reas de la figura 5.15
r7
Acelerado
Nonnal Duración
Costo
Duración
Costo
Subtarea h
r:-tj
e"!1
o
e'1.
Subtarea j¡
tj
o
f¡
f¡
e"!1
f¡
Tarea j
CCII.f?.::3C- DEL PROYECTO: TRUEOUESTIEMPO-COSTO
123
=a o en hoja de Jo modificado con
TuJ-A
Oirect Cost/Taot•
"$68
Tatol Dlrect C.Sts • Ovorlocl4 costo Totol Cl$1
$338 S220 $558
= =
$8S •.
1
so
Tn~C
.$65.0
t65 0
En la solución dada, el proyecto se acelera dos semanas para minimizar los costos totales; la tarea A se acelera una semana y la tarea C, una semana, de 15 a 14 semanas (la subtarea C2 se acelera a O y la tarea C 1 no se acelera). Esto se debe a que estas tareas pueden reducirse a un costo marginal de $8 (tarea A) y $10 (tarea C2); la diferencia implica un ahorro en el costo general de 2 x $11 =$22. Cualquier aceleración adicional del proyecto costará más ($13/semana al acelerar las tareas A y B) de lo~que podría ahorrarse en costos generales e indirectos ($ 11 por semana).
Trueques tiempo-costo discretos En algunos casos las tareas sólo pueden realizarse en ciertos modos o puntos discretos. En un proyecto de desarrollo de software, por ejemplo, tal vez el administrador sólo disponga de ciertos programadores y tenga que asignar a uno de ellos al proyecto. En este caso, cada modo representa un empleado específico e indica una estimación del tiempo requerido por cada individuo (y su costo asociado) para realizar la tarea de manera satisfactoria. La figura 5.18 ilustra el caso en que hay tres modos posibles para realizar una tareaj. Los tiempos de las tareas en cada punto (modo) se denotan tf, donde k es el número del punto (en la figura S. 18, k= 1, 2, 3); los costos asociados se denotan de manera similar por Cf. Para modificar el modelo de Solver con modos discretos es necesario usar variables de decisión binarias (como O, 1), Yjk' donde: 1 si la tarea} se reali za en el modo/punto k
Y·k 1
= {O de otra manera
Por ejemplo, si se desea minimizar los costos directos totales, la formulación de programación lineal es directa. Si la tarea se realiza en el modo k, la duración y costo de la tarea} son iguales a yf y yf, respectivamente. Si se incluyen restricciones de opción múltiple que requieren que
t/
C/
124
CAPiTULO 5
PLANEACIÓN PARA MINIMIZAR COSTOS
FIGURA 5. 18
Trueque tiempo-costo discreto
Costo
e~ 1
Punto / acelerado #1
-----·K
Punto ¿intermedio #2
1
c21 ------'--------- - -- •
Punto ¿normal #3
1
e~ 1
-----J
1
1
- - - - - - - - - - - -
-1- -
-
-
-
-
-
-
-
-•
1
L-------------------------L-----------~------~ Ti e m p o
Tiempo acelerado=
t}
tJ
Tiempo normal=
tJ
sólo una variable yf sea igual a uno (para que la tarea se realice en un modo o punto), la formulación de programación lineal se conviene en: 3
Minimizar el costo directo total= LLC/ Yjk j
k=l
suj eta a 3 L Yjk = 1 para todas las tareasj
k=l 3
S j 2': S¡ + L t /
y jk para toda j E P¡
k= l -
Yjk
Sj
= (0, 1) para todas las tareasj ;::=:
O para todas las tareas j
donde Sj denota el tiempo de inkio de la tarea}. La hoja de cálculo ~el problema presentado en la figura 5.8 se da en la figura 5.19 donde las cuatro tareas deben realizarse sólo en sus puntos normal o acelerado. Observe que en este modelo las duraciones de las tareas no son variables de decisión; las variables de decisión son los tiempos de inicio de las tareas, Sj, y las variables de decisión binarias Y¡k· Como en este ejemplo sólo hay dos modos posibles para cada tarea, sólo se necesita una variable binaria para cada una (además de las variables continuas que representan los tiempos de inicio de las tareas). Si YjN denota la variable binaria que indica si la tarea se realiza en el tiempo y costo normal, YjC = l - YjN si la tarea se reali za en el tiempo acelerado y al costo acelerado. Por lo tanto, en nuestra hoja de cálculo hay seis variables continuas de decisión que indican los tiempos de inicio de las cuatro tareas y los dos eventos (INICIO Y FIN), y cuatro variables binarias de decisión. Como se indica en la figura 5. 19, se desea minimizar los costos totales del proyecto definidos por la suma de los costos directos y los costos indirectos y generales ($11/semana). La solución óptima indica que tres tareas (A, B y D) se realizan con sus duraciones y costos normales, mientras que la tarea C se establece en su punto acelerado ( 13 semanas con un costo de mano de obra directa de $75). El costo mínimo total es $560 y el proyecto terminará en 20 semanas. Es interesante comparar estos resultados con la solución en la figura 5.17, en donde se permitieron trueques continuos (pero no lineales) tiempo-costo entre los puntos normal y acelerado.
R GURA 5 . 19 de trueque ":mpo-costo discreto
~e mplo
Tczsk &mi"€ Tll1W5 Yarlebles START STARTA STARTB STARTC STARTD
END
13
8 60
OVerl>ca• Costhtlc =
$
1$
85
1$
1S
1S
, .,..
11
Tatal Olrecl Cosls • Overl>c.. ~uts • Teta1 C.5t •
Cuando las tareas se restringe n a modos discretos, el costo mínimo total siempre será por lo menos igual al del caso continuo, ya que el problema discre to tiene más restricciones. En este ejemplo. el caso discreto es más costoso que e l continuo ($560 versus $558), aunque ambos proyectos se aceleraron a 20 semanas.
Trueques tiempo-costo con consideraciones de coordinación y comunicación En su libro, Brooks ( 1995) estableció que "agregar personal a un proyecto de software retrasado lo retrasa más". Esta afirmación se ha llegado a conocer como ley de Brooks, y coincide con observaciones similares como la observación de Hughes ( 1986) de que muchos proyectos han fracasado por tener demasiado personal, pero 9ue ninguno ha fracasado por tener muy poco personal. ¿A que se debe esto? Si hubiera una relación inversa entre duración de la tarea y costo directo, se pensaría que aumen tar recursos (en este caso, programadores) a un proyecto reduce la duración de la tarea y del proyecto. La ley de Brooks y las observaciones de Hughes se basan en el hecho de que un incremento en el tiempo de comunicación y coordinación suele ser una consecuencia de aumentar trabajadores a una tarea. Como se vio en el capítulo 3, el número de relaciones interpersonales aumenta exponencialmente al agregar personas a una tarea o equipo de proyecto. En algún punto, la carga adicional de comunicación y coordinación que resulta del aumento de personal se vuel ve contraproducente y de hecho empieza a incrementar la duración global de la tarea. Esto ocurre especialmente en los proyectos de software, donde e l código de computación se debe coordinar e integrar en un producto final. Para ilustrar lo que pasa cuando los tiempos de coordinación se incl uyen en los trueques tiempo-costo usuales, considere un pequeño proyecto de desarrollo de software para desarrollar un programa que requiere aproximadamente 50 000 líneas de código en el lenguaje Perl. * Suponga que un programador típico puede escribir 1 500 líneas por semana. Según el anál isis del capítulo 3 respecto al número de relaciones interperso nales e ntre los miembros de un equipo de proyecto, el tiempo de coordinación (en semanas) se define por MC2 = M(M - 1)/2, donde M es el número de programadores contratados para el proyecto. A medida que el admi nistrador del proyecto contrata más programadores, se reducen sus tareas individuales y sus tiempos de trabajo asociados. Sin embargo, como se indica en la figura 5.20, la reducción marginal en el tiempo de programación se contrarresta con el incremento marginal en
* Las líneas de código no son una métrica adecuada para proyectos de software. pero se usa aquí de todas maneras.
126
CAPITULO 5
PLANEACIÓN PARA MINIMIZAR COSTOS
FIGURA 5.20 Trueque tiempo-costo con coordinación
Número de programadores
1 2 3 4 5 6 7 8 9 10 11
Número de semanas de programaci ón
Número de semanas de coordinación
33.33 16.67 11.11 8.33 6.67 5.56 4.76 4.17 3.70 3.33 3.03
o 1
3 6 10 15 21 28 36 45 55
Núm ero total de semanas
33.33 17.67 14.11 14.33 16.67 20.56 25.76 32.17 39.70 48.33 58.03
el tiempo de coordinación a medida que se agregan más programadores al proyecto. Como se ve, el tiempo necesario para este proyecto hipotético se minimiza con tres programadores (la duración asociada es 14.11 semanas), mientras la duración del proyecto aumenta a 14.33 semanas si se contrata un cuarto programador. Aunque la relación en este ejemplo es una aproximación, es claro que el concepto se satisface y puede explicar las observaciones tanto de Hughes como de Brooks.
COSTOS DE MATERIALES E INVENTARIO En el capítulo 2 se vio que deben tenerse en cuenta los costos de materiales al determinar el presupuesto de un proyecto y se aprendió que los costos de materiales pueden ser un factor significati vo al estimar los costos de un proyecto. Además, los costos de materiales pueden afectar radicalmente los flujos de efectivo, dependiendo de cuándo se ordenan y reciben los materiales; inversamente, los materiales pueden retrasar un proyecto si no se dispone de ellos en el momento en que se necesitan. En general se supone que las tareas no pueden iniciar hasta que se disponga del material necesario. Dado que los retrasos por falta de disponibilidad de materiales pueden ser costosos, parece obvio que objetos de bajo costo (artículos de oficina, tuercas, tomillos, etcétera) se ordenen con suficiente anticipación a la realización de la tarea y se almacenen hasta que se necesiten. Estos artículos casi siempre se clasifican como artículos "tipo C"; si desea más información de los esquemas de clasificación de materiales vea Nahmias (1997) o Davis et al. (2003). Mantener materiales en inventario es costoso; los costos comprenden no sólo deterioro, mermas y seguros, sino también el costo de oportunidad en que se incurre al mantener recursos invertidos en materi ales y no en opciones generadoras de ingresos (como bonos). Dado que este costo de oportunidad constüuye la mayor parte del costo de mantener materiales en al macén, la mayoría de las organizaciones usan una tasa de costo anual de mantener inventario para calcular el costo de mantener una unidad de material en almacén durante un año. Los valores comunes de las tasas de costo de mantener inventario un año van de 15 a 40%. En el enlomo de un proyecto, los materiales se consumen durante toda la tarea y se transforman en componentes, subensambles o productos finales. Si se supone que el valor de las componentes, subensambles, productos finales, etcétera, es mayor que el valor de los materiales empleados para hacerlos, entonces los costos de mantener inventario se podrán reducir retrasando una tarea (aunque pueden aumentar otros costos). Es decir, si una tarea agrega valor a las materias primas y los costos de mantener inventario son proporcionales al valor del producto, entonces se entiende que los costos de mantener siempre se reducen almacenando materias primas en lugar de productos terminados (o intermedios).
COSTOS DE MATERIALES E INVENTARIO
127
¿Qué implica esta suposición? En un entom.... dc:rerminístico, significa que todas las tareas que tengan costos de materiales significativos deben p15p0oerse tanto como sea posible (esto es. iniciar en su tiempo de inicio más lejano). Pero, ¿siem¡re debe ser así? ¿Debe e l adm inistrador del proyecto alguna vez considerar retrasar el proyecto ¡x:n ..borrar costos de mantener o de ordenar? Para estudiar estos aspectos, vea el ejemplo ~atado en la figura 5 .2 1. En este proyecto hay seis tareas; dos de ellas (B y E) usan sólo una ::Jl31e'ri:! prima. La tarea B necesita 2 unidades y la tarea E, 30 unidades. En la figura 5.21 se indica wdara ión y el tiempo de inicio más lejano de cada una de las seis tareas; la ruta crítica es de 1 ~ semanas (INICIO-A-B-C-FIN). Siguiendo las suposiciones usuales respecto a la administración de inventarios (Davis et al. 2003), se supone que hay un costo fijo de oo:iemr denotado por S. Para si mplificar este análisis, suponga que el costo de almacenar materias ~es proporcional al número de "semanas-unidad" de materia prima, aunque este valor puede com-enuse en costos reales si se conoce el costo de mantener inventario y los costos de lo rruue:na1es. Según el análisis anterior, suponga que es más costoso almacenar el producto final o el intermedio que se obtiene como resultado de una tarea, que las materias primas empleadas para hacer este producto tntermedio o final. Por último suponga que el proyecto se puede retrasar a un costo P por semana Es claro que una opción para ordenar las 32 unidades o materia prima es ordenar todos los materiales al principio del proyecto y almacenarlos hasta que se necesiten (es decir, hasta el tiempo 4 para la tarea B, y el tiempo 12 para la tarea E, suponiendo que inician en su tiempo de inicio más lejano). Si se opta por esta política de ordenar, el costo asociado será igual a S+ (4 x 2 = 8) semanas-unidad + (30 x 12 = 360) semanas-unidad = S + 368 semanas-unidad. (Suponga que los costos de almacenar se acumulan sólo hasta que inicia la tarea; esta suposición no es restrictiva y es fácil relajarla.) Sin embargo, como el proyecto es determinístico, parece haber pocas razones para almacenar la materia prima desde el tiempo cero. Si se surtieran las 32 unidades en el tiempo 4, estarían disponibles cuando se necesitaran para las dos tareas (es decir, se tendrían en el tiempo 4 para la tarea B y en el tiempo 12 para la tarea E). En este caso, el costo de almacenar se reduciría a S+ (30 unidadcs)(8 semanas)= S+ 240 semanas-u nidad. (Una vez más, los costos de almacenar materia prima se reduc irían si la tarea E iniciara antes de su tiempo de inicio más lejano; sin embargo, sería más costoso almacenar el producto terminado de esta tarea que las materias primas para hacerlo.) Otra posibilidad sería que los materiales se entregaran en dos envíos. Dada esta opción se desearía que las unidades para la tarea B se surtieran en el tiempo 4 y las de la tarea E en el tiempo 12. De esta manera los costos de material serían igua l a (2S) y no habría costos de almacenaje, ya que la materia prima se surtiría "justo a tiempo". Esta opción tambié n indica por qué nunca deben dividirse las órdenes, por ejemplo, ordenar 12 unidades en el tiempo 4 y 22 unidades en el tiempo
;¡GURA 5.21
=-:!mplo de JCministración ;a material
128
CAPÍTULO 5
PLANEACIÓN PARA MINIMIZAR COSTOS
12. En este caso se incurriría en un costo fijo por orden de (2S) (ya que se harían dos envíos), y se incurriría también en un costo de mantenimiento de ( LO unidades)(8 semanas) = 80 semanas-unidad, ya que 1Ode las unidades surtidas en el tiempo 4 tendrían que conservarse hasta el tiempo 12 para usarlas al ejecutar la tarea E. También puede considerarse la posibilidad de retrasar el proyecto con objeto de ahorrar costos de mantener inventario. Una posibilidad es que las 32 unidades lleguen en el tiempo 12; de esta manera sólo se incurre en S por costos fijos de ordenar, y la mayoría de las unidades (30 unidades) no incurrirían en costos de almacenaje ya que se entregarían justo a tiempo para la tarea E. ¿O habría costos de mantener inventario? Al considerar este caso con más detalle, se observa que si no se entrega el material hasta el tiempo 12, la tarea B se retrasa 8 semanas respecto a su tiempo de inicio más lejano actual (tiempo 4). Como la tarea B está en la ruta crítica, el tiempo de terminación del proyecto se retrasa 8 semanas, a 25 semanas ( 17 semanas + retraso de 8 semanas). Como el proyecto está retrasado hasta el tiempo 25, el tiempo de inicio más lejano para la tarea E se atrasa hasta el tiempo 20 (25 - 3 - 2). Dado que se supuso que el costo de almacenar bienes tenninados o trabajo en proceso es mayor que para la materia prima (y por esto se desea iniciar las tareas en su tiempo de inicio más lejano para reducir costos de almacenar), el costo en este caso se puede calcular como sigue: •
El costo fijo de colocar una orden = S.
•
El costo de almacenar la materia pri ma para la tarea E = (30 unidades) x (20 - 12 semanas) = 240 semanas-unidad.
•
El costo de penalización por tenninar el proyecto 8 semanas tarde= 8? .
Debe observar que el costo de esta política (S+ 240 semanas-unidad + 8P) es exactamente 8P más costosa que la política de que se surtan las 32 unidades en el tiempo 4. Esta no es una coincidencia; como se demuestra en Smith-Daniels ( 1987), nunca se tratará de retrasar un proyecto para ahorrar costos de mantener inventario si el costo P de retrasar el proyecto es mayor que cero. Así, en este caso sólo hay dos al ternativas viables: •
Ordenar 12 unidades en el tiempo 4 (con costo= S+ 240 semanas-unidad).
•
Ordenar 2 un idades en el tiempo 4 y 30 en el tiempo 12 (con costo = 25).
Para comparar estas dos alternativas, es necesario conocer el valor de S y el costo semanal de mantener una unidad en almacén, que se define como el número de semanas-unidad, por el costo por unidad, por el costo semanal de mantener el inventario. Sin embargo, lo importante es que hay sólo dos alternativas a considerar; estas opciones dominan el resto de las alternativas. Este ejemplo tiene otras implicaciones. Primera, sólo hay dos tiempos para que entreguen las unidades, el tiempo 4 o 12. Además, corno se mostró, nunca se divide una orden. Entonces, en el tiempo 4, se ordenan las unidades para el tiempo 4 o para el tiempo 4 y el 12. Sí hubieran otras tareas que necesitaran los mismos materiales después, se considerará incluirlos también en la orden para el tiempo 4. Este tipo de problema se conoce bien en la literatura de administración de operaciones (Davis et al., 2003; Nahmias, 1997). Existe otra implicación importante. Un sistema de administración de materiales de amplio uso se conoce como sistema de planeación de requerimientos de materiales (MRP, material requirements planning); los sistemas MRP son parte integral de muchos sistemas de planeación de recursos empresariales (ERP, enterprise resource planning) (S htub, 1999). En un sistema MRP se usa un programa maestro de producción (MPS, master production schedule) para predecir la demanda de artículos finales; después, estas demandas se usan junto con una lista de materiales para generar las demandas de subensambles, componentes y materia prima. El resultado es un pronóstico de las demandas de estos materiales que se necesitan en periodos específicos. El problema en MRP es encontrar las cantidades adecuadas de materiales; es decir, saber qué pronósticos deben combinarse en una sola orden. La misma lógica que se usó para analizar las deci-
PROBLEMAS PARA ESTUDIO
129
siones de ordenar material en el ejemplo se usa en los sistemas MRP; es decir, las órdenes nunca se dividen y un administrador ó lo debe pensar en combinar algunas otras órdenes subsiguientes. Co mo Jos problemas de la ad ministración de materiales en los proyec tos son tan similares a los problemas encontrados en los sistemas MRP, éstos (y muchos sistemas ERP) se pueden usar en la toma de decisiones de órdenes y nujo de materiales en el entorno de un proyecto. El lector interesado puede encontrar más detalles de los sistemas MRP en Nahmias ( 1997) o Davis et al. (2003).
PROBLEMAS PARA ESTU DIO 1. El presidente de Walla Walla Boat Company, el señor Seymore Books, ha aceptado construir un nuevo velero para un consorcio que planea inscribirlo en la próxima carrera de la Copa América. La red del proyecto, que consiste en cinco tareas y cuatro eventos, es la que se presenta en la figura 5.6 con las siguientes duraciones de las tareas:
• Tarea A: 1 mes • Tarea B: 10 meses • Tarea C: 4 meses • Tarea D: 9 meses • Tarea E: 2 meses El señor Books estima que e n el evento M l hará un pago de $5 000, mientras que el consorcio ha aceptado hacer un pago de $3 000 a Walla Walla en el evento 2 y $3 000 cuando se entregue el velero terminado. El señor Books quiere programar el proyecto de manera que se maximice el valor presente neto de los fluj os de efectivo, pero no está seguro de la tasa de descuento apropiada en este caso. Entonces decide tratar al dinero como un recurso que puede gastarse o ganarse en diferentes puntos del tiempo y programar las tareas (o eventos) para minimizar los meses-dólar. El señor Books afirma que minimizar los meses-dólar es casi equivalente a maximizar el VPN. ¿Cuál es el tiempo de ej ecución de este proyecto según la ruta crítica? Si el señor Books minimiza los meses-dólar totales, ¿cuál es el tiempo de ejecución del proyecto? Si el señor Books maximiza el VAN del proyecto, suponiendo una tasa de descuento anual de 20%, ¿cuál es el tiempo de ejecución del proyecto? 2. a. El señor Books está preocupado por un retraso en la entrega del velero para la Copa América del problema l . ¿En cuánto habrá que reducir el pago de $5 000 que se hace en el evento M 1 de manera que el proyecto NO se retrase respecto a la ruta crítica y aún se maximice el VPN del proyecto? b. En el problema 1 el cliente pagará en total $6 000 ($3 000 en el evento M2 y $3 000 al final del proyecto). Si el cliente paga más de $3 000 en el evento M2 y menos al final del proyecto (pero paga en total $6 000), ¿reducirá esto el tiempo de ejecución del proyecto de la solución que maximiza el VPN? (suponga que el pago de $5 000 todavía se hace en el evento MI). Si es así, ¿cuánto deberá pagar en el evento M2? 3. Izzi Bright tiene que realizar un proyecto con siete tareas identificadas; las relaciones de precedencia y sus respectivas duraciones se dan en el siguiente diagrama AON. Tres de las tareas (3, 4 y 5) de este proyecto requieren un recurso específico para terminarlas; todos los recursos necesarios deberán estar disponibles antes de que cada tarea pueda iniciarse.
130
CAPiTULO 5
PLANEACIÓN PARA MINIMIZAR COSTOS
El número de unidades de recurso necesarias para las tareas 3, 4 y 5, y el valor estimado de las tareas terminadas se da en la siguiente tabla. Tarea
3 4 5
Número de unidades necesarias
Valor de la tarea terminada
10 10 12
$4000 $3 000 $4 500
Cada unidad de un recurso cuesta $1 00; no hay descuentos por cantidad. Además, mantener en almacén estos recursos cuesta $2 por unidad por periodo, y colocar una orden de material tiene un costo de $45 (independiente del número de unidades ordenadas). Una vez terminada una tarea, el costo de mantener inventario por periodo se estima en 2% del valor de la tarea terminada (mantener la tarea 3 terminada durante un periodo costará $80). Si el proyecto no termina a tiempo, cada periodo de retraso costará $5. ¿Cuándo debe iniciar cada tarea del proyecto y cuándo deben ordenarse los recursos (y cuántos) para minimizar los costos totales del proyecto? 4 . Rob D. Store, director del departamento de mercadotecnia, hizo una lista de todas las tareas
que debe terminar su equipo antes del fin del año académico. Dados los días restantes del semestre, ya está nervioso. Por fortuna, Rob ha estudiado administración de proyectos y quiere aplicar los conceptos de CPM. Con los datos que se dan a continuación, reduzca 4 días el tiempo de terminación del proyecto. Suponga que cada tarea tiene un trueque tiempo-costo lineal y muestre, paso por paso, cómo obtuvo la programación.
FIN
PROBLEMAS PARA ESTUDIO
Actividad
Tiempo normal (días)
Costo normal($)
Tiempo acelerado (días)
131
Costo de aceleración ($)
B
10
100
9
110
e
8
80
7
100
o
12
120
10
140
E
10
100
7
120
F
14
140
12
190
G
7
70
S
100
H
9
90 60
6 S
150
6
80
5. La doctora Denton Fender, una notable geóloga, descubrió un s;üo donde cree que hay un gran depósito de gas natural. Para probar la presencia posible de ga:. natural propo ne una perforación de prueba, detonar una pequeña carga de explo ivo } u:.ar el patrón sísmico obtenido para detenninar la presencia o ausencia posible de gas natural. El proceso de probar el sitio se ha dividido en cinco tareas que se indican en la siguiente red AOK Tarea O 4días
Tarea E
Sd1as Tarea C 12 días
Tarea 8 10 días
La doctora Fender estimó la duración y el costo de cada tarea suponiendo condiciones normales, y también suponiendo condiciones de aceleración o reducidas. Esta información se presenta en la tabla que sigue. Normal Tarea
Duración
Costo
Acelerada Duración
Costo
Pendiente
o
INICIO
o
Tarea A
8
$100
6
$200
$50
Tarea B
10
$ 70
5
$ 170
$20
Tarea C
12
$260
8
$500
$60
Tarea O
4
$ 80
4
$ 80
Tarea E
5
$100
2
$175
FIN
o
$25
o
La doctora Fender estima que en condiciones nonnales, el procedimiento de prueba tomará 22 días y tendrá un costo de $61 Oen costos directos. a. Dada la importancia de una nueva fuente de gas natural, la doctora Fender desea considerar otros escenarios posibles de menor duración ; por lo que le pide que reduzca el proyecto un día a la vez y calcule el costo directo mínimo asociado con cada día. ¿Cuál e el tiempo mínimo necesario para este proyecto?
132
CAPÍTULO 5
PLANEACIÓN PARA MINIM IZAR COSTOS
b. Si se tienen costos generales (indirec10s) de $50 por día, ¿cuál será la duración del proyec1o que minjmiza la suma de costos directos y costos indirec10s? c. Formule y resuelva un modelo de programación lineal con Solver de MS Excel para obtener la solución del inciso b. Compare u respuesta con la solución encontrada en ese inciso. d. Suponga que ahora se ofrece un incenlivo (bono) si el proyecto termjna en 19 dias. Suponiendo que los costos generales del inciso b) son los mismos, ¿de qué cantidad deberá ser el incentivo para que sea atractivo para la doctora Fender term inar el proyecto en 19 días? 6. En la siguiente red de proyecto AON se indica en cada nodo la d uración normal estimada de cada tarea. Las tareas de es1e proyec10 se pueden comprimir máximo dos semanas cada una: una reducción de una semana costará una cantidad igual a la duración normal estimada (por ejemplo, la duración de la tarea A se puede reducir a 6 semanas gastando $7 más, o se puede reducir a 5 semanas gastando $14 más). Tarea E 6semanas
Tarea O S semanas
Tarea B 10 semanas
Tarea C 7 semanas
Tarea H 11 semanas
Tarea F 5semanas
10 semanas
a. ¿Qué tareas debe acelerar si desea reducir 3 semanas la duración del proyecto al menor cos1o directo tola! posible? ¿Cuál es el incremento marginal en los costos direclos totales por semana de reducción en la duración del proyecto? b. Si el proyecto termina en más de 20 semanas, hay una penalización de $9 por semana de retraso. Pero si el proyecto termina antes de la semana 20, hay un bono de $5 por semana de adelanto. Encuentre la duració n del proyecto que minimiza los costos totales (costos de mano de obra directa, penali zaciones por retraso y bonos por terminar antes). Justifique su respuesta.
REFERENCIAS Brooks, F. The Mythical Man-Month: Essays on Software Enginccring. Boston : Addison-Wesley, 1995 (edición de aniversario). Davis, M., N. Aquilano y R. Chase. Fwulomemals ofOperutions Matwgemem. 4a. ed. Nueva York: McGraw-Hill, 2003. Grinold. R. C. "The Payment Scheduling Proble m", Naval Research Logistics Quan erly 19 ( 1972): 132- 142. Elmaghraby, S. E. y W. S. He rroelen. "The Scheduling of Activities to Maximize the Net Present Value of Projects". European Joumal of Operational Research 49 (1990): 35-49. Hughes, M. W . ..Why Projects Fai\: The Effects of lgnoring the Obvious"', Industrial Engineering, abril, 1986, 14- 18. Jiambalvo, J. Managerial Accotmting. (Nueva York: Wiley. 2001). Levy, F., G. L. Thompson y J.D. Wiest. "The ABC's of lhe Critica! Path Method". Harvard Business Re1•iew (septiembre-octubre, 1963): 98-1 08. Nahmias, S . Production and Operations A11alysis. 3a. ed. Chicago: Richard D. Irwin. 1997. Roemer, T., R. Ahmadi y R. Wang. "Ti me-Cost Trade-offs in Overlapped Product Developmem", Operations Research 48, núm. 6 (noviembre-
APÉNDICE SA. RELACIÓN ENTRE EL VALOR PRESENTE NETO Y LOS MESES-DÓLAR
133
Rosenblan, M. J. y Y. Roll. "A FuiUre Value Approach to Determining Project Duration··. 1/E TransacrioflS 17 (1986;. 164-167. Russell, R. A. "A Comparison of Heuristics for Scheduling Projects with Cash A ows and Resource Restrictions-, Management Science 32 (1986): 1291-1300. Shrub, A. Enterprise Resource Planning (ERP): The Dynumics of Operarions Managemem. Boston: Kluwer Acadenúc Publishers, 1999. Smith-Daniels. D. "Optimal Project Scheduling with Material Ordering"', IIETramucrions 19, núm. 2 ( 1987). Snúth-Daniels, D. y N. J. Aquilano. "The Use of a Late Stan Resource Constrained Project Schedule to l mprove Project Net Present Value'", Decision Sciences 18 ( 1987): 617-{)30. Snúth-Daniels. D. y V. Smith-Daniels. '"Maxinúzing the et Present Value of a Project Subject to Materials and Capital Constraints", Joum al ofOperarinn s Munagemem7 ( 1987): 33-45. Yang, K. K.. F. B. Talbot y J. H. Panerson. "Scheduling a Project to Maximize lts Net Present Value: An lnteger Programnúng Approach"", Europeun Joumal of Operarional Reseurch 64 ( 1993): 188-198.
APÉNDICE 5A. RELACIÓN ENTRE EL VALOR PRESENTE NETO Y LOS MESES-DÓLAR Denote por F; el i-ési mo flujo de efectivo (de manera que un fluj o de efectivo positivo represente una cuenta por cobrar y un fluj o de efecti vo negativo, una cuenta por pagar) que ocurre en el tiempo i . Si r denota la tasa de descuento, entonces el valor presente neto de F; se define como
F¡ Si se tienen M de estos flujos de efectivo en la vida del proyecto, su valor presente neto (VPN) es simplemente la suma de los M flujos de efectivo, es decir M VPN=L i=l (1
F ;
+ r)s,
que se maxirnjza sujeto a las restricciones s.J > s.1 +t.1 para todas las tareas i en el conJ·unto P1. -
Ahora, suponga que se tiene una función j(x) en algún punto a donde la funció n es continua y diferenciable. Ento nces, si la primera derivada dej(x) en el punto a se denotaf'(a), la segunda derivada por f"(a), la tercera derivada por f"'(a), etcétera, la función j{x) se puede aprox imar por el polinomio !"(a) ¡ m(a) ¡( ) 2 11 { (a)+ f'(a)(x - a) + - - (x - a) + -- (x - a)3 +... + - - a-(x - a) 2! 3! n!
+···
que se conoce como expansión en serie de Taylor dej(x) en el punto a. El valor presente de F;, que se define como F¡(l + rtsi, es de la forma b". Como la primera derivada de b" respecto a x está definida por: d (b") = b"(In b) du
dx
dx
entonces la primera derivada del valor presente de F1, respecto a s;. es d[F¡ (1 + r )-s;] = - F¡(l + r)-s; ln( l + r) ds;
134
CAPiTULO 5
PLANEACIÓN PARA M INIMIZAR COSTOS
Dada una consta nte a y usando sólo el ténni no lineal de la expansión en serie de Taylor, e l problema de maximizar el valor presente neto se puede aproximar media nte M
Maximizar
E - F¡[(I + r )- a; ln(l + r )]s¡ i= l
Haciendo 8; = (1 + r )- a; ln( l + r )
el proble ma de maxim izar el val or presente neto del proyecto (dados los M fluj os de efectivo) se puede rescribir como: Max imi zar
M
M
i= l
i=l
E - F¡g¡s; = Minimizar E F¡g¡s;
=
Si los valores de 8; 1, entonces la función objetivo es exactamente equivalente a minimizar lo meses-dólar. ¿Cómo deben definirse las constantes a; (y los ténninos g¡)? Teóricamente, los valores a¡ deberán ser iguales a los valores óptimos de s;, que por supuesto son desconocidos. Sin embargo, como la función (F¡g¡ s¡) es convexa, se puede emplear el siguiente esquema iterativo para e nconLrar los val ores óptimos de a¡ (y s¡) ya que el proceso convergerá a una solución óptima (en gene ral después de Lrcs o c uaLro iteraciones). Paso l. Inicialmente se hacen todos los valores de a; = 1 (o igual a los valores de s; encontrados al minimizar los días-dólar). M
Minimi zar
E Ff8;S; i =l
Paso 2. Se calculan los valores de 8; y se resuel ve el problema de programación lineal ujeto a las resLricciones de precedencia. Paso 3. Si M
E la; - s;j:::;E i=l
donde E es algún número positivo pequeño, entonces TERMINAR; se ha encontrado la solución óptima. Si no es así, los valores de a¡ se igualan a los valores ópúmos des¡ y se repite el paso 2.
CAPÍTULO
PLANEACIÓN CON INCERTIDUMBRE
E
n el primer capítulo se estudió la historia breve de los sistemas de administración de proyectos (AP) incluyendo PERT (conocido como Técnica de Revisión y Evaluación de Programas) desarrollado, según se reporta, entre 1956 y 1958 por la empresa de consultoría Booz Allen Hamilton para la Oficina de Proyectos Especiales de la Marina de Estados Unidos, con objeto de ayudar en el desarrollo del programa Polaris Rete Ballistic Missile. Desde entonces, el PERT se conoce, aplica y critica en todo el mundo. Según Malcolm et al. (1959), el sistema PERT inicial (conocido como Tarea de Investigación para Evaluación de Programas o Program Evaluarían Research Task) se desarrolló para proporcionar a "la administración una evaluación integrada y cuantitativa de: a) el avance logrado hasta la fecha, b) la validez de los planes y programas establecidos y e) los efectos de las modificaciones propuestas a los planes establecidos". Craven (2001), quien era el científico en jefe de la Oficina de Proyectos Especiales cuando el PERT fue desarrollado, da una perspectiva ligeramente diferente de la historia del PERT. De acuerdo con él: Se inventó un nuevo sistema de administración que incluía al ahora famoso programa PERT (técnica de reporte y eval uación del avance o progress evaluation and reporting technique). Su origen es una directiva del Admiral Raborn para establecer un nuevo programa de administración que diera a los contratistas la ilusión de que se les estaba administrando, el nombre del programa debería ser PERT en honor a su nueva novia cuyo apodo era Pert. Como sea que se haya desarrollado, el PERT sigue siendo muy conocido, au nque su aplicación es limitada. Sin embargo, la motivación para el desarrollo de PERT sigue siendo válida: desarrollar un sistema de administración de proyectos que considere explícitamente el hecho de que las duraciones de las tareas son variables aleatorias y proporciona a Jos administradores una manera de contestar explícitamente la pregunta: si el evento X se logra en una fecha dada, ¿cuál es la probabilidad de que el evento Y se logre en Olra fecha (dada)? En este capítulo se estudiará el método desarrollado para apoyar el proyecto Polaris en los años 50. Se hará referencia a este modelo como "PERT Clásico" y se analizará la metodología así como sus desventajas y sus muchas limitaciones. Se verán también algunas implicaciones importantes que ocurren cuando se supone que los tiempos de las tareas son variables aleatorias. Por último se analizarán otras metodologías, basadas en la simulación Monte Cario y la teoría de restricciones de Goldratt, que sustituyen al PERT Clásico y evitan casi todas las limitaciones de ese enfoque.
DEFINICIÓN DE PERT CLÁSICO El sistema PERT desarrollado para la Oficina de Proyectos Especiales (PERT Clásico) supone que los tiempos de las tareas se pueden describir mediante una distribución beta, como se vio en el capí-
135
136
CAPÍTULO 6
PLANEACIÓN CON INCERTIDUMBRE
rulo 2. Conúnuando con la presentación del capítulo 2 , PERT Clásico supone que los admi nistradores pueden estimar tres puntos para cada tarea:
=
f' estimación del tiempo más optimista fP = estimación del tiempo más pesimista f'l = estimación del tiempo más probable
C on estas tres estimaciones se puede calcular la duración esperada o media (denotada por J.L) y la varianza (denotada por a 2) de cada tarea, usando las siguie ntes fórmulas de aproximación sencillas:
y
Recuerde del capítulo 2 que una distribución beta es una distribución unimodal que no es necesariamente simétrica, sino que puede estar sesgada a la derecha o a la izquierda, dependiendo de los valores de los parámetros. En la figura 2.21 se da un ejemplo de una distribución beta. Como ejemplo, considere una vez más una tarea de programación que el administrador de proyectos piensa que durará 6 días en las mejores circunstancias posibles, 14 días en las peores circunstancias y lo más probable es que dure 11 días. Usando las fórmulas de aproximación de PERT, la duración esperada de la tareaj, J.Lp será J.Lj
= 6+ 14+4(11) =
10.67
6 con una desviación estándar igual a a} =
(14-6) = 1.33 6
Aunque surgían muchos problemas al usar estas fórmulas (vea en el capítulo 2 el análisis de estos aspectos), los diseñadores del modelo PERT Clásico de todas maneras las usaban para calcular la media y la desviación estándar de cada tarea. Después sustituían las medias en el modelo de la ruta crítica (CPM), descrito en el capítulo 4, y calculaban la ruta más larga esperada de la red de precedencias; esta ruta se usaba para calcular las distintas probabilidades de lograr eventos importantes e n alguna fecha dada. Para describir con más detalle el modelo PERT Clásico, se empleará el ejemplo de la figura 6.1 para mostrar los cálculos y limitaciones de PERT Clásico. El ejemplo de la figura 6.1 supone que los administradores han estimado la duración optimista, pesimista y más probable de las seis tareas de este proyecto de tecnología de la información (TI). Con estas estimaciones se usaron las ecuaciones para J.L y a2 para calcular la media o valor esperado y la varianza, respectivamente. La plantilla para estos cálculos se encuentra en el disco compacto que acompaña el libro, para que pueda verificar estas ecuaciones y cálculos. El modelo PERT Clásico supone que las duraciones de las tareas son variables aleatorias estadísticamente independientes que siguen una distribución beta. Dada esta suposición, un administrador de proyectos puede encontrar la duración esperada de cualqu ier ruta de la red de precedencias sumando las duraciones esperadas de todas las tareas en esa ruta. Por ejemplo, considere la ruta (INICIO-A-O-FIN) ; la duración esperada es O+ 6.67 + 14.33 +O= 23 .33. Como se
DEFINICIÓN DE PERT CLÁSICO
137
Estimaciones de tiempo Predecesor
'írea Descripción
Optimista
Pesimista
Más probable
Duración esperada
Varianza
~
Análisis de requerim ientos
ninguno
2
14
6
6.67
3
Programación
A
4
12
7
7.33
1.78
e
Adquisición de hardware
A
2
13
8
7.83
3.36
A
12
18
14
14.33
1.00
B,C
3
5 4
5.00 4.33
0.44 0.44
o
0.00
0.00
o
Capacitación del usuario
E
lm plementación
= _..,
Pruebas Fin del proyecto
=Ia URA 6.1
E
3
7 7
D,F
o
o
4.00
Ejemplo 1 de PERT Ctásico
supone que las tareas son estadísticamente independientes, las varianzas se pueden sumar (pero no las desviaciones estándar) para encontrar la varianza asociada con cada ruta. Examinando la red de precedencias de la figura 6. 1, se puede ver que hay tres rutas en esta red. La tabla 6.2 presenta las tres rutas de esta red junto con sus duraciones esperadas y varianzas. El modelo PERT Clásico supone que la ruta con el mayor valor esperado es la ruta crftica; t:sta ruta se usa en todos los cálculos subsiguientes. Si hay dos o más rutas con la misma duración esperada, la ruta que con la mayor varianza define la ruta crítica. Como se indica en la figura 6.2, la ruta (INICIO-A-C-E-F-FIN) de la figura 6.1 define la ruta crftica con la mayor duración esperada; con el enfoque de PERT Clásico, el administrador supondrá que la duración de este proyecto es 23.83 semanas con una varianza de 8.25 semanas. Suponga ahora que el administrador del proyecto quiere ver la probabilidad de tem1inar, digamos, en 25 semanas; es decir, quiere encontrar Pr[ICFIN ::::; 25] la probabilidad de que el tiempo de inicio más cercano del evento FIN sea menor o igual a 25. Como las duraciones de las tareas son variables aleatorias, ICFIN es también una variable aleatoria definida
138
CAPÍTULO 6
PLANEACIÓN CON INCERTIDUMBRE
FIGURA 6 . 2 Rutas en la red de preced enci as del ejemplo de PERT Clásico
Inicio más cercano esperado
Ruta INICIO A-8-E-F-FIN INICIO A-C-E-F-FIN INICIO A-O-FIN
Varianza
23.33 23.83 21.00
6.67
8 .25 5.00
por la suma de las duraciones de las tareas en la ruta crítica esperada RC (INICIO-A-C-E-F-FIN); es decir, el valor esperado de ICFIN es 23.83 semanas con una varianza asociada de 8.25 semanas. Como ICFIN es una variable aleatoria definida por la suma de una serie de distribuciones beta independientes, ICF!N está definida por una distribución normal de acuerdo con el teorema del límite central que establece que la suma de un número grande de variables aleatorias independientes converge a una distribución normal. Aunque en este ejemplo no hay un "número grande" de tareas que definan la ruta más larga esperada, en un proyecto real suele haber suficientes tareas para satisfacer este requerimiento. Así, se procede con la suposición de que las redes de estos ejemplos tienen suficientes tareas de manera que cualquier valor de IC; puede describirse por una distribución normal. El modelo PERT Clásico define entonces la duración esperada del proyecto y la varianza de esa duración como sigue:
L
Duración esperada del proyecto = E[ICFIN] = [
Jl.jl
1areasjen RC y
Varianza de la duración del proyecto= Var[ICFIN] = [
L larea jen RC
a/]
Sabiendo que ICRN puede describirse por una distribución normal con media de 23.83 semanas y varianza de 8.25 semanas, se puede encontrar la probabilidad de que el proyecto termine en no más de 25 semanas (la "fecha de entrega"). Para usar una tabla normal estándar (basada en una d istribución normal con media cero y varianza uno), se calcula el valor z asociado como sigue: Pr (ICFlN ~ fecha de entrega) = Pr
fecha de entrega - E[ICFlN] )
(
z ~ - -------....:....:'-'Var [ICFIN]
= Pr(z ~ 25 -23.83) .J8.25
= Pr (z
~
0.41 )
Usando la tabla nom1al estándar del apéndice 6A, se encuentra que Pr(z ~ 0.41) = 0.658; es decir, existe una probabilidad de casi 0.66 de que el proyecto termine en no más de 25 semanas (inversamente, hay una probabilidad de 34% de que el proyecto exceda 25 semanas). La hoja de cálculo con los valores z y las probabilidades para varias fechas de entrega se presentan en la fi gura 6.3 . De acuerdo con el modelo PERT Clásico, virtualmente no existe una probabilidad de que el proyecto de la figura 6.1 termi ne en 15 semanas. Casi se tiene la seguridad (99.8% de probabilidad) de que el proyecto termine en 32 semanas. El modelo PERT Clásico se puede usar para estimar la probabilidad de que cualquier tarea termine en una fecha dada. Por ejemplo, considere la tarea D (capacitación del usuario). En este caso, sólo hay una ruta (a través de A) que precede la tarea D, de manera que la media y la varianza de la tarea A definen la media y la varianza de IC0 . En general, el administrador del proyecto encon-
DEFINICIÓN DE PERT CLÁSICO
GURA 6 .3 Clásico :;.; ctJios de que el ~oyecto del ejem plo :::rmine dentro de un ~ azo dado
Fecha de entrega
Z¡
Pr(z;)
- 3.07 -1.33 0.41 1.45 2.84
0.001 0.091 0.658 0.927 0.998
139
~RT
15 20 25 28 32
trará la ruta más larga esperada hacia la tarea en cuestión y usará la suma de las duraciones y varianzas esperadas de las tareas en esa ruta; es decir, Tiempo de inicio más cercano esperado para la tarea k
= E[ICk] = máx s
donde existen s
¡
L
Jl
j)
tareas j en la ruta s
= 1, ... , NI: rutas entre el evento INICIO y la tarea k.
Limitaciones del modelo PERT Clásico El modelo PERT Clásico ha sido criticado en muchos aspectos, incluyendo los problemas asociados con la estimación precisa de la duración optimista, pesimista y más probable de cada tarea (este tema se trató en el capítulo 2). Otro problema es el relacionado con la elección aparentemente arbitraria de la distribución beta y de las fórmulas para aproximar la media y la varianza de las tareas. Un problema más es la suposición de que las duraciones de las tareas son independientes, lo cual, por supuesto, muchas veces no se cumple. Sin embargo, el problema más significativo del PERT Clásico es el ilustrado en el ejemplo de cuatro tareas de la figura 6.4. En este ejemplo suponga que el administrador del proyecto conoce las medias y las varianzas de las cuatro tareas, de manera que puede ignorar los problemas de estimar estos valores. Como se vio, el modelo PERT Clásico supone que la rula crítica es la ruta de mayor duración esperada; es fáci l ver en la figura 6.4 que esta ruta crítica es INICIO-B-D-FIN, y q ue tiene duración esperada de 15 y varianza de 5; es decir,
;¡GURA 6.4
=;mplo 2 de PERT ::.C.Sico
140
CAPÍTULO 6
PLANEACIÓN CON INCERTIDUMBRE
E[ICFIN) = 15 y Var[ICFINJ = 5 De acuerdo con el PERT Clásico, la probabilidad de que e l proyec10 termine, digamos, e n e l tiempo 17 (fecha de entrega) es Pr(IC FIN _:::; 17) = Pr ( ~ _:::;
17-15)
J5 = Pr(z _:::; 0.894) = 0.8 1
Es deci r, hay 81 % de proba bilidad de que el proyecto termine hasta e n 17 periodos. No obsLante, en este ejemplo hay dos rutas entre los eventos INICIO y FIN. La segunda ruta (INICIO-A-C-FlN) es ignorada por el modelo ya que su duración esperada es menor que la duración esperada de la ruta (INICIO-B-0-FIN); pero esta ruta tiene una duración esperada de 14 y una varianza de 7. Suponiendo que e l número de tareas es suficiente para u ar una aproxi mación normal. un admini strador puede calcular la probabilidad de que las tareas en esta ruta terminen en 17 periodos o menos. Pr(z.:::;
17 -14
J7
= Pr(z.:::; 1.134) =
0.872
Por supuesto que en realidad todas las tareas en ambas rutas deben terminar en 17 periodos o menos para que el proyecto termine en este tiempo. Como las dos ruLas no se traslapan, es razonable suponer que las rutas son independientes; por lo tanto, la probabilidad real de que el proyecto termine en 17 periodos o menos es el producto de las dos probabilidades: 0.8 1 x 0.872 = 0.706. Al multiplicar probabilidades que son menores que uno, el produc to siempre será me nor que cualquiera de las probabi lidades individuales; es decir, la probabilidad verdadera de que el proyecto de la figura 6.4 termine en 17 periodos o menos es sólo 70.6%. Esto ilustra el problema más importante del modelo PERT Clásico: siempre que hay ruLas paralelas, proporciona estimaciones optimistas porque considera una sola ruta a través de la red de precedencias. Aunque la aproximación de PERT Clásico puede ser buena c uando sólo hay una ruta domjnante, e n Jos proyectos reales es raro que esto ocurra debido a varios factores que se presentan en la sección siguien te. Las limitaciones-de PERT Clásico se pueden ilustrar mejor con un ejemplo con probabi lidades discretas; ahora suponga que el administrador del proyecto conoce las duracio nes precisas de cada tarea y sus probabilidades respectivas. Este ejemplo (ejemplo 3 de PERT Clásico) se presenta en la figura 6.5. En este caso, hay cuatro tareas que pueden te ner las duraciones indicadas en la tabla con sus probabilidades respectivas. La duración esperada de cada tarea se indica e n la red de precedencia, en su nodo correspondie nte; estos valores se calcularon simple mente multiplicando cada duración por su probabilidad y sumando \os productos; por ejemplo, 2
E[B] = L X¡ Pr(X
= X¡) =
2(0.2) + 12(0.8) = 10.0
i=l
En el ejemplo 3 hay tres rutas del INICIO al FIN; empleando las duraciones esperadas calculadas de cada Larca, las duraciones esperadas de cada ruta son: INICIO-A-O-FIN: duración esperada= 17.3 INICIO-B-0-FIN: duración esperada = 19.3 INICIO-C-FIN: duración esperada = 19.0
DEANICION DE PERT Ct.ASK:O
141
R GURA 6 .5
-=-emplo 3 de PERT
\
~:..:. -
~1.
Tarea B (10.0)
Tarea C (19.0)
Tarea A
~
\
'
1
Tarea B
Tarea C
Tarea O
Valor
Prob.
Valor
Prob.
Valor
Prob.
Valor
Prob.
7 8 9
0.333 0.333 0.333
2 12
0.2 0.8
5 15 25
0.2 0.2 0.6
3 13
0.3 0.7
Según el modelo PERT Clásico, (IN1CIO-B-D-FIN) es la ruta crítica; se espera que el proyecto dure 19.3 semanas y las tareas B y D son las que más preocupan (ya que se encuentran en la ruta crítica). Como existe un número finito de duraciones para cada tarea, se pueden enumerar todas las combinaciones posibles de duraciones de las tareas (y sus probabilidades) para encontrar la distribución exacta de los tiempos de terminación del proyecto. Dado que la tarea A puede tomar 3 valores; la tarea B, 2 valores; lat:, 3 valores, y la D, 2 valores, hay 3 x 2 x 3 x 2 =36 combinaciones posi bles. Estas 36 combinaciones se dan en la tabla de la figura 6.6. Para cada combinación en la tabla de la figura 6.6, se encuentra la duración de las tres rutas a través de la red de precedencias y se indica la ruta más larga. La probabilidad de cada combinación se calcula multiplicando las probabilidades de la duración asociada de cada tarea; por ejemplo, en la primera combinación, la probabilidad de q ue la duración de la tarea A sea 7, de la tarea B sea 2, de la C sea 5 y de la D sea 3 es (0.333) x (0.2) x (0.2) x (0.4) = 0.004. La ruta más larga asociada con estos valores es la ruta IN1CIO-A-B-FIN, que tiene un valor de 10. Se pueden usar los datos de la figura 6.6 para calcular la duración esperada verdadera del proyecto multiplicando la probabilidad de cada combinación por su respectiva ruta más larga. En este caso, se encuentra que el valor esperado es 23.22 semanas, un valor que es 20% mayor que las 19.3 semanas dadas por el modelo PERT Clásico. Un administrador que usa el modelo PERT Clásico para estimar la duración esperada del proyecto estará trabajando con una estimación significativamente menor que el valor verdadero. Con la información de la tabla dada en la figura 6.6 se pueden calcular las probabilidades de todas las duraciones posibles del proyecto; esta información se resume con las probabilidades y con las probabilidades acumuladas en la figura 6.7. Dado que PERT Clásico supone que la duración del proyecto sigue una distribución normal con media de 19.3 semanas, esto implica que hay 50% de probabilidad de que el proyecto termine
142
CAPi TULO 6
PLANEACIÓN CON INCERTIDUMBRE
Tarea A Combinación
Valor Prob.
23 24 25 26 27 28 29 30 31 32 33 34 35
7 7 7 7 7 7 7 7 7 7 8 8 8 8 8 8 8 8 8 8 8 8 8 9 9 9 9 9 9 9 9 9 9 9 9
0.333 0.333 0.333 0.333 0.333 0.333 0.333 0.333 0.333 0.333 0.333 0.333 0.333 0.333 0.333 0.333 0.333 0.333 0.333 0.333 0.333 0.333 0.333 0.333 0.333 0.333 0.333 0.333 0.333 0.333 0.333 0.333 0.333 0.333 0.333
36
9
0.333
1
2 3 4 5 6 7
8 9 10 11
12 13 14
15 16 17 18 19 20 21
22
FIGURA 6 . 6
Tarea B
Tarea C
Tarea D
Valor Prob.
Valor Prob.
Valor Prob.
2 2 2 2 2 2 12 12 12 12 12 12 2 2 2 2 2 2 12 12 12 12 12 12 2 2 2 2 2 2 12 12 12
0.2 0.2 0.2 0.2 0.2 0.2 0.8 0.8 0.8 0.8 0.8 0.8 0.2 0.2 0.2 0.2 0.2 0.2 0.8 0.8 0.8 0.8 0.8 0.8 0.2 0.2 0.2 0.2 0.2 0.2 0.8 0.8 0.8
12 12 12
0.8 0.8 0.8
5 5 15 15 25 25 5 5 15 15 25 25
25 25 5 5 15 15 25 25 5 5 15
0.2 0.2 0.2 0.2 0.6 0.6 0.2 0.2 0.2 0.2 0.6 0.6 0.2 0.2 0.2 0.2 0.6 0.6 0.2 0.2 0.2 0.2 0.6 0.6 0.2 0.2 0.2 0.2 0.6 0.6 0.2 0.2 0.2
3 12 3 12 3 12 3 12 3 12 3 12 3 12 3 12 3 12 3 12 3 12 3 12 3 12 3 12 3 12 3 12 3
0.3 0.7 0.3 0.7 0.3 0.7 0.3 0.7 0.3 0.7 0.3 0.7 0.3 0.7 0.3 0.7 0.3 0.7 0.3 0.7 0.3 0.7 0.3 0.7 0.3 0.7 0.3 0.7 0.3 0.7 0.3 0.7 0.3
15 25 25
0.2 0.6 0.6
12 3 12
0.7 0.3 0.7
5 5 15
15 25 25 5
5 15 15
Ruta critica
Prob. de RC
A,O A. O
0.004 0.009 0.004 0.009 0.012 0.028 0.016 0.037 0.016 0.037 0.048 0.112 0.004 0.009 0.004 0.009 0.012 0.028 0.016 0.037 0.016 0.037 0.048 0.112 0.004 0.009 0.004 0.009 0.012 0.028 0.016 0.037 0.016 0.037 0.048
e A,O
e e B.O B.O B.O B,O
e e A, O A, O
e A. O
e e B,O B,O B,O B,O
e e A,O A,O
e A,O
e e B,O B,O B.O B,O
e e
0.112
Long itud de RC
10 19
15 19 25 25 15 24
15 24 25 25
11 20 15 20 25 25 15 24 15 24 25 25 12 21
15 21 25 25
15 24
15 24 25 25
Treinta y seis combinaciones para el ejemplo 3 de PERT Clásico
en ese tiempo. Sin embargo, en realidad las probabilidades acumuladas que se dan en la figura 6.7 indican que el proyecto necesitará 25 semanas para tener por lo menos 50% de probabilidad de terminar a tiempo. Una vez más PERT Clásico da un error considerable. Recuerde que el modelo PERT Clásico identifica a las tareas B y D como críticas; es de suponer que los administradores les darán un seguimiento cercano. Sin embargo, al usar la tabla de la figura 6.6 se puede calcular la posibilidad verdadera de que cada tarea sea crítica. Para calcular la probabilidad de que la tarea A sea crítica, simplemente se suman las probabilidades de cada combinación q ue identifica a la tarea A como tarea crítica (las combinaciones 1, 2, 4, etcétera). Repitiendo este proceso para cada tarea, se encuentran las probabilidades mostradas en la figura
MODELOS DE SIMULACIÓN MONT E CARLO
l ongitud deRC
Prob.
10
0.004
11
0.004
12
0.004
15 19
0.1 08
20
0.019
21 24
0.224
25
0.599
Prob. acumulada
Tarea A Tarea 8 Tarea C Tarea O 0.068
0.019 0.019
0.00 0.01 0.01 0.12 0.14 0.16 0.18 0.40 1.00
143
0.320
0.611
0.388
FIGURA 6.8 Índices críticos para las tareas del ejem plo 3
FIGURA 6 .7 Rutas crít icas posibles en el ejemplo 3 de PERT Clásico
6.8. La probabilidad de que una tarea se cncuenne en la ruta crítica algunas veces recibe el nombre de índice crítico. Es interesante que ni la tarea B ni la D tienen la mayor posibilidad de ser criticas; la tarea C es la que tiene la mayor posibilidad (0.611 contra 0.388 de la tarea D y 0.32 de la tarea B). En este pequeño ejemplo, el resultado se debe a que la tarea e tiene 60% de probabilidad de tener una duración de 25, que es mayor que cualquier otra ruta posible. Sin embargo, en proyectos mayores y más reales, es raro que haya una tarea o ruta dominante; una vez más, los administradores que siguen el modelo PERT Clásico pueden tener equivocaciones serias.
• c eLOS DE SIMULACIÓN MONTE CARLO Dado que las duraciones de las tareas en los proyectos reales, de hecho, son aleatorias y que el modelo PERT Clá'Sico tiene fallas, ¿cómo puede determjnar un administrador el plan del proyecto? Una alternativa es usar un modelo de simulación de Monte Cario. La simulación de Monte Cario (con eventos discretos) es un proceso iterativo que da valores a las variables aleatorias haciendo un muestreo de la distribución respectiva de cada variable; después usa estos valores para ca\cu\ar \a ruta criuca, \as no\guras, e\cé\era. \'or e)emp\o, suponga que \as duraciones de las tareas siguen una distribución beta como se describió en e\ capítu\o 1. En cada corrida de simulación se establece el tiempo de cada tarea "extrayendo" un valor de su distribución respectiva (es decir, es más probable que aparezcan los valores cercanos a la moda 1'11 que los valores en la cola de la distribución cerca de la estimación optirrusta f1 o de la estimación pesimista !'). En otras palabras, la selección de la duración de cada tarea está determinada por la distribución de probabilidad asociada con cada tarea. Después de seleccionar las duraciones de las tareas, es fácil calcular la ruta critica, los tiempos de irucio cercanos y lejanos, las holguras, etcétera. Este proceso se repite muchas veces y con los resultados se calculan estadísticos de interés (como los índices críticos). Para ilustrar el enfoque de la simulación de Monte Cario, se describirán dos ejemplos: el ejemplo 1 de PERT Clásico con variables aleatorias contjnuas y el ejemplo 3 de PERT Clásico con variables aleatorias discretas. En el primer caso, se supondrá que las duraciones de las tareas se pueden describir por una distribución normal usando las estimaciones de la media y la varianza obtenidas con las ecuaciones dadas en "definición de PERT Clásico". Para generar una variable aleatoria t . a partir 1 de una distribución normal con media Jlj y varianza para cada tarea }, se puede emplear 1a ecuación siguiente (Naylor eral., 1968):
a/
144
CAPÍTULO 6
PLANEACIÓN CON INCERTIDUMBRE
donde ALEATORlOK es el k-ésirno número aleatorio generado por la función ALEATORIO de Excel a partir de una distri bución uniforme en el intervalo [0, 1]. Los valores obtenidos en una corrida se indican en la tabla de la figura 6.9; las d uraciones esperadas y las varianzas para todas las tareas se encontraron con las fórmulas dadas en "definición de PERT Clásico". Usando los valores generados (como tA = 8.24, t 8 = 8.18, etcétera), se pueden encontrar los tiempos de inicio más cercano, de terminación más lejana, etcétera, para esta corrida Observe que toma 26.44 semanas terminar el proyecto con el conjunto de duraciones elegido. Usando la función TABLA de Excel, se puede hacer una tabla que dé los resu ltados de múltiples corridas. Los resultados de 200 ensayos de la simulación de Monte Cario para este ejemplo se presentan en la figura 6.1 O; este modelo se encuentra también en el CD que acompaña al libro. En cada corrida se da el valor de la ruta crítica, así como los valores de una variable binaria para cada tarea, que indica si la tarea es o no crítica. Estas variables bi narias, t(j) para la tarea}, se definen de manera más formal como:
.
tU)=
{1
si TS(j) = O O de otra manera
donde TS(j) =holgura total de la tarea j. Dados los valores de t(j) en 200 corridas, se puede estimar la probabilidad de que una tarea esté en la ruta crítica, sumando los 200 valores de t(j) y dividiéndolos entre el número de corridas (200). Estas probabilidades (identificadas como índices críticos) se dan en la figura 6.1 O. De acuerdo con el modelo PERT Clásico, la rula crftica esperada es INICIO-A-C-E-F-FIN (la tarea A no se incluye en la tabla de la figura 6.10, ya que se encuentra en las tres rutas críticas y por lo tan to debe ser crítica). Observe que la probabilidad de que la tarea C sea crítica es 55%, mientras que esa probabi lidad para la tarea B (que el PERT Clásico no identifica como crítica) es 5 1%. Las probabilidades de que las tareas E y F sean críticas son casi el doble de la probabilidad de que la tarea B se encuentre en la ruta crítica. La simulación de Monte Cario encuentra que la duración esperada de este proyecto será 27.65 semanas, un valor significativamente mayor que la duración esperada (23.83 semanas) determinada por el modelo PERT Clásico. Es interesante observar que el modelo PERT Clásico estima que la varianza del proyecto es 8.25 semanas, mien tras que el modelo de simulación de Monte Cario estima una varianza considerablemente más alta, 18.022 semanas. Dado que la simulación de Monte Cario representa un muestreo (con reemplazo), se pueden estimar intervalos de confianza para todos los valores calculados con el modelo de simulación. Suponiendo que nos interese el tiempo de ejecución del proyecto, se puede usar la media muestral de la ejecución del proyecto (27.65 semanas) y la varianza muestra] (18.022 semanas) para encontrar los intervalos de confianza deseados. FIGURA 6 .9 U na corrida de simulación Monte Cario par a el ejemplo 1 de PERT Clásico
Tarea
Duració n d e la t area (distribución normal)
Inici o Terminación cercano lejana
Holgura t ot al
Duración esperada
Varianza 4.00
A
8.24
o
8.24
0.00
6.67
B
8.18
8.24
16.41
0.00
7.33
1.76
e
6.87
8.24
16.41
1.30
7.83
3.36
D
13.52
8.24
26.44
4.68
14.33
1.00
E
4.81
16.41
21.23
0.00
5.00
0.44
F
5.22
21.33
26.44
0.00
4.33
0.44
FIN
0.00
26.44
26.44
0.00
0.00
0.00
MODELOS DE SIMULACIÓN MONTE CA.~
FIGURA 6 .10 Resultados de 200 corridas de simu lación Monte Cario
t(D)
Corrida
Duración del proyecto
1 2
29.35 29.97
3 4 5
25.37 30.87 35.26
194
28.57
1
o
195 196 197
31.76 27.22 28.63 24.94 27.45
o
o o
198 199 200 Pro m . Var.
t(B
1
o o
o
o o e Sl.O"l(.
27.65 18.022
t (F)
91.0%
91.0%
o o o o o
:J
31.18
t(E)
145
1
o o o
1 55.0%
9.0%
o
Suponga que se desea enconrrar un intervalo bilateral de 95% de confianza para el tiempo de ejecución del proyecto; es decir. se desea encontrar un intervalo que tenga 95% de probabilidad de contener a la duración \erdadern. del proyecto. Con una aproximación normal, se encuentra que el valor normal estándar de;:. :0 025• es igual a 1.96; por lo tanto, el intervalo de confianza es: X ::r: :0.025
SX =X± 1.96 SX
donde X es la media muestra! y s¡ es el error estándar estimado de la media, que es igual a s/,J;; , con s la desviación estándar muestra] y 11 el número de ensayos. Dado que X = 27.65, s = .JI 8.02 =4.25, y n =200 ensayos, Jos intervalos de 95 y 99% de confianza para el tiempo de ejecución del proyecto se dan en la figura 6.11. Mayor precisión (es decir, intervalos de confianza menores) pueden encontrarse aumentando el número de ensayos (n).
Simulación Monte Cario con distribuciones de probabilidad discretas Para ilustrar un caso en el que las duraciones de una tarea se describen mediante distribuciones de probabilidad discretas, considere el ejemplo 3 de PERT Clásico presentado en la figura 6.5. Como este ejemplo es pequeño, se pudieron enumerar las 36 combinaciones posibles (figura 6.6) y encontrar la duración esperada verdadera del proyecto, así como la probabilidad de que cada tarea sea crítica. Sin embargo, en Jos proyectos reales más grandes los administradores no pueden enumerar todas las combinaciones posibles y tendrán que recurrir a un método de muestreo (Monte Cario). Se puede construir un modelo de Monte Cario para el ejemplo 3 de PERT Clásico (figura 6.5), usando de nuevo la función ALEATORIO. Recuerde que en este ejemplo la tarea A puede tomar 1res valores (7, 8 o 9 semanas) con igual probabilidad. Para generar uno de los valores con la función ALEATORIO, se crea una hoja de cálculo usando el operador SI que establece la dumción de la tarea A igual a 7 semanas si ALEATORIO está entre O y 0.33, a 8 semanas si ALEATORIO está enlre 0.33 y 0.67 y
~G URA
6.11 __mites de confianza -:ara la duración del -=royecto (ejecución)
Duración del proyecto Intervalo d e confianza de 95% Intervalo de confianza de 99%
Límite inferior Límite superior 27.07 26.88
28.24 28.43
146
CAPiTULO 6
PLANEACIÓN CON INCERnDUMBRE
a 9 semanas si ALEATORlO está entre 0.67 >O. (Como ALEAIDRJO genera un número continuo entre Oy l. no es necesario preocuparse por la posibilichi de que ALE-\TORJO =0.33 o 0.67 exactamente.) Los resultados de este proceso de Monte Cario son informamos. Si se promedian los l OO valores de la ruta crítica, se encuentra un valor de 2.3.1 ~ semanas ¡x!1a la ruta crítica esperada. La comparación de este valor con el valor verdadero de ruta criuca esperada de 23.22 semanas encontrado e n la fig ura 6.6 es favorable. A ~de ~ ronidas, se puede generar una distribución para los valores de la ruta crítica simil:rr a la figura 6.- . La distribución de las duraciones de la ruta crítica (y del proyecto) encontrada a partir de la sim:tlación Monte Cario se da en la figura 6.12. Una comparación entre las tablas de las figuras 6.7 y 6. 11 indica un alto grado de similitud. La probabilidad de que el proyecto termine en 20 semanas es 12'k según la imulación Monte Cario y 16% en realidad. La difere ncia entre las dos tablas e debe a que los estadísticos de Monte Cario se basaro n en una muestra de sólo 100 ensayos; conforme aumenta el número de ensayos o corridas, la varianza asociada con cada estadístico disminuye y los valores de las dos tablas convergen. Empleando las variable t(j) calculadas en cada en ayo de Monte Cario. se puede estimar la probabilidad de que cada tarea esté en la ruta crítica. Estos valores se presentan en la figura 6.13; como se ve, la tarea C tiene la mayor probabilidad de encontrarse en la ruta crítica (igual a 0.59), mientras que la tarea A tiene la menor probabilidad de ser una tarea crítica (igual a 0.1 0). La comparación de estos valores con los valores verdaderos de 61.1 % y 6.8% de las tareas C y A, respectivamente, es favorable. Es relativamente sencillo aplicar la simulación Monte Cario a proyectos de gran escala y complejos. Dada la velocidad y las capacidades de memoria de las microcomputadoras actuales, toma poco tiempo simular varios miles de corridas de proyectos reales grandes. Se dispone de varios productos de simulación, entre ellos @Risk creado por Palisades Corporation para usarse con Microsoft Proj ect. Estos productos para si mulación generan duraciones de tareas a partir de un gran número de distribuciones de probabilidad posibles (especificadas por el usuario) y después calculan los estadísticos de interés e n cada ensayo. Los resultados de los ensayos se resumen en una forma parecida a nuestro modelo de simulación e n hoja de cálculo; sin e mbargo, estos paquetes de simulación proporcionan más opciones al usuario y pueden manejar proyectos mucho más grandes que en una hoja de cálculo estándar.
Ejemplo de desarrollo de un nuevo producto: ciclos en las redes de precedencias Los modelos de simulación Monte Cario emplean los cálculos de la ruta c rítica descritos en el capítulo 4 para cada corrida de simulación que re presenta una muestra aleatoria de las duraciones de las tareas. Es decir, para c ualesqu iera elecciones de duraciones de las tareas, se calcula la ruta crítica, los valores de holgura, los costos, etcétera, y se evalúa la distribución de estos valores para todas las corridas de simulación. Sin embargo, e n algunos proyectos se deben considerar otras incenidumbres del proyecto. Por eje mplo, los resultados de una tarea pueden indicar que alguna de FIGURA 6 . 12 Distribució n de las d uracio nes de la r uta crítica, determinada con 100 ensayos de M o nte Ca rio
Longitud de la ruta crítica Probabilidad
Probabilidad acumulada
10
0.01
0.01
15
0.09 0.11
19
0.08 0.02
20
0.01
0.12
21 24
0.01 0.24
0.13 0.37
25
0.63
1.00
MODELOS DE SIMULACIÓN MONTE CARLO
Tarea
Predecesor
t{1)
Pr [t(1))
t{2)
INICIO
ninguno
o
A
Inicio
7
B
Inicio
e
Inicio
1.0 0.333 0.2 0.2 0.3 1.0
8 12 15 12
D
A,B
2 5 3
FIN
C,D
o
Tarea
Duración
INICIO
o
A
7
o o o o
t{B)
7
19
15
9.3
o
o
t {C)
t{D)
o
1
25
o
o
1
15
1
o
25
4
25
5 6
25
o o o o o o o o
25
11
25
12
24
13
25
14
25
96 97 98 99 100
24 24 24
:-...o medios ;;¡GURA 6 .13
24 21
Pr [ t(3))
#aleatorio
0.203 0.243 0.176 0.446 0.046 0.510
1
o o o o
10
o
2 3
8 9 10
1.0
o
t{A)
25 15
25
8
Ruta crítica
7
1.0
o
Corrida
D FIN
9
15 20
25
25 3
0.667 1.00 0.40 1.000
o
o
2
e
t {3)
Inicio Terminación Holgura Duración cercano lejana total esperada
22 22 25 25 25
B
Pr [ t(2))
147
1
o o
o
o o
o o
o
1
1
o
1
o 1
1
o
o o
o
1
1
o
1
o
o
25
o o o o
25 23.12
o
o
10.0%
33.0%
1
o o
o o 1
o o
1
o o
o 59.0%
43.0%
Modelo de hoja de cálculo de Monte Cario para el ejemplo 3 de PERT Clásico
las tareas anteriores debe repetirse, dando como resultado un ciclo en la red de precedencias. Esto es común en proyectos de desarrollo de nuevos productos (DNP) donde un producto o servicio prototipo puede no pasar una prueba beta o un obstáculo de investigación de mercado, y regresa a la etapa de diseño o pruebas. Este caso se ilustra en el ejemplo de la figura 6.14, que muestra un proyecto de DNP en la etapa de prueba beta. Como se indica, hay una probabilidad de 0.25 de que no pase la prueba beta; si esto ocurre, todas las tareas de diseño anteriores - incluyendo "diseño de unidades físicas", "diseño electrónico" y "software"- deben repetirse.
148
CAPÍTULO 6
PLANEACIÓN CON INCERTIDUMBRE
Los cálculos de la ruta crítjca no pueden tener ciclos, como el indicado en la figura 6.14, en la red de precedencias; muchos de los paquetes de software para AP verifican -y no permiten-los ciclos en la red. Así, el administrador debe modificar la red de manera que pueda calcular la rULa crítica y los valores asociados con cada corrida de simulación. Una manera de lograr esto es suponer que cuando mucho se requerirá un ciclo de rediseño la prueba beta falla, e indicar todas las larea.S de rediseño como tareas nuevas en la red (de otra manera, todas las tareas de rediseño podrían repetirse agregando cinco tareas nuevas a la red Después esta tarea de rediseño se agrega a una red modificada, como se indica en la figura 6.1 ~ Ob erve que todavía hay una probabilidad de 0.25 de desviarse hacia esta tarea de rediseño y 0.75 de probabilidad de que la prueba beta tenga éxito y se evite la tarea de rediseño. Para modelar la ramificación probabilística de "prototipo de prueba beta" a "prueba beta falla o "fin" suponga que los arcos en la red de precedencias representan la relación "estándar" terminació n-inicio y modifique la duración de la tarea "prueba beta falla"; es decir, ahora habrá una probabilidad de 0.75 de que la duración de "prueba beta falla" sea cero y de 0.25 de que la duración de esa tarea sea un valor estimado. Por lo tanto, al modificar de manera adecuada la duración de la tarea "prueba beta falla", el administrador puede analizar la rama probabilística (y el posible ciclo en una red de precedencias. Observe que este marco de trabajo puede ampliarse para comprender varios ciclos si el administrador lo desea. Por ejemplo, puede añadir otra tarea, "prueba beta falla por segunda vez", entre "prueba beta falla" y "fin " para incluir la posibilidad de un segundo rediseño. Pueden agregarse mfu. ciclos de la misma forma (aunque no está claro cuántos ciclos de rediseño se aceptarán antes de que el proyecto de DNP sea cancelado). En la figura 6.16 se da el modelo de simulación Monte Cario modificado para el proyecto de DNP de la figura 6.15. En este ejemplo, suponga que el administrador sólo tiene dos estimaciones para las duraciones de las tareas -la duración optimista y la pesimista- y que estas duraciones siguen una distribución uniforme entre los dos extremos. El administrador usa las duraciones de las tareas para determinar los costos de mano de obra directa con base en el número de tipos de recursos y los costos indicados en la fig ura 6.16. En cada corrida de simula-
Renta de
La prueba beta falla (con probabilidad 0.25) y se necesita retrabajo
Diseño de unidad física Ensamblar prototipo
Prototipo de prueba beta
. ... \
lden@"''' "'""ata< personal
Diseño electrónico
:
,..__ ',
FIGURA 6.14
Ejemplo de un proyecto de desarrollo de un nuevo producto
La prueba beta falla (con probabilidad 0.25) y se necesita retrabajo
1 \
Rentar espacio para plantaioficina
Diseñar unidad física Ensamblar prototipo
Orob.
=_75
y
:a.-~=~ =
INICIO
FIGURA 6 .15
::p:,:o· PO de ::'('"..J eoa ~a
.A. y
Diseño electrónico
personal
la c-n.e!:la :;e;;:
folla y
S;;' .,
eces ~.a
re:raoa,o
Red de p recedencias modificada para el desarrollo de un nuevo p roducto
FI GURA 6 .16 \lodelo de s imulación d e Monte Ca rio pa ra el ej emplo de DNP
....... ,. . .
f uke.
C»rM:~~,r~st.tn
............. "Yfr9JKt ~
.......,....,..,. J« ~•.)I
l a*C: ~W.,.~..O • ...,......,..t'Y2~~«l tfl0r...,....-...c,..u... • •"'" • \ l l~/trit {,.idl. q.....,) TMit O ~~ii ............ .,.J f ltc'tr~fo!l9,..,.,.:1:(ot M~& .... ~tt750J\ll't,) r.d t tKI!ti:.il6 ( $1101llwt.) Tut~: t - ~l •.......,..-.4•Mftv.,..Wn~.t ,..•lwfMC*Htl iZ.tXI'J Tt*J - (.u_._._~) • t«MciM{kJrrrf: t( ~ '•*>
............,l'Y t.-.c ...-o...,...,..,... w
T4rlli. Ci: (I;H.a"-'t ,......._,..)ll..........,ttit_,. p«ltto;a,.; •t$1400J ...-t¡) TMf
ción, el admi nistrador encuentra el tiempo de ej ecución del proyecto, el costo de mano de obra directa y la holgura total asociada con cada tarea del proyecto. En la figura 6.16 se da el resultado de 200 corridas de simulación.
TEORÍA DE RESTRICCIONES Y EL AMORTIGUADOR DEL PROYECTO En su libro Critica/ Chain, Goldratt (1997) aplica la teoría de restricciones (TOC, theory of constraims) a la administración de proyectos complejos y presenta una alternativa a la simulaci ón de Monte Cario. Fundamentalmente, el enfoque de Goldratt está basado en el método de la ruta crítica detenninística (CPM) con la adición de amortiguadores para manejar la incertidumbre relacionada con las duraciones de las tareas. Como describen Goldratt ( 1997), Newbold ( 1998) y Lcach (2000), entre otros, un administrador de proyectos debe primero identificar la ruta crítica, es decir,
150
CAPÍTULO 6
PLANEACIÓN CON INCERTIDUMBRE
el conjunto de tareas que incluye requerim ientos de recursos, así como dependencias de precedencia y determina la duración global del proyecto. La cadena crítica es la ruta crítica con recursos restringidos que se analiza en el capítulo 8. Al aplicar la teoría de resLriccio nes, G oldratt propone lo siguiente: •
Usar e l modelo CPM detemtinistico con amortiguadores para manejar la incertidumbre.
•
Colocar un amortiguador al final del programa del proyecto para proteger la fecha de terminación del cliente.
•
Aprovechar la restricción de recursos (comprobar que los recursos se utilicen por completo).
•
Evitar desperdiciar el tiempo de holgura promoviendo que las rareas terminen antes.
•
Desarrollar un plan y apegarse a él.
•
Supervisar con cuidado e l estado de los amortiguadores y comunicarlo a los demás miembros del equipo de proyecto de manera regular.
•
Verificar que e l equipo del proyecto esté 100% enfocado a las tareas de la cadena crítica.
Goldratt también reconoce los problemas que atañen a la estimación de las duraciones de las tareas necesarias para crear un plan inicial del proyecto. Para evitar sesgos de estimación, Goldratt recomienda usar la mediana para eliminar el "colchón" de las estimaciones y evitar desperdiciar la holgura (contrario a la ley de Parkinson). Sin embargo, calcular la mediana requiere que los admi nisLradores estime n la duración optimista y pesimista para cada rarea, así como el sesgo de la distribución de probabilidad de la duración de las tareas. Las dificultades relacionadas con la estimación de la duración se analizaron en el capítulo 2. Al aplicar la teoría de restricciones, Goldratt sugiere colocar amortiguadores en varios puntos de la cadena crítica para proteger la programación. De acuerdo con Newbold ( 1998), habrá tres tipos de amortiguadores: un amortiguador del proyecto, amortiguadores de alimentación y amortiguadores de recursos (los amortiguadores de alimentación y de recursos se analizan en el capítulo 8 en la sección "asignación de recursos y la cadena crítica"). El amortiguador del proyecto se coloca después de la última tarea del proyecto, para proteger la programación del proyecto. Como las duraciones de las tareas son aleatorias, colocar un amortiguador al final del proyecto y eliminar las contingenc ias de cada rarea (usando la mediana de la duración y empezando todas las tareas en su tiempo de inicio más cercano) permite al administrador de un proyecto unir los ~e sgos y las fluctuaciones aleatorias asociadas con todas las tareas . Para ilustrar esto, co nsidere un proyecto sencillo de dos tareas A y B que realizará la misma persona (o equipo) en forma secuencial. Suponga que la duración de la tarea A se describe por una distribución nom1al con media de 20 días y desviación estándar de 5 días, y que la duración de la tarea B se describe por una distribución normal con media de 30 días y desviación estándar de 8 días. Si el admi nistrador del proyecto quiere asegurarse de que cada tarea tenga 95% de probabilidad de terminar a tiempo (lo que corresponde a z = 1.64 en la tabla del apéndice 6A), deberá conLar con 20 + 1.64(5) = 28.2 días para tem1inar la tarea A y con 30 + 1.64(8) = 43.12 días para terminar la tarea B. Así, el amortiguador total integrado en este programa será de 8.2 + 13.12 21.32 días. Sin embargo, el administrador observa que puede Lratar las dos tareas como una sola y ganar mucho en eficiencia. Para combinar las dos tareas, suma las medias y las varianzas de las tareas (suponiendo que las tareas originales sean estadísticamente independientes ) y obtiene la tarea combinada con media de 50 días (30 días + 20 días) y varianza igual a 89 días (25 días + 64 días). Si hay un número suficiente de tareas, será razonable suponer que la duración de la tarea combinada es N(50, 89) N(50, 9.4). Ahora, si el adminisLrador quiere 95% de probabilidad de que el proyecto termine a tiempo, deberá prometer que terminará en 65.47 días (50+ 1.64 x 9.4 días) en lugar de en el tiempo anterior de 7 1.32 días. Por lo tanto, el adm in istrador ha ahorrado 7 1.32-65.47 5.85 días al usar un
=
=
=
TE ORlA DE RESTF.:.cxx>~ES Y EL AMORTIGUADOR DEL PROYECTO
151
solo amortiguador de proyecto igual a 15.47 días en lugar de amortiguadores individuales para cada tarea. y tiene la misma probabilidad de terminar el proyecto a tiempo. De acuerdo con Newbold ( 1998), el tamaño del amortiguador del proyec to no es claro; de hecho, él establece que "en la práctica deseamos amortiguadores de tamaños que sean suficientemente buenos. Sin duda podríamos entrar en detalles con fórmulas y cálculos, tiempos en el peor caso y tiempos en el mejor caso, etcétera. Esto no valdría la pena. Lo datos no son suficientemente buenos para apoyar cálculos complejos o precisión". De cualquier manera, ewbold sugiere "para aquellos que desean un método científico para determinar el tamaño de los amoniguadores" el amoniguador del proyecto debe establecer como
.----------------------
¿:
(tf - Jlk )2
tareas k en la cadena crílica
donde t! es la estimación más pesimista de la duración de la tarea k) llt es la duración media (o la mediana si sigue la sugerencia de Goldratt). De acuerdo con Newbold. este amortiguador representa aproximadamente dos desviaciones estándar, de manera que 90% de lo proyectos terminarán e n el tiempo asignado (suponiendo una distribución normal). Para ilustrar un an10niguador de proyecto, considere el ejemplo 1 de PERT Clásico presentado e n la figura 6.1. En la figura 6. 17 se presenta la red del proyecto modificada, con el an10niguador del proyecto agregado. Con las duraciones esperadas de las tareas, el administrador del proyecto aplica el CPM determinístico y encuentra que INlCIO-A-C-E-F-FIN es la ruta crítica (note que éste es el mismo proceso de PERT C lásico). La duración esperada de esta ruta es 23.83 semanas con una varianza de 8.25 semanas. Empleando las duraciones pesimistas estimadas de las tareas y las duraciones esperadas calc uladas (figura 6. 1), el administrador obtiene el tamaño del amoniguador del proyecto siguiendo la sugerencia de Newbold; los cálculos se indican en la tabla dada en la figura 6. 18. Por lo tanto, el amoniguador del proyecto es igual a 9.57 semanas, ya que Amonig uador
=
2
(tf - Jlk ) = ../91.59 = 9.57 semanas
Goldratt, Newbold y otros sugieren establecer la fecha de entrega al cliente agregando el amortiguador del proyecto a la duración de la ruta crítica en e l modelo PERT Clásico; en este ejemplo, el
Amortiguador del proyecto
::¡GURA 6 . 17
Ejemplo 1 de PERT Clá sico con am o rtiguador de proyecto
152
CAPÍTULO 6
PLANEACIÓN CON INCERTIDUM BRE
FIGURA 6 . 18 Cálculo de un amortiguador de tiempo para el ejemplo 1 de PERT
Tarea crítica
Descripción
Estimación del tiempo pesimista, tp
es pe rada, ~
fP - ~
(tp - ~) 2
Duración
A
Análisis de req uerimientos
14
6.67
7.33
53.73
e
13
7.83
5.17
26.73
E
Adquisición de hardware Implantación
7
5.00
2.00
4.00
F
Pruebas
7
4.33
2.67
7.13 91.59
administrador espera que el proyecto termine en 23.83 + 9.57 =33.4 semanas. Con la informacióc de la simulación Monte Cario, el adminiSLrador puede calcular la probabilidad de que el proyecto de hecho termine en 33.4 semanas. En este caso, una simulación Monte Cario con 200 repeticiones estima que el tiempo de ejecución es 27.6 semanas con una varianza de 18.2 semanas. Suponiendo que la ej ecución del proyecto tiene una distribución normal, la probabilidad de que el proyecto termine en la fecha prometida es Pr[z
~
1.36] = 0.91
En el ejemplo 3 de PERT, el administrador también puede agregar un amortiguador. Como las tareas B y D se encuentran en la ruta crítica esperada (con CPM determinístico), el amortiguador del proyecto (usando los cálculos sugeridos por Newbold) es igual a Amortiguador=
f
L
Uf -
Vtareas By D
2 Jlk)
= ~(12-10)2 +( 12-9.3)2 = -.!1126 = 3.36
La duración esperada del proyecto es ento nces 19.3 + 3.36 = 22.66 semanas; según la tabla de la figura 6.7 sólo hay 18% de posibilidad de que el proyecto se termine en este tiempo (recuerde que la duración esperada verdadera de este proyecto es 23.22 semanas). Aunque el uso de un amortiguador de proyecto sin duda es mej or que sólo confiar en Jos cálcul os de PERT Clásico, esta duración esperada del proyecto puede aún ser muy optimista.
OTRAS IMPLICACIONES DE LA INCERTIDUMBRE EN EL PROYECTO Cuando se reconoce que las duraciones de las tareas de hecho son variables aleatorias, se e ncuentran numerosas implicaciones que son administrativamente significativas (y alg unas veces van en contra de la intuición). Para ilustrar esto, se considerará inicialmente un proyecto senci llo con sólo dos tareas que se pueden realizar simultáneamente como se indica en la figura 6.19. Las duraciones de las dos tareas son variables aleatorias que pueden describirse por una distribución simétrica (como la normal) con una duración media de 30 días. Se supondrá también que se ha dado una fecha de entrega (de notada por D ) dentro de 30 días. Si no hay incertidumbre (es decir, si las du raciones de las tareas son determinfsticas), es claro que el tiempo de ejecución del proyecto es 30 días y no se espera que se retrase más allá de esta fecha. Sin embargo, como las duraciones de las tareas son aleatorias, el proyecto se retrasará si cualquiera de las tareas dura más de 30 días. Dado que se supone que la duración de ambas tareas está descrita por una distribución simétrica con media de 30 días, se sabe que la probabilidad de que cada tarea termine en 30 días o menos es 50%. Por lo tanto, la probabilidad de que este proyecto se retrase es Pr[proyecto se retrase]
=
Pr[al menos una tarea> 30 días] = 1 - Pr[ninguna tarea se retrase]
OTRAS IMPUCAOONES DE LA INCERTIDUMBRE EN EL PROYECTO
153
FIGURA 6 . 19 Ejemplo de proyecto
=1 -
Pr[A $ 30 días y B $ 30 días) (0.5) (0.5) =0.75 Esto es, existe una probabilidad de 75% de que el proyecto se retrase más allá de la fecha de entrega. ¿Qué pasa con la probabilidad de que el proyecto se retrase si hay más de dos tareas simultáneas (aun cuando la misma distribución simétrica con media de 30 días describa las duraciones de todas las tareas)? En general, la probabilidad de que el proyecto se retrase e 1 - (0.5yv, donde N es el número de tareas; la probabilidad de que un proyecto se retrase está dada como función de N en la figura 6.20. Como se ve, la probabilidad de que el proyecto se retrase es 99.2% cuando sólo se tiene 7 tareas simultáneas.
= 1-
Comportamiento de los trabajadores y duración esperada del proyecto El profesor C. N. Parkinson (1957) observó en 1957 que "el trabajo se expande para que se ocupe todo el tiempo disponible para terminarlo", expresión conocida como ley de Parkinson. Krakowski (1974) analiza en forma cómica las implicaciones de la ley de Parkinson explicando que la consecuencia es que todos los valores de holgura serán siempre iguales a cero. Gutiérrez y Kouvelis ( 1991 ) emplearon de manera más seria la ley de Parkinson para analizar el componarniento de los trabajadores y su impacto en las fechas de entrega, el contenido real de trabajo y la duración esperada del proyecto. Según Gutiérrez y Kouvelis se pueden considerar las implicaciones de la ley de Parkinson examinando un proyecto sencillo con dos tareas que deben realizarse en ecuencia; se supone que el mismo trabajador o subcontratista realiza ambas tareas. Las duraciones son variables aleatorias T; con duraciones esperadas E[T;] para i 1, 2. Suponiendo independencia, es claro que el tiempo es pe-
=
R GURA 6.20 ~obabilidad de que " proyecto se retrase .:uando las tareas son '"'m ultáneas
Número de tareas ( N)
Probabi lidad de que el proyecto se retrase
2 3
75.0% 87.5% 93.8% 96.9% 98.4% 99.2% 99.6% 99.8% 99.9%
4
5 6 7 8 9 10
154
CAPÍTULO 6
PLANEACIÓN CON INCERTIDUMBRE
rado de ejecución del proyecto (denotado por T) es igual a la suma de las duraciones esperadas de las dos tareas; es decir, E[T]
= E[T1]
+ E[T2]
¿Qué pasa cuando los trabajadoreslsubcontratistas tienen un plazo de entrega D? La ley de Parkinson establece que el trabajo se expande (si es necesario) de manera que el proyecto nunca termina antes del plazo de entrega D. Por lo tanto, el tiempo de ejecución esperado del proyecto, que ahora es una función de D, se define como E[T(D)] = E(T1) + E(T2) +E{ máx[O, (D - T 1 - T2)]} Para ilustrar esto, considere el ejemplo de la figura 6.21 , en el que las duraciones de las tareas están dadas por probabilidades discretas. Como se indica, la duración esperada de la primera tarea es 8 días y la duración esperada de la segunda es 16 días, de manera que E[T] = E[T1] + E[T2] = 8 + 16 = 24 días Suponga que se establece como plazo de entregaD= 24 días, lo que representa una fecha de entrega "razonable" para los trabajadores o subcontratistas. En este caso, se pueden enumerar las 6 duraciones posibles del proyecto; como se supone que el trabajo se amplía hasta llenar el tiempo asignado, cualquier opción de duraciones de las tareas menor al plazo de entrega se extiende a 24 días. Los cálculos se muestran en la figura 6.22. Usando los cálculos del tiempo de ejecución del proyecto y sus probabilidades respectivas, se encuentra que la duración esperada del proyecto ahora es 25.0 días; es decir, es posible que se haya retrasado el proyecto simplemente por establecer una fecha de entrega. Siguiendo este enfoque, se puede investigar también el impacto del comportamiento de otros trabajadores. Por ejemplo, suponga que se tienen trabajadores morosos que esperan el último momento posible para empezar una tarea, pero que no se retrasan una vez iniciado el trabajo. Entonces, si en el ejemplo de la figura 6.21 un trabajador moroso termina la primera tarea en 7 días, retrasará un día el inicio de la segunda tarea, ya que espera que la segunda tarea tome sólo 16 días. Los cálculos para el caso de un trabajador moroso se dan en la figura 6.23. La duración esperada del proyecto para el trabajador moroso es igual a E'[T(D)]
= E(T 1) + E(T2) + E(máx{O, [D- T 1 - E(T2)]}) = 8 + 16 + 1 (.3) = 24.3 días
En general, se puede demostrar que E[T(D)]
~
E'[T(D)]
~
D
Este resultado un poco sorprendente tiene varias implicaciones. Primera, los adm inistradores deben esperar que el proyecto termine después de la fecha de entrega si los trabajadores son morosos o siguen la ley de Parkinson. Esto ocurre aun cuando la primera tarea termine antes de lo esperado y la fecha de entrega sea "razonable" e igual a la suma de las duraciones esperadas de las tareas. Segundo,
Valores de T 1 Prob. Valores de T2 Prob. Valores de T 1 Prob.
7 8 9 FIGURA 6.21 del trabajador
0.3 0.4 0.3 8.0
Valores de T2 Prob.
14 18
0.5 0.5 16.0
Ej emp lo del comportamiento
7 7 8 8 9 9
0.3 0.3 0.4 0.4 0.3 0.3
14 18 14 18 14 18
0.5 0.5 0.5 0.5 0.5 0.5
Tiempo de ejecución Prob.
24 25 24 26 24 27
0.15 0.15 0.20 0.20 0.15 0.15
FIGURA 6.22 Co mporta m iento del trabajador que sigue la ley de Parkinso n
OTRAS IMPliCACIONES DE LA INCERTIDUMBRE EN EL PROYECTO
URA 6 . 23
- - ;;np orta m iento
del tra-
.....:.: ador moroso
Valores de T1
Prob .
E [retraso]= máx[O,O-T1 - E{T2)]
7
0.3 0.4 0.3
o o
8 9
155
E [ejecución]
1
24 24 25
es usual que los trabajadores morosos tenninen un proyecto antes que los trabajadores que "expanden", lo que implica que los administradores tratarán de mantener a los trabajadores tan ocupados como sea posible para evitar tiempos de holgura. Como señalan Gutiérrez y Kouvelis, los administradores pueden reducir estas consecuencias negativas estableciendo fechas de entrega tan justas como sea posible. Sin embargo, los plazos demasiado apretados pueden traer otros efectos negativos para trabajadores y administradores, incluyendo estrés y deserción. De nuevo, el administrador debe optar por el trueque óptimo.
Variación en la tarea y duración esperada del proyecto Debe ser evidente que la variación en las duraciones de las tareas y los costos dificultan la adm inistración del proyecto y pueden tener consecuencias inesperadas. Un ejemplo de los efectos negativos de aumentar la varianza de las tareas es la conclusión de Schonberger ( 198 1) cuya hipó tesis es que un incremento en la variabilidad de las duraciones de las tareas producirá un incremento en la duración esperada del proyecto. Un pequeño ejemplo ilustra la hipótesis de Schonberger y el razonamiento en que se apoya. Suponga que se tiene un proyecto con dos tareas (A y B) que pueden ser simultáneas; las duraciones de las tareas son variables aleatori as que pueden tomar sólo un número limitado de valores discretos. Los detalles de este ejemplo se dan en la figura 6.24. Como se ve, la duración esperada de la tarea A es 14 días (con varianza de 0.8 días) y la duración esperada de la tarea B es 12.5 días (con varianza de 6.3 días). En un mundo determinístico, el proyecto tomaría 14 días, es decir, la longitud de la ruta crítica esperada. E n este caso se pueden enumerar las seis ejecuciones y encontrar el valor verdadero de la duración esperada del proyecto; n GURA 6.24 -=-em plo d e los efectos .:e la va riación en la
::.re a
Duración de la tarea A Probabilidad Duración de la tarea B Probabilidad
12 14 16 14.0
0.1 0.8 0.1
10.0 15.0 12.5
0.5 0.5
156
CAPÍTULO 6
PLANEACION CON INCERTIDUMBRE
estos cálculos se dan en la figura 6.22. Multiplicando la probabilidad de cada ejecución por su tiempo asociado y sumando estos valores se obtiene un tiempo de ejecución esperado del proyecto de 14.55 días. Para probar la hipótesis de Schonberger, se puede aumentar la varianza -pero no la mediade la tarea A modificando las probabilidades de cada duración. Las nuevas probabilidades se dan en la fig ura 6.25. Con las probabilidades modificadas de la figura 6.25, la varianza de la tarea A aumenta ahora a 2.4 d ías (la media sigue siendo 14 días). Para medir el efecto de esta modificación en la duración esperada del proyecto, la figura 6.26 repite los cálculos con las probabilidades de la figura 6.25 modificadas (observe que los va lores dados bajo máx[A. B] no cambian). Ahora la duración esperada del proyecto ha aumentado a 14.65 días. Se puede demostrar que siempre que aumenten las varianzas de las tareas, el tiempo modificado de ejecución del proyecto será mayor o igual que el tiempo de ejecución actual del proyecto si hay tareas que se pueden realizar en paralelo. (Por ejemplo, si las tareas A y B se ejecutan en secuencia, el aumento en la varianza de las tareas no afectará el tiempo de ejecución esperado del proyecto.) Los ejemplos dados en las figuras 6.21 a 6.23 ilustran también que si una tarea tiene una duración mucho mayor (o mucho menor) que la otra, modificar la varianza de una tarea tendrá poco o ni ngún efecto en el tiempo de ejecución del proyecto. Esto se puede ver cambiando las duraciones posibles de la tarea B, digamos, a 100 y 150 días (en lugar de 10 y 15) con iguales probabilidades. Gutiérrez y Paul (1998) investigaron con detalle estas relaciones y desarrollaron condiciones generales en l as que una mayor variabilidad en la rarea produce mayor tiempo de ejecución del proyecto. El ejemplo ilustra por qué (y tal vez dónde) los administradores deben tratar de reducir el tiempo de ejecución de un proyecto. Los modelos de simulación Monte Cario descritos en este capítulo pueden ayudar al adminjstrador a evaluar el impacto potencial.
COMPRESIÓN DEL PROVECTO CON DURACIONES INCIERTAS DE LAS TAREAS En el capítulo 5, e n la sección "compresión del proyecto: trueques tiempo-costo", se analizó la compresión de un proyecto para encontrar los trueques óptimos entre los costos directos por un lado y los costos indirectos/generales (y tal vez costos de penalización y bonos) por el otro, cuando se supone que las duraciones de las tareas son detem1inísticas. Si las duraciones de las tareas son estocásticas, debe modificarse el proceso descrito en el capítulo anterior.
FIGURA 6 .25 M ayor va rianza en la tarea A
FIGURA 6 .26 Cálcu lo del tiempo de ejecución del proyecto
Ejecución
Duración de la t area A
Duración d e la ta rea B
1 2 3 4 5 6
12 14 16 12 14 16
10 10 10 15 15 15
Probabilidad
0.05 0.4 0.05 0.05 0.4 0.05
Duración de la tarea A
Probabilidad
Duración de la t area A
Probabilidad
12 14 16 14.0
0.3 0.4 0.3
10 15
0.5 0.5
12.5
M áx (A,B)
12 14 16 15 15 16
COMPRESIÓN DEL PRO'I::c-;) CO' DURACIONES INCIERTAS DE LAS TAREAS
157
Johnson y Schou ( 1990) describen tres reglas JX!f'! comprimir proyectos con redes estocásticas; estas reglas indican cuál o cuáles tareas seleccioll2T ~ a...··elerar cuando se comprime un proyecto de manera iterativa. (Recuerde que en el capírulo 5 se II10SlrÓ que tales procesos iterativos no necesariamente proporcionan una solución óptima.) EstaS rres regt::.~ ~describen como sigue: •
Regla 1: seleccione la tarea de la ruta crítica esperada con menor pendiente (es decir. con el menor costo marginal de aceleración por periodo ,.
•
Regla 2: seleccione la tarea con el menor índice crítico.
•
Regla 3: seleccione la tarea con el me nor costo marginal esperado de aceleración por periodo.
La regla 1 se basa en la regla usada en el capítulo anterior para acelerar pro)eclos cuando las duraciones son determinísticas y se supone que existe un trueque tiempo-coslo lineal. En este caso. para calcular la pendiente debemos estimar los tiempos optimista, pesimista y más probable. tamo en condiciones normales como en condiciones aceleradas y encontrar la duración normal esperada de la tarea (denotada E[r"]) y la duración acelerada esperada de la tarea (denotada E{r ]) usando la fórmula del modelo PERT Clásico descrita en este capítulo (y en el capítulo 2). Sea C't el costo total esperado por ejecutar la tarea con su duración normal y sea cA el costo total por ejecutar la tarea con su duración esperada acelerada, el valor absoluto del costo marginal o la pendiente se calcula entonces (en el capítulo 5 se hizo de manera similar) como sigue: C N - CA
Costo marginal (pendiente) de acelerar la tarea un periodo=
----~1
E[rN] -E[tA 1 La regla 2 está basada en el trabajo de Van Slyke (1963), quie n sugiere elegir la tarea con el índice crítico más grande. Esta regla está motivada por la idea de que la tarea con el índice crítico más alto tiene mayor probabilidad de ser una tarea crítica; entonces, acelerar esa tarea tiene más probabilidad de acelerar el proyecto. Después de acelerar la tarea (y presumiblemente el proyecto), el administrador deberá recalcular los índices críticos antes de repetir el proceso y continuar comprimiendo el proyecto. Si hay un empate, se puede usar una de las otras reglas para romperlo. La regla 3 es una modificación de la regla 1 que incluye, en los cálculos, los índices críticos. Multiplicando la diferencia {E[rN]- E[r]) por el índice crítico, se encuentra el tiempo esperado que se puede acelerar el proyecto. Este valor se usa para calcular el costo marginal de acelerar cada tarea: CN -CA Costo marginal (pendiente) de acelerar una tarea un periodo= 1-~----~1 CI { E{tN]- EltA
J}
donde el índice crítico se denota por CI (criticality index). La tarea con el menor valor se e lige para acelerarla. Igual que con la regla 2, el índice crítico (CD debe recalcularse después de cada compresión del proyecto. Johnson y Schou señalan que las condiciones específicas del proyecto determinarán qué regla funcionará mejor. Por ejemplo, si una ruta crítica esperada dominante es significativamente más larga que el resto de las rutas, quizá la primera regla funcione bien. La segunda regla tiene la limitación de que no incluye información de costo, pero funcionará bien si los costos marginales son similares para todas las tareas. La tercera regla combina las ventajas de las dos primeras, pero (como la regla 1) tiene dificultades para estimar los valores E[rN] y E[r] descritas en el capítulo 2.
158
CAPITULO 6
PLANEACIÓN CON INCERTIDUMBRE
CONCLUSIONES Este libro hace hincapié en la naturaleza aleatoria de las duraciones de las tareas. Dado que la mayor parte del software para AP se basa en la suposición de que las duraciones son determinísticas, un administrador prudente debe tener cuidado al usar estas herramientas e interpretar sus resultados. El PERT Clásico fue el resultado de un esfuerzo por desarrollar una herramienta que reconociera la aleatoriedad de manera expl ícita. Si hay sólo una ruta dominante a través de la red de precedencias, los resultados del modelo PERT Clásico pueden ser razonableme nte precisos (Eimaghraby et al., 1999; Gutiérrez y Paul , 2001, y Chao y Yum , 1997 profundizan en el concepto de ruta dominante cuando la duraciones de una tarea son aleatorias). Sin embargo, cuando no hay una ruta dominante. el PERT Clásico da resultados demasiado optimistas que pueden llevar a conclusiones erró neas. Para corregir este sesgo, cada vez má administradores usan simulación Monte Cario y/o el concepto de amortiguador del proyecto propuesto por Goldratt y otros.
PROBLEMAS PARA ESTUDIO 1. Considere la siguiente red de proyecto:
INICIO
En la tabla siguiente se dan tres estimaciones del tiempo (en meses) requerido para cada actividade de la red: Estimación más probable
Estimación pesimista
8
9
10
6
7
9
9
12
15
Actividad
Estimación optimista
(1,2) (1,3) (2,6) (3,4)
5
5
5
(3,5)
8
10
11
(3,6)
11
15
20
(4,5)
3
4
(5,6)
5
6
6 8
(5.7)
8
10
12
(6.7)
4
5
10
El programa original para los eventos respectivos se ha fijado según la estimación más probable; estas estimaciones se dan en la tabla (suponiendo que el proyecto inicia en el tiempo 0). El administrador ha solicitado la siguiente información de los eventos de este proyecto; responda completando la tabla:
PROBLEMAS PARA ESTUDIO
159
Tiempo más cercano Evento número
Valor esperado
Varianza
Programa original
Valor de z
Probabilidad de cumplir con el programa
o 9 8
2
3 4
12
5
18 25 30
6 7
2. Rob D. Store es un contador que prepara declaraciones de impuestos para clientes que presentan su información de ingresos vía Internet. Uno de los problemas de Robes determinar para cuándo prometer a sus clientes que sus declaraciones de impuestos estarán listas para firma y envío. Rob (quien estudi ó administrac ión de proyectos en un programa de maestría) sabe que para cada declaración debe terminar cuatro tareas. Sabe también que su duración varía de acuerdo con probabilidades conocidas. En la siguiente tabla se dan las relaciones de precedencia y las duraciones posibles de las tareas: Días
Prob.
Tarea {1,2)
2 3 4
0.6 0.2 0.2
Tarea (1,3)
1 4
0.1 0.9
Tarea (2,4)
7
9
0.6 0.4
10 2
0.5 0.5
Tarea
Tarea (3,4}
a. Si Rob usa el modelo PERT Clásico y quiere dar a sus clientes una fecha de entrega que tenga por lo menos 60% de posibilidad de ocurrir, ¿cuál es la fecha más cercana que puede prometer que la declaración estará lista? b. En la realidad, ¿cuál es la fecha más cercana que Rob debe prometer que terminará la declaración con al menos 60% de probabilidad de que ocurra? 3. La doctora Denton Fender tiene la siguiente red de precedencias de actividad en los nodos (AON) para un pequeño proyecto de reparación de un automóvil:
160
CAPiTULO 6
PLANEACIÓN CON INCERTIDUMBRE
Ella ha obtenido las estimaciones siguiemes: Duración (semanas) Tarea
Optimista
1
Más probable
Pesimista 8 8 11 16
2
7
2 3
4
4
5
3 9 9
a . Según el modelo PERT Clásico, ¿cuál es el liempo mínimo de ejecución del proyecto que tiene por lo menos 90%: de probabilidad de ocurrir? b. Suponiendo que la fórmula para calcular la desviación estándar de cualquier tareaj (a) se
modifica como sigue:
donde t0 = tiempo optimista y tP = tiempo pesimista. Con esta fórmula modificada para estimar la desviación estándar de la duración de la tarea, ¿cuál es la probabilidad de que el proyecto termine en 26 semanas o menos, según el modelo PERT Clásico? 4. Duncan Tank es un plomero que ti ene un pequeño proyecto representado por la siguiente red de precedencias AON. Duncan no está seguro de la duración de cada tarea; sin embargo, ha estimado varias duraciones posibles y sus probabilidades respectivas dadas después de la red.
1
r------+~~~---Ti-ar_e_a~B=-_.~~-------.
FIN
Tarea C Tarea A
Tarea C
1
j
Tarea B
2 (0.3)
4(0.45)
5 (0.5)
3 (0.7)
6 (0.55}
10 (0.5}
a. Si Duncan usa el modelo PERT Clásico y quiere dar a sus clientes una fecha de entrega que tenga por lo menos 60% de posibilidades de ocurrir, ¿cuál es la fecha más cercana que Duncan puede prometer a sus clientes para terminar el proyecto? b. En realidad, ¿cuál es la fecha más próxima en la que Duncar debería prometer a sus clientes que el proyecto estaría terminado con 60% de posibilidades de que esto ocurra?
PROBLEMAS PARA ESTUDIO
161
5. Un admin istrador de proyectos tiene la siguie nte red de precedencias para un proyecto pequeño:
INICIO
Los tiempos estimados son los siguientes: Duración (semanas) Tarea
Optimista
Más probable
Pesimista
1 2
4 1 2
6 3 9 3
14 11 16 8
3 4
a. Encuentre la duración esperada del proyec10 y su varían La. de acuerdo con el modelo PERT Clásico. b. Según el modelo PERT Clásico. ¿cuál es la probabilidad de que el proyecto termine en 13 semanas o menos? c. ¿Cuál es la probabilidad verdadera de que el proyecto termi ne en 13 semanas o menos? 6. Un pequeño proyecto está compuesto de 7 actividades c uyas duraciones estimadas se dan en la tabla. Las acúvidades se identifican por los números en los nodos de inicio (i) y terminación (j). Duración estimada (semanas)
1 2 3 4 5
j
Optimista
Más probable
Pesimista
2 3 4 5 5
1 1 2
1 4
7
7
9
2 3
2 6 3
14
6 6
2
7
10 15
a . Usando el modelo PERT Clás ico, ¿cuál es la probabil idad de que el proyecto termine dos semanas antes de su duración esperada? b. Según el modelo PERT Clásico, ¿qué fecha de terminación tiene 90% (o más) de posibilidades de que se c umpla? c. Una de las críticas princi pales al modelo PERT Clásico es que se apoya sólo en la ruta más larga esperada de la red de precedencias. Una posible solución sugerida es usar la ruta más larga y la segunda más larga para calcular la duración esperada del proyecto. Si se usa
162
CAPÍTULO 6
PLANEACIÓN CON INCERTIDUMBRE
este enfoque en este problema, ¿cuál es la probabilidad de que el proyecto termine en 16 semanas o menos? 1. Para el proyecto de desarrollo de un nuevo producto (DNP) de la figura 6.15, calcule la ruta crítica esperada y compare sus resultados con los de la simulación dados en la figura 6. 16. ¿Qué concluye?
8. Para el proyecto de desarrollo de un nuevo producto (DNP) dado en la figura 6.15, modifique la red de precedencias para permhir que la tarea de diseño del prototipo se pueda repetir por Jo menos dos veces. Modifique el modelo de simulación de manera adecuada (en la hoja de cálculo del CD que acompaña al libro) y compare sus resultados con los de la figura 6. 16.
REFERENCIAS Chames, A., W. W. Cooper y G. L. Thompson. ·'Critical Path Analyses via Chance Constrained and Stochastic Prograrnming'', Operatio1zs Reseurch 12 ( 1964): 460-470. Cho, J. G. y B. J. Yum. "An Uncertainty lmponance Measure of Activiries in PERT 'etworks'', lmemalionul Joumul of Production Research 3S ( 1997): 2737-27S7. Craven, J. P. The Silem \Var: The Cold \Var Bau/e beneath the Sea. Nueva York: Simon & Schustcr, 2001. Elmaghraby, S. E. "On the Expecte(J Duration of PERT Type 'etworks", Ma11agemem Science l. núm. 3 ( 1967): 299-306. Elmaghraby, S. E .. Y. Falhi y M. R. Taner. "On !he Sensitivity of Projecl Variabilily lo Activity Mean Duration", Joumal of Production Economics 62 ( 1999): 219-232. Goldran, E. Critica/ Chain. Great Barrington, Mass. : North River Press. 1997. Gutiérrez, G . y P. Kouvelis. "Parl::inson·s Law and lts lmplications for Project Management'·. Manugemelll Science 37, núm. 8 (agosto, 1991): 990-1001. Gutiérrez, G. y A. Paul. "Analysis of the Effects of Uncertainty, Risk-pooling. and Subcontracting Mechanisms on Project Perfo rmance", Operatimzs Research 48 ( 1998): 927- 938. Guliérrez, G. y A. Paul. " Robustness to Variability in Project Networks", 1/E TransactioiiS 33 (200 1): 649-
APÉNDICE 6A. TABLA DE LA DISTRIBUCIÓN NORMAL ESTÁNDAR (VALORES POSITIVOS DE z)
APÉNDICE 6A. TABLA DE LA DISTRIBUCIÓN NORMAL ESTÁNDAR (VALORES POSITIVOS DE z) z
o
0.01
0.02
0.03
0.04
0.05
0.06
0.520 0.560 0.599
0.07
0.08
0.09
0.524
0.528 0.567 0.606
0.532 0.571
0 .536 0.575 0.614
0.637
0.564 0.603 0.641
0.670
0 .674
0.677
0.709 0 .742 0.773
0.712
0.0
0.500
0.504
0.508
0.512
0.516
0.1 0.2 0.3
0.540 0.579 0.618
0.544 0.583 0.622
0.548
0.556 0.595 0.633
0 .4
0.655
0.659
0.587 0.626 0.663
0.552 0.591
0 .5
0.691
0.695
0.698
0.702
0.705
0 .6 0 .7
0.726 0.758
0.729 0.761
0.732
0 .8 0 .9
0.788 0.816
0.791 0.819
0.764 0.794
0.736 0.767 0.797
0.821
0.824
0.739 0.770 0 .800 0.826
1.0 1.1
0.841 0.864
0.844 0.867
0.848
0.851
1.2 1.3 1.4
0.885 0.903 0.919
0 .887 0.905 0.921
0.846 0.869 0.889
1.5 1.6
0.933 0.945
0.934 0.946
0.907 0.922 0.936 0.947
0.871 0.891 0.908 0.924
0.873 0.893 0.910 0.925 0.938 0.949
1.7 1.8
0.955 0.964
0.956 0 .965
0.957 0.966
0.958 0.966
1.9
0.971
0.972
0.973
0.973
2 .0 2.1
0.977 0.982
0.978 0 .983
0.978 0.983
0.979 0.983
2.2
0.986
0.986
0.987
2.3 2.4
0.989 0.992
0.990 0.992
0.990 0.992
2.5
0.994
0.994
2.6 2.7
0 .995 0 .997
0 .995 0 .997
2.8
0 .997
2.9 3.0
0 .998 0 .999
0 .998 0 .999
0.629 0.666
0.937 0.948
0.802 0.829 0.853 0.875 0.894 0.911 0.926 0.939 0.951
0 .745 0.776 0.805 0.831 0.855 0.877 0.896 0.913 0.928 0.941 0.952 0.961
0.959
0.960
0.967 0.974
0.968 0.974
0.969
0.980 0.984 0.988
0.980 0.985
0 .987
0.979 0.984 0.987
0.988
0 .990 0.992
0 .990 0 .993
0.991 0.993
0.991 0.993
0.994
0 .994
0.995 0.996 0.997
0 .998
0 .996 0 .997 0 .998
0 .994 0 .996 0 .997
0.995
0.996 0.997 0.998
0.998 0 .999
0.998 0 .999
0 .998 0 .998 0 .999
0.998 0.998 0.999
0.975
0.996 0.997 0.998 0.998 0.999
0.644 0.681 0.716 0.749 0.779 0 .808 0.834 0.858 0.879 0.898 0 .915 0.929 0.942 0.953 0.962 0.969 0.976 0.981 0.985 0.988 0.991 0.993 0.995 0.996 0.997 0.998 0.999 0.999
0.610 0.648
0.652
0.684 0.719
0.688 0.722
0.752
0.755 0.785 0.813
0.782 0 .811 0.836 0.860 0.881 0.900 0.916 0.931 0.943 0.954 0.962 0.970 0.976 0.981 0.985 0.989 0.991 0.993 0.995 0.996 0.997 0.998 0.999 0.999
0.839 0.862 0.883 0.901 0.918 0.932 0.944 0.954 0.963 0.971 0.977 0.982 0.986 0.989 0.992 0.994 0.995 0.996 0.997 0.998 0.999 0.999
163
164
CAPÍTULO 6
PLANEACIÓN CON INCERTIDUMBRE
APÉNDICE 6A. (CONTINUACIÓN) TABLA DE LA DISTRIBUCIÓN NORMAL ESTÁNDAR (VALORES POSITIVOS DE z) z
0.09
0.08
0.07
0.06
0.05
0.04
0.03
0.02
0.01
o
-3.0 -2.9 -2.8 -2.7 -2.6 -2.5 -2.4 -2.3 -2.2 -2.1 -2.0 -1.9 -1.8 -1.7 -1.6 -1.5 -1.4 -1.3 -1.2 -1.1 -1.0 -0.9 -0.8 -0.7 -0.6 -0.5 -0.4 -0.3 -0.2 -0.1 0.0
0.002 0.002 0.003 0005 0.006 0.008 O.Q1 0 0.014 0.017 0.022 0.028 0.035 0.044 0.054 0.066 0.079 0.095 0.113 0.133 0.156 0.181 0.209 0.239 0.271 0.305 0.341 0.378 0.417 0.456 0.496 0.536
0.002 0.002 0.003 0.004 0.006 0.008 0.010 0.013 0.017 0.022 0.027 0.034 0.043 0.053 0.064 0.078 0.093 0.111 0.131 0.154 0.179 0.206 0.236 0.268 0.302 0.337 0.374 0.413 0.452 0.492 0.532
0.002 0.002 0.003 0.004 0.006 0.008 0.010 0.013 0.017 0.021 0.027 0.034 0.042 0.052 0.063 0.076 0.092 0.109 0.129 0.152 0.176 0.203 0.233 0.264 0.298 0.334 0.371 0.409 0.448 0.488 0.528
0.002 0.002 0.003 0.004 0.006 0.007 0.010 0.013 0.016 0.021 0.026 0.033 0.041 0.051 0.062 0.075 0.090 0.107 0.127 0.149 0.174 0.200 0.230 0.261 0.295 0.330 0.367 0.405 0.444 0.484 0.524
0.002 0.002 0.003 0.004 0.005 0.006 0.007 0.009 0.012 0.016 0.020 0.026 0.032 0.040 0.049 0.061 0.074 0.089 0.106 0.125 0.147 0.171 0.198 0.227 0.258 0.291 0.326 0.401 0.440 0.480 0.520
0.002 0.002 0.003 0.004 0.005 0.007 0.009 0.012 0.015 0.020 0.025 0.031 0.039 0.048 0.059 0.072 0.087 0.104 0.123 0.145 0.169 0.195 0.224 0.255 0.288 0.323 0.359 0.397 0.436 0.476 0.516
0.001 0.002 0.003 0.004 0.005 0.007 0.009 0.012 0.015 0.019 0.024 0.031 0.038 0.047 0.058 0.071 0.085 0.102 0.121 0.142 0.166 0.192 0.221 0.251 0.284 0.319 0.356 0.394 0.433 0.472 0.512
0.001 0.002 0.003 0.004 0.005 0.007 0.009 0.011 0.015 0.019 0.024 0.030 0.038 0.046 0.057 0.069 0.084 0.100 0.119 0.140 0.164 0.189 0.218 0.248 0.281 0.316 0.352 0.390 0.429 0.468 0.508
0.001 0.002 0.003 0.004 0.005 0.006 0.008 0.011 0.01 4 O.Q18
0.001 0.002 0.003 0.005 0.006 0.008 0.011 0.014 0.018 0.023 0.029 0.036 0.045 0.055 0.067 0.081 0.097 0.115 0.136 0.159 0.184 0.212 0.242 0.274 0.309 0.345 0.382 0.421 0.998 0.460 0.500
0.023 0.029 0.037 0.046 0.056 0.068 0.082 0.099 0.117 0.138 0.161 0.187 0.215 0.245 0.278 0.312 0.348 0.386 0.425 0.464 0.504
CAPÍTULO
..,
ADMINISTRACION DEL RIESGO
U
na parte crítica al administrar cualquier proyecto es definir, analizar y administrar el riesgo del proyecto. Todo proyecto tiene cierto grado de riesgo. aunque con frecuencia muchos administradores de proyecto no lo tienen en cuenta (y obtienen resultados perturbadores). En este capítulo se consideran aspectos relacionados con planear. analiLar y mitigar el riesgo. Por último, se examinará un caso de estudio que ilustra la naturaleza de muchos riesgos de proyectos y las estrategias posibles para administrar estos riesgos. Como se vio en el capítulo 2, muchas organizaciones eligen un portafolio de proyectos que minimiza el riesgo global del proyecto: es decir eligen un portafolio "balanceado" para compensar los riesgos relacionados con la asignación de per onal, recursos, equipo, etcétera, de la misma manera que un individuo diversificaría un portafolio de inversiones. Subcontratar una parte (o la totalidad) del proyecto es otra manera de admi nistrar el riesgo; el tipo de contrato que se firme al subcontratar tiene implicaciones significaóvas en la asignación de riesgos entre quienes tienen intereses en los proyectos. Por ejemplo, un contrato a precio fijo coloca en el subcontratista casi todos los riesgos asociados con el subproyecto, mientras que en un contrato de costo con beneficio el cliente corre la mayor parte de los riesgos. En general, hay dos elementos que definen el riesgo en los proyectos: 1) la probabilidad de un evento o resultado adverso y 2) la severidad o costo de ese evento o resultado. En otras palabras, ¿qué puede pasar (y cuánto puede costar) y cuál es la posibilidad de que ese evento ocurra? La posibilidad de la mayoría de los eventos está innuida por fac tores tanto exógenos como endógenos; por ejemplo, el mal tiempo o una mala administración pueden igualmente retrasar la terminación del proyecto. Las organizaciones deben ser capaces de atender directamente los factores endógenos (por ejemplo, sustituyendo al administrador), pero suele ser más difícil influir en la posibilidad de factores ambientales o exógenos. Algunas veces, las acciones de una organización pueden influir en la posibilidad de un evento adverso, pero tal vez quede cierta incertidumbre. En general, las fuentes de incertidumbre exógenas incluyen: •
Cambios en la tecnología
•
Reglamentos o políticas gubernamentales
•
Pérdidas inesperadas debidas a deterioro, robos, etcétera
•
Fluctuación en los precios y suministros
•
Asuntos legales o contractuales
•
Riesgos naturales como cambios ambientales, terremotos y otros
Los factores endógenos incluyen variaciones aleatorias en el desempeño de una componente, datos inexactos o incompletos, asuntos de personal, los impactos de otros proyectos y el nujo de efectivo, así como la incapacidad de pronosticar con precisión por falta de datos, experiencia o perspectiva Huchzermeier y Loch (200 1) identifican cinco fuentes de incertidumbre o variabilidad que suelen asociarse con proyecto de I&D: •
Variabilidad en la programación (las duraciones de las tareas son aleatorias)
165
166
CAPÍTULO 7
ADMINISTRACIÓN DEL RIESGO
•
Variabilidad en el presupuesto (lo costos pueden variar)
•
Variabilidad en el desempeño (el producto en desarrollo puede no alcanzar las especificaciones propuestas)
•
Variabilidad en los requerimientos del mercado (las especificaciones del producto requeridas por el mercado pueden cambiar)
•
Variabilidad en el rendimiemo en el mercado (el rendimiento puede cambiar por la competencia, cambios ambientales, etcétera)
Estas variaciones pueden deberse a efectos tanto endógenos como exógenos. Los administradores de I&D deben mantener tanta flexibilidad como sea posible a fin de responder a los cambios en estos factores. Algunas organizaciones distinguen los eventos adversos de acuerdo con la magnitud de su impacto posible. En este caso, las organizaciones clasificarán los riesgos potenciales en categorías (pequeño, mediano, grande) de manera que se dé mayor atención a eventos con costos potenciales grandes. Sin embargo, otros administradores creen que este enfoque puede dar conclusiones erróneas y piensan que todos los rie gos deben estudiarse y monitorearsc con cuidado. ¿Cómo puede una organización evitar o reducir los costos potenciales relacionados con eventos o resultados adversos? Es obvio que el primer paso es identificar los eventos adversos, así como las posibilidades de que ocurran y sus impactos. Para cada riesgo/evento identificado, los administradores deben identificar dos acciones posibles. •
Acción preventiva: qué hacer antes de un evento adverso para reducir la posibilidad de que ocurra o atenuar sus efectos.
•
Plan de contingencia: qué hacer si el evento indeseable ocurre.
Por ejemplo, suponga que una empresa está considerando un proyecto de comercio exterior; si la empresa firma un contrato de precio fijo, las fluctuaciones en la tasa de cambio monetario podrían afectar adversamente el rendimiento esperado del proyecto. Como plan preventivo, la organi zación puede considerar el uso de derivados financieros como contratos a plazo y opciones para protegerse del riesgo de las divisas; como plan de contingencia, la organización puede planear reducir el alcance del proyecto si de hecho varía la tasa de cambio y reduce las ganancias del proyecto. Asociado con el plan de contingencia se identifica un "punto de activación" que especifica el momento y las condiciones en las que se pondrá en marcha la acción de contingencia. Por ejemplo, considere un proyecto para implantar la planeación de recursos empresariales (ERP). Un riesgo puede ser un retraso en la adquisición del equipo necesario para que funcione el sistema; para atenuar esta posibilidad, el administrador de proyectos puede adquirir el equipo tan pronto como sea posible (acción preventiva) y si todavía se retrasa, debe rentarlo (plan de contingencia). El administrador debe identificar también una fecha (punto de activación) para negociar los contratos de renta si el equipo no está disponible. Es útil crear un diagrama para cada evento adverso que identifique con claridad cada evento/resullado indeseable, su probabilidad y costo adicional asociados, el plan preventivo y las acciones de contingencia. En la figura 7.1 se da un ejemplo de estos diagramas. La posibilidad de un evento se puede estimar mediante un solo número, un intervalo (como la probabilidad es menor que 70%) o una evaluación cualitativa (baja, media o alta). El costo adicional esperado se puede estimar de manera similar. También se puede agregar una columna a la tabla de la figura 7.1 que especifique el punto de activación de cada acción de contingencia.
HERRAMIENTAS PARA ANALIZAR EL RIESGO DEL PROYECTO Existen varias herramientas útiles para analizar el riesgo de un proyecto. Una de ellas es el dia· grama de tomado, que representa un análisis de sensibilidad de las variables de entrada. Cada variable de entrada varía en secuencia; al iniciar, cada variable se hace igual a un valor estimado
HERRAM IENTAS PARA ANALIZAR El RIESGO DEL PROYECTO
Evento/ resultado indeseable
Probabilidad Costo adicional del evento esperado
Pl an preventivo
167
Acción de contingencia
Investigación de mercado inadecuada
Agregar incentivos al cuestionario
Contratar a una empresa de investigación de mercado
Personal clave abandona la organización
Tratar bien al pe rsonal clave
Contratar sustitutos
Manual de instrucciones mal redactado
Redactar en estrecha colaboración con el usuario final
Subcontratar tareas
El equipo no se entregó a tiempo
Programar su entrega tan pronto como sea posible
Rentar tiempo/capacidad de almacenaje en computadora
FIGURA 7_1
Ejemplo de análisis de riesgo
bajo y después a un valor estimado alto. Para cada valor estimado de la variable de entrada, se calcula el valor global del proyecto. En el ejemplo de la figura 7.2 suponga que se espera que el proyecto propuesto cueste $1 500, con base en la mejor estimación del administrador. Para probar la sensibilidad a cambios en ciertos parámetros clave (como tasa de salarios, tasas de interés y otros), quienes hacen la planeación del proyecto varían cada factor de un valor eslimado bajo a uno alto, con todo los demás factores constantes, y calculan el impacto en el costo total del proyecto. Por ejemplo. suponga que los encargados de la planeación del proyecto creen que la tasa de salarios de mano de obra directa podría incrementarse o disminuir cuando mucho 8% durante la vida del proyecto. En ese caso, los costos esperados del proyecto podrían aumentar a $ 1 760 (si la tasa aumentara) o di minuir a $1 260 (si disminuyera). Como resultado de este análisis de sensibilidad, dado que la tasa de salarios de la mano de obra directa tiene el mayor impac to en la variabilidad del costo potencial del proyecto, las tasas de salarios se enumeran en la parte superior del d iagrama. Cada factor que podría afectar el costo del proyecto se lista en orden decreciente de su impacto potencial. El diagrama resultante recuerda a un tomado, de ahí su nombre. Los diagramas de tornado tienen la desventaja de calcularse variando sólo un factor a la vez, mientras todas las demás variables de entrada se mantienen constantes. Un diagrama de sensibilidad considera cambios simultáneos en todas las variables. En este caso, el administrador varía todas las variables de entrada al mismo tiempo eligiendo valores aleatorios de cada factor en su intervalo especificado. Por ejemplo, puede usar un generador de números aleatorios para establecer el valor de la tasa de salarios, el número de horas de mano de obra directa, etcétera. (Los generadores de números aleatorios en las hojas de cálculo generan un número aleatorio entre cero y uno a partir de una distribución uniforme.) Los complementos de las hojas de cálculo, como Crystal
Tasa de salarios
~~
Ho ras de mano de obra Unidades de material necesarias
~~
$1 290 • • • • • • • • • • • • • • • $1 700 1
$1 265
$1 720 1
Bono por terminar antes
$1 310
$1 680
Costo de una unidad de material
$1 350
Tasas de interés
$1 350
$1 690 $1 640
$1 380
Costos de energía Gastos generales
$1 620 $1 625
$1 400 $1 200
$1 300
$1 400
$1 500
$1 600
Costo del proyecto (miles)
FIGURA 7_2
Ejem plo de diagrama de to rnado
$1 700
$1 800
168
CAPÍTULO 7
ADMINISTRACIÓN DEL RIESGO
Ball* o @Risk, permiten al usuario generar números aleatorios a partir de varias distribuciones. Dados estos valores de las variables de entrada, el admi nistrador calcula el costo del proyecto. Este procedimiento puede repetirse para múhiples conjuntos de valore muestrales para obtener un valor para cada variable de entrada y el costo del proyecto correspondiente. Se puede calcular un coeficien te de correlación entre cada conjunto de variables de entrada y el costo del proyecto, como se indica en el ejemplo de la figura 7.3. En este caso, parece que el costo del proyecto tiene una correlación más fuerte con los cambios en la tasa de costos de mano de obra directa. Por lo tanto, el administrador deberá observar de cerca el valor de esta variable de entrada, ya que es la que tiene el mayor potencial para incrementar el costo del proyecto. Se pueden hacer varias observaciones sobre este diagrama. Primera, note que uno de los factores (bono por terminar antes) tiene una correlación negativa con el costo del proyecto. Esto es natural; indica que un bono mayor es un incentivo mayor para terminar el proyecto antes, lo que parece que reducirá el costo total del proyecto. Seg undo, el sencillo método de muestreo (conocido como simulación Monte Cario) empleado para hacer este diagrama de sensibil idad supone que todos los factores (tasa de salarios, horas de mano de obra, etcétera) son estadísticamente independientes. Esto tal vez no siempre se cumpla. Por ejemplo, si el administrador aumenta las unidades de material necesarias, tendrá que aumentar también las horas de mano de obra directa. Sin embargo, la suposición de que las variables de entrada son estadísticamente independientes, es una limitación de estos diagramas.
TIPOS DE CONTRATO V RIESGO RELATIVO Como se vio en el capítulo 2, el cliente o dueño de un proyecto puede negociar varios tipos de contratos. Todos los contratos influyen en la administración del riesgo. Por ejemplo, el contrato de precio fijo requiere que el contratista absorba todos los costos que exceden al precio negociado del contrato. Como el contratista acepta el riesgo en este caso, el cliente debe esperar pagar un precio más alto que si aceptara pagar los costos excedentes. Por otro lado, los contratos de costo con beneficio especifican que el cliente pagará al contratista todo tiempo y material (T&M) que se requieran para completar el diseño del proyecto. Como en este caso el cliente está asumiendo todo el riesgo, esperará negociar un precio inicial más bajo que en un contrato de precio fijo. Por supuesto, existen muchas variaciones de este tipo de contratos. El cliente y el contratista pueden negociar un contrato de precio fijo con una cláusula que requiera que el cliente pague una FIGURA 7.3 Diagrama de sensibilidad
Tasa de salarios
0.85
Horas de mano de obra
0.73
Unidades de material requeridas
0.62
Bono por terminación anticipada
-o.45
Costo por u nidad de material
0.42
Tasas de interés
0.28
Costos de energía
0.19
Gastos generales
0.10
-o.s
o
0.5
1.0
Ordenados según su correlación con el cost o total d el proyecto
* Crys1al Ball es una serie de herramic:ntas para análisis de riesgo producidas por lkcisioneering que usa simulación Monte Cario jumo con las hojas de cálculo de Excel. @ Risk es un producto similar producido por Palisade Corporal ion.
TIPOS DE CONTRATO Y RIESGO RELATIVO
169
tasa más alta si los costos de mano de obra o material exceden cierto nivel. El cliente y el contrati sta pueden negociar también un contrato por una parte de l proyecto, entendiéndose que el resto será negociado en un momento posterior. Los incentivos de contrato también determinan cómo se distribuyen los riesgos. Un contrato de precio fijo con una penalización especificada si el proyecto se retrasa respecto a cierta fecha de entrega, pasa parte del riesgo al contratista. Por otro lado, parte de este riesgo se puede atenuar mediante un incentivo de "anticipación" que proporciona un bono al contratista si el proyecto tennina antes de cierta fecha. En la figura 7.4 se presentan varios tipos de contratos y sus riesgos asociados (no es una lista exhaustiva de los tipos de contratos).
La compañia construc10ra Van Al! en espera firmar un contrato en los próximos meses para construir un nuevo estadio de futbol. donde ahora está el Louisiana Superdome. Confiando en obtener este contrato, los administradores de Van Allen han empezado a planear la primera etapa del proyecto (esto es, la demolición del Superdome). El proyecto de demolición consiste en nueve tareas, que se dan en la tabla siguiente. Se indican los tiempos normales (en semanas) ) Jos costos normales (en cientos de dólares), así como los tiempos y costos acelerados. Los costos indirectos (como la barda de seguridad alrededor del lugar) y los costos generales serán aproximadarneme Sl 200 por semana.
Tarea
Aceleración Normal Predecesores inmediatos Tiempo Costo Tiempo Costo
A
3
B
1
e
8
D
A
E F G
A
H
C,D C,D
G E,G
5 2 2 5 4
$60 $50 $70 $60 $50 $90 $60 $40 $50
5 5 10 7 6 11 6 5 4
$40 $30 $40 $40
$30 $60 $30 $20 $20
El administrador del proyecto está consciente de que los trabajadores pueden hacer una huelga durante el proyecto de demolición. Si se presenta la huelga. ninguno cruzará el piquete y el proyecto de demolición se suspenderá durante toda la huelga (sin embargo, Jos gastos generales e indirectos continuarán acumulándose). Para obtener más información acerca de este riesgo de huelga potencial, el administrador del proyecto contrata a un asesor especializado en relaciones laborales. E1 asesor informa que la probabilidad de huelga es 60 a 80%. Si hay huelga. el asesor eslima que su duración será como sigue: Duración de la huelga Probabilidad 3 semanas 4semanas 5 semanas
0.45 0.30 0.25
El asesor también establece que si ocurre la huelga, cualquier momento del proyecto de demolición tiene la misma posibilidad para que inicie y que no habrá más de una huelga durante el proyecto. Dada esta información, ¿cómo debe la compañía Van Allen administrar este riesgo? ¿Debe Uevar a cabo alguna acción preventiva o planear acciones de contingencia? Si es así. ¿qué recomendarfa?
170
CAPITULO 7
ADMINISTRACIÓN DEL RIESGO
FIGURA 7.4
Bajo Bajo Alto Alto +--- - - - - - -- - - Grado de riesgo --'---- -- - --------+
Riesgo relativo y tipos de contratos
Contratista Contrato de precio fijo Precio firme
Los elementos se pueden renegociar
Cliente Contrato de costo con beneficio Incentivos
T&M con límites
Costo con beneficios con incentivos
Tiempo y materiales
CASO DE ESTUDIO DE ADMINISTRACIÓN DEL RIESGO Para ilustrar los elementos del anál isis del riesgo en la administración de proyectos (AP), se puede considerar el "pequeño caso" de Van Allen Construction Company. En el análisis que sigue el caso intenta estimular al lector para que reflexione más acerca de los aspectos de planeación y administración del riesgo; este análisis no pretende presentar un plan exhaustivo para manejar los eventos negativos potenciales. El caso está basado en un proyecto real con una fecha de entrega establecida y que inició bajo la amenaza de una huelga potencial (que de hecho se materiali zó). Los nombres y el escenario de este caso se han modificado para salvaguardar la confidencialidad de la información. El caso de Van Allen ilustra algunos puntos importantes de la administración del riesgo. Primero, según la información anterior o simplemente la experiencia, la administradora del proyecto fue capaz de identificar el riesgo (una posible huelga). Más aún, la administradora tenía suficiente información preliminar acerca de una posibilidad de huelga que hizo que contratara a un asesor, quien a su vez pudo proporcionar más información de la posibilidad y costo de una huelga. Las acciones emprendidas por la administradora del proyecto ilustran los tres factores principales asociados con la administración del riesgo de un proyecto. •
Identificación del riesgo: identificar los eventos adversos posibles.
•
Probabilidad d e riesgo: estimar la probabilidad de que ocurra el evento.
•
Evaluación del riesgo: estimar todos los costos asociados al evento adverso.
Una vez que la administradora del proyecto reconoce que puede ocurrir una huelga, debe determinar un plan de mitigación del riesgo. Antes de formular este plan, la admi nistradora del proyecto deseará determinar la motivación de la posible huelga. ¿Ha expirado (o está a punto de expirar) el contrato colectivo de trabajo? ¿Es la huelga potencial resultado de un exceso de trabajo? ¿De sueldos muy bajos? ¿Ha habido otras quejas de los trabajadores? ¿Ha satisfecho la empresa puntos que están afectando negativamente el ánimo de los trabajadores? ¿Se pueden identificar otros factores que quizá contribuyan a la posibilidad de huelga? Cuando la administradora del proyecto ha identificado las causas posibles, deberá realizar un análisis de impacto que muestre Jos efectos de la huelga sobre el proyecto y la organi zación a corto y largo plazos (¿afectará una huelga en el proyecto de demolición del Superdome a otros proyectos de Van Allen en Louisiana? ¿Cuánto costará un retraso?). E l plan de mitigación del riesgo deberá incluir infonnación de las acciones preventivas, así como del plan de contingencia. (El punto de activación en esta situación es directo; los planes de contingencia se pondrán en marcha si ocurre la huelga.) Como parte de las acciones preventivas, el administrador del proyecto puede considerar estas estrategias: •
Negociar directamente con los trabajadores involucrados para reducir la posibilidad de huelga.
•
Tratar de modificar el contrato del proyecto de manera que el cliente asuma toda pérdida resultante de la huelga.
CASO DE EST UDIO DE ADMINISTRACIÓN DEL RIESGO
171
•
Tratar de obtener un seguro que cubra la pérdida financiera que resulte de la huelga.
•
Comprimir el proyecto para terminar antes del tiempo que minimiza el costo total del proyecto.
Las últimas dos acciones preventivas son similares: en ambos casos el administrador del proyecto incurrirá en costos adicionales para asegurar la posibilidad de que el proyecto termine a tiempo. Al comprimir el proyecto antes del punto que minimiza el costo, el administrador estará creando un amortiguador de tiempo que puede usar para contrarrestar una huelga, si ocurre. En el caso de una huelga. este evento adverso puede estar motivado por asun tos que competen a toda la empresa y que están fuera del alcance de responsabilidad del administrador del proyecto. Si así es, será poco lo que el administrador del proyecto pueda hacer directamente para reducir la posibilidad de una huelga. Si ocurre la huelga, los planes de conti ngencia posibles incluyen: •
Contratar personal no sindicalizado.
•
Asignar administradores de Van Allen para trabajar en el proyecto.
•
No hacer nada (es decir, suspender el trabajo hasta que terrrnne la huelga).
Uso de un modelo de costos para evaluar y administrar riesgos El modelo de costos descrito en el capítulo 5 puede ser útil para comprender mejor el riesgo en el caso Van Allen, así como las medidas preventivas y los planes de contingencia. Siguiendo el modelo estudiado en el capítulo 5, se consideran los trueques entre los costos directos y los costos generales e indirectos para minimüar el costo total del proyecto. Ignorando la posibilidad de huelga, el administrador del proyecto planea terrrnnar en 17 semanas para minimizar el costo total (si todas las tareas se ejecutaran en su tiempo normal, el proyecto tomaría 26 semanas). El modelo en hoja de cálculo y la solución de costo mínimo se dan en la figura 7.5; observe que las tareas B, e, D, F y H se comprimieron a menos que su duració n normal en la solución de costo mínimo. Como se vio en el capítulo 5, la solución dada en la fig ura 7.5 representa los trueques entre el incremento en costos d irectos que resultan de acelerar las tareas B, e, D, F y H y la reducción de los costos indirectos y generales por reducir la duración esperada del proyecto de 26 semanas (sin
Tarea
Duración de la tarea (tj)
INICIO
o
A
1
5 1 6 2 6 10 6 4 4
FIN
o
B
e D E
F G H
Acelerado Nonnal Predecesores Tiempos Tiempos de inmediatos de inicio terminación Tiempo Costo Tiempo Costo
o INICIO INICIO B A A
C, D C, D G E,G F,l, H
0.0 0.0 1.0 5.0 6.0 7.0 7.0 13.0 13.0 17.0
5.0 1.0 7.0 7.0 12.0 17.0 13.0 17.0 17.0 17.0
3 1
5 2 2 5 4
Totales
FIGURA 7.5
$60.00 $50.00 $70.00 $60.00 $50.00 $90.00 $60.00 $40.00 $50.00
5 5 10 7 6 11 6 5 4
$530.00
Costo indirecto/ semana
Aumento Pendiente en costo (bj) marginal
=$12.00
Costo directo total Costos indirectos
=$384.00 =$204.00
Solución de costo mínimo para Van Alle n (sin co nsiderar la hue lga )
$40.00 $30.00 $40.00 $40.00 $30.00 $60.00 $30.00 $20.00 $20.00
$10.00 $ 5.00 $ 6.00 $ 4.00 $ 5.00 $ 5.00 $15.00 $ 5.00 $ 0.00
$ 0.00 $20.00 $24.00 $20.00 $ 0.00 $ 5.00 $ 0.00 $ 5.00 $ 0.00
$310.00
$65.00
$74.00
172
CAPITULO 7
ADMINISTRACIÓN DEL RIESGO
aceleración) a 17 semanas. Con 17 semanas. el costo total de mano de obra es $384 y los costos indirecto /generales son 17 semanas x $12/semana =$240, dando un costo total mínimo de $588. Si el admin istrador trata de comprimir el proyecto a menos de 17 semanas, tendrá que acelerar las tareas A y C (además B, D. F y H) con un costo marginal adicional de $16 (llevando los costos de mano de obra a $400). Como la empresa ahorrará sólo $12 en costos directos y generales, no vale la pena comprimir el proyecto a menos de 17 semanas. Ahora se puede modificar el modelo en hoja de cálculo para considerar la posibilidad de una huelga u otro evento negativo (figura 7.6). Con base en la información dada por el asesor, la duración esperada de la huelga es 3.80 semanas, como se indica en la tabla Como la admin istradora Larnbién sabe que hay 70% de posibilidades de que haya huelga, puede multiplicar 0.70 por 3.80 semanas y sumar este valor esperado a la duración del proyecto. Dado que ella supone que durante la huelga se interrumpirá todo trabajo del proyecto (pero los costos indirectos/generales continuarán acumulándose), usa la duración modificada del proyecto para ajustar la celda de costo indirecto/general y resolver el modelo de Solver. La nueva solución se da en la figura 7.6. Al examinar la solución óptima de la figura 7.6 se observa que la administradora aún puede planear terminar el proyecto en 17 semanas. De hecho, si se corre de nuevo el modelo con diferentes probabilidades, se ve que la solución no cambia aun cuando la posibilidad de huelga sea 1.0. ¿A qué se debe? Como se indica en la figura 7.5, los administradores comprimen un proyecto hasta que el aumento margi nal en costos directos iguala o excede los ahorros marginales en costos indirectos/generales. Al sumar la duración esperada de la huelga a la duración del proyecto sólo se agrega una constante al costo total del proyecto (igual a 3.80 semanas por $12/semana = $31.92, de manera que el costo total del proyecto aumenta ahora a $6 19.92, como se ve en la figura 7 .6). La duración esperada del proyecto es ahora 19.66 semanas; sin embargo, si la administradora del proyecto trata de reducir la duración esperada del proyecto, le costará más ($16) que el ahorro obtenido ($12 en cosos generales). La conclusión de este análisis es clara. Según el modelo en hoja de cálculo de la figura 7.6 no vale la pena que la administradora del proyecto lo comprima a menos de 17 semanas aun cuando la probabilidad de una huelga sea uno. Siempre que la probabilidad de un evento negativo sea constante, un plan preventivo no debe incluir la compresión adicional del proyecto.
Tarea
Duración de la tarea (ti)
INICIO A
B
e o E F G H
FIN Totales
Acelerado Nonnal Predecesores Tiempos Tiempos de inmediatos de inicio tenninación Tiempo Costo Tiempo Costo
o
o 5 1 6 2 6 10 6 4 4
o
INICIO IN ICIO
B A A C,D C, D G E, G F,l, H
0.0 0.0 1.0 5.0 6.0 7.0 7.0 13.0 13.0 17.0
5.0 1.0 7.0 7.0 12.0 17.0 13.0 17.0 17.0 17.0
3 5 2 2 5 4
$ $ $ $ $ $ $ $ $
60.00 50.00 70.00 60.00 50.00 90.00 60.00 40.00 50.00
5 5 10 7 6 11 6 5 4
$530.00
Costo indirecto/semana = $12.00 Prob. de huelga= 0.70 FIGURA 7.6
Aume nto Pendiente en costo (bj) marginal
Costo directo total = $384.00 Costos indirectos = $204.00 = $588.00 Costo total
Solución de costo mínimo para Van Allen (considerando la huelga)
$ 40.00
30.00 40.00 40.00 30.00 60.00 30.00 20.00 20.00
$ 10.00 $ 5.00 $ 6.00 $ 4.00 $ 5.00 $ 5.00 $ 15.00 $ 5.00 $ 10.00
$ 0.00 $20.00 $24.00 $20.00 $ 0.00 $ 5.00 $ 0.00 $ 5.00 $ 0.00
$310.00
$65.00
$ 74.00
$ $ $ $ $ $ $ $
PROBLEMAS PARA ESTUDIO
173
Sin embargo, este resultado puede cambiar si la naturaleza del problema cambia. Por ejemplo, la administradora puede planear acelerar el proyecto a menos de 17 semanas si hay una fecha de entrega y si Van Allen incurre en una penalización si el proyecto termina después de esta fecha . De manera alternativa, la probabilidad de huelga puede no ser constante, sino variar durante la vida del proyecto (una situación típica en muchos eventos de riesgo). Por otro lado, la posibilidad de huelga puede aumentar conforme la duración del proyecto aumenta. El modelo en hoja de cálculo de la figura 7.6 proporciona una herram ienta importante para analizar y comprender mejor las consecuencias de estos requerimientos. Algunas de estas extensiones se estudian con más detalle en los problemas para estudio.
RIESGOS EN PROYECTOS DE DESARROLLO DE NUEVOS PRODUCTOS Riek (200 1) identificó tres tipos de riesgo que observó al estudiar quince desarrollos de nuevos productos (DNP) y los clasificó en la siguiente taxonomía: •
Riesgo técnico
•
Riesgo comercial
•
Riesgo relacionado con el personal del desarrollo de nuevos productos
El riesgo técnico es el riesgo asociado con el desarrollo y aplicación de nuevas tecnologías. Respecto al riesgo técnico, Riek advierte la necesidad de entender claramente todos los pasos en un proyecto de desarrollo tecnológico y no "tomar atajos" durante el proceso. También subraya la necesidad de una capacitación en AP y planeación de la administración del riesgo. Respecto al riesgo comercial, Riek documenta varios casos donde la tecnología estaba adelantada (o atrasada) a su tiempo, en los que se pasaron por alto efectos secundarios o terciarios, o no se apreciaron cabalmente las tecnologías competitivas. Otros problemas que documenta tienen una relació n directa con asuntos de personal e incluyen la pérdida de personal clave y las malas políticas de asignación y programación. Ahmadi y Wang ( 1999) describen los problemas relacionados con el desarrollo de un propelente en la división de Rocketdyne de Rockwelllntemational. Ellos describen cómo los administradores de Rockwell lntemational controlan los riesgos de desarrollo (incluyendo tiempo y costo) mediante una cuidadosa administración del proceso de diseño. La supervisión y el control del proceso de diseño son una parte clave de este proceso; los autores indican que el control en exceso o escaso puede llevar a fal las. Ahmadi y Wang desarrollaron una metodología basada en el trabajo de Ha y Porteus ( 1995), que intenta determinar la politica de revisión óptima en proyectos de desarrollo de nuevos productos. Como la naturaleza y posibilidad de los diversos eventos de riesgo cambian durante la vida de un proyecto, los administradores deben supervisarlo muy de cerca, en especial d urante la etapa de diseño. Es esencial que los administradores de proyectos identifiquen los eventos de riesgo, si es posible, porque afectarán el costo final, la programació n y el diseño del proyecto.
PROBLEMAS PARA ESTUDIO 1. El asesor de Van Allen ha descubierto que el contrato colectivo está vigente hasta el inicio de la semana 14; es decir, si la huelga ocurriría sólo al inicio de la semana 14. ¿Modifica esto su decisión? Si es así, ¿cómo?
2. La administradora del proyecto de Van Allen c ree ahora que la posibilidad de una huelga aumenta confom1e la duración del proyecto aumenta. Ella estima que la posibilidad de una huelga durante el curso del proyecto es como sigue: Probabilidad de huelga= FIN/(FIN + 4)
174
CAPITULO 7
ADMINISTRACIÓN DEL RIESGO
donde FIN es la duración del proyecto. ¿Modificará esta suposición sus planes preventivos? Si es así, ¿cómo? 3. Suponga que Van Allen tiene 20 semanas para terminar el proyecto de demolición del Superdome. Por cada semana de retraso, el estado multará a la compañía Van Allen con $3.5 (cientos). ¿Cómo afecta esto sus recomendaciones (suponga que la probabilidad de huelga es 0.70)? 4. Para que el proyecto de demolición termine tan pronto como sea posible, el estado de Louisiana está considerando agregar una cláusula de incentivo al proyecto de Van Allen. En particular, la cláusula de incentivos premiará a la empresa con un bono de $5.0 (cientos) por cada semana que se adelante la terminación a la semana 18. ¿Qué recomendaría ahora a Van Allen? ¿Por qué? (Suponga que la probabilidad de huelga permanece constante en 0.70.)
REFERENCIAS Ahmadi, R. y R. H. Wang. ''Managing Development Risk in Product Design Processes·•, OperacioiiS Research 47, núm. 2 (mano-abril, 1999): 235-246. Ha, A. y E. Pone us. "Optimallinúng of Reviews in Concurren! Design for Manufacturability". Managenzent Science 41, núm. 9 (septiembre, 1995): 1431-1447. Huchzermeier, A. y C. H. Loch... Project Management Under Risk: Using the Real Options Approach to Evaluate Flexibility in R&D", Managemem Science 47. núm. 1 (enero, 2001 ): 85-101. Riek. R. F. '·From Experience: Capturing Hard-Won NPD Lessons in Checklists'', Joumal of Produce lnnovarion Managemelll 18 (2001): 301 - 313.
CAPÍTULO
ADMINISTRACIÓN DE RECURSOS
E
n los capítulos anteriores e ha supuesto que los recursos (es decir, trabajadores, máquinas, dinero) están disponibles en cantidades ilimitadas. Dado que esta suposición en general no es cierta, los administradores de proyectos deben saber cómo administrar recursos limitados; de hecho, administrar recursos limitados puede ser el mayor reto para un admi nistrador de proyectos. En este capítulo se estudian los problemas relacionados con recursos limitados. Como motivación del tema comenzamos por presentar el "pequeño caso", el dilema de la cita. El caso del dilema de la cita está diseñado para ilustrar algunos puntos importantes relacionados con la definición de las tareas y con el hecho de que un proyecto puede tener "restricciones de recursos". En el caso del dilema de la cita, el recurso limitado es Jim y es claro que él es el único disponible. Observe que hay otros recursos en este caso, pero no están restringidos; por ejemplo, se supone que Ji m dispone de tantos hornos como necesite. Los recursos agregan restricciones de precedencia a un proyecto; como Jim sólo puede realizar una tarea a la vez, las tareas asignadas a Jim deben realizarse en secuencia. Este caso ilustra el imponante punto de que el concepto de la ruta crítica, como se estudió en el capítulo 4, debe modificarse de manera significativa cuando se tienen en cuenta los recursos. Existen dos problemas generales asociados con la admi nistración de recursos: 1) el problema de nivelación de recursos y 2) el problema de asignación de recursos. El problema de njvelación de recursos se refiere a la programación de actividades no críticas de manera que se minimicen los picos de requerimientos de recursos y se suavice o balancee la utilización de recursos durante la vida del proyecto. Por otro lado, el problema de asignación de recursos se refiere al caso en que existen recursos suficientes para terminar un proyecto dentro del tiempo crítico. Suponiendo que no se dispone de recursos adicionales, el administrador del proyecto desea encontrar el tiempo (o costo) mínimo necesario para terminar el proyecto dentro de sus restricciones de recursos.
EL PROBLEMA DE NIVELACIÓN DE RECURSOS Para ilustrar el problema de nivelación de recursos, considere el problema representado por la red de precedencias AON en la figura 8. 1. Como se indica, la rula crítica es INICIO-A-0-G-FIN con un tiempo de ejecución del proyecto (definido por la ruta crítica) igual a 13 semanas. Este ejemplo considera sólo un recurso, denotado de manera genérica por "trabajadores"; sin embargo, este análisis puede extenderse con facilidad a múltiples recursos repitiendo el enfoque para cada recurso. En el problema de nivelación de recursos, el administrador desea programar las tareas no críticas para minimizar el número máximo de trabajadores que la compañía debe contratar durante el proyecto (es obvio que las tareas críticas no se pueden atrasar si n retrasar el proyecto). Para entender mejor cómo programar las tareas no críticas, se puede examinar primero qué ocurre si la administradora programa todas las tareas no críticas para que inicien en su tiempo de inicio más cercano. La figura 8.2 presenta una hoja de cálculo que indica el número de trabajadores necesarios cada semana para el programa de inicios cercanos, con el hjstograma que se obtiene. Observe que las tareas A, O y G son críticas.
175
176
CAPÍTULO 8 ADMINISTRACIÓN DE RECURSOS
Ji m Gantt no está poniendo atención a su clase de contaduría; está pensando en su cila de esta noche. Va a preparar una cena para alguien especial en su departamento y está preocupado con la idea de que tal vez no tenga suficiente tiempo para dejar todo listo esa noche. Su clase de contaduría dura hasta las 5:30 PM y su invitada llegará a las 7:00PM en punto; su invitada es muy puntual y le disgusta que los demás lleguen tarde. Ji m sabe que necesitará 8 minutos para caminar hasta su casa y alrededor de 1 hora 20 minutos para lavar su ropa y vestirse. Fuera de eso, espera poder hacer todas las otras tareas ames de las siete. Ji m hace una lista de lo que tendrá que hacer hasta las siete y del tiempo que piensa le tomará cada una. La lista de Jim es la siguiente: 8 minutos Caminar hasta la casa Lavar la ropa 1 hora 20 minut.os 35 minutos Limpiar el piso del comedor Pedir a su amigo el álbum de los Beatles 5 minutos Hacer la cama 2 minutos lr por el vino 10 minutos Ir por helado 3 minutos Descongelar el pastel de queso 42 minutos 55 minutos Hornear las papas Preparar y cocinar el salmón 24 minutos Preparar y calentar Jos panes 15 minutos Hacer la ensalada 10 minutos Poner la mesa 5 minutos TOTAL 4 horas 54 minutos Jim se da cuenta de que no necesitará casi cinco horas para preparar todo, ya que algunas actividades tienen tiempos de espera que pueden hacerse productivos. Sin embargo, duda que casi cinco horas puedan condensarse a 90 minutos. Lavar la ropa le lleva 5 minutos para juntarla y llevarla al cuarto de lavado de su edificio, 25 minutos lavarla. 3 minutos pasarla a la secadora, 40 secarla y 7 recogerla, doblarla y vestirse. Ji m cree que necesitará 5 minutos para pasar por el departamento de su amigo para que le preste el álbum de los Beatles si lo hace al regresar del cuarto de lavado (si no, le tomará más tiempo). También cree que será mejor ir por el vino y el helado en un solo viaje al centro comercial, para ahorrar tiempo y gasolina. Para el piso del comedor necesitará JO minutos de limpieza y 25 para que se seque. Descongelar el pastel le llevará 40 minutos. 1 minuto más para sacarlo del congelador y otro para ponerlo en el refrigerador. Dentro de los 55 minutos para cocer las papas, Jim deja 4 para lavarlas y umarlas con mantequilla. Como compró el salmón entero. piensa que necesitará 9 minutos para lavarlo, cortarlo en filetes y sazonarlo con especias, y otros 15 minutos para cocerlo. Necesitará 5 minutos para untar mantequilla al pan, sazonarlo y envolverlo en papel aluminio, y JO minutos para calentarlo. Como quiere servir la cena a las 7 en punto, Ji m quiere que toda la comida caliente esté lista justo ames de que su invitada llegue (Jim deja dos minutos más para retirar toda la comida caliente de la estufa y colocarla en platoncs). Fuera de esto, toda la comida debe prepararse tan tarde como sea posible. A Ji m no le preocupa salir de su departamento mientras la comida se cocina. Ji m sabe que tiene suficiente espacio de horno y hornillas en la cocina, de manera que los tiempos de cocimiento se pueden traslapar, pero no puede poner la mesa mientras el piso del comedor esté húmedo. Son las 4:20 y Ji m está pensando dejar la clase en la pausa que habrá en diez minutos. Aunque considera su cita de esta noche mucho más importante que su clase de contaduría. se acuerda de lo mal que salió en el examen anterior. De ser posible, Jim quisiera quedarse toda la clase y terminar todo lo que tiene que hacer antes de su cita de las siete. (cont inúa) *Este caso fue escrito por Jack F.isenhauer.
EL PROBLEMA DE NIVELACIÓN DE RECURSOS
177
Preguntas l. ¿Debe Ji m dejar la clase en la pausa? Si no, ¿tendrá suficiente tiempo para todas las tareas que debe hacer antes de las siete?
2. Dibuje un diagrama de la red que describa el orden en que Ji m podrá realizar todas sus tareas en el menor tiempo tOGII. ¿Cuáles son las actividades críticas? 3. Prepare un diagrama de Gantt que ilustre el tiempo de holgura de cada actividad. 4. ¿Puede pensar en una formulación de programación matemática que ayude a resol ver el problema de Jim?
0 5 trabajadores
FIGURA 8 . 1
Ejemplo de nivelación de recursos
Como se indica, tanto en la hoja de cálculo como en el histograma, el mayor número de trabajadores necesarios en una semana es 21 (semana 4). En las semanas 3 y 5, el número de trabajadores necesarios se reduce a 16. El histograma de frecuencias generado por Microsoft Project para el problema de programación con los tiempos más cercanos se da en la figura 8.3. Observe la línea punteada que indica el día/hora actual y la línea horizontal que indica la restricción en el número de trabajadores disponibles. ¿Qué pasa si el admi nistrador del proyecto programa todas las tareas no críticas en su tiempo de inicio más lejano? El resultado de esta programación se muestra en la figura 8.4; como se ve, el número máximo de trabajadores necesarios en una semana se reduce ahora a 16. En otras palabras, el programa que usa los tiempos de inicio más lejanos representa una mejor utilización de Jos trabajadores desde la perspectiva de reducir los requerim ientos máximos (picos).
178
CAPÍTULOS ADMINISTRACIÓN DE RECURSOS
Semana
2
3
4
5
6
7
e
2
10
2 10
2
Tarea D
10
Tarea A
7
7
Tarea B
3
3
Tarea
Tarea E
4 5
Tarea F
8
9
10
11
12
2
2
2
2
2
2
10
10
6
6
6
6
6
8
8
8
8
6
7
4
4 5
Tarea G Total de 10 trabajadores requeridos cada semana
10
13
21
16
12
12
12
16
Prog ra ma de inicio cercan o
.,
"'o ·e Cll
:::1
C1'
25
20
f
"'o... Cll
.,
i ~'
15 ¡,
Cl
·¡¡¡ .o
..... ., Cl
10 -
Cll
o... Cll
5-
E
o
~
b 2
3
-
-
•
r--:;:
---
i' ! .~
íi¡¡
r-
----
';
~-
'.··
· :::1
z
----
f--
1-1-
-
-
-
1--
~~
f-
r-
f-
-
-
s i
4
5
6
7
8
9
10
n
w
11
12
Tarea G Tarea F
•
Tarea E
O
Tarea D
'?
D
1
•
Tarea Tarea B
O
Tarea A
~
~
O
~-~
e
13
Semana FIGURA 8 . 2
Programación más cercana de las tareas no críticas del ej emplo
Observe que la cantidad total de semanas-trabajador necesarias en la programación con fechas de inicio más cercanas o más lejanas es 147 semanas-trabajador (se encuentra sumando el número de trabajadores necesarios cada semana durante la vida del proyecto). El número de semanas-trabajador es el mismo, independientemente de la programación de las tareas no críticas. ¿Existe otro programa que reduzca a menos de 16 el número máximo de trabajadores necesarios en una semana? Para investigar esla posibilidad, un administrador de proyectos puede reprogramar las tareas no críticas en los tiempos que se encuentran entre sus respectivos tiempos de inicio más cercano y más lejano. Si empieza con el programa de inicios más cercanos de la figura 8.2, es claro que sólo debe reprogramar las tareas C, E y F (como la tarea D es crítica, no puede retrasarse sin retrasar la termi nación del proyecto). La tarea F tiene la holgura total más grande ( 12- 3 = 9 semanas), ya que puede iniciar hasta la semana 12. Sin embargo, el requerimiento de 16 trabajadores es el resultado de programar las tareas C, D y E en paralelo; un análisis cuidadoso de este problema indica que estas tareas deben traslaparse por lo menos una semana. Entonces, parece que el administrador de proyectos no puede reducir a menos de 16 el requerimiento máximo de trabajadores sin retrasar la terminación del proyecto después de la semana 13. Los histogramas de frecuencia presentados en las figuras 8.2, 8.3 y 8.4 se conocen también como perfiles de recursos o perfiles del horizonte. Cuando se comparan con la uti li zación real de
EL PROBLEMA DE NIVELACIÓN DE RECURSOS
Die 17. ' 00
Die 24, ·oo
1
Dic31, '00
179
Ene 7, '01
S
S
. ... . .: ....' .
- -------- -- --------------r---- ------ -------------- ---------- ---------------}---------- ---------- ---1 1
. ..
1
' '
. ''
'
1
:
:
:
.:
-=- _______ l ________________ ~----------- --- - -- ----- - -j- ----------- ~ - ~ 1
1
.
--- - -- ~- - ,~-
'
'
'' '
it>
''
- - ------ 1
------:--
' :
''
'
1
,...,_ "7
ro::'
•••
_ ~ __l __ ~_ ft
l'
~{:
- :r-
~"'=! --~ - - - ........ -1"" --
¡:
h H ~3 - ~'
10
-
10 10
~--..! - - -
10 10
10
10
16
16
16
16
16
21
21
21
Trabajadores
Sobreasignados Asignados -
::;G URA 8 .3
Histograma de frecuencias de M icrosoft Project (p rograma de inici os más ce rcanos)
recursos, pueden ser útiles como dispositivos de comunicación y control, y también como herramientas de planeación. Casi todos los paquetes de software para administración de proyectos (AP) disponen de estos histogramas. El problema de la nivelación de recursos es importante por muchas razones. Un requerimiento de trabajadores "nivelado" puede minimizar los costos de contratación y de despido, que pueden ser sustanciales. Un presupuesto "nivelado" puede maximizar la ganancia de intereses sobre el dinero no gastado. El problema de ni velar recursos es especialmente importante en entornos de manufactura repetitiva. Por ejemplo, considere un caso en el que el proyecto de la figura 8.1 representa el ensamble de un producto que debe fabricarse en una línea de ensamble especializada, digamos, en ciclos de 13 semanas. En este caso, los trabajadores representan el número de personas necesario en esa línea. Si el administrador del proyecto usa el programa de inicios cercanos, tendrá que contratar un equipo de 21 personas; por otro lado, si usa el programa de inicios lejanos deberá contratar sólo 16 personas. Comprender la naturaleza del problema de nivelar recursos puede permitir al administrador de proyectos visualizar un esquema que con menos de 16 personas (por ejemplo, contratando trabajadores de tiempo parcial o traslapando el trabajo en copias múltiples del producto). Esto se verá con más detalle en el problema para estudio 8.2 al final del capítulo. El problema de nivelar recursos suele ser complicado, por supuesto, debido a la existencia de varios recursos que se deben nivelar al mismo tiempo. Como es de esperarse, programar las tareas
180
CAPÍTULO 8 ADMINISTRACIÓN DE RECURSOS
Semana 4
5
6
7
8
9
10
11
12
13
Tarea B
3
Tarea e Tarea O
2 10
2 10
2 10
2
2
2
2
2
10
3 2 10
4
4
4
5
5
6
6
6
6
6
8
8
8
13
13
Tarea A
7
2
3
7
7
Tarea E Tarea F Tarea G Total de trabajadores necesarios cada semana
7
7
7
13
15
16
16
16
Programa más lejano en
o
.,en
·e
18 16
~ e:
14
en
12
o
10
,.,.. .,.. Ql
·¡¡¡ .D
,cu
E Ql E
· ::1
z
8 6 4
1
~c-~:EI:=I
Ql
i
-
_.i r!-- f-- r:!-- -
fr·!--k
r-- ,____ ! - - 1 2 -t r- !-- J-
t-~
o 1
2
llii
td
3
4
1
J Tarea G
!---
f--
e--
f--
'-
f--
!-!-- -
r--
e--
'--
1-
!--
¡.;,
¡.;..
5
6
7
8
9
r-- r-- -
f-
f---e'
f-
r--
~
10
11
12
O
Tarea F
•
Tarea E
O D
Tarea O
•
Tarea B
O
Tarea A
Ta rea
e
13
Semana
FIGURA 8 . 4
Programación más lejana de las tareas no críticas en el ejemplo
no críticas para ni velar un recurso "desnivela" algún otro recurso. Aunque algunos investigadores han sugerido modelos de programación matemática para resolver este problema, en general estos modelos no son prácticos para problemas de tamaño razonable y es raro que se apliquen. Así, Jos administradores de proyectos se apoyan generalmente en heurísticas (reglas cortas) para encontrar una solución aceptable.
PROBLEMA DE ASIGNACIÓN DE RECURSOS El problema de asignación de recursos se ocupa de asignar los recursos limitados a las tareas para cumplir ciertas metas (como terminar el proyecto tan pronto como sea posible, minimi zar el costo total o maximizar el valor presente neto del proyecto). Se supone que estos recursos (que pueden ser trabajadores, equipo o dinero) están limitados en cantidad, en tasa o en ambos. De hecho, Jos problemas de asignación se pueden distinguir según el tipo de recursos presentes en el problema. En general se definen dos tipos de recursos: •
Recursos renovables. Límite en la tasa de utilización de los recursos (como número máx imo de trabajadores por día).
•
Recursos no renovables. Lúnite proyecto (límite en el presupuesto
Los recursos renovables, limitados en la ~ _ ~.se llaman ·renovables" debido a que se renuevan cada perioC... fb~"!'l~;;:ft:-.. ~ para un proyecto, cada mañana se renuevan los diez ~ _ p;~:Z:: ¡"!:S~!!" si es iZCeSario (por supuesto, suponiendo que ninguno renuncia o se enfa!....! limitados en su consumo total; por ejemplo, los dólares o .;.:.,.;:s.,c;::r.:~:s~:::c"!:~sJ vables si hay una restricción en el presupuesto total, pero e:: último, los recursos restringidos tanto en la tasa como en el CO:l5.':::::3) doblemellte restringidos. Por ejemplo, si hay límite tanto en el (X'es::;:o:s&~-W!"'....-~·.,.., tos, el dinero es un recurso doblemente restringido. Muchos de los problemas de asignación de recursos (aunque resolver. Sin embargo, se ha estado trabajando mucho para encontrar mc:soc.asdeo_~_cmci...,;] problemas de tamaño razonable (un ejemplo de un modelo de optinuz.aci, cálculo, que se usó para asignar administradores a un proyecto de cofl5li'UCC1o.n. S! r ox:oúlTar en LeBlanc et al., 2000). Las funciones objetivo comprenden 1) tiempo de e_jecuci(C del ¡ro:.ecto. 2) demora (es decir, el tiempo después de la fecha de entrega) 3) tardanza (es decir. el tiempo ames y después de la fecha de entrega), 4) costo total, 5) carga de trabajo balanceada 6 :!1cr ,.-eseme neto. Demeulemeester y Herroelen (1992) desarrollaron un procedimiento relati\amente efi..."ieme para minimizar el tiempo de ejecución del proyecto, basado en ramificación y acotamiento (un análisis más amplio se encuentra en Sprecher y Drexl, 1999). Se han considerado otras variaciones. Talbot ( 1982) desarrolló un algoritmo de optimización para minimizar el costo del proyeclO. que combina el problema de los recursos renovables y el trueque tiempo-costo. En su trabajo. Talbot modela cada tarea usando un trueque tiempo-costo discreto (como se indica en la figura 5.7c) y coloca límites a la tasa de utilización de los recursos y al consumo total de los mismos. Para obtener más infonnación vea Ozdamar y U1usoy (1995), Brucker et al. ( 1999), Herrolen et al. ( 1998), Talbot y Patterson ( 1978) y Demuelemeester y Harroelen (2002). Dada la dificultad para resolver problemas de asignación de recursos renovables, no es de sorprender que las técnicas heurísticas se apliquen ampliamente. Se considerará un pequeño ejemplo para ilustrar dos métodos heuósticos que minimizan la duración de un proyecto cuando se tiene restricción en los recursos renovables. A pesar de la sencillez de estos enfoques, el análisis ilustra algunos puntos importantes acerca del problema de as ignación de recursos, incluyendo el concepto de "cadena cótica" introducido por Goldratt ( 1997). El ejemplo consiste en cinco tareas que usan un sólo recurso genérico denotado por "trabajadores"; se supone que no se dispone de más de 9 trabajadores por semana. Dado un máximo de 9 trabajadores disponibles cada semana, interesan las siguientes preguntas que pueden ser relevantes para un administrador de proyectos: •
¿ Puede terminar el proyecto en 12 semanas (la longimd de la ruta crítica) con no más de 9 trabajadores?
•
Si el proyecto no puede terminar en 12 semanas, ¿cuántos trabajadores más serán necesarios para cumplir con este plazo?
•
Si el administrador no puede contratar más de 9 trabajadores, ¿cuál es el retraso mínimo del proyecto en que incurrirá?
Para contestar estas preguntas, se empezará con un enfoque sencillo sugerido por Baker (1974), para encontrar una cota inferior para el número mínimo de trabajadores necesario para terminar el proyecto en 12 semanas o el número mínimo de semanas necesario para terminar el proyecto con 9 trabajadores. Estas cotas pueden no ser estrechas, pero es fáci l calcularlas y con frecuencia proporcionan información útil al administrador del proyecto en la etapa de planeación. Aunque este método se ilustra con un ejemplo que tiene un solo tipo de recurso, un administrador de proyectos sólo repe-
182
CAPÍTULO 8 ADMINISTRACIÓN DE RECURSOS
FIGURA 8 .5
3 trabajadores
6 trabajadores
5 trabajadores
8 trabajadores
Ejemplo de asignación de recursos renovables
tirá este análisis con cada tipo de recursos, si se están considerando varios tipos, y usará la mayor cota inferior encontrada para todos los recursos. Para definir estas cotas inferiores, se consideran primero el programa de inicio más cercano y el programa de inicio más lejano. La figura 8.6 representa el programa de inicio más cercano usando la notación de AOA; cada tarea se denota por una flecha cuya longitud indica su duración (por ejemplo, la tarea B necesita 3 semanas). Observe que el número de trabajadores disponibles se excede la primera vez en la semana 4, que necesita JI trabajadores. Como se indica en la figura 8.6, se necesitan en total 1O1 semanas-trabajador para completar este proyecto en 12 semanas (que es la suma del número de trabajadores necesarios cada semana). Esta cantidad total de semanas-trabajador es constante para cualquier programación de las tareas no críticas, como en la figura 8.7 que muestra el programa con el tiempo de inicio más lejano. Parece, según los programas de inicios más cercanos y más lejanos, que este proyecto no puede terminar en 12 semanas con sólo 9 trabajadores (ya que ambos programas necesitan más de 9 por Jo menos en una de las semanas). Sin embargo, esta información puede llevar a errores; quizá el administrador pueda reprogramar las tareas no críticas entre sus tiempos de inicio más cercanos y más lejanos, y crear un programa que no requiere más de 9 trabajadores todas las semanas. ¿Es posible elaborar un programa que termine el proyecto en 12 semanas, sin emplear más de 9 trabajadores en cualquier semana? Para ver si es posible (sin resolver realmente el problema), Baker ( 1974) sugiere una elegante prueba que todo administrador puede calcular, empleando únicamente papel y lápiz. Para ilustrar el enfoque de Baker, el número total de semanas-trabajador se denota por W (en este problema W es igual a 1O1 semanas-trabajador). Sea R el número de trabajadores disponibles (por semana), tal que R = 9 trabajadores en este ejemplo, y D el tiempo meta de terminación del proyecto (en este ejemplo D = 12 semanas). Como se tiene un máximo de (9 trabajadores) x (12 semanas) = 108 semanas-trabajador disponibles durante el proyecto, se sabe que para que un programa sea factible, W::;DR
Como W = 1O1 semanas-trabajador, parece que un programa de 12 semanas puede ser factible ya que 101 :::; 108.
PROBLEMA DE ASIGNACIÓN DE RECURSOS
Program a con inicios cercanos 1
i
~ '..---- ~
tarea1 3 trtbajad
1
INICIO
l l 1 ! !
K" ,
l, ! '
r~·
'
'
'
:
'
'
'
'
1 1
'-,' ', j---'' ', ' ' ' ' ''
! 1
5 tr bajad res
d
area bajadtres
1
area ~
i
8 tr
!
-
bojad¡'es
J__ -
1
1 1
!¡ !¡
1
1 1
! !
1 1 1 1
~
1
1
i
Semana
1
Núm . de trabJsem .
8
8
Trab. acu m ulados
8
Trab. " desperdiciados "
1
FIGURA 8.6
~
12
8
7
7
7
7
65
73
80
87
94
101
-
-
-
-
-
-
----
~
6
7
8
8
11
14
8
8
16
24
35
49
57
1
1
-
-
-
!
1
10 1 11 1
5
1
l
9
4
3
FIN
farea E 7 tr bajad res
1
1 2 1
~
Prog ram a con inicios cercanos para el ejem plo de as ignación de recu rsos
Programa con inicios lejanos
INICIO
------ -
<.:_._
1 ____/ ,.·~ Tare A
trabaj dores
~
r-....... ............
area E 5 tr baiad res
1 11 8 tr
<
~
area [ bajad res
area e bajado es
~ --'~
area E 7 tr bajad res
1 1 J
!
1 1 Semana
1
2
Núm. de trab./sem.
5
Tra b. acumulados Tra b. "despe rd iciados"
FIGURA 8. 7
J
3
4
5
6
7
8
9
10
11
12
5
5
11
11
11
11
14
7
7
7
7
5
10
15
26
37
48
59
73
80
87
94
101
-
-
-
-
-
-
-
-
2
2
2
2
Progra m a con inicios lejanos para las tareas no críticas
FIN
183
184
CAPÍTULO 8 ADMINISTRACIÓN DE RECURSOS
Sin embargo, este límite se puede mejorar examinando los programas de inicios más cercanos y más lejanos. Primero se considerará el programa de inicios cercanos presentado en la figura 8.6. Observe que para el programa con inicios más cercanos, en la semana 1 el administrador emplea sólo 8 trabajadores, aun cuando tiene 9 disponibles. Como todas las tareas del programa con inicios más cercanos se recorrieron lo más posible a la izquierda en el diagrama de Gantt, es imposible encontrar otro programa que satisfaga las restricciones de precedencia y que use más de 8 trabajadores en la primera semana. Por lo tanto, en la semana 1 se "desperdicia" un trabajador; es decir, no hay manera de aprovechar este trabajador en este proyecto sin cambiar las restricciones de precedencia. En la semana 2, se ve que se desperdicia (no se usa) otro trabajador. En tanto que el número de trabajadores empleados por semana sea menor o igual que el número de trabajadores disponibles (9 trabajadores), el administrador puede continuar pasando a semanas superiores en secuencia. En este ejemplo, el administrador necesita JI trabajadores en la semana 4, por lo tanto se detiene en este punto; aun cuando en alguna semana futura se requieran menos de 9 trabajadores, quizá el administrador pueda reprogramar las tareas no críticas para mover trabajadores a esas semanas. Así, según el programa con inicios cercanos, el proyecto tiene en total 3 (1 + 1 + 1) semanas-trabajador desperdiciadas. Para resumir los cálculos necesarios para encontrar el número de semanas-trabajador desperdiciadas en el programa con inicios cercanos, sea re(t) el número de trabajadores necesarios en el periodo t para el programa con inicios cercanos. Entonces, 1.
Sea Te = el menor valor de t tal que re(t) > R (el número de trabajadores disponibles). En este ejemplo, Te= 4.
2.
Para cada valor de t = 1, .. ., Te - 1, el número de semanas-trabajador desperdiciadas es igual a [R- rc(t)].
3.
Se suman las semanas-trabajador desperdiciadas (que en este ejemplo es igual a 3).
Los cálculos para encontrar las semanas-trabajador desperdiciadas para el programa con inicios cercanos se resumen en la hoja de cálculo de la figura 8.6. El procedimiento es similar para el programa con inicios más lejanos, excepto que el administrador del proyecto empieza con la última semana y trabaja hacia atrás hasta la primera semana. Por ejemplo, en el programa con inicios más lejanos de la figura 8.7 sólo se emplean 7 trabajadores en la semana 12; entonces, se desperdician 9 - 7 = 2 trabajadores y, dado que las tareas en el programa con inicios lejanos se recorren a la derecha lo más posible, no se pueden emplear. Los cálculos para encontrar el número de semanas-trabajador desperdiciadas con el programa de inicios lejanos se resumen en la ecuación siguiente. En este caso, rL(t) denota el número de unidades del recurso usadas en cada periodo t del programa de inicios lejanos, y TL denota el mayor valor de t tal que rL(t) > R. En el ejemplo de la figura 8.6, TL = 8, ya que rL(8) = 14. Entonces el número de semanas-trabajador desperdiciadas con el programa de inicios más lejanos se puede calcular como sigue: 1.
Sea TL =mayor valor de t tal que rL(t) >R. En este ejemplo, TL = 8.
2.
Para cada valor de t
3.
Sume las semanas-trabajador desperdiciadas (en este ejemplo, 2 + 2 + 2 + 2 = 8).
= D, D- 1, ..., TL + 1, encuentre [R- rL(t)].
Observe que el cálculo de las semanas-trabajador desperdiciadas según el programa con inicios lejanos se resume en el tercer renglón de la hoja de cálculo de la figu ra 8.7. Previamente se indicó que el proyecto necesitaría 101 semanas-trabajador para terminar, independientemente de la programación. Pero ahora sabemos que el proyecto tiene en total 3 + 8 semanas-trabajador desperdiciadas que es imposible utilizar con cualquiera de los programas. Por lo tanto, el administrador debe reducir en 11 las semanas-trabajador disponibles para reflejar estos recursos desperdiciados. La relación básica será ahora: lc - 1
W :S DR -
D
2::: [R - rc (t)]- 2:::
u=l
[ R - rL (t)]
SOLUCIONES FACTIBLES PARA EL PROBLEMA DE ASIGNACIÓN DE RECURSOS RENOVABLES
185
Como (D R - 3- 8) = ( 108- 11) = 97, lo que es claramente menor que W (= 10 1). se sabe ahora que no se puede crear un programa factible, que tennine en 12 semanas o menos, usando sólo 9 trabajadores (es decir, el administrador tendría que retrasar el proyecto o aumentar el número de trabajadores disponibles). Suponga que el administrador no desea contratar más de 9 trabajadores. ¿Qué se puede decir de la duración mínima factible del proyecto con 9 trabajadores? Con los cálc ulos anteriores, es fácil obtener un límite inferior para la duración del proyecto. En este caso se conoce el número de trabajadores disponibles (R = 9), pero no se conoce la duración del proyecto, D. Entonces, la relació n básica se convierte en 101
semanas-trabajador ~
9 D - 11 semanas-trabajador "desperdiciadas" 9 0 2:: 112 D 2:: 11 219 = 12.44 semanas
Si el admini trador requiere un número e ntero de semanas. entonces el proyecto no puede terminar en menos de 13 semanas, a menos que contrate más de 9 trabajadores. El método de Baker, además de proporcionar a los administradores de proyecto información valiosa respecto a la duración mínima del proyecto, les da un mejor punto de partida en la búsqueda de un programa factible. De manera similar, se puede buscar un límite inferior para el número de trabajadores necesarios para terminar el proyecto en 12 semanas (supon iendo que éste sea ahora el requerimiento). En este caso. D = 12 semanas y el número de recursos R es desconocido; la relación básica será
101 + 11
~
12 R
lo que implica que se necesitarán por lo merws 1O trabajadores para terminar el proyecto en doce semanas (9.33 redondeado hacia arriba).
SOLUCIONES FACTIBLES PARA EL PROBLEMA DE ASIGNACIÓN DE RECURSOS RENOVABLES En muchas situaciones de planeación de proyectos existe una restricción, ya sea sobre los recursos d isponibles o e n la fecha de entrega del proyecto; pero como se vio en la sección anterior. el administrador del proyecto en general no puede satisfacer ambas restricciones. Con el fin de explorar algunos métodos para resolver el proble ma de asignación de rec ursos, se supondrá que existe una restricción sobre el número de recur os di sponibles y se intentará buscar un programa que minimice la demora del proyecto. Inversamente, se puede mantener la fecha de entrega fija y tratar de e ncontrar el menor número de recursos adicionales que se necesitarían para c umplir con esa fecha de entrega. Los procedimientos para resolver el primer problema se pueden modificar con facilidad para resolver el segundo problema. Dada la complejidad del problema de asignación de recursos, los administradores, por lo general, se apoyan en algoritmos heurísticos para encontrar un programa factible. Algunos algori tmos son bastante sencillos y otros son más complejos. Por definición, ninguno garanti za una solució n óptima (es decir, minimiza la demora del proyecto); sin embargo, dada la excesiva complejidad que e nfrentan los administradores de proyectos reales, será muy útil un proceso que pueda generar fácil y rápidamente múltiples soluciones alternativas para que tome e n c uenta el admjnistrador. Existen numerosas maneras de clasificar los algoritmos heurísticos. Lo algoritmos más eficie ntes se conocen como algoritmos de "una sola pasada"; estos algoritmos programan una tarea a la vez hasta programar todas las tareas. Como los tiempos de inicio de cada tarea quedan fijos, una vez que se programa la tarea, estos algoritmos tie nen una complejidad de o rden N (donde N es el número de tareas en el proyecto). Igual que en casi todos los algoritmos, se necesitará un método para jerarqu izar u ordenar las tareas. Aunque se puede definir un número ilimitado de mediciones, las medidas típicas se basan en
186
CAPÍTULO 8 ADMINISTRACIÓN DE RECURSOS
la duración. la holgura y/o los requerimientos de recursos. Se definirán varias métricas de uso común, aunque representan sólo un pequeño subconjunto de las mediciones posibles. Para definir estas medidas se denotará por Rf el número de unidades de un recurso tipo k que se requiere para la tarea}. •
PEPS: primero en entrar, primero en servir = elegir primera tarea disponible (si hay empate elegir al azar)
•
TRU: total del recurso utilizado =
¿ Rj k
•
GRD: (mayor) utilización de un recurso x duración de la tarea=
•
GTS: (mayor) número total de sucesores
•
SPT: tiempo de procesamiento más cono= mín (tj)
•
MINSLK: holgura total mínima
t1
mf'(RJ)
•
ACTIM/ ruta más larga de la tareaj al fin del proyecto
•
ACTRES/ "valor de ruta" más largo de la tareaj al fin del proyecto, donde cada "valor de ruta" está definido por el producto de la duración de cada tarea por los recursos totales
•
ROT (recursos en el tiempo): "valor de ruta" más largo de la tarea j al fin del proyecto, donde cada "valor de ruta" está definido por la razón de recursos entre duración
Para ilustrar el cálculo de estas medidas se usará la tarea B del proyecto de la figura 8.5. Como en este problema sólo hay un recurso (trabajadores), TRU es igual al número de trabajadores. Para encontrar otras medidas para una tareaj cualquiera, el administrador del proyecto tiene que identificar todas las rutas de la tarea j al fin del proyecto; desde la tarea B hay dos rutas: la ruta (C, E, FIN) y la ruta (D, E, FIN). GTS 8 (mayor número de sucesores desde la tarea B hasta el evento "FIN") es entonces igual a máx(2, 2) = 2. La suma de las holguras totales en la ruta (C, E) es 7 + O= 7; la suma de las holguras totales en la ruta (D, E) es O (ya que D y E están en la ruta crítica). Así, el valor de MINSLK 8 es igual al mínimo de estas dos holguras; es decir, MINSLK 8 = mín(7, 0)
=o.
La medida ACTIMj está definida como la ruta más larga de la tareaj al final del proyecto. Como sólo hay una ruta de la tarea A al fin del proyecto, ACTIMA = 5; para la tarea B, que tiene dos rutas posibles al fin del proyecto,
ACTlM 8 = máx (1 + 4, 5 + 4) = máx (5, 9) = 9 La medida ACTRES, propuesta por Bedwonh (1973), fue un intento para mejorar ACTlM al incluir los recursos. Para calcular la medida ACTRESP se usan las "semanas-trabajador" de cada tarea en la ruta que va de la tareaj al final del proyecto; para la tarea B de este ejemplo, ACTRES 8 = máx (6 + 28, 40 + 28) = máx (34, 68) = 68 La medida ROTj es si milar a ACTRES, pero emplea la razón de recursos entre duración de cada tarea de la ruta o rutas de la tareaj al fin del proyecto. Para la tarea B, dado que hay dos rutas (C, E) y (D, E), de B al fin del proyecto, ROT8 = máx (6/ 1 + 7/4, 8/5 + 7/4) = máx (7 .75, 3.35) = 7.75 Es sencillo calcular la mayor parte de estas métricas, aunque algunas tienen serias desventajas. Por ejemplo, la medida TRU (total de recursos utilizados) usa simplemente el número de recursos requeridos por cada tarea; por ejemplo, si una tarea requiere dos técnicos y un cirujano de cerebro, tendrá la misma ponderación (con un peso igual a 3) que una tarea que requiere un técnico y dos cirujanos de cerebro (ya que los recursos no se ponderan según sus valores relativos). Es obvio que la medida TRU podría modificarse para tomar en cuenta ponderaciones relativas, pero habrá dudas en cuanto a cómo asignar los pesos en sí.
ALGORITMOS HEURÍSTICOS PARA El PROBLEMA DE ASIGNACIÓN DE RECURSOS RENOVABLES
1ff1
Dadas estas críticas, Jos investigadores han propuesto muchas otras medidas, casi todas \Wciones o combinaciones de las medidas sencillas que se presentaron (se estima que se han propue.;; más de cien métricas diferentes). Por ejemplo, Whitehouse y Brown ( 1979) propusieron una medl..u que es una combinación ponderada de las medidas ACTIM y ACfRES; denotaron esta medida por GENRESj y la definieron como GENRESj =w ACTIMj + ( l - w) ACfRESj donde O $ w $ l representa el peso relativo en la medida ACTIM o ACTRES. De manera surular. Elsayed (1982, 1984) sugirió otras dos medidas que utilizan ROT: •
ROT-ACTIM =(w) ROT + ( 1 - w) ACTIM
•
ROT-ACfRES
=(w) ROT + ( 1 -
w) ACTRES
donde w es una vez más un factor de ponderación que varía de O a l. La tabla presentada en la fig ura 8.8 resume los cálculos de varias medidas para el ejemplo presentado en la figura 8.5. El lector deberá verificar Jos cálculos. Todas estas medidas (como ACTIM, ACTRES y ROT) se pueden normalizar a una escala (0. 1) dividiendo cada medida por el mayor valor en cada caso. Por ejemplo, las medidas ROT se pueden normalizar dividiendo todas las medidas en la columna ROT entre 7.75, las medidas ACTIM se pueden normalizar dividiéndolas entre 68, etcétera. Si hay varios tipos de recursos, es posible extender las métricas sumando todo lo requerimientos de recursos de cada tarea. Sin embargo, debido a las diferencias en las escalas, sería prudente convenir todos los recursos a una escala de medición común. De manera alternativa, lo administradores pueden tratar cada recurso por separado, calcular una métrica para cada uno y usar un algoritmo de programación adecuado para cada medida. La mejor solución se conserva para su implementación posible.
ALGORITMOS HEURÍSTICOS PARA EL PROBLEMA DE ASIGNACIÓN DE RECURSOS RENOVABLES Los enfoques heurísticos de una sola pasada para el problema de asignación de recursos renovables se pueden clasificar de acuerdo con la manera en que se implantan las medidas. Son muchas las aplicaciones de estos algoritmos, entre ellas: •
Orden fijo versus orden dinámico de las tareas. En un orden fijo las tareas quedan ordenadas antes del proceso de programación; este orden no cambia durante el proceso de programación. De otra manera, se puede modificar dinámicamente el orden de la:. tareas conforme avanza el proceso de programación.
•
El proceso de programación puede ser un proceso "basado en tareas" o un proceso "basado en tiempos". En el enfoque basado en tareas (conocido también como algoritmos heurísticos en serie), las tareas se ordenan y programan en secuencia para que inicien tan pronto como los recursos y las restricciones de precedencia lo permitan. Una vez programadas todas las tareas, el proceso se detiene. Los algoritm o basados en tiempos (conocidos también como algoritmos heurísticos en paralelo) consideran cada periodo en secuencia; en cada periodo, los administradores de pro-
FIGURA 8.8 Cálculo de las med idas de clasificación para el ejemplo de la figur a 8 .5
TRU: Tarea
trabajadores
Duración Holgura Total (semanas) (TS¡l
ROT¡
ACTIM¡
GENRES¡ (w=O.S)
A
3
4
3
7.75
34
19.5
B
5
O*
6 8
68 28
5
o•
7.75 1.75 1.75
38.5
e o
3 1
E
7
4
0*
0.00
o
3
28
16.0 16.0 0.0
188
CAPÍTULO 8 ADMINISTRACIÓN DE RECURSOS
yec10 definen y ordenan el conj un10 de tareas cuyas restricciones de precedencia están satisfechas. De este conjunto factible, seleccionan para iniciar tantas tareas como los requerimientos de recur os lo permitan. Después consideran el siguiente periodo, y siguen así hasta que se programan todas las tareas. •
P roceso d e p rogramación hacia delante o hacia atrás. Los administradores de proyecto suelen programar cada wea en su tiempo de inicio más cercano y construir un programa factible a partir del inicio del proyecto; sin embargo, algunos algoritmos programan las tareas a partir del final del proyecto y proceden hacia atrás.
Aquí se supondrá que las tareas no se pueden dividir o suspender prematuramente una vez que inicia el trabajo (esto es, los trabajos se hacen "sin interrupción"). Sin embargo, los administradores de proyectos deben pensar siempre en la posibilidad de dividir las tareas, cuando sea posible, y redefinir la estructura desglosada del trabajo (EDT) descrita en el capítulo 2. Observe que muchos paquetes comerciales de software suponen que las tareas no se pueden dividir o interrumpir. Se usará el ejemplo de la figura 8.5 para ilustrar los dos enfoques. basado en tareas y basado en tiempos. En ambos casos se u a arbitrariamente la medida ACTRES para ordenar las tareas. Por supuesto, el resultado final puede ser diferente si el administrador de proyectos usa una medida diferente para ordenar las tareas. En ambos casos el objetivo del administrador es encontrar la duración del proyecto más corta que es posible lograr con no más de 9 trabajadores.
Algoritmos basados en las tareas (heurísticos en ser ie) Para comenzar, el administrador coloca las tareas en orden lexicográfico, y usa ACTRES para romper los empates. Un orden lexicográfico es una lista ordenada de tareas para las que se satisfacen las restricciones de precedencia de cada tarea sucesiva. En el ejemplo de la figura 8.5, el administrador empieza con las tareas A y B que están inmediatamente después del evento INICIO; el administrador puede colocar la tarea B primero, dado que su valor ACTRES (68) es mayor que ACTRESA (ACTRESA = 34). Después de las tareas A y B siguen las tareas C y D; pero en este caso ambas tareas tienen el mismo valor ACTRES (28). El administrador elige la tarea C al azar, lanzando una moneda. Así, el orden lexicográfico final de las cinco tareas de la figura 8.5 (usando ACTRES) es B, A, C, O, E. Después el administrador programa cada tarea en orden, programando que cada una inicie en su tiempo más cercano posible. Es claro que la tarea B puede iniciar al principio de la semana l. La tarea A puede iniciar al mismo tiempo, ya que pueden traslaparse y emplean 8 trabajadores en total. La tarea C (la siguiente en la lista) puede entonces iniciar al principio de la semana 5, cuando tanto la tarea A como la B han terminado. El programa hasta este punto se presenta en la figura 8.9. De acuerdo con las restricciones de precedencia, la tarea O podría iniciar también al pri ncipio de la semana 5, ya que en teoría las tareas C y D pueden ser simultáneas. Sin embargo, la tarea O no puede ini ciar hasta que la tarea C esté terminada porque las tareas C y D requieren en total 14 trabajadores; entonces, el administrador empezará la tarea D al principio de la semana 6. Como las tareas D y E no se pueden realizar al mismo tiempo, el admi nistrador no puede empezar la tarea E sino hasta el principio de la semana 11 , cuando la tarea D esté term inada. El admi nistrador ha encontrado un programa factible que requiere 14 semanas en total para terminarse; este programa se presenta en la figura 8.1 O. El algoritmo se puede repetir con otro orden lexicográfico (usando otra métrica para romper los empates). Como el proceso es bastante eficiente, el administrador y el equipo del proyecto pueden generar y considerar numerosos programas.
Algoritmos basados en el tiempo (heurísticos en paralelo) De manera alternativa, el administrador de proyectos puede encontrar un programa factible con un enfoque basado en los tiempos. En este caso, el administrador empieza en el tiempo t =O (pri nci-
ALGORITMOS HEURÍSTICOS PARA El PROBLEMA DE ASIGNACIÓN DE RECURSOS RENOVABLES
FIGURA 8.9 Programación parcial con el algoritmo heurístico basado en tareas
INICIO
w K 1
___...,
!
' ''
~
.'
189
.'' IZ !l
'
1 l
l
Semana
1
2
1 3
4
5
Núm. de trab./sem.
8
8
8
3
6
Trab. acumulados
8
16
24
27
33
6
7
8
33
33
33
1
1l 1
1
k
INICIO
1
-A
-----
1
........._ 8
1
_, e
-..¡
f-1
'
'
:
.
-- - ·-- --! -
¡--. ''
- ---il
--
--- ____., --- .
o
1
1--- 1---
E
1
1
1 1
Semana
1
2
Núm. de trabl sem.
8
8
Trab. acumulados
8
16
A GURA 8 . 10
l
4
5
6
7
8
8
3
6
8
8
8
24
27
33
41
49
57
3
l
9
10
11
12
13
14
8
8
7
7
7
7
65
73
80
87
94
101
15
Programa factible para el ejemplo de la f igura 8.5
pio de la semana l ) y coloca todas las tareas cuyas tareas predecesoras están programadas en una lista "ideal". En el tiempo t =O la lista ideal es {A, B}. OLra vez, el administrador usa alguna medida para ordenar las tareas de la lista y las programa para que inicien al principio de la semana 1 en ese orden. En este caso programa las tareas A y B para iniciar en la semana l. En el tiempo t =3 (principio de la semana 4), la tarea B está terminada; el administrador puede considerar otra lista ideal que en este caso contiene nada más a la tarea {D}. Así, programa la tarea D para iniciar en la semana 4. Al comenzar la semana 5 (cuando termina la tarea A), la lista ideal contiene a la tarea {C}; sin embargo, esta tarea no puede iniciar debido a li mitaciones de recursos. Cuando la tarea D termina (al final de la semana 9), el administrador programa la tarea C que dura una semana y le sigue la tarea E. Para resumir el proceso para un algoritmo basado en tiempos, un contador de tiempo (t) se incrementa desde t =O hasta que todas las tareas están programadas. Para cada valor de t, el administrador del proyecto lista aquellas tareas cuyos predecesores están programados y ordena estas tareas según alguna métrica. Después programa tantas tareas como los recursos se lo permiten, considerando cada tarea en orden. Cuando en la lista no hay más tareas que pueda programar, incrementa el contador de tiempo (t) y repite el proceso hasta que programa todas las tareas. Para el ejemplo de la figura 8.5, el programa resultante será el mismo que el dado en la figura 8.1 O, excepto que la tarea C se programa antes que la tarea D. De todas maneras el proyecto necesitará 14 semanas para terminar.
190
CAPÍTULO 8 ADMINISTRACIÓN DE RECURSOS
PROBLEMA DE ASIGNACIÓN DE RECURSOS RENOVABLES CON SOLUCIÓN SENCILLA En un interesante ejemplo, Fox ( 1990) presenta un problema para ilustrar por qué el concepto de ruta crítica no se debe usar en la planeación del proyecto. La figura 8.11 da una versión modificada de su problema. Como se indica, hay dos equi pos ~1 azul y el gris- y seis rareas. Cada equipo puede hacer sólo una tarea a la vez; se conocen las duraciones de las tareas y se dan en la figura 8. 11. La preg unta es, ¿qué secuencia deben usar los equi pos para procesar sus rareas respectivas? Este ejemplo ilustra varios puntos importantes relacionados con la asignación de recursos y la administración de proyectos. Primero, el camino crítico es claramente de 10 días; sin embargo, se sabe que este proyecto no podrá terminar en 10 días (suponiendo que no se puedan agregar más equipos), ya que el equipo azul tomará por lo menos once días para terminar sus tareas. Sin embargo, con frecuencia se usa la información obtenida de los cálculos de la ruta crítica para establecer la secuencia de tareas. Por ejemplo, suponga que el administrador del proyecto calcula las holguras totales y decide usar esta información para establecer la secuencia de las tareas del equipo azul. Ordenando las tareas en orden ascendente de holguras totales se obtiene la siguiente secuencia (para el equipo azul): A l, Bl , Cl ya que TSA 1 =O, TS8 1 = 2, and TSc 1 = 3. Suponiendo que el equipo gris sigue la misma secuencia, el programa que resulta para el proyecto se da en la figura 8. 12. Como se indica, se necesitan en total 20 días para terminar este proyecto. Observe que el equipo gris no tiene demoras entre sus tareas (una vez que empiezan a trabajar en la tarea A2), pero podría haberlas si las duraciones de las tareas fueran diferentes. Es interesante hacer notar que la solución dada en la figura 8. 12 es igual a la encontrada por Microsoft Project con la función "nivelación de recursos" (el algoritmo para resolver el problema de asig nación de recursos renovables). Dado que la función está basada en los cálculos de las holguras totales, no es de sorprender que el programa llegue a la misma solución que la figura 8. 12. ¿Existe otra secuencia que dé un tiempo de ejecución del proyecto más corto? Un cuidadoso examen del problema de la figura 8.1 1 indica que el problema ocurre porque el equipo azul de hecho bloquea al equipo gris, impidiéndole empezar a trabajar hasta que el equipo azul termina por lo menos una tarea. Entonces, parece razonable que el equipo azul empiece con su tarea más corta y de esta manera minimice el retraso del equipo gris. Siguiendo esta lógica, el administrador del
FIGURA 8 . 11 Solución de un probl ema de asign ación de recursos renovables
Equipo azul
Equipo gris
PROBLEMA DE ASIGNACIÓN DE RECURSOS RENOVABLES CON SOLUCIÓN SENCILLA
191
proyecto hará que el equipo azul comience con la tarea e 1 y trabaje sus tareas en el orden e 1, B 1, A l. Si el equipo gris sigue la misma secuencia (es decir. e2, 82, A2) la solución se indica en la figura 8. 13. Note que esta secuencia da como resultado una reducción a 16 días en el tiempo de ejecución del proyecto. Este razonamiento (establecer la secuencia de tareas del equipo azul en orden ascendente de los tiempos de ejecución), ¿produce siempre una solución que minimiza el tiempo de ejecución del proyecto? La respuesta general es no. Sin embargo, este problema tiene una estructura que permite encontrar -y verificar- una olución óptima. El punto clave es reconocer que este problema está estrechamente relacionado con un problema de programación de un taller de flujo continuo. Un taller de flujo continuo es un grupo de estaciones de trabajo (máquinas, trabajadores) que producen partes, componentes o subensambles donde todos los artículo producidos en el taller deben procesarse en el mismo orden de estaciones de trabajo. En este caso, se considerará un taller de flujo continuo justo con dos estaciones de trabajo, como se representa en la figura 8.14. Además, el taller continuo está clasificado como taller de flujo "estático", es decir. todos los trabajos que deben procesar las estaciones de trabajo están disponibles al inicio del periodo de procesamiento; la otra posibilidad es el taller de flujo "dinámico", donde las tareas llegan en diferentes tiempos. Para ilustrar un problema de taller de flujo "estático", se supondrá que hay 5 trabajos que deben procesarse en dos estaciones de trabajo; los tiempos de procesamiento en cada estación se dan en la figura 8.14. La pregunta en este caso es cómo determinar la secuencia de procesamiento de trabajos que minimiza el tiempo de ejecución necesario para procesar los 5 trabajos en ambas estaciones. Hay 5! = 5 x 4 x 3 x 2 x 1 = 120 secuencias de trabajo posibles. Pero resolver este problema con una enumeración completa, pronto se vuelve imposible (para 1O tareas hay 3 628 800 secuencias posibles). Sin embargo, si sólo hay dos estaciones de trabajo existe un método muy sencillo para encontrar la secuencia que mirumiza el tiempo total de procesamiento (para cualquier número de tareas). El procedimiento conocido como regla de Johnson (Johnson, 1954), es el siguiente: 1.
Encontrar la combinación tarea-estación de trabajo con el menor tiempo de procesamiento. Si hay un empate, se elige una combinación arbitraria tarea-estación de trabajo.
2.
Si esta combinación tarea-estación de trabajo oc urre en la estación de trabajo 1, se asigna la tarea al primer lugar disponible en la secuencia.
3.
Si esta combinación tarea-estación de trabajo ocurre en la estación de trabajo 2, la tarea se asigna al último lugar disponible en la secuencia.
4.
Tachar esta tarea y repetir el proceso.
FIGURA 8 .12 Programa del proyecto que usa las holguras totales para determinar la secuencia de las tareas
TareaA1 Equipo azul
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
TareaA2 Equipo gris
FIGURA 8 . 13 Programa del proyecto que sigue la secuencia C, B,A
1Tafea 81 !rarea c1l
Tarea 82
Tarea C2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Tarea Al Equipo azul
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Tarea C2 Equipo gris
Tarea 82
TareaA2
2 3 4 5 6 7 8 9 10 ,, 12 13 14 15 16 17 18 19 20
192
CAPITULO 8 ADMINISTRACIÓN DE RECURSOS
En el ejemplo de la figura 8.14, la combinación tarea-estación de trabajo con el menor tiempo de procesamiento será la combinación (tarea 4-estación de trabajo 1) que tiene un tiempo de procesamiento igual a 4. Así, la tarea 4 se coloca primero en esta secuencia y se elimina de la lista. La siguiente tarea con el menor tiempo de procesamiento será la combinación (tarea 3-estación 1) con un tiempo de procesamiento igual a 6. Entonces la tarea 3 se coloca en egundo lugar en la secuencia (ya que la tarea 4 es la primera) y se tacha de la lista. La siguiente tarea será la combinación (tarea !-estación 1). De las dos tareas restantes (tarea 2 y tarea 5) la que tiene el menor tiempo de procesamiento es (tarea S-estación de trabajo 2). Como este tiempo de procesamiento corresponde a la estación de trabajo 2, se programa la tarea 5 al final de la secuencia. La única tarea que queda (tarea 2) se coloca entonces en la cuarta posición. La secuencia final será tareas (4, 3, 1, 2, 5), con un tiempo de ejecución minimo de 16. Ahora se puede ver la relación entre el problema del taller de flujo y el problema de programación del proyecto propuesto por Fox. Cada equipo de trabajo (los equipos gris y azul) representa una estación de trabajo en el taller. Las tareas del proyecto representan tres trabajos -A, B y Cque deben procesarse (en orden) en cada estación de trabajo. Aplicando la regla de Johnson al problema de programación del proyecto presentado en la figura 8.1 1, se ve que el menor tiempo de procesamiento es la duración de la tarea el (2 días); así el equipo azul deberá trabajar primero en la tarea Cl. De las dos tareas restantes (A y B), el menor tiempo de procesamiento es 3 días, ésta es \a duración de \a tarea B \. Entonces e\ equipo az.u\ deberá empezar con \a tarea B cuando termine la tarea Cl. La secuencia completa es (C, B, A), que da un tiempo mínimo de ejecución del proyecto de 16 días, como se indica en \a f\gura 8. \3. La relación entre los problemas de programación del proyecto y programación del taller intermitente (y el flujo) se conoce desde hace muchos años (un buen análisis se encuentra en David el al., 1999). Desafortunadamente, la regla de Johnson sólo se cumple para dos estaciones de trabajo en un taller (y para un caso especial con tres estaciones de trabajo). Si hay más de tres estaciones. la complejidad combina10ria del problema crece con rapidez, de manera que los algoritmos heurísticos se usan con más frecuencia. De cualquier manera, se tendrá una mayor comprensión a! reconocer la relación entre los problemas de programación de un taller y de un proyecto. Con uhe más detalles de la regla de Johnson y la programación de talleres de flujo en Nahamias ( 1997 Davis et al. (1999).
ASIGNACIÓN DE RECURSOS Y LA CADENA CRÍTICA Reconociendo la importancia del problema de la asignación de recursos, Goldratt (1997) int.rod:. el concepto de la "cadena crítica" que relaciona dependencias de los recursos con el concepto de crítica. Por ejemplo, en el caso "el dilema de la cita", descrito al principio de este capítulo, las tarc-:i asignadas a Jim Ganu forman una cadena (ya que sólo puede realizar una tarea a la vez) que dela duración del proyecto. Si Ji m se retrasa en alguna de sus tareas asignadas, el proyecto se retrasz::'! y requerirá más de los 90 minutos asignados. El "dilema de la cita" ilustra la teoría de restricciones (TOC) definida originalmente Goldratt y Cox ( 1992) para la admi nistración de procesos y recientemente aplicada a la ad lilll".-.'-
FIGURA 8.14 Un taller de flujo con 2 estaciones de trabajo y 5 trabajos
Trabajo
Tiempo de procesamiento en estación de trabajo #1
Tiem po de procesamiento en estación de trabajo #2
1
10
14
2
13
20
8 8 12
3
6
4
4
5
19
ASIGNACIÓN DE RECURSOS Y LA CADENA CRÍTICA
193
tración de proyectos por Goldratt (1997), Newbold (1998) y Leach (2000). La teoría de restricciones, según la defin ió Leach, contiene cinco pasos:
1.
Ide ntificar las restricciones del proyecto.
2.
Aprovechar las restricciones del proyecto.
3.
Subordinar otras decisiones para apoyar los recursos restringidos.
4.
Mejorar los recursos restringidos.
5.
Repetir los pasos l a 4 con otros recursos cuando se convierten en restringidos
Según Goldran. la meta de la administración de proyectos es minimizar el tiempo de ejecución del proyecto. Para minimizar el tiempo de ejecución en e l caso del dilema de la cita, Ji m debe mantenerse ocupado en todo momento, ya que sus actividades definen la duración mínima, de 90 minutos, del proyecto. Por lo tanto. las tareas de Jim definen la cadena crítica en este caso. Para ilustrar un poco más el concepto de cadena crítica, considere el problema de la figura 8. 11 . Este problema se puede representar por una red de precedencias que indica la secuenc ia óptima e incluye dependencias de recursos, así como relaciones de precedencia; e l resultado se da en la figura 8. 15. Observe que la cadena crítica (IN ICIO-Cl-C2-B2-A2-FIN) que representa la secuencia óptima de tareas define el tiempo de ejecución mínimo del proyecto, que es 16 días. Este ejemplo puede ilustrar otros conceptos relacionados con la aplicación de TOC a la administración de proyectos. Una vez identificada la cadena crítica, Goldratt et al. recomiendan que se agreguen amortiguadores para "proteger" las tareas de esta cadena y reducir la posibilidad de que el proyecto se retrase. Dos factores pueden retrasar el proyecto: 1) el trabajo está retrasado y no está disponible para procesarlo en el momento correcto o 2) los recursos (los equipos azul y gris) no están disponibles en el momento en que se necesitan. Por ejemplo, si al equipo azul le toma más de 3 días terminar la tarea B 1, la tarea B2 puede retrasarse. Para reducir la posibilidad de estos dos eventos, Newbold et al. recomiendan agregar dos tipos* de amortiguadores al proyecto: •
Amortiguadores de recursos para asegurar la disponibi lidad de recursos
•
Amortiguadores d e alimentación para asegurar la di sponibilidad del trabajo
Los amortiguadores de recursos aseguran que los recursos (como equipos) estén disponibles cuando se necesitan; Newbold se refiere a estos amortiguadores como "despertadores" que avisan al equipo que pronto deberá realizar una tarea crítica. En las redes de precedencias los amortiguadores de recursos se agregan justo antes de que un equipo empiece a trabajar en una tarea crítica; en el ejemplo de la figura 8.15 debe agregarse un amortiguador de recursos antes de la tarea C 1 y antes de la tarea C2, para avisar a los respectivos equipos azul y gris que pronto se necesitarán para una tarea crítica. Los amortiguadores de alimentación se agregan siempre que una tarea no crítica precede a una tarea crítica, para asegurar que la tarea crítica pueda realizarse sin retraso. En el ejemplo de la figura 8. 15, se agrega un amortiguador de alimentación entre las tareas B 1 y B2 y otro entre las tareas A 1 y A2. Estos amortiguadores agregan tiempo (pero no retrasan el proyecto) para asegurar que las tareas B2 y A2 se inicien puntualmente al iniciar el día 8 y el día 13, respectivamente.
CAPACIDADES DEL SOFTWARE COMERCIAL PARA LA ASIGNACIÓN DE RECURSOS Se hi zo notar que Microsoft Project, usando la fu nción integrada de asignación de recursos, encontró la solución subóptima de la figura 8.12 (de 20 días), para el problema de la figura 8.11. ¿Qué tan bien funciona el software comercial para resolver e l problema de asignación de recursos renovables?
* Recuerde que e n e l capítulo 6, en la sección "teoría de restricciones y e l amoniguador del proyecto", se estudió el concepto de amortiguador del proyecto. el tercer tipo de amoniguador propuesto por Newbold.
194
CAPÍTULO 8 ADMINISTRACIÓN DE RECURSOS
FIGURA 8.15
Cadena crítica para el ejemplo de la fi gura 8.11
Para contestar esta pregunta, Kolisch ( 1999) probó siete paquetes comerciales de software de AP en una serie de problemas de asignación de recursos renovables generados aleatoriamente y comparó sus soluciones con las soluciones óptimas conocidas. El análisis de Kolisch se realizó con 160 problemas de prueba generados aleatoriamente, en los que se variaba el número de tareas ( 1O, 20 o 30), el número de tipos de recursos (2, 3 o 4), la complejidad de la red de precedencias, el número promedio de tipos de recursos usados en cada tarea y la proporción de demanda de recursos y disponibilidad. Él supone, como se supuso aquí, que las tareas son sin interrupción y que las duraciones de las tareas son determin ísticas. El criterio para evaluar cada paquete de software fue el tiempo de ejecución del proyecto. Para cada problema, Kolisch encontró la solución óptima con el algoritmo de ramificación y acotamiento desarrollado por Demeulemeester y Herroelen ( 1992) y después resolvió cada problemas usando siete paquetes comerciales. Denotando por el tiempo de ejecución óptimo del problema p , definió
'Ti;
=
*
1fp s -7ip
1fs
como la métrica para evaluar cada paquete comercial de software, donde 7ips es el tiempo de ejecución encontrado con el paquete de software s para el problema p. La figura 8. 17 presenta los siete paquetes comerciales y los resuiLados de Kolisch. El valor des se refiere al promedio de los valores 1fps (porcentaje de desviación de la solución óptima) en los 160 problemas de prueba. Kolisch informa que los siete paquetes comerciales de software encontraron la solución óptima para 45% de los proyeclOs probados. Además, informa que su funcionamiento empeora conforme aumentan el número de tareas y el número de recursos restringidos, pero que mejora cuando aumenta el número de relaciones de precedencia. Con base en varias pruebas estadísticas, paramétricas y no paramétricas, Kolisch concluye que estos paquetes comerciales se pueden clasificar en cuatro grupos según su habilidad para resolver problemas de asignación de recursos renovables; en la primera clase incluye a Primavera Project Planner, CA Super-Project y Time Line; en la segunda clase incluye a Time Line, Project Scheduler y Microsoft Projec t (Time Line está en la primera y la segunda clases). Project Manager Workbench y Artemis Schedule Publisher, que piensa que funcionan mal en general, definen la tercera y cuarta clases, respectivamente.
PROBLEMAS DE ASIGNACIÓN DE RECURSOS NO RENOVABLES
FIGURA 8 . 16
195
Red de precedencias modificada con amortiguado res de recursos y de alimentación
FIGURA 8 .17 Evaluación de paquetes comerciales de softwa re
Paquetes comerciales de software
"'s
Oesv.Est. (TI 5) 6.04
Artem is Schudule PublisherV4.1
4.39
CA Super-Project V3.0C
4.41
6.02
Microsoft Project V4.0
4.49
5.09 6.53
Primavera Project PlannerV1.0
5.35
Project ManagerWorkbench V.1.1.02w
5.43
7.98
Project Scheduler 6.0 V1.02 Time Une V6.0.0
6.69
8.60 9.82
9.76
PROBLEMAS DE ASIGNACIÓN D E RECURSOS NO RENOVABLES Recursos no renovables son los recursos que tienen un límite en su uso total, pero no en su tasa de utili zación. Por ejemplo, el proyecto de la figura 8.5 requiere, en total, 101 semanas-trabajador; sin embargo, no hubo manera de que el administrador pudiera asignar al proyecto más de 9 trabajadores por semana (sin contratar más, claro). En esta sección se considerarán recursos que no tienen límite en su tasa de utili zación, aunque sí hay un límite en la utilización total (considere dólares como ejemplo). Para motivar este estudio considere el proyecto en la figura 8. 18 con cuatro tareas. Cada tarea necesita un número específico de unidades de un recurso no renovable; estos requerimientos se resumen en la tabla de la figura 8.19. Se supone que una tarea no puede iniciar hasta que estén disponibles todas las unidades requeridas del recurso; es decir, la tarea B no puede iniciar hasta que se disponga de 12 unidades del recurso. Los recursos se envían al proyecto de acuerdo con una programación específica; estos programas suelen negociarse antes de iniciar el proyecto. En este ejemplo se supone que se entregan 4 unidades al inicio de cada periodo 1, 3, 5, 7, ..., 19, lo que representa 10 entregas y 40 unidades. Observe que el requerimiento total del recurso para el proyecto es 36 unidades. Según la ruta crítica, el proyecto (ignorando las restricciones de recursos) tomará 13 semanas para terminar (la ruta crítica es INlClO-A-B-D-FIN). Sin embargo, dado el programa de entregas y los requerimientos de recursos, ¿puede terminar el proyecto en 13 semanas? Si no, ¿cuál es el tiempo mínimo necesario para terminar el proyecto (es decir, que minimiza el tiempo de ejecución del proyecto)?
196
CAPiTULO 8 ADMINISTRACIÓN DE RECURSOS
12 unidades
10 unidades
FIGURA 8 . 18
Ejemplo de asignación de recursos no renovables
FIGURA 8.19 Resumen de la información para el ejemplo de la figura 8.18
Número de unidades necesarias de reeursos no renovables
Inicio cercano
Inicio lejano
6
o
o
12
6 6 11
6
Tarea
Duración
A 8
e
6 5 3
D
2
8
10
8
11
Como en este caso se está suponiendo que las duraciones de las tareas son determinísticas, todas las tareas se pueden iniciar en su tiempo de inicio más lejano sin retrasar el proyecto a más de 13 semanas. De esta manera, se asigna el tiempo máximo para entregar Jos recursos antes de iniciar una tarea. Si todas las tareas se programan en sus tiempos de inicio más lejanos, la línea punteada de la figura 8.20 indica los requerimientos acumulados de recursos necesarios para terminar el proyecto en 13 semanas. La otra línea de esta gráfica indica la disponibilidad acumulada de recursos (esto es, 4 unidades entregadas en Jos tiempos 1, 3, ...). Al examinar las gráficas de la figura 8.20, se ve que para que el proyecto termine en 13 semanas sin retraso de recursos, la grafica acumulada que indica la entrega de recursos (lfnea continua) nunca debe estar abajo de la línea punteada que indica Jos requerimientos de recursos. Esta observación viene de la suposición de que debe haber suficientes unidades de recursos antes de iniciar una tarea. Así, es evidente que el proyecto/tarea A no puede iniciar hasta el principio de la semana 3, ya que no habrá recursos suficientes (6 unidades) hasta ese momento. Esta observación lleva a un procedimiento de solución de este problema que es fácil implementar gráficamente. En este caso, la línea punteada que indica requerimientos de recursos, debe recorrerse a la derecha hasta que todas las partes de la línea punteada estén sobre o abajo de la línea que indica la entrega de recursos acumulados. Mover la línea punteada es equivalente a retrasar el inicio (y la terminación) del proyecto. Al hacer el menor corrimiento necesario para colocar la línea punteada sobre o abajo de la línea de entregas, se minimiza el retraso del proyecto sujeto a las restricciones de los recursos (como probaron Carlier y Rinnooy Kan, 1982). En este
PROBLEMAS DE ASIGNACIÓN DE RECURSOS NO RENOVABLES
FIGURA 8 . 20 Requ erimi entos y d isponibilidad de recursos acumulados
197
40 36
Requerimientos
"'o
32
::ur:;~=
:;
28
'O 111
E ::::1
24
u
111
.."'"'o ::::1
20
l
¡-·-·-·-····-·-·-·-·-····-·r----' !'"......... ..,..-.•~~·· · · :
!
16
u
Gl
a:
12 8 4 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Semanas
ejemplo, el retraso mínimo del proyecto es igual a 6 semanas; esta sol ución óptima se indica en la figura 8.2l. Este ejemplo ilustra varios puntos. Primero, indica que muchos problemas de asignación de recursos no renovables son relativamente fáciles de optimizar, comparándolos con los problemas de asignación de recursos renovables, cuya solución óptima es más complicada. Segundo, implica que si los recursos renovables se manejan corno no renovables, puede aplicarse la técnica de solución para recursos no renovables para encontrar una buena solución (no necesariamente óptima) o para comprender mejor el problema de asignación de recursos renovables y las soluciones posibles. (Esta es la naturalez.a del procedimiento de Baker, descrito antes, para encontrar el límite inferior de\ ti.empo de e)ecuc\ém de\ pto')'ecto ')'lo de \a u\\\1-z.ac\ón de un recuiT.o·, mane~a con e\ec\.\'1\.dad \o~ tecutsos reno'lab\es como no reno'lab\es.) "Para recutsos no reno\la\)\es, ¿;puede e"1..t endeiT.e e\ proceso de so\uc\ém, presentado en \a \\guta ~.1 \ , para mane~ar cons\deTac\()nes ad\c\ana\es \() más rea\\stas)'"l "Por e)em'Q\(), ¡,o,ué \)asa s\ se \mponen kchas de entrega para algunas \o todas \as) \.areas'"l Para \\ustrar esto, suponga que \a tarea ~ de \a \\gu-ra'?:..\ '?:. debe tenn\nat a\ 1ma\ de \a semana\<\. ¡,Se puede moo\1\.car e\ \)T()cesa de sa\ución para incorporar esta restricción 'J aún encontrar \a solución óptima con eficiencia? Si \a tarea B debe terminar a\ fma\ de \a semana \ 4, debe iniciar a más tardar a\ inicio de \a semana \0 (ya que dura 5 semanas). E\ proceso de solución empiez.a)us\o como se reso\\lió e\ problema anterior (sin fechas de terminación); es decir, se dibuja la curva de disponibilidad de recursos acumulados y la curva de requerimientos de recursos acumulados, y se mueve ésta a la derecha. Si se encuentra una fecha de entrega para alguna tarea, se programa de manera que termjne en su fecha de entrega (en este ejemplo, la tarea B inicia al principio de la semana 10) . Después se elimina esta tarea del problema; es decir, se reducen 12 unidades, tanto de la entrega como de la demanda de recursos (el primer "envío" de recursos ahora ocurre al inicio de la semana 7), y continua el proceso de solución del problema. Suponiendo que exista una solución factible, este proceso encontrará el tiempo mínimo de ejecución. Carlier y Rinnooy Kan ( 1982) demostraron que este procedimiento se puede modificar para incluir de manera eficiente otras extensiones (por ej emplo, si el administrador quiere mi ni mjzar la impuntualidad total de las tareas, donde impuntualidad se defi ne como tiempo de terminación menos tiempo de entrega). Sin embargo, si las tareas están disponjbles en diferentes fec has o producen recursos (en lugar de consumirlos), el problema se vuelve un problema de programación no lineal (PN) "duro" para el cual no se conoce un algoritmo eficiente. PN-d uro se refiere a una gran clase de problemas, para los que es improbable que funcione un algoritmo polinomial. Es interesante obser-
198
CAPITULO 8 ADMINISTRACIÓN DE RECURSOS
FIGURA 8 . 21 Solución para el eje mplo de recursos no r enovables
40 36 Cl)
o
32
'O «1
28
E ::1
24
~
"'
20
...::1
16
«1 Cl)
o
Cl)
a:"' G)
i:;
8 4
...,................ ...
:···~·
¡
12
L Recursos acumulados requeridos
r-·~·······-····--··-··~
1 2 3 4 5 6 7 8 9 10 11
~
12 13 14 15 16 17 18 19 20
Semanas
var que la mayor parte de los problemas que surgen en el contexto de la administración de recursos no renovables para los proyectos están en la primera categoría y pueden resolverse con bastante eficiencia.
PROBLEMAS DE ASIGNACIÓN DE RECURSOS CON TAREAS DE DURACIÓN ALEATORIA Hasta ahora se ha supuesto que las duraciones de las tareas se conocen y son constantes. ¿Qué pasa con la asignación de recursos cuando las duraciones de las tareas se manejan como variables aleatorias? Para motivar este análisis considere el problema siguiente. Un administrador ti ene un proyecto con cuatro tareas: A, B, C y D, como se indica en la figura 8.22, la tarea A debe preceder a la C y la tarea B debe preceder a la D. El administrador tiene dos trabajadores, Bob y Barb, que puede asignar a estas tareas: Bob y Barb tuvieron capacitación cruzada y los dos pueden realizar cualquier tarea con igual efectividad. Las duraciones de las rareas (para un solo trabajador) son variables aleatorias discretas descritas por la información de la figura 8.22. El administrador puede decidir que Bob y Barb trabajen juntos como un equipo de proyecto; en este caso, los dos juntos podrán reali zar cada tarea en la mitad del tiempo que necesita un solo trabajador. Es decir, el adm inistrador supone que si asigna a Bob y Barb como equipo a la tarea B, le tomará 9/2 = 4.5 semanas con probabilidad 0.667 o 3 semanas con probabilidad 0.333 (con un valor esperado de 4 semanas). Si asigna a Bob y Barb a todas las tareas como equipo, realizarán las tareas en secuencia; por supuesto no importa el orden si satisfacen las restricciones de precedencias. Por otro lado, el administrador puede asignar un trabajador a cada tarea; por ejemplo, puede decidir que Bob trabaje en las tareas A y C y Barb en las tareas B y D. Aunque es probable que cada tarea tome más tiempo (las duraciones esperadas son mayores), Bob y Barb podrían realizar sus taras respectivas en forma simultánea. Si bien existen otras configuraciones posibles (como el trabajador que termina sus tareas asignadas y ayuda a otros trabajadores), sólo se considerarán estas dos. Si Bob y Barb trabajan como equipo en las cuatro rareas, su tiempo esperado de ejecución es la suma de las duraciones esperadas de las tareas. Como el administrador ha supuesto que Bob y Barb pueden terminar el trabajo en la mitad del tiempo que necesita un solo trabajador, su tiempo esperado de terminación es 15 (30/2) semanas.
PRO~ DE ASIGNACIO"- 0: R:-a.JRSOS CON TAREAS DE DURACIO ALEA~
199
FIGURA 8 .22 Asignación de recursos con duraciones aleatorias para las tareas
Tarea B
Tarea A
Tarea D
Tarea C
Duraci ón
Prob.
Duración
Prob.
Duración
Prob.
Duración
Prob.
6 5 4
0.33 0.33 0.33
9 6
0.667 0.333
12 7
0.6 0.4
10 6
0.25 0.75
Duración esperada
5.0
10.0
7.0
Sin embargo, si Bob realiza las tareas A y C, y Barb las tareas B y D, el administrador puede pensar que el tiempo esperado de termjnación también es 15 semanas, ya que la duración esperada de ambas rutas (INICIO-A-C-FIN) e (INICIO-B-D-FIN) es 15 semanas. Como las duraciones de las tareas se describen por distribuciones de probabilidad di scretas, puede probar estas suposiciones enumerando todos los resultados posibles. Como la duración de la tarea A puede tomar tres valores (4, S y 6 semanas) y las duracione de las tareas B, C y D, tres valores cada una. se tienen en total 3 x 2 x 2 x 2 = 24 "realizaciones" posibles. Estas 24 realizaciones se dan en la figura 8.23. Para cada realización, el administrador puede calcular la duración de cada ruta (INICIO-A-C-FLN) e (INICIO-B-D-FIN) y la duración del proyecto, que es el valor de la ruta más larga de estas dos. Suponjendo independencia entre las tareas, la probabilidad de cada realización es el producto de las probabilidades respectivas (por ejemplo, la probabilidad de la realización 1 con A 6 semanas, B = 9, C = 12 y D = lO semanas, es 0.33 x 0.67 x 0.60 x 0.25 = 0.033). Un examen de la hoja de cálculo de la figura 8.23 indica que varias realizaciones tienen la misma duración del proyecto con valores de 12 a 19 semanas. Combinando estas realizaciones (y sumando las probabilidades cie reali7.acioncs con la misma duración del proyecto), el administrador obtiene la hoja de cálculo de la figura 8.24. Dada esta distribución de probabilidades (con 7 realizaciones), si d; denota la duració n del proyecto para cada realización i, y después se calcula la duración esperada del proyecto E[D) con la definición usual de valor esperado de una distribución de probabilidad discreta:
=
1
E[D) = Ld; Pr(D
= d¡) = 12(0.07) + 13(0.03) + ... + 19(0. 17) = 16.42
i -1
Si Bob y Barb trabajan solos (aun cuando trabajen en tareas simultáneas), la duración esperada del proyecto aumenta a más de 16 semanas. Más aún, la distribución de probabilidad acumulada de la figura 8.24 indica 50% de probabilidad de que el proyecto tome hasta 16 semanas. ¿Por qué es la duración esperada del proyecto para esta configuración (con Bob y Barb solos) significativamente
200
CAPiTULO S ADMINISTRACIÓN DE RECURSOS
FIGURA 8 .23 Realizaciones para el problema Bob y Barb
Realización #
2
3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
FIGURA 8 . 24 Distribución de probabilidad de las duraciones del proyecto cuando Bob y Barb trabajan solos
A
B
e
o
A-te
B-tD
máx (A-te, B+ D)
6 6 6 6 6 6 6 6 5 5 5 5 5 5 5 5 4 4 4 4 4 4 4 4
9 9 9 9 6 6 6 6 9 9 9 9 6 6 6 6 9 9 9 9 6 6 6 6
12 12 7 7 12 12 7 7 12 12 7 7 12 12 7 7 12 12 7 7 12 12 7 7
10 6 10 6 10 6 10 6 10 6 10 6 10 6 10 6 10 6 10 6 10 6 10 6
18 18 13 13 18 18 13 13 17 17 12 12 17 17 12 12 16 16 11 11 16 16 11 11
19 15 19 15 16 12 16 12 19 15 19 15 16 12 16 12 19 15 19 15 16 12 16 12
19 18 19 15 18 18 16 13 19 17 19 15 17 17 16 12 19 16 19 15 16 16 16 12
máx (A+ e, B +DI
Prob.
Prob. acumulada
12 13 15 16 17 18 19
0.07 0.03 0.20 0.20 0.17 0.17 0.17
0.07 0.10 0.30 0.50 0.67 0.83 1.00
Prob.
0.03 0.10 0.02 0.07 0.02 0.0 5 0.01 0.03 0.03 0.10 0.02 0.07 0.02 0.05 0.01 0.03 0.03 0.10 0.02 0.07 0.02 0.05 0.01 0.03
más larga que la configuración de Bob y Barb como equipo, aun cuando trabajan a la misma velocidad? Para explicar este fenómeno se puede usar el ejemplo sencillo de la figura 8.25. Se tienen dos tareas, A y B, que pueden hacerse en paralelo; la duración de ambas tareas está descrita por la misma distribución de probabilidad (duraciones de 6 o 10 semanas con la misma probabilidad). La duración esperada de cada tarea es 8.0. En este ejemplo hay cuatro realizaciones igualmente probables, como se indica en la hoja de cálculo de la figura 8.26. Como el proyecto no termina hasta que ambas tareas terminen, su duración es igual a la duración má.xinw de las tareas A y B, dada en la columna etiquetada "máx (A, B)". Aunque para cada tarea existe
PROBLEMAS DE ASIGNACIOt. DE RE0..7S:S. O::a::=:;;;;;;:::.o:__:::.::;m.,.~!liioll---.
FIGURA 8 .25 Tareas paralelas con d istribuciones ale atorias
FIGURA 8.26 Cuatro realizaciones del ejemplo sencill o
Duración de la tarea
Probabilidad
6 10
0.5 0.5
Realización
Duracion de la tarea A
Duracion de la tarea B
Máx(A, B)
Probabilidad
2 3 4
6 10 6 10
6 6 10 10
6 10 10 10
0.25 0.25 0.25 0.25
la misma posibilidad de que su duración sea 6 o 10 semanas, para el proyecto hay 25% de posibilidad de que su duración sea igual a 6 semanas y 75% de posibilidad de que sea igual a 1O emanas. De e ta manera, la duración esperada del proyecto es 9 semanas, no 8. que es lo que se podría pensar si se u pusieran duraciones de las tareas determinísticas y estimadas por sus valores esperados. Expresado algebraicamente, E[máx(A, B)] ;::: máx {E[A], E[B]} lo (\Ue implica que un proyecto con tareas paralelas y duraciones aleatorias siempre tendrá una duración esperada mayor que \a ouraC\ón e'l.~"t~\\~ \\~ 1::u~\.Q,~\~'1:a. de \as tareas (la igualdad se cumple sólo para duraciones determinísticas de las tareas). Todavía más, ¿qué pasaría si en lugar de 2, hubiera 3 tareas (digamos, A, B y C) en paralelo? Suponiendo que las 3 tareas tienen la misma distribución de probabilidad discreta dada en la figura 8.25 (es decir, que puedan necesitar 6 o 10 semanas con igual probabilidad), ¿cuál es el nuevo valor de E[máx(A, B, C)]? Debe verificarse que la duración esperada del proyecto aumenta a 9.50 (enumerando las ocho realizaciones de este caso). Se puede demostrar que la duración esperada del proyecto es una función monótona no decreciente al poner más tareas en paralelo. Este es un hecho importante: aun cuando todas las tareas tienen la misma distribución y el mismo valor e perado, la duración esperada del proyecto aumenta conforme se realizan más tareas simuháneas. Este concepto se exploró en la sección del capftulo 6 "variación en la tarea y duración e perada del proyecto". Volviendo al ejemplo de Bob y Barb, ahora se entiende por qué cuando trabajan solos en tareas simuháneas, en promedio, necesitan más tiempo que si trabajan en equipo, al menos mientras se suponga que juntos pueden terminar el trabajo en la mjtad del tiempo. Sin embargo, ¿qué ocurre si no se hace esta suposición? El administrador sabe que el proyecto tomará en promedio 16.42 semanas si Bob y Barb trabajan solos. Suponga que su eficiencia, cuando trabajan como equipo, está dada por la variable a; es decir, cuando Bob y Barb trabajan en equipo en la tarea}, pueden terminar la tarea en un tiempo tj, donde tj es el tiempo requerido por un individuo para terminar la tarea. (En el ejemplo anterior se supuso que a era igual a 0.5.)
202
CAPÍTULO 8 ADMINISTRACIÓN DE RECURSOS
El administrador puede ahora enconLrar el valor de a para el que le será indiferente que Bob y Barb trabajen en equipo o solos. Si trabajan en equipo, les tomará (30 a ) semanas esperadas terminar el proyecto; si trabajan solos les tomará en promedio 16.42 semanas. Por lo tanto, la igualdad 30 a = 16.42 implica que a = 54.7%; es decir, si Bob y Barb no pueden terminar una tarea en menos de 55% del tiempo que necesita una persona, entonces no deberán trabajar en equipo. Las implicaciones de este análisis son cruciales para los problemas de asignación de recursos, así como para la planeación de proyectos. Dado un número de tareas que pueden ser simultáneas y suponiendo que un equipo de proyecto pueda tenninar una tarea en un tiempo inversamente proporcional al tamaño del equipo (es decir, a ~ JIN. donde hay N miembros en el equipo) podría parecer prudente asignar estas tareas a un equipo de proyecto para que se realicen en secuencia. Aunque deben considerarse muchos otros factores al tomar decisiones de asignación de recursos, será prudente que un administrador de proyecto recuerde los efectos de las rutas paralelas y de las variaciones estadísticas.
CONCLUSIONES En este capítulo se exploraron los temas de nivelación de recursos y asignación de recursos en proyectos detenninísticos y estocásticos. En este capítulo se subrayaron otros puntos importantes: •
El problema de asignación de recursos es uno de los problemas fundamentales al que se enfrenta un admi nistrador de proyectos y en general es uno de los más difíciles, aun suporuendo que las duraciones de las tareas son conocidas y detenninísticas.
•
El problema de asignación de recursos está directamente relacionado con el concepto de cadena crítica definido por Goldrall y otros.
•
La naturaleza del problema de asignación de recursos cambia significati vamente cuando se reconoce en forma explícita que las duraciones de las tareas son aleatorias (por ejemplo, la duración esperada de un proyecto suele aumentar confonne se realizan más tareas en paralelo).
PROBLEMAS PARA ESTUDIO 1. A intervalos periódicos, Banco Acme da mantenirruento completo a sus sistemas de ilumina-
ción y ventilación. Como este proceso causa ciertas interrupciones en las operaciones del banco, los adrrurustradores quieren que se desarrolle de manera ordenada y eficiente. Para facilitar la planeación del proyecto, los administradores de Acme lo han dividido en tareas específicas. En la tabla siguiente se dan estas tareas. junto con sus predecesores inmediatos y sus duraciones estimadas para trabajadores rápidos y lentos. Tarea
Predecesor
A. Verificación de paneles y circuitos eléctricos
B. Cambio de todos los focos C. Limpieza y servicio al compresor del acondicionador de aire D. Prueba y servicio al calentador E. Llenado de tanques de aceite F. Limpieza y servicio al filtro electrostático G. Limpieza y servicio a la unidad del ventilador
Rápido (días)
Lento (días)
1.5 4
7
A
2
A
3 0.5
C, D C,D
2
3 4 5 5 3 4
Para cada tarea los administradores de Acme pueden contratar a uno de dos contratistas posibles. Para cada tarea se puede contratar un contratista más económico, que cobra $20
PROBLEMAS PARA ESTUDIO
203
por día, pero trabaja despacio, o se puede contratar a un contratista más costoso, de $50 por día, que trabaja más rápido. Como las tareas A y B requieren los servicios de un contratista que sea electricista, los administrado res de Acme desean que el mismo contratista realice ambas. Además, el costo de llenar los tanques de aceite no es una función del tiempo requerido; el costo es estrictamente una función de l número de galones de aceite necesario (estimado e n 15 000 galones a $ 1.75/galón). El Banco Acme lo ha contratado para administrar este proyecto y establece que quiere que el proyecto termi ne al menor costo posible, pero debe terminar en un lapso de 9 días para minimizar las interrupciones. Determine qué contratista deberá usarse y e l costo estimado del mantenimiento. ¿Cuá ndo deberá empezar a trabajar cada contrati ta? 2. Los administradores de Friged Midget Widget (FMW) Company, fabrican tes de pequeños chunches fríos, han elaborado una lista de las tareas a reali zar para el ensamble de un chunche (vea la tabla siguiente). ElJos deben decidir qué tamaño de equipo asignar a cada tarea; el tamaño del equipo detenn.IDará la duración de la tarea (en general, hay una relación inversa entre el tamaño del equipo y la duración del trabajo). A cada trabajo se puede asignar un equipo de tamaño mínimo. noriD3.I o máximo ; por razones técnicas no hay otras opciones posibles. Además, el reglamento del smdicalo e x.ige que no se cambie de equipo en lo que dure la tarea (por ejemplo, no se puede astgnar un equipo de tamaño normal durante Jos dos primeros días y luego aumentar el tamaño el resto de la duración de la tarea). Las duraciones se calculan como el número total de días-trabajador dividido entre el tamaño del equipo asignado a la tarea. Por ejemplo. si se asigna un equi po normal para la tarea ( 1, 2), ento nces la tarea requiere 8 días. La empresa FMW tiene un contrato para producir un chuncbe frio cada 24 días. Suponiendo que todos Jos trabajadores puedan realizar todas las tareas. determi ne cómo deben programarse las tareas de producción con objeto de minimizar la fuerza de trabajo necesaria (los costos de contratación y de despido son muy altos en esta industria). Tarea (í, 11 Días-trabajador totales
(1, 2) (1, 3) (2, 3) (2,4) (4, 5) (3, 5) (5, 6)
Mínimo
Nonnal Máx imo
32
2
4
48 40 12
4 4
6
2
30 54 24
3 3 3
5 3 5
8 8 8 4 6
6
9
4
6
3. Una imprenta tiene Jos siguientes trabajos a las 7 A.M.: Tiempos de procesamiento Trabajo
M áquina 1
A
3
1
B
4
3
e
Máquina 2
4
Todos Jos trabajos de impresió n deben procesarse primero e n la máquina 1 y luego en la máquina 2. La imprenta permanece abierta hasta termi nar todos Jos trabajos y no llegan trabajos durante el día. Los tiempos de procesamiento están dados en horas. a. Muestre por qué el procesamiento de los tres trabajos es equivalente a un proyecto dibujando una red de precedencias. Calcule la holgura total asociada con cada tarea.
204
CAPITULO 8 ADMINISTRACIÓN DE RECURSOS
b. Si el administrador de la imprema establece la secuencia de trabajo usando las holguras (es decir, el trabajo con la menor holgura tiene la prioridad más alta), ¿cuál será la duración del proyecto? ¿Hay otra secuencia que reduzca la duración del proyecto? ¿Es ésta la duración rrúnima del proyecto? Explique su razonamiento. c. ¿Cuál es el recurso cruci al en este problema? ¿Por qué?
REFERENCIAS Baker. K. lmroduction ro Sequencing and Scheduling. Nueva York: Wiley, 1974. Bedwonh. D. D. Industrial Systems: Planning. Analysis. Control. Nueva York: Ronald Press, 197 3. Brucker, P., A. Drex.l, R. Mohring. K. eumann y E. Pesch. "Resource-Constrained Project Scheduling: Notation, Classification, Models, and Methods''. Europeun Joumul of Operational Research 112, núm. 1 ( 1999): 3-41. Carlier, J. y A. H. G. Rínnooy Kan. "Scbeduling Subject to Nonrenewable Resource Constraims··. OperarioiiS Research Lerrers l, núm. 2 (abril, 1982): 52- 55 Davis, E. W. "Resource Allocation in Projea etwork Models-A Survey", Joumul of lndusrriul Engineering 17 ( 1966): 177-1 88. Davis, M .. N. Aquilano, y R. B. Chase. Fundamentals of Operarions Managemem. Burr Ridge. lll.: 1rwin McGraw-Hill, 1999. Demeulemeester, E. L. y W. S. Herroelen. "A Branch and Bound Procedure for the Multiple Resource-Constrained Project Schcduling Prob1em", Management Science 38 ( 1992): 1803-1818. Demeulemeester, E. L. y W. S. Herroelcn. Projecr Scheduling: A Research Handbook. orwell. Mass.: Kluwer Academic Publishers, 2002. Elsayed. E. A. "Aigorithms for Project Scheduling with Resource Constraints", lnremurionul Joumul of Producrion Research 20. núm. 1 ( 1982): 95-103. Elsayed, E. A. " Heuristics for Resource-Constrained Scheduling", /memariona/ Joumal of Producrion Researc/1 24, núm. 2 ( 1984): 299-310. Fox. R. E. The OPTionnaire: Can You \Vinar Managing rhe Producrion Game ? Milford, Conn.: Creative Output, 1990. Goldratt, E. M. Crirical Chain. Great Barrington, Mass.: Nonh River Press, 1997. Goldrau. E. M. y J. Cox. The Goal: A Processjor Ongoing lmpro¡·emem. Great Barringron. Mass. : Nonh River Press, 1992. Herroelen. W. S .. B. De Reyck y E. L. Demeulemeester. "Resource-Constrained Projcct Scheduling: A Survcy of Recent Devclopments" , Compurers and Operarions Researc/1 25 ( 1998): 279-302. Johnson, S. M. "Optímal Two and Three Stage Production Schedules with Setup Times lncluded''. Nal'al Research Logistics Quarterly 1 ( 1954): 61-68. Kolisch. R. "Resource Allocation Capabilitics ofCommercial Project Management Software Packages''. l nterfaces 29, núm. 4 (juli(}-agosto, 1999): 19-31. Lcach, L. Critica/ Chain Projecr Manageme/11. Norwood, Mass.: Anech House. 2000. LcBianc. L.. D. Randels y T. K. Swann . "Herry lntemational's Spreadsheet Optímízalion Model for Assigning Managers to Construction Projects", /11/erfaces 30. núm. 6 (noviembre-diciembre. 2000): 95- 106. Nahamias, S. Production and Operutions Anu/ysis. 3a ed. Chicago: lrwin, 1997. Newbold. R. C. Project Management in tite Fasr Lane: Applying tite Theory of Constraims. Boca Raton, Aa.: St. Lucie Prcss, 1998. Ozdamar, L. y G . Ulusoy. ''A Survey on the Rcsource-Constraincd Project Scheduling Problem". 1/E Transactions 21 ( 1995): 574-586. Sprecher, A. y A. Drexl. '·Note: On Semi-Active Timetabling in Resource-Constrained Project Scheduling", Manugemelll Science 45, núm. 3 (marzo, 1999): 452-454. Talbot. B. "Resource Constrained Project Scheduling with Time- Rcsource Trade-offs: The Nonpreemplive Case". Manugemelll Science 28. núm. 10 ( 1982): 1197-1210. Talbot, B. y J. Pauerson. "An Efficient lnteger Programming Algorithm with Network Cuts for Solving RcsourccConstrained Scheduling Problems". Manugemem Science 23, núm. 11 (julio. 1978): 1163-1174. Whitehouse, G. E. y J. Brown. "GENRES: An Extension of Brooks' Algorithm for Project Scheduling with Resource Constraints''. Jmernationul Joumal of Computers and btduslfial Engineering 3 ( 1979): 261.
CAPÍTULO
SUPERVISIÓN Y CONTROL Es de la más alta imponancia en el arte de la detección poder reconocer, enlie un número de actos, cuáles son incidentales y cuáles son vitales. De otro modo su energía y u atención estarán dispersas, en lugar de estar concentradas.
Sherlock Holmes
U na vez iniciado un proyecto, los adminisuadores del proyecto deben vigilar toda acción en con objeto de concenliar su energía (en palabras de Sherlock Holmes) para identificar las que estén real mente "fuera de conuol" y requieran acciones correctivas. Para esto, los adm inistradores deben responder cuatro pregun tas básicas:
C\D'SO
tareas
•
¿Cuál es el mejor método(s) para supervisar un proyecto en curso?
•
¿Cuándo está una tarea "fuera de conliol" y requiere la intervención activa de la adminislfación?
•
Si una tarea se marca como fuera de conuol, ¿qué acción o acciones deben emprenderse?
•
¿Quién debe ser el responsable del conuol de un proyecto?
Es claro que no hay una respuesta que sea la mej or para estas preguntas. Como se vio en el primer capítulo. no todos los proyectos son iguales; un sistema de supervisión y control debe ser adecuado para la complejidad y alcance del proyecto. Proyectos con un alto grado de complejidad pueden requerir sistemas de revisión más formales, mientras que proyectos de menor complejidad y alcance (como los proyectos de consuucción) requerirán sistemas de revisión informales. De cualquier manera, aquí se analizarán algunos de los sistemas de supervisión y conuol más usados, así corno los uueques que enfrentan los admi nistradores al adoptar estos sistemas. En general, se pueden tipificar los sistemas de supervisión y conliol como sistemas informales o sistemas formales . Enlie los sistemas informales se encuenuan juntas, correo electrónico o sólo pasar a echar un vistazo. Los sistemas formales incluyen contabil idad y otros informes periódicos, evento · programados, juntas, auditorías internas, revisiones del cliente y puntos de comparación externos. El costo de los sistemas informales puede ser más bajo que el de los formales aunque en general, ambos tienen costos significativos (se pueden dedicar tiempo y esfuerzo considerables a juntas, correo electrónico, etcétera). Es común que se use una combinación de sistemas formales e informales; sin embargo, las preguntas básicas para cualquiera de los dos sistemas son similares; qué métricas de desempeño usar, con qué frecuencia deben hacerse las revisiones, etcétera. En la siguiente sección se analizan estos aspectos con más detalle.
DISEÑO EFECTIVO DE UN SISTEMA DE SUPERVISIÓN Existen ues preguntas básicas relacionadas con el diseño de un sistema efectivo para supervisar y controlar un proyecto: •
¿Cómo deben realizarse las revisiones?
•
¿Con qué frecuencia deben ocurrir las revisiones?
•
¿Qué métricas de desempeño deben usarse?
205
206
CAPÍTULO 9
SUPERVISIÓN Y CONTROL
Respecto a las métricas de desempeño apropiadas, se deben resolver las siguientes preguntas. ¿Qué datos se deben recolectar?¿Cómo han de recolectarse estos datos? ¿De qué fuentes? ¿Qué frecuencia debe tener la recolección de datos? ¿Cómo deben analizarse las tendencias de los datos? Para ilustrar mejor estos aspectos, considere el ejemplo siguiente. Una administradora de proyectos tiene una tarea que se espera le lle'e 4 emanas y un total de l 600 horas-trabajador. Al final de la primera semana, encuentra que }a se han usado 420 horas- trabajador en esta tarea. ¿Está la tarea fuera de control y necesita alguna acción correctiva o debe la administradora suponer que la tarea se va desarrollando en forma normal y no necesita tomar una acción? Suponga que el administrador no emprende una acción y que el trabajo avanza a la segunda semana. Al final de la semana 2. la administradora encuentra que se ba "gastado" un total de 880 horas-trabajador en la tarea (es decir, -!89 horas-trabajador en la segunda semana). ¿Debe ahora emprender alguna acción? Suponga de nuevo que la admiru tradora del proyecto decide que las horas-trabajador extra representan fluctuaciones "normales . y la tarea avanza a la tercera semana. Al final de la semana 3 se han gastado 1 380 horas-trabajador. En la figu ra 9.1 se muestran la hoja de cálculo y la gráfica que indican las horas-trabajador utilizadas. El lector familiarizado con el concepto de control estadístico de procesos (SPC, statistical process control) empleado en mucho entornos de producción, reconocerá que el problema de control de un proyecto es similar al problema de control de la producción. En ambos casos se supone que el administrador conoce alguna medida de desempeño, así como la distri bución de esa medida, incluyendo la media y la varianza En cada periodo de revisión se prueba la hipótesis nula para ver si el proceso se ha salido de control (en cuyo caso será necesaria una acción correctiva). Para ilustrar cómo funciona este proceso en el ejemplo de control del proyecto, suponga que el gasto de horas-trabajador es constante cada semana a una tasa de 400 horas-trabaj ador (la estimación de la administradora del proyecto de 1 600 horas-trabajador en total para la tarea, dividido entre las 4 semanas de duración esperada). Suponga también que el gasto semanal sigue una distribución normal. Por lo tanto, se puede esperar que el gasto de horas-trabajador siga una distribución normal, como se indica para la semana 3 de la figura 9. 1. Conociendo la varianza en las horas-trabajador, la administradora puede calcular un valor de z y la posibilidad de que se usen 500 horas-trabajador en
FIGURA 9.1 Ejemplo de sistema de control
Costo planeado Costo real Costo acumulado Semana (horas-trabajador) (horas-trabajador) (horas-trabajador)
1 2 3
420 460 500
400 400 400
420 880 1 380
600
..o
500
e
400
..
300
"ti
·co
.o e
. ~
+;' <11
e
200
:::r:::
100
o
o 2 Semana
3
4
ENFOQUE DEL VALOR GANADO
207
una semana. Si esta probabilidad es menor que algún límite de confianza aceptado, la administradora aceptará la hipótesis nula y upondrá que la tarea está en un estado fuera de control y tomará alguna acción o acciones correctivas. Existen varios problemas al aplicar este enfoque al control de un proyecto. Primero, supone que se conoce la varianza del gasto semanal. Esta información suele estimarse a partir de una muestra de un proyecto anterior: si n embargo, las tareas de un proyecto son. por definición, únicas y quizá no se tengan datos de actividades anteriores. Si un administrador tiene suficiente experiencia en tareas similares (de manera que pueda estimar la distribución y los parámetros del gasto de recursos), entonces podrá emplear los métodos de SPC para determinar si la tarea requiere alguna acción o acciones correctivas. Otro problema con este enfoque es la estimación de las horas-trabajador por semana. Recuerde que la administradora estimó que esta tarea tomará 4 semanas y requiere 1 600 horas-trabajador en total; su estimación de 400 horas-trabajador por semana se basa, simplemente, en la suposición de que el gasto de horas-trabajador es igual todas las semanas. Sin embargo, no hay una razón para que esto se cumpla; en realidad, los gastos de muchas tareas varían durante la vida de la tarea de la misma manera que los gatos de recursos varían durante el curso de un proyecto. Sin embargo, si las tareas se definen con duraciones relativamente cortas, este problema se minimia (una razón más para definir más tareas de duración corta). No obstante, el problema más importante es que la admi nistradora no tiene una pieza primordial del rompecabezas de control; en realidad no sabe cuánto trabajo de la tarea se ruzo durante el periodo de tres semanas. Por ejemplo, suponga que en la cuarta semana se necesitan sólo 120 horas-trabajador para terminar la tarea. En este caso, la tarea termina a tiempo (en 4 semanas) con un gasto total de 1 500 horas-trabajador, lOO horas menos de lo estimado originalmente.
ENFOQUE DEL VALOR GANADO El enfoque del valor ganado surge del enfoque de PERT/Costo descrito en el importante documento de 1992, DoD and NASA Cuide, PERT Cost Systems Design . El sistema PERT/Costo se basaba en el principio de que los costos deben medirse y controlarse con base en el proyecto y no de acuerdo con la organización funcional de la empresa. El enfoque del valor ganado es una extensión del PERT/Costo. El enfoque del valor ganado se basa en la observación de que para construir un sistema de control efectivo se necesitan tres bloques básicos. Como se ilustra en el ejemplo anterior, deben tenerse valores de tres métricas para determinar con precisión el estado de todas las tareas (y del proyecto) en cualquier punto en el tiempo. En cualquier momento se deben conocer: •
Gastos reales a la fecha
•
Pronóstico de los gastos esperados por el plan del proyecto
•
Cantidad de trabajo logrado a la fecha
Estas tres métricas tienen términos y acrónimos bien definidos, que en general se incluyen en casi todos los programas comerciales de software para admi nistración de proyectos (AP). Los valores de estas métricas se reportan cada periodo defi nido (como cada semana) e incluyen los valores acumulados desde el inicio de la tarea o del proyecto. Estos acrónimos se definen como sigue: •
Costo real del trabajo desempeñado (CRTD). Costos o gastos reales de la tarea (o proyecto) durante un periodo dado. Los costos se pueden medir en unidades monetarias (dólares, euros, yenes), horas-trabajador o en cualquier otra unidad de medida consistente. En el ejemplo de la figura 9.1 , el valor del CRTD en la semana 3 es 500 horas-trabajador; el valor acumulado del CRTD para el periodo de tres semanas (semana 1, 2 y 3) es 1 380 horas-trabajador.
208
CAPÍTULO 9
SUPERVISIÓN Y CONTROL
•
Costo presupuestado del trabajo programado (CPTP). Camidad que el administrador del proyecto planeó gastar cada semana en esta tarea. según se determinó en el proceso de planeación del proyecto. En el ejemplo de la figura 9.1. la administradora estimó que la tarea requeriría, en total. 1 600 horas-trabajador y 4 semanas; usando la sencilla suposición de que el costo es el mismo todas las semanas, la admi nistradora estimó que el CPTP sería igual a 400 horas-trabajador cada semana. EJ CPTP se conoce también como valor planeado.
•
Costo presupuestado del trabajo desempeñado (CPTD). Valor real del trabajo logrado durante el periodo en cuestión. Por supuesto, este es el valor más difícil de estimar, ya que requiere que la administradora estime la proporción de trabajo realizado cada periodo. El CPTD se conoce también como valor ganado.
Estimar el porcentaje de trabajo realizado (para calcular el CPTD) puede ser difíci l en sí. Para obtener estimaciones razonablemente confiables, suele ser necesario que un asesor independiente capaz evalúe el trabajo reali zado hasta la fecha; en ocasiones, estimar el CPTD es tan sencillo como contar el número de artículos producidos, pero en tareas complejas, como programación de software, puede ser en extremo difícil (casi todas las medidas sencillas. como contar líneas de código, son inadecuadas). En este caso lo administradores de proyectos llegan a usar reglas fijas para estimar los valores de CPTD. Las reglas fijas usadas para estimar los valores de CPTD toman la forma: Xlk terminado al inicio de una tarea
( 1 -X)% terminado al final de una tarea Por ejemplo, si X = 1O, esto implica que se supone que el 10% de la tarea está terminado justo después del inicio de la tarea; pero no se acredi tará el 90% restante hasta q ue la tarea esté completamente term inada. El valor de X puede variar de cero a uno (un valor X = O implica que no se acredita nada para el CPTD hasta que toda la tarea esté completa). Es sencillo aplicar estas reglas, ya que no requieren inspección y pueden funcionar bien cuando las tareas están definidas con claridad y son relativamente cortas. Los valores de X más usuales son O, 25 y 50%; pero en teoría, se puede usar cualquier valor de X. En la figura 9.2 se dan los valores acumulados de CRTD, CPTP y CPTD para el ejemplo de la figura 9.1; los cáJculos del CPTD se basan en la suposición de que es posible estimar el porcentaje de trabajo terminado al final de cada semana. Observe que los valores de CPTD se obtienen multiplicando el porcentaje de trabajo terminado por 1 600 horas-trabajador (el costo total estimado para la tarea). Para encontrar los valores relativos para cada semana, la administradora simplemente resta los valores acumulados de la semana anterior; por ejemplo, en la tercera semana, se completó una cantidad total de trabajo igual a ( 1 360 - 800 = 560 horas-trabajador). Un examen de la tabla en la figura 9.2 indica que se puede usar una comparación entre estas tres métricas para evaluar el avance de la tarea; por ejemplo, una comparación entre el trabajo logrado y los gastos reales o entre el trabajo logrado y la cantidad de trabajo planeado. Estas dos
FIGURA 9.2 Métricas de desempeño acumulado para el ejemplo de la figura 9.1
Semana
CPTP (horas-trabajador)
CRTD (hora s-trabaj ador)
Porcentaje de trabajo terminado (acumulado)
CPTD (horas-traba jador)
1
400
420
23%
368
2
800
880
50%
800
3
1 200
1 380
85%
1 360
4
1 600
1 500
100%
1 600
ENFOQUE DEL VALOR GANADO
209
comparaciones, o variaciones, son la base del sistema del valor ganado y están defi nidas como sigue: Diferencia en el programa (DP) =(valor logrado)- (valor programado para completar) = valor ganado - valor planeado =CPTD-CPTP Diferencia en el costo (DC) =(valor logrado) - (gastos reales) = valor ganado - gastos reales = CPTD -CRTD La diferencia en el programa (DP) al final de la semana 1 es 368 - 400 = -32 horas-trabajador; SV negativo indica que la tarea no ha alcanzado el avance programado. De igual manera, la diferencia en el costo, DC (también conocida como variación en el gasto) al final de la semana l es negativa (368 - 420 = -52 horas-trabajador), e indica que los gastos excedieron al trabajo logrado (al menos durante la primera semana). La diferencia en el programa y la diferencia en el costo son medidas absolutas; es decir, la diferencia en el programa al fmal de la primera semana indica que el avance de la tarea va atrasado 32 horas-trabajador respecto a lo planeado. Pero, ¿32 horas-trabajador son una diferencia significativa? Si el gasto total para la tarea fuera, digamos, 5 000 horas-trabajador, lo más probable es que la diferencia de 32 horas-trabajador fuera insignificante. Por otro lado, si el gasto total planeado fuera l OO horas-trabajador. una variación de 32 horas-trabajador garantizaría una preocupación inmediata. Para evitar este problema se pueden usar dos medidas relativas, el índice de programa (IP) y el índice de costo (IC), definidos como sigue: , . CPTD lnd1ce de programa (IP) = - - CPTP - . CPTD Ind1ce de costo (IC) = - - CRTD Entonces las reglas siguientes asociadas con estos índices son válidas: Si IP = 1, la tarea va a tiempo. Si IP > 1, la tarea va adelantada al programa. Si IP < 1, la tarea va retrasada respecto al programa. Si IC = l, la tarea va dentro del presupuesto. Si IC > 1, los gastos son mejores que lo esperado. Si IC < 1, hay exceso de gastos. En la figura 9.3 se dan los valores de la diferencia en el programa, la diferencia en el costo, el índice de programa y el índice de costo para el ejemplo de la figura 9.2. Como indica la figura 9.3, las cuatro métricas indican que al final de la primera semana, la tarea iba retrasada y excedía el presupuesto. Al final de la semana 2, el trabajo logrado igualaba al
FIGURA 9 .3 Diferencia en el programa , diferencia en el costo, índice de programa e índ ice de costo para el ejemplo de las figuras 9.1 y 9.2
Semana
Diferencia en el programa (DP)
Diferencia en el costo (OC)
Índice de programa (IP)
Índice de costo (IC)
-32
-52
0.92
0.88
2
o
-80
1.00
0.91
3
160
-20
1.13
0.99
4
o
100
1.00
1.07
210
CAPITULO 9
SUPERVISIÓN Y CONTROL
trabajo programado; sin embargo, la tarea todavía excedía el presupuesto. Para el fin de la semana 4, la tarea parece estar a tiempo y por debajo de los costos esperados. Con frecuencia una gráfica de los índices de programa y de costo es útil para indicar tendencias. Observe que la tarea del ejemplo permanece arriba del presupuesto hasta que termina al final de la semana 4. Sin embargo, la gráfica del índice de costo indica que el costo mejoró de forma estable durante las 4 semanas que duró la tarea. La figura 9.4 presenta una gráfica de los índices de programa y de costo. Además de las diferencias en el programa y el costo, a veces se usan otras dos medidas: variación total y variación de tiempo. La variación total se define corno la diferencia entre la variación en el costo y la variación en el programa; es decir; Variación total =diferencia en costo- diferencia en programa = (CPTP - CRTD) - (CPTD - CPTP) =CPTD-CRTD La variación total es la diferencia entre el valor planeado y el costo real. La variación de tiempo se describe mejor con el ejemplo de las figuras 9.1 a 9.4. Al final de la semana 3, se ha completado el 85% del trabajo en la tarea del ejemplo, lo que equivale a 1 360 horas-trabajador. Según el plan original de la administradora, ¿en qué tiempo había planeado completar 1 360 horas-trabajador de trabajo? Como en el proceso de planeación se supuso que el trabajo avanzaría de manera uniforme durante las cuatro semanas de la vida de esta tarea, la administradora esperaba terminar 85% del trabajo en (0.85) x (4 semanas)= 3.4 semanas. La variación de tiempo está definida como la diferencia entre el tiempo planeado (3 .4 semanas) y el tiempo real (3 semanas) para terminar una cantidad de trabajo dada. Entonces, al final de la semana 3, la variación de tiempo es 3.4 - 3 = 0.4 semanas. Como el valor de la variación de tiempo es positivo, se tiene que el trabajo avanza adelante del programa.
Enfoque del valor ganado: ejemplo 2 Para ilustrar el enfoque del valor ganado, considere el diagrama de Ganlt de la figura 9.5. El proyecto representado por este diagrama de Gantl consiste en tres tareas; observe que se espera que los valores planeados para dos de las tareas (A y C) varíen durante su ejecución. Las horas-trabajador programadas por semana y las horas trabajador programadas acumuladas se dan en los renglones inferiores del diagrama de Gantt. Las horas-trabajador programadas acumuladas ( 128 horas-trabajador) se conocen como presupuesto a la terminación (PAT). Suponga que el equipo de proyecto ha trabajado ya 5 semanas en este proyecto. El administrador ha programado una reunión al final de cada semana para revisar y estimar el porcentaje de tra-
FIGURA 9 .4 Gráfica de índices de programa y de costo en el tiempo
1.20 1.10 4)
u
'6 1.00
.:
-¡¡ 0.90 'O
o 0.80
~
~
- ><
------ -----
-
0.70 0.60
2
3
4
Semana -
Índice de programa (IP) -
Índice de costo (IC)
ENFOQUE DEL VALOR GANADO
FIG URA 9 .5 Enfoque del valor ganado: ejemplo 2
211
Semana
1
2
4
3
5
6
8
7
9
10
!rarea A (36 horas-trabajado r)
6
6
6
8
10
Tarea B (36 horas-trabajador)
12
1
12
1
12
Tarea
e f56 h oras-traba j~dor)
10
10
12
12
12
12
12
Horas-trabajador programadas por sem.
6
6
6
20
22
22
10
12
Horas-trabajador prog . acum. (CPTP)
6
12
18
38
60
82
92
104 116 128
bajo logrado de cada tarea; estos valores se dan en la figura 9.6. El número de horas-trabajador cargadas a cada tarea también se reporta cada semana; estos valores se dan en la tabla de la figura 9.7. Basándose en estos informes. el admi nistrador de proyectos puede calcular las tres métricas de desempeño: CPTP, CRTD y CPTD. Observe que los cálculos de sus CPTD se basan en la suposición de que los recursos se han usado a una tasa uniforme; es decir, él supone que la termi nación de 30% de la tarea A corresponde a (0.3 x 36 horas-trabajador=) 10.8 horas trabajador de acuerdo con su plan inicial, donde la tarea A requiere 36 horas-trabajador. Inversamente, puede suponer que el trabajo terminado es proporcional al tiempo; en este caso supondrá que lograr 30% de la tarea corresponde a (0.3 x 5 semanas =) 1.5 semanas de trabajo. Con estos informes de avance como base, el administrador puede encontrar las tres medidas de desempeño así como La diferencia en el programa, la diferencia en el costo, el índice de programa y el índice de costo que se dan en la fig ura 9.8. Como se indica, los costos reales exceden los valores planeados en todas las semanas después de la primera (la diferencia en el costo en la semana 1 es positiva), lo que indica que después de la primera semana el proyecto excede su presupuesto. De manera similar, las diferencias en el programa son negativas durante todo el periodo de cinco semanas, esto indica que el proyecto va retrasado respecto a la tasa planeada de terminación. La gráfica de las tres métricas de desempeño, CRTD, CPTP y CPTD puede ayudar a visualizar las tendencias. En este ejemplo, parece que la terminación del trabajo está retrasada, pero esta diferencia no empeora, mientras que el excedente en los gastos parece aumentar con el tiempo (aunque estos aumentos no son monótonos).
FIGURA 9 . 6 Porcentaje acumulado del trabajo log rado al fin de cada semana
Semana Tarea A
1
3
15% 30% 40%
4
5
60% 80% 25%
Tarea B Tarea e
FIGURA 9 .7 Horas t rabajado r reales ca rgadas a las ta reas del proyecto
2
65%
Aún no iniciada
Semana
1
2
3
4
5
Tarea A
5
6
8
Ta rea B
10 15
10 10
e
Aún no iniciada
Tarea
212
CAPÍTULO 9
SUPERVISIÓN Y CONTROL
FIGURA 9 . 8 Métricas de desempeño y gráfica de cont ro l para el ejemplo 2
Semana
Horas-trabajador prog. acum . (CPTP) Horas-trabajador reales usadas (CRTD) Valor ganado (CPTD) Dif. en prog rama {DP) Dif. en el costo (OC)
1
2
3
4
5
6
7
8
9
10
6
12
18
38
60
82
92
104
116
128
11 10.8 -1.2
19 14.4 -3.6 -4.6
5 5.4 -0.6 0.4
-0.2
44 64 30.6 52.2 -7.4 -7.8 -13.4 - 11.8
.·•
140 120
o 100
IC:
8.
¡..
80
..
.,u
60
:E
40
Gl "O Gl "O
·e
en el programa
•GI
,1'',"-.
CPTD
20
o 2
3
4
5
6
7
8
9
10
Semana
Este ejemplo se puede usar para ilustrar la diferencia si el administrador aplica una regla fija para calcular el CPTD, en lugar de un porcentaje estimado de trabajo logrado. En forma arbitraria, suponga que el administrador usa una regla 20/80; es decir, supone que 20% del trabajo asociado con cada tarea termina al inicio de la tarea, pero que el 80% restame no se logra hasta que la tarea esté terminada. Al usar la regla 20/80, al final de la semana 1 se han completado (0.20 x 36 horas-trabajador = ) 7.2 horas-trabajador en la tarea A, otras (0.20 x 36 horas-trabajador =) 7.2 horas-trabajador se completan en la tarea al final de la semana 4 (observe que ninguna tarea ha terminado al final de la semana 5). En la figura 9.9 se da la estimación del CPTD (y CRTD y CPTP) con la regla fija 20/80. Como se indica en la figura 9.9, parece que el proyecto tiene problemas más serios al final de la semana 5 que cuando el administrador estimó el porcentaje de trabajo logrado en la figura 9.8. Esto no es una sorpresa, ya que ahora el admin istrador está suponiendo que sólo el 20% del trabajo en las tareas A y B se logra durante 5 semanas de trabajo en el proyecto. Este ejemplo ilustra que los administradores deben ser cuidadosos al interpretar los resultados cuando usan estas reglas fijas. Observe también que no tiene que aplicar la misma regla fija a todas las tareas. En algu nos casos se aplican reglas de asignación fijas diferentes a categorías de las tareas (un administrador de proyectos puede usar una regla 01100 para las tareas críticas y una regla 25175 para las tareas no críticas).
ACTUALIZACIÓN DE LAS ESTIMACIONES DE COSTO Y PROGRAMA
FIGURA 9.9 Ejemplo 2 usando la r egla fija 20/ 80 para esti mar el CPT D
213
Semana
Horas-trabajador prog. acum. (CPTP) Horas-trabajador reales usadas (CRTD) Valor ganado (CPTD)
1
2
3
4
5
6
7
8
9
10
6
12
18
38
60
82
92
104
116
128
5
11
7.2
7.2
19 7.2
44 14.4
64 14.4
Dif. en programa (OP}
1.2
-4.8
- 10.8 -23.6 -45.6 ,
Dif. en el costo (OC)
2.2
-3.8
-11.8 -29.6 -49.6 !
140 120
o 100
~
= ·¡; .tl
= ... = ...o
80
u
40
<;'
1/)
é o 'lii o
60
20
o 2
3
4
5
6
7
8
9
10
Semana
ACTUALIZACIÓN DE LAS ESTIMACIONES DE COSTO Y PROGRAMA Los administradores de proyectos deben poder usar la información disponible para actualizar sus estimaciones del costo y el programa en cualquier momento. Considere el ejemplo de la figura 9.6. Al final de la semana 5 el administrador estima que se ha logrado 80% de la tarea A, 65% de la tarea By que la tarea C aún no ha iniciado. Según estas estimaciones, al final de la semana 5 se ha logrado un trabajo con valor de 52.2 horas-trabajador. Como el administrador pronosticó un comenido total de trabajo (PAT) de 128 horas-trabajador, quedan 128 - 52.2 = 75.8 horas-trabajador en el proyecto. A la fecha (final de la semana 5) se han usado en total 64 horas-trabajador (costo real) para realizar este trabajo con valor de 52.2 horas-trabajador. Entonces, la razón CRTD/CPTD da el costo por hora-trabajador consumida; esto es, el costo por hora-trabajador completada es 64/52.2 = 1.226 horas-trabajador. Como esta razón es mayor que uno, el administrador est.á pagando más en horastrabajador que el trabajo que está obteniendo (al menos durante las primeras 5 semanas de este proyecto). Si se supone que esta proporción se mantiene el resto del proyecto (suposición algo pesimista), entonces el costo pronosticado por el administrador deberá revisarse y será igual a 1.226 x PAT = 1.226 x 128 horas-trabajador = 156.9 horas-trabajador. Este valor representa el costo actualizado del proyecto y se conoce como estimación a la ter minación (EAT). Observe que
214
CAPÍTULO 9
SUPERVISIÓN Y CONTROL
Estimación a la tenninación (EAT) = (CRTD ) PAT = (_!_) PAT CPTD IC Por supuesto, se pueden hacer otras suposiciones respecto a los pronósticos actualizados. Por ejemplo, el admin istrador puede ser más optimjsta y suponer que el problema q ue encontró hasta la semana 5 se puede corregir. En este caso él supone que el excedente del costo hasta la semana 5 (que es igual a DC = CPTD- CRTD = -11.8 horas-trabajador) es un evento único y que al corregir la fonna de administrar este proyecto no ocurrirán más excedemes de costos. Por lo tan to, un segundo pronóstico más optirillsta del EAT se defi ne por la estimación original del costo hecha por el administrador (PAT) más los excedentes de costos experimentado a la fecha (DC); en este caso, Estimación a la tenninación (EAT) = PAT- DC = 128 + 11 .8 = 139.8 horas-trabajador Estas dos estimaciones EAT representan el intervalo probable de los costos a la tenninación actualizados: es posible que el verdadero valor se encuentre entre 139.8 y 156.9 horas-trabajador. De manera sim ilar, el administrador puede estimar el tiempo de tenninación actualizado. En sus suposiciones originales, estrrnó que el proyecto requeriría 128 horas-trabajador (PAT) en total y 1O semanas. Esto corresponde a 128/10 semanas= 12.8 horas-trabajador por semana. Suponga que cree que el costo final total (EAT) será igual a 156.9 horas-trabajador. Entonces, el tiempo total actualizado para terrrunar el proyecto será 156.9/12.8 = 12.26 semanas. Por lo tanto, el adrillnistrador puede esperar que el proyecto se retrase 2.26 semanas sobre su estimación original.
CONCLUSIONES En este capítulo se estudió el enfoque del valor ganado y varias métricas que pueden ser útiles para supervisar el avance del proyecto. Igual que otras medidas, los adm inistradores deben usar con cuidado esta información y liltrarla según su propia experiencia y criterio. Por ejemplo, existen muchas razones por las que un proyecto puede tener una diferencia negativa en el programa o el costo y no estar "fuera de control"; algunas de estas razones son: •
Estimación incorrecta desde la base (valor planeado)
•
Cambios en las tasas o precios del trabajo
•
Materiales comprados antes de iniciar la tarea(s)
•
Cambios en el diseño o alcance del proyecto
En muchas organizaciones que usan el enfoque de valor ganado, con frec uencia se ponen en práctica límites arbitrarios para indicar cuándo debe revisarse con detalle el estado de una tarea (por ejemplo, 10% de excedente de costo o de retraso en el programa). Así, los administradores saben cómo dirigir su energía para mantener un proyecto dentro del programa y el presupuesto. Debe hacerse notar también que el enfoque del valor ganado es parte de un sistema más grande, desarrollado originalmente por el Departamento de Defensa de Estados Unidos para proporcionar un conjunto uni fonne de lineamientos para contratistas primarios y subcontralistas. La idea básica de este conj unto de lineamie ntos, conocido como Criterios para Sistemas de Control de Costo/Programa o (CISCSC, Cost/Schedule Control Systems Criteria) fue dar a contratistas y subcontratistas un conjunto común de treinta y cinco estándares para presupuestar, planear, contabilizar y controlar proyectos. De esta manera, todos los contratistas involucrados e n un proyecto podrían comunicarse entre ellos y conservar sus siste mas de in fonnación individuales. Para ver más detalles de estos criterios y lineamientos consulte Shtub et al., 1994. Aunque han surgido cuestionamientos acerca de la aplicabilidad e interpretación de estos estándares desde que se publicaron en 1967 (Fleming y Koppelman, 1994), el enfoque del valor ganado, como parte central de los C/SCSC, se ha empleado y aplicado con éxito en muchos tipos de organizaciones. Se dispone de más información de los C/SCSC en Project Management Institute (PMl ).
PROBLEMAS PARA ESTUDIO
215
PROBLEMAS PARA ESTUDIO l.
2.
a.
Encuentre la diferencia en el programa para un proyecto que tiene un costo real al mes 22 de $540 000, un costo programado de $523 000 y un valor ganado de $535 000.
b.
Un proyecto tiene en el mes 5 un costo real de $34 000, un costo planeado de $42 000 y un valor a la 1em1inación de $39 000. Encuentre las diferencias en el programa y el costo.
c.
Un proyecto exhibe en el mes 70 un costo real de $78 000, un costo programado de $84 000 y un valor a la terminación de $81 000. Encuentre los índices de programa y de costo.
Considere la información de un plan de proyecto que se presenta en la tabla siguiente. Tarea
Predecesor inmediato
Duración
Costo/ día programado
3
$1 000
5
$2 000
4 7
$4000
A B
e
A
o
B
$1 000
E
e
6
$2 000
F
D
8
$3 000
La tabla siguiente muestra los informes de control semanales para las primeras dos semanas (suponga semanas de 5 días laborales). Fin de la sem ana 1 Tarea
3.
o/o real completado
Fin de la semana 2
Costo real acumulado
"'o real completado
Cost o real acumulado
A
60%
$1 500
100%
B
30%
$3 000
100%
$ 2 900 $11 000
e
10%
$13 500
O%
$2 000 $ o
100%
D
90%
$10 000
E
0%
$
50%
$ 4 000
F
O%
$
o o
0%
$
o
a.
Use el enfoque del valor ganado para calcular CPTD, CPTP, CRTD, DP, DC, lP e IC para cada tarea y todo el proyecto.
b.
Calcule la variación total y la variación de tiempo al final de la semana 2.
c.
Use el enfoque de la estimación original y el enfoq ue de la estimación revisada para estimar el costo final de este proyecto al final de la semana l.
d.
Use el enfoque de la estimación original y el enfoque de la estimación revisada para estimar el costo final de este proyecto al final de la semana 2.
Un fabricante de sistemas de comunicación hace actualmente una revisión de su sistema de nómina computarizado. En lugar de usar LOC (líneas de código) para dar eguimiento al desarrollo de ese sistema de nómina, el fabricante adopta un método más confiable, el análisis de puntos de función. para medir/controlar el avance del proyecto. El nuevo sistema de nómina consta de 8 módulos, cada uno con cierta cantidad de puntos de función. Según la experiencia del fabricante, el desarrollo de cada punto de función toma una semana. El proyecto en proceso se evalúa al final de la octava semana. En la tabla
216
CAPiTULO 9
SUPERVISIÓN Y CONTROL
siguiente se proporciona el informe de programa/costo. (Suponga linealidad del costo vs. puntos de función en cada módulo.) Comente el estado del proyecto al final de la semana 8 con base en el cálculo de CPTD, CPTP y CRTD. ¿Está el proyecto "bajo control"?; si no, ¿por qué no? Predecesor Puntos de Presupuesto Puntos de función Dinero gastado (K) Módulo inmediato función terminados (K)
A
B
A
e o
A
E F G
e e
B
O, E F
H
4.
4 3 6 3 8 2 S 7
$90 $65 $75 $60 $55 $40 $80 $90
4 3 2 3
o o
$110 $ 35 $ 40 $ 75 S 20 S 10 S o S o
Sandy Point es la administradora de un pequeño proyecto que tiene 7 Lareas. Después de una cuidadosa y exhaustiva planeación, Sandy y su equipo llegaron a un acuerdo acerca de un programa propuesto para el proyecto que se muestra en el siguiente diagrama de Gantt. Hoy
8·--·· A ! - - - - - - ' ------1
e
o
E
F G 2
3
4
5
Tarea crítica
O programada
6 •
7
8
9 10 11 12 13 14 15
Tarea no crítica programada
•
Planeado, pero no usado
O Usado, pero no planeado
Como se indica en su proyecto original, Sandy y su equipo habían estimado las siguientes duraciones y costos directos (totales) para cada tarea. Tarea
A
B
e o E
F G
Duración (semanas)
Valor planeado
4 7 3 5 5 3
$2,000 $2,800 $1 ,150 $ 625 $1 ,350 $1,050 $ 270
3
REFERENCIAS
217
Esta mañana (al iniciar la semana 6), Sandy recibió un informe del avance: como se ve en el diagrama de GantL la tarea C no pudo iniciar hasta esta semana debido a un retraso inesperado en la terminación de la tarea A. El informe indica también que la tarea 8 terminó dos semanas antes de lo esperado. El informe de avance se resume como sigue.
5.
Ta rea
Estado actual
Gastos reales a la fecha
Porcentaje de trabajo completado
A
Terminado
$2 000
100%
8
Terminado
$2 800
100%
e o
Iniciando En marcha
E
No ha iniciado
F
No ha iniciado
G
No ha iniciado
o
0%
S 330
55%
o o o
O%
$ $ $ $
0% 0%
a.
Hasta hoy (principio de la semana 6), ¿cuál es la diferencia en el costo del proyecto? ¿Cuál es la diferencia en el programa del proyecto?
b.
Con base en la información proporcionada a la fecha, ¿cuál es su evaluación del estado actual del proyecto?
Considere la información del problema 4. Si usa una fórmula fija 30nO para calcular el valor del trabajo terminado (CPTD) en lugar de confiar en los informes de avance para estimar el porcentaje de trabajo terminado, ¿cuál es el valor del índice de costo del proyecto al inicio de la semana 6? ¿Cuál es el índice de programa para el proyecto? ¿Modifica esto su punto de vista sobre el avance del proyecto a la fecha?
REFERENCIAS Aeming, Q. W. y J. M. Koppelman. "The 'Eamed Value' Concept: Back to the Basics" . PM Nen•-ork, enero, 1994. Shtub. A., J. Bard y S. Globerson. Project Management: Engineering, Technology, and lmplementation. Prentice·Hall , Englewood Cliffs. N.J.. 1994.
10,--~_,~---,.------------~~~~ ADMINISTRACIÓN DE PROYECTOS MÚLTIPLES
P
ocas organizaciones admjnisiiall un solo proyecto a la vez. Como 'irno al principio de este libro, casi todas mantienen un portafolio de proyec10s con objeto de maximizar la utilización de recursos y diversificar (y mirurrúzar) el riesgo organi zacional. Dado que los recursos en general se comparten entre los proyectos, la torna de decisio nes con proyectos múltiples es mucho más complej a que cuando se administra un proyecto ún ico. En este capítulo se estudia el tema relativo a la administración de proyectos múltiples y se muestra cómo pueden hacerse los complejos trueques entre ellos. La mayor parte de los productos de software para admjrusLraeión de proyectos (AP) no están diseñados para proyectos múltiples. Algunos admjnistradores de proyectos usan estos productos con varios proyectos agregando nodos "súper-inicio"y "súper-fin" que unen todos los proyectos en una sola red gigante de precedencias de actividades en los nodos (AON). Corno se verá en este capítu lo, este ingenuo método rara vez resulta útil. Administrar proyectos múltiples requiere que la organización y los trabajadores establezcan prioridades para los proyectos. En este capítulo se estudiará cómo se pueden establecer estas prioridades, así corno los impactos negativos cuando se adoptan prioridades inadecuadas. Para iluSLrar estos trueques se verá un sencillo juego (K&B del clip) que servirá para ilustrar algun os puntos importantes relacionados con la administración de proyectos múltiples. El juego K&B del clip se describe en la siguiente sección; en el CD que acompaña a este libro se encontrarán diapositivas de Power Point, correspondientes a este j uego. Por último, se considerará q ué ocurre cuando la organización se encuentra con proyectos múltiples que le llegan en diferentes tiempos. En algunos casos (como talleres de automóviles, salones de belleza), los administradores pueden programar las llegadas para reducir un poco la variación entre llegadas; pero en muchos otros casos, los proyectos llegan en forma aleatoria en momentos fuera del control administrativo directo (corno las llegadas a clírucas de urgencias, pedidos de automóviles nuevos, etcétera). Cuando los proyectos llegan de manera aleatoria (programados o no), los administradores tienen que decidir cuánto tiempo tomará cada proyecto (¿c uándo estará listo su automóvil?), además de decidir cuántos recursos asignar a cada proyecto. Es claro que si se contratan más mecánicos, se reduce el tiempo de ej ecución de cada "proyecto" de reparació n de un automóvil, pero se incrementan los costos del taller. En este capítulo se analizarán estos trueques, así como los métodos para establecer fechas de entrega y niveles de recursos. Por último, se examina un caso de estudio (Pate Moss: contador especialista en impuestos) que ilustra los problemas y aspectos rel acionados con la llegada aleatoria de nuevos proyectos.
TAREAS MÚLTIPLES CON PROYECTOS MÚLTIPLES Para ilustrar alg unos de los problemas y trueques que deben enfrentarse cuando se administran proyec!Os múltiples, se considerará un ej emplo sencillo. Suponga que una organización tiene dos, A y B; cada proyecto requiere T periodos para terminar. Ambos proyectos requieren cuatro tareas que tienen la misma duració n esperada (igual a 0.25T). Los dos proyectos A y B pueden iniciar al rrusmo
218
TAREAS MÚLTIPLES CON PROYECTOS MÚLTIPLES
219
tiempo. Para simplificar más el análisis, se supondrá que el mismo equipo del proyecto debe realizar las cuatro tareas de los dos proyectos en secuencia. El equipo del proyecto se encuentra con varias opciones, dependiendo de las prioridades que asignen a los dos proyectos. En un caso, el equipo puede ponderar igual los dos proyectos y realizar tareas múltiples de manera que el avance en los dos proyectos sea aproximadamente igual; es decir, trabajarían en las tareas Al, B 1, A2, B2, etcétera, hasta terminar los dos proyectos. Este enfoque se llama también enfoque de enrejado. En el otro extremo de las prioridades, el equipo podría dar una prioridad más alta a uno de los proyectos (por ejemplo. al proyecto A) y trabajar sólo él hasta term inarlo, para después volver su a tención al segundo proyecto, B. Suponiendo que no hay un costo asociado con el cambio entre tareas o proyectos, estos dos programas alternativos se presentan en la figura 10.1. Observe que el tiempo necesario para terminar los dos proyectos de la figura 10.1 es aproximadamente el mismo (2T periodos), ya sea que el equipo de proyecto realice tareas múltiples o no. Si el equipo realiza tareas múltiples, el proyecto A termina en el tiempo 1.75T, y el proyecto B termina en el tiempo 2T. Sin embargo, si se establecen prioridades entre los proyectos, el proyecto A termina en el tiempo T, y el proyecto B termina en el tiempo 2T. Suponiendo que se paga a la organización cuando el proyecto está terminado. entonces una ventaja de dar prioridades a los proyectos es evidente: la organización recibe el pago del proyecto A en el tiempo T (no hay tareas mú ltiples) e n lugar de esperar hasta el tiempo 1.75T con tareas múltiples. En ambos casos, la organización cobra por el proyecto B en el tiempo 2T. Así, la empresa inc rementa sus ganancias al cobrar antes, sin incurri r en gastos adicionales. Si además hay un costo por cambiar de un proyecto a otro, la ventaja de dar prioridades a los proyectos aumenta. En este caso, las ganancias de la empresa son mayores si termina el proyecto A antes de e mpezar a trabajar en el B.
Juego K&B del clip ¿Existe la ventaja de dar prioridades a los proyectos cuando las duraciones de las tareas son aleatorias? ¿Qué pasa si las redes de precedencias son más realistas (cuando no todas las tareas son secuenciales)? ¿Cuáles son las consecuencias de asignar prioridades a los proyectos cuando hay que emplear distintos tipos de trabajadores? Estos aspectos se exploran e n el j uego K&B del clip, descrito en las diapositivas de Power Point que se encuentran en el CD que acompaña al libro. En el juego se deben realizar tres proyectos: los proyectos Rojo, Azul y Blanco. Los tres proyectos son idénticos; en cada proyecto se requiere que tres tipos de clips (estándar, de mariposa y de presión, vea la figura 10.2), que están mezclados en un recipiente, se separen en tres recipien-
FIGURA 10. 1 Enfoqu e de ta reas múltiples vs. el de enrejado (prioridades)
GBGC!!JG~GB 1
Proyecto A
~1
Proyecto B
FIGURA 10. 2 Tipos de clips usados en el juego K&B
Clip está ndar
Clip de mariposa
Clip de presión
~
220
CAPÍTULO 10
ADMINISTRACIÓN DE PROYECTOS MÚLTIPLES
tes del mismo color (esto es, los 90 clip mezclados en el recipiente rojo deben separar e por tipo en tres recipientes rojos, los 90 clips mezclados en e l recipiente azuJ deben separarse por tipo en tres recipienres azules, etcétera). En el juego de este ejemplo hay 30 clips de cada tipo, pero se puede usar cualquier número de clips. Las reglas para terminar cada proyecto son las siguientes: •
Sólo una persona (especiali ta en cli ps) puede separar cada tipo de clips.
•
Sólo un clip se puede separar a la vez (y sólo se puede usar una mano).
•
Todos los clips estándar deben estar separados antes de separar los otros dos tipos.
•
Una persona se dedica a registrar e l tiempo req uerido para terminar cada proyecto y e l tiempo total para los tres proyectos.
Se realizan dos corridas como parte del juego: corresponden a las dos estrategias de tareas múltiples y prioridades indicadas en la figura 10. 1. En la primera corrida (tareas múltiples) cada jugador puede separar máximo cinco clips antes de pasar a otro proyecto; es decir, el especialista en clips está ndar separa cinco clips del proyecto Rojo y pasa al proyecto Azul. Después de eparar ci nco clips estándar del proyecto Azul puede regresar al Rojo o pasar al Blanco. Cada especialista puede separar hasta cinco clips en un proyecto antes de pasar a otro (a menos que no haya otro proyecto disponible). En esta corrida, cada especialista hace tareas múltiples entre los tres proyectos hasta que terminan los tres proyectos. En la segunda corrida. los especialistas usan enfoq ue de enrej ado o prioridades, concenrrándose primero en el proyecto Rojo, separando cuantos clips sea posible (se elimina el límite de cinco c lips). Cuando el especialista e n clips estándar termina de separar todos sus clips en el proyecto Rojo, pasa a l proyecto Azul. Cuando termina de separar los clips estándar del proyecto Azul pasa al Blanco. Los otros especialistas e n clips siguen un patrón similar. En cada corrida, un especiali ta de tiempos registra los tiempos de inicio y te rminación de cada proyecto para poder comparar los tiempos de nujo. Al termi nar las dos corridas deben considerarse la diferencia entre las corridas en el tiempo de terminación del proyecto, e l trabajo e n proceso del proyecto, la e ficiencia y la utilización de los miembros del equipo. ¿Cuáles de estas métricas son más importantes en los entornos de proyectos? ¿Qué implicaciones tiene este juego en los proyectos reales?
EQUIPOS DE PROVECTO E INCENTIVOS ¿Los miembros del equipo deben recibir incentivos especiales por lograr c iertas metas del proyecto? Es claro que esta es quizá la manera más efectiva de dar prioridades a los proyectos en un entorno de proyectos múltiples, pero es controversia! en la práctica, ya que esos incentivos pueden ocasionar que los e.quipos tomen atajos y no realicen bien las tareas necesarias. Para ilustrar estos riesgos considere un caso de estudio descrito por Riek (2001 ): Se encargó a un equipo de proyecto expandir la capacidad de producción y la presencia internacional construyendo nuevas insta laciones en un lugar en el extranjero. Como el personal consume mucho capital, se incentivó al equipo de proyecto para realizar la construcción con costos de capital inferiores al presupuesto. El equipo del proyecto estaba constitu ido por ingenieros de construcción y de procesos, ya que este esfuerzo se consideraba una duplicación directa de la tecnología existe nte. La planta se construyó con una reducción de capital significativa y e l equipo de proyecto fue premiado con un fuerte incentivo como se le había prometido. Sin embargo, las operaciones de la planta subsiguiente fueron un desastre importante. Un material ácido estaba presente en todo el proceso y las revisiones de los materiales de construcción no fueron apropiadas. En consecuencia, durante los primeros tres meses de operación, casi todas las tuberías y algunos recipientes importantes del proceso sufrieron
ASIGNACIÓN DE RECURSOS Y DESIGNACIÓN DE FECHAS DE ENTREGA EN UN ENTORNO DE PROYECTOS MÚLTIPLES
221
una fuerte corrosión. Después de verificar qué habría que hacer para remediar el problema, la planta dejó de operar, se cerró y se desmanteló. El caso de estudio de Riek ilustra los trueques entre las 4 dimensiones dadas en la figura 1.4 (capítulo 1): costo, presupuesto, di seño/alcance y calidad. Cuando se dan prioridades demas iado altas a un subconjunto de estas dimensiones (en este caso, costo y programación) lo más probable es que las otras dimensiones sufran. Cuando se usan incentivos para establecer prioridades, un buen sistema de control y supervisión del proyecto es esencial para asegurar que no se comprometan los objetivos de calidad y diseño. L'o segundo problema que surge con frecuencia cuando se ofrecen incentivos directos en proyectos específicos está relacionado con la compresión del proyecto (estudiada en el capítulo 5). Si a un eqc:.po de proyecto se le ofrecen incentivos relacionados con eventos específicos, puede ser difícil cambiar estos incentivos y/o las fechas de entrega si el administrador decide que debe cambiar el progranu del proyecto. Por el contrario, los incentivos pueden hacer más difícil interrumpir o suspender un proyecto (por ejemplo, c uando un competidor saca inesperadamente un producto mejor).
ASIGNACIÓN DE RECURSOS V DESIGNACIÓN DE FECHAS DE ENTREGA EN UN ENTORNO DE PROYECTOS MÚLTIPLES En un experi mento único, Dumond y Mabe rt ( 1988) investigaron varios algoritmos heurísticos de programación y reglas para fijar fechas de entrega, en un entorno simulado de proyec tos múltiples, cuando los proyectos IJegan aleatoriamente. En su simulación, los proyectos conte nían entre 6 y 49 tareas (con media de 2~) y IJegaban al azar durante un periodo simulado de 2 000 días. El tiempo promedio e ntre llegadas para lo proyectos era 8 días : la ruta crítica promedio de los proyectos era 31.4 días (el intervalo era de 8 a 78 días). Las e struc turas (es dec ir, las redes de precedencias) de estos proyectos generados alealOriamente se seleccionaron de proyectos usados en investigaciones anteriores. Cada tarea podia emplear hasta tres tipos de recursos; los requerimientos de recursos se establecían de manera que la utili zació n promedio de un recurso fuera alrededor de 85% . Dumont y Mabert compararo n la efectividad de las heurísticas de asignac ión de recursos y designación de fechas de entrega en dos entornos: •
Entorno de control completo. Cuando los administradores pueden establecer la fecha de entrega de todos los proyectos que llegan.
•
Entorno de control parcial. Cuando una proporción de proyectos llega con una fecha de e ntrega preestablecida (por e l personal de ventas o por requerimientos del mercado).
Dumont y Mabert analizaron cinco reglas de programación para dar prioridades a las tareas disponibles en cualquier momento dado (según sus restricciones de precedencia). Los valores de prioridad se recalcularo n cada vez que llegaba un nuevo proyecto. Las cinco reglas de programación consideradas por Dumond y Mabert fueron: 1.
Primero en entrar, primero en salir. La tarea que ha estado en espera más tiempo tiene la prioridad más alta (Jos empates se rompen aleatoriamente).
2.
La tarea más corta del proyecto más corto. La prioridad de una tarea se calcula sumando la duración de la tarea más la ruta crítica del proyecto.
3.
Holgura mínima basada en la fecha de entrega. La prioridad de una tarea se basa en la fecha de e ntrega inicial establecida cuando llega el proyecto menos e l tiempo de inicio más próximo de la tarea.
4.
Tiempo mínimo de retraso en la terminación según la fecha de entrega. La prioridad de una tarea es el mínimo entre los tiempos de terminación más lejanos basado en la fecha de entrega inicial establecida c uando llega el proyecto o en el tiempo de terminación más lejano calculado.
222
CAPÍTULO 10
ADM INISTRACIÓN DE PROYECTOS M Ú LTIPLES
5.
Duración mínima de la tarea tomada del proyecto más corto restante. La prioridad de una tarea es el mínimo de los \
Cuando los proyectos llegan sin fechas de entrega preeslablecidas, Dumond y Mabert estudiaro n cuatro reglas para establecerlas. Las cuatro heurísticas se basaron e n reglas que los autores observaron en la práctica, así como en reglas incl uidas en la literatura de programación de tall eres intermitentes. Las cuatro reglas empleadas para establecer fechas de entrega fueron: 1.
Regla del flujo medio p ara la (echa de entrega. La fecha de e ntrega es la fecha de llegada del proyecto más el tiempo promedio histórico necesario para term inar el proyecto.
2.
Regla del número de acthi dades. La fecha de entrega es el tiempo de llegada del proyecto más a lguna constante que representa la durac ión esperada de la tarea) multiplicada por el número de tareaS en e l proyecto.
3.
Regla de la ruta crítica. La fecha de entrega es el tiempo de llegada del proyecto más una constante (factor de retraso) multiplicada por la longitud de la rula crítica.
4.
Regla de la fecha de entrega en el tiempo de terminación programado. La fecha de entrega se fija u ando una de l:b reglas para programar proyectos suponiendo que no llegan nuevos proyectos, } después se ajusta esta fecha de e ntrega con un factor de retraso.
Para comparar la efectividad de las reglas heurísticas de asignación de recursos y de terminación de fechas de entrega, Du mond y Yfaben recolectaron datos con cuatro criterios: •
Tiempo promedio de term inación del proyecto
•
Retraso promedio del proyecto
•
Desviación estándar del retraso promedio del proyecto
•
Retraso total sobre todos los proyectos y periodos
En el entorno de control c ompleto (donde los admin istradores de proyecto fijan las fechas de entrega de todos los proyectos que llegan), los autores no encontraron diferencias significativas entre todas las heurísticas de programación y las reglas para fijar fecha de entrega, a un ni vel de significancia de 0.05 (con la prueba de intervalo múltiple de Scheffe) para el tiempo medio de terminación y e l retraso promedio de un proyecto. Sin embargo, respecto a la varianza en e l retraso los autores encontraron que la regla de programación (2) y la de fecha de entrega ( 1) funcionan mucho peor que las otras dos reglas (a un nive l de significancia 0.01), mientras que la regla para la fecha de entrega (4) func iona mucho mejor. Respecto al criterio de retraso tota l los autores encontraron que la regla (4) para fijar fecha de e ntrega también funciona mej or que las otras reglas. En el entorno de control parcial, Dumond y Mabert suponen que los administradores de proyecto pueden fijar las fechas de e ntrega de los proyectos "normales", pero no de proyectos de alta prioridad (donde las fechas de entrega son iguales a la rula crítica) ni de proyectos de baja prioridad (cuyas fechas de entrega se igualan a tres veces la ruta crítica). Los autores probaron casos en los que lO, 20, 30, 40, 50 y 60% de los proyectos caían dentro de la categoría normal. Como se esperaba encontraron que el desempeño se deterioraba cuando los administradores no podían establecer la fecha de entrega. Usando las reglas (3) y (4), Dumond y Mabert encontraron que la regla de programación (4) funciona mejor para todos los tamaños (excepto uno) de categorías normales respecto al tiempo de terminación promedio. En c uanto al retraso medio, encontraron que e l retraso promedio decrece como función monótona conforme aumenta la proporción de proyectos con fecha de entrega preeslablecida (para cualquiera de las reglas de tiempo de entrega). Otro hallazgo interesante en este estudio fue el desempeño de la combinación de la regla de programación ( 1) y la de fechas de entrega (4). La regla de programación que programa la tarea que lleva más tiempo en espera no considera fechas de entrega y, por lo tanto, e vi la (según Dumond y Mabert) algo del "nerviosismo" de las reglas heurísticas basadas en fechas de entrega. Esta com-
APÉNDICE 10A. PETE MOSS: CONTADOR
223
binación pareció fu ncionar mucho mejor cuando la proporción de fechas de entrega preestablecidas para proyectos "normales" era menor que 40% (al menos para la tardanza total).
CONCLUSIONES La estructura de una organización tiene un impacto mayor en los resultados de un proyecto en un entorno de proyectos múltiples que en uno con un proyecto único. Si los admi nistradores de proyectos son relativamente autónomos (como en una organización matricial), es más probable que los proyectos tengan ponderaciones iguales y es posible que los trabajadores realicen tareas múltiples como resultado. Por otro lado. cuando un solo administrador controla todos los proyectos, es más probable que se les asignen prioridades y que los recursos se utilicen mejor. Un administrador de proyectos de un portafolio puede considerar los trueques entre todos los proyectos activos y dar prioridad a los que proporcionan más ganancia para la organjzación. El administrador de un portafolio es también una parte crucial para la supervisión y control de todos los proyectos en desarrollo, de manera que la organización puede seguir tanto los proyectos retrasados como los que terrillnaron antes de lo esperado. Conforme se realiza el trabajo de los proyectos y los factores externos cambian. se pueden revaluar las prioridades de los proyectos lo mismo que el trabajo asignado al equipo de proyecto. El resultado de esta mayor flexibilidad permite una mejora global en todos los proyectos.
REFERENCIAS Dumond, J. y V. Mabert. "'Evaluating Project Scheduling and Due Date Assignment Procedures: An Experimental Analysis". Ma11agemelll Scie11ce 343. núm. 1 (enero. 1988): 1O1-118. Riek, R. F. "'From Experience: Capruring Hard-Won NPD Lessons in CheckJists", Producr lmrovario11 Manageme111 18, (2001) : 30 1- 313.
APÉNDICE 10A. PETE MOSS: CONTADOR Pete Moss es un contador especializado en declaraciones de impuestos de personas físicas y empresas pequeñas. Como es de esperarse, Pete encuentra que la demanda de sus servicios aumenta significativamente después el 1 de enero, y continúa más o menos constante hasta el 15 de abril (esto es, en la temporada de preparación de declaraciones). Como es buen contador y buen administrador, Pete está preocupado por su proceso para la preparación de declaraciones y se pregunta si debe hacer alg unas modificaciones para aumentar sus ganancias durante la temporada. Pete ha observado que requiere más o menos el mismo tiempo para preparar las declaraciones de impuestos de la mayoría de sus clientes. Dada esta observación, Pete cobra a sus clientes una cantidad fija ($550) por declaración. Aunque unas declaraciones requieren más tiempo que otras, Pete estima que esta cuota de $550 representa el precio que H&R Block cobraría por una declaración promedio hecha por Pete. Además ha encontrado que una cuota fija satisface más a los clientes ya que saben desde un principio cuál es el costo y no los sorprende un costo inesperado. Dado su esquema de cobro, Pete sabe que podrá aumentar sus ganancias si reduce sus costos, suponiendo que todavía proporcione un servicio de calidad. En este momento Pete tiene dos contadores jóvenes que le ayudan con la preparación de las decl araciones. Cada uno de ellos tiene contrato y cobra 40 horas a la semana (estén ocupados preparando alguna declaración de impuestos o sentados sin hacer nada), a un costo de $20 por hora. Pete puede contratar también contadores j óvenes en base a horas extras por más de 40 horas a la semana; por las horas extras paga $30 por hora (aunque limita la cantidad de horas extras a un máximo de 1O horas por semana). Las decisiones de horas extras deben tomarse al inicio de la semana para que los jóvenes puedan hacer sus planes. Pete no se asigna un salario a sí mjsmo; en su lugar se queda con las ganancias residuales como ingreso. Además se rehúsa a trabajar más de 40 horas a la semana debido a su activa vida social;
224
CAPÍTU LO 10
ADMINISTRACIÓN DE PROYECTOS MÚLTIPLES
si n embargo, está dispuesto a Lrabajar más horas alg unos días. si es necesario (es decir, Pete no necesariamente Lrabaja sólo 8 horas al dfa). Aunque Pete podría realizar algunas (o todas) las tareas que asigna a sus contadores jóvenes, tiene la política de no realiz.arlas. Casi todas las declaraciones de im puestos requieren un proceso imitar que consiste en siete tareas etiquetadas como {A, B, C. D. E. F, G}. Algun as no se pueden realizar hasta que las predecesoras estén terminadas; por ejemplo, no se pueden introducir los datos en la computadora hasta que están org anizados y revisados por contador joven. Como es usual que los clientes Lraigan sus datos a la primera reunión con Pete, un contador j oven puede revisarl os tan pronto como Pete inicie la reun ión con el cliente. Tres de las tareas las hace Pete mismo (tareas A, D y G) y no puede hacer más de una tarea a la vez. En la tabla JO. J se presenta la Ji ta de tareas, la descripción, la duración estimada y la persona responsable. Como Pete contrata solamente contadores jóvenes experimentados, ellos pueden realizar cualquier tarea; sin embargo. una vez que uno de ellos empieza una tarea, se espera que la realice sin interrupción. ni ayuda, hasta terminarla. En la temporada de preparación de declaraciones de impuestos. Pete tiene, en promedio, 3 clientes por semana, aunque este número varía mucho (Pete abre su oficina sólo 5 días a la semana para poder ir a esquiar los fines de semana). Como Jos clientes Uegan de manera aleatoria, con frecuencia la oficina tiene más de una declaración en proceso. Para aumentar sus ganancias (y su ingreso), Pete estudia varias alternativas. Primero, ha considerado la posibilidad de disminuir el tamaño de su empresa } quedarse sólo con un contador joven (que trabajará horas exlras si es necesario). Pete piensa que esto reducirá sus costos si n incrementar demasiado el tiempo de preparación de las declaraciones. Como cobra una cuota fij a por cada declaración, piensa que ésta es una manera de incrementar sus ganancias. Como olra alternativa, Pete contempla la posibilidad de una expansión que aumentaría la cantidad de cl ientes. En particular, está considerando la posibilidad de desarrollar un servicio de preparación de declaraciones que ofrezca servicios vía Internet (por ejemplo, www. PeteMoss.com). Pete estima que el costo por un sitio en la Red para su negocio eleclrónico sería un pago único aproximado de $2 000. También estima que la naturaleza de su Lrabajo de preparación de declaraciones en esencia no cambiaría y que podría seguir cobrando la misma cantidad ($550 por declaración). Sin embargo, una empresa de investigación de mercado contratada por Pete estima que la tasa promedio de llegadas de clientes se incrementaría a 3.75 clientes por semana. (La empresa de investigación de mercado descubrió también que los clientes llegan de acuerdo con una distribución Poisson.) Pete se dirige a usted para pedirle consejo. ¿Qué estrategia recomendaría que Pete adoptara? ¿Por qué? ¿Debe Pete iniciar un negocio elccLrónico? Si Pete adopta la estrategia sugerida por usted, ¿cuál será el incremento semanal esperado en sus ganancias? ¿Podrá Pete ofrecer a sus clientes la misma calidad de servicio (como puntualidad)?
FIGURA 10A. 1 Descr ipción d e las tareas para p repara r declaraciones d e impuestos
Tarea
Descripción
A
Reunión inicial con el cliente
B
Revisar los datos del cliente
e
Introducir datos en la computadora
D
Revisa r resultados iniciales
E F
Revisar si faltó alguna form a
G
Revisión final y reunión con el cliente
Revisar códigos de impuestos rel eva ntes
Predecesor( es) inmediato(s)
Duración (horas)
Persona(s) responsable(s)
(Inicio de) A
3.0 3.0 2.0
Contado r joven Contador joven
3.0 2.0
Pete Contador joven
D
1.5
Contador joven
E, F
2.0
Pete
B A,C D
Pete
EPÍLOGO
Igual que en todos los esfuerzos administrativos, mucho de la administración de proyectos se basa e n hacer bien "los bloqueos y las tacleadas" elementales. La mayoría de los administradores de proyectos aseguran que una comunicación eficiente es la parte más importante para una administración de proyectos exitosa, y hay muchas evidencias que apoyan esta afirmación [como observa Brook (l995). 1a construcción de la torre de Babel se interrumpió cuando se introdujeron distintas lenguas]. Un examen de varios proyectos indica que cuatro elementos básicos son cruciales para terminar con éxito cualquier proyecto; los proyectos que carecen de uno o más de estos elementos, rara vez se consideran exitosos cuando (y si) term inan. Estos cuatro elementos son: •
Comunicación eficiente e ntre los interesados.
•
Fuerte compromiso de la alta administración.
•
Metas y objetivos bien definidos.
•
Un sistema de supervisión y control efectivo.
Es difícil decir cuál de estos elementos, si es que hay uno, es más importante que los otros. Tampoco son elementos ortogonales. Por ejemplo, un sistema de supervisión y control efectivo es parte integral de un buen sistema de com unicación. Meta y objetivos bien definidos no significa que nunca hay cambios en un proyecto, sino que se hacen dentro de límites bien definidos. En c uanto a proyectos de TI, el impacto negativo de metas imprecisas y un alcance que no se logra se ilustra con el caso del sistema de transacciones Medicar descrito al final del capítulo l. Los cuatro factores están directamente re lacionados con la administración del riesgo del proyecto y pueden considerarse parte de las acciones preventivas presentadas en el capítulo 7. Más aún, al reducir el riesgo del proyecto, se reduce la duración esperada del proyecto, como se vio en el capítulo 6, y se incrementa la posibilidad de cumplir con la fecha de ent rega del proyecto.
AUDITORÍAS POSPROYECTO Es raro que un proyecto se vea como un éxito o un fracaso rotundo. Como se observó en el capítu lo 1, aun cuando la película Titanic excedió significantemente su presupuesto y su programa planeado, se considera como uno de los proyectos cinematográficos de mayor éxito jamás realizados. Una auditoría posproyecto permite aprender qué funcionó (y qué no) en un proyecto y, lo más importante, transferir este aprendizaje a proyectos fULuros. Todos los interesados deben estar involucrados en la auditoría posproyecto, incluso los admi nistradores que pueden no haber sido parte del equipo de proyecto. Es importante documentar con cuidado todos los hallazgos, ya que los resultados de los proyectos, con frecuencia, se ignoran o se olvidan. Los participantes en la auditoría posproyecto deben considerar muchos factores que incluyen: •
Una revisión del plan de proyecto y una comparac ión del pla n con los resultados reales.
•
Revisión de las acciones para mitigar los riesgos y de los resultados reales.
•
Qué partes del proyecto se consideraron éxitos (y por qué).
225
226
EPILOGO
•
Qué partes del proyecto se consideraron fracasos (y por qué).
•
Cómo pudo haberse mejorado el proyecto.
Después de una auditoría posproyecto es útil para el equipo de proyecto (o para quie nes rea lizan la auditoría) reunirse con los adminisLradores de proyecto involucrados en proyectos similares. y con c ualquiera que pueda beneficiarse de lo aprendido. Las audiLOrías posproyecto deben ser vistas como eventos proactivos que pueden mejorar futuras tareas de admi nisLración de proyectos y ayudar a identificar nuevas oportunidades y mercados. Sólo de~ manera una organización y su gente conti nuarán ampliando sus conocimie ntos y mejorando sus procesos y posiciones.
APÉNDICE
PROYECTO DE UN RADAR MARINO PORTÁTIL COMO COPILOTO UN ESTUDIO INTERACTNO DISEÑADO PARA ILUSTRAR LOS PRINCIPIOS INVOLUCRADOS EN EL DESARROLLO, PRUEBA Y COMERCIALIZACIÓN DE UN NUEVO PRODUCTO EN UN ENTORNO DE ALTA TECNOLOGÍA *
ANTECEDENTES La doctora Page Turner, una joven y ambiciosa ingeniera que acaba de terminar su doctorado en ingeniería eléctrica en la Universidad de Washington, ha sido durante mucho tiempo una entusiasta de navegar y velear. Con frecuencia ha deseado una unidad de radar pequeña, compacta y económica que pueda usar por la noche o con mal tiempo cuando se dificulta identificar otras embarcaciones o las ayudas de navegación. Moti vada por su experiencia en el veleo, ella y algunos colegas han construido, durante los últimos tres años, varios prototipos de pequeñas unidades de radar de bolsillo, a las que han llamado radar marino copiloto. Dos de sus diseños se presentan en este apéndice. Sin embargo, ellos reconocen que todavía hay mucho trabajo por hacer antes de que el diseño de este radar pueda quedar terminado y la unidad pueda fabricarse y venderse. Por medio de Internet y organizaciones profesionales, la doctora Turner se ha informado de que otras empresas también están desarrollando unidades similares de radar. Por esto, ella y sus colegas desean terminar el diseño y lanzar una unidad al mercado tan pronto como sea posible. Para desarrollar con éxito el radar marino portátil, la doctora Turner ha formado un equipo de proyecto en el que ha incluido a varios maestros en administración (MBA) de la Universidad de Washington. Estos MBA que han renunciado a prometedores empleos en punto-coms locales a cambio de una participación en el proyecto, han realizado la estructura desglosada del trabajo (EDT) y han identificado una serie de actividades que deberán terminar para lanzar con éxito el peq ueño radar al mercado. Estas tareas (que incluyen contratar ingenieros calificados, programadores y técnicos, adquirir un espacio de laboratorio, obtener financiamiento, entre otras) se enumeran y describen en la "hoja de requerimientos de actividades"; la relación de precedencia entre estas actividades se índica en la red AON de la figura A. l.
MANO DE OBRA Cada empresa tiene que contratar técnicos, programadores e ingenieros de diseño para desarrollar con éxito la nueva unidad de radar marino de bolsillo. El tiempo esperado para terminar muchas de estas actividades de I&D está determinado por el número de empleados en la nómina. Una vez que *Desarrollado con J. Christopher Sandvig.
227
226
EPILOGO
•
Qué partes del proyecto se consideraron fracasos (y por qué).
•
Cómo pudo haberse mejorado el proyecto.
Después de una auditoría posproyecto es útil para el equipo de proyecto (o para quie nes rea lizan la auditoría) reunirse con los adminisLradores de proyecto involucrados en proyectos similares. y con c ualquiera que pueda beneficiarse de lo aprendido. Las audiLOrías posproyecto deben ser vistas como eventos proactivos que pueden mejorar futuras tareas de admi nisLración de proyectos y ayudar a identificar nuevas oportunidades y mercados. Sólo de~ manera una organización y su gente conti nuarán ampliando sus conocimie ntos y mejorando sus procesos y posiciones.
N N 00
,
)>
m.
z
o
¡:; m
,
:Il
Q m ()
b
o e
~------ - -----------,
m
1
z
1
Rentar espacio de oficinas/ producción
:Il )>
Programación
~
:Il
~
INICIO DEL PROYECTO
)> :Il
z
Adecuar
l
l
~ l es~a~io de
of1crnasl producción
__..__.
Armar unidad prototipo
,oo
Establecer instalación de producción
Prueba beta de prototipo
, ,......,
:Il -i )>· -i
FIN DEL PROYECTO
=
¡:: ()
o
~
o ,o
()
Comunicado de prensa
¡::
~
Obtener aprobación del gobierno "1( / /
/
\
l _________ ____ _
\
1 1
\
.o¡
'
' ' '.... . .
FIGURA A. 1
Red del proyecto
Obturttu cmtlflouclón
.... _ _ _
"
•...
""
_ _ _ _ _ _ _ _ ..... r
:
. " .. .
. ...
MANO DE OBRA
229
cada empresa haya desarrollado con éxito un pequeño radar marino, deberá contratar a los trabajadores para la línea de ensamble.
Técnicos Hay un número ilimitado de técnicos disponibles. Los técnicos ganan $2 000 por semana; hay una cuota única de $500 al contratar a cada técnico. En cualquier momento pueden contratarse técnicos de otros equipos si están de acuerdo; en este caso no hay cuota de contratación a menos que se negocie como parte de la transferencia. Si se despide a un técnico, se le pagarán tres semanas de indemnización.
Programadores Hay un número ilimitado de programadores disponibles. Hay una cuota única de $750 al contratar a cada programador. En cualquier momento se pueden contratar programadores de otro equipo, con su consentimiento; en este caso no hay cuota de contratación a menos que se negocie como parte de la transferencia. Si se despide a un programador se le pagará una indemnización de 4 semanas. Los programadores ganan S2 000 por semana más prestaciones (Pepsi y Twinkies ilimitados).
Trabajado r es de la línea de ensamble Hay un número i)jmitado de trabajadores para la línea de ensamble en el mercado. Los trabajadores de la línea de ensamblado pueden producir un máximo de quince unidades por semana y ganan $1 000 por semana; hay una cuota única de $500 al contratar a cada trabajador de la línea de ensamble y una cuota de $750 por cada trabajador despedido. Estos trabajadores necesitan dos semanas de capacitación antes de empezar a trabajar en la línea de producción.
Ingenieros de diseño Los ingenieros de diseño actualmen te ganan un mínimo de $4 000 por semana. En el mercado local existe un total de cinco ingenieros de diseño con los conocimientos necesarios. ¿Cómo se puede contratar un ingeniero de diseño? Si un ingeniero de diseño está disponible ahora (es decir, desempleado), aceptará su oferta enseguida y se unirá a la empresa por el salario actual del mercado ($4 000 por semana). Si no hay ingenieros de diseño desempleados, podrá contratar uno de otra empresa ofreciéndole un salario más alto. Sin embargo, esa empresa tiene la opción de igualar su oferta; si la iguala, el ingeniero de diseño permanecerá en su empleo actual con el (nuevo) salario más alto. Bajo ninguna circunstancia puede un equipo reducir el salario de un ingeniero de diseño una vez que se encuentra en la nómina. Cada equipo puede hacer, a lo más, una oferta de contratación por semana para un ingeniero de diseño y cada oferta ocasiona un pago de $5 000 a una empresa de búsqueda de ejecutivos. Si se contrata un ingeniero de una empresa que tiene más de un ingeniero de diseño en nómina, se supone que se transfiere a la nueva empresa el
FIGURA A.2 Cronología para el copiloto
Decisiones de contratación/despido
Ocurren actividades
Informe de resu ltados de la semana
1
1
Fin de la semana
Inicio de la semana Semana t
230
APÉNDICE
PROYECTO DE UN RADAR MARINO PORTÁTIL COMO COPILOTO
ingeniero con salario más bajo. Cuando se contrata un ingeniero de di eño, se agrega de inmediato a la nómina. Una vez que un equipo empieza la tarea de "diseño electrónico y de circuitos", sus ingenieros de diseño (máximo do ) no pueden ser despedido mienuas el diseño esté en proceso. Se pueden desped ir en otro momento con un pago igual a cuaLrO !>emanas de salario como indemnización.
FINAN ZAS Cada eq uipo debe mantener un balance positivo de efectivo para poder pagar sus gastos semanales. Puede aumentar su capital tomando un préstamo a largo plazo con una tasa de interés relativamente baja antes de iniciar el proyecto. No necesitará pagar int~ durante el desarrollo, pero el banco pide $1.25 por cada dólar prestado al pagar el préstamo al fi..r:u.: del juego. El equipo de proyecto puede también pedir un préstamo de emergmcia. en cualquier momento, según necesite efectivo. Estos préstamos tiene tasas de interés relamamente altas (2% semanal) y los intereses se pagan cada semana, empezando en la semana en la que se rec1be el dinero. Los préstamos de emergencia se dan sólo en incrementos de $50 000 con pagos de mtereses semanales de S I 000 por cada $50 000 recibidos. Los intereses se pagan por semana hasta que se cubre el principal empleando las ganancias del producto (el principal se puede pagar en cualquier momento. pero los intereses continúan acumulándose sobre saldos no pagados).
EL JUEGO El tablero El juego se juega en un tablero con una red de precedencias proporcionada por el profesor. Se usa la notación AON; es decir, cada nodo del diagrama representa una actividad. Los requerimientos para realizar cada actividad se presentan en la hoja de requerimientos de la actividad. Siguiendo las suposiciones estándar en la administración de proyectos, una actividad no puede iniciar hasta que todas sus predecesoras hayan terminado.
Supervisión del juego Cada equipo lleva una hoja de saldo de efectivo para dar seguimiento a sus saldos y gastos semanales en salarios, renta, intereses, etcétera. Cada equipo lleva también un calendario donde señala cuándo realizará act ividades futuras (cuando esa informaci ón esté disponible).
Inicio del juego Antes de empezar el proyecto, cada equipo lanza dos dados con objeto de determinar el orden que seguirán los equipos al tratar de contratar ingenieros de diseño. El equipo que obtenga la suma más alta procederá siempre primero, seguido por los otros equipos en secuencia numérica (si el equipo #3 obtiene la suma más alta con Jos dados, entonces -si hay cinco equipos- la sucesión será, equipos # 3, 4, 5, 1, 2).
Financiamiento para el proyecto (préstamo a largo plazo) Antes de empezar el juego, cada equipo puede obtener un préstamo a largo plazo del Warranty Trust Bank. Toda cantidad obtenida como préstamo debe pagarse al li na! del j uego junto con un
El JUEGO
231
pago de intereses igual a 25% de la suma obtenida. Hay también una cu01a de 1% que se paga "adelantado" cuando se obtiene el préstamo.
Para jugar el juego Una semana representa un tumo en el juego. Al principio de cada semana (después de negociar un préstamo a largo plazo), cada equipo toma sus decisiones de contratación y de despido (incluyendo un ingeniero de diseño) y después procede con las tareas factibles. Al final de la semana, cada equipo informa su estado actual. Un equipo puede iniciar cualquier actividad si todas las actividades predecesoras están terminadas. Al terminar una actividad, cada equipo la marca como 'terminada' con un punto coloreado. Toda información relevante se anota en el calendario y en la hoja de balance de cada equipo.
Fusiones y adquisiciones En cualquier momento, dos o más equipos pueden acordar una fusión. Si lo hacen, el nuevo equipo (fusionado) adquiere la deuda conjunta, de los dos equipos, hasta el momento de la fusión; a partir de ese momento, operan como un solo equipo. Se supone que el nuevo equipo (fusionado) ha terminado todas las tareas completadas por alguno de los dos equipos. Si un equi po compra a otro, el eq uipo que compra asume tanto las deudas del equi po comprado como el costo de la compra. Con respecto a las características de diseño de la unidad de radar de un equipo, cualquier unidad que tenga un número diferente de características se considera un nuevo producto, aunque el tiempo restante en el ciclo de desarrollo del equipo adquirido se reduce a la mitad. Por ejemplo, suponga que un equipo ha terminado con éxito el desarrollo de una unidad de radar sin características y ya tiene esa unidad en producción. Si ellos adquieren un equipo que está desarrollando una unidad de radar con, digamos, cinco características, el nuevo equipo (fusionado) no puede vender la unidad de radar más avanzada hasta que haya sido desarrollada con éxito, probada en el mercado, etcétera. En este caso, el tiempo para termi nar cada paso del proceso de desarrollo se calcula de la manera normal, y después se reduce por un factor de un medio.
Licencias de tecnología En cualquier momento, un equipo que ha desarrollado con éxito una unidad de radar marino puede vender a otro equipo una licencia para usar su desarrollo tecnológico. El equipo que compra esta tecnología vende el producto exactamente de la misma manera que si ellos lo hubieran desarrollado. El pago por la licencia puede ser en una sola presentación o se puede negociar con base en regalías (es decir, parte del precio de venta es para la empresa que vendió la licencia). Los equipos pueden negociar acuerdos especiales.
Terminación del juego El juego tennina cuando todos los equipos han iniciado la producción comercial de la nueva unidad de radar o salen del mercado (es decir, quiebran) y el último equipo en entrar al mercado lleva ya tres semanas de ventas. El primer equipo que entra al mercado recibe un bono de $750 000 por acuerdos de licencias para el extranjero, el segundo equipo recibe $500 000 y el tercero $250 000. (Otros equipos no reciben pagos por licencias en el extranjero.) Cuando termina el j uego, cada equipo debe calcular su demanda semanal promedio durante las últimas tres semanas del juego y suponer que esta demanda continuará un año más (cincuenta y dos semanas). Al final del periodo de un año, la vida efectiva de la unidad de radar marino termina ya
232
APENDICE
PROYECTO DE UN RADAR MARINO PORTÁTIL COMO COPILOTO
que lo superan nuevas tecnologías. Las ganancias semanales en las 52 semanas se calculan como stgue: [(Demanda prom. en últimas 3 semanas) x (precio de venta)] - [rentas/salarios/gastos semanales] Después de pagar los préstamos e intereses, el equipo que obtenga las mayores ganancias gana el juego, el eq uipo que sigue en ganancias obtiene el segundo lugar. etcétera.
HOJA DE REQUERIMIENTOS PARA LAS ACTIVIDADES Rentar espacio oficinas/producción Tan pronto como obtenga su préstamo a largo plazo, debe rentar un lugar para sus o ficinas, I&D y producción. Su agente inmobiliario, el señor Holly Park, ha identificado dos lugares posibles. El primero estará disponible la emana próxima, renta $2 500/semana} requjere un depósito no reembolsable de $30 000. El segundo. cuesta $1 000/semana (sin depósito): pero hay cierta incertidumbre sobre cuándo estará disponible, ya que en este momento se encuentra ocupado. Si elige el segundo lugar, lance un dado una vez por semana hasta que obtenga un 3 o menos; cuando tenga éxito, el lugar estará disponible de inmediato.
Ordenar equipo de laboratorio Puede comprar equipo de laboratorio a cualquiera de dos distribuidores: Slickquick y Pcnnycrawl. Pennycrawl ofrece un buen surtido de quipo, todo lo que usted necesita por sólo $125 000, pero el tiempo de entrega puede ser errático. Slickquick, por otro lado, garantiza una entrega a tiempo, pero cobra $200 000 por el mismo equipo. El equipo no se puede entregar hasta que se tenga un espacio. El pago se hace al recibir el equipo. Si usted elige Pennycrawl, lance un dado hasta que obtenga un 2 o menos (cuando tenga éxito, Pennycrawl entregará el equipo en una semana). Si escoge Slickquick, recibirá el equipo justo en cuatro semanas. Elija un distribuidor y pague la cantidad adecuada. Si elige Slickquick, se supone que el contrato con ellos no se puede cancelar una vez firmado. Sin embargo, si elige a Pennycrawl y no logra obtener 2 o menos en alguna semana, tiene la opción de cambiar de distribuidor la semana siguiente. (Por ejemplo, si no logra obtener 2 o menos en la semana #4, entonces no puede firmar un contrato con Slickquick hasta la semana #5. Recibirá el equipo al inicio de la semana #9.)
Comunicados de prensa Una vez obtenido el préstamo a largo plazo, usted da una conferencia de prensa para dar a conocer el trabajo de su equipo en el desarrollo de una unidad de radar marino portátil. Du rante la conferencia surgen algunas preguntas no muy agradables respecto a negocios anteriores de los miembros de su equipo. Lance un dado para determinar si los periódicos locales tomarán una posición positiva o negativa respecto a su proyecto. Si obtiene 2 o menos, los periódicos presentarán un artículo negativo y usted tendrá que contratar una empresa de relaciones públicas (con costo de $20 000) para contrarrestar la mala publicidad. Si tiene mala publicidad, tomará tres semanas realizar una campaña en los medios para contrarrestarla. De otra manera el comunicado de prensa termina en una semana.
HOJA DE REQUERIMIENTOS PARA LAS ACTIVIDADES
233
Preparación de espacio de oficinas/producción Una vez que se renta el espacio de oficinas y producción y se recibe el equipo, toma una semana preparar las instalaciones ames de empezar el trabajo de diseño.
Diseño de unidad es f ísicas Los ingenieros mecánicos que trabajan en el diseño físico indican que el tiempo de diseño es muy sensible al número de técnicos. Lance un dado. Si el número obtenido e menor o igual al número de técnicos en su nóllllll3.. u tarea de diseño será terminada en una semana. Los técnicos deberán permanecer e n la nómim por el resto de esta tarea. Si el número obtenido es mayor que el número de técnicos en su nómina. asted tendrá que repetir el proceso la semana próxima; continúe probando cada semana basl3 Je el diseño tenga éxito.
Diseño de pa rtes e l e ctrónicas y circuitos El tiempo necesario p:!f3 el diseño electrónico está determinado por dos fac tores: el número de ingenieros de diseño en la nómina y el número de características elegidas para la unidad de radar. Hay cinco caract.eriso~ pos1bles: 1.
Adzplador integrado para CA de 11 O V
2.
lnterlas.e GPS (sistema de posicionamiento global)
3.
Opción de rango variable
4.
Opción de espera de bajo pode r
5.
Alarma de rona de anclaje
El tiempo necesario para el di eño electrónico está dado por la ecuación siguiente:
1) 1 . = [ .(D :.__..:)(. . :.F._+___:. T1empo N+1 donde
=
D número aleatorio lanzando un dado F = número de características e legido N = número de ingenieros de diseño en el equipo (O < N
~2)
con [x] definido como el menor entero mayor o igual que x. Por ejemplo, si elige cuatro atributos (F = 4), obtiene 3 al lanzar e l dado (D =3), y tiene un ingeniero de diseño e n su equipo (N = 1), entonces
Tiempo
5
= [(3)~:: l) 1= [(3~ ) 1= [7.5]= 8 semanas
Observe que esta función no estará completa hasta que haya por lo men os un ingeniero de di seño en su equipo, y que tener más de d os ingenieros de di seño no produce beneficios adic ionales.
234
APÉNDICE
PROYECTO DE UN RADAR MARINO PORTÁTIL COMO COPILOTO
Programación La programación es una pane imponante del diseño de la un idad de radar, ya que el software determjna la operación. Una vez que el diseño electrónico está terminado. puede iniciar la programación. Las instrucciones de programa ión. una vez escritas y totalmente probadas, se colocan en chips de memoria ROM (Read-Onl) ~1emory) que forma pane de la unidad de radar. Para determinar la duración de estas tareas, lance dos dados. Si la suma es menor o igual que el número de programadores en su equipo, entonces terminará con éxito las tareas de programación esta semana. Si no, deberá lanzar el dado una vez más la semana próxima y conñr:.uar así hasta que tenga éxito.
Ensamble de la unidad prototipo Cuando terminan la programación y el diseño de la unidad física puede ensamblar una unidad prototipo. Lance un dado, divida entre do el número que obtenga y redondee hacia arriba al entero más cercano para deterrnjnar el número de semanas necesarias para temúnar esta tarea. Se necesita el mismo número de técnicos para terminar esta tarea que para el diseño de la unidad física.
Prueba beta del prototipo Ahora el prototipo del radar copiloto está sujeto a pruebas de campo y de laboratorio donde se prueba la unidad con diversas condiciones externas (clima. uso, etcétera). Esta tarea necesita tres semanas y se requiere el rrusmo número de técnicos que ensamblar la unidad prototipo. Al final de la prueba beta, usted sabrá si el prototipo no pasa la prueba y si se deben rediseñar algunas partes de la unidad. Para determinar si el prototipo no pasa la prueba, lance dos dados; la suma se usa para determinar los siguientes resultados: # en l os dados
Resultado
2
Falla mecánica y electrónica; debe reg resarse a estas dos funciones
3 4
Falla electrónica; debe regresarse al "diseño electrónico y de circuitos·
5o más
Fa lla mecánica; debe regresarse al "diseño de la unidad física" El prototipo pasa la prueba beta
Prueba de mercado Una vez terminada con éxito la prueba beta, la unidad de radar copiloto puede probarse en el mercado. Esta tarea incluye usar grupos focales y campañas limitadas de publicidad en unas cuantas ciudades seleccionadas. Lance dos dados. Si la suma es doce, la unidad no pasa la prueba de mercado y prácticamente no hay demanda de la unidad de radar copiloto marino; en este caso el juego termina para su equipo. El número de semanas necesario para la prueba de mercado está determinado por el menor número en los dos dados (si se obtiene 4 y 6, la tarea de prueba de mercado termi nará e n 4 semanas).
Preparación de la instalación de producción Cuando termina la prueba de mercado, deben prepararse las instalaciones de producción. Se debe comprar el equipo de producción, que es caro y temperamental. Las opciones son: comprar el equipo de alta calidad en $200 000 y proceder hasta obtener 4 o menos en un dado, o comprar el equipo de la "Línea Econ" en $ 100 000 y proceder hasta obtener 2 o menos en un dado. Siga intentando un
HOJA DE REQUERIMIENTOS PARA LAS ACTIVIDADES
235
lanzamiento por semana, hasta que obtenga el equipo adecuado. Sólo necesita comprar eq uipo una vez.
Aprobaciones del gobierno Una vez terminadas las pruebas de mercado, deberá contratar abogados para negociar con la Comisión Federal de Comunicación la aprobación de la unidad de radar (no puede vender la unidad de radar hasta obtener la aprobación del gobierno). Puede elegir entre abogados con experiencia que cobran $25 000, o con poca experiencia que cobran $ 1O 000. Los abogados con experiencia obtienen la aprobación cuando obtenga 4 o menos en el dado, y los de poca experiencia cuando obtenga 2 o menos. Si no obtiene la aprobación, inténtelo de nuevo la semana próxima. Cada vez que lo intenta debe pagarle a su abogado.
Obtención de la certificación Tal vez desee tener una certificación para el radar marino antes de colocarlo en el mert:ado. Para determinar si obtiene la certificación, elija un número entre O y 6; multiplíquelo por $5 000 para determinar el costo de la solicitud de certificación. Lance un dado. Si el número obtenido es menor o igual que el número que eligió, obtendrá la certificación. (Si escogió el 6, no es necesario lanLar el dado, ya que automáticamente obtendrá la aprobación; si escogió O, no es necesario lanzar el dado, pues es obvio que decidió olvidarse de la certificación). Si no tiene la certificación deberá reducir el precio $50 por unidad. Si usted solicita la certificación, el proceso tomará una semana. Si decide no solicitarla, no se requiere tiempo para esta actividad y puede ser ignorada.
Producción y ventas Una vez que prepara las instalaciones de producción, contrata a los trabajadores de la línea de ensamble y obtiene la certificación (opcional), ya puede empezar a producir y vender unidades de radar. Recuerde que cada trabajador de la línea de ensamble puede producir un máximo de 15 unidades por semana y que se necesitan dos semanas para capacitar a un nuevo trabajador antes de que pueda integrarse en la lfnea de producción. Los trabajadores de la línea de ensamble se pueden contratar o despedir al principio de cada semana mientras se juegue el juego.
Precio de venta El precio de mercado de su unidad de radar es un a función del número de competidores en el mercado (independientemente del diseño de sus unidades) y del número de características de su unidad. La tabla siguiente determina el precio de venta: Número total de empresas que venden unidades de radar marino portátil
2
No. de características
o 1 2 3 4 S
$1 000 1 12S 1 250 1 37S 1 500 1 625
$
8SO 97S 1 100 1 22S 1 350 1 475
4
3
$
700 82S 950 1 07S 1 200 1 325
Recuerde restar $50 por unidad si no tiene la certificación
$
S50 67S 800 925 1 oso 1 175
5 $
400 S2S 650 775 900 1 025
236
APÉNDICE
PROYECTO DE UN RADAR MARINO PORTÁTIL COM O COPILOTO
Dem anda del mercado Para determinar la demanda semanal del mercado, cada equipo lira dos dados y divide la suma entre el número de empresas (incluyendo la suya) que venden unidades de radar marino pon áúl. Tome el número resultante y multiplíquelo por 20; redondee hacia arriba, al entero más cercano. (Por ejemplo, si obtiene un "8" con lo dados y hay tres empresas en el mercado, entonces la demanda esta semana es 54 unidades). En general, Ventas semanales = mínimo(demanda del mercado, capacidad de producción) donde la capacidad de producción e determina por el número de trabajadores de línea de ensamble en su nómina. Mul tiplique las ventas semanales por el precio de \enta para determ inar los ingresos semanales.
" IND/CE
A Acción de contingencia, 166 Acción preventiva, 166 Acelerar un proyecto, 107 Actividades en arcos (AOA), 182 Administración de proyectos, 1-21, 135 administración de cambios, 63 aplicación de teoría de restricciones, 149-152 estructura organi zacional, 72-76 historia de, 17- 18 interés por, 1 regla 6P, 13 Administración de recursos, 175-202 Administración de riesgo, 16-17, 165-174 caso de estudio, 170-173 portafolio balanceado, 165 subcontratación, 165 Administración del financiamiento de atención a la salud, transacciones de Medicare, 19-2 1 Administrador de proyectos, papel y responsabilidades, 62-72 Aeropuerto Internacional de Denver, 2 Agrupar, 79-80 Alcance del sistema, 5 Algoritmos basados en tareas, 188 basados en tiempo, 188-1 89 de optimización. 18 1 de ramificación y acotanuento, 194 de una sola pasada, 185 heurísticos para la asignación de recursos renovables, 187-189 Alianzas, 80 Amortiguador de alimentación, 150, 193 de recursos, 150, 193 Análisis de impacto, 170 Árbol genealógico, 43 Artemis Schedule Publisher, 194
Asignación de recursos cadena crítica, 192-193 capacidades del software comercial para, 193- 195 en un entorno de proyectos múltiples, 221 -223
B BC Hidro, 2
e CA Super-Proyect, 194 Cadena crítica, 150, 192 asignación de recursos, 192-1 93 Cambio de administración, l . Vea también Administración de proyectos administración de proyecto y, 63 Cambio de órdenes, 78 Cambio del producto, 6 Catalytic Construction Company, 17 Ciclo de vida de un proyecto, 12- 13 Ciclos de vida del producto, 1 Ciclos en redes de precedencias, 146-149 Cohesión y hostilidad del grupo, equilibrio entre, 66-67 Compañía constructora Van Allen, 169 Complejidad del proyecro, 5 Complejidad en la clasificación de proyectos, 5 Complemento para hojas de cálculo, 167 Comportamiento de trabajadores y duración esperada del proyecto, 153-1 55 Compresión del proyecto, 115-126, 221 con duraciones inciertas de tareas, 156- 157 Comunicación dentro del equipo, 68 resultado del proyecto, 9 trueques tiempo-costo, 125- 126 Comunicación dentro del equipo, relación con tamaño, 67
237
238
iNDICE
Contrato con beneficios, 77, 78, 168 Contrato de precio fijo, 77, 168-1 69 riesgos, 165 Contrato(s) costo con beneficios, 77, 78, 168 de alcance opcional, 15 gestión, 77 li neal, 77 por unidad, 77 con precio fijo, 77, 165, 168- 169 riesgo relativo y tipo de, 168- 170 Control estadístico de procesos (SPC), 206 Coordinación dentro del proyecto, 73 Costo presupuestado del trabajo desempeñado (CPTD), 208 Costo presupuestado del trabajo programado (CPTP), 208 Costo real del trabajo desempeñado (CRTD), 207-208 Costo(s) de inventario, 126-128 de mano de obra, 109 de material, 109, 126-128 directo, 108-109 estándar, 109 generales, 109 indirecto, 109 plan para mi ni mizar, 107-129 Costos basados en actividades (ABC, consideraciones en el presupuesto), 109 Costos de mano de obra, estimación, 108-109 Costos de materiales, 126-128 en el presupuesto, 108 Costos de penalización/bonos en el presupuesto, 108 Costos directos, consideración en el presupuesto, 108- 109 Costos generales en el presupuesto, 108, 109 Costos indirectos en el proyecto, consideración de, 108-109 Cristóbal Colón l nc., 59-61 Crystal Ball, 168 Cuestionarios para evaluar características intern as del eq uipo, 66
D Desarrollo de nuevos productos, 1 ciclos en redes de precedencias, 146-149 Descuentos por cantidad, 78 Desempeño de un proyecto comparación con la estructura organizacional, 74-75 equilibrio entre excelencia técnica y, 74
relación con el tamaño del grupo, 67 Diagrama de componentes, -B Diagrama de sensibilidad. 167-168 Diagrama de tomado. 166-167 Diagramas de Ganu. 1 . 95-97, 184, 21 O u ando MS-ExceL 103 Diseño efectivo de sistemas de supervisión, 205-207 Di ney, 3 Distribución beta, 49. 52. 135- 136, 139 Disu·ibución de probabilidad discreta, simulación Monte Cario, l-t5-146 Diversificación de proyecto . 38 DuPont Corporation, 17 Duración esperada de la tarea, 136 Duración esperada del proyecto, comportamiento de los trabajadores, 153- 155 variac ión de la tarea, 155- 156 Duración incierta de una tarea, compresión de un proyecto con, 156- 157 Duración mínima de una tarea tomada del proyecto más corto restante, 222 Duraciones aleatorias de tareas, problema de asignación de recursos, 198-202
E Ejecución, 87 El coloso de Rodas, 17 Enfoque de enrejado, 219 Enfoque de filtro-etapa, 33-34 Enfoque de opciones reales, 33-34 Entorno de control parcial, 22 1 completo, 221 Entorno dinámico de proyectos múltiples, asignación de recursos y fechas de entrega, 221 Equipos. Vea también Equipos de proyecto dentro del, 66 diseño-construcción , 78 Eq uipos de proyecto características de equipos efectivos, 67-68 diversidad, 68-69 fonnación, 70-71 incentivos, 69, 220-21 multifuncionales, 3-4 papel y responsabilidades, 62-72 relación entre comunicación interna y tamaño, 67 Escala exponencial, 35 Estilos de administración de conflictos, relación entre éxito y fracaso de un proyecto, 64 Estimación a la tenninación (EAT), 214
ÍNDICE
Estimaciones actualización de costo y programa, 2 13-21 4 de costos y duraciones de tareas, 46-48 Estructura desglosada del proyecto (EDP), 43 n Estructura desglosada del trabajo (EDT), 188 al definir tareas o paquetes de trabajo, 23, 83 en la planeación del proyecto, 43-46 tareas, 108 Estructura organizacional comparación con desempeño del proyecto, 74-75 y admi nistración de proyectos, 72-76 Etapas del ciclo de vida, 43 Evaluación del riesgo, 170 Evaluación del portafolio de proyectos, 37-41 Excelencia técnica, equilibrio entre desempeño del proyecto y, 74
F Fechas de entrega en entornos de proyectos múltiples, 221-223 Flujo de efectivo descontado (FED), 26-27 Flujo descontado deterministico, 26-27 Flujos de efectivo administración, 112- 11S relación entre tarea programada y, 115 Fórmula de Black-Scholes, 33 Formulac ión de programación lineal, 93-95 Formulación de programación matemática para redes de actividades en arcos, 99- 100 Fraccionar, 79-80 Fractiles, 52-53
239
1 ldenti ficación del riesgo, 170 Incentivos de contrato, 169 Incentivos, equipos de proyecto, 69, 220-22 1 1ncertidumbre al clasificar proyectos, S en el presupuesto, 109- 11O en el proyecto, implicaciones, 152-156 exógenas, fuentes, 165 manejo de, 48-53 planeación con, 135-1 58 presupuesto, 109- 11 O Indicador de tipo Myers-Briggs, 68 Índice crítico, 143, 157 Índice de costo (IC), 209 Índice de programa (IP), 209 Industria de la comunicación, regla 4-3-3, 1 Ingeniería concurrente, 70 Inicio y selección de un proyecto, 24-37 enfoque de calificación y clasificación, 34-37 enfoq ue de opciones reales, 33-34 medidas numéricas, 25-32 Interesados, papel del admin istrador de proyectos, 62-63 Intervalo de confianza, incertidumbres en el presupuesto, 109
L Ley de Brook, 125 Ley de Parkinson, 1SO, 153- 154 Líder por pérdidas, 107 Límite de aceleración, 115
G Generadores de números aleatorios, 167 Giza, pirámides egipcias de, 17
H Heurísticas en serie, 188 paralelas, 188- 189 Hipótesis nula, prueba de, 206 Holgura(s), 9 1-92 de seguridad, 92 independiente, 92 libre, 9 1-92 mínima basada en fec ha de entrega, 22 1 total, 9 1
M Manej o de la incertidumbre, 48-53 Matriz balanceada, 73, 76 de proyecto, 73, 76 fu ncional, 73 Medidas numéricas, 25-32 Meses-dólar, 114 criterio de minimización, 11 4-11 S relación entre valor presente neto y, 133- 134 Método de clasificación, 34-37 Método de la ruta crítica (CPM), 17, 18, 136 cálculos para redes de acti vidades en arcos, 97- 100 conceptos y cálculos, 86-95 Método del valor ganado. 207-2 13
240
INDICE
Microsoft Project, 194 Mi nimización del costo del proyecto, 107 Minimización del tiempo de ejecución de un proyecto. 107 Mi ión Mars Climate Orbiter, 11 Modelo de Black-Scholes, 38 Modelo de costo para evaluar y administrar riesgos. 171-173 Modelo de hoja de cálculo, 41 Modelo de programac ión lineal (PL), 113 para trueq ues tiempo-costo, 117- 12 1 Modelo PERT clásico, 144 defin ición, 13S- 143 limitaciones, 139-143 Modelos de madurez de administración de proyectos, 19 Modelos de simulación de Monte Cario, 16, 143-149, 168 con distribuciones de pro babilidad discreta , 145-146 Multa, 78
o Ofertas para licitació n, 78-79 Organ ización matricial, 72-74, 75 balanceada, 73, 76 funcional, 73 proyecto, 73, 76
p Perfi l de recursos, 178- 179 Pcrliles del horizonte, 178- 179 Periodo de recuperación, 2S PERT (Técnica de Revisión y Evaluación de Programas), 143 Plan de conú ngencia, 166 Plan de mitigación del riesgo, 170 Planeación con incertidumbre, 135- 158 Planeación de proyectos, 4 1-53 estimación de costos y duración de la tarea, 46-48 estructura desglosada del trabajo, 43-46 manejo de la incertidumbre, 48-53 Planeación de recursos empresariales (ERP), implantación de proyectos, 166 Planeación para minimizar costos, 107- 129 Portafolio balanceado en la administración de riesgo, 165
Presupuesto a la terminación (PAT), 21 O Presupuesto( S) costos basados en la acúvidad, 109 costo de penalización )/o bonificacio nes, 108 costos de materiales.. 108. 109 costos directos, 108-109 costos generales, 10 . 109 costos indirectos, 1O • 109 de abaj o arriba, 108. 11 O de arriba abaj o, 108 de proyecto, 108- 112 Primavera Project Planner, 19-t Primero en entrar. primero en salir, 221 Probabilidad de riesgo. 170 Problema de la asignación de recursos. J80-18S con tareas de duración aleatoria, 198-202 no renovables, 195-1 98 soluciones factibles para recursos renovables, 185- 187 Problema de asignación de recursos renovables algoritmos heurísticos, 187- 189 con solució n sencilla, 190-192 soluciones fac tibles, 185- 187 Problema de ni velación de recursos, 175-180 Problema para cubrir un conjunto, 7 1 Proceso de fabricación, modificación, 6 Proceso de programación hacia adelante, 188 hacia atrás, 188 Proceso programado basado en tarea versus tiempo, 187-188 Producto de simulación @ Risk, 146 Programa maestro de producción (MPS), 128 Programa Polaris Fleet Ballistic Missile, 17 Programación en pareja, 72 Programación extrema (XP), 72 Project Management Institute (PMI), 18 Project Management Workbench, 194 Project Scheduler, 194 Proyecto de aterrizaje en Marte, 7, 107 Proyecto(s) admi nistración de los riesgos, 16- 17 de alta tecnología, 5 de baja tecnología, 5 de ensamble, 5 de innovación, 6 de integración, S de plataforma, 6 de sistemas, S
ÍNDICE
de tecnología media, 5 definición, 3-6 derivados, 6 desarrollo de un nuevo producto, 173 diferencias en, 4-6 etapas, 23 herramientas para analizar riesgos, 166-68 innovadores, 6 medidas de éxito/fracaso, 7-12 múltiples, tareas múltiples con, 2 18-220 programación, 95-96 relación entre estilos de administración de conflicto y éxito o fracaso, 64 terminación, 11-12 vida, 3, 24 Proyectos de desarrollo de nuevos productos, riesgos, 173 Proyectos de l&D, fuentes de incertidumbre asociados con, 165-1 66 Proyectos múltiples, tareas múltiples con, 2 18-20 Prueba de intervalo múltiple de Scheffe, 222 Punto de activación, 166
R Ramificación probabilfstica, 148 Recursos doblemente restringidos, 181 Recursos no renovables, 181 problema de asignac ión, 195- 198 Recursos renovables, 180, 18 1 Redes de actividades en arcos (AOA), 84-85 cálculos para el método de la ruta crítica, 97-1 00 fom1Ulación de programación matemática, 99-100 Redes de precedencias actividades en arcos (AOA), 84-85 actividades en nodos, (AON), 84, 2 18 ciclos, 146-149 comparación de AOA con AON, 85-86 definición, 83-86 Regla 4-3-3 para industria de comunicación, 1 Regla 6P de administración de proyectos, 13 Regla de fecha de entrega en tiempo de terminación programado, 222 Regla de flujo medio para la fecha de entrega, 222 Regla de la ruta crítica, 222 Regla de plan de proyecto de costo total mínimo, 107 Regla del número de actividades, 222 Relaciones alternativas de precedencias, 104-106 relación inicio a inicio, 104- 105
relación terminación a terminación, 105-106 Restricciones, teoría de, 149-152 Riesgo relativo, tipos de contrato, 168- 170 Riesgo(s) comercial, 173 definición en proyectos, 165 endógenos, 165 relacionado con personal de desarrollo de productos, 173 técnicos, 173 Riesgos en proyectos de desarrollo de nuevos productos, 173 @Risk, 168 Ruta crítica, 87, 139- 140
S Sesgos de estimación, 150 Sistema de oferta competi tiva al elegir subcontratistas, 78 Sistema de planeación de recursos empresariales (ERP), S, 128 de requerimientos de materiales (MRP), 128-129 Sistemas de supervisión formal, 205 Sistemas de supervisión informal, 205 Sistemas PERT/costo, 207 Sociedades, 76-80 Software administración de proyectos, 9-10, 18, 108 comercial, capacidades para asignación de recursos, 193-1 95 Software Engineering lnstitute (SEI), 19 modelo de madurez de capacidad, 19 Soluciones factibles para el problema de asignación de recursos renovables, 185-187 Subcontratación, 76-80 en administración de riesgo, 165 Subcontratistas agrupar contra fraccionar, 79 sistema de licitación competitiva en la selección de, 78 Supervisión, enfoque del valor ganado. 207-213 Symington, Fife, 7
T Tabla de la distribución normal estándar, 163- 164 Taco Bell, 2
241
242
ÍNDICE
Tamaño del grupo, relación entre desempeño del proyecto y, 67 Tareas, 3 compresión de proyectos con duraciones inciertas. 156-157 duración esperada de, 136 estimación de costos y duraciones, 46-48 más corta del proyecto más corto, 221 orden fijo contra dinámico, 187 PERT y duración de, 48-49 problema de asignación de recursos con duraciones aleatorias, 198-202 relación entre flujo de efectivo y programación, 11 5 variabilidad de las duraciones, 155 variación en, y duración esperada del proyecto, 155-156 Tareas múltiples con proyectos múltiples, 21 8-2'20 Tasa crítica de rentabilidad. 26 Tasa de corte, 26 Tasa interna de retomo (TIR), 27 Técnica de Revisión y Evaluación de Programas (PERT), 17, 18, 135 duraciones de tarea~. 48-49 Tecnología de la infonnación (TI), proyectos, 1 éxito, 2 resultados, 10- 11 Teoría de amortiguador de un proyecto, 149-1 52 Teoría de cálculo de precios de opciones (OPT), 33 Teoría de restricciones (TOC), 192-193 Texas Instruments, 74 Tiempo mínimo de retraso en la terminación según la fecha de entrega, 221 Time Line, 194 Tipos de personalidad. diversidad en los equipos de proyecto, 68-69 Titanic (película), 7 Trueques en la admini tración de proyectos, 13-15
Trueques tiempo-costo, 115-126 con consideraciones de coordinación y comunicación, 125-126 cóncavo, 121-122 convexo, 121-122 discreto. 123-125 lineal, 117-121 no lineal, 12 1-123 problema, 107
V Valor comercial esperado (VCE), 27-32 Valor del dinero en el tiempo, 1 1'2 Valor ganado, 208 Valor planeado, 208 Valor presente neto (VPN), 26-27, 30, l 14 impacto del tlujo de efectivo. 112 relación con meses-dólar, 133-134 Valor presente neto (VPN) o flujo de efectivo descontado (FED), 24 Valores de ptioridad, 221 Valores positivos de z, 163- 164 Vaporware, 74 Variación en el gasto, 209 de tiempo, 2 1O total, 210
X Xerox Corporation, 74
z Z, valore. positivos, 163-164
Esta edición se 1enninó de imprimir en febrero de 2013. Publicada por
AJJFAOMEGA GRUPO EDITOR, S.A. de C.V. Pitagoras No. 1139 Col. Del Valle, BeniTo Juárez., C. P. 03311, México, D.F La impresión y encuadernación se realizó en CARGRAPHJCS, S.A. de C.V. Calle Auecas No.27 Col. Sama Cru: Acmlán, Nauca/pa11. Esw do de México, C. P. 53150. México
Contiene la versión estudiantil da Microsoft Pro)act 2002, el programa Risk complemento de éste, una presentación de Power-Point con más de 200 diaposHivas y plantillas de hoJas de dlculo para todos los modelos estudiados en el libro.
ISBN 970-15-1099-2
A
Alfaomega Grupo Editor
95
