Este documento describe los estándares y modelos para la gestión de proyectos de software, incluyendo PMBOK, CMMI, y modelos de madurez. Explica conceptos clave como los procesos, el ciclo de vida del desarrollo de software, y los modelos iterativos como RUP. El objetivo es mejorar la gestión de proyectos mediante el seguimiento de estas mejores prácticas.

1. Gestión de Proyectos de Software basado en procesos del
PMBOK y CMMI
Miguel Angel Cid
José Cheda
•9 de Febrero 2012

2. CONTENIDO
1. Estándares de procesos
2. Mejora en los procesos de software
3. Consideraciones sobre la madurez en la
gestión de proyectos
4. Contexto sobre el desarrollo del modelo
5. El metamodelo (modelo del modelo)
6. Presentación del modelo
7. Conclusiones finales

3. La problemática de la Gestión de Proyectos:
Realidades frecuentes en las organizaciones
• Se desarrollan proyectos no tan importantes y se dejan otros que lo son más
para después.
• Los objetivos, productos y resultados esperados son “zonas difusas”
El alineamiento estratégico de los proyectos es bajo.
• La organización de los proyectos es débil, en competencia permanente con la
organización “formal”.
• Las metodologías para gestionar los proyectos es altamente informal.
• La alta dirección participa más en el inicio (lanzamiento) del proyecto y en el
final.
y por lo tanto se mantiene “ausente”, desinformada y propensa a sorpresas no
deseadas.
• El control del proyecto se orienta al seguimiento de diagramas Gantt, por lo
general desactualizados.
• El día a día operativo no deja tiempo para la ejecución satisfactoria de los
proyectos.

4. •4

5. 2. Consideraciones sobre la madurez de la G.P.
Marco teórico (1).
•Modelo de Madurez para el desarrollo de proyectos de software, CMM SEI.
5 niveles: inicial, repetible, definido, administrado, optimizado.
•Qué elementos hace que unas organizaciones o personas sean más
efectivos a la hora de gerenciar proyectos ? Importancia del concepto de
madurez (Hartman y Skulmoski, 1998).
•“Las empresas aumentan su rigidez y la burocracia por enfocarse al CMM.
Se evitan proyectos de riesgo alto para obtener calificaciones altas en los
procesos de evaluación de CMM” (Hartman y Skumolski, 1998).
•Los modelos de madurez son una importante herramienta de validación.
Identifican fortalezas y debilidades, permiten la referenciación entre
organizaciones, se orientan al “Know-what”, pero no profundizan en el
“Know-How”. (Hartman y Skumolski).

6. 2. Consideraciones sobre la madurez de la G.P.
Marco teórico (2).
•Los modelos de madurez pueden llevar a una organización a una ventaja
competitiva temporal pero no a una sostenida, que se logra con una
combinación de definiciones sobre lo que hay que hacer (“know what”) y
cómo se debe hacer (“know-how”).
(Jugdev y Thomas, 2.002)
•Modelo PMMM, de Fincher y Levin (1,997), incorporando las 9 áreas de
conocimiento de PMBOK y los 5 niveles de madurez de CMM. Según
Skumolski (1997) existen inconsistencias entre los niveles del modelo.
•Goldsmith (1997) desarrolló un modelo de madurez para proyectos de
software orientado a la aceleración de tiempos de desarrollo y a la
certificación PMP. Es un híbrido de CMM con PMBOK.
•Ibbs y Kwak (1997) desarrollaron el modelo PM2, basado en un estudio de
beneficios financieros y organizacionales de la gestión de proyectos en 38
organizaciones.

7. CIO Priorities
Top 10 Management Issues
(2003-2008)
1. Business/IT Fusion
2. Demonstrating Business Value
3. IT Skills (Recruit, Retain, Re-skill)
4. Y2K Clean-up/Contingencies
5. "Sourcing" Management
6. IT Governance
7. Process/Project Management
8. M&A IT Integration
9. Knowledge Management
•Gartner Group (11/16/2002)
10. IT Organization

8. •¿En qué nivel está mi Organización?
•08/17/12 •8

9. •Niveles de Madurez de la
•Gestión de Proyectos
• Nivel 1: Inexistencia del concepto de Gestión de
Proyectos
• Nivel 2: Aplicación empírica de las personas en forma
individual
• Nivel 3: Se sigue una metodología
(institucionalización)
• Nivel 4: Se monitorea el cumplimiento del proceso
• Nivel 5: Existe un proceso de mejora continua.
•9

10. •PMBOK
¿Qué significa Gestionar un Proyecto?
••Administración
Administración
••deProyectos
de Proyectos
••Integración
Integración ••Alcance
Alcance ••Tiempo
Tiempo
••Recursos
Recursos
••Costo
Costo ••Calidad
Calidad ••Humanos
Humanos
••Comunicaciones
Comunicaciones ••Riesgo
Riesgo ••Adquisiciones
Adquisiciones
•10

11. •Grupos de Procesos de Gestión
•11

12. •Proceso y Proyecto
• Un Proyecto es una instancia en el
tiempo y en recursos de un Proceso
•El Proceso dice “qué” y “cómo”
•El Proyecto dice “quién” y “cuándo”
•Proceso •Programación de un proyecto
ID Task Name
Oct 5, '03 Oc t 12, '03 Oct 19, '03 Oct 26, '03 Nov 2, '03 Nov 9, '03
W T F S S M T W T F S S M T W T F S S M T W T F S S M T W T F S S M
A nalist a del Negocio (Domini o) Analista Sistema Arquitecto Sistema De veloper 1
2
3 M odelado de Ne gocio
Modelar Cas os de uso de Negocio 4 Moelar Casos de Uso de Negocio Mortade lo
5 Modelar Objetos de Negoc io Mortadelo
Derivar Cas os de Uso Sis tema 6 Modelado de Negocio Completado 10/15
7 Captura Re quis itos
Bussiness Use Cas e Model File m on[50%]
8 Deriv ar Casos de Us o de Sistema
Design Model
9 Requisitos Completos 10/17
Dis eñar Classes
(es tructura y com portam inento) 10 Analisis y Dis eño
Modelar Objetos de Neogcio Use Case Model 11 Analizar Casos de Uso Sistema Filemon[50%]
Bussines Object Model
(Workers, Entidades y Procesos ) Im plementar Com ponnetes 12 Deriv ar Entidades Mortadelo,Filem on[50%]
13 Diseñar Clases Bacte rio
Definir Componentes
14 Definir Componentes Bacte rio
Analizar Casos de Us o
15 Definir Despliegue Bacte rio
16 A rquitectura Definida 10/28
Implem entation Model 17 Implentación y De s plie gue
Derivar Entidades
Analy is Model
s 18 Implementar Componentes Zipi,Zape [50%]
Com ponentes
(estructura y com poratm iento) 19 Desplegar Componentes Zape[50%]
Definir Des pliegue
20 V ersión Sistema 1.0 11/3
Des plegar Com ponnetes
Deploym ent Model
•tiempo
•12

13. •El Proceso del Software
• Conjunto estructurado de actividades requeridas para
desarrollar un sistema de software.
Especificación- qué debe hacer el software y
cuáles son sus especificaciones de desarrollo.
Desarrollo – producción del sistema de software.
Validación – verificar que el software hace lo que
el cliente pide.
Evolución – cambiar/adaptar el software a las
demandas.
• Las actividades varían dependiendo de la
organización y del tipo de sistema a desarrollarse.
• Debe estar explícitamente modelado para posibilitar
un adecuado gerenciamiento.
•13

14. Modelos de Proceso
Analista del Neg ocio ( Dominio) Analista Sistema Arquitecto Sistema Develo per
Modelar Cas os de us o de Negocio
Derivar Cas os de Uso Sis tem a
Bussiness Use Cas e Model
Design Mo del
Dis eñar Classes
(es tructura y com portam inento)
Modelar Objetos de Neogcio Us e Case Model
Bussines Object Model
(Workers , Entidades y Procesos ) Im plementar Com ponnetes
Defi nir Com ponentes
Analizar Cas os de Us o
Im plem entation Model
Derivar Entidades
Analys is Model
Com ponentes
(es tructura y com poratm iento)
Definir Des pliegue
Des plegar Com ponnetes
Deploym ent Model
•14

15. Existen numerosos modelos de “procesos de
software”
•Real-time
•execution
•Simulation
•Model
•execution
Continuit
y
•Requirement
•Behavior •Specs
•Requirement •Model •Verificatio
s Structures at n and
•at lower higher levels •Validation
levels of
•levels of •System
System •Specification
•Specification
•Test Models/
•Federations •Experiment
•System
•Theory al
•Frames
•15

16. •Proceso de Software y
Modelo de Ciclo de Vida
• Modelo de Ciclo de Vida
– Fases por las que pasa un producto de software a
lo largo de su “vida” (estudio de viabilidad,
análisis, diseño, construcción, pruebas,
implantación, mantenimiento, etc)
– Forma en la que relacionan dichas fases entre sí.
•16

17. •Modelo de Ciclo de Vida en Espiral
••13.
13. ••14.
14.
••Agregación
Category •BIT
••Test •Prueba de
Test •Integración
••7.
7.
••SW OOD-
SW OOD-
••Process los
Vista de
••Procesos
View ••15.
15.
••12.
12. ••Prueba del
System
••Clases
Class ••Sistema
Test
••Test de Implementación
Implementation/Test •3.
•System OOA-
•Dynamic View
••8.
8.
•6.
••SW OOD-
SW OOD-
•SW OOA-
•Dynamic View ••Static View
Vista Estática
•1.
•Requerimientos
••2.
2.
••System OOA- ••4.
4.
System OOA- •16.
••Static View ••HW/SW
HW/SW
••11. Static View
11. ••Split
Split •Requerimientos
••SW OOD-
SW OOD- ••Trace
(Traza)
••Diseño (Métodos)
Method Design
••9.
9.
•5. ••SW OOD-
SW OOD-
•SW OOA- ••Vista Dinámica
DynamicView
•Static View
••10.
10.
••SW OOD-
SW OOD-
••Language
Language ••17.
••Representation 17.
Representation ••Mantenimiento
Maintenance
•17

18. •Modelo de Ciclo de Vida: RUP
•Aspectos de la
•Capa 2
•Flujos de Trabajo •Organización a lo largo del tiempo
•de Ingeniería
•Aspectos de la Capa 3
•Fases
•Flujos de trabajo principales
•Organización
•según la
•naturaleza de
•las tareas •Flujos de trabajo de apoyo
•Flujos de Trabajo
•de Apoyo
•(Environment
incluye
•“Risk
Management”)
•Aspectos de la
Capa 1
•18

19. •ARRANQUE DEL PROYECTO UNICAMENTE •TODAS ITERACCIONES
•SUBSECUENTES
•PLAN PARA
• LA PRIMERA •GESTION DE
•CONCEBIR • ITERACIÓN •LA ITERACIÓN
•NUEVO
•PROYECTO
•ITERACIÓN
• EXITOSA •No
•PLAN DE
•EVALUACION DEL • PROYECTO •EVALUACIÓN DEL
•PROYECTO DEL ALCANCE • APROBADO • ALCANCE Y RIESGOS •MONITOTEO Y
•Y DE LOS RIESGOS •DEL PROYECTO •CONTROL DEL
•PROYECTO
•FIN DEL
•PROYECTO •FIN DE FASE
•PLAN DEL
•¿CERRAR •CERRAR
• PROYECTO •PROYECTO
•PROYECTO? •FASE
• CANCELADO
•FIN DE
•PROYECTO
•ITERACIÓN
•COMPLETO
•FASE
•FIN DEL
•COMPLETA
•PROYECTO •CIERRE NO ACEPTADO
•PLAN PRÓXIMA •PLAN DEL
• ITERACIÓN • PROYECTO •(OPIONAL, DEPENDIENDO
•PROYECTO • DEL GRADO DE CAMBIO)
•CANCELADO
•RUP •FIN DE ITERACIÓN
•19

20. Considerando el Modelo de Ciclo de Vida y la
Iteraciones necesarias se llega a algo así:
Analista del Negocio (Dominio) Analista Sistema Arquitecto Sistema Developer
Modelar Cas os de uso de Negocio
Derivar Casos de Uso Sistema
Bussiness Use Case Model
Design Model
Diseñar Classes
(estructura y comportam inento)
Modelar Objetos de Neogcio Use Case Model
Bussines Object Model
(Workers, Entidades y Procesos) Implementar Componnetes
Definir Com ponentes
Analizar Casos de Uso
Implementation Model
Derivar Entidades
Analysis Model Componentes
(estructura y comporatm iento)
Definir Despliegue
Des plegar Componnetes
Deployment Model
•20

21. Asignación de Recursos
•Recurso
• •Rol • •Actividad
•
•Pablo
• •Diseñador •Diseño de Objetos
•
•María
• •Autor de Casos de Uso
• •Detallar un Caso de Uso
•
•José
• •Diseñador de Casos de Uso
• •Diseñar un Caso de Uso
•
•Silvia
• •Revisor de Diseño
• •Revisar el Diseño
•
•Eduardo
• •Arquitecto
• •Análisis de Arquitectura
•
•Diseño de Arquitectura
•
•
•
•21

22. A partir de Flujos de Trabajo
•Análisis de •Diseño de •Describir •Describir
•Arquitectura •Arquitectura •Concurrencia Distribución
•
• Una lista de actividades,
•Arquitecto
trabajadores (roles) y artefactos
constituye un proceso.
•Análisis de •Diseño de
•Casos de Uso •Casos de Uso
• Un flujo de trabajo es una •Diseñador de
•Casos de Uso
secuencia de actividades que
produce un resultado valioso. •Análisis de
•Objetos •Diseño de
•Objetos
• “Instanciando” el “Proceso” y •Diseñador
los “Flujos de Trabajo” podemos
llegar a un Programa de Trabajo
•Revisor de •Revisar el •Revisar el •Revisar la
•Diseño •Análisis •Diseño •Arquitectura
•22

23. PMBOK© - CMMi®
•23

24. Niveles del Modelo de CMMI
•Optimi
•5 •Focus on process
improvement
zing
•Quantita
•4•and controlled
Process measured
tively
•Managed
•Defin
•3•characterized for the
Process
organization and is
proactive
ed
•Manage
•2•for projects and is often
Process characterized
reactive d
•Perfor
•1•poorly controlled and
Process unpredictable,
•reactive
med
•24

25. •25

26. Level Focus Process Areas
Continuous Organizational Innovation and Deployment
5 Optimizing process Causal Analysis and Resolution
improvement
4 Quantitatively Quantitative Organizational Process Performance
Managed management Quantitative Project Management
Requirements Development
Technical Solution
Product Integration
Verification
Validation
Process Organizational Process Focus
3 Defined standardization Organizational Process Definition
Organizational Training
Integrated Project Management
(SS) Integrated Supplier Management
Risk Management
Decision Analysis and Resolution
(IPPD) Organizational Environment for Integration
(IPPD) Integrated Teaming
Basic Requirements Management
2 Managed project Project Planning
management Project Monitoring and Control
Supplier Agreement Management
Measurement and Analysis
Process and Product Quality Assurance
Configuration Management
1 Performed
•26

27. Proyectos según el CMMI
CMMI
Gestión del Gestión de
Ingeniería Soporte
Proceso Proyectos
- Enfoque Proceso Organizacional - Planificación del Proyecto - Gestión de Requisitos - Gestión de Configuración
- Definición Proceso Organizacional - Monitorización y Control de - Desarrollo de Requisitos - Aseguramiento de la Calidad
- Formación Organizacional Proyectos - Solución Técnica del Proceso y Producto
- Rendimiento - Gestión del Acuerdo con - Integración del Producto - Medición y Análisis
- Innovación y Distribución el Suministrador - Verificación - Análisis de Decisiones y Resolución
Organizacional - Gestión Integrada de Proyectos - Validación - Análisis Causal y Resolución
- Gestión de Riesgos
- Gestión Cuantitativa de Proyectos
IPPD Adquisición
- Entorno Organizacional para la Integración - Selección y Monitorización del Suministrador
- Equipo Integrado - Gestión Integrada del Suministrador
- Gestión Cuantitativa del Suministrador
•27

28. Application of the PMBOK®
Guide to the CMMI Process Management Process Areas
•OPD
•Create Organizational Definition •Make Org Process Assets
Available
•Process Area
•OPF
•OPP
•Practices
•OID
•© 2002 Clark Sheakley •28

29. Proyectos según el CMMI
CMMI
Gestión del Gestión de
Ingeniería Soporte
Proceso Proyectos
- Enfoque Proceso Organizacional - Planificación del Proyecto - Gestión de Requisitos - Gestión de Configuración
- Definición Proceso Organizacional - Monitorización y Control de - Desarrollo de Requisitos - Aseguramiento de la Calidad
- Formación Organizacional Proyectos - Solución Técnica del Proceso y Producto
- Rendimiento - Gestión del Acuerdo con - Integración del Producto - Medición y Análisis
- Innovación y Distribución el Suministrador - Verificación - Análisis de Decisiones y Resolución
Organizacional - Gestión Integrada de Proyectos - Validación - Análisis Causal y Resolución
- Gestión de Riesgos
- Gestión Cuantitativa de Proyectos
IPPD Adquisición
- Entorno Organizacional para la Integración - Selección y Monitorización del Suministrador
- Equipo Integrado - Gestión Integrada del Suministrador
- Gestión Cuantitativa del Suministrador
•29

30. •CMMI: Planeamiento del Proyecto
•Definir los
procesos y
•Preparar el metodología
proyecto
dentro del
grupo de •Adaptar los •Realizar
•Iniciar desarrollo soportes reunión de
proyecto administrativos kick off
•Determinar y organizar los
recursos del proyecto
•30

31. •Status, issues, results
•PMC •of process and
•product evaluations;
•measures and analyses
•Replan
•What •Corrective action
•to monitor
•What to build
•PP
•Commit •Engineering and Support
me nts
•process areas
•Plans
•Measurement needs
•SAM
•Supplier
•agreement
•Supplier
•31

32. Project Planning - Contexto
•Establecer
•Desarrollar
•Datos de
•Estimativos planeación
un plan para
•1 el proyecto
•2
•Obtener
compromiso •Planes de
con el plan proyecto
•3
•PMC
•32

33. •Propósito
•El propósito de la Planeación del Proyecto es
establecer y mantener planes que definan las
actividades del proyecto.
•La planeación del proyecto empieza con los requerimientos
e implica:
 Desarrollar el plan
 Interactuar con los actores del proyecto
 Obtener compromiso para el plan
 Mantener el plan
08/17/12 •33

34. •SG 1. Establecer estimativos
•Estimates of project planning parameters are established and maintained.
•Establecer estimativos
Establecer
Estimar el estimativos
alcance de WP
del y atributos
proyecto de tareas •Datos de
1 2 planeación
Determinar
estimativos Definir el
de esfuerzo ciclo de
y costo vida del
4 proyecto
3
08/17/12 •34

35. •SG 2. Desarrollar un plan para el proyecto
•A project plan is established and maintained as the basis for managing the
project. [PA163.IG102]
•Datos de •Desarrollar un plan para el proyecto
planeación
Establecer Plan para Plan de
presupuesto Identificar admon recursos
y riesgos de datos 4
cronograma 2 3
1
Plan de
Plan de Establecer el entrenamiento
plan del y habilidades
participación
de actores proyecto 5
6 7
•Planes de
proyecto
08/17/12 •35

36. •SG 3. Obtener compromisos con el plan
•Commitments to the project plan are established and maintained.
•Obtener compromiso con el
plan
Revisar
planes que
afectan el
proyecto
•Planes de Reconciliar
proyecto productos y
recursos
Obtener
compromiso
08/17/12 •36

37. Project Life Cycle:
Timing and Application

38. Project Management and the Software
Development Life Cycle

39. Project Management Activities

40. The Art and Science of
Project Management
Art Science
 Vision
 Planning
 Leading
 Organizing
 Motivating
 Staffing
 Creative problem
 Tracking
solving  Control
 Managing
 Reporting
expectations

41. Seguimiento y Control de Proyectos
•41

42. •CMMI: Control de la
Ejecución
•Control y monitoreo
•Analizar •Determinar
estado del alternativas y
•perfomance • acciones correctivas
•Actualizar
•Asignar •Medir •No •Tomar Plan de
•Afecta programa•S •Comunicar
•tareas •rendimiento •o costos? í Acciones •Acciones •Proyecto
Correctivas Correctivas
•Desviaciones •Sí
•No
•Ejecutar soporte en los proyectos de gestión
•Coordinar revisiones QA
•42

43. •CMMI: Gestión de la ejecución
•Ejecutar el proyecto
• Administrar los recursos del proyecto
•Comunicar el status del proyecto
•Preparar informe de status •Comunicar informe de status
•17/08/12 •43

44. •
•
•
•
•
•
•
•
•
•
•
• Contexto
•
•
• •Monitorear
•
el proyecto
•Administrar
contra el
acciones
plan
•1 correctivas
•2
•PMC •Planes de
proyecto
08/17/12 •44

45. •Propósito
•El Plan es la base para:
 Monitorear actividades
 Comunicar su estado
 Tomar acciones correctivas
•Las acciones correctivas pueden generar:
 Replaneación, nuevos acuerdos o
 Actividades para mitigar efectos
08/17/12 •45

46. •SG 1. Monitorear el proyecto contra el
plan
•Actual performance and progress of the project
are monitored against the project plan.
•Monitorear el proyecto
contra el plan
Monitorear Monitorear
Monitorear el Monitorear admon de
parámetros
compromiso riesgos datos
de
2 3 4
planeación
1
Hacer Hacer Monitorear
•Planes
revisión
de hitos
revisiones de
avance
participación
de actores de
7 6 5
proyecto
08/17/12 •46

47. •SG 2. Administrar acciones correctivas hasta
implementarlas
•A Corrective actions are managed to closure when the project's performance or
results deviate significantly from the plan.
dministrar acciones correctivas hasta implementarlas
• [PA162.IG102]
Administrar
correctivas
acciones
correctivas
acciones
Tomar
Planes de
Proyecto
situaciones
Analizar
08/17/12 •47

48. •CMMI: Gestión del cierre
•Completar y cerrar el proyecto
•Capitalizar los • Completar
Activos del •Cerrar el
Proyecto Proyecto
•17/08/12 •48

49. Proyectos con SCM
• •Inicio •Planeamiento •Ejecució •Control •Cierre
n
•Gestión de •Entrenamiento •Establecimiento de una •Ejecuci •Control de •Informe
las de los biblioteca SCM a ser ón de las Cambios de de las
Configuracio miembros del utilizada como repositorio actividad las “Líneas actividad
nes en Equipo de de las “Líneas de Base” es SCM de Base” de es SCM
Proyectos de Desarrollo y de del Proyecto de Software. definidas acuerdo con realizadas
Software otros grupos •Establecimiento de un de un procesos durante el
relacionados equipo con autoridad para acuerdo documentad Proyecto.
para encarar las la Gestión de las “Líneas con las o.
actividades de de Base” del Proyecto de definicio •Actualizació
SCM y también Software. nes n del Plan
en el uso de las •Definición de las metas y program SCM del
herramientas tareas del área SCM. áticas y Proyecto tal
automatizadas •Establecimiento de un presupu que refleje la
de SCM. programa detallado estarias. situación
(calendario) asociado a las vigente en
metas y tareas SCM. todo
•Suministrar los recursos y momento.
presupuesto adecuados
para encarar las tareas
SCM
•17/08/12 •49

50. ITIL/CMMI

51. •Managing Portfolios of Projects
•Managing Projects

52. •Process/Project Management
•Business and Quality Controls
•Business Controls •Discipline-Specific Template
•(Management) •
(Web Dev., CSOO, Support, etc.) •PM Process
•- Resources
•- Schedule
•- Cost
•Stage 1 •Stage 2 •Stage 3 •Stage 4
•Technical •Technical •Technical •Technical
Tasks Tasks Tasks Tasks •Lessons
Learned
•T e c h n i q u e s
•Quality Controls
•(Technical)
•- Product Quality
•T o o l s
•- Technical Standards
•= Compulsory End-Stage Assessment
• Meeting
•Stage 1, 2, 3, 4… •= Quality Review Meetings
•(for example: Initiation, Development, • (Scheduled as needed by Project Type,
•Implementation, Closure) • Activity Type, Deliverable Type
•= Compulsory Quality Review Meeting

53. •Organizational Project Management
Processes
– the Domains

54. Project Office Mission
 Processes, Standards and Methodologies
 Process and Project Management Tools
Project Support
 Planning, Scheduling, Risk Management
 Consulting and Mentoring
 Facilitated Workshops
 Training

55. •Project Office Overview
•Projects
•Drill Down
•Capability
•Status
•Executive •Business •Project Portfolio
•Management •Units •Database
•Policy
•Vision •Budget Proposals
•Approvals/Adjustments/Status
•Business Cases
•Strategy
•Project Justification
•Business Trends
•Direction •• Program Status
•
•Standard •• Program
•
•Reporting • Forecasting
•PROJECT •Requirements •• Schedule
•
•OFFICE • Performance
••Project Funding
•Training ••Resource Analysis
• and Allocation
•• Projects
•
• Disposition
••Issues/Resolutions
•PPM Tools
•Resource ••Overtime Reporting
•Pool ••• Cost Overrun
•PPM Operations
••Business Function/
•Guide
• Program Evaluation
••Contract Analysis
••Program Exception
•Contractor •Process • Analysis
•Database •Library ••Budget Analysis
••Problem Analysis

56. Project Office Mission
 Software Quality Assurance
 Software Configuration Management
 Certified Project Managers
 Subcontract Management
 Benchmarking
 Strategic Planning
 Project Portfolio Management

57. Staffing the Project Office
 Project Office Director  Administrative
 Project Managers Support Coordinator
 Project Mentors  Communications
 Project Controllers Coordinator
 Project Planners  Issue Resolution and
 Methodology Experts Change Control
 Estimators Coordinator
 Librarian/Documentation
 Risk Management
Specialist Coordinator
 PM Software Guru

58. Enterprise Project Management
 Leading EPM Software Tools:
 Artemis (www.artemisintl.com)
 DapTiv (www.daptiv.com)
 Microsoft portafolio management (www.microsoft.com)
 Changepoint (www.changepoint.com)
 Evolve (www.evolve.com)
 Kintana (www.kintana.com)
 Niku (www.niku.com)
 Pacific Edge (www.pacificedge.com)
 Planview (www.planview.com)
 Primavera (www.primavera.com)
 Prosight (www.prosight.com)
 Systemcorp (www.systemcorp.com)

59. Recomendaciones
 Definir la gobernanza de TI
 Políticas
 Procesos
 Procedimientos
 Herramientas
 Oficina de proyecto
 Usar modelos como CMMI o COBIT para
acelerar la implantación de las practicas
PMBOK

60. PREGUNTAS

61. GRACIAS
Miguel Angel Cid
m.cid@unibe.edu.do