Embed Size (px)
Citation preview
1
FACULTAD DE INGENIERÍA
Carrera de Ingeniería Industrial y Comercial
APLICACIÓN DE UN MÉTODO MIXTO PARA MEJORAR LA GESTIÓN DE
PROYECTOS TI
Tesis para optar el Título Profesional de Ingeniero Industrial y Comercial
FALCON DELGADO, ALEXANDER ALDAIR
Asesor:
Ricardo López Guevara
Lima – Perú
2017
2
3
JURADO DE LA SUSTENTACION ORAL
……………….……………………………………… Presidente
……………….……………………………………… Jurado 1
……………….……………………………………… Jurado 2
_____________________________________ Entregado el: 12/12/2017 Aprobado por: …………………………….. ……………………………..
Graduando 1 Asesor de Tesis:
4
UNIVERSIDAD SAN IGNACIO DE LOYOLA FACULTAD DE INGENIERIA
DECLARACION DE AUTENTICIDAD
Yo, Alexander Aldair Falcón Delgado, identificado/a con DNI N° 75417461 Bachiller del Programa
Académico de la Carrera de Ingeniería Industrial y Comercial de la Facultad de Ingeniería de la
Universidad San Ignacio de Loyola, presento mi tesis titulada:
Aplicación de un método mixto para mejorar la gestión de proyectos TI. Declaro en honor a la
verdad, que el trabajo de tesis es de mi autoría; que los datos, los resultados y sus análisis e
interpretación, constituyen mi aporte. Todas las referencias han sido debidamente consultadas y
reconocidas en la investigación.
En tal sentido, asumo la responsabilidad que corresponda ante cualquier falsedad y ocultamiento
de la información aportada. Por todas las afirmaciones, ratifico lo expresado, a través de mi firma
correspondiente.
Lima, diciembre de 2017
…………………………………….………….. Alexander Aldair Falcón Delgado
DNI N° 75417461
5
EPÍGRAFE
“El científico no tiene por objetivo un
resultado inmediato. Él no espera que
sus ideas avanzadas sean fácilmente
aceptadas. Su deber es sentar las
bases para aquellos que están por
venir, y señalar el camino.”
(Nikola Tesla, 1943)
6
INDICE DE CONTENIDO
RESUMEN 13
ABSTRACT 14
INTRODUCCION 15
IDENTIFICACION DEL PROBLEMA 16
FORMULACION DEL PROBLEMA 28
Problema general 29
Problemas específicos 29
MARCO REFERENCIAL 30
Antecedentes internacionales 30
Antecedentes nacionales 31
Estado del arte 33
Marco teórico 37
Proyectos. 37
Gestión de proyectos con PMBOK 5ta Edición. 39
Gestión de proyectos con PRINCE2. 47
Gestión de proyectos con SCRUM. 53
Ciclo de mejora continúa 55
Gestión de valor ganado. 56
Metodología mixta propuesta 57
Elementos del método mixto propuesto 59
OBJETIVOS 80
Objetivo general 80
Objetivos específicos 80
7
JUSTIFICACION 81
HIPOTESIS 82
Hipótesis general 82
Hipótesis especifica 82
MATRIZ DE CONSISTENCIA 83
MARCO METODOLOGICO 84
VARIABLES 84
POBLACION Y MUESTRA 84
UNIDAD DE ANALISIS 88
INTRUMENTOS Y TECNICAS 88
PROCEDIMIENTOS Y METODO DE ANALISIS 92
RESULTADOS 94
DISCUSIONES 96
CONCLUSIONES 97
RECOMENDACIONES 98
REFERENCIAS 99
ANEXOS 102
8
INDICE DE TABLAS
Tabla 1 Estructura del método actual de la empresa. 20
Tabla 2 Evaluación de procesos del método actual en la empresa. 21
Tabla 3 Procesos clave de cada nivel de madurez de la empresa. 22
Tabla 4 Evaluación de proyectos según cumplimiento de alcance. 23
Tabla 5 Evaluación de proyectos según cumplimiento del tiempo. 24
Tabla 6 Evaluación de proyectos según cumplimiento de presupuesto. 25
Tabla 7 Áreas de conocimiento según PMBOK 5ta edición. 45
Tabla 8 Grupos de proceso por área de conocimiento. 46
Tabla 9 Procesos del método SCRUM 54
Tabla 10 Matriz de consistencia 83
Tabla 11 Tamaño de población 85
Tabla 12 Formato de análisis de resultados de proyectos 89
Tabla 13 Formato histórico de proyectos 90
Tabla 14 Consolidado de resultados de proyectos históricos 91
Tabla 15 Datos entrados al software SPSS 93
Tabla 16 Variables entradas al software SPSS 93
Tabla 17 Resultado de análisis de tablas cruzadas 94
Tabla 18 Resultado de prueba chi-cuadrado en software SPSS 95
9
INDICE DE FIGURAS
Figura 1 Organigrama general de la empresa. 19
Figura 2 Análisis causa-efecto aplicado a proyectos. 27
Figura 3 Restricciones en gestión de proyectos según PMBOK. 40
Figura 4 Ciclo de vida del proyecto según PMBOK. 41
Figura 5 Red lógica de relación grupo de procesos según PMBOK. 43
Figura 6 Estructura de método PRINCE2. 48
Figura 7 Red lógica de relación proceso PRINCE2. 51
Figura 8 Flujo de proceso Scrum. 53
Figura 9 Modelo de relación de mejora continua entre procesos. 55
Figura 10 Curva S de la gestión del valor ganado. 56
Figura 11 Elementos clave de métodos tomados. 58
Figura 12 Elementos del método mixto propuesto. 59
Figura 13 Proceso de análisis y evaluación de caso de negocio. 62
Figura 14 Proceso de definición del caso de negocio como proyecto. 62
Figura 15 Proceso de recopilación y evaluación de requisitos. 63
Figura 16 Proceso de desarrollo de acta constitutiva del proyecto. 64
Figura 17 Proceso de definición de alcance del proyecto. 65
Figura 18 Proceso de planificación de la gestión del alcance y las actividades
del backlog. 66
Figura 19 Proceso de planificación del cronograma. 66
Figura 20 Proceso de planificación de la gestión del equipo del proyecto. 67
Figura 21 Proceso de planificación de la gestión de la calidad. 68
Figura 22 Proceso de la planificación de la gestión del riesgo. 69
Figura 23 Proceso de planificación de la gestión del presupuesto. 69
Figura 24 Proceso de planificación del ciclo de la mejora continua. 70
Figura 25 Proceso de integración del plan del proyecto. 71
Figura 26 Proceso de creación de los entregabes por sprints. 72
Figura 27 Proceso de ejecución y control sobre los procesos de gestión. 73
Figura 28 Proceso de aprobación y transferencia de entregables. 74
Figura 29 Proceso de cierre con clientes (internos y externos). 75
Figura 30 Proceso de elaboración del informe final de desempeño del proyecto.
76
Figura 31 Formas usadas para diagramación 77
Figura 32 Dieciocho procesos del método mixto. 78
Figura 33 Iteración entre procesos de inicio y planificación con procesos de
ejecución y control. 79
Figura 34 Presentación de población 87
10
INDICE DE ANEXOS
Anexo 1: Contrato de alcance del segundo proyecto de Entidad Pública 4 103
Anexo 2: Incumplimiento de alcance predefinido en contrato 107
Anexo 3: Contrato del cuarto proyecto de Entidad Pública 3 111
Anexo 4: Incumplimiento de tiempo predefinido en contrato 113
Anexo 5: Incumplimiento de presupuesto por compra no planificada 114
Anexo 6: Formato acta de constitución del proyecto 115
Anexo 7: Panel general de control de herramientas informáticas 116
Anexo 8: FODA - Modelo de análisis de entorno 116
Anexo 9: Formato de registro interesados y requerimientos 117
Anexo 10: Modelo de EDT 118
Anexo 11: Formato registro de riesgos 119
Anexo 12: Modelo de cronograma 120
Anexo 13: Diagrama de gantt en software GanttProject 121
Anexo 14: Análisis de valor ganado 122
Anexo 15: Indicadores y curva S 123
Anexo 16: Análisis de avance de actividades por horas 124
Anexo 17: Burndown chart de avance de actividades 125
11
DEDICATORIA
La presente tesis está
dedicada a mis padres por
su inalcanzable deseo de
superación. También para
las personas que no
renuncian al deseo de poder
alcanzar la felicidad.
12
AGRADECIMIENTO
Agradezco a las personas
que siempre me apoyaron y
compartieron un poco de su
experiencia conmigo.
13
RESUMEN
La investigación se basa en la propuesta de un método para mejorar la gestión de proyectos
en una empresa consultora. Esta empresa carece de un método comprobado científicamente
para la gestión de proyectos, por lo que usualmente se cometen errores que causan el
fracaso de los proyectos.
Se evalúa el nivel de madurez de los procesos clave del área. Luego se realiza un
análisis de los resultados de los últimos proyectos de la empresa. Posteriormente, se realiza
un análisis de Ishikawa para dar con las causas raíces de los problemas en los proyectos.
El marco referencial presenta los cuerpos de contenido usados en la mayoría de los
proyectos, refiriéndose al PMBOK, PRINCE2 y SCRUM. Luego se explica el método
propuesto derivado del estudio y análisis de los contenidos nombrados, buscando que el
método se encuentre bien estructurado pero que también sea ágil.
Se presenta la matriz de consistencia, la cual detalla los problemas, objetivos
planteados, hipótesis formuladas, variables (independiente y dependiente) y el método a
usar.
Se toma una muestra en base al cálculo de las poblaciones finitas, donde cada
elemento tiene la misma probabilidad de ser elegido. Se recogen los datos de la unidad de
análisis y con un software estadístico se realiza la prueba de independencia chi-cuadrado
con el fin de validar la veracidad de la hipótesis nula. Luego se muestran los resultados
obtenidos.
Por último, se discuten los resultados con otras investigaciones, se concluye acerca
de los resultados de la investigación y se describen las recomendaciones.
Palabras clave: PMBOK, PRINCE2, SCRUM, ágil, nivel de madurez, análisis de Ishikawa.
14
ABSTRACT
The research is based on the proposal of a method to improve the project management in a
consulting company. This company lacks a scientifically proven method for managing
projects, so mistakes are usually caused that cause the failure of the projects.
The level of maturity of the key processes of the area is evaluated. Then an analysis
of the results of the last projects of the consulting company is made. Afterwards, an Ishikawa
analysis is carried out to find the root causes of the problems in the projects.
The frame of reference presents the bodies of content used in most projects, referring
to the PMBOK, PRINCE2 and SCRUM. Then the thesis explains the proposed method
derived from the study and analysis of the named contents, looking for the method to be well
structured but also to be agile.
The consistency matrix is presented, which details the problems, objectives,
hypotheses formulated, variables (independent and dependent) and the methodology to be
used.
A sample is taken based on the calculation of finite populations, where each element
has the same probability of being chosen. The data of the unit of analysis are collected and
will a statistical software the chi-square independence test is carried out in order to validate
the accuracy of the null hypothesis. Then the results obtained are shown.
Finally, the results are discussed with other researches, the results of the research
are concluded and the recommendations are described.
Key words: PMBOK, PRINCE2, SCRUM, agile, level of maturity, Ishikawa analysis.
15
INTRODUCCION
La investigación se desarrolla dentro del ámbito de aplicación de los proyectos. Hoy en día,
la única forma de sostener a una empresa, una economía, un país, es llevando a cabo
operaciones diarias e impulsando proyectos para lograr saltos significativos de valor. Estos
esfuerzos temporales se distinguen de las operaciones por ser de carácter único y con un
tiempo de vida finito.
El desarrollo de la tesis pasa por identificar un problema relacionado a la forma en
cómo se gestionan los proyectos y proponer un método para mejorar su forma de gestión.
Para esto, la investigación se divide en tres partes bien diferenciadas entre sí.
La primera parte, trata sobre la identificación, formulación del problema y la
presentación del marco referencial, en donde se detallan los componentes del método mixto
propuesto.
La segunda parte, trata sobre el planteamiento de los objetivos, la justificación, el
planteamiento de la hipótesis, la elaboración y presentación de la matriz de consistencia, la
descripción del marco metodológico, la definición de las variables, población, tamaño de
muestra, la selección de la unidad de análisis, la presentación de los instrumentos y las
técnicas a usar para recolectar los datos a ser procesados, y el método de análisis de la
información.
La tercera parte, trata sobre la presentación de los resultados, la explicación de las
discusiones, las conclusiones de la investigación y las recomendaciones.
16
IDENTIFICACION DEL PROBLEMA
Hoy en día el éxito de los proyectos se mide en función de alcanzar no sólo el producto o
entregable principal, sino también en cumplir con los objetivos trazados en un inicio, cumplir
con satisfacer la necesidad del usuario o cliente final portador del producto o entregable. Los
objetivos principales y más comunes en todo proyecto en cualquier ámbito de aplicación de la
industria se caracterizan por la necesidad de realizar esfuerzos en entregar el proyecto dentro
del tiempo planeado, cumpliendo el alcance definido y asegurando la ejecución dentro del
presupuesto establecido. El cumplimiento de estos objetivos aumenta la probabilidad del éxito
del proyecto. Además, se asegura la calidad del entregable o producto, la satisfacción del
cliente y el uso óptimo de recursos. “El alcance es la descripción de los límites del proyecto,
define lo que el proyecto realizará para lograr sus objetivos”, (Díaz, 2009, págs. 3-4)
Las empresas buscan alcanzar estos objetivos a través de la gestión de los proyectos
bajo distintos métodos, guías prácticas o la propia experiencia empírica adquirida para
gestionar los proyectos. La poca comprensión y una inadecuada gestión por carecer de
métodos, procesos, procedimientos, técnicas y herramientas bien definidos en su ámbito de
aplicación conllevan a empezar los proyectos sin tener claro los supuestos y restricciones en
un inicio, a gestionar sin haber planificado, a ejecutar sin conocer el alcance y los riesgos, a
controlar sin tener en cuenta los indicadores específicos por cada entregable y a concluir los
proyectos sin haber logrado el cierre formal que garantice el éxito.
Desde los albores de la humanidad, la gestión de proyectos siempre ha estado presente
en la vida personal y colectiva del ser humano. Los monumentos que podemos apreciar hoy en
día como La Gran Muralla China, La Gran pirámide de Giza, El Coliseo Romano, entre otros,
son ejemplos de ideas con un objetivo claro convertidas en proyectos únicos que perduran
hasta la actualidad. Las empresas, comunidades, países y nuestra propia vida conservan la
única característica de naturaleza innata de los proyectos, todo tiene un inicio y todo tiene un
fin con un resultado distinto. Para llevar a cabo la ejecución de un proyecto es necesario
establecer métodos sistemáticos capaces de reaccionar a súbitos cambios generados por
distintos factores técnicos, políticos, legales, sociales, naturales.
A lo largo del tiempo, la gestión de proyecto ha sido considerada como un arte y no
como una ciencia. Es en la época moderna a partir de 1900 que se empieza a vislumbrar la
17
gestión de proyectos como una ciencia, con la introducción de los diagramas de Gantt, la
secuencia de actividades, el avance tecnológico de los sistemas e instituciones que promueven
guías y metodologías para la gestión.
En la época moderna se han desarrollado proyectos de gran envergadura, como el
proyecto Manhattan para el desarrollo de primera bomba atómica en 1945, la construcción del
Colisionador de Hadrones para su uso científico en 2008. Ambos proyectos demuestran la
aplicación de la gestión en entornos multidisciplinarios. Por otro lado, podemos recordar el
proyecto del décimo lanzamiento del transbordador espacial Challenger en 1986, cuya falla
principal se atribuyó a una causa de gestión, por no identificar ni realizar una medición
probabilística de ocurrencia e impacto del riesgo funcional del transbordador. Hoy podemos
deducir que, la gestión de los proyectos implica la aplicación de conocimientos, técnicas,
habilidades para trabajar en distintos entornos.
En el Perú podemos hablar técnicamente de proyectos grandes que no cumplieron con
el presupuesto establecido, entre ellos tenemos la construcción de la carretera interoceánica
sur (IIRSA), cuyo presupuesto inicial fue incrementado en 257% partiendo de aproximadamente
1161 $MM y terminando con un costo acumulado que bordeó los 4000 $MM, esto debido a la
extensión en el tiempo de cuantiosas adendas. Proyectos medianos que no cumplieron con el
plazo de entrega, como la construcción del intercambio vial a desnivel Benavides, en el distrito
de Surco, cuya obra se inició a cargo de una contratista de construcciones en el último trimestre
del año 2014, teniendo como plazo de entrega 18 meses y culminando en el primer trimestre
del 2017, lo cual refleja la ineficiencia que se tiene en el país al planificar y ejecutar proyectos.
Hoy en día, tenemos proyectos atrasados en el territorio nacional como la ampliación
del aeropuerto Jorge Chávez en el Callao, la concesión del aeropuerto de Chinchero en Cusco
paralizado por observaciones en su adenda de contrato, la construcción de la segunda línea
del metro de Lima que fue promovida para que concluya en el 2019, hoy en día no alcanza el
porcentaje de avance planeado siendo alertado por el Organismo Supervisor de la Inversión en
Infraestructura de Trasporte de Uso Público (OSITRAN). También se tiene proyectos sobre
costeados, como la modernización de la refinería de Talara, la cual en un inicio se estimó en
1335 $MM para la construcción de la unidad de proceso, unidades auxiliares e inversiones
complementarias. Hoy en día la Contraloría General de la República advierte el sobrecosto no
sustentado a través de un informe publicado en el mes de mayo.
18
El problema abordado en este trabajo se presenta en el área de proyectos de una
empresa consultora del sector privado. La empresa consultora, fundada con capitales peruanos
dedicada a la consultoría y asesoría, brinda soluciones en tecnología de la información y
comunicación desde hace más de 10 años. El área de proyectos dirige sus esfuerzos en la
participación de concursos públicos que promueve el estado peruano a través del Sistema
Electrónico de Contrataciones del Estado (SEACE), así también se enfoca en la captación de
clientes del sector privado que quieran mejorar sus procesos aplicando la tecnología. El área
se especializa en proponer, vender, implementar y administrar soluciones en sistema de gestión
de colas, terminales multimedia y soluciones en biometría, actualmente muy requeridas por el
alto grado de impacto tecnológico en la mejora y control de procesos.
En su larga experiencia los proyectos del área han sido entregados no siempre
cumpliendo con los objetivos trazados en un inicio. Muchas veces se ha tenido problemas de
comunicación y barreras de gestión para el desarrollo y entrega de los proyectos. El análisis
del por qué no se logran los objetivos ha sido identificado y definido por la carencia de un
método práctico para gestionar los proyectos en la empresa. Según (Nuñez, 2013) “la no
utilización o mala utilización de metodologías de trabajo representa el 31% de los motivos que
originan el fracaso en el cumplimiento en los proyectos.” Actualmente los proyectos llevados en
la empresa siguen un contenido publicado por la empresa en su portal de intranet. Este
contenido está orientado a la gestión de proyectos se enfoca en lo recomendado por el PMI y
ha sido elaborado por una PMO orientada al desarrollo de software. El contenido no muestra
un método para gestionar proyectos en la empresa. En la evaluación se puede identificar que
la estructura, formatos, herramientas no son claros y no cumplen con el objetivo principal de
orientar a la gestión de proyectos.
El método propuesto por la empresa no necesariamente es la ideal para los proyectos
del área, el usar un método inadecuado puede afectar la productividad de las demás áreas
funcionales y los objetivos estratégicos de la empresa. Esto debido al factor ambiental de la
estructura organizacional orientada a proyectos. Los gestores del área de proyectos de la
empresa distan de usar el contenido y gestionan los proyectos según el criterio y experiencia
de cada gestor. Por tal razón, es necesario transformar la forma en cómo se gestionan los
proyectos dentro de la empresa en una actividad soportada por un método efectivo que apoye
las habilidades de gestión.
19
A continuación, se muestra la representación de jerarquía en la estructura de la empresa
consultora.
Figura 1 Organigrama general de la empresa. Fuente: Elaboración propia.
El organigrama presentado incluye una gerencia general que actúa como uno de los
principales interesados en los proyectos internos y externos de la organización, también se
incluye gerencias funcionales que juegan roles importantes como la gerencia de Recursos
Humanos, administrando las planillas, seguros, vacaciones entre otros. La gerencia de
Administración y Finanzas que aprueba la evaluación de los proyectos para poder financiarlos
con recursos internos o externos. La gerencia de Sistemas que se encarga del desarrollo de
soluciones siguiendo los requerimientos funcionales y de diseño propuestos por el área de
proyectos. La gerencia de Proyectos, tiene como Core la venta y ejecución de proyectos,
teniendo capacidad de autonomía para solicitar, gestionar y responsabilizarse de los recursos
operativos y presupuesto otorgado.
A continuación, se muestra la estructura del método usado actualmente en la empresa.
GERENCIA GENERAL
GERENCIA DE RR.HH
GERENCIA DE ADMINISTRACION
Y FINANZAS
GERENCIA DE PROYECTOS
GERENCIA DE SISTEMAS
GERENCIA COMERCIAL
STAFF DE ASESORES
20
GRUPO DE PROCESO
ORDEN CONTENIDO PROPUESTO
DESCRIPCIÓN DEL CONTENIDO OBJETIVO DE CONTENIDO APORTE EN
GESTIÓN
INICIO 1° CERT_PM_001_PROJECTCHARTER
PRESENTA PLANTILLA PARA COLOCAR INFORMACIÓN RELEVANTE EN LA CREACIÓN DE UN PROYECTO.
DESARROLLAR EL ACTA DE CONSTITUCIÓN DEL PROYECTO.
MEDIO
PLANIFICACIÓN
2° CERT_PM_002_REQUERIMENTSDOCUMENTS
PRESENTA PLANTILLA PARA COLOCAR INFORMACIÓN RELEVANTE DE LO REQUERIDO EN PARA EL PROYECTO.
RECOGER LOS REQUERIMIENTOS Y CRITERIOS DE ACEPTACIÓN DE CADA INTERESADO.
BAJO
PLANIFICACIÓN
3° CERT_PM_003_PROJECTSCOPESTATEMENT
PRESENTA PLANTILLA PARA COLOCAR INFORMACIÓN RELEVANTE DEL ALCANCE.
DESCRIBIR EL ALCANCE DEL PROYECTO.
BAJO
PLANIFICACIÓN
4° CERT_PM_004_REQUERIMENTSTRACEABILITYMATRIX
PRESENTA PLANTILLA PARA REGISTRAR INFORMACIÓN RELEVANTE EN LA MATRIZ DE TRAZABILIDAD
RECOGER REQUISITOS, ASOCIAR A LOS OBJETIVOS Y EDT, INDICANDO COMO SE REALIZARÁ SU VERIFICACIÓN Y VALIDACIÓN.
BAJO
PLANIFICACIÓN
5° CERT_PM_005_RISKREGISTER
PRESENTA PLANTILLA PARA REGISTRAR LOS RIESGOS IDENTIFICADOS Y PROBABILIDAD DE OCURRENCIA E IMPACTO.
RECOGER LA INFORMACIÓN DE RIESGOS, CALIFICARLOS, ASIGNAR RESPONSABLES Y PLANTEAR RESPUESTAS.
BAJO
PLANIFICACIÓN
6° PLANTILLA EDT_TEMPLATE WBS
PRESENTA PLANTILLA EN HOJA DE CALCULO PARA ORDENAR LOS ENTREGABLES EN DIAGRAMA DE JERARQUÍA.
ORDENAR LOS ENTREGABLES EN UN DIAGRAMA JERARQUICO.
BAJO
EJECUCIÓN 7° CERT_PM_006_CHANGELOG
PRESENTA PLANTILLA PARA DESCRIBIR Y REGISTRAR LOS CAMBIOS.
REGISTRAR INFORMACIÓN RELEVANTE A LOS CAMBIOS SOLICITADOS.
BAJO
EJECUCIÓN 8° CERT_PM_007_TEAMMEMBERSTATUSREPORT
PRESENTA PLANTILLA DE REPORTE DE ACTIVIDADES.
REGISTRAR LA DESCRIPCIÓN DEL AVANCE DE LAS ACTIVIDADES DEL EQUIPO DE PROYECTO.
BAJO
CIERRE 9° CERT_PM_008_LESSONSLEARNED
PRESENTA PLANTILLA PARA REGISTRAR QUÉ FUNCIONÓ BIEN Y QUÉ SE PUEDE MEJORAR.
DOCUMENTAR LAS LECCIONES APRENDIDAS.
BAJO
CIERRE 10° CERT_PM_009_PROJECTCLOSEOUT
PRESENTA PLANTILLA PARA REGISTRAR OBJETIVOS ALCANZADOS, CRITERIOS DE ÉXITO, ENTREGABLES Y VARIANZA.
FORMALIZAR EL CIERRE DEL PROYECTO.
MEDIO
Tabla 1 Estructura del método actual de la empresa. Fuente: Elaboración propia.
21
El criterio de aporte de gestión del método actual, ha sido valorado según la
comparación de los objetivos principales de cada grupo de proceso que recomienda el
contenido del PMBOK para la gestión de proyectos frente a lo que ofrece el método actual. Para
la comparación se usaron los siguientes criterios: Bajo, cuando el contenido no impacta en
lograr los objetivos de cada grupo de procesos. Medio, cuando el contenido contribuye al logro
del objetivo. Por último, alto, cuando es de vital importancia para alcanzar los objetivos.
A continuación, se muestra la comparación para definir criterios de evaluación.
GRUPO DE PROCESO
PMBOK
OBJETIVO PRINCIPAL GRUPO DE PROCESOS
PMBOK
MÉTODO ACTUAL
OBJETIVO PRINCIPAL GRUPO DE PROCESOS MÉTODO ACTUAL
CRITERIO
INICIO
FORMALIZAR EL ACTA DE CONSTITUCIÓN EN CONSENSO CON LOS INTERESADOS DEL CLAVE.
INICIACIÓN DESARROLLAR EL ACTA DE CONSTITUCIÓN DEL PROYECTO.
MEDIO
PLANIFICACIÓN
PREPARAR EL PLAN DE DIRECCIÓN DEL PROYECTO INCLUYENDO LOS PLANES SUBSIDIARIOS.
PLANIFICACIÓN
RECOGER LOS REQUERIMIENTOS Y CRITERIOS DE ACEPTACIÓN DE CADA INTERESADO. DESCRIBIR EL ALCANCE DEL PROYECTO RECOGER REQUISITOS. RECOGER INFORMACIÓN DE RIESGOS. ORDENAR LOS ENTREGABLES EN DIAGRAMA JERÁRQUICO.
BAJO
EJECUCIÓN
ALCANZAR LOS ENTREGABLES E HITOS DEL PROYECTO DENTRO DE LAS TRES RESTRICCIONES BÁSICAS DE ALCANCE, TIEMPO Y PRESUPUESTO
EJECUCIÓN
REGISTRAR INFORMACIÓN RELEVANTE A LOS CAMBIOS SOLICITADOS. REGISTRAR LAS ACTIVIDADES DEL AVANCE DEL EQUIPO DE PROYECTO.
BAJO
SEGUIMIENTO Y CONTROL
ASEGURAR LA EJECUCIÓN DE ACTIVIDADES Y CONTROLAR LOS CAMBIOS.
- - BAJO
CIERRE CERRAR LAS ADQUISICIONES Y CERRAR EL PROYECTO
CIERRE
DOCUMENTAR LAS LECCIONES APRENDIDAS. FORMALIZAR CIERRE DEL PROYECTO.
BAJO
Tabla 2 Evaluación de procesos del método actual en la empresa. Fuente: Elaboración propia.
Se agrega a la evaluación que el método usado actualmente, no contiene procesos de
seguimiento y control. La importancia del control de calidad y cambios puede no estar siendo
considerada en la gestión de proyectos.
22
Independientemente del método usado es importante tener en cuenta el diagnóstico de
como el área de proyectos ha gestionado sus proyectos en el tiempo. Se debe analizar en qué
nivel de madurez se encuentra y cuáles son los objetivos que se han visto afectados en cada
proyecto. Para esto, se evalúa los procesos clave del área de proyectos y su entorno, y se
recoge los resultados de proyectos concluidos por plazos de ejecución.
A continuación, se muestra la evaluación del nivel de madurez aplicado al área de
proyectos de la empresa. Se utiliza el “Modelo de madurez de las capacidades (CMM) el cual
proporciona un marco para organizar los pasos evolutivos en cinco niveles de madurez que
establecen los fundamentos sucesivos para la mejora continua de procesos.” (C. Paulk, Curtis,
Bet Chrissis, & V. Weber, 1993, pág. 7).
PROCESOS CLAVE
INICIAL REPETIBLE DEFINIDO GERENCIADO OPTIMIZADO
INFRAESTRUCTURA EN TI
NO EXISTE INFRAESTRUCTUR
A TI PARA LA OPERACIÓN.
EXISTE INFRAESTRUCTUR
A TI NO AJUSTADO A LA
NECESIDAD.
EXISTE INFRAESTRUCTURA TI AJUSTADA A LA NECESIDAD.
SE RETROALIMENTA EL USO DE LOS
SISTEMAS.
SISTEMA OPTIMIZADO
PARA PREDICCIÓN Y
TOMA DE DECISIONES.
CUMPLIMIENTO DE LOS SLA
SE CARECE DE MÉTRICAS PARA
ESTABLECER SLA.
EXISTEN MÉTRICAS PERO LOS SLA NO SON
DEFINIDOS CLARAMENTE.
SE TIENEN DEFINIDOS LOS
SLA.
SE TIENE SLA'S INTEGRADOS
ENTRE SÍ.
PREDICCIÓN DE INCIDENTES
GESTIÓN DE LAS
ACTIVIDADES
NO EXISTE PROCEDIMIENTOS
DE GESTIÓN
EXISTEN PROCEDIMIENTOS
DE GESTIÓN NO REVISADOS Y PROMOVIDOS.
PROCEDIMIENTOS REVISADOS Y APROBADOS.
EVALUACIÓN Y MEDICIÓN DE
PROCEDIMIENTOS ESTABLECIDOS.
MEJORA CONTINUA PARA
MEJORAR Y AGILIZAR LA
GESTIÓN.
CONTROL DE LOS
PROYECTOS
SE CARECE DE INFORMACIÓN,
HERRAMIENTAS Y PROCEDIMIENTOS
PARA EL CONTROL.
SE USAN HERRAMIENTAS
BÁSICAS Y PROCEDIMIENTOS
PARA EL CONTROL DE PROYECTOS.
SE USA HERRAMIENTAS PROGRAMABLES
Y PROCEDIMIENTOS
APROBADOS PARA
CONTROLAR LOS PROYECTOS.
EVALUACIÓN Y MEDICIÓN DE
PROCEDIMIENTOS DE CONTROL
ESTABLECIDOS.
MEJORA CONTINUA PARA
MEJORAR EL CONTROL DE PROYECTOS.
Tabla 3 Procesos clave de cada nivel de madurez de la empresa.
Fuente: Elaboración propia.
Según el ajuste en el modelo del nivel de madurez CMM, la empresa consultora se
encuentra en el segundo nivel de madurez denominado por el CMM como procesos repetibles
sin alcanzar una definición clara, este resultado muestra que el nivel en procesos es prematuro.
23
Posteriormente, se revisa el cumplimiento del alcance en los proyectos de la empresa
consultora. Se indica que los datos proporcionados son reales, sin embargo; los nombres de
entidades, empresas y nombre de proyectos han sido reemplazados con fines de conservar
información sensible sobre sus resultados.
PROYECTO CUMPLIÓ CON
ALCANCE CRITERIO DE INCUMPLIMIENTO GOLD PLATING
ENTIDAD PUBLICA 1
NO NINGUNO SE ENTREGÓ BIENES ADICIONALES.
ENTIDAD PUBLICA 2
SÍ NINGUNO NINGUNO
ENTIDAD PUBLICA 3
NO NO SE ENTREGÓ EL PRODUCTO DE
ACUERDO A LOS CRITERIOS DE ACEPTACIÓN.
NINGUNO
ENTIDAD PUBLICA 4
SÍ NINGUNO NINGUNO
ENTIDAD PUBLICA 5
SÍ NINGUNO NINGUNO
ENTIDAD PUBLICA 7
NO NO SE ENTREGÓ EL PRODUCTO DE
ACUERDO A LOS CRITERIOS DE CALIDAD
NINGUNO
ENTIDAD PUBLICA 4
NO NINGUNO SE ENTREGÓ MÓDULOS METÁLICOS
ADICIONALES.
ENTIDAD PUBLICA 3
NO NINGUNO SE ENTREGÓ FUNCIONALIDADES
ADICIONALES AL SISTEMA.
ENTIDAD PUBLICA 1
SÍ NINGUNO NINGUNO
ENTIDAD PUBLICA 3
SÍ NINGUNO NINGUNO
ENTIDAD PUBLICA 3
SÍ NINGUNO NINGUNO
ENTIDAD PRIVADA 1
NO NO SE ENTREGÓ MÓDULOS
METÁLICOS DE ACUERDO A LOS CRITERIOS DE CALIDAD EXIGIDOS.
SE ENTREGÓ MÓDULOS METÁLICOS CON FUNCIONALIDADES
ADICIONALES.
ENTIDAD PRIVADA 2
NO NO SE ENTREGÓ SISTEMA CON FUNCIONALIDADES EXIGIDAS.
SE ENTREGÓ FUNCIONALIDADES ADICIONALES AL SISTEMA.
ENTIDAD PUBLICA 6
SÍ NINGUNO NINGUNO
ENTIDAD PUBLICA 2
SÍ NINGUNO NINGUNO
ENTIDAD PUBLICA 5
NO NINGUNO SE ENTREGÓ FUNCIONALIDADES
ADICIONALES AL SISTEMA.
ENTIDAD PRIVADA 3
NO NO SE ENTREGÓ BIENES DE ACUERDO
A LOS CRITERIOS DE CALIDAD. NINGUNO
Tabla 4 Evaluación de proyectos según cumplimiento de alcance. Fuente: Elaboración propia.
Se observa que de un total de 17 proyectos desde el año 2012 al año 2016, solo el 47%
de ellos cumple con el alcance definido. El resto no cumplió por criterios de incumplimiento o
porque entregó más de lo esperado al cliente. En el listado de anexos se puede encontrar
24
evidencias de la ruptura del alcance para el segundo proyecto de la Entidad Pública 4.
Asimismo, se precisa que por cuestiones de confidencialidad de la información solo se muestra
lo relevante de las evidencias. Cabe mencionar que la ruptura del alcance tiene un impacto
directamente en el presupuesto del proyecto, pues causa que se asignen más recursos dentro
de una línea de tiempo.
La siguiente tabla muestra el cumplimiento del tiempo establecido por cada proyecto.
CLIENTE CUMPLIÓ CON
TIEMPO ESTABLECIDO
CRITERIO DE RETRASO CRITERIO DE ADELANTO
ENTIDAD PÚBLICA 1
SÍ NINGUNO NINGUNO
ENTIDAD PÚBLICA 2
NO DESFASE EN EL TIEMPO DE DESARROLLO DEL
SISTEMA NINGUNO
ENTIDAD PÚBLICA 3
NO DESFASE EN EL TIEMPO DE DESARROLLO DEL
SISTEMA NINGUNO
ENTIDAD PÚBLICA 4
NO INCUMPLIMIENTO DE ENTREGABLE NINGUNO
ENTIDAD PÚBLICA 5
SÍ NINGUNO NINGUNO
ENTIDAD PÚBLICA 7
SÍ NINGUNO NINGUNO
ENTIDAD PÚBLICA 4
SÍ NINGUNO NINGUNO
ENTIDAD PÚBLICA 3
SÍ NINGUNO NINGUNO
ENTIDAD PÚBLICA 1
NO DESFASE EN TIEMPO DE DESARROLLO DE SISTEMA. NINGUNO
ENTIDAD PÚBLICA 3
SÍ NINGUNO NINGUNO
ENTIDAD PÚBLICA 3
NO INCUMPLIMIENTO DE ENTREGABLE NINGUNO
ENTIDAD PRIVADA 1
NO DESFASE EN TIEMPO DE DESARROLLO DE SISTEMA.
DESFASE EN TIEMPO DE ADQUISICIÓN Y ENTREGA DE BIENES.
NINGUNO
ENTIDAD PRIVADA 2
NO DESFASE EN EL TIEMPO DE DESARROLLO DE SISTEMA
POR PARTE DEL CLIENTE. NINGUNO
ENTIDAD PÚBLICA 6
SÍ NINGUNO NINGUNO
ENTIDAD PÚBLICA 2
SÍ NINGUNO NINGUNO
ENTIDAD PÚBLICA 5
SÍ NINGUNO NINGUNO
ENTIDAD PRIVADA 3
SÍ NINGUNO NINGUNO
Tabla 5 Evaluación de proyectos según cumplimiento del tiempo.
Fuente: Elaboración propia.
De un total de 19 proyectos, solo el 58% cumplió con el tiempo establecido, el resto no
cumplió por criterios de retraso en el desarrollo de sistemas, adquisiciones y entrega de bienes.
En los anexos de la tesis se puede encontrar evidencia de que el cuarto proyecto de la Entidad
25
Pública 3 no cumplió con el tiempo establecido para los entregables derivados del mismo. Se
precisa que por cuestiones de confidencialidad de la información solo se muestra lo relevante
de las evidencias. Cabe mencionar que el incumplimiento en el tiempo tiene un valor
penalizable, el cual impactó directamente en el margen de utilidad de dicho proyecto.
En la siguiente tabla se presenta el cumplimiento del presupuesto establecido para cada
proyecto concluido hasta el año 2016.
CLIENTE CUMPLIÓ EL
PRESUPUESTO ESTABLECIDO
CRITERIO DE SOBRECOSTO DIFERENCIA DE
PRESUPUESTO AL CONCLUIR EL PROYECTO
ENTIDAD PÚBLICA 1
SÍ NINGUNO S/. 1,235.00
ENTIDAD PÚBLICA 2
NO INCUMPLIMIENTO DE ENTREGABLES A TIEMPO,
SOBRE ASIGNACIÓN DE RECURSOS. S/. -4,600.00
ENTIDAD PÚBLICA 3
NO INCUMPLIMIENTO DE ENTREGABLES SEGÚN CRITERIOS DEL PRODUCTO, MAYOR HORAS
HOMBRE POR DESARROLLO S/. -3,700.00
ENTIDAD PÚBLICA 4
SÍ NINGUNO S/. 2,200.00
ENTIDAD PÚBLICA 5
SÍ NINGUNO S/. 8,700.00
ENTIDAD PÚBLICA 7
SÍ NINGUNO S/. 2,300.00
ENTIDAD PÚBLICA 4
SÍ NINGUNO S/. 1200.00
ENTIDAD PÚBLICA 3
NO INCUMPLIMIENTO DE ENTREGABLES SEGÚN CRITERIOS DEL PRODUCTO, MAYOR HORAS
HOMBRE POR DESARROLLO S/. -13,050.00
ENTIDAD PÚBLICA 1
NO COMPRA ADICIONAL DE BIENES POR NO
REALIZAR PLANIFICAR DE ADQUISICIONES. $. -78,000.00
ENTIDAD PÚBLICA 3
SÍ NINGUNO S/. 1,450.00
ENTIDAD PÚBLICA 3
SÍ NINGUNO S/. 4,200.00
ENTIDAD PRIVADA 1
NO EN REFERENCIA A LOS CRITERIOS DE
INCUMPLIMIENTO, GOLD PLATING Y RETRASO S/. -45,520.00
ENTIDAD PRIVADA 2
NO EN REFERENCIA A LOS CRITERIOS DE
INCUMPLIMIENTO, GOLD PLATING Y RETRASO S/. -7,600.00
ENTIDAD PÚBLICA 6
SÍ NINGUNO S/. 540.00
ENTIDAD PÚBLICA 2
SÍ NINGUNO S/. 2,110.00
ENTIDAD PÚBLICA 5
SÍ NINGUNO S/. 4,320.00
ENTIDAD PRIVADA 3
SÍ NINGUNO S/. 3,500.00
Tabla 6 Evaluación de proyectos según cumplimiento de presupuesto. Fuente: Elaboración propia.
En la revisión del cumplimiento del presupuesto se observa que solo el 64% de los
proyectos ha cumplido con el presupuesto otorgado, el resto suma un sobrecosto acumulado
total de S/. 331,870.00. En el listado de anexos se puede evidenciar el incumplimiento al
26
presupuesto en el segundo proyecto de la Entidad Pública 1, en el que se realizó (en la etapa
de ejecución del proyecto) una compra adicional de bienes por no planificar las adquisiciones.
Esto impacto directamente en el costo presupuesto y en el margen de utilidad esperado.
Bajo un análisis más profundo se podría deducir el cumplimiento de las tres restricciones
básicas, en conjunto con la calidad y la administración considerando los factores ambientales
y los activos de la organización que serán determinantes para guiar el resultado deseado del
proyecto. Una gestión sin un método científico aplicando solo conceptos empíricos puede
conllevar a no lograr el éxito del proyecto. La planificación y definición correcta del alcance se
vuelve necesaria para tener una clara visión antes de empezar a ejecutar un proyecto. Un
cronograma planteado con una línea base podría verse impactado a consecuencia de cualquier
modificación en el alcance. Asimismo, el presupuesto podría variar por cambios en el alcance
y en el cronograma. Un cambio en el alcance del proyecto responde a una necesidad no
identificada al inicio, puede resultar en un riesgo que derive en una incertidumbre con impacto
positivo o negativo.
En base a lo descrito, se puede asegurar que la triple restricción de alcance, tiempo y
costo se ve relacionada entre sí a lo largo del ciclo de vida del proyecto, es por ello que el
incumplimiento en cualquiera de ellas puede afectar el proyecto. Para una mejor comprensión
de las principales causas que afectan los proyectos se presenta un gráfico basado en el análisis
causa-efecto. El diagrama plantea a la triple restricción como los principales atributos, siendo
estos susceptibles a posibles causas perjudiciales para la gestión de los proyectos.
Aparte de los atributos ya nombrados, se tiene a los factores ambientales de la
organización que incluyen los canales de comunicación, estructura de la organización, sistemas
usados, y los activos de proceso de la organización incluyendo los procesos, procedimientos y
políticas a seguir. Estos atributos pueden afectar directamente los intereses del proyecto si no
son considerados desde un inicio.
A continuación, se muestra una representación del análisis causa – efecto aplicado a
los proyectos. “El diagrama Ishikawa, tiene como principal objetivo la solución de las causas
raíces de los problemas existentes.” (James, 1997). En él se identifica las causas que podrían
afectar los proyectos. Por último y en base a lo descrito se define la identificación del problema
como la carencia de un método para la gestión de proyectos en la empresa consultora.
27
Figura 2 Análisis causa-efecto aplicado a proyectos.
Fuente: Elaboración propia basada en el diagrama de Ishikawa.
28
Para reforzar el análisis realizado, podemos revisar la publicación de (Díaz Piravique &
Gonzales Crespo, 2015) “Motivos de fracaso en los proyectos de Tecnologías de Información
y Comunicaciones”, en donde presentan los sobrecostos de los proyectos analizan los factores
que causaron el fracaso de proyectos bajo la modalidad de ejecución propia y la
subcontratación. En una tabla mostrada sobre este análisis podemos rescatar lo siguiente.
La fecha de entrega impactó el proceso de ejecución en el 93.9% en los proyectos de ejecución
propia y 90.5% en los proyectos de ejecución subcontratada.
Los cambios en el alcance durante la ejecución del proyecto impacto el proceso de ejecución
en el 67.3% en los proyectos de ejecución propia y 57.1% en los proyectos de ejecución
subcontratada.
Asimismo, (The Standish Group International, 2013) presenta resultados de cifras obtenidas
por sobrecosto en los proyectos en su estudio realizado en la publicación “CHAOS Manifesto
2013: Think Big, Act Small”, en el cual se detalla sobrecostos asociados a una mala gestión en
costos o presupuestos en un 74% (en el año 2012), mala gestión del tiempo en un 59% (en el
año 2012), y mala gestión del alcance en un 69% (en el año 2012).
29
FORMULACION DEL PROBLEMA
Problema general
¿Qué mejora se obtendrá en la gestión de proyectos aplicando la guía PMBOK, el método
PRINCE2 y el método SCRUM?
Problemas específicos
¿Cuál es el impacto en el cumplimiento de los objetivos en los proyectos aplicando la guía
PMBOK, el método PRINCE2 y el método SCRUM?
¿Cuál es el impacto en el cumplimiento del alcance de los proyectos aplicando la guía PMBOK,
el método PRINCE2 y el método SCRUM?
¿Cuál es el impacto en el margen de utilidad obtenido una vez culminado los proyectos
aplicando la guía PMBOK, el método PRINCE2 y el método SCRUM?
¿Cuál es el impacto en la satisfacción del cliente una vez entregados los proyectos aplicando
la guía PMBOK, el método PRINCE2 y el método SCRUM?
30
MARCO REFERENCIAL
Hoy en día podemos encontrar guías y métodos para gestionar toda clase de proyectos,
capaces de ser usadas individual o colectivamente. Así como también experiencia que sirve de
antecedentes para este trabajo.
Antecedentes internacionales
Un primer trabajo correspondiente a (Suárez, 2010), de la escuela técnica superior de ingeniería
informática de la Universidad de Málaga en España, quién en su proyecto: “Estudio de la
metodología de Gestión de Proyectos PRINCE2: Aplicación a un caso práctico”, realizó un
análisis y comparación de la método estructurado que propone el PRINCE2 frente a otras
formas y métodos de gestionar proyectos como el Métrica V3, el PMBOK, Scrum y DSDM
ATERN. El objetivo fue determinar en qué aspectos se diferencian las guías y métodos con la
metodología PRINCE2. Llegando a la conclusión de poder usar las actividades y complementos
del método PRINCE2 para complementarse con otras formas y métodos de gestión de proyecto
como el PMBOK.
Un segundo trabajo correspondiente a (Lema & Oña, 2016), de la Universidad Técnica
de Cotopaxi en Ecuador, quiénes en su trabajo “Implementación de un sistema de
comercialización, mediante dispositivos móviles aplicando la metodología Scrum, en la
empresa imagen distribuidora de NEC en Ecuador durante el periodo 2014-2015” aplicaron el
método Scrum para el desarrollo de software para obtener productos de calidad que satisfagan
los requerimiento del cliente. Al final se concluye que los proyectos bajo el método implantando
cumple con los objetivos propuestos. Se reduce tiempos de respuesta y se incrementa la
satisfacción del cliente.
Un tercer trabajo corresponde a (Merlo Vega & Ramón Borja, 2016) de la Universidad
Técnica Cotopaxi en Ecuador, quiénes en su trabajo “Implementación de una solución para el
manejo de ciclo de vida de aplicaciones (ALM), utilizando metodología Scrum y TFS como core
central de la solución, para la optimización del proceso de desarrollo de software, en la empresa
grupo Babel del Ecuador en la ciudad de Lataguna en el periodo Agosto – Diciembre 2015”
realizan la implementación de la gestión del ciclo de vida con la ayuda de la herramienta Team
Foundation Server, aplicando la metodología de Scrum para llevar a cabo sus actividades.
31
Concluyendo que se logra el trabajo por la instalación y configuración según método Scrum y
recomendaciones del Team Foundation Server.
Un cuarto trabajo corresponde a (De Jesús De la Hoz Gonzáles & Méndez Chávez,
2016) del Instituto Universitario Politécnico Grancolombiano en Colombia, quiénes en su trabajo
“Método Scrum aplicado al sistema de gestión de seguridad de la información” donde aplican
el método Scrum para garantizar la forma ágil de implementar el esquema de seguridad en la
empresa. Se logra implementar nuevos procesos de manera ágil gracias al método Scrum,
además de manejar y controlar la confidencialidad, disponibilidad e integridad para la seguridad
de la información.
Antecedentes nacionales
En el ámbito nacional, también podemos revisar cuantiosos trabajos sobre aplicación de
metodologías como Scrum y guías como el PMBOK.
Un primer trabajo corresponde a (Soto Vicente, 2015) de la “Universidad Nacional Mayor
de San Marcos” en su trabajo “Aplicación de la guía del PMBOK en el desarrollo de nuevos
productos farmacéuticos en un área de investigación y desarrollo”. En su investigación aplica
las plantillas de todos los procesos que sugiere usar la guía del PMBOK 4ta edición para la
obtención de un jarabe de hierro polimaltosado. Asimismo, muestra una comparativa entre los
resultados obtenidos por el uso de los grupos de procesos frente a los resultados del método
antiguo usado para la obtención del jarabe. Demostrando que el uso de la guía del PMBOK
contribuye a cumplir con los objetivos del proyecto. Concluye que el PMBOK es útil para la
gestión en el desarrollo de productos en la industria farmacéutica definiendo correctamente el
alcance y controlando la ejecución del proyecto.
La aplicación al sector construcción puede revisarse en el trabajo de (Mañuico Mendoza,
2015) “Modelo de gestión de control de costos, en la industria de la construcción, bajo el
enfoque PMI - PMBOK; caso presa de relave, consorcio Stracon GyM-Montaengil, minera
Chinalco,Perú”, quién implementa el modelo de gestión de costos recomendado por el PMI,
utilizando los procesos incluidos en el área de conocimiento de la gestión de costos, usando
herramientas como el modelo de valor ganado y su indicadores. Concluyendo que se obtiene
una mejora en los indicadores de desempeño por la gestión del costo.
32
La aplicación del método Scrum para mejorar los indicadores de gestión en ventas de
una compañía nacional se puede revisar en el trabajo de (Terukina, 2016) “Sistema de gestión
de fuerza de ventas web y móvil, utilizando el estilo arquitectónico Rest, metodología Scrum y
la geolocalización”, realiza aplicativo móvil basándose en el método ágil Scrum, el aplicativo
móvil consulta a un servicio web con capacidad de geolocalizar a los vendedores en campo.
Brinda información relevante a gerencia, y a partir del sistema de supervisión y gestión de
ventas web y móvil se puede mejorar los indicadores de productividad y minimizar los tiempos
muertos de los vendedores.
Una aplicación del método al sector construcción se puede revisar en el trabajo de
(Delgado, 2012) de la facultad de ingeniería civil en la “Universidad Nacional de Ingeniería en
Perú”, titulado “Metodología práctica para la gestión y administración en proyectos de
construcción para micro y pequeñas empresas”. El autor propone un método para llevar a cabo
los proyectos de construcción a través de un plan de gestión de proyectos. En el plan que
propone se detallan tres procesos claves de inicio y planificación, además del desarrollo de
ocho planes subsidiarios para la ejecución de proyectos utilizando herramientas que propone
el PMBOK para la gestión. Finalmente concluye su investigación argumentando que con la
aplicación de la metodología planteada se llegó a cumplir los objetivos requeridos en el
proyecto, además de guardar y usar para próximos proyectos las lecciones aprendidas tomadas
en todo el ciclo de vida del proyecto.
Para un aplicación práctica a implementación de otros procesos, estándares o
programas se puede revisar la tesis de (Ticona Daza, 2012) de la facultad de ingeniería
ambiental en la “Universidad Nacional de Ingeniería en Perú”, titulada “Aplicación de las buenas
prácticas en gestión de proyectos(Estándar PMI) para la implementación de un programa de
seguridad y salud ocupacional OHSAS 18001:2007 en el proyecto: Mejoramiento de los
sistemas de agua potable y alcantarillado – lote 3A – Piura – Castilla”. Se relacionan los
procesos sugeridos en el PMBOK con las políticas de las OHSAS, de esta forma refuerza el
cumplimiento de la norma para su implementación a lo largo del ciclo de vida. Se concluye que
el uso del estándar contribuye a atender la necesidad estratégica de la implementación del
programa de SST mejorando los índices de cumpliendo del cronograma y presupuesto.
Por último se puede revisar la aplicación al sector minero en la tesis de (Vivanco
Huaytara, 2015) de la facultad de ingeniería geológica, minera y metalúrgica en la “Universidad
33
Nacional de Ingeniería en Perú”, titulada “Aplicación de las buenas prácticas del PMBOK a la
iniciación, planificación, ejecución, monitoreo, y cierre del proyecto caminos mineros en las
Bambas”. En el trabajo usa los procesos de la guía del PMBOK para llevar a cabo el proyecto
de abrir los caminos mineros en el cruce del río (tramo 1), con el objetivo de reducir el tiempo
de acarreo desde el depósito de materias primas hacia la ubicación de la presa de relaves. La
tesis propone el desarrollo del acta de constitución de proyecto como proceso clave de inicio.
A partir de esta salida, sigue el desarrollo del proyecto mediante la gestión de áreas sugeridas
en la tesis y obedeciendo al proceso de seguimiento y control. Concluyendo que aplicando
gestión de proyectos pueden controlar sus costos y tiempos de entrega.
Estado del arte
Actualmente los proyectos en el mundo globalizado optan por usar cuerpos de conocimiento,
métodos, sistemas integrados, herramientas y técnicas ejecutadas por el capital humano para
mejorar sus procesos y ser más efectivos en sus operaciones, generando rentabilidad y
sostenibilidad a través del tiempo.
Dentro del conjunto de sistemas integrados se encuentra el “Sistema de gestión de
calidad donde define a la calidad como el grado en el que un conjunto de características
inherentes cumple con los requisitos” según (ISO, 2005). El estado del arte de la ISO 9001 se
presenta en la última actualización a la norma que fue publicada en el año 2015, la cual incluye
a diferencia de su versión antecedente, el enfoque en la gestión de los riesgos para los sistemas
de gestión de calidad, además de dar énfasis en la mejora continua de procesos. Septiembre
de 2018 culmina el plazo de transición para adoptar la implementación y certificación de esta
norma en las organizaciones que deseen ser nombradas por este estándar de calidad a nivel
mundial.
En la primera parte del trabajo de (Tembleque Montero, 2016) titulado “Proyecto de
Implantación de un Sistema de Gestión de la Calidad ISO 9001:2015 en la Empresa Pinatar
Arena Football Center S.L.” se puede revisar el marco teórico que describe los conceptos de
calidad, costos y el sistema de gestión de la norma. En el cual precisa los cambios para la
nueva estructura de alto nivel de la norma, la cuál está conformada por el alcance, las
referencias normativas, los términos y condiciones, el contexto de la organización, el liderazgo,
la planificación, el soporte, las operaciones, la evaluación de desempeño y la mejora.
34
En la segunda parte del trabajo se explica el proyecto de implementación describiendo
la metodología a usar para generar los manuales de procesos, los procedimientos
documentados de gestión de auditorías, el registro de calidad del plan de auditorías, la
elaboración del plan de objetivos y metas, la elaboración de la instrucción técnica dentro del
campo de aplicación del trabajo.
Cabe mencionar que la norma actual tiene un enfoque orientado a los riesgos y
mantiene el enfoque de la mejora continua, siguiendo el método de aplicación del ciclo de
William Edwards Deming. Por lo que el “PDCA” se divide en la estructura de la siguiente forma.
Se planea para el contexto de la organización, el liderazgo y la planificación. Se ejecuta para el
soporte y las operaciones. Se verifica en la evaluación de desempeño. Se actúa sobre los
planes de mejora. Es así como se cumple el ciclo de mejora continua.
El ciclo se inicia identificando y priorizando los problemas existentes, en esta etapa se
analizan las posibles causas y se planifica acciones para corregir los problemas. Lo planificado
se implementa ejecutando acciones de mejora y registrando cada salida del proceso. Se verifica
los resultados a través de la medición y comparación con los objetivos planteados en un inicio,
se retroalimenta sobre las acciones realizadas y se analiza las causas que derivaron en
desviaciones del proceso. Por último, se define las acciones para eliminar las desviaciones y
sus casusas. Asimismo, se actualiza y formaliza el plan, con el plan modificado se culmina un
ciclo para dar inicio a un nuevo nivel de mejora continua.
Un ejemplo claro de la aplicación del ciclo de Deming se tiene en el postulado de (Prieto
Delgado & Piattini Velthuis, 2015), denominado “Propuesta de marco de mejora continua de
gobierno TI en entidades financieras”, en el que se plantea alinear el gobierno de las
Tecnologías de la Información en negocios de entidades financieras. El trabajo plantea planear
las mejoras de iniciativa de gobierno TI, implementar las iniciativas de mejora, verificar, mediar
y comprobar la efectividad del proceso desde una perspectiva global y redefinir acciones de
mejora integral.
El ciclo de mejora continua viene siendo usado hoy en día por múltiples instituciones y
sistemas integrados, mostrando resultados favorables. Sin embargo, el éxito dependerá de la
adopción de una cultura de calidad basada en la mejora continua. Siendo necesario el
compromiso de las distintas áreas participantes de las organizaciones.
35
Otras de las herramientas más usadas para la mejora de procesos bajo análisis de
causas observables es el “Diagrama de Ishikawa o Diagrama de causa-efecto”, propuesto por
el japonés Kaoru Ishikawa en 1943. En su modelo se presenta el problema central en la cabeza
del diagrama en forma de pez, y se lista las causas como las espinas de los ejes principales.
Cabe mencionar que la naturaleza del diagrama analiza las causas desde el enfoque del
hombre, máquina, entorno, material, método y medida. Sin embargo, los enfoques pueden ser
ajustados según las posibles causas generales presentadas en cada problema.
Un claro ejemplo que podemos revisar es el trabajo de (Escaida Villalobos, Jara Valdés,
& Letzkus Palavecino, 2016) “Mejora de procesos productivos mediante Lean Manufacturing”,
en el que aplican el módelo Lean Manufacturing para mejorar la producción de una empresa de
colchones. Dentro del modelo usan el Diagrama de Ishikawa para poder identificar las causas
raíces del excesivo transporte de materias para la producción de colchones, dividiendo las
categorías en: Maquinaria, planta, materia prima, método de trabajo. El diagnóstico luego de
usar la herramienta fue que había un problema con el alto porcentaje de productos
semielaborados defectuosos por taller. El mismo proceso se usó para el problema de los
desperdicios en el tiempo y desperdicios en los inventarios. A partir del análisis realizado se
siguió con la propuesta de mejora, planteando una reingeniería en el proceso a través de la
representación en un nuevo Diagrama de Flujo de Valor.
Para mapear y diagramar los procesos se puede hacer uso de distintos diagramas de
flujo de procesos, diagramas de operaciones de procesos, diagramas de actividades de
procesos, diagramas de recorrido de procesos. Para diagramar procesos de negocio y servicios
se puede usar el estándar del “Business Process Modeler Notation (BPMN)”. Un caso de
ejemplo lo tenemos en el postulado de (Flores-Rios, J. Pino, Ibarra-Esquer, Gonzáles-Navarro,
& Rodríguez-Elías, 2014) “Análisis de Flujos de Conocimiento en Proyectos de Mejora de
Procesos Software bajo una perspectiva multi-enfoque” en el cuál usan una metodología para
el análisis del flujo del conocimiento en los proyectos de mejora de software, apoyados del
modelamiento de datos a través de diagramas de flujo de procesos.
Para el seguimiento y control de proyectos, hoy en día se usan múltiples softwares de
control de proyectos como herramientas que faciliten el monitoreo y la toma de decisiones en
la etapa de ejecución de los proyectos. (Suárez Medina, 2013) en su trabajo “Uso de software
36
para la gestión de proyectos hidráulicos” realiza un breve repaso sobre las herramientas
informáticas usadas para el seguimiento y control de los proyectos. Los softwares revisados en
su investigación son: Ganttic (software libre de programación en línea), OpenProj (software de
administración de proyectos sustituto del MS Project), GanttProject (software libre de gestión
de proyectos), Planner (software licenciado escrito en lenguaje C), PHPProjekt (software
licenciado escrito en lenguaje PHP), MS Project 2010 (software licenciado por Microsoft). Aplica
una metodología que se basa en la comparación funciones que cumple cada software para
elegir uno de ellos y usarlo para los proyectos hidráulicos. Luego del análisis comparativo opta
por elegir el MS Project 2010 y usarlo como complemento para el seguimiento y control de
proyecto según el enfoque del PMI.
El “Diagrama de Gantt”, en honor a su inventor Henry Gantt en los inicios de la época
moderna de la gestión de proyecto. Sirven hasta el día de hoy para listar, secuenciar y
establecer plazos para el desarrollo de actividades en tiempos establecidos. El uso del
diagrama de Gantt, se fortalece con la funcionalidad de los diagramas “Program Evaluation and
Review Technique(PERT) y Critical Path Method(CPM)”. El diagrama PERT implementado por
la marina de los Estados Unidos sirve para integrar los recursos, plazos y secuencias de los
proyectos. El diagrama CPM sirve para calcular las holguras del proyecto y definir la ruta crítica
de lo planificado. En el trabajo de (Meireles Moreira, Soares da Silva, & Molina Palma, 2010),
“Análise de gerenciamento de tempo aplicado a um projeto de petróleo” se explica la gestión
del tiempo con los conceptos usados por el PMI. En la gestión explican la definición, el
secuenciamiento, el seguimiento y control de las actividades del cronograma a través del uso
del software Microsoft Office Project.
La aplicación de la regla de Pareto o más conocido 80-20 sigue siendo de gran utilidad
para determinar en qué porcentaje acumulado se encuentra el objetivo común a analizar. Una
vez determinado el 20% muy vital se puede aplicar estrategias de clasificación ABC para una
mejora de procesos. Podemos revisar su aplicación en proyectos en el trabajo de
(Shuangshuang Nie, 2015) “Discrete time-cost tradeoff model for optimizing multi-mode
construction project resource allocation”, quién propone un modelo integre el problema de la
nivelación de recursos y el problema de compensación de tiempo-costo con recursos limitados.
Para ello aplica el algoritmo SPEA II sobre la regla de Pareto para optimizar el costo y tiempo
de los recursos asignados a los proyectos.
37
La técnica de gestión de riesgos para evaluarlos, armar una estructura de desglose de
riesgos y representarlos en una matriz es muy usada para tratar los riesgos en los proyectos.
Sugiere identificar los riesgos primarios, separarlos por categoría de riesgos, evaluar su
probabilidad de ocurrencia e impacto y generar planes de respuesta a los riesgos. Como
ejemplo claro se puede revisar el trabajo de (Ayala Cruz, 2016) “Planificación de riesgos en
proyectos para el desarrollo de nuevos productos de alta tecnología”, quién aplica los conceptos
de PMBOK para identificar los riesgos, categorizarlos, realizar un análisis de sensibilidad
usando la simulación Montecarlo y tratarlos según su probabilidad de ocurrencia y el nivel de
impacto que podrían tener. Los resultados fueron 32 riesgos identificados, donde se clasificó al
40% de ellos como riesgos de baja probabilidad de ocurrencia y baja probabilidad de impacto.
Marco teórico
Proyectos.
“Los humanos han estado trabajando en proyectos desde la antigua historia” es lo que comenta
(Seymour & Hussein, 2014, pág. 1). También se ha alcanzado el desarrollo personal, social,
cultural, político, económico a través de cumplimiento de objetivos que partieron de una idea
inicial esperando por resultados que muestren avances significativos a través del tiempo. Hoy
en día toda organización sobrevive sobre dos pilares básicos representado por la sostenibilidad
en sus operaciones y sobre el éxito de proyectos que añadan valor y den como resultado un
producto, un servicio, una solución o una mejora que se vea reflejada como innovación.
Los proyectos se vuelven necesarios para dar ese salto de valor y se caracterizan por
ser de naturaleza finita y única. Todo proyecto tiene un inicio partiendo de alguna idea y fin por
aceptar el resultado alcanzado por el desarrollo de esa idea o en su defecto concluyendo el
proyecto por alguna razón. Cada proyecto es único y diferente de cualquier otro que lo anteceda
o preceda, pues no contará con la misma cantidad de recursos, ni con el mismo tiempo u
objetivos.
Las asociaciones y expertos involucrados con la gestión de proyectos coinciden en
definir al proyecto como un esfuerzo temporal que satisface alguna necesidad dando como
resultado un producto, servicio, mejora de proceso, solución ya sea de tipo social, económico,
político o entre otras muchas. La dirección de proyectos contempla utilizar conocimientos,
técnicas y habilidades para planificar, dirigir y controlar recursos esperando cumplir con los
38
requisitos del proyecto.
Actualmente existe una gran variedad de guías y métodos para apoyar la gestión de
proyectos, desde los más tradicionales hasta los métodos ágiles muy usados hoy en día. Es
así que en la publicación de (Macek, 2010) “Methodologies of Project Management” se revisan
los estándares de gestión de proyectos más populares, haciendo una comparación de las
regulaciones generales, la gestión del rango del proyecto, la administración de recursos, los
procesos relacionados al riesgo y los sistemas de gestión de calidad en el PMBOK, PRINCE2,
CMMI, ISO 10006 (directrices para la gestión de calidad en proyectos), BS6079, IPMA. Del cual
se concluye que muchas veces un sólo modelo o método no es suficiente para gestionar un
proyecto dentro de un contexto único.
De los cuerpos tradicionales mencionados, para el trabajo de investigación se ha
tomado la guía del PMBOK 5ta Edición por la completa y variada cantidad de procesos que
ofrece. Además, también se toma el método PRINCE2 por su estructura flexible y por el enfoque
orientado a asegurar que la gestión de los proyectos siempre responda a un caso de negocio.
En contra parte al uso de los modelos tradicionales, tenemos los métodos ágiles, muy
usados en los proyectos de Tecnología de la Información y Comunicación. Estos métodos se
caracterizan por ser flexibles, se usan principalmente para asegurar la entrega efectiva de los
productos y atender los cambios de requerimientos del producto a lo largo del tiempo de vida
del proyecto. (Jiménez, 2014, pág. 2) en su publicación “Aplicación de Metodologías Ágiles en
el Diseño de UX” describe que el objetivo de un método ágil es “mejorar el valor del entregable
del producto para satisfacer los requisitos del cliente.”
Dentro del grupo de los métodos más representativos podemos encontrar a XP, Kanban,
Lean, SCRUM. A continuación, se realizará un breve reconteo de lo que implica cada método.
El método XP o “Extreme Programming” muy usado para el desarrollo de software es
descrito por (Beck, 2000) como “una metodología ligera para pequeños y medianos equipos de
desarrollo de software para requerimientos imprecisos o rápidamente cambiantes”. Para esta
investigación sólo se tomarán las experiencias del uso de este método, dado a que es poco
frecuente que se aplique a proyectos de implementación que no sean de desarrollo.
39
Por otro lado, Kanban es un método muy usado hoy en día en distintos entornos de
trabajo, el método también puede ser definido como la herramienta de tablero Kanban, la cual
permite controlar las actividades de una organización. Este método sugiere dividir las tareas y
clasificarlas en tareas pendientes, tareas en procesos, tareas terminadas, esto con el objetivo
de controlar el flujo de la operación, lograr entregables a tiempo y evitar cuellos de botellas.
Para esta investigación, del método japonés sólo se tomará al tablero Kanban como
herramienta para ayudar a controlar las actividades del proyecto.
El método Lean también es usado en distintos entornos, (Escuder, Tanco, & Santoro,
2015, pág. 2) en su investigación titulada “Experiencia de Implementación de Lean en un Centro
de Salud de Uruguay” manifiestan que “Lean no es una metodología que tiene como objetivo
resolver grandes problemas, sino que trata de resolver cientos de pequeños problemas que
dificultan el buen funcionamiento de la organización”. Lean no se encuentra parametrizada y
engloba muchas herramientas, en la presente investigación se tomarán solo las experiencias y
herramientas de este método.
Por último, tenemos el método SCRUM el cual ha sido tomado para la investigación.
SCRUM ha diferencia de los demás ofrece un marco más definido en el cual se definen roles
para los participantes de los proyectos, asegurando la entrega de los productos en cada
ejecución de trabajo dentro un tiempo de ciclo establecido por el equipo. Según la (Comunidad
profesional SCRUM Manager , 2016, pág. 12) “Scrum es un modelo de desarrollo ágil
caracterizado por adoptar una estrategia de desarrollo incremental, en lugar de la planificación
y ejecución completa del producto”
Gestión de proyectos con PMBOK 5ta Edición.
El estándar del PMBOK en su quinta edición publicado por el “Project Management Institute
(PMI)” en el año 2013 y aceptada a nivel mundial por personas y empresas involucradas en la
gestión de proyectos se enfoca en el uso de procesos tomando la estructura, los factores
ambientales y los activos de proceso de la organización. Asimismo, la guía del PMBOK
reconoce a las organizaciones según su característica en el manejo de proyectos y su ciclo de
vida. El PMBOK propone la gestión desde dos frentes: Diez áreas de conocimiento y cuarenta
y siete procesos agrupados en cinco grandes grupos de procesos. La guía detalla las entradas,
herramientas, técnicas y salidas de cada proceso. A continuación, se explica las restricciones,
el ciclo de vida, las partes integrantes, los procesos recomendados y las áreas de conocimiento.
40
Figura 3 Restricciones en gestión de proyectos según PMBOK. Fuente: Elaboración propia basada en la guía PMBOK 5ta edición.
El PMBOK sugiere que la dirección de proyectos siempre se va ver afectada por las
restricciones en el alcance, el tiempo, el costo, la calidad, los recursos, los riesgos y satisfacción
y la participación de los interesados. La gestión junto con la toma de decisiones debe considerar
estas restricciones a lo largo del ciclo de vida del proyecto.
Por otro lado, el PMBOK define que todo proyecto se divide en cuatro fases dentro de
su ciclo de vida. El siguiente gráfico representa la relación duración-costo de cada fase.
DIRECCION DEL
PROYECTO
ALCANCE
COSTO
TIEMPO
CALIDADSATISFACCION DEL CLIENTE
RECURSOS
CALIDAD
41
Figura 4 Ciclo de vida del proyecto según PMBOK. FUENTE: Guía PMBOK Quinta edición (Project Management Institute, 2013, pág. 39).
El ciclo de vida del proyecto inicia con la identificación una necesidad entregando al final
de su etapa el acta de constitución del proyecto. La siguiente etapa se conoce como la
organización y preparación en la cual se planifica y reúne todo lo necesario para iniciar con la
ejecución del trabajo. Al concluir con las actividades y alcanzar los entregables se pasa a la
etapa del cierre del proyecto. El PMBOK explica que durante las etapas del ciclo de vida se
presentan iteraciones entre los procesos usados para la gestión del proyecto.
La gobernabilidad y las partes integrantes del proyecto nos describen la forma en cómo
se gobierna el proyecto. A continuación, se explica brevemente cada una de las partes
integrantes del proyecto.
Patrocinador del proyecto: Es la persona o entidad que inicia el proyecto, encargándose
de reunir los primeros supuestos, las restricciones y de establecer los hitos del proyecto. Sirve
como guía de escalamiento para los temas que escapen del alcance del director de proyectos.
PMO: De las siglas Project Management Office, se presenta como un órgano interno de
la organización que puede cumplir rol de supervisar, controlar o tomar decisiones según lo
requiera el proyecto. Contiene la base de conocimiento y las actualizaciones en la metodología
aplicada para la dirección de proyectos.
42
Director de proyecto: Es la persona encargada de dirigir las actividades para alcanzar
los objetivos que requiere el proyecto.
Representante del usuario: Miembros internos de la organización que se encargan de
representar a los clientes finales para la aprobación de entregables.
Expertos de apoyo: Miembros internos de la organización, quiénes ejecutan actividades
clave de logística, finanzas, legal, recursos humanos, ingeniería.
Vendedores: El PMBOK los describe como contratista o terceros que brindan servicios
a la organización con el fin de alcanzar entregables.
Socios de negocio: Son organizaciones externas que guardan relación con la empresa,
viéndose interesada en los proyectos y proporcionando experiencia en campos especializados.
Personal del proyecto: Colaboradores que se encargaran de asegurar la obtención de
los entregables.
La composición del equipo del proyecto depende del tipo de proyecto, del tipo de
estructura de la organización y de la necesidad del proyecto. Como ejemplo podemos tener un
proyecto de desarrollo de una app, que necesitará que el director de proyecto solicite los
recursos formalmente a los gerentes funcionales, requiriendo la participación de cada miembro
por el plazo de tres meses, en los cuáles su avance será revisado en una plataforma virtual
pasado los 30 días. Se puede describir a este ejemplo como un proyecto virtual, de tiempo
parcial, de una estructura funcional que requiere la revisión del avance del proyecto al término
de cada mes.
Para dividir el trabajo a realizar durante todo el ciclo de vida del proyecto, el PMBOK
propone dividirlos en cinco grandes grupos de procesos. A continuación, se presenta y explica
cada grupo de procesos.
43
Figura 5 Red lógica de relación grupo de procesos según PMBOK. Fuente: Elaboración propia basada en la guía PMBOK 5ta edición.
El grupo de inicio se inicia partiendo de un caso de negocio por parte del patrocinador
del proyecto. Su creación formal se alcanza al realizar y aprobar el acta de constitución por los
interesados del proyecto. El acta de constitución se refiere a un documento con requisitos,
supuestos, plazos y alcance de alto nivel en un inicio. Dentro de este grupo, se identifica y
clasifica a los interesados del proyecto en base a niveles de influencia, interés y poder de cada
interesado. Este grupo de procesos consta de dos procesos.
Dentro del grupo de planificación se encuentra la mayor parte del trabajo, ya que
partiendo de la planificación de que es lo que se va hacer, cuánto tiempo va tomar, cuánto va
costar, se define y programa las actividades a realizar. Este grupo de proceso incluye entradas
definidas en el grupo de inicio, principalmente se toma como referencia al acta de constitución
del proyecto y los requisitos de alto nivel. Este grupo de proceso da como resultado un plan
integral de dirección de proyectos, donde se detalla el qué, cómo, cuándo, por quién se actuará
para incidir en los entregables. Cabe mencionar que la guía sugiere la creación de 11 planes
subsidiarios junto con otros planes de utilidad. Este grupo de procesos consta de veinticuatro
procesos.
Dentro del grupo de ejecución se encuentran los procesos para dirigir y gestionar los
proyectos para lograr alcanzar los entregables, obteniendo a la vez datos de desempeño del
trabajo, así como solicitudes de cambio. La ejecución se ve guiada por la planificación realizada
INICIO (2)
PLANIFICACION(24)
EJECUCION(8)SEGUIMIENTO Y
CONTROL(11)
CIERRE(2)
44
en el grupo de proceso de planificación. Este grupo de procesos consta de 8 procesos.
En el grupo de seguimiento y control del proyecto lleva a cabo de técnicas para poder
pronosticar los resultados hacia el futuro basados en datos históricos en la ejecución del
proyecto. Como bien se mencionó el monitoreo o seguimiento y control influye en una posible
nueva planificación según el estado actual del proyecto. Este grupo de procesos consta de once
procesos.
El grupo de cierre incluye las actividades para finalizar todos los procesos de dirección
del proyecto. El cierre debe realizarse de manera formal del proyecto o fase del mismo. El cierre
da como resultado la transferencia del producto o servicio creado por el proyecto, genera
lecciones aprendidas y actualiza los activos de proceso de la organización. Este grupo de
procesos consta de dos procesos.
El segundo frente que encontramos en el cuerpo de conocimiento del PMBOK son las
áreas de conocimiento que agrupan de conceptos, términos y actividades de cada campo
especializado para la dirección de proyectos.
45
Tabla 7 Áreas de conocimiento según PMBOK 5ta edición. Fuente: Elaboración propia basada en la guía PMBOK 5ta edición.
Cada área entrega un plan subsidiario que contribuye al plan de dirección del proyecto.
El área de integración reúne lo necesario para lograr la cohesión entre las demás áreas
de conocimiento. El área de alcance se encarga de definir y gestionar lo incluirá el proyecto. El
área de tiempo se encarga de asegurar la planificación y estimación del cronograma. El área
de costo se encarga de asegurar la planificación y estimación del presupuesto. El área de
calidad se encarga de asegurar y controlar la calidad del producto. El área de RR. HH es la
encargada de definir los roles y responsabilidad del proyecto. El área de comunicaciones se
encarga de gestionar la comunicación entre interesados y partes integrantes del proyecto. El
área de riesgos se encarga de identificar, clasificar, plantear planes de respuesta. El área de
adquisiciones se encarga de planificar toda compra y/o contratación de servicios. Por último, el
área de interesados se encarga de gestionar la relación con los interesados del proyecto. Para
una mejor comprensión entre procesos y área de conocimiento se muestra la siguiente tabla.
46
GRUPOS DE PROCESO
PROCESO AREA DE
CONOCIMIENTO
INICIO DESARROLLAR EL ACTA DE CONSTITUCION DEL PROYECTO 1
IDENTIFICAR A LOS INTERESADOS 10
PLANIFICACION
DESARROLLAR EL PLAN PARA LA DIRECCION DEL PROYECTO 1
PLANIFICAR LA GESTION DEL ALCANCE 2
RECOPILAR REQUISITOS 2
DEFINIR EL ALCANCE 2
CREAR LA EDT/WBS 2
PLANIFICAR LA GESTION DEL CRONOGRAMA 3
DEFINIR LAS ACTIVIDADES 3
SECUENCIAR LAS ACTIVIDADES 3
ESTIMAR RECURSOS PARA LAS ACTIVIDADES 3
ESTIMAR LA DURACION DE LAS ACTIVIDADES 3
DESARROLLAR EL CRONOGRAMA 3
PLANIFICAR LA GESTION DE COSTOS 4
ESTIMAR LOS COSTOS 4
DETERMINAR EL PRESUPUESTO 4
PLANIFICAR LA GESTION DE LA CALIDAD 5
PLANIFICAR LA GESTION DE LOS RR.HH 6
PLANIFICAR LA GESTION DE LAS COMUNICACIONES 7
PLANIFICAR LA GESTION DE LOS RIESGOS 8
IDENTIFICAR LOS RIESGOS 8
REALIZAR EL ANALISIS CUALITATIVO DE LOS RIESGOS 8
REALIZAR EL ANALISIS CUANTITATIVO DE LOS RIESGOS 8
PLANIFICAR LA RESPUESTA PARA LOS RIESGOS 8
PLANIFICAR LA GESTION DE LA ADQUISICIONES 9
PLANIFICAR LA GESTION DE LOS INTERESADOS 10
EJECUCION
DIRIGIR Y GESTIONAR EL TRABAJO 1
REALIZAR EL ASEGURAMIENTO DE LA CALIDAD 5
ADQUIRIR EL EQUIPO DEL PROYECTO 6
DESARROLLAR EL EQUIPO DEL PROYECTO 6
DIRIGIR EL EQUIPO DEL PROYECTO 6
GESTIONAR LAS COMUNICACIONES 7
EFECTUAR LAS ADQUISICIONES 9
GESTIONAR LA PARTICIPACION DE LOS INTERESADOS 10
MONITOREO Y CONTROL
MONITOREAR Y CONTROLAR EL TRABAJO DEL PROYECTO 1
REALIZAR EL CONTROL INTEGRADO DE LOS CAMBIOS 1
VALIDAR EL ALCANCE 2
CONTROLAR EL CRONOGRAMA 3
CONTROLAR LOS COSTOS 4
CONTROLAR LA CALIDAD 5
CONTROLAS LAS COMUNICACIONES 7
CONTROLAR LOS RIESGOS 8
CONTROLAR LAS ADQUISICIONES 9
CONTROLAR LA PARTICIPACION DE LOS INTERESADOS 10
CIERRE CERRAR EL PROYECTO O FASE 1
CERRAR LAS ADQUISICIONES 9
Tabla 8 Grupos de proceso por área de conocimiento. Fuente: Elaboración propia basada en la guía PMBOK 5ta edición.
47
La tabla mostrada relaciona los 47 procesos que propone el PMBOK 5ta edición con
cada una de las áreas de conocimiento.
El aprovechamiento del contenido y lógica de cuerpo de conocimiento servirá siempre
y cuando se seleccionen correctamente los procesos a usar en el proyecto. Pues la correcta
ejecución no depende de usar los 47 procesos sino de tomar como modelos los procesos
necesarios y con la ayuda de herramientas y técnicas lograr una metodología acorde a la
organización.
Gestión de proyectos con PRINCE2.
“Projects In Controlled Enviroments (PRINCE)” es un método estructurado de origen británico
derivado del estándar PROMTII usada en un inicio por el centro de informática y la agencia de
comunicaciones del gobierno de Reino Unido para la estandarización de sus procesos. Cuenta
con un enfoque basado en dividir el trabajo en fases manejables y enfocarse en el producto.
Los autores explican que este método es capaz de ser fraccionado y usado según la necesidad
de cada organización.
PRINCE 2 define al proyecto como una organización creada con el propósito de entregar
uno o más productos empresariales alineados a un caso de negocio. PRINCE2 describe a la
gestión de proyectos como el trabajo de planificar, delegar, monitorear y controlar todos los
aspectos del proyecto. La gestión del proyecto se lleva a cabo bajo la restricción de controlar
las variables de alcance, calidad, tiempo, costo, beneficio y riesgo. El método se estructura en
siete principios, siete procesos y siete temáticas para gestionar los proyectos, estos elementos
deben estar presentes a lo largo del ciclo de vida del proyecto. A continuación, se muestra un
gráfico que representa la estructura del PRINCE2.
48
Figura 6 Estructura de método PRINCE2. Fuente: (AXELOS, Managing Successful Project with PRINCE2, 2017, pág. 23).
La figura mostrada representa en su base a los principios del método. Se sugiere que a
lo largo del proyecto debe evaluarse si la gestión cumple con los siete principios. Si la gestión
no cuenta con uno de los principios, el proyecto no estará siendo gestionado bajo el método
PRINCE2. A continuación se describe cada uno de los principios.
Continuación de la justificación de negocio: Este principio establece una justificación
aprobada para dar inicio al proyecto basándose en un caso de negocio. Su justificación debe
ser evaluada y permanecer válida durante el ciclo de vida del proyecto. Si en algún momento
no se logra justificar el proyecto, este deberá cerrase.
Aprender de la experiencia: Este principio establece que se deberá revisar las fuentes
de conocimiento y lecciones aprendidas de proyectos pasados. Durante su ejecución el
proyecto deberá aprender a través de la gestión de la mejora continua. Al finalizar deberá
documentarse para lograr cambios en próximos proyectos.
Definición de roles y responsabilidades: El principio sugiere tener tres roles principales,
conformados por un sponsor del negocio para soportar los objetivos y garantizar la rentabilidad
del proyecto alineado al negocio. Un usuario que usará el producto al finalizar el proyecto. Un
49
proveedor que brindará los recursos, experiencia y conocimientos necesarios para entregar el
producto.
Gestión por etapas: Este principio sugiere dividir el proyecto para mejorar la gestión.
Las etapas deben tener un plan detallado que se encuentre alineado al plan de alto nivel.
PRINCE2 sugiere como mínimo una etapa de iniciación y una o más etapas consecuentes a
esta.
Gestión por excepción: Este principio define tolerancias por cada objetivo alineado al
alcance, calidad, tiempo, costo, beneficio, riesgo delegando autoridad para la dirección, gestión
y entrega del proyecto.
Enfoque en productos: Este principio describe que el éxito del proyecto dependerá de
la entrega del producto y no de las actividades para fabricar el producto. Se basa en los
requerimientos de calidad y los criterios de aceptación del mismo. Es importante definir el
producto para no incurrir en posibles cambios que deriven en altos riesgos para su entrega.
Adaptación al entorno del proyecto: Este principio asegura y controla que el método
PRINCE2 usado se adapte al tamaño, complejidad, capacidad y riesgo que significa el proyecto.
Explicado los siete principios fundamentales del PRINCE2, se procede a explicar cada
uno de los temas abordados como elemento integral del método.
Caso de negocio: El caso de negocio se construye para evaluar la viabilidad, factibilidad,
rentabilidad del proyecto como documento a ser usado para la toma de decisiones. Debe
justificar al proyecto y explicar los resultados a través del output, outcome y benfit del proyecto.
Se puede ejemplificar de la siguiente forma, un proyecto que dio como resultado una playa de
estacionamiento eléctrica para un edificio comercial, que logrará suministrar de carga eléctrica
a autos eléctricos que se estacionen dentro, que disminuirá en 40% el tiempo de carga eléctrica
de un auto por día. El ejemplo mostrado explica la justificación continua de todo caso de
negocio.
Organización: Este tema explica la necesidad de dividir la gestión corporativa del equipo
de proyecto en niveles de dirección, gestión y entrega, donde se delega la autoridad a
50
responsables de cada nivel. Existen cuatro niveles de gestión en el PRINCE2, empezando por
el programa o corporación quienes se encuentran fuera del equipo de proyecto, pero a la vez
establecen requisitos y niveles de tolerancia por cada restricción. Siguiendo con la junta del
proyecto quienes asignan tolerancias a cada etapa del proyecto a ser gestionando por el
director del proyecto. El director del proyecto controla las actividades y el avance día a día
dentro de las restricciones del proyecto. El administrador de equipo de gestión contiene
paquetes de trabajo delegados con cierta tolerancia por el director del proyecto.
Calidad: El tema explica la necesidad de definir estrategias de calidad en el inicio del
proyecto. Las estrategias deben responder a los criterios de calidad, métodos de calidad y
responsables de calidad. En PRINCE2 la calidad es fundamental por enfocarse en el producto
y transversal por estar involucrada tanto en la junta directiva como en la gerencia del proyecto.
Planificación: El método sugiere la creación de distintos planes según el nivel de detalle
y tolerancia. Como plan principal se tiene al plan del proyecto, que es el documento que indica
como a través el alcance, costo y tiempo se obtendrá el producto. El plan de etapa es un
documento a mayor nivel de detalle para completar una etapa del proyecto. El plan de equipo
se encarga de programar los paquetes de trabajo para alcanzar una etapa. El plan de excepción
es un documento usado para reducir las desviaciones durante el desarrollo del proyecto.
Riesgos: El riesgo se define como un acontecimiento incierto que si llega a concretarse
tendrá un impacto positivo o negativo en los objetivos de los proyectos, el riesgo puede derivar
en una oportunidad o amenaza. El tema abarca la gestión de los riesgos, para identificarlos
oportunamente, evaluarlos según su impacto en los objetivos y nivel de probabilidad de
ocurrencia, planificar acciones frente a los riesgos e implementar estas acciones de manera
continua a lo largo del ciclo de vida del proyecto.
Cambio: El tema de cambios es inherente en todo proyecto, pues cualquiera sea el caso
siempre se sufrirán cambios. Lo importante es saber controlar los cambios, gestionando la
configuración del proyecto y sus variaciones como propuestas de solicitud de cambio. Este
tema plantea un procedimiento de registro, examinación, propuesta, decisión, implementación
de cambios, los cuáles deben ser aprobados por la junta del proyecto.
Progreso: El tema sugiere implementar mecanismos que permitan monitorear y
51
comparar los resultados alcanzados frente a los planificados, siguiendo los objetivos acordados
en el inicio del proyecto. El progreso se relaciona con el principio de gestión por etapas pues
evalúa cada etapa finalizada. Analizando también el principio de viabilidad del proyecto alineado
a los objetivos del caso de negocio.
Los procesos que sugiere el PRINCE2 son la puesta en marcha de un proyecto, la
dirección de un proyecto, el inicio de un proyecto, el control de fase, la gestión de entrega de
productos, la gestión de los límites de fase, el cierre de un proyecto. A continuación, se
muestran los procesos del método PRINCE2 y su relación a lo largo del ciclo de vida del
proyecto.
Figura 7 Red lógica de relación proceso PRINCE2.
Fuente: (AXELOS, Managing Successful Project with PRINCE 2, 2017, pág. 178).
El método propone dar el primer paso con el proceso puesta en marcha de un proyecto
(SU) generando un expediente que define en un inicio el caso de negocio que debe incluir la
justificación, descripción del producto y los requisitos que garanticen la viabilidad del proyecto.
52
El segundo proceso es el iniciar el proyecto (IP), en este proceso clave se prepara la
estrategia para gestionar el riesgo, la configuración y calidad del producto. Se actualiza y define
el caso de negocio, se establecen los controles y se crea el plan de proyecto.
El tercer proceso es controlar una fase (CS), en este proceso se asigna los paquetes de
trabajo, se realiza el monitoreo de cada actividad midiendo las desviaciones y ejecutando
acciones correctivas. Se actualiza la lista de riesgos y se implementa planes de acción.
El cuarto proceso es la gestión de entrega de productos (PD), en el cual se implementan
las actividades de aceptación, ejecución y entrega de paquetes de trabajo. Se controla la
aceptación de entrega de paquetes de trabajo al director de proyecto de parte del equipo de
administración del proyecto.
El quinto proceso es la gestión de límites de una fase (SB), en este proceso se revisa y
aprueba la entrega de cada etapa evaluando la viabilidad según el caso de negocio y sus
objetivos. Se crea un nuevo plan para la siguiente etapa, se crea un nuevo plan de excepción,
se actualiza el caso de negocio y el plan del proyecto.
El sexto proceso es el cierre del proyecto (CB), en este proceso se realizan las
actividades de aceptación, transferencia del producto y cierre del proyecto. Se compara los
resultados y objetivos según el plan de trabajo y el caso de negocio. Se documenta las lecciones
aprendidas del proyecto.
El séptimo proceso es la dirección del proyecto (DP), proceso transversal a lo largo del
ciclo de vida desde el comienzo hasta el cierre del proyecto. La junta directiva visualiza y evalúa
en todo momento la viabilidad del negocio tomando decisiones y delegando la gestión del
proyecto sobre el director. A lo largo de la dirección del proyecto la junta es responsable de
aprobar cada plan de inicio y fin de etapa, aprobar los planes de excepción y dar la orden para
su ejecución, así como de autorizar el inicio o fin del proyecto.
53
Gestión de proyectos con SCRUM.
A diferencia de los cuerpos de contenidos ya presentados, SCRUM se presenta como un
método ágil pensado en un inicio por Ikujiro Nonaka e Hirotaka Takeuchi en los años 80. Scrum
proviene del juego de Rugby en el cual el equipo se agrupa como uno sólo para lograr el fin
deseado, en la realidad podemos traducirlo como “la gestión de proyectos en situaciones en las
que es difícil planificar el futuro, con mecanismos de control empírico” (Amaya, 2013, pág. 4).
SCRUM se lleva a cabo mediante un desarrollo incremental donde la entrega de productos se
realiza bajo entornos de cambios habituales a lo largo del ciclo de vida del proyecto.
Las principales ventajas de Scrum son la flexibilidad y adaptabilidad a proyectos en los
que no se tenga definido claramente el alcance y surjan modificaciones en el camino. Estos
cambios pueden ser controlados por tareas más pequeñas alcanzadas por el esfuerzo del
equipo de proyecto. A continuación, se muestra una representación gráfica del proceso general
del método Scrum, iniciando por un caso de negocio, definiendo un alcance en una declaración
de visión del programa, priorizando la lista de pendientes y generando los sprints para alcanzar
los entregables a fin de evaluarlos para su aceptación.
Figura 8 Flujo de proceso Scrum. Fuente: Guía SBOOK (SCRUMstudy™, 2016, pág. 19).
Scrum define roles y responsabilidades teniendo como mediador principal al Scrum
Master que cumple un rol de facilitador y controlador de cambios en la gestión de proyectos.
Define a un Product Owner que cumpla el rol de representar los requerimientos de los
54
interesados internos y externos para la creación del producto. Como parte de todo entregable
en Scrum los Stakeholders representan un factor importante para el éxito del proyecto. Por
último se forma el equipo denominado Team para desarrollar las actividades durante cada
sprint. Un sprint es considerado como el desarrollo de un entregable dentro de un periodo de
tiempo en el cual se definirán actividades importantes y se ejecuta según lo definido en el plan.
Se usa el término Backlog para presentar los requisitos de alto nivel que formarán parte del
sprint. Si el sprint lo requiere congelará los requisitos mediante un sprint backlog.
SCRUM también se basa seis principios, los cuales son el control del proceso empírico, la auto-
organización, colaboración, priorización basada en el valor, asignación de un bloque de tiempo,
desarrollo iterativo. Además de contar con aspectos básicos como la organización, la
justificación de negocio, la calidad, el cambio y el riesgo. Por último, SCRUM contiene 19
procesos a ejecutarse en cada fase en el transcurso del proyecto. A continuación, se presenta
una tabla detallada mostrando todos los procesos de SCRUM.
Tabla 9 Procesos del método SCRUM Fuente: Elaboración propia basada en la guía SBOOK.
55
Ciclo de mejora continúa
El ciclo de la mejora continua propuesto por Deming en el año 1950 trasciende hoy en día en
la adopción de esta cultura hacia las normas de calidad. Según lo propuesto por Deming
para una gestión efectiva de la mejora continua se necesita tener liderazgo en dirección
y un comité de mejora continua. Como todo proceso el ciclo de Deming identifica el
problema, listando las entradas de los procesos, aplicando procedimientos en la
transformación del proceso, es aquí donde se identifica las oportunidades, se mide la
eficacia y eficiencia de la salida del proceso.
El ciclo de la mejora continua es aplicable entre procesos en su estado óptimo, es lo
que se busca al usar este sistema, generar beneficios en los procesos externos partiendo de
los procesos internos. A continuación, se muestra gráficamente el ciclo de la mejora continua.
Figura 9 Modelo de relación de mejora continua entre procesos. Fuente: Elaboración propia.
56
Gestión de valor ganado.
La gestión del valor ganado (EVM) se usa para controlar el avance del proyecto. Su función se
inicia a partir de la comparación de lo ejecutado frente a lo planificado y definido como línea
base del costo. El método del valor ganado busca responder a las preguntas de cuántos
recursos se han utilizado, cuánto se ha avanzado por entregable y cuánto se ha desviado de
los gastos planificados. En el mejor de los casos para alcanzar un entregable se puede gastar
menos recursos y menos tiempo; caso contrario, se puede recurrir en mayores gastos de
recursos y tiempo a causa de una ejecución deficiente. Para estas interrogantes se puede
recurrir al cálculo de variables como el valor planeado (PV), costo actual (AC), valor ganado
(EV), presupuesto hasta la conclusión (BAC), variación del costo (CV), variación del
cronograma (SV). El desempeño del valor ganado se mide a través de los indicadores de
desempeño del costo y cronograma CPI y SPI. Lo que busca la gestión de valor ganado es
corregir la variabilidad respecto de la línea base del costo. Se presenta una representación.
.
Figura 10 Curva S de la gestión del valor ganado. Fuente: Elaboración propia.
El Schedule Value (SV) se interpreta como una variación a lo planificado del cronograma
en términos monetarios, donde si SV es mayor a 1 quiere decir que el valor ganado ha sido
mayor al costo planificado. El Cost Value (CV) se interpreta como la variación respecto al costo
planificado si este indicador es mayor a 1 significaría que se genera un ahorro de costo a la
fecha.
0
500
1000
1500
2000
2500
3000
1 2 3 4 5
PR
ESU
PU
ESTO
Control valor ganado
Línea base
Línea base actual
Valor ganado
57
Método mixto propuesto
Como parte del desarrollo de la investigación se propone un método mixto basado en el PMBOK
5ta edición, PRINCE2 y SCRUM para mejorar la gestión de proyectos en la empresa consultora.
¿Por qué un método mixto?
Los proyectos tienen dos atributos principales: el ciclo de vida finito y las características
innatas por proyecto. Basándonos en el segundo atributo cada proyecto se origina, se planea,
se gestiona, se concluye de una forma distinta a pesar de las similitudes con otros proyectos.
Es por ello que hoy en día los proyectos exigen variedad de modelos, procedimientos, técnicas
y herramientas. El aporte del método mixto se encarga de entregar lo mejor de cada uno de los
tres cuerpos de conocimientos previamente explicados. Esto para asegurar que el usuario del
método tenga una visión clara y amplia para poder gestionar sus proyectos.
¿Qué ventajas tiene el método mixto sobre los métodos existentes?
En comparación con los demás métodos, este método tiene la ventaja de estar hecho
para ser una guía coordinada para la gestión desde la conceptualización hasta el cierre formal
de un proyecto. El aporte incluye la descripción detallada de cada proceso, así como también
el flujo de procesos que representan la secuencia ordenada por procesos y etapas.
Una de las ventajas es que el método ofrece 18 procesos bien estructurados en
comparación de los 47 procesos del PMBOK 5ta edición, los 7 procesos y 41 subprocesos del
PRINCE2 y los 19 procesos del SCRUM. El método mixto contiene los principales inputs,
outputs para gestionar los proyectos. Asimismo, estos pueden ser estudiados de forma rápida
sin la necesidad de incurrir en cuantiosas horas de estudio para comprender la ciencia de
gestionar proyectos. El usuario puede consultar la representación gráfica del modelo del
método mixto.
Otra ventaja es que se ha interiorizado la mejora continua dentro de sus procesos, esto
con el fin de asegurar la calidad de los outputs y cumplir con el enfoque orientado a entregables
y satisfacción del cliente.
58
Otra ventaja es que método está orientado para ser ágil en la etapa de ejecución y
control con la finalidad de ser efectivo en el cumplimiento de entregables. La ventaja se presenta
sobre el cuerpo de contenido del PMBOK 5ta edición y el método PRINCE2.
Descripción del método mixto
Este método fue aplicado a proyectos de implementación de soluciones multimedia para
entidades estatales. El método mixto propuesto para la mejora de gestión de proyectos tiene la
finalidad de entregar un marco que sea ágil y concreto. El método plantea el uso e integración
de los principales elementos tomados del PMBOK 5ta edición, PRINCE2 y SCRUM. El método
se ajusta a las necesidades de los proyectos en tecnología de la información llevados a cabo
por la empresa consultora, considerando un margen de flexibilidad y adaptabilidad para su
aplicación en proyectos de otros rubros de la industria. A continuación, se muestra los
elementos clave de las guías prácticas y metodologías tomadas como base para definir el
método mixto.
Figura 11 Elementos clave de métodos tomados. Fuente: Elaboración propia basada en los elementos clave de cada guía o método.
Como se puede apreciar en la figura mostrada, cada cuerpo de conocimiento contiene
propios principios y procesos estructurados de manera distinta. Los principios y la forma de
seguir los procesos comprueban si un proyecto se lleva a cabo bajo el enfoque de cualquiera
59
de los métodos antes mencionados. Otro punto es que cada uno presenta sus propias
restricciones las cuales delimitan el accionar dentro del ciclo de vida del proyecto. En adición a
ello, cada método cuenta con un propio enfoque orientado a los entregables del proyecto o a
entregar el producto final. Por último, PMBOK y PRINCE2 no limitan la cantidad máxima de
miembros para el equipo de proyecto, solo el método ágil SCRUM recomienda un rango
específico.
Partiendo del estudio y la compresión de los principales elementos de cada cuerpo de
conocimiento, la propuesta del método mixto se define los elementos del método propuesto que
servirán como base para el desarrollo, se presenta la estructura de su contenido, se explica el
modo de operación de los procesos a través de diagramas de bloques, se presenta un
flujograma integral de los procesos. Por último, se presenta la iteración entre los grupos de
procesos más representativos del método.
Elementos del método mixto propuesto
El método propuesto presenta cuatro elementos a considerar para la gestión de proyectos. Los
procesos del proyecto formados en cuatro grupos de procesos, el entorno del proyecto, el
enfoque aplicado para el proyecto y la conformación de los miembros del equipo del proyecto.
Figura 12 Elementos del método mixto propuesto.
Fuente: Elaboración propia basada en el estudio del PMBOK, PRINCE2 y SCRUM.
60
Entorno del proyecto.
Su propio nombre lo describe como la base a considerar frente a la toma de decisiones en el
desarrollo del proyecto. Ningún proyecto puede desarrollarse sin considerar las variables por
las cuáles será sometido a lo largo de su ciclo de vida. El método mixto indica que se debe
considerar lo siguiente respecto al entorno.
El primer punto a tratar por el entorno serán los factores ambientales. Los factores a
considerar bajo el método mixto son la cultura organizacional que influye en la mayoría de los
casos para alcanzar los objetivos del proyecto, la política establecida en la organización que
predetermina el accionar a lo largo del proyecto, las variables externas al proyecto que están
sujetas a cambios socio-políticos, económicos, tecnológicos, legales y globales.
El segundo punto a tratar por el entorno serán las restricciones para el proyecto. El
método indica que los proyectos se encuentran supeditados por restricciones básicas en el
alcance del proyecto, el tiempo para entregar el proyecto, el presupuesto establecido para su
desarrollo, la utilidad del proyecto, los objetivos planteados, los riesgos a los que se afronta el
proyecto, los recursos asignados para el proyecto y la satisfacción de los interesados del
proyecto.
Enfoque.
El enfoque del método propuesto orienta los esfuerzos para alcanzar los entregables del
proyecto y lograr satisfacer las expectativas del cliente. El método sugiere desglosar el proyecto
en partes más pequeñas para tener mapeado el progreso de cada entregable. Sumado a ello,
el método sugiere definir previamente los atributos que tendrá el entregable principal y
establecer estrategias para cumplir con los atributos asegurando la satisfacción del cliente al
finalizar el proyecto.
Equipo del proyecto.
La composición del equipo de proyecto es otro elemento muy importante del método propuesto,
pues es la base del capital intelectual para poder desarrollar el proyecto. El método sugiere que
se encuentre liderado por un Project Manager que asuma la responsabilidad de la dirección del
proyecto. Entre sus principales funciones tiene que ser el medio entre los requerimientos del
patrocinador y los requerimientos del usuario final o cliente. Seguido en el rango de jerarquía,
se tiene al(los) Project Facilitator que cumplen el rol de facilitar las actividades gestión y
61
comunicación del equipo de proyecto, principalmente del Project Manager. Dentro del mismo
rango de jerarquía, se tiene al Product Owner que cumple el rol de reunir los requerimientos del
cliente y las partes interesadas. En el mismo rango, también tenemos al(los) Project Controller
que se encargan de controlar las actividades que se realizan día a día, así como también de
controlar la obtención de cada entregable. En el nivel más bajo tenemos al(los) Assistant que
se encargan de asistir al Project Manager en actividades básicas.
Grupos de procesos.
El elemento que completa el método mixto es la conformación de los dieciocho procesos, los
cuales se encuentran aglomerados en cuatro grupos alineados al ciclo de vida del proyecto,
cabe mencionar que los procesos pueden resultar ser iterativos según la forma en cómo se
ejecute el proyecto. Se tiene a los grupos de procesos de conceptualización, grupos de
procesos de inicio y planificación, grupos de procesos de ejecución y control, grupos de
procesos de cierre. A continuación, se detalla los procesos integrantes de cada grupo.
Grupos de procesos de conceptualización.
Este grupo incluye los procesos para formular y evaluar un caso de negocio, bajo evaluación el
requerimiento es conceptualizado para convertirse en un proyecto con características
predefinidas en costo y plazo estimado.
Análisis y evaluación de caso de negocio: Los insumos de este proceso son el
requerimiento inicial por parte del patrocinador, quién se encarga de proponer y de brindar la
información inicial sobre el caso. Un insumo importante es incluir los factores ambientales que
pueden afectar al proyecto.
El proceso se lleva a cabo a través del análisis y evaluación por medio de modelo
preestablecidos dentro o fuera de la organización. Para confirmar algunos datos o ideas sobre
el caso de negocio se puede consultar a expertos sobre el juicio que tienen sobre lo relacionado
al caso de negocio.
Como salida se obtiene información sobre la viabilidad, los beneficios y los riesgos de
alto nivel por llevar a cabo el caso de negocio. A continuación, se presenta el diagrama de
bloques con las entradas, las herramientas que se recomiendan usar y las salidas de este
proceso.
62
Figura 13 Proceso de análisis y evaluación de caso de negocio. Fuente: Elaboración propia basada en el estudio del PMBOK, PRINCE2 y SCRUM.
Definición de caso de negocio como proyecto: Los insumos de este proceso son la
información sobre la viabilidad, los beneficios esperados y el listado de riesgos del caso de
negocio.
El proceso se lleva a través de la consulta de juicio de expertos y del planteamiento del
proyecto en un modelo preestablecido, en el caso de esta investigación se aplica a la práctica
el método mixto propuesto.
Como salida del proceso se obtiene una definición primaria del proyecto indicando
datos estimados sobre el costo y tiempo estimado. A continuación, se presenta el diagrama de
bloques con las entradas, las herramientas que se recomiendan usar y las salidas de este
proceso.
Figura 14 Proceso de definición del caso de negocio como proyecto.
Fuente: Elaboración propia basada en el estudio del PMBOK, PRINCE2 y SCRUM.
63
Grupos de procesos de inicio y planificación.
Este grupo incluye los procesos para acordar un inicio formal para la creación del proyecto,
además incluye los procesos dedicados a la planificación de las actividades de gestión y de las
actividades de obtención de entregables. Como proceso fundamental se lleva a cabo la
integración del plan del proyecto, la cual se encarga de integrar todos los planes dentro de un
plan maestro. A continuación, se describe cada uno de los procesos de este grupo.
Recopilación y evaluación de requisitos: El insumo de este proceso es el listado de
requerimientos propuestos por cada interesado que es identificado como parte del proyecto.
El proceso se lleva a cabo mediante la priorización de los requisitos dentro de una
matriz.
Como salida se obtiene la lista priorizada de requisitos y la actualización del listado de
riesgos. A continuación, se presenta el diagrama de bloques con las entradas, las herramientas
que se recomiendan usar y las salidas de este proceso.
Figura 15 Proceso de recopilación y evaluación de requisitos. Fuente: Elaboración propia basada en el estudio del PMBOK, PRINCE2 y SCRUM.
Desarrollo de acta constitutiva del proyecto: Los insumos de este proceso son el listado
de requisitos, el listado de riesgos, la definición primaria del proyecto, los contratos que se
encuentren mediados por cláusulas específicas, los factores ambientales de la organización y
las restricciones básicas del proyecto.
64
El proceso se lleva a cabo a través de la composición del acta haciendo uso de un
modelo preestablecido dentro o fuera de la organización, este documento debe ser aprobado
por los interesados clave del proyecto, por el gerente del proyecto y el patrocinador
principalmente.
Como salida se obtiene el acta de constitución del proyecto aprobada, este documento
contiene los datos esenciales del proyecto acerca de los hitos que se acordaron para el
proyecto, las asunciones y las excepciones del proyecto, los criterios de aceptación de los
entregables, la lista de riesgos de alto nivel, el plazo estimado y el presupuesto estimado. A
continuación, se presenta el diagrama de bloques con las entradas, las herramientas que se
recomiendan usar y las salidas de este proceso.
Figura 16 Proceso de desarrollo de acta constitutiva del proyecto. Fuente: Elaboración propia basada en el estudio del PMBOK, PRINCE2 y SCRUM.
Definición del alcance del proyecto: Los insumos de este proceso son la lista priorizada
de requisitos, el acta de constitución del proyecto y las restricciones básicas del proyecto.
El proceso se lleva a cabo completando el modelo de definición del alcance, pudiendo
apoyarse de juicios de expertos y reuniones realizadas con los interesados del proyecto.
Como salida se obtiene el documento que formaliza el alcance del proyecto, este
documento debe precisar que se incluirá y que no se incluirá en el trabajo a realizar para obtener
el entregable final del proyecto. Sumado a ello se obtendrá la estructura de desglose de trabajo
(EDT), que viene a ser la composición estructural del proyecto dividida en entregables de
65
distintos niveles, el nivel más bajo serán los paquetes de trabajo y servirán para definir las
actividades a realizar. A continuación, se presenta el diagrama de bloques con las entradas, las
herramientas que se recomiendan usar y las salidas de este proceso.
Figura 17 Proceso de definición de alcance del proyecto. Fuente: Elaboración propia basada en el estudio del PMBOK, PRINCE2 y SCRUM.
Planificación de la gestión del alcance y actividades del backlog: Los insumos de este
proceso son el documento de alcance definido, la estructura de desglose de trabajo, los factores
ambientales, las restricciones básicas y las propuestas de mejora continua.
El proceso se lleva a cabo mediante un método de planificación, apoyadas por consultas
a juicios de expertos y reuniones con interesados.
Como salida se obtiene el plan de gestión del alcance y las actividades del backlog, y el
protocolo de control de cambios. El plan detalla cómo se gestionará el alcance y cómo se
desarrollarán las actividades del backlog alineadas a la estructura de desglose de trabajo y al
alcance definido. El protocolo de control de cambios debe indicar la mecánica frente a las
solicitudes de cambios en el proyecto. A continuación, se presenta el diagrama de bloques con
las entradas, las herramientas que se recomiendan usar y las salidas de este proceso.
66
Figura 18 Proceso de planificación de la gestión del alcance y las actividades del backlog.
Fuente: Elaboración propia basada en el estudio del PMBOK, PRINCE2 y SCRUM.
Planificación de la gestión del cronograma: Los insumos de este proceso son el acta de
constitución del proyecto, la estructura de desglose de trabajo, los factores ambientales, las
restricciones básicas y las propuestas de mejora continua.
El proceso se lleva a cabo mediante un método de planificación, apoyadas por consultas
a juicios de expertos y reuniones con interesados. Como salida el plan detalla cómo se
gestionará el cronograma, el cual deberá ir alineado a la línea de tiempo definida para el
proyecto en el acta de constitución. A continuación, se presenta el diagrama de bloques con las
entradas, las herramientas que se recomiendan usar y las salidas de este proceso.
Figura 19 Proceso de planificación del cronograma. Fuente: Elaboración propia basada en el estudio del PMBOK, PRINCE2 y SCRUM.
67
Planificación de la gestión del equipo del proyecto: Los insumos de este proceso son el
acta de constitución del proyecto, los factores ambientales, las restricciones básicas y las
propuestas de mejora continua.
El proceso se lleva a cabo mediante un método de planificación, apoyado del uso de la
matriz de RACI, también se puede realizar consultas a juicios de expertos y reuniones con
interesados.
Como salida, el plan entrega la lista definida de los miembros del equipo del proyecto,
el listado de roles y responsabilidades del equipo del proyecto, también detalla la forma en la
se gestionará al equipo a lo largo del ciclo de vida del proyecto. A continuación, se presenta el
diagrama de bloques con las entradas, las herramientas que se recomiendan usar y las salidas
de este proceso.
Figura 20 Proceso de planificación de la gestión del equipo del proyecto. Fuente: Elaboración propia basada en el estudio del PMBOK, PRINCE2 y SCRUM.
Planificación de la gestión de la calidad: Los insumos de este proceso son el acta de
constitución del proyecto, los criterios de aceptación de los entregables, los factores
ambientales, las restricciones básicas y las propuestas de mejora continua.
El proceso se lleva a cabo mediante un método de planificación, apoyado por consultas
a juicios de expertos y reuniones con interesados.
En la salida del proceso el plan detalla cómo se llevará a cabo el aseguramiento y el
control de calidad sobre los entregables para satisfacer las expectativas del cliente, además de
68
incluir los criterios de calidad que deberá contener cada entregable. A continuación, se presenta
el diagrama de bloques con las entradas, las herramientas que se recomiendan usar y las
salidas de este proceso.
Figura 21 Proceso de planificación de la gestión de la calidad. Fuente: Elaboración propia basada en el estudio del PMBOK, PRINCE2 y SCRUM.
Planificación de la gestión del riesgo: Los insumos de este proceso son el acta de
constitución del proyecto, la estructura de desglose de trabajo, la lista de riesgos de alto nivel,
los factores ambientales, las restricciones básicas y las propuestas de mejora continua.
El proceso se lleva a cabo mediante un método de planificación, métodos de evaluación
de riesgos, modelo de matriz de riesgos, apoyados por consultas a juicios de expertos y
reuniones con interesados.
En la salida del proceso el plan detalla los procedimientos para identificar, evaluar,
priorizar y tratar mediante planes de acción a los riesgos del proyecto, además de incluir la lista
de riesgos actualizada. A continuación, se presenta el diagrama de bloques con las entradas,
las herramientas que se recomiendan usar y las salidas de este proceso.
69
Figura 22 Proceso de la planificación de la gestión del riesgo. Fuente: Elaboración propia basada en el estudio del PMBOK, PRINCE2 y SCRUM.
Planificación de la gestión del presupuesto: Los insumos de este proceso son el acta de
constitución del proyecto que incluye el presupuesto estimado en un inicio, la estructura de
desglose de trabajo, los factores ambientales, las restricciones básicas y las propuestas de
mejora continua.
El proceso se lleva a cabo mediante un método planificación, apoyado por consultas a
juicios de expertos y reuniones con interesados.
En la salida del proceso el plan detalla los procedimientos para gestionar y controlar el
presupuesto a lo largo del ciclo de vida. A continuación, se presenta el diagrama de bloques
con las entradas, las herramientas que se recomiendan usar y las salidas de este proceso.
Figura 23 Proceso de planificación de la gestión del presupuesto. Fuente: Elaboración propia basada en el estudio del PMBOK, PRINCE2 y SCRUM.
Planificación del ciclo de la mejora continua: Los insumos de este proceso son las
70
propuestas de mejora, los informes de desempeño de proyectos históricos, los factores
ambientales, las restricciones.
El proceso se lleva a cabo mediante el uso del método del Plan, Do, Check, Act (PDCA
ciclo de Deming), apoyado por las consultas a juicios de expertos y reuniones con interesados.
En la salida del proceso el plan detalla el procedimiento para implementar el ciclo de la
mejora continua durante el ciclo de vida del proyecto. A continuación, se presenta el diagrama
de bloques con las entradas, las herramientas que se recomiendan usar y las salidas de este
proceso.
Figura 24 Proceso de planificación del ciclo de la mejora continua. Fuente: Elaboración propia basada en el estudio del PMBOK, PRINCE2 y SCRUM.
Integración del plan del proyecto: Los insumos de este proceso son el alcance definido
para el proyecto, los seis planes de gestión, el plan del ciclo de la mejora continua y los factores
ambientales.
El proceso se lleva a cabo mediante métodos de integración de los planes, apoyado por
las consultas a juicios de expertos y reuniones con interesados.
Como salida del proceso se obtiene el documento que servirá como columna vertebral
para la ejecución del proyecto, el plan maestro del proyecto que también debe contener los
procedimientos de control para el proyecto. A continuación, se presenta el diagrama de bloques
con las entradas, las herramientas que se recomiendan usar y las salidas de este proceso.
71
Figura 25 Proceso de integración del plan del proyecto. Fuente: Elaboración propia basada en el estudio del PMBOK, PRINCE2 y SCRUM.
Grupos de procesos de ejecución y control.
Este grupo incluye los procesos para ejecutar y controlar el desarrollo de los entregables del
proyecto. Para esto se hace uso de lo planificado para llevar a cabo los esfuerzos operativos y
de gestión. Además de ello, los procesos aseguran que se realice un seguimiento y control
sobre las actividades. A continuación, se describe cada uno de los procesos de este grupo.
Creación de los entregables por sprints: Los insumos de este proceso son el plan
maestro del proyecto junto con los demás planes que sirven para revisar la lista de actividades
del backlog, el listado de riesgos del proyecto que sirve para revisar los riesgos identificados y
evaluados, los criterios de calidad de los entregables que sirven para medir si un entregable
está cumpliendo con la calidad establecida, los factores ambientales que pueden representar
variaciones en la ejecución del proyecto, las restricciones básicas del proyecto y las propuestas
de mejora continua.
El proceso se lleva a cabo mediante la ejecución del plan maestro, la cual debe asegurar
que se alcancen los entregables según las especificaciones acordadas. Para la ejecución se
recomienda usar el tablero Kanban junto con el check list para saber que está pendiente por
hacer, que se está haciendo y que se ha completado del backlog, también se recomienda
consultar a juicios de experto y llevar a cabo reuniones diarias con el equipo del proyecto.
Como salida se obtienen los entregables listos para ser aprobados, el check list
72
actualizado, los datos de desempeño de trabajo por los entregables del proyecto, solicitudes de
cambio del proyecto, las lecciones aprendidas y las nuevas solicitudes de cambio en el
proyecto. A continuación, se presenta el diagrama de bloques con las entradas, las
herramientas que se recomiendan usar y las salidas de este proceso.
Figura 26 Proceso de creación de los entregables por sprints.
Fuente: Elaboración propia basada en el estudio del PMBOK, PRINCE2 y SCRUM.
Ejecución y control sobre los procesos de gestión: Los insumos de este proceso son el
plan maestro del proyecto (específicamente la parte de procedimientos de control), el listado de
riesgos del proyecto, los factores ambientales que afectan al proyecto, las restricciones básicas
del proyecto, las propuestas de mejora y las solicitudes de cambio aprobadas.
En el proceso se utiliza el modelo de cumplimiento de alcance para controlar las
actividades destinadas a alcanzar los entregables. Para controlar el plazo de entrega del
proyecto se puede hacer uso de un cronograma apoyado del diagrama de Gantt para seguir y
controlar de forma general el avance de las actividades o del Burndown Chart para controlar el
tiempo empleado por cada actividad. Para controlar el presupuesto se puede hacer uso del
modelo del valor ganado en el tiempo. Para controlar la calidad se puede hacer uso de un
modelo de cumplimiento de parámetros de calidad. Para controlar el riesgo se puede hacer uso
de un modelo de evaluación y seguimiento de riesgo, esto con el fin de asegurar que los planes
de respuestas a los riesgos se estén implementando. El proceso puede hacer uso del método
PDCA para verificar las acciones de mejora en la ejecución de las actividades operativas y de
gestión. También se puede consultar con expertos y realizar reuniones del equipo del proyecto.
73
Como salida se obtienen la actualización del plan maestro del proyecto (si fuera el caso),
actualización del estado de avance del backlog, los datos de desempeño de trabajo que indican
el resultado de la verificación de las mejoras propuestas, las nuevas solicitudes de cambios en
el proyecto, las lecciones aprendidas y un feedback para cada uno de los miembros del equipo
del proyecto. A continuación, se presenta el diagrama de bloques con las entradas, las
herramientas que se recomiendan usar y las salidas de este proceso.
Figura 27 Proceso de ejecución y control sobre los procesos de gestión. Fuente: Elaboración propia basada en el estudio del PMBOK, PRINCE2 y SCRUM.
Aprobación y transferencia de entregables: Los insumos de este proceso son el plan
maestro del proyecto, el documento de alcance definido, los contratos de por medio en el
proyecto, los entregables listos por aprobar, los criterios de calidad de los entregables, las
restricciones básicas y las propuestas de mejora.
En el proceso se utilizan modelos de verificación para comprobar las características y
criterios de aceptación de los entregables, se usan técnicas de demostración de entregables
para asegurar que el cliente comprenda y acepte los entregables, se usan las especificaciones
de los entregables, también se consulta a juicios de expertos y se realizan reuniones del equipo
del proyecto.
Como salida del proceso se obtienen los documentos de aprobación de entregables, los
cuales detallarán si los entregables cumplen con lo acordado y servirán como garantía de
74
aprobación. De aprobarse, el proceso da como salida la propiedad, la documentación y
capacitación sobre los entregables, esto como transferencia de los mismos hacia el cliente que
gozará del entregable. En caso no se aprueben los entregables, el proceso da como salida una
solicitud de reajuste en los entregables, especificando que características deben contener para
ser aprobados en una próxima revisión. Por último, el proceso genera lecciones aprendidas del
proyecto.
Figura 28 Proceso de aprobación y transferencia de entregables.
Fuente: Elaboración propia basada en el estudio del PMBOK, PRINCE2 y SCRUM.
Grupos de procesos de cierre.
Este grupo incluye los procesos poder cerrar el proyecto desde las dimensiones del cierre con
clientes internos y externos, y del cierre de la documentación del proyecto, incluyendo
propuestas de mejora en base a los informes de desempeño. A continuación, se describe cada
uno de los procesos de este grupo.
Cierre con clientes (internos y externos): Los insumos de este proceso son el plan
maestro del proyecto, el documento de aprobación de entregables, los contratos determinantes
del proyecto, las restricciones básicas y las propuestas de mejora.
En el proceso se utilizan técnicas de retroalimentación con los clientes internos de la
organización, además de aplicar los procedimientos de la organización para garantizar el pago
efectivo a proveedores, el cobro efectivo al cliente externo y la generación de la constancia de
conformidad del proyecto, la cual debe ser aprobada por cada interesado clave. Como salida
75
del proceso también se obtienen lecciones aprendidas del proyecto.
Figura 29 Proceso de cierre con clientes (internos y externos).
Fuente: Elaboración propia basada en el estudio del PMBOK, PRINCE2 y SCRUM.
Elaboración del informe final de desempeño del proyecto: Los insumos de este proceso
son el acta de constitución del proyecto, el documento de aprobación de entregables, la
propiedad, documentación y capacitación por la transferencia de los entregables, los datos de
desempeño del trabajo evaluados en el seguimiento y control de las actividades operativas y
de gestión, por último las propuestas de mejora.
El proceso consiste en elaborar un informe final, donde principalmente se analice y
documente los resultados del cumplimiento de los objetivos del proyecto, cumplimiento del
alcance del proyecto, los resultados de la rentabilidad y el margen de utilidad que genera el
proyecto, los resultados del análisis de la satisfacción del cliente (interno y externo),
principalmente del dueño del entregable. También debe incluir los resultados del análisis del
tiempo empleado en el proyecto, indicando si el proyecto se entregó dentro del plazo
determinado en el acta de constitución y cuáles fueron las variaciones en el tiempo, debe incluir
los hitos alcanzados, así como los resultados de la ejecución de las actividades, la gestión de
la calidad, la gestión de los riesgos tratados, además de otros indicadores operativos.
El informe final debe contener todo lo mencionado, además de un apartado sobre las
lecciones aprendidas que indiquen mejoras a implementar en otros proyectos. Por último, como
salida también se obtiene la actualización del formato histórico de proyectos, el consolidado de
resultados de proyecto, el binder físico y electrónico del proyecto.
76
Figura 30 Proceso de elaboración del informe final de desempeño del proyecto. Fuente: Elaboración propia basada en el estudio del PMBOK, PRINCE2 y SCRUM.
Luego de la explicación de las entradas, herramientas y salidas de cada proceso se
presenta el flujo consolidado de los dieciocho procesos del método mixto. Como en todo
proyecto la situación presentada a lo largo del ciclo de vida promueve a que los procesos sean
iterativos con procesos de otros grupos, por esta razón el método ha considerado representar
mediante un diagrama las principales iteraciones que se dan entre los procesos del grupo de
iniciación y planificación y los procesos del grupo de ejecución y control. Para un mayor
entendimiento a continuación se ilustran las formas y su significado para los diagramas de flujo.
77
Figura 31 Formas usadas para diagramación
Fuente: Elaboración propia
78
Figura 32 Dieciocho procesos del método mixto.
Fuente: Elaboración propia.
79
Figura 33 Iteración entre procesos de inicio y planificación con procesos de ejecución y control. Fuente: Elaboración propia.
80
OBJETIVOS
Objetivo general
Mejorar la gestión de proyectos aplicando la guía PMBOK, el método PRINCE2 y el método
SCRUM.
Objetivos específicos
Mejorar el cumplimiento de los objetivos en los proyectos aplicando la guía PMBOK, el método
PRINCE2 y el método SCRUM.
Mejorar el impacto en el cumplimiento del alcance de los proyectos aplicando la guía PMBOK,
el método PRINCE2 y el método SCRUM.
Mejorar el impacto en el margen de utilidad obtenido una vez culminado los proyectos aplicando
la guía PMBOK, el método PRINCE2 y el método SCRUM.
Mejorar el impacto en la satisfacción del cliente una vez entregados los proyectos aplicando la
guía PMBOK, el método PRINCE2 y el método SCRUM.
81
JUSTIFICACION
La justificación teórica se basa en que la investigación aportará conocimiento nuevo al campo
de la ingeniería industrial y comercial, pues se aplicará conceptos, métodos, herramientas y
técnicas de ingeniería que ayudarán a lograr los objetivos de la investigación. Cabe mencionar
que el método propuesto se evaluará para proyectos de una empresa consultora de tecnología
de la información. No obstante, el método es flexible y aplicable en cualquier sector de la
industria, por ser fuente de conocimiento derivado de la integración de tres guías de dirección
de proyectos usadas y validadas mundialmente. El método propuesto puede ser usado para
crear productos, servicios, soluciones, implementar mejoras de procesos o proyectos sociales.
En la práctica se logrará mejorar el cumplimiento de los objetivos del proyecto,
mejorando el cumpliendo con el alcance del proyecto, impactando positivamente en el margen
de utilidad y mejorando la satisfacción del cliente que obtiene el producto. Cumpliendo estos
objetivos se logrará mejorar la gestión del proyecto en el día a día, contribuyendo a que la
empresa consultora y los usuarios interesados en la gestión de proyectos puedan añadir este
método como partes de los activos de procesos de la organización, para ser analizado,
estudiarlo y utilizarlo en el desarrollo de sus proyectos. La puesta en práctica del método
generará lecciones aprendidas como parte del proceso de elaboración y comprobación de la
investigación, las cuales serán usadas para retroalimentar, mejorar y definir el método mixto.
Socialmente la investigación aporta desde dos frentes. El primer frente tiene que ver
con las organizaciones, al ser un método comprobado científicamente puede lograr a través de
su uso impactar en los resultados de proyectos de cualquier sector de la industria. A nivel
regional y local dentro del país, el método establece los conocimientos, herramientas y técnicas
para manejar proyectos de alto grado de incertidumbre. Desde el punto de vista personal la
investigación contribuye como guía para el desarrollo de proyectos personales, pues resulta ser
fácil de comprender para proyectos donde las decisiones pasan por solo un responsable.
82
HIPOTESIS
Hipótesis general
Hipótesis alterna: Aplicando la guía PMBOK, el método PRINCE2 y el método SCRUM se
mejorará la gestión de proyectos.
Hipótesis nula: Aplicando la guía PMBOK, el método PRINCE2 y el método SCRUM no se
mejorará la gestión de proyectos.
Hipótesis especifica
Hipótesis alterna 1: Aplicando la guía PMBOK, el método PRINCE2 y el método SCRUM se
obtendrá una mejora en el cumplimiento de los objetivos en los proyectos.
Hipótesis nula 1: Aplicando la guía PMBOK, el método PRINCE2 y el método SCRUM no se
obtendrá una mejora en el cumplimiento de los objetivos en los proyectos.
Hipótesis alterna 2: Aplicando la guía PMBOK, el método PRINCE2 y el método SCRUM se
obtendrá una mejora en el cumplimiento del alcance de los proyectos.
Hipótesis nula 2: Aplicando la guía PMBOK, el método PRINCE2 y el método SCRUM no se
obtendrá una mejora en el cumplimiento del alcance de los proyectos.
Hipótesis alterna 3: Aplicando la guía PMBOK, el método PRINCE2 y el método SCRUM se
obtendrá una mejora en el margen de utilidad una vez culminado los proyectos.
Hipótesis nula 3: Aplicando la guía PMBOK, el método PRINCE2 y el método SCRUM no se
obtendrá una mejora en el margen de utilidad una vez culminado los proyectos.
Hipótesis alterna 4: Aplicando la guía PMBOK, el método PRINCE2 y el método SCRUM se
obtendrá una mejora en la satisfacción del cliente una vez entregados los proyectos.
Hipótesis nula 4: Aplicando la guía PMBOK, el método PRINCE2 y el método SCRUM no se
obtendrá una mejora en la satisfacción del cliente una vez entregados los proyectos.
83
MATRIZ DE CONSISTENCIA
Problema Objetivos Hipótesis Variables Metodología
Problema general ¿Qué mejora se obtendrá en la gestión de proyectos aplicando la guía PMBOK, el método PRINCE2 y el método SCRUM?
Objetivo general Mejorar la gestión de proyectos aplicando la guía PMBOK, el método PRINCE2 y el método SCRUM.
Hipótesis general Aplicando la guía PMBOK, el método PRINCE2 y el método SCRUM se mejorará la gestión de proyectos.
Variable independiente Método mixto.
Tipo de investigación Investigación aplicada, no experimental, transversal
Problema específico ¿Cuál es el impacto en el cumplimiento de los objetivos en los proyectos aplicando la guía PMBOK, el método PRINCE2 y el método SCRUM? ¿Cuál es el impacto en el cumplimiento del alcance de los proyectos aplicando la guía PMBOK, el método PRINCE2 y el método SCRUM? ¿Cuál es el impacto en el margen de utilidad obtenido una vez culminado los proyectos aplicando la guía PMBOK, el método PRINCE2 y el método SCRUM? ¿Cuál es el impacto en la satisfacción del cliente una vez entregados los proyectos aplicando la guía PMBOK, el método PRINCE2 y el método SCRUM?
Objetivo específico Mejorar el cumplimiento de los objetivos en los proyectos aplicando la guía PMBOK, el método PRINCE2 y el método SCRUM. Mejorar el impacto en el cumplimiento del alcance de los proyectos aplicando la guía PMBOK, el método PRINCE2 y el método SCRUM. Mejorar el impacto en el margen de utilidad obtenido una vez culminado los proyectos aplicando la guía PMBOK, el método PRINCE2 y el método SCRUM. Mejorar el impacto en la satisfacción del cliente una vez entregados los proyectos aplicando la guía PMBOK, el método PRINCE2 y el método SCRUM.
Hipótesis específica Aplicando la guía PMBOK, el método PRINCE2 y el método SCRUM se obtendrá una mejora en el cumplimiento de los objetivos en los proyectos. Aplicando la guía PMBOK, el método PRINCE2 y el método SCRUM se obtendrá una mejora en el cumplimiento del alcance de los proyectos. Aplicando la guía PMBOK, el método PRINCE2 y el método SCRUM se obtendrá una mejora en el margen de utilidad una vez culminado los proyectos. Aplicando la guía PMBOK, el método PRINCE2 y el método SCRUM se obtendrá una mejora en la satisfacción del cliente una vez entregados los proyectos.
Variable dependiente Mejora de la gestión de proyectos TI.
Método de investigación Método cuantitativo Marco teórico: Proyectos PMBOK 5ta edición PRINCE2 SCRUM Mejora continua Valor ganado Método mixto propuesto
Tabla 10 Matriz de consistencia
Fuente: Elaboración propia
84
MARCO METODOLOGICO
La metodología usada para el desarrollo de la investigación es de finalidad aplicada para dar
con la solución inmediata al problema planteado. Contiene un paradigma positivista, basándose
en la observación de datos cuantitativos para su estudio. Se plantea las posibles hipótesis para
deducir una solución al problema. Asimismo, presente un enfoque cuantitativo pues usa
números como datos de muestra y población, contribuyendo al análisis estadístico para
defender la veracidad de las hipótesis. El método usado es no experimental y transversal pues
en un momento determinado se toma la muestra de datos preestablecidos en la práctica para
ser analizados.
VARIABLES
La investigación es bi-variada, donde la variable independiente es el método mixto a
implementarse. Esta variable no sufre cambios por alguna otra variable e impacta directamente
sobre la variable dependiente. La variable dependiente se define como la mejora de gestión en
proyectos. Esta variable dependerá del método aplicado a los proyectos.
POBLACION Y MUESTRA
Por ser una investigación basada en el estudio de los proyectos de implementación de una
organización, se toman los datos resultantes de los proyectos delivery (entregados) de
tecnología de la información, pertenecientes a proyectos gestionados desde el año 2012 al
2017. Consecuentemente a lo explicado, la población es definida como los proyectos
finalizados que fueron gestionados en la empresa consultora. Sin embargo, se aclara que una
parte de los proyectos han sido gestionados con el método empírico actual, los demás y más
recientes del año 2017 han sido gestionados con el método mixto propuesto. Para mayor
comprensión sobre lo indicado se puede observar la siguiente tabla del tamaño de la población
en donde se indica el proyecto, su código asignado, el año de ejecución del proyecto y el
método usado para su gestión.
85
N° Entidad
Público/Privada Código
Proyecto Año Método usado
1 Entidad Pública 1 001 2012 Actual(empírico)
2 Entidad Pública 2 002 2012 Actual(empírico)
3 Entidad Pública 3 003 2013 Actual(empírico)
4 Entidad Pública 4 004 2013 Actual(empírico)
5 Entidad Pública 5 005 2013 Actual(empírico)
6 Entidad Pública 7 006 2014 Actual(empírico)
7 Entidad Pública 4 007 2014 Actual(empírico)
8 Entidad Pública 3 008 2014 Actual(empírico)
9 Entidad Pública 1 009 2014 Actual(empírico)
10 Entidad Pública 3 010 2015 Actual(empírico)
11 Entidad Pública 3 011 2015 Actual(empírico)
12 Entidad Privada 1 012 2015 Actual(empírico)
13 Entidad Privada 2 013 2015 Actual(empírico)
14 Entidad Pública 6 014 2016 Actual(empírico)
15 Entidad Pública 2 015 2016 Actual(empírico)
16 Entidad Pública 5 016 2016 Actual(empírico)
17 Entidad Privada 3 017 2016 Actual(empírico)
18 Entidad Privada 1 018 2017 Propuesto
19 Entidad Pública 3 019 2017 Propuesto
20 Entidad Pública 1 020 2017 Propuesto
21 Entidad Pública 4 021 2017 Propuesto
Total población (N) 21
Tabla 11 Tamaño de población
Fuente: Elaboración propia
86
Para calcular el tamaño de la muestra, la investigación se basa en el método
probabilístico del muestreo en poblaciones finitas, donde cada elemento de la población
definida tiene la misma probabilidad de ser elegida para la muestra. Se hace uso de la fórmula
para el cálculo en poblaciones finitas.
El modelo matemático usado para hallar la muestra comprende elementos de la
distribución muestral por proporciones, pues en este caso no nos interesa tener la media o
desviación estándar, sino más bien saber si la muestra tomada presentará las características
definidas para la población seleccionada. Para lo cual nos basamos en que los datos recogidos
de la población seleccionada responden a una misma característica, pues la proporción de éxito
de la muestra tomada sería de 21/21, para fines prácticos el valor de p será tomado al 98%
para obtener una muestra mínima. El nivel de confianza para esta investigación será tomado al
95%. A continuación, se detallan los datos y cálculo del tamaño de la muestra.
N: Tamaño de la población = 21
n: Tamaño de la muestra = ?
NC: Nivel de confianza = 95%
Z: Unidad estándar del nivel de confianza = 1.96
p: Probabilidad de éxito de que ocurra el suceso = 0.98
q: Probabilidad de que no ocurra el suceso = 0.02
E: Error asumido: 0.05
Entonces:
𝑛 = (𝑝 × 𝑞) × 𝑁 × 𝑍2
(𝑁 − 1) × 𝐸2 + (𝑝 × 𝑞) × 𝑍2
𝑛 = (0.98 × 0.02) × 21 × 1.962
(21 − 1) × 0.052 + (0.98 × 0.02) × 1.962
𝑛 = 12.6198014 = 13
𝑛 = 13
87
Según el modelo usado la muestra obtenida es de 13 proyectos delivery gestionados
entre los años 2012 y 2017. Este resultado puede ser poco útil para ser tomado como referencia
a la hora de validar la hipótesis nula debido a que es una muestra muy pequeña para elementos
que han sido evaluados por el mismo formato de medición de resultados. Sumado a ello, la
definición de la muestra se encuentra delimitada por contener a los proyectos que fueron
gestionados bajo el método mixto propuesto, siendo cuatro proyectos en este caso de
investigación. Para aclarar lo antes expuesto, se presenta a continuación un esquema que
explica la distribución de los proyectos delivery.
Figura 34 Presentación de población
Fuente: Elaboración propia.
El esquema presentado describe la variable “M” como los proyectos históricos ya
concluidos que fueron gestionados con el método mixto propuesto. Estos proyectos
representan el 20% del total de proyectos en el periodo del 2012 al 2017, su ejecución
correspondió al año 2017. Para tomar la decisión sobre la muestra la investigación se apoya de
la teoría sobre el muestreo no probabilístico el cual según (Parra Olivares, 2003) “una muestra
88
no probabilística corresponde a procedimientos de selección de muestras en donde intervienen
factores distintos al azar”. Para este caso, usaremos un muestreo por conveniencia debido a la
disponibilidad de tener los últimos proyectos gestionados bajo el método propuesto. Por
consecuencia, el tamaño de la muestra es de cuatro proyectos gestionados en el año 2017.
UNIDAD DE ANALISIS
Se define la unidad de análisis como los proyectos delivery concluídos y gestionados bajo el
método actual y propuesto en la empresa consultora entre los años del 2012 al 2017. La unidad
de análisis será evaluada a través de los resultados históricos de los proyectos delivery. La
información histórica sobre los resultados y los métodos usados para la gestión de cada
proyecto se encuentra archivada en la organización a disposición del investigador.
INTRUMENTOS Y TECNICAS
Para la presente investigación se realiza un análisis documental sobre los documentos
contenidos en “files” y “binder” de los proyectos delivery de la empresa consultora. Para la
recopilación de la información de interés se hace uso del “formato medición de resultados de
proyectos”, en el cual se compara lo planteado en un inicio contra los resultados alcanzados
para los objetivos, el alcance, el costo, el tiempo y la satisfacción del cliente en los proyectos.
El formato es un documento formal que debe ser completado por el jefe de proyecto con ayuda
del gestor de proyecto, y ser validado por el sponsor del proyecto.
Se menciona que el formato presentado es un diseño propuesto y usado en variación al
formato de evaluación establecido como método en la organización. La información de los
proyectos fue evaluada a través del formato propuesto. El formato fue desarrollado en la
plataforma de Microsoft Word 2013 sin embargo, puede ser adaptado o modificado en
plataformas libre como Open Office o Libre Office.
Una vez recopilada la información por cada proyecto, se pasa a realizar la agrupación
de datos en el “formato histórico de proyectos” en el cual se consolida la información respecto
a las variables estudiadas. A continuación, se muestran ambos formatos usados para la
recolección de datos.
Versión 1.0 [dd/mm/aa]
Formato de medición de resultados de proyectos
1. Al iniciar el proyecto
1.1. Nombre de proyecto: [XXXXXX]
1.2. Objetivo de proyecto esperado: [XXXXXX]
1.3. Alcance del proyecto esperado: [XXXXXX]
1.4. Presupuesto de proyecto establecido: [XXXX] indicar moneda
1.5. Plazo de entrega del proyecto: [XXXXXX] días
1.6. Satisfacción de cliente esperada: [XXXXXX]
2. Al culminar el proyecto
2.1. Nombre de proyecto: [XXXXXX]
2.2. Objetivo del proyecto alcanzado: [XXXXXX]
2.3. Alcance del proyecto alcanzado: [XXXXXX]
2.4. Presupuesto del proyecto consumido: [XXXX] indicar moneda
2.5. Plazo de entrega del proyecto: [XXXXXX] días
2.6. Satisfacción de cliente portador de producto: [XXXXXX]
Final Item 2.2 2.3 2.4 2.5 2.6
Inicio
1.2 1/0 1/0 1/0 1/0 1/0
1.3 1/0 1/0 1/0 1/0 1/0
1.4 1/0 1/0 1/0 1/0 1/0
1.5 1/0 1/0 1/0 1/0 1/0
1.6 1/0 1/0 1/0 1/0 1/0
Total x/5 x/5 x/5 x/5 x/5
La comparación del inicio vs el final se califica midiendo el resultado final frente a lo
planteado al inicio, donde se obtiene las siguientes puntuaciones según el caso:
• Puntuación positiva: 1 (Cuando se alcanzó o superó el valor inicial, cuando se
impacta positivamente sobre otro Item al final)
• Puntuación negativa: 0 (Cuando no se alcanzó el valor inicial, cuando no se impacta
sobre otro Item al final, cuando se impacta negativamente sobre otro Item al final)
Calificación de desempeño del proyecto: Suma horizontal de las puntuaciones por Item.
[1-5] Pésimo, [6-10] Malo, [11-15] Regular, [16-20] Bueno, [21-25] Muy Bueno
________________ ________________
Gerente de proyecto Oficina de proyectos
__________________
Sponsor de proyecto
Tabla 12 Formato de análisis de resultados de proyectos
Fuente: Elaboración propia
90
Porcentaje Alcance Porcentaje Tiempo Porcentaje Presupuesto
Nombre de
proyecto Año Puntaje Método
Objetivo principal
alcanzado
Cliente de producto
satisfecho
Cumple alcance
Criterio de
incumplimiento
Criterio de
favorecimiento
Cumple tiempo
establecido
Criterio de
retraso
Criterio de
adelanto
Cumple presupuesto establecido
Criterio de
sobrecosto
Diferencial de
presupuesto al
concluir el proyecto
Proyecto 1 X X/25 Actual/Propuesto
Sí/No Sí/No Sí/No Criterio / Ninguno
Criterio / Ninguno
Sí/No Criterio / Ninguno
Criterio / Ninguno
Sí/No Criterio / Ninguno
Criterio / Ninguno
Proyecto 2 Y X/25 Actual/Propuesto
Sí/No Sí/No Sí/No Criterio / Ninguno
Criterio / Ninguno
Sí/No Criterio / Ninguno
Criterio / Ninguno
Sí/No Criterio / Ninguno
Criterio / Ninguno
Proyecto 3 Z X/25 Actual/Propuesto
Sí/No Sí/No Sí/No Criterio / Ninguno
Criterio / Ninguno
Sí/No Criterio / Ninguno
Criterio / Ninguno
Sí/No Criterio / Ninguno
Criterio / Ninguno
Proyecto 4 K X/25 Actual/Propuesto
Sí/No Sí/No Sí/No Criterio / Ninguno
Criterio / Ninguno
Sí/No Criterio / Ninguno
Criterio / Ninguno
Sí/No Criterio / Ninguno
Criterio / Ninguno
Proyecto 5 L X/25 Actual/Propuesto
Sí/No Sí/No Sí/No Criterio / Ninguno
Criterio / Ninguno
Sí/No Criterio / Ninguno
Criterio / Ninguno
Sí/No Criterio / Ninguno
Criterio / Ninguno
Proyecto 6 M X/25 Actual/Propuesto
Sí/No Sí/No Sí/No Criterio / Ninguno
Criterio / Ninguno
Sí/No Criterio / Ninguno
Criterio / Ninguno
Sí/No Criterio / Ninguno
Criterio / Ninguno
Proyecto 7 N X/25 Actual/Propuesto
Sí/No Sí/No Sí/No Criterio / Ninguno
Criterio / Ninguno
Sí/No Criterio / Ninguno
Criterio / Ninguno
Sí/No Criterio / Ninguno
Criterio / Ninguno
Proyecto 8 Ñ X/25 Actual/Propuesto
Sí/No Sí/No Sí/No Criterio / Ninguno
Criterio / Ninguno
Sí/No Criterio / Ninguno
Criterio / Ninguno
Sí/No Criterio / Ninguno
Criterio / Ninguno
Tabla 13 Formato histórico de proyectos Fuente: Elaboración propia
91
Proyecto Año Calificación Método usado
Objetivo principal
alcanzado
Cliente satisfecho
Cumplimiento de alcance
Cumplimiento de tiempo
establecido
Cumplimiento de
presupuesto establecido
1 2012 15 Actual No Sí No Sí Sí
2 2012 4 Actual No No Sí No No
3 2013 5 Actual No No No No No
4 2013 10 Actual No No Sí No Sí
5 2013 20 Actual Sí Sí Sí Sí Sí
6 2014 20 Actual Sí Sí No Sí Sí
7 2014 17 Actual Sí Sí No Sí Sí
8 2014 15 Actual No Sí No Sí No
9 2014 5 Actual No No Sí No No
10 2015 25 Actual Sí Sí Sí Sí Sí
11 2015 20 Actual Sí Sí Sí No Sí
12 2015 4 Actual No No No No No
13 2015 5 Actual No No No No No
14 2016 24 Actual Sí Sí Sí Sí Sí
15 2016 25 Actual Sí Sí Sí Sí Sí
16 2016 14 Actual Sí Sí No Sí Sí
17 2016 15 Actual Sí No No Sí Sí
18 2017 25 Propuesta Sí Sí Sí Sí Sí
19 2017 25 Propuesta Sí Sí Sí Sí Sí
20 2017 25 Propuesta Sí Sí Sí Sí Sí
21 2017 25 Propuesta Sí Sí Sí Sí Sí
Tabla 14 Consolidado de resultados de proyectos históricos Fuente: Elaboración propia
Los resultados mostrados corresponden a la información consolidada con la ayuda de
la recolección individual del “formato de medición de resultados de proyectos”. Luego de
recogidos los datos se introdujeron en el “formato consolidado de resultados de proyectos
históricos”, del cual solo se tomarán los valores mas no los criterios de cada valor.
92
PROCEDIMIENTOS Y METODO DE ANALISIS
Recogidos los datos se procede a analizar la relación entre las variables independiente y
dependiente, para esto usaremos la prueba de independencia chi cuadrado para analizar la
frecuencia de las dos variables y comparar datos categóricos, con el fin de evaluar si son
independientes entre ambas. Como evaluación se propone el planteamiento de dos hipótesis.
- H0: No hay relación entre los resultados de los proyectos y el método usado.
- H1: Si hay relación entre los resultados de los proyectos y el método usado.
Se define un nivel de significancia del 5% y se dispone del software estadístico SPSS Statistic
22. A continuación se detalla el procedimiento y los resultados mostrados al realizar la prueba.
Primer paso: Recolectar de datos individuales de cada proyecto.
Segundo paso: Obtener de puntaje por cada proyecto
Tercer paso: Seleccionar un tamaño de muestra.
Cuarto paso: Introducir datos al formato consolidado.
Quinto paso: Acceder al software SPSS.
Sexto paso: En la vista de variables, definir la categoría de cada variable.
Séptimo paso: En la vista de datos, introducir los datos del formato consolidado.
Octavo paso: Seleccionar analizar, estadísticas descriptivas, tablas cruzadas.
Noveno paso: Colocar como filas a la puntuación alcanzada, esta representa el
resultado global del proyecto y la variable dependiente.
Décimo paso: Colocar como columnas al método usado, esta representa la variable
93
independiente sobre la cual se aplicará la mejora.
Onceavo paso: En casillas, seleccionar en “columnas” en porcentajes.
Doceavo paso: En estadísticos, seleccionar “Chi-cuadrado”.
Treceavo paso: Seleccionar aceptar.
A continuación, se muestra los datos entrados al software y los resultados obtenidos.
Tabla 15 Datos entrados al software SPSS
Fuente: Elaboración propia
Tabla 16 Variables entradas al software SPSS Fuente: Elaboración propia
94
RESULTADOS
Tabla 17 Resultado de análisis de tablas cruzadas Fuente: Elaboración propia
El resultado mostrado detalla la evaluación de veintiuno proyectos históricos de la empresa
consultora gestionados con el método actual empírico y el método mixto propuesto. A
continuación, se presenta la tabla de prueba del chi-cuadrado.
95
Tabla 18 Resultado de prueba chi-cuadrado en software SPSS Fuente: Elaboración propia
La tabla nos muestra el valor chi-cuadrado de Pearson por valor de 9.882 y un P-Value
de 0.042 siendo este menor que el nivel de significancia planteado de 5%. Por lo que existe
suficiente evidencia estadística para rechazar la hipótesis nula y se afirmar la hipótesis alterna
que si indica que si hay dependencia entre los resultados de los proyectos y el método usado
para gestionarlos.
96
DISCUSIONES
En comparación con la investigación de Delgado (2012), el colega aplica transversalmente
nueve de las diez áreas de conocimiento del PMBOK para los proyectos de construcción.
Explicando en sus conclusiones que el uso de su método ha contribuido con mejorar la
planificación, ejecución y control de sus proyectos.
Se puede comparar los resultados exitosos del método propuesto al adaptarse a la
empresa consultora, similar al caso práctico de la investigación de Suárez (2010), donde la
colega manifiesta que el uso del método PRINCE2 se ajusta a las necesidades de su proyecto.
El método mixto también es capaz de adaptarse a distintos entornos, ampliarse o retraerse
según la necesidad.
En comparación con la investigación de, De La Hoz Gonzales (2016), se puede apreciar
similitudes en la aplicación de un método ágil que permite que el trabajo fluya sin tantas
restricciones en el proyecto. La diferencia es que la colega solo usa SCRUM para sus
proyectos, bajo este método los equipos se auto organizan, en el método mixto propuesto el
orden y la delegación pasa por la responsabilidad del gerente del proyecto.
97
CONCLUSIONES
El uso del método mixto, compuesto por la aplicación de la guía PMBOK, el método PRINCE2
y el método SCRUM se relaciona directamente con la mejora de gestión en los proyectos. Esto
se puede demostrar con la puntuación alcanzada por los últimos cuatro proyectos en el formato
de medición de resultados. La calificación de desempeño fue “muy bueno” en el 100% de los
proyectos gestionados con el método mixto propuesto.
Se concluye también que cuando la empresa usó el método mixto se logró mejorar en
el cumplimiento de los objetivos en los proyectos aplicando la guía PMBOK, el método
PRINCE2 y el método SCRUM. Caso contrario, el 48% de los proyectos gestionados bajo el
método empírico no cumplió con los objetivos planteados.
Se concluye también que cuando la empresa usó el método mixto se logró mejorar el
impacto en el cumplimiento del alcance en los proyectos aplicando la guía PMBOK, el método
PRINCE2 y el método SCRUM. La evidencia se muestra en los últimos cuatro proyectos que
cumplieron con el alcance definido. Caso contrario, sólo el 47% de proyectos gestionados bajo
el método empírico logró cumplir con el alcance. He aquí la importancia del uso de procesos
para planificar, gestionar el alcance y controlar los cambios de los proyectos.
Se concluye también que cuando la empresa usó el método mixto se logró mejorar el
impacto en el margen de utilidad obtenido una vez culminado los proyectos aplicando la guía
PMBOK, el método PRINCE2 y el método SCRUM. La evidencia muestra que los últimos cuatro
proyectos cumplieron con el presupuesto establecido, además de generar un margen de utilidad
adicional el cual ascendió a S/. 9,440 en su totalidad. Caso contrario, en los proyectos
gestionados bajo el método empírico, donde el 36% generó sobrecostos en sus entregables e
impacto en el margen de utilidad.
Por último, se concluye que el método mixto contribuyó a mejorar el impacto en la
satisfacción del cliente una vez entregados los proyectos aplicando la guía PMBOK, el método
PRINCE2 y el método SCRUM. La evidencia se muestra en el consolidado de los proyectos
históricos donde se tuvo clientes satisfechos en los últimos cuatro proyectos. La satisfacción
del cliente se obtuvo cuando el cliente dio conformidad a los productos según los criterios de
calidad establecidos en el alcance.
98
RECOMENDACIONES
Para obtener mejor calificación en los proyectos se sugiere aplicar correctamente los procesos,
formatos y plantillas que brinda el método. Se recuerda que el método es flexible y capaz de
ser adaptado a entornos pequeños y grandes.
Para tener mayores probabilidades de lograr los objetivos, se recomienda usar el
método mixto y definir en conjunto con los interesados clave los objetivos que se alcanzarán
como resultado del proyecto. Estos objetivos deben encontrarse por escrito en lo que el método
llama “Acta de constitución del proyecto”, pues este será el documento que servirá como
constancia de que se acordó los objetivos planteados.
Para tener mayores probabilidades de cumplir con el alcance, se recomienda usar los
procesos del método mixto para definir el alcance en consenso con los interesados clave. El
documento de alcance definido y la EDT serán de vital importancia para ordenar y priorizar las
actividades. Al tener una estructura de cuáles son los paquetes de trabajo del proyecto, se
puede tener mapeado que se debe y que no se debe hacer en el proyecto.
Para tener mayores probabilidades de cumplir con el cronograma se recomienda hacer
un seguimiento exhaustivo del estado de avance del cumplimiento de las actividades. Para esto,
se puede usar el diagrama de Gantt y el Burndown Chart.
Para tener mayores probabilidades de cumplir con el presupuesto se recomienda hacer
uso del método del valor ganado y de revisar periódicamente los movimientos de flujo de caja
del proyecto, para esto se puede hacer uso de hojas de cálculo o algún tipo de software.
Para tener mayores probabilidades de satisfacer a los clientes se recomienda hacer uso
de los procesos que propone el método mixto, con la finalidad de alcanzar los entregables y
garantizar que los criterios de calidad se cumplan.
En adición a lo mencionado, se recomienda que la gestión de los proyectos bajo el
método mixto propuesto se lleve a cabo bajo la gestión de capital humano que cuente con
ciertas habilidades blandas, además de competencias formadas en liderazgo, comunicación a
todo nivel, trabajo en equipo y orientación a resultados.
99
REFERENCIAS
Amaya, Y. (2013). Metodología ágiles en el desarrollo de aplicaciones para dispositivos
móviles. Colombia.
AXELOS. (2017). Managing Successful Project with PRINCE 2. Reino Unido.
AXELOS. (2017). Managing Successful Project with PRINCE2. Reino Unido.
Ayala Cruz, J. (2016). Planificación de riesgos en proyectos para el desarrollo de nuevos
productos de alta tecnología. San Juan, Puerto Rico: University of Puerto Rico.
Beck, K. (2000). Extreme Programming explained. United States of America.
C. Paulk, M., Curtis, B., Bet Chrissis, M., & V. Weber, C. (1993). Modelo de madurez de las
capacidades. Pensilvania, Estados Unidos.
Comunidad profesional SCRUM Manager . (2016). SCRUM Manager v. 2.6.
De Jesús De la Hoz Gonzáles, W., & Méndez Chávez, M. (2016). Método Scrum aplicado al
sistema de gestión de seguridad de la información. Colombia: Politécnico
Grancolombiano .
Delgado, P. C. (2012). Metodología práctica para la gestión y administración en proyectos
de construcción para micro y pequeñas empresas. Perú: Univeridad Nacional de
Ingeniería.
Díaz Piravique, F., & Gonzales Crespo, R. (2015). Motivos de fracaso en los proyectos de
Tecnologías de Información y Comunicaciones. Colombia.
Díaz, P. (2009). Gestión del alcance del proyecto. En P. M. Organizations, Gerencia de
proyectos para organizaciones de desarrollo (págs. 3-4).
Escaida Villalobos, I., Jara Valdés, P., & Letzkus Palavecino, M. (2016). Mejora de procesos
productivos mediante Lean Manufacturing. Chile: Universidad Tecnológica
Metropolitana.
Escuder, M., Tanco, M., & Santoro, A. (2015). Experiencia de Implementación de Lean en
un Centro de Salud de Uruguay. Uruguay.
Flores-Rios, B., J. Pino, F., Ibarra-Esquer, J., Gonzáles-Navarro, F., & Rodríguez-Elías, O.
(2014). Análisis de Flujos de Conocimiento en Proyectos de Mejora de Procesos
Software bajo una perspectiva multi-enfoque. México: Revista Ibérica de Sistemas
y Tecnologías de Información.
100
ISO. (2005). ISO 9000:2005. Ginebra, Suiza.
James, P. (1997). Gestión de calidad total.
Jiménez, I. (2014). Aplicación de Metodologías Ágiles al Diseño de la UX. Puebla, México.
Lema, P., & Oña, M. (2016). Implementación de un sistema de comercialización, mediante
dispositivos móviles aplicando la metodología SCRUM, en la empresa imagen
distribuidora de NEC en Ecuador durante el periodo 2014-2015. Ecuador:
Universidad Técnica de Cotopaxi.
Macek, W. (2010). Methodologies of Project Management. Polonia.
Mañuico Mendoza, R. (2015). Modelo de gestión de control de costos, en la industria de la
construcción, bajo el enfoque PMI - PMBOK; caso presa de relave, consorcio
Stracon GyM-Montaengil, minera Chinalco,Perú. Perú: Universidad Ricardo Palma.
Meireles Moreira, A., Soares da Silva, R., & Molina Palma, M. (2010). Análise de
gerenciamento de tempo aplicado a um projeto de petróleo. Sao Paulo, Brasil:
Revista de gestión de proyectos.
Merlo Vega, S., & Ramón Borja, M. (2016). Implementación de una solución para el
manejo de ciclo de vida de aplicaciones (ALM), utilizando metodología SCRUM y
TFS como core central de la solución, para la optimitización del proceso de
desarrollo de software, en la empresa grupo Babel del Ecuador . Ecuador:
Universidad Técnica de Cotopaxi.
Nuñez, A. (04 de Febrero de 2013). ¿Por qué fracasan los proyectos? Newsletter ESAN,
pág. 1.
Parra Olivares, J. (2003). Guía de muestreo. Maracaibo, Venezuela.
Prieto Delgado, A., & Piattini Velthuis, M. (2015). Propuesta de marco de mejora continua
de gobierno TI en entidades financieras. La Mancha, España: Universidad Castilla-
La Mancha.
Project Management Institute, I. (2013). Guía del PMBOK Quinta edición. Pensilvania,
EE.UU.
SCRUMstudy™. (2016). Guía SBOOK. Arizona, Estados Unidos.
Seymour, T., & Hussein, S. (2014). The history of project management. Estados Unidos.
Shuangshuang Nie, J. G. (2015). Discrete time-cost tradeoff model for optimizing multi-
mode construction project resource allocation. Shanghai, China: Department of
Construction Management, Tongji University.
101
Soto Vicente, E. I. (2015). Aplicación de la guía del PMBOK en el desarrollo de nuevos
productos farmaceúticos en un área de investigación y desarrollo. Perú:
Universidad Nacional Mayor de San Marcos.
Suárez Medina, M. (2013). Uso de software para la gestión de proyectos hidraúlicos.
México: Instituto Mexicano de Tecnología del Agua.
Suárez, L. C. (2010). Estudio de la metodología de Gestión de Proyectos PRINCE2:
Aplicación a un caso práctico. España: Escuela técnica superior de ingeniería
informática de la Universidad de Málaga.
Tembleque Montero, R. S. (2016). Proyecto de Implantación de un Sistema de Gestión de
la Calidad ISO 9001:2015 en la Empresa Pinatar Arena Football Center S.L.
Cartagena, España: Universidad Politécnica de Cartagena.
Terukina. (2016). Sistema de gestión de fuerza de ventas web y móvil, utilizando el estilo
arquitectónico Rest, metodología Scrum y la geolocalización. Perú: Universidad
Nacional Mayor de San Marcos.
The Standish Group International. (2013). CHAOS Manifesto 2013: Think Big, Act Small.
Ticona Daza, C. (2012). Aplicación de las buenas prácticas en gestión de
proyectos(Estándar PMI) para la implementación de un programa de seguridad y
salud ocupacional OHSAS 18001:2007 en el proyecto: Mejoramiento de los
sistemas de agua potable y alcantarillado–lote 3A–Piura. Perú: Univeridad
Nacional de Ingeniería.
Vivanco Huaytara, D. (2015). Aplicación de las buenas prácticas del PMBOK a la iniciación,
planificación, ejecución, monitoreo, y cierre del proyecto caminos mineros en las
Bambas. Perú: Universidad Nacional de Ingeniería .
102
ANEXOS
103
Anexo 1: Contrato de alcance del segundo proyecto de Entidad Pública 4
Fuente: Contrato de empresa consultora
104
105
106
107
Anexo 2: Incumplimiento de alcance predefinido en contrato
Fuente: Informes de empresa consultora
108
109
110
111
Anexo 3: Contrato del cuarto proyecto de Entidad Pública 3
Fuente: Contrato de empresa consultora
112
113
Anexo 4: Incumplimiento de tiempo predefinido en contrato
Fuente: Expedientes de empresa consultora
114
Anexo 5: Incumplimiento de presupuesto por compra no planificada
Fuente: Orden de compra de empresa consultora
115
Anexo 6: Formato acta de constitución del proyecto
Fuente: Elaboración propia
116
Anexo 7: Panel general de control de herramientas informáticas
Fuente: Elaboración propia
Anexo 8: FODA - Modelo de análisis de entorno
Fuente: Elaboración propia
117
Anexo 9: Formato de registro interesados y requerimientos
Fuente: Elaboración propia
118
Anexo 10: Modelo de EDT
Fuente: Elaboración propia
119
Anexo 11: Formato registro de riesgos
Fuente: Elaboración propia
120
Anexo 12: Modelo de cronograma
Fuente: Elaboración propia
121
Anexo 13: Diagrama de gantt en software GanttProject
Fuente: Elaboración propia
122
Anexo 14: Análisis de valor ganado
Fuente: Elaboración propia
123
Anexo 15: Indicadores y curva S
Fuente: Elaboración propia
124
Anexo 16: Análisis de avance de actividades por horas
Fuente: Elaboración propia
125
Anexo 17: Burndown chart de avance de actividades
Fuente: Elaboración propia
