Diapositiva 1Decano Facultad de Administración de Proyectos
1
Expositor
Algunos puestos desempeñados:
Presidente Colegio de Ingenieros Civiles de Costa Rica
Presidente Fundación para la Vivienda Rural Costa Rica Canadá
Presidente Fundación Centro para la Investigación en Desastres
Naturales.
Miembro Junta Directiva Comisión Nacional de Emergencias.
Jefe Unidad de Planeamiento y Control. CONAVI.
Trabajo de consultoría con Universidad de Lund, Suecia; Universidad
Nacional, PNUD y diversos empresas privadas.
el 30/11/2010
PMI. (Nov. 2010) The State of Project Management in Latin America.
PMI Today. Tomado de
http://www.pmitoday-digital.com/pmitodayopen/201011/?folio=5#pg5 el
30 de noviembre del 2010.
PMI (2008). Project Management Body of Knowledge (4th. Ed.)
Pennsylvania: PMI Inc.
Sáenz de Viguera, Miguel. En “Innovación, educación universitaria y
certificaciones profesionales para la gestión de proyectos en el
siglo XXI”.
UCI obtiene acreditación académica del PMI. En UniversidadesCR.com
abril 30, 2009. En
http://universidadescr.com/blog/uci-obtiene-acreditacion-academica-del-pmi%C2%AE/
. Tomado el 30 de noviembre del 2010.
Salas, X. (2007) Curso de Introducción a la Administración de
Proyectos .
Chamoun, Y. (2002). Administración profesional de proyectos. La
guía. México: Mc Graw Hill.
Kerzner, H. (2009)., Project Management: A Systems Approach to
Planning, Scheduling, and Controlling (10 th Ed.) New
Jersey: John Wiley & Sons
3
Universidad privada debidamente acreditada en Costa Rica por el
Consejo Superior de Educación de las Universidades Privadas según
consta en el Art. 2 de la sesión 238-94 del 21/4/1994.
Surge como respuesta a la necesidad de contar con profesionales con
una formación inter y multidisciplinaria, poseedores de los
conocimientos, herramientas y valores para liderar los procesos de
cambio requeridos, bajo los conceptos de sostenibilidad y
globalización.
UCI cuenta con un reconocido prestigio nacional e internacional
tanto por su trayectoria académica como por su asistencia técnica a
los países.
4
Misión: Formación de profesionales líderes, capaces de inducir y
conducir los cambios requeridos en el desarrollo económico,
ambiental, socio-cultural y político de los países de América
Latina y El Caribe.
Visión: La UCI será una organización de educación superior líder en
América Latina en los campos de la investigación, la formación de
recursos humanos y la integración y desarrollo de los países de la
región.
5
Maestría en Administración de Proyectos
La Universidad para la Cooperación Internacional, ha desarrollado
el programa de Maestría en Administración de Proyectos (única en su
género en la región por su desarrollo y experiencia en AP, así como
por su fuerte componente de apoyo virtual).
La MAP incorpora los estándares y criterios del Project Management
Institute (PMI), que se ha perfilado como líder en la
administración de proyectos con más de 325,000 afiliados en todo el
mundo (octubre 2010).
La UCI es Registered Education Provider del PMI desde el año
2001.
Cuenta con el único programa de estudios certificado en LA por el
Global Accreditation Center (GAC) del PMI (desde 2009).
6
La MAP de UCI como GAC
A partir de la acreditación del GAC, la MAP entra en contacto
con otros programas de maestría y doctorado a nivel
mundial a fin de intercambiar técnicas y metodologías
académicas. Del mismo modo, provee a los profesores la posibilidad
de intercambiar ideas e investigación a nivel mundial con colegas
en la AP. Sus graduados tienen a su haber 1.500 horas de
experiencia en Administración de Proyectos que pueden ser
utilizados para completar los requisitos necesarios para ganar la
credencial de Project Management Professional (PMP®).
Los principales objetivos del sistema de acreditación del PMI
son:
Promover la profesionalización de la Administración de
Proyectos
Asegurar mejor calidad en los programas académicos de
Administración de Proyectos
Proveer estándares externos de calidad para la planificación de
programas y esfuerzos de mejora
Brindar reconocimiento por parte del PMI y GAC
Facilitar la comunicación entre escuelas y facultades.
7
8
12
Sonda espacial Mariner I (1962): falló porque la fórmula
matemática escrita en papel que debía gestionar la trayectoria del
cohete que la ponía en órbita no fue transcrita a lenguaje
informático correctamente.
Apagón en EEUU (2003): se bloquearon más de 100 plantas
eléctricas y más de 50 millones de hogares estuvieron sin
electricidad hasta que se detectó el error. ¿La solución? Instalar
la versión anterior del programa de control de las centrales de
distribución de energía eléctrica de los EEUU, el cual había sido
actualizado a una nueva versión con errores.
Acelerador médico Therac 25 (1985 – 1987): a causa de un error
de programación, se podía exponer a los pacientes a una dosis letal
de radiación. Resultado: cinco muertos.
Ejemplos de fracaso de proyectos de TI
13
Intel Pentium (1993): debido a un fallo de diseño, entre 3 y 5
millones de chips tenían un error del 0.006 por ciento a la hora de
dividir un número de punto flotante. Coste para la compañía: 475
millones de dólares.
Ataque por Ping (1995 – 1996): un “ping” es una señal que
puede lanzarse un ordenador a otro para comprobar que esta “rebota”
y vuelve, comprobando en primer lugar que la dirección destino
existe y está operativa, y en segundo el tiempo que tarda en
realizar el trayecto. Sin embargo, si se modificaba el código de
este paquete de información deliberadamente, se podía hacer que el
ordenador destino se colgase sin remisión.
Ariane 5, V501: se reutilizó un acelerómetro del predecesor,
que funcionaba con palabras de 64 bits de coma flotante, que eran
transformadas a palabras de 16 bits de tipo entero. Sin embargo, no
se tuvo en cuenta que la aceleración del Ariane 5 era bastante
superior a la del Ariane 4, por lo que los números que se
generaban, al transformarse en palabras de 16 bits, daban
información errónea al sistema. Este fallo causó el bloqueo de
ambos ordenadores de abordo y el consecuente cambio de trayectoria
y explosión final.
Ejemplos de fracaso de proyectos de TI
14
Airbus A320: en algunas primeras versiones del software de
control de los sistemas de motores del Airbus 320, y dependiendo de
la configuración de vuelo, el proceso de apagado de motores acababa
con los motores encendidos. El sistema no reconocía que estaba en
el aeropuerto de destino, por lo que decidía que todavía no tenía
que desconectar los motores y, por tanto, la única manera de
apagarlos era dejar que se acabara el combustible restante en los
depósitos.
Eurofighter: el software del avión estaba mal programado, y el
apagado manual de un motor en vuelo causaba el cierre erróneo de la
válvula de combustible, que no podía volver a ser abierta en vuelo.
Como consecuencia, el segundo motor también se apagaba y el avión
caía en picado.
Instituto Nacional contra el Cáncer, Ciudad de Panamá: un
sistema de radioterapia controlado por un programa que calculaba
las dosis de radiación adecuada en cada caso, doblaba dichas dosis
de radiación recomendada. Resultado: ocho víctimas mortales y más
de veinte personas quedaron seriamente afectadas.
Ejemplos de fracaso de proyectos de TI
15
16
PROYECTOS DE TI
En 1985 un grupo de profesionales de West Yarmouth, Massachussets
creó el Standish Group con una visión: obtener
información de los proyectos fallidos de IT. El objetivo: encontrar
(y combatir) las causas de los fracasos.
Con el tiempo, la seriedad y el profesionalismo del Standish
Group lo convirtieron en un referente mundial sobre los
factores que inciden en el éxito o fracaso de los proyectos
de IT . Sus análisis apuntan fundamentalmente a los proyectos
de software y se aplican tanto a los desarrollos como a la
implementación de paquetes ( SAP , Oracle , Microsoft ,
etc.)
A lo largo del tiempo, el Standish Group relevó 50.000 proyectos
fallidos. Así, sus conclusiones nos brindan interesantes pistas
sobre dónde poner el foco para mejorarlos. Veamos lo que ocurrió en
la última década...
17
Una gran cantidad de proyectos cancelados todos los años nos dice
que algo funciona muy mal en la ingeniería informática. ¿Qué
es?
Según una encuesta del 2004, el 71 por ciento de los proyectos de
sistemas terminan fracasando.
¿Cuál es el problema con el IT y cómo resolverlo?
PROYECTOS DE TI
El 53 % registró enormes desvíos en presupuesto y en
cronograma.
Sólo el 16 % se completó en tiempo y dentro de los costos
presupuestados (apenas nueve por ciento en el caso de grandes
empresas).
Para colmo, de la funcionalidad comprometida sólo se cumplió, en
promedio, con el 61 % (42 % en grandes empresas).
PROYECTOS DE TI
Razones del fracaso de proyectos de TI
Escasa participación de los usuarios finales (12,8%)
El usuario es quien finalmente evaluará y aprobará o desaprobará el
proyecto terminado. Se deben establecer canales y vías de
comunicación constante con el usuario para poder brindarle la mayor
información posible del avance del proyecto, para que éste pueda
valorarlo y dar su feedback, que es la base para hacer ajustes si
algo no estuviese del todo bien.
21
2) Requerimientos y especificaciones incompletas (12,3%)
La ingeniería de requerimientos cumple un papel primordial en el
proceso de producción de software, ya que enfoca un área
fundamental: la definición de lo que se desea producir. Su
principal tarea consiste en la generación de especificaciones
correctas que describan con claridad, sin ambigüedades, en forma
consistente y compacta, el comportamiento del sistema; de esta
manera, se pretende minimizar los problemas relacionados al
desarrollo de sistemas.
La ambigüedad ayuda a generar falsas expectativas y provoca enormes
pérdidas de tiempo cuando lo que se implementa es la solución
equivocada.
Razones del fracaso de proyectos de TI
22
23
3) Cambios frecuentes en los requerimientos y especificaciones
(11,8%)
Durante el proceso de construcción de un sistema de información es
común encontrarse con usuarios ávidos en añadirles nuevas
funcionalidades o características al mismo. Esto se constituye en
un factor peligroso ya que el equipo de desarrollo podría perder
días, semanas y hasta meses valiosos haciendo algo que al usuario
inicialmente no especificó. Los requerimientos de los usuarios
tienen contienen generalmente muchas ambigüedades, malos
entendidos, inconsistencias y omisiones.
Razones del fracaso de proyectos de TI
24
4) Falta de soporte ejecutivo (7,5%)
Todo proceso de cambio tecnológico genera cierto grado de oposición
en las organizaciones. En este sentido los funcionarios de mayor
rango deben estar comprometidos con este proceso y este compromiso
debe ser transmitido a los demás miembros de la organización.
Razones del fracaso de proyectos de TI
25
5) Incompetencia tecnológica (7,0%)
La incompetencia tecnológica proviene de la resistencia,
psicológica o cultural, de los usuarios para modernizar sus
procedimientos de trabajo, roles y obligaciones
organizacionales.
Razones del fracaso de proyectos de TI
26
6) Falta o recorte de recursos (6,4%)
La asignación de recursos humanos y materiales suele ser uno de los
aspectos que mas complicaciones produce. La definición y asignación
de recursos implica de hecho prever tres elementos:
Qué tipo de recursos se van a usar
En qué cantidad
Durante cuanto tiempo
Muchos proyectos grandes que fracasan lo hacen porque se reducen
sutilmente los recursos necesarios para llevarlos a cabo. Cualquier
albañil sabe que hay una proporción correcta entre cal y cemento y
que no se puede quitar un 5% de hierro a un edificio porque los
precios del acero se hayan disparado. En informática, en cambio, es
normal contratar un profesional de 3 años en experiencia en el
puesto de uno de 5. No importa convertir 9 meses en 8 o US$100.000
del presupuesto en US$90.000. Se van metiendo pequeños recortes por
todas partes, un poco de cada lado hasta que se arruina cualquier
posibilidad de éxito
Razones del fracaso de proyectos de TI
27
7) Expectativas no realistas (5,9%)
Es necesarios compartir toda la información posible con sus
clientes, evitando el uso de la jerga técnica, y ayudar a los
clientes en la descripción de sus necesidades.
Deben aclararse las percepciones de los clientes y explicitar las
limitaciones de manera frontal y honesta.
Razones del fracaso de proyectos de TI
28
8) Objetivos poco claros (5,3%)
Un principio básico en la gestión de proyectos es que los objetivos
estén definidos a priori y con un grado de suficiente de claridad y
precisión. Los objetivos generalmente son: el resultado ,
el costo y el plazo del proyecto. Estos tres
objetivos son inseparables y forman un sistema en el que cada
modificación de cada una de las partes afecta a las restantes. Dado
que la maximización individual de los tres criterios básicos no es
posible, es necesario maximizar una cierta combinación entre
ellos.
Razones del fracaso de proyectos de TI
29
9) Cronogramas irreales (4,3%)
Se deben estimar plazos realistas para cada una de las etapas del
proyecto teniendo en cuenta los recursos disponibles. Es frecuente
que los plazos se definan sin criterios técnicos
Razones del fracaso de proyectos de TI
30
10) Nuevas tecnologías (3,7%)
Observemos que de los diez factores mencionados, siete están
referidos a factores humanos (1 a 4 y 7 a 9). Si bien algunas de
las metodologías cubren temas de comunicación, manejo de conflictos
y negociación, en su abordaje se pone mucho más énfasis en los
elementos hard (duros) que en los suaves (soft). Así, muchas
metodologías cometen el error de prestigiar el contenido
procedimental por encima del conceptual. Es decir, se apunta más al
COMO que al QUE.
En este marco, para incrementar los resultados de los proyectos de
IT , es fundamental reformar la educación en sistemas, adoptando un
enfoque original y desafiante que comprenda no sólo la difusión de
metodologías, técnicas y experiencias sino también el replanteo de
varios paradigmas incorporando nuevos marcos conceptuales.
Razones del fracaso de proyectos de TI
31
Otro estudio: PROYECTOS DE TI
El 20% de las inversiones en proyectos de TI es lisa y llanamente
derrochado, asegura la consultora Gartner Group en un informe sobre
el sector corporativo europeo, que bien puede ser representativo de
la realidad internacional.
El empresariado de la región despilfarró más de 12 mil millones de
dólares en proyectos desacertados en 2001, estimación que considera
conservadora pero que sería difícil documentar.
Esta es la lista de los errores más comunes cometidos por las
empresas:
Estimaciones exageradas de las necesidades de máquinas.
Estimaciones exageradas para la capacidad que debe tener la
red.
Exigencias innecesarias de adaptación de software estándar.
Control central deficiente de las compras de software.
Inicio de proyectos que luego no son implantados, especialmente en
el segmento Internet.
http://diarioti.com/noticias/2002/abr2002/15195909.htm
32
Sonda espacial Mariner I (1962): falló porque la fórmula
matemática escrita en papel que debía gestionar la trayectoria del
cohete que la ponía en órbita no fue transcrita a lenguaje
informático correctamente.
Apagón en EEUU (2003): se bloquearon más de 100 plantas
eléctricas y más de 50 millones de hogares estuvieron sin
electricidad hasta que se detectó el error. ¿La solución? Instalar
la versión anterior del programa de control de las centrales de
distribución de energía eléctrica de los EEUU, el cual había sido
actualizado a una nueva versión con errores.
Acelerador médico Therac 25 (1985 – 1987): a causa de un error
de programación, se podía exponer a los pacientes a una dosis letal
de radiación. Resultado: cinco muertos.
Ejemplos de fracaso de proyectos de TI
33
Intel Pentium (1993): debido a un fallo de diseño, entre 3 y 5
millones de chips tenían un error del 0.006 por ciento a la hora de
dividir un número de punto flotante. Coste para la compañía: 475
millones de dólares.
Ataque por Ping (1995 – 1996): un “ping” es una señal que
puede lanzarse un ordenador a otro para comprobar que esta “rebota”
y vuelve, comprobando en primer lugar que la dirección destino
existe y está operativa, y en segundo el tiempo que tarda en
realizar el trayecto. Sin embargo, si se modificaba el código de
este paquete de información deliberadamente, se podía hacer que el
ordenador destino se colgase sin remisión.
Ariane 5, V501: se reutilizó un acelerómetro del predecesor,
que funcionaba con palabras de 64 bits de coma flotante, que eran
transformadas a palabras de 16 bits de tipo entero. Sin embargo, no
se tuvo en cuenta que la aceleración del Ariane 5 era bastante
superior a la del Ariane 4, por lo que los números que se
generaban, al transformarse en palabras de 16 bits, daban
información errónea al sistema. Este fallo causó el bloqueo de
ambos ordenadores de abordo y el consecuente cambio de trayectoria
y explosión final.
Ejemplos de fracaso de proyectos de TI
34
Airbus A320: en algunas primeras versiones del software de
control de los sistemas de motores del Airbus 320, y dependiendo de
la configuración de vuelo, el proceso de apagado de motores acababa
con los motores encendidos. El sistema no reconocía que estaba en
el aeropuerto de destino, por lo que decidía que todavía no tenía
que desconectar los motores y, por tanto, la única manera de
apagarlos era dejar que se acabara el combustible restante en los
depósitos.
Eurofighter: el software del avión estaba mal programado, y el
apagado manual de un motor en vuelo causaba el cierre erróneo de la
válvula de combustible, que no podía volver a ser abierta en vuelo.
Como consecuencia, el segundo motor también se apagaba y el avión
caía en picado.
Instituto Nacional contra el Cáncer, Ciudad de Panamá: un
sistema de radioterapia controlado por un programa que calculaba
las dosis de radiación adecuada en cada caso, doblaba dichas dosis
de radiación recomendada. Resultado: ocho víctimas mortales y más
de veinte personas quedaron seriamente afectadas.
Ejemplos de fracaso de proyectos de TI
35
36
37
38
39
Mi casa como la ve el que me la financia…
40
41
“Le dije que quiero un balcón…”
42
“y una rampa para el garage…”
43
“y una escalera eléctrica…”
44
Falta de claridad en los requerimientos y acuerdos del alcance del
proyecto y de su producto.
Falta de identificación de los involucrados del proyecto y sus
requerimientos.
Razones del fracaso de proyectos de I & A
45
¿Consideramos las condiciones externas del proyecto
previamente?
46
¿Consideramos las condiciones externas del proyecto
previamente?
47
Razones del fracaso de proyectos de I & A
48
Razones del fracaso de proyectos de I & A
¿Tuvimos una buena comunicación entre todos los involucrados en el
proyecto?
49
Razones del fracaso de proyectos de I & A
¿Tuvimos una buena comunicación entre todos los involucrados en el
proyecto?
50
Este edificio de 13 pisos en la ciudad de Shanghai, que simplemente
se cayó de medio lado y quedó enterito
Razones del fracaso de proyectos de I & A
¿Se diseñó bien el producto?
51
¿Se diseñó bien el producto?
52
Razones del fracaso de proyectos de I & A
53
55
¿Y la calidad?
¿Y la calidad, cómo la establecimos?
57
Se hacen tres tipos de trabajo: bueno, barato o rápido.
Si es bueno, no va a ser barato ni rápido;
Si es rápido no va a ser bueno ni barato;
Si es barato, no va a ser bueno ni rápido.
Razones del fracaso de proyectos de I & A
58
Caso No. 1
Cuando la NASA comenzó con el lanzamiento de astronautas al
espacio, descubrieron que los bolígrafos no funcionarían sin
gravedad (o con gravedad cero), pues la tinta no bajaría hasta la
superficie en que se deseara escribir.
Solución A): Resolver este problema, les llevó 6 años y 12 millones
de dólares. Desarrollaron un bolígrafo que funcionaba: bajo
gravedad cero, al revés, debajo del agua, prácticamente en
cualquier superficie incluyendo cristal y en un rango de
temperaturas que iban desde abajo del punto de congelación hasta
superar los 300 grados centígrados.
Solución B): ¿Y qué hicieron los rusos? ¡Los rusos utilizaron un
lápiz!
Razones del fracaso de proyectos de I & A
¿Cómo encontramos las causas de los problemas?
59
Caso No. 2
Uno de los más memorables casos de estudio de la gestión japonesa
fue el caso de la caja de jabón vacía, que ocurrió en una de las
más grandes empresas de cosmética de Japón. La compañía recibió la
queja de un consumidor que compró una caja de jabón y estaba
vacía....
Inmediatamente las autoridades aislaron el problema a la cadena de
montaje, que transportaba todas las cajas empaquetadas de jabón al
departamento de reparto. Por alguna razón, una caja de jabón pasó
vacía por la cadena de montaje. Los altos cargos pidieron a sus
ingenieros que encontraran una buena y rápida solución del
problema.
Solución A): De inmediato, los ingenieros se lanzaron a su labor
para idear una máquina de rayos X con monitores de alta resolución
manejados por dos personas y así vigilar todas las cajas de jabón
que pasaran por la línea para asegurarse de que no fueran vacías.
Sin duda, trabajaron duro y rápido.
Solución B): Cuando a un empleado común en una empresa pequeña se
le planteó el mismo problema, no entró en complicaciones de rayos
X, robots, equipos informáticos o complicados; en lugar de eso
planteó otra solución: Compró un potente ventilador industrial y lo
apuntó hacia la cadena de montaje. Encendió el ventilador, y
mientras cada caja pasaba por el ventilador, las que estaban vacías
simplemente salían volando de la línea de producción.
¿Cómo encontramos las causas de los problemas?
Razones del fracaso de proyectos de I & A
60
Caso No. 3
Un magnate hotelero viajo a una ciudad Hindú por segunda vez a un
año de distancia de su primer viaje, al llegar al mostrador de un
hotel inferior en estrellas a los de su cadena, el empleado le
sonríe y lo saluda diciéndole: Bienvenido nuevamente señor, que
bueno verlo de vuelta en nuestro hotel; sorprendido en gran manera
ya que a pesar de ser una persona tan importante, le gusta el
anonimato y difícilmente el empleado tendría tan buena memoria para
saber que estuvo allí un año antes, quiso imponer el mismo sistema
en su cadena de hoteles ya que ese simple gesto lo hizo sentir muy
bien. A su regreso inmediatamente puso a trabajar en este asunto a
sus empleados para encontrar una solución a su petición.
Solución A): La solución fue buscar el mejor software con
reconocimiento de rostros, base de datos, cámaras especiales,
tiempo de respuesta en micro segundos, capacitación a empleados,
etc. Etc. Con un costo aproximado de 2.5 millones de dólares.
Solución B): El magnate prefirió viajar nuevamente y sobornar al
empleado de aquel hotel para que revelara la tecnología que
aplican. El empleado no acepto soborno alguno, sino que
humildemente comento al magnate como lo hacían, el dijo: "mire
señor, tenemos un arreglo con los taxistas que lo trajeron hasta
acá, ellos le preguntan si ya se ha hospedado en el hotel al cual
lo está trayendo, y si es afirmativo, entonces cuando el deja su
equipaje aquí en el mostrador, nos hace una señal, y así se gana un
dólar".
Razones del fracaso de proyectos de I & A
¿Cómo encontramos las causas de los problemas?
61
Moraleja
¡No complique su trabajo! ; conciba la solución más simple al
problema; aprenda a centrarse en las soluciones, ¡no en los
problemas!
62
63
Algunos de los problemas típicos que se cometen al planificar
son:
a) No incluir todos los recursos necesarios para cumplir con los
objetivos del proyecto.
b) No dar participación en la elaboración del plan a las personas
responsables de implementar esas tareas
c) Objetivos o agendas irreales al no comprender la ‘restricción
triple’ (alcance, tiempo y costo)
d) Falta de establecer métricas de ejecución y desempeño contra
tiempo y costo.
Razones del fracaso de proyectos sociales
64
Causas que inciden en el fracaso de un proyecto son errores en su
administración:
a) El rol del administrador del proyecto no está bien
definido
b) Falta de comunicación y coordinación para trabajar en
equipo
c) Rotación excesiva de personas en las actividades de trabajo.
Menor especialización
d) Controles inapropiados
e) No realizar informes de avance periódico
f) El administrador del proyecto pierde la visión de conjunto
controlando detalles minuciosos
g) No comparar el estado del proyecto con el plan original
h) No planificar la administración de los riesgos potenciales
Razones del fracaso de proyectos sociales
65
Optimismo General
Iniciamos con la esperanza de algo nuevo y con buenos
augurios
Desorientación Inicial
No sabemos por donde empezar, tenemos muchas ganas e iniciamos con
lo que consideramos más urgente, pero postergamos lo
importante.
Período de Desorden Incontrolado
La ejecución está en su máximo, contratamos a los diferentes
proveedores y no todos cumplen como dijeron. El alcance sigue sin
definirse y cambia frecuentemente.
Alarma y Caos, el Tiempo No es Aliado
No cumplimos las fechas de entrega, seguimos recibiendo cobros por
trabajos no considerados y el presupuesto y el presupuesto se agoto
cuando aún no hemos logrado ni el 70% de avance. Además, hay
problemas con la calidad de los trabajos efectuados.
67
Castigo Ejemplar a los Inocentes
Despedimos a los proveedores e integrantes que menos culpa
tienen.
Recuperación del Optimismo Perdido
Ahora sí, ya eliminamos a los supuestos malos y encontramos el
segundo aliento.
Terminación del Proyecto a como dé lugar
Trabajos forzados, unos encima de otros, noches, tiempo extra,
sábados y domingos, desgaste, presión, promesas y más
presión.
Condecoración y Premios a los No Participantes
El equipo ejecutor está muy cansado y terminando los últimos
pendientes, y los no participantes, frescos para adjudicarse el
mérito, levantarse el cuello y recibir los elogios.
68
El alcance no es claro y se presta a ambigüedades.
No representa la solución técnica de las necesidades del cliente
sino las preferencias del encargado del proyecto.
No está completo y/o validado por el cliente antes de iniciar la
ejecución del proyecto.
No tiene la aprobación formal de la persona con la responsabilidad
y autoridad requerida por el el proyecto.
No incluye la estructura del equipo de trabajo.
No se le da seguimiento, los cambios no son aprobados formalmente
por las partes antes de procederse a ejecutarlos.
69
¿Porqué fracasan los proyectos? El manejo del tiempo
No es realista y responde a deseos más que a juicio y datos.
Las actividades no tienen tamaños adecuados para darle seguimiento
(ni tan pequeñas que incluyan tareas no relevantes ni tan grandes
que no puedan estimarse adecuadamente).
No se establece formalmente un cronograma base que se antes de la
ejecución del proyecto.
No se acuerdan cambios en el cronograma base entre el cliente y los
ejecutores.
70
No se definen los costos basados en el alcance del trabajo.
No se definen los costos basados en el diseño del trabajo.
Se inician trabajos sin tener asegurado el contenido presupuestario
para terminar la fase o el proyecto.
El presupuesto no es aprobado antes de iniciar por la autoridad
competente.
No se les da seguimiento en la etapa de ejecución a través de
indicadores de rendimiento y otros que se acuerden.
¿Porqué fracasan los proyectos? El manejo de los costos
71
No existe un procedimiento de aseguramiento de la calidad.
No se mide la calidad continuamente sino sólo al inicio y al final
del proyecto.
Los términos de definición de la calidad son subjetivos y no se
pueden medir.
Se acepta la terminación de fases, entrega de productos o
subproductos y aún del proyecto sin completar la verificación de la
calidad. No se definen períodos de prueba en el alcance del
proyecto.
¿Porqué fracasan los proyectos? El manejo de lo calidad
72
No se planea ni se documenta la estructura formal de comunicación
entre las diferentes grupos participantes en el proyecto.
No se da como un proceso continuo de inicio a fin.
No se define la frecuencia de la reuniones y los resultados de las
mismas no se documentan.
No se comunican a todas las partes involucradas los cambios al
alcance, al cronograma o al presupuesto.
¿Porqué fracasan los proyectos? La gestión de la comunicación
73
No se conforma un equipo de proyecto de acuerdo con las necesidades
del trabajo a realizar y las capacidades de los integrantes.
No se asignan formalmente los roles y responsabilidades de cada
miembro del equipo del proyecto.
No se establece una estructura formal jerárquica que prevea los
conflictos entre las estructuras funcionales de la organización y
los requerimientos del gerente del proyecto.
¿Porqué fracasan los proyectos? La gestión de los recursos
humanos
74
No se planean las adquisiciones de bienes y servicios con
suficiente tiempo de antelación.
No se vinculan las adquisiciones con los entregables del proyecto,
con los flujos de caja ni el cronograma del proyecto.
No se estudia y se decide qué se va a hacer por el equipo y qué se
va a contratar.
No se establecen documentos apropiados, de acuerdo a los
requerimientos y alcance establecido para el proyecto, para
solicitar ofertas ni se establecen criterios de selección objetivos
y formales.
No se realizan procesos de cierre de contrato contra verificación
del alcance y calidad de los entregables.
¿Porqué fracasan los proyectos? La gestión de los
abastecimientos
75
No se estiman las oportunidades y amenazas del proyecto en los
procesos de planificación.
No se planean las medidas de mitigación, transferencia, asunción y
evitación de riesgos (planeación de contingencias).
No se le da seguimiento a los factores de riesgo en la ejecución
del proyecto.
¿Porqué fracasan los proyectos? La gestión de los riesgos
76
No se administran los cambios antes de que se ejecuten.
No se documentan o comunican los cambios de alcance, calidad, costo
y tiempo a los involucrados en el proyecto
No se lleva cuenta de lecciones aprendidas en el proyecto, los
cuales representan valiosos activos organizacionales si se
registran y se ponen a disposición de los demás miembros de la
organización.
¿Porqué fracasan los proyectos? La gestión de la integración del
proyecto
77
78
79
PMBOK®
Es un estándar en la Gestión de proyectos desarrollado por el
(PMI). Comprende dos grandes secciones, la primera sobre los
procesos y contextos de un proyecto, la segunda sobre las áreas de
conocimiento específico para la gestión de un proyecto.
EL PMBOK se encuentra disponible en 11 idiomas: inglés, español,
chino simplificado, ruso, coreano, japonés, italiano, alemán,
francés, portugués de Brasil y árabe.
80
PMBOK
El 'PMBOK' reconoce 5 grupos de procesos básicos y 9 áreas de
conocimiento comunes a casi todos los proyectos.
Los procesos se traslapan e interactúan a través de un proyecto o
fase.
Los procesos son descritos en términos de: Entradas (documentos,
planes, diseños, etc.), Herramientas y Técnicas (mecanismos
aplicados a las entradas) y Salidas (documentos, productos, etc.).
Las nueve áreas del conocimiento mencionadas en el PMBOK son:
Gestión de la Integración Gestión del Alcance
Gestión del Tiempo Gestión de la Calidad
Gestión de Costos Gestión del Riesgo
Gestión de Recursos Humanos Gestión de la Comunicación
Gestión de las Compras y Adquisiciones
81
¿Qué es un Proyecto?
Es un esfuerzo temporal que se lleva a cabo para crear un producto,
servicio o resultado único.
Características
Finaliza cuando:
La necesidad ya no existe.
Producto, Servicio o Resultado Único.
Elaboración Progresiva: paso a paso.
Marco Conceptual de la Dir.de Proyectos
82
Lanzamiento transbordador NASA
Construir un bote
Construir un hospital
Organizar olimpiadas
83
Operaciones en curso:
Ejemplos:
Una compañía de seguros procesa miles de reclamos al día.
Un cajero atiende a 100 clientes por día.
Planta de automóviles produce miles de vehículos, del mismo modelo
y con opciones limitadas.
Operativa normal de la oficina
84
En la actualidad, los preceptos básicos de la administración de
proyectos están representados por el triángulo del proyecto, un
símbolo que popularizó Harold Kerzner en su obra de referencia,
Project Management: A Systems Approach to Planning, Scheduling, and
Controlling.
85
86
Aplicación de la Administración de Proyectos
La matriz de esta filmina, explica la relación que existe entre las
áreas del conocimiento y sus grupos de proceso.
Al centro, las bolitas de colores indica cuales grupos de proceso
se desarrollan en cuales áreas del conocimiento (ver pag. 70 de
PMBoK version 2004 o filmina siguiente)
01/12/2010
-XSC-
88
-XSC-
Iniciación
Planificación
Ejecución
Control
Cierre
Integración
Identificar, definición, combinación, unión y coordinación de los
procesos del
proyecto
Alcance
Asegurar que se incluya todo el trabajo requerido y solo el
requerido para
completar el proyecto satisfactoriamente
Presupuesto
Calidad
Asegurar que el proyecto satisfaga las objetivos por los cuales fue
emprendido
Gente
Comunicación
final de la información del proyecto en tiempo y forma
Riesgo
Identificación, análisis, respuesta, seguimiento y control de los
riesgos del
proyecto.
Adquisiciones
Procesos requeridos para la adquisición de bienes y servicios para
el proyecto
01/12/2010
-XSC-
89
01/12/2010
-XSC-
91
Ciclo PHVA Concepto subyacente a la interacción de los
procesos
planificar
revisar
actuar
hacer
Sheward/
Demming
Como se trata de un proceso finito: los procesos de iniciación
inician el ciclo y los de cierre lo terminan.
01/12/2010
-XSC-
92
01/12/2010
-XSC-
92
01/12/2010
-XSC-
93
Las fases en un proyecto se traslapan, es decir, no deben terminar
para qu otras fases comiencen.
Generalmente los proyectos se dividen en fases.
El conjunto de estas fases, dependiendo de la empresa y el proyecto
van a resultar en el ciclo de vida del proyecto.
Las fases se definen de acuerdo al trabajo técnico a realizar, a
las fechas en las que se deben presentar entregables, los
involucrados o bien de acuerdo a cómo y quién debe aprobar cada
una.
Ciclo de vida de un proyecto
94
Características comunes:
Fases secuenciales con algún nivel de transferencia de información
entre ellas.
Los factores de costo y recursos humanos son bajos al inicio, llega
al máximo en las etapas intermedias y vuelve a decaer en la etapa
de cierre.
La incertidumbre es más alta al inicio del proyecto, se va
disminuyendo a lo largo del mismo.
El grado de influencia de los interesados en el proyecto es más
crítico al inicio del mismo.
El costo de los cambios y corrección de errores aumenta conforme
avanza el proyecto.
Ciclo de vida de un proyecto
95
Iniciación (Initiation) 11%
Planeamiento (Planning) 23%
Ejecución (Executing) 27%
Cierre (Closing) 9%
96
Son procesos que se dan varias veces durante el transcurso de un
proyecto.
Se repiten en cada etapa del proyecto: Ej.
Formulación y evaluación (factibilidad)
97
Alcance: Lo que incluye y lo que no incluye el proyecto.
Tiempo: Programación, calendario, entregas parciales y
totales.
Costo: Estimaciones, presupuestos, flujos de gastos y
recuperaciones.
Calidad: Definición del producto o servicio, estándares, modo de
cumplimiento y requerimientos.
Recursos humanos: Equipo de proyecto, roles y funciones.
Áreas por considerar en la Administración de Proyectos
98
Riesgo: Amenazas y oportunidades. Planes de contingencia y
mitigación.
Abastecimiento: Estrategias de contratación, concursos,
cotizaciones, administración de contratos.
Integración: Administración de cambios, lecciones aprendidas,
adecuada integración de áreas.
Áreas por considerar en la Administración de Proyectos
99
Adopt a project management methodology and use it
consistently.
Implement a philosophy that drives the company toward project
management maturity and communicate it to everyone.
Commit to developing effective plans at the beginning of each
project.
Minimize scope changes by committing to realistic objectives.
Recognize that cost and schedule management are inseparable.
Select the right person as the project manager.
Provide executives with project sponsor information, not project
management information.
Strengthen involvement and support of line management.
100
Focus on deliverables rather than resources.
Cultivate effective communication, cooperation, and trust to
achieve rapid project management maturity.
Share recognition for project success with the entire project team
and line management.
Eliminate nonproductive meetings.
Focus on identifying and solving problems early, quickly, and cost
effectively.
Measure progress periodically.
Use project management software as a tool—not as a substitute for
effective planning or interpersonal skills.
Institute an allemployee training program with periodic updates
based upon documented lessons learned.
101
CONCLUSIÓN
Puesto que el mundo está cada vez más interconectado y los negocios
son más complejos y dinámicos, el trabajo tiene que estar cada vez
más lleno de aprendizaje
Ya no basta tener a una persona aprendiendo para la organización.
Ya no es posible “resolver” desde arriba, y hacer que los demás
sigan las órdenes del “gran estratega”. Las organizaciones que
realmente destacarán en el futuro, serán aquellas que descubran
cómo aprovechar el compromiso de todos los miembros de la
organización (sea cual sea su nivel), y su capacidad para
aprender
Peter Senge
102
CONCLUSIÓN
Las mejores organizaciones empujan a sus profesionales más allá del
confort de su conocimiento actual.
Quinn, J. B.; Aderson, P.; Finkelstein,
S.Harvard Business Review, Vol 74, N°2, 1996
103
104
Comienzo
Final
Tiempo
Procesos de