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