Documentos de Académico
Documentos de Profesional
Documentos de Cultura
CPM
1. INTRODUCCIN ............................................................................................................................................................2
9. FLECHAS FICTICIAS.................................................................................................................................................14
11. EJEMPLOS....................................................................................................................................................................17
BIBLIOGRAFA ..................................................................................................................................................................50
Cuando la Marina de los Estados Unidos comenz el proyecto del submarino atmico
Polaris, se dieron cuenta que no slo deban vencer las dificultades tcnicas y cientficas,
sino tambin el problema de coordinacin y control de estos enormes esfuerzos. En este
proyecto haba 250 contratistas directos y ms de 9.000 subcontratistas, que suponan gran
cantidad de recursos y factores humanos y, por tanto, era preciso encontrar una nueva
tcnica para desarrollar el proyecto con eficacia bajo un nivel razonable de coste y tiempo.
En colaboracin con la casa Booz, Allen y hamilton se iniciaron los conceptos bsicos
del sistema PERT (Project Evaluation and Review Technique), como instrumento de
planificacin, comunicacin, control e informacin. El resultado de la aplicacin de esta
nueva tcnica fue el ahorro de dos aos en un proyecto de cinco de duracin total.
Este xito no slo impresion en el campo militar, sino tambin en otros sectores; su
utilizacin se extendi rpidamente en el campo industrial y comercial. Hoy prcticamente
en los Estados Unidos todas las empresas utilizan PERT para controlar sus proyectos,
especialmente las que estn vinculadas con el Departamento de Defensa.
En 1957, la casa E. I. Du Pont desarroll un sistema que pudiera mejorar el mtodo de
planificacin y programacin para los programas de construccin. Bajo la direccin de los
seores J.E. Kelly y M.R. Walker, se cre la tcnica CPM (Critical Path Method).
La tcnica de CPM es similar al PERT en muchos aspectos. La diferencia fundamental
de estos dos sistemas consiste en que, el PERT, estima la duracin de cada tarea u
operacin de los proyectos basndose simplemente en un nivel de coste, mientras que el
CPM relaciona duracin y coste, de lo cual se deriva una diversidad de duraciones para
cada tarea u operacin, y la eleccin de una duracin adecuada se har de modo que el
coste total del proyecto sea mnimo.
Lo ms criticado de PERT y CPM es que ambas son determinstas, es decir, se
predetermina que actividades deben hacerse para terminar un proyecto. Es asumido que
todas las actividades del grfico de red se tiene que hacer antes o despus, y que la
terminacin de todas las actividades marca el final del proyecto. La duracin de una
actividad es lo nico que se considera incierto.
Para muchos tipos de proyectos, particularmente aquellos en los cuales los procesos no
son bien conocidos hay muchas ms cosas inciertas que se deberan considerar.
Por ejemplo, una actividad en un proyecto de desarrollo de software puede ser "probar los
resultados del programa". No siempre el resultado es el que esperbamos y puede ser que
no sepamos si esto representa un error en de tipo software o hardware o un poco de
ambos. An sera peor si fuese un problema de diseo o de especificacin entonces el
proyecto necesitara volver atrs hasta llegar al paso de diseo o de especificacin.
Estas contingencias de salto para redisear o reespecificar son normales en proyectos de
desarrollo.
Como PERT y CPM requieren que todas las tareas estn terminadas no se considera el
caso de tener que volver atrs. Para compensar estas deficiencias se han desarrollado
sistemas de red ms generalizados, probablemente el ms conocido es el GERT (Graphical
Evaluation and Review Technique).
PERT y CPM son dos mtodos usados por la direccin para, con los medios
disponibles, planificar el proyecto al fin de lograr su objetivo con xito. Estos mtodos no
pretenden sustituir las funciones de la direccin, sino ayudarla. PERT y CPM no resuelven
los problemas por s solos sino que relacionan todos los factores del problema de manera
que presentan una perspectiva ms clara para su ejecucin. Muchas veces las decisiones
no son fcilmente tomadas por la direccin debido a su incertidumbre, pero PERT y CPM
ofrecen un medio eficaz de reducir sta, y que las decisiones tomadas y acciones
emprendidas sean las adecuadas al problema, con gran probabilidad de xito.
El mayor problema con que la direccin se enfrenta hoy en un proyecto complejo, es
cmo coordinar las diversas actividades para lograr su objetivo. Los enfoques tradicionales
sobre la planificacin y programacin resultan inadecuados e insuficientes. Generalmente
los diferentes grupos que trabajan para el proyecto tienen sus propios planes de realizacin
independientes entre s. Esta separacin conduce a una falta de coordinacin para el
proyecto como conjunto. En cambio, las tcnicas de PERT y CPM preparan el plan
mediante la representacin grfica de todas las operaciones que intervienen en el proyecto
y las relacionan, coordinndolas de acuerdo con las exigencias tecnolgicas.
Adems, estas tcnicas proporcionan un mtodo de actuacin por excepcin para la
direccin; esto quiere decir que la direccin slo actuar cuando surjan desviaciones
respecto al plan previsto.
De aqu tambin se deduce que la funcin de la direccin est caracterizada por las
decisiones que se deben tomar y, a su vez, estas decisiones van acompaadas de la
incertidumbre. Sobre todo, cuando el objetivo no tiene precedente y el xito de la con-
secucin no est garantizado. Aun cuando los trabajos sean repetitivos, la direccin suele
encontrarse con problemas tanto de tiempo como de coste.
PERT y CPM son sistemas especialmente diseados para asistir a la direccin en esas
tareas donde la incertidumbre pudiera comprometer su eficacia, ya que estos mtodos le
ofrecen una planificacin detallada, con las responsabilidades designadas, y la
programacin mejor estimada y con ms probabilidad de cumplimiento.
Las principales ventajas de estas tcnicas son el poder proporcionar a la direccin las
siguientes informaciones:
cualquier tarea sea diferente del que realmente hubiera necesitado, y entonces, el grfico
no refleja la realidad del proyecto. Adems, muchas veces el proyecto se retrasa y la
direccin no permite ver claramente en qu tareas tiene que acelerar y en qu medida para
que la duracin total del proyecto sea la estimada, ni mucho menos saber cunto le va a
costar esta aceleracin.
Para los sistemas de PERT y CPM, la planificacin consiste en un anlisis de las
actividades que deben intervenir en el proyecto y el orden en que han de tener lugar. La
programacin en el PERT es estimar las duraciones de las tareas tanto en el sentido deter-
minstico como en el probabilstico. En el CPM, la programacin consiste en estimar las
duraciones de las tareas con el mnimo de recursos, es decir, que el tiempo y el coste estn
relacionados directamente en un proyecto.
Tampoco es preciso que la flecha sea una lnea recta, sino que pueden dibujarse en
curva:
Esto depende de la facilidad que haya para representar las actividades en una red de
flechas que refleje el orden y secuencia de las relaciones del proyecto.
Sin embargo, hay una excepcin en los sucesos iniciales y finales. El primer suceso
inicial del proyecto no tiene una actividad que la preceda y el ltimo suceso final tampoco
tiene una actividad que la subsiga.
Volvamos a nuestro ejemplo anterior (fig. 6-1) y lo representaremos con una red de
flechas. Primero, en la fase de planificacin es necesario estudiar las actividades que deben
intervenir y sus relaciones de precedencia.
En el ejemplo citado las relaciones de precedencia son las siguientes:
En nuestro ejemplo vemos que cada actividad tiene dos nmeros. A todos los sucesos
iniciales los llamamos i y a los sucesos finales j.
Excepto el primer suceso inicial y el ltimo suceso final, en todos los dems, la letra j de
la actividad precedente es igual a la letra i de la subsiguiente.
Si aadimos una actividad restrictiva (la actividad F), que por ejemplo puede ser
autorizacin gubernamental. En este diagrama de flechas la actividad F no es una actividad
interna de la ejecucin del proyecto. Vemos que en la figura 9-1 la flecha de la actividad F
apunta al suceso 2; esto quiere decir que para empezar la construccin de las actividades B
y C es preciso tener la autorizacin en regla.
Tambin podemos interpretar el suceso 0 como el comienzo del proyecto, Y el suceso 1
como el comienzo de la ejecucin del mismo.
En un diagrama de flechas, muchas veces existe una relacin de precedencia entre dos
actividades, pero no porque se requiera previamente ningn trabajo, ni recurso, ni tiempo,
sino por circunstancias especiales, como veremos en los siguientes ejemplos. En estos
casos para expresar la conexin de estas actividades se crea una flecha ficticia,
representada con una lnea punteada (- - - ->)
Por ejemplo, supongamos que construimos un gran alternador elctrico, en el taller de
calderera, y no se puede realizar el estator y el rotor al mismo tiempo por su tamao,
siendo estas dos actividades independientes, y para expresar el orden de ejecucin unimos
con una flecha ficticia, indicando que primero se hace el estator y luego el rotor.
En muchos diagramas, suele ocurrir que entre el mismo suceso inicial y el final,
aparecen paralelamente varias actividades, como en el siguiente ejemplo:
En tal caso, para el clculo de la duracin del proyecto a mano no importa mucho que
las tres actividades se numeren de la misma forma (2, 3), ya que podemos llamar a las
mencionadas actividades por sus nombres A, B y C; pero para el uso del ordenador, no se
pueden describir tres actividades con la misma enumeracin (2, 3). Para evitar esta
confusin se pueden crear las actividades ficticias, aumentando los nmeros de sucesos.
En caso de que la actividad F, sea slo necesaria para la B, y no para la C, tenemos que
trazar una flecha ficticia para marcar la relacin de precedencia entre la A y B, separando la
relacin de precedencia de las F y C.
Primer ejemplo
Antes de representar el proyecto en forma de red de flechas, es preciso terminar el
anlisis de actividades que van a intervenir. Supongamos que tenemos seis actividades
bien definidas A, B, C, D, E y F, siendo las relaciones de precedencia entre ellas las
siguientes:
A pesar de que la numeracin de la actividad ficticia entre (2) y (5) en el primer mtodo
es (4) y (5), y en el segundo es (2) y (4), la representacin grfica del proyecto es idntica.
Segundo ejemplo
Es evidente que la obra no se realiza de esa forma, sino que antes de terminar de cavar
los 10 Km. de terreno, ya se inicia el trabajo de poner las secciones de tubos. As como
antes de poner a lo largo de 10 Km. las secciones de tubos, ya se empiezan las soldaduras.
Entonces podemos modificar nuestro diagrama en la siguiente forma:
Por otro lado, antes de terminar de poner todas las secciones de tubos ya se inician los
trabajos de soldadura. Sin terminar la soldadura de todas las secciones se emprende el
trabajo de recubrir el terreno.
Hasta ahora podemos decir que hemos terminado la fase de planificacin y entramos en
la fase de programacin. La programacin consiste en estimar la duracin de cada
actividad. Esta estimacin puede ser deterministica o probabilistica.
Vamos a ver primero la determinstica. Esto quiere decir que la duracin ser nica y
exacta.
Primero se construye el diagrama de flechas y se discute, entre los responsables que
intervienen en el proyecto, sobre qu actividades son necesarias y qu relacin de
precedencia hay entre ellas.
Luego se estima la duracin t (i, j) de cada actividad.
Ahora se calculan los tiempos de lo ms pronto posible en que puede empezar y
terminar una actividad, y lo sealaremos con t(i) y t (j) respectivamente.
Por ejemplo, en la actividad (1, 2), el tiempo lo ms pronto posible (t) de comenzar -
t(1)-es cero y el tiempo lo ms pronto posible de terminar -t (2)- es tres unidades de tiempo;
ya que
t(2) = t(1) + t(1,2) = 0 + 3 = 3
a) Flotante total.
b) Flotante libre.
c) Flotante independiente.
d) Flotante programado.
a) Flotante total
Se calcula la diferencia entre el tiempo lo ms tarde permisible en que se puede
terminar y el tiempo lo ms pronto posible en que se puede comenzar una actividad, menos
la duracin de la misma. Por ejemplo, en la actividad (4, 5) tenemos que el tiempo lo ms
tarde permisible para terminar es 20, y el tiempo lo ms pronto posible para comenzar es de
11. La diferencia de stos menos la duracin de la propia actividad, es 5. El flotante total es
FT = t*(5) - t(4) - t(4, 5) = 20 - 11 - 5 = 4
El flotante total es la holgura que permite el que una actividad se pueda demorar sin
afectar al tiempo programado en el proyecto.
Todas las actividades que tienen tiempos flotantes totales ceros, son actividades
crticas. Por tanto, las actividades (0, 1), (1, 2), (2, 4), (4, 6) y (6, 7) son crticas, en la figura
14-2.
b) Flotante libre
El tiempo flotante libre es la cantidad de holgura disponible despus de realizar la
actividad si todas las actividades del proyecto han comenzado en sus tiempos lo ms pronto
posible del comienzo. O sea, la diferencia de los tiempos lo ms pronto posible de
Veamos en la subruta (2, 5) y (5, 6). Cada actividad tiene a su disposicin 2 unidades de
flotante total para la realizacin del trabajo. Esto indica que estas dos unidades son para
toda la subruta. De forma que si se retrasaran dos unidades en la actividad (2, 5), entonces
para que el proyecto se cumpla en 25 unidades de tiempo, la actividad (5, 6) no debe ser
demorada en ningn momento. En cambio, el flotante libre indica que si se quiere que
empiece la actividad (5, 6) en su tiempo lo mas pronto posible t(5)=18, la actividad
precedente (2, 5) no deber disponer de ninguna holgura de tiempo. El tiempo flotante libre,
desde el punto de vista de la direccin es ms interesante para el control del proyecto.
Ahora vamos a trasladar los resultados de los clculos a un cuadro de cmputos de
tiempos.
W ij
FP = F
Wij T
(i,j) P
Por otra parte, si se desea tener en cuenta el factor de promixidad al camino crtico,
entonces se puede expresar en una funcin E(u), cuya determinacin depende del criterio
del programador.
El clculo del flotante programado ser de la siguiente forma:
C N CT (21-1)
c (i , j ) =
D(i , j ) d (i , j )
a) Relacin horizontal
Muchas veces, en la prctica, se ve que al reducir la duracin no se ocasiona al
mismo tiempo un aumento de coste. Por ejemplo, si el personal trabaj horas
extraordinarias sin mas pagas que el jornal normal, esto significa la disminucion de
duracin sin incremento del coste directo por unidad de tiempo. Otro caso es que
con el mismo nivel de inversin. el personal responsable del clculo de duracin lo
ha sobrestimado, y tiene que acortarlo ulteriormente para corregirlo. Esta clase de
reduccin no va acompaada de ningn aumento de coste directo.
b) Casos no continuos
Hay casos en que slo existen los puntos tope y normal. En otras palabras, que
en tal actividad no existe una relacin de duracin-coste en forma continua. Por
ejemplo, el correo postal con un pais extranjero en que slo existen dos clases de
tarifas: areo o normal. No se hace la mitad del trayecto por ruta area y la otra
mitad por mar.
c) Actividades artificiales
En el diagrama de flechas, se representan estas actividades con lneas
punteadas y, como no requieren ni recursos ni tiempo, los puntos normales y topes
son ceros. Estas actividades artificiales no tienen incremento de coste.
d) Inclinacin opcional.
La inclinacin indica el coeficiente del incremento del coste directo en
relacin con la disminucin de la duracin. En nuestra figura 22-1, se puede acortar
la duracin ventajosamente, pero no lo podemos hacer por razones ajenas, tales
como dificultades para disponer de fondos, o la gran inseguridad de estimacin del
coste. Y por ello creamos una recta opcional que tenga mayor inclinacin con el fin
de que al usar el ordenador, ste no nos indique que hay que acortar la duracin.
a) Que la duracin total del proyecto no puede ser inferior a la suma total de las
duraciones-topes de las actividades.
b) Que el mnimo coste directo total se da si todas las actividades han sido
programadas con duraciones normales.
El primer caso, lo llamamos todo tope duracin del proyecto. El segundo, todo normal
duracin del proyecto. Entre estos dos extremos, existe un nmero infinito de
combinaciones de duracion-coste del proyecto. Pero slo hay unas pocas que pueden llevar
a cabo el proyecto con un coste total ptimo. El problema est en:
1. Identificar las actividades del proyecto que influyen en la duracin de ste.
2. Especificar, para una duracin determinada del proyecto aquella combinacin de
duraciones de actividades que d lugar al coste total ptimo.
Camino primero
Camino segundo
Camino tercero
Camino cuarto
Camino sexto
T.P. (0) + B(16) + F(8) + I(6) = 30 semanas
El camino ms largo en duraciones de todo normal es el tercero
Obtenemos del cuadro 23-1 las duraciones y costes directos de todo normal
programacin en el cuadro 23-2.
Segunda programacin
Si se desea la reduccin del proyecto, las actividades que estn en el camino critico de
la primera programacin deben ser aceleradas. Cualquier intento en la reduccin de otras
actividades no criticas significara un aumento de coste directo sin afectar en nada a la
duracin del proyecto.
Qu actividades tenemos que reducir? Naturalmente se elegir la que tenga el coste
por unidad de tiempo ms bajo. En nuestro cuadro 23-1, la actividad C debe ser acortada, y
adems la duracin normal de la C es de 12 semanas y la tope es de 6. Se pueden reducir
hasta 6 semanas. Ahora bien, slo vamos a reducir 4 semanas, y as tendremos la duracin
del proyecto con 46 semanas, igual que el camino segundo. Con esta reduccin, vemos que
el camino segundo se convierte tambin en crtico.
Tercera programacin
Segn lo que hemos calculado en la segunda programacin, no existe otra alternativa
que la de reducir 2 semanas en la actividad A, ya que cualquier otra posibilidad, no dara el
coste directo total mnimo, con esa duracin de 44 semanas y as se convierte el camino
quinto en el crtico.
Cuarta programacin
Quinta programacin
Graham, Robert J. "Project management as if people mattered" Primavera Press 1989, Pennsylvania
Yu Chuen-Tao, Luis "Aplicaciones prcticas del PERT y CPM" Ediciones Deusto S.A, Bilbao
Romero Lpez, Carlos. "Tcnicas de programacin y control de proyectos" Ediciones Pirmide S.A,
Madrid 1993
Rutkowski P.J; Peiffer B.L. "Project Management Experience & Practice Workshop", Madrid: Abril
1999
Taha, Hamdy A, "Operations Research an Introduccion", Prentice Hall
http://hadm.sph.sc.edu/Courses/J716/CPM/CPM.html
http://www.cs-solutions.com/hulett.htm