1. Gestión de Proyectos
(Basado en PMBOK)
Algunas imágenes son aporte del académico Luis Hevia (UTFSM)

2. Indice














Presentación
Origen
¿Qué?
Dimensiones
Errores
Conflicto de los requerimientos
Crisis de proyectos
Claves para el éxito
Introducción a EPM
PMBOK
Mapa mental de PMBOK
Estándares de documentación
Conclusiones
Bibliografía Recomendada

3. Origen

Históricamente relacionada con proyectos de ingeniería de construcción
de obras civiles (como los proyectos de ingeniería hidráulica en
Mesopotamia, donde entraban en juego la logística o la creación de
equipos de trabajo, con sus categorías profesionales definidas.

La cultura ingenieril desarrollada por el Imperio Romano, donde aparece
el control de costos y tiempos y la aplicación de soluciones
normalizadas, como por ejemplo en la construcción de una calle).

En “campañas militares”, donde también entran en juego muchos
elementos de gestión (identificación de objetivos, gestión de recursos
humanos, logística, identificación de riesgos, financiación, etc.).

……. a partir de la Segunda Guerra Mundial cuando el avance de estas
técnicas desde el punto de vista profesional han transformado la
administración por Proyectos en una disciplina de investigación.

4. ¿Qué es?
 PROYECTO
Conjunto de actividades interdependientes
orientadas a un fin específico, con una duración establecida.
 ¿Qué significa terminar con éxito un proyecto?


Cumplir con los objetivos dentro de las especificaciones
técnicas, de costo y de plazo de término.
A un conjunto de Proyectos orientados a un
objetivo superior se denomina PROGRAMA, y un
conjunto de Programas constituye un PLAN.
 Responder al ¿Qué? ¿Cómo? ¿Porqué?


5. Dimensiones

Dimensión técnica:
 Aplicar los conocimientos específicos de cada área de trabajo, cumpliendo con
una forma de trabajar y unos requisitos ("know how") que cada profesión
impone.
 Disponer de los conocimientos adecuados para resolver el problema en cuestión
o realizar la obra encomendada.
 La importancia de esta faceta técnica no debe eclipsar el resto de aspectos que
intervienen en la consecución de un proyecto, y que otorgan a esta actividad de
una trascendencia y complejidad mayor.

Dimensión humana:
 Un proyecto es un complejo entramado de relaciones personales, donde se dan
cita un gran número de intereses a veces contrapuestos.
 Regularmente existen diferencias que surgen por ejemplo entre el jefe de
proyecto y cliente o proveedores.
 Disputas entre departamentos al momento de repartir los recursos de que se
dispone, pues son varios los proyectos que se pueden estar llevando a cabo
paralelamente en la organización.

6. Dimensiones
 Dimensión
gestión:
 Dimensión menospreciada porque no es tan
espectacular o visible como otros
elementos
 “Lamentablemente” es el catalizador que
permite que el resto de los elementos se
comporten adecuadamente.
 El éxito del proyecto depende en gran
medida de la gestión.

7. Errores
 Usado
sin modificar:
 Usado con cambios:
2%
3%
 Nunca
47%
30%
18%
usado:
 Pagado, pero nunca usado
 Rehecho, y abandonado:

8. Fuentes de Errores
 por
Requerimientos:
 por Diseño:
 de Programación:
 Otros:
56%
27%
7%
10%
¿Dónde concentrar el esfuerzo
para evitar los errores?

9. El Conflicto de los Requerimientos













Exageración al ámbito del Sistema.
Sistemas “Monstruosos”.
... “por si Acaso” .
… “es fácil”
... los nuevos requerimientos.
... los últimos requerimientos.
Estabilidad de lo solicitado.
El involucramiento del Usuario.
La falta de preparación del Usuario.
La revisión de Informes.
La Recepción Conforme.
Experiencia de la Institución.
El nivel de desconocimiento en el tema.

10. Crisis de Proyectos 1
 Alto
nivel de error en la estimación de recursos
y plazos de entrega.
 Mala calidad en las tareas de Especificación,
Análisis y Diseño.
 Enormes esfuerzos dedicados a la mantención
del sistema.
 Alternativa: un proceso de desarrollo inflexible
 Dificultad para manejar los cambios.

11. Crisis de proyectos 2
 Proceso
de desarrollo lento e intensivo
en mano de obra, que lo hace
descontrolado e impredecible
 Malos niveles de comunicación entre
analistas y usuarios finales.
 Los proyectos informáticos están insertos
en un mundo dirigido por un mercado,
caótico (time to market) y humano.

12. Errores relacionados con las personas
 Escasa motivación.
 Personal mediocre.
 Empleados problemáticos descontrolados.
 Confiar en las Hazañas.
 Añadir más personal a un proyecto retrasado (brooks)
 Oficinas repletas y ruidosas.
 Síndrome del “only you”.
 Fricciones entre los clientes y la parte técnica.
 Expectativas poco realistas.
 Falta de un promotor efectivo del proyecto.
 Falta de participación de los implicados (stakeholder).
 Consideraciones de Política antes que desarrollo.
 Ilusiones.

13. Errores relacionados con el proceso.














Planificación excesivamente optimista.
Gestión de riesgos insuficiente.
Falla de los sub-contratistas
Planificación insuficiente.
Abandono de la planificación bajo presión.
Pérdida de tiempo en el inicio difuso (cuidado con la parálisis del
análisis).
Escatimar en las actividades iniciales.
Diseño inadecuado.
Escatimar en el control de calidad.
Control insuficiente de la dirección
Convergencia prematura o excesivamente frecuente.
Omitir tareas necesarias en la estimación.
Planificar ponerse al día más adelante.
Programación a destajo.

14. Errores relacionados con el producto y la
tecnología
 Exceso de requerimientos.
 Cambio de las prestaciones.
 Desarrolladores muy
meticulosos.
 Desarrollo más orientado a
la investigación.
 Tiras y aflojas en la
negociación.
 Síndrome de la panacea (o
de la bala de plata).
 Sobreestimación de las
ventajas del empleo de
nuevas herramientas o
métodos.
 Cambiar de herramientas a
mitad del proyecto.
 Falta de control automático
para versiones del código
fuente.

15. Claves para el éxito (1)

Jefes de Proyecto competentes es el primer paso para la mejora de los
resultados de los proyectos.

Un Jefe de Proyecto debe ser un buen Líder y un miembro del equipo. Pero no
sólo eso. También debe ser un excelente creador de equipos. Un Equipo de
Gestión de Proyectos tiene una posibilidad mucho más alta de asegurar que se
cumplirán los Objetivos.

Un Modelo de Proyectos es clave para repetir el éxito en proyectos, especialmente
si estos se desarrollan en sitios diferentes y/o se dividen en varias partes debido a
su tamaño. Por lo tanto, una documentación y terminología de gestión de
proyectos uniforme pasa a ser vital. La utilización del PMI PMBOOK es un
primer paso firme.

Es absolutamente necesario tener un Entorno de Proyectos positivo para que un
proyecto tenga éxito. El entorno se compone:





De los proyectos.
De los responsables.
De los métodos, procesos y herramientas,
De la gestión de requisitos,
De la gestión del negocio, etc.

16. Claves para el éxito (2)

Es muy importante aclarar las responsabilidades entre los diferentes roles
involucrados en un proyecto, para así conseguir un entorno eficiente para los
proyectos.

Para que un proyecto tenga éxito también son claves la gestión de riesgos y el
manejo de problemas.

A menos que realice una buena gestión de requisitos no podrá estar seguro de que
el proyecto cumplirá las expectativas de su cliente.

Las Herramientas de Gestión de Proyectos son buenas y útiles pero no son la
solución a los problemas de la gestión de proyectos. Todos los proyectos deberían
enfocarse en la integración para disminuir los tiempos de entrega. ¡El modelo en
cascada ha quedado obsoleto!

La Comunicación es clave para el éxito de los proyectos. Para todos los proyectos se
debería hacer un plan para todos los proyectos que abarque la comunicación tanto
interna como externa del proyecto.

El Jefe de Proyecto debería tener una perspectiva global, ser "el helicóptero", que
vuela sobre el proyecto y que aterriza cuando sea necesario llevar a cabo acciones.

17. ¿Qué es un Proyecto?
COSTO
ALCANCE
TIEMPO

18. ¿Cuál es el centro del Proyecto?
COSTO
ALCANCE
CALIDAD
TIEMPO

19. ¿Qué es EPM (Enterprise Project
Management)?
Solución
para quienes
necesiten coordinación y
estandarización entre los
proyectos y los
administradores de
proyectos, administración
centralizada de los
recursos o un mayor nivel
de creación de informes
acerca de los proyectos.
Strategy
People
EPM
Technology
Process

20. EPM mejora los procesos en la empresa.


Más del 94% de los
encuestados responden que
están implementando Project
Management para agregar
valor a sus organizaciones.
Muchas organizaciones de
todos los tamaños e
industrias, informan que ha
mejorado gracias al Project
Management.
Return on
Investment
25%
Productivity
15%
Time to Market
15%
Project/Process
Performance
20%

21. Enterprise Project Management
Alineamiento
estratégico para
administración de
proyectos
empresariales

22. Buenas Prácticas (PMBOK)
 PMBOK
(Project Management Body of
Knowledge)
 Contiene prácticas que han sido compiladas y
mejoradas durante los últimos veinte años
gracias al esfuerzo de profesionales y
académicos de diversos ámbitos de ingeniería.
 Es uno de los más importantes documentos
publicados en la actualidad por el Project
Management Institute que produce documentos
y prácticas generalmente aceptadas de
dirección y de gestión de proyectos.

23. PMBOK e Ingeniería de Software
 ¿Porque
PMBOK?
 Aporta todas las
bases para una
gestión adecuada
independiente de
la ingeniería o
construcción.
 SEI
y la Ing de
Software  aportan
los instrumentos de
trabajo básicos de
todo desarrollo de
software.
 SEI
Software
Engineering Institute

http://www.sei.cmu.edu

24. El proyecto: su crudeza y realidad

25. Las dimensiones del proyecto
El proyecto
GESTION
CONSTRUCCION

26. Dimensión de construcción
trabajo en
equipo
herramientas
mando
Sistema
ofrecido
administración
Diagramación-planos
Sistema
deseado
trabajo físico-intelectual
organización
de materiales

27. Dimensión de gestión
trabajo colaborativo
Negociación
Resolución de conflictos
reflexión
herramientas
diseño
Sistema
deseado
Sistema
ofrecido
organización de datos
intervención

28. Gestión de Proyectos
 “La
aplicación del conocimiento,
herramientas y técnicas a las actividades
de un proyecto para satisfacer los
requerimientos del proyecto” (PMI).
 Actuación predictiva, anticiparse o
sencillamente no olvidar errores
pasados.

29. Un proceso gestionado
Padrón de
organización

30. Un proceso gestionado
métricas
ti
criterios de
entrada
$$$$
ti+1
condiciones
de salida

31. La dimensión de gestión

32. La necesidad de gestión en
informática: Causas

Naturaleza del
producto:





intangible
invisible
complejo
Volátil
difícil de medir

Problemas de gestión:




objetivos y especificaciones
pobremente definidas
falta de un plan de proyecto
presupuestos y plazos poco
realistas
inhabilidades en el trato
social

33. Buenas prácticas tradicionales




Segmentación - el proyecto debe ser separado en un
número manejable de actividades y tareas.
Interdependencia – la planificación debe reflejar la
segmentación de tareas, y la relaciones entre ellas.
Hay algunas tareas ocurren en secuencia, otras en
paralelo, algunas son requisito de otras, etc.
Asignación de tiempo - a cada tarea se le debe
asignar un cierto número de unidades de trabajo
(personas-días, etc) y fechas de inicio y término.
Validación del esfuerzo – se debe verificar que la
gente asignada a una tarea esté disponible y además
que sea suficiente.

34. Buenas prácticas tradicionales

Definición de responsabilidades - cada tarea debe
tener un responsable.

Salida definida - cada tarea debe tener un “producto”
bien definido. Por ejemplo: diseño de un módulo, plan
de pruebas, etc.

Definición de metas - cada grupo de tareas se debe
estar asociado con una meta.

35. PMBOK

36. Estructura de componentes del
PMBOK
grupo de
procesos
área de
conocimiento
_pertenece_
_agrupa_
proceso de
gestión

37. Etapas del proceso de gestión
Iniciación
Planificación
Control
Ejecución
Cierre
 Cada etapa se compone de varios procesos de
gestión

38. Etapas del proceso de gestión=
grupos de procesos
Iniciación
Planificación
Control
Ejecución
Error fatal: pensar
que esto es el proyecto
Cierre

39. Límites del Proyecto

40. Áreas de conocimiento
Describen los conocimientos y las prácticas de la
dirección de proyectos que toda gestión de
proyectos “debe gestionar”.
área de
conocimiento
grupo de
procesos
_pertenece_
_agrupa_
proceso de
gestión

41. Estructura del PMBOK
Project Management
Knowledge Areas
Integration
Scope
Time
Cost
Quality
Human Resources
Communications
Risk
Procurement
área de
conocimiento
Project Management
Processes
_pertenece_
Management
Processes Groups
Initiation (IP)
Planning (PP)
Executing (EP)
Control (CoP)
Closing (ClP)
grupo de
procesos
proceso de
gestión
_agrupa_

42. Áreas de Experiencia
Áreas de experiencia que necesita el
equipo de dirección del proyecto

43. Áreas de Conocimiento (y previas)
4. Gestión de Integración del Proyecto
 5. Gestión del Alcance del Proyecto
 6. Gestión de Tiempos del Proyecto
 7. Gestión de Costos del Proyecto
 8. Gestión de la Calidad del Proyecto
 9. Gestión de los Recursos Humanos del Proyecto
 10. Gestión de las Comunicaciones del Proyecto
 11. Gestión de Riesgos del Proyecto
 12. Gestión de las Adquisiciones del Proyecto


44. 4. Gestión de la Integración
 Gestión
de la
Integración (4)
incluye los procesos
requeridos para
asegurar que todos
los diversos
elementos del
proyecto están
coordinados de
manera propia

45. 5. Gestión del Alcance
 Gestión
del
Alcance (5) incluye
los procesos
requeridos para
asegurar que el
proyecto contiene
todo el trabajo
necesario y sólo el
trabajo necesario,
para completar el
proyecto con éxito

46. 5. Gestión del Alcance
Estructura de
deglose de
trabajo (EDT)

47. 5. Gestión del Alcance (ej.1)
Ejemplo de estructura de desglose de trabajo organizada por
fases

48. 5. Gestión del Alcance (ej.2)
Ejemplo de estructura de desglose de trabajo para artículos de
materiales de defensa.

49. 6. Gestión de Tiempos
 Gestión
del tiempo
(6) incluye los
procesos necesarios
para asegurar la
completitud del
proyecto a tiempo

50. 6. Gestión de Tiempos (ej.)

51. 6. Gestión de Tiempos (ej.)

52. 7. Gestión de Costos

Gestión del Costo (7)
incluye los procesos
necesarios para
asegurar que el
proyecto sea
terminado dentro del
presupuesto aprobado

53. 7. Gestión de Costos (ej.)

54. 8. Gestión de la Calidad
 Gestión
de la
Calidad (8) incluye
los procesos
requeridos para
asegurar que el
proyecto dé
satisfacción a las
necesidades que lo
definieron.

55. 9. Gestión de los Recursos Humanos
 Gestión
de los
Recursos Humanos
(9) incluye los
procesos necesarios
para realizar el uso
más efectivo de las
personas
involucradas en el
proyecto.

56. 10. Gestión de las Comunicaciones

Gestión de las Comunicaciones
(10) incluye los procesos
requeridos para asegurar la
apropiada, y a tiempo,
generación, colección,
diseminación, almacenamiento
y últimas disposiciones de la
información del proyecto.

57. 10. Gestión de las Comunicaciones
 La
importancia del Lenguaje.
 Evitar intermediarios.
 Implementación de línea abierta.
 Reuniones documentadas y efectivas
(scrum)

58. 11. Gestión de Riesgos
 Gestión
del Riesgo
(11) es el proceso
sistemático de
identificar, analizar
y responder a los
riesgos del
proyecto

59. 12. Gestión de las Adquisiciones

Gestión del
Aprovisionamiento (12)
incluye los procesos
requeridos para adquirir
los bienes y servicios,
para lograr el alcance del
proyecto, desde fuera de
la organización
realizadora”

60. Estructura de componentes del
PMBOK
grupo de
procesos
área de
conocimiento
_pertenece_
_agrupa_
proceso de
gestión

61. Procesos de Gestión de Proyectos
 Los
procesos de gestión de proyectos:
Contienen las “mejores prácticas” de gestión
 Se pueden adaptar a cada disciplina, pero sin dejar
de lado la esencia de su singularidad y del conjunto
 Se describen en el PMBOK en función de entradas,
salidas, y herramientas/técnicas involucradas en
transformar las entradas en salidas.


62. Procesos de Gestión de Proyectos
Inputs/Outputs
Project Charter
Project Plan
Work Results
Lessons Learned
Performance Report
Historical Information
Organizational policies
Constraints
Assumptions
Etc.
Project Management
Processes
Entradas/Salidas
_son_parte_de_
Methods/Tools
Earned Value Technique
Work Authorization System
Organizational Procedires
Gantt/CPM
WBS
Etc.
proceso de
gestión
Métodos/Herramientas
_ son_parte_de _

63. Mapa mental de PMBOK

64. Estándares de Documentación
 Prince2
 ESA
 RUP
 MSF

65. Conclusiones
 Las
personas son lo más importante.
 La gestión marca el éxito y/o fracaso de un
proyecto.
 Para llevar a cabo un proyecto, no basta con
ser conocedor de tecnologías.
 Hay que conocer, planificar y controlar los
procesos y recursos asignados a un proyecto.
 La planificación del proyecto se desarrolla al
comienzo pero es continuamente refinada a
medida que el trabajo progresa.

66. Conclusiones
 Leer
PMBOK no sirve, hay que llevarlo a
la práctica.
 Difícil su implementación de una vez,
debe ser gradual.
 Una buena intuición soportada por
experiencia documentada (información
histórica) puede ser más precisa que
cualquier modelo.
 Reflexión sobre Metodologías Ágiles.

67. Conclusiones
Tener en cuenta que……..
 “La mayoría de las veces el administrador del
proyecto marca la diferencia entre el éxito o el fracaso
de un proyecto”
 “La gestión es tan importante como la parte técnica....”
 Para construir buen software no basta con ser buen
programador.
 Para ello, hay que conocer, planificar y controlar los
procesos y recursos asignados a un proyecto.

68. Bibliografia
 Inteligencia
Emocional en la Empresa [Daniel
Goleman]
 Inteligencia Emocional. [Daniel Goleman]
 La Quinta Disciplina [Peter Senge]
 PMBOK, tercera edicición.
 Gestión de Proyectos Infórmáticos [Steve
McConnell]
 PMI (http://www.pmi.cl)