Details of the Check – Search Algorithm

9.47. ¿Cómo puede usarse la planeación, programación y control de proyectos para acelerar el tiempo de introducción de un producto? {Sugerencia: piense en prescindir de actividades, comprimirlas y cambiar la estructura de precedencia lo más posible.)

8 SOFTWARE

En general, se necesita una computadora para la planeación, programación y control de pro- yectos. Una computadora es maravillosa para los cálculos de los tiempos de inicio cercano y le- jano, las holguras y las rutas críticas. Es útil para el análisis de costos, la asignación de recursos y los trueques tiempo/costo; pero aún más importante, proporciona los datos a tiempo para las actualizaciones y es muy conveniente para el análisis de "qué pasa si".

Si decide usar una computadora, existen muchos paquetes disponibles. La primera deci- sión es si compra software para una microcomputadora o renta software para una mini o una computadora grande. Hubo una época en que los proyectos grandes sólo se podían manejar en computadoras grandes, pero ya no es así. Los costos de los paquetes para microcomputadoras van de cero (los de dominio público) a 50 000 dólares por las versiones más elaboradas. Los pa- quetes para las mini y las grandes cuestan desde 5000 a varios cientos de miles de dólares. Mu- chos paquetes de 500 dólares tienen buen desempeño para las funciones básicas de programa- ción. Si se agregan costos y control de recursos el precio aumenta. La capacidad para reducir actividades se encuentran en paquetes más avanzados. Unos cuantos realizan nivelación y asignación de recursos, pero tal vez sólo usen un heurístico de despacho sencillo.

Como la industria del software cambia con rapidez, no se mencionan paquetes específicos. Periódicamente, se publican listas y comparaciones del software disponible para la planeación, programación y control de proyectos. Los ejemplos incluyen: Wortman (1989), Yahdav (1992), Bloom (1993) y "Project Management Software Buyer's Guide" (1995). Un análisis detallado sobre la selección de software para la administración de proyectos se encuentra en Kezbom et al (1989).

Varias revistas tienen columnas que evalúan paquetes específicos de planeación, progra- mación y control de proyectos. Éstas incluyen Cosí Engineering, Project Management Jour-

nal, Byte, PC Magazine y PC World. En la sección 11 se hace referencia a muchos ejemplos.

Algunos paquetes son tan populares que se han escrito libros sobre ellos, como Day (1995). Para proyectos sencillos puede ser suficiente el software "académico". De nuevo existe una gran variedad de paquetes, que incluye a Chang (1995) y Emmons et al (1989).

9 EVOLUCIÓN

Los egipcios usaron los conceptos de planeación, organización y control hace más de 6000 años; es probable que se usara alguna forma de planeación, programación y control en la cons- trucción de las pirámides. No fue sino hasta mediados de los 50 cuando se formalizó el procedi- miento. Sin embargo, existen dos precursores que deben mencionarse. La gráfica de Gantt (1911) contiene las ideas fundamentales de la planeación, programación y control de proyec- tos. Karol Adamiecki, un científico polaco, desarrolló la gráfica armónica en 1931, una gráfica tipo Gantt diseñada especialmente para la programación de proyectos. Se ordenaban las activi- dades según sus precedencias y se iniciaban lo más pronto posible, es decir, una pasada hacia adelante. Como las actividades estaban representadas por tabuladores que corrían, resultaba sencillo llevar a cabo la actualización y reprogramación. Su descubrimiento no se difundió y pronto se desvaneció.

A mediados de la década de 1950, tres grupos independientes desarrollaron la planeación, programación y control de proyectos que conocemos hoy. La sección de investigación de ope- raciones del British Central Electricity Generating Board quería reducir el tiempo de la repara- ción general de una planta generadora. Para 1957 habían desarrollado una metodología para identificar la ruta crítica. Eventualmente se redujo el tiempo para reparar una planta en más de 40% (Lockyer, 1969).

Durante el mismo periodo, un equipo compuesto por empleados de Lockheed Aircraft Corporation, de Booz, Alien y Hamilton Consultants y de U.S. Navy trabajaron para reducir los costos y el tiempo de terminación de proyectos gubernamentales. Malcolm et al (1959) pu- blicaron su metodología, llamada PERT. El sistema de armamento Polaris fue planeado, pro-

gramado y controlado usando PERT y terminó antes de la fecha programada y abajo del presu- puesto.

Otra colaboración, hecha por la compañía Du Pont junto con la Remington Rand Univac, produjo el CPM (Walker y Sayer, 1959). También deseaban reducir el tiempo dedicado a repa- raciones generales en la planta, mantenimiento y construcción. Este grupo introdujo el modelo básico de tiempo/costo (Kelley y Walker, 1959; Kelley, 1961).

El éxito de estos métodos condujo a estándares gubernamentales para controlar los costos de los proyectos que financiaban (DOD and NASA Guide, 1962). Comenzó la investigación sobre el balanceo de recursos (Burgess y Killebrew, 1962) y los heurísticos para modelos con restricción de recursos (Weist, 1964, 1967). En 1964, Moder y Phillips publicaron la primera edición de su libro clásico, Project Management with CPM, PERT and Precedence Dia-

gramming (actualizado en Moder et al, 1983).

A finales de los 60 y principios de los 70 se desarrollaron paquetes de software comercia- les para computadoras grandes. Éstos eran muy costosos y difíciles de usar. Los datos de entrada (y algunas veces los de salida) se perforaban en tarjetas y con frecuencia llevaba de ocho a diez horas de tiempo de computadora tan sólo actualizar un proyecto grande. El gobierno im- pulsó el uso continuo de los sistemas (USAFSC, 1976). Se dedicaron esfuerzos a la investiga- ción sobre estimaciones probabilísticas, algoritmos heurísticos de programación con restric- ción de recursos y diferentes medidas de desempeño, pero ya se habían establecido los fundamentos de planeación, programación y control. El primer libro de texto riguroso sobre el tema fue escrito por Elmaghraby en 1977.

La proliferación de las computadoras personales ha sido un factor dominante en la planea- ción, programación y control durante los últimos 15 años. Se han desarrollado muchos paque- tes amigables y están disponibles a precios razonables. Esta tecnología ha puesto una gran he- rramienta sobre el escritorio de muchos administradores y analistas. La investigación en las mismas áreas continúa: recursos limitados (Olaguibel y Goerlich, 1989; Oguz y Bala, 1994); nuevas medidas de desempeño como costos de retraso (Kim, 1993), penalización por ade- lanto/tardanza (Padman y Smith-Daniels, 1993) y objetivos múltiples (Davis et al, 1992; Slowinski et al, 1994); aspectos probabilísticos (Gong y Hugsted, 1993; Keefer y Verdini, 1993), y nuevas técnicas de solución (Icmeli y Erenguc, 1994). Varios libros, como Slowinski y Weglarz (1989), Morton y Pentico (1993) y Sprecher (1994) profundizan en aspectos parti- culares de la planeación, programación y control. Otros, por ejemplo, Badiru (1994), Cleland (1994) y Kezbom et al (1989), proporcionan textos introductorios comprensibles.

10 RESUMEN

Este capítulo estudió los proyectos, un conjunto de actividades interrelacionadas que deben terminar para lograr una meta. Un proyecto puede desarrollar un nuevo producto o sistema, dar mantenimiento a equipo existente, instalar equipo nuevo o construir una planta. Los elementos principales son la planeación, la programación y el control.

La planeación ocurre tanto antes como durante la ejecución del proyecto. La elección de un administrador del proyecto y del equipo son parte de la planeación. La estructura organiza- cional puede ser por proyecto, por personal o matricial. Otra parte de la planeación es definir el proyecto. Esto incluye la definición de las actividades y la estimación de sus duraciones, costos y requerimientos de recursos. Deben determinarse las precedencias de las actividades y especi- ficarse la red final.

La programación consiste en asignar los tiempos de inicio de cada actividad. Los cálculos requeridos se componen de una pasada hacia adelante, para obtener los tiempos de inicio más cercanos y una pasada hacia atrás para calcular los tiempos de inicio más lejanos. Las activida- des críticas se identifican como actividades que merecen toda la atención. También se definen los programas de inicio cercano y de inicio lejano.

Una vez que el proyecto está en marcha, debe controlarse. Conforme las actividades avan- zan, se actualizan las estimaciones de tiempo, dinero y recursos. El proyecto se programa de nuevo para tomar en cuenta los eventos reales. Para controlar los recursos, el proyecto se divide en paquetes de trabajo o en estructuras de trabajo desglosadas. Las variaciones entre el uso real de recursos y el programado señalan puntos de conflicto en el proyecto. Aunque es más común dar seguimiento al tiempo y al dinero, cualquier recurso se puede controlar de esta manera.

Para tomar en cuenta la incertidumbre en la duración de las actividades, se introdujo el PERT. Se supone que la duración de cada actividad sigue una distribución de probabilidad; se estudiaron los casos de la uniforme, la triangular y la beta. La ruta crítica, con las duraciones esperadas, se encuentra de la manera estándar. Después se puede llevar a cabo un análisis pro- babilístico del tiempo de terminación del proyecto usando el teorema del límite central. Es po- sible que las suposiciones requeridas para este enfoque no siempre sean válidas; esto lleva a de- terminar las limitaciones del PERT.

Otra extensión de los cálculos básicos del proyecto es incluir recursos limitados, que pue- den causar retrasos en el desarrollo del proyecto. Puede resultar muy complejo encontrar solu- ciones factibles en recursos a estos problemas. Hacer gráficas que muestren los perfiles de re- cursos puede ayudar para la programación de proyectos. El índice crítico indica la importancia del uso efectivo de un recurso específico. Se presenta un heurístico de despacho sencillo para recursos fijos. Se mencionan en forma breve otras variaciones, como nivelación o balanceo de recursos, recursos múltiples y proyectos múltiples.

Si aumentar los recursos puede disminuir el tiempo para realizar una actividad, se tiene un trueque tiempo/costo. Puede quererse pagar más para reducir la duración de una actividad si esto reduce el costo indirecto del proyecto o si hace que el proyecto termine antes. Se definen el tiempo y el costo normales y reducidos y se supone que la relación entre el tiempo y el costo es lineal. Se presenta un heurístico sencillo de costo/unidad de tiempo. Para problemas más gran- des, el número y las combinaciones de actividades críticas y casi críticas hace que el heurístico no sea práctico. Se expone un modelo de programación lineal que optimiza el costo total para un costo indirecto dado. Su solución proporciona una gráfica de trueque tiempo/costo.

Por último, se hizo un análisis breve del software y de la evolución de la planeación de pro- yectos.