Diseño Sistema Gestion

DISEÑO DE UN SISTEMA DE GESTIÓN DE PROYECTOS QUE CONSIDERE
TRABAJAR TANTO CON METODOLOGÍAS TRADICIONALES COMO CON

METODOLOGÍAS ÁGILES EN EL BANCO DE OCCIDENTE
JULIANA JARAMILLO JIMENO
PONTIFICIA UNIVERSIDAD JAVERIANA CALI

FACULTAD DE INGENIERÍA
CARRERA DE INGENIERÍA INDUSTRIAL
SANTIAGO DE CALI
2018
DISEÑO DE UN SISTEMA DE GESTIÓN DE PROYECTOS QUE CONSIDERE
TRABAJAR TANTO CON METODOLOGÍAS TRADICIONALES COMO CON
METODOLOGÍAS ÁGILES EN EL BANCO DE OCCIDENTE
JULIANA JARAMILLO JIMENO
Trabajo de grado presentado como requisito parcial para optar el título de

Ingeniero Industrial
Director:
JORGE ENRIQUE ÁLVAREZ PATIÑO
PONTIFICIA UNIVERSIDAD JAVERIANA CALI

FACULTAD DE INGENIERÍA
CARRERA DE INGENIERÍA INDUSTRIAL
SANTIAGO DE CALI
2018
ARTÍCULO 23 de la Resolución No.
13 del 6 de julio de 1946 del Reglamento
de la Pontificia Universidad Javeriana.
“La Universidad no se hace

responsable por los conceptos emitidos
por sus alumnos en sus trabajos de
grado. Solo velará porque no se publique
nada contrario al dogma y a la moral
católica y porque la tesis no contenga
ataques o polémicas puramente
personales, antes bien, se vea en ella el
anhelo de buscar la verdad y la justicia”
3
DEDICATORIA
Este trabajo de grado es el resumen del esfuerzo durante los años de estudio de
las carreras Ingeniería Industrial y Administración de Empresas. Existieron
momentos difíciles que hicieron retrasar algunos compromisos, pero a pesar de esto
se logró culminar esta etapa.
El proyecto va dedicado a mi padre amado, Dios, a la Virgen María, por

bendecirme en cada instante y darme fortaleza para no rendirme y buscar
soluciones en todo momento; a mi familia por el apoyo, la motivación de crecer día
a día y por creer en mí.
1
AGRADECIMIENTOS
Gracias a la Pontificia Universidad Javeriana Cali, por la formación como

ingeniera y administradora, por los aprendizajes académicos y morales que dejó en
mí.
Gracias al director de tesis, Jorge Enrique Álvarez, por su disposición, tiempo y

conocimientos en el tema. Por su paciencia y su ayuda constante.
Y por último gracias al Banco de Occidente, por abrir sus puertas para el
desarrollo de su trabajo de grado, a una estudiante dispuesta a aprender en todo
momento.
2
CONTENIDO
Pág.
ABSTRACT ................................................................................................. 1
RESUMEN .................................................................................................. 2
INTRODUCCIÓN ........................................................................................ 4
1. ASPECTOS GENERALES DEL PROYECTO ......................................... 5
1.1 EL BANCO DE OCCIDENTE ................................................................ 5
1.2 PLANTEAMIENTO DEL PROBLEMA ................................................... 7
1.3 OBJETIVOS .......................................................................................... 9
1.3.1 Objetivo general ................................................................................. 9
1.3.2 Objetivos específicos........................................................................ 10
1.4 JUSTIFICACIÓN ................................................................................. 10
1.5 ALCANCE ........................................................................................... 10
1.6 MARCO TEÓRICO .............................................................................. 11
2. ANÁLISIS DE LAS METODOLOGÍAS Y LOS PROCESOS

RELACIONADOS CON LA GESTIÓN DE PROYECTOS QUE SE
EMPLEAN ACTUALMENTE EN EL BANCO............................................. 22
2.1 DESCRIPCIÓN DE LA OFICINA DE GESTIÓN DE PROYECTOS .... 22
2.1.1 Organigrama .................................................................................... 22
2.1.2 Recursos técnicos ............................................................................ 23
2.2 DESCRIPCIÓN DE LOS PROYECTOS .............................................. 23
2.2.1 Estratégicos...................................................................................... 24
2.2.2 Aval .................................................................................................. 24
3
2.2.3 Actualización/Obsolescencia tecnológica ......................................... 24
2.3 PROCESOS Y SUBPROCESOS PARA LA REALIZACIÓN DE UN

PROYECTO .............................................................................................. 25
2.3.1 Proceso general ............................................................................... 25
2.3.2 Etapas .............................................................................................. 25
2.3.2.1 Planeación de los requerimientos ................................................. 25
2.3.2.2 Ejecución de los proyectos ............................................................ 32
2.3.2.3 Control de los proyectos ................................................................ 35
2.3.2.4 Cierre y verificación de los proyectos ............................................ 38
2.4 DESCRIPCIÓN DE LA METODOLOGÍA ACTUAL ............................. 41
2.4.1 Proyectos ejecutados bajo metodología tradicional ......................... 42
2.4.2 Proyectos ejecutados bajo metodologías ágiles ............................... 43
2.5 ANÁLISIS DE LA SITUACIÓN ACTUAL VERSUS COMO SE DEBERÍA

TRABAJAR SEGÚN EL MANUAL............................................................. 47
2.6 IDENTIFICACIÓN DE OPORTUNIDADES DE MEJORA DENTRO DE

LA PMO ..................................................................................................... 48
3. DISEÑO DE UN SISTEMA DE GESTIÓN DE PROYECTOS PARA

TRABAJAR TANTO CON METODOLOGÍAS TRADICIONALES COMO
CON METODOLOGÍAS ÁGILES .............................................................. 54
3.1 DESARROLLO DE LAS ACCIONES CORRECTIVAS ........................ 56
3.1.1 DEFINICIÓN LOS PROCESOS Y PROCEDIMIENTOS PARA

TRABAJAR BAJO LAS METODOLOGIAS ÁGILES EN LA PMO ............. 56
3.1.2 SISTEMA DE INFORMACIÓN ......................................................... 63
3.1.3 CAPACITACIONES .......................................................................... 66
3.2 MÉTODO ÁGIL ADAPTADO A LA PROPUESTA DE ADMINITRACIÓN

DE METODOLOGÍAS ÁGILES ................................................................. 72
4
3.2.1 Inicio ................................................................................................. 72
3.2.2 Planificación y Estimación ................................................................ 74
3.2.3 Implementación ................................................................................ 75
3.2.4 Revisión y Retrospectiva .................................................................. 76
3.2.5 Lanzamiento ..................................................................................... 77
3.3 ACTIVIDADES PARA LA IMPLEMENTACIÓN DE LAS

PROPUESTAS .......................................................................................... 78
3.4 COSTO DE LA IMPLEMENTACIÓN DEL SISTEMA DE GESTIÓN DE

PROYECTOS ............................................................................................ 84
4. EVALUACIÓN DE LOS BENEFICIOS QUE SE OBTENDRÍAN EN EL

BANCO CON LA IMPLEMENTACIÓN DE UN SISTEMA DE GESTIÓN DE
PROYECTOS QUE LE PERMITA TRABAJAR TANTO CON
METODOLOGÍAS TRADICIONALES COMO CON METODOLOGÍAS
ÁGILES ..................................................................................................... 87
4.1 ESTIMACIÓN DE LOS BENEFICIOS ................................................. 87
5. CONCLUSIONES .................................................................................. 91
6. RECOMENDACIONES ......................................................................... 92
BIBLIOGRAFÍA ......................................................................................... 93
ANEXOS ................................................................................................... 95
5
LISTA DE TABLAS
Pág.
Tabla 1. Roles, eventos y artefactos en Scrum ..................................................... 19
Tabla 2. Probabilidad de los eventos de riesgo ..................................................... 29
Tabla 3. Impacto de los eventos de riesgo ............................................................ 29
Tabla 4. Categoría ................................................................................................. 30
Tabla 5. Estado ..................................................................................................... 30
Tabla 6. Plantilla consolidada ................................................................................ 33
Tabla 7. Oportunidades de mejora ........................................................................ 49
Tabla 8. Acciones correctivas................................................................................ 52
Tabla 9. Plan de capacitación ............................................................................... 70
Tabla 10. Actividades y fechas según la propuesta .............................................. 78
Tabla 11. Costos para la implementación del sistema de gestión de proyectos ... 85
Tabla 12. Beneficios en los diferentes interesados y áreas de los proyectos ....... 88
Tabla 13. Estimación del impacto en las áreas de conocimiento .......................... 90
6
LISTA DE FIGURAS
Pág.
Figura 1. Ejemplo de ciclo de vida predictivo ............................................ 13
Figura 2. Diseño de procesos ME310 ....................................................... 14
Figura 3. Método ágil ................................................................................. 15
Figura 4. Marco de Scrum ......................................................................... 21
Figura 5. Organigrama de la Oficina de Gestión de Proyectos ................. 23
Figura 6. Diagrama de bloques del proceso general para la ejecución de

proyectos en la organización ..................................................................... 25
Figura 7. Diagrama de flujo del proceso de planeación de

requerimientos........................................................................................... 27
Figura 8. Severidad del riesgo................................................................... 29
Figura 9. Diagrama de flujo del proceso de ejecución de los proyectos .... 32
Figura 10. Diagrama de flujo del proceso de control de los proyectos ...... 36
Figura 11. Diagrama de flujo del proceso de cierre y verificación de los

proyectos ................................................................................................... 39
Figura 12. Causas de la dificultad para la administración de proyectos bajo

metodologías ágiles .................................................................................. 51
Figura 13. Componentes del Sistema de Gestión ..................................... 54
Figura 14. Esquema general de la gestión de proyectos considerando las

dos metodologías ...................................................................................... 55
Figura 15. Formato Aspectos Básicos del Proyecto .................................. 57
Figura 16. Formato para las Historias de Usuario ..................................... 59
7
Figura 17. Formato para Sprints................................................................ 60
Figura 18. Tablero de Scrum ..................................................................... 61
Figura 19. Diagrama de flujo fase de inicio ............................................... 73
Figura 20. Diagrama de flujo fase de planificación y estimación ............... 74
Figura 21. Diagrama de flujo fase de implementación .............................. 75
Figura 22. Diagrama de flujo fase de revisión y retrospectiva ................... 76
Figura 23. Diagrama de flujo fase de lanzamiento .................................... 77
Figura 24. Diagrama de Gantt para la propuesta de la definición de procesos

y procedimientos para trabajar bajo metodologías ágiles ......................... 81
Figura 25. Diagrama de Gantt de la propuesta del sistema de

información ................................................................................................ 82
Figura 26. Diagrama de Gantt para la propuesta de capacitaciones......... 83
Figura 27. Beneficio en los interesados del proyecto ................................ 89
8
LISTA DE ANEXOS
Pág.
Anexo 1. Diagrama de flujo del proceso ajuste de la definición del alcance del
proyecto ........................................................................................................ 95
Anexo 2. Diagrama de flujo del proceso identificación de la necesidad de la

metodología de administración del cambio ................................................... 96
Anexo 3. Diagrama de flujo del proceso definición del recurso humano ...... 97
Anexo 4. Diagrama de flujo del proceso de desarrollo del plan de adquisiciones

y contratación ................................................................................................ 98
Anexo 5. Diagrama de flujo del proceso de detalle del cronograma de

actividades-WBS ........................................................................................... 99
Anexo 6. Diagrama de flujo del proceso de identificación de riesgos......... 100
Anexo 7. Diagrama de flujo del proceso de construcción de costos y

presupuestos del proyecto .......................................................................... 101
Anexo 8. Diagrama de flujo del proceso de capacitación ............................ 102
Anexo 9. Diagrama de flujo del proceso de realización de la reunión del inicio

del proyecto-KICKOFF ................................................................................ 103
Anexo 10. Diagrama de flujo del proceso de realización del plan de trabajo en
Project Server.............................................................................................. 104
Anexo 11. Diagrama de flujo del proceso de la administración del plan de

trabajo ......................................................................................................... 105
Anexo 12. Diagrama de flujo del proceso de la administración de

imprevistos .................................................................................................. 106
Anexo 13. Diagrama de flujo del proceso de la administración de control de
9
cambios ....................................................................................................... 107
Anexo 14. Diagrama de flujo del proceso de la ratificación del

presupuesto................................................................................................. 108
Anexo 15. Diagrama de flujo del proceso de solicitud de aprobación

presupuesto – viajes ................................................................................... 109

comunicaciones........................................................................................... 110

recursos logísticos ....................................................................................... 111
Anexo 18. Diagrama de flujo del proceso de la revisión de mecanismos de

control ......................................................................................................... 112
Anexo 19. Diagrama de flujo del proceso del monitoreo de riesgos............ 113
Anexo 20. Diagrama de flujo del proceso del monitoreo de estrategia de

integración ................................................................................................... 114
Anexo 21. Diagrama de flujo del proceso del monitoreo de solución a

imprevistos .................................................................................................. 115
Anexo 22. Diagrama de flujo del proceso de costos y presupuestos del

proyecto ...................................................................................................... 116
10
ABSTRACT
The following thesis project is intended to provide a solution to the Project Office
of Banco de Occidente to solve one of its main problems, to carry out an adequate
administration of the projects that are currently being worked with agile
methodologies. For this, it was defined as a general objective to design and evaluate
a management system that allows the office to work under the two methodologies,
the traditional and the agile. For this purpose, there are three specific objectives that
include the analysis of the current situation, the design of the system and the
evaluation of the benefits it will provide.
This is a type of descriptive-analytical study and is based on primary sources such

as interviews with the bank's staff, professors and experts on the subject, books and
reliable internet sources.
The project is developed in four chapters: the first one shows the company, the
approach of the problem, the general and specific objectives, the justification, the
scope and the theoretical framework. The second chapter is based on the analysis
of the use of agile and traditional methodologies within the bank, ending with the
identification of weaknesses or opportunities for improvement. The proposals are
developed in chapter three: processes and procedures to work under agile, an
information system and staff training. And the fourth and final chapter shows the
benefits obtained by the bank and the different parties involved in the projects with
this thesis.
The limitations that were encountered during the development of the work were
the obtaining of data of a financial nature, since no real investments were found in
the projects and other types of figures. This is because in this type of companies,
the information is handled with great confidentiality.
Keywords: project management, agile methodologies, traditional methodology,

banking sector.
1
RESUMEN
En el siguiente trabajo de grado se pretende brindar una solución a la Oficina de

Proyectos del Banco de Occidente en uno de sus principales problemas, realizar
una adecuada administración de los proyectos que se están trabajando actualmente
con metodologías ágiles. Para esto se definió como objetivo general diseñar y
evaluar un sistema de gestión que le permita a la oficina trabajar bajo las dos
metodologías, la tradicional y la ágil. Y se plantearon tres objetivos específicos que
comprenden el análisis de la situación actual, el diseño del sistema de gestión de
proyectos y la evaluación de los beneficios que éste brindará.
Este es un trabajo de tipo de estudio descriptivo-analítico y se basa en fuentes

primarias como entrevistas al personal del banco, profesores y personas expertas
en el tema, libros y fuentes confiables de internet.
El proyecto se desarrolla en cuatro capítulos: el primero muestra la empresa, el

planteamiento del problema, los objetivos tanto generales como específicos, la
justificación, el alcance y el marco teórico. El segundo capítulo se basa en el análisis
del uso de metodologías ágiles y tradicionales dentro del banco, finalizando con la
identificación de debilidades u oportunidades de mejora. Las propuestas se
desarrollan en el capítulo tres: procesos y procedimientos para trabajar bajo ágiles,
un sistema de información y capacitaciones al personal. Y como cuarto y último
capítulo se muestran los beneficios obtenidos por el banco y los diferentes
involucrados en los proyectos con este trabajo de grado.
Las limitaciones que se tuvieron a lo largo del desarrollo del trabajo, fueron la
obtención de datos de tipo financiero, pues no se lograron saber inversiones reales
en los proyectos y otro tipo de cifras. Esto debido a que, en este tipo de empresas,
la información se maneja con mucha confidencialidad.
Palabras clave: gestión de proyectos, metodologías ágiles, metodología
2
tradicional, sector bancario.
3
INTRODUCCIÓN
Dada la incursión de metodologías ágiles en las empresas, las oficinas de

proyectos, se han visto obligadas a cambiar o reajustar su trabajo habitual. El
proyecto surge por la necesidad de una buena comunicación de todos los directores
y equipo del proyecto en la oficina de proyectos del Banco de Occidente, el cual
tiene problemas en la administración de los diferentes proyectos que se están
desarrollando actualmente bajo las metodologías ágiles. Para esto se ha planteado
un objetivo general el cual abarca el diseño y evaluación de los beneficios de un
sistema de gestión de proyectos que le permita al banco trabajar tanto con
metodologías tradicionales como con ágiles.
Se estima que se obtengan beneficios para todos los grupos de interés y se logre
impactar positivamente gran parte de las áreas de conocimiento. Entre estos
beneficios están la reducción de tiempo de respuesta al cliente, la mejor
organización en el desarrollo de funciones, la disminución de riesgos, entre otros.
4
1. ASPECTOS GENERALES DEL PROYECTO
En el siguiente capítulo se retoman los parámetros para la ejecución del proyecto.

Estos son el planteamiento del problema, los objetivos, justificación, alcance y el
marco teórico donde se analizan los principales temas y conceptos que sirvieron de
base para el desarrollo del proyecto.
1.1 EL BANCO DE OCCIDENTE
El Banco en Occidente es una entidad financiera, líder a nivel nacional, que hace
parte del Grupo Aval, y cuya sede principal está ubicada en la ciudad de Cali.
El banco tiene como misión: “Ser el líder en la prestación de servicios financieros,

de transacciones y medios de pago, asegurando la satisfacción de las necesidades
de los clientes, la máxima rentabilidad para sus accionistas, el desarrollo integral
del equipo humano y la contribución al bienestar de la comunidad” (Banco de
Occidente, 2016).
El Banco de Occidente es una entidad financiera, que actualmente pertenece al

Grupo Aval, la cual fue fundada en 1965, bajo la administración del doctor Alfonso
Díaz. Su orientación y su rango conservaron inicialmente el matiz regional durante
los primeros años, período durante el cual el desarrollo del sector bancario fue
realmente lento.
Las primeras oficinas fuera de Cali, donde actualmente se encuentra la sede

principal, se abrieron en Palmira, Pereira y Armenia. En 1970, el Banco contaba con
una red de 15 oficinas, un patrimonio aproximadamente $ 74 millones de pesos y
activos totales del orden de $ 685 millones. Al final del año 2016 contaba con 218
oficinas en 63 ciudades del país, un patrimonio de $ 4.061.609 millones y unos
activos de $30.440.463 millones.
5
Los productos y servicios que ofrece el banco son dirigidos tanto a personas
como a empresas, donde se encuentran los productos banca personal, banca
empresarial, productos crédito vehículos y equipos y productos leasing.
El banco, actualmente cuenta con una Vicepresidencia de Servicio al cliente

donde se encuentra el área de Procesos y Proyectos en la cual está la Oficina de
Gestión de Proyectos (PMO), que es el área que tiene relación directa con este
proyecto de grado. Esta oficina cuenta con un director de proyectos, analistas de
proyectos y estudiantes en práctica, quienes son encargados del manejo de los
proyectos estratégicos del banco, todos aquellos que tienen un grado de
importancia muy alto para los objetivos de la organización y sus accionistas. En su
mayoría, estos proyectos son tecnológicos, pues implican el desarrollo de alguna
aplicación o herramienta tecnológica para mejorar los procesos del banco.
Actualmente los proyectos dentro del banco, están divididos en tres grandes
grupos, proyectos estratégicos de los que se encarga la PMO, proyectos Aval y
proyectos de actualización tecnológica.
Las etapas que se surten en el proyecto son: viabilidad, la cual consiste en validar
y definir el tiempo, recursos y costos del proyecto para la posterior aprobación de la
presidencia; planeación, donde se aplican las “metodologías PMI” 1 ; ingeniería,
donde se plasma el requerimiento de que es lo que se necesita; diseño, donde se
establece el cómo se realizará el desarrollo y prototipo; desarrollo, que consiste en
el desarrollo de la aplicación de acuerdo a los requerimientos del cliente; pruebas,
donde se confirma que lo anteriormente desarrollado funcione y por último la
implementación de la solución.
Estos proyectos son medidos en tres variables, tiempo, costo y alcance, y cada
uno de estos con dos tipos de indicadores: desviación y cumplimiento. Así, la PMO
1Se refiere al conjunto de procesos, herramientas y buenas prácticas para la gestión de proyectos
promovida por el Project Management Institute PMI y considerada las de mayor aceptación por
empresas de diferentes sectores alrededor del mundo.
6
puede identificar el momento en el cual los proyectos se encuentran en riesgo y esto
permite tomar decisiones frente a que herramientas utilizar para mitigar un desfase
en los indicadores.
1.2 PLANTEAMIENTO DEL PROBLEMA
Durante el primer trimestre del año 2016, por medio de reuniones y visitas, se
analizó la situación del banco, y específicamente lo relacionado con la ejecución de
los proyectos a cargo de la Oficina de Gestión de Proyectos (PMO), perteneciente
a la Vicepresidencia de servicio al cliente.
Esta oficina se dedica únicamente a la administración y apoyo para la gestión de

los proyectos que se consideran estratégicos por parte del banco; y tiene definidos
procesos, procedimientos, documentos que fueron establecidos hace varios años
considerando el enfoque que se conoce como metodologías tradicionales o
definiendo ciclos de vida predictivos para los proyectos. Este enfoque además
responde a una estructura de vicepresidencias y áreas que el banco tenía definida
hasta el año 2015, y que aún no se ha actualizado considerando los cambios
implementados en cuanto a estructura y estrategia. Otros proyectos se desarrollan
directamente en las áreas, en estos la PMO puede definir algún tipo de lineamiento
o política, pero no tiene injerencia en el desarrollo del día a día.
Al momento de hacer este análisis, en el primer trimestre de 2016, la PMO

contaba con proyectos que no habían sido culminados durante largos períodos de
tiempo, desde dos hasta nueve años, esto debido a la cambiante tecnología que se
ha tenido en la empresa, a la necesidad de hacer cambios en el alcance del proyecto
y en los requisitos de los entregables, a la dificultad para realizar estimaciones
confiables de costos y tiempo, y a la poca aplicabilidad que tienen las metodologías
de gestión consideradas tradicionales para ciertos proyectos.
7
En principio, la PMO fue diseñada para aplicar únicamente metodologías
tradicionales, teniendo en cuenta estándares internacionales como el PMBOK
(Project Management Body of Knowledge) del PMI (Project Management Institute),
que en la práctica funcionan muy bien para cierto tipo de proyectos, pero que tiene
limitaciones cuando se trata de proyectos que se trabajan en entornos que cambian
rápidamente, cuando el alcance y los requisitos son difíciles de definir con
antelación.
Según el Project Management Institute – PMI (2013), las metodologías

tradicionales, también conocidas como orientadas al plan o que definen ciclos de
vida predictivos, son aplicadas en aquellos proyectos en los cuales el alcance, el
tiempo y el costo requeridos para lograr dicho alcance, se determina lo antes posible
en el ciclo de vida del proyecto. Dichas metodologías funcionan muy bien en muchos
sectores e industrias, incluso en el sector financiero, pero se ha determinado que
para cierto tipo de proyectos las metodologías tradicionales representan muchas
desventajas en cuanto a la posibilidad de incorporar cambios y hacer ajustes que
se adapten a las necesidades de clientes y usuarios.
Ciertas áreas y equipos de proyectos en el banco (conformadas con personas de

diferentes áreas) consideran que en determinados proyectos se deben aplicar
metodologías ágiles (o de ciclo de vida adaptativo) que permitan el mejoramiento
continuo de las actividades del proyecto, en donde sea posible definir pequeñas
mejoras graduales que aporten valor a las partes interesadas, y no sea la prioridad
obtener resultados que se entregan terminados solo hacia el final del proyecto
Incluso algunos equipos de proyecto en el banco ya han implementado estas
metodologías, pero la PMO no tiene definidos sus procesos y procedimientos para
poder hacer un adecuado seguimiento y control, y en general realizar una labor de
acompañamiento metodológico a proyectos que están siendo ejecutados con este
enfoque.
Trabajar de esta manera ha representado que:
8
 Para algunos proyectos estratégicos, al momento de ser aprobados, no se
define bien cuál es la metodología más adecuada para su ejecución y seguimiento.
 El trabajo que se realiza en algunos proyectos bajo el enfoque ágil aún no está
parametrizado, y por tanto no puede ser valorado ni comparado con los resultados
de otros proyectos similares o que estén siendo ejecutados con metodologías
tradicionales.
 La PMO no puede realizar un adecuado acompañamiento a la gestión de todos

los proyectos que tiene a cargo, ya que algunos se están trabajando con
metodologías ágiles.
 Las dos metodologías no han sido integradas en un solo sistema de gestión a

cargo de la PMO.
Dado el uso de las dos metodologías, y estado actual de los procesos de la PMO,
esta oficina no está cumpliendo cabalmente su función con otras áreas, ni con la
dirección del banco.
Teniendo en cuenta el problema, para este estudio se plantea la siguiente

pregunta de investigación:
¿Qué procesos, procedimientos, documentos, estructura organizacional y/o

estrategias debería adoptar la PMO del banco para lograr gestionar al mismo tiempo
proyectos bajo metodologías tradicionales y ágiles?
1.3 OBJETIVOS
1.3.1 Objetivo general
Diseñar y evaluar los beneficios de un sistema de gestión de proyectos que

considere trabajar con metodologías tradicionales y con metodologías ágiles en el
Banco de Occidente.
9
1.3.2 Objetivos específicos
 Analizar las metodologías y los procesos relacionados con la gestión de

proyectos que se emplean actualmente en el banco.
 Diseñar un sistema de gestión de proyectos que le permita a las diferentes

áreas del banco trabajar tanto con metodologías tradicionales como con
metodologías ágiles, dependiendo del tipo y características de los proyectos.
 Evaluar los beneficios que se obtendrían en el banco con la implementación de

un sistema de gestión de proyectos que le permita trabajar tanto con metodologías
tradicionales como con metodologías ágiles.
1.4 JUSTIFICACIÓN
La realización de este proyecto trajo consigo el beneficio de las diferentes partes

involucradas: principalmente el banco, ya que la mejora de los procesos dentro de
la gestión de proyectos, va dirigida especialmente hacia sus clientes, que es su
primordial objetivo, e internamente podrán darse cambios que se verán reflejados
en la ejecución de los proyectos de forma más rápida y con menor costo.
Por otro lado, la gestión de proyectos está relacionada directamente con una
rama de la ingeniería industrial, específicamente, la gestión de proyectos bajo las
metodologías ágiles. En la Pontificia Universidad Javeriana Cali, no se han realizado
trabajos de grado relacionados con esta temática. Por esto se considera una idea
original e importante. Lo anterior favorece a los estudiantes que realizan el proyecto,
pues en cuanto al aprendizaje de nuevas temáticas y la aplicación de las mismas.
1.5 ALCANCE
Con el proyecto se establecio el diseño de un sistema de gestión de proyectos

que permite trabajar tanto con metodologías tradicionales como con metodologías
10
ágiles, el cual queda consignado en un documento que contiene los diferentes
elementos de análisis y los elementos constitutivos de diseño como los procesos,
procedimientos, estrategias y estructura organizacional.
El sistema de gestión de proyectos no será implementado dentro del tiempo de

realización, aunque el banco tendrá la posibilidad de hacerlo una vez el presente
estudio termine.
Aunque muchos de los proyectos que se manejan en el banco tienen que ver con
desarrollos tecnológicos, desarrollo o mejoras de software, etc., el trabajo de grado
se enfoca en las aplicaciones desde la ingeniería industrial para definir procesos,
procedimientos, documentos, estructura organizacional y/o estrategias que debería
adoptar la PMO del banco para lograr gestionar al mismo tiempo proyectos bajo
metodologías tradicionales y ágiles, en lo que se ha denominado un sistema de
gestión de proyectos cuyo responsable es la PMO del banco. Además, entre las
diferentes metodologías ágiles existentes se tiene en cuenta únicamente la
aplicación de un modelo específico denominado Scrum, donde no es necesario
iniciar el proyecto con requisitos detallados, sino que se trabaja con la visión del
resultado final, y no sigue un plan pre-elaborado; y que en “lugar de proporcionar
una descripción completa y detallada de cómo deben realizarse las tareas de un
proyecto, genera un contexto relacional e iterativo, de inspección y adaptación
constante para que los involucrados vayan creando su propio proceso” (Alaimo,
2013, p.21).
1.6 MARCO TEÓRICO
En la Guía de los fundamentos para la dirección de proyectos (Guía del PMBOK ®)

se define un proyecto como “un esfuerzo temporal que se lleva a cabo para crear
un producto, servicio o resultado único” (Project Management Institute - PMI, 2013,
p. 3), estos proyectos tienen un principio y fin definidos y éste último se logra cuando
se han cumplido los objetivos, cuando se toma la decisión de terminar el proyecto
11
porque no se van a cumplir los mismos o cuando el cliente del proyecto lo desee.
A pesar de que no todos los proyectos son iguales, estos siguen una misma
estructura a la que se le denomina ciclo de vida del proyecto. Este consta de: el
inicio del proyecto, la organización y preparación, la ejecución del trabajo y el cierre
del proyecto. Existen tres tipos de ciclos de vida, los predictivos, los iterativos e
incrementales y los adaptativos; cada uno de ellos para los diferentes tipos de
proyectos (Project Management Institute - PMI, 2013).
Ciclos de vida predictivos: “son aquellos en los cuales el alcance del proyecto,
el tiempo y costo requeridos para lograr dicho alcance, se determinan lo antes
posible en el ciclo de vida del proyecto” (Project Management Institute - PMI, 2013).
Estos proyectos atraviesan una serie de fases, requisitos, factibilidad,

planificación, diseño, construcción, pruebas y entrega; estas fases se enfocan en
un subconjunto de actividades del proyecto y en procesos de la dirección del
proyecto.
El trabajo realizado en cada fase normalmente es de naturaleza diferente al

realizado en las fases anteriores y subsiguientes, y por lo tanto la composición
y habilidades requeridas del equipo del proyecto puede variar de una fase a
otra. Generalmente se opta por ciclos de vida predictivos cuando el producto
a entregar se comprende bien, existe una base práctica significativa en la
industria, o cuando un producto debe ser entregado en su totalidad para que
tenga valor para los grupos de interesados (Project Management Institute -
PMI, 2013, pág. 44).
La figura 1 ilustra las fases secuenciales del ciclo predictivo.
12
Figura 1. Ejemplo de ciclo de vida predictivo
Fuente: (Project Management Institute - PMI, 2013)
Ciclos de vida iterativos e incrementales: son las llamadas iteraciones, se

repiten intencionalmente una o más actividades del proyecto a medida que aumenta
el entendimiento del producto por parte del equipo del proyecto. Desarrollan el
producto a través de ciclos repetidos, mientras que los incrementos agregan
funcionalidad al producto. Se opta por los ciclos de vida iterativos e incrementales
cuando una organización necesita gestionar objetivos y alcances cambiantes, para
disminuir la complejidad de un proyecto (Project Management Institute - PMI, 2013).
Este es el ciclo de gestión que generalmente se aplica a proyectos de

investigación y desarrollo y a proyectos de innovación. Por ejemplo, en la innovación
por diseño (desing thinking), se sigue un proceso circular iterativo de actividades
que pasa por la definición del problema (define the problem), el descubrimiento de
necesidades (a partir de la observación) y benchmarking (needfinding and
benchmarking), generación de ideas (brainstorm), realización de prototipos
(prototype) y evaluación (test) de los mismos con usuarios, para volver al primer
punto y empezar de nuevo. Un proyecto pasa por todas éstas actividades
13
aproximadamente tres veces. A medida que el proyecto evoluciona, los prototipos
son cada vez más refinados; al inicio los gastos en prototipos son menores y al final,
mayores; cuando ya se invierte en prototipos avanzados, hay gran seguridad de
estar en el camino correcto. En la figura 2 se ilustra el ciclo utilizado en los proyectos
desarrollados en el curso ME310 de la Universidad de Stanford y las universidades
con las que trabaja en convenio alrededor del mundo, a través de la Red SUGAR.
Figura 2. Diseño de procesos ME310

Fuente: (Stanford University, 2010)
Ciclos de vida adaptativos: conocidos como métodos orientados al cambio o

métodos ágiles buscan responder a niveles altos de cambio y a la participación
continua de los interesados, son iterativos e incrementales, como se muestra en la
figura 3 y difieren de los anteriores en que las iteraciones son muy rápidas. Ejecutan
varios procesos en cada iteración, las iteraciones iniciales se concentran en las
actividades de planificación. Se opta por los métodos adaptativos en entornos que
cambian rápidamente, cuando los requisitos y el alcance son difíciles de definir con
antelación y cuando es posible definir pequeñas mejoras graduales que aportarán
valor a los interesados.
14
Figura 3. Método ágil
Fuente: (APM North West Branch, 2015)
El Project Management Institute (PMI) es una asociación sin ánimo de lucro

compuesta de profesionales expertos en proyectos. Tiene normas reconocidas a
nivel mundial, certificaciones, entre otros, que la hacen ser uno de los mejores
organismos orientados a la gestión de los proyectos (PMI, 2016, párr. 1).
Para el PMI (2013), en su PMBOK®, la gestión o dirección de proyectos es la

“aplicación de conocimientos, habilidades, herramientas y técnicas a las actividades
del proyecto para cumplir con los requisitos del mismo. Se logra mediante aplicación
e integración adecuadas de las actividades que se reúnen en cinco grandes grupos
de procesos: inicio, planificación, ejecución, monitoreo y control y cierre” (Project
Management Institute - PMI, 2013).
15
Los conocimientos de la gestión de proyectos se basan en diez áreas:
integración, alcance, tiempo, costo, calidad, obtención, comunicaciones, recursos
humanos, gestión de riesgos y gestión de los interesados. Toda la gestión se ocupa
de estos, la gestión de proyectos aporta un enfoque único hacia los objetivos, los
recursos y el cronograma de cada proyecto. El valor de ese enfoque se demuestra
por el rápido crecimiento de la gestión de proyectos a nivel mundial ya sea como
una competencia de organización reconocida y estratégico, como tema de la
formación y la educación o finalmente como una carrera (Project Management
Institute - PMI, 2016).
La oficina de gestión de proyectos - PMO es una estructura en donde se definen

y estandarizan los procesos relacionados con la gestión de proyectos. “Las
responsabilidades de una PMO pueden abarcar desde el suministro de funciones
de soporte para la dirección de proyectos hasta la responsabilidad de la propia
dirección de uno o más proyectos” (Project Management Institute - PMI, 2013, p.
11).
Hoy en día las empresas la gestión de proyectos necesitan nuevos métodos que
respondan a la entrega temprana de resultados tangibles y a la respuesta ágil y
flexible necesaria para trabajar en entornos que se encuentren en constante cambio.
Esta gestión ágil, desarrollada en los años 80s, se refiere a aquellas técnicas que
comparten ciertas cualidades, valores y principios para favorecer diferentes
desarrollos en los que no es fácil aplicar las metodologías tradicionales. Este
enfoque ha mostrado su efectividad en proyectos con requisitos muy cambiantes y
cuando se exige reducir drásticamente los tiempos de desarrollo, pero aun así,
manteniendo una alta calidad (Letelier & Penadés, 2006).
Un desarrollo ágil es un proceso iterativo e incremental que tiene como

características la mejora continua, la calidad desde el primer día, la priorización de
requerimientos según su valor, la colaboración continua con el cliente, la mitigación
del riesgo mediante iteraciones fijas, entre otras.
16
En marzo de 2001, surge una reunión de los 17 críticos de los modelos de
producción basados en procesos, cuyo objetivo fue esbozar los valores y principios
que deberían permitir a los equipos, desarrollar software rápidamente y
respondiendo a los cambios que puedan surgir a lo largo del proyecto. Se fijan
cuatro postulados que fueron denominados como “El manifiesto ágil”. Estos
postulados son los valores sobre los que se asientan las metodologías ágiles
(Letelier & Penadés, 2006).
El manifiesto plantea que se valora:
 A los individuos y su interacción, por encima de los procesos y las

herramientas.
 El software que funciona, por encima de la documentación exhaustiva.
 La colaboración con el cliente, por encima de la negociación contractual.
 La respuesta al cambio, por encima del seguimiento de un plan (Scrum

Manager, 2015).
Tras estos postulados, se establecen los 12 principios:
 Nuestra principal prioridad es satisfacer al cliente a través de la entrega

temprana y continua de valor.
 Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al

desarrollo. Los procesos ágiles se doblegan al cambio como ventaja
competitiva para el cliente.
 Entregar con frecuencia software que funcione, en periodos de un par de

semanas hasta un par de meses, con preferencia en los periodos breves.
 Las personas del negocio y los desarrolladores deben trabajar juntos de

forma cotidiana a través del proyecto.
17
 Construcción de proyectos en torno a los individuos motivados, dándoles la
oportunidad y el respaldo que necesitan y procurándoles confianza para que
realicen la tarea.
 La forma más eficiente y efectiva de comunicar información de ida y vuelta

dentro de un equipo de desarrollo es mediante la conversación cara a cara.
 El software que funciona es la principal medida de progreso.
 Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores,

desarrolladores y usuarios deben mantener un ritmo constante de forma
indefinida.
 La atención continua a la excelencia técnica enaltece la agilidad.
 La simplicidad como arte de maximizar la cantidad de trabajo que se hace,

es esencial.
 Las mejores arquitecturas, requisitos y diseños emergen de equipos que se

auto organizan.
 En intervalos regulares, el equipo reflexiona sobre la forma de ser más

efectivo y ajusta su conducta en consecuencia (Scrum Manager, 2015).
Existen diferentes metodologías que coinciden con los valores y los principios
enunciados anteriormente, pero cada uno de ellos tiene sus propias características
y aspectos específicos. Entre estas metodologías están: Scrum, Crystal
Methodologies, Dynamic Systems Development Method (DSDM), Adaptive
Software Development (ASD), Feature-Driven Development (FDD), Lean
Development (LP) y eXtreme Programming (XP) (Letelier & Penadés, 2006).
Scrum. Uno de los métodos más destacados y divulgados a nivel mundial es

Scrum. Modelo definido por Ikujiro Nonaka e Hirotaka Takeuchi a principios de los
18
80, quienes compararon la nueva forma de trabajo en equipo, con el avance en
“formación de Scrum”.
Scrum es un modelo de desarrollo ágil que se caracteriza principalmente por

adoptar una estrategia de desarrollo incremental, en lugar de la planificación y
ejecución completa del producto; por basar la calidad del resultado más en el
conocimiento táctico de las personas en equipos auto organizados, que en la
calidad de los procesos empleados, y por el solapamiento de las diferentes
fases del desarrollo, en lugar de realizarlas una tras otra en un ciclo secuencial
o de cascada (Letelier & Penadés, 2006).
En Scrum el equipo se focaliza en construir el producto. La gestión de un proyecto

se centra en definir las características que debe tener este producto y en vencer los
obstáculos que puedan afectar la tarea del equipo de desarrollo. Para llevar a cabo
este proceso se definen cuatro roles para el equipo, cinco eventos (o reuniones) y
tres artefactos o formas de verificar los avances, tal como se definen en la tabla 1 y
como se muestra su integración y funcionamiento en la figura 4 (Scrum Manager,
2015).
Tabla 1. Roles, eventos y artefactos en Scrum

Roles
Rol Descripción
Propietario del producto Determina las prioridades
(Product owner)
Equipo de desarrollo Construye el producto
(Scrum team)
El facilitador (Scrum Gestiona y facilita la ejecución de las reglas de Scrum
Master)
Interesados Resto de los implicados. Asesoran y observan.
Eventos
Evento Descripción
Planificación del sprint Una jornada de trabajo máximo. El propietario del producto
(Sprint planning explica las prioridades. El equipo estima el esfuerzo de los
meeting) requisitos prioritarios y se elabora la pila del sprint. El equipo
define en una frase el objetivo del sprint.
Sprint Ciclo de desarrollo básico en el marco estándar de scrum,
de duración recomendada inferior a un mes y nunca mayor
19
Roles
Rol Descripción
de seis semanas.
Scrum diario (Daily Máximo 15 minutos. Responsabilidad del equipo. Cada
stand-up meeting) miembro expone: lo que hizo ayer, lo que va hacer hoy, si
tiene o prevé problemas. Se actualiza la pila del sprint.
Revisión del sprint Informativa, máximo cuatro horas, presentación del
(Sprint review meeting) incremento, planteamiento de sugerencias y anuncio del
próximo sprint.
Retrospectiva (Sprint El equipo analiza la forma de trabajo identificando fortalezas
retrospective) y debilidades. Refuerzo de las primeras, plan de mejora de
las segundas.
Artefactos
Artefacto Descripción
Pila del producto Relación de los requisitos del producto, no es necesario
(Product backlog) excesivo detalle. Priorizados. Lista en evolución y abierta a
todos los roles. El propietario del producto es su
responsable y quien decide.
Pila del sprint (Sprint Requisitos comprometidos por el equipo para el sprint con
backlog) nivel de detalle suficiente para su ejecución.
Incremento Parte del producto desarrollada en un sprint, en condiciones
de ser usada (pruebas, codificación limpia y documentada).
Fuente: (Scrum Manager, 2015)
20
Figura 4. Marco de Scrum
Fuente: (Scrum Manager, 2015)
21
2. ANÁLISIS DE LAS METODOLOGÍAS Y LOS PROCESOS RELACIONADOS
CON LA GESTIÓN DE PROYECTOS QUE SE EMPLEAN ACTUALMENTE EN
EL BANCO
Este capítulo abarca la descripción de la oficina de proyectos del Banco de

Occidente, la explicación de cómo se trabajan los proyectos bajo metodologías
ágiles y tradicionales y la identificación de oportunidades de mejora en la PMO. Este
capítulo corresponde a los resultados de entrevistas y análisis realizados en
diferentes momentos del año 2016.
2.1 DESCRIPCIÓN DE LA OFICINA DE GESTIÓN DE PROYECTOS – PMO
En este numeral se hablará principalmente acerca de la oficina de proyectos-

PMO. Como está constituida y que recursos técnicos usa para el desarrollo de los
proyectos.
2.1.1 Organigrama
La PMO se encuentra dentro de una de las vicepresidencias del banco, en este

caso la Vicepresidencia de Servicio al Cliente. Esta cuenta con una Gerencia de
Procesos y Proyectos a la cual le reporta el cargo de Dirección de Proyecto que
tiene como responsables los analistas y estudiantes en práctica. En total la PMO es
conformada por ocho integrantes. Figura 5.
22
Figura 5. Organigrama de la Oficina de Gestión de Proyectos
Fuente: la empresa
2.1.2 Recursos técnicos
Las plataformas en las cuales se trabaja y documentan los procesos en la PMO

son Project y PWA.
Project: es un programa de Microsoft que facilita la administración de los

proyectos. Este permite el desarrollo de planes, la asignación de recursos a tareas,
la realización de un seguimiento al proyecto, la administración del presupuesto,
entre otros.
PWA: es una plataforma o espacio de trabajo compartido, que permite a los

involucrados del proyecto subir, o en su defecto descargar, los documentos,
plantillas, actas que se han llevado a cabo en el proyecto.
2.2 DESCRIPCIÓN DE LOS PROYECTOS
Dentro la PMO, se manejan los proyectos estratégicos del banco, estos son todos
aquellos que tienen un grado de importancia muy alto para cumplir los objetivos de
23
la organización y sus accionistas. La mayoría de estos proyectos son de carácter
tecnológico pues implican el desarrollo de una aplicación o herramienta tecnología
para la mejora de procesos y sistemas.
Actualmente, estos proyectos estas divididos en tres grandes grupos: proyectos

estratégicos, proyectos Aval y por último proyectos de actualización tecnológica.
2.2.1 Estratégicos
Los proyectos estratégicos son aquellos que tienen un alto grado de importancia
dentro de la organización. Son proyectos propios del banco, que de acuerdo a sus
estrategias, necesitan realizarse para así poder crecer más. Como ejemplos se
encuentran nuevos productos, servicios, métodos competitivos y mejoras para el
cliente.
2.2.2 Aval
Los proyectos Aval que comúnmente se conocen como proyectos mandatarios,

son lineamientos importantes para el Grupo Aval y sus accionistas. Estos proyectos
los asigna el grupo para que todos los bancos los realicen. Como ejemplo: que todos
los bancos tengan la misma plataforma (SAP).
2.2.3 Actualización/Obsolescencia tecnológica
Los proyectos de actualización tecnológica son aquellos que el banco plantea

como estratégicos, para el crecimiento tecnológico del banco. Sucede por ejemplo
con las plataformas propias del banco que se están quedando obsoletas por falta
de actualizaciones, pero que aún son necesarias.
24
2.3 PROCESOS Y SUBPROCESOS PARA LA REALIZACIÓN DE UN PROYECTO
En el presente numeral se describirá el proceso general y las etapas del mismo,

para llevar a cabo un proyecto dentro del Banco de Occidente bajo la metodología
tradicional.
2.3.1 Proceso general
La figura 6 muestra el proceso de Evaluación, Gestión e Implementación de

Proyectos estratégicos dentro del Banco de Occidente, que tiene como etapas la
planeación, ejecución, control y cierre y verificación de actividades y recursos que
intervienen en el desarrollo de un proyecto sin importar sus características.
Figura 6. Diagrama de bloques del proceso general para la ejecución de

proyectos en la organización
2.3.2 Etapas
En las etapas para el desarrollo de un proyecto bajo metodología tradicional

dentro del banco, se encuentran la planeación de requerimientos, la ejecución, el
control y el cierre y verificación del proyecto. Para estas etapas se han construido
diagramas de flujo y en estos se encuentran los procesos de cada etapa; aquellos
procesos que se encuentran en color azul significan que tienen anexos en la parte
final del trabajo, mientras que los que están en blanco, no tienen.
2.3.2.1 Planeación de los requerimientos
La etapa de planeación de los requerimientos mostrado en la figura 7, inicia con
25
la radicación a través de lo que el banco denomina clear quest2, presentando el
requerimiento a la división de tecnología, y termina con el plan de integración,
consolidado y cargado en la herramienta Project Server. La plantilla es la hoja de
ruta, uno de los documentos más importantes de la metodología, en la cual se
trabaja todo el proyecto, detallando todos los aspectos relacionados con el mismo.
Después de radicar el requerimiento, está el ajuste de la definición del alcance

del proyecto (ver anexo 1), el proceso en el cual se definen los puntos que debe
llevar el alcance, como los objetivos, premisas, riesgos y presupuesto del proyecto,
entre otros. Cabe resaltar que este documento se va diligenciando durante toda la
etapa de planeación.
Seguido de este proceso, está la identificación de la necesidad de la metodología

de administración del cambio (ver anexo 2), proceso en el cual se determina el
impacto y resistencia que genera el alcance en los diferentes procesos y áreas
durante la realización del proyecto.
2Clear quest: Herramienta utilizada por el área de sistemas/tecnología donde se visualiza y modifica
el flujo de trabajo de un proyecto
26
Figura 7. Diagrama de flujo del proceso de planeación de los requerimientos
Fuente: (Banco de Occidente, 2016)
27
Al finalizar este punto, se define el recurso humano requerido (ver anexo 3),
donde los líderes de frente (persona asignada por cada área como responsable de
administrar las actividades de las personas a su cargo), concretan las personas que
serán parte del equipo de trabajo, de acuerdo con la capacidad del banco y así
mismo identificar la necesidad de contratar personal externo. Esto con el fin de
identificar los roles y participación en el requerimiento, y crear los recursos en el
Project Server para proceder al cronograma.
Una vez definidos los recursos, se define el plan de adquisiciones y contratación

(ver anexo 4), donde el gerente del proyecto debe interactuar directamente con las
áreas involucradas en el proceso, siendo esto: entender los términos y condiciones
del contrato, asegurarse que el contrato contiene todos los requerimientos, validar
que el contrato este acorde a las necesidades del proyecto, establecer fechas para
completar los procesos de contratación en el cronograma y brincar apoyo a las
áreas en la negociación y a la gestión de cambios.
Como sexto paso, se encuentra el detalle del cronograma de actividades-WBS

(descomposición de la estructura de trabajo) (ver anexo 5), donde para su
realización se debe iniciar definiendo los entregables esperados del proyecto, los
cuales fueron definidos en el alcance. Una vez estén bien definidos y claros los
entregables, el gerente del proyecto reúne al equipo de trabajo para asignar las
tareas que tiene cada actividad, a los jefes. A continuación, se realiza la
identificación de los riesgos (ver anexo 6), se hace por medio de una reunión con el
equipo del proyecto, se identifican los riesgos y se asigna un responsable para cada
uno de estos. Se debe registrar la probabilidad (tabla 2), el impacto del proyecto
(tabla 3) y la severidad (figura 8), para definir la prioridad de atención de los riesgos,
enfocándose en los que tengan severidad alta y media.
28
Tabla 2. Probabilidad de los eventos de riesgo
Probabilidad Descripción
Alta (3) Riesgos materializados en más del 50% de los proyectos
Medio (2) Riesgos materializados entre el 20% y 50% de los
proyectos
Baja (1) Ocurre en menos del 20% de los casos
Tabla 3. Impacto de los eventos de riesgo

Impacto Descripción
Alto (3) Desviación en el plan de trabajo y presupuesto en el más >=50%
Medio (2) Desviación en el plan de trabajo y presupuesto entre 20% <X< 50%
Bajo (1) Desviación en el plan de trabajo y presupuesto <=20%
Bajo Riesgo = 1 – 6 (verde)

Medio Riesgo = 8 – 9 (amarillo)
Alto Riesgo = 12 – 16 (rojo)
Figura 8. Severidad del riesgo

Posterior a esto, se deben definir los riesgos “asumidos”, riesgos que al

implementar el plan de mitigación cuesta más la materialización del mismo. Y por
29
último diligenciar la clasificación y estado del riesgo (tablas 4 y 5), para generar la
hoja de riesgos.
Tabla 4. Categoría
Categorías Descripción
Recurso Humano Disponibilidad, competencia, resistencia al cambio,
relaciones interpersonales y cambios del recurso
humano
Tecnología Entregas de Hardware y Software. Manejo de
proveedores. Recolección de información histórica
Comunicación Gestión de alertas oportunas. Información a las áreas
involucradas en el proyecto
Integración y/o dependencia Dependencia de entregables entre proyectos
de otros proyectos
Presupuesto Presupuestos y demoras en elaboración, definición y
aprobación de los mismos
Calidad Cumplimiento de los criterios ISO
Dependencia de terceros Lineamiento del grupo Aval, reglas de terceros y manejo
de proveedores diferentes a tecnología
Cambio en la planeación Cambios en el alcance, causados por el mismo proyecto
Administración y control de Ausencia de liderazgo de la gerencia del proyecto.
proyectos Oportunidad de toma de decisiones y prioridades
Recursos físicos Inconvenientes en las adecuaciones de las
instalaciones, muebles y equipos
Tabla 5. Estado
Estado del Riesgo Descripción
Mitigado Se elimina el impacto en el proyecto gracias a los planes
de mitigación
Materializado El plan de mitigación no resulto como se esperaba, y por
ende afecta tiempo, alcance y costos del proyecto
Abierto Estado con el que nace el riesgo
Cerrado Estado en el cual se dan de baja los proyectos cuando
pierden vigencia o se elimina el impacto
Asumido El costo del plan de mitigación es mayor su impacto en
el proyecto en caso de materializarse
El siguiente paso consiste en definir el presupuesto del proyecto (anexo 7), para
lo cual se deben solicitar los costos a las diferentes áreas involucradas (viajes,
30
capacitaciones, infraestructura, entre otros). Adicional a esto, se debe aclarar si
existe o no un presupuesto de inversión para los requerimientos, y solicitar su
aprobación a la presidencia o vicepresidencia correspondiente, según el caso.
Después se deben sumar los costos del proyecto, con el fin de establecer una línea
base de presupuesto estimado y adicionarlo en la definición del alcance. Si el monto
supera los cien millones de pesos ($100’000.000), se debe solicitar a la división de
contabilidad la asignación de un identificador contable y un centro de costos en el
cual se deben contabilizar todos los gastos del proyecto. Y si el monto es menor a
los cien millones de pesos ($100’000.000), se deben contabilizar los gastos,
diferentes a tecnología, imputados al proyecto al centro de costos de la división en
el que fue aprobado. Por último, se solicita al área de Análisis y Presupuesto la
adición del monto aprobado para evitar el reporte de sobre ejecución por las
actividades del proyecto y así la División de Tecnología, seguirá realizando control
y seguimientos al presupuesto según solicitudes de compra y pagos que se
generen.
Sigue el plan de capacitación al equipo del proyecto (anexo 8), en donde se

definen las personas a capacitar, los aspectos en los cuales es necesario preparar
a las personas del proyecto, el objetivo de la capacitación y las fechas en las cuales
se realizarán las actividades. Una vez establecido lo anterior, se genera un acta de
capacitación, y una vez realizadas las actividades, cada persona debe registrar su
asistencia para tener evidencia de los participantes.
A continuación, se realiza una reunión de inicio del proyecto-KICKOFF (anexo 9),

en la cual se presenta al equipo del proyecto lo planteado en el alcance, el
presupuesto y el rol que cumple cada uno en la ejecución del proyecto; además se
acuerda unas reglas de juego. En este proceso también se deja una evidencia de
asistencia por medio de un acta.
Posteriormente, se elabora el plan de trabajo en el Project Server (anexo 10), que

será ajustado a lo largo de toda la etapa de planeación.
31
Los dos últimos pasos en la planeación de los requerimientos son: la
documentación del proyecto en estructura de carpetas en el PWA y el plan de
integración. El primero consiste en la revisión de las carpetas que asigna el sistema
con toda la documentación que se realizó en las etapas. Y el segundo se hace para
facilitar la coordinación y seguimiento detallado de los procesos anteriores a cada
uno de los proyectos.
2.3.2.2 Ejecución de los proyectos
Para llevar a cabo la ejecución de los proyectos es necesario seguir los nueve
pasos mostrados en la figura 9.
Figura 9. Diagrama de flujo del proceso de ejecución de los proyectos

32
La administración del plan de trabajo (anexo 11), consiste en el manejo de todos
los entregables que se definieron en la etapa de planeación del proyecto; desde la
elaboración hasta la certificación. Empezando con el ingreso del porcentaje de
avance, que debe ser actualizado por el responsable de cada proceso. Una vez
diligenciada la plantilla consolidada con fechas de finalización propuesta y real (tabla
6), el gerente del proyecto debe aprobar o rechazar estos porcentajes; si la actividad
no cumple con la fecha definida en el plan de trabajo, se debe analizar si el motivo
fue un imprevisto, de serlo se pasa al proceso de la administración de imprevistos
(anexo 12), de lo contrario continuar con el proceso de administración de control de
cambios (anexo 13).
Tabla 6. Plantilla consolidada

Fechas propuestas del requerimiento Fechas finales (reales) del requerimiento
Fecha de Inicio Dd/mm/aaa Fecha de Inicio Dd/mm/aaa
Fecha final proceso Dd/mm/aaa Fecha final proceso Dd/mm/aaa
– Ingenieria – Ingenieria
Requerimiento Requerimiento
– Diseño – Diseño
– Desarrollo – Desarrollo
– Pruebas – Pruebas
– Implementación – Implementación
Fecha final del Dd/mm/aaa Fecha final del Dd/mm/aaa
requerimiento requerimiento
Como segundo paso está la administración de riesgos, que es la continuación de

la identificación de riesgos (anexo 6), se realizan los seguimientos a los planes de
mitigación o contingencia, la cual debe quedar registradas en el acta de
seguimiento, hasta que el riesgo sea eliminado o materializado. Se actualiza el
estado del riesgo cada que este cambie, hasta que sea cerrado.
33
En la administración de imprevistos (anexo 12), primero se informa al gerente del
proyecto el impacto que tiene el imprevisto sobre el cronograma, costo y calidad del
proyecto, para que después éste mismo brinde la información solicitada por un ente
superior asignado, para la realización del plan de acción. Una vez preparado el plan
de acción, corresponde ejecutarlo y hacerle el respectivo seguimiento, para que por
último se actualice el estado del imprevisto cuando sea mitigado su impacto.
La administración de control de cambios, es el proceso mediante el cual se

analiza, planea y pacta de forma adecuada, modificaciones a las variables de
tiempo, alcance y costo para su implementación y asegurar que no existan cambios
que afecten el proyecto sin aprobación (ver anexo 13).
El proceso de administración de reporte de avance busca generar y comunicar

los informes pertinentes al avance del proyecto, teniendo en cuenta las ópticas del
líder de frente, gerente del proyecto/líder de requerimiento de Tecnología e
informática- TI y del área de proyectos como integrador. Para ello los informes de
avance quedan registrados de tres formas: actas de reuniones de seguimiento,
informe consolidado mensual al Comité de presidencia y presentaciones por parte
de la PMO del gerente del proyecto a la Presidencia del banco o el Sponsor del
proyecto en una reunión coordinada por el área de proyectos.
Para el proceso de costos y presupuestos, se tienen dos subprocesos que son la

ratificación del presupuesto (anexo 14) y la solicitud de aprobación de presupuesto-
viajes (anexo 15). En el primer subproceso, se debe empezar por la identificación
del costo real de los proveedores que serán parte del proyecto para ratificar el
presupuesto y así pedir aprobación a la vicepresidencia correspondiente. Para
finalizar documentando en la plantilla consolidada el detalle del presupuesto. Y en
el segundo subproceso, solicitud de aprobación de presupuesto-viajes, se debe
informar al gerente del proyecto que se hará la solicitud por medio de la intranet
para que este la revise e informe al gerente de la división para que apruebe la
solicitud.
34
El siguiente paso es la administración de la documentación, proceso que describe
las actividades relacionadas a ésta. Donde se garantiza la generación de toda la
documentación del proyecto exigida por la metodología, guardando las versiones
finales. Se puede documentar la información en dos tipos de formatos, plantillas y
modelos, en los cuales la diferencia es que los primeros tienen el contenido pre
establecido y los segundos no.
En el penúltimo proceso de la ejecución de los proyectos, se encuentra la

administración de comunicaciones (Ver anexo 16). Proceso en el cual se deben
identificar y preparar las comunicaciones que se generan dentro del proyecto. Una
vez preparadas, las áreas involucradas, deben validar estas estrategias de
comunicación para garantizar que se tengan en cuenta todos los elementos
requeridos para una comunicación efectiva. Y también si las comunicaciones al
exterior del proyecto, tienen algún impacto con otros proyectos en curso. Posterior
a esto, se debe divulgar y actualizar en el plan de trabajo, para así realizar un
seguimiento a la comunicación.
Y como último proceso está la administración de recursos logísticos (Ver anexo

17). Donde se debe: revisar el plan de requerimientos logísticos hecho en la etapa
de planeación, solicitar la generación de solicitudes de compra, actualizar el plan de
trabajo, validar demoras y ver si causan retrasos sobre las fechas anteriormente
definidas.
2.3.2.3 Control de los proyectos
Esta etapa se realiza con el fin de que tanto el área de proyectos como el equipo
desarrollador del proyecto, estén al tanto de los controles y seguimientos que se
llevaran a cabo. Se analizan los resultados obtenidos y si estos no fueron cumplidos,
entonces proponer acciones correctivas. Y se preparan los diferentes informes:
informes de avance, listas de chequeo e indicadores de cumplimiento.
35
Para llevar a cabo el control de los proyectos se realizan los pasos ilustrados en
la figura 10.
Figura 10. Diagrama de flujo del proceso de control de los proyectos

Fuente: Manual de gerencia de proyectos del banco
1. Para la revisión de mecanismos de control (Ver anexo 18), es necesario tener

el plan de trabajo completo y validado por el área de proyectos, para así identificar
las actividades en las que interviene el área y realizar el control respectivo. Estos
controles pueden ser por medio de:
 Reuniones con el equipo
36
 Reuniones con el gerente del proyecto
 Validación de las actividades
Interviniendo en los temas:
 Integración y solución de conflictos entre proyectos
 Riesgos
 Retrasos
 Seguimiento del plan
 Participación de los recursos
 Temas asignados por el gerente del proyecto
Con una periodicidad ya sea semanal, quincenal, mensual, o simplemente cada

que acabe la actividad.
2. En el monitoreo de comunicaciones externas, se valida que estas no afecten

a otros proyectos, y en caso de ser así, buscar una solución para que ambas partes
resulten beneficiadas.
3. Está el avance del proyecto y el indicador de cumplimiento, es aquí donde se

analizan las actividades en donde el indicador puede causar atrasos en otras
actividades y el gerente o líder del proyecto debe realizar un plan de acción
inmediato para que esto no ocurra.
4. Se encuentra el monitoreo de riesgos (ver anexo 19), donde se valida que las
estrategias de mitigación se hayan cumplido para cada uno de los riesgos
previamente identificados o en su defecto si el riesgo se materializa, que se ejecute
correctamente su plan de contingencia.
37
5. Está el monitoreo de la documentación de lecciones aprendidas, este es un
proceso permanente en la ejecución del proyecto pues todas las acciones, impacten
positiva o negativamente, deben tenerse en cuenta en próximos proyectos. Por
tanto, deben quedar documentados tanto por el equipo de trabajo como por el área
de proyectos.
6. Está el monitoreo de estrategias de integración (Ver anexo 20), esta

integración puede ser directa o indirecta. En la primera se asocian una a una las
actividades que se están realizando simultáneamente en el proyecto, y en la
segunda, cada que termine una actividad debe ser informado el gerente del
proyecto, acerca del requerimiento impactado para continuar con la ejecución.
7. Se encuentra el monitoreo de solución a imprevistos (Ver anexo 21), donde se

valida si el plan de acción arroja resultados satisfactorios o no, para que en los casos
negativos realizar acciones correctivas, y si afecta a otros proyectos, realizar el
proceso de monitoreo de integración (Ver anexo 20).
Y como octavo y último paso se encuentra el procedimiento de costos y

presupuestos del proyecto (ver anexo 22), aquí se encuentran todas las actividades
relacionadas con el control y seguimiento a los costos del proyecto. Esto permite la
identificación de costos que necesiten aprobación de entes superiores y por otro
lado la ampliación o reducción de presupuesto sin que esto afecte el alcance del
proyecto.
2.3.2.4 Cierre y verificación de los proyectos
Como última etapa se encuentra el cierre y verificación de los proyectos (figura

11). Esta etapa tiene como procesos:
En la revisión de entregables definidos conforme con planeación, se debe revisar

que todos los entregables sean facilitados y validados por la persona responsable
del mismo, en la medida que se vayan ejecutando. Los entregables deben cumplir
38
con los criterios de aceptación definidos al inicio.
Figura 11. Diagrama de flujo del proceso de cierre y verificación de los

proyectos
Fuente: Manual de gerencia de proyectos del banco
El cierre de contratos, donde el gerente del proyecto debe validar que todos los
39
contratos establecidos durante el proyecto queden debidamente cerrados y
archivados junto con la documentación del proyecto.
El cierre financiero, que tiene como fin cerrar formalmente la cuenta contable y
dar inicio al proceso de automatización. Una vez cerrado, no se pueden incluir
gastos, por tanto, se debe garantizar que todas las partidas de gastos se hayan
contabilizado antes del cierre.
El reintegro de recursos humanos, donde se informa a las áreas que facilitaron

los recursos, el fin del proyecto. Y para personas externas, cerrar correctamente sus
contratos en caso de no necesitar más su colaboración. De no ser así, definir la
situación laboral en el banco.
El reintegro de requerimientos logísticos en calidad de préstamo, donde se

informa a las áreas facilitadoras de recursos logísticos la fecha definitiva de
finalización del mismo, para iniciar con el proceso de devolución de los recursos y
licencias de Project profesional y Server que fueron asignados para la ejecución del
proyecto.
La entrega formal del producto/servicio a las áreas de soporte, donde se

garantiza que se haga la entrega del proceso a estas áreas que serán las
encargadas de brindar el soporte a las personas que ejecutaran el proyecto.
La consolidación de lecciones aprendidas, donde se prepara un documento con

lo ocurrido en cada una de las etapas del proyecto.
Los responsables de seguimiento a beneficios, donde se definen las personas

encargadas de hacer el seguimiento a los beneficios que brinde el requerimiento,
teniendo claro la periodicidad y meta a alcanzar.
Y por último, la generación del acta de cierre, que es el documento formal en la

que se oficializan los entregables y se coordina con el beneficiario/usuario cdl
proyecto, la responsabilidad y la salida a producción.
40
2.4 DESCRIPCIÓN DE LA METODOLOGÍA ACTUAL
Para la construcción de este punto, se realizaron entrevistas a personas

relacionadas tanto con la PMO como con los proyectos ágiles. Es de ellos
principalmente de donde proviene la información acerca de cómo se trabajan los
proyectos actualmente. En la PMO se estuvo en constante contacto con la directora
de la oficina, y en agilismo con un coordinador de proyectos.
Como ya se mencionó, el Banco de Occidente está llevando sus proyectos por

diferentes metodologías, identificadas como tradicional y ágil.
Antes de desarrollar el proyecto, se debe determinar por cuál de los dos métodos
se debe llevar a cabo. Y esta identificación se realiza de la siguiente forma:
Se identifica el contexto, a eso se refiere en ubicar el proyecto en uno de los

cuatro sistemas para así asignar el método. Los sistemas son:
Simple: en este sistema existe una relación directa entre la causa y el efecto.
Complicado: en este sistema no existe una relación directa entre la causa y el

efecto como el simple. Para encontrar esta relación, se debe realizar un análisis
previo de la causa para así entender el efecto. En este análisis se empiezan a
generar iteraciones para la comprensión del efecto, y una vez este claro se convierte
en algo repetitivo lo cual nunca va a cambiar.
En estos dos primeros sistemas regularme se utiliza el método tradicional bajo el

cual el banco ha trabajado a lo largo del tiempo.
Complejo: en este sistema tampoco existe una relación entre la causa y el efecto
y tampoco se puede encontrar realizando el análisis como en el complicado. Esto
debido a que por más iteraciones que se realicen, jamás va a ser repetitiva. El
41
sistema va a estar en un constante cambio y es aquí donde entran las metodologías
ágiles.
Caótico: en este último sistema no existe relación entre causa y efecto y no se

entiende el problema ni lo que pueda llegar a suceder. No se pueden utilizar las
metodologías ágiles ya que se empiezan a generar hipótesis.
En estos sistemas, lo ideal es intentar convertir el proyecto caótico en un

complejo para poder trabajarlo bajo el agilísimo. Y si se trata de un complicado
intentar convertirlo en un simple. Resulta difícil en el momento de pasar de complejo
a complicado pues el primero no es repetitivo sino cambiante.
En el banco las metodologías ágiles solo han sido acogidas por unos pocos, esto
debido a la cultura tradicional que siempre se ha manejado.
2.4.1 Proyectos ejecutados bajo metodología tradicional
Actualmente en el Banco de Occidente, a la hora de trabajar un proyecto bajo el

método tradicional, se rigen por el manual de proyectos descrito anteriormente. Esto
debido a que los proyectos que se manejan son de alto costo (mayores a 1.000.000
USD), y esto para el banco en casos donde se cometan errores, se atrasen en
tiempos, significa un riesgo. Por otro lado, están las auditorías las cuales se
encargan de observar si se están llevando a cabo y correctamente los procesos
internos de la organización. Estos proyectos suelen tener duraciones mínimas de
un año.
De forma concreta, lo primero que se debe tener a la hora de realizar un proyecto

es un sponsor 3 y un gerente de proyecto, la cual normalmente son los
vicepresidentes de las áreas involucradas. Una vez estén establecidos estos roles,
se empieza a desarrollar la etapa de planeación, que normalmente tiene una
3 Sponsor: patrocinador del proyecto
42
duración de dos meses y consta de unos entregables básicos que son la definición
de alcance, la conformación del equipo del proyecto e involucrados, el presupuesto,
el cronograma, la WBS (Work Breakdown Structure) o en español EDT (Estructura
de decomposicion del trabajo), los riesgos, las lecciones aprendidas, la cual finaliza
con un kickoff4, donde se comunica a los interesados como ha quedado el desarrollo
del proyecto, y de qué manera se llevará a cabo.
Posteriormente se encuentra la ejecución y control, con sus respectivas etapas

donde se administran la mayoría de los entregables del punto anterior; se realizan
análisis de indicadores, monitoreo de costos, de tiempos, seguimiento a la parte
humana, entre otros. En estas etapas se llevan a cabo reuniones semanales,
máximo cada 15 días donde se muestra un resumen de la semana que acaba de
pasar y de la que esta próxima. Todo en estos puntos va quedando documentado.
Como punto final se encuentra el cierre del proyecto, donde se devuelve todo lo
que fue solicitado a lo largo del proyecto, desde personas hasta equipos. Y se dejan
unos compromisos futuros, ya que ningún proyecto queda cerrado al 100%. Estos
compromisos normalmente son tareas pequeñas o insignificantes que no son
necesarias de culminar para cerrar el proyecto y entregar el producto o servicio final.
2.4.2 Proyectos ejecutados bajo metodologías ágiles
Actualmente en el Banco de Occidente, no existe un manual para llevar a cabo

proyectos por metodologías ágiles, como lo hay para la metodología tradicional,
pero si existen tres funcionarios expertos en metodologías ágiles, los cuales
capacitan al resto de los involucrados en el respectivo proyecto. En agilismo se
manejan cuatro pilares que son bajo los que trabajaran durante sus proyectos:
 Adaptación al cambio.
4 Kickoff: Se define como la primera o reunión inicial del proyecto.
43
 Mejora continua
 Colaboración
 Entrega temprana y continua de valor.
Para comenzar a trabajar, primero se deben identificar las necesidades de la

organización, tales como tener al cliente más satisfecho y esto realizándolo con
equipos altamente motivados y teniendo times to market 5 más pequeños. Los
proyectos se basan en ir entregándole al cliente en corto tiempo avances del
objetivo final, de tal manera que el cliente brinde retroalimentación, para así mejorar
el proyecto desde un principio y que no se deba esperar hasta el final para hacerlo.
Este método ayuda a conocer el valor del proyecto junto con el cliente.
Como parte positiva para el Banco no solo está el valor, el retorno de la inversión,
sino también el crecimiento del personal, pues en el momento de la realización del
proyecto se están uniendo diferentes áreas donde todos se involucran con todos;
los trabajadores empiezan a entender y a tener la sensibilidad de las actividades
que hacen sus colegas y de esta manera se genera el conocimiento transversal a
nivel organizacional.
Los pasos a seguir para la realización de un proyecto por el método ágil son:
 Identificar si es un problema, y si lo es, cuál es la necesidad del cliente. Junto

con el interesado o accionista definir las personas de las diferentes áreas que
podrían estar involucradas en el proyecto, para así citarlas a la reunión de inicio y
en esta reunión definir los principales (9 personas) y los colaboradores.
 Realizar la reunión de inicio, esta es una de las prácticas de agilísmo. Se realiza

sobre una plantilla ya establecida. Consta de cocreación y colaboración. Son
5 times to market: Se refiere al tiempo que tarda un producto desde que se concibe hasta que
está disponible para la venta.
44
reuniones durante aproximadamente tres días (8 am a 5 pm). Asisten las personas
involucradas en el requerimiento y aquí es donde se identifica la necesidad del
cliente y definen como enfocarse en ella.
 Se escoge el equipo que estará 100% involucrado en el trabajo (Son

aproximadamente nueve personas de las diferentes áreas que estarán involucradas
según la temática del proyecto. Ejemplo: sistemas, proyectos, riesgos,
infraestructura, entre otros). Es donde se define un mismo propósito para todos, el
propósito del equipo para solucionar esa necesidad u oportunidad.
 Identificación de riesgos y clasificación según el nivel de ocurrencia, para así

tomar medidas y planes de acción (soluciones).
 Según las propuestas para la resolución del problema, se define el marco de

trabajo bajo el cual se va a llevar a cabo el proyecto. Dependiendo de la técnica que
se va a utilizar, así mismo se define el equipo de trabajo y los roles.
Los frameworks6 o marcos de trabajo, más utilizados en el Banco de Occidente

son: Scrum, Lean Start Up y Kanban, los cuales van a ser descritos a continuación.
Scrum: Actualmente es el más utilizado por el banco, por ende es el marco de

trabajo en el que más se va a profundizar. Los roles que se manejan en este marco
de trabajo son el scrum master, scrum owner y scrum team.
Scrum master: amo y dueño del proyecto. Es aquel que sabe a la perfección que
se hace en scrum (temas técnicos). Sabe todo lo que se necesitará y utilizará en el
proyecto. Vela por que se cumpla y se vean los resultados. Es el facilitador del
equipo y quien quita los impedimentos que pueden aparecer en el desarrollo del
proyecto.
Project owner/scrum owner: es aquel que conoce el negocio y sabe tomar las
6 Frameworks Marco de trabajo
45
decisiones correctamente. Siempre está pendiente de su objetivo el cual es a nivel
de negocio y que este se esté viendo en camino. Se apoya mucho con el scrum
master.
Scrum team: Equipo involucrado en el proyecto.
En el Scrum básicamente se trabaja bajo unas historias de usuario o Sprints, que

son las necesidades del cliente las cuales se dividen en las tareas que se van a
realizar durante el proyecto. A estas historias se les pone un orden según el nivel
de importancia, y también un tiempo de trabajo (entre 10 y 15 días). Una vez termine
la primera, se puede continuar con la siguiente, y así sucesivamente hasta terminar
el proyecto.
En este marco de trabajo se llevan a cabo unas reuniones diarias más conocidas
en el banco como “el daily”; esta tiene una duración de 15 minutos y se realizan tres
preguntas principales a cada uno de los asistentes: ¿Qué hiciste ayer?, ¿Qué
problemas tuviste? Y ¿Cuál es la siguiente tarea a tomar? Esta reunión se realiza
con el fin de sincronizar al equipo de trabajo y sus actividades, para corroborar que
todo se está trabajando bajo el mismo objetivo.
Las siguientes son las principales actividades para llevar a cabo un proyecto bajo
Scrum:
 Planeación del sprint o historia de usuario. Se planean las actividades a realizar

diariamente para cumplir el sprint y ser revisadas en las reuniones diarias.
 Ejecutar la historia de usuario en el tiempo planeado.
 Realizar el review: presentar a los interesados o accionistas lo realizado.
 Reunión de retrospectiva: es aquella donde se realizar una reflexión al equipo

a nivel técnico y personal. Se revisa si se alcanzó el objetivo y los aspectos a
mejorar.
46
Una vez se finalicen todas las historias de usuario previamente establecidos, es
donde acaba el proyecto. Para esto no existe una reunión de cierre pues en el
momento en que cada sprint va terminando, se pueden ir viendo los resultados.
Lean startup: Básicamente es un marco de trabajo donde se observa el

problema, se genera una idea y se pone en el mercado para obtener una
retroalimentación por parte del cliente y medir resultados para así generar otra idea.
Se convierte en un ciclo, ideación-medición-aprendizaje-ideación, que básicamente
juega con hipótesis. Es un método que resulta muy segmentado a diferencia del
Scrum que funciona de forma masificada.
 Una vez definido el marco de trabajo, se define el tiempo o duración del proyecto
y el alcance (Presupuesto). El sponsor es quien delimita el monto del presupuesto,
si se puede alargar más tiempo el proyecto, pues él es el responsable de los
resultados del proyecto.
A diferencia del método tradicional, en el ágil no se usa mucho la documentación

del trabajo realizado. Si existen documentos, pero solo aquellos que generen valor
y apoyen realmente el trabajo. Se cree más en la comunicación cara a cara en vez
de informes archivados, pero aun manejan el sistema de información (La “Wiki” del
banco) donde se suben los archivos nombrados anteriormente (los que generan
valor, que se consideren importantes).
No se manejan actas, sino que todo se va manejando en un tablero, con postits,

donde se ve a diario la trazabilidad del proyecto y donde se va consignando todo.
2.5 ANÁLISIS DE LA SITUACIÓN ACTUAL VERSUS COMO SE DEBERÍA

TRABAJAR SEGÚN EL MANUAL
Para verificar si actualmente se estaba utilizando el manual de gerencia de

proyectos, se realizó una reunión con la directora de proyectos del Banco de
Occidente, el día 30 de marzo de 2017. En este encuentro dio a conocer la gran
47
importancia que tiene el manual para el banco y las consecuencias del mal uso de
éste.
Dentro del banco se deben llevar a cabo los proyectos (tradicionales)

estrictamente bajo los pasos definidos previamente en el manual, esto debido al alto
costo de los proyectos, nombrados anteriormente, y a las constantes auditorías que
se realizan en el banco. Por ende, su mal uso puede provocar pérdidas económicas
muy grandes para el banco y no conformidades por parte de los auditores, haciendo
esto el no recibimiento de los certificados.
Después de esta entrevista, se concluyó que el manual se sigue al pie de la letra

por parte de todos los involucrados y que no hay inconsistencias a la hora de realizar
un proyecto, siempre y cuando se trate de utilizar la metodología tradicional. Para
los proyectos que requieran metodología ágil no se cuenta con un manual dentro
del banco, sino que se siguen los pasos mencionados en el numeral 2.4.2., propios
de los proyectos ágiles pero no establecidos formalmente dentro del banco.
2.6 IDENTIFICACIÓN DE OPORTUNIDADES DE MEJORA DENTRO DE LA PMO
El Banco de Occidente lleva trabajando bajo la misma metodología para la

gestión de proyectos (tradicional) alrededor de siete años. Ellos y el mundo han
evolucionado, tanto tecnológica como culturalmente y por esta razón es que han
entrado otras metodologías en donde se tengan entregables de valor en un tiempo
más corto de lo habitual, generando así proyectos de menor costo o que su retorno
se vea reflejado en menor tiempo. Esta es la gran diferencia entre las dos
metodologías, pues su duración termina siendo la misma.
La incursión de estas metodologías en el banco, han permitido que las personas

que trabajan dentro de la PMO tengan una visión más amplia de los proyectos y
generen nuevas ideas para mejorar la forma bajo al cual se está trabajando
actualmente.
48
Dentro del banco existe la forma de llevar a cabo la administración de los
proyectos que se realizan bajo la metodología tradicional (manual de gerencia de
proyectos), pero aún no existe para aquellos que se trabajan con ágiles. Es por esto
que en el siguiente capítulo se aborda la elaboración de un sistema de gestión con
el fin de brindar una solución para la administración (seguimiento y control) de los
proyectos que se realizan bajo agilísimo que se debe integrar con lo actual en un
solo sistema.
Se habla de administración ya que no se pretende cambiar la forma de trabajo

de los proyectos que se ejecutan bajo agilísimo, sino la forma de gestionar estos e
informar el desarrollo, evolución y resultados a la oficina de proyectos del banco.
Después de analizar la situación actual del banco se encontraron oportunidades

de mejora o debilidades las cuales fueron validadas con el personal de la empresa
en cargos de dirección y coordinación de los proyectos; estas se muestran en la
tabla 7 y se encuentran clasificadas entre causas principales y subcausas; con ellas
se construyó un diagrama de Ishikawa para un mejor análisis del problema (ver
figura 12).
Tabla 7. Oportunidades de mejora

Oportunidades de mejora Causa principal Subcausa
Deficiencias en el establecimiento del gobierno X
corporativo de proyectos organizacionales
Presentan deficiencias en la gestión de portafolio, X
programas y proyectos
Se carece de políticas claras que delimiten la viabilidad X
de ejecución de los proyectos y comités
interdisciplinarios decisores.
Dificultades en la comunicación entre la PMO y los X
gerentes de proyecto que utilizan metodologías de
ágiles
Los miembros de la PMO no poseen suficiente X
conocimiento en metodologías ágiles, ni los gerentes
de estos proyecto en administración de portafolios de
proyectos
Desactualización del estándar documental X
49
Oportunidades de mejora Causa principal Subcausa
Los elementos procedimentales de los proyectos X
gestionados con metodologías ágiles no se han
incorporado al manual de la PMO
Se carece de una clara definición de los entregables X
que debe generar los proyectos ejecutados bajo
metodologías ágiles
Tipificación muy básica para los proyectos X
organizacionales que administra la PMO
Falta de recursos capacitados en la administración de X
diversas metodologías en gestión de proyectos
Fallas en la selección del método adecuado para X
gestionar proyectos bajo distintas metodologías
Insuficientes criterios para la clasificación de proyectos X
Pobre definición y control sobre la triple restricción X
establecida para los proyectos
Poca claridad sobre la administración de la triple X
restricción para cada tipo de gestión de los proyectos
Plataformas tecnológicas de apoyo a la gestión de X
portafolio, programas y proyectos
Carencia de un software que facilite el control y X
seguimiento de los proyectos desarrollados tanto bajo
el agilísimo como bajo metodología tradicional.
50
Figura 12. Causas de la dificultad para la administración de proyectos bajo metodologías ágiles
51
A partir del anterior análisis y de la identificación de oportunidades de mejora, se
proponen unas acciones correctivas que se muestran en la tabla 8.
Tabla 8. Acciones correctivas

Problema Causas Acciones correctivas
Definición (o revisión) de
los procesos relacionados
Gestión de portafolio, programas y
con la gestión de
Deficiencias en el proyectos
portafolio, programas y
establecimiento del
proyectos
gobierno corporativo
de proyectos Se carece de políticas claras que
organizacionales delimiten la viabilidad de ejecución de Creación y validación de
los proyectos y comités políticas
interdisciplinarios decisores.
Dificultades en la
comunicación entre Los miembros de la PMO no poseen
la PMO y los suficiente conocimiento en
gerentes de metodologías ágiles, ni los gerentes de Capacitación al personal
proyecto que utilizan estos proyecto en administración de
metodologías de portafolios de proyectos
ágiles
Los elementos procedimentales de los
proyectos gestionados con
metodologías ágiles no se han
Desactualización del Estandarizar el método
incorporado al manual de la PMO
estándar de administración para
Se carece de una clara definición de
documental metodologías ágiles
los entregables que debe generar los
proyectos ejecutados bajo
Falta de recursos capacitados en la
Tipificación muy administración de diversas
básica para los metodologías en gestión de proyectos
Capacitación al personal
proyectos Fallas en la selección del método
organizacionales adecuado para gestionar proyectos
que administra la bajo distintas metodologías
PMO Insuficientes criterios para la
clasificación de proyectos
Pobre definición y
control sobre la triple Poca claridad sobre la administración
restricción de la triple restricción para cada tipo de Capacitación al personal
establecida para los gestión de los proyectos
proyectos
52
Problema Causas Acciones correctivas
Plataformas
Alternativas de sistemas
tecnológicas de Carencia de un software que facilite el
de información o
apoyo a la gestión control y seguimiento de los proyectos
softwares para la
de portafolio, desarrollados tanto bajo el agilísimo
administración de los
programas y como bajo metodología tradicional.
proyectos
proyectos
Estas acciones correctivas se plantean en extenso en el capítulo 3, con excepción

de la definición (o revisión) de los procesos relacionados con la gestión de portafolio,
programas y proyectos y de la creación y validación de políticas, ya que estas dos
propuestas requieren un conocimiento más detallado en el tema y opiniones de alto
rango como vicepresidencias, gerentes, entre otros, por ende será responsabilidad
del banco la realización de estas.
En el segundo capítulo se recopiló y analizó la información acerca de las

metodologías y los procesos relacionados con la gestión de proyectos dentro del
banco; además se logró la identificación de debilidades lo cual permitió el
planteamiento de oportunidades de mejora.
53
3. DISEÑO DE UN SISTEMA DE GESTIÓN DE PROYECTOS PARA TRABAJAR
TANTO CON METODOLOGÍAS TRADICIONALES COMO CON
METODOLOGÍAS ÁGILES
Como resultado de implementar las acciones de mejora, se conforman los

elementos necesarios para la construcción de un sistema de gestión de proyectos,
dicho sistema se define como el resultado de la unión seis componentes, estos son:
las políticas, el personal capacitado, el sistema de información adecuado, los
métodos de administración para metodologías ágiles y tradicional y los procesos
relacionados con la gestión de portafolio, programas y proyectos (ver figura 13). A
lo largo de este capítulo se propone cómo desarrollar dichos componentes.
Procesos relacionados
con la gestión de
portafolio, programas y
proyectos
Método de
administración para
metodología Políticas
tradicional
Método de
administración para Personal
metodologías ágiles Capacitado
Sistema de
información
Figura 13. Componentes del Sistema de Gestión
54
En la figura 14 se aprecia como cualquier tipo de proyecto inicialmente debe ser
presentado a la vicepresidencia según el área de trabajo, este debe ser aprobado
para después definir bajo cual metodología se realizará. Como se ha mencionado
anteriormente, en el banco ya todo está establecido para trabajar de la forma
tradicional, pero no de la ágil. Para esta última ya se conoce la forma de ejecutar
los proyectos más no de administrarlos y es aquí donde se halla el principal
problema de la PMO, la mala comunicación, presentación y el no entendimiento de
los proyectos realizados con agilísmo.
Figura 14. Esquema general de la gestión de proyectos considerando las dos

metodologías
55
3.1 DESARROLLO DE LAS ACCIONES CORRECTIVAS
En el siguiente numeral se desarrollarán las acciones correctivas propuestas en

el capítulo dos, en las cuales se tienen los recursos suficientes para llevarlas a cabo.
3.1.1 Definición los procesos y procedimientos para trabajar bajo las

metodologías ágiles en la PMO
Para brindar una solución a este problema se crea un sistema de gestión que
mostrará las diferentes formas de seguimiento al proyecto en cada una de sus
etapas, creando informes, plantillas y diferentes tipos de reportes que debe entregar
el equipo de ágiles a la PMO.
Para definir la administración de los proyectos ágiles, en el banco se toman

aspectos considerados en el SBOK (Scrum Body of Knowledge), publicado por
SCRUM study™, pues es una guía completa para trabajar bajo la metodología ágil
más popular, Scrum.
Bajo este marco un proyecto ágil tiene cinco fases que son: inicio, planificación y
estimación, implementación, revisión y retrospectiva y lanzamiento. Cada una de
estas etapas tiene unos procesos, y estos tienen entradas, herramientas y salidas.
Estas últimas que son aquellas en las que se basa la propuesta para la
administración de los proyectos que se llevarán a cabo en el del banco.
La primera fase es el inicio, esta consiste en todos los procesos para empezar
un proyecto: la visión, identificación del equipo, entre otros. Y para ésta se ha
propuesto una plantilla que tendrá como nombre “Aspectos Básicos del Proyecto”,
(ver figura 15). Este formato debe ser diligenciado por el Scrum Master o puede ser
él quien elija un miembro del equipo para esta tarea. Una vez estén diligenciados
todos los campos, debe ser compartido a la PMO de dos formas, digital e impresa.
Para esto el responsable a llenar el formato tiene un plazo de 15 días para su
diligenciamiento y será revisado por el Scrum Master.
56
1
3
2
Figura 15. Formato aspectos básicos del proyecto
57
El formato requiere la fecha de elaboración en dd/mm/aaaa. Seguido de esto
debe ir el nombre del proyecto a desarrollar. Como tercer punto están los campos
donde se identifican aquellas personas que estarán involucradas en el proyecto:
1. Propietario del producto: aquella persona que se encarga de lograr el máximo

valor empresarial para el proyecto. Representa la voz del cliente. Es quien elige al
Scrum Master y al equipo Scrum.
2. Scrum Master: asegura que el equipo tenga un buen ambiente para lograr el
proyecto. Enseña las prácticas de Scrum. Elimina impedimentos.
3. Socio(s): clientes, usuarios, patrocinadores.
4. Equipo Scrum: son quienes comprenden los requerimientos, estiman las

historias de usuario y crean los entregables del proyecto.
4. Prototipos: se deben llenar las descripciones de los prototipos, estos son

personajes ficticios detallados, usuarios o socios que pudieran no utilizar el producto
final. Esto para entender mejor al usuario y sus necesidades.
6. Lista priorizada de pendientes: se ponen los requerimientos del negocio y del

proyecto
Y para terminar, junto con el nombre de quien lo elabora, se debe dejar definido
el número de semanas que durará cada sprint del proyecto para así tener un
estimado de tiempo del proyecto cuando de identifiquen cada uno de los sprints a
llevar a cabo.
En la segunda fase, más conocida como planificación y estimación, que como su

nombre lo dice, consiste en aquellos procesos relacionados con la planificación y
estimación de las tareas, se han propuesto dos formularios o plantillas, que se
basan en las historias de usuario o sprints.
La primera plantilla tiene como nombre “Formato para las Historias de Usuario”.
58
Únicamente tiene tres campos a diligenciar. Ver figura 16. Esta plantilla la debe
diligenciar el encargado de la historia de usuario, y tiene un plazo de tres semanas.
Esta plantilla es revisada por el Scrum master.
Formato para las Historias de Usuario Fecha: / /

Criterios de Terminado:
-
-
-
-
-
Criterios de Aceptación:
-
-
-
-
-
Número Historia de Usuario Estado
Elaborado por:
Figura 16. Formato para las historias de usuario
El primero aparece en la fase de inicio pero se considera para este formato ya

que se debe usar en cada uno de los Sprints y no en términos generales como lo
es la plantilla “aspectos básicos del proyecto”. Este campo son los criterios de
terminado, el cual se especifican las reglas que debe aplicar todas las historias de
usuario. Seguido de esto, se tienen los criterios de aceptación los cuales brindan la
59
objetividad requerida para que las historias de usuario se consideren o no
terminadas. Y por último una tabla donde se deben poner las historias de usuario
con sus descripciones en el orden que van a ser desarrolladas y el estado en el que
se encuentre, este puede ser aprobado o no.
Figura 17. Formato para Sprints
El segundo formato se ha adecuado para la realización de los diferentes Sprints,

por eso su nombre “Formato para Sprints” (Ver figura 17). Esta plantilla debe
60
diligenciarla el encargado del sprint o de la historia de usuario y debe entregarla una
vez termine el sprint (depende de la duración de cada sprint); y será revisado por el
Scrum master. En él se debe especificar el número del Sprint actual, las tareas que
quedaron pendientes del sprint anterior en forma de listado, los riesgos que trajo y
las actividades que se usaron para mitigarlos. Y por último la lista de las tareas a
realizar en el sprint actual, su estimación y la prueba de si es compatible con el
próximo sprint.
Junto con estos formatos de la fase dos, se debe entregar la gráfica de

pendientes del sprint, el cual puede ser elaborado en una herramienta para gráficos
o Microsoft Excel. Esta grafica muestra la cantidad de trabajo pendiente en el sprint
actual y el progreso. Se pueden observar también estimaciones incorrectas.
Para la tercera fase de implementación, la cual está relacionada con la

ejecución de las tareas y actividades para la creación del producto, se realizará la
entrega de un tablero de Scrum virtual, como el que se usa diariamente en el
proyecto. Este debe estar actualizado hasta lo último que se haya hecho del sprint,
esto incluye por hacer, en progreso, prueba y terminado como lo muestra la figura
18.
Figura 18. Tablero de Scrum
61
Fuente: (SCRUMstudy, 2016)
De este tablero se sacan conclusiones de aquellas historias que han sido

finalizadas satisfactoriamente y que son aptas para ser presentadas ante el
propietario y los socios. También se puede aprovechar para sacar el registro del
segundo entregable de esta fase, los impedimentos u obstáculos que redujeron la
productividad del proyecto; esto para ser resueltos y eliminados.
Para las fases cuatro y cinco, las cuales se definen como:
La cuarta fase, llamada revisión y retrospectiva, el cual consta de la revisión de

los entregables y de lo que se ha desarrollado hasta el momento y también de
determinar maneras de mejorar las prácticas en lo que se trabajó.
Y la quinta fase, lanzamiento, el cual se centra en la entrega final de los

entregables aceptados a los clientes.
Se deben realizar reuniones cada tres semanas, este tiempo ya que es

aproximadamente lo que dura un sprint. Pero esto se basará principalmente en el
tiempo que se estableció para cada sprint en la plantilla “Aspectos básicos del
proyecto”.
A esta reunión deben asistir todos los involucrados del proyecto para revisar los
entregables y la forma de trabajar, así se tendrán retroalimentaciones acerca de
aspectos a mejorar, eliminar, entro otros. Uno de los miembros del equipo debe
llevar una minuta que debe ser enviada al final de la reunión para que todo el equipo
esté al tanto de correcciones para la entrega final de lo realizado del producto o
servicio.
La entrega final de cada uno de los entregables del producto o servicio, se

realiza en una reunión con el propietario del producto y los socios donde se expone
que, como y cuáles son los beneficios de lo realizado, si se debe seguir
construyendo o si será el fin del proyecto. En este espacio ellos pueden aprobar o
62
no los entregables. De esta reunión también debe quedar una minuta diciendo si el
proyecto fue aprobado o no, de haber sido aprobado como fue entregado o enviado
el proyecto y las retroalimentaciones que brindaron el propietario y los socios.
3.1.2 Sistema de información
A continuación se presenta la propuesta de software para manejar los proyectos

y tener una correcta administración de ellos.
Se escogieron dos softwares a analizar. Microsoft Project, el cual el banco realiza

algunas tareas con este, e ITM Platform, un sistema innovador con buenas
herramientas incorporadas.
Para saber cuál de las dos era la ideal, se realizó una comparación el cual
constaba del análisis en cada una sobre las áreas funcionales que tenía
incorporadas. Ver tabla 9.
Tabla 9. Detalle de las áreas funcionales

ITM MS
ÁREAS FUNCIONALES PLATFORM PROJECT
Estrategia
Portafolio Corporativo SI NO
Gestión de Portafolio SI NO
Gestión de Programas SI NO
Priorización Estratégica SI SI
PMO
Gestión de Recursos SI SI
Cuadros de Mando SI SI
Control Financiero SI SI
Gestión de Clientes SI NO
Gestión de Proveedores SI NO
Gestión de Servicios SI NO
Gestión de proyectos
Proyectos Clásicos SI SI
Proyectos Ágiles SI NO
Gestión de Equipo SI SI
63
Gestión de Tareas SI SI
Valor Ganado SI SI
Workflow y Validaciones SI SI
Gestión de Riesgos SI NO
Comunicación
Mensajería Social
Empresarial SI NO
App Celular SI NO
Gestión Documental SI SI
Compatibilidad
API SI NO
MS Project SI SI
Slack SI NO
Jira SI NO
Zapier SI NO
Después de analizar la tabla anterior, se concluye que el mejor software a utilizar

es ITM Platform, pues cumple con el 100% de las áreas funcionales, mientras que
Project únicamente cumple con el 44%.
ITM PLATFORM. Esta es una herramienta para la gestión de proyectos en

cualquier tipo de empresa, pequeña, mediana o grande. Como se nombró
anteriormente es un software que es amigable con las actividades o tareas descritas
en la propuesta.
A continuación se describen las características y funciones de la herramienta:
Como primera característica importante, ITM permite gestionar metodologías

ágiles y tradicionales en un mismo portafolio integrado.
Planeación y seguimiento:
Planificación de proyectos:
 ITM permite asignar los recursos y los perfiles profesionales.
64
 Cronograma Gantt: ITM permite por medio de esta función, planificar, controlar
y hacerle seguimiento a los tiempos en línea. Es una de las mejores formas gráficas
de ver la gestión del proyecto.
 Planificación continua soportada por escenarios previstos.
 Planificación estratégica: ITM permite planificar la actividad de la organización

y dimensionar previamente los recursos.
 Planificación de recursos: ITM permite asignar tareas, proyectos, jefes de

tareas, de servicio, Project managers. Además de esto identifica quienes tienen
sobrecargas en su trabajo o en qué actividad están faltando recursos. Para esto
están disponibles las siguientes herramientas: indicadores y cuadros de mando,
análisis de recursos por esfuerzos, análisis de carga y productividad, distinción de
empleados y recursos externos, entre otros.
 Valor ganado: ITM incluye dentro de su plataforma la métrica del valor ganado,
haciendo esta, evaluaciones del rendimiento de costos reales versus planificados
usando las gráficas más aptas para la lectura de los resultados.
Costos e ingresos: Se necesitan conocer y controlar los costos para saber

exactamente como va avanzando el proyecto. Para esto están disponibles
diferentes herramientas que permiten la gestión de costos, gestión de ingresos y el
margen y la rentabilidad. En estas se pueden encontrar el control de las horas
trabajadas, los ingresos por cliente, la vinculación de los ingresos por tarea, la
rentabilidad del cliente agregada, el análisis financiero del portafolio, entre otros.
Clientes y proveedores: El buen desarrollo del proyecto también se debe a la

relación que se tiene tanto con clientes como con proveedores. Para esto ITM
permite tener la gestión de cada uno de estos. Para esto tiene herramientas que
administran datos, comparte documentos, analiza costos, ingresos y rentabilidad
por cliente, compara tarifas de proveedores, entre otros (Itmplatform, 2017).
65
Información y comunicación:
- ITM permite llevarlo a cualquier parte, para esto tiene una aplicación en el
celular, donde se pueden ver los proyectos, modificar actividades, tareas, etc.
- ITM tiene una red social integrada para que todos los involucrados compartan
información entre ellos.
- ITM es un sistema que se puede utilizar a nivel global, para esto tiene todas las
monedas e idiomas disponibles según el país donde se encuentre trabajando.
- ITM tiene un flujo de aprobación para las diferentes modificaciones que se

realicen dentro del proyecto. Así se evita la recolección de firmas y queda todo en
la nube documentado.
- ITM permite el diseño de informes a la medida de las necesidades del proyecto

y la empresa. Estos pueden ser exportables a Excel.
Además de todo esto, ITM tiene integración con otros softwares como Teambot,
JIRA, MS Project y Zapier. Estos complementarios a las actividades y según las
necesidades de la organización.
ITM es una plataforma confiable usada por grandes empresas como LOEWE,
Lala, Pemex, Macmilla, Telefónica, entre otros.
Este software tiene un costo de 24 USD por usuario al mes, el cual es un valor
asequible para el banco y es una buena inversión.
3.1.3 CAPACITACIONES
Se ha diseñado un programa de capacitación al personal que lo necesite, esto

con el fin de mejorar algunas de las debilidades mencionadas anteriormente y así
mismo garantizar un mejor rendimiento de los trabajadores.
66
Antes del programa, se debe definir el término capacitación, el cual hoy en día se
define como un medio para apalancar el desempeño en el trabajo, el cual desarrolla
las competencias de cada persona para que estas puedan ser más productivas,
creativas e innovadora con el fin de aportar más a los objetivos de la organización
y resultados del negocio (Chiavenato, 2009).
Programa de capacitación “Projects College”:
Nombre de la capacitación: Metodologías ágiles.
Objetivo: Entrenar y dar a conocer sobre las metodologías ágiles a los miembros
de la PMO, con el fin de disminuir las dificultades en la comunicación entre la PMO
y los gerentes de proyecto que utilizan metodologías de ágiles.
Objetivos específicos: Lograr un mejor entendimiento sobre las metodologías

ágiles, que permita tener sinergia entre los equipos de trabajo involucrados.
Nombre de la capacitación: gestión de proyectos
Objetivo: Entrenar y dar a conocer sobre la Gestión de Proyectos a los miembros

de Agilísimo, con el fin de disminuir las dificultades en la comunicación entre la PMO
y los gerentes de proyecto que utilizan metodologías de ágiles.
Objetivos específicos: Lograr un mejor entendimiento sobre la gestión de

proyectos, que permita tener sinergia entre los equipos de trabajo involucrados.
Nombre de la capacitación: tipificación de proyectos
Objetivo General: Capacitar a todos los involucrados en proyectos del Banco de

Occidente, en herramientas que les permitan diferenciar y categorizar los diversos
proyectos que se generen, con el fin de identificar que metodología (tradicional o
ágil) se debe implementar para cada uno de ellos.
Nombre de la capacitación: Conceptos básicos sobre la triple restricción
67
(alcance, tiempo y costo)
Objetivo general: Capacitar a todos los involucrados en proyectos del Banco de

Occidente, en los conceptos básicos de la triple restricción (definición, uso y
metodología) con el fin de gestionar y administrar de manera adecuada los
proyectos del banco.
Otros aspectos:
¿Quién debe ser capacitado?
Las personas que deben ser capacitadas dentro de la empresa, son aquellas que
estén estrechamente relacionadas con los proyectos, ya sean manejados de
manera tradicional o ágil. En este caso serían ocho integrantes de la PMO y seis
involucrados en agilísimo, para un total de 14 capacitados.
¿Cómo capacitar?
Como métodos de capacitación o técnicas, se plantean capacitaciones fuera del

trabajo, es decir externo a la actividad laboral pero dentro del horario laboral, basada
en un programa previamente estructurado. Estas serán grupales y presenciales,
simulando un aula de clases, por eso su nombre “Projects College”.
En estas clases de utilizarán técnicas como lecturas, casos, debates y

simulaciones. Y para quienes no puedan asistir a alguna sesión, se usará el E-
Learning, el cual puede realizar desde su puesto de trabajo o casa. Lo importante
es cumplir con todas las sesiones y estar todos con el mismo nivel de conocimientos
y preparación.
¿En qué capacitar?
Serán varios temas a capacitar. En el caso de los ocho integrantes de la PMO,

se deben instruir en metodologías ágiles, en especial en Scrum. Y para los
involucrados en agilísimo, que son seis, se deben capacitar en gestión de proyectos.
68
Para todo el grupo, se debe dar una capacitación acerca de la tipificación de los
proyectos y su correcta asignación a la metodología por la cual se vaya a llevar a
cabo; esto para que todos estén claros en el momento de seleccionar el método
para el desarrollo del proyecto.
¿Quién capacitará?
Para llevar a cabo estas sesiones, las personas encargadas de enseñar al

personal del banco, son instructores o profesores profesionales en los temas
previamente seleccionados. Estos pertenecientes a universidades o centros de
educación.
¿Dónde se capacitará?
Las capacitaciones se pueden llevar a cabo en dos espacios según lo pactado

con la institución perteneciente de los instructores. Por facilidad y movilidad lo ideal
es una sala dentro de la empresa, o en su defecto, transportarse hacia el lugar de
trabajo del profesor (Universidad).
¿Cuándo capacitar?
Se capacitará según lo planteado en el plan de acción el cual será definido en el

numeral 3.2. Como se dijo anteriormente, las capacitaciones tendrán lugar en
horarios laborales, posiblemente una vez a la semana cada 15 días.
Según la información anterior, se ha construido un plan de capacitación (ver tabla

10), donde se muestra la capacitación con sus respectivos temas a tratar, los
objetivos, las personas que serán beneficiadas, los formadores que dictaran las
capacitaciones y los lugares con sus fechas y horas respectivas.
69
Tabla 10. Plan de capacitación
TEMA DE
CONTENIDO OBJETIVOS BENEFICIARIOS FORMADOR HORARIO FECHA LUGAR
FORMACIÓN
Entrenar y dar a conocer sobre

las metodologías ágiles a los
miembros de la PMO, con el fin
de disminuir las dificultades en la
Historia, conceptos comunicación entre la PMO y los
básicos, principios, gerentes de proyecto que utilizan Profesor de
Metodologías etapas, roles y metodologías de ágiles. Miembros de la universidad Junio 20 a
Ágiles
2 - 5 pm Universidad
ámbitos (riesgo, PMO (posgrado) - Julio 20
calidad, tiempo, Javeriana/Icesi
alcance, costo, etc.) Lograr un mejor entendimiento
sobre las metodologías ágiles,
que permita tener sinergia entre
los equipos de trabajo
involucrados.
Entrenar y dar a conocer sobre la

Gestión de Proyectos a los
miembros de Agilísmo, con el fin
de disminuir las dificultades en la
Historia, conceptos comunicación entre la PMO y los
Integrante de la
básicos, principios, gerentes de proyecto que utilizan
PMO Sala del
Gestión de etapas, roles y metodologías de ágiles. Miembros de Agosto 1 al
Proyectos
(Preferiblemente de 8 - 12 m Banco de
ámbitos (riesgo, agilismo 31
la gerencia o Occidente
calidad, tiempo,
Lograr un mejor entendimiento dirección de la PMO)
alcance, costo, etc.)
sobre la gestión de proyectos,
que permita tener sinergia entre
los equipos de trabajo
involucrados.
70
TEMA DE
CONTENIDO OBJETIVOS BENEFICIARIOS FORMADOR HORARIO FECHA LUGAR
FORMACIÓN
Capacitar a todos los
involucrados en proyectos del
Definición de los Banco de Occidente, en
diferentes tipos de herramientas que les permitan
Profesor de
proyectos, su diferenciar y categorizar los
Tipificación de Miembros de la universidad Marzo 10 a
Proyectos
correcta diversos proyectos que se 2 - 5 pm Universidad
PMO y agilismo (posgrado) - Abril 10
clasificación, la generen en el banco, con el fin de
Javeriana/Icesi
forma de trabajarlos, identificar que metodología
entre otros temas. (tradicional o ágil) se debe
implementar para cada uno de
ellos.
Capacitar a todos los
involucrados en proyectos del
Definición de la triple
Conceptos Banco de Occidente, en los
restricción, su Profesor de
básicos sobre la conceptos básicos de la triple
correcto uso, la Miembros de la universidad Mayo 1 al
triple restricción restricción (definición, uso y 2 - 5 pm Universidad
(Alcance, tiempo importancia dentro PMO y agilismo (posgrado) - 31
metodología) con el fin de
y costo) de la organización, Javeriana/Icesi
gestionar y administrar de
entre otros.
manera adecuada los proyectos
del banco.
71
3.2 MÉTODO ÁGIL ADAPTADO A LA PROPUESTA DE ADMINISTRACIÓN DE
METODOLOGÍAS ÁGILES
Como se nombró anteriormente en el numeral 3.1.1 para la administración de

metodologías ágiles en el banco, se toman aspectos considerados en el SBOK
(Scrum Body of Knowledge), publicado por SCRUM study™, pues es una guía
completa para trabajar bajo la metodología ágil más popular, Scrum.
Bajo este marco, un proyecto ágil tiene cinco fases que son: inicio, planificación
y estimación, implementación, revisión y retrospectiva y lanzamiento; y lo que se
mostrara en este numeral, son los procesos de cada una de estas fases más la
incorporación de lo propuesto en el método para administrar metodologías ágiles
(ver numeral 3.1.1). Los procesos se mostrarán en diagramas de flujo elaborados
con base al SBOK, y en rojo se mostraran dichas propuestas.
3.2.1 Inicio
En esta primera fase (ver figura 19) el cual consta de seis procesos: la creación
de la visión del proyecto, la identificación del Scrum master y socios, la formación
del equipo Scrum, el desarrollo de las épicas, la creación de la lista priorizada de
pendientes del producto y la realización del plan de lanzamiento, tiene al final del
último proceso la realización del formato de los aspectos básicos del proyecto. Se
deben realizar antes todos los procesos anteriormente nombrados para poder llenar
correctamente la plantilla.
72
Figura 19. Diagrama de flujo fase de inicio
73
3.2.2 Planificación y Estimación
A lo largo de la segunda fase de planificación y estimación (ver figura 20) el cual

consta de cinco procesos, se desarrollan dos de los formatos y la gráfica propuesta.
La fase inicia con la creación de las historias de usuario, donde a partir de aquí se
puede llenar el formato para las historias de usuario. Seguido de esto está la
aprobación, estimación y asignación de historias de usuario, la creación y la
estimación de tareas; una vez terminada la estimación, se es posible completar el
tercer formato que es el de los Sprints. Y como último proceso está la creación de
la lista de los pendientes del sprint el cual es necesaria para la creación del grafico
de dichos pendientes.
Figura 20. Diagrama de flujo fase de planificación y estimación
74
3.2.3 Implementación
En la tercera fase de implementación (ver figura 21) se desarrolla una de las

propuestas, el tablero de Scrum. Este se lleva a cabo dos veces, la primera después
de la creación de los entregables que es aquí cuando se realiza o crea el tablero y
la segunda cuando se debe actualizar según lo conversado en la reunión diaria de
pie. Esta tercera fase finaliza con el mantenimiento de la lista priorizada de
pendientes del producto.
Figura 21. Diagrama de flujo fase de implementación
75
3.2.4 Revisión y retrospectiva
Como cuarta fase se encuentra la revisión y retrospectiva, el cual inicialmente

consta de tres procesos, el convocar al Scrum de Scrums, el realizar la
demostración y validación del sprint y el realizar la retrospectiva del sprint. Pero a
esta fase se le ha añadido un último proceso propuesto en el numeral 3.1.1 el cual
es la realización de una reunión del sprint. Esta reunión va dependiendo de la
duración de cada sprint y en ella se revisaran entregables y la forma de trabajo para
así tener retroalimentaciones acerca de los aspectos a mejorar o eliminar. De esta
reunión debe queda una minuta con todo lo analizado.
Figura 22. Diagrama de flujo fase de revisión y retrospectiva
76
3.2.5 Lanzamiento
En la quinta y última fase, llamada lanzamiento, sucede lo mismo que la cuarta.

Inicialmente tenía únicamente dos procesos, pero se le ha añadido un tercero. Los
primeros dos son el envío de entregables y la retrospectiva del proyecto, y el tercero
y nuevo, es la reunión del proyecto. Es en esta reunión donde se exponen los
entregables del producto o servicio y los beneficios de lo realizado; en esta misma
se define si se continúa realizando o si es el fin del proyecto. De esta reunión debe
quedar una minuta diciendo si el proyecto fue aprobado o no, de haber sido
aprobado como fue entregado o enviado el proyecto y las retroalimentaciones que
brindaron el propietario y los socios.
Figura 23. Diagrama de flujo fase de lanzamiento
77
3.3 ACTIVIDADES PARA LA IMPLEMENTACIÓN DE LAS PROPUESTAS
En este numeral se presentan las propuestas con sus respectivas actividades y

fechas de implementación, como se muestra en la tabla 11. Se pretenden realizar
en un periodo de tiempo de un año una vez entregado el trabajo de grado al banco.
Tabla 11. Actividades y fechas según la propuesta
Propuestas Actividades Fecha planeada (2018)
Informar al banco sobre la

Febrero 1 al 5
propuesta
Realizar reunión entre la PMO y

el vicepresidente
correspondiente, para tomar la Febrero 10 al 20
decisión de la implementación
Definir los procesos y de la propuesta o no
procedimientos para Presentar y explicar la
trabajar bajo las propuesta a los equipos de
metodologías ágiles en la Agosto 1 al 5
trabajo, tanto PMO como
PMO miembros de agilismo
Realizar una prueba de
implementación con un proyecto Agosto 10 a noviembre
de corta duración para su 30
validación y efectividad
Oficializar e implementar la
propuesta tanto en la PMO Enero 2 de 2019
como en el banco en general
Febrero 1 al 5
propuesta
Contactar a la empresa
prestadora del servicio para
Febrero 20 al 28
planear una reunión donde se
hable acerca de la plataforma
el vicepresidente
Sistemas de información correspondiente, para tomar la Marzo 1 al 10
decisión de adquirir o no el
software
Contactar a la empresa
prestadora del servicio para
confirmar la adquisición del
Marzo 15 al 20
software, dar toda la
información de número de
usuarios, tiempo de contrato,
78
etc.
La empresa prestadora del
servicio debe crear los usuarios
Abril 1 a Junio 1
solicitados por el banco y otros
requerimientos
Implementación del software en
Junio 5 al 20
el banco
La empresa prestadora del
servicio debe realizar
Agosto 1 al 20
capacitaciones a los usuarios
que van a usar la plataforma
Oficializar la plataforma y
empezar su uso en todos los Septiembre 1 al 15
proyectos
Febrero 1 al 5
propuesta
el vicepresidente
correspondiente, para tomar la Febrero 5 al 10
decisión de la implementación
de la propuesta o no
Contactar a las diferentes
instituciones y profesionales que
dictarán las capacitaciones para Febrero 10 al 28
informar acerca del plan de
capacitación y fechas de inicio
Reunir al equipo que será
capacitado para explicarles la
Marzo 1 al 5
propuesta, definir fechas y
horarios
Capacitaciones Iniciar con la capacitación de
Marzo 10 a abril 10
tipificación de los proyectos
Finalizar capacitación y evaluar
Abril 10 al 30
el desempeño
Iniciar con la capacitación de
conceptos básicos sobre la Mayo 1 al 31
triple restricción
Junio 1 al 19
el desempeño
Junio 20 a Julio 20
Julio 20 al 31
el desempeño
Agosto 1 al 31
gestión de proyectos
Finalizar capacitación y evaluar Septiembre 1 al 15
79
el desempeño
Con base a la tabla anterior se ha creado un diagrama de Gantt para cada

propuesta, que permite una mejor visión del cronograma de actividades y sus
tiempos de realización.
Las figuras 24, 25 y 26 representan los diagramas de Gantt para las propuestas,
definición de procesos y procedimientos para trabajar bajo metodologías ágiles,
sistema de información y capacitaciones, respectivamente.
80
2018 2019
Diciembre 1 al 15
Septiembre 16 al
Octubre 16 al 31
Febrero 16 al 28
Noviembre 16 al
Septiembre 1 al
Agosto 16 al 31
Diciembre 16 al
Octubre 1 al 15
Febrero 1 al 15
Noviembre 1 al
Marzo 16 al 31
Enero 16 al 31
Agosto 1 al 15
Mayo 16 al 31
Junio 16 al 30
Marzo 1 al 15
Enero 1 al 15
Enero 1 al 15
Julio 16 al 31
Abril 16 al 30
Mayo 1 al 15
Junio 1 al 15
Julio 1 al 15
Abril 1 al 15
FECHA
ACTIVIDADES
PLANEADA
15
30
15
30
31
Informar al banco
sobre la propuesta
Febrero 1 al 5
Realizar reunión entre
la PMO y el
vicepresidente
correspondiente, para
tomar la decisión de la
implementación de la Febrero 10 al
propuesta o no 20
Presentar y explicar la
propuesta a los
equipos de trabajo,
tanto PMO como
miembros de agilismo Agosto 1 al 5
Realizar una prueba
de implementación
con un proyecto de
corta duración para su
validación y Agosto 10 a
efectividad noviembre 30
Oficializar e
implementar la
propuesta tanto en la
PMO como en el Enero 2 de
banco en general 2019
Figura 24. Diagrama de Gantt para la propuesta de la definición de procesos y procedimientos para trabajar
bajo metodologías ágiles
81
2018 2019
Septiembre 16 al 30
Noviembre 16 al 30
Septiembre 1 al 15
Diciembre 16 al 31
Noviembre 1 al 15
Diciembre 1 al 15
Octubre 16 al 31
Febrero 16 al 28
Agosto 16 al 31
Octubre 1 al 15
Febrero 1 al 15
Marzo 16 al 31
Enero 16 al 31
Agosto 1 al 15
Mayo 16 al 31
Junio 16 al 30
Marzo 1 al 15
Enero 1 al 15
Enero 1 al 15
Julio 16 al 31
FECHA
Abril 16 al 30
Mayo 1 al 15
Junio 1 al 15
Julio 1 al 15
Abril 1 al 15
ACTIVIDADES
PLANEADA
Informar al banco sobre la propuesta

Febrero 1 al 5
Contactar a la empresa prestadora
del servicio para planear una reunión
donde se hable acerca de la Febrero 20 al
plataforma 28
Realizar reunión entre la PMO y el
vicepresidente correspondiente, para
tomar la decisión de adquirir o no el
software Marzo 1 al 10
Contactar a la empresa prestadora
del servicio para confirmar la
adquisición del software, dar toda la
información de número de usuarios, Marzo 15 al
tiempo de contrato, etc. 20
La empresa prestadora del servicio
debe crear los usuarios solicitados Abril 1 a
por el banco y otros requerimientos Junio 1
Implementación del software en el
banco Junio 5 al 20
La empresa prestadora del servicio
debe realizar capacitaciones a los Agosto 1 al
usuarios que van a usar la plataforma 20
Oficializar la plataforma y empezar su Septiembre 1
uso en todos los proyectos al 15
Figura 25. Diagrama de Gantt para la propuesta del sistema de información
82
2018 2019
Septiembre 16 al 30
Noviembre 16 al 30
Septiembre 1 al 15
Diciembre 16 al 31
Noviembre 1 al 15
Diciembre 1 al 15
Octubre 16 al 31
Febrero 16 al 28
Agosto 16 al 31
Octubre 1 al 15
Febrero 1 al 15
Marzo 16 al 31
Enero 16 al 31
Agosto 1 al 15
Mayo 16 al 31
FECHA
Junio 16 al 30
Marzo 1 al 15
Enero 1 al 15
Enero 1 al 15
Julio 16 al 31
Abril 16 al 30
Mayo 1 al 15
Junio 1 al 15
ACTIVIDADES
Julio 1 al 15
Abril 1 al 15
PLANEADA
Febrero 1 al
Informar al banco sobre la propuesta
5
Realizar reunión entre la PMO y el
vicepresidente correspondiente, para Febrero 5 al
tomar la decisión de la implementación 10
de la propuesta o no
Contactar a las diferentes instituciones
y profesionales que dictarán las
Febrero 10
capacitaciones para informar acerca
al 28
del plan de capacitación y fechas de
inicio
Reunir al equipo que será capacitado
para explicarles la propuesta, definir Marzo 1 al 5
fechas y horarios
Iniciar con la capacitación de Marzo 10 a
tipificación de los proyectos abril 10
Finalizar capacitación y evaluar el Abril 10 al
desempeño 30
Mayo 1 al
conceptos básicos sobre la triple
31
restricción
Finalizar capacitación y evaluar el Junio 1 al
desempeño 19
Iniciar con la capacitación de Junio 20 a
metodologías ágiles Julio 20
Finalizar capacitación y evaluar el Julio 20 al
desempeño 31
Iniciar con la capacitación de gestión Agosto 1 al
de proyectos 31
Finalizar capacitación y evaluar el Septiembre
desempeño 1 al 15
Figura 26. Diagrama de Gantt para la propuesta de capacitaciones
83
3.4 COSTO DE LA IMPLEMENTACIÓN DEL SISTEMA DE GESTIÓN DE
PROYECTOS
Algunas de las actividades a realizar para llevar a cabo el sistema de gestión de

proyectos, tendrán un valor que representa una inversión para el banco. Estos
costos se relacionan en la tabla 12.
Para el sistema de información, se tendrán 14 usuarios involucrados en proyectos

que reúne tanto a las personas de la PMO como a los de agilísimo. Se hará un
estimado para la adquisición del sistema por un año, con una tasa representativa
de $3000 por dólar.
En cuanto a las capacitaciones, que son cuatro, tres de estas tendrán un costo
(Metodologías ágiles, tipificación de proyectos y conceptos básicos de la triple
restricción), pues la capacitación de gestión de proyectos será dictada por un
miembro de la PMO y no tendrá costo. Las tres capacitaciones que necesitan una
inversión, serán de tres clases cada una de tres horas. La hora de capacitación tiene
un valor estimado de $300.000.
Para el método de administración de metodologías ágiles, será únicamente

implementar lo propuesto en este trabajo, por lo que no incurre con ningún costo. Y
el método de administración para metodologías tradicionales ya existe
implementado dentro del banco, por tanto tampoco tiene valor monetario alguno.
Y finalmente para las dos propuestas que serán responsabilidad del banco, no
se tiene un costo estimado pues no se desarrollaron en este proyecto.
84
Tabla 12. Costos para la implementación del sistema de gestión de proyectos
ACTIVIDAD/PROPUESTA COSTO (COP) Observaciones
Sistema de Información $12’096.000 14 Usuarios
24usd/usuario/mes
1usd=3000COP
1 año
Capacitaciones $8’100.000 3 capacitaciones de 3
clases de 3 horas
Valor hora: $300.000
Método de Administración para $0 Implementar
Metodologías Ágiles propuesta
Método de Administración para $0 Ya existe
Metodologías Tradicionales
Políticas $0
Procesos relacionados con la $0
gestión de portafolio, programas y
proyectos
TOTAL $20’196.000
Como inversión total se tienen $20.196.000 una cifra que no se puede comparar
y concluir si es favorable o no, pues no se tienen valores reales de inversiones en
los proyectos que realiza el banco.
Si es posible trabajar tanto con metodologías tradicionales como con

metodologías ágiles gracias a la integración de todas las propuestas en el sistema
de gestión. Y a pesar de que no se desarrollaron dos de estas propuestas, se llevó
a cabo bien el sistema.
El correcto desarrollo de las propuestas planteadas y sus actividades, permite a

la PMO tener definidos sus procesos y procedimientos para lograr un adecuado
seguimiento y control en todo tipo de proyectos realizados, ya sea de forma
tradicional o ágil.
También permite:
• La correcta identificación de la metodología más adecuada para la ejecución y

seguimiento de los proyectos.
85
• El control y seguimiento de los proyectos bajo una plataforma adecuada.
• El adecuado acompañamiento en la gestión de los proyectos
• La integración de las dos metodologías (tradicional y ágil) en un mismo

sistema de gestión.
86
4. EVALUACIÓN DE LOS BENEFICIOS QUE SE OBTENDRÍAN EN EL BANCO
CON LA IMPLEMENTACIÓN DE UN SISTEMA DE GESTIÓN DE PROYECTOS
QUE LE PERMITA TRABAJAR TANTO CON METODOLOGÍAS
TRADICIONALES COMO CON METODOLOGÍAS ÁGILES
4.1 ESTIMACIÓN DE LOS BENEFICIOS
Al considerar el desarrollo del tercer objetivo específico, no fue posible realizar

una evaluación de tipo económica o con valores de presupuesto de los proyectos,
debido a la confidencialidad del banco no fue posible acceder a datos de cifras
reales y por ende en este capítulo se presentan los beneficios cualitativos de dos
formas: para los involucrados o interesados en los proyectos y para los diferentes
ámbitos de los proyectos.
En la tabla 12 se encuentran los beneficios a los involucrados o interesados en

los proyectos y se presentan las áreas de conocimiento en que impacta el beneficio.
Como interesados están el Banco de Occidente, la oficina de proyectos (PMO), los
otros interesados como el equipo del proyecto, el patrocinador y el cliente final. Y
como ámbitos o áreas de conocimiento se encuentran las que se consideraron más
importantes: la calidad durante el proceso, el tiempo, el recurso humano, el alcance,
el costo o presupuesto y las comunicaciones.
Estos beneficios para los interesados del proyecto, tienen unas calificaciones
para así determinar quién será el más y el menos favorecido. Las calificaciones son:
1: poco beneficio 3: medio beneficio 7: alto beneficio
87
Tabla 13. Beneficios en los diferentes interesados y áreas de los proyectos
Beneficio Área de Banco de PMO Equipo Patrocinador Cliente
conocimiento Occidente del final
en que se proyecto
impacta
Agilidad en los Tiempo 3 7 3 1 7
procesos
Reducción de Tiempo 3 3 3 3 7
tiempo de
respuesta al
cliente
Disminución en Tiempo, 1 7 3 1 1
tramitología comunicaciones
(firmas,
aprobaciones,
etc.)
Mejor Recurso 3 7 7 3 1
organización en humano,
el desarrollo de Comunicaciones
funciones
(personal)
Mejor ambiente Comunicaciones 3 7 7 1 1
laboral
Mejor Comunicaciones 7 3 3 1 1
transferencia de
información
entre áreas
Aumento en la Calidad 3 7 7 3 1
capacidad de
trabajo del
equipo
Aumento de la Calidad 7 7 7 3 1
productividad
Mayor control en Costos 7 3 1 7 1
los costos
Mayor control en Costos, calidad 7 3 3 7 3
los riesgos del
proyecto
Disminución de Costos, calidad 7 3 1 7 3
riesgos
Mejoras en la Calidad 3 3 1 3 3
gestión de la
calidad
Mayor Alcance 1 3 7 3 1
flexibilidad en los
proyectos
88
Mejor y más Alcance 3 3 7 3 3
precisa
estimación de
esfuerzo para el
desarrollo de los
entregables
requeridos por el
cliente
Después de observar la tabla 13 se puede concluir que todos los involucrados

salen favorecidos en algún aspecto. Pero la más beneficiada es la PMO y el menos
beneficiado es el cliente final como se evidencia en la figura 27. Por ende, el sistema
de gestión de proyectos aporta positivamente de diferentes maneras al Banco de
Occidente.
70
60
50
40
30
20
10
0
Banco de PMO Equipo del Patrocinador Cliente final
Occidente proyecto
Figura 27. Beneficio en los interesados del proyecto

Por otro lado se tiene la estimación del impacto en las áreas de conocimiento que
se evidencia en la tabla 14. Este impacto se clasifica en niveles de alto, medio y
bajo. Para así saber cuáles son las áreas más y menos impactadas.
89
Tabla 14. Estimación del impacto en las áreas de conocimiento
Área de Conocimiento Impacto
Integración Alto
Tiempo Alto
Costos Alto
Comunicaciones Alto
Alcance Medio
Calidad Medio
Recursos Humanos Medio
Riesgos Medio
Interesados Medio
Adquisiciones Bajo
Se puede concluir que el 90% de las áreas de conocimiento son impactadas alta
o medianamente y que únicamente el 10% tiene un impacto bajo. Por lo que
evidencia que el sistema de gestión tendrá un gran impacto en la realización de los
proyectos.
Como aspectos que no impacte o favorezca el sistema de gestión de proyectos

está la compra de productos o servicios para la realización de los proyectos, la
gestión de los contratos con terceros; por eso la gestión de las adquisiciones es la
que menos se ve impactada por el sistema.
90
5. CONCLUSIONES
Según la situación analizada en la PMO en el Banco de Occidente, y la propuesta

planteada, se puede concluir que:
 Por medio de visitas, entrevistas y un análisis de la PMO, fue posible identificar

los principales problemas que presentaba la oficina a la hora de trabajar con
metodologías ágiles. Estos basados en la poca comunicación con los encargados
de los proyectos, el no saber bajo cual metodología trabajar (tradicional o ágil) y la
inadecuada gestión de los proyectos.
 Después de la información suministrada por la empresa y el análisis de la

situación actual, se logran identificar los componentes del sistema de gestión de
proyectos. Estos son la definición de los procesos relacionados con la gestión de
portafolio, programas y proyectos, la creación y validación de políticas, las
capacitaciones al personal, el sistema de información y el método de administración
para metodologías ágiles.
 La propuesta planteada estima aportar beneficios a los todos los grupos de

interés y lograr impactar favorablemente la mayoría de las áreas de conocimiento.
Estos beneficios a pesar de que son cualitativos, permiten demostrar el buen
funcionamiento del sistema de gestión si se es implementado.
 En cuanto a beneficios e impactos, se concluye que todos los interesados logran

tener beneficios, pero quien más obtiene es la PMO. Y por otro lado el 90% de las
áreas de conocimiento son impactadas alta o medianamente y únicamente el 10%
tiene un impacto bajo.
91
6. RECOMENDACIONES
Las siguientes recomendaciones son las posibles actividades a realizar o temas

de investigación futuros, como continuación al trabajo de grado realizado:
 La implementación de la propuesta planteada dentro de la empresa, ya que

esto permitirá mejorar aspectos tanto en la PMO como en el banco.
 Para una adecuada gestión de los proyectos, indiferente por cual metodología
se realicen, es necesario un constante seguimiento por parte de los directores o
supervisores de proyectos. Y además constante comunicación entre la PMO y los
encargados de agilismo.
 Profundizar en otras metodologías ágiles, no únicamente Scrum y XP, para así

tener otros métodos de desarrollo de proyectos, pues el entorno cada día es más
cambiante y se recomienda estar preparados.
 Para afianzar y mantener la propuesta, es necesario una constante capacitación

según los nuevos tipos de proyectos o metodologías a trabajar.
 Se recomienda desarrollar aquellas acciones de mejora propuestas en el

capítulo dos, que no se llevaron a cabo en este proyecto pues necesitaban de un
conocimiento más detallado y opiniones de altos rangos.
 En la formación de ingenieros industriales dentro de la Pontificia Universidad

Javeriana Cali, deberían incluirse dentro de la asignatura “Análisis de proyectos de
ingeniería”, temas relacionados con metodologías ágiles. Pues bajo estas
metodologías es que hoy en día muchas organizaciones están trabajando.
92
BIBLIOGRAFÍA
Alaimo, D. (2013). Proyectos Ágiles con #Scrum. Ciudad Autónoma de Buenos

Aires, Argentina: Kleer.
APM North West Branch. (2015). The Practical Adoption of Agile Methodologies.
Reino Unido. Obtenido de Reino Unido.
Banco de Occidente. (2016). Manual de Gerencia de Proyectos. Cali.
Banco de Occidente. (2016). Misión. Recuperado el 8 de Mayo de 2016, de

www.bancodeoccidente.com.co/wps/portal/banco-
occidente/web/institucional/mision-vision
Banco de Occidente. (2017). Manual de gerencia de proyectos del banco. Santiago

de Cali.
Chiavenato, I. (2009). Gestión del Talento Humano (Tercera ed.). México: McGraw
Hill.
Itmplatform. (2017). ITM. Obtenido de http://www.itmplatform.com/es/
Letelier, P., & Penadés, M. (2006). Metodologías ágiles para el desarrollo de

software: eXtreme Programming (XP). Técnica Administrativa, 5(26).
Obtenido de http://www.cyta.com.ar/ta0502/v5n2a1.htm#3
Project Management Institute - PMI. (2013). Guía de los fundamentos para la

dirección de proyectos (Guía del PMBOK®) (Quinta ed.). Pensilvania,
Estados Unidos: Newton Square.
Project Management Institute - PMI. (2016). What is Project Management? Obtenido

de http://www.pmi.org/en/About-Us/About-Us-What-is-Project-
Management.aspx
93
Scrum Manager. (2015). Gestión de Proyectos Scrum Manager.
SCRUMstudy. (2016). Una Guía para el Conocimiento de SCRUM (GUÍA SBOK).

USA: SCRUMStudy.
Stanford University. (2010). Desing ME310 innovation. Obtenido de Estados Unidos:

http://web.stanford.edu/group/me310/me310_2016/about.html
94
ANEXOS
Anexo 1. Diagrama de flujo del proceso ajuste de la definición del alcance del
proyecto
95
Anexo 2. Diagrama de flujo del proceso identificación de la necesidad de la
metodología de administración del cambio
96
Anexo 3. Diagrama de flujo del proceso definición del recurso humano
97
Anexo 4. Diagrama de flujo del proceso de desarrollo del plan de
adquisiciones y contratación
98
Anexo 5. Diagrama de flujo del proceso de detalle del cronograma de
actividades-WBS
99
Anexo 6. Diagrama de flujo del proceso de identificación de riesgos
100
Anexo 7. Diagrama de flujo del proceso de construcción de costos y
presupuestos del proyecto
101
Anexo 8. Diagrama de flujo del proceso de capacitación
102
Anexo 9. Diagrama de flujo del proceso de realización de la reunión del inicio
del proyecto-KICKOFF
103
Anexo 10. Diagrama de flujo del proceso de realización del plan de trabajo en
Project Server
104
trabajo
105
Anexo 12. Diagrama de flujo del proceso de la administración de imprevistos
106
Anexo 13. Diagrama de flujo del proceso de la administración de control de
cambios
107
Anexo 14. Diagrama de flujo del proceso de la ratificación del presupuesto
108
Anexo 15. Diagrama de flujo del proceso de solicitud de aprobación
presupuesto – viajes
109
comunicaciones
110
recursos logísticos
111
Anexo 18. Diagrama de flujo del proceso de la revisión de mecanismos de
control
112
Anexo 19. Diagrama de flujo del proceso del monitoreo de riesgos
113
Anexo 20. Diagrama de flujo del proceso del monitoreo de estrategia de
integración
114
Anexo 21. Diagrama de flujo del proceso del monitoreo de solución a
imprevistos
115
Anexo 22. Diagrama de flujo del proceso de costos y presupuestos del
proyecto
116

Diseño Sistema Gestion

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Diseño Sistema Gestion

Încărcat de

Drepturi de autor:

Formate disponibile

DISEÑO DE UN SISTEMA DE GESTIÓN DE PROYECTOS QUE CONSIDERE

TRABAJAR TANTO CON METODOLOGÍAS TRADICIONALES COMO CON

JULIANA JARAMILLO JIMENO

PONTIFICIA UNIVERSIDAD JAVERIANA CALI

JULIANA JARAMILLO JIMENO

Trabajo de grado presentado como requisito parcial para optar el título de

PONTIFICIA UNIVERSIDAD JAVERIANA CALI

“La Universidad no se hace

El proyecto va dedicado a mi padre amado, Dios, a la Virgen María, por

Gracias a la Pontificia Universidad Javeriana Cali, por la formación como

Gracias al director de tesis, Jorge Enrique Álvarez, por su disposición, tiempo y

1. ASPECTOS GENERALES DEL PROYECTO ......................................... 5

1.1 EL BANCO DE OCCIDENTE ................................................................ 5

1.2 PLANTEAMIENTO DEL PROBLEMA ................................................... 7

1.3 OBJETIVOS .......................................................................................... 9

1.3.1 Objetivo general ................................................................................. 9

1.3.2 Objetivos específicos........................................................................ 10

1.4 JUSTIFICACIÓN ................................................................................. 10

1.5 ALCANCE ........................................................................................... 10

1.6 MARCO TEÓRICO .............................................................................. 11

2. ANÁLISIS DE LAS METODOLOGÍAS Y LOS PROCESOS

2.1 DESCRIPCIÓN DE LA OFICINA DE GESTIÓN DE PROYECTOS .... 22

2.1.1 Organigrama .................................................................................... 22

2.1.2 Recursos técnicos ............................................................................ 23

2.2 DESCRIPCIÓN DE LOS PROYECTOS .............................................. 23

2.2.2 Aval .................................................................................................. 24

2.3 PROCESOS Y SUBPROCESOS PARA LA REALIZACIÓN DE UN

2.3.1 Proceso general ............................................................................... 25

2.3.2 Etapas .............................................................................................. 25

2.3.2.1 Planeación de los requerimientos ................................................. 25

2.3.2.2 Ejecución de los proyectos ............................................................ 32

2.3.2.3 Control de los proyectos ................................................................ 35

2.3.2.4 Cierre y verificación de los proyectos ............................................ 38

2.4 DESCRIPCIÓN DE LA METODOLOGÍA ACTUAL ............................. 41

2.4.1 Proyectos ejecutados bajo metodología tradicional ......................... 42

2.4.2 Proyectos ejecutados bajo metodologías ágiles ............................... 43

2.5 ANÁLISIS DE LA SITUACIÓN ACTUAL VERSUS COMO SE DEBERÍA

2.6 IDENTIFICACIÓN DE OPORTUNIDADES DE MEJORA DENTRO DE

3. DISEÑO DE UN SISTEMA DE GESTIÓN DE PROYECTOS PARA

3.1 DESARROLLO DE LAS ACCIONES CORRECTIVAS ........................ 56

3.1.1 DEFINICIÓN LOS PROCESOS Y PROCEDIMIENTOS PARA

3.1.2 SISTEMA DE INFORMACIÓN ......................................................... 63

3.1.3 CAPACITACIONES .......................................................................... 66

3.2 MÉTODO ÁGIL ADAPTADO A LA PROPUESTA DE ADMINITRACIÓN

3.2.2 Planificación y Estimación ................................................................ 74

3.2.3 Implementación ................................................................................ 75

3.2.4 Revisión y Retrospectiva .................................................................. 76

3.2.5 Lanzamiento ..................................................................................... 77

3.3 ACTIVIDADES PARA LA IMPLEMENTACIÓN DE LAS

3.4 COSTO DE LA IMPLEMENTACIÓN DEL SISTEMA DE GESTIÓN DE

4. EVALUACIÓN DE LOS BENEFICIOS QUE SE OBTENDRÍAN EN EL

4.1 ESTIMACIÓN DE LOS BENEFICIOS ................................................. 87

Tabla 1. Roles, eventos y artefactos en Scrum ..................................................... 19

Tabla 2. Probabilidad de los eventos de riesgo ..................................................... 29

Tabla 3. Impacto de los eventos de riesgo ............................................................ 29

Tabla 4. Categoría ................................................................................................. 30

Tabla 5. Estado ..................................................................................................... 30

Tabla 6. Plantilla consolidada ................................................................................ 33

Tabla 7. Oportunidades de mejora ........................................................................ 49

Tabla 8. Acciones correctivas................................................................................ 52

Tabla 9. Plan de capacitación ............................................................................... 70

Tabla 10. Actividades y fechas según la propuesta .............................................. 78

Tabla 13. Estimación del impacto en las áreas de conocimiento .......................... 90

Figura 1. Ejemplo de ciclo de vida predictivo ............................................ 13