administracion de proyectos Clifford F. Gray J ————— ae 0 td ae A Td)En primer lugar queremos agradecerle especialmente y expresarle nuestro aprecio a Diane Parente, quien preparé el caso ampliado SimProject que se incluye en el apéndice. Este caso comprende una serie de gjercicios que se han relacionado con los capitulos del libro. El SimProject afiade una di- ‘mension prictica y de experiencia concreta a esta obra. Es importante advertir que el texto incluye contribuciones de numerosos estudiantes, colegas, ‘amigos y gerentes, las cuales se extrajeron de conversaciones profesionales. Queremos que sepan {que apreciamos sinceramente su asesoria y sus sugerencias. Casi todos los ejercicios, casos y ejem- plos del texto se tomaron de un proyecto del mundo real. Les agradecemos especialmente a los ge- rentes que amablemente compartieron su proyecto actual para obtener de ahi ideas para ¢jercicios, ‘temas para casos y ejemplos para el texto, Shlomo Cohen, John A. Drexler, Jim Moran, John Sloan, Pat Taylor y John Wold, cuyo trabajo esta impreso, también merecen nuestro reconocimiento. ‘Nuestras gracias también a Robert Breitbarth de Interact Management, quien compartié valiosas perspectivas sobre la jerarquizacién de proyectos. Los estudiantes universitarios y los gerentes me- rocen que los mencionemos especialmente por haber identificado problemas en los borradores an- teriores del texto y de los gjercicios. Estamos en deuda con los revisores de la primera y de la segunda ediciones, quienes compartic- ron nuestro compromiso por clevar la ensefianza de la administracién de proyectos. Entre ellos se cuentan: Paul S. Allen, Rice University; Denis F. Cioffi, George Washington University; Joseph D. DeVoss, DeVry University; Edward J. Glantz. Pennsylvania State University; Michael Godfrey, University of Wisconsin-Oshkosh; Robert Key, University of Phoenix; Dennis Krumwiede, Idaho State University; Nicholas C. Petruzzi, University of Illinois -Urbana/Champaign; William R. She- rrard, San Diego State University;S. Narayan Bodapat, Southern Illinois University at Edwardsvi- lle; Warren J. Boe, University of Towa; Burton Dean, San Jose State university; Kwasi Amoako-Gyampah, University of North Carolina Greensboro; Owen P. Hall, Pepperdine U: sity; Bruce C. Hartman, University of Arizona; Richard Irving, York University; Robert T. Jones, DePaul University; Richard L. Lucbbe, Miami University of Ohio; William Moylan, Lawrence ‘Technological College of Business; Edward Pascal, University of Ottawa; James H. Patterson, In- diana University; Art. Rogers, City University; Christy Strbiak, US. Air Foroe Academy; David A. Vaughan, City University: Y Ronald W. Witzel, Keller Graduate School of Management. En la cuarta edicién continuaremos con nuestro compromiso de mejorar el contenido del texto y la instruccién de la administracién de proyectos. Estamos agradecidos con los revisores que nos proporcionaron iitiles opiniones y perspectivas respecto a la tercera edicién, las cuales nos ayuda-Planeaciin para contingencias 191 Transferencia del riesgo Escomiintransfriel riesgo a otra part; este traslado no cambia el riesgo. Hacerlo cas siempre resulta cen que se paga una prima por esta exencion. Los contratos de precio fijo son el ejemplo elisico de trans- ferir el riesgo de un propictario a un contratista. Este timo entiende que su empresa pagar cualquier evento de riesgo que se materialce; por lo tanto, se atade un factor de riesgo monetaro al precio de la licitacin. Antes de decidir la transferencia del riesgo, el propictario debe determinar qué partido puede controlar mejor las actividades, lo cual conduciria al riesgo. Ademis, :puede el contratista absorberlo? Es imperativo identificar y documentar la responsabilidad para la absorcién del riesgo. ‘Una manera mas obvia de transferir el riesgo es un seguro. Sin embargo, en general esto es poco prictico porque resulta dif y caro definr el evento de riesgo del proyecto esto lo condiciona a que un corredor de seguros, que no conoce el proyecto, lo haga. Por supuesto, es mas ficil dfinir y obtener un seguro para los eventos de riesgo de poca probabilidad y grandes consecuencias. Otros instrumen- tos financieros para trasladar riesgos son los bonos por desempefio y las garantias de diversos tipos. Distribucion del riesgo Al distribuirlo se asignan proporciones del riesgo a distintas partes. Un ejemplo de distribucién del riesgo se dio con el Airbus A340. Se repartieron riesgos para investigacién y desarrollo a paises ccuropeos como Gran Bretaiia y Francia. Por otro lado, la industria del entretenimiento formé un consorcio para definir un formato comiin de operacién para el disco de video digital (DVD, Digital Video Disk) a fin de garantizar la compatibilidad entre productos. Estiin surgiendo otras formas de Aistribuir riesgos. En proyectos de construccién internacionales grandes, como plantas petroquimicas y refinerias petroleras, los paises anfitriones inssten en que los contratos pongan en practica las provisiones para cconstruir-poscer-operar-transferir (BOOT, Build-Own-Operate-Transfer). Aqui se espera que la or- ‘ganizacién primaria del proyecto no s6lo construya las instalaciones, sino que también se convierta en propietaria hasta que se haya probado su capacidad de operacién y se haya dado todo el descifra- ‘iento de las operaciones, antes de la transferencia final de la propiedad al cliente. En tales casos, el is anfitrin y la empresa encargada del proyecto se ponen de acuerdo en compartir el riesgo finan- ciero de la propiedad hasta que se termine el proyecto y se comprueben las capacidades. ‘También se ha usado la distribucién del riesgo para reducir los costos de los proyectos y fomen- tara innovacién. La creacién de sociedades (véase capitulo 12) entre el propietario y los contratis- tas ha desencadenado el desarrollo de procedimientos de mejora continua para fomentar a los contratistas a que sugicran formas innovadoras para la puesta en prictica del proyecto. Quizé el ‘nuevo método implique costos adicionales para el inicio y el riesgo de que el nuevo proceso no fun- cione. En general, los costos del riesgo y los beneficios del proceso mejorado se comparten 50/50 centre el propietario y las empresas contratistas. Retencién del riesgo En algunos casos se toma una decisin de aceptar el riesgo de que ocurra un evento, Algunos res- gos son tan grandes que no es posible considerar una transferencia 0 una reduccién del evento (por jemplo, un terremoto o una inundacin, El propictario del proyecto asume el riesgo porque las probabilidades de que un evento asi se presente son escasas. En otros casos, los riesgos que se iden- fifican en la reserva del presupuesto pueden absorberse si se materializan. El riesgo se retiene al desarrollar un plan de contingencia para el momento en que el primero se realie. En algunos casos es posible ignorar un evento de riesgo y aceptar un excedente en los costs scl evento se presenta Mientras mayor esfuerzo se hagi para responder al riesgo antes de que el proyecto se inicie, mayo res seri ls posbilidades de minimizar sorpresas en el proyecto. AL saber que a respuesta un even- tose retendri,transferiri o compartir, se elimina mucho estrse incetidumbre cuando se presenta cl evento de riesgo. De nuevo, es posible mantener el contol con este enfoque estructurado. Planeacién para contingencias Un plan de contingencias es una alternativa que se utilizard si un evento de riesgo previsto y posibleBN EE 182 Capitulo? Administracin del riesgo del evento de riesgo. Como todos los planes, responde a los cuestionamientos de qué, dinde, cuan- do y cuinta accién se llevard a cabo. La falta de un plan de contingencia, cuando se presenta un cevento de riesgo, puede propiciar que un gerente retrase o posponga la decisién de poner en pricti- cca un remedio, Cuando lo hace puede producir pinico y la aceptacién de la primera componenda que se sugiera. Tomar una decision asi, posterior al evento y bajo presién, puede ser muy peligrosa y costosa. En la planeacién para contingencias se evalian soluciones alternas para eventos previs- tos antes de que se presenten y se escoge el mejor plan entre las opciones disponibles, Esta planea- cin temprana para contingencias facilita una transici6n facil a la soluci6n o al plan de trabajo en torno a la dificultad. Cuando se cuenta con un plan de contingencias aumentan mucho las proba- bilidades de que el proyecto tenga éxito. Es necesario decidir y documentar con claridad las situaciones en las que debe activarse el plan de contingencias. Esto debe incluir un estimado de costos ¢ identificar la fuente de financiamiento. ‘Todas las partes afectadas deben estar de acuerdo con él y tener la autoridad necesaria para hacer compromisos. Como la puesta en prictica de un plan de contingencias afecta en forma negativa la secuencia normal de las tareas a realizar, debe informarscle de su existencia y contenido a los inte- ¢grantes del equipo, de tal manera que las sorpresas y la resistencia sean minimas. He aqui un ejemplo: una empresa de computacién de alta tecnologia de nicho pretende introdu- cir un nuevo producto “plataforma” en una fecha designada muy especifica. Los 47 equipos que trabajan en el proyecto estiin de acuerdo en que los retrasos son inaceptables. Sus planes de contin- ¢gencia para dos grandes proveedores de componentes demuestran la seriedad con la que se manja a administracién de riesgos. Una dellas plantas proveedoras se ubica en la falla de San Andrés. El plan de contingencia prevé un proveedor alterno, a quien se le mantiene informado de manera constante, que produce una réplica del componente en otra planta. Otro proveedor con sede en ‘Toronto, Canada, implica riesgos en la entrega debido a un potencial mal clima. Este plan de con- tingencias exige contar con un avién charter (al que ya se ha contratado para que permanezca en espera), si la transportacién general presenta retrasos. Para los externos estos planes pueden pare- cer un poco extremos, pero en las industrias de alta tecnologia, donde el tiempo de comercializacion es el rey, los riesgos de eventos identificados se toman muy en serio. Las matrices de respuesta a los riesgos, como la que se muestra en la figura 7.8 son iitiles para resumir de qué manera el equipo del proyecto planea manejar los riesgos que se han identificado. De nuevo se utiliza el proyecto Windows Vista para ilustrar este tipo de matriz. Lo primero es iden- tificar si hay que reducir, compartir, transferir o aceptar el riesgo. El equipo decidié reducir las probabilidades de que el sistema se congele al experimentar con un prototipo del sistema. La expe- rimentacién con los prototipos no sélo les permite identificar y fijar “virus” de conversion antes de la instalacién real, sino que también produce informacién que podria ser dtil para aumentar la aceptacién de los usuarios finales. Entonces el equipo del proyecto podra identificar y documentar cambios entre el antiguo y el nuevo sistema, los cualles se incorporariin a la capacitacién que se da a los usuarios. El riesgo de un mal funcionamiento del equipo se transfiere cuando se elige un pro- veedor confiable con un programa de garantias sido. EI siguiente paso consiste en identificar planes de contingencia en caso de que aiin haya riesgo. Por ejemplo, si los problemas de la interfaz prueban no tener solucién, entonces el equipo debiera buscar cémo trabajar en otras cosas hasta que los expertos del proveedor Ileguen para solucionar el problema. Si el sistema se congela después de la instalacién, el equipo intentara primero reinstalar el software. Si el usuario esti muy insatisfecho, entonces el departamento de SI le proporcionarit ‘mis personal para que lo apoye. Si clequipo no puede obtener herramientas confiables del provee- dor original, colocara un pedido de una marca distinta con un segundo proveedor. El equipo tam- bién necesita analizar y estar de acuerdo en que “desataria” la ejecucién del plan de contingencias. En el caso de que el sistema se congel, el disparador no puede descongelarlo en una hora o, en el caso de un reclamo violento del usuario, una llamada iracunda de la alta direccién. Por iltimo, es necesario asignar a una persona como responsable de supervisar los riesgos potenciales y de iniciar cl plan de contingencia. Los administradores de proyecto inteligentes establecen protocolos para respuestas de contingencia antes de que se les necesite, Para un ejemplo de la importancia de esta- blecer protocolos véase el recuadro Caso de prictica: Administracin de riesgos en la cima del mundo. “A ces eeFIGURA78 Matelz de respuesta al rlesgo riesgos. Planeaciin para contingencias 12 Evento Plan de Quién es deriasgo Respuesta _contingencia Desencadenante al responsable Problemas con | Reducit | Darla la vusta hasta | No se resuele Nils lainteriaz quellegue ayuda | en 24 horas Congelamienio | Reducir | einstalarel SO | Sigue congelado des- | ‘Emmylou el sistema ues de una hora Respuesta negatival Reducir | Aumentar el soporte | Se recibe una llamada] Eddie del usuario el personal de la alta direccion ‘Mal uncionamiento| Transterir | Ordenar una Elreempiazo sim el equipo area distnta ro funciona Riesgos técnicos Los riesgos técnicos son problemiticos; a menudo pueden propiciar la cancelacién del proyecto. {Qué pasa si el proceso o el sistema no funcionan? Se claboran planes de contingencia o respaldo para esas posibilidades impredecibles. Por ejemplo, Carrier Transicold participé en el desarrollo de tuna nueva unidad Phoenix de refrigeracién para aplicaciones en camiones y tractocamiones. Esta ‘nueva unidad tendria que utilizar paneles redondos hechos de metales especiales, lo que en ese mo- ‘mento era una nueva tecnologia para Transicold. Ademas, uno de sus competidores habia intenta- do, sin éxito, incorporar metales especiales similares en sus productos. El equipo de proyecto estaba dispuesto a lograr que la nueva temnologia funcionara, pero no fue sino hasta el final del proyecto {que pudieron lograr que los nuevos adhesives pegaran de manera adecuada para completar el pro- recto. En el proceso, el equipo mantuvo un enfoque de fabricacién de paneles soldados, en caso de {que no tuvieran éxito, Si se hubiera necesitado este enfoque de contingencias, los costos de produc- cién se hubieran incrementado; pero, de cualquier manera, el proyecto se hubiera terminado a tiempo. ‘Ademis de las estrategias de respaldo, los administradores de proyectos necesitan desarrollar ‘métodos para valorar pronto si se pueden resolver las incertidumbres téenicas. El uso de programas complejos de CAD ha ayudado mucho a solucionar problemas de disefio. Asimismo, Smith y Rei- nersten, en su libro Developing Products in Half the Time, sostienen que no hay sustitutos para ha- cer algo y ver cémo funciona, cémo se siente o cémo se ve. Sugieren que uno debe primero identificar las areas de alto riesgo, luego construir modelos o disefiar experimentos para resolver el riesgo lo mas pronto posible. Al aislar y comprobar las cuestiones técnicas clave pronto en un pro- yyecto, es posible determinar con rapidez. cual es la factibilidad del proyecto y hacer los ajustes nece- Sarios, como reestructurar el proceso o, en algunos casos, cancelar el proyecto. Por lo general, las decisiones relativas a los riesgos téenicos competen al propictario y al administrador del proyecto. Riesgos de programacion Muchas veces, las organizaciones difieren la amenaza de retrasos en el proyecto hasta que ésta se hace evidente. Aqui se apartan los fondos de contingencia para aceleraro “forzar”el proyecto afin de que éste “vuclva al reil”. Lo segundo, que es reducir la duracién del proyecto, se log acortan- & = Expedicion de pesca a Alaska* Usted esti sentado frente al hogar de una cabatia en Dillingham, Alaska, comentando sobre una expedicin de pesca que esti plancando con sus colegas en Great Alaska Adventures (GAA). Mis temprano, usted recibié un fax del presidente de BlueNote, nc. El desea recompensar a su equipo de alta dircocén llevindolos a un @ aventura de pesca en Alaska con todos los gastos pagados. Quisiera que GAA organizaray drigiera la expedicion F Hate caso fue preparado con la ayuda de Stuart Morigcau. 24 Capitulo7 Adminisracn del riesgo Usted acaba de terminar una dedlaracién preliminar del alcance del proyecto (lea en seguida). Ahora realiza una tormenta de ideas sobre los riesgos potenciales que este proyecto implica 1. Realice una tormenta de ideas sobre los riesgos potenciales que este proyecto implica. Intente ‘obtener al menos cinco riesgos potenciales. 2. Utilice una evaluacién de riesgos semejante a la de la figura 7.6 para analizar los riesgos identi- ficados. 3. Desarrolle una matriz de respuesta al riesgo semejante a la de la figura 7.8 para delinear cémo se cnfrentaria usted a cada uno de los riesgos. DECLARACION DEL ENFOQUE DEL PROYECTO OBJETIVO DEL PROYECTO Organizar y dirigir una expedicién de pesca de cinco dias a lo largo del rio Tikchik, situado en Alaska, dei 21 al 25 de junio, a un costo no superior a 27 000 délares. PRODUCTOS A ENTREGAR + Proporcionar transportacién por aire desde Dillinghan, Alaska, al Campamento I'y del Cam- pamento II de regreso a Dillingham. ‘+ Suministrar transportacién pluvial con ocho embarcaciones para ocho tripulantes con motores fuera de borda. ‘+ Servir tres comidas al dia durante los cinco dias que permanezcan en el rio. + Dar cuatro horas de instrucciones para pescar con moscas. + Conseguir alojamiento en el hotel de Dillingham durante una noche y tres tiendas para cuatro personas con catres, ropa blanca y linternas. + Contratar cuatro gulas experimentados en el rlo que también sean pescadores diestros en estt técnica, + Consoguir permisos de pesca para todos los invitados. ACONTECIMIENTOS IMPORTANTES 1. Contrato firmado ~ 22 de enero. 2. Llegada de los invitados a Dillingham — 20 de junio.NO NNO OL NIISIO NS ON OS OOS 4, Salida en avién al Campamento base II de regreso a Dillingham — 25 de junio. REQUERIMIENTOS TECNICOS 1. ‘Transportacién por aire de ida y ée regreso a los campamentos. 2. ‘Transportacién en embarcaciones dentro del rio Tikchik. 3. Dispositivos de comunicacién celular digital 4. Los campamentos y la pesca se adaptarin a los requerimientos oficiales del estado de Alaska. LIMITES Y EXCLUSIONES 1. Los invitados se encargaran de arreglar su viaje de ida y vuelta a Dillingham, Alaska. 2. Los invitados se responsabilizardn de su equipo y ropa de pesca. 3. La transportacién local por aire de ida y vuelta a los campamentos se contratarii con proveedo- res externos, 4. Los guias no son responsables de la cantidad de salmén rey que los invitados pesquen REVISION DEL CLIENTE El presidente de BlueNote, Inc. Caso: Silver Fiddle Construction 705 D> i @#&3 3 }©—l Silver Fiddle Construction Usted es el presidente de la Silver Fiddle Construction (SFC), empresa que se especializa en la construccién de casas a la medida, de alta calidad, en el area de Grand Junction, Colorado. La fa- milia Czopek acaba de contratarlo para que construya la casa de sus suefios. Usted opera como contratista general y emplea un solo tenedor de libros de tiempo parcial. Asimismo, subcontrata profesionales locales para realizar los trabajos. La construccién de vivienda en Grand Junction se encuentra en un muy buen momento. Usted tiene programado terminar, en forma tentativa, 11 ca- ssas este afio. Le ha prometido a los Czapek que el costo final sera entre 450 000 y 500 000 délares. Esta familia esta dispuesta a que el proyecto se retrase para ahorrar costos. Usted acaba de elaborar una declaracién preliminar del enfoque del proyecto (lea en seguida), ‘Ahora efectiia una tormenta de ideas para identificar los riesgos potenciales que se asocian al pro- yyecto. 1. Identifique los riesgos potenciales que este proyecto implica. Intente obtener al menos cinco riesgos potenciales. 2. Utilice una evaluacién de riesgos semejante a la de la figura 7.6 para analizar los riesgos identi- ficados. 3. Desarrolle una matriz.de respuesta al riesgo semejante a la de la figura 7.8 para delinear cémo se cenfrentaria usted a cada uno de los riesgos. DECLARACION DEL ENFOQUE DEL PROYECTO OBJETIVO DEL PROYECTO Construir una casa hecha a la medida, de alta calidad, en un plazo de cinco meses sin exceder 500 000 délares. PRODUCTOS A ENTREGAR + Unacasa terminada de 233 metros cuadrados, dos bafios y medio, y tres recima* Una cochera terminada, alslada y con chapa de cantera. + Aparatos de cocina tales como estufa, horno, microondas y lavavajillas. + Un horno a gas de alta eficiencia con termostato programable. ACONTECIMIENTOS IMPORTANTES 1. Aprobacién de permisos: 5 de juli. 2. Vaciado de los cimientos: 12 de julio. 3. Inspecciones para aprobar marcos, recubrimientos, instalaciones eléctricas, plomeria y elemen- ‘tos mecéinicos: 25 de septiembre. 4, Inspeccién final: 7 de noviembre. REQUERIMIENTOS TECNICOS Una casa debe cumplir con los cédigos locales de construccién. ‘Todas las ventanas y puertas deben aprobar las calificaciones de energia de la NERC clase 40, El aislamiento de las paredes exteriores debe cumplir un factor “R” de 21 Elaislamiento de los techos debe cumplir un factor “R” de 38. El aislamiento de los pisos debe cumplir un factor “R” de 25. La cochera tendra espacio para dos automéviles y una camioneta Winnebago de 8.5 metros de largo. 7. Laestructura debe aprobar los cédigos de estabilidad sismica. 206 Capitulo7 Adminisracn del riesgo LIMITES Y EXCLUSIONES 1. La casa se construira de acuerdo con las especificaciones y el diseito de los planos originales que elcliente proporcion6. El propictario se encargara del disefio de las areas verdes. El reftigerador no se incluye entre los aparatos de cocina, No se ineluye el aire acondicionado, pero si se instalaron los cables para conectarlo. SFC se reserva el derecho de subcontratar servicios. REVISION DEL CLIENTE “Bolo” e Izabella Czopek. =D> & Proyecto de Red de Area Local (LAN) de Peak Peak Systems es una empresa pequefia de consultoria en sistemas de informacién situada en Meri- dian, Luisiana. Se le acaba de contratar para disefar e instalar una red de area local (LAN: Local ‘Area Network) para la agencia de seguridad social de la ciudad de Meridian. Usted es el administra- dor del proyecto, el cual incluye a un profesionista de la empresa y a dos practicantes de una univer- sidad local. Acaba de terminar una declaracién preliminar del enfoque del proyecto (lea en seguida). ‘Ahora esta realizando una tormenta de ideas sobre los riesgos potenciales que el proyecto implica 1. Identifique los riesgos potenciales que este proyecto implica. Intente obtener al menos cinco riesgos potenciales. 2. Utilice una evaluacién de riesgos semejante a la de la figura 7.6 para analizar los riesgos identi- ficados. 3. Desarrolle una matriz.de respuesta al riesgo semejante a la de la figura 7.8 para delinear como enfrentaria cada uno de los riesgos.DECLARACION DEL ENFOQUE DEL PROYECTO OBJETIVO DEL PROYECTO Disefiar e instalar una red de area local (LAN) en un mes con un presupuesto no mayor a 90 000 dalares para la agencia de servicio social de Meridian, PRODUCTOS A ENTREGAR + Veinte estaciones de trabajo y 20 computadoras portatiles. + Unservidor con procesadores de doble niicleo (dual core). + Dos impresoras liser a color. + Unservidor Windows Vista y un sistema operativo para estacién de trabajo. + Cuatro horas de capacitacién introductoria para el personal del cliente. + Dicciséis horas de capacitacién para el administrador de la red del cliente. + Unsistema LAN en operacién total ACONTECIMIENTOS IMPORTANTES 1. Hardware: 22 de enero. 2. Establecimiento de las prioridades de los usuarios y autorizacién: 26 de enero. 3. Fin de la comprobacién de toda la red instalada: | de febrero. 4. Terminacin de la prueba en la ubicacién del cliente: 2 de febrero. 5. Capacitacién terminada: 16 de febrero, Caso: Concerto de primavera XSU 200 REQUERIMIENTOS TECNICOS 1. Estaciones de trabajo con pantalla plana de 17 pulgadas, procesadores de doble niicleo, 1 GB de RAM, 8X DVD+RW, tarjeta inalimbrica, tarjeta Ethemet, disco duro de 80 GB. 2. Computadoras portitiles con pantalla de 12 pulgadas, procesadores de doble niicleo, 12 MB de RAM, 8X DVD+RW, tarjeta inalimbrica, tarjeta Ethernet, disco duro de 60 GB y un peso me- nor a cuatro libras y media. 3. Tarjetas inalimbricas de interfaz con la red y conexiones de Ethernet, 4, Elssistema debe soportar la plataforma Windows Vista. 5. El sistema debe proporcionar un acceso externo seguro a los trabajadores de campo. LiMITES Y EXCLUSIONES |. Mantenimiento y reparacién del sistema s6lo hasta un mes después de la inspeccién final. 2. Las garantias se trasladan al cliente, 3. Sélo se es responsable de instalar el software que el cliente disefié dos semanas antes del inicio del proyecto. 4. Alcliente se le cobrara la capacitacién adicional mas alla de lo prescrito en el contrato. REVISION DEL CLIENTE El director de la agencia de servicio social de Meridian.Vera ADU uu Usted es miembro del comité de entretenimiento de la comunidad estudiantil dela X State Univer- sity (XSU). Su comité ha acordado patrocinar un concierto de primavera. El motivo es ofrecer una lternativa segura al Fin de Semana Hasta. Este es unfestejo de primavera en el que los estudiantes de la XSU rentan botes y organizan una fiesta muy desenfrenada. Fs tradicional que se haga el il- timo fin de semana de mayo. Por desgraca, tiene una larga historia de salirse de control yen oca siones, de propiciar accidentesfatales. Después de una tragedia ocurrida la primavera pasada, su omit quiere ofrecerle una experiencia alterna a quienes estin ansiosos de celebrar el cambio de lima y el préximo final del ao escolar. Usted acaba de terminar la declaracién preliminar del alcance del proyecto (lea en seguida) ‘Ahora esti ealizando una tormenta de ideas sobre los riesgos potenciales que el proyecto im- plica 1. Identifique los riesgos potenciales que este proyecto implica. Intente obtener al menos cinco riesgos potenciales. 2. Utilice una evaluacién de riesgos semejante a la de la figura 7.6 para analizar los riesgos identi- ficados, 3. Desarrolle una matriz de respuesta al riesgo semejante a la de la figura 7.8 para delinear cémo se cenfrentaria usted a cada uno de os riesgos. DECLARACION DEL ENFOQUE DEL PROYECTO OBJETIVO DEL PROYECTO Organizar y llevar a cabo un concierto de ocho horas en el Wahoo Stadium a un costo que no su- pere los 50.000 délares el iltimo domingo de mayo. 208 Captulo7 Adminisracn del riesgo PRODUCTOS A ENTREGAR + Publicidad local ‘+ Seguridad para el concierto. + Un jardin de cerveza separado (donde se permite beberla). + Ocho horas de miisica y entretenimiento, + Puestos de comida. + Camisetas de recuerdo del concierto. + Cubrir todos los permisos y licenc + Asegurar patrocinadores. ACONTECIMIENTOS IMPORTANTES Asegurar todos los permisos y aprobaciones: 15 de junio. Contratar artistas de renombre: 15 de febrero. ‘Completar el programa de apariciones de los artistas: | de abril Asegurar los contratos de los proveedores: 15 de abril ‘Terminar los preparativos: 27 de mayo. Realizar el concierto: 28 de mayo. ‘Terminar la limpieza: 31 de mayo. REQUERIMIENTOS TECNICOS I. Sistema y escenario de sonido profesional. 2. Al menos un artista de renombre. 3. Al menos siete actos en el especticulo. 4, Instalaciones sanitarias para al menos 10 000 personas.ene ONE NII ISLES 6. Cumplimiento de los requerimientos y normas de la XSU y de la ciudad, LIMITES Y EXCLUSIONES 1. Los artistas son responsables de los arreglos de viaje de ida y vuelta a la XSU. 2. Los proveedores contribuyen con un porcentaje fjo de las ventas. 3. El.concierto debe terminar para las 11:30 p.m. REVISION DEL CLIENTE El presidente del cuerpo estudiantil de la XSU. PN A PERT y simulacion PERT TECNICA DE REVISION DE LA EVALUACION DE PROGRAMAS: PERT En 1958, la oficina especial de la Armada de Estados Unidos y la empresa de consultoria Booze, Allen y Hamilton desarrollaron la PERT (es decir, técnica de revision de evaluacién de programas) [para programar a los mas de 3 300 contratistas del proyecto de submarino Polaris y para cubrir la incertidumbre de los estimados de tiempo de las actividades. Apéndive 7.1: PERT y simulacisn PERT 208 La PERT es casi idéntica a la técnica del método de la ruta critica (MRC) con la diferencia de {que supone que la duracién de cada actividad tiene un alcance que sigue una distribucién estadistica, La PERT utiliza tres estimados de tiempo para cada actividad. En esencia, esto significa que cada actividad puede durar desde un tiempo pesimista hasta uno optimista y que es posible caleular un promedio valorado para cada actividad. Como en general las actividades del proyecto representan ‘trabajo, y como el trabajo tiende a estancarse una vez que empieza a retrasarse, os desarrolladores de la PERT escogieron una aproximacién de la distribucién beta para que representara la dura- cién de las actividades. Esta distribucién es conocida por su flexibilidad y puede acomodar datos cempiricos que no siguen una distribucién normal. Las duraciones de las actividades pueden incli- ‘narse mas hacia el extremo superior o inferior del rango de datos. En la figura A7.la se muestra una distribucion beta de las duraciones de actividades con tendencia a la derecha que representa el ‘trabajo que tiende a estar rezagado una vez. que se retrasa. La distribucién para la duracién del proyecto se representa por una distribucién normal (simétrica), la cual se muestra en la figura ‘AT.Ib. La distribucién del proyecto representa la suma de los promedios valorados de las activida- des en la(s) ruta(s)critica(s) Si se conocen el promedio valorado y las varianzas de cada actividad, el planeador del proyecto podri calcular la probabilidad de que se cumplan las distintas duraciones del proyecto. Siganse los pasos que se describen en el ejemplo hipotético que aparece a continuaci6n. (La jerga es dificil para quienes no estan familiarizados con la estadistica, pero el proceso es muy sencillo una vez que se ‘trabaja con un par de ejemplos.) El tiempo de la actividad promedio valorada se calcula con la férmula siguiente: _atamth ¢ (71) te donde, = tiempo valorado de actividad promedio a = tiempo optimista de la actividad (probabilidad de 1 en 100 de terminar antes laactividad en condiciones normales) 'b = tiempo pesimista de la actividad (probabilidad de | en 100 de terminar después la actividad en condiciones normales) _m = tiempo mis probable de la actividad ‘Cuando se han especificado los tres estimados, se utiliza la ecuacién para calcular la duracién valo- rada promedio de cada actividad. El valor promedio (determinista) se ubica en la red del proyecto ‘como en el método MRC y los tiempos temprano, tardio, de inactividad y de terminacién del pro- yyecto se calculan como estan en el método MRC. La variabilidad en los estimados de tiempo de actividad se aproxima con las siguientes ecuacio- nes: la ecuaci6n 7.2 representa la desviacin estindar para la actividad. La ecuacién 7.3 representa la desviacién estindar para el proyecto. Observe que la desviaciGn estindar de la actividad se ha FIGURAA7.1_Distribuciones de frecuencia del proyecto y de la actividad ACTIVIDAD PROYECTO