UNIVERSIDAD MAYOR

ESCUELA DE INGENIERÍA
EN COMPUTACIÓN E INFORMÁTICA

Propuesta de un modelo de gestión para proyectos informáticos en el

Instituto de Previsión Social

Proyecto de Titulación para Optar al Título de

Ingeniero en computación e informática

YERKO VLADIMIR MORETIC VIDAL

SANTIAGO DE CHILE

Abril - 2019

1
 UNIVERSIDAD MAYOR

ESCUELA DE INGENIERÍA
EN COMPUTACIÓN E INFORMÁTICA

Propuesta de un modelo de gestión para proyectos informáticos en el

Instituto de Previsión Social

Proyecto de Titulación para Optar al Título de

Ingeniero en computación e informática

Alumno : Yerko Vladimir Moretic Vidal.

6.865.434-3

Profesor Guía : Cristián David Barría Huidobro

SANTIAGO DE CHILE
Abril – 2019

2
 Dedicatoria

A mi madre, profesora de Estado y periodista; se emocionó mucho al

enterarse de mi decisión de estudiar, aunque no alcanzó a ver la
culminación de mi esfuerzo.

3
 Agradecimientos

A mis compañeros de la universidad que me insuflaron entusiasmo y

energía de su juventud, a mis colegas y jefes del IPS que apoyaron mi
esfuerzo, a mis profesores que fueron fuente de estímulo.

4
 Contenido
Contenido5

Índice de ilustraciones8

Índice de tablas9

Resumen10

INTRODUCCIÓN11

Metodología14

Resumen de la introducción14

Capítulo I: Planteamiento del problema15

1.1 Definición del problema15

1.2 Preguntas de investigación17

1.3 Objetivos18

1.3.1 Objetivo general18

1.3.2 Objetivos específicos18

1.4 Justificación18

1.5 Alcances19

Capítulo II: Marco teórico20

2.1 Definiciones conceptuales20

2.2 Fundamentos teóricos20

2.2.1 Planificación estratégica20

2.2.2 Gestión de proyectos21

Capítulo III: Determinación del impacto del actual modelo de gestión de proyectos
informáticos24

3.1 Proyectos seleccionados24

5
 3.1.1 Proyecto Sistema de cálculo PFP Fase II24

3.1.2 Sistema de Exención de Salud26

3.2 Problemas declarados26

3.3 Impactos identificados28

Capítulo IV: Determinación de los principales factores del modelo de gestión de proyectos
informáticos que inciden en el cumplimiento del plan director30

4.1 Identificación de los factores30

4.2 El proceso32

4.2.1 Análisis del proceso36

Capítulo V: Definición factores que ayuden a establecer un nuevo modelo de gestión de

proyectos37

5.1. Valores deseados de un modelo propuesto37

5.2. Factores a considerar en el modelo propuesto38

Capítulo VI: Propuesta de un modelo mejorado de gestión de proyectos informáticos40

6.1 Determinación de las características de un modelo propuesto40

6.1.1 Requisitos40

6.1.2 Avance periódico40

6.1.3 Alcance41

6.1.4 Actualizar estado41

6.1.5 Entrega temprana41

6.1.6 Dedicación del JP41

6.1.7 Plazo41

6.1.8 Costo42

6.2 Métodos tradicionales de gestión de proyectos42

6.3 Mejoramiento del modelo43

6
 6.3.1 Definición de los requisitos43

6.3.2 Avance periódico45

6.3.3 Alcance46

6.3.4 Actualizar estado46

6.3.5 Entrega temprana46

6.3.6 Dedicación del JP47

6.3.7 Plazos48

6.3.8 Costo48

6.4 El proceso48

6.4.1 Proceso general del proyecto50

7 Capítulo VII: Conclusiones52

7.1 De las preguntas de investigación52

7.2 De los objetivos específicos52

Bibliografía53

Anexos57

8.1 Anexo I: Procesos del proyecto - diagramas57

8.1.1 Inicio del proyecto57

8.1.2 Construcción del proyecto58

8.1.3 Transición del proyecto59

8.1.4 Proceso general60

7
 Índice de ilustraciones

Ilustración 1: Dominios donde hay deficiencias que causan error en la gestión de

proyectos16

Ilustración 2: Planificación estratégica21

Ilustración 3: Proceso SCRUM22

Ilustración 4: Proceso Agile22

Ilustración 5: Evolución del proyecto Cálculo del PFP Fase II, desde mayo de 201725

Ilustración 6: Desviación de la duración del proyecto Sistema de Cálculo PFP Fase II29

Ilustración 7: Desviación de plazos y costos del proyecto Exención de Salud29

Ilustración 8: Dominios donde existen deficiencias que causan error en la gestión de

proyectos30

Ilustración 9: Modelo de gestión de proyectos del IPS33

Ilustración 10: El proceso de determinación de los requerimientos44

Ilustración 11: Proceso de captura de requisitos45

Ilustración 12: Proceso de Definición de requerimientos49

Ilustración 13: Proceso general del proyecto (vista 1)51

Ilustración 14: Proceso general del proyecto (vista 2)51

Ilustración 10: Proceso Inicio del proyecto58

Ilustración 11: Construcción del proyecto58

Ilustración 12: Transición del proyecto59

8
 Índice de tablas

Tabla 1: Factores involucrados en la problemática17

Tabla 2: Incidencia de los proyectos en los lineamientos estratégicos y compromisos

institucionales24

Tabla 3: Objetivos y alcances de los proyectos seleccionados24

Tabla 4: Clasificación de problemas declarados durante el proyecto27

Tabla 5: Proceso de Inicio del proyecto34

Tabla 6: Proceso Construcción del proyecto34

Tabla 7: Proceso Transición del proyecto35

Tabla 8: Cuadro resumen de las dedicaciones36

Tabla 9: Propuesta de factores38

Tabla 10: El conjunto de requisitos está formado por los artefactos [23]45

9
 Resumen
El presente proyecto de título aborda la problemática planteada en la gestión de proyectos
informáticos, realizando un análisis para determinar una propuesta que satisfaga la
necesidad de resultados exitosos en los planes estratégicos y en los procesos de negocio
del Instituto de Previsión Social.

En la introducción se describe el entorno de la organización en que se realizó el estudio,

así como el devenir nacional y local de la planificación estratégica, y una aproximación a
la problemática.

El primer capítulo expone el objeto de esta investigación a través del planteamiento del
problema, cuya definición es el foco del capítulo, y va acompañado del marco general del
trabajo: objetivos que se persiguen, alcances y límites del proyecto, justificación de la
investigación, y el foco de ésta, expresado en las preguntas de investigación, que son las
que en definitiva sirven de marco de referencia a este trabajo.

El segundo capítulo presenta el marco teórico consistente en el conjunto de definiciones

conceptuales, antecedentes y el marco conceptual que constituyen los referentes que
son válidos para el correcto encuadre de esta investigación.

El tercer capítulo determina el impacto en la gestión de proyectos se plantea para medir

el efecto de un modelo de gestión de proyectos en los resultados de éstos.

En el cuarto capítulo se determinan los principales factores de la gestión de proyectos

informáticos que reflejan la problemática enunciada y e inciden en el poco oportuno
cumplimiento del plan director.

En el quinto capítulo se definen los valores deseados para elaborar una propuesta de
modelo de gestión de proyectos informáticos, los cuales configurarán un mapa que
determinará las características de la propuesta.

El sexto capítulo expondrá las características de un modelo mejorado, a partir de los

valores deseados definidos en el capítulo anterior, que subsane las deficiencias
identificadas.

El último capítulo resumirá las conclusiones respondiendo las preguntas de investigación

y exponiendo los logros con relación a los objetivos específicos.

10
 INTRODUCCIÓN
La planificación estratégica, que hoy es parte de la cultura organizacional, tuvo su origen
en la planificación militar, es decir, desde que existen conflictos armados, las fuerzas
armadas la han generado con una orientación a la organización de las fuerzas propias y
conocimiento del adversario, definiéndose en la doctrina militar como la determinación de
objetivos necesarios para alcanzar el triunfo. En el ámbito empresarial, para definir los
objetivos estratégicos se planteó la necesidad de conocer el entorno y, sobre todo,
conocer las fuerzas favorables, las industrias complementarias (aliados), y las fuerzas
contrarias, la competencia (adversario). En esta perspectiva, pensadores del mundo de
los negocios, desde Igor Ansoff [1], pasando por Michael Porter [2] y Robert Kaplan &
David P. Norton [3], han posicionado la Planificación Estratégica como una herramienta
imprescindible para la conducción empresarial en un mundo cada vez más competitivo y
más globalizado. De este modo, el diseño de una estrategia competitiva se sustenta no
sólo en el mapa de sus procesos de negocio y en la estructura organizacional, sino
también en las iniciativas estratégicas que se desarrollan a través de proyectos, entre
otros, informáticos. Entonces, la Gestión de Proyectos constituye una herramienta
esencial para llevar a cabo la Planificación Estratégica. Tal es así que, según un estudio
del Project Management Institute (PMI), las organizaciones que alinean su gestión de
proyectos a la estrategia reportan 27% más de proyectos terminados con éxito. [5] [7]

En el ámbito nacional, en el contexto del impulso de la Alianza para el Progreso para la

modernización del Estado, apoyada por la Fundación Ford1 y CIEPLAN2 [8], el gobierno

1 Fundación Ford: La Fundación Ford es una fundación caritativa, domiciliada en Nueva York, Estados Unidos,
creada para financiar programas que promuevan la democracia, reduzcan la pobreza, promuevan la cooperación
internacional y el desarrollo humano. [16]

2 CIEPLAN: La Corporación de Estudios para Latinoamérica (CIEPLAN), es una institución académica cuyo
objetivo es el estudio de las políticas públicas y la economía política, en una perspectiva comparativa en las áreas del
desarrollo y la democracia, en Chile y América Latina.

11
de Eduardo Frei M. (1964-1970) creó ODEPLAN 3 que inició un proceso de
sistematización de la gestión pública [9]. En la concepción del Estado impuesta por las
nuevas autoridades a partir del Régimen Militar en la década de los `70 primó la visión
geopolítica de las FF.AA., determinando la necesidad de una nueva institucionalidad, lo
cual se expresó en el estudio sobre la regionalización del país de la CONARA 4, el que
puso énfasis en la capacidad de planificación de las entidades públicas.[10] En la
empresa privada, la llegada de profesionales recién formados en EE.UU. y Europa, y
encuentros internacionales de estudiosos en temas de gestión, como fueron los Talleres
de Ingeniería de Sistemas del Departamento de Ingeniería Industrial de la Universidad
de Chile, renovó la concepción de gestión de empresas, incorporando los conceptos de
planificación estratégica, gestión de procesos y gestión de proyectos en el bagaje de
herramientas de apoyo a la gestión. A partir de 1990, en el marco del Consenso de
Washington [4] y del esfuerzo democratizador de las nuevas autoridades políticas, se
implementaron procesos de reforma y modernización del Estado con énfasis en la
dimensión económica y en la racionalización del aparato administrativo, donde las
directrices del proceso fueron: “liderazgo gerencial, formación de élite gerencial,
planificación estratégica, indicadores y control de gestión, convenios de desempeño,
descentralización, atención al usuario como cliente, presupuesto como instrumento
fundamental, sistemas de auditoría y la implementación de importantes técnicas
empresariales al sector público”. [9]

El Instituto de Previsión Social –en adelante IPS-, cuyo origen está en la implantación del
sistema de capitalización individual, se enfocó en la administración de la complejidad de
la información proveniente de las ex cajas de previsión y otorgamiento de los beneficios
correspondientes. La planificación estratégica fue incorporada al asumir las políticas
gubernamentales de subsidios a los sectores más vulnerables de la nación 5 , y al

3 ODEPLAN: Oficina de Planificación Nacional, precursora del actual Ministerio de Desarrollo Social.

4 CONARA: Comisión Nacional de Reforma Administrativa, instituida por la Junta de Gobierno en 1973 para la
organización territorial del país.

5 Bonos invierno, Bodas de oro, subsidio a la contratación del trabajador joven, entre otros.

12
transformarse en la palanca del Estado para la modernización de la atención de público
[11], que se expresa en el proyecto ChileAtiende6. De este modo, se ha apoyado en
consultorías expertas para definir sus programas estratégicos [12].

De acuerdo a lo anteriormente expuesto, surge la problemática presentada en el

cumplimiento de los proyectos del plan director. Siendo este un compendio de programas
que comprenden los proyectos e iniciativas de carácter estratégico y que tiene como
objetivo principal el mejoramiento significativo de las capacidades de prestación de
servicios a los usuarios, donde el área de informática constituye un componente
fundamental de la estrategia por los volúmenes y complejidad de la información
involucrada; pero los proyectos informáticos de los programas estratégicos no fueron
cumplidos en los plazos, alcances o costos inicialmente definidos 7 , lo cual ha tenido
impacto en el presupuesto, por los sobrecostos que ha debido incurrir y ha impedido que
el IPS cumpla a tiempo sus compromisos con el Estado en el marco de la modernización
institucional, y con su público objetivo en el mejoramiento de sus procesos de negocio.

De esta manera se plantea como propósito de este proyecto, mejorar el cumplimiento del
plan director abordando el factor fundamental de la razón de las demoras, esto es, a
través de la superación de las debilidades detectadas en la gestión de los proyectos
informáticos, para lo cual se deben subsanar las causas que han provocado las
deficiencias, en términos de plazos, costos y alcances, en la entrega de los productos
comprometidos.

El aporte es la propuesta de un modelo de gestión de proyectos informáticos que permita

mejorar significativamente el nivel de cumplimiento de los programas comprendidos en
el plan director, de modo de mitigar una causa fundamental que impide llevar a cabo
oportunamente los planes estratégicos del IPS que tienen como objetivos consolidar sus
capacidades que facilite al gobierno el despliegue de sus políticas de modernización del

6 ChileAtiende, instituido en la Administración 2011-2014, aprovechó los centros de atención previsional del
IPS para atender solicitudes correspondientes a varias entidades públicas, como son Servicio de Registro Civil e
Identificación, Fondo Nacional de Salud (FONASA), Ministerio de Educación, entre otras.
7 Que atañen a la División Beneficios, back office del negocio del IPS.

13
Estado, y mejorar significativamente la plataforma de atención al público y procesamiento
de las solicitudes. Estos objetivos estratégicos están alineados con la iniciativa
gubernamental de la ventanilla única el Estado, que contempla integración de procesos,
trámites en línea y procesamiento expedito de solicitudes.

Metodología
La investigación se centrará en los siguientes documentos del IPS:

• Resúmenes anuales del Plan Director

• Estados de avance mensuales de los proyectos

• Documentación anexa de los proyectos (cartas Gantt, controles de cambio,

minutas).

Resumen de la introducción
Los proyectos informáticos constituyen una piedra angular del Plan Director del IPS, y su
gestión ha adolecido de falencias que han retrasado el cumplimiento de los objetivos
estratégicos. Este trabajo busca determinar las causas y diseñar una propuesta de un
modelo de gestión de proyectos informáticos que subsane los problemas identificados.

14
 Capítulo I: Planteamiento del problema

El presente capítulo expone el objeto de esta investigación a través del planteamiento del
problema, cuya definición es el foco del capítulo, y va acompañado del marco general del
trabajo: objetivos que se persiguen, alcances y límites del proyecto, justificación de la
investigación, y el foco de ésta, expresado en las preguntas de investigación, que son las
que en definitiva sirven de marco de referencia a este trabajo.

1.1 Definición del problema

Los lineamientos y objetivos estratégicos del IPS se definieron en su Planificación

Estratégica condensándose en su Plan Director 2016, que contemplaba dieciséis
programas con veintitrés proyectos del ámbito de la informática, principalmente de
desarrollo de software para la automatización de procesos y la incorporación de
actualizaciones en las normativas que rigen la actuación de la institución. [13] Tres de los
dieciséis programas, que comprenden ocho proyectos informáticos, corresponden a
mejoramientos y automatizaciones de procesos en la División Beneficios, el back office u
operaciones del IPS.

Todos aquellos proyectos sufrieron cambios en sus plazos, presupuestos y/o alcances,
retrasando el cumplimiento del plan estratégico del Instituto para su modernización e
incurriendo en sobrecostos en la ejecución presupuestaria. Lo primero ha incidido en una
imagen negativa del IPS ante sus usuarios, en su mayoría perteneciente a los sectores
más vulnerables de la población, al no poder satisfacer sus expectativas en lo que
respecta a la claridad, oportunidad y eficacia en la tramitación de sus solicitudes.
Asimismo, no se ha dado cumplimiento a los indicadores del IPS ante los organismos
supervisores, como son: Dirección de Presupuesto, Subsecretaría de Previsión Social,
Superintendencia de Pensiones, entre otros, lo que ha dificultado la contribución a la
política de modernización del Estado que impulsa el Ejecutivo, en el sentido de constituir
la ventanilla única del Estado, ChileAtiende.

De esta manera, análisis ex post muestran que los programas estaban alineados con la
estrategia corporativa, que los proyectos eran viables y, en general, estaban dadas las
condiciones para alcanzar las metas trazadas. Sin embargo, las reformulaciones de los

15
proyectos han retrasado el cumplimiento de los objetivos en la oportunidad comprometida.
Dentro de las causas detectadas a priori, están el modelo de gestión de proyectos
informáticos, la contratación de personal para los equipos de proyecto bajo la modalidad
horas / hombre en vez de experticia y un persistente cuello de botella en el Aseguramiento
de Calidad (QA), según se presenta en la ilustración 1.

Modelo de gestión de proyectos

Proceso del proyecto

Rol y responsabilidad de PMO

Soporte tecnológico

PROBLEMÁTICA
Adquisición de RRHH del proyecto Incumplimiento en:
• Plazos
Modalidad de contratación
• Costos
Asignación de responsabilidades • Alcances
en proyectos estratégicos y,
por ende, en Plan Director
Aseguramiento de calidad
Desconocimiento del negocio

Capacidad instalada insuficiente

Ilustración 1: Dominios donde hay deficiencias que causan error en la gestión de proyectos

En lo que respecta al modelo de gestión de proyectos informáticos, el problema radicaría

en:

• el proceso del proyecto: gran cantidad de formalismos que debe cumplimentar

el Jefe de Proyecto y baja participación del cliente en la etapa de ejecución del
proyecto;
• el débil rol de las oficinas de gestión de proyectos (PMO): carente preparación
de las condiciones del proyecto (ingeniería de requerimientos, principalmente) y la
facilitación de la labor del jefe de proyecto (supervisión del equipo de proyecto,
generación de reportes);
• el deficiente soporte tecnológico: la actualización de estados de avance la debe
realizar el jefe de proyecto, y la herramienta no apoya la generación de reportes
de avance.

En el caso de la adquisición de trabajadores para el equipo de proyecto bajo la modalidad

16
de contratación de horas / hombre hace recaer la responsabilidad en el éxito de los
proyectos y en la gestión de los riesgos en la propia institución, sin tener el recurso de
acuerdos de niveles de servicio (SLA) para asegurar la correcta ejecución de los
proyectos.

Finalmente, apoyarse en una unidad interna de QA ha ocasionado retrasos de meses en

la puesta en producción de los sistemas desarrollados en los proyectos, debido
principalmente a desconocimiento del negocio y a la inapropiada documentación. En
relación al primer problema, el IPS carece de un óptimo en la gestión de procesos como
tal, por ende, hay un conocimiento débil de los procesos de negocio y de las reglas de
negocio que los rigen. Por el lado de la documentación, los casos de prueba son
insuficientes en calidad y cantidad, lo que obliga al cliente a realizar pruebas exhaustivas
de los productos entregados. La tabla 1 resume lo anteriormente expuesto.

Tabla 1: Factores involucrados en la problemática

Factor Descripción

Modelo de gestión de proyectos

Proceso del proyecto Muchos formularios para el JP, poca participación del cliente en
ejecución

Rol de PMO Poco proactivo, débil apoyo al JP

Soporte tecnológico No favorece al equipo de proyecto, no genera reportes

Adquisición de RRHH para el proyecto

Modalidad de contratación Basada en horas/hombre en vez de resultados / experticia

Roles y responsabilidades IPS debe asumir la responsabilidad por los resultados y por los riesgos

Aseguramiento de calidad

Desconocimiento del negocio No hay apoyo de un modelo de proceso del negocio, mucha rotación

Insuficiente capacidad No hay externalización, la unidad de QA no da abasto

instalada

1.2 Preguntas de investigación

Para llevar adelante esta investigación y definir su foco, se plantean las siguientes

17
preguntas de investigación:
● ¿Cuáles son los factores de los proyectos informáticos que han determinado los
retrasos en sus cumplimientos?
● ¿Es determinante la selección de una metodología de gestión de proyectos
informáticos en los cumplimientos de estos?

1.3 Objetivos

A continuación se plantean los objetivos de la presente investigación.

1.3.1 Objetivo general

Definir una propuesta para el modelo de gestión de proyectos informáticos que permita
incrementar el nivel de cumplimiento de los planes directores.

1.3.2 Objetivos específicos

● Determinar el impacto del actual modelo de gestión de proyectos informáticos
● Determinar los principales factores del modelo de gestión de proyectos
informáticos que inciden en el cumplimiento del plan director
● Definir factores que ayuden a establecer un nuevo modelo de gestión de
proyectos
● Proponer un modelo mejorado de gestión de proyectos informáticos.

1.4 Justificación

El cumplimiento del Plan Director y la necesidad de sistemas informáticos que apoyen

eficiente y eficazmente los procesos de negocio, y la constante actualización de las
normativas que los rigen, demandan un modelo de gestión de proyectos informáticos para
cumplir con las metas trazadas en la planificación estratégica dentro del marco de los
compromisos con el público objetivo y con los organismos supervisores.

Bajo el texto “gestión de proyectos informáticos chile” Google muestra cerca de dos
millones de entradas. En Estados Unidos de América, informe Chaos (Standish group)
del año 2015, revela que, de 50.000 proyectos de todo tamaño, sólo un 29% se consideró
exitoso (cumplir con alcance, presupuesto y plazo), un 52% con resultados discutibles, y
un 19% definitivamente fracasados.

18
En general, la tasa de éxito en los proyectos informáticos es relativamente baja; los
proyectos se terminan, pero con extensiones de plazos y presupuestos, y reducciones de
alcance. El caso del Plan Director 2016 del IPS es un claro ejemplo de esta ausencia de
éxito.

La principal causa en la falta de éxito es la gestión del proyecto en todas sus fases:
definición precaria de requerimientos sin suficiente comprensión del proceso de negocio
involucrado, la inadecuada adquisición de RR.HH. como se ha expuesto, un rol deficiente
de las PMO, bajo nivel de participación del cliente en el ciclo de desarrollo, atrasos en la
actualización de la documentación del proyecto (carta Gantt, control de cambios), entre
otros.

Lo anteriormente expuesto determina la necesidad de un modelo de gestión de proyectos

informáticos que los equipos de proyecto perciban como una efectiva ayuda a su labor.
Bajo este concepto se comprende la definición del rol de las PMO de modo tal que
absorba algunas labores relativas a la necesidad de registro y control que realizan los
jefes de proyecto; un modelo que se apoye en una herramienta tecnológica que facilite la
actualización de los estados de avance al equipo de proyecto y que genere indicadores
para la elaboración de los estados de avance.

Resolviendo este aspecto de la gestión, se pretende mitigar una traba en la ejecución de

los planes directores.

1.5 Alcances

Son varios los factores que inciden en el cumplimiento de las estrategias empresariales:
Planificación Estratégica, Gestión de Procesos, Gestión de Proyectos.

La presente investigación considerará las variables que inciden directamente en la

gestión de proyectos informáticos, específicamente en el proceso del proyecto.

Otros aspectos, como son QA o gestión de riesgos quedan fuera del alcance propuesto.

En lo que respecta a los proyectos a analizar, el presente trabajo se centrará en aquellos

que, relacionados con los procesos de negocio administrados por la División Beneficios,
organización que funciona como el back office del IPS.

19
 Capítulo II: Marco teórico

El marco teórico presenta el conjunto de definiciones conceptuales, antecedentes y el

marco conceptual que constituyen los referentes que son válidos para el correcto
encuadre de esta investigación.

2.1 Definiciones conceptuales

• Planificación estratégica: “proceso sistemático de desarrollo e implementación

de planes para alcanzar objetivos” [6]. Originada en la planeación militar, fue
llevada al dominio de los negocios, los cuales fueron vistos como fuerzas militares
a conducir, para así analizar las fortalezas y debilidades propias y de la
competencia, definir objetivos estratégicos y plantearse planes para el logro de
aquellos.

• Gestión de proyectos: “es la disciplina del planeamiento, la organización, la motivación,

y el control de los recursos con el propósito de alcanzar uno o varios objetivos ”, donde un
proyecto es un emprendimiento temporal diseñado a producir un único producto,
servicio o resultado, con un principio y final definidos, limitado en tiempo,
presupuesto y alcance. Sus precursores fueron Henry Gantt y Henri Fayol . [31]

• Plan director: instrumento definido por organizaciones para cumplir con sus
objetivos, lineamientos estratégicos y políticas que deberá orientar y alinear las
acciones de mediano plazo. Parten con un diagnóstico de la situación actual y
definen grandes metas a ser alcanzadas. Se basan en intervenciones a través de
programas que comprenden proyectos e iniciativas estratégicos. [15]

2.2 Fundamentos teóricos

2.2.1 Planificación estratégica

La planificación estratégica, a partir de declaraciones fundamentales, análisis de las

condiciones de desenvolvimiento y establecimiento de la meta, determina los objetivos
estratégicos y define los medios para alcanzarlos, que se traducen en iniciativas
estratégicas, las cuales se materializan orientando la formulación de programas y

20
proyectos, de acuerdo con la ilustración 2.

Ilustración 2: Planificación estratégica

2.2.2 Gestión de proyectos

La Gestión de proyectos pasa a ser entonces instrumento fundamental para la concreción

de los programas y proyectos estratégicos, posibilitando así el cumplimiento de los planes
estratégicos.

En la perspectiva de los proyectos informáticos, cobra relevancia tanto el proceso del

proyecto como el proceso del software. Si bien en los años 50 se incorporaron nuevas técnicas
de apoyo a la gestión de proyectos, Program Evaluation and Review Techniques (PERT) y Critical
Path Method (CPM), las cuales se basan en modelos matemáticos, el problema de los procesos
involucrados no ha sido satisfactoriamente resuelto, como en los casos de proyectos más complejos,
donde las variables no están totalmente controladas. Cuando hay factores externos que son críticos,
por ejemplo, el modelo revela sus debilidades, las que se reflejan en los resultados. Ocurre lo mismo
con proyectos en los que los requerimientos no están claramente formulados, en los que el usuario
va definiendo los requisitos en el transcurso de la ejecución del proyecto.

21
En los casos de requerimientos insuficientemente definidos, ha tenido bastante éxito la
aplicación de metodologías ágiles, que ha ofrecido marcos de trabajo de gran difusión y
uso, como son SCRUM, Crystal Method y Extreme Programming. [14] En las ilustraciones
3 y 4 se presentan los procesos de dos metodologías ágiles, donde se puede apreciar su
convergencia.

Ilustración 3: Proceso SCRUM

Ilustración 4: Proceso Agile

22
Cuando los requerimientos están suficientemente definidos8, y el modelo de dominio es
relativamente estable9, las metodologías tradicionales han demostrado un alto nivel de
eficacia.

En este campo, el IPS desde los inicios optó por las mejores prácticas del Project
Management Institute (PMI) expresadas en la guía PMBOK [22], combinadas con el
modelo Rational Unified Process (RUP) como proceso del software y SCRUM para
incorporar algunas características del modelo ágil de gestión de proyectos.
Recientemente esa orientación fue reforzada al adoptar el Modelo Operacional Objetivo
de Everis, basado en PMI10.

8 Es decir, cuando la probabilidad de cambios en los requisitos críticos es muy baja.

9 Modelo de dominio: estructura organizacional, entorno de la industria, proceso de negocio.
10 Actualmente se está preparando la licitación para la incorporación de la suite MS Project Online
como herramienta de soporte a la gestión de proyectos.

23
Capítulo III: Determinación del impacto del actual modelo de gestión de
proyectos informáticos

La determinación de impacto en la gestión de proyectos se plantea para medir el efecto

de un modelo de gestión de proyectos en los resultados de éstos.

En el caso del IPS, está definida la incidencia de los proyectos en los lineamientos
estratégicos, como se ve en la tabla 2, pero no el grado de incidencia, por lo que no hay
valores para comparar el efecto de las desviaciones de los proyectos en los objetivos
estratégicos.

El efecto de un modelo de gestión de proyectos informáticos se puede medir en términos

de plazos, costos y alcances, sobre todo cuando son impactos que afectan a todos los
proyectos que atañen a la División Beneficios. Como muestra, se consideraron dos
proyectos del programa Mejora del Sistema de Reforma Previsional, Sistema de Cálculo
PFP Fase II y Sistema Exención de Salud, cuyas definiciones se presentan en la tabla 3.
Tabla 2: Incidencia de los proyectos en los lineamientos estratégicos y compromisos institucionales

3.1 Proyectos seleccionados

Tabla 3: Objetivos y alcances de los proyectos seleccionados

ID Proyecto Objetivo Alcance

Crear una nueva plataforma para el cálculo del
Puntaje de Focalización Previsional (PFP), que
permita ser manejado por personas no técnicas,
entregando una retroalimentación efectiva para el
9.2 Sistema de cálculo PFP Fase II
monitoreo de la ejecución de cada proceso de
cálculo. La plataforma debe permitir la administración
de variables importantes como variables de fórmulas
e instituciones consultadas.
Implementar una aplicación que permita bonificar las
pensiones que cumplen los criterios de la ley 20.531
9.3 Sistema de Exención de Salud para la exención parcial de la salud, de acuerdo a la
especificación de dicha ley y de los requerimientos
entregados por la División de Beneficios.
Nueva plataforma de cálculo del PFP,
utilizable por personas no técnicas y
parametrizable, que aborda las principales
observaciones realizadas por la
Superintendencia de Pensiones al actual
procedimiento de cálculo del PFP.
Desarrollar una aplicación que incorpore
todas las reglas del negocio y
funcionalidades que den soporte del proceso
de Exención de Salud.

3.1.1 Proyecto Sistema de cálculo PFP Fase II

El Puntaje de Focalización Previsional, PFP, es un indicador de vulnerabilidad socio

económica de los grupos familiares que la Ley establece como requisito para acceder a

24
beneficios que otorga el Estado, como son Pensión Básica Solidaria (PBS), Aporte
Previsional Solidario (APS), entre otros. Desde que se promulgó el reglamento en el año
2010, la División Beneficios realizaba el cálculo en forma administrativa, con
procedimientos semi automatizados. En el año 2015 se hizo el diseño para un sistema
informático, comenzando su desarrollo a principios del año 2016.

Las principales variables del proyecto fueron las siguientes:

• Fecha de inicio del proyecto: 24/02/2016

• Fecha de término del proyecto: 30/06/2016

• En agosto de 2016 se reformuló el proyecto, fijándose la fecha de término el

30/06/2017.

• En agosto de 2017 se cambió la fecha de término a 31/12/2017.

• En definitiva, el proyecto fue cerrado el 30/06/2018.

En el siguiente gráfico se muestra la evolución del proyecto desde mayo de 2017.

Evolución del proyecto Cálculo PFP Fase II

101%
100%
99%
98%
97%
96%
95%
94%
93%
92%
91%

planificado real

Ilustración 5: Evolución del proyecto Cálculo del PFP Fase II, desde mayo de 2017

En resumen, el proyecto cuya duración inicial se estimó en 92 días hábiles, se alargó a

614 días hábiles, un 567% respecto de la planificación original.

El presupuesto fijado no varió.

25
3.1.2 Sistema de Exención de Salud

La llamada Exención de Salud consiste en una bonificación que otorga el Estado a los
adultos mayores para cubrir, gradualmente hasta el 100%, la cotización obligatoria al
seguro de salud11.

Al igual que en el caso del Cálculo del PFP, la División Beneficios implementó el proceso
en forma administrativa, con apoyo de procedimientos semiautomáticos, en espera del
desarrollo de un sistema por parte de la División Informática.

Las principales variables del proyecto son las siguientes:

• Fecha de inicio del proyecto: 24/11/2014

• Fecha de término inicial: 31/08/2016

• Segunda fecha de término: 30/06/2017

• Tercera fecha de término: 31/12/2018

• Último avance planificado: 97% (al 30/11/2018)

• Último avance real: 74% (al 30/11/2018)

• Presupuesto inicial: m$ 75.000

• Presupuesto reformulado: m$ 106.500.

Este proyecto trabajó con un equipo de proyecto conformado por personal externo
contratado bajo la modalidad horas/hombre, con un Jefe de Proyecto que funge de JP y
de analista de sistemas.
A esta fecha el sistema está en fase de pruebas, por lo que se estima probable que la
fecha de término del proyecto se aproxime bastante a la tercera fecha de término.

3.2 Problemas declarados

Los problemas declarados durante la ejecución del proyecto son principalmente de tres
tipos:

11 La cotización corresponde al 7% de los ingresos. La implementación de esta bonificación partió

cubriendo hasta el 5%, para finalmente cubrir completamente el 7%.

26
 • Técnicos: Principalmente, fallos en algunos servicios por causas no informadas.

• Externos: Causas no atribuibles al equipo de proyecto.

• Del proceso: Causas atribuibles al equipo de proyecto, a la coordinación o a la

PMO. En ambos proyectos hay problemas de definición de requerimientos.

La tabla 4 expone los problemas declarados en los avances; se agruparon en Problemas

técnicos, Factores externos y Problemas del proceso (incluidos problemas de requisitos).
La columna meses indica las veces que el problema fue declarado.
Tabla 4: Clasificación de problemas declarados durante el proyecto

# problema veces declarado

Proyecto Cálculo PFP Fase II

Problemas técnicos

1 Sistema en ciertos momentos deja de leer FTP 5

2 Falla en el pool de conexiones de la aplicación a la BD 6

3 Falla enlace entre bases de datos 3

Factores externos

4 Retraso por cambio de parámetros 1

Problemas del proceso

5 Retraso en la disponibilidad de información 1

6 JP asignado a otras actividades 1

7 Datos inconsistentes 2

8 Reglas de negocio no implementadas 2

9 Conocimientos del nuevo sistema en un solo profesional 3

Proyecto Exención de Salud

Problemas técnicos

1 Retraso por complicaciones técnicas en despliegue de la solución 2

2 Fallas en VPN afecta desarrollo 3

3 Falla en servidor FTP afecta desarrollo 1

4 Problemas técnicos retrasan autorizaciones FireWork para pruebas 1

5 Problemas de acceso a FTP y WebLogic 1

Factores externos

6 Cambios en servidores sin previo aviso retrasan pruebas 2

27
 # problema veces declarado
7 Restricciones técnicas a solicitudes para desarrollo 2

8 Rechazado WS por estar fuera de recomendaciones 1

9 Restricciones técnicas a herramientas de integración 1

10 Restricciones para la creación de ambiente de emulación 1

11 Cambios en políticas informáticas prohiben componentes usados en desarrollo 1

12 Termina contrato con empresa desarrolladora 1

Problemas del proceso

Problemas del proceso

13 Demora en tramitación de creación de DBLink 1

14 Demora en validar planificación 3

15 Suspensión del proyecto por 3 meses obliga a revisión detallada 1

16 Tiempos mayores para adaptar salida a enero 2008 1

17 Retraso en actualización de BD para pruebas 2

18 Complicaciones técnicas asociadas a tamaño de archivo 1

19 Negocio realiza requerimiento de exclusiones 1

20 Optimizaciones técnicas para ODI no contempladas en diseño 5

21 Resultados de prueba no concuerdan con resultados reales 3

22 Falla de pruebas por errores de datos (código inexistente) 1

3.3 Impactos identificados

La ilustración 6 grafica la desviación en días hábiles del proyecto Cálculo PFP Fase II.

La ilustración 7 gráfica las desviaciones, de duración (en semanas) y de presupuesto (en

millones de pesos), del proyecto Exención de Salud.

28
 Duración del proyecto (días hábiles)
700

600

500

400

300

200

100

0
Planificado Real

Ilustración 6: Desviación de la duración del proyecto Sistema de Cálculo PFP Fase II

Desviación Sistema Exención de Salud

350
300
250
200
150
100
50
0
Primera planificación Segunda Tercera planificación
planificación

duración (semanas) presupuesto (mm$)

Ilustración 7: Desviación de plazos y costos del proyecto Exención de Salud

29
Capítulo IV: Determinación de los principales factores del modelo de
gestión de proyectos informáticos que inciden en el cumplimiento del
plan director

En este capítulo se determinan los principales factores de la gestión de proyectos

informáticos que reflejan la problemática enunciada y e inciden en el poco oportuno
cumplimiento del plan director.

4.1 Identificación de los factores

En el Capítulo I se identificaron las áreas, representados en la ilustración 8, donde existen

situaciones que podrían estar ocasionando los problemas cumplimiento de los proyectos
y, por ende, del plan director. Hay situaciones que pudieran determinar las razones de
aquellos: la demanda de control y registro de las actuaciones en los organismos públicos,
los supuestos sobre capacidades, propias en gestión y externas en desarrollo, de los
integrantes del equipo de proyecto, y cierto nivel significativo de rotación en la unidad de
QA que incide en el conocimiento del negocio, agravado por la carencia de modelos de
proceso del negocio.

Modelo de gestión de proyectos

Proceso del proyecto

Rol y responsabilidad de PMO

Soporte tecnológico

PROBLEMÁTICA
Adquisición de RRHH del proyecto Incumplimiento en:
• Plazos
Modalidad de contratación
• Costos
Asignación de responsabilidades • Alcances
en proyectos estratégicos y,
por ende, en Plan Director
Aseguramiento de calidad
Desconocimiento del negocio

Capacidad instalada insuficiente

Ilustración 8: Dominios donde existen deficiencias que causan error en la gestión de proyectos

● Modelo de gestión de proyectos informáticos: proceso del proyecto, PMO y

soporte tecnológico.

30
 El proceso del proyecto es el tradicional de cuatro fases (Inicio, Planificación,
Ejecución y control, Cierre), basado en el PMBOK, con MS-Project (stand alone)
como herramienta de gestión, y alrededor de sesenta formularios y plantillas que
debe manejar el jefe de proyecto (JP). La elección de la herramienta de gestión
tiene impacto en la actualización de los estados de los proyectos, pues el JP debe
recopilar la información provista por su equipo de proyecto, actualizar la carta
Gantt y elaborar el informe de estado de avance.
En lo que respecta a las PMO, existe una PMO institucional que centraliza y
resume la información, las PMO divisionales que representan los negocios, y
varias PMO de la División Informática. El rol de estas últimas ha sido de velar por
el cumplimiento de los proyectos, sin que se pueda apreciar un efectivo apoyo a
la labor de los JP ni apoyo al negocio en la etapa de definición de los
requerimientos.
El proceso del software es RUP12 (iterativo e incremental), donde el cliente, una
vez formalizado el proyecto, recibe información periódica de los estados de avance
e incidencias, sin ulterior participación efectiva en el desarrollo del proyecto.
● Adquisición de equipo: modalidad de contratación de trabajadores basada en
horas / hombre, en vez de basarse en resultados o experticia.
Para completar las dotaciones de los equipos de proyecto, la División Informática
contrata profesionales del área con el criterio de disponibilidad de horas / hombre
para su asignación a las distintas actividades del proyecto por parte del JP. Esta
modalidad implica que el JP asume la responsabilidad final por los resultados del
proyecto, e internaliza los riesgos que, por tanto, él debe gestionar. Se pierden así
las ventajas de la contratación por resultados garantizados mediante SLA, y
externalización de los riesgos.
● Retrasos en puesta en producción por cuello de botella en QA.

La División Informática tiene una unidad de QA, responsable del aseguramiento

de la calidad de los productos para su puesta en producción. Esta unidad tiene

12 RUP: Rational Unified Process, proceso de desarrollo de software que, junto al Unified Modeling
Language (UML), constituye una metodología estándar para el desarrollo orientado a objetos.

31
 una alta demanda que no ha sido capaz de satisfacer oportunamente,
ocasionando que los proyectos se retrasen varios meses por la espera de la
liberación de sus productos y poder cerrar los proyectos.

Por otra parte, en el capítulo anterior se identificaron los principales problemas que
afectaron a los proyectos estudiados, de donde se desprenden los siguientes factores a
abordar:

Definición de requerimientos: ambos proyectos adolecieron de debilidad en la definición

de los requerimientos.

Desconocimiento del negocio: ambos proyectos fueron abordados en la perspectiva de

los algoritmos, sin tener en cuenta el proceso de negocio afectado.

Involucramiento del cliente: salvo en las reuniones mensuales, el cliente no está

involucrando activamente en el proyecto, ni se entera de las incidencias cotidianas.

Fragmentación del proyecto: ambos proyectos se propusieron resolver y entregar un todo,

aun cuando había posibilidad de fragmentarlos.

Dedicación del Jefe de Proyecto: en ambos proyectos el JP dedicó parte importante de

su esfuerzo a tareas administrativas, lo que comunmente se conoce como secretaría
técnica.

Elaboración de informes: parte de las labores del JP fue la elaboración de informes de

avance, en forma manual. La plataforma tecnológica no daba facilidades al respecto.

4.2 El proceso

Ponerse del lado del cliente para evaluar si una actividad crea valor es una
prueba crítica de valor de cualquier actividad. El cliente paga por las cosas
que cree que tienen valor. Esto es muy diferente a pensar que él compra las
cosas que nosotros pensamos que son valiosas. (Lledó et.al. 2006)

A continuación, se describen el proceso del proyecto y sus actividades, algunas de cuyas

actividades (tareas y actores) estarían incidiendo en las causas de la problemática.

El modelo general de la gestión de proyectos informáticos del IPS se presenta en la

ilustración 9.

32
 Ilustración 9: Modelo de gestión de proyectos del IPS

El modelo general más detallado se presenta en el anexo 7.1.4.

Las actividades13 de los subprocesos, así como los responsables o actores, se listan en
las siguientes tablas. Para clasificar las actividades se recurrió a la tipología Lean [28],
que se definen en base a la disposición del cliente a pagar por ella; es decir, cuánto valor
aporta al proyecto:

• Agrega valor: actividad con valor agregado, necesaria para producir resultado-

• Desperdicio tipo 1: actividad parcialmente sin valor agregado, pero necesaria para
completar las tareas. Solo agrega costos al proyecto

• Desperdicio tipo 2: actividad que carece de valor agregado.

Se agregó la clasificación secretaría técnica, que comprende actividades de apoyo al

proceso.

13 Los modelos no contienen descripciones de las actividades; cuando los nombres de aquellas no
son claros, se consignan entre comillas.

33
Tabla 5: Proceso de Inicio del proyecto

# actividad actor clasificación secretaría técnica

1 Entregar documentación inicial Jefe de proyecto Desperdicio tipo 1 Sí

2 Crear repositorio del proyecto Jefe de proyecto Desperdicio tipo 1 Sí

3 Elaborar requerimiento infraestructura Analista desarrollador Agrega valor

4 Elaborar especificación requerimientos Analista funcional Agrega valor

5 Enviar requerimiento infraestructura Analista desarrollador Desperdicio tipo 2 Sí

6 Notificar validación del documento Jefe de proyecto Desperdicio tipo 2 Sí

7 Solicitar ambientes Jefe de proyecto Desperdicio tipo 1 Sí

8 Elaborar casos de uso Analista funcional Agrega valor

9 Elaborar diccionario de datos Analista desarrollador Agrega valor

10 Enviar diccionario de datos Jefe de proyecto Desperdicio tipo 2 Sí

11 Presentación al usuario Jefe de proyecto Desperdicio tipo 1 Sí

12 Realizar reunión de presentación Jefe de proyecto Agrega valor

13 Enviar minuta Jefe de proyecto Desperdicio tipo 2 Sí

14 Desarrollar chk.docs. DyM Jefe de proyecto Desperdicio tipo 1 Sí

15 Subir documentación Jefe de proyecto Desperdicio tipo 2 Sí

16 Realizar reunión semanal Jefe de proyecto Desperdicio tipo 1

Tabla 6: Proceso Construcción del proyecto

# actividad actor clasificación secretaría técnica

1 Solicitar ficha de proyecto (a QA) Jefe de proyecto Desperdicio tipo 2 Sí

2 “Gestionar C. Macrogantt” (a QA) Jefe de proyecto Desperdicio tipo 1 Sí

3 “Solicitar C. Pauta de pruebas” (a QA) Jefe de proyecto Desperdicio tipo 2 Sí

4 “Enviar P. ficha seguridad” Jefe de proyecto Desperdicio tipo 2 Sí

5 Solicitar paso a QA Jefe de proyecto Desperdicio tipo 1 Sí

6 Enviar C. informe de incidencias Jefe de proyecto Desperdicio tipo 1 Sí

7 Presentar avance al usuario Jefe de proyecto Agrega valor

34
 # actividad actor clasificación secretaría técnica

8 Elaborar y enviar minuta reunión Jefe de proyecto Desperdicio tipo 2 Sí

9 Subir documentación Jefe de proyecto Desperdicio tipo 2 Sí

10 Elaborar Def. de arquitectura Analista desarrollador Agrega valor

11 Elaborar diccionario de datos Analista desarrollador Agrega valor

12 Desarrollar prototipo funcional Analista desarrollador Agrega valor

13 “Desarrollar P. Ev. pruebas unit.” Analista desarrollador Agrega valor

14 Disponibilizar software Analista desarrollador Agrega valor

15 Realizar corrección de errores Jefe de proyecto Agrega valor

16 Elaborar especificación requerimientos Analista funcional Agrega valor

17 Elaborar casos de uso Analista funcional Agrega valor

18 Confeccionar manual de usuario Analista funcional Agrega valor

19 Confeccionar manual de sistema Analista funcional Agrega valor

20 Confeccionar manual de operación Analista funcional Agrega valor

Tabla 7: Proceso Transición del proyecto

# actividad actor clasificación secretaría técnica

1 Solicitar paso a producción Jefe de proyecto Desperdicio tipo 1 Sí

2 Solicitar revisión de seguridad Jefe de proyecto Desperdicio tipo 1 Sí

3 Enviar informe incidencias seguridad Jefe de proyecto Desperdicio tipo 1 Sí

4 Resolver incidencias Jefe de proyecto Agrega valor

5 Presentar Avance al usuario Jefe de proyecto Agrega valor

6 Elaborar y enviar minuta reunión Jefe de proyecto Desperdicio tipo 2 Sí

7 Subir documentación Jefe de proyecto Desperdicio tipo 2 Sí

8 Empaquetar componente Lógica App Analista desarrollador Agrega valor

9 Empaquetar componentes Acceso a BD Analista desarrollador Agrega valor

10 Empaquetar componente Interfaz Grf. Analista desarrollador Agrega valor

35
 # actividad actor clasificación secretaría técnica

11 Cerrar Manual de sistema Analista desarrollador Desperdicio tipo 1

12 Cerrar especificación requerimientos Analista funcional Desperdicio tipo 1

13 Cerrar casos de uso Analista funcional Desperdicio tipo 1

14 Cerrar Manual de operación Analista funcional Desperdicio tipo 1

15 Cerrar Manual de usuario Analista funcional Desperdicio tipo 1

En la tabla 5 siguiente se expone un cuadro resumen, que comprende los tres

subprocesos presentados.
Tabla 8: Cuadro resumen de las dedicaciones

Agrega valor Desperdicio tipo 1 Desperdicio tipo 2 Secretaría técnica

Jefe de proyecto 5 9,8% 12 23,5% 11 21,6% 22 43,1%

Analista desarrollador 10 19,6% 1 2,0% 1 2,0% 1 2,0%

Analista funcional 7 13,7% 4 7,8% 0 0 0

total 43,1% 33,3% 23,5% 45,1%

4.2.1 Análisis del proceso

En la perspectiva Lean, el 76% de las actividades que realiza el equipo de proyecto

agrega poco o ningún valor al proyecto.

De las actividades de secretaría técnica, esto es: tareas de apoyo, registro y transmisión
de información, el 95,6% las realiza el Jefe de proyecto. A su vez, el aporte de éste
representa tan solo el 10% del total de valor agregado. Aun en el caso que cada una de
esas actividades ocupara poco tiempo, el total de ellas le significa al Jefe de proyecto un
importante esfuerzo y una significativa dedicación, todo lo cual se resta de su misión:
liderar el equipo de desarrollo para llevar a cabo el proyecto de forma exitosa.

36
 Capítulo V: Definición factores que ayuden a establecer un nuevo
modelo de gestión de proyectos

En este capítulo se definen los valores deseados para elaborar una propuesta de modelo
de gestión de proyectos informáticos, los cuales configurarán un mapa que determinará
las características de la propuesta.

5.1. Valores deseados de un modelo propuesto

En el capítulo III se expuso que la métrica basada en el triángulo PMI, esto es, plazo –
costo – alcance, en el contexto del modelo de gestión de proyectos informáticos, no ayudó
al desempeño de los proyectos del Plan Director. Las variables no dan cuenta de los
siguientes factores que, en otras metodologías, han demostrado ser efectivo apoyo a los
resultados de los proyectos14:

• Trabajar la definición de requerimientos como un proyecto en sí mismo, que

comprende el levantamiento del proceso de negocio, la elaboración de las historias
de usuario y casos de uso, la construcción del prototipo y el refinamiento de los
requisitos

• Definir el anteproyecto por parte de la PMO, incluyendo la asignación inicial de

trabajadores y recursos

• Descomposición del proyecto en subproyectos menores a un año

• Definir los requisitos en conjunto entre cliente y analista

• Comprensión del modelo de proceso del negocio involucrado

• Entrega temprana de productos parciales

• Participación del cliente en los controles periódicos de avance15

14 La mayoría de los cuales, sin embargo, están consignados en la metodología del IPS.
15 Por ejemplo, en los daily scrum meeting del marco de desarrollo ágil Scrum.

37
 • Dedicación principal del Jefe de Proyecto al core del proyecto, esto es, a la
administración (liderazgo, riesgos e incidencias, logística), a la ejecución y al
control

• Actualización de estado de avance de cada tarea realizada por el responsable de

ella

• Generación automática de la base de los reportes periódicos

• Responsabilidad de los Coordinadores en las interacciones con áreas

involucradas.

Finalmente, mantener las variables, plazo, costo y alcance, como parte de los factores a
medir, con una ponderación menor a la de los factores antes mencionados.

5.2. Factores a considerar en el modelo propuesto

“Tradicionalmente, las métricas de tiempo, costo, alcance y calidad de la

dirección de proyectos han sido los factores más importantes para definir
el éxito de un proyecto. Más recientemente, profesionales y académicos
han determinado que el éxito del proyecto también debe medirse teniendo
en cuenta el logro de los objetivos del proyecto.” (PMBOK, 2017)

Si bien la mayoría de las variables son cuantificables, las hay también cualitativas, como
podría ser el caso de la participación del cliente en la etapa de ejecución del proyecto. Es
difícil cuantificar cuánta participación es conveniente: En Metodologías Ágiles, el cliente
tiene una baja participación en términos de tiempo, pero su involucramiento es cualitativo,
esencial en todo el transcurso del proyecto y un pilar fundamental de la metodología.

Las métricas para los factores expuestos en la tabla 8 definen dónde están los incentivos,
cuáles son las direcciones del esfuerzo principal, y permiten “…motivar a los equipos
responsables del cumplimiento de los objetivos reflejados en el KPI…” (Ayestarán et.al.,
2012). [25]
Tabla 9: Propuesta de factores

38
 # factor descripción

Rol de PMO16

1 PMO define plan general A partir del requerimiento inicial, PMO asigna JP y analista de requisitos

Coordinador comunica Coordinador asegura la interacción con las demás áreas involucradas:
2
las partes Arquitectura, QA, Seguridad de la Información, entre otras.

Requisitos

3 Comprensión del dominio Levantamiento / Análisis del proceso de negocio involucrado

4 Definición conjunta Cliente y analista definen los requisitos; analista los refina

5 Prototipo Entendimiento se plasma en un prototipo, permitiendo refinar requisitos

6 Descomposición Fragmentación del requerimiento en hitos o entregables parciales

7 Entrega temprana Los productos parciales son aprobados por el cliente

8 Avance periódico Reuniones periódicas (diarias o semanales, según duración del

proyecto), con participación del cliente

9 Actualizar estado Responsable de cada tarea actualiza el estado de avance

10 Dedicación del JP Jefe de proyecto gestiona el proyecto y lidera el equipo de éste

11 Plazo Estimación del tamaño en base a puntos de casos de uso para

determinar recursos y duraciones

12 Costo Costo determinado por el punto anterior

13 Alcance Alcance determinado por las condiciones de satisfacción y criterios de

calidad acordados con el cliente

16 PMBOK (2017): Oficina de Dirección de Proyectos (PMO) / Project Management Office (PMO).
Estructura de gestión que estandariza los procesos de gobernanza relacionados con el proyecto y facilita
el intercambio de recursos, metodologías, herramientas y técnicas.

39
 Capítulo VI: Propuesta de un modelo mejorado de gestión de
proyectos informáticos

En este capítulo se determinarán las características de un modelo mejorado, a partir de

los valores deseados definidos en el capítulo anterior, que subsane las deficiencias
identificadas.

6.1 Determinación de las características de un modelo propuesto

6.1.1 Requisitos

La definición adecuada de los requisitos del software constituye los cimientos sobre los
cuales se construirá la solución informática. A decir de SWEBOK (2004): “Es un área muy
difícil e ingenieros de software necesitan sensibilizarse al hecho que (por ejemplo) los
usuarios pueden tener dificultades para describir sus tareas, puede dejar la información
importante sin especificar, o pueden estar poco dispuestos a cooperar. Es
particularmente importante entender que la captura no es una actividad pasiva, y que,
ingenieros de software tienen que trabajar difícilmente para sacar la información
adecuada.” [17]

Por su parte, Pfleeger (2001) plantea: “La falta de cuidado en la comprensión, la

documentación y la gestión de los requerimientos puede llevar a una miríada de
problemas: construir un sistema que resuelve el problema equivocado, que no funciona
como se espera o que presenta dificultades para que los usuarios puedan comprenderlo
y utilizarlo.” [18]

Una solución radica en la participación plena del equipo de requerimientos (cliente,

stakeholders e ingeniero(s) de software) en todas las etapas de la definición de requisitos,
desde la formulación inicial hasta el refinamiento y documentación de los mismos.

6.1.2 Avance periódico

En la práctica, el control de avance periódico se puede expresar en la participación activa

del cliente en los controles de estados de avance periódicos del proyecto. Tal como
declara el Manifiesto Ágil (2001): “Los responsables de negocio y los desarrolladores
trabajamos juntos en forma cotidiana durante todo el proyecto.” [19]

40
6.1.3 Alcance

El alcance del proyecto será resultado del apropiado proceso de definición de requisitos
en combinación con el control periódico de los estados de avance, donde el cliente podrá
aprobar ajustes al alcance de acuerdo a las realidades que pueda ir presentando el
proyecto y las necesidades del negocio.

6.1.4 Actualizar estado

Un factor retardante en el actual modelo de gestión de proyectos informáticos es el rol de

‘secretario técnico’ que juega el JP, debiendo recabar los antecedentes de cada miembro
del equipo desarrollador y actualizar los estados de avance en el soporte tecnológico en
uso.

La solución a este problema pasa por una plataforma tecnológica que permita a los
integrantes del equipo actualizar los estados de avance de sus asignaciones, que son
enunciados en las reuniones de control periódico de avance.

6.1.5 Entrega temprana

Una de las causas del éxito de las metodologías ágiles es la entrega temprana y continua
de productos parciales, en la que el cliente puede apreciar cómo el producto va
adquiriendo consistencia. Para ello es necesario orientar la Estructura de
Descomposición del Trabajo (EDT) a segmentos que terminen en un entregable tangible.

6.1.6 Dedicación del JP

Las responsabilidades del JP consisten en coordinar el equipo y atender a los

stakeholders, asegurar la provisión de los insumos, ejercer el liderazgo sobre los
miembros del equipo, tomar medidas correctivas ante desviaciones y participar
activamente en la ejecución del proyecto. Si el JP dedica gran parte del tiempo a tareas
de secretaría técnica, necesariamente descuidará sus responsabilidades primordiales.

6.1.7 Plazo

En el caso particular del IPS, la mayoría de los desarrollos son normativos, por lo que los
plazos son de carácter perentorio. El modelo debe considerar flexibilidad en la
reorientación de los esfuerzos según los desempeños que se vayan manifestando; esto

41
es, el JP o la PMO deberá asignar recursos extraordinarios si una actividad crítica tiene
retrasos significativos.

6.1.8 Costo

En la Administración Pública el manejo presupuestario es relativamente rígido, por lo que

es conveniente asegurar calidad por sobre cantidad en la contratación de trabajadores
externos. En este sentido, una afinada EDT constituye una buena premisa para
aprovechar óptimamente a los miembros externos del equipo de desarrollo.

6.2 Métodos tradicionales de gestión de proyectos

Cabe la siguiente pregunta: ¿Son las prácticas del PMBOK, proceso RUP y reuniones
SCRUM las causas de los problemas del modelo de gestión cuestionado? En otras
palabras, se pretende determinar si las características definidas como necesarias para
una propuesta de modelo son compatibles con la metodología en uso.

Los desarrollos del IPS son primordialmente normativos, cuyos algoritmos y reglas de
negocio están claramente establecidos17, así como el alcance del producto, situación
para la cual los métodos tradicionales son adecuados. Sin embargo, en los hechos el
actual modelo de gestión de proyectos informáticos se ha revelado insuficiente.

Entonces, se debe buscar la causa de las deficiencias en los otros factores que,
combinados con la metodología PMBOK-RUP-SCRUM, constituyen el modelo
mencionado.

En capítulos anteriores fueron identificadas las principales variables las cuales se deben
analizar:

1. Insuficiente profundización del proceso de definición de los requerimientos

2. Desconocimiento del proceso de negocio por parte de los desarrolladores
3. Escasa participación del cliente en las etapas de diseño y de desarrollo del
proyecto

17 Aun cuando Pressman (2010) señala: “los requerimientos de software tienen la tendencia a seguir
cambiando, y con la llegada de los sistemas de mundo abierto, los requerimientos emergentes (y el cambio
casi continuo) pueden volverse la norma”

42
 4. Soporte tecnológico a la gestión del proyecto inadecuado
5. Contratación de trabajadores externos inadecuada
6. Entorpecimiento de la labor de gestión del proyecto del JP, debido a la profusión
de formularios que debe cumplimentar y a significativa dedicación a tareas de
secretaría técnica del proyecto.

Los primeros cinco factores son abordables en forma directa, modificando algunas
prácticas. El último factor requeriría de una intervención significativa para subsanarlo.
Pero es la combinación de los seis factores es la que introduce complejidad al modelo,
por lo que abordar cada factor de manera aislada no conduciría a una solución
satisfactoria. Además, Sáez Vacas (1969) señala: “Debido a que los sistemas complejos
tienen un carácter imprevisible, la gestión basada en el orden y control ya no es efectiva.”
[21]

A continuación, se presentan algunas propuestas que ayudarían a mejorar el modelo de

gestión que se está estudiando.

6.3 Mejoramiento del modelo

“El agente que capacitó a estas compañías para romper las viejas reglas
y crear nuevos modelos de proceso fue la informática moderna. Ésta obra
como un capacitor que les permite a las empresas hacer el trabajo en
forma radicalmente diferente.” (Hammer, 1994)

6.3.1 Definición de los requisitos

“Es la peor de las pesadillas. Un cliente entra a la oficina, toma asiento, lo

mira a uno fijamente a los ojos y dice: ‘Sé que cree que entiende lo que
digo, pero lo que usted no entiende es que lo que digo no es lo que quiero
decir.’ Invariablemente, esto pasa cuando ya está avanzado el proyecto,
después de que se han hecho compromisos con los plazos de entrega,
que hay reputaciones en juego y mucho dinero invertido.” (Pressman,
2010)

Este proceso define lo que el cliente espera del proyecto: cuál es el resultado deseado,
qué características debe cumplir, cuáles son los criterios de aceptación.

43
Constituye el pilar fundamental sobre el cual se elabora el proyecto y se construye la
solución.

Pfleeger (2001) define el proceso de requisitos en la siguiente ilustración.

Ilustración 10: El proceso de determinación de los requerimientos

En el contexto de la operación, toda intervención informática afecta a un proceso de

negocio, sea mejorándolo, sea incorporando o eliminando una funcionalidad, sea
automatizando una actividad. En esta perspectiva, el proceso intervenido es el contexto
que da significado a la intervención, es el marco de referencia para la definición de los
requerimientos. Detrás de cada requerimiento hay reglas de negocio que son las que
determinan los objetivos y las restricciones del proceso. Por ende, tener a la vista el
modelo de proceso de negocio es fundamental en toda la etapa de definición de
requerimientos. Si ello implica levantar el proceso, se debe considerar como una
importante ganancia, pues el analista no solo comprenderá mejor el contexto del
problema, sino también podrá aportar en el mejoramiento del proceso antes de diseñar
la solución.

Parte de la captura de requisitos consiste en: “Por tanto, desarrollar un modelo del
negocio es una alternativa más potente que desarrollar un modelo del dominio… El
modelado del negocio es una técnica para comprender los procesos de negocio de la
organización.” (Jacobson et.al., 2006) y listan las actividades a realizar y los artefactos
resultantes, en la siguiente tabla.

44
Tabla 10: El conjunto de requisitos está formado por los artefactos [23]

Trabajo a realizar Artefactos resultantes

Enumerar requisitos candidatos Lista de características

Comprender el contexto del sistema Modelo del dominio o del negocio

Capturar los requisitos funcionales Modelo de casos de uso

Definen una
Requisitos adicionales o casos de uso especificación de
Capturar los requisitos no funcionales
concretos requisitos tradicional

Sobre esta base se desarrolla el levantamiento de requisitos, el

análisis y el prototipado, tal como se expone en la ilustración 11.

Levantar /
Comprender el Definir los Prototipo y Refinar Documentación
proceso de requisitos prueba requisitos y validación
negocio

Definición tradicional de requisitos

Ilustración 11: Proceso de captura de requisitos

La descomposición del proyecto puede resultar clave en su desempeño, y cabe

plantearse asegurar plazos menores a un año. A decir de Pressman (2010): “El tamaño
del proyecto es otro factor importante que puede afectar la precisión y la eficacia de las
estimaciones. Conforme aumenta el tamaño, la interdependencia entre varios elementos
del software crece rápidamente. La descomposición del problema, un importante enfoque
de la estimación se vuelve más difícil porque el refinamiento de los elementos del
problema todavía puede ser formidable. Para parafrasear la ley de Murphy: ‘lo que puede
salir mal, saldrá mal’, y si hay más cosas que pueden fallar, más cosas fallarán.”

6.3.2 Avance periódico

Uno de los atractivos del modelo SCRUM de Metodologías Ágiles es su Scrum daily
meeting 18 , en las que cada integrante del equipo responde tres preguntas, dando

18 Reuniones diarias, de no más de 15 minutos, en las que participan todos los miembros del equipo

45
contexto a la labor del día:

• ¿Qué hiciste ayer?

• ¿Qué harás hoy?

• ¿Qué impedimentos tienes?

Con esta práctica se aplica el principio N° 4 del Manifiesto Ágil: “Las personas de
negocios y los desarrolladores deben trabajar juntos, a diario y durante todo el proyecto.”
[19] y, como plantea Pressman (2010): “…adopta al cliente como parte del equipo de
desarrollo y trabaja para eliminar la actitud de ‘nosotros y ellos’ que todavía invade
muchos proyectos de software…”.

6.3.3 Alcance

Los alcances del proyecto y del producto constituyen un tema que requiere especial
consideración debido al carácter público del IPS y al carácter normativo de la mayoría de
los requerimientos19. La apropiada definición y refinamiento de los requerimientos en
conjunto con el cliente aumenta la probabilidad de definir un alcance realista, factible y
comprensible para las partes.

6.3.4 Actualizar estado

Cada integrante del equipo de proyecto es responsable de las actividades asignadas a

él; es el ‘líder’ de esas tareas, responde por ellas y sabe exactamente el estado en que
se hallan. Por ende, es la persona que debe actualizar el estado de sus actividades en la
plataforma técnica de soporte a la gestión del proyecto.

6.3.5 Entrega temprana

Al definir el IPS su proceso del software como iterativo incremental, se deben aprovechar
ciertas características de la metodología para la entrega temprana, según describe
PMBOK (2017):

de proyecto y, generalmente, el cliente.

19 Aun en el caso de proyectos de mejoras estructurales de sistemas de negocio, se pueden
considerar como normativos, debido a los compromisos institucionales con organismos como DIPRES o
Subsecretaría de Previsión Social.

46
Iterativo: “…Las iteraciones desarrollan el producto a través de una serie de ciclos
repetidos, mientras que los incrementos van añadiendo sucesivamente funcionalidad al
producto.”

Incremental: “…el entregable se produce a través de una serie de iteraciones que

sucesivamente añaden funcionalidad dentro de un marco de tiempo predeterminado”.

6.3.6 Dedicación del JP

“La gestión de proyectos es una actividad intensamente humana… Todo

proyecto de software está poblado con personas que están dentro de esta
taxonomía. Para ser efectivo, el equipo de software debe organizarse de
manera que maximice las habilidades y capacidades de cada persona. Y
ésta es labor del líder del equipo. ” (Pressman, 2010)

“Los administradores de proyectos tienen que resolver problemas técnicos

y no técnicos utilizando las personas de su equipo de la forma más
efectiva posible. Tienen que motivar a la gente, planear y organizar su
trabajo y asegurar que el trabajo se realice de manera adecuada. La
administración pobre del personal es uno de los factores más importantes
para el fracaso de los proyectos.” (Sommerville, 2005)

“No se espera que el director del proyecto desempeñe cada rol en el

proyecto, pero debería poseer conocimientos, conocimientos técnicos,
entendimiento y experiencia en la dirección de proyectos. El director del
proyecto proporciona al equipo del proyecto liderazgo, planificación y
coordinación a través de las comunicaciones.

El director del proyecto proporciona comunicaciones escritas (p.ej., planes

y cronogramas documentados) y comunicaciones en tiempo real con el
equipo usando reuniones e indicaciones verbales y no verbales.” (PMBOK,
2017)

La responsabilidad del JP es asegurar el cumplimiento de los objetivos del proyecto en

un marco de plazo – costo – alcance – calidad acordados. Debe para ello gestionar los
recursos, los riesgos, las relaciones con el cliente y el liderazgo sobre el equipo de

47
proyecto. Toda labor complementaria al proyecto, aquella que no agrega valor, la debe
asumir el Coordinador.

6.3.7 Plazos

La mayor debilidad del actual modelo se refleja en el incumplimiento de los plazos, lo cual
se puede solucionar descomponiendo el proyecto en subproyectos y afinando los
métodos de estimación, sea por puntos de casos de uso o por puntos de objeto.

Las reuniones diarias y la dedicación centrada en la gestión y liderazgo del JP son

factores que permitirán la realización de ajustes oportunos y focalizar esfuerzos
puntualmente.

6.3.8 Costo

Los sobrecostos históricamente se han producido debido a alargues en las duraciones

de los proyectos. Es por tanto una función del punto anterior.

6.4 El proceso

Al considerar la etapa de definición de requerimientos como un proceso en sí, lo

anteriormente expuesto queda reflejado en la ilustración N.

En lo que respecta a la metodología para el levantamiento de procesos, el Estado de

Chile, a través del Consejo de Auditoría Interna General de Gobierno ha generado unos
documentos técnicos útiles para este fin:

• Documento técnico N° 88 Versión 0.2, Conceptos generales sobre enfoque de

procesos de negocios [29]

• Documento Técnico N° 89 Versión 0.2, Propuestas metodológicas para el

levantamiento y modelamiento de procesos [30].

Para la especificación de requerimientos la División Informática elaboró una plantilla muy

completa, ER_NombreProyecto_aaaammdd-v2.0.docx (Diciembre 2016).

48
 Ilustración 12: Proceso de Definición de requerimientos

En lo principal, este modelo plantea que la PMO tiene la responsabilidad por la definición
del marco en el cual se desarrolla el proyecto; esto es, el alcance general del producto y
los recursos iniciales con los cuales contará el JP para su ejecución20.

Una vez refinados los requisitos, al elaborar el Acta de Constitución del Proyecto, es
cuando se establecen los plazos – costos – alcance del proyecto, así como los criterios
de calidad de los entregables.

20 El IPS define su PMO como de Control: “La PMO instalada en nuestra institución es de control, ya
que sus principales tareas son; proporcionar soporte y exigir el cumplimiento a través de diferentes medios,
se ejerce un grado de control moderado que implica”

49
Este esquema es utilizado por algunas empresas dedicadas al desarrollo de software a
pedido21, cuyo negocio se basa en la eficiencia y eficacia de sus procesos de desarrollo
y de proyectos.

6.4.1 Proceso general del proyecto

En las ilustraciones 13 y 14 se expone el proceso general, donde los principales cambios

dicen relación con las responsabilidades y la incorporación de la definición de
requerimientos como un subproyecto.

21 Por ejemplo, Kuvasz Solutions, www.kvz.cl

50
Ilustración 13: Proceso general del proyecto (vista 1)

Ilustración 14: Proceso general del proyecto (vista 2)

51
7 Capítulo VII: Conclusiones

7.1 De las preguntas de investigación

¿Cuáles son los factores de los proyectos informáticos que han determinado
los retrasos en sus cumplimientos?
La investigación reveló que los factores adversos a una exitosa gestión de proyectos
informáticos radica principalmente en el proceso del proyecto:

• Insuficiente profundización en la recopilación de requisitos

• Poca comprensión del proceso de negocio involucrado
• Insuficiente dedicación del Jefe de proyecto a liderar el equipo de desarrollo y
a gestionar el proyecto
• Precario soporte tecnológico a la gestión de proyectos.
¿Es determinante la selección de una metodología de gestión de proyectos
informáticos en los cumplimientos de estos?
La elección de la metodología de gestión de proyectos (PMBOK) no ha tenido efectos
significativos en los resultados de los proyectos estudiados, principalmente debido a
que se aplicó el proceso del proyecto de PMBOK , pero no así las recomendaciones
de sus primeros tres capítulos.

7.2 De los objetivos específicos

1. Los antecedentes aportados con relación al cumplimiento de los proyectos

estudiados permitieron determinar un impacto negativo del modelo de gestión de
proyectos informáticos.

2. El análisis de los problemas y dedicaciones permitieron determinar los principales

factores que incidieron en el cumplimiento del Plan Director.

3. A partir de lo anterior se pudo definir factores que ayudaron a establecer un nuevo

modelo de gestión de proyectos informáticos.

4. Finalmente, se pudo elaborar la propuesta de un modelo mejorado de gestión de

proyectos informáticos.

52
Bibliografía

[1] Ansoff, Igor (1965), Corporate Strategy: an analytic approach to business policy for
growth and expansion (1ª ed.), New York, McGraw-Hill.

[2] Porter, Michael (1980), Competitive Strategy: Techniques for Analyzing Industries and
Competitors (1ª ed.), New York, The Free Press.

[3] Kaplan, Robert & Norton, David P. (2003), Strategy maps: converting intangible assets
into tangible outcomes (1ª ed.), Boston, Harvard Business School Press.

[4] Consenso de Washington (2006). Wikipedia, La enciclopedia libre. Fecha de consulta:

19 de abril de 2019. Recuperado de
https://es.wikipedia.org/wiki/Consenso_de_Washington

[5] Armijo, Marianela (2011). Planificación estratégica e indicadores de desempeño en el

sector público. Santiago de Chile: Instituto Latinoamericano y del Caribe de Planificación
Económica y Social (ILPES), CEPAL. Recuperado: 19 de abril de 2019, desde
https://www.cepal.org/ilpes/publicaciones/xml/8/44008/sm_69_ma.pdf

[6] Planificación estratégica (2005). Wikipedia, La enciclopedia libre. Fecha de consulta:

20 de abril de 2019. Recuperado de
https://es.wikipedia.org/wiki/Planificación_estratégica

[7] Project Management Institute (2016). The High Cost of Low Performance: PMI's Pulse
of the Profession. Recuperado: 19 de abril de 2019, desde http://www.pmi.org/-
/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/pulse-of-the-
profession-2016.pdf

[8] Morales Martín, Juan Jesús (2018), Dominación Filantrópica y gobernabilidad

democrática: El caso de la Fundación Ford y CIEPLAN en Chile (1976-1990), Instituto de
Historia, Pontificia Universidad Católica de Chile. Recuperado: 19 de abril de 2019, desde
http://revistahistoria.uc.cl/index.php/rhis/article/view/247/154

[9] Rodríguez U., Manuel Luis (2012), Modernidad y Estado: El proceso de modernización
desde el Estado en Chile. Recuperado: 19 de abril de 2019, desde
https://cienciadelapolitica.wordpress.com/2012/08/08/modernidad-y-estado-el-proceso-

53
de-modernizacion-desde-el-estado-en-chile/

[10] Comisión Nacional de Reforma Administrativa (1974). Esquema general desarrollo

2ª exposición sobre regionalización, gobierno y administración regional. Recuperado: 19
de abril de 2019, desde http://www.subdere.gov.cl/sites/default/files/documentos/articles-
68910_recurso_1.pdf

[11] Reporte de Cumplimiento Modernización del Estado, Evaluación de la

implementación de la red multiservicios del Estado ChileAtiende (2013). Recuperado: 19
de abril de 2019, desde
http://www.observatoriodigital.gob.cl/sites/default/files/reporte_de_cumplimiento_chileati
ende.pdf

[12] Licitación ID: 5418874-49-LP13 (2013), Servicios Consultoría para Gestión Plan
Director. Recuperado: 19 de abril de 2019, desde
http://www.mercadopublico.cl/Procurement/Modules/RFB/DetailsAcquisition.aspx?qs=3z
8Ey+2YLM47+8j6LfEVQw==

[13] Plan Director 2016, Instituto de Previsión Social.

[14] OBS Business School (2014), Gestión de proyectos informáticos: ¿tradicional o ágil?
Recuperado: 19 de abril de 2019, desde

[15] Ministerio de Obras Públicas (2011), Guía para la elaboración de planes.

Recuperado: 19 de abril de 2019, desde
http://www.dirplan.cl/centrodedocumentacion/Documents/Metodologia/Guia_Elaboracio
n_Planes_marzo_2011.pdf

[16] Fundación Ford (2006). Wikipedia, La enciclopedia libre. Fecha de consulta: 20 de

abril de 2019. Recuperado de https://es.wikipedia.org/wiki/Fundación_Ford

[17] IEEE Computer Society (2004), SWEBOK: Guía al cuerpo de conocimiento de la

ingeniería del software versión 2004 (Borrador). Recuperado: 19 de abril de 2019,
desde https://www.academia.edu/7079594/Hispa_SWEBOK_Borrador

[18] Pfleeger, Shari Lawrence (2001), Ingeniería de software: Teoría y práctica (2ª ed.),
Buenos Aires, Pearson Education (by Prentice Hall).

54
[19] Manifiesto Ágil (2001). Principios del Manifiesto Ágil. Recuperado: 19 de abril de
2019, desde https://agilemanifesto.org/iso/es/principles.html

[20] Pressman, Roger S. (2010), Ingeniería del software, un enfoque práctico (7ª ed.),
México D.F.: McGraw-Hill.

[21] Sáez V. et.al., Fernando (2003), Innovación tecnológica en las empresas, Temas
básicos, Madrid, Universidad Politécnica de Madrid.

[22] Project Management Institute (2017), Guía de los fundamentos para la dirección de
proyectos (Guía del PMBOK – 6ª ed.), Pensilvania, PMI Publications. Recuperado el 20
de abril de 2019 desde: https://mega.nz/#!2jghRQyY!VNNbgpixjJPhdGcvFh-
nqqXmPcTDdVD7dFv_-opleVM

[23] Jacobson I., Booch G., Rumbaugh J. (2006), El proceso unificado de desarrollo de
software, Madrid, Pearson Educación - Adisson Wesley.

[24] Hammer M., Champy J. (1994), Reingeniería, Bogotá, Grupo Editorial Norma
(HarperCollins Publisher).

[25] Ayestarán Crespo, Raquel & Rangel Pérez, Celia & Sebastián Morillas, Ana (2012).
Planificación estratégica y gestión de la publicidad. (1ª ed.). Madrid: ESIC Editorial.

[26] Somerville, Ian (2005). Ingeniería del software. (7ª ed.). Madrid: Pearson
Educación.

[27] López Gil, Alba (2018). Estudio comparativo de metodologías tradicionales y ágiles
para proyectos de Desarrollo de Software. Tesis de grado. Universidad de Valladolid,
Escuela de Ingenierías Industriales, Valladolid. Recuperada: 20 de abril de 2019, desde
http://uvadoc.uva.es/bitstream/10324/32875/1/TFG-I-1015.pdf.

[29] Lledó P., et.al. (2006). Administración Lean de Proyectos. (1ª ed.). México D.F.:
Pearson Educación.

[29] Consejo de Auditoría Interna General de Gobierno, Secretaría General de Gobierno (2016).
Conceptos generales sobre enfoque de procesos de negocios. (Documento técnico N° 88
Versión 0.2). Santiago, Chile. Recuperado: 20 de abril de 2019, desde
https://www.auditoriainternadegobierno.gob.cl/wp-content/upLoads/2015/07/DOCUMENTO-TECNICO-
88-CONCEPTOS-GENERALES-SOBRE-ENFOQUE-DE-PROCESOS-DE-NEGOCIOS.pdf

55
[30] Consejo de Auditoría Interna General de Gobierno, Secretaría General de Gobierno (2016).
Propuestas metodológicas para el levantamiento y modelamiento de procesos. (Documento
técnico N° 89 Versión 0.2). Santiago, Chile. Recuperado: 20 de abril de 2019, desde
https://www.auditoriainternadegobierno.gob.cl/wp-content/upLoads/2015/07/DOCUMENTO-TECNICO-
N-89-PROPUESTAS-METODOLOGICAS-PARA-EL-LEVANTAMIENTO-Y-MODELAMIENTO-DE-
PROCESOS-2.pdf

[31] Gestión de proyectos (2013). Wikipedia, La enciclopedia libre. Fecha de consulta: 20

de abril de 2019. Recuperado de https://es.wikipedia.org/wiki/Gestión_de_proyectos

56
Anexos

8.1 Anexo I: Procesos del proyecto - diagramas

8.1.1 Inicio del proyecto

57
 Ilustración 15: Proceso Inicio del proyecto

8.1.2 Construcción del proyecto

Ilustración 16: Construcción del proyecto

58
8.1.3 Transición del proyecto

Ilustración 17: Transición del proyecto

59
8.1.4 Proceso general

60