Flores García Luis Alberto

ESCUELA DE POSTGRADO
Impacto de la Gestión de Portafolio de Proyectos en el

rendimiento de pequeñas empresas de desarrollo de software
en Perú
TESIS PARA OPTAR EL GRADO ACADÉMICO DE DOCTOR EN

GESTIÓN ESTRATÉGICA CON MENCIÓN EN GESTIÓN
EMPRESARIAL Y SOSTENIBILIDAD
AUTOR
LUIS ALBERTO FLORES GARCÍA
ASESOR:
JOSE ANTONIO POW SANG PORTILLO
Enero, 2021
1
Dedicatoria
A mi esposa Verónica y mis hijos Fernando y Roberto, mi razón de vivir. Gracias por
comprender que en ocasiones no podía estar con ustedes tanto como quisiera para
poder completar este objetivo.
2
Agradecimientos
Agradezco primero que nada a cada una de las empresas que aceptaron formar parte
en cada una de las fases de este estudio. Agradezco también a mi asesor, el Doctor
Pow-Sang por su asesoría, a los docentes del Doctorado que con sus observaciones
me permitieron afinar el proyecto y a mis compañeros del Doctorado por sus
comentarios y buenos momentos durante esos largos días de clases. Finalmente
agradezco a la Pontificia Universidad Católica del Perú y al Departamento de Ingeniería
por el apoyo para que pueda culminar este reto de mi carrera académica.
3
Resumen
La gestión de portafolio de proyectos se define como colección de componentes de
portafolios (proyectos, programas y otras actividades) agrupados para facilitar su
gestión, para cumplir total o parcialmente un conjunto de objetivos estratégicos de la
organización. Estos proyectos constituyen una parte importante de los negocios en
general y juegan un rol central en el desarrollo, visión estratégica y mantenimiento de la
competitividad y rendimiento de una empresa. Sin embargo, desde una visión
estratégica, para que estos proyectos generen valor a la empresa se debe garantizar
que el grupo seleccionado de proyectos contribuye a implementar la estrategia de
negocio en términos de líneas de productos, mercados, plataformas tecnológicas, etc.
La revisión del estado del arte realizada como parte de este proyecto de investigación
muestra que la gestión de portafolio de proyectos ha sido tratada en múltiples
publicaciones a través principalmente de estudios de casos los cuales identifican
herramientas, factores de éxito y desafíos para su implementación. Lo anterior justifica
la hipótesis de que la implementación de gestión de portafolio de proyectos influye en el
rendimiento de las empresas, sin embargo, de los estudios encontrados solo unos pocos
incluyen en su muestra pequeñas empresas y ninguno en el contexto latinoamericano.
Para la realización de este proyecto se utilizó un diseño de investigación mixto,

empezando por un estudio cuantitativo exploratorio, que permitió identificar un conjunto
de empresas que apliquen prácticas de gestión de portafolio. El siguiente paso fue un
estudio de caso múltiple que permitió identificar cómo estas empresas aplicaban las
prácticas de gestión de portafolio. Con la información recabada se elaboró una
propuesta de marco de trabajo de gestión estratégica de proyectos, el cual incluye un
conjunto de roles, así como actividades relacionadas a la revisión de objetivos
estratégicos, definición y gestión del portafolio y gestión de proyectos. Finalmente, la
propuesta de marco de trabajo fue validada en dos empresas con resultados positivos.
Los resultados de este proyecto contribuyen al campo de la investigación en la gestión

de carteras al verificar su aplicabilidad en el ámbito de las pequeñas empresas y también
ayudan a los responsables de la implementación proporcionando un marco estratégico
de gestión de proyectos aplicable a las pymes de desarrollo de software.
4
Abstract
Project portfolio management is defined as a collection of portfolio components (projects,
programs, and other activities) grouped together to facilitate their management, to fully
or partially fulfill a set of strategic objectives of the organization. These projects are an
important part of the business in general and play a central role in the development,
strategic vision, and maintenance of the competitiveness and performance of a
company. However, from a strategic perspective, to generate value for the company, it
must be guaranteed that the selected group of projects contributes to implementing
strategy in terms of product lines, markets, technological platforms, etc.
The state-of-the-art review carried out as part of this research shows that project portfolio
management has been addressed in multiple papers through mainly case studies that
identify tools, success factors, and challenges for its implementation. This justifies the
hypothesis that the implementation of project portfolio management influences the
performance of companies, however, of the studies found, only a few include small
companies in their sample and none in the Latin American context.
To develop this project, a mixed research design was used, starting with a quantitative
exploratory study, which allowed the identification of a set of organizations that apply
project portfolio management practices. The next step was a multiple case study that
identified how these organizations applied project portfolio management practices. With
the information collected, a strategic project management framework was developed,
which includes a set of roles, as well as activities related to the review of strategic
objectives, definition and management of the portfolio, and project management. Finally,
the proposed framework was validated in two companies with positive results.
The results of this project contribute to the field of research in portfolio management by
verifying its applicability in the field of small companies and also helps those responsible
for implementation by providing a strategic project management framework applicable to
SMEs of software development.
5
Tabla de Contenido
Dedicatoria .................................................................................................................... 2
Agradecimientos ........................................................................................................... 3
Resumen ...................................................................................................................... 4
Abstract......................................................................................................................... 5
Tabla de Contenido ....................................................................................................... 6
Capítulo 1. Introducción ...........................................................................................12
1.1 Planteamiento del Problema .........................................................................13
1.2 Pregunta de Investigación: ............................................................................14
1.3 Objetivos .......................................................................................................15
1.4 Justificación ..................................................................................................15
Capítulo 2. Marco Teórico ........................................................................................17

2.1 Pequeña empresa .........................................................................................17
2.2 Rendimiento de las empresas .......................................................................19
2.3 Factores que afectan el rendimiento de una pequeña empresa ....................22
2.4 Portafolio de Proyectos .................................................................................24
2.5 Procesos de la gestión de portafolio..............................................................25
2.6 Gestión de múltiples proyectos (Multiple Project Management).....................27
Capítulo 3. Revisión de la literatura ..........................................................................29

3.1 Método de la revisión ....................................................................................29
3.1.1 Protocolo de la revisión ..........................................................................30
3.1.2 Preguntas de investigación ....................................................................30
3.1.3 Fuentes de datos ...................................................................................30
3.1.4 Cadenas de búsqueda ...........................................................................30
3.1.5 Criterios de inclusión ..............................................................................30
3.1.6 Criterios de exclusión .............................................................................31
3.2 Resultados de la revisión ..............................................................................31
3.3 Evaluación del éxito de la gestión de portafolio .............................................32
6
3.4 Desafíos y problemas de la gestión de portafolio ..........................................36
3.5 Factores de éxito de la gestión de portafolio .................................................38
3.6 Impacto de la gestión de portafolio en resultados de la empresa...................42
3.7 Conclusiones de la revisión ...........................................................................45
Capítulo 4. Diseño de investigación .........................................................................47

4.1 Descripción de la población...........................................................................47
4.2 Fases y procedimientos ................................................................................48
4.3 Criterios de Selección ...................................................................................54
4.4 Matriz de Operacionalización ........................................................................55
4.5 Instrumentalización .......................................................................................60
Capítulo 5. Estudio Exploratorio ...............................................................................63

5.1 Ejecución del estudio ....................................................................................63
5.2 Identificación de respuestas válidas ..............................................................64
5.3 Análisis de respuestas ..................................................................................66
Capítulo 6. Estudio de Caso Múltiple........................................................................69

6.1 Preparación de las entrevistas ......................................................................69
6.2 Descripción de las empresas participantes ...................................................69
6.3 Discusión del caso ........................................................................................72
6.3.1 Nivel estratégico.....................................................................................72
6.3.2 Portafolio de Proyectos ..........................................................................74
6.3.3 Gestión de Proyectos .............................................................................82
Capítulo 7. Propuesta de Marco de Trabajo .............................................................86
7.1 Roles.............................................................................................................86
7.2 Esquema General .........................................................................................87
7.2.1 Bloque 1 (Estrategia) .............................................................................88
7.2.2 Bloque 2 (Propuestas de Proyecto o Portafolio de ideas).......................89
7.2.3 Bloque 3 (Definición y Gestión del Portafolio) ........................................90
7
7.3 Recomendaciones para la implementación ...................................................91
7.3.1 Generación de propuestas para proyectos internos ...............................91
7.3.2 Elaboración de propuestas.....................................................................91
7.3.3 Evaluación de propuestas ......................................................................92
7.3.4 Gestión de Proyectos .............................................................................93
7.3.5 Gestión de Portafolio..............................................................................94
7.3.6 Evaluación de resultados .......................................................................94
Capítulo 8. Validación del Marco de Trabajo ............................................................95

8.1 Proceso de validación ...................................................................................95
8.1.1 Convocatoria a empresas ......................................................................95
8.1.2 Evaluación previa ...................................................................................96
8.1.3 Apoyo en la implementación ..................................................................98
8.1.4 Hechos relevantes .................................................................................99
8.1.5 Evaluación de la implementación ......................................................... 100
8.1.6 Resumen de resultados ....................................................................... 101
Capítulo 9. Conclusiones, limitaciones y trabajos futuros .......................................106

Capítulo 10. Referencias ......................................................................................110
Anexo 1 – Cuestionario Fase de Exploración ............................................................123
Anexo 2 – Cuestionario Fase Cualitativa ...................................................................126
Anexo 3 – Consentimiento Informado (Encuesta)......................................................129
Anexo 4 – Consentimiento Informado (Entrevista).....................................................130
Anexo 5 – Acuerdo de Confidencialidad con Empresas ............................................132
Anexo 6 – Transcripción de entrevista 1 ....................................................................133
Anexo 10 – Transcripción de entrevista 4 ..................................................................184
Anexo 13 – Análisis bibliométrico de los artículos .....................................................239
8
ÍNDICE DE FIGURAS
Figura 3.1 Artículos revisados ....................................................................................31
Figura 5.1. Distribución de empresas por Principal Actividad de Negocio. ...................64
Figura 5.2. Distribución de empresas por Tamaño del Portafolio ................................65
Figura 5.3. Distribución de empresas por Número de Trabajadores ............................66
Figura 7.1. Representación del modelo general. .........................................................87
9
ÍNDICE DE TABLAS
Tabla 2.1 Clasificación de Micro y Pequeña Empresa (MERCOSUR, 1992) ...............18
Tabla 1.2 Prácticas de Gestión de Portafolio según ISO 21504 (basado en ISO, 2015)
......................................................................................................................................26
Tabla 2.2 Prácticas de Gestión de Portafolio según PMI (basado en Project

Management Institute, 2013b) .....................................................................................27
Tabla 4.1 Matriz de Operacionalización Fase Exploratoria ..........................................55
Tabla 4.2 Matriz de Operacionalización Fase Cualitativa ............................................58
Tabla 5.1 Evaluación de prácticas de gestión y percepción de rendimiento.................67
Tabla 6.1 Descripción de las empresas .......................................................................70
Tabla 6.2 Puntaje obtenido por las empresas entrevistadas ........................................71
Tabla 6.3 Objetivos de negocio ...................................................................................72
Tabla 6.4 Percepción sobre la innovación ...................................................................75
Tabla 6.4 Aspectos a considerar en la decisión de realizar un proyecto ......................77
Tabla 6.5 Resumen de aspectos a considerar en la decisión de realizar un proyecto .78
Tabla 6.6 Responsables de la decisión de ejecución de proyectos .............................80
Tabla 6.7 Actividades de aseguramiento y control de calidad ......................................84
Tabla 7.1 Roles definidos en el marco de trabajo ........................................................86
Tabla 8.1 Evaluación inicial - Fase validación .............................................................96
Tabla 8.2 Resumen Evaluación inicial - Fase validación .............................................98
Tabla 8.3 Objetivos por Reunión .................................................................................99
Tabla 8.4 Implementación de Prácticas de Gestión de Portafolio de Proyectos.........101
Tabla 8.5 Resumen Implementación de Prácticas de Gestión de Portafolio de

Proyectos ..................................................................................................................103
Tabla 8.6 Percepción sobre el rendimiento de la empresa luego de la implementación

del marco de gestión estratégica de proyectos ..........................................................103
10
Tabla 8.7 Resumen de variación en la percepción sobre el rendimiento de la empresa
....................................................................................................................................104
Tabla 8.8 Expectativas del gerente general tras la implementación del marco de
gestión estratégica de proyectos ...............................................................................105
Tabla 8.9 Percepción de utilidad del marco de gestión estratégica de proyectos.......105
11
Capítulo 1. Introducción
Los proyectos constituyen el medio de conseguir los resultados de negocio esperados

y muchas empresas dedican la mayor parte de sus recursos a proyectos. Estas
organizaciones se conocen como organizaciones proyectizadas (Hyvari, 2006), pero
para que estos proyectos beneficien a la organización deben ser adecuadamente
seleccionados (Gutiérrez & Magnusson, 2014) y gestionados (Srivannaboon & Ph,
2006). Lo anterior constituyen los objetivos de la gestión de portafolio.
En el Perú, y en general en los países de Latino América es común que la mayor parte
de las empresas sean micro y pequeñas empresas y generan cerca del 30% del PBI
(Organización Internacional para el Trabajo, 2015), sin embargo según los estudios del
Banco Mundial (2013) estas empresas suelen operar con bajos niveles de productividad.
Esta situación se observa también en la industria de software en Perú, la cual está

principalmente constituida por pequeñas y microempresas, y entre el 2010 y 2017
registró un incremento de 10.8%, por encima del crecimiento mundial específico de la
industria del software (Ochoa, 2019).
Es en este contexto que se plantea el siguiente proyecto con el objetivo de desarrollar

un marco de gestión estratégica de proyectos orientado a pequeñas empresas de
desarrollo de software. La motivación para desarrollar este proyecto es contribuir al
campo de la investigación al verificar la aplicabilidad de las prácticas de gestión de
portafolio en pequeñas empresas y proveer una base para los profesionales que
desempeñen esta función dentro de las organizaciones.
El marco de trabajo planteado tiene por objetivo apoyar a las organizaciones a lograr un
mejor rendimiento, lo que implica el logro de sus objetivos estratégicos. De esta forma
el marco de trabajo generado como parte del proyecto apoyará la mejora de la
productividad y al crecimiento de las pequeñas empresas de desarrollo de software en
Perú. Dado que el 95% de estas empresas son micro y pequeñas empresas (APESOFT,
2015) brindar una herramienta que ayude a mejorar su productividad ayudará también
al desarrollo de la industria de software en Perú con la perspectiva de poder replicarlo
12
en otros países de la región cuyas características de la industria de software son
similares a las de Perú
Este capítulo describe el planteamiento del problema tomando como base la definición
de portafolio descrita en la Norma Internacional ISO 21504 y su relación con la estrategia
organizacional. Posteriormente se presenta la pregunta de investigación principal y los
objetivos de investigación que guían el presente proyecto.
1.1 Planteamiento del Problema

La norma ISO 21504 publicada el año 2012 define un portafolio como “colección de
componentes de portafolios agrupados para facilitar su gestión, para cumplir total o
parcialmente un conjunto de objetivos estratégicos de la organización” (ISO, 2015, p. 1).
En este contexto, la gestión de portafolio involucra identificar, priorizar, autorizar,
gestionar y controlar los proyectos y programas, así como los riesgos, recursos y
prioridades asociadas (Young, Owen, & Connor, 2011).
Desde un punto de vista estratégico, la gestión de portafolio puede ser considerada

como un proceso de toma de decisiones, con tres objetivos principales (Gutiérrez &
Magnusson, 2014):
 maximizar el retorno de la inversión realizada en el desarrollo de productos,
 gestionar el riesgo mediante la diversificación de los tipos de proyectos de la
cartera (a lo largo de ciertas dimensiones, tales como probabilidad de éxito, tipos
de tecnología, cantidad de inversión, etc.)
 asegurar que el grupo seleccionado de proyectos contribuye a implementar la
estrategia de negocio de la empresa en términos de líneas de productos,
mercados, plataformas tecnológicas, etc.
Este proyecto se enmarca en el contexto de “Implementación de la Estrategia”. En este

ámbito, las estadísticas muestran que el 70% de las empresas fallan en la
implementación de su estrategia de negocios (Pucko, 2008; Sterling, 2003), así mismo
muestran que las pymes en Latinoamérica operan con muy bajos niveles de
productividad (Banco Mundial, 2013).
La revisión de la literatura desarrollada como parte de este proyecto de investigación

muestra que los proyectos son reconocidos como parte importante de los negocios en
13
general y juegan un rol central en el desarrollo, la visión estratégica y el mantenimiento
de la competitividad y rendimiento de una empresa (Artto & Wikström, 2005; Wikström,
Artto, Kujala, & Söderlund, 2010). Sin embargo, desde una visión estratégica, para que
estos proyectos generen valor a la empresa, se debe garantizar que el grupo
seleccionado de proyectos contribuye a implementar la estrategia de negocio en
términos de líneas de productos, mercados, plataformas tecnológicas, etc. (Gutiérrez &
Magnusson, 2014). Por otro lado muchos líderes de negocios consideran que alinear la
gestión de los proyectos con la estrategia empresarial puede mejorar significativamente
el logro de los objetivos de negocio, estrategias y desempeño (Srivannaboon & Ph,
2006).
Este tema ha sido tratado en múltiples investigaciones a través principalmente de

estudios de casos, los cuales identifican herramientas, factores de éxito y desafíos para
su implementación. Varios de estos estudios sugieren una relación entre la gestión de
portafolio de proyectos y el rendimiento de las empresas (Young et al., 2012). Es sobre
esta afirmación que se plantea la hipótesis de que la aplicación de prácticas de gestión
de portafolio puede afectar el rendimiento de una empresa.
Cabe mencionar también que la gestión de portafolio no es una función aislada dentro
de la organización, sino que interactúa con múltiples áreas, lo que hace que el éxito de
la gestión de portafolio se vea influenciado por la participación del resto de actores
involucrados (W. Heising, 2012; Voss & Kock, 2013). De la revisión de la literatura se
observa que el tema ha sido estudiado en el contexto de grandes empresas y
mayormente en países del continente europeo o Norteamérica, dejando un amplio
campo de investigación en el caso de pequeñas empresas.
1.2 Pregunta de Investigación:

¿Cómo impacta la gestión de portafolio de proyectos el rendimiento de las pequeñas
empresas desarrolladoras de software en Perú?
Para ello se consideran las siguientes preguntas secundarias:

 ¿Cómo se aplican las prácticas de gestión de portafolio en pequeñas empresas
dedicadas al desarrollo de software en Perú?
 ¿Empresas proyectizadas de igual o similar tamaño que apliquen prácticas de
gestión de portafolio tienen un rendimiento diferente que las que no lo aplican?
14
1.3 Objetivos:
El objetivo principal de este estudio es desarrollar un marco de gestión estratégica de
proyectos que permita mejorar el rendimiento de pequeñas empresas de desarrollo de
software en Perú
Objetivos Específicos
 Describir las prácticas de gestión de portafolio utilizadas en las pequeñas
empresas dedicadas al desarrollo de software en Perú.
 Determinar si la aplicación de las prácticas de gestión de portafolio influye en el
rendimiento de estas pequeñas empresas.
 Proveer un conjunto de lineamientos guía para la implementación de las
prácticas de gestión de portafolio como parte de un marco de trabajo de gestión
estratégica de proyectos aplicable a pequeñas empresas de desarrollo de
software.
1.4 Justificación
Este trabajo busca apoyar al crecimiento de las pequeñas empresas en Perú a través
de la elaboración de un marco de gestión estratégica de proyectos que considere las
características propias de una pequeña empresa.
En la actualidad muchos líderes de negocios consideran que alinear la gestión de los

proyectos con la estrategia de negocios puede mejorar significativamente el logro de los
objetivos de negocio, estrategias y desempeño (Srivannaboon & Ph, 2006).
La revisión de la literatura desarrollada como parte de este proyecto de investigación

evidencia que el tema de la gestión de portafolio ha sido estudiando por múltiples
actores y en diferentes industrias. Sin embargo, la mayoría de los trabajos analizados
se enfocan en empresas grandes, mientras que la realidad de una pequeña empresa
difiere considerablemente en cantidad de proyectos y disponibilidad de recursos.
Los resultados de este proyecto contribuyen al campo de la investigación en gestión de

portafolio al verificar su aplicabilidad en el campo de las pequeñas empresas. Así
mismo, pueden servir de apoyo a los responsables de la implementación de la
estrategia, como base para la definición de un proceso de gestión orientado a pymes
que trabajen en función de proyectos.
15
El marco de trabajo planteado tiene por objetivo apoyar a las organizaciones a lograr un
mejor rendimiento, lo que implica el logro de sus objetivos estratégicos. De esta forma
el marco de trabajo generado como parte del proyecto apoyará la mejora de la
productividad y al crecimiento de las pequeñas empresas de desarrollo de software en
Perú. Dado que el 95% de estas empresas son micro y pequeñas empresas (APESOFT,
2015) brindar una herramienta que ayude a mejorar su productividad ayudará también
al desarrollo de la industria de software en Perú con la perspectiva de poder replicarlo
en otros países de la región cuyas características de la industria de software son
similares a las de Perú
16
Capítulo 2. Marco Teórico
El presente proyecto tiene como objetivo desarrollar un marco de trabajo de gestión
estratégica orientado a pequeñas empresas de desarrollo de software. Para lograr este
objetivo es necesario identificar las características y problemas que enfrentan las
pequeñas empresas, así como las prácticas asociadas a la gestión del portafolio de
proyectos.
En el mundo no existe una definición única de lo que constituye una pequeña empresa,
y los factores que afectan a las empresas pueden variar entre industrias, por lo que
como parte del marco teórico se revisaron diferentes propuestas, optando por la
definición de la ISO 29110 como base para el proyecto.
De la misma forma, existen varios estándares y buenas prácticas asociadas a la gestión

del portafolio, pero, como base del proyecto se utilizó la norma ISO 21504 debido al
proceso de consenso entre países utilizado para su elaboración.
En lo que resta del capítulo se desarrolla el marco teórico requerido para apoyar en la
comprensión del problema de investigación. Dados los objetivos del proyecto, este
capítulo se centra en revisar conceptos relacionados con cómo evaluar el rendimiento
de pequeñas empresas, los estándares más conocidos sobre los procesos de gestión
de portafolio de proyectos y la diferencia entre gestión de portafolio y gestión de
múltiples proyectos.
2.1 Pequeña empresa

En el mundo existen diferentes definiciones de lo que se considera una pequeña
empresa. Estas clasificaciones pueden estar basadas en el número de empleados o el
monto de ingresos anuales (MERCOSUR, 1992). De acuerdo a la Unión Europea, una
microempresa se considera aquella con menos de 10 empleados e ingresos de menos
de 2 millones de euros anuales (aproximadamente 2.2 millones en dólares americanos),
mientras que una pequeña empresa se caracteriza por tener menos de 50 empleados y
un monto máximo de ingresos de 10 millones de euros (aproximadamente 11 millones
en dólares americanos) (Union, 2003).
En Estados Unidos, la clasificación de pequeña empresa es diferenciada por sector de

la industria, así por ejemplo, una pequeña empresa dedicada al rubro de desarrollo de
software se considera pequeña si sus ingresos anuales son menores a los 27.5 millones
17
de dólares americanos, mientras que para un hospital, se considera pequeño si sus
ingresos son menores a los 38.5 millones de dólares americanos. (USA SBA, 2012).
En Perú, en cambio, según la ley 30056 (2013) una microempresa se caracteriza por
tener un monto máximo de ventas anuales de 150 Unidades Tributarias
(aproximadamente 180 000 dólares americanos), mientras que una pequeña empresa
puede tener hasta 1700 Unidades Tributarias (aproximadamente 2.1 millones de
dólares).
En el caso de Argentina, se sigue un esquema similar al de USA, diferenciado por

industria, pero con montos tope muy diferentes. En este contexto, una empresa del
sector servicios se considera pequeña si el promedio de sus ingresos anuales no
superan los 8 600 000 pesos argentinos (aproximadamente 598 000 dólares
americanos) (Comisión Nacional de Valores, 2010). En chile, según ley 20.416(2014),
microempresas son aquellas empresas cuyos ingresos anuales por ventas y servicios y
otras actividades del giro no hayan superado las 2.4 unidades de fomento en el último
año calendario (aproximadamente 86 000 dólares americanos), pequeñas empresas
son aquellas con ingresos máximos anuales de 25 unidades de fomento
(aproximadamente 902 000 dólares americanos).
Como se puede apreciar, de la revisión de las diversas definiciones de pyme no hay una
clasificación estandarizada, sin embargo, existen algunas propuestas de
estandarización que podrían aplicar para los países de Latinoamérica.
El Grupo de Países que conforma MERCOSUR estableció un esquema de clasificación

basado en el número de empleados y ventas anuales (MERCOSUR, 1992), el cual se
presenta en la tabla 2.1.
Tabla 2.1 Clasificación de Micro y Pequeña Empresa (MERCOSUR, 1992)
Donde: Coef = 10 x (PO/POm x V/Vm)

PO = Personal ocupado de la empresa.
POm = Personal ocupado de referencia.
18
V = Venta de la Empresa.
Vm = Venta anual de referencia
El problema con este enfoque es que se ve afectado por la variación del tipo de cambio
del dólar estadounidense.
Otra propuesta de estandarización específica, para el sector de desarrollo de software,

se presenta en la norma ISO 29110 (ISO, 2011), en la cual se define una VSE (very
small entity) como una empresa que tiene hasta 25 trabajadores.
Con base en lo anterior, lo primero que se observa es que la definición de pequeñas

empresas en países como Estados Unidos y los Miembros de la Comunidad Europea
presenta diferencias significativas con los países de América Latina, quienes a pesar de
las diferencias presentan mayor similitud en su definición. Esto es de importancia para
el estudio por dos razones principales:
 Sirve como un punto de análisis de la literatura. Dado que mucha de la literatura

encontrada, sobre gestión de portafolio, se enfoca en las economías de Estados
Unidos y Europa, es importante, durante la revisión, considerar el contexto
diferente en que se realizaron dichos estudios.
 El utilizar la definición de la ISO para la clasificación de las empresas, permitirá
realizar una extensión del alcance del presente estudio a Empresas de los países
de la región Sur de Latino América que participaron en la elaboración de la ISO
29110.
2.2 Rendimiento de las empresas
El rendimiento de una empresa, desde una perspectiva general, puede ser definido
como la habilidad de las operaciones para satisfacer las expectativas de los principales
interesados de la organización (Smith & Reece, 1999). Para poder entonces determinar,
si el rendimiento de una empresa puede considerarse satisfactorio, se debe definir
primero lo que constituye el éxito y cómo medirlo (Atkinson, 2006).
Múltiples artículos en la literatura tratan sobre sistemas de medición de desempeño

(Artur & Brito, 2004; Venkatraman & Ramanujam, 1986; Wall & Wood, 2004). En este
19
contexto se requieren métricas que permitan medir la eficacia y/o eficiencia de las
acciones (Tangen, 2003).
La visión más directa, para evaluar el rendimiento organizacional, se basa en la

obtención de indicadores financieros basados en resultados, que se asume reflejan el
cumplimiento de las metas económicas de la empresa. Esto implica examinar
indicadores como crecimiento en ventas, rentabilidad (ROI) o ganancias por acción
(Venkatraman & Ramanujam, 1986).
En esta línea, el estudio de Combs et al., (2005) realiza un análisis de los artículos
publicados en el Strategic Management Journal entre 1980 y 2004 identificando 238
estudios empíricos. Estos estudios utilizaron 56 indicadores diferentes para evaluar el
rendimiento de la organización, sin embargo, el 82% de los casos utilizó métricas
financieras, y especialmente métricas contables (52% de los casos).
En otros estudios, se considera que para evaluar el rendimiento de una organización,

es insuficiente utilizar solo factores financieros, ya que estas medidas están orientadas
internamente y no están vinculadas a la estrategia organizacional (Atkinson, 2006). De
esta forma, se consideran otro tipo de métricas relacionadas con aspectos
operacionales y eficacia de la estrategia. Dentro de este bloque se pueden incluir
métricas, tales como cuota de mercado, introducción de nuevos productos, calidad del
producto, comercialización efectiva, valor añadido de fabricación, y otras métricas de
eficiencia tecnológica (Venkatraman & Ramanujam, 1986).
Bonomi & Ledur (2012) presentan un análisis de dimensiones para evaluar el

rendimiento de una empresa, entre ellas, se incluye la rentabilidad, crecimiento y valor
de mercado. Pero el principal aporte de este estudio es analizar estructuras de segundo
orden que agrupan a las dimensiones de primer orden.
En este aspecto, define dos estructuras de segundo orden:

 Rentabilidad financiera: agrupa aspectos financieros como la rentabilidad, el
crecimiento y el valor de mercado. Esto se ve soportado en el estudio de
Rowe & Morrow (1999).
 Rentabilidad estratégica: también definida como dominio operacional, el cual
incluye los aspectos competitivos no financieros, tales como satisfacción del
cliente, calidad, innovación, satisfacción del empleado y reputación.
20
De otro lado, muchas compañías se centran en utilizar mediciones de rendimiento
interno a expensas de comparaciones externas. Un ejemplo de esto se puede ver en
una compañía que logra reducir sus costos, pero a una velocidad más lenta que sus
competidores (Keegan, Eiler, & Jones, 1989).
En el marco anterior, y desde el punto de vista de la empresa, a fin de controlar su propio

rendimiento, las organizaciones requieren un sistema de control de gestión que permita
asegurar que su estrategia se traduce en acción, y en esta línea, una de las
herramientas más reconocidas es el cuadro de mando integral (BSC por sus siglas en
inglés). Esta herramienta contiene 4 niveles de control (Chenhall, Hall, & Smith, 2010)
representados en 4 dimensiones (Atkinson, 2006) que permiten evaluar el rendimiento
de la organización:
 Perspectiva financiera
 Perspectiva del cliente
 Perspectiva de crecimiento y aprendizaje
 Perspectiva interna de negocio
Desde 1998, el BSC ha sido utilizado por el 60 por ciento de las empresas Fortune 1000
(Atkinson, 2006). Sin embargo, algunos autores mencionan que el BSC no es adecuado
para todas las organizaciones, dado que incluye demasiados indicadores, lo que lo hace
difícil de manejar (Swee & Kormas, 2009).
Específicamente, en el ámbito de investigación, las mediciones requeridas para evaluar

el rendimiento de la empresa pueden basarse en mediciones objetivas o subjetivas.
(Venkatraman & Ramanujam, 1986). Las mediciones subjetivas son de hecho utilizadas
ampliamente en investigaciones y típicamente son interpretadas como equivalentes a
las mediciones objetivas (Wall & Wood, 2004). Un ejemplo de esto se plantea en el
estudio de Roach (2011) quien busca evaluar el impacto de la gestión de productos en
el rendimiento de pequeñas empresas a través de un cuestionario a los directivos de
mayor nivel.
En resumen, podemos observar que si bien es posible evaluar el rendimiento de las

empresas en función solo del desempeño financiero, evaluar el rendimiento
considerando una visión más amplia podría ofrecer una mejor visión hacia el
21
cumplimiento de los objetivos estratégicos, dado que algunas mejoras organizacionales
pueden ser difíciles de cuantificar directamente en términos monetarios (Swee &
Kormas, 2009). Una comparación detallada de modelos de medición de rendimiento,
incluyendo beneficios, limitaciones y aspectos metodológicos clave, puede observarse
en el estudio clásico de Venkatraman & Ramanujam(1986) y en el estudio más reciente
de Ravelomanantsoa, Ducq, & Vallespir (2019).
Dadas las condiciones del proyecto, se optó por realizar la medición del rendimiento
utilizando indicadores financieros y operacionales de fuentes primarias. La ventaja de
esto es que provee una operacionalización detallada del rendimiento de la empresa y
permite analizar la relación entre aspectos financieros y operacionales.
Para poder hacer este análisis, se tomó como base el artículo de Roach (2011), el cual
utiliza un cuestionario web respondido directamente por gerentes senior. La principal
limitante en este caso es la inhabilidad para validar la información con diferentes fuentes,
por lo que para reducir el posible bias se debería recoger información de más de una
persona en cada empresa (Venkatraman & Ramanujam, 1986).
2.3 Factores que afectan el rendimiento de una pequeña empresa

El rendimiento de una empresa puede verse afectado por múltiples factores. En Perú,
un estudio cualitativo, realizado por Avolio, Mesones, & Roca (2011), orientado a
identificar los factores que afectan el crecimiento de las pymes, identificó 14 factores
agrupados en las siguientes categorías:
 Factores administrativos: gestión de recursos humanos, aspectos contables

y financieros, la administración propia de sus negocios y la capacitación.
 Factores operativos: estrategias de marketing, establecimiento de precios,
control de la producción y control de inventarios.
 Factores estratégicos: acceso a capital, falta de una visión de largo plazo y
planeamiento y la investigación y conocimiento de mercados.
 Factores externos: corrupción, informalidad y tecnología. De hecho, en Perú,
la informalidad juega un rol clave, dado que, según un reporte del INEI, para
el 2016, el Perú funcionaba con 6,6 millones de unidades productivas
desenvolviéndose en el sector informal de la economía, las que representan
una quinta parte del producto bruto interno (PBI) del país. Así mismo, el
22
73.2% del trabajo se daba en el empleo informal. (Saavedra, 2016). Ante
este escenario el Ministerio del Trabajo tiene entre sus prioridades al 2021
duplicar el nivel de formalidad (MTPE, 2016).
De otro lado, el estudio de Barcenas, Garcia, & Sanchez, (2009) realizado en México,
menciona que los principales factores que afectan el rendimiento de una pequeña
empresa incluyen:
 Formación y experiencia de los recursos humanos, en particular el gerente
 Planeación estratégica
 Innovación y tecnología
 Certificación de calidad
Finalmente Kelvin Sergeant, especialista en desarrollo sostenible de la Organización

Internacional para el Trabajo sostiene que: (Serveant, 2017)
 El empleo en las pymes se da en trabajo de baja calidad y que requiere bajas
cualificaciones.
 Algunas ofrecen bajos salarios.
 Operan en condiciones de trabajo deficientes e inseguras.
 Se quedan cortos en términos de productividad, competitividad y cuota de
mercado.
Analizando estos estudios, en el contexto de una empresa proyectizada, el control de la

producción, mencionado en el estudio de Avolio, Mesones, & Roca (2011) como factor
operacional, hace referencia al control del grupo de proyectos, lo cual está directamente
relacionado con la gestión del portafolio (Project Management Institute, 2013) y en esa
línea es importante evaluar si el desempeño de los proyectos está positivamente
correlacionado con el rendimiento de la empresa (Rivera-ruiz & Ferrer-moreno, 2015).
Por otro lado, y en relación con el artículo de Barcenas et al. (2009), la implementación
del portafolio de proyectos tiene como objetivo implementar la estrategia organizacional
(Project Management Institute, 2013) y la literatura sugiere que la participación del
responsable de gestionar el portafolio en la elaboración de la estrategia tiene un impacto
positivo (Alsudiri, Al-Karaghouli, & Eldabi, 2013).
23
La innovación, mencionada también en el artículo de Barcenas et al (2009) inicia con un
proceso de selección de proyectos (primer proceso de la gestión de portafolio), lo cual,
según la literatura, constituye una de las mayores dificultades en proyectos de
innovación (Artto, Kulvik, Poskela, & Turkulainen, 2011). En este tipo de proyectos la
naturaleza altamente incierta de las decisiones de asignación de recursos hace que la
búsqueda de un portafolio balanceado sea una tarea más complicada (Teufel, 2011).
Así mismo, esto puede ayudar a contribuir a hacerle frente al hecho de baja
productividad y competitividad mencionada por Serveant (2017).
Con base en lo anterior, se considera que la gestión de portafolio puede constituirse en

una herramienta útil para hacerle frente a los factores que afectan el rendimiento de las
pequeñas empresas. Cabe mencionar que, dentro de este grupo, existe una cantidad
significativa de empresas informales en Perú, sin embargo, el estudio se centró solo en
empresas formales.
2.4 Portafolio de Proyectos

La gestión de portafolio ha sido tratada en múltiples artículos y con relación a múltiples
sectores como se verá en la sección de revisión de la literatura. Algunos sectores, en
que se ha estudiado el tema de gestión de portafolio, incluyen tecnologías de
información (Reyck et al., 2005), industrias de servicios y manufactura (Killen & Hunt,
2010), sector farmacéutico (Bode-Greuel & Nickisch, 2008), energía y petróleo (Cañez
& Garfias, 2006; Wu, Li, Wang, & Huang, 2012), servicios públicos (Daim, Oliver, & Iskin,
2013), administración pública (García-Melón, Poveda-Bautista, & Del Valle M., 2015a),
entre otros. Así mismo, los artículos revisados cubren proyectos de desarrollo de nuevos
productos, así como proyectos de mejora de productos (Kornfeld & Kara, 2011, 2013).
El Project Management Institute define un portafolio como “una colección de programas,

proyectos u operaciones gestionadas en grupo para lograr objetivos estratégicos” (PMI
2013, p. 3). Así mismo, define la gestión de portafolio como “la gestión coordinada de
uno o más portafolios para lograr objetivos y estrategias organizacionales. Incluye
procesos organizacionales interrelacionados, por los cuales una organización evalúa,
selecciona, prioriza y asigna sus recursos limitados para implementar estrategias
organizacionales alineadas con su misión, visión y valores” (PMI, 2013, p. 5).
Por su parte la norma ISO 21504, publicada el año 2015, define un portafolio como
“colección de componentes de portafolios agrupados para facilitar su gestión, para
24
cumplir total o parcialmente un conjunto de objetivos estratégicos de la organización”
(ISO, 2015, p. 1) y la gestión de portafolio como “conjunto de procesos y métodos
organizacionales interrelacionados y por los cuales una organización asigna recursos
para implementar sus objetivos estratégicos. La gestión de portafolio alinea los
componentes del portafolio con los objetivos estratégicos de una organización,
prioridades de las partes interesadas y valores, tales como prácticas de sostenibilidad y
principios éticos” (ISO, 2015, p. 2).
La gestión de portafolio puede ser considerada entonces como un proceso de toma de

decisiones, con tres objetivos principales: maximizar el retorno de la inversión realizada
en el desarrollo de productos, la gestión del riesgo mediante la diversificación de los
tipos de proyectos de la cartera (a lo largo de ciertas dimensiones, tales como
probabilidad de éxito, tipos de tecnología, cantidad de inversión, etc.) y asegurar que el
grupo seleccionado de proyectos contribuye a implementar la estrategia de negocio de
la empresa en términos de líneas de productos, mercados, plataformas tecnológicas,
etc. (Gutiérrez & Magnusson, 2014).
Históricamente, los temas relacionados con la gestión de portafolio estuvieron dirigidos

y mantenidos en secreto por los altos directivos. Para 1990, la mayor parte de estos
temas se mantenían a alto nivel, pero había participación de los niveles medios. En la
actualidad, se considera productivo el involucramiento de los gerentes de proyecto y las
Oficinas de Gestión de Proyectos en la elaboración del portafolio, así mismo, la gestión
de proyectos está presente en todos los niveles de la organización (Ranf, 2011).
Resumiendo, el principal objetivo de la gestión de portafolio se relaciona con el

cumplimiento de los objetivos estratégicos y el rendimiento de la organización. por lo
que es de esperar que en las organizaciones existan personas que desempeñen este
rol de manera parcial o total en los niveles intermedios de la empresa.
2.5 Procesos de la gestión de portafolio

La gestión de portafolio involucra identificar, priorizar, autorizar, gestionar y controlar los
proyectos y programas, así como los riesgos, recursos y prioridades asociadas (Young,
Owen, & Connor, 2011). Cabe resaltar el proceso de priorización de proyectos, el cual
consiste en alinear la prioridad a los proyectos dentro de un portafolio, basado en un
conjunto de criterios de prioridad. Esta priorización es un proceso multidimensional
25
debido a que involucra un amplio rango de criterios: técnicos, económicos, políticos,
sociales y del entorno (García-Melón, Poveda-Bautista, & Del Valle M., 2015b).
Formalmente la norma ISO 21504 (2015) identifica las prácticas descritas en la tabla
2.2
Tabla 2.2 Prácticas de Gestión de Portafolio según ISO 21504 (basado en ISO, 2015)
Procesos Prácticas
Definir el portafolio Identificar objetivos del portafolio
Identificar componentes potenciales del Identificar componentes
portafolio
Definir el plan de portafolio Definir el plan
Evaluar y seleccionar componentes del Evaluar estado actual
portafolio Seleccionar componentes
Validar alineamiento con los objetivos Alinear con objetivos estratégicos
estratégicos Mantener alineamiento con riesgos y
capacidad de recursos
Documentar resultados del alineamiento
Evaluar y reportar el desempeño del Establecer línea base de desempeño
portafolio Gestionar el desempeño del portafolio
Reportar el desempeño del portafolio
Gestionar la integración de beneficios
Balancear y optimizar el portafolio Optimizar componentes
Mantener el portafolio
Optimizar recursos
Gestionar riesgos
Por su parte, el Estándar para la Gestión de Portafolio de Proyectos del Project

Management Institute (PMI, 2013) define 5 áreas de conocimiento, cada una de las
cuales identifica un conjunto de prácticas según se muestra en la tabla 2.3.
26
Tabla 2.3 Prácticas de Gestión de Portafolio según PMI (basado en Project
Management Institute, 2013b)
Área de Conocimiento Práctica

Desarrollar el plan del portafolio
Desarrollar el acta de constitución del
portafolio
Definir el roadmap del portafolio
Gestión Estratégica del Portafolio Gestionar el cambio
Desarrollar el plan de gestión del portafolio
Definir el portafolio
Optimizar el portafolio
Autorizar el portafolio
Gobernanza del Portafolio Proveer supervisión
Desarrollar el plan de gestión del desempeño
Gestión de desempeño del Gestionar la provisión y demanda
portafolio Gestionar el valor del portafolio
Desarrollar el plan de gestión de
Gestión de comunicación del comunicaciones
portafolio Gestionar la información del portafolio
Desarrollar el plan de gestión de riesgos
Gestión de riesgos del portafolio Gestionar los riesgos
Como puede verse, de las tablas 2.2 y 2.3, los dos estándares poseen muchas cosas
en común. Para este trabajo, se tomó como base las prácticas definidas en la norma
ISO 21504 por considerarse un poco más general y debido a que el proceso de
consenso utilizado para desarrollar normas ISO requiere haber tomado en cuenta las
opiniones de todos los países miembros de ISO.
2.6 Gestión de múltiples proyectos (Multiple Project Management)

Muchos gerentes consideran la gestión de múltiples proyectos como simplemente la
gestión de una lista de proyectos individuales, en lugar de una operación compleja, con
una capacidad y carga de trabajo dada (Hans, Herroelen, Leus, & Wullink, 2007).
27
En algunos casos, los términos de gestión de múltiples proyectos y gestión de portafolio
se toman como términos iguales; sin embargo, existe una diferencia entre ambos
términos. La gestión de múltiples proyectos se orienta a decisiones tácticas y operativas
de asignación y programación de recursos, y es trabajo del gerente de proyecto o
gerente de recursos. La gestión de portafolio, por otro lado, se relaciona con la selección
y priorización de proyectos con un foco en decisiones de mediano y largo plazo (Hans
et al., 2007).
A pesar, que en estricto, estos dos conceptos son diferentes, los mismos están
estrechamente relacionados, ya que la decisión de incluir un nuevo proyecto no solo se
relaciona con su contribución a la estrategia o valor financiero, sino a como el proyecto
candidato interactúa con el portafolio existente, en términos de riesgos, cronograma o
presupuesto (Pajares & López, 2014).
Es importante esta distinción para el presente estudio, a fin de resaltar los aspectos
estratégicos de la gestión de portafolio, mientras que los aspectos técnicos (que forman
parte del proceso de Multiple Project Management), dependerán más del enfoque de
gestión de proyectos que utilice la empresa.
28
Capítulo 3. Revisión de la literatura
La revisión de literatura constituye un paso imprescindible en toda investigación, en
cuanto permite identificar y analizar las investigaciones previas realizadas sobre el tema
en estudio. En este contexto, una revisión sistemática es una forma de estudio
secundario, ya que utiliza los estudios primarios (Kitchenham, 2004).
Como un paso inicial de la investigación se plantea en este capítulo el desarrollo de una

revisión sistemática de literatura, con el objetivo de analizar las investigaciones previas
realizadas sobre la aplicación de gestión de portafolio de proyectos y su impacto sobre
los objetivos de negocio de la empresa.
En la fase de ejecución de la revisión, se analizaron 63 artículos, provenientes de las

bases de datos Scopus, ISI Web of Science, ScienceDirect, Proquest y JStor. Entre los
principales resultados se obtiene que el tema de gestión de portafolio ha sido tratado
previamente en múltiples investigaciones, sin embargo, el impacto sobre el rendimiento
en pequeñas empresas es un tema poco explorado.
Lo que resta de este capítulo describe el protocolo seguido para la revisión y los
resultados encontrados basados en las preguntas de investigación agrupándolos en
cómo evaluar el éxito de la gestión de portafolio, los desafíos y factores de éxito para la
gestión de portafolio y la evaluación del impacto de gestión de portafolio de proyectos
sobre el rendimiento de las empresas.
3.1 Método de la revisión

Para la revisión de la literatura se utilizó el método de revisión sistemática. Una revisión
sistemática es una revisión de una pregunta claramente formulada que utiliza métodos
sistemáticos y explícitos para identificar, seleccionar y evaluar críticamente la
investigación relevante, y para recopilar y analizar datos de los estudios que se incluyen
en la revisión (Moher, Liberati, Tetzlaff, & Altman, 2009). La revisión sistemática es una
forma de estudio secundario, es decir que presenta un análisis de los estudios primarios
publicados por otros investigadores, utilizando las siguientes fases (Kitchenham, 2004):
 Planificación: incluyendo la definición de las preguntas de investigación y el

protocolo de revisión.
 Ejecución de la revisión: incluyendo la obtención de publicaciones de las bases
de datos científicas seleccionadas, selección de publicaciones, evaluación de la
calidad de las publicaciones, extracción de datos y síntesis.
29
 Reporte de la revisión: en esta fase se elaboró el presente capítulo con el
análisis de las publicaciones seleccionadas.
3.1.1 Protocolo de la revisión

El protocolo de revisión describe los fundamentos, hipótesis y métodos planificados de
la revisión. Debe prepararse antes de comenzar una revisión y usarse como una guía
para llevar a cabo la revisión (Kitchenham, 2004; Moher et al., 2009). Para el presente
proyecto de investigación, el protocolo de revisión incluye la definición de las preguntas
de investigación, la selección de fuentes de datos, la definición de cadenas de búsqueda
y la identificación de criterios de inclusión y exclusión. Estos elementos son descritos en
las siguientes secciones.
3.1.2 Preguntas de investigación

Las preguntas de investigación que guían esta revisión sistemática son:
1. ¿Cómo se evalúa el éxito de la gestión de portafolio de proyectos?
2. ¿Qué variables influyen en el éxito en la gestión de portafolio de proyectos?
3. ¿Cómo los resultados de la gestión de portafolio de proyectos afectan el
rendimiento de la organización?
3.1.3 Fuentes de datos

Para la búsqueda de las publicaciones, se decidió emplear cinco bases de datos
científicas asociadas al tema de administración y gestión. Las bases de datos fueron
Scopus, ISI Web of Science, ScienceDirect, Proquest y JStor.
3.1.4 Cadenas de búsqueda

La cadena de búsqueda utilizada en las bases de datos seleccionadas fue ("project
portfolio" AND ("business strategy" OR "business objectives" OR "strategy
implementation" OR "firm performance"))
3.1.5 Criterios de inclusión

Los criterios de inclusión definidos para la revisión sistemática fueron:
CI1) Solo se incluyeron artículos publicados en revistas científicas o congresos con
anales indexados que hayan sido evaluados por pares.
CI2) Solo se incluyeron artículos escritos en inglés.
CI3) Se incluyó artículos que relacionen la gestión del portafolio de proyectos con
los objetivos estratégicos de la organización.
30
3.1.6 Criterios de exclusión
Los criterios de exclusión definidos para la revisión sistemática fueron:
CE1) No se incluyeron artículos enfocados en la gestión de proyectos individuales.
CE2) No se incluyeron artículos que se enfoquen solo en el uso de herramientas
de software para la gestión de portafolio.
CE3) No se incluyeron artículos cuyo principal enfoque sea la presentación de un
método específico para la selección de proyectos.
3.2 Resultados de la revisión

La búsqueda se realizó el 13 de agosto del 2020 sobre las bases de datos seleccionadas
y utilizando la cadena de búsqueda mostrada en la sección 3.1.4. Los resultados se
muestran siguiendo las recomendaciones de Moher et al. (2009).
Figura 3.1 Proceso de Selección de Artículos
Como se puede apreciar en la figura 3.1, la búsqueda inicial, aplicando los criterios de
inclusión CI1 (publicados en revistas o anales de congreso indizados) y CI2 (artículos
31
publicados en inglés), obtuvo 1010 resultados entre las 5 bases de datos consultadas.
Una revisión rápida identificó 70 artículos duplicados, por lo que se inició la revisión de
los títulos y abstracts con 940 artículos. Durante esta revisión, se evaluó, en base al
título y abstract, que el artículo cumpliera con el criterio de inclusión CI3 (artículos que
relacionen la gestión del portafolio de proyectos con los objetivos estratégicos) y los
criterios de exclusión para descartar artículos que no apoyen a esta revisión de
literatura. El paso anterior concluyó con 291 artículos, que fueron revisados en su
totalidad para verificar el aporte a la revisión sistemática. Finalmente se obtuvieron 66
artículos.
Cabe mencionar que para esta revisión sistemática se decidió no excluir artículos por
antigüedad, sin embargo, el análisis bibliométrico mostrado en el anexo 13 permite ver
que el 90% de los artículos seleccionados tiene una antigüedad menor a 10 años,
sugiriendo que el tema ha ido suscitando interés en los años recientes.
El análisis de los artículos seleccionados se presenta a continuación, agrupados en

secciones que buscan responder a las preguntas de investigación. Cabe también
mencionar, que el mayor número de artículos encontrados se enfocaban en las áreas
de tecnologías de información y construcción.
La lista completa de artículos incluidos en esta revisión sistemática de la literatura se

presenta en el anexo 13 – análisis bibliométrico junto con el número de citas para cada
documento. Además, este apéndice muestra la cantidad de artículos por revista que
indica el factor de impacto de cada revista y la cantidad de artículos por año.
La utilidad de este análisis bibliométrico es validar la calidad de los artículos incluidos,

lo cual se puede apreciar en que alrededor del 75% de artículos han sido citados más
de 15 veces y el 25% cuentan con más de 100 citaciones. Además, la mayoría de
artículos provienen de revistas indizadas especializadas en el tema.
3.3 Evaluación del éxito de la gestión de portafolio

Teniendo en cuenta que la función de la gestión de portafolio es apoyar la
implementación de la estrategia de la organización, es importante entender cómo se
mide el éxito de una organización. En este contexto, la mayoría de organizaciones
32
utilizan solo métricas financieras para medir el éxito, sin embargo, varios estudios han
mostrado que estas métricas solas son insuficientes como indicadores del éxito a largo
plazo, lo cual lleva al desarrollo de modelos de medición de éxito multidimensionales.
(Meskendahl, 2010). En esta misma línea, la evaluación del éxito del portafolio de
proyectos debería realizarse teniendo en cuenta un modelo multidimensional. Cabe
resaltar también que el éxito en la gestión de portafolio debería ser definido teniendo en
cuenta la obtención de metas desde diferentes perspectivas de los interesados
(Patanakul, 2015).
El éxito de un proyecto puede medirse sobre la base de varios factores, entre los cuales
cabe resaltar el éxito económico y la preparación para el futuro (Meskendahl, 2010).
Siendo un poco más específico, se pueden identificar los siguientes factores que
permitan evaluar la gestión coordinada de múltiples proyectos (Patanakul & Milosevic,
2009):
a) Productividad de los recursos
b) Aprendizaje organizacional
c) Time-to-market
d) Satisfacción del cliente
e) Crecimiento y satisfacción personal
En otros estudios, Patanakul (2015) citando los trabajos de Cooper sugiere que el
desempeño del portafolio puede ser medido a partir de:
a) Un número apropiado de proyectos en el portafolio para los recursos
disponibles.
b) Llevar a cabo los proyectos en el plazo establecido y de manera eficiente en
tiempo.
c) Contar con un portafolio de proyectos de alto valor, que sea balanceado,
alineado con la estrategia de negocios y cuya descomposición de gastos refleje
la estrategia de negocios y las prioridades estratégicas.
Lo anterior, lleva a plantear un modelo de atributos de eficacia de la gestión de portafolio

basado en atributos estratégicos y operacionales (Patanakul, 2015):
Atributos estratégicos
a) Alineamiento estratégico: alineamiento del portafolio con la dirección estratégica
de la organización.
33
b) Adaptabilidad a cambios internos y externos: habilidad para hacer frente a
riesgos e incertidumbres.
c) Valor esperado: consideración de proyectos con un alto valor esperado.
Atributos operacionales
a) Visibilidad de Proyectos: grado de exposición de proyectos a los interesados.
b) Transparencia en toma de decisiones: una clara comprensión de las razones
detrás de las decisiones.
c) Predictibilidad de la entrega de proyectos: habilidad para predecir el desempeño
del proyecto.
Así mismo, algunos artículos consideran a la sostenibilidad como un aspecto clave que
debe ser tomado en cuenta para la evaluación del éxito del portafolio de proyectos
(Brook & Pagnanelli, 2014; Hoffmann, Müller, & Ahlemann, 2017; Khalili-Damghani &
Tavana, 2014; Ngqulunga & Walwyn, 2018).
Cabe mencionar también, que para evaluar el éxito del portafolio, con base en los
aspectos anteriores, es necesario contar con datos confiables y estructurados, los
cuales no siempre están disponibles (Bruno De Souza, Carneiro, Puc-Rio, & Bandeira-
De-Mello, 2015).
De esta forma, la literatura ofrece un conjunto de indicadores que pueden ser utilizados
para evaluar la eficacia de un portafolio de proyectos, los cuales incluyen aspectos
estratégicos y operativos. Estos últimos más relacionados con la gestión de los
proyectos específicos.
Cabe mencionar en esta sección, que desarrollar capacidades en gestión de proyectos

constituye un prerrequisito para una gestión de portafolio eficaz (Inger Bergman, Sven
Gunnarson, 2013). Así mismo, la flexibilidad es una característica importante a fin de
hacerle frente a los entornos y condiciones cambiantes (Gutiérrez & Magnusson, 2014).
Jerbrant (2014) presenta un modelo que ayuda a comprender las diversas etapas de
maduración para organizaciones basadas en proyectos. Bergman y Gunnarson (2013)
presentan un modelo similar. En ambos casos, se ratifica lo que la literatura menciona,
que la gestión de una organización basada en proyectos, a menudo implica cambios
estructurales (Kaiser, El Arbi, & Ahlemann, 2015; Killen, Hunt, & Kleinschmidt, 2008). A
34
continuación, se resume el modelo propuesto por Jerbrant, que indica los cambios por
los que pasa una organización en su proceso de maduración, haciendo especial énfasis
en el manejo de la incertidumbre:
1) Estructuración en proyectos individuales (“Proyectización”): Esto implica la

separación de funciones en varios proyectos que son vistos como una forma eficaz
de obtener las metas organizacionales, pero, cuando los proyectos que requieren
coordinación entre áreas funcionales se vuelven algo común, se generan problemas
de coordinación.
2) Configuración multiproyecto: En este nivel, la gestión de incertidumbre se centra en
gestionar eventos inesperados que ocurren debido al síndrome de asignación de
recursos, falta de comunicación, sobrecarga de gerentes de proyecto y
fragmentación de la organización.
3) Establecimiento de la Gestión de Portafolio: Muchas organizaciones se apoyan en
el establecimiento de una PMO para cubrir con esta etapa. A este punto, se definen
rutinas para trabajar la gestión de portafolio.
4) Organizaciones basadas en proyectos: Se obtiene un diseño óptimo de estructura
organizacional basada en proyectos. La alta dirección comprende su
responsabilidad en la gestión del portafolio y su alineamiento con la estrategia,
adaptando la gestión de recursos humanos de la organización, así como enfatizando
la gestión de incertidumbre y liderazgo situacional. Esto es importante, dado que la
falta de apoyo de la alta dirección es uno de los principales obstáculos para la
implementación de la gestión de portafolio (Hadjinicolaou & Dumrak, 2017).
En resumen, se observa que la evaluación del éxito de la gestión de portafolio de

proyectos debería incluir métricas financieras, pero para tener una evaluación más
completa se requiere un esquema multidimensional que permita evaluar aspectos
estratégicos incluyendo la sostenibilidad de los resultados.
Así mismo se observa que el desarrollo de capacidades de gestión de portafolio conlleva

un proceso de maduración, que inicia con la gestión de proyectos individuales. De esta
forma la gestión de proyectos constituye un paso previo antes de poder implementar
gestión de portafolio. Esto es relevante para el estudio en cuanto establece la
necesidad de analizar la forma en que las empresas gestionan sus proyectos
individuales como un paso previo a plantear un esquema de gestión de portafolio.
35
3.4 Desafíos y problemas en la gestión de portafolio
La gestión de portafolio como cualquier otro proceso organizacional enfrenta desafíos y
problemas, los cuales se resumen a continuación.
Las interdependencias que surgen entre diferentes proyectos, así como entre proyectos
y su entorno, son significativamente difíciles (S. Bathallath, Smedberg, & Kjellin, 2019;
Sameer Bathallath, Smedberg, & Kjellin, 2016; Jerbrant & Gustavsson, 2013; Jerbrant,
2014; Thiry & Deguire, 2007). En una organización, pueden de hecho existir varios tipos
de portafolios (portafolio de ideas, portafolios de recursos, portafolio de activos), con los
cuales se requiere una fuerte interacción (M. Young et al., 2011). Así mismo, cada área
estratégica puede manejar su propio portafolio, pero este debe estar alineado con el
portafolio de la organización (Ilyin & Teslya, 2016). En esta misma línea, una de las
principales razones, por las cuales puede fracasar un portafolio, es por tener
demasiados proyectos y pocos recursos (Buys & Stander, 2010).
Los mayores desafíos se presentan en proyectos de desarrollo de nuevos productos,

tema ampliamente cubierto en la literatura (Claus Beringer, Jonas, & Kock, 2013;
Cooper, Edgett, & Kleinschmidt, 2016; Killen, Hunt, Kleinschmidt, & Hunt, 2008;
Weissenberger-Eibl Teufel, 2011). En este tipo de proyectos, la naturaleza altamente
incierta de las decisiones de asignación de recursos hace que la búsqueda de un
portafolio balanceado sea una tarea aún más complicada (Weissenberger-Eibl Teufel,
2011). En particular, al tratarse de innovaciones radicales, es necesario considerar la
evaluación de los proyectos en relación con la selección de tecnologías, mercado a ser
desarrollado, tamaño del mercado potencial, costos de buscar la innovación, costos
operativos, entorno político, impuestos, rentabilidad, estructura organizacional, entorno
económico y competencia (Paulson, Connor, & Robeson, 2000), lo cual implica
decisiones en varios niveles de la organización.
La gestión de riesgos es otro factor que afecta la gestión de portafolios. Este tema es
cubierto por múltiples autores (Costa, Barros, & Travassos, 2007; Drake & Byrd, 2006;
Ghasemi, Sari, Yousefi, Falsafi, & Tamošaitiene, 2018; Sanchez, Robert, Bourgault, &
Pellerin, 2009; Sanchez, Robert, & Pellerin, 2008; Sheykh, Azizi, & Sobhiyah, 2013;
Tang, Zhou, & Cao, 2017; Teller & Kock, 2013; Teller, Kock, & Gemünden, 2014) y forma
parte de las áreas de conocimiento en la edición actual del Estándar de Gestión de
Portafolio del Project Management Institute (PMI, 2013).
36
En general, los riesgos al portafolio pueden ser agrupados en riesgos estratégicos, de
exposición a la tecnología, cambio organizacional, gestión, comunicaciones, legal,
organización de proyecto, gestión de proyectos y complejidad de proyectos (Sheykh et
al., 2013). Así mismo, las fuentes de riesgo de la cartera de proyectos se pueden
clasificar como 'sistemáticas' y 'no sistemáticas', y deben considerar cuatro categorías
de cartera de riesgo operacional para caracterizar y en última instancia, evaluar el riesgo
de la cartera de proyectos: 'nivel de gestión de la cartera', 'condiciones ambientales',
'interacciones del proyecto' y 'procesos internos' (Micán, Fernandes, Araújo, & Ares,
2019).
Si bien los procesos de gestión de portafolio incluyen una revisión periódica, existe la
asunción de que no se producirán cambios significativos al portafolio hasta la siguiente
revisión periódica (que podría ser trimestral, semestral o anual) y que los proyectos
individuales tratarán con los riesgos e incertidumbres en el curso de su ejecución (Petit,
2012). Una perspectiva de gestión de la incertidumbre en el contexto de la gestión de
portafolio llama la atención sobre la necesidad de entender y gestionar la variabilidad en
las actividades de la organización que tienen impactos en una serie de proyectos
(Pedersen & Nielsen, 2011). Esta perspectiva pone de relieve la necesidad de poner en
marcha enfoques y técnicas para abordar algunos aspectos de incertidumbre en
proyectos, fuera del contexto de proyectos individuales. Esto puede incluir incertidumbre
técnica, incertidumbre del mercado, incertidumbre organizacional e incertidumbre
financiera (Petit, 2012).
El deseo de evitar la ineficiencia y la urgencia de manejar la incertidumbre y los riesgos

incrementa el grado de control y burocratización, lo cual a menudo reduce la creatividad
y flexibilidad (Jerbrant & Gustavsson, 2013; Jerbrant, 2014). Esta incertidumbre surge
debido a la complejidad de las tareas en combinación con la complejidad de la
organización (Jerbrant & Gustavsson, 2013). Así mismo, plantea un problema adicional
para las organizaciones que no utilizan métodos tradicionales, como es el caso de los
métodos ágiles (Stettina & Hörz, 2015; Sweetman & Conboy, 2018).
De otro lado, la toma de decisiones organizacionales, como selección de proyectos y

asignación de recursos, es un tema inherentemente político en naturaleza, y por lo tanto
no puede ser adecuadamente gestionado sin tener en cuenta esta dimensión del
proceso (Hadjinicolaou & Dumrak, 2017; Pedersen, 2016; Weissenberger-Eibl Teufel,
2011). Aún más, uno de los principales desafíos que dificultan el éxito de la cartera de
37
proyectos es que no se dispone de recursos suficientes para lograr los objetivos de la
cartera de proyectos (NYANDONGO & MSHWESHWE, 2020). En este mismo aspecto,
la decisión de terminar o no anticipadamente un proyecto influye en el éxito del portafolio
(Li & Chi, 2013; Barbara Natalie Unger, Kock, Gemünden, & Jonas, 2012).
Finalmente, la inclusión de gestión de portafolio en una organización puede incluir

desafíos importantes, tales como alineamiento con los procesos existentes y
compromiso de los participantes (Stettina & Hörz, 2015). Así mismo, el alineamiento
estratégico, el control y la comunicación (Dooley, Lupton, & O’Sullivan, 2005), así como
el aprendizaje y gestión del conocimiento, representan desafíos para la implementación
de la gestión de portafolio (Dooley et al., 2005; Killen & Hunt, 2010; Rosselet, Jolliet, &
Wentland, 2009).
En resumen, la aplicación exitosa de las prácticas de gestión de portafolio enfrenta

múltiples desafíos, entre los que destacan la definición del número adecuado de
proyectos sobre la base de los recursos disponibles, la gestión de riesgos e
incertidumbre del portafolio, la definición de los procesos y la gestión de los
involucrados. Esto último incluye temas de comunicación, capacitación, así como temas
políticos que afectan las decisiones sobre asignación de recursos.
Estos factores son relevantes en cuanto cada empresa es diferente, y la implementación

de gestión de portafolio se ve afectada por aspectos técnicos y humanos. Estos últimos
se relacionan con la cultura de la organización, y mal gestionados pueden afectar
negativamente la implementación de la gestión de portafolio, a pesar de contar con un
proceso adecuadamente definido y la tecnología de soporte.
3.5 Factores de éxito en la gestión de portafolio

En base a la revisión de los artículos, se han encontrado diversos factores que pueden
afectar al éxito de la gestión de portafolio y su consiguiente impacto en el logro de los
objetivos estratégicos.
En relación con el alineamiento del portafolio con los objetivos estratégicos se pueden
identificar algunos factores internos y externos que afectan el alineamiento. Los factores
internos incluyen la comunicación, soporte ejecutivo, involucramiento de los gerentes de
proyecto en el desarrollo de la estrategia, competencias de liderazgo del gerente del
38
proyecto, competencias del equipo de proyecto, recursos del proyecto y herramientas
de gestión de proyecto. Así mismo, el involucramiento de los gerentes de línea y altos
directivos afectan el éxito de la gestión del portafolio (Claus Beringer et al., 2013;
Hermano & Martín-Cruz, 2016; Yang & Xu, 2017).
Asociado a lo anterior, otros autores sugieren que el empoderamiento de los gerentes

de portafolio influye positivamente en los resultados (Jonas, 2010), y que el liderazgo
transformacional puede influir en el éxito de la cartera de proyectos, en condiciones
mediadoras de orientación estratégica a la innovación y función moderadora de la
gobernanza de la cartera (Zaman, Nadeem, & Nawaz, 2020).
Cabe mencionar también, que el nivel de involucramiento de cada uno de los

interesados puede variar según la fase en el proceso en el que se encuentran. Por
ejemplo, el estudio de Beringer, Jonas, y Gemunden (2017) encontró que la Alta
Dirección domina la estructuración del portafolio, la gerencia media lidera la asignación
de recursos y el gerente de portafolio tiende a dominar la dirección del portafolio. Esto
a su vez sugiere la necesidad de roles y responsabilidades claras en la gobernanza de
la gestión de proyectos organizacional (Hyväri, 2016).
Los estudios de Lerch y Spieth (2013; 2014) afirman también que la percepción y
satisfacción de la alta gerencia influye positiva o negativamente en el éxito del portafolio.
Entre los factores externos se incluyen el mercado dinámico, proveedores y contratistas

y agencias del gobierno (Alsudiri et al., 2013).
Así mismo, algunos estudios sugieren que la cultura nacional y corporativa tiene un
impacto sobre el éxito de la gestión del portafolio (Killen, Hunt, Kleinschmidt, et al.,
2008; Killen & Kjaer, 2012; Barbara N. Unger, Rank, & Gemünden, 2015).
Cabe mencionar, que previo a seleccionar los proyectos del portafolio es necesario
generar las ideas o propuestas. Esto corresponde a la fase de front end. Estudios
relacionados sugieren que el éxito de esta fase tiene relación con el éxito del portafolio
de proyectos (Wilderich Heising, 2012; Kock, Heising, & Gemünden, 2015, 2016).
Además, mencionan que este efecto se hace más fuerte en empresas con portafolios
más grandes, portafolios con mayor interdependencia entre proyectos y en empresas
con alta orientación hacia el riesgo (Kock et al., 2016).
39
El proceso de control es otro aspecto crítico para el éxito del portafolio. En este aspecto,
es necesario monitorear las desviaciones reportadas en los hitos y el riesgo económico
positivo y negativo, así como identificar la flexibilidad económica del portafolio para la
ejecución de pagos (Eik-Andresen, Johansen, Landmark, & Sørensen, 2016).
En general, se establece que la toma de decisiones a nivel del portafolio requiere

coordinar el involucramiento de todos los participantes y que esta tarea es más
importante que el desarrollo de métodos sofisticados (Weissenberger-Eibl Teufel, 2011).
En esta misma línea, el estudio de (Voss, 2012) resalta la importancia de gestionar las
relaciones con clientes, a fin de que el portafolio genere el mayor valor.
Esto implica también la participación del área de marketing (responsable del contacto
con los clientes). En un estudio posterior (Voss & Kock, 2013) ratifica que el valor de
la relación con el cliente (desde y hacia) afecta positivamente el éxito del portafolio y
agrega que la turbulencia económica modera positivamente este efecto.
En dos artículos revisados (Kaiser et al., 2015; Martinsuo, 2013) se analiza que la
implementación exitosa de PPM en una organización se ve impactada por un exitoso
cambio estructural. En particular, Kaiser et al (2015) enfatizan la importancia de una
adecuada centralización de procesos de información importante, que permita tener
información de mayor calidad y en el momento oportuno para la toma de decisiones.
Esto puede dar lugar, entre otras cosas, a la creación de una PMO (Oficina de Gestión
de Proyectos) y PPMO (Oficina de Gestión de Portafolio) que puedan ejercer funciones
de coordinación, control y apoyo (Barbara Natalie Unger, Gemünden, & Aubry, 2012).
Sobre este tema, las Prácticas de Oficinas de Gestión de Proyectos (PMOP por sus
siglas en inglés) tienen un efecto directo en la gestión del portafolio de proyectos, pero
la presencia de una Oficina de Gestión de Proyectos formal no necesariamente indica
que las PMOP se apliquen de manera más efectiva dentro de la organización (Ichsan &
Sadeli, 2020).
El trabajo de gestionar múltiples proyectos requiere un balance entre la flexibilidad y la

estructura en los procesos de gestión (Bruno De Souza et al., 2015; Jerbrant &
Gustavsson, 2013) . En este contexto la improvisación se entiende como la posibilidad
de crear un espacio de acción, dejando de lado las presiones de tiempo, estructuras
formales racionales y rígidas. En este sentido, el éxito de la gestión de portafolio no
40
depende de un proceso completamente racional, sino también de un tema de
negociación y habilidades (Martinsuo, 2013).
Finalmente, de la observación de reuniones de gestión de portafolio (Christiansen &

Varnes, 2008) se identifican algunos factores adicionales que pueden influir en el éxito
de la gestión de portafolio:
 Comprender que las reglas pueden ser negociadas y que los tomadores de
decisiones son más propensos a cumplir con las identidades cuando se ven a sí
mismos como eficaces.
 Tener en cuenta que la aprobación social en la organización se gana cumpliendo las
expectativas de otros.
 Tener en cuenta que el contexto organizacional y su historia influencian las
decisiones.
 Aprender de las experiencias pasadas.
A pesar que no es el único factor asociado al éxito del proyecto, cabe mencionar también
que el uso de un sistema de información adecuado ayuda a soportar el proceso de la
gestión de portafolio (Alsudiri et al., 2013).
De lo anterior, se observa que la gestión del portafolio solo puede generar resultados
positivos, siempre y cuando vaya acompañada de otros factores internos y externos.
Dado que la organización no tiene control sobre los factores externos, se debe trabajar
sobre los factores internos. Estos factores internos pueden ser agrupados en factores
humanos (cultura organizacional, comunicación, involucramiento de los interesados,
relación con el cliente), y factores relacionados con la estructura organizacional y con
los procesos, en especial el proceso de control, que, a su vez, se ve favorecido por el
uso de un sistema de información de proyectos. La ausencia de estos factores, por el
contrario, puede llegar a convertirse en un obstáculo.
Así mismo la implementación de gestión de portafolio de proyectos requiere la

interacción con diferentes áreas de la empresa, como es el caso de marketing. Esto,
sumado a los factores humanos descritos anteriormente, implica que la implementación
exitosa de la gestión de portafolio de proyectos debería llevar consigo un proceso de
gestión de cambio organizacional para hacer frente a los factores humanos y
estructurales a través de la flexibilidad y negociación.
41
3.6 Impacto de la gestión de portafolio en los resultados de la empresa
Dentro de los artículos revisados, es común encontrar referencias a teorías

correspondientes a la gestión estratégica tales como Resource Based View (RBV),
Dinamyc Capabilities, Organizational Theory, etc.
Una de las que más se repite, en los artículos revisados, es la teoría de capacidades
dinámicas. Desde este ángulo, se busca comprender cómo la gestión de portafolio
puede ser considerada una capacidad dinámica y cómo el uso de esta perspectiva, junto
con RBV ayuda a comprender como la gestión de portafolio puede contribuir a generar
una ventaja competitiva para la organización (Biedenbach & Müller, 2012; Daniel, Ward,
& Franken, 2014; Jerbrant, 2014; Killen, Hunt, & Kleinschmidt, 2008; Killen & Hunt, 2010;
Killen, Jugdev, Drouin, & Petit, 2012; Petit, 2012; Sicotte, Drouin, & Delerue, 2015).
Entendiendo capacidad como un tipo específico de recurso, que permite a la

organización desplegar otros recursos para realizar actividades que generen los
resultados esperados, la capacidad de gestión de portafolio se define como una
combinación de estructura organizacional, procesos específicos y las personas
involucradas en la gestión del portafolio (Killen, Hunt, & Kleinschmidt, 2008).
Las rutinas organizacionales, tales como los procesos de gestión de portafolio,

constituyen una capacidad dinámica debido al rol que juegan en la habilidad de la
organización para continuamente alinear proyectos a la estrategia organizacional
deliberada y emergente (Killen, Hunt, & Kleinschmidt, 2008; Kopmann, J., Kock, A.,
Killen, C. P., & Gemünden, 2017).
En este contexto, se establece que las capacidades de gestión de portafolio de

proyectos de innovación ayudan a mejorar la tasa de éxito de proyectos de innovación
de productos y servicios, al proveer un entorno holístico y sensible para la toma de
decisiones, a fin de maximizar el valor a largo plazo de las inversiones en innovación
(Killen & Hunt, 2010).
Así mismo, se resalta el aprendizaje corporativo y los procesos de mejora involucrados

en la gestión de portafolio (Petit, 2012). El resultado de una inversión en aprendizaje
eficaz será un portafolio de proyectos alineado, balanceado, con alto valor y con
recursos adecuados que proveerá el mayor retorno en la inversión en aprendizaje y en
42
la inversión en proyectos (Killen, Hunt, & Kleinschmidt, 2008). En otras palabras, la
capacidad de estructurar el portafolio de proyectos constituye una capacidad dinámica,
que cuando se encuentra alineada con la orientación estratégica conlleva a mejores
resultados del portafolio (Meskendahl, 2010).
De los artículos anteriores, se observa que la gestión de portafolio tiene un valor

estratégico para la empresa al garantizar el alineamiento de los proyectos con los
objetivos, lo cual a su vez puede generar una ventaja competitiva.
Muchos artículos sugieren la importancia de la gestión de portafolio para la

implementación de la estrategia de la organización. Si embargo, de los artículos
revisados, solo algunos utilizan métodos cuantitativos para analizar el impacto. Dentro
de este grupo, Rungi (2014) evalúa el impacto de las capacidades en gestión de
proyectos sobre el desempeño organizacional, y dentro de los hallazgos más
importantes incluidos en este estudio obtiene que:
 Las capacidades de negocio describen el 38% de la varianza de ingresos,

mientras que las capacidades de gestión de proyectos describen el 14% y las
capacidades en gestión de portafolio 13%.
 Con relación a la rotación de personal, las capacidades de negocio describen un
58% de la varianza, las capacidades en gestión de proyectos 26% y las
capacidades en Gestión de Portafolio 15%.
 Con relación al desempeño de los proyectos, específicamente en la variación de
cronogramas, las capacidades de negocio describen un 33% de la varianza, las
capacidades en gestión de proyectos 22% y las capacidades en Gestión de
Portafolio solo un 5%.
 Con relación al alcance de los proyectos, las capacidades de negocio describen
un 28% de la varianza, las capacidades en gestión de proyectos 27% y las
capacidades en Gestión de Portafolio un 10%.
 Finalmente, en relación con el costo de los proyectos, las capacidades de
negocio describen un 23% de la varianza, las capacidades en gestión de
proyectos 15% y las capacidades en Gestión de Portafolio un 12%.
De lo anterior, se ve que, para las organizaciones incluidas en el estudio, tanto la gestión

de proyectos, como la gestión de portafolio, influyen en los resultados financieros y de
43
proyecto. Analizando los resultados, se obtiene que las tres principales capacidades
que influyen en los resultados financieros son gestión de tiempo, alcance y costo;
maximización de portafolio de proyectos y gestión logística (Rungi, 2014).
Los estudios de Lerch y Spieth (2013), Urhahn y Spieth (2014) por su parte realizan
también estudios cuantitativos, cuyos resultados soportan la hipótesis que la capacidad
de gestión de portafolio mejora el rendimiento de la organización al permitir mayores
niveles de innovación en aspectos de mercado y tecnológicos.
Específicamente hablando de proyectos de innovación, considerados de creciente

importancia en un mundo global competitivo. donde la supervivencia de la organización
depende fuertemente del desarrollo de nuevos productos (Killen, Hunt, Kleinschmidt, et
al., 2008), una adecuada gestión de portafolio puede generar los siguientes beneficios:
(Brook & Pagnanelli, 2014)
 Centrarse solo en aquellas innovaciones y conocimientos que ayuden a crear valor

a partir de la sostenibilidad, en el corto plazo y el largo plazo, para los clientes en los
segmentos de mercado específicos en los que una empresa opera o tiene la
intención de operar.
 Responder con agilidad a las necesidades cambiantes de los clientes, la
modificación de la dirección estratégica de la empresa para adaptarse a las
condiciones del mercado, basadas en las nuevas regulaciones gubernamentales;
categorías de clientes emergentes en mercados emergentes y en mercados
desarrollados; así como tecnologías emergentes.
 Mejorar el desempeño de la organización a través de la traducción efectiva de la
estrategia de innovación a la ejecución.
 Mejorar el rendimiento de la gestión de portafolio de proyectos de innovación basado
en un enfoque de pronóstico gradual.
 Ayudar a adaptar continuamente el portafolio de proyectos de innovación.
 Propuestas de proyectos de innovación anteriormente rechazadas pueden ser
reconsideradas, cuando un caso de negocio positivo se desarrolla sobre la base de
nuevos datos de los avances tecnológicos o las tendencias del mercado.
De otro lado, se encuentran también en la literatura artículos que desafían estas

afirmaciones. En particular, el artículo de R. Young, Young, Jordan, & O’Connor (2012)
44
presenta un estudio realizado en el Estado de Victoria, Australia, considerado como un
ejemplo de gestión pública, en el cual se aplican buenas prácticas de gestión de
proyectos y selección de proyectos (orientadas a beneficios), sin embargo, los
resultados no muestran mejoras en el logro de los objetivos estratégicos. Los autores
concluyen que este caso presenta una debilidad sistémica en la forma en que los
proyectos son seleccionados y gobernados.
En resumen, los artículos revisados describen que, desde un punto de vista estratégico,
la gestión de portafolio de proyectos puede generar una ventaja competitiva para la
empresa, al asegurar el alineamiento de los proyectos con los objetivos de la empresa,
priorizar ideas de proyectos, adaptar el portafolio y alimentar el registro de proyectos, lo
que constituye activos de la organización y alimenta el conocimiento organizacional.
Para lograr esto, la gestión de portafolio debe ir acompañada de un proceso de
aprendizaje, y requiere que los responsables de su gestión cuenten con las capacidades
empresariales que les permitan tomar decisiones adecuadas con respecto al portafolio.
Así mismo, aunque se encontraron varios artículos que sugieren que la implementación
de gestión de portafolio tiene un impacto sobre los resultados o rendimiento de la
empresa, el número de estudios cuantitativos o que buscan generalizar resultados es
reducido, dejando espacio para la investigación en este campo.
3.7 Conclusiones de la revisión

De la revisión de la literatura, se puede apreciar que el tema de la gestión de portafolio,
si bien ha sido cubierto por varios investigadores, desde diferentes perspectivas, aún
presenta muchos campos de investigación.
Sobre los métodos de investigación utilizados en los artículos, se aprecia que la gran
mayoría utiliza estudios de casos como base para la investigación, lo que limita la
posibilidad de generalización de los resultados.
Se observa también, que la gestión de portafolio no es una función aislada dentro de la

organización, sino que interactúa con múltiples áreas, lo que hace que el éxito de la
gestión de portafolio se vea influenciado por la participación del resto de actores
involucrados.
45
Con relación al tamaño de las empresas consideradas en los estudios, se aprecia que
la mayoría cubren empresas de tamaño mediano (considerando una empresa mediana,
aquella con menos de 500 empleados) y grande (más de 500 empleados). Solo cuatro
estudios mencionan a las pequeñas empresas.(Rungi, 2010, 2014; Vacík, Špaček, Fotr,
& Kracík, 2018; Vähäniitty, Rautiainen, & Lassenius, 2010).
Se tiene presente, que el nivel de separación de funciones de la gerencia general con

la gestión de proyectos, claramente depende del tamaño de la organización (Ligetvári
Student, 2013) y que si bien la formalización de los procesos de gestión de proyectos y
gestión de portafolio pueden influir positivamente en los resultados (Lerch & Spieth,
2013), el nivel de formalización requerida depende de la complejidad de los proyectos
(J. Teller, Unger, Kock, & Gemünden, 2012) y de la interdependencia entre ellos (Killen
& Kjaer, 2012). De esta forma, las prácticas que aplican en una gran empresa no
necesariamente aplican en una pequeña o mediana empresa. Con base en ello, se hace
necesario identificar si la gestión de portafolio pude tener un impacto en el desempeño
de las pequeñas y medianas empresas.
46
Capítulo 4. Diseño de la investigación
Los diseños de investigación son procedimientos para recopilar, analizar, interpretar y

reportar datos en estudios de investigación (Creswell & Clark, 2007). Los diseños de
investigación son útiles porque ayudan a guiar las decisiones de métodos que los
investigadores deben tomar durante sus estudios y establecen la lógica mediante la cual
se realizan interpretaciones al final de los proyectos.
Para el presente proyecto, se optó por utilizar un diseño mixto. Este se caracteriza por
combinar al menos un método cuantitativo y un método cualitativo, donde ningún tipo
de método está inherentemente vinculado a ningún paradigma de investigación en
particular (Creswell & Clark, 2007).
Dadas las características del proyecto, en que no se cuenta con información secundaria,
es decir, datos que hayan sido previamente recolectados por otras personas y para otros
propósitos (Allen, 2017), se utilizó un diseño de entrada cuantitativo preliminar (Morgan,
2013) que permite identificar y seleccionar intencionalmente los casos para la fase
cualitativa.
El presente capítulo describe las 4 fases en que se dividió el proyecto, así como los
instrumentos generados a partir de las matrices de operacionalización. Posteriormente,
los capítulos 5 y 6 describen los resultados obtenidos en la fase cuantitativa y cualitativa.
4.1 Descripción de la población

El presente proyecto de investigación se enfoca en pequeñas empresas desarrolladoras
de software. El tamaño de estas empresas (según volúmenes de ventas), es muy
variado, pero en el estudio realizado por PROMPEX & APESOFT (2003). se apreciaba
una marcada preponderancia de las microempresas (64%), mientras que las pequeñas
representaban un 19% y las medianas un 13%. Esta tendencia se ha mantenido en los
siguientes años, como lo muestra el informe más reciente de APESOFT en que se indica
que en Perú, para el año 2015, existían alrededor de 450 empresas formalizadas que
se dedican al desarrollo de software, de las cuales el 95% correspondían a mypes.
47
El presente estudio se enfocó en las pymes, que además cumplan con la definición de
Very Small Entity de la ISO (ISO, 2011), lo cual genera una población aproximada de
144 empresas.
4.2 Fases y procedimientos
Basado en la revisión de la literatura, la investigación fue un estudio mixto,

específicamente un diseño secuencial explicativo (Creswell & Clark, 2007), divido en
cuatro fases:
Fase 1: Estudio Exploratorio
En esta fase se envió una encuesta a las empresas que forman parte de la población.
El resultado de esta fase fue identificar empresas que formen parte de la población y el
nivel de aplicación de las prácticas de gestión de portafolio y gestión de proyectos. A
este método se le conoce también como diseño de entrada cuantitativo preliminar
(Morgan, 2013) y permite identificar y seleccionar intencionalmente los casos para la
fase cualitativa (Creswell & Clark, 2007).
El resultado de este estudio permitió clasificar a las empresas en cada uno de los
siguientes grupos:
 Empresas que apliquen prácticas de gestión de proyectos, pero no de gestión
de portafolio
 Empresas que apliquen prácticas de gestión de portafolio, pero no de gestión de
proyectos
 Empresas que apliquen prácticas de gestión de portafolio y gestión de proyectos
 Empresas que no apliquen ninguna de las dos.
El detalle de la ejecución de esta fase se muestra en el capítulo 5 del presente

documento.
Fase 2: Estudio Cualitativo
48
Sobre la base de los grupos anteriores, se realizó un estudio de casos múltiples. Un
estudio de caso múltiple permite al investigador explorar las diferencias dentro y entre
los casos (Baxter & Jack, 2008).
El detalle de la ejecución de esta fase se describe en el capítulo 6 del presente

documento.
Fase 3: Diseño de un marco de trabajo para gestión estratégica de proyectos
Sobre la base del estudio realizado, se planteó un marco de trabajo para pymes, como
un conjunto de prácticas recomendadas para la implementación de gestión de portafolio
de proyectos en pymes de desarrollo de software.
El detalle del marco de trabajo propuesto se detalla en el capítulo 7 del presente

documento.
Fase 4: Validación del modelo
El modelo generado fue aplicado en 2 empresas que se comprometieron a implementar

el modelo y que cumplían con los criterios de selección establecidos. Una de ellas
participó en las primeras fases del estudio, mientras que la segunda se incorporó al
proyecto luego de tener definido el marco de trabajo.
Para esta fase se realizaron las siguientes actividades:
a) Evaluación de línea base utilizando el mismo cuestionario en línea empleado en

la fase exploratoria.
b) Implementación del modelo.
c) Evaluación post implementación, utilizando un cuestionario en línea y una
entrevista al Gerente General de las empresas.
Los resultados de la ejecución de esta fase se describen en el capítulo 8 del presente

documento.
49
El resumen de la metodología se muestra en la figura 4.1
Figura 4.1 Metodología del estudio
50
4.3 Consistencia de la metodología con los objetivos y preguntas de
investigación
La metodología planteada para este proyecto de investigación ha sido planteada a fin

de cubrir los objetivos del proyecto y las preguntas de investigación. La figura 4.2
muestra como las fases apoyan al logro de los objetivos planteados.
Tanto la fase 1, como la fase 2, apoyan el logro del objetivo específico 1, “Describir las
prácticas de gestión de portafolio utilizadas en las pequeñas empresas dedicadas al
desarrollo de software en Perú”. En la fase 1, el cuestionario permitió identificar la
frecuencia con que se aplican las prácticas de gestión de proyectos y gestión de
portafolio en la empresa. Por su parte, la fase 2 permitiió comprender cómo se aplican
estas prácticas en función de procedimientos, herramientas y participantes en el
proceso.
El objetivo específico 2, “Determinar si la aplicación de las prácticas de gestión de

portafolio influye en el rendimiento de estas pequeñas empresas” se ve soportado por
la metodología, dado que, la fase 1 permitió clasificar a las empresas de acuerdo a la
aplicación de prácticas de gestión de proyectos y gestión de portafolio vs el rendimiento
de la empresa. De esta forma se pudo clasificar a la empresa en una de las siguientes
cuatro categorías:
 Empresas que aplican prácticas de gestión de portafolio y reportan un

rendimiento satisfactorio
 Empresas que aplican prácticas de gestión de portafolio y reportan un
rendimiento insatisfactorio
 Empresas que no aplican o aplican pocas prácticas de gestión de portafolio y
reportan un rendimiento satisfactorio
 Empresas que no aplican o aplican pocas prácticas de gestión de portafolio y
reportan un rendimiento insatisfactorio
Así mismo, la evaluación final de la fase 4 permitió evaluar si, tras la implementación del
marco de trabajo, basado en la aplicación de prácticas de gestión de portafolio, la
empresa percibía una mejora en el rendimiento.
51
Finalmente, el objetivo específico 3, “Proveer un conjunto de lineamientos guía para la
implementación de las prácticas de gestión de portafolio como parte de un marco de
trabajo de gestión estratégica de proyectos aplicable a pequeñas empresas de
desarrollo de software” se vio soportado por la fase 3 y 4 de la metodología en que se
desarrolló y validó el marco de trabajo.
Figura 4.2 Aporte de la metodología para el cumplimiento de objetivos
52
Con respecto a las preguntas de investigación, la fase 1 y 2 permitieron responder a la
primera pregunta de investigación, relacionada a la forma en cómo se aplican las
prácticas de gestión de portafolio en pequeñas empresas dedicadas al desarrollo de
software en Perú.
La fase 1 permitió identificar las prácticas de gestión de proyectos y gestión de portafolio

más utilizadas en las empresas, mientras que la fase 2 permitió comprender cómo se
aplican estas prácticas en función de procedimientos, herramientas y participantes en el
proceso.
Con respecto a la segunda pregunta de investigación que busca evaluar si empresas

proyectizadas de igual o similar tamaño que apliquen prácticas de gestión de portafolio
tienen un rendimiento diferente que las que no lo aplican, la respuesta a esta pregunta
se obtendrá a partir de la fase 1 y 4 de la metodología.
La fase 1 permitió clasificar a las empresas de acuerdo a la aplicación de prácticas de

gestión de proyectos y gestión de portafolio vs el rendimiento de la empresa y tras la
implementación del marco de trabajo, durante la fase 4 se pudo observar la variación
en el rendimiento luego incluir o reforzar el uso de prácticas de gestión de portafolio.
53
Figura 4.3 Aporte de la metodología para responder las preguntas de investigación
4.4 Criterios de Selección
Para el estudio se tomó en cuenta los siguientes criterios de selección:
54
 Ser una empresa desarrolladora de software
 Tener menos de 25 trabajadores
 Manejar al menos dos proyectos en paralelo
 Que los ingresos no provengan principalmente de outsourcing.
4.5 Matriz de Operacionalización
Para la fase de exploración se utilizó la siguiente matriz de operacionalización
Tabla 4.1 Matriz de Operacionalización Fase Exploratoria
Dimensiones Variables Operacionalización

(grandes
conceptos)
Y: Rendimiento  Ventas: (crecimiento Valores de 1 a 7 (1 Muy Malo ...

Rendimiento Financiero de ventas en 7 sobresaliente)
de la comparación con la
competencia)
Empresa
 Rentabilidad Valores de 1 a 7 (1 Muy Malo …
Financiera de los 7 sobresaliente)
Definición proyectos (ingresos –
operativa de egresos en
Y: comparación con la
Análisis de competencia
rendimiento
 Crecimiento en el
basado en el Rendimiento
estratégico empleo (aumento del
rendimiento
número de
financiero,
empleados en
operativo
comparación con la
competencia)
 Cumplimiento de
expectativas
(desempeño general
55
(grandes
conceptos)
del negocio supera a

la competencia)
 Comparación con la
competencia
(desempeño en
comparación con las
otras empresas)
 Satisfacción de la alta
dirección (nivel de
desempeño cumple
con las expectativas
del CEO)
Gestión de  Control de alcance Valores de 1 a 7 (donde 1

Proyectos  Control de implica que la empresa no
cronograma realiza estas tareas … 7 la
X
 Control de empresa realiza completamente
Implementación
presupuesto estas tareas)
de Gestión de
 Gestión de calidad
Portafolio
(realización a
actividades de
Prácticas de aseguramiento y
selección y control de calidad)
gestión de  Gestión de riesgos
proyectos
Valores de 1 a 7 (donde 1
aplicadas en la  Cumplimiento de
implica que los proyectos nunca
empresa plazos (los proyectos
terminan a tiempo … 7 siempre
terminan a tiempo)
terminan a tiempo)
implica que el número de
56
(grandes
conceptos)
 Satisfacción del defectos reportados es muy

cliente (número de bajo… 7 el número de defectos
defectos reportados) es muy alto)
Gestión de  Registro del portafolio Valores de 1 a 7 (donde 1

Portafolio implica que la empresa no
realiza esta tarea … 7 la
empresa realiza completamente
estas tareas)
 Proyectos internos
 Proyectos de
implica que la empresa nunca
Innovación
realiza este tipo de proyectos …
7 la empresa siempre realiza
este tipo de proyectos)
 Criterios para Valores de 1 a 7 (donde 1

selección de implica que la empresa nunca
proyectos utiliza criterios para seleccionar
proyectos … 7 la empresa
siempre utiliza estos criterios)
 Alineamiento con los

objetivos de la Valores de 1 a 7 (donde 1
empresa implica que los proyectos no
tienen ninguna alineación con
los objetivos de la empresa … 7
57
(grandes
conceptos)
los proyectos están

 Análisis de recursos completamente alineados)
requeridos
 Evaluación de
riesgos previa al Valores de 1 a 7 (donde 1
inicio del proyecto) implica que la empresa no
 Revisión periódica realiza esta tarea … 7 la
del estado del empresa realiza completamente
portafolios estas tareas)
 Priorización de
proyectos
 Comunicación entre
alta dirección y
responsables del
portafolio Valores de 1 a 7 (donde 1
 Comunicación entre implica una muy mala
responsables de comunicación… 7 comunicación
portafolio y sobresaliente)
responsables de
proyecto
A continuación, se muestra la matriz de operacionalización que permitió definir un

cuestionario base para el estudio cualitativo tomando como preguntas de investigación
base ¿Cómo se aplica la gestión de portafolio de proyectos en pequeñas empresas
desarrolladoras de software? y ¿Cuál es su impacto en el rendimiento de estas?
Tabla 4.2 Matriz de Operacionalización Fase Cualitativa
58
Dimensiones Definiciones operativas Variables
(grandes de las dimensiones
conceptos)
Y: Rendimiento Resultados financieros  Ventas: (ingresos recibidos

a partir de los proyectos)
Rendimiento Financiero obtenidos por la empresa
de la en un periodo de tiempo  Rentabilidad Financiera de
Empresa determinado los proyectos (ingresos –

egresos)
Definición
operativa de
Rendimiento Percepción de  Crecimiento en el empleo
Y:
(aumento del número de
estratégico rendimiento basada en
Análisis de empleados)
indicadores no
rendimiento  Cumplimiento de
financieros
basado en el expectativas
rendimiento  Comparación con la
financiero, competencia (evaluación del
operativo desempeño en comparación
con las otras empresas)
 Satisfacción de la alta
dirección (nivel de
satisfacción del CEO)
Selección de Prácticas y herramientas  Tipo de Modelo de Negocio

X
 Fuentes de generación de
Implementación Proyectos utilizadas para la
selección de proyectos ideas de negocio
de Gestión de
teniendo en cuenta la  Personas involucradas en la
Portafolio
estrategia de negocio selección de proyectos
 Criterios para la selección
Prácticas de de proyectos
selección y  Tipos de riesgos
gestión de considerados en el portafolio
59
Dimensiones Definiciones operativas Variables
(grandes de las dimensiones
conceptos)
proyectos  Nivel de innovación

aplicadas en la (porcentaje de presupuesto
empresa dedicado a innovación)
Gestión de Prácticas y herramientas  Medios de comunicación del

portafolio
Portafolio para gestionar los
proyectos de la empresa  Métodos y herramientas de
seguimiento del portafolio
 Experiencia del personal
responsable de la gestión
del portafolio (número de
años de experiencia en
gestión de proyectos o
certificaciones en el tema)
Resultados del Nivel de cumplimiento de  Retraso en los proyectos

(tiempo de desfase entre la
portafolio objetivos de desempeño
planificación original y final)
en proyectos
 Calidad percibida (número
de defectos encontrados
posterior a la entrega)
4.6 Instrumentalización
La primera fase se realizó a través de una encuesta, utilizando la plataforma de
GoogleForms. El cuestionario fue validado previamente con un par de empresas que
cumplían el perfil requerido.
60
En el caso de la fase cualitativa, y con el fin de reducir posibles sesgos introducidos por
los entrevistadores, el estudio consideró entrevistar al responsable de la definición de
los objetivos de la organización (CEO en la mayoría de los casos) y el responsable de
los proyectos. De las 6 empresas seleccionadas para la fase cualitativa, en cuatro de
ellas la misma persona desempeñaba ambos roles, mientras que en los otros dos casos
los roles eran desempeñados por personas diferentes.
Las entrevistas se realizaron utilizando un cuestionario guía elaborado con base en la

matriz de operacionalización. Una vez realizadas las entrevistas, se transcribieron y
analizaron utilizando el software NVivo. Los resultados de las entrevistas se
correlacionaron con las prácticas incluidas en el Estándar para la Gestión de Portafolio
de PMI (Project Management Institute, 2013), la Norma ISO 21504 (ISO, 2015) y el
proceso de Gestión de Portafolio definido por Rungi (2014).
En todos los casos, se elaboró un protocolo de consentimiento informado que fue

aprobado por el Comité de Ética en la Investigación de la Pontificia Universidad Católica
del Perú. Así mismo, a cada empresa que participó en el Estudio, se le hizo entrega de
un acuerdo de confidencialidad. Los formatos de consentimiento informado se muestran
en el anexo 3 y 4 del presente documento y el formato de acuerdo de confidencialidad
se presenta en el anexo 5.
Para analizar el rendimiento de la empresa, se utilizó el modelo dimensional propuesto

por Roach (2011), el cual se ve reflejado en la matriz de operacionalización, considera
dos dimensiones y presenta un cuestionario con 6 aspectos evaluados en una escala
de Likert de 7 puntos:
• Crecimiento de las ventas

• Crecimiento del beneficio
• Crecimiento de empleados
• Rendimiento general del negocio
• Desempeño del negocio en comparación con la competencia
• Satisfacción de la alta dirección
Y las preguntas específicas son:
61
 Durante el año pasado, nuestro crecimiento de ventas fue en
comparación con nuestros competidores.
 Durante el año pasado, nuestro crecimiento de ganancias fue en
 Durante el año pasado, nuestro crecimiento de empleo fue en
 Durante el año pasado, el desempeño general del negocio cumplió con las
expectativas.
 Durante el año pasado, el rendimiento general del negocio superó al de
nuestros principales competidores.
 Durante el año pasado, la alta gerencia estuvo muy satisfecha con el
desempeño general del negocio.
62
Capítulo 5. Estudio Exploratorio
Previo a realizar la fase cualitativa del estudio, se requería identificar casos

representativos, donde se apliquen las prácticas de gestión de portafolio. Con este
objetivo, y dado que no se cuenta con información secundaria acerca de la aplicación
de prácticas de gestión de portafolio de proyectos en empresas de software, la primera
fase del estudio consistió en un estudio cuantitativo exploratorio, también conocido como
diseño de entrada cuantitativo preliminar (Morgan, 2013). Este permite identificar y
seleccionar intencionalmente los casos para la fase cualitativa (Creswell & Clark, 2007).
En el caso de este proyecto de investigación, esta fase del estudio se enfocó en evaluar
la aplicación de prácticas de gestión de proyectos y gestión de portafolio en pequeñas
empresas desarrolladoras de software y con base en esto seleccionar un grupo de
empresas para la fase cualitativa.
Dado que no se disponía de una base de datos con la totalidad de las empresas que
cumplían con la definición de VSE y que esta fase del estudio tiene un carácter
exploratorio, la difusión se realizó a través de listas de interés asociadas al desarrollo,
de software, gestión de proyectos y las redes de contacto del investigador fijando un
plazo para la recepción de respuestas.
El contenido de este capítulo describe la realización de esta fase del proyecto junto con
los resultados obtenidos.
5.1 Ejecución del estudio
Para la realización de esta fase de la investigación se realizó un cuestionario basado en

la matriz de operacionalización descrita en la sección 4.4, el mismo que fue validado
con un par de profesionales y ajustado previo a su envío.
El cuestionario fue implementado utilizando Formularios de Google. El detalle del

cuestionario se muestra en el anexo 1.
Dado que no se disponía de una base de datos con la totalidad de las empresas que
cumplían con la definición de VSE y la dificultad para conseguir una muestra
63
estadísticamente significativa, esta fase del estudio tiene un carácter exploratorio. Este
tipo de estudio permite identificar y seleccionar intencionalmente los casos para la fase
cualitativa (Creswell & Clark, 2007).
La difusión se realizó a través de listas de interés asociadas al desarrollo de software,

gestión de proyectos y las redes de contacto del investigador.
5.2 Identificación de respuestas válidas

Se recibieron 25 respuestas, de las cuales 21 completaron toda la encuesta. De estas
21 empresas, 11 tenían como principal actividad el desarrollo de software a medida y 3
el desarrollo de software empaquetado, además 7 tenían como principal actividad de
negocio el outsourcing. El gráfico mostrado en la figura 5.1 presenta la distribución de
respuestas por principal actividad de negocio.
Principal Actividad de Negocio
33%
52%
14%
Desarrollo de Software a Medida Desarrollo de Software Empaquetado

Outsourcing
Figura 5.1. Distribución de empresas por Principal Actividad de Negocio.
Durante la validación, previa al inicio del estudio, se identificó que las empresas cuyo
principal rubro de negocio es el outsourcing realizan los proyectos que dispongan los
clientes con los cuales tienen contratos. En ese sentido, estas empresas enfatizan la
selección de clientes, más que la selección de proyectos. Basándose en esto, se decidió
restringir el alcance del estudio a empresas cuya principal actividad sea el desarrollo de
software a medida o el desarrollo de software empaquetado.
64
De las 14 empresas restantes, una de ellas no cumplía el criterio de manejar al menos
dos proyectos en simultáneo. El gráfico mostrado en la figura 5.2 resume el porcentaje
de empresas agrupadas según el número de proyectos del portafolio gestionados en
forma simultánea.
Empresas por tamaño del portafolio

Un proyecto ; 7%
Más de 5
proyectos;
36%
Entre 2 y 5
proyectos;
57%
Figura 5.2. Distribución de empresas por Tamaño del Portafolio
Finalmente, el gráfico mostrado en la figura 5.3 muestra el porcentaje de empresas

agrupadas por tamaño de la empresa en función del número de trabajadores. Tres de
estas empresas reportaban tener más de 25 trabajadores (23%), sin embargo, se
decidió analizar su información con el objetivo de observar si en estos casos se cumplía
la hipótesis de que la aplicación de prácticas de gestión de portafolio predice un mejor
rendimiento en las organizaciones.
65
Empresas por Número de Trabajadores
Más de 25 ;
Entre 1 y 5;
23%
31%
Entre 16 y 25;
15% Entre 6 y 15;
31%
Figura 5.3. Distribución de empresas por Número de Trabajadores
5.3 Análisis de respuestas

Habiendo identificado las respuestas válidas para el estudio se procedió a analizar las
respuestas de cada una de las empresas.
El cuestionario elaborado con base en la matriz de priorización descrita en el capítulo 4

incluye preguntas relacionadas a 4 aspectos:
 Gestión de Proyectos
 Gestión de Portafolio
 Percepción de rendimiento financiero
 Percepción de rendimiento estratégico
Cada pregunta se evaluó en una escala de Likert de 7 puntos. A fin de analizar las
respuestas, se realizó la sumatoria de resultados por cada una de estos aspectos. La
tabla 5.2 muestra los resultados de cada una de las empresas, asignando un código a
cada una para mantener la confidencialidad.
66
Tabla 5.1 Evaluación de prácticas de gestión y percepción de rendimiento
Gestión Gestión Total, X Rendimiento Rendimiento
Proyectos Portafolio (Max Financiero estratégico Total Y
Empresa (máx. 49) (máx. 84) 133) (máx. 14) (máx. 28) (máx. 42)
E21 42 79 121 12 25 37
E23 38 60 98 12 24 36
E20 38 78 116 12 21 33
E22 43 62 105 11 22 33
E6 40 64 104 9 21 30
E25 38 67 105 10 19 29
E18 34 76 110 8 18 26
E12 26 31 57 10 16 26
E24 44 61 105 8 15 23
E13 35 62 97 8 14 22
E1 38 61 99 10 10 20
E16 49 76 125 10 9 19
E8 34 51 85 8 9 17
A pesar de que el número de respuestas no permite generalizaciones, algunos datos

relevantes que se observan en los resultados incluyen:
 La empresa E21 tiene la mejor percepción de rendimiento y el valor más alto de

aplicación de prácticas de gestión de portafolio. De manera similar, en los casos
E23, E20, E22 y E6 se aprecia una alta percepción del rendimiento de la
empresa y un nivel alto de aplicación de prácticas de gestión de proyectos y
gestión de portafolio.
 Por otro lado, las empresas E16 y E24 reportan un alto nivel de aplicación de
prácticas de gestión de proyectos y gestión de portafolio, sin embargo, presentan
una percepción de rendimiento baja.
 Entre las respuestas recibidas no se encontró ningún caso en que la empresa
tenga una percepción de rendimiento alta y baja aplicación de prácticas de
gestión.
67
Estos resultados fueron utilizados para invitar a un grupo de empresas a participar en la
fase cualitativa del estudio.
68
Capítulo 6. Estudio de Caso Múltiple
Teniendo como base los resultados del estudio exploratorio, se invitó a un grupo de
empresas para la realización de entrevistas en profundidad a fin de entender cómo
aplicaban las prácticas de gestión de proyectos y gestión de portafolio.
Estas entrevistas permitieron validar algunas de las respuestas recibidas en el

cuestionario, así como obtener información acerca de la forma en que las empresas
aplican la gestión de proyectos y gestión de portafolio, y su relación con el rendimiento
organizacional.
El resto del presente capítulo describe la ejecución de las entrevistas, así como los
resultados obtenidos agrupados en temas estratégicos, de gestión del portafolio y de
gestión de proyectos, buscando identificar aspectos comunes y diferencias entre cada
uno de los casos entrevistados.
6.1 Preparación de las entrevistas
Con los resultados de la fase anterior, se realizó la invitación a participar en la segunda

fase del estudio a 10 empresas que cubrían con el perfil esperado. De estas, seis
empresas accedieron a brindar la entrevista.
La entrevista utilizó como base el cuestionario del anexo 2, elaborado a partir de la

matriz de operacionalización descrita en la sección 4.4. Cada entrevista tomó en
promedio 75 minutos. Estas entrevistas fueron grabadas con consentimiento de los
participantes para posteriormente ser transcritas y analizadas utilizando el software
Nvivo.
6.2 Descripción de las empresas participantes
La tabla 6.1 muestra una descripción general de cada una de las empresas que
participaron en las entrevistas.
69
Tabla 6.1 Descripción de las empresas
ID Número de Número de Año Descripción de la empresa

empleados proyectos fundación
en portafolio
E1 Entre 5 y 15 4 2007 La empresa se dedica al desarrollo

de software y ha realizado
productos propios. Adicionalmente
tiene otra línea de negocio
orientada a la instalación y
configuración de centrales IP.
E18 Entre 1 y 5 3 2018 Se dedica al desarrollo de software

principalmente con clientes
internacionales y mantiene una
línea de consultoría en métodos
ágiles.
E21 Entre 15 y 25 5 2016 Se dedica a desarrollar software a

medida, y proyectos de soporte con
clientes antiguos. Adicionalmente
mantiene 2 fábricas de software.
E22 Entre 15 y 25 4 2001 La empresa principalmente trabaja

en desarrollar soluciones adhoc
para clientes asociados y ha
generado productos propios a partir
de proyectos realizados.
E24 Entre 5 y 15 3 2013 Realiza desarrollo de software a

medida y soporte. Adicionalmente
incluye entre sus servicios,
asesorías en arquitectura de
soluciones y maquetado de
prototipos
70
ID Número de Número de Año Descripción de la empresa
empleados proyectos fundación
en portafolio
E25 Entre 1 y 5 4 2015 Trabaja principalmente con

proyectos tercerizados y desarrollo
de sistemas para pymes.
En la tabla 6.2, se aprecia los valores obtenidos por cada una de estas empresas en
relación con la aplicación de las prácticas de gestión de proyectos y gestión de portafolio
durante el estudio exploratorio.
Tabla 6.2 Puntaje obtenido por las empresas entrevistadas

Proyectos Portafolio (Max Financiero estratégico Total, Y
E21 42 79 121 12 25 37
E22 43 62 105 11 22 33
E25 38 67 105 10 19 29
E18 34 76 110 8 18 26
E24 44 61 105 8 15 23
E1 38 61 99 10 10 20
Así, se puede ver que la muestra de empresas entrevistadas incluye empresas con alto
nivel de implementación de prácticas de gestión de portafolio, así como empresas con
menor nivel de aplicación de prácticas de gestión de portafolio y menor percepción de
rendimiento.
71
6.3 Discusión del caso
Se aprecia que, en todos los casos, las empresas reportaban aplicar prácticas básicas
de gestión de proyectos, pero, en lo que respecta a prácticas de gestión de portafolio,
se notaba una diferencia significativa en las empresas E18 y E21.
6.3.1 Nivel estratégico
Dado que la definición de portafolio de proyectos señala que su objetivo es cumplir total
o parcialmente un conjunto de objetivos estratégicos de la organización (ISO, 2015, p.
1), se identificó que durante las entrevistas debía profundizarse en este tema.
Uno de los primeros hallazgos fue que todas las empresas aseguraban tener objetivos
definidos, pero al momento de la entrevista, se observaban diferentes ideas de lo que
es un objetivo de negocio y como plantearlos. Cabe mencionar que durante las
entrevistas se consultó inicialmente cuáles eran los objetivos de negocio de la empresa,
posteriormente, con base en la respuesta, se dio ejemplos de lo que sería un objetivo
de negocio y se volvió a plantear la pregunta.
La tabla 6.3 muestra un fragmento de las respuestas obtenidas sobre los objetivos de
negocio.
Tabla 6.3 Objetivos de negocio
“En cuanto a objetivos tenemos primero que la visión y la misión está claramente
definida. Ya la hemos revisado. Como objetivo al inicio del año lo que hacemos es
objetivos económicos, es decir cuánto más queremos crecer en el año que viene y el
otro objetivo que se ha fijado es también la capacitación técnica, que es un tema que
también se ha empezado con fuerza.”
“Los objetivos de negocios es poder crecer como empresa, para eso necesitamos
tener un portafolio de desarrollos empaquetados, poder abarcar mucho más, es decir
poder abarcar las necesidades de más clientes de diferentes sectores.”
72
“Nuestros objetivos a muy corto plazo es tener soluciones que nos permitan tener una
presencia en el mercado, porque desarrollo de software se está volviendo un
comodity.”
“Nosotros apuntamos, según nuestro plan estratégico actualizado, a escalar a un

mercado global. Ósea nuestra atención ha estado a mercados locales y no nos va
mal, pero ahora queremos ya atender mercados globales. Para este año queremos
como meta al menos tener 2 proyectos globales.”
“La visión que se tiene como empresa es llegar a las empresas pymes. Los objetivos
de esta empresa es incrementar cierta cantidad las ventas, incrementar también el
personal, incrementar las ventas ofreciendo nuevos servicios y productos. También
mejorar la captación de clientes, relanzando la página web y algunas redes sociales.”
“Para empezar rentabilidad es lo que se busca. Mi objetivo es que nos llamen para
cosas bastante especializadas. Ahorita el objetivo es productizar. Para este año el
objetivo es hacer un producto y modificar los productos que tenemos para ofrecer.”
De otro lado, una de las tareas que las organizaciones deben completar para
implementar con éxito la estrategia es acordar qué constituye el éxito (Loomis, 1988).
En este contexto, los Sistemas de Control de Gestión comprenden todos aquellos
procesos y procedimientos mediante los cuales los gerentes deben garantizar que las
estrategias organizacionales se implementen y que se alcancen sus objetivos
(Pratuckchai, 2012).
En el caso de las empresas que formaron parte de esta fase del estudio, se observó que
para la evaluación de cumplimiento de sus objetivos utilizaban principalmente la
facturación y los proyectos concretados y ninguna de ellas manejaba un esquema
complejo para controlar el logro de los objetivos.
Esto se ve reflejado en las afirmaciones obtenidas durante las entrevistas:
 “Evalúo el cumplimiento de objetivos por la facturación, contratos cerrados.”

 “Nosotros llevamos básicamente la métrica de cuanto número de proyectos se
han hecho, en cada uno de estos 3 cuadrantes que tenemos.”
73
Cabe mencionar también, que para las empresas entrevistadas el horizonte de tiempo
más grande era de un año.
Un aspecto presente en este tipo de empresas es que su reducido número de

trabajadores facilita la difusión de los objetivos de negocio a la mayoría de los
colaboradores de la empresa a través de reuniones a la que se invite al personal. Esto
puede constituir una oportunidad para este tipo de empresas, dado que el éxito del
proceso de la estrategia depende en gran medida del significado y la importancia que el
empleado otorgue a la misma (Vänttinen & Pyhältö, 2009).
De las 6 empresas, 4 indicaron que todos los trabajadores tenían conocimiento de los
objetivos de la empresa, una indicaba que aún no lo había hecho, pero que lo tenía
planificado y un caso particular se presenta en una de las empresas entrevistadas en
que indicaba que los objetivos únicamente eran de conocimiento de los gerentes.
“Los socios y las gerencias conocen los objetivos de negocio. En mi caso soy
socio y gerente general y hay una persona externa, que es socio y tiene
conocimiento sobre esto además las personas que dirigen el área administrativa
y la parte financiera y contable.”
6.3.2 Portafolio de Proyectos
Cabe recordar que como criterio de selección para las empresas, se consideró que
dentro de su modelo de negocio se enfocaran en desarrollo de software a medida o
desarrollo de producto. Dentro de las empresas entrevistadas todas desarrollan
software a medida.
En lo que se refiere al desarrollo de productos, en la sección del estado del arte se

identifica que los proyectos de innovación son considerados de creciente importancia
en un mundo global competitivo donde la supervivencia de la organización depende
fuertemente del desarrollo de nuevos productos (Killen, Hunt, Kleinschmidt, et al., 2008).
En este contexto, se observa que, de las empresas entrevistadas, únicamente dos de
74
ellas habían desarrollado productos propios hasta el momento, otras expresaron la
intención de hacerlo y todas reconocían que la innovación es importante.
La tabla 6.4 resume la percepción sobre la innovación de las empresas entrevistadas
Tabla 6.4 Percepción sobre la innovación
“Creemos bastante en la innovación, pero no solo en la innovación por el lado de las

tecnologías, sino en la innovación por el lado de cultura, de procesos. Queremos
comenzar a innovar con soluciones que podamos después usar nuevas tecnologías,
mejorar ciertos procesos, solucionar problemas.”
“Normalmente innovamos en todo lo que es temas de tecnología. Pero innovación de

negocios, ahorita personalmente no nos ha nacido. Tengo ideas que salen, pero
ahora las estoy plasmando como tesis.”
“La innovación es superimportante en el tema de desarrollo de software, y no

solamente innovación a nivel tecnológico, sino innovación a nivel de metodología.
Pero como proyecto interno, no tenemos todavía ningún proyecto interno, de algún
desarrollo.”
“Nosotros tratamos de inculcar o darles a entender a los clientes que la innovación es

necesaria, porque no solamente es automatizar.
“Tenemos proyectos que ya hemos desarrollado con los clientes, y algunos creemos
que pueden ser productos masivos, entonces le damos un esfuerzo adicional para
convertirlo en un producto masivo y eso ya lo lanzamos al mercado. Estamos
planteando productos que no solo les sirvan, sino que son innovadores y que aportan
a su negocio. Entonces la innovación la vemos siempre en todos los proyectos que
trabajamos.”
“Dentro de nuestros tipos de proyectos tenemos desarrollos internos con miras a que
sean productos empaquetados que se puedan vender. Hemos hecho proyectos con
fondos concursables del gobierno, pero aparte, hemos desarrollado software por
nuestra cuenta, con ciertos diferenciales que podrían hacerlo innovador.”
75
Previo a iniciar el proyecto, sea un proyecto a medida o desarrollo de productos, los
procesos front end incluyen revisar las ideas y problemas, antes de la fase formal de
desarrollo de los proyectos (K. Artto et al., 2011). En este contexto, la tarea de la gestión
del portafolio de ideas es alimentar a la subsecuente gestión de portafolio de proyectos
con un flujo suficiente de propuestas de proyectos que generen alto valor y que soporten
la implementación de los objetivos estratégicos desarrollados. Esto incluye el soporte
de los cambios deseados en los objetivos estratégicos que surjan para ser
implementados dentro de un marco de tiempo y con niveles de riesgo aceptables
(Wilderich Heising, 2012).
Lo anterior se relaciona directamente con la forma en que la empresa obtiene

propuestas de proyectos. Con respecto a este punto, en lo que respecta a proyectos a
medida, todas las empresas se apoyan principalmente en referencias directas, lo cual
se evidencia en las respuestas de los entrevistados:
“Particularmente nuestra empresa por el prestigio que tiene dentro del nicho,
dentro del sector, la gran mayoría de clientes que ahorita se tiene es del boca a
boca.”
“Por recomendaciones, ya sea por amistades o por otros clientes y por trabajos
anteriores.”
“Referencias netamente, todo es contactos.”
En el caso de proyectos de desarrollo de productos, durante las entrevistas, se

identificaron dos estilos diferentes para la identificación de ideas de productos.
a) Desarrollo de productos a partir de proyectos a medida desarrollados
“Ahí tenemos proyectos que ya hemos desarrollado con los clientes, y

algunos creemos que pueden ser productos masivos, entonces le damos un
esfuerzo adicional para convertirlo en un producto masivo y eso ya lo
lanzamos al mercado.”
76
“Nos pidieron un tema de facturación electrónica con SAP Business One.
Hicimos números y dijimos que nos convenía y sería también como
oportunidad para tener un producto propio.”
b) Ideas generadas al interior de la misma empresa
“Básicamente surgen de la experiencia de los integrantes, se invoca a todos

para que también aporten. En algún momento hemos hecho dinámicas como
para alimentar mucho más la idea y aterrizarla. Listamos todas la ideas y
oportunidades, internamente votamos y escogemos un proyecto interno.”
Una vez que se tienen las ideas o propuestas, si bien ninguna de las empresas tenía un
proceso documentado para la selección de proyectos, durante las entrevistas se pudo
identificar que cada una tenía prioridades al momento de decidir realizar un proyecto.
La tabla 6.5 resume los aspectos considerados por cada una de las empresas.
Tabla 6.5 Aspectos a considerar en la decisión de realizar un proyecto
Empresa Factores a considerar
E1  Facturación y retorno de inversión

 Tecnología a utilizar
 Tiempo de desarrollo
 En proyectos de innovación, que tan rápido es el proyecto y que tan
maduro y que tan fácil va a ser venderlo, si hay competencia.
E18  Rentabilidad
 Capacidad operativa
 Burocracia.
 Para los proyectos de innovación que además de ser rentables ayuden a
la sociedad
E21  Rentabilidad
 Viabilidad tecnológica
 Nivel de reto
77
Empresa Factores a considerar
 Nivel de rentabilidad temporal

 Dependencias del cliente
E22  Facturación
 Tecnología
 Tiempo
 Presupuesto
 Nivel de Burocracia
 Información del Cliente
 Riesgos del proyecto
E24  Si el cliente es buen pagador y experiencias previas con dicho cliente.

 Tecnología
 Referencias y oportunidad.
 Capacidad de atención y preparación por parte del cliente
E25  Complejidad (tamaño)

 Recursos requeridos
 Tiempo para empezar
 Tecnología
La tabla 6.6 presenta un resumen de los aspectos encontrados, el cual permite observar
cuáles son los más que se repiten dentro de las empresas entrevistadas.
Tabla 6.6 Resumen de aspectos a considerar en la decisión de realizar un proyecto
Criterio E1 E18 E21 E22 E24 E25
Facturación x x x x x
Presupuesto
Rentabilidad
78
Criterio E1 E18 E21 E22 E24 E25
Tecnología x x x x x
Disponibilidad de recursos x x
Tiempo disponible x x x
Facilidad de trabajar con el x x x

cliente (por trabajo previo o
referencias)
Complejidad x x
Nivel de burocracia x x
Madurez de la idea del proyecto x
Competencia x
Impacto en la sociedad x
Facilidad para venderlo x
Nivel de riesgo X
De los casos observados, se aprecia que la facturación o rentabilidad es uno de los

criterios más importantes, de hecho, en la mayoría de los casos fue el primero en ser
mencionado. De la misma forma, el criterio de tecnología constituye uno de los más
importantes. En un menor número aparece el tiempo disponible y la facilidad para
trabajar con el cliente.
En lo que respecta a las personas involucradas, en todos los casos reportan que para
la decisión de iniciar un proyecto el gerente general siempre está involucrado.
La tabla 6.7 resume las personas que participan en cada una de las empresas en el
proceso de selección de proyectos.
79
Tabla 6.7 Responsables de la decisión de ejecución de proyectos
Empresa Personas involucradas
E1 Socios (2)
E18 Gerente General
E21 Gerente general
Gerente Comercial
E22 Gerente General
Líder de proyecto
Responsable de finanzas
E24 Socios (2)
E25 Gerente general
Cabe observar que el perfil de cada una de estas personas es diferente, pudiendo
identificar que los gerentes de las empresas E18, E21 y E22 tienen un mayor número
de años de experiencia, habiendo trabajado en proyectos de gran envergadura.
Coincidentemente, estas empresas son las que reportaban un mayor uso de prácticas
de gestión de proyectos y gestión de portafolio.
Adicionalmente las empresas E21 y E22 reportaban el mejor rendimiento. La empresa

E18 reportaba un rendimiento un poco menor, sin embargo, una posible explicación de
ello es el poco tiempo que tenía en el mercado.
Aunque de la investigación realizada, no es posible afirmar que exista una relación entre
la experiencia del gerente y el rendimiento de la empresa, esta hipótesis es apoyada por
estudios como Staniewski (2016), Cassar (2014) y Stuart & Abetti (1990) quienes
afirman que la experiencia previa contribuye a tener expectativas más realistas y mejor
desempeño.
80
Finalmente, sobre la alineación de los proyectos a los objetivos, en general las empresas
consideraban que la mayoría de proyectos apoyaban a sus objetivos, pero hacían la
salvedad que, en ocasiones, principalmente por temas de facturación han realizado
proyectos que no se alinean con los objetivos:
“Ha habido proyectos que no se alinean con los objetivos, pero los hemos hecho.
Lo más importante es la facturación en realidad.”
“Algunos proyectos no se alinean con los objetivos, la visión de la empresa es

más enfocada a las pymes, pero también se tienen proyectos como tercero de
otras empresas de TI. Estos proyectos, si bien es cierto, no están alineados
digamos a la misión, nos generan caja.”
“Hay temas de proyectos simples, pero que al final no nos retribuye

económicamente, ni tampoco cumple con el objetivo de buscar retos técnicos.”
Con respecto a la priorización de los proyectos, en general, se aprecia que las empresas
no definían prioridades o los priorizaban basándose en fechas de entrega o costo.
“Ahora los proyectos se priorizan en base a fecha de entrega.”
“Cuál es el hito más crítico a cubrir o dependiendo de cuál es el hito que va a

pagar más.”
“La prioridad se afecta un poco cuando no tengo muchos recursos. Entonces si

tengo que estar midiendo la prioridad en función de cuál es el proyecto que
tiene menos holgura o menos tiempo para poder ser entregado.”
Con respecto al seguimiento del portafolio, las empresas entrevistadas centraban el

control de portafolio en el seguimiento de proyectos individuales, apoyado en alguna
herramienta informática para gestión de proyectos (como Trello o Asana) o una
herramienta de ofimática (archivos Excel u Hojas de Cálculo de Google) junto con un
repositorio centralizado (como Google Drive).
El contar con la información centralizada les permite conocer el estado general del
portafolio.
81
“Sobre ese Excel tengo una vista rápida sobre qué proyectos están en estado,
pendiente, en proceso, o finalizados.”
“Primero dentro de una pizarra, ponemos los proyectos pendientes con su

estado y aparte eso mismo se vuelca en un Excel y vamos revisando lo que se
está desarrollando, los que están pendientes o ya finalizados.”
“En el caso de Kanban, en el kanbanize automáticamente nos da un porcentaje

de avance de las tareas en función a las iniciativas que están en el portafolio.”
Lo anterior se muestra como una necesidad en las empresas que no lo tienen:
“Ahorita no hay una forma de ver el estado global de los proyectos. Si tú me

preguntas, hay que entrar a cada una de las carpetas y ver. La idea sería tener
un dashboard que diga cuantos proyectos tengo en cola, cuánto es el porcentaje
de avance y cuál sería de mi atraso.”
“Estamos trabajando en eso. Como somos una empresa pequeña es fácil para
nosotros preguntar ¿cómo va tu proyecto? Pero debe ser algo más formal. No
existe todavía ese mecanismo formal para evaluar la cartera, o gestionar la
cartera de proyectos.”
6.3.3 Gestión de Proyectos
Las capacidades en gestión de proyectos constituyen un prerrequisito para una gestión

de portafolio eficaz (Inger Bergman, Sven Gunnarson, 2013). En esta línea, era
necesario profundizar un poco sobre la forma en que las empresas gestionan sus
proyectos.
Con respecto a las prácticas de gestión de proyectos, dos de las empresas utilizaban la
Guía del PMBOK y un enfoque tradicional de gestión de proyectos, tres de las empresas
utilizaban metodologías ágiles, en especial Scrum. y una de ellas indicaba
explícitamente que utilizaba un enfoque híbrido combinando aspectos de la Guía del
PMBOK con metodologías como Scrum y Kanban.
En el caso de la gestión del alcance, todas las empresas poseían una forma de definir
el alcance del proyecto, utilizando diferentes herramientas como especificaciones de
82
procesos, propuestas técnicas, términos de referencia, prototipado, catálogo de
requisitos funcionales, especificación funcional o un roadmap sobre la base de los
requerimientos del cliente.
En el caso del cronograma, casi todas las empresas utilizaban un cronograma elaborado
en base a juicio experto, sin embargo, cabe mencionar que una de las empresas que se
especializa en métodos ágiles enfatizó que ellos no usaban un cronograma
propiamente.
“Bueno, no usamos cronograma, aunque los clientes a veces nos piden. Lo que
al final hacemos es un timeline del roadmap. Se crea este timeline o roadmap
al inicio y conforme se va desarrollando el proyecto se va adaptando”.
En el caso del presupuesto, todas las empresas tomaban con base para el cálculo del
presupuesto la tarifa por recurso. Para el cálculo de esta tarifa se tomaban diferentes
consideraciones.
En algunos casos dicha estimación se realizaba basándose en algún método conocido
“Hace tiempo, había una escala de Price Water house, que te decía el rol y el
costo por hora. Después descubrí como llegaban a ese monto. Entonces cada
año veo más o menos cuál es el costo estándar en Perú, el costo de consultoría
y tengo un Excel para ello”.
“Hay un modelo que lo aprendí hace poco que se llama Agile Fix Price, que
maneja dos módulos, uno optimista y uno pesimista”
En uno de los casos se mencionaba también que el precio dependía del cliente
“Tratamos de conocer la empresa, porque algunas empresas facturan más,

entonces si se les puede cobrar más. Y no le vas a cobrar lo mismo a las pymes,
porque no te van a pagar”.
83
En el caso de prácticas de aseguramiento y control de calidad, todas las empresas
incluían una fase de pruebas dentro de sus proyectos, pero se identifican diferentes
perspectivas con respecto a la calidad. La tabla 6.7 presenta las afirmaciones de calidad
realizadas por cada empresa.
Tabla 6.8 Actividades de aseguramiento y control de calidad
Empresa Actividades de calidad
E1 “Básicamente el control de calidad que hacemos es de pruebas

internas, lo más clásico que hacemos es probar el funcionamiento con
un juego de datos de prueba, pruebas de stress, lo más básico.”
E18 “Para los proyectos que hemos hecho acá en Perú, hemos tenido que
ser bastante escuetos en el control de calidad con automatización de
algunas cosas que sean posibles. En cambio, para proyectos que
hemos tenido en el extranjero si hemos implementado más
automatización. Esto porque aquí en Perú, al control de calidad no le
ven valor a veces.”
E21 “Hacemos una verificación interna. Generalmente tratamos que

aparte de las pruebas unitarias, en la medida de lo posible haya una
verificación, revisión de pares, verificación del código.”
E22 “Se verifica el alcance y también que el producto esté completo. Es

decir que haya un cumplimiento a satisfacción del cliente. El área de
QA trabaja mucho con los usuarios líderes y el usuario final porque
ellos no solamente hacen pruebas internas, sino también están
involucrados para hacer pruebas externas con el cliente”.
E24 “Hacemos pruebas unitarias cuando son cálculos. El único mitigante

de problemas de calidad es mi etapa de análisis, que cuido un
montón.”
E25 “Manejamos la última fase que es pruebas, pruebas unitarias,

integrales y certificación o del cliente.”
84
De esta forma, se observa que las empresas entrevistadas se enfocaban más en el
control de calidad, sin incluir mucho esfuerzo en actividades de aseguramiento de
calidad.
Con relación a la gestión de riesgos, algunas de las empresas poseían esquemas

definidos para la gestión de riesgos de acuerdo a su metodología de gestión.
“Los riesgos son identificados, hay riesgos al inicio del proyecto y otros que salen
durante el proyecto. Estos se comunican en el informe de seguimiento que
tenemos y sobre ese se va haciendo el seguimiento.”
“Mantenemos una hoja de riesgos, un Excel y ahí se van actualizando cada 4

semanas.”
“En el daily meeting, de los 15 minutos, siempre dejamos un espacio para ver los
riesgos que pueden darse y si requieren más discusión, lo conversamos después
del daily, pero siempre estamos en constante revisión de los riesgos.”
Estas respuestas corresponden a las empresas que reportaban mayor nivel de

aplicación de las prácticas de gestión de portafolio y buenos niveles de rendimiento.
Otras empresas declaraban que no contaban con un esquema definido para gestionar
riesgos. En un caso se mencionaba que se identificaban al inicio, pero no se les hacía
seguimiento.
“Los manejo en el acta de constitución, pero están como de manera de plantilla.”
85
Capítulo 7. Propuesta de Marco de Trabajo
Un marco de trabajo (framework) se define como un conjunto de ideas, información y
principios que forman la estructura de una organización o plan (Cambridge Dictionary,
n.d.). El objetivo de este proyecto es desarrollar un marco de trabajo que sirva de base
para realizar una gestión estratégica del portafolio de proyectos en pequeñas empresas
de desarrollo de software. Para cumplir este objetivo el resultado debería ser flexible a
fin de adaptarse a las características de las empresas y generar beneficios financieros
y estratégicos.
Con base a los hallazgos de las fases previas del estudio, se elaboró una propuesta de
marco de trabajo, para el cual se presenta un conjunto de roles identificados, haciendo
la salvedad de que una persona podría cumplir más de un rol, el esquema general del
marco de trabajo agrupado en bloques y un conjunto de recomendaciones para su
implementación.
Cabe mencionar, que la sección de recomendaciones se generó a partir de las prácticas

recopiladas en las entrevistas, la revisión de literatura y la experiencia del investigador,
pero depende de cada empresa decidir la mejor forma para implementar el marco de
trabajo propuesto.
7.1 Roles
La tabla 7.1 describe los roles que forman parte del marco de trabajo de gestión
estratégica de proyectos y que serán los responsables de ejecutar las actividades del
marco de trabajo descritas en la sección 7.2
Cabe mencionar que una misma persona puede desempeñar más de un rol, sin
embargo, se recomienda que una misma persona no asuma más de dos roles
Tabla 7.1 Roles definidos en el marco de trabajo
Rol Responsabilidad
Alta Dirección Responsable de definir los objetivos de la empresa.
86
Rol Responsabilidad
Responsable del portafolio Responsable de participar en la evaluación de

propuestas y del monitoreo del portafolio.
Responsable de Proyecto Responsable de la gestión de un proyecto específico
Colaboradores Responsables de la ejecución del trabajo del proyecto.
7.2 Esquema General
La figura 7.1 resume las actividades principales propuestas, que las pequeñas empresas
deberían realizar a fin de tener una gestión estratégica de proyectos.
Figura 7.1. Representación del modelo general.
87
7.2.1 Bloque 1 (Estrategia)
El bloque 1 corresponde a la gerencia de la organización, en la que se define los

objetivos de negocio que guían a la empresa, y la responsabilidad de su ejecución recae
en la Alta Dirección.
La definición de objetivos es un prerrequisito para poder implementar el marco de

gestión estratégica de proyectos. Esta definición de objetivos corresponde a los
procesos de Planificación Estratégica. Este tema ha dado lugar a estudios de
investigación previos que muestran que una planificación estratégica formal apoya al
crecimiento de las empresas (Jeffcoate, Chappell, & Feindt, 2002; Kraus, Harms, &
Schwarz, 2006; O’Regan & Ghobadian, 2002; Stonehouse & Pemberton, 2002; Vargo &
Seville, 2011).
Si bien el tema de identificar herramientas de planificación estratégica para pequeñas

empresas queda fuera del alcance de este trabajo, el marco incluye algunas
recomendaciones generales al momento de definir sus objetivos.
1. La empresa debe tener una misión definida, teniendo en cuenta que la misión
define el propósito básico de la organización y define el alcance de los productos
y mercados (Pearce & David, 1987). Esta misión debería ser compartida con
toda la organización.
2. Siguiendo las recomendaciones de Jeffcoate (2002), se debería empezar

identificando la actitud de la organización hacia el crecimiento, definir las líneas
de negocio, establecer objetivos para cada una de ellas y elaborar estrategias
para conseguirlos.
3. Con respecto a los objetivos, estos podrían desarrollarse teniendo en cuenta las
perspectivas del Balanced ScoreCard (Atkinson, 2006):
a. Perspectiva financiera (tales como facturación, rentabilidad, reducción de

costos, etc.)
b. Perspectiva de negocio interna (tales como objetivos de calidad)
88
c. Perspectiva del cliente (niveles de satisfacción del cliente)
d. Perspectiva de aprendizaje y crecimiento (objetivos de capacitación o
aprendizaje, número de proyectos de cierto tipo, desarrollo de nuevos
productos o incursión en nuevos mercados).
El horizonte de tiempo para estos objetivos debería ser de mínimo un año, pero es
recomendable pensar en objetivos a más largo plazo.
Cabe mencionar que todos los ejemplos de objetivos anteriores se vieron reflejados en
al menos una de las empresas entrevistadas durante el estudio de caso.
Una vez definidos los objetivos, es recomendable difundirlos a toda la organización.
7.2.2 Bloque 2 (Propuestas de Proyecto o Portafolio de ideas)
El bloque 2 corresponde a los aspectos comerciales de la empresa, pues en esta etapa

es que se debe:
 Generar ideas para proyectos internos

 Identificar convocatorias o licitaciones donde se pueda participar
 Recibir directamente solicitudes de proyectos de parte de un cliente
A fin de lograr los objetivos establecidos, puede ser necesario revisar el proceso de
ventas de la empresa. Si bien, en la mayoría de las empresas entrevistadas, la forma
de conseguir proyectos era principalmente por recomendación, a fin de crecer puede
ser necesario utilizar otras estrategias de acercamiento con los clientes, como
participación en procesos de licitación o campañas de marketing. Así mismo, es
importante analizar si la persona que estaría a cargo de este proceso tendría el perfil o
competencias requeridas.
Para el caso de pequeñas empresas la responsabilidad de este bloque puede recaer en

un área o responsable comercial, pero usualmente habrá una fuerte participación de la
Alta Dirección.
89
7.2.3 Bloque 3 (Definición y Gestión del Portafolio)
El bloque 3 corresponde propiamente a la definición y gestión del portafolio de

proyectos, y el principal responsable de su ejecución es el responsable del Portafolio,
quien recibe información de los responsables de proyecto y reporta a la Alta Dirección.
Este bloque incluye las siguientes actividades:
A. Elaborar una Tipificación de Proyectos. Esta tipificación se basa en las líneas de

negocio y otros criterios definidos por la empresa.
B. Evaluar propuestas: Para la evaluación de las propuestas se debe tener en

cuenta los siguientes aspectos:
 Alineamiento con los objetivos de negocio

 Balanceo del portafolio
 Criterios propuestos por el marco de trabajo (previa asignación de pesos)
 Criterios específicos por cada empresa
Los criterios propuestos por el marco de trabajo incluyen:
 Facturación/Rentabilidad
 Tecnología
 Disponibilidad de recursos
 Duración del proyecto
 Conocimiento previo del cliente
 Nivel de riesgo del proyecto
C. Gestionar proyectos: Para la gestión de los proyectos, puede utilizarse

metodologías basadas en la Guía del PMBOK u otro estándar, metodologías
ágiles como Scrum, o metodologías híbridas. Sin embargo, en cualquiera de los
casos, el responsable del proyecto debe tener indicadores definidos, los cuales
deben ser reportados al responsable del portafolio. Los indicadores mínimos
requeridos son:
90
 Porcentaje de avance
 Cumplimiento de cronograma
 Necesidad de recursos adicionales (en caso se requiera)
D. Gestionar portafolio: Cada proyecto debe tener una prioridad asignada y el

portafolio debe ser monitoreado con base en una periodicidad establecida, es
decir, los proyectos deben reportar el nivel de avance en función del alcance,
cronograma y presupuesto.
Dentro de este proceso también debe evaluarse la satisfacción del cliente.
E. Evaluar resultados: Al culminar el proyecto, debe evaluarse sus resultados y su

impacto sobre los objetivos de negocio.
7.3 Recomendaciones para la implementación
Esta sección incluye algunas recomendaciones enfocadas en el bloque 2 y 3 para la

definición y gestión del portafolio.
7.3.1 Generación de propuestas para proyectos internos
 Para el caso de generación de ideas internas, estas pueden venir de los

directivos o de los mismos empleados.
 Para promover la generación de ideas con empleados, se puede brindar un
espacio, en el cual los empleados puedan expresar sus ideas. Esto puede
lograrse en una reunión grupal, individual o a través de una plataforma en línea.
 Una posibilidad adicional es desarrollar un nuevo producto a partir de un
producto a medida desarrollado previamente.
7.3.2 Elaboración de propuestas
 Para elaborar una propuesta técnica, sea para una licitación o para atender el
pedido de un cliente, se debería involucrar al líder de proyecto (si existiese) y a
91
personal técnico, a fin de identificar adecuadamente el tiempo y recursos
requeridos, lo que a su vez le permita elaborar la propuesta económica.
 La propuesta elaborada debe ser revisada usando las recomendaciones para la
evaluación de propuestas de la sección 7.2.3 antes de enviarla al cliente.
7.3.3 Evaluación de propuestas
 En la evaluación de las propuestas es recomendable que participe más de una

persona, de esa forma se realiza un análisis más objetivo.
 La evaluación de la propuesta se puede realizar usando una hoja de cálculo o
alguna otra herramienta que la organización prefiera.
 La propuesta debe poder asociarse con al menos un objetivo de negocio, caso
contrario debería ser rechazada.
 La evaluación debería incluir todos los criterios propuestos por el marco de
trabajo, y cada empresa puede asignar un conjunto de criterios específicos de
acuerdo a sus objetivos. Por ejemplo, una empresa podría optar por agregar
como criterio el nivel de reto o aprendizaje que traería el proyecto.
 Es posible definir un conjunto de criterios distintos para proyectos de desarrollo
para clientes y proyectos de desarrollo de nuevos productos.
 El primer paso para utilizar la lista de criterios es asignar un peso a cada uno de
ellos. Este peso debería ir entre 1 y 3, donde 1 es poco importante y 3 es muy
importante. Estos pesos deberían mantenerse en el tiempo. Si bien, es posible
modificarlos cuando se realiza un cambio a los objetivos o estrategias, no
deberían modificarse con cada propuesta.
 A cada criterio se le asigna un valor entre 0 y 3 de acuerdo al proyecto y se suma
los resultados. La organización debería fijar un valor mínimo que determine si el
proyecto es conveniente para la empresa.
 Cuando se evalúa dos posibles proyectos o propuestas, la más recomendable
sería la que obtenga mayor puntaje, sin embargo, la decisión final puede verse
influenciada por algunos otros factores, por lo que la decisión final depende del
responsable de la toma de decisiones.
 La evaluación de propuestas debería quedar almacenada en algún repositorio
local, en la nube, o en una herramienta de gestión de propuestas o ideas.
 Las propuestas aprobadas deben ser registradas en la lista de proyectos. Esta
puede ser gestionada en un archivo centralizado (como un Excel), un repositorio
92
en la nube (como un spreadsheet de Google) o en una herramienta de gestión
de proyectos.
 Un aspecto final para considerar en la evaluación de propuestas es el balanceo
del portafolio. Esto implica que la empresa debe definir qué porcentaje de
recursos asignará al desarrollo de nuevos productos (asumiendo que esto sea
parte de sus objetivos), y con base en ello, determinar los proyectos que puede
realizar y el horizonte de tiempo en que se podría lograr.
7.3.4 Gestión de Proyectos
 El responsable del proyecto podría tener el rol de líder de proyecto, jefe de

proyecto, Scrum Master o cualquier otro rol que defina la empresa, pero será el
responsable de reportar la situación del proyecto.
 Para la gestión de los proyectos, puede utilizarse metodologías basadas en la
Guía del PMBOK u otro estándar, metodologías ágiles como Scrum o
metodologías híbridas, según la preferencia de la empresa. También es posible
tener proyectos que son gestionados bajo el esquema de la Guía del PMBOK
Guide y otros gestionados utilizando Scrum.
 El responsable de proyecto debe reportar los indicadores del proyecto al
responsable del portafolio con la frecuencia establecida por la empresa. Esta
frecuencia dependerá del tamaño del proyecto, pero se recomienda como
mínimo una periodicidad quincenal.
 El responsable del proyecto debe tener conocimiento de cómo su proyecto
aporta a los objetivos de la empresa y la prioridad del mismo y transmitir esto al
equipo de proyecto.
 Es conveniente incluir en el contrato o acuerdo de trabajo las condiciones para
la realización del proyecto relacionadas con la gestión del proyecto (por ejemplo,
definir punto focal, aprobación de cambios, entre otros).
 Es recomendable verificar el perfil de la persona responsable del proyecto a fin
de garantizar que pueda cumplir con sus responsabilidades de gestión.
93
7.3.5 Gestión de Portafolio
 Cada proyecto debería tener una prioridad entre 1 y 3 (donde 1 es baja, 2 es

media y 3 es alta), la cual puede cambiar con el tiempo.
 La prioridad debe tomarse en cuenta en caso se requiera reasignar recursos de
un proyecto a otro.
 Para la asignación de prioridad se debe tener en cuenta el aporte a los objetivos
de negocio y la urgencia del proyecto.
 El responsable del portafolio recibirá de parte de los responsables del proyecto
los indicadores definidos y los almacenará en un repositorio centralizado, de esta
forma podrá saber el estado del portafolio en cualquier momento.
 Todo proyecto debe tener un estado. Los estados sugeridos son “Pendiente de
Inicio” “En proceso”, “Detenido”, “Cerrado” o “Cancelado”. El proyecto se
encuentra “Pendiente de Inicio” cuando ya ha sido aprobado, pero aún no está
ejecutando; “En Proceso” mientras se está desarrollando; “Detenido” si por
alguna razón el trabajo se ha detenido a la espera de alguna renegociación o
respuesta por parte del cliente; “Cerrado” una vez se reciba el acta de aceptación
o “Cancelado” cuando un proyecto es cancelado antes de terminar.
 El responsable de portafolio debería solicitar los indicadores a los responsables
de proyectos en caso no los reciba según la periodicidad establecida.
 El responsable del portafolio debería reunirse con el responsable del proyecto al
menos en forma quincenal para conocer con más detalle el estado del proyecto.
 La evaluación de satisfacción del cliente puede realizarse mediante una
encuesta en papel o en línea, pero no es conveniente postergar la evaluación de
satisfacción de cliente hasta el final del proyecto. Dependiendo de la duración
del proyecto se recomienda realizar al menos una evaluación intermedia.
7.3.6 Evaluación de resultados
 Terminado el proyecto debe evaluarse el aporte del resultado final a los objetivos
de negocio y la experiencia debe servir como input para el proceso de evaluación
de nuevas propuestas.
 De manera anual debería evaluarse el logro de los objetivos de negocio y
plantear nuevos sobre la base de los resultados obtenidos y un análisis del
contexto.
94
Capítulo 8. Validación del Marco de Trabajo
Como parte final de este proyecto de investigación, se requería validar la aplicabilidad y
utilidad del marco de trabajo propuesto. A fin de cumplir este objetivo, se realizó un
proceso de implementación del marco de trabajo en dos empresas. Para ello, las
empresas recibieron una inducción al marco de trabajo y durante el tiempo de
implementación contaron con el apoyo del investigador para finalmente realizar una
evaluación de su satisfacción con la aplicación del marco de trabajo y su utilidad en
relación al desempeño de la empresa.
Los resultados muestran que en ambas empresas donde se implementó el marco de

trabajo, la percepción sobre la utilidad es muy buena y que las expectativas de
cumplimiento de objetivos son positivas tras la implementación.
El resto del presente capítulo describe en detalle cómo se realizó el proceso de

validación, los principales hechos identificados y los resultados obtenidos luego de la
implementación del marco de trabajo.
8.1 Proceso de validación
Para la validación del marco de trabajo se llevaron a cabo las siguientes actividades:
8.1.1 Convocatoria a empresas
La convocatoria a empresas se realizó a través de tres canales
a) Listado de empresas que participaron en las primeras partes del estudio

b) Redes de contacto del investigador
c) Difusión por el PMI Lima Perú Chapter
Como resultado de esta fase se seleccionaron dos empresas interesadas en

implementar el marco de trabajo. Una de ellas corresponde al grupo de empresas que
participaron en las primeras dos fases del estudio (identificada con la sigla E1), mientras
que la segunda se incorporó al proyecto de investigación en esta última fase y se le
identificó como E30.
95
E30 es una pequeña empresa de desarrollo de software, que al inicio de la
implementación tenía un año de antigüedad, entre 5 y 10 trabajadores y dos líneas de
negocio principales, desarrollo de software y mejora de procesos. Cada línea tenía un
responsable asignado y en la línea de desarrollo de software manejaban entre 2 y 5
proyectos en paralelo.
8.1.2 Evaluación previa
Las empresas interesadas tuvieron que responder a un cuestionario inicial a fin de tener
una línea base con respecto a la aplicación de prácticas de gestión de proyectos y
gestión de portafolio. Para esto se utilizó el mismo cuestionario empleado en el estudio
exploratorio.
En el caso de la empresa que participó en la primera parte del estudio, se solicitó que
volviera a completar el cuestionario, a fin de contar con un mismo punto de partida en el
tiempo.
Cabe recordar que este cuestionario cubría cuatro aspectos:
 Gestión de Proyectos (7 preguntas)

 Gestión de Portafolio (9 preguntas)
 Percepción de rendimiento financiero (2 preguntas)
 Percepción de rendimiento estratégico (4 preguntas)
Cada pregunta se evaluó en una escala de Likert de 7 puntos. La tabla 8.1 muestra las
respuestas por cada empresa y la tabla 8.2 muestra los resultados sumarizados.
Tabla 8.1 Evaluación inicial - Fase validación
Categoría Pregunta E1 E30

Gestión de La empresa controla el alcance de los
Proyectos proyectos realizados 6 4
La empresa control el cronograma de los
(1 Total Desacuerdo proyectos realizados 5 5
- 7 Completamente La empresa controla el presupuesto de los
de acuerdo) proyectos realizados 2 6
96
La empresa aplica prácticas de
aseguramiento o control de calidad en los
proyectos 1 4
La empresa gestiona riesgos en los
proyectos realizados 1 5
En general los proyectos terminan a tiempo 4 6
En general los clientes reportan pocos
defectos tras la entrega del proyecto 4 6
La empresa lleva un registro del portafolio
de proyectos en ejecución 6 5
El portafolio de proyectos que maneja la
empresa incluye proyectos internos 6 6
El portafolio de proyecto incluye proyectos
de innovación 4 5
Al momento de decidir realizar un proyecto
se toma en cuenta criterios definidos 2 6
Los proyectos realizados se alinean con los
objetivos de empresa 6 5
Gestión de se analizan los recursos requeridos 6 6
Portafolio Al momento de decidir realizar un proyecto
se consideran los riesgos que genera 5 5
(1 Total Desacuerdo La empresa periódicamente revisa el
- 7 Completamente estado del portafolio de proyectos en
de acuerdo) ejecución 5 6
La empresa define distintas prioridades
para los proyectos que forman parte del
portafolio 6 6
La empresa monitorea el desempeño del
portafolio 5 6
Existe una buena comunicación entre la
alta dirección y los responsables del
portafolio de proyectos 5 7
Existe una buena comunicación entre los
responsables del portafolio de proyectos y
los responsables de cada proyecto 5 6
Crecimiento de ventas fue en
comparación con nuestros competidores 4 5
Rendimiento Crecimiento de ganancias fue
en comparación con nuestros
(1 Total Desacuerdo competidores 4 4
- 7 Completamente Crecimiento de empleo fue en
de acuerdo) comparación con nuestros competidores 4 4
El desempeño general del negocio cumple
con las expectativas 1 5
97
El rendimiento general del negocio supera
al de nuestros principales competidores 1 3
La alta gerencia está satisfecha con el
desempeño general del negocio 1 4
Tabla 8.2 Resumen Evaluación inicial - Fase validación

E1 23 61 84 8 7 15
E30 36 69 105 9 16 25
Cabe mencionar que, en el caso de la empresa E1, se observó una disminución en los
resultados de gestión de proyectos comparados con la evaluación inicial mostrada en la
tabla 6.2, pero también cabe precisar que la empresa E1 fue una de las primeras en
participar en el estudio y que la segunda evaluación fue realizada 11 meses después de
la primera.
Con base en la evaluación previa, se elaboró un plan de acompañamiento a las

empresas para el proceso de implementación del marco de gestión estratégica de
proyectos.
8.1.3 Apoyo en la implementación
Con la lista de empresas seleccionadas, se elaboró un cronograma de capacitación y

asesoría a fin de implementar el marco de trabajo. La labor del investigador en esta fase
fue la de brindar apoyo, la implementación en sí fue realizada por personal de la misma
empresa.
Durante el periodo de implementación, se llevaron a cabo reuniones periódicas con los

representantes de la empresa para evaluar sus avances y brindar sugerencias.
Algunos datos adicionales sobre estas reuniones se describen a continuación:
98
 En ambas empresas, las reuniones se realizaron con presencia de más de un
representante de la empresa.
 En todas las reuniones estuvo presente el gerente general.
 La mayoría de las reuniones se realizaron en las instalaciones de la empresa,
aunque por disponibilidad de tiempo, algunas de las reuniones se realizaron en
forma virtual.
 En ambos casos, las reuniones tuvieron objetivos específicos según muestra la
tabla 8.3
Tabla 8.3 Objetivos por Reunión
Número de Reunión Objetivo
1 Presentación del marco de trabajo y Plan de

implementación por parte del Investigador.
2 Explicación por parte de la empresa del modelo de

negocio y objetivos de negocio.
3 Identificación de prácticas actuales para la gestión de

proyectos y gestión de portafolio.
4 en adelante Presentación de avances por parte de la empresa y

recomendaciones por parte del investigador.
8.1.4 Hechos relevantes
Durante el periodo de implementación, se observó algunos hechos en ambas empresas,

los cuales se describen a continuación, a fin de proveer una mejor visión de cómo se
realizó la implementación.
a) En ambas empresas el gerente estaba involucrado directamente en la gestión

de proyectos, sin embargo, tras la implementación del marco, el gerente se
enfocó más en temas estratégicos y comerciales, dejando la responsabilidad de
gestionar los proyectos específicos a otra persona de la empresa. En un caso
esta persona ya formaba parte de la empresa, mientras que en otro caso la
persona fue contratada específicamente para ese fin.
99
b) En ambos casos se utilizaron herramientas gratuitas o de bajo costo para apoyar
en la gestión. Cabe mencionar el uso de Google Drive Google como repositorio
de información, una hoja de cálculo de Google compartida para la administración
de la lista de proyectos y Trello para la gestión de proyectos.
c) Tras revisar los objetivos de negocio con la empresa, ambas empresas notaron
que debían ajustar sus objetivos de negocio, de acuerdo a la visión que tenían
para la empresa. En ambos casos se optó por definir objetivos anuales.
d) Tras realizar la tipificación de proyectos, ambas empresas pudieron identificar

qué tipo de proyectos les generaban mayores beneficios.
e) Los pesos asignados a cada uno de los criterios para evaluación de propuestas,
identificados en el marco, fueron diferentes en ambas empresas. Estos se
definieron en una de las reuniones de seguimiento con la empresa.
f) Ambas empresas solicitaron ejemplos de formatos que podrían utilizar. Ante esta
solicitud se distribuyó a las empresas tres formatos que pudieran adaptar a sus
necesidades:
 Formato para evaluación de propuestas
 Formato para evaluar el logro de los objetivos
 Formato de registro de proyectos
Estos formatos se encuentran en el anexo 14
g) En una de las empresas se tenía en curso un proyecto de innovación, el cual fue

dejado de lado tras analizar la capacidad de recursos disponibles en la empresa
y potencial de mercado. Al final del estudio estaban evaluando posibilidades para
iniciar un proyecto de innovación diferente.
8.1.5 Evaluación de la implementación
Con base en los mismos criterios utilizados en la evaluación inicial, se realizó una
evaluación final consistente en dos componentes
100
a) Evaluación de implementación de las prácticas descritas en el marco de trabajo
b) Evaluación de la percepción del gerente de la empresa sobre el impacto en el
rendimiento.
Para realizar esta evaluación se utilizaron dos instrumentos:
 Cuestionario en línea que evalúa la aplicación de las prácticas de gestión de

proyectos y gestión de portafolio y que permitió la comparación con los
resultados de la línea base descrita en la sección 8.1.2.
 Entrevista con el gerente de la empresa.
8.1.6 Resumen de resultados
Con base en el proceso de evaluación final se presentan los resultados en la presente

sección. El anexo 15 presenta algunos detalles adicionales sobre la implementación
del marco en cada una de las empresas participantes.
La tabla 8.4 presenta los resultados de aplicación de las prácticas de gestión de proyecto
y gestión de portafolio en las empresas tras la implementación del marco de gestión
estratégica de proyectos obtenidas a través de un cuestionario en línea. Así mismo, por
facilidad de lectura, la tabla 8.5 presenta el resumen de resultados, comparándolos con
los de la evaluación inicial, a fin de poder identificar la mejora en la aplicación de las
prácticas.
Tabla 8.4 Implementación de Prácticas de Gestión de Portafolio de Proyectos

La empresa controla el alcance de los
Gestión de
La empresa control el cronograma de los
Proyectos 6 6
proyectos realizados
(1 Total Desacuerdo La empresa controla el presupuesto de los
- 7 Completamente proyectos realizados 5 5
de acuerdo) La empresa aplica prácticas de
aseguramiento o control de calidad en los
proyectos 5 5
101
La empresa gestiona riesgos en los
En general los proyectos terminan a tiempo 7 6
En general los clientes reportan pocos
defectos tras la entrega del proyecto
6 6
Porcentaje Obtenido 81.6% 83.6%

La empresa lleva un registro del portafolio
de proyectos en ejecución 7 7
El portafolio de proyectos que maneja la
empresa incluye proyectos internos 7 7
El portafolio de proyecto incluye proyectos
de innovación 7 6
se toma en cuenta criterios definidos 7 7
Los proyectos realizados se alinean con los
objetivos de empresa 7 6
Gestión de se analizan los recursos requeridos 6 6
Portafolio Al momento de decidir realizar un proyecto
se consideran los riesgos que genera 6 6
(1 Total Desacuerdo La empresa periódicamente revisa el
- 7 Completamente estado del portafolio de proyectos en
de acuerdo) ejecución 6 7
La empresa define distintas prioridades
para los proyectos que forman parte del
portafolio 7 7
La empresa monitorea el desempeño del
portafolio 6 7
Existe una buena comunicación entre la
alta dirección y los responsables del
portafolio de proyectos 6 7
Existe una buena comunicación entre los
responsables del portafolio de proyectos y
los responsables de cada proyecto 7 7
Porcentaje Obtenido 94% 95.2%
Para calcular el porcentaje de aplicación de las prácticas de gestión de proyectos y

gestión de portafolio se sumó los valores obtenidos en cada una de las secciones y se
calculó el porcentaje en función del valor máximo alcanzable. De esta forma se observa
que la empresa E1, tras la implementación del marco de gestión estratégica tiene un
102
81.6 % de cumplimiento en la aplicación de prácticas de gestión de proyectos y un 94%
de cumplimiento en la aplicación de prácticas de gestión de portafolio.
De manera análoga, la empresa E30 tiene un 83.6% de cumplimiento en la aplicación
de prácticas de gestión de proyectos y un 95.2 % de cumplimiento en la aplicación de
prácticas de gestión de portafolio.
Tabla 8.5 Resumen Implementación de Prácticas de Gestión de Portafolio de

Proyectos
Gestión de Proyectos Gestión de Portafolio Total,

Empresa
(máx. 49) (máx. 84) (Max 133)
Inicial Final Mejora Inicial Final Mejora Inicial Final Mejora
E1 23 40 34% 61 79 21% 84 119 26.3%
E30 36 41 10.2% 69 80 13% 105 120 11.2%
En la tabla 8.5 se puede apreciar que, tras la implementación del marco de gestión
estratégica de proyectos, ambas empresas aplican con mayor frecuencia el uso de
prácticas asociadas a la gestión de proyectos y gestión de portafolio. Para el caso de
E1 se aprecia una mejora de 34% en la aplicación de prácticas de gestión de proyectos
y una mejora de 21% en la aplicación de prácticas de gestión de portafolio, mientras que
para E30 se aprecia una mejora de 10.2% en la aplicación de prácticas de gestión de
proyectos y una mejora de 13% en la aplicación de prácticas de gestión de portafolio
Con respecto al rendimiento de la empresa, se consultó al gerente sobre el rendimiento

actual y su expectativa de cumplimiento de los objetivos anuales.
La tabla 8.6 muestra los resultados de la percepción del rendimiento actual de la

empresa por parte del gerente y la tabla 8.7 presenta los resultados obtenidos en forma
sumarizada.
Tabla 8.6 Percepción sobre el rendimiento de la empresa luego de la implementación

del marco de gestión estratégica de proyectos
Crecimiento de ventas fue en
Rendimiento comparación con nuestros competidores 5 5
Crecimiento de ganancias fue
(1 Total Desacuerdo en comparación con nuestros
- 7 Completamente competidores 4 5
de acuerdo) Crecimiento de empleo fue en
103
El desempeño general del negocio cumple
con las expectativas 5 5
El rendimiento general del negocio supera
al de nuestros principales competidores 4 5
La alta gerencia está satisfecha con el
desempeño general del negocio 6 6
De manera similar a lo realizado con la evaluación de prácticas de gestión de proyectos
y gestión de portafolio se sumó los valores obtenidos en las preguntas relacionadas al
rendimiento, los cuales se muestran en la tabla 8.7
Tabla 8.7 Resumen de variación en la percepción sobre el rendimiento de la empresa
Rendimiento Financiero Rendimiento estratégico Total,

Empresa
(máx. 14) (máx. 28) (Max 42)
Inicial Final Inicial Final Inicial Final
E1 8 9 7 19 15 28
E30 9 11 16 22 25 33
Los resultados obtenidos sugieren una ligera mejora en el rendimiento financiero y una
mejora más significativa en el rendimiento estratégico. Cabe mencionar que ambas
empresas indicaron durante la entrevista que en los últimos tres meses habían mejorado
la facturación. Cabe recordar también, que estas empresas realizan proyectos cortos,
con duración promedio entre 1 y 3 meses.
A fin de contar con mayor información sobre la percepción de utilidad del marco de
gestión estratégica se realizaron tres preguntas adicionales:
 Tengo confianza que este año el crecimiento de ventas será en

comparación con nuestros competidores-.
 Tengo confianza que el crecimiento de ganancias será en
 Tengo confianza que el crecimiento de empleo será en
Cada una de las anteriores se evaluó en una escala de Likert de 7 puntos, donde 1
representaba un desempeño malo y 7 un desempeño sobresaliente. La tabla 8.8
presenta los resultados a estas preguntas.
104
Tabla 8.8 Expectativas del gerente general tras la implementación del marco de
gestión estratégica de proyectos

Tengo confianza que este año el
crecimiento de ventas será en
Expectativas comparación con nuestros competidores 5 6
(1 es un desempeño Tengo confianza que el crecimiento de

muy malo y 7 un ganancias será en
desempeño
sobresaliente) Tengo confianza que el crecimiento de
empleo será en comparación
con nuestros competidores. 6 6
Finalmente, se consultó sobre la utilidad percibida del marco de gestión estratégica con
la siguiente pregunta
 ¿La implementación del marco ha ayudado a mejorar el desempeño de la empresa?
Esta última se evaluó también en una escala de Likert de 7 puntos, donde 1 representa
total desacuerdo y 7 totalmente de acuerdo. Los valores obtenidos se muestran en la
tabla 8.9
Tabla 8.9 Percepción de utilidad del marco de gestión estratégica de proyectos

Percepción de
utilidad
La implementación del marco ha ayudado a
7 7
(1 total desacuerdo mejorar el desempeño de la empresa
y 7 completamente
de acuerdo)
Los resultados muestran que, en ambas empresas, donde se implementó el marco de

trabajo, la percepción sobre la utilidad es muy buena y que las expectativas de
cumplimiento de objetivos son positivas tras la implementación.
105
Capítulo 9. Conclusiones y trabajos futuros
Tras la ejecución de este proyecto de investigación se tienen las siguientes conclusiones
La revisión del estado del arte realizada como parte de la investigación muestra que la
gestión de portafolio de proyectos ha sido tratada en múltiples publicaciones a través
principalmente de estudios de casos, los cuales identifican herramientas, factores de
éxito y desafíos para su implementación. Estos proponen que la gestión de portafolio de
proyectos contribuye positivamente al desempeño de la organización, sin embargo, la
ausencia de estudios cuantitativos limita la posibilidad de generalizar estos resultados.
En cuanto al contexto en que ha sido realizada la investigación previa, la mayoría de

publicaciones se enfocan en medianas o grandes empresas. Solo algunos autores
incluyen en su muestra pequeñas empresas y ninguno en el contexto latinoamericano,
dejando un amplio campo de investigación en estos contextos.
Si bien existen múltiples formas de evaluar el rendimiento de las empresas, una

combinación de métricas financieras con metas estratégicas permite una mejor visión
sobre los resultados de la empresa. Siguiendo esta idea, el modelo planteado por
Roach (2011) permitió obtener una visión general sobre el rendimiento percibido por
parte de los directivos de las empresas participantes en la investigación.
La metodología de estudio mixto planteada permitió soportar el proceso para responder

a las preguntas de investigación y obtener los objetivos esperados. Con la aplicación de
la metodología se pudo identificar un conjunto de prácticas de gestión del portafolio
aplicables en pequeñas empresas, que sirvieron de base para la elaboración del marco
de trabajo, cuyos resultados muestran una mejora en el rendimiento de la empresa tras
su implementación
La primera fase del proyecto permitió identificar un grupo de trece empresas que
aplicaban prácticas asociadas a la gestión de portafolio de proyectos. Aunque no es
posible generalizar los resultados, cabe observar que las organizaciones que aplicaban
106
en mayor porcentaje las prácticas de gestión de portafolio coincidían con las
organizaciones que reportaban un mejor rendimiento. Esto permitió también ajustar el
cuestionario que se utilizó en la fase cualitativa.
La fase cualitativa del estudio, llevada a cabo a través de entrevistas a 6 empresas

participantes en la fase exploratoria, permitió identificar cómo las pequeñas empresas
aplican las prácticas asociadas a la gestión de portafolio y gestión de proyectos. Dentro
de este proceso se pudo identificar un conjunto de criterios que las pequeñas empresas
de desarrollo de software podrían considerar al momento de seleccionar y priorizar
proyectos. Así mismo, las entrevistas realizadas confirmaron que todas las empresas
tenían objetivos definidos, aunque no en todos los casos estaban adecuadamente
documentados.
Los resultados de esta fase también parecen sugerir que el impacto de la gestión de
portafolio de proyectos sobre el rendimiento de la empresa se ve afectado por la
experiencia previa del gerente. Aunque la investigación realizada no se enfocó en
evaluar esta relación, esta hipótesis es apoyada por estudios como Staniewski (2016),
Cassar (2014) y Stuart & Abetti (1990) quienes afirman que la experiencia previa
contribuye a tener expectativas más realistas y mejor desempeño.
Las dos primeras fases sirvieron como base para elaborar una propuesta de marco de
trabajo que busque ser fácil de implementar en pequeñas empresas de desarrollo. Este
marco de trabajo incluye la revisión de los objetivos estratégicos, gestión del portafolio
y la gestión de proyectos específicos. En opinión de las empresas participantes en la
última fase del proyecto, cuyo objetivo fue validar el marco de trabajo, este objetivo fue
logrado. Así mismo, las dos empresas en que se aplicó el marco de trabajo expresaron
estar totalmente de acuerdo en que el marco de trabajo contribuyó a la mejora del
rendimiento de la organización.
Las implicaciones del presente trabajo de investigación pueden agruparse en (a)

implicaciones académicas, tanto para la literatura de gestión de proyectos como para la
de gestión estratégica; y (b) implicaciones prácticas para los profesionales responsables
del portafolio de proyectos en las organizaciones.
107
Desde un punto de vista académico, el estudio (1) ha brindado un análisis de la literatura
existente, que se ha desarrollado sobre el tema de la gestión de portafolio de proyectos
y su relación con el rendimiento de la empresa; (2) presenta un esquema de
investigación que puede ser replicado para evaluar el impacto de la gestión de portafolio
de proyectos en otros sectores de la industria; (3) verifica la aplicabilidad de las prácticas
de gestión de portafolio en pequeñas empresas desarrolladores de software; (4)
identifica un conjunto de criterios que deberían tomarse en cuenta al momento de
evaluar propuestas de proyectos; (5) presenta un marco de trabajo para la gestión
estratégica de proyectos en pequeñas empresas de desarrollo de software; y (6) aunque
el número de casos no permite la generalización de los resultados recoge evidencia que
soporta la hipótesis que la aplicación de gestión de portafolio de proyectos predice una
mejora en el rendimiento de la organización.
Desde el punto de vista práctico, el marco de trabajo provee un conjunto de lineamientos

para la implementación de la gestión de portafolio en pequeñas empresas de desarrollo
de software, el cual puede ser aplicado fácilmente por las personas responsables de su
implementación en las empresas.
Aunque del estudio se concluye que es posible implementar todos los procesos de la
gestión de portafolio en pequeñas empresas, se verifica que la forma de implementación
difiere de las prácticas de implementación en empresas grandes donde se ha realizado
la mayor parte de la investigación en el tema.
El marco de trabajo planteado proporciona un conjunto de lineamientos desarrollados

sobre la base de la revisión de investigaciones previas, el estudio de casos de empresas
peruanas de desarrollo de software y la validación de este, el cual no requiere incurrir
en gastos que podrían afectar negativamente el rendimiento de la empresa. Sin
embargo, se debe tomar en cuenta que el rendimiento de las pequeñas empresas se ve
afectado por varios factores (como se menciona la sección 2.3) por lo que la sola
implementación del marco de trabajo no puede garantizar el éxito de la empresa.
108
Como lección aprendida, tras la realización del proyecto, se puede mencionar la
necesidad de adaptación a las condiciones de la empresa. Para el proyecto en cuestión,
algunas reuniones se llevaron a cabo en la oficina de la empresa, pero otras se tuvieron
que realizar en ubicaciones cercanas a donde se encontraban las personas en ese
momento. Esto debido a que los directivos y responsables del portafolio están
permanentemente visitando clientes. El uso de la tecnología de videollamada también
resultó ser una alternativa útil en estos casos, sin embargo, se observó que el nivel de
atención de las personas involucradas era mayor cuando las reuniones se realizaban
en forma presencial.
Por otro lado, cabe mencionar que en algunos casos las pequeñas empresas están
principalmente preocupadas por subsistir. Esto hace que su estrategia se enfoque en el
flujo de caja y deja poco espacio para plantear mejoras estratégicas.
Este proyecto de investigación incluyó una encuesta a 25 empresas del rubro, seguida
de un estudio de caso múltiple con 6 de ellas y una implementación del marco de trabajo
en 2 pequeñas empresas desarrolladoras de software. Debido al tamaño de la muestra
no es posible generalizar los resultados, pero establece un punto de partida para
investigaciones futuras.
Como trabajos futuros se plantea realizar la implementación en un mayor número de

empresas del rubro de desarrollo de software. Así mismo, considerando que cada
industria puede tener necesidades específicas se plantea replicar el estudio en otras
industrias a fin de identificar su aplicabilidad.
Finalmente, considerando que los países de Latinoamérica poseen características

similares, es posible replicar el estudio en otros países de la región e identificar su
aplicabilidad en contextos distintos. Para esto, ya se han iniciado conversaciones con
los capítulos de PMI de Latinoamérica para evaluar su viabilidad.
109
Capítulo 10. Referencias
Administration, U. S. B. (2012). Table of Small Business Size Standards Matched to

North American Industry Classification System Codes.
Allen, M. (2017). The SAGE Encyclopedia of Communication Research Methods.

https://doi.org/10.4135/9781483381411 NV - 4
Alsudiri, T., Al-Karaghouli, W., & Eldabi, T. (2013). Alignment of large project
management process to business strategy A review and conceptual framework.
https://doi.org/10.1108/JEIM-07-2013-0050
APESOFT. (2015). La Industria Peruana del Software: Cifras de cierre 2014 (Boletín
No. 1). Lima.
Artto, K. A., & Wikström, K. (2005). What is project business? International Journal of
Project Management, 23(5), 343–353.
https://doi.org/10.1016/j.ijproman.2005.03.005
Artto, K., Kulvik, I., Poskela, J., & Turkulainen, V. (2011). The integrative role of the
project management office in the front end of innovation. International Journal of
Project Management, 29(4), 408–421.
Atkinson, H. (2006). Strategy implementation: a role for the balanced scorecard?

Management Decision, 44(10), 1441–1460.
https://doi.org/10.1108/00251740610715740
Avolio, B., Mesones, A., & Roca, E. (2011). Factores que limitan el crecimiento de las
micro y peque{ñ}as empresas en el Per{ú} (MYPES). Strategia, (22), 70–80.
Banco Mundial. (2013). Informe sobre el desarrollo mundial 2013. Panorama general:
Empleo.
Barcenas, R., Garcia, D., & Sanchez, V. (2009). Factores determinantes del éxito
competitivo en la Pyme: Estudio Empírico en México. Revista Venezolana de
Gerencia, 14(46). Retrieved from
http://www.scielo.org.ve/scielo.php?script=sci_arttext&pid=S1315-
99842009000200002&lng=es&nrm=iso
Bathallath, S., Smedberg, Å., & Kjellin, H. (2016). Project Interdependency

Management in IT/IS Project Portfolios: From a Systems Perspective. Procedia
Computer Science, 100, 928–934. https://doi.org/10.1016/j.procs.2016.09.250
Bathallath, S., Smedberg, Å., & Kjellin, H. (2019). The viable system model for
diagnosing and handling IT-project interdependencies in large portfolios.
International Journal of Information Technology Project Management, 10(1), 72–
87. https://doi.org/10.4018/IJITPM.2019010105
110
Baxter, P., & Jack, S. (2008). Qualitative Case Study Methodology : Study Design and
Implementation for Novice Researchers Qualitative Case Study Methodology :
Study Design and Implementation. 13(4), 544–559.
Beringer, C., Jonas, D., & Gemunden, H. (2017). Establishing Project Portfolio
Management - An exploratory Analysis of the influence of internal stakeholders’
interactions. Project Management Journal, 43(6), 16–32.
https://doi.org/10.1002/pmj.21307
Beringer, C., Jonas, D., & Kock, A. (2013). Behavior of internal stakeholders in project
portfolio management and its impact on success. International Journal of Project
Management, 31(6), 830–846. https://doi.org/10.1016/j.ijproman.2012.11.006
Biedenbach, T., & Müller, R. (2012). Absorptive, innovative and adaptive capabilities
and their impact on project and project portfolio performance. International Journal
of Project Management, 30(5), 621–635.
Bode-Greuel, K. M., & Nickisch, K. J. (2008). Value-driven project and portfolio

management in the pharmaceutical industry: Drug discovery versus drug
development – Commonalities and differences in portfolio management practice.
Journal of Commercial Biotechnology, 14(4), 307–325.
https://doi.org/10.1057/jcb.2008.6
Bonomi, J., & Ledur, L. (2012). Toward a Subjective Measurement Model for Firm
Performance. Brazilian Administration Review, 9(6), 95–117.
Brook, J. W., & Pagnanelli, F. (2014). Integrating sustainability into innovation project
portfolio management – A strategic perspective. Journal of Engineering and
Technology Management, 34, 46–62.
https://doi.org/10.1016/j.jengtecman.2013.11.004
Bruno De Souza, P., Carneiro, J., Puc-Rio, Ω, & Bandeira-De-Mello, R. (2015). Inquiry
into the Conceptual Dimensions of Project Portfolio Management. BBR Special
Issues Vitória-ES, 118–148. https://doi.org/10.1073/pnas.0703993104
Buys, A. J., & Stander, M. J. (2010). Linking projects to business strategy through
project portfolio management. South African Journal of Industrial Engineering,
21(1), 59–68.
CÃ¡Ã±ez, L., & Garfias, M. (2006). Portfolio management at the Mexican Petroleum
Institute. Research Technology Management, 49(4), 46–55. Retrieved from
http://www.scopus.com/inward/record.url?eid=2-s2.0-
33745920508&partnerID=40&md5=5ab88d123fcb078d081428bd5ce462e1
Cambridge Dictionary. (n.d.). Retrieved from https://dictionary.cambridge.org/
Cassar, G. (2014). Industry and startup experience on entrepreneur forecast

performance in new firms. Journal of Business Venturing, 29(1), 137–151.
https://doi.org/10.1016/j.jbusvent.2012.10.002
111
Chenhall, R. H., Hall, M., & Smith, D. (2010). The role of management control systems
in NGOs. Chartered Institute of Management Accountants, 6.
Chile, C. N. de. LEY NÚM. 20.41 NORMAS ESPECIALES PARA LAS EMPRESAS DE
MENOR TAMAÑO. , (2014).
Christiansen, J. K., & Varnes, C. (2008). From models to practice: decision making at
portfolio meetings. International Journal of Quality & Reliability Management,
25(1), 87–101. https://doi.org/10.1108/02656710810843603
Combs, J. G., Crook, T. R., & Shook, C. L. (2005). The Dimensionality of

Organizational Performance and its Implications for Strategic Management
Research. In Research Methodology in Strategy and Management: Vol. 2.
Research Methodology in Strategy and Management (pp. 259–286).
https://doi.org/doi:10.1016/S1479-8387(05)02011-4
Comision Nacional de Valores, A. Clasificación PyME CNV - Resolución General

582/2010. , (2010).
Cooper, R. G., Edgett, S. J., & Kleinschmidt, E. J. (2016). Benchmarking Best NPD
Practices-II. https://doi.org/10.1080/08956308.2004.11671630
Costa, H. R., Barros, M. de O., & Travassos, G. H. (2007). Evaluating software project
portfolio risks. Journal of Systems and Software, 80(1), 16–31.
https://doi.org/10.1016/j.jss.2006.03.038
Creswell, J. W., & Clark, V. L. P. (2007). Designing and conducting mixed methods
research.
Daim, T. U., Oliver, T., & Iskin, I. (2013). Research and development (R&D) portfolio
management in the electric utility sector. Benchmarking: An International Journal,
Daniel, E. M., Ward, J. M., & Franken, A. (2014). A dynamic capabilities perspective of
IS project portfolio management. The Journal of Strategic Information Systems,
23(2), 95–111. https://doi.org/10.1016/j.jsis.2014.03.001
Dooley, L., Lupton, G., & O’Sullivan, D. (2005). Multiple project management: a modern
competitive necessity. Journal of Manufacturing Technology Management, 16(5),
466–482. https://doi.org/10.1108/17410380510600464
Drake, J. R., & Byrd, T. A. (2006). Risk in Information Technology Project Portfolio
Management. Journal of Information Technology Theory and Application, 8(3), 1–
11. Retrieved from http://aisel.aisnet.org/jitta/vol8/iss3/3
Eik-Andresen, P., Johansen, A., Landmark, A. D., & Sørensen, A. Ø. (2016).

Controlling a Multibillion Project Portfolio - Milestones as Key Performance
Indicator for Project Portfolio Management. Procedia - Social and Behavioral
Sciences, 226(October 2015), 294–301.
https://doi.org/10.1016/j.sbspro.2016.06.191
112
García-Melón, M., Poveda-Bautista, R., & Del Valle M., J. L. (2015a). Using the
strategic relative alignment index for the selection of portfolio projects application
to a public Venezuelan Power Corporation. International Journal of Production
Economics. https://doi.org/10.1016/j.ijpe.2015.08.023
García-Melón, M., Poveda-Bautista, R., & Del Valle M., J. L. (2015b). Using the
strategic relative alignment index for the selection of portfolio projects application
to a public Venezuelan Power Corporation. International Journal of Production
Economics, 170, 54–66. https://doi.org/10.1016/j.ijpe.2015.08.023
Ghasemi, F., Sari, M. H. M., Yousefi, V., Falsafi, R., & Tamošaitiene, J. (2018). Project
portfolio risk identification and analysis, considering project risk interactions and
using Bayesian Networks. Sustainability (Switzerland), 10(5).
https://doi.org/10.3390/su10051609
Gutiérrez, E., & Magnusson, M. (2014). Dealing with legitimacy: A key challenge for
Project Portfolio Management decision makers. International Journal of Project
Hadjinicolaou, N., & Dumrak, J. (2017). Investigating Association of Benefits and

Barriers in Project Portfolio Management to Project Success. Procedia
Engineering, 182, 274–281. https://doi.org/10.1016/j.proeng.2017.03.191
Hans, E. W., Herroelen, W., Leus, R., & Wullink, G. (2007). A hierarchical approach to
multi-project planning under uncertainty. Omega, 35(5), 563–577.
https://doi.org/10.1016/j.omega.2005.10.004
Heising, W. (2012). The integration of ideation and project portfolio management - A

key factor for sustainable success. International Journal of Project Management,
30(5), 582–595. https://doi.org/10.1016/j.ijproman.2012.01.014
Heising, W. (2012). The integration of ideation and project portfolio management — A

key factor for sustainable success. International Journal of Project Management,
30(5), 582–595. https://doi.org/10.1016/j.ijproman.2012.01.014
Hermano, V., & Martín-Cruz, N. (2016). The role of top management involvement in
firms performing projects: A dynamic capabilities approach. Journal of Business
Research, 69(9), 3447–3458. https://doi.org/10.1016/j.jbusres.2016.01.041
Hoffmann, D., Müller, T., & Ahlemann, F. (2017). Balancing alignment adaptivity and
effectiveness - design princples for for sustainable IT project management. Ecis,
Spring, 1503–1520.
Hyvari, I. (2006). Success of Projects in Different Organizational Conditions. Project

Management Journal, 37(4), 31–42. https://doi.org/10.1055/s-0029-1225353
Hyväri, I. (2016). Roles of Top Management and Organizational Project Management

in the Effective Company Strategy Implementation. Procedia - Social and
Behavioral Sciences, 226(October 2015), 108–115.
113
Ichsan, M., & Sadeli, J. (2020). Fostering Project Delivery Capabilities in Indonesian
Commercial. PERTANIKA JOURNAL OF SOCIAL SCIENCE AND HUMANITIES,
28(2), 827–846.
Ilyin, I. V., & Teslya, A. B. (2016). Strategic business areas as a mechanism for
coordinating stakeholder interests when managing a company’s project portfolio.
St. Petersburg State Polytechnical University Journal. Economics, 240(2), 60–68.
https://doi.org/10.5862/JE.240.6
Inger Bergman, Sven Gunnarson, C. R. (2013). Decoupling and standardization in the

projectification of a company. International Journal of Managing Projects in
Business, 6(1), 106–128. https://doi.org/10.1108/17538371311291053
ISO. (2011). ISO/IEC 29110-4-1:2011 Preview Software engineering -- Lifecycle

profiles for Very Small Entities (VSEs) -- Part 4-1: Profile specifications: Generic
profile group.
ISO. (2015). ISO 21504- Project, programme and portfolio management -- Guidance
on portfolio management.
Jeffcoate, J., Chappell, C., & Feindt, S. (2002). Best practice in SME adoption of e‐
commerce. Benchmarking: An International Journal, 9(2), 122–132.
Jerbrant, A. (2014). A MATURATION MODEL FOR PROJECT-BASED

ORGANISATIONS – WITH UNCERTAINTY MANAGEMENT AS AN EVER-
PRESENT MULTI-PROJECT MANAGEMENT FOCUS. SAJEMS Special Issue,
17, 33–51.
Jerbrant, A., & Gustavsson, T. K. (2013). Managing project portfolios: balancing

flexibility and structure by improvising. International Journal of Managing Projects
in Business, 6(2), 365–378. https://doi.org/10.1108/17538371311291071
Jonas, D. (2010). Empowering project portfolio managers: How management

involvement impacts project portfolio management performance. International
Journal of Project Management, 28(8), 818–831.
Kaiser, M. G., El Arbi, F., & Ahlemann, F. (2015). Successful project portfolio
management beyond project selection techniques: Understanding the role of
structural alignment. International Journal of Project Management, 33(1), 126–
139. https://doi.org/10.1016/j.ijproman.2014.03.002
Keegan, D. P., Eiler, R. G., & Jones, C. R. (1989). Are Your Performance Measures
Obsolete? Management Accounting, 70(12), 45–50.
Khalili-Damghani, K., & Tavana, M. (2014). A comprehensive framework for

sustainable project portfolio selection based on structural equation modeling.
Project Management Journal, 45(2), 83–97. https://doi.org/10.1002/pmj.21404
Killen, C. P., & Hunt, R. A. (2010). Dynamic capability through project portfolio
management in service and manufacturing industries. International Journal of
114
Managing Projects in Business2, 3(1), 157–169.
Killen, C. P., Hunt, R. a., & Kleinschmidt, E. J. (2008). Learning investments and
organizational capabilities: Case studies on the development of project portfolio
management capabilities. International Journal of Managing Projects in Business,
Killen, C. P., Hunt, R. a., Kleinschmidt, E. J., & Hunt, R. a. (2008). Project portfolio
management for product innovation. International Journal of Quality & Reliability
Management, 25(1), 24–38. https://doi.org/10.1108/02656710810843559
Killen, C. P., Jugdev, K., Drouin, N., & Petit, Y. (2012). Advancing project and portfolio
management research: Applying strategic management theories. JPMA, 30, 525–
Killen, C. P., & Kjaer, C. (2012). Understanding project interdependencies: The role of
visual representation, culture and process. International Journal of Project
Kitchenham, B. (2004). Procedures for performing systematic reviews. Keele, UK,

Keele University, 33(TR/SE-0401), 28. https://doi.org/10.1.1.122.3308
Kock, A., Heising, W., & Gemünden, H. G. (2015). How ideation portfolio management
influences front-end success. Journal of Product Innovation Management, 32(4),
539–555. https://doi.org/10.1111/jpim.12217
Kock, A., Heising, W., & Gemünden, H. G. (2016). A Contingency Approach on the
Impact of Front-End Success on Project Portfolio Success. Project Management
Journal, 47(2), 115–129. https://doi.org/10.1002/pmj.21575
Kopmann, J., Kock, A., Killen, C. P., & Gemünden, H. G. (. (2017). The role of project
portfolio management in fostering both deliberate and emergent strategy.
International Journal of Project Managemen.
Kornfeld, B. J., & Kara, S. (2011). Project portfolio selection in continuous

improvement. International Journal of Operations & Production Management,
Kornfeld, B. J., & Kara, S. (2013). A Framework for Developing Portfolios of

Improvements Projects in Manufacturing. Procedia CIRP, 7, 377–382.
https://doi.org/10.1016/j.procir.2013.06.002
Kraus, S., Harms, R., & Schwarz, E. J. (2006). Strategic planning in smaller enterprises
– new empirical findings. Management Research News, 29(6), 334–344.
Lerch, M., & Spieth, P. (2013). Innovation project portfolio management: A qualitative
analysis. IEEE Transactions on Engineering Management, 60(1), 18–29.
https://doi.org/10.1109/TEM.2012.2201723
115
Li, Y., & Chi, T. (2013). Venture capitalists’ decision to withdraw: The role of portfolio
configuration from a real options lens. Strategic Management Journal, 34(11),
1351–1366. https://doi.org/10.1002/smj.2073
Ligetvári Student, É. (2013). Project Portfolio Management: A Pilot Survey on the

Importance of “Project Building Stones” in Corporate Life. Club of Economics in
Miskolc’ TMP, 9(1), 57–62.
Loomis, W. (1988). The real drivers of strategy. Strategy & Leadership, 16(3), 4–40.
https://doi.org/10.1108/eb054217
Martinsuo, M. (2013). Project portfolio management in practice and in context. JPMA,

31, 794–803. https://doi.org/10.1016/j.ijproman.2012.10.013
MERCOSUR. POLITICAS DE APOYO A LAS MICROPEQUEÑAS Y MEDIANAS

EMPRESAS DEL MERCOSUR. , (1992).
Meskendahl, S. (2010). The influence of business strategy on project portfolio

management and its success — A conceptual framework. JPMA, 28, 807–817.
Micán, C., Fernandes, G., Araújo, M., & Ares, E. (2019). Operational risk categorization
in project-based organizations: A theoretical perspective from a project portfolio
risk lens. Procedia Manufacturing, 41, 771–778.
https://doi.org/10.1016/j.promfg.2019.09.069
Moher, D., Liberati, A., Tetzlaff, J., & Altman, D. G. (2009). Preferred reporting items for
systematic reviews and meta-analyses: the PRISMA statement. Annals of Internal
Medicine, 151(4), 264–269.
Morgan, D. (2013). Integrating qualitative and quantitative methods: A pragmatic

approach. Sage publications.
MTPE. (2016). Menor informalidad generará más empleo digno y mayor productividad.
Ngqulunga, B., & Walwyn, D. (2018). Efficient project portfolio management: Avoiding
value destruction by promoting social returns on RD. PICMET 2018 - Portland
International Conference on Management of Engineering and Technology:
Managing Technological Entrepreneurship: The Engine for Economic Growth,
Proceedings. https://doi.org/10.23919/PICMET.2018.8481878
NYANDONGO, K. M., & MSHWESHWE, A. (2020). INFORMATION TECHNOLOGY (

IT ) PROJECT PORTFOLIO MANAGEMENT PRACTICES IN SOUTH AFRICA.
26th International Association for Management of Technology Conference; IAMOT
2017, 1–15.
O’Regan, N., & Ghobadian, A. (2002). Effective strategic planning in small and medium
sized firms. Management Decision, 40(7), 663–671.
116
Ochoa, V. (2019). Mercado de la informática en Perú crecerá 9.7% este año. Gestión.
Retrieved from https://gestion.pe/economia/empresas/mercado-informatica-peru-
crecera-9-7-ano-260535-noticia/
Organización Internacional para el Trabajo. (2015). Panorama TEMÁTICO Laboral

Pequeñas empresas, grandes brechas, Empleo y condiciones de trabajo en las
MYPE de América Latina y el Caribe.
Pajares, J., & López, A. (2014). New Methodological Approaches to Project Portfolio
Management: The Role of Interactions within Projects and Portfolios. Procedia -
Social and Behavioral Sciences, 119, 645–652.
Patanakul, P. (2015). Key attributes of effectiveness in managing project portfolio.

International Journal of Project Management, 33(5), 1084–1097.
Patanakul, P., & Milosevic, D. (2009). The effectiveness in managing a group of

multiple projects: Factors of influence and measurement criteria. International
Journal of Project Management, 27(3), 216–233.
Paulson, A. S., Connor, G. C. O., & Robeson, D. (2000). EVALUATING RADICAL

Large firms that successfully radical innovations. (c), 17–29.
Pearce, J. a., & David, F. (1987). Corporate Mission Statements: The Bottom Line.
Academy of Management Perspectives, 1(2), 109–115.
https://doi.org/10.5465/ame.1987.4275821
Pedersen, K. (2016). It project selection: Politics, experience and good friends. The
Electronic Journal Information Systems Evaluation, 19(1), 55–70. Retrieved from
www.ejise.com
Pedersen, K., & Nielsen, J. A. (2011). Managing Uncertainty And Conflict In It Project
Portfolio Management. Journal of Information Technology Case and Application
Research, 13(4), 51–83. https://doi.org/10.1080/15228053.2011.10856217
Petit, Y. (2012). Project portfolios in dynamic environments: Organizing for uncertainty.

JPMA, 30, 539–553. https://doi.org/10.1016/j.ijproman.2011.11.007
Pratuckchai, W. (2012). the Study of Management Control Systems in State Owned

Enterprises : a Proposed Conceptual Framework. 5, 83–116.
Project Management Institute. (2013). Standard For Portfolio Management Third

Edition. Project Management Institute.
PROMPEX, & APESOFT. (2003). Situación de la Industria Nacional de Software en el

Perú.
Pucko, D. (2008). A holistic strategy implementation model based on the experiences

of slocenian companies. Economic and Business Review., 10(4).
117
Ranf, D. E. (2011). PROJECT MANAGEMENT – THEN AND NOW. Annales
Universitatis Apulensis Series Oeconomica, 13(2), 596–603.
Ravelomanantsoa, M. S., Ducq, Y., & Vallespir, B. (2019). A state of the art and
comparison of approaches for performance measurement systems definition and
design. International Journal of Production Research, 57(15-16), 5026–5046.
https://doi.org/10.1080/00207543.2018.1506178
Reyck, B. De, Grushka-Cockayne, Y., Lockett, M., Calderini, S. R., Moura, M., &
Sloper, A. (2005). The impact of project portfolio management on information
technology projects. International Journal of Project Management, 23(7), 524–537.
Rivera-ruiz, I., & Ferrer-moreno, E. (2015). The Relationship Between Strategic

Leadership , Human IT Infrastructure , Project Management , Project Success ,
and Firm Performance. International Journal of Information, Business and
Management, 7(2), 77–85.
Roach, D. C. (2011). The impact of product management on SME performance:

Evidence from Canadian firms. Journal of Small Business and Enterprise
Development, 18(4), 695–714. https://doi.org/10.1108/14626001111179758
Rosselet, U., Jolliet, Y., & Wentland, M. (2009). Knowledge management for IT project
portfolio. Proceedings of the European Conference on Knowledge Management,
ECKM, 2, 695–700.
Rowe, W. G., & Morrow, J. L. (1999). A Note on the Dimensionality of the Firm
Financial Performance Construct Using Accounting, Market, and Subjective
Measures. Canadian Journal of Administrative Sciences / Revue Canadienne Des
Sciences de l’Administration, 16(1), 58–71. https://doi.org/10.1111/j.1936-
4490.1999.tb00188.x
Rungi, M. (2010). Success rate and resource consumption from project

interdependencies. Industrial Management and Data Systems, 110(1), 93–110.
Rungi, M. (2014). The impact of capabilities on performance. Industrial Management &

Data Systems, 114(2), 241–257. https://doi.org/10.1108/IMDS-04-2013-0202
Saaevdra, M. (2016). INEI: Los impresionantes números del sector informal peruano.
El Comercio.
Sanchez, H., Robert, B., Bourgault, M., & Pellerin, R. (2009). Risk management
applied to projects, programs, and portfolios. International Journal of Managing
Projects in Business, 2(1), 14–35. https://doi.org/10.1108/17538370910930491
Sanchez, H., Robert, B., & Pellerin, R. (2008). A Project Portfolio Risk-Opportunity
Identification Framework . Project Management Journal, 39(3), 97–109.
https://doi.org/10.1002/pmj
Serveant, K. (2017). Can better Working Conditions Improve the performance of

SMEs?
118
Sheykh, M. J., Azizi, M., & Sobhiyah, M. H. (2013). How can the Trade off between
Corporate Business Strategy and Project Risk be Optimized? Procedia - Social
and Behavioral Sciences, 74, 134–143.
Sicotte, H., Drouin, N., & Delerue, H. (2015). Innovation portfolio management as a
subset of dynamic capabilities: Measurement and impact on innovative
performance. Project Management Journal, 45(6), 58–72.
Smith, T. M., & Reece, J. S. (1999). The relationship of strategy, fit, productivity, and
business performance in a services setting. Journal of Operations Management,
17(2), 145–161. https://doi.org/https://doi.org/10.1016/S0272-6963(98)00037-0
Spieth, P., & Lerch, M. (2014). Augmenting innovation project portfolio management
performance: The mediating effect of management perception and satisfaction. R
and D Management, 44(5), 498–515. https://doi.org/10.1111/radm.12092
Srivannaboon, S., & Ph, D. (2006). Linking Project Management with Business
Strategy. PMI Gloabl Congress, 1–11.
Staniewski, M. W. (2016). The contribution of business experience and knowledge to

successful entrepreneurship. Journal of Business Research, 69(11), 5147–5152.
https://doi.org/10.1016/j.jbusres.2016.04.095
Sterling, J. (2003). Translating strategy into effective implementation: dispelling the

myths and highlighting what works. Strategy & Leadership, 31(3), 27–34.
Stettina, C. J., & Hörz, J. (2015). Agile portfolio management: An empirical perspective
on the practice in use. International Journal of Project Management, 33(1), 140–
Stonehouse, G., & Pemberton, J. (2002). Strategic planning in SMEs – some empirical
findings. Management Decision, 40(9), 853–861.
Stuart, R. W., & Abetti, P. a. (1990). Impact of entrepreneurial and management

experience on early performance. Journal of Business Venturing, 5(3), 151–162.
https://doi.org/10.1016/0883-9026(90)90029-S
Swee, T., & Kormas, S. (2009). Firm performance measurement in fast growth small-
to-medium enterprises. ICSB World Conference Proceedings.
Sweetman, R., & Conboy, K. (2018). Portfolios of Agile Projects: A Complex Adaptive
Systems’ Agent Perspective. Project Management Journal, 49(6), 18–38.
Tang, B.-J., Zhou, H.-L., & Cao, H. (2017). Selection of overseas oil and gas projects
under low oil price. Journal of Petroleum Science and Engineering, 156, 160–166.
https://doi.org/10.1016/j.petrol.2017.05.022
119
Tangen, S. (2003). An overview of frequently used performance measures. Work
Study, 52(7), 347–354. https://doi.org/10.1108/00438020310502651
Teller, J. (2013). Portfolio risk management and its contribution to project portfolio
success: An investigation of organization, process, and culture. Project
Management Journal, 44(2), 36–51. https://doi.org/10.1002/pmj.21327
Teller, J., & Kock, A. (2013). An empirical investigation on how portfolio risk
management influences project portfolio success. International Journal of Project
Teller, J., Kock, A., & Gemünden, H. G. (2014). Risk management in project portfolios
is more than managing project risks: A contingency perspective on risk
management. Project Management Journal, 45(4), 67–80.
Teller, J., Unger, B. N., Kock, A., & Gemünden, H. G. (2012). Formalization of project
portfolio management: The moderating role of project portfolio complexity.
Thiry, M., & Deguire, M. (2007). Recent developments in project-based organisations.

Unger, B. N., Gemünden, H. G., & Aubry, M. (2012). The three roles of a project
portfolio management office: Their impact on portfolio management execution and
success. International Journal of Project Management, 30(5), 608–620.
Unger, B. N., Kock, A., Gemünden, H. G., & Jonas, D. (2012). Enforcing strategic fit of
project portfolios by project termination: An empirical study on senior management
involvement. JPMA, 30, 675–685. https://doi.org/10.1016/j.ijproman.2011.12.002
Unger, B. N., Rank, J., & Gemünden, H. G. (2015). Corporate innovation culture and
dimensions of project portfolio success: The moderating role of national culture.
Project Management Journal, 45(6), 38–57. https://doi.org/10.1002/pmj.21458
Uniion, E. (2003). Commission Recommendation of 6 May 2003 concerning the

definition of micro, small and medium-sized enterprises. EU Official Journal, 124,
36–41. Retrieved from http://eur-lex.europa.eu/legal-
content/EN/TXT/?uri=CELEX:32003H0361
Urhahn, C., & Spieth, P. (2014). Governing the portfolio management process for
product innovation - A quantitative analysis on the relationship between portfolio
management governance, portfolio innovativeness, and firm performance. IEEE
Transactions on Engineering Management, 61(3), 522–533.
https://doi.org/10.1109/TEM.2014.2327254
Vacík, E., Špaček, M., Fotr, J., & Kracík, L. (2018). Project portfolio optimization as a
part of strategy implementation process in small and medium-sized enterprises: A
methodology of the selection of projects with the aim to balance strategy, risk and
120
performance | Optimalizace projektových portfolií jako. E a M: Ekonomie a
Management, 21(3), 107–123. https://doi.org/10.15240/tul/001/2018-3-007
Vähäniitty, J., Rautiainen, K., & Lassenius, C. (2010). Small software organizations
need explicit project portfolio management. IBM Journal of Research and
Development, 54(2). https://doi.org/10.1147/JRD.2009.2038747
Vänttinen, M., & Pyhältö, K. (2009). Strategy process as an innovative learning

environment. Management Decision, 47(5), 778–791.
Vargo, J., & Seville, E. (2011). Crisis strategic planning for SMEs: Finding the silver
lining. International Journal of Production Research, 49(18), 5619–5635.
Venkatraman, A. N., & Ramanujam, V. (1986). Measurement of Business Performance

in Strategy Research : A Comparison of Approaches Published by : Academy of
Management Stable URL : http://www.jstor.org/stable/258398 Linked references
are available on JSTOR for this article : Measurement of Business. 11(4), 801–
814.
Voss, M. (2012). Impact of customer integration on project portfolio management and

its success—Developing a conceptual framework. International Journal of Project
Voss, M., & Kock, A. (2013). Impact of relationship value on project portfolio success
— Investigating the moderating effects of portfolio characteristics and external
turbulence. International Journal of Project Management, 31(6), 847–861.
Wall, T., & Wood, S. J. (2004). on the Validity of Subjective Measures of. Personnel
Psycology, 57(1), 95.
Weissenberger-Eibl Teufel, M. a. (2011). Organizational politics in new product

development project selection: A review of the current literature. European Journal
of Innovation Management, 14(1), 51–73.
Wikström, K., Artto, K., Kujala, J., & Söderlund, J. (2010). Business models in project
business. International Journal of Project Management, 28(8), 832–841.
Wu, Y., Li, J., Wang, J., & Huang, Y. (2012). Project portfolio management applied to
building energy projects management system. Renewable and Sustainable
Energy Reviews, 16(1), 718–724. https://doi.org/10.1016/j.rser.2011.08.037
Yang, Y., & Xu, D.-L. (2017). A methodology for assessing the effect of portfolio
management on NPD performance based on Bayesian network scenarios. Expert
Systems, 34(2). https://doi.org/10.1111/exsy.12186
121
Young, M., Owen, J., & Connor, J. (2011). Whole of enterprise portfolio management.
International Journal of Managing Projects in Business, 4(3), 412–435.
Young, R., Young, M., Jordan, E., & O’Connor, P. (2012). Is strategy being
implemented through projects? Contrary evidence from a leader in New Public
Management. International Journal of Project Management, 30(8), 887–900.
Zaman, U., Nadeem, R. D., & Nawaz, S. (2020). Cross-country evidence on project
portfolio success in the Asia-Pacific region: Role of CEO transformational
leadership, portfolio governance and strategic innovation orientation. Cogent
Business and Management, 7(1), 1–26.
122
Anexo 1 – Cuestionario Fase de Exploración
Datos Generales
1. Nombre
2. Empresa
3. Cargo
4. Correo Electrónico
5. Está familiarizado con métodos de gestión de proyectos

SI
NO
6. Está familiarizado con métodos de gestión de portafolio
SI
NO
Contexto de la Empresa
1. El principal rubro de mi empresa es:
Desarrollo de Software a medida

Outsourcing
Desarrollo de Software para comercialización
Nota: En caso responda que su principal rubro es el outsourcing se debe terminar

el cuestionario, agradeciendo su participación, pero indicando que el tipo de
empresa no califica dentro de los criterios de inclusión del estudio
2. En mi empresa laboran actualmente en promedio
1-5 personas
5- 15 personas
15 – 25 personas
123
Más de 25 personas
Nota: En caso responda que el tamaño es mayor a 25 personas se debe terminar

el cuestionario, agradeciendo su participación, pero indicando que el tipo de
3. En mi empresa se suelen manejar en paralelo:
Un solo proyecto
De 2 a 5 proyectos
Más de 5 proyectos
Nota: En caso responda que solo se maneja un proyecto se debe terminar el

cuestionario, agradeciendo su participación, pero indicando que el tipo de
Prácticas de Gestión
Por favor responda cada una de las siguientes preguntas en una escala del 1 al 7
considerando que 1 es completamente en desacuerdo y 7 completamente de acuerdo
4. La empresa controla el alcance de los proyectos realizados

5. La empresa control el cronograma de los proyectos realizados
6. La empresa controla el presupuesto de los proyectos realizados
7. La empresa aplica prácticas de aseguramiento o control de calidad en los proyectos
8. La empresa gestiona riesgos en los proyectos realizados
9. En general los proyectos terminan a tiempo
10. En general los clientes reportan pocos defectos tras la entrega del proyecto
Para las siguientes preguntas entiéndase portafolio como “Conjunto de Proyectos”

11. La empresa lleva un registro del portafolio de proyectos en ejecución
12. El portafolio de proyectos que maneja la empresa incluye proyectos internos
13. El portafolio de proyecto incluye proyectos de innovación
14. Al momento de decidir realizar un proyecto se toma en cuenta criterios definidos
15. Los proyectos realizados se alinean con los objetivos de empresa
16. Al momento de decidir realizar un proyecto se analizan los recursos requeridos
17. Al momento de decidir realizar un proyecto se consideran los riesgos que genera.
124
18. La empresa periódicamente revisa el estado del portafolio de proyectos en ejecución
19. La empresa define distintas prioridades para los proyectos que forman parte del
portafolio
20. La empresa monitorea el desempeño del portafolio
21. Existe una buena comunicación entre la alta dirección y los responsables del portafolio
de proyectos.
22. Existe una buena comunicación entre los responsables del portafolio de proyectos y los
responsables de cada proyecto.
Rendimiento de la empresa
considerando que 1 es un desempeño muy malo y 7 un desempeño sobresaliente
23. Durante el año pasado, nuestro crecimiento de ventas fue en comparación

con nuestros competidores
24. Durante el año pasado, nuestro crecimiento de ganancias fue en
comparación con nuestros competidores
25. Durante el año pasado, nuestro crecimiento de empleo fue en comparación
con nuestros competidores
considerando que 1 es completamente en desacuerdo y 7 completamente de acuerdo
26. Durante el año pasado, el desempeño general del negocio cumplió con las expectativas.
27. Durante el año pasado, el rendimiento general del negocio superó al de nuestros
principales competidores.
28. Durante el año pasado, la alta gerencia estuvo muy satisfecha con el desempeño general
del negocio.
125
Anexo 2 – Cuestionario Fase Cualitativa
I. Información general de la entrevista
1. Empresa 4. Lugar de la
entrevista
2. Nombre del 5. Fecha de la

entrevistado entrevista
3. Cargo en la 6. Nombre del

empresa entrevistador
II. Información general del modelo de negocio
II.1 ¿Qué tipo de proyectos realiza la empresa? ¿Cuántos proyectos puede manejar al
mismo tiempo?
II.2 ¿Cuáles son los objetivos de negocio de la empresa?, ¿Quiénes en la empresa conocen
estos objetivos? ¿Cómo se les comunica?
II.3 ¿Cómo evalúas si se han cumplido los objetivos de la empresa?
II.4 ¿Existen proyectos internos? ¿Un ejemplo?
III. Selección de proyectos
III.1 ¿Cómo consigue proyectos la empresa? ¿Quiénes participan en este proceso?
III.2 ¿En el caso de proyectos internos de dónde surgen las ideas?"
III.3 ¿Cómo se decide qué proyecto ejecutar? ¿Quiénes participan en este proceso?
III.4 ¿Qué aspectos toman en cuenta para tomar la decisión? ¿Esto queda documentado
en algún sitio? ¿Dónde?
III.5 ¿Hay proyectos que deciden no hacer? ¿Por qué?
126
III.6 ¿La empresa ha realizado proyectos de innovación en los últimos años? ¿Qué tipo
de proyectos? ¿Qué porcentaje de recursos se asocia esto? " ¿Qué tan importante es la
innovación para la empresa?
III.7 ¿Al momento de decidir iniciar un proyecto, se toma en cuenta los riesgos que
implica? ¿Qué tipo de riesgos se considera?
III.8 ¿Dirías que todos los proyectos se alinean con el objetivo de la empresa? ¿Cuáles
no? ¿Por qué?
III.9 ¿Qué conocimientos y experiencia tienen las personas responsables de la selección

de proyectos en la empresa?
IV. Gestión del portafolio
IV.1 ¿Cómo gestionan sus proyectos? ¿Se basan en algún estándar? ¿Hace cuánto tiempo
lo hacen de esta forma? ¿Cuánto tiempo suelen durar sus proyectos?
IV.2 ¿Cómo gestionan el alcance? ¿Cómo gestionan el cronograma? ¿Cómo gestionan el

presupuesto? ¿Qué prácticas de aseguramiento o control de calidad aplican? ¿Cómo de
gestionan los riesgos durante la ejecución del proyecto?
IV.3 ¿Qué actividades de gestión considera que generan mayor valor al negocio?
IV.4 ¿Cómo sabe la empresa el estado de sus proyectos en curso?
IV.5 ¿Los empleados saben cómo su proyecto se alinea con los objetivos? ¿Cómo logran
esto?
IV.6 ¿Qué conocimientos y experiencia tienen los responsables de la gestión de proyectos

en la empresa?
V. Rendimiento de la empresa
V.1 ¿Cómo defines éxito en tus proyectos?
V.2 ¿Qué porcentaje de proyectos termina con éxito? ¿Qué porcentaje de proyectos
termina retrasado? ¿Cuánto se atrasan?
127
V.3 ¿Por qué un proyecto podría ser cancelado antes de terminar? ¿Qué porcentaje de
proyectos son cancelados antes de terminar?
V.4 ¿Cuál es la tasa de errores reportados después de la entrega?
V.5 ¿En la encuesta se indica …? ¿Puede darnos un poco más de detalle al respecto?
V.6 ¿Qué crees que necesitas para crecer?
128
Anexo 3 – Consentimiento Informado (Encuesta)
La presente investigación es conducida por el Magister Luis Alberto Flores García de la Pontificia
Universidad Católica del Perú, como parte de su trabajo conducente al Grado de Doctor en gestión
Estratégica y bajo el asesoramiento del Dr. José Antonio Pow-Sang.
La meta de este estudio es determinar cómo la aplicación de prácticas de gestión de portafolio (selección
y gestión) de proyectos impacta el desempeño de pequeñas organizaciones desarrolladoras de software
en Perú.
Si usted accede a participar en este estudio, se le pedirá responder una encuesta, lo que le tomará 15
minutos de su tiempo.
Su participación será voluntaria. La información de sus datos personales será tratada de forma
confidencial y sólo podrá ser utilizada para contactarlo en caso sea invitado a participar en la segunda fase
del proyecto (fase de entrevistas) o para enviarle un resumen de resultados de la investigación en caso lo
desee. Igualmente, sus respuestas individuales serán confidenciales,
Si tuviera alguna duda con relación al desarrollo del proyecto, usted es libre de formular las preguntas
que considere pertinentes al correo [email protected]. Además, puede finalizar su participación en
cualquier momento del estudio sin que esto represente algún perjuicio para usted. Si se sintiera incómoda
o incómodo, frente a alguna de las preguntas, puede ponerlo en conocimiento de la persona a cargo de
la investigación y abstenerse de responder.
Así mismo para absolver consultas sobre temas de ética de la investigación puede comunicarse con el
Comité de Ética de la Investigación (CEI) al correo electrónico: [email protected]
Muchas gracias por su participación.
¿Desea participar en la encuesta?
0 SI
0 NO
129
Anexo 4 – Consentimiento Informado (Entrevista)
PROTOCOLO DE CONSENTIMIENTO INFORMADO PARA PARTICIPANTES
El propósito de este protocolo es brindar a los y a las participantes en esta investigación, una explicación
clara de la naturaleza de la misma, así como del rol que tienen en ella.
La presente investigación es conducida por el Magister Luis Alberto Flores García de la Pontificia
Universidad Católica del Perú, como parte de su trabajo conducente al Grado de Doctor en gestión
Estratégica y bajo el asesoramiento del Dr. José Antonio Pow-Sang.
La meta de este estudio es determinar cómo la aplicación de prácticas de gestión de portafolio de

proyectos impacta el desempeño de pequeñas organizaciones desarrolladoras de software en Perú.
Si usted accede a participar en este estudio, se le realizará una entrevista, lo que le tomará 15 minutos de
su tiempo. La conversación será grabada, así el investigador o investigadora podrá transcribir las ideas
que usted haya expresado.
Su participación será voluntaria. La información de sus datos personales será tratada de forma
confidencial y no se podrá utilizar para ningún otro propósito que no esté contemplado en esta
investigación. Igualmente, sus respuestas individuales serán confidenciales,
Si tuviera alguna duda con relación al desarrollo del proyecto, usted es libre de formular las preguntas
que considere pertinentes. Además, puede finalizar su participación en cualquier momento del estudio
sin que esto represente algún perjuicio para usted. Si se sintiera incómoda o incómodo, frente a alguna
de las preguntas, puede ponerlo en conocimiento de la persona a cargo de la investigación y abstenerse
de responder.
Así mismo para absolver consultas sobre temas de ética de la investigación puede comunicarse con el
Comité de Ética de la Investigación (CEI) al correo electrónico: [email protected]
Muchas gracias por su participación.
130
Yo, doy mi
consentimiento para participar en el estudio y soy consciente de que mi participación es enteramente
voluntaria.
He recibido información en forma verbal sobre el estudio mencionado anteriormente. He tenido la

oportunidad de discutir sobre el estudio y hacer preguntas.
Al firmar este protocolo estoy de acuerdo con que mis datos personales serán tratados de forma
confidencial, pudiendo ser utilizados únicamente según lo descrito en la hoja de información que detalla
la investigación en la que estoy participando.
Entiendo que puedo finalizar mi participación en el estudio en cualquier momento, sin que esto
represente algún perjuicio para mí.
Entiendo que recibiré una copia de este formulario de consentimiento e información del estudio
y que puedo pedir información sobre los resultados de este estudio cuando éste haya concluido.
Para esto, puedo comunicarme con el Magister Luis Flores al correo [email protected].
Nombre completo del (de la) participante Firma Fecha
Luis Alberto Flores García
Nombre del Investigador responsable Firma Fecha
131
Anexo 5 – Acuerdo de Confidencialidad con Empresas
Yo, Luis Alberto Flores, identificado con DNI N° 1077024, de nacionalidad peruano, me
obligo a guardar estricta reserva y confidencialidad, de forma indefinida, sobre toda la
información y documentación que me sea entregada con dicho carácter por la empresa
, identificada con RUC N° , a fin de
que la referida información y documentación sea utilizada exclusivamente en el marco
de la realización de mi tesis de posgrado, titulada provisionalmente Impacto de la
Gestión de Portafolio en el Rendimiento de Pequeñas y Medianas Empresas
desarrolladoras de software.
Para tal efecto, me comprometo a no utilizar la referida información documentación para

fines ajenos a la realización de mi tesis; comprometiéndome a no divulgar, reproducir,
transmitir, revelar ni utilizar dicha información en beneficio propio o de terceros, salvo
consentimiento previo y por escrito de la Empresa. En el mismo sentido, cualquier
publicación que incluya la información confidencial deberá ser coordinada previamente
con la Empresa.
El compromiso asumido en el presente documento es exclusivamente personal, por lo

que exonero a la Pontificia Universidad Católica del Perú de cualquier responsabilidad
que pudiera generarse por el eventual incumplimiento del mismo.
Lima, de del 2019
Luis Alberto Flores García
DNI N° 10772024
132
Anexo 6 – Transcripción de entrevista 1
¿Qué tipos de proyectos está realizando actualmente la empresa?
Estamos con proyectos de desarrollo, proyectos de configuración e implementación de

centrales telefónicas, que también derivan algunos desarrollos en base a esa tecnología
y bueno desarrollos internos con miras a que sean productos empaquetados que se
puedan vender.
¿Cuántos proyectos manejan al mismo tiempo aproximadamente?
Ahorita, como proyectos, hemos tenido hasta cuatro al mismo tiempo.
¿Y cómo empresa cuáles son sus objetivos de negocio?
Los objetivos de negocios es poder crecer como empresa, para eso necesitamos tener
un portafolio de desarrollos empaquetados, poder abarcar mucho más… ósea poder
abarcar las necesidades de más clientes de diferentes sectores. Por ejemplo,
implementación de desarrollo CRM, no solamente abarcar plataformas o tecnologías de
PBX, que, si es el fuerte de la empresa, sino otras tecnologías también. Con Daniel
continuar con el tema de innovación utilizando tecnologías que estén pues en boga,
estén a la vanguardia. Lo que pasa es que ahora hemos trabajado en un esquema de
buscar proyectos. Ya sea los de implementación de centrales y call centers que digamos
que ya se saben cuál es su alcance, casi siempre. Son tecnologías que ya se conocen,
pero hemos ido abandonándolo por un tema de desarrollo de software puto, porque
realmente lo están necesitando nuestros clientes. Es como una segunda etapa después
de que hemos dado el primer paso de entrar a su empresa. Le decimos “también
desarrollamos esto”, pero igual eso sigue siendo un tema de… todo el mundo lo hace
en realidad, entonces se buscó trabajar con productos, pero eso ya hace unos dos años.
La idea es que ahora que todo está en la nube sea un servicio, software como servicio.
Eso es poco hacia dónde va o iba la empresa, buscar que productos se pueden vender
coa servicios. Esa sería la idea.
¿Esos objetivos que tiene la empresa, quiénes en la empresa los conocen?
Todos realmente. Ósea es una empresa pequeña. Por ser empresa pequeña
generalmente los objetivos, el desarrollo, lo que se quiere como empresa como
necesidad se definen en proyectos. Proyectos internos que decimos “Ya este proyecto...
“. Por ejemplo, los chicos de desarrollo dicen “¿pero para quién es este proyecto?” Es
un proyecto interno que se quiere completar, poner en la nube y por cada proyecto que
133
van desarrollando, que no son muchos igual, le van definiendo un objetivo, un alcance
y una orientación hacia quien está dirigido. Cuando no tienen clientes directos les
decimos el porqué. Entonces lo que acaba de decir Daniel a dónde va la empresa, en
relación con los productos que están desarrollando, lo saben todos.
¿Y cómo se les comunica estas cosas?
En forma verbal
¿Cómo evalúan si se cumplen estos objetivos?
Nosotros tenemos un listado, hacemos un…dentro de un dashboard. Tenemos varias

formas. Primero dentro de una pizarra, ponemos los proyectos pendientes con su estado
y aparte eso mismo se vuelca en un Excel y vamos chequeando ahí, por estados lo que
se está desarrollando, los que están pendientes o ya finalizados y es visible a todos.
¿Ok, pero cómo alineas eso o cómo usas ese dashboard para ver si tus objetivos
de negocio se están cumpliendo?
Vinculados a los objetivos, propiamente dichos no están. Ósea como idea tenemos los
proyectos que necesitamos y vemos que proyectos se van a desarrollar y a esos les
cambiamos estado digamos en proceso y dejamos los otros en pendiente. Pero
propiamente dicho, objetivos vinculados a qué proyecto no.
Me comentabas que tenían proyectos internos que buscan desarrollar primero

como productos y ahora como servicios. Puedes dar un ejemplo de eso para
entender un poco más.
Uno de ellos es por ejemplo el CRM, que digamos es una necesidad propia interna pero
también es una necesidad en general que podría brindar a ciertos clientes, Algunos
tienen experiencia en CRM de diferentes tipos, que han trabajado en diferentes
empresas y esos... ese conocimiento se está volcando. Se ha centralizado y se quiere
desarrollar, primero como uso interno, peor el objetivo es probarlo internamente para
ponerlo en la nube, y poder venderlo, ofrecerlo como un servicio. También hay proyectos
que nosotros hemos desarrollado para otros clientes que se han vendido como servicio,
del cual nosotros somos dueños del código fuente, ósea por contrato. Eso también ya
lo tenemos casi listo, obviamente hasta que sea un producto que salga al mercado,
demora un tiempo, pero hemos estado en ese esfuerzo. Ahí hay un soporte de calidad
de la data.
¿Y cómo consigue proyectos la empresa?
134
Es interesante. Particularmente nuestra empresa por el prestigio que tiene dentro del
nicho, dentro del sector, la gran mayoría de clientes que ahorita se tiene es del boca a
boca. Un cliente te recomienda, el otro cliente me ha recomendado por aquí, un tal por
aquí, me pasaron el dato por aquí, mira que este amigo que está haciendo algo así me
ha hablado de ustedes y es sobre todo el boca a boca. Del 100% de clientes, creo que
los que tenemos ahora, es un 80% es boca a boca y el 20% han llegado solos, de
casualidad, pero muchos o la gran mayoría es el boca a boca. Tenemos la página web
que también está en Google, todo, y por ahí tenemos un Bot que toma pedidos, o toma
preguntas. Entonces por ahí también entran. Te digo hoy día ha entrado uno por ese
lado, otro es un boca a boca de una persona que nos conoce, sabe que nuestro nicho
también al principio ha sido el tema de IVRs, y ahí ya…
¿Y en ese proceso de conseguir a los clientes, quiénes participan en la empresa?
Mira, digamos antes fueron, casi todo Néstor, yo, la parte comercial, pero ahora estamos
justamente en un cambio accionarial, de las cuales una de las personas que va a entrar,
va a proveer el brazo comercial. Si porque, bueno no sé si habrá una pregunta más
abajo, pero en realidad el tema comercial es el que siempre hemos adolecido, porque
somos muy técnicos y por otro lado explicar la tecnología es bastante difícil y también
es difícil no solamente explicarla, sino cuando sale un producto poder decir para que
sirve, todo eso y hacer un plan de mercado consistente. Digamos como nos estuvo
funcionando el boca a boca bacán, pero eso no te hace crecer. Ahora estamos en un
tema de entrada de un nuevo socio y ese socio viene con una inversión en el área
comercial y es lo que está aportando.
¿Y en el caso de estos proyectos internos, estos proyectos de innovación, de

dónde surgen las ideas?
Básicamente surgen de la experiencia de los integrantes, en mi caso, he conocido sobre

algunas herramientas que he utilizado en otras empresas. Algunas unidades de
desarrollo que también he visto y sabiendo que nuestra empresa tiene el potencial de
desarrollarlo, con toda la tecnología que puedan utilizar, se ha conformado, digamos
como conocimientos un poquito de todo. Ósea se puede dar un conocimiento general,
global, pero se invoca a todos para también aporten. Se hace dinámicas, en algún
momento hemos hecho dinámicas como para alimentar mucho más la idea y ya
aterrizarla.
Y teniendo estas ideas, más las que llegan a través del boca a boca o del chatbot.
¿Cómo deciden qué proyectos ejecutar?
135
A ver, lo que pasa es que, entre las ideas de innovación, obviamente se priorizan
conforme a también el socio. Muchas veces hacemos los productos, por lo menos de
innovación, de la mano de otras personas. Por ejemplo, de alguien que vino con la idea,
o de alguien que pueda aportar algo. Si son de todos los proyectos en general
obviamente vamos a tomar primero los que van a facturar, antes de los que sean
innovación o no, pero ya si solamente son los de innovación priorizamos también que
tan rápido, que tan maduro ya está. Te digo tenemos una cartera de proyectos en las
cuales, de repente a uno solamente le falta localizarlo o falta ver cómo se puede, si va
a ser multitenan, o si se va a generar una instancia en la nube. Esas decisiones hacen
que los proyectos se aceleren. Otras veces fue por un tema de oportunidad, por ejemplo,
se desarrolló un software de facturación electrónica que funcionaba. Claro es un
software de uso interno, pero que tenía potencial hacia afuera. Obviamente con todas
estas movidas que ha habido en la facturación electrónica está un poco en stand by,
pero digamos ahí tenemos.
¿Y quiénes toman esas decisiones de que proyectos se ejecutan al final?
Bueno, como dice Daniel es a demanda. En general los proyectos que intervienen con
necesidad para clientes, a demanda de ellos, por la necesidad de desarrollarlo lo más
antes posible, o porque el cliente ya está, ha mandado la orden de servicio, se
desarrolla, pero en el caso de proyectos internos, una dinámica que hemos hecho hace
poco, listamos todas la ideas y todas las grandes oportunidades, internamente votamos,
damos un peso sobre qué tan fácil era la tecnología que se iba a utilizar, el tiempo de
desarrollo, retorno de la inversión por el tiempo que se está ejecutando y escogimos un
proyecto interno, y después para digamos tener un desarrollo o un proyecto que hacer
mientras los otros proyectos vinculados tal vez a los clientes externos, se acaban. Se
acaban y continuamos con este proyecto.
Dijiste que han votado. ¿Quiénes votan?
Todos
¿Toda la empresa?
Somos pequeños, todos, sí.
¿Esos aspectos que toman para tomar las decisiones quedan documentados en
alguna parte?
Básicamente por correo. Por correo se hace como una encuesta. Cada uno... recuerdo
haber hecho una encuesta, y a cada uno le llegó un correo. Cada propuesta tenía
136
asociado un valor, al final tengo una sumatoria de valor y gana el que tiene un ponderado
mayor y se les comunica a todos que el proyecto elegido a desarrollar internamente es
este. Esa fue la última dinámica que hicimos.
¿Y hay proyectos que se deciden no hacer, con cliente por ejemplo?
En algún caso puede ser que se decida no hacer, porque lo intentamos al inicio,
hacemos pruebas, intentamos, pero si en caso no, se podría decir al cliente que no, pero
generalmente si intentamos, lo hacemos. A veces se ha hecho unas pruebas de
concepto y no se puede hacer o le costaría bastante al cliente. Muchas veces es que
eso, del costo de hacerlo tradicionalmente. Nosotros tratamos de ver otro enfoque y a
veces no sale. Otros proyectos que no van son por la prueba de concepto, no les
convenció no.
¿Y en el caso de los proyectos de innovación es básicamente según lo que me

comentaste? Dificultad, madurez creo que también mencionaron por ahí.
La tecnología que se va a utilizar, el tiempo que va a demorar en tenerlo, que tan fácil
también va a ser venderlo, que tanto impacto pueda tener un producto de ese tipo. Ahora
los proyectos de innovación que nosotros tuvimos hace unos años, se lanzaron casi
porque había fondos. Había ese fondo, algo constructivo y todo eso, pero digamos
ahora, casi todos los proyectos son internos, o con la ayuda de otra empresa. Ósea ya
no buscamos fondos concursables por ahora. Desde el año pasado que terminamos el
último.
¿Y qué tipo de proyectos de innovación se ha hecho?
Bueno, hablemos los que fueron con fondos concursables. Hicimos uno de inteligencia
artificial hace unos 4 años un chatbot que se terminó el año pasado, con los fondos de
Innovate, tanto PIPEI y el de validación y empaquetamiento. También tuvimos... bueno
este es un proyecto ya terminado, valorizado, como te digo se terminó el 2017. Se
supone que el 2018 era el año de comercialización, pero bueno por algunos problemas
creo que no se ha logrado. El otro proyecto era un software, bueno software y hardware
para detectar, poder detectar el manejo de las personas. Que tan bien o mal manejaban
de tal manera de poder hacer predicciones y también calificaciones. Serviría para evitar
los accidentes de tránsito. Esos son los proyectos que han sido pagados con dinero del
gobierno, pero aparte de eso hemos desarrollado software por nuestra cuenta, con
ciertos diferenciales que podrían hacerlo innovador a un mismo... Por ejemplo,
facturación, si bien era un tema interno lo enfocamos a que también tenga una
administración básica de la gestión, y es más creo que por ahí vamos a ponerle algunas
137
cositas más. Ósea siempre tratamos de que el producto sea distinto para competir con
la oferta que si es bastante común en todos lados.
¿Y qué porcentaje de recursos se asocian a estos proyectos cuando se realizan?
Bueno, en el caso de los recursos de la empresa, bueno en el tiempo de los fondos

concursables era 20%, si era considerable, pero ahora lo hacemos en los tiempos que…
puede ser en tiempo de hombres, puede ser el 20% del tiempo de todos los chicos que
se utilizan, pero antes era más. Ahí si había monetario.
¿Y al momento de decidir iniciar un proyecto, sea con cliente o sea interno, se

analizan los riesgos que implica hacer este proyecto?
Como riesgos, riesgos… bueno tal vez el riesgo que no sea… que no tenga mucha
acogida, tal vez por ahí, el riesgo de hacerlo cuando ya hay competencia, que podríamos
ya…Ósea una que ya tiene pues, un UBER no voy a hacerlo, pues no. Entonces ese
riesgo ya no lo asumimos. Ese tipo de cosas se evalúan. Riesgo tecnológico.
¿Consideran que todos los proyectos se alinean con los objetivos empresariales
o hay alguno que no esté alineado o que lo hayan hecho solo por facturación o
alguna otra razón?
Sí, ha habido, pero evidentemente, obviamente lo hemos hecho. Lo más importante es

la facturación en realidad. Sí, pero eso sí, tratamos de no meternos en software que
digamos que sabemos que hay alternativas de mercado más, que son mejores y que
simplemente, ni siquiera concursarlo no. Porque realmente, ósea un software de
contable, ese tipo de cosas, es casi suicida, porque sabemos que, aunque nos lo den,
es un trabajazo y probablemente no tenga la continuidad. Solamente nos gusta software
que podamos reusarlo, podamos volver a crear…, a hacerlo algo innovador. En este
caso apuntar a que sea como un servicio para que nosotros lo distribuyamos, si es que
no hay un tema…Y bueno otra cosa es por ejemplo si siguen llegando proyectos de
centrales o call center pues los vamos a tomar por el know how, pero no es que nos
apasione ahora hacerlos. Sí, pero esos son ejemplos clásicos.
Entendiendo que todos participan en la selección de los proyectos que me

estabas diciendo, entonces entiendo que el background de conocimientos y
experiencia que tienen las personas al momento de seleccionar también es muy
variado
Sí,
¿Cómo les resulta eso?
138
Enriquecedor, cada uno tiene su punto de vista y aunque no tienen el conocimiento
algunos de ellos, por ejemplo, unos chicos que estaban practicando, el hacer sus
preguntas, nos hace cuestionarnos, porque les respondemos y sobre eso se hacen otras
consultas que actualmente un estudiante ve otras cosas. Igual nos alimenta, nos llena.
Sí, sobre todo porque casi el 90% son gente de tecnología, preguntarles a todos ellos
sobre tecnología es válido. Antes solo había una persona que era de administración,
pero igual su experiencia de ella era interesante, porque tenía otro enfoque y por eso
creo que este tipo de empresas que son pequeñitas, que todos o la mayoría somos de
tecnología, todos tienen que aportar.
¿Y este porcentaje aproximado de 20% que les dedican a los proyectos de

innovación, es una política de la empresa, surgió naturalmente, es algo
establecido de alguna forma?
Yo creo que es natural, porque como te decía, si ahorita nos vienen clientes y nos llenan
la lista de proyectos en cartera, vamos a dedicarnos a hacer proyectos de clientes. Y
cuando se acaba algún proyecto, que se ha desarrollado por demanda, recién
comenzamos a continuar con los proyectos internos.
¿Cómo gestionan sus proyectos entonces? ¿Se basan en algún estándar?

¿Tienen alguna metodología?
Creo que una mezcla de todo. Tratamos de usar Scrum, pero hay por ejemplo en
algunos proyectos que necesita el cliente, pues su cronograma y sin eso no se mueve.
Quiere su cronograma y hay que hacerle su cronograma. Hay actividades que si
necesitan ser documentada porque facilitan pues la fase de información y hay otras
cosas que no son necesarias. No sé, los seguimientos, las pruebas que se hacen, que
son internas y que tratan de acabar tal vez con un módulo específico, se hacen siguiendo
el estándar Scrum, pero hay cosas vinculadas al cliente, que necesita por lo menos
hacer un corte y se hace cierta documentación, se hace cronogramas, cierto avance
como un proyecto basado en otra metodología.
¿Hace cuánto tiempo trabajan de esa forma ¿Desde que se fundó la empresa?
No, desde el 2014.
¿Cómo controlan el alcance de los proyectos? ¿Cómo lo gestionan? ¿Cómo lo

identifican?
Particularmente yo, y lo que hace la empresa es primero definimos el proceso que

vamos a trabajar. Sobre el proceso hay actividades de inicio y actividades de fin.
139
Hacemos una trazabilidad, porque de repente es un proceso donde intervienen varias
áreas y varios usuarios. Y sobre ese proceso, esa actividad de inicio y fin se desarrolla.
Cosa o actividad posterior que impacta y no está dentro de este mapa de proceso o de
este proceso levantado no se realiza. Se deja en claro que todo lo posterior a esta
actividad o anterior a la actividad que se he levantado sobre el proceso no se va a
realizar. Ese es el alcance para nosotros.
¿Y el cronograma como lo elaboran?
El cronograma, generalmente, cuando definimos las actividades de proceso, estimamos

cuales son los módulos que van a agrupar ciertas actividades y definimos complejidad
por cada módulo a desarrollar y por esa complejidad definimos tiempos estimados y
sobre eso hacemos los cronogramas, cuando el cliente necesita el cronograma.
¿Y el presupuesto?
Lo mismo, hacemos exactamente lo mismo. Primero las actividades, lo agrupamos en

módulos por complejidad de ese módulo y vemos horas hombres de dedicadas en esa
complejidad, en ese desarrollo y sobre eso estimamos tiempo y costo.
¿Qué prácticas de aseguramiento o control de calidad aplican en los proyectos?
Haber…básicamente el control de calidad que hacemos es de pruebas internas, sobre

lo más clásico que hacemos es con un juego de datos de prueba y sobre eso correr el
funcionamiento, pruebas de stress, digamos es lo más básico. Nosotros ideamos en un
inicio, que vamos a crear ciertos datos, sobre eso te debería darnos 20 datos, 20
entidades. Cuando ingresamos ya al módulo desarrollado, ingresamos y hacemos las
pruebas. ¿Por qué no me sales esto? De repente mis pruebas, mis datos de alguna
manera han sido erróneos, verificamos, y sobre eso digamos planteamos la calidad,
sobre algo que se espera y sobre un resultado.
¿Eso está planificado desde el inicio o se va haciendo?
Desde el inicio se tiene una idea general. Si se tiene una idea general sobre qué es lo
que se necesita y qué es lo que sucede. Se da como historias de usuario al programador,
se le dice quiero esto, quiero lo otro y dentro del proceso hemos levantado, hemos
identificado herramientas tipo formularios, tipos Excel, documentos reales y eso viene a
ser nuestros casos de prueba. Entonces eso es lo que necesitamos y así debe de salir
la vista o Excel o el formato que se necesita porque es la realidad del usuario, es lo que
usualmente trabajo. Lo que hacemos es automatizar.
140
Me habías adelantado que cuando eligen un proyecto, a veces analizan la
posibilidad del mercado o la competencia existente. ¿Cuándo ya empezó el
proyecto, gestionan riesgos de alguna manera?
Cuando ya empezamos el proyecto ya no. Si estamos hablando de proyectos internos

no.
¿Y en proyectos externos?
En proyectos externos, el único riesgo es que nos cancelen el proyecto, porque si nos
siguen pagando por algo, lo seguimos desarrollando.
Me habías comentado que tenían un dashboard de proyectos. Coméntame un

poquito más como usan este dashboard.
Es una réplica de la pizarra que tenemos. Nosotros tenemos una pizarra por un listado
de proyectos y los estados de los proyectos, también quién lo está viendo y en qué
estado está. Dentro de los posits ponemos fecha de inicio, fecha de fin por esa actividad
o por ese módulo. Básicamente por esa actividad que está realizando y aún no termina.
Yo lo vuelco dentro de una Excel. Sobre ese Excel digamos tengo un avista rápida sobre
qué proyectos están en qué estado, pendientes, en proceso, o finalizados.
¿Ese Excel lo administras directamente tú?
Sí
¿Y usan alguna herramienta para los otros elementos de la gestión, para gestión
de alcance, de cronograma, el presupuesto?
Bueno, del cronograma usamos… Yo básicamente usaba Ganter, el clásico Gant y el

Project, pero para el presupuesto no. No utilizamos más que la experiencia de los
programadores.
¿Usan Excel para eso?
Sí Excel. Básicamente el presupuesto es experiencia de los programadores, para

definir la complejidad, para definir horas hombre y un Excel que vamos definiendo ahí.
¿Y conforme avanza el proyecto, controlan los gastos reales?
Sí claro,
¿Cómo lo hacen?
Por ejemplo, en los proyectos que había inversión externa, lo ponemos todo en un
listado, cada factura o cada salida del proyecto tiene que estar justificado con algo.
141
Básicamente era un listado vs una factura o algún tipo de…más que nada eran servicios,
pago de los chicos.
¿Y en los proyectos internos controlan de alguna manera los costos?
Horas hombres.
¿Cómo registran las horas hombres entonces?
Como te decía en los posits que tenemos, por estado se pone la fecha inicio, fecha fin.
Ahí volcamos… cuando lo vuelco en el Excel, vuelvo a.… digamos que reescribo en el
posit si dice cuando es la fecha de inicio, cuando es la fecha que terminó y ahí hago una
resta y pongo los días.
¿Y el dashboard que mencionas lo manejas en Excel también?
En Excel, sí es un Excel.
¿Los empleados saben cómo su proyecto se alinea con los objetivos? Bueno si
me acabas de decir que todos forman parte de esto.
¿Quién se encarga de la gestión de los proyectos dentro de la empresa?
Soy yo
¿De todos?
Sí
¿Y dentro de los proyectos, hay un líder adicional o tú llevas la gestión directa de

todo?
No, hay líderes. Hay un líder en tema de programación y hay un líder en tema técnico.
¿Cuáles son las funciones de estos? (30:18)
La calidad de… en el caso de desarrollo, digamos él es el responsable de absolver

consultas, revisar, hacer un filtro adicional al que yo voy a hacer. Y el de soporte
exactamente lo mismo.
¿Y por cada proyecto cómo definen éxito?
Con la satisfacción en este caso del cliente si es externo, y nuestro caso la satisfacción
de los que están revisando y de todo, porque en el caso de los internos le pedimos a
todos que prueben. Obviamente nosotros, sabiendo los objetivos de lo que se necesita,
revisamos y vemos si se han logrado o no los objetivos, lo que se necesita, lo que se
quiere. Pero igual le decimos a todos que prueben, bajo el objetivo que se necesita, bajo
142
el enfoque que se ha desarrollado el proyecto. Y una vez que todos están digamos con
OK, o se sienten satisfechos damos por alto el proyecto.
¿Cómo mides la satisfacción del cliente en el caso de los externos?
Con un acta de conformidad. Sí básicamente es hacer pruebas, si está tu requerimiento,

chequeamos, por ejemplo, ahora en proyectos vamos revisando. Este módulo hace
esto, entre este dato, sale este dato, está OK, OK. Es básicamente un checklist sobre
funcionalidad y si el cliente siente que cumple la funcionalidad que se está presentando
sí o no. Si en general todo es OK, está bien.
Entiendo que los proyectos externos son los que tienen la mayor prioridad.
¿Dentro de los proyectos internos tienen alguna forma de priorizarlos?
Si se priorizan. Como te comentaba se hizo una dinámica de hacer un listado de

proyectos internos, y a través de un cuestionario por cada proyecto, se le puso un valor
a la respuesta, el tiempo de demora, que tanto impacto puede ser, que tanto sale, la
tecnología que se están utilizando y hay varios criterios que ahorita no recuerdo, que se
envió por cada proyecto. Y sobre el valor de esos resultados se dio prioridad a uno de
los proyectos.
¿Ósea el resultado es siempre uno?
Es uno y una secuencia, el que se quedó segundo, el que quedó tercero… el que quedó
cuarto, quinto, sexto.
¿Y usualmente tienen un proyecto interno en desarrollo o puede ser más de uno?
Podemos tener más de uno.
¿Dirías que hay una buena comunicación entre la alta dirección y los que llevan
los proyectos?
Sí, la ventaja de estar, es ser pequeñitos, hace que sea bastante rápida. Aparte se les
ha dado la confianza a todos para decir lo que piensan y lo que se necesita.
¿Cómo es una típica reunión para decidir un proyecto?
Típica, típica, típica, con bastantes risas. Hago que cada uno hable y remarco mucho
que cada uno tiene un conocimiento que es importante, preciso de su conocimiento para
alimentar la idea y si alguien está equivocado o no igual. Es decir, es importante saber
de porque creen que están equivocados, lo cual valida o invalida algunos conocimientos.
¿Qué porcentaje de proyectos termina entonces con éxito?
143
Bajo la definición de éxito con los clientes externos tienen que ser todos, porque para
eso están pagando, y si no están satisfechos, volvemos al tema de porque está
insatisfecho, volvemos a hacer la revisión y hasta que ellos estén satisfechos. Ósea
puede ser que muchos no estén satisfechos, pero sobre eso no terminamos. Vamos a
revisar parte de la garantía, revisar y porque crees que no y hasta que el acta de
conformidad o su validación es OK, ya no tenemos ningún tipo de problema. En el
caso de internos, creo que somos, hasta más molestosos, como ya depende de
nosotros. Si encontramos algún tipo de observación o algo, están todos nosotros para
tratar de mejorarlo.
¿Qué porcentaje de proyectos terminan retrasados o con presupuesto excedido?
Eso es otra cosa, retrasados, te diría que 70%.
¿Qué tan retrasados?
No sé, cómo definimos que tan retrasado, moderadamente retrasado, súper retrasado…
¿Para ustedes que sería un proyecto retrasado en estado crítico?
Que tenga 3 meses y seguir con esa factura sin cobrarse. Tres meses es demasiado.
Un me, un mes y medio… uhmm, ya te acepto, pero dos meses ya... y tres meses ya
mucho porque es un dinero que no está ingresando a la empresa. Date cuenta que
también nuestros proyectos no son de mucha duración. Ósea todos los de call center,
PBX normalmente es un mes máximo. Call center será un mes y medio, dos meses y
cualquier otro desarrollo lo hacemos entre uno y dos meses. Es nuestro tiempo y
desarrollos más grandes que pueden tomar 4, 5 meses serían los más críticos, pero
tampoco hay muchos de esos. Si se demoran, se demoran pues hay observaciones y
más que se demoran realmente estamos como que a grandes rasgos, agregando
nuevas funcionalidades, nuevas mejoras para que el cliente se sienta satisfecho.
¿Hay proyectos que se cancelen antes de terminar?
Iniciado, en externo, no creo, porque para iniciar ya dan un porcentaje del valor. Hubo
creo un proyecto hace más de 10 años. Los internos tal vez sí porque obviamente hay
demanda de otros y se deja de lado por lo externo.
¿Y cuál es la tasa de errores reportados después de entrega?
Como errores, errores, errores, si yo creo que, si puede haber, es bajo. Observaciones
es diferente, pero errores, errores, puede haber que se nos haya pasado lago, pero es
144
bajo. Un 10%, es bajo. Observaciones muchas, pero justamente ahí está la garantía de
45 días para seguir mejorando o para conseguir la satisfacción completa del cliente.
Los resultados de la encuesta que respondió Daniel muestran buenos resultados

en ventas, ganancias y crecimiento del empleo para la empresa. Desde tu
perspectiva cómo has visto las ventas, las ganancias de la empresa.
Ya, ahí, en el tema de dinero, ganancias, recién me estoy metiendo por n motivos, pero
no. Te hago la cotización, pero más allá de ello no.
OK, Daniel, ¿Porque consideras que el crecimiento en ventas fue bueno en

comparación con los competidores?
Lo que pasa es que nuestra empresa compite con los de centrales telefónicas y compite
con desarrollo de software. En el tema de centrales telefónicas, nosotros vendimos al
principio del año del 2017 un montón de centrales a un cliente, grande, a dos clientes
grandes. Entonces eso como que paró fuerte la facturación. Ósea te digo y es más
vendimos en uno de ellos, una cantidad interesante de teléfonos. Entonces yo creo que
en relación a nuestros competidores estábamos bien en el tema de Centrales
telefónicas. En el tema de facturación también nos fui bien, justamente por esas dos
ventas que conseguimos. Hubo un margen interesante.
Pero me estás diciendo hace un ratito que ya lo de las centrales telefónicas no

quisieran que fuera su core.
Exactamente. Es que el 2017 todavía no habíamos dicho. Es medio complejo, porque

se tiene mucho conocimiento en eso, la experiencia y todavía nos llaman, pero nos
gustaría como empresa ir a otras cosas.
¿Y el crecimiento del empleo, ahí estaba 4 sobre 7?
Lo que sucede es digamos, ahora hay menos gente, pero digamos de que había gente,
había gente. Lo que pasa es que dejamos de invertir en innovación, se terminó todos
esos proyectos que nos asignaron plata, entonces optamos por traer más personas,
inclusive había chicos de SENATI, practicantes, entonces al final hubo un aumento en
la cantidad de personas.
¿Pero dices que ahora son menos?
Ahora, en este instante, en este último 6, 7 meses. Se ha visto la necesidad que los
practicantes son nuestros. Ósea si hay necesidad de tener practicantes, pero los de
SENATI han optado por, bueno estos chicos han tenido muy buenas calificaciones y los
145
han posicionado en empresas más grandes, ya no como practicantes, sino como
empleados, pero como rol de practicantes que nos apoyen si es necesario y si está
previsto en marzo igual coordinar con SENATI para continuar con practicantes.
Un poco contrario a esta pregunta, el cumplimiento de expectativas si parece bajo.

Un valor de 2 en una escala del 1 al 7. ¿Cuáles eran tus expectativas Daniel?
Lo que pasa es que mis expectativas eran la parte de desarrollo. Ósea tecnología,
porque, ósea, también hubo, desde el año antepasado, los proyectos open source que
nosotros usábamos como base de nuestra tecnología, fueron comprados por empresas.
En un caso simplemente desapareció el proyecto y en el otro caso no va a desaparecer,
pero, de todas maneras, siempre es un riesgo. Entonces nosotros teníamos que tratar
de huir de eso. Y, por otro lado, yo quería salir definitivamente del tema de centrales
telefónicas porque era un tema que nosotros habíamos llegado como de taquito. Ósea
no era algo que yo me quería… bueno la empresa se creó tratando de generar valor
agregado, ósea desarrollo de telefonía, entonces en eso si hemos sido bastante
exitosos, pero digamos, el IVR y todo eso es una tecnología que no se mueve mucho.
Ósea, si bien todavía es parte importante de la IA y llamas a un call center te contesta
un sistema que te dice digita 1, digita 2, pon tu DNI, todas esas cosas. No es un nicho
que tenga demasiado…o por lo menos, en el tiempo ha sido muy lento su crecimiento.
En el ínterin, hemos puesto otras cosas, las centrales telefónicas y al final nos cargamos
de un trabajo de soporte de esas centrales y todo eso, que los integrantes que no
somos… no es que no seamos especializados, sino que nunca quisimos entrar ahí.
Entonces yo decía, movámonos de acá y movámonos a desarrollar productos que
realmente tenga innovación y todas esas cosas.
Acá mencionabas que el crecimiento en ganancias fue bueno en comparación con

tus competidores. Entiendo eso es contra los de Centrales.
Si centrales
Y en la otra el desempeño general del negocio no supera a nuestros principales

competidores entiendo que eso es a desarrollo.
No, también a centrales. Lo que pasa es que hay gente, ósea nosotros estamos…
nuestros competidores, digamos que somos los que ponemos centrales y todas esas
cosas, en eso estamos bien, Pero hay otros grandotes, y hay otros grandotes que son
gigantes, que son Cisco, contra esos nunca vamos a competir. Yo estoy diciendo muy
bien contra los que instalan centrales telefónicas, por otro lado, también durante estos
años ha pasado el tema de, y es una naturaleza de las telco, que ellos ya te vendan
146
todo. Entonces se han vuelto mucho más agresivos, porque antes pues a Telefónica no
le interesaban proyectos pequeñitos, pero ahora sí, Telefónica y las otras empresas te
ponen la central a quien quiera, con Claro ahora hay más sectores, Entel, Óptica.
Entonces ese es el... Ósea el negocio ya cambió, ahora la central telefónica es un
comodity que te lo ofrece la operadora. Entonces no, por ahí, te digo es un mercado que
yo veo que va a hacia abajo. Entonces no, en relación a esos grandes jugadores que
ahora ya ni siquiera es Cisco, ni Avaya, ni los que eran competencia de software libre,
sino que ahora es todos, Telefónica, todos los grandes telco que ya traen su propia
central. Inclusive pueden tener por dentro la tecnología que nosotros usamos, pero ya
no... es imposible competir con ellos.
¿Y eso hace que la gerencia no esté muy satisfecha con el desempeño general del
negocio?
No, justamente ese es un problema. En realidad, había que reenfocarse, ósea vamos,
estamos en un negocio de tecnología, que su fortaleza y debilidad es exactamente la
misma, la tecnología. Entonces si nosotros no damos soluciones tecnológicas de
avanzada, pues no vamos a llegar a ningún lado, porque hay mucha competencia,
porque chicos de la universidad pueden hacer exactamente lo que nosotros hacemos.
Eso no tiene sentido.
¿Y en tu perspectiva Ronald, estas prácticas que me han mencionado, que, si se

ejecutan, como por ejemplo la reunión para tomar las decisiones con todos, crees
que es productiva para la empresa?
Sí, es productiva. Como te mencioné nos apoyamos en el conocimiento de todos, sobre

todo porque todos somos de tecnología. Todos tienen un conocimiento interesante que
aportar.
¿Y este dashboard que mencionabas, que es llevado en Excel? ¿Qué tan útil les
es a la empresa?
Sí, es útil, porque particularmente yo no me manejo a la memoria. Soy súper olvidadizo

de las cosas. Y acercarme a la pizarra donde hay cierta información o estar en algún
lugar donde me preguntan algo que no lo tengo en la mente y no tengo la pizarra, tengo
mi Excel y ahí está mi información.
¿Qué tan importante creen que es la innovación para la empresa?
Es fundamental, porque como decía Daniel, no podemos avanzar si es que alumnos o

personas que están estudiando hacen básicamente lo mismo. Tenemos que dar algo
147
diferencial. Algo que genere mucho más valor aún de lo que estamos brindando y eso
lo podemos hacer con innovación. Usar tecnología digamos probada en otros países o
que se está desarrollando y hacerla acá. Integrarlo a los desarrollos que estamos
haciendo.
¿Cuántas personas aproximadamente hay ahorita trabajando en la empresa?
Ahorita hay 6, y próximamente el practicante que es necesario y la otra persona de

administración. En general seríamos 8, pero ahorita hay 6.
Y desde el punto de vista financiero Daniel ¿Cuánto es aproximadamente la

rentabilidad de la empresa?
La rentabilidad, a ver, lo que pasa es que la rentabilidad normal debería ser pues, un
28%, entre 20 y 30%. Lo que pasa es que nosotros hemos estado invirtiendo en los
proyectos de innovación hasta el 2017. Como te dije, eso nos comió. Aparte entraba
dinero a la empresa que salía inmediatamente como gasto. Entonces en números,
digamos en estados financieros estamos en rojo, pero si normalmente hubiéramos
trabajado sin invertir en innovación y todo es. Sin estos proyectos grandes de
innovación, esa hubiera sido la rentabilidad de la empresa. Bueno es la rentabilidad en
realidad. Lo que pasa es que como, no se ve reflejado en los estados por el gasto que
hemos tenido.
¿Qué creen que necesita la empresa para crecer?
A ver, yo creo que hay dos o tres ejes en lo que es la empresa. Uno que es la parte de
ventas. La empresa debe mejorar su parte de ventas, yo creo que sin eso no vamos a
avanzar. Dos, es justamente si nosotros hemos estado recibiendo requerimientos y de
alguna manera así hemos vivido, imaginemos una situación en la que cual hay gente
activa que vaya generando ventas, ventas, ventas. Si nosotros eso lo podemos reposar
sobre un soporte técnico, un desarrollo que realmente cumpla las cosas en tiempo y en
esto y que le demos al cliente lo que precisa, yo creo que esa sería la fórmula. En
realidad, es una forma genérica. Yo creo que, dado nuestra fortaleza en la parte
tecnológica, deberíamos, digamos terminar de cerrar los productos y tratar de vender el
software como servicio. Ósea una de las cosas que yo soy creyente es el tema de
software como servicio. Ahora también, y esto ya es a mediano… Digamos, hay dos
partes, comercial y la parte de empaquetar los productos como servicios para ayudar
justamente en la parte comercial que se venda. Y la otra parte por abajo que estoy
viendo, es la parte de innovación tecnológica, pero yo creo que no es eso lo que nosotros
debemos trabajar, digo, nosotros hemos estado en una tecnología de nicho, en la cual
148
nos hemos podido desarrollar, pero yo creo que ya hay que adoptar los estándares
reales y la parte de por ejemplo llevar un proyecto. Ósea no debemos ser muy
contemplativos con el cliente en ahorrarles muchas cosas, porque al final no te hacen
ver bien a ti. Me parece que muchos clientes, nosotros vamos “Sí te lo hacemos en tal
tiempo”, entonces cuando de repente podemos hacer un poquito más de tiempo si es
que aumentamos algunos controles, un poco más de administración, no excesivamente,
pero que de una idea de que somos una consultora de que… una empresa que provee
soluciones y que lo hacemos de una manera profesional. Lo que sucede es que la
verdad, nosotros nos lanzamos a hacer las cosas, le solucionamos el problema al
cliente, pro realmente también puede venir Cisco y hacerlo por 7 veces más y el cliente
se siente feliz de pagarle a Cisco, a pesar de que hagan exactamente las mismas cosas.
Entonces el valor, no depende solo de lo que uno hace, sino también de cómo te
presentas al cliente. Es un tema de percepción, cómo nos vendemos. Yo creo que, si
nos ven a nosotros, ya no como Tx, y todo tranquilo, el cliente va a tener más
tranquilidad. Normalmente ellos estaban felices de tener a alguien, una empresa que le
solucione problemas, pero eso también podría llevarnos a… Digamos, si queremos
crecer tenemos que tener también ciertos estándares. Que podría hacer que haga que
tengamos cierto proceso, más burocrático, pero bueno, es el precio del cambio.
¿Y si ya venían desarrollando estos procesos de innovación, porque decidir ya no seguir

buscando esto fondos externos? ¿Por qué optar por hacerlo con fondos internos?
Porque, a ver, el caso del sistema de inteligencia artificial, no sé en qué momento se

perdió la fe en el producto, ósea es un producto que funciona y todo, pero no sé, como
nosotros no… si bien tenemos la tecnología, tenemos el código fuente, todo.
Dependíamos mucho de las personas que habíamos programado, entonces, no se dio
muy bien. Increíblemente la transferencia de tecnología no se dio muy bien hacia dentro
de la empresa. Entonces es difícil, hacer un cambio y venderlo. Nos dimos cuenta que
haciendo cosas más chiquititas a veces que parecieran inteligencia artificial, la gente
compraba más. Por otro lado, yo he visto, ya a un nivel macro que ahora, mucho con
esa corriente de las APIs y ponerse con las nubes y todo eso, quizás lo que estamos
desarrollando ya lo está haciendo Google y los está haciendo mejor y simplemente hay
que llamar la API y se acabó el asunto. Ósea eso también ha sido. El otro punto, el
sistema de los carros fuimos con un socio que se iba a encargar de la parte hardware,
el socio se retiró y nos dejó en el aire. Entonces nos dimos cuenta que también arriesgas
al momento de innovar. De todas formas, de so aprendes y segundo supongo que es
por el poder monetizar ya con las cosas que tenemos. Buscar cosas más prácticas.
149
Hemos dejado de solicitar fondos. Algo particular es que nos daban fondos y
contratamos profesional muy especializado, con un criterio, con un conocimiento bien
específico y grande, pero que pasa cuando se va el fondo. Ya no tenemos ese ingreso
para seguir manteniendo a alguien con ese conocimiento y que esa persona haga la
transferencia de ese conocimiento a otra persona que no está preparada para recibir
esa información básicamente nos quita un poco los temas de modificar, actualizar o
soporte del desarrollo que se realizó. Se encuentra, pero es un poquito más tedioso, ya
que no hay ese dinero para seguir manteniéndolo.
150
¿Qué tipo de proyectos maneja la empresa?
Bueno nosotros estamos abocados a crear soluciones adhoc o personalizadas para

nuestros clientes asociados, hablo de clientes asociados porque tenemos convenios
marco con empresas del sector comercio, portuario y finanzas. Nos movemos en esos
sectores. Tenemos ahorita portuario, finanzas y comercio. Ese es el orden. Entonces a
través de sus áreas de TI, ellos nos hacen requerimientos de proyectos que podemos
iniciar en un año o digamos de acuerdo a su plan estratégico de TI, proyectos que ellos
tienen. Que no son áreas de desarrollo porque sus áreas son de soporte,
mantenimiento, infraestructura. Entonces nosotros funcionamos como fábrica de
software o desarrollo de productos para ellos y se crea un portafolio de proyectos al año
o dependiendo de la envergadura del proyecto puede durar más de un año y vamos
atendiéndolos. En esa actividad nos movemos. El 80% del esfuerzo está ahí. Después
tenemos productos propios que comercializamos que es el otro 20%. Este es el esfuerzo
de ventas, entonces tenemos servicios personalizados y ofrecemos también productos
y dentro de los servicios que ya creamos o productos de proyectos terminados a medida
que los van utilizando se van requiriendo más funcionalidades y se activan las
actividades de soporte y mantenimiento. El soporte y mantenimiento de nuestros propios
proyectos hay tenemos también esfuerzo. De ese 80%, debe ser un 20%, 25% de
esfuerzo en mantenimiento, el otro 55% en desarrollo propio y un 20% en productos
propios, en instalación, puesta en producción de productos propios.
¿Y cuántos proyectos puede manejar al mismo tiempo la empresa?
En promedio administramos entre 3 y 4 proyectos al mismo tiempo. A veces hay picos

de 5 o 6 proyectos. Ahorita por ejemplo tenemos 4 proyectos activos en el portafolio y
cuando esos proyectos tenemos demanda se forman equipos. Somos 20 personas,
entonces se forman equipos de 4, 6 o 5 personas para atender cada proyecto y en el
tiempo se va definiendo. NO necesariamente a fin de año culmina ese portafolio. Por
ejemplo, ahorita tenemos 3 proyectos que todavía son del año pasado y uno que ha
empezado nuevo. Entonces más o menos en promedio es 4.
¿y cuáles son los objetivos de negocio de la empresa? ¿a dónde apunta?
Nosotros apuntamos según nuestro plan estratégico que lo hemos actualizado, es salir
a, apuntar a escalar a un mercado global. Nuestra atención ha estado a mercados
151
locales y no nos va mal pero ahora queremos ya atender mercados globales. Entonces
ya estamos haciendo negociaciones contactos con personas en el extranjero y para este
año queremos como meta al menos tener 2 proyectos globales.
¿Ese plan estratégico que mencionas está documentado?
Si,
¿Y quiénes en la empresa conocen esos objetivos?
Los socios y las gerencias. Tenemos una gerencia general, la gerencia de

administración y la gerencia de finanzas. Esos, serían 3 áreas de la empresa y un socio.
En mi caso por ejemplo yo soy socio y gerente general y hay una persona externa, que
es mi hermano, que es socio y tiene conocimiento sobre esto y las personas que dirigen
estas tres áreas, la administradora y la parte financiera y contable.
¿Quiénes dirigen los proyectos en la empresa?
En los proyectos, pues a mi cargo está la dirección de proyectos, del portafolio, yo lo

dirijo, estoy encabezando, peor por cada proyecto se nombra un líder de equipo que con
ellos coordino directamente toda la gestión y la ejecución de los proyectos
¿Y estas personas que lideran los proyectos están al tanto de los objetivos de la
empresa?
Hasta el 2018 sí, para el 2019 justo vamos a tener una reunión el lunes porque hemos
actualizado nuestro plan y se les va comunicar oficialmente el lunes
¿Ósea, esto se hace a través de una reunión?
Sí
¿Y a quienes invitan a la reunión?
Los líderes de los proyectos y los gerentes de las áreas que son la parte administrativa,
la parte financiera y la gerencia general
¿Y cómo evalúan si están cumpliendo los objetivos de la empresa?
Justamente, ahora; ¿cómo lo hacemos o cómo lo hacíamos?, porque ya hemos

cambiado y ya hemos tenido una reunión de trabajo del equipo el lunes para completar
nuestra nueva forma de evaluar metas
Coméntame en todo caso cómo lo hacían antes y cómo piensan hacerlo ahora
¿Cómo lo hacíamos antes, pues en el portafolio de proyectos, se generan planes d

proyecto por cada uno y los planes de proyecto tienen asociados productos u objetivos
152
o entregables del proyecto y esos entregables se miden en hitos, los hitos están
asociados a productos intermedios, entonces ahí medimos el rendimiento de objetivos
por proyecto, en base al cronograma de trabajo y en cuanto al desarrollo y la
implementación, manejamos metodologías agiles, Scrum para asociar digamos las
metas a los incrementos. Y una vez que se cumple un proyecto, está cerrado, entonces
todos se actualiza en la parte financiera y ejecución del proyecto, es decir recursos que
se utilizaron en el proyecto, personas, herramientas o servicios, todo se cierra. Como
que hay un centro de costos para cada proyecto. Ahora vamos a mantener algunas
buenas prácticas de eso, pero estamos cambiando la forma de cumplimento de metas,
porque antes hacíamos la evaluación cada tres semanas d metas de cumplimiento de
proyecto. Ahora lo vamos a hacer cada semana y tenemos ya y hemos lanzado una
nueva forma de trabajo que tiene tres eventos, que es el daily planning, todos los días
ellos planifican, el daily review, hacemos una revisión diaria, y todo eso tiene una
planificación. Está asociado a un planeador que hemos creado en físico y al final de la
semana tenemos una evaluación semanal. En este planeador se van a registrar las
tareas cumplidas, no cumplidas, los resultados esperados obtenidos en la semana, la
meta de la semana, horas de esfuerzo efectivas, horas de esfuerzo que no han sido
efectivas o han sido reemplazadas por otras tareas, todos esos indicadores, día a día
se van a registrar. Semanalmente se hace la evaluación en un repositorio y se van a
tener indicadores por día o por semana acumulados.
¿Esos son los indicadores del proyecto, y cómo los relacionan con los objetivos
de la empresa?
Ya, es que claro, los objetivos de la empresa, para nosotros, digamos a nivel macro,
objetivos generales para este año, en los objetivos generales tenemos, así en bruto es
crecer el doble, eso es lo que nos hemos propuesto este año. Después estamos
terminando el plan de acción esta semana y vamos a comunicarlo el lunes, pero la meta
es crecer el doble. Entonces ante eso tenemos objetivos específicos que van a aportar
a esa meta. Como te digo, ahí es salir al mercado global, mantener las relaciones con
los clientes que son los más importantes, generar los servicios, entonces, una vez que
se hayan cumplido las tareas por proyecto, todo esto va a sumar hacia la meta global
y el objetivo. Todo está en escala, a nivel de tareas, actividades, procesos. Proceso
engloba meta global
¿Y dentro del portafolio hay proyectos internos o todos son para clientes?
153
Si, también tenemos proyectos internos, por ejemplo, tenemos activo un proyecto
justamente en el área de QA, hemos iniciado un proyecto de mejora de los
procedimientos. Estamos asignando dos personas y en la parte administrativa hemos
tenido un proyecto interno de homologación de proveedores que ya lo hemos culminado
hace poco. Si hay proyectos internos, pero al año serán 2
¿Y proyectos internos de desarrollo?
Para nosotros, no
¿Y proyectos de desarrollo para la venta como software empaquetado o cómo

servicio?
Ahí tenemos proyectos que ya hemos desarrollado con los clientes, y algunos creemos
que pueden ser productos masivos, entonces le damos un esfuerzo adicional para
convertirlo en un producto masivo y eso ya lo lanzamos al mercado.
¿De los proyectos que realiza la empresa, cómo los consiguen?
Antes trabajábamos con el Estado y privadas, pero hace dos años ya solamente quedó
privadas, porque el Estado, bueno cambió su ley de Contratación con proveedores, ha
sido más estricto y demoraban en los pagos ósea muchos problemas con el Estado, así
que decidimos enfocarnos solamente en empresas privada. Y con esas empresas como
trabajamos. Como te dije al inicio somos más que proveedor-cliente somos socios
estratégicos. Nos hacemos socios, entonces le ofrecemos una cartera de servicios y la
confianza la vamos ganando en los proyectos a medida que vamos creando proyectos,
haciendo proyectos, vamos conociéndonos ambas partes para fortalecer nuestros
estándares, estándares de ellos, de nosotros, nuestra forma de trabajo. Se crea un nexo
de confianza y con ellos se generan. Ahorita tenemos 3 empresas que funcionan de ese
tipo para nosotros y con ellos los ayudamos a crecer y también obviamente ellos nos
dan fluidez en los proyectos. Ahora, si fuera una nueva empresa, tenemos ahí una
sesión, una persona encargada de promoción de nuestros servicios que va ofreciendo.
Nos interesa ahorita empresas medianas y grandes, porque los proyectos que queremos
son de ese tipo, entonces hay una persona encargada que se encarga de ver y ser el
nexo con ese tipo de empresas ese va con información. Es como un currículum de la
empresa que tiene todo lo que tenemos, con que empresas trabajamos, que proyectos
hemos logrado. Entonces al año también planteamos una meta de asociar al menos un
nuevo cliente de ese tipo. Ahorita tenemos esos tres que son dos grandes y una
mediana, y este año también queremos asociar una empresa grande.
154
¿Entonces tienes una persona específicamente para ventas?
Sí, hay una persona que se encarga de hacer seguimiento y eso recién lo hemos
activado hace un año más o menos, menos, 10 meses.
¿Entre las propuestas que llegan o las posibilidades que encuentran, cómo
deciden qué proyectos ejecutar?
Ah bueno, ahí, uno, determina el alcance, lo que quiere el cliente, si encaja en nuestro
perfil. Tenemos perfiles. Por ejemplo, trabajamos mucho con herramientas de Microsoft.
.Net, después tenemos otro grupo que trabaja en Java, todo lo que tecnologías es Java,
y otro grupo que trabaja con Python. Entonces si por ahí alguna empresa nos dice yo
trabajo con por ejemplo Genexus, Oracle y tengo una necesidad muy particular pues le
decimos que no. Podemos atenderlo si es que buscamos especialistas en el área y lo
tenemos, si lo podemos ofrecer. Primero vemos el perfil, el alcance, luego el tema del
tiempo, Si tiene mucho alcance y lo requiere en poco tiempo tampoco lo vamos a poder
atender porque nos va a afectar en nuestra credibilidad, porque sabemos que eso no lo
vamos a poder cumplir en tan poco tiempo y el tercer factor es el costo, el presupuesto,
En el presupuesto, nosotros asociamos no solamente desarrollo, también asociamos el
tema de pruebas, mucho testing, calidad, garantía, algo de soporte y mantenimiento que
generalmente les damos un año de soporte y mantenimiento, ósea de garantías y a todo
eso se suma el tema de impuestos, el tema de viáticos diarios en caso esté fuera de la
ciudad y generamos un presupuesto. Si ellos están de acuerdo van a tener un producto
que finalmente satisface sus necesidades y vamos. Si les parece mucho eso y ya no
llegamos a una negociación a un nivel, tampoco, la desechamos.
¿Y quiénes participan en ese proceso? ¿En esa decisión?
En la parte de alcance, con los líderes de proyecto, ósea junto conmigo, los líderes de
proyecto y la parte de tiempos también con ellos, hasta el equipo entra n veces. Porque
decimos tenemos este proyecto, hay que dimensionarlo, entonces el tema de alcance y
tiempos con ello y el tema de presupuesto con el área de finanzas y con el área de
portafolio de proyectos.
¿Ese proceso de evaluación queda documentado en algún sitio o solamente se

hace?
Sí, tenemos una ficha en Excel y vamos llenando cosas así muy rápidas. No es
detallado, pero si funciona así.
¿Hay proyectos que deciden no hacer entonces?
155
Sí, por lo que te comento, por el tema de alcance, tiempo o costo.
¿Hay alguna otra razón, por la que decidan no hacer un proyecto?
Tal vez temas de regulación, o más con el Estado, cuando necesitan algo que tiene que
ver con mucho tema burocrático. No nos gusta eso, porque nosotros mantenemos un
esquema de pagos puntuales, todo en orden, entonces trabajar con empresas que no
nos dan garantía, o que van a demorar 3 meses en pagar o atender. Evaluamos también
ese aspecto. Quién es la empresa, si tiene la capacidad de trabajar bien con nosotros,
sino también lo podemos desechar. Obviamente son empresas legales y constituidas,
porque una vez tuvimos de una empresa que no era legal, prestaba dinero y quería
hacer un software y le decimos ¿facturado? NO, ¿quieres recibo? Tampoco. Bueno el
pago es en cuenta corriente. No, tampoco lo puedo hacer, el pago es en efectivo y no
nos dio confianza y lo desechamos.
¿Y la empresa ha realizado proyectos de innovación en los últimos años?
Si
¿Qué tipo de proyectos?
Sobre todo, hemos participado con Innovate Perú. Hemos participado en dos proyectos,
pero asociado a Universidades. Nosotros con una Universidad Privada aquí en
Arequipa, la UCSM, hemos hecho asociados con ellos, la idea del proyecto, todo eso la
generamos nosotros como empresa, y la universidad solamente participó como un
medio más de apoyo en el proceso de investigación, tesis, investigadores. Hemos hecho
dos proyectos de ese tipo. Uno con Fincyt y otro con Innovate Perú y hemos participado
en un tercero colaborando con otra empresa para un proyecto.
¿De qué trataban los proyectos?
El primero con Fincyt fue un proyecto en el sector salud, se creó una plataforma e-
Marketplace para la comercialización de medicamentos, ahí también estuvo metido un
poco DIGEMID. No directamente involucrado, pero sí. El segundo proyecto fue con
Innovate Perú. Era un proyecto de asistencia remota para pacientes con enfermedades
crónicas que creamos, era una plataforma como una central médica virtual. Ahí también
intervino la Universidad y el Sector Salud y el tercero colaboramos con otra empresa,
aquí en Arequipa, para un proyecto de geolocalización de buses para una empresa de
transporte.
¿Y qué porcentaje de recursos de la empresa se asocian a estos proyectos de

innovación?
156
Más o menos el 20%, 20 a 25 %. Actualmente no tenemos, ya desde hace casi 2 años
no hemos participado. Nos hemos avocado mucho al tema de proyectos de lo que te
comenté, pero este año si queremos postular a otras ventanas abiertas en Innovate.
Este año si vamos a participar, bueno ya depende, si es que nos aprueban el proyecto.
¿Y en esa línea que tan importante es la innovación para la empresa?
Es importante. Ahora en la innovación, nosotros tenemos claro que así hagamos clientes
para un solo cliente, ese proyecto debe ser innovador. Debe tener características de
innovación, porque si el retorno de inversión es más corto y les genera a ellos mucho
valor genera más confianza para nosotros, de ellos hacia nosotros. Estamos planteando
productos que no solo les sirvan, sino que son innovadores y que aportan a su negocio.
Entonces la innovación la vemos siempre en todos los proyectos que trabajamos.
Al momento que deciden iniciar los proyectos, mencionaste que se tomaba en

cuenta el alcance, el tiempo y el costo ¿se toma en cuenta de alguna manera los
riesgos que implica el proyecto?
Si claro, si analizamos los riesgos, claro que no lo documentamos, simplemente los

analizamos como se dice a ojo de buen cubero, por experiencia. Ya cuando inicia el
proyecto, ahí recién creamos una ficha de riesgos más detallado.
¿Y qué tipo de riesgos suelen considerar al inicio, para decidir iniciar?
Uno, los riesgos asociados al cumplimiento del proyecto, que no solamente somos
nosotros, sino queremos ver si la otra empresa cliente, está también en la capacidad de
estar alineada con nosotros. Entonces analizamos un poco la empresa, por ejemplo si
es una empresa seria, cuál es su mercado, con que clientes trabaja, número de
trabajadores, si está en la capacidad financiera para aportar en su proyecto, si está
legalmente constituida, analizamos también la gente con la que trabaja en el área
usuaria, un poco los entrevistamos, hacemos un diagnóstico rápido de los stakeholders,
quién está liderando por ejemplo el área de TI, si lo conocemos o no, qué respaldo
tiene, qué fortalezas, la gente. Y una vez que vemos que eso está bien, todo está bien,
si el proyecto que están esperando es realmente un proyecto de interés para la
organización o es algo que se le ocurrió a una sola persona y que va a ver si es que
funciona o no. Entonces ahí se van viendo riesgos en todos lados.
¿Y dirías que todos tus proyectos se alinean con el objetivo de la empresa o

alguno se aleja un poco?
157
Claro, todos los proyectos que aceptamos sí. Lo que pasa es que nuestros proyectos
siempre nos generan para nosotros un crecimiento, porque están asociados a
capacitaciones, están asociados a comprar equipos, está asociado tal vez a aprender
nuevas tecnologías con capacitaciones o hasta obligarnos a usar un estándar para bien.
Un estándar nuevo en temas de integración, en temas de desarrollo, ósea aporta.
Siempre dejan un aporte. Activos también dejan. Entonces todo eso se alinea con el
objetivo porque nos presiona a crecer.
¿Y estas personas responsables de decidir qué proyectos se hacen, que entiendo

eres tú con los líderes, qué perfil o que conocimientos y experiencia tienen?
Primero tienen que tener más de 1200 horas de vuelo que le llamamos, horas en
proyectos. Tiene que haber tenido experiencia, con nosotros o fuera, pero más que nada
con nosotros, Más de 2 años y también tienen capacidad de decisión. Entonces, ese es
un factor importante
Y en cuanto a la gestión de los proyectos, habías mencionado que trabajan con

Scrum
Si
¿Scrum, tal cual, agregan herramientas adicionales, está mezclado con algo de
tradicional?
Adaptado, hemos hecho una adaptación de Scrum, a ver, agregamos herramientas

propias o agregamos al proceso eventos que creemos también que funciona más ágil.
La hemos adaptado y ahora hemos hecho otro cambio que es lo que te comentaba, que
es la planificación de tareas, una división por metas que va a estar asociada también a
esta forma de trabajo y mucho es la comunicación con el cliente, con los usuarios.
Mucho trabajamos con ellos, sea presencial o remoto, los involucramos mucho en los
proyectos. También fortalecemos mucho que el equipo tenga mucha capacidad de
comunicación, mucha capacidad de negociación, de análisis. Entonces todos esos
factores nos llevan a que también los proyectos sean exitosos, no solamente por el
conocimiento técnico.
¿Y este proceso de gestión está documentado, todos lo conocen?
Sí, tenemos unas diapositivas, pero justamente ahora, con todo este cambio que
estamos haciendo, con esta meta que nos hemos planteado de crecer el doble estamos
estandarizando una serie de documentos de desarrollo y tenemos que hacer esto. Crear
el procedimiento formal más detallado de nuestra forma de trabajo
158
¿Y hace cuánto tiempo trabajan con Scrum?
Ya 5 años, más o menos
¿Y sus proyectos cuanto tiempo suelen demorar?
En promedio 6 meses, mínimo son 3 meses para un proyecto, mínimo y bueno ya el

máximo que hemos tenido para un proyecto es 15 meses, pero en promedio son 6
meses.
¿Y usan alguna herramienta informática para llevar la gestión del proyecto?
Sí, trello.
¿Cómo gestionan el alcance en los proyectos?
Primero el proyecto lo dividimos en módulos, o subsistemas, a esos módulos se les

asocia requerimientos funcionales. Ósea hay un catálogo de RFs que ya está
previamente identificado con el cliente y por cada módulo se asocian cuantos RFs tiene.
Hay Rfs que son transversales, ósea, están en todos los módulos, por ejemplo, la parte
administrativa de un proyecto. Entonces, a cada RF, en algunos casos se crean casos
de uso y en otros casos se crean historias de usuario y se van generando o se van
tomando de acuerdo a la prioridad del plan de proyecto, se van implementando.
Entonces se evalúa el cumplimiento. El área de QA se encarga del cumplimiento
justamente de alcance, en términos de que el producto esté terminado correctamente
con los Rfs identificados, los módulos, que esté probado, que esté validado, y ya listo
para puesta en producción. Entonces ahí tenemos un área de QA
¿Y esta área de QA, cuántas personas tiene?
Ahorita son 4.
¿De los 20 más o menos que me comentaste que era la empresa?
Sí, por cada proyecto, se asigna una persona de QA. Ese es más o menos el esfuerzo.
¿y cuándo hay cambios en el proyecto como los gestionan?
Con una solicitud de cambio. El plan de proyecto tiene varios formatos. Uno de ellos es
el formato de solicitud de cambios
¿el cronograma cómo lo gestionan, cómo lo estiman para empezar?
El cronograma, tenemos un cronograma por el proyecto que es en base a actividades,

pueden ser semanales y se va tomando en base a la prioridad de la planificación, por
ejemplo, hemos estimado desarrollar 5 módulos para un proyecto en 8 meses y tenemos
159
prioridades Módulo A, Módulo B, etc. Entonces a medida que se van sacando los
módulos se va estimando. El módulo tiene una estimación general que se ha hecho ya
por el cliente y digamos el Módulo A va a demorar un mes y medio, que tiene asociados
los requerimientos funcionales, pero a medida que yo voy trabajando semana a semana
se crean tareas y ellos vana estimando el número de horas por tarea para el
cumplimiento de ese módulo.
¿Cuándo dices ellos a quienes te refieres?
El equipo, el líder del equipo con el equipo
¿Y el presupuesto cómo se gestiona en los proyectos?
Igual, el presupuesto tiene un presupuesto global aprobado inicialmente con el cliente,

el cual está refrendado en el contrato. Entonces por cada hito que se entrega. El hito
puede tener 1,2 o 3 productos intermedios. A la aprobación o entrega de eso, se hace
la facturación. Entonces por hitos definimos una factura y ¿quién controla eso? El área
de finanzas y en este caso mi cargo que es como Director de Proyectos voy controlando
que la proporción sea correcta en presupuesto, recursos,
¿Y considerando que los pagos no son mensuales, sino por los entregables, cómo
garantizan tener la suficiente sostenibilidad para pagar a los recursos?
Porque tenemos una bolsa de liquidez en nuestra cuenta. Entonces, los proyectos, no
quiere decir que dependamos de un proyecto exclusivamente. Si los proyectos se van
culminando los hitos van generando. Ósea cada pago se divide en centro de costos. Un
costo es para impuestos, otro para temas de equipos, otro para pago de personal, pago
de seguros y la utilidad se va quedando en la cuenta y siempre tenemos esa fluidez.
¿Qué prácticas de aseguramiento o control de calidad se suelen aplicar en los

proyectos? Habías comentado que el área de QA verifica el alcance.
Sí verifica el alcance y también que el producto esté completo. Ósea que haya un
cumplimiento a satisfacción del cliente, porque el área de QA trabaja por ejemplo mucho
con los usuarios líderes y el usuario final porque ellos no solamente hacen pruebas
internas, sino también están involucrados para hacer pruebas externas con el cliente.
Entonces una vez que tenemos la aceptación con acta y todo recién sale a producción
y luego tenemos un acompañamiento de soporte y mantenimiento con el cliente ante
cualquier inconveniente.
¿Y ya durante el proyecto cómo se gestionan los riesgos?
160
Mantenemos una hoja de riesgos, un Excel y ahí se van actualizando.
¿Quién lo actualiza?
Los líderes de equipo con mi persona, esa actualización la hacemos cada 4 semanas.
Normalmente nuestros clientes nos solicitan un informe de avance cada mes, entonces
antes de reportar ese informe de avance, revisamos los riesgos y también reportamos
si se han activado los riesgos, o cómo van una vez al mes
Y me habías dicho que por cada proyecto tenías ciertos indicadores. ¿Cómo se
hace seguimiento de esos indicadores? ¿Cómo los reportan los líderes?
Por el módulo, ósea, tenemos indicadores de QA y de desarrollo. Entonces en desarrollo

tenemos indicadores de número de Rfs implementados, número de módulos en
desarrollo o implementados. En QA tenemos el número de pruebas, la cobertura de
pruebas que se han aplicado a un módulo, una matriz de trazabilidad de requerimientos
vs pruebas o pruebas vs casos de uso, cumplimiento de aceptación, y algunos otros
indicadores que usamos para algunos proyectos como por ejemplo evaluar la
complejidad ciclomática de un módulo, si el código está muy engorroso se hace una
actualización. También hay algunas herramientas que utilizamos que proporcionan esos
indicadores o métricas, el uso de buenas prácticas de programación, la revisión por
pares de uno a otro desarrollador. Esos indicadores los tenemos A nivel del proyecto,
se hace una evaluación por hitos digamos.
¿Y hay entonces una lista centralizada donde están todos los proyectos y estos
indicadores?
Sí, pero no es público, ósea lo manejamos internamente con el área de …, ósea no es

público para toda la empresa.
¿y esta lista en qué se almacena?
Es un repositorio en Google Drive donde tenemos ahí indicadores de gestión.
¿Es un spreadsheet de Google entonces?
Sí
¿Y los empleados saben cómo el proyecto aporta a los objetivos de la empresa?

Los desarrolladores en este caso
Los antiguos, es que los nuevos, ahora también estamos corrigiendo eso. Los que son
recientes, tenemos gente que ha ingresado hace dos meses o gente que recién ha
161
ingresado este año, todavía no están alineados, pero los que ya tienen más de un año
sí.
¿Y cómo defines entonces éxito en tus proyectos?
Si cumplimos los resultados que nos planteamos en el proyecto. Digamos, que un

resultado para nosotros es un producto, puede ser intermedio o el producto final.
Entonces decíamos que teníamos un proyecto con 8 productos intermedios y que la
sumatoria de esos productos nos da el producto final y que lo estén usando. Ese es un
proyecto exitoso. Una vez que entregamos el producto, al mes, dos meses lo están
usando al 100% todos los módulos o todos los productos intermedios. Ese es un
proyecto exitoso.
¿Y qué porcentaje de proyectos termina con éxito entonces?
90%. Estamos muy alineados con el tema de calidad. Bueno, como ya sabrás con
Abraham venimos trabajando con eso, hace como 8 años y sería algo tonto que yo no
aplique eso a la empresa. Y mucho, mucho nos enfocamos en temas de calidad.
Tenemos la certificación y vamos a seguir trabajando, armando productos de mejora y
cada año tenemos más y más desafíos y vamos a seguir trabajando con respecto a eso.
Yo diría que ahorita estamos en un 90%. Hace 5 años quizás estaríamos en un 50 o 60
de éxito.
¿Y qué porcentaje de proyectos termina retrasado entonces?
Ahí si el porcentaje es menor. De lo planificado… es que el retraso no es responsabilidad

directa de nosotros. Puede ser compartida, pero al final hay un retraso. Entonces más
o menos será el 30% de los proyectos. Ósea de 10 proyectos, 3 o 4 terminan retrasados.
¿Cuánto se atrasan usualmente? ¿Cuánto es lo máximo que se puede atrasar un

proyecto?
Será un 20% del tiempo, 25%, pero como te digo eso no es directamente nuestra culpa
en la mayoría de los casos, porque es compartida por el tema de que un usuario viajó,
que le cambiaron las reglas, o tal vez hubo muchas solicitudes de cambio que originaron
que el proyecto se alargue. Eso está previamente aprobado. Igual generó un
aplazamiento.
¿Hay proyectos que se cancelan una vez iniciados?
No, hasta ahorita no hemos tenido. Bueno uno sí hace… Si hemos tenido un caso así
hace 3, tres años y medio.
162
¿Qué ocurrió en ese escenario?
Que el cliente ya no pudo… ya no tenía presupuesto para seguir. Es porque no hicimos

correctamente el análisis de riesgos de lo que te comenté al inicio (empresa seria, todo
eso). Entonces nos pagó solamente un entregable y ya no tuvo más y ya tuvo que
cancelar.
¿Cuál es la tasa de errores reportados después de la entrega del proyecto?
También ha bajado drásticamente. El área de QA la hemos creado hace más o menos

un año y dos meses. Actualmente con el área de QA, esa tasa ha bajado a menos del
10% o el 10$ digamos. En cuanto a reportes de errores. El número no te puedo decir
porque para cada proyecto es distinto, pero digamos el nivel de aceptación es del 90%
y un 10% que se va cubriendo ya en el uso, afinamiento y ya hasta que ya fluye. A los
dos, tres meses ya está. No tenemos ningún reporte de nada. Antes de esa área de QA,
antes de que la creemos, teníamos más o menos un 30%. Ósea que digamos se lanzaba
algo y nos reportaban errores sobre todo nos reportaban mucho el tema de seguimiento
de la validación, aceptación.
¿Hace cuánto tiempo que tienen el área de QA?
Exactamente un año y tres meses.
Cuando respondiste la encuesta, en el punto que dice la empresa lleva un registro

del portafolio de proyectos en ejecución lo marcaste como 3 de 7. Me comentas
que hay un registro que está en Google Drive, en un spreadsheet que tiene el
registro del portafolio. ¿Por qué consideras que la empresa no está fuerte en ese
aspecto de llevar el registro?
Porque cuando hablas de portafolio yo me refiero a todo el conjunto de proyectos, que

yo tenga que sacar estadísticas, el comparativo entre uno y otro proyecto, y no lo
tenemos. Ahorita tenemos por proyecto y todavía eso es algo muy, como te digo, muy
simple que manejamos. Eso sí queremos fortalecer todo eso.
En el caso de si al momento de decidir realizar un proyecto se toma en cuenta

criterios definidos, mencionabas que tomaban en cuenta el alcance, el tiempo y el
costo principalmente y era también uno de los que más bajos marcabas en la
encuesta. ¿Esto por qué? ¿Qué otra cosa te gustaría evaluar en ese sentido para
que ese número suba en todo caso?
Ahí no sé porque le puse tres, porque sería un poquito más, 6, pero que otros factores
nos gustaría. Nos gustaría saber... Mira, ahorita estamos en una etapa nosotros en la
163
empresa en que creemos, bueno esto siempre se ha sabido, pero ahora le damos más
énfasis, de que las personas son las que determinan el éxito del proyecto. Entonces nos
gustaría saber por ejemplo todo el perfil de cada usuario que va a intervenir en el
proyecto del lado del cliente. Nos gustaría, si tenemos una ficha de cada persona sería
excelente. Después que el conocimiento que nos brinden sea el correcto para poder
armar todo el tema de requisitos. Porque a veces una persona dice una cosa, luego otra
persona la cambia. Mucha vuelta y muchas iteraciones para llegar a la verdad. Todo eso
nos aportaría mucho en la definición de criterios.
¿Y qué tanto valor crees que daría eso para la empresa?
Bastante, para la empresa, para el cliente bastante, porque van a tener un producto que
realmente necesitan, que va a generar un valor agregado y que no están creando un
producto simplemente para paliar algo temporal. Nuestra filosofía es crear productos
con un ciclo de vida de 5 años. Eso quiere decir que, en 5 años, ósea lo que te hemos
creado lo usas, le sacas el jugo te retorna la inversión y luego como ese producto es
bueno, queremos que sea bueno, vamos a hacer querer la versión 2, y así vamos a
querer la versión 3. Entonces el tiempo de vida de uso queremos que sea larga vida,
pero el ciclo es de 5 años, que es lo que queremos crear. Entonces mucho aportaría
esa información.
¿De los elementos de gestión de gestión de portafolio listados cuáles crees que
generan mayor valor a la empresa, independientemente que no se hagan según
un modelo específico?
El seguimiento del portafolio, el monitoreo, eso creo que nos generaría mucho valor. No
lo estamos haciendo ahorita como quisiéramos y la selección que tendría que ser mucho
más fina.
¿Y qué tanto valor les da a tus proyectos la metodología de gestión basada en

Scrum que usan actualmente?
Sí, mucho valor porque ya todos estamos acostumbrados a un trabajo de ese tipo y no
hemos tenido resistencia. Siempre estamos obviamente escuchando a las personas
como seguir mejorando, porque tampoco es nuestra filosofía imponer algo que no
quieres usarlo o no te sientes bien. Si estas usando algo es porque si te va a generar
productividad lo que haces. Siempre estamos evaluando eso.
Y finalmente, en toda esta línea de temas de gestión, que de una u otra forma,
algunas prácticas se aplican dentro de la mayoría de empresas de una forma
164
rudimentaria, en algunas de una forma más formal que en otras. ¿Qué es lo que
tú crees que les serviría más para crecer?
Me parece que, ya apuntando a la escala global, a clientes globales, tener un sistema

automatizado o alguna metodología automatizada para gestión de proyectos globales.
Ya no solo trabajamos local, sino globalmente cómo sería.
¿Y qué consideras que le falta todavía a la empresa reforzar más para llegar a esos
objetivos de proyectos globales?
Apertura un cliente, para tener práctica. Estamos ahorita en la búsqueda de tener

clientes a otra escala. Estamos ahorita con los contactos. Estamos entrando con los
contactos primero. Entonces la meta para este año es tener 2.
De tus respuestas de la última parte de la encuesta, rendimiento de la empresa,

casi todo está entre 5 y 6, lo que implica una buena percepción de tu parte acerca
del rendimiento de la empresa. Eso incluye la parte financiera, la parte de empleo,
y la comparación con la competencia y tus expectativas como gerente de la
empresa y como socio.
Así es, esa es la expectativa que tenemos, pero sí seguir en esa senda del crecimiento
por que la meta es ahorita alta para nosotros que nos hemos propuesto. Estamos
haciendo cambios de la cultura organizacional. Estamos implementando más
actividades que apoyen el desarrollo personal y también operativo.
¿Aproximadamente cuánto han crecido en ventas en los últimos años?
El crecimiento ha sido más o menos progresivo un 30% anual
¿y en lo que a empleo se refiere, cómo ha sido el crecimiento?
Directamente trabajamos con 20 personas actualmente, pero también tenemos

consultores, tenemos gente que nos apoya externamente. Entonces ha ido creciendo.
No tanto como 30% será un 10%. La meta para este año es también crecer en recursos
el doble. Es decir, tener al final de este año un equipo de 40 personas por lo menos.
¿Y en comparación con tu competencia por qué consideras que han tenido un

buen año o en que te basas para decir eso?
Por lo números que tenemos actualmente, pero con mi competencia no sé. La

competencia no sé cómo les ha ido a ellos, pero lo que yo te digo es de los números
que tenemos internamente.
165
¿pero tienen información al menos general del mercado como para saber cómo
están el resto de las empresas?
Sí conocemos quienes son las empresas del rubro que están en este sector, en
Arequipa, Lima también. Sabemos algunas cosas que están haciendo ellos, pero creo
que su mercado es distinto. Por ejemplo, hay empresas de Fintech. Nosotros no
trabajamos con eso. Hay empresas que trabajan con Minas, empresas mineras,
empresas que ofrecen productos más de productos masivos, entonces de otro tipo. Creo
que el mercado es abierto. Hay distintas oportunidades.
166
¿Qué tipos de proyectos realiza La empresa?
Mira, La empresa nace como una consecución de la empresa en que laboraba

anteriormente, porque tú me conociste creo cuando yo estaba en otra empresa. Esta
cerró sus oficinas en Perú y en Bulgaria y yo adquirí algunos clientes de ellos. Formé La
empresa y adquirí algunos clientes. Entonces desarrollamos lo que La empresa anterior
venía haciendo, lo que es un poco de desarrollo de software a medida o boutique de
software, y también estamos por implementar soluciones propias de La empresa.
Soluciones que tengan que ver con desarrollo de aplicaciones móviles, Internet de las
Cosas. Aquí en el Cluster está bastante movido el tema de Inteligencia Artificial,
entonces también estamos tratando de participar en algunos proyectos que tengan que
ver con Inteligencia artificial y esas son básicamente dos de las tres líneas que tenemos
en La empresa. En La empresa, un lado está el tema de consultoría, el tema de
consultoría, apoyo a la adopción de metodologías ágiles, transformación digital. El otro
lado es el desarrollo de soluciones propias, el otro es el de software a medida. Son las
tres líneas que tenemos.
¿Cuál es el que más influye en la facturación?
Ahora, bueno recién está. La empresa como tal existe desde mayo del año pasado, así
que hemos nacido con clientes en temas de desarrollo de software, que tenemos
clientes en Australia que desde la empresa anterior los venimos atendiendo hace ya
cuatro años y medio, casi cinco. Entonces ellos siguen con nosotros, haciendo
desarrollo a medida y este año vamos a presentarnos a Innovate para hacer dos
proyectos. Dos soluciones.
¿Y cuántos proyectos manejan al mismo tiempo?
En estos momentos estamos en 3 proyectos al mismo tiempo.
¿Y cuáles son los objetivos de negocio? ¿Cuáles son los objetivos de la empresa?
¿Están definidos?
Los objetivos de la empresa... La empresa si nació con la idea de no centrarnos

solamente en desarrollo de software en proyectos, nuestro objetivo a muy corto plazo
es tener soluciones que nos permitan generar, tener una presencia en el mercado,
porque como desarrollo de software, desarrollo de software se está volviendo un
comodity. Entonces hay muchas empresas peruanas, extranjeras acá en el Lima que
hacen desarrollo de software. Entonces competir en un mercado en que hay mucha
167
competencia, en un mercado rojo no es lo más adecuado, pues queremos irnos por el
lado de tener soluciones propias, pero como tenemos también un expertise en lo que es
agilidad, en temas de metodologías ágiles, prácticas ágiles, en empresas del extranjero
más que nada, también el lado de la consultoría es uno de los objetivos que queremos
aplicar. Llevar todo este conocimiento que tenemos a temas de asesoría técnica y
consultoría
¿Y esos objetivos están escritos en alguna parte?
No, Los tenemos un poco alineados. No están formalizados como un plan estratégico.
No lo tenemos así tan formalizado, pero sí los tenemos claros.
¿Y quienes en la empresa conocen esos objetivos?
En la empresa la conoce... lo conozco yo que soy el gerente general, lo conoce uno de

los empleados con el que trabajo hace tiempo, Remmy Ticona y lo conoce mi esposa
que es como mi socia, aunque no está como accionista, porque por temas legales no
podía ser accionista, pero sí con ella es que estamos empujando este barco.
¿Y a los empleados se les comunica los objetivos?
No, no se les ha comunicado porque no hemos implementado todavía, más que solo
desarrollo de software. Como hemos seguido con el tema de desarrollo de software,
ellos han continuado prácticamente algunos de los proyectos que teníamos antes y los
nuevos proyectos se han mantenido en la misma línea. Pero apenas comencemos con
este proyecto de implementación del.… de lanzarnos ya a Innovate, ya obviamente
tenemos que transmitir estos objetivos y explicar el por qué vamos a hacer eso.
¿Cómo evalúas si has cumplido tus objetivos como empresa entonces?
Nosotros llevamos básicamente la métrica de cuanto número de proyectos se han

hecho, en cada uno de estos 3 cuadrantes que tenemos. Bueno el año pasado como te
menciono todo ha sido de desarrollo de software a medida, entonces obviamente no
había nada en los otros dos cuadrantes y en base a eso, en este tercer cuadrante
teníamos planeado cerrar, con los proyectos que tenemos en progreso, no teníamos
planeado aumentar más proyectos, porque nuestro grupo de trabajo es pequeño, sin
embargo, si se inició las conversaciones para empezar este año con dos más.
Me dices que hay la idea de presentarse a los fondos de Innovate para los
proyectos. ¿Actualmente hay proyectos internos en desarrollo o se espera el tema
de financiamiento?
168
Actualmente lo que hemos hecho es… hemos hecho el análisis de las soluciones,
hemos ya definido nuestros requerimientos, hemos definido un alcance inicial, pero no
hemos pasado más allá porque esperamos lanzarlo y una vez que tenemos el
financiamiento comenzar a implementarlo. Como son dos soluciones que no tienen nada
que ver una con la otra, hemos tenido unas sesiones de ¿cómo se llama? reléase
planning. Tratar de definir un roadmap para estas dos soluciones
¿De qué tratan las soluciones?
Una es sobre tema inmobiliario y la otra es sobre tema educativo.
Me comentabas que los proyectos que se han estado desarrollando más que nada
vienen de los clientes que tenías de antes. ¿En general cómo consigue proyectos
la empresa?
Es una buena pregunta, nosotros… y esa es una de las razones por las que ingresé al
clúster, bueno empujé el clúster, porque somos uno de los socios fundadores. La
empresa es una empresa muy pequeña y no tiene una estrategia de marketing. Que es
difícil también en empresa de desarrollo de software tener una estrategia de marketing.
Entonces lo que buscamos es la colaboración con otras empresas que forman también
parte del clúster. Entonces a través de las otras empresas es que hemos estado
consiguiendo los proyectos, ya tenemos un cierto prestigio de ser una de las empresas
que trabajan con metodologías ágiles y ya hemos tenido varios proyectos con empresas
del clúster en donde hemos trabajado con metodologías ágiles de manera exitosa.
Entonces eso nos da cierto renombre, acá internamente en el clúster, y cuando hay
algo, siempre nos están buscando o para asesorarlos, ver si trabajamos juntos, en
algunos casos si hemos trabajado juntos, en algunos no, pero esa es la forma que
actualmente tenemos para poder interrelacionarnos con el clúster.
¿Y en ese proceso quién participa por La empresa?
Yo, en ese proceso yo. Así es, porque, las otras personas que trabajan conmigo trabajan
remoto.
¿y en caso de proyectos internos, de dónde surgen las ideas?
Una surgió de un colega mío, de un amigo mío del colegio de mi hija, el tema
inmobiliario, que él es contador. Entonces el me dio una idea. Él sabe que yo desarrollo
software, entonces nos reunimos y vimos que podía ser una solución interesante. El
tema educativo si salió con un tema de mi esposa, una necesidad que nosotros hemos
identificado en nuestra experiencia como padres y queremos darle una solución.
169
¿Y dentro de las posibilidades de proyectos que tienen, cómo se decide qué
proyectos ejecutar?
Bueno, no somos una empresa grande, así que básicamente es una priorización en
función de las capacidades que tengamos, capacidades operativas. Si tenemos gente,
si podemos conseguir gente, el proyecto va, obviamente si el proyecto se considera
rentable también. Que va a generar alguna rentabilidad. Eso es con el tema de software
básicamente, porque en el tema de soluciones como verás eso va a ser una inversión,
y eso se espera pues que me dé una rentabilidad en unos años, un año, dos años.
¿Y hay casos en que ha dicho que el proyecto no va?
Sí, hemos tenido algunos escenarios en donde, más que nada ha sido por un tema
burocrático más que nada. Vemos que el proyecto quizás participa otras empresas, y
vemos que hay mucho tema burocrático que hace que el proyecto quizás no avance a
la rapidez que uno desearía. Entonces nosotros mejor decimos Te apoyo, pero no puedo
participar, porque tengo otro… es un costo de oportunidad... tengo un costo de
oportunidad quizás en otro proyecto donde sí puedo avanzar mucho más rápido,
entonces decido no a este y avanzar por otro.
¿Quién decide qué proyectos hacer entonces?
Yo
¿Directamente?
Así es
Además de la capacidad y de la rentabilidad del proyecto. ¿Hay algún otro criterio

que te parece tomas en cuenta para tomar la decisión del proyecto?
Para el tema de las soluciones… Para el tema de los proyectos de software, mucho
depende del cliente. Ahí no hay mucho… Si el cliente quiere, nosotros podemos
asesorar, podemos hacer algunas conversiones, pero al final es más una decisión del
cliente. En el caso de soluciones. Tú tienes más independencia cuando haces una
solución propia, entonces, en este tema de las soluciones, si nos interesa, como te
comenté solucionar un problema que es repetitivo en el sistema educativo y queremos
de esa forma que además de que la solución sea rentable para la empresa, la empresa
también… ayudar un poco a la sociedad.
Las propuestas de proyectos que no se llegan a hacer. ¿Quedan registradas en

alguna parte?
170
Sí, nosotros usamos HubSpot como CRM. Ahí estamos registrando todas nuestras
iniciativas, y además de eso cuando hacemos alguna estimación o algo, usamos una
herramienta Kanbanize, donde también, bueno ahí queda registrado todo el roadmap.,
entonces si al final no se llega a implementar igual está ahí.
Fuera de los dos proyectos que están por salir. Mejor dicho, ¿esos dos proyectos
serían los primeros proyectos de innovación que ha hecho la empresa?
Propios de la empresa, como empresa. Así es.
¿Qué tan importante es la innovación para la empresa?
Mucho, nosotros, justo nuestro nombre es porque creemos bastante en la innovación,

pero no solo en la innovación por el lado de las tecnologías, sino en la innovación por el
lado de cultura, de procesos, el tema esto de haber tenido experiencias en metodologías
ágiles no solo en desarrollo de software, sino también en otras industrias. Que yo
también tuve la experiencia de aplicarlo en la minería y en Europa, en Francia en temas
de retail. Entonces como que te da la visión de que en realidad no es software todo,
entonces es un tema de cultura, de personas, de procesos, y ese laso es el que
queremos apuntar por el lado de la línea de consultoría y asesoría técnica y por eso
creemos que no solo es cuestión de desarrollar software. Queremos comenzar a innovar
con soluciones que podamos después usar nuevas tecnologías, mejorar ciertos
procesos, solucionar problemas.
Y teniendo en cuenta que cuando te presentas a un fondo, igual hay un aporte

monetario que tiene que hacer la empresa. ¿Qué porcentaje de recursos de la
empresa lo van a destinar a innovación entonces?
Bueno, va a depender del... Porcentaje en el caso de … por ejemplo este caso de la

innovación inmobiliaria va a ser cofinanciado con mi socio. Entonces un porcentaje de
la empresa va a tener que ir para allá. En la otra que, si es propia de la empresa con mi
esposa, yo creo que vamos a tener que invertir un gran porcentaje de lo que tengamos
en La empresa, porque queremos apostar por eso.
¿Cuánto es un gran porcentaje?
Yo no sé, más del 50% probablemente. Porque para comenzar hasta donde tengo
conocimiento, lo del aporte monetario que da Innovate depende el del tipo de proyecto,
pero es 50, 70% no? Ósea mínimo es 30% lo que uno tiene que poner, máximo es el
50%.
171
¿Al momento de que inician un proyecto, o están por iniciarlo se analizan los
riesgos del proyecto?
Sí, si analizamos los riesgos
¿Cómo lo hacen?
Lo hacemos de una manera un poco empírica, a través de conversaciones con los

involucrados, y después analizamos en el equipo los riesgos técnicos que podría haber
y por otro lado están los riesgos del negocio. Ósea los riesgos de negocio y los factores
expertos que pueden impactar en el proyecto. Tenemos un proyecto que estoy haciendo
con otra empresa aquí del clúster que involucra empresa grande como telefónica y
donde los riesgos son bastante grandes por temas de burocracia. Entonces siempre
estamos revisando los riesgos cada cierto tiempo.
Analizamos primero el riesgo de factibilidad de un proyecto, ósea que tan factible es que
el cliente lo implemente, lo quiera, que nos brinde la información que necesitamos, que
los terceros que participan en el proyecto también estén involucrados a tiempo, de tal
forma que toda la información que se requiere para la implementación del proyecto esté
más o menos controlada y después es el riesgo técnico. Si se tiene acceso a las
tecnologías, a los servidores, a lo que se necesite.
¿La tecnología o el lenguaje de programación es una limitante para la selección

de proyectos?
Mira, la única limitante creo yo por mi experiencia que vengo trabajando. He trabajado
como 10 años en temas de Microsoft es que prefiero no trabajar con Microsoft por los
costos de licencia. Prefiero trabajar con tecnologías más abiertas y que hay bastantes.
Hemos proyectos con diferentes tecnologías, java, php, node.js. Entonces como que
además me da más apertura. No me amarro a una tecnología.
¿Dirías que todos los proyectos que hace la empresa están alineados con el objetivo
generar de la empresa, lo que esperas para tu empresa?
Bueno, como te digo de esas 3 líneas que tengo, ósea si hago un mapa, ahorita un
radar, bastante peso tiene el de software. Cuando comience con estas dos soluciones
si creo que van a tener mucho más alineamiento con nuestros objetivos. Ahorita en
desarrollo de software a medida es básicamente lo que quiere el cliente y los vas
implementando. Pero por más que nosotros llegamos a involucrarnos bastante en el
proyecto, finalmente el proyecto no es nuestro. Ósea siempre va a ser de un tercero.
172
¿Hay algún proyecto que sea solo por facturación, pero que sientas que no aporta a la
empresa?
Ahorita no. Ahorita sí todos los proyectos nos aportan a la empresa por una razón
fundamental, como por ejemplo en este caso con el cliente australiano. Como ya
trabajamos varios años con ellos nos permiten utilizar tecnologías que probablemente
no conocemos y nos dan un periodo de aprendizaje, entonces si aportan porque nos
permiten aprender e implementar lo aprendido en el camino. Entonces eso si es un valor.
¿y entonces que conocimientos y experiencia tienen las personas que eligen los
proyectos, ósea tú?
Si, ahorita yo. ¿Qué conocimientos? ¿En qué sentido?
Cuantos años de experiencia tienes trabajando en software, o en gestión
Ya, bueno, yo tengo 19 años de experiencia en software desde que egresé como
bachiller en ciencias de la computación de Trujillo, de la Universidad Nacional de Trujillo,
pero tengo mi MBA. Bueno en proyectos estoy desde el 2006 como gestión de
proyectos. Me metí bastante en el tema de gestión de proyectos. Primero con PMI, de
ahí en el 2007 me moví al mundo agile y me quedé por ahí y después tengo mi maestría
en ESAN, MBA, una maestría en Francia que, si me ha permitido no solo centrarme en
temas de tecnología, sino también conocer temas de negocio. Por eso es que para mí
es mucho más sencillo entender las necesidades de los clientes, porque no solo es
porque quieren usar ese software, sino que hay detrás. El alineamiento de marketing,
los objetivos de la estrategia, no sé... Entonces para mí es más fácil, y eso me permite
también brindar un poco de sugerencias a los clientes.
Entiendo que sus proyectos los gestionan usando esquemas ágiles, coméntame
un poquito más como es la gestión del proyecto.
Básicamente la gestión del proyecto, depende mucho del tipo de proyecto. Si es un

proyecto de desarrollo de un producto, nuevo normalmente, usamos Scrum con técnicas
de ingeniería de software, de XP algunas cosas, no todas. Por qué, porque tenemos
periodos definidos, y Sprints definidos, entonces podemos implementar todos los
mecanismos que Scrum te ofrece de retrospectiva, de ayuda al equipo, el tema de
mejora continua, bajo esos esquemas, peor cuando tenemos proyectos de
mantenimiento, o soporte a alguna aplicación que ya existe y el soporte puede ser de
largo tiempo, usamos Kanban, entonces ahí es más continuo el proceso. Siempre
hacemos pausas, cada cierto tiempo, pero no es como que efectivamente tiene que ser
173
un Time Box, ósea 2 semanas, 4 semanas. Depende más de que cómo se está llevando
a cabo el proceso. Por eso básicamente usamos esas dos técnicas en cuanto a la
implementación del software. Cuando ya estás en fase de implementación. Cuando
estás es fase de preliminar pues usamos técnicas de design thinking para poder evaluar
las alternativas, comenzar un poco a pensar que opciones se pueden identificar para la
solución de un problema.
¿Hace cuánto tiempo lo hacen de esta forma? ¿Desde que empezó la empresa?
Sí, desde que empezó. Scrum yo vengo usando, como te digo, desde el 2007, cuando
entré al mundo ágil tuve la oportunidad de que me permitieron en la empresa en la que
yo trabajaba, una empresa americana, a implementar pilotos, hasta que la empresa se
dio cuenta de que eso funcionaba y se adoptó como metodología en toda la empresa
aquí en Perú y en la India. Entonces, eso a mí ya se quedó como forma de trabajo y
después entré con Kanban más o menos el 2011, después de la maestría, casi durante
la maestría, cuando entré al tema de retailing, donde ahí había bastantes cosas en
proceso. Entonces me di cuenta que Scrum era como muy restrictivo. No podía estar
parando, parando el proceso y comencé a meterme más en Kanban y desde ahí me he
quedado con eso.
¿Y cuánto tiempo suelen durar sus proyectos entonces?
Mira, hay proyectos que duran 4 meses como hay proyectos que duran un año,
proyectos que duran 8 meses. El más largo que hemos tenido ha sido uno de 14 meses.
¿Hay diferencias en la gestión de los proyectos cuando son más cortos que
cuando son más grandes?
En el proceso en sí no, pero obviamente hay más presión. Cuando es más corto, la
gente obviamente, los clientes quieren, como saben que el periodo es más corto,
quieren resultados más rápido. Entonces hay más, como que interacción con los
clientes. A veces los clientes se relajan un poco cuando ven los periodos muy largos,
pero nosotros siempre estamos insistiéndoles que participen, no es tan fácil a veces,
sobre todo si tus clientes están en el extranjero que participen en los meetings o en las
retrospectivas, pero siempre estamos insistiendo de que es necesario, porqué es
necesario, siempre un proceso de evangelización continua.
¿El alcance de los proyectos, cómo lo manejan?
El alcance de los proyectos lo manejamos con un roadmap inicial, en base a los

requerimientos del cliente se modelan una serie de funcionalidades a grandes rasgos
174
de lo que debería tener la solución, pero ese alcance cambia pues. Cambia en las 2, 3,
4 iteraciones ya hay cambios. Entonces lo vamos adaptando al plan usando justamente
las prácticas que promueve Scrum, ósea las retrospectivas, en las demos sobre todo
salen cosas, se ingresan, se priorizan. Cuando es en Kanban, eso es más natural,
porque entra una funcionalidad y ya tenemos el bloqueo del work in progress, entonces
ya tenemos que priorizar en ese momento cuál es más urgente, Si hay reuniones, en
ese momento y se dice ya OK trabajen en esto, no trabajen en lo otro, dejen esto,
posterguen. Entonces es más dinámico el flujo ahí.
¿Cómo los desarrolladores tienen acceso a eso? ¿Dónde está visible?
Como te digo usamos la herramienta Kanbanize, usamos una herramienta que ya la

tenemos usando hace 5 años, desde La empresa anterior lo vengo impulsando como 5
años. Entonces ya ellos están acostumbrados al flujo de trabajo.
¿Y el cronograma como lo manejan o los plazos mejor dicho?
Bueno, no usamos cronograma, aunque los clientes a veces nos piden. Lo que al final
hacemos en un timeline del roadmap. Básicamente es una secuencia de iteraciones, o
módulos, a veces tenemos que llamarlo para que los clientes entiendan un poquito
mejor, pero los manejamos como te digo, se crea este timeline o el roadmap al inicio y
conforme se va desarrollando el proyecto pues se va adaptando.
¿Quién maneja ese roadmap?
Normalmente lo manejo yo, a veces también lo maneja uno de los desarrolladores, el

que más experiencia tiene cuando comenzamos a hacer los cambios. Cuando
comenzamos a hacer los cambios, me dice “oye, pero esto va a afectar en el
cronograma, esto de acá”. “Ya OK, modifícalo y después se va adaptar”.
¿Y el presupuesto como lo manejan?
El presupuesto es un tema a veces complejo, y en mi experiencia cuando quise con La

empresa anterior, cuando quise meter el tema de metodologías ágiles acá en Perú en
empresas medianas y grandes me fue bastante chocante. Nos fue mal en realidad.
Invertimos un año casi en un montón de reuniones, y un montón de licitaciones, pero al
final casi todos quieren precio fijo. Precio fijo, mano alzada como le dicen algunos,
entonces eso no iba con el principio de La empresa anterior. Esa es una empresa de la
cual aprendí mucho porque es una empresa que se basaba en principios ágiles. Ósea
no solo el desarrollo de software, sino toda la empresa, entonces por eso me encantó
trabajar ahí con ellos. Entonces eso me permitió a mí aprender cómo gestionar una
175
empresa de manera ágil. Entonces cuando íbamos a estos concursos, el tema del precio
era complicado. Decirles que no necesariamente vamos a tener un precio fijo, sino que
puede variar en función de los cambios que se vayan dando, en los niveles medios se
entendía, pero a veces cuando ya llegabas a niveles altos, ya ahí encontrabas bloqueos,
sin contar el tema legal, que a veces los abogados no entienden que puede haber
proyectos sin penalidades, pero ellos necesitan ver penalidades en los contratos.
Entonces eso nos fue bien difícil. Entonces por eso nos enfocamos nuevamente en
nuestros clientes en el extranjero, donde con ellos es más sencillo, porque tienen quizás
más experiencia en este tipo de proyecto. Por eso cuando tenemos clientes acá en Perú,
tratamos de llevarlo a un modo ágil, tratando de… la mejor opción siempre es tener un
precio por hora, un precio por hora. Estimar horas de esfuerzo en función de la
complejidad de los requerimientos, y definir un precio inicial. Incluso hay un modelo que
lo aprendí hace poco que se llama agile Fix Price, que también mezclan las dos cosas.
Te define como que dos módulos. Digámoslo así tienes el módulo optimista y el módulo
pesimista con precio fijo en ambos escenarios, y bajo ciertas condiciones. Hay
condiciones de salida para poder salir del proyecto, para poder cambiar los precios.
Entonces eso en algún momento también lo utilicé, pero al final tengo que llegar a eso
acá en el Perú. Tener precios fijos en alguna forma y tratar de tener un buffer, un
colchón. Lo bueno es que, si bien tienes precios fijos, la gestión de cambios en agile es
mucho más sencillo cuando el cliente está involucrado. Entonces sabe exactamente qué
está ocurriendo, por qué están ocurriendo las cosas, entonces cuando tienes que
solicitar un cambio que puede incrementar el costo, es más sencillo de negociar. Eso sí
es algo bueno.
¿Y quiénes participan en la elaboración de ese presupuesto?
Cuando es la empresa, ósea cuando es un proyecto solamente con la participación de

La empresa lo hago yo, pero cuando es con empresas socias lo hacemos entre las
empresas que participan.
¿Y qué prácticas o recomendaciones de aseguramiento y control de calidad

siguen en sus proyectos?
Ese también es otro tema aquí en Perú, que el control de calidad no lo quieren..., no lo
ven valor a veces. Como que quieres cobrar por el tiempo que va a involucrar el tiempo
de control de calidad, porque es tiempo y esfuerzo y algunos no… “me estás
incrementando el presupuesto” me dicen. Otros no me lo ofrecen y voy a pagar menos.
Ese tipo de respuesta. Entonces para acá los proyectos que hemos hecho acá en Perú,
176
si hemos tenido que ser bastante escuetos en el control de calidad con automatización
de algunas cosas que sean posibles, cuando es web o cuando es móvil. En cambio,
para proyectos que hemos tenido en el extranjero si hemos implementado más
automatización.
¿De los tres proyectos que me dijiste que tienes en cartera?, cuántos son
nacionales y cuántos son para el Extranjero?
Uno es extranjero y dos son nacionales.
¿Y entiendo que en general ustedes trabajan solamente con el sector privado, no

trabajan con el sector público o sí?
Normalmente no he trabajado con el sector público, pero uno de estos proyectos

nacionales es con el sector público, pero no es que yo sea la empresa que ganó la
licitación. Sino que yo formo parte del grupo de implementación. La empresa que ganó
la licitación es otra y es la que da la cara. Pero si obviamente participo en todos los
procesos que involucren al sector público. Pero te soy sincero, no es que yo quiera
trabajar mucho con el sector público. Yo creo que la innovación es muy lenta por ese
lado. Hay muchas barreras de personas y de proceso y creo que la innovación puede ir
más rápido por el lado privado o el lado de la empresa propia.
¿Estos riesgos que me dijiste que, si identificaban y que les hacían seguimiento,
cómo les hacen seguimiento o con que periodicidad lo hacen?
Diaria, en el stand daily, daily stand estamos hablando. En el daily meeting estamos
siempre revisando los requerimientos, de los 15 minutos que son técnicos siempre
dejamos un espacio para ver los riesgos que pueden darse y si requieren más discusión,
la conversamos después del daily, pero siempre estamos en constante revisión de los
riesgos.
¿Cómo sabe la empresa el estado de sus proyectos en curso?
Las herramientas nos ayudan en eso. En el caso de Kanban, en el kanbanize

automáticamente tenemos un… nos da un porcentaje de avance de las tareas en
función a las iniciativas que están en el portafolio. Entonces, ahí sabemos que estamos
al 20%, 30%. Eso es automático y también usamos una herramienta que se llama...
Bueno recién estamos comenzando a utilizar la herramienta que se llama Aja. Que es
para la gestión de productos, no de proyectos de productos, que nos brinda ciertos
indicadores de cómo va el proyecto.
¿Y hay algún indicador de la cartera como un todo?
177
El Kanban, en el kanbanize puedes hacer eso, porque puedes definir tu portafolio, tus
iniciativas las asocias a acciones y las acciones a proyectos y todo genera indicadores.
Y de estos temas de gestión de gestionar alcance, el cronograma, el presupuesto,

la calidad y los riesgos. ¿De las actividades que realiza la empresa cuáles
consideras que generan mayor valor al negocio? ¿Cuáles crees que son las más
críticas?
De la propia gestión en realidad todas, pero quizás la que más impacta… la que más
visibilidad tiene con el cliente es la de costos y de tiempos. Ósea a veces ahí invertimos
más tiempo que en el resto quizás para poder demostrar al cliente que estamos atrasos
a veces y justificar el retraso o que estamos bien y que estamos en el costo o que
probablemente vamos a llegar un poco más del costo porque hay muchos cambios.
Entonces esas dos, sí nos llevan un poco más de tiempo que el resto, pero más por el
lado de que tenemos que estar, como es cada dos semanas normalmente el sprint o
cada 4 a veces, estar mostrando al cliente como vamos en el proyecto y tenemos que
justificar la situación. Pero en realidad como te comenté si hacemos todas las otras
gestiones, calidad, costo, tiempo, alcance obviamente, comunicación. Te soy sincero, si
bien esas actividades generan un poco más de esfuerzo, la de gestión de tiempo y
calidad, yo considero que incluso, una de las gestiones más importantes en todos los
proyectos es la de comunicación, porque en mi experiencia por más bien que se esté
llevando el proyecto, si no lo comunicas correctamente o no se enteran correctamente
las personas que deben enterarse, eso no anda bien. Entonces la gestión de
comunicación si es muy importante también, y también le damos bastante énfasis a eso.
¿y cómo gestionas las comunicaciones en el proyecto?
Con las reuniones que tenemos con los clientes, con los dailys, con las sesiones que
tenemos después de los dailys, pero incluso nosotros y eso les estoy inculcando a los
desarrolladores es que tenemos que tener nuestro mapa… Es algo que PMI siempre
inculcaba tener identificados nuestros stakeholders. En algunas empresas que he visto
no se tiene esa identificación, entonces a veces entra una persona, sale otra, no sabes
quién es, por qué participa. Entonces eso nosotros si lo tenemos identificado desde el
inicio y a la hora que tenemos que comunicar sabemos a qué personas tenemos que
comunicar. Entonces eso es una actividad que es muy importante para la gestión.
¿Y los empleados saben cómo su proyecto aporta a la empresa de alguna forma?
No de manera formal, pero si les comentamos que con este proyecto se está
solucionando tal cosa, el cliente está más satisfecho por esta razón, nosotros como nos
178
sentimos satisfechos por el proyecto. Pero no es algo formal. Yo espero que
probablemente eso cambie, cuando tenga ya las soluciones, porque eso si va a tener
un impacto directo sobre nosotros.
¿Y quién gestiona los proyectos?
¿En qué, en su totalidad?
Entiendo que tu manejas el portafolio, tienes la lista de todos los proyectos contra
los indicadores y participas en la elaboración del presupuesto de cada uno. ¿Una
vez que el proyecto empieza a ejecutarse, quien lidera el proyecto?
En la mayoría de los casos, en algunos casos, no en la mayoría, si en la mayoría lo he

hecho yo mismo también. Pero en estos proyectos que son con empresas socias, a
veces no he sido yo, a veces una de las personas de la empresa que participa. Pero sin
embargo siempre estoy bien metido en la gestión. Si quizás no es mi responsabilidad o
no soy el responsable oficial, siempre estoy bastante involucrado apoyando en que las
cosas se vayan dando.
¿Y en estos casos en que lidera otra persona, cuál es el perfil de esa persona?
¿Lo determinan por el aspecto técnico, si tiene experiencia en gestión, qué
consideran?
Si bueno me ha tocado dos experiencias que eran personas que venían del mundo del
PMI que no tenían casi ninguna experiencia en agile. Entonces era un poco más difícil.
Ahí si tuve que participar un poco más, explicando las razones de cada una de las
actividades, de los procesos. En un caso no se adaptó, se retiró a mitad de proyecto y
yo asumí la gestión del proyecto y en el otro sí se adaptó. Estuve yo más como soporte
al final casi, porque ya se gestionaba de la manera como queríamos y nos fue bien pues.
¿Cómo defines éxito en tus proyectos?
Si el cliente está satisfecho, no me mido por si el costo fue mayor o menor que el
presupuesto, o si el tiempo tomó más o menos tiempo, sino si el cliente está satisfecho
con lo que se ha hecho. ¿Por qué? Porque ha habido casos en que hemos hecho el
proyecto en el tiempo estimado y el cliente ha estado bien, pero también ha habido
casos en que los hemos hecho en tiempos más largos de lo planificado inicialmente,
pero sin embargo el cliente se ha quedado contento. Entonces para mí, mi indicador es
la satisfacción del cliente.
¿Cómo se evalúa la satisfacción del cliente?
179
Con un acta, hacemos un… no es un acta, es como un chárter, es un documento en el
que le enviamos al cliente que por favor nos diga sus reflexiones sobre el proyecto.
Incluso aquí en Perú hemos tenido la oportunidad de hacer una retrospectiva final con
el cliente. Nos fuimos con los gerentes a hacer una retrospectiva y quedaron fascinados
porque para ellos era la primera vez que un proveedor les hacía este tipo de actividades,
y estaban muy contentos con el trabajo. Y ese es un proyecto por ejemplo que nos
demoramos más de lo planificado, pero terminaron muy contentos.
¿Bajo esa definición, qué porcentaje de tus proyectos terminan con éxito?
Casi todos, solo he tenido 2 proyectos en los que, si el cliente no estaba completamente
satisfecho, pero casi todos terminan bien. Si te doy un porcentaje, tendría que ser un
95%, por ahí, porque, por eso es que nosotros siempre nos hemos definido como una
boutique de software, no como una Factory. Porque como tenemos tanta integración e
interacción con el cliente durante el desarrollo del proyecto, el cliente está muy al tanto
de cómo van las cosas. Entonces ellos saben porque se dieron las cosas, porque fueron
los problemas, cómo se solucionaron, si la solución fue óptima o no. Entonces eso ayuda
a que la satisfacción al final sea buena. A veces es difícil porque hay clientes que no
tienen mucho tiempo. Es…, hay un término en la teoría de Adler, que es la ilusión del
product owner. Ósea el concepto de product owner tal cual se define en la agilidad, a
veces es muy difícil de conseguir, pero procuramos siempre tener un product owner muy
involucrado en los proyectos.
¿Y qué porcentaje de proyectos terminan retrasados?
Es que todo depende de qué es retraso
¿Cómo defines retraso?
Claro, si lo definimos contra el periodo de tiempo estimado inicialmente, la mayoría.

Porque lo que estimamos inicialmente es en rango de incertidumbre alto, entonces casi
todos terminan más del tiempo estimado inicialmente, pero como te digo por eso no es
uno de los indicadores que yo considero. Yo considero más que terminen bien, clientes
contentos con lo que se deja. En los proyectos que, si hemos tenido aquí en Perú, en
los que han sido Fix Price, que son dos nomás, si hemos terminado pues en tiempos.
¿Hay casos en que un proyecto haya sido cancelado antes de terminar por n
motivos?
Uno, si uno, el cliente, era un tema más de... para mí me quedó como una lección
aprendida. La clienta era un poco difícil. Era una persona que venía del extranjero,
180
llegaba acá al Perú. Estaba haciendo un proyecto acá en el Perú y venía del extranjero
cada 2 o 3 semanas y estábamos elaborando un proyecto así y ella quería algo como
Fix Price, pero su proyecto iba creciendo demasiado. Entonces yo le trataba de hacer
entender que no íbamos a poder cumplir con esos términos porque ella misma estaba
viendo que el proyecto crecía. Entonces fue un poco difícil. Al final decidimos, sabes
que, mejor busquemos un punto intermedio hasta el cual tú quieres que nosotros
lleguemos. Llegamos a eso, te entrego todo lo que tengamos que entregarte y tú decides
con quién más continuar, porque no podemos seguir así y ese fue el único proyecto que
se canceló.
Después de entrega final, son pocas en realidad, es bajo, porque justamente al hacer
bastante control de calidad interno, y progresivo la tasa de errores baja comparado con
otros proyectos que yo veía hace muchos años atrás. Si te tuviera que dar un porcentaje
es como que del total de funcionalidades que se implementaron, será pues el 10%, 15%
porque los errores salen, que van a salir porque por más pruebas que hagamos siempre
se va a pasar, van a salir en algunas cosas puntuales, no en todo el proyecto.
En tus respuestas a la encuesta había valores que calificabas como

completamente de acuerdo, y algunos que ponías un poco más bajo. Por ejemplo,
en “la encuesta controla el alcance de los proyectos realizados, ponías un 3, 3 de
7. ¿Por qué esa percepción?
Porque nosotros no controlamos mucho el alcance, bajo el modelo de boutique de

software, el alcance va mucho del cliente, entonces el alcance varía.
Pero en todo momento si sabes cuál es el alcance actual por así decirlo.
Si claro, sí sabemos, en todo momento.
Imagino que razones similares son para cronograma y presupuesto.
Exactamente, así es.
En la pregunta de “Al momento de decidir realizar un proyecto, se toma en cuenta

criterios definidos”, le pusiste 5 de 7. Durante la entrevista me has contado que
toman en cuenta la capacidad, toman en cuenta la factibilidad y la rentabilidad.
¿Estos criterios están definidos propiamente, son tu propia experiencia y siempre
lo haces igual o están documentados de alguna forma que así se debería hacer?
181
Bueno, yo creo que lo debo haber aprendido en los cursos que he llevado de gestión,
porque no sé si estará escrito en algún lugar, pero es algo que aprendí y así lo llevo
desde hace mucho tiempo. Yo asumo que en algún momento me lo deben haber
enseñado o lo debo haber leído en alguno de los libros que he leído, pero no es algo
que yo haya inventado. Es algo que yo sigo porque en algún lugar lo aprendí.
¿Y cómo determinas las prioridades de los proyectos?
Si tengo varios proyectos, al mismo tiempo
Ahorita tienes 3. ¿Los 3 tienen la misma prioridad o hay alguno que tenga mayor
prioridad?
Bueno, ahorita tengo 3 y los tres están cubiertos, entonces como que tienen la misma
prioridad. La prioridad se afecta un poco cuando no tengo muchos recursos, ósea no
tengo la suficiente capacidad de personas que me puedan ayudar en un proyecto.
Entonces si tengo que estar midiendo la prioridad en función de cuál es el proyecto que
tiene menos holgura o menos tiempo para poder ser entregado. Entonces si tengo que
cumplir primero con uno, me preocupo en cumplir con él y después trato de avanzar con
los otros.
¿Entiendo que ha habido casos anteriores en que has estado en esa situación?
Si, así es, porque en algún momento me dejaron algunos programadores, entonces el
proyecto se tuvo que….
¿Y esas prioridades son explícitas o simplemente están en tu cabeza de alguna

forma?
Es un análisis cualitativo del desarrollo del proyecto, analizas los proyectos y ves cuales
son los que tienen menos tiempo, menos holgura, menos tiempo para ser entregados y
decimos OK, enfoquémonos en esto y después….
¿Ósea que en teoría la prioridad también cambia conforme avanza el tiempo?
Eso, es correcto
¿Y qué crees que necesitas para crecer entonces?, que de alguna forma creo que
ya los has respondido.
Sí, como te digo no centrarme en el desarrollo de software. Eso al final incluso la

tendencia es que el código se va a escribir solo, en algunos años. Entonces me quiero
mover al lado del desarrollo de soluciones y me gusta mucho el tema de consultoría.
182
Entonces quiero enfocarme en esos dos lados. El tema de docencia también es algo
que siempre me gustó.
183
¿Cuánto tiempo tiene la empresa?
3 años. Estamos trabajando desde febrero del 2016.
¿Y qué tipo de proyectos realiza la empresa?
Tenemos dos líneas, mira, brindamos 4 tipos de servicios, pero tenemos dos líneas bien
marcadas en las que tenemos más demanda. Uno que es soporte de infraestructura y
de software, que es un servicio de 24x7, estamos como bomberos, si se cae algo en
ese servicio estamos ahí. Y en la otra línea de servicio es desarrollo de software,
desarrollo de software tenemos de dos sabores, se podría decir, desarrollo como
proyecto o desarrollo a través de fábrica de software porque tenemos dos fábricas, ósea
dos fábricas en dos clientes. Esos son los dos servicios que realmente hasta el momento
venimos dando.
¿Y cuántos proyectos puede manejar la empresa al mismo tiempo?
Mira, ahorita tenemos, como gestión tenemos tres jefes de proyecto y más o menos
tenemos 5 proyectos en paralelo, porque por ejemplo Gisella maneja dos de ellos,
Milexa maneja dos de ellos y yo a veces manejo uno y tenemos otros proyectos de
desarrollo de software. Como soporte tenemos a una persona dedicada en un
porcentaje a ver toda la gestión de soporte, de los incidentes, los informes.
¿Esos 5 son solo proyectos de desarrollo entonces?
Claro, proyectos de desarrollo.
¿Y cómo empresa tienen objetivos definidos?
Objetivos definidos, por ejemplo, primero que la visión y la misión está claramente
definida. Ya la hemos revisado. Como objetivo al inicio del año lo que hacemos es
objetivos económicos, es decir cuánto más queremos crecer en el año que viene como
ha pasado con el año pasado a ahora y el otro objetivo que se ha fijado es también la
capacitación técnica, que es un tema que también se ha empezado con fuerza. Se ha
hecho un plan de certificación para los chicos, un plan de estudios, se compró… como
te puedo decir, se pagó por una membrecía para el tema de RedHat para IBM para que
los chicos tuvieran materiales y hay un plan concreto. Ósea son objetivos concretos,
certificación a mayo de este punto, a junio de este tema y así. Entonces son dos,
crecimiento en volumen de ventas y crecimiento a nivel técnico de los chicos, del equipo.
¿Y quiénes en la empresa conocen esos objetivos?
184
Hicimos una reunión, porque esos objetivos los planteamos al cierre del año 2018
realmente. Hubo una reunión al fin del año y expusimos esos objetivos. Ósea todo el
personal de la empresa lo sabe y a partir de eso se organizó en enero justamente lo de
las capacitaciones, quién va a tal proyecto, quien toma este tiempo para ver temas de
nube, temas de RedHat y así.
¿Cuál es la misión que me habías comentado de la empresa?
Mira, tenemos visión y misión. La visión es como te quieres ver al futuro, entonces es
un tema que también transmito siempre a los chicos cuando llegan, ósea como me
quiero ver, para ver la visión de la empresa está también orientada a la visión de cada
uno. Yo me quiero ver como una persona líder en tecnología, la empresa se quiere ver
como una empresa líder en tecnología, que enfrente retos, ese tipo de cosa. Ósea ahí
vamos como visión. Y como misión, que tengo como misión, la misión es... cómo te digo,
satisfacer al cliente en sus necesidades y esta satisfacción de necesidad del cliente se
basa en de buena calidad, cumplimos sus expectativas. Esa es nuestra misión y esa
satisfacción al cliente es en todos los rubros en los que estamos metidos. Es decir, todos
los servicios que damos.
¿Cómo evalúan si se han cumplido los objetivos?
Mira, hasta el año pasado no habíamos establecido objetivos claros y medibles, recién,
como te digo a final del año hemos hecho por ejemplo unos… Estamos en ese proceso
de fijar esa forma de medirlos, porque nos hemos fijado si metas, como por ejemplo a
mayo tienes que certificar a 2 personas en esto, por el tema del objetivo de la
capacitación técnica y el mejoramiento tecnológico. Hasta tal fecha se ha fijado eso,
pero que hayamos hecho formalmente la medición… cómo vamos a medirlo
formalmente no lo hemos establecido. Eso es un tema que tenemos que hacerlo.
¿Existen proyectos internos? Es decir, desarrollo de productos que hayan

pensado hacer o que hayan hecho
No, como proyecto interno, no tenemos todavía ningún proyecto interno, de algún
desarrollo. El único bueno el de la página web y el diseño que queremos para que los
chicos también lo vean, el tema de sus boletas, pero no hay más allá de eso.
Y dentro de estos proyectos, principalmente los proyectos de desarrollo. ¿Cómo

consigue proyectos la empresa?
Es por recomendación. Te cuento, nosotros hemos entrado al mercado debido al

conocimiento que tienen personas sobre el trabajo que hacíamos antes. Ha sido más
185
por eso. Tenemos 5 clientes importantes y a los 5 hemos llegado porque están gente
que nos conocían de trabajos anteriores y es ahí donde estamos creciendo. Ahora, justo
también es algo que comentábamos en la reunión de fin de año, ahora nos toca también
buscar nuevos clientes en lugares donde quizás no nos conozcan, y eso es lo que
estamos también. Estamos buscando en ese sentido eso.
¿Y quienes participan en ese proceso de conseguir proyectos?
Bueno, ahí participa José como gerente general, yo como gerente comercial y de
operaciones y Gisella que es Gerente de Proyectos. Somos los 3 que estamos metidos
en esa búsqueda de nuevos clientes. Los demás si no se enfocan en ese tema.
¿Entre un grupo de posibilidades, cómo deciden qué proyectos ejecutar?
Yo me imagino por la rentabilidad que nos va a dar o si realmente vamos a ganar en

ese proyecto. Claro ese es uno, si es viable tecnológicamente y si es retador para
nosotros. Exacto, si la tecnología está relacionada con la tecnología que conocen. Por
ejemplo, nos estamos muy metidos en el mundo de .NET, entonces cuando sale un
tema de .NET, que es simple, que podemos manejar, lo vamos, pero si es un tema de
.NET, no sé, muy grande, porque si nos han llamado, lo derivamos ya sea por ejemplo
con Aldo Villagarcía, con gente que si sabemos que conoce de temas de .NET. Está
muy orientado a la tecnología en la que estamos enfocados nosotros, que es java,
Redhat, IBM, integración, temas que estamos orientados de ese tipo.
¿Y quién toma esa decisión o cómo toman esa decisión?
Esa decisión se toma, que pasa, nuestro gerente general tiene mucho bagaje técnico,
ósea si bien es el gerente general, pero es el arquitecto de la empresa. Entonces, el en
coordinación conmigo, como gerente comercial decidimos. Oye esto no, esto sí, esto ya
déjalo, dile que hasta acá nomás, porque es un tema que no nos vamos a meter, porque
nuestro plan no está enfocado a esa tecnología. Dejémoslo ahí, recomiéndale tal y así.
Eso en una reunión que tenemos entre el gerente general, nuestro arquitecto y nosotros
como operaciones.
¿Aparte de la viabilidad tecnológica y que el proyecto sea retador, hay algún

aspecto adicional que se tome en cuenta para decidir si un proyecto va o no va?
Si, a veces el cliente tiene una idea del tiempo y no es viable, como nos ha pasado hace
poquito. Ósea yo necesito que lo saques en 6 meses y por más que hagas magia, no lo
vas a sacar en 6 meses. Entonces decimos “Oye no se puede, hasta aquí lo dejamos”
Por ejemplo, el tiempo que exige el cliente, el precio también, porque a veces también
186
el cliente te dice que “no, estás muy alto, y quiero que te bajes a tanto”. Definitivamente,
no vas a ir a perder. En función de los riesgos que también tiene el proyecto también
decimo no. Y si nos ha pasado.
¿Esa evaluación queda documentada en alguna parte?
No, por ahora no. No está quedando documentada.
¿Entonces hay proyectos que deciden no hacer?
Sí.
¿En algún momento deciden no hacer un proyecto por falta de recursos? Es decir,
aunque sepa que mis recursos tienen el conocimiento tecnológico, pero ya no
tengo tiempo para ver proyectos
Normalmente no, en la que decimos ya no vamos porque los chicos no tienen tiempo.
Por último, podemos conseguir. Nos ordenamos, reestructuramos equipos o hacemos
prioridades y hablamos también con el cliente, “mira podemos empezar en esta fecha”.
Generalmente no hemos rechazado proyectos porque no tengamos el recurso humano,
o porque no tengamos la persona que esté asignada al proyecto.
¿Qué tan importante consideran que sería la innovación para la empresa?
Bueno, es súper importante en el tema de desarrollo de software, sino estás innovando

olvídate, y no solamente es innovación a nivel tecnológico, sino innovación a nivel de
metodología, porque te das cuenta que se usa una metodología, surge otra y los clientes
están “Oye esto nuevo”. No definitivamente que sí, y justo por eso es que tenemos este
plan de capacitación, para que se metan en temas nuevos. Incluso hemos armado todo
un ambiente nuevo para que los chicos jueguen, practiquen, se metan.
¿Y la empresa ha realizado proyectos que se consideren innovadores para los

clientes?
Ahorita, sí, por ejemplo, el tema en Visanet, por ejemplo, para irse a la nube, usar Open
Shift, todo eso para ellos es un tema innovador y tamos metidos con ellos en ese tema.
¿Qué porcentaje de los recursos económicos de la empresa se destinan a

capacitación aproximadamente?
Te podría decir que un 5 a 105 porque los costos de las membrecías no son nada
baratos. Las membrecías de IBM, de Redhat, el costo de las certificaciones y así. Pero
sí se destina, incluso hasta el ambiente porque se ha creado un ambiente para que los
chicos practiquen.
187
Mencionaste que también se toman en cuenta los riesgos al momento de decidir hacer
un proyecto. ¿Cómo hacen ese análisis?
Mira, no tenemos un análisis, no se hace de manera formal o documentada, pero si se

conversa, a través de reuniones que tenemos. Por ejemplo, “Ya viene este proyecto,
Vamos a ir no vamos a ir” Y nos ponemos los tres que somos los encargados de decidir
qué proyecto va o no va. Y por ejemplo Gisella puede decir “oye, pero esto es muy
riesgoso, porque nos quieren cortar el plazo” o hay un riesgo porque los webservices no
están o empezamos a.… y tratar de decidir “oye no, pero este proyecto lo podemos
manejar así”, y a veces resulta que si es viable y hay veces que no. Pero que
documentemos, que esté formalizado, que tengamos un checklist de evaluación de
riesgos para tomar el proyecto o no, no lo tenemos. Si serviría tenerlo, pero no lo
tenemos.
¿Y qué tipo de riesgos se consideran en ese análisis informal?
Por ejemplo, riesgos técnicos, dependencias del cliente, por ejemplo, porque hay
muchas cosas que tú dependes del cliente, y a veces te dicen que no los tienen o que
los van a tener recién. También el otro riesgo que tenemos es expectativo de plazos,
que el cliente establece también. Porque a veces quiere hacer un monstruo en tres
meses, ya nos ha pasado. Y complejidad técnica definitivamente, porque sabes que, los
proyectos en los que nos metemos, están muy orientados a temas técnicos. Están
más… ósea nos buscan por temas más técnicos y complicados que por temas simples.
¿Dirían que todos los proyectos que realiza actualmente la empresa, se alinean
con los objetivos de la empresa?
Yo creo que sí, porque como te vuelvo a repetir, los proyectos están orientados a temas
técnicos, de complejidad alta y las expectativas del cliente es esa. Justo ayer nos
comentaban “Los buscamos a ustedes por su conocimiento técnico.
¿No hay ninguna cosa que se esté haciendo actualmente, que consideran que
debería dejar de hacerse en el futuro cercano?
Te podría decir que sí. Mira, hay temas, por ejemplo, los proyectos de Alignet en los que
estamos metidos. Son proyectos simples, donde hemos, por ejemplo, ahí asignado
como una especie outsourcing, pero que al final no nos retribuye económicamente, ni
tampoco cumple con el objetivo de buscar retos técnicos, porque son temas sencillos,
simples, pero el cliente incluso tiene problemas económicos y nos es difícil afrontar pues
188
una asignación de alguien que te paga de acá a 3 o 4 meses. Esos son temas que si
pues.
Y la razón para seguir haciendo esos proyectos. ¿Cuál es?
Justo, el tema era cerrar un compromiso que teníamos con ellos porque hay una primera
fase en la cual teníamos que apoyarlos, que cierra este mes, pero justo ahí, estamos
rechazando ya la continuidad de ese proyecto, porque ... primero no es viable, los chicos
se aburren, porque técnicamente no tiene ningún reto y económicamente tampoco es
rentable porque no te pagan en el tiempo en que uno necesita.
Y en este proceso de seleccionar o de tomar la decisión de qué proyectos son los

que finalmente van. Me dices básicamente lo hace el gerente general, gerente
comercial. ¿Cuál es el perfil o cómo se podría describir el perfil de estas personas,
que le ayude a este proceso específico, ósea tomar la decisión?
En el caso del gerente general que representa también el arquitecto de la empresa,

justamente es el conocimiento a nivel de arquitectura, a nivel técnico con el que cuenta.
En el caso comercial y de gestión el tema es el skill que tenemos es por ejemplo, va
más orientado a si es conveniente económicamente, la asignación de las personas, si
va a ser retador para las personas que van a hacer asignadas, si vamos a poder lograr…
Ósea es un conocimiento del equipo que tienes para afrontar el proyecto, conocimiento
del cliente que tenemos para afrontar el proyecto y el conocimiento de la rentabilidad
que va a generar el proyecto al cual nos vamos a enfrentar. Esos son los skills que al
final intervienen para decidir si o no.
¿Y en lo que a formación se refiere?
Bueno, yo creo que la formación universitaria que tenemos todos, que va por ahí. Tanto
universitaria, la maestría y la experiencia en sí también.
¿La persona que hace la propuesta y la persona que dirige el proyecto es la

misma, son diferentes?
En la mayoría de los casos tratamos de que sea la misma. Sí, quien hace la propuesta,
los cronogramas son las personas que luego gestionan. Porque no somos una empresa
muy grande que tengamos muchas personas. Por ejemplo, tengo una persona en un
cliente y se dedica a gestionar y hacer las propuestas, los requerimientos que salgan de
ese cliente. Tengo otra que ve otros clientes como Cavali, como Visanet y así. Cada uno
va. Pero sí, quien hace la propuesta generalmente la ejecuta.
¿Y cómo gestionan sus proyectos? (17.57)
189
Bueno, hasta el momento hemos usado, no estamos usando Scrum, estamos usando
la metodología tradicional. Y la gestión como va. La revisión del avance, generalmente
hacemos el seguimiento de los proyectos semanalmente, hacemos el informe semanal
al cliente, del avance del cronograma. Estamos muy de la mano con los chicos, porque
no somos mucho tampoco, para poder ver por ejemplo el avance del proyecto, las horas
invertidas, los desplazamientos que existen.
¿Se basan en algún estándar para la gestión?
¿Estándar en qué sentido?
¿Hay algún proceso definido documentado?
Sí, tenemos procesos definidos y documentados. Del proceso de gestión, del proceso
comercial y de los procesos operativos que son los de soporte y desarrollo de software.
Si tenemos estos documentados. Ósea ahí tenemos artefactos, plantillas, todo para
cada uno de esos procesos.
¿Y la parte de gestión específicamente? Me comentaste que no se estaba usando

Scrum, aunque se está pensando para un futuro. ¿Entonces la gestión se basa en
la Guía del PMBOK?
Sí en el PMBOK
¿Hace cuánto tiempo lo hacen de esta forma, desde el inicio o ha ido

evolucionando?
Desde el inicio, cuando iniciamos, justamente iniciamos ya con todo un proceso de

gestión, con plantillas y todo para poder seguir.
¿Y cuánto tiempo suelen durar los proyectos de desarrollo?
Son cortos en realidad, en realidad pueden ser de un mes, dos meses. Se vienen
proyectos grandes. Los proyectos son de uno o dos meses, pero tenemos fábricas con
contratos de más un año y ahí son requerimientos cortos. Entonces como son fábricas,
son requerimientos cortitos, pero tienes un año de contrato con el cliente renovable
automáticamente. Y así sigues toda la vida con el cliente, los tres años. Así estamos
con Cavali, con Visanet y con BBVA como fábrica y a lo largo de todo este tiempo.
¿Cómo gestionan el alcance de los proyectos? ¿Cómo lo identifican y cómo lo

controlan?
El alcance, a través del documento... Hay un documento funcional. El documento

funcional hacemos un entendimiento, de repente una reunión, call algo para aclarar
190
algunas dudas. Sobre ese alcance definido, ya se trabaja los cronogramas y actividades.
Ese cronograma se presenta al cliente y ese es nuestro punto de partida para poder
luego hacer el seguimiento y control. Ahora en la propuesta ponemos el alcance
funcional, el alcance no funcional y las consideraciones que hemos tomado en cuenta
para el alcance, porque para poder gestionar luego con el cliente, cualquier ampliación
de plazo, movimiento o cambio de alcance.
¿Y cuándo hay cambios en el alcance, cómo lo gestionan?
Con control de cambios. Hay un control de cambios, se hace un análisis de la

funcionalidad nueva o la que estimamos que está fuera del alcance, hacemos un análisis
de costos y tiempos. Con eso se conversa con el cliente. Si lo aprueba se da el Gol.
Muchas hay alcance que lo asume el cliente y otros cambios de alcance que lo
asumimos nosotros, porque de repente hemos tenido un entendimiento no muy claro
del tema, pero que si estaba expresado por ejemplo en el Documento Funcional.
Entonces, a pesar se hace un control de cambios, pero asumido por nosotros, que hace
movimientos de tiempos y no impacta en costos al cliente en algunos casos. En la
mayoría de los casos tratamos de trasladar al cliente, pero hay momentos en que no se
puede.
¿Y en cuanto al cronograma, cómo hacen la estimación de tiempos?
Juicio de expertos, no tenemos una metodología o una historia, porque generalmente

lo que tendríamos que hacer ahora es ir guardando los cronogramas reales, para que
luego nos sirvan de base para los cronogramas nuevos que vamos haciendo. Pero
ahorita, como los proyectos son de corta duración y más tenemos fábrica, donde el
cliente pone el requerimiento y la prioridad, casi estamos por juicio de expertos. “Mira,
esto, mínimo una pantalla me demoro 3 días, o dos días o una hora y así”.
¿Los cronogramas se manejan en alguna herramienta en particular?
Project
¿Y en temas de presupuesto, como se gestiona el presupuesto de los proyectos?
El presupuesto, nosotros tenemos un cálculo ya de tarifas establecidas con el cliente,

por un lado. También tenemos un cálculo del costo que representa esa... un analista
programador tiene un costo para nosotros, más el margen que queremos ganar,
tenemos este precio y por ende esta tarifa. Eso sí está claramente establecido. Entonces
en función a la tarifa que tenemos, es la tarifa con la que costeamos los proyectos, que
ya están basadas en el costo, el margen y su contribución al costo fijo de la empresa.
191
¿Y las variaciones del presupuesto vienen dadas por variaciones del alcance
entonces?
Claro, exactamente sí.
¿Qué prácticas de aseguramiento o control de calidad llevan en los proyectos?
Bueno, así hacemos una verificación interna. Generalmente tratamos que aparte de las
pruebas unitarias en la medida de lo posible haya pues, una verificación, revisión de
pares, verificación del código. Eso es lo que hacemos, antes de entregar al cliente, y un
documento que ahora estamos preparando. Hay una serie de evidencias de pruebas.
Ósea una vez que hacemos las pruebas, tenemos que evidenciar que todo esté en
orden para entregarlo al cliente, con un documento que se entrega previo a pasar a QA.
¿Y los riesgos, como se gestionan durante el proyecto?
Los riesgos son identificados, como comentó Susana, hay riesgos al inicio del proyecto
y otros que salen durante el proyecto. Estos se comunican en el informe, en el informe
de seguimiento que tenemos y sobre ese se va haciendo el seguimiento. Se establecen
los riesgos, el estatus de abierto o cerrado, fechas de tope y si hacemos mitigación, la
responsabilidad también, quién va a asumir ese riesgo, ósea está a cargo de Visanet o
del cliente, o nuestro. Eso se pone, y también está en el informe los problemas, riesgos
que se convirtieron en problemas porque no se manejaron de manera correcta.
¿Y la gestión de estos riesgos, de quién es responsabilidad?
Del jefe de proyecto con el equipo también.
De estas actividades relacionadas con gestión, ósea lo que hacen para gestionar
el alcance, el cronograma, el presupuesto, la calidad y los riesgos. ¿Cuáles
consideran que generan mayor valor al negocio? ¿Cuáles son más importantes?
Yo creo que el manejo de los riesgos. La gestión del cronograma y el manejo de los
riesgos, porque eso te segura que cumplas con el plazo y que cumplas con el
presupuesto.
¿Y cómo sabe la empresa el estado de sus proyectos? Mejor dicho, de la cartera

de proyectos.
Mira, estamos trabajando en eso. ¿Qué pasa? Como somos una empresa pequeña
claro es fácil para nosotros ¿cómo va tu proyecto? ¿Cómo va el tuyo? Pero si tenemos
que establecer un tema formal, que no existe, ósea, es más, en un momento dado de la
semana, me siento con una de mis jefes de proyecto y veo el estado del proyecto. Luego
192
me voy con el otro y voy viendo. Pero debe ser algo más formal. No existe todavía ese
mecanismo formal para evaluar la cartera, o gestionar la cartera de proyectos.
¿Pero si se sabe el estado de los proyectos individuales?
Sí.
¿Esto está en el informe que …?
Claro, exacto.
¿Los empleados saben cómo su proyecto se alinea con los objetivos de la

empresa? ¿Ósea saben cómo aportan a los objetivos?
Sí, bueno en el caso que tengo si es consciente de que el cumplimiento de plazo del
cliente genera satisfacción o insatisfacción. Eso sí claramente lo tenemos porque
tenemos mucha relación con el cliente y de hecho los compromisos si se tratan de
cumplir y si no, hay una justificación y se tiene que dar. Entonces por lo menos en la
satisfacción, sí está muy clara, porque inclusive tenemos manejo de encuestas,
encuestas de satisfacción del cliente. Nosotros tenemos..., ósea los chicos tratan de
lograr que hacemos una encuesta de satisfacción del cliente por requerimiento en
general y a nivel gerencial también de la empresa. Eso se hace trimestralmente.
Entonces tratan de que, por ejemplo, el grupo que maneja estos grupos de clientes, se
esfuerzan porque ya saben que al trimestre va a volver la encuesta y no quieren salir
mal en la evaluación que hace el cliente. Entonces si hay mucha conciencia que
tenemos que trabajar en la satisfacción del cliente, en el cumplimiento de plazos del
proyecto y la calidad también. Somos bastante conscientes de ese tema.
¿Y cómo se logra que sean conscientes de esto?
Porque el jefe de proyecto se lo comenta al inicio del proyecto, y además porque al inicio
cuando se integra un nuevo miembro a la empresa, como parte de la inducción, se
encarga..., específicamente yo directamente en transmitirle la misión, la visión y los
valores de la empresa y el objetivo de la empresa que tenemos. Tratamos también de
que las personas, somos 21 personas ahorita, pero hemos tratado que todos tengan la
esencia, que necesitamos, es decir que sean responsables, que les guste la
investigación, que sepan, que sean conscientes. Es muy difícil, la verdad encontrar,
como la empresa es pequeña, un vago, un rezagado, alguien que no quiera cumplir, o
que le resbale lo que el cliente le diga. Ósea es muy difícil, porque tenemos un perfil que
estamos tratando de buscar en los que entran a la empresa.
193
¿Y cuál es el perfil, un poco generalizando de los responsables de la gestión de
los proyectos?
En todos los casos son personas de formación universitaria, que tienen conocimiento
en gestión de proyectos, ósea experiencia en gestión de proyectos. Que tienen
conocimiento en el manejo de las herramientas de gestión como los cronogramas, el
manejo de riesgos, la identificación de problemas, el seguimiento de proyectos. Que
también tienen conocimiento en tecnología también. Es decir, en todos los casos, las
personas que gestionan han sido programadoras, han sido desde abajo, ósea hay una
línea de carrera. No son gente que de repente estudio y se vino de frente y ahora son
jefes. No, todos han tenido..., entonces el tener el bagaje, el conocimiento a nivel de
programación incluso hace que tú también entiendas a tu gente y conozcas. Son
personas técnicas que en algún momento han decidido enfocarse en el tema de gestión.
Eso ayuda y facilita mucho.
¿Cómo se define el éxito en los proyectos entonces?
Generalmente por el cumplimiento de plazos, con una desviación del 5%. No te puedo
decir que todos los proyectos cumplen en fecha. Tratamos de que la desviación máxima
sea de 5% en cuanto a duración. Igual también por ejemplo que el proyecto haya tenido
mínimo un margen entre 25 al 30% de rentabilidad. Te cuento que nosotros cuando
costeamos, costeamos en un margen de 35, 40 más o menos, pero luego siempre que
terminamos el proyecto no ha logrado ese margen de 40 o de 35 con el que costeaste
inicialmente y esto baja porque has tenido que asumir, se ha estirado. Ósea hay varias
cosas y llegamos a un margen de entre 30 a 25 en algunos casos, pero nunca hemos
tenido al punto que ha llegado a una pérdida, pero es exitoso si por lo menos llegamos
eso.
¿Bajo esa definición, que porcentaje de proyectos termina con éxito? (30.25)
Habremos tenido en todos los 3 años que tenemos, un proyecto, ósea la verdad no
hemos tenido ninguno que nos haya generado un problema hasta el momento. Habrá
habido uno que por ahí no llegamos al margen de 25, o que nos pasamos del 5%, pero
no más.
¿Y qué porcentaje de proyectos termina retrasado, más allá de ese 5%?
Ósea nunca hemos terminado… que será… que se hayan retrasado más del 5%, hasta
el momento no tenemos. Ósea no hemos tenido ese problema, porque los proyectos
son cortos. Ósea no estamos metidos en proyectos de gran envergadura, con 6... ósea
194
son proyectos con periodo de duración un mes, dos meses, pero de esos tenemos
varios, en el mismo cliente con continuidad. Entonces al final estás un año con el cliente,
pero con proyectos de un mes y medio, dos meses y así. No hemos tenido esa
desviación tan grande como para tener que preocuparnos.
¿Hay casos en que un proyecto sea cancelado antes de terminar?
Hasta el momento no hemos tenido ningún caso. Ah, ahí vino un caso con San
Fernando que cancelamos el proyecto, antes de terminar, pero por tema de ellos.
Hacíamos algo que tenía que integrarse con otro cliente, y al final, el otro cliente nunca
estuvo preparado. Pasó un año y seguíamos igual. Ahora nos volvieron a llamar, pero
hemos desistido del proyecto, porque retomarlo significa para mí volver a revisar todo,
porque la gente que estuvo en el proyecto ya no está, y el cliente no quiere asumir ese
costo de retomar todo. Pero es el único caso en que ha sido cancelado antes de tiempo
y que no hayamos retomado.
Creo que mínima, una que otra observación y que finalmente no es un tema propio, por
lo menos en lo que es recurrente. Mira, yo recuerdo ahorita que hemos tenido un caso
de todo el… hemos ido el 2016, 2017, 2018 en Cavali hemos tenido un solo caso de un
error en un proyecto, fuera de una vez en producción después de un largo tiempo de
ejecución, que es el tema del tipo de cambio, el único. Pero de ahí…
En la sección de prácticas de gestión de proyectos, decía que estaba

completamente de acuerdo con la gestión de alcance, la gestión de cronograma,
tenía un 6 de 7 en presupuestos, 6 d e7 en riesgos, en que los proyectos terminan
a tiempo y en tasa de defectos coincide más o menos con los que estamos
hablando. Pero el que aplica Prácticas de Aseguramiento o Control de Calidad en
los proyectos marcaba un 4. Entonces en su opinión, ¿la empresa debería aplicar
más prácticas de aseguramiento de calidad? ¿Es suficiente con lo que se está
haciendo?
No, deberíamos aplicar más. Sí, ese es un tema que tenemos que revisar. Porque si
queremos… Hasta el momento no hemos tenido problemas, pero en la medida que los
proyectos sean más grandes si tenemos que aplicar prácticas de aseguramiento de
calidad antes de entregar al cliente. Como son… aseguramiento de calidad, no es
solamente funcionales con las pruebas funcionales, sino técnicas. Porque la idea es que
no encuentren problemas en el código. Por ejemplo, la aplicación de Sonar, aplicación
195
de herramientas que te digan, “Oye tu código tiene esto que no estás haciendo bien” y
son temas por ejemplo que hemos estado conversando ya con José de ese tema, de
que, si tenemos que aplicar herramientas que rápidamente nos digan una revisión de
código, estos problemas existen y los chicos lo solucionen. Porque estamos creciendo
y hay más gente programando y es más difícil la revisión.
¿Los proyectos dentro de la empresa tienen prioridades? Es decir ¿tienen alguna

forma de identificar este proyecto es más importante que este, o todos tienen la
misma prioridad?
Lo que pasa es que como están enfocados en clientes, hay un grupo de clientes
orientado por ejemplo con cada gestora. Dentro de los grupos si pues, tenemos
prioridades. Por ejemplo, en este proyecto de Portal vs este, este es más prioritario. Si
hay algún problema, saltamos al toque, porque va a haber un impacto mayor, mientras
que en el otro de repente se puede manejar. Ósea que quiero decir, que qué cosa marca
la prioridad del proyecto y la atención cuando haya algún riesgo, algún problema, es
como va a impactar eso en el entregable final y en la fecha final, ósea en esos temas,
cómo impacta eso al cliente. Y eso se traduce en cómo va a impactar esto en la
satisfacción del cliente. Entonces es eso lo que marca la prioridad, en caso de que fuera
necesario.
¿Esa prioridad está escrita en alguna parte?
Más que escrita como prioridad, está escrita como la misión. Ósea como nuestro
principal objetivo es la satisfacción del cliente, pues si hay algo que va a impactar eso,
pues toma prioridad el proyecto.
¿Y la lista de todos los proyectos que maneja la empresa, dónde está guardada?
Esa lista es un Excel, que lo tengo yo, en el que vemos los proyectos, quienes están
asignados, de qué fecha a qué fecha y vamos viendo ahí.
Según lo que marcó José, el portafolio de proyectos que maneja la empresa

incluye proyectos internos, ¿pero según lo que me están diciendo, eso no es
correcto?
Claro, él yo imagino que está viendo como proyecto interno, el hecho de la capacitación
por ejemplo de la gente, en las que están haciendo por ejemplo... por decirte todo un
equipo de chicos que está orientado a todo lo que es Nube, Open Shift, y están en un
tema que de 8 a tal hora se dedican a estudiar y a hacer pruebas de concepto. No tiene
un entregable final. El entregable final es que los chicos estén capacitados y se puedan
196
certificar en un momento dado Entonces él está viendo eso como proyecto interno, pero
no es tener un producto de software interno.
Bueno y la percepción sobre el desempeño general sobre la empresa está también

6 sobre 7.
Mira, en 2016, tú sabes que cuando empiezas una empresa, ¿qué esperas? Esperas
que tu rentabilidad, tu margen o tu inversión la recuperes en dos, tres años. No esperas
recuperarla o que tengas ganancias el primero o segundo año. Justo en el 2016 tuvimos
pérdida económica. En el 2017, duplicamos al 100% las ventas y generamos
rentabilidad acumulada, incluso después de la pérdida y en este 2018 es igual. Ósea
hemos llegado al 100% de ventas del 2017 en el 2018, lo cual significa que sí pues, al
final el tema del manejo de la rentabilidad de la empresa ha sido bueno. Eso es, por un
lado, ahora el habla también sobre el desempeño. Cuando hablamos de desempeño,
hablamos de la satisfacción del cliente. Hasta el momento, los clientes, los 5 clientes
que tenemos están satisfechos. Tenemos mucho apoyo y mucho... siento que hay
mucha colaboración, que los clientes nos ven como un aliado, más que como un
proveedor cualquiera. Ósea en los 5 hemos logrado eso.
¿Y el crecimiento del empleo cómo ha sido?
Empezamos con 3 personas el 2016 y hemos ido creciendo. Ahora somos 21 personas
y bueno somos los que atendemos a los 5 clientes, pero el crecimiento no ha sido…3,
7 y en el 2018 hemos multiplicado.
¿Y luego de todo esto, qué creen que necesitan para crecer como empresa desde
el punto de vista de gestión?
Mira, justo cuando hablábamos mucho con José sobre el crecimiento de la empresa,
siempre conversamos de los dolores del crecimiento, ósea qué pasa. A mí, mira si yo
mantengo esta empresa tal como está ahorita, me es rentable, es posible manejarlo
como lo venimos manejando, pero que pasa cuando tienes que crecer y tiene que crecer
¿Por qué? Porque la gente misma que forma parte de tu empresa lo necesita, porque
necesita nuevos retos. Tus clientes tienen nuevas necesidades de crecer más. Entonces
que requerimos para crecer. Esa es la gran interrogante, pero necesitamos justamente
un correcto manejo del portafolio porque si no manejamos, no tengo una visión clara de
cómo está cada proyecto económicamente, a nivel de recursos, a nivel de satisfacción.
Ósea de los objetivos que nos hemos planteado esto se pierde el control. Ahora lo
podemos controlar todavía, porque tenemos 5 clientes con proyectos no muy grandes y
una fábrica que es una producción de tipo outsourcing, una fábrica que va a producir,
197
pero cuando crezcamos en proyectos, si no hay una agestión de portafolio y una gestión
de proyectos, olvídate. Esto se va a volver inmanejable y al no tener una visión adiós.
Habías comentado al inicio que hay los proyectos de soporte, los proyectos de
desarrollo que son proyectos de uno o dos meses y los proyectos de software
Factory. En porcentaje de ingresos de la empresa. ¿Qué representa cada uno más
o menos?
Mira, el tema de desarrollo de software, donde está metida la fábrica es el 70%. El otro
30% es soporte. Es 70, 30 más o menos y en fábrica, desarrollo per se. De ese 70%,
te diría que el 80% es fábrica, porque tenemos 3 fábricas y el otro 20% de ese grupo es
proyectos en sí. Ósea quiere decir tienes el 100%, acá está el 30, 70. De ese 70, el 80%
es fábrica y el otro 20 es proyectos. Tenemos fábricas en tres empresas que nos rinden,
que al final la gente está más metida en fábricas que en proyectos per se. Ahora esa
fábrica incluso hace proyectos de retos, porque justamente nos han buscado por eso.
No nos dan los facilitos, sino los más complicados
¿Y dentro de este porcentaje cómo empresa se sienten satisfechos con esa línea?
¿Creen que debería aumentar alguno, disminuir alguno?
Queremos aumentar la gestión de... los proyectos en sí, más que fábrica. Ahora soporte
como tal, también queremos que crezca y va a crecer, porque estamos justamente
trabajando en este tema a nivel comercial de vender más el tema de soporte, porque
tenemos más capacidad instalada. Tenemos recursos orientados a soporte que no están
siendo utilizados al 100%.
198
¿Qué tipo de proyectos realiza tu empresa?
Desarrollo de software a medida y en ocasiones soporte a sistemas o proyectos que ya

vienen desarrollados por terceros, pero la mayoría de proyectos que tenemos es
software a medida. En qué sentido, ósea aplicaciones web que se necesitan todo
completo, componentes de integración, que se llaman a través de servicios web,
aplicaciones en Android, no comerciales sino más que nada a empresas con core de
negocios muy particular, y el tema de soporte. Ese es el fuerte. Después el otro es, la
empresa lo que brinda directamente son asesorías en la parte de lo que es arquitectura
de soluciones, ósea que componentes deberían participar en una solución de software
web, se puede decir, frameworks, APIS que se pueden utilizar que ya se hayan usado,
y en ocasiones tenemos ya componentes que se han hecho para ciertos otros
componentes de integración como son para SAP Business ONE, para Alfresco,
contenedor de servicios, hay APIS ya con temas de AUDs y todos los temas de
seguridad que ya se tienen, ahí hay componentes que se pueden usar. Normalmente
los piden por eso. Y lo otro he hemos estado haciendo, que hemos estado haciendo
bastante es maquetado de prototipos. Que eso ha sido el año pasado que es lo que
hemos estado haciendo más que nada. Dan una idea y hacíamos el maquetado
funcional, todo HTML incluyendo temas de UX y temas de usabilidad y eso se lo
entregábamos a otra empresa que ya hacía el desarrollo, pero más que nada es sastre,
ósea desarrollo de sistemas a medida. No tengo un producto, bueno tenemos un
producto recién qué es lo nuevo que se podría estar viendo, que es facturación
electrónica y otro es un componente que hemos visto que es, que nos han pedido
bastante que es un monitor de integración. Básicamente es que tengo el pool de
servicios, contra terceros que yo consumo, y esa información se ve en una trazabilidad
de cuáles son los objetos que me han caído, y el estatus de cuando yo los pongo contra
un sistema interno, y ese sistema interno me devuelve el resultado si es que se creó o
en qué estado creó la creación de ese pedido por ejemplo, una de las funcionalidades y
que ese cambio de resultados se refleje también en otro servicio del proveedor.
Entonces puedo tener un pool de servicios con terceros y tener un tema del estatus final
de ese registro en los sistemas internos de mi cliente. Eso es lo nuevo que hemos
querido hacer.
¿Cuántos proyectos tiene ahorita la empresa?
Ahorita corriendo, tengo 3.
199
¿Y en general, en promedio cuantos proyectos suele manejar?
Al mismo tiempo, hemos llegado a tener en promedio 5, en el mejor de los casos. Ahorita
tenemos 3, que ya se están como… Facturación electrónica es uno, el integrador que
tengo ahí, que es más o menos cierres. Pero más o menos son 3 que se manejan. En
las mejores épocas son 5. Ahora estos proyectos son 3 y algunos son de poco alcance.
No son tan complejos. Eso es algo bien importante, sino no podríamos tener tantos
proyectos. Ósea son bien puntuales. Ósea es necesito esto que haga esto, pero si ya
en tema de core y toma mucho tiempo y la gente con la que se va a dedicar, puede ser
un proyecto, que me ha pasado, cuando empezábamos, cuando la empresa empezó,
teníamos solamente dos proyectos al año, pero ocupaba toda la gente y era por 8 meses
o 10 meses. Si el proyecto es difícil por ejemplo el que hicimos en la maestría, el que yo
mostré. Ese duró 9 meses, y era 9 meses todos dedicados a eso. Ósea depende de
mucho de la complejidad del proyecto. Si son cosas pequeñas, chiquitas, de 3 a 5.
¿Cómo empresa, cómo gerente de la empresa cuáles serían los objetivos de

negocio de la empresa?
Rentabilidad para empezar, lo que se busca. El hecho de formar una empresa solos,
independiente fue el no trabajar para un tercero, escoger los proyectos que se necesitan.
Mi objetivo es que nos.… por un lado la empresa es que nos llamen para cosas bastante
especializadas, eso.
¿Hay alguna línea de mayor especialización en la empresa?
De nosotros, todo lo que es desarrollo Java Web. Ese es el core y funcional, ósea a
nivel funcional es que se define porque no tenemos muchos errores en implementación.
Mi etapa de análisis, de definición de requerimientos es bien detallada, ya sea para web
o móviles, que hace que no tenga reproceso. Ósea mis proyectos, aparte de que es con
el Estado que trabajamos en su mayoría, trabajamos con entregas, entonces una forma
de poder … y son llave en mano, ósea no es que te den el alcance inicial, sino tu defines
cuál es el alcance y sobre cuál tú vas a trabajar. Entonces mi fuerte sería que el alcance
que hacemos es bastante detallado, yo uso mapas mentales, que es el tema que he
estado manejando bastante y es con el que yo contrasto mi análisis y la valido contra el
usuario. Y de eso el reproceso que llegamos a tener es bien..., ósea el riesgo está bien
controlado. No ha habido casos en que he tenido que hacer un mes, mis delays de
atrasos pueden haber sido pues 2 días, o 5 días, máximo una semana, pero no tengo
atrasos de un mes o 15 días. No puedo, uno porque incurriría en penalidades, y lo otro
es que optimizamos, el tema de lo que es el uso, cada uno hace su parte y termina.
200
Esos son los dos fuertes que tenemos, el análisis funcional que se hace en detalle a
nivel de especificación de requerimientos, hacemos specs funcionales. No usamos
temas de casos de uso o ERS tradicionales, ósea usamos specs funcionales, ventanas
y especificación funcional del flujo, campos y todo el detalle que se tiene. Esos son los
dos fuertes. Eso y la construcción.
¿Y para este año cuáles serían los objetivos de la empresa entonces?
Para este año es hacer uno, modificar los productos que tenemos ahorita, esos dos que
te mencionó. Uno volverlo a escala a nivel de mype. Ósea ahorita tengo el integrador de
facturación electrónica con SAP business one, pero no tengo muchos SAP Business
One que quieran pasar, salvo que vean el tema que nosotros controlamos el tema de
errores de transacción con SUNAT, el preproceso automático del envío de la
información, porque SUNAT no te asegura la disponibilidad. Aparte del OSCE, ósea los
OSCE que van a trabajar, también está ese tema. Entonces la idea es que cambiar ese
producto a algo más, se puede decir para mypes, y se le escala, y eso va a demandar
tener otro tipo de arquitectura que es hostear y todo lo demás. Ahorita el objetivo es
productizar, ósea solo producto el integrador de facturación electrónica. Eso es lo que
tenemos ahorita.
¿Y a nivel de los servicios, de bueno todo lo que mencionaste, desarrollo,

mantenimiento, diseño de UX, para ti cuál debería ser el core de la empresa?
Nuestro Core, debería ser arquitectura de soluciones, porque desarrollo puede hacer
cualquiera, pero yo no soy de volumen, ósea no soy un software Factory. No tengo
programadores que están generando código, sino doy más que nada soluciones.
Entonces nuestro core debería ser netamente. Entrar como arquitectos, tener ese tipo
de solución, decir cómo se tienen que hacer las cosas y gestionar algún equipo de
desarrollo. Ese sería ahorita nuestro core. Por el tema de experiencia de las personas
que tenemos, que trabajan, ese debería ser nuestro core.
¿Y los objetivos de tu empresa quienes los conocen en la empresa?
Ahorita somos 5 personas en toda la empresa, de los cuales 2 somos socios. Entonces
los saben 5.
¿Y cómo se enteran de estos objetivos?
Normalmente nosotros tenemos lo que se llama. Hay una como que reunión mensual
acerca de qué es lo que se tiene que hacer como objetivos del mes, qué se tiene que
lograr y qué es lo que tenemos que alcanzar a hacer. Por ejemplo, en diciembre como
201
aprovechando el fin de año se conversó justamente de lo que se esperaba este año.
Darle impulso, bastante fuerza al tema de productizar esta solución de facturación
electrónica y qué es lo que queríamos hacer. Ósea los tres primeros meses de enero a
marzo, es tener ese producto, poder colocarlo, ver el tema comercial con algunas
alianzas que se puedan manejar, con otros terceros que puedan vender la solución y
después lo que seguía era sobre eso, plantear el otro escenario que es amarrarlo con
un e-commerce para mypes, porque si ya tengo la venta y la facturación, ¿qué es lo que
me falta? Que yo pueda hacer el pedido, si yo estoy entrando a consultar mi factura,
podría pedirle eso a mi cliente, entonces eso fue más o menos los objetivos que se
trasladen, es que cosas se quiere hacer, qué proyectos se vienen, que hay... por
ejemplo, hay soportes que se vienen en abril, que ya están como que, conversados,
entonces todo el mundo sabe más o menos que cosa va a hacer en qué mes. Porque
eso de tener como que vendrán o no vendrán proyectos, o tener no tener que hacer.
Nunca personalmente no nos ha gustado, tener, así como que no saber qué cosa voy a
hacer en el año y que la gente tampoco sepa, porque el tema, es decir. Ahora vas a ver,
por ejemplo, en el tema de soportes que se vienen, vienen cosas como con BIgData,
que nunca hemos hecho. Entonces se pregunta quiénes quieren investigar, quién hace
Haduk, quién hace otras cosas, como va a ser el tema de los algoritmos de machine
learning. Entonces de los 5 alguien dice yo quiero hacer, me interesa, entonces como
rama de investigación también se ve quienes son los que tienen interés. Ósea no
imponer, sino preguntarles quién es el que más o menos quiere de ese grupo y así, ósea
es reuniones mensuales que tenemos de lo que se avanzó, de lo que se tiene como
resultados, más que nada vemos resultados, y aparte de que estamos acostumbrados
a una cena o ir a comer como team una vez al mes. Es ya costumbre.
¿Ósea el mayor horizonte de tiempo para tus objetivos es actualmente un año?
Sí, ósea mi mayor horizonte es un año, que es lo que tengo que hacer. En base a eso
me tengo que mover.
¿y cómo evalúas si se han cumplido los objetivos?
Por la facturación, contratos cerrados y porque tienes unos leads de proyectos,

tentativos leads a que se puedan llevar a cabo y tengo los leads como que son más
seguros que se van a hacer. Por ejemplo, que ya sabes que está planificado, que está
presupuestado y ya se conversó a fines de año, y tienes solamente que esperar que
para tal trimestre está programado la contratación. Entonces la forma en que yo mido
el tema esto es justamente por el tema de las facturaciones esperadas.
202
¿Y en el caso del proyecto de Facturación electrónica, igual?
Ahí es como un proyecto de inversión, ósea se supone que la inversión inicial fue crear
este componente con los clientes de SAP Business One y todo el resto es un proyecto
interno, entonces, es las ganancias que se tenían con el otro proyecto, se supone que
la forma que yo estoy midiendo es cuanto se hizo de caja para invertir en el componente
para mypes y que tengo que tener una mínima cantidad de suscritos para abril. Entonces
si en abril no tengo esa mínima cantidad de suscritos, estoy mal dentro de mis
indicadores. Ósea es la única forma en que yo puedo medir que lo que yo pensaba
hacer como producto para mypes me es rentable. ¿Por qué? Porque si tengo
mensualmente que alquilar, ya no tengo el servidor que tú lo dejas en tu cliente, sino
que tengo que hacer yo el hosting y hacer el host es un pago mensual. Ahora el host
tiene que ser con una arquitectura que yo pueda crear varias instancias de manera
rápida. Entonces ahí va otro tipo de arquitectura tecnológica que tampoco sabía. Que
ahora también estoy aprendiendo, que es el tema de contenedores. Entonces manejo
contenedores y a eso lo complemento con el tema de DevOps, que es lo que manejo y
ya eso crea el ambiente, crea el entorno de manera automática para que escale rápido.
Entonces la única forma es que, si no tengo 3 suscritos al servicio de mype, el proyecto
no tendría sentido. Ósea mínimo 3. Ahora si hay menos, puedes darte hasta un mes
más en la holgura de que en el otro, aparezcan 6, pero en mi experiencia de hacer
proyectos, así de hacer productos. Si en los tres primeros meses, no tienes, no
recuperaste tu inversión por lo menos, no es viable, tienes que cambiar de rubro. Apunta
a otro tipo de proyecto.
¿Cómo consigue proyectos la empresa?
Referencias netamente, todo es contactos. Todos me conoces o es de un proyecto que

hicimos anteriormente nos contactan. No he hecho, eso es algo que también hago mal
que tengo que reconocer que hace 2 años atrás no hago campaña comercial. No voy a
ofrecerme, pero no voy a ofrecerme, no porque no quiera, sino porque no hay capacidad.
Capacidad en qué sentido, de que yo me dedique a eso o que encuentra a alguien que
pueda hacer lo mismo. Ese es el problema
¿Y quiénes participan en ese proceso de conseguir proyectos entonces?
Yo ahorita netamente. Ósea el que da la cara en los proyectos soy yo y es el que

referencian pues no, y así nacieron todos los contactos que tengo.
¿y en el caso de los proyectos internos como el de facturación electrónica, cómo

surgen esas ideas, o de dónde surgen?
203
Se puede decir por moda, ósea el año pasado hubo el tema de que todo el mundo
estaba pasando a facturación electrónica y hubo un contacto que tenía SAP Business
One, entonces fue una necesidad grande. Era que tenía sus partners que tenían que
pasar. Eran 4, 5 partners y contratar a otras empresas que están haciendo la integración,
como que no les... 1) ya habían tenido malas experiencias, y no querían trabajar con
esos otros profesores y nos dicen pues. ¿Por qué no hacen ustedes una solución?
Entonces dijeron había 4 clientes y había tanta plata, hicimos números y dijimos ya pues,
nos conviene y sería como que yo lo vi también como oportunidad para tener un proyecto
propio, ya un producto. Se supone que yo debería tener ya un proyecto con el tema de
gestión documentaria con CARC con la Católica, porque es un sistema que te maneja
todos los expedientes de conflictos. Cualquier notaría, cualquier empresa de resolución
de conflictos, o entidad podría usar el sistema, peor no he tenido el contacto con laguna
otra entidad que no sea CARC y aparte he tenido que pasar 3 años para recién yo poder
desligarme del contrato de confidencialidad, así que yo puedo por lo menos tratar de
hacer un tipo de solución parecida a lo que he hecho. Ya pasaron esos 3 años. Entonces
para no cometer el mismo error, de no poder usar una solución o reutilizar un modelo
de producto, con eso que fuimos fue un desarrollo directamente para un tercero, ósea
nosotros desarrollamos para una tercera empresa, y esa empresa va a tener la solución
para ellos. Pero ya la solución era mía. Ósea yo la puedo adecuar de qué manera.
¿Y cómo deciden qué proyectos ejecutar? ¿De un abanico de alternativas que

tendrían, cómo deciden?
Uno, ves bastante el tema de donde viene el cliente. Ósea si el cliente es buen pagador
y todos los temas de las experiencias previas con ellos, no hay temas de demoras, no
hay temas de cambio de personal, ósea sabes que el usuario líder siempre va a estar,
no te va a cambiar. Priorizamos mucho el tema de que el proyecto esté sano.
Priorizamos eso. Si son otros que sabemos que si han trabajado y que no son tan
buenos es como que si de acá un mes o dos meses. Pero más que nada priorizamos
por el tema de que el proyecto, uno) que el cliente sea bueno y que las definiciones se
manejen de manera controladas se puede decir, porque si hay clientes que te dicen
ahora quiero esto o lo otro., le mandas un control de cambios, te lo aceptan, pero igual
sigues amarrado y no puedes ver otro proyecto que te es o más rentable y muchísimo
más directo, porque ya tenemos cosas hechas. Entonces, ese eso, más que nada eso.
¿Y quienes participan en ese proceso de decisión?
204
¿Decisión? Ahorita los que somos socios. Otto que es el arquitecto de soluciones y yo
pues. Otto es el arquitecto de software, ósea la ve todo lo que es la construcción, ósea
el maneja el equipo de desarrollo y todo lo demás.
¿Fuera del cliente, de si es un buen pagador, hay algún otro aspecto o criterio que
tengan en cuenta para decidir?
Tecnología, ósea si es full java y MySQL, Oracle bienvenido. Si es algún tipo de

tecnología, por ejemplo, que nos han pedido, por ejemplo, haya cosas en php, hacer
componentes para Salesforce que si nos dicen quiero hacer eso, pero PHP no
manejamos, entonces no tomamos el proyecto. Más que nada nuestro expertise, ¿por
qué? Porque sabemos que lo podemos hacer controlado, no necesariamente rápido,
pero sé que tenemos poco riesgo de que falle algo o no controlemos algo de la
tecnología.
¿Esas decisiones o ese análisis quedan documentado en alguna parte?
De porque aceptamos uno, el otro no. Ahorita no. Ósea llega el requerimiento, llega el
correo o tenemos una reunión y te dicen quiero esto y la decisión es que es PHP o es
Python
¿Ósea no hay una lista de propuestas, llamémosle así?
De iniciativas, yo manejo un control de propuestas, de leads de proyectos, pero si no es

negociación, no entra ahí. No guardo la relación de cuantos he choteado, sino
solamente guardo la información de las que estoy como que en propuesta.
¿Y los proyectos que deciden nos hacer, es básicamente por el cliente, la

tecnología; algún otro criterio que pueda haber o que tomen en cuenta?
¿Para no hacer el proyecto?
Digamos que tienes dos proyectos, en que los dos clientes parecen estar al mismo
nivel de pagador y los dos son Java Web. ¿Cómo eliges?
Si lo conozco o no. Es decir, si a los dos los conozco, alguno de ellos siempre tiene
mejor referencia como resultado del proyecto. Si no lo conozco obviamente no me voy
a arriesgar tanto, pero si ya sé que son los dos y me están pidiendo. Ahora si tengo la
referencia de otro lado o el compromiso de que alguien te recomienda, entonces, dices,
quiero entrar en ese cliente, quiero tener esa oportunidad para que me conozcan,
porque de ahí un proyecto me va a abrir uno o dos, que es por ejemplo el caso de que
si nos pasan. Yo llego por ejemplo de referencia a ArgenPack, Argenpack quería un
205
sistema bastante bien suigéneris para hacer el tema de scoring de clientes. Dijeron ya
hazte un webservice y tenían otros proyectos que eran, ósea pagaban más, pero yo no
sé pues, dile intuición o lo que sea, decidí o decidimos en este caso con Otto, sabes que
qué nos vamos para Argenpack como estrategia y dicho y hecho, desde ese proyecto
nacieron 4. Tanto así que íbamos a cambiar toda la arquitectura .NET que tenían ellos
a puro open source, pero se supone que el arquitecto de soluciones que lo habían
contratado, cuando planteó esas ideas y un montón de cosas más, chocó con otro
gerente y este dijo “No, tú estás loco, chau” y lo sacó. Para que cambiar algo que ya
funciona. Entonces dijeron que no.
¿Han hecho proyectos de innovación como empresa?
De innovación, ¿te refieres a temas de startups?
No, a algún proyecto, usualmente se relaciona con proyectos internos, como es

el caso de la facturación, de alguna manera podría ser, aunque es algo que ya se
ha hecho en muchas empresas, pero de diferente manera.
La innovación en el tema de facturación electrónica podría comentarte que es la forma

de como amarrar el e-commerce con la misa plataforma. Ósea tu creas sin querer, sería
una pequeña intranet para una empresa, porque eso es lo que logramos hacer con la
empresa de SAP. Ósea me dicen yo quiero bajar mis facturas, quiero consultar y
descargarme pues todo lo que yo he trabajado contigo, entonces tiene la información de
lo que ha comprado, ¿no cierto? Entonces eso como innovación, a mí lo que se me
ocurrió es decir Ok, tengo un e-commerce que está ahí aislado, lo integro. Como tengo
con SAP Business One en ese entonces, tengo la lista de clientes, tengo la lista de
productos, entonces, sincronízame y yo te puedo listar y tu colocas el pedido. Saco mi
innovación, es Intranet para los clientes.
¿Y qué tan importante es para ustedes como empresa la innovación en sí?
Normalmente innovamos en todo lo que es temas de tecnología. No como solución de

negocio final, sino como lo último, bueno, buenas prácticas que se hacen en temas de
desarrollo y uso de frameworks, que se utilizan. Uno te agiliza el tema de la construcción,
¿no cierto? y siempre estamos innovando tecnología. Eso es de cajón, siempre, Ósea
no me quedo con el clásico java antiguo que se tenía, ósea paso de versiones de
framework que se utilizan, se evoluciona. Cambia el java cambia todo el tema de
arquitectura, ósea bastante vemos el tema de innovación a nivel de tecnología, APIS de
integración que salen, que es mejores, entonces es mejor trabajar con ellos, con lo que
está saliendo. Pero innovación de negocios, ósea ahorita personalmente no nos ha
206
nacido. Por ejemplo, quiero hacer esta APP para, no se pues, para que tengo ideas,
pero no tengo quien las desarrolle y ahora lo estoy volviendo temas de tesis. Por
ejemplo, webs que me permitan a mí concentrar a los servicios profesionales, ósea
gasfiteros, carpinteros, vidrieros, todos los que tienen que entrar a tu casa, pero no
sabes cómo validarlos. Ósea son ideas que salen y las estoy plasmando ahorita como
tesis.
¿Y en este proyecto de facturación electrónica, por ejemplo, qué porcentaje de

recursos de la empresa se destina a ese proyecto?
A ese proyecto destinamos dos recursos, el último trimestre. Ósea prácticamente Otto
y otra persona más hicieron esos proyectos. Somos 5
Ustedes son 5, tu como gerente, ¿Otto como arquitecto y tres programadores o

son otros roles?
Sí tres desarrolladores, analistas desarrolladores
¿Ósea Uno de los tres está asociado?
Uno de los tres está asociado. Los otros 2 han hecho lo que tenían que hacer para la
caja.
¿Y de los recursos económicos, que porcentaje se asocia a ese proyecto?
Ahí creo que el 20% es lo que destinamos.
¿Al momento de decidir iniciar un proyecto, se toma en cuenta los riesgos que
puede implicar ese proyecto?
Si, bastante
¿Qué tipo de riesgos?
Hay dos que manejemos nosotros, uno es nuestra capacidad de atención cuando inicie
el proyecto, ósea si es que tenemos el horizonte de que todo el equipo que se necesita
va a participar, como que decidimos ya no, genérame la orden de servicio, la orden de
compra y en una semana empezamos. Ese es uno. El otro es por el lado del cliente.
Que tanto está preparado él para iniciar el proyecto, porque ya nos ha pasado de que
quieren hacer el proyecto, pero infraestructura, recursos no tienen. Podemos empezar
el tema del desarrollo, pero dime en dónde te lo despliego para que pruebes. Entonces,
nos ha pasado que hemos terminado, como que, parando proyectos, solamente por el
hecho de que no tenían donde desarrollar o no estaban preparados. El otro es que tanto
está la coyuntura del proyecto. En el Estado, normalmente se manejan fechas medio
207
particulares. Ósea tú sabes que iniciar un proyecto en marzo, es tranquilo porque no
tienes presión y haces un tema controlado, planificado, pero si lo inicias en octubre,
noviembre, sabes que estás contra objetivos. Entonces cosas que tenías que hacer, en
3 meses, quieren que lo hagas en un mes. Entonces el riesgo de aceptar un tipo de
proyectos así es que no cumplas con las expectativas que tiene el cliente y quedes mal
pues. Solo por el tema de capacidad. Entonces esos, ósea para iniciar el proyecto es
que debemos tener la capacidad y uno normalmente no tenemos el riesgo de que
tenemos gente experimentada porque normalmente nosotros no... mi rotación de
equipos no es frecuente. Ósea no tengo que estoy cambiando. Mi team de desarrollo
dura o está con nosotros dos años. Ósea ahorita voy en la generación tres de
developers. Ósea empiezan conmigo, están un año, dos años y migran pues no y viene
otro team. Pero no tengo alta rotación que te dice acá a tres meses va y necesito otro
team.
¿Y a qué crees que se debe esa baja rotación?
No somos de negreros se puede decir. Tengo bastante cultura, de Google y Facebook.

Ósea nosotros trabajamos en un área de en un entorno de tú sabes que tienes que
hacer y hay capacitación. Ósea te indica lo que necesitas y están por objetivos entonces
cada uno trabaja de manera tranquila. Le enseñas tecnología nueva, aprenden, no se
aburre, no hace cosas así monótonas. El core del negocio normalmente cambia. Ósea
hay una especialización de un tema de negocio, entonces se involucra a la persona, no
solamente que programe, sino que piense. Entonces se sienten comprometidos y
además supongo que me son fieles. No los trato normalmente como si fueran
desarrolladores, sino se plantea la idea, se le hace ver como está y con Otto también
que los maneja, el tino, cómo los guía y como ya es tercera generación, las otras
generaciones con las que si hemos tenido feedback y ahí si es un tema directo porque
nos hemos encontrado en algún momento en algún cliente u otro lado, a veces ellos
mismos nos referencian. “Yo he trabajado ahí, son ordenados, saben que cosas tienen
que entregar”. El orden que viene de nosotros es bastante por el Estado, porque como
son entregables, documentos, cosas que se tienen que hacer. Ósea ahí hay un orden,
siempre sabes que tienes que hacer. Ósea no estás como que llegas y ya no sé qué
hacer. Si tienes algo que hacer. Y lo que pasa es que no estás detrás de ellos como
chiquitos y evolucionan.
¿y dirías que todos los proyectos que están realizándose en la empresa están
alineados con los objetivos de la empresa?
208
Que es seguir subsistiendo, obviamente que sí. Que seguir aprendiendo también.
Porque algo que si nos, no sé si te mencioné o no, pero la idea es que siempre
aprendamos. Muy aparte de que son netamente hacer sastres de software, estamos
como que fuese a la moda, ósea sale otro tipo de tendencia, otro tipo de necesidad
tenemos la facultad, por ejemplo yo he cambiado las interfaces de usuario de sistemas
antiguos que tenían, he mandado todo de nuevo y se han hecho con los nuevos
estándares de UX, con componentes en Bootstrap, temas minimalistas, ósea tenemos
esa de estás con el día a día y ese es un tema que se cumple, Siempre estamos como
que viendo. Por ejemplo, ahora estamos queriendo ver temas de BigData y ni mi team
ni yo tampoco somos ninguno de computer science, pero llegó un contacto mío, nos
habló de lo que se podía hacer y vimos que hay cosas que, si podemos manejar a nivel
de infraestructura de solución, de acceso, de implementación, de acceso a grandes
masas de datos y tenemos a quien poder ofrecerle cosas. Entonces eso hace que cada
año sigamos queriendo seguir existiendo. No voy a temas de volúmenes que eso ya
debería ser una parte, que ya crezca más, como yo estoy también con otras ideas en la
cabeza, no solamente quiero ver solamente desarrollo pues no.
¿Y qué conocimientos o experiencia, o cuál es el perfil de las personas

responsables de la selección de proyectos? En este caso tuyo y de Otto
Más o menos, experiencia en proyectos y experiencia en el negocio, porque si son

temas de seguros, por ejemplo, ahorita vengo yo de una reunión en Pacífico, pero quien
va ahí. El que ha visto temas de seguros, entonces más o menos para ver qué es lo que
quieren hacer. Por ejemplo, Otto ha visto bastante el tema de lo que es para los que son
trámites documentarios, entonces él es el que más o menos dice, va específica y
necesita. Perfiles, experiencia en el negocio, capacidad de análisis, conocimiento
técnico. Eso para nosotros es bastante porque depende de lo que te digan que hacer y
tu sepas si se puede hacer o no lo que está queriendo hacer depende de cómo definas
el alcance y finalmente si se hace o no se hace el proyecto pues no. Capacidad de
análisis más que nada, que defines y experiencia en el negocio. Esos dos.
¿y cómo gestionan sus proyectos?
De herramientas, cada proyecto tiene un Gantt de Desarrollo, ese Gantt está integrado,
ósea lo llegamos a integrar en un Trello. El Trello maneja alertas o maneja asignación
de tareas. Entonces cada proyecto tiene un Trello, ese trello tiene asignación de tareas
y cada tarea puede tener una lista de caducidad. Entonces el seguimiento de los
209
proyectos es a nivel de esa herramienta, del Trello, ósea todas las actividades que se
tienen que hacer se plasman ahí y se asignan responsables a cada una de ellas.
¿Quién es el responsable de proyectos?
En este caso, el desarrollo en sí Otto. Otto es el que ya dice quien hace que cosa y que
temas. Yo defino funcionalidades, alcance. Yo defino los sprints también, pero
finalmente quien hace, quien tiene que hacer que cosa en desarrollo es Otto. El ve el
equipo de desarrollo.
¿Y la gestión toma como base alguna metodología existente?
Yo estoy usando. Se puede decir un híbrido. Ósea uso PMBOK para hacer el tema del
gant, que son por fases y las fases más o menos la defino igual que RUP. Análisis,
diseño, construcción, pruebas, pero internamente son bloques de tareas grandes. Ahora
eso es en la planificación. Eso se plasma en el Trello y en el Trello está ahí como… En
el Trello la plantilla que tenemos, hay una fusión de cosas de Scrum con Kanban, y eso
es lo que tenemos como trabajo. Ósea que cosa va entrando y qué cosa va haciendo
para el tema de liberación de reléase y que cosa está en cada una de esas etapas. Cual
está en el Todo, el Do y el que se acabaron.
¿Y hace cuánto tiempo gestionan de esa forma?
Hace ya, desde que empezamos LA EMPRESA.LA EMPRESA empezó el 2013, si pues
si, 14, el 2015 empezamos ya más, así como que ley, si, ya son 3 años más o menos.
¿Cuánto tiempo entonces suelen durar sus proyectos?
Como te mencionaba el horizonte de los proyectos, el más pequeño es un mes, el

estándar son 3 meses y los grandes entre 9 a 12, esos son los grandes.
¿Cuáles son los que más tienes?
Los que más tenía antes, eran los de 9 a 12 con los que vivía tranquilo
¿y ahora?
Ahora son los pequeños, que son de 3 meses o un mes.
¿Cómo gestionan el alcance de los proyectos? Me decías que eso lo ves

directamente tú.
El alcance, si es en el Estado, es previa conversación y unas TDR y es llave en mano.

Ósea te dicen necesito que haga estas funcionalidades, estas cosas que están ahí. Ese
es el alcance de alto nivel. De ahí yo vengo a hacer. Ósea yo voy a hacer el tema de
210
aterrizar, eso ya a nivel de módulos funcionales que se están haciendo, reuniones con
el usuario, bastante conocimiento también del negocio que se pueda manejar y según
eso yo defino los requerimientos que van a hacer en base a ese horizonte de tiempo
que hay y al presupuesto. Experiencia se puede hacer de yo no puedo ofrecer cosas
adicionales sabiendo que me va a tomar más tiempo y me salgo del famoso triángulo,
tiempo, costo y calidad. Entonces si es que ya veo que sale de eso, entonces cambio la
lógica de la funcionalidad para que calce pues con el requerimiento. Eso es con el
Estado. Lo otro para definir el alcance con los privados es reuniones de las preventas,
y en las reuniones, normalmente yo lo que estilo es hacer un prototipado, un mock, muy
muy muy de alto nivel, por lo menos para que se definan cuáles son los módulos que
tendría y el workflow que soportaría el sistema. Ese es mi contraparte, porque contra
eso yo planteo el alcance, planteo el tiempo y planteo el costo, y eso es lo que también
planteo en el Contrato. Entonces mi alcance se controla a nivel de módulos funcionales.
Tengo que hacer un módulo que haga esto. El objetivo se cumple, entonces el módulo
se cierra. Entonces aterrizo bastante con el tema de los mockups. Uno por salud mental
mía, para no tener temas de falsas expectativas con el cliente, porque tú le puedes
ofrecer Voy a hacer un sistema de control de asistencia, o sistema de votaciones que
nos pidieron una vez, votaciones para el tema de elección de representantes de cada
área. Entonces ¿cómo va a ser? Como el voto electrónico, que vas y pones tu huella y
no sé qué, no sé cuántos, ósea todas esas expectativas que tenían los stakeholders que
se estaban manejando, los aterricé con mockups. Y le dije Tu alcance va a ser esto.
¿Cuánto presupuesto tienes? Tanto. ¿Cuánto tiempo tienes para hacerlo? También
tanto. Esa también es otra condición para definir el alcance. Es el presupuesto que
manejan ellos y en cuanto tiempo quieren la solución. Depende de eso también. Es muy
importante para poder decir, qué cosa se va a hacer.
¿Y este alcance, bueno en caso del Estado todo queda documentado porque está
en los TDR, pero en caso de las privadas, queda documentado de alguna forma?
En el documento de preventa y en el contrato. Ósea en el contrato, dice que cosa tengo

que hacer. Porque si me ha pasado el hecho de que decía, “No, pero todavía no
terminas”, “pero mi contrato dice esto y ya está”. Ya por experiencias prácticas eso ya
lo he heredado con las privadas que ya también sé en qué momento hacer el tema de
mandarle la carta notarial diciendo “Mira, ya terminó el trabajo. Está firmado el
documento, y te entrego la factura y no me pagas”
¿Y el presupuesto como lo gestionas?
211
El presupuesto, se supone que cada proyecto inicial y se tiene una caja inicial de que
ese proyecto paga supuestamente a tu equipo de desarrollo, pero si puedes manejar el
presupuesto de otro proyecto para pagar uno que todavía no lo pagan. Entonces se
supone que cada proyecto por ejemplo... antes si tenía centros de costo, porque decía,
proyectos web lo maneja este presupuesto con este tiempo. Los que yo manejaba de
consultoría, otro centro de costos, porque yo lo hacía o lo hacía de manera muy puntual.
Con el fin de poder tener ese control. Es decir, cuál es el que me rinde más, o haciendo
desarrollo de software o haciendo consultoría. Eso fue al inicio, pero como no fue tan
mediático el tema de ...que no todo el mundo te pide consultorías, se asoció a un solo
centro de costos y ya ha pasado por ejemplo el año pasado se fue al diablo todo. Ósea
plata que entraba era para pagar a todos. Si hubiera un tema de recurrencia, seguiría
con la forma con la que empecé en el 2014. Cada uno su centro de costos, desarrollo,
consultoría y soporte, porque soporte tenías u ingreso mensual. Entonces tenías a gente
dedicada, sentada, esperando que te digan algo. Pero eso ya está pues pagado.
Entonces ese centro de costos era para pagar a la gente que está ahí. Era un tema de
orden, pero ahora ya no se puede hacer eso.
¿Y cómo estiman el presupuesto del proyecto? (45:53)
Yo lo que uso fue hace tiempo, había una escala de Price Water House, que te decía el
rol y el costo por hora. Después descubría como llegaban a ese monto. Tomabas el
costo anual entre 14 meses y no sé qué, no sé cuántos, con un porcentaje de ganancia.
Entonces cada año veo más o menos cuál es el costo estándar en Perú, el costo de
consultoría. Entonces, tengo un Excel ahora. Debería tener un sistema a estas alturas,
pero no se tiene. Que es en el proyecto tu defines cuales son los roles que van a
participar. Entonces en el proyecto tienes un desarrollador, tienes un analista, tienes un
QA, tienes un experto en UX o un diseñador que solamente maqueta. Tengo esos roles
y tengo un DBA, por ejemplo. Entonces esos roles son los que van a estar en el proyecto.
Ya cada rol tiene un costo. Entonces ese costo por la cantidad de horas que se van a
dedicar mensuales a ese proyecto y por el costo del mes, multiplico eso y tengo el costo
del proyecto
¿Y cómo decides de estos tres programadores quien va a cada proyecto?
Como nunca hemos sido tantos, ósea no hemos llegado a más de 15, lo máximo que
he tenido de equipo de desarrollo han sido 10 a 12 personas desarrollando, es por
expertise, ósea si es un proyecto nuevo con un cliente nuevo pongo a alguien que tiene
experiencia y alguien que va a aprender. Entonces nunca dejo como que a dos nuevos
212
solos en un solo proyecto y los dejo ahí, necesito a alguien que le haga mentoría, sino
no aprende y así se da el tema de la asignación. Ya si es un proyecto bastante particular
que necesita bastante expertise, full senior, ningún practicante.
¿Y qué prácticas de aseguramiento o control de calidad se tienen en los

proyectos?
¿Prácticas?, en desarrollo, si hacemos pruebas unitarias cuando son cálculos que si

nos han pasado. Ósea por proyectos que se necesitan. El único mitigante de calidad es
mi etapa de análisis. Ósea es lo que yo cuido un montón, porque si yo no logro tener
afinado ese alcance funcional, porque yo también soy el que hace los prototipos y todo
lo demás, validado con el usuario, tendría bastante reproceso. Entonces la única
práctica que tengo es hacer un buen análisis.
¿y se gestionan riesgos en los proyectos?
Tenemos como parte de los entregables, si tenemos que definir cuáles son los riesgos
de cada proyecto. Ósea se definen y la gestión en sí no la hacemos nosotros, sino la
hace, en el caso del Estado que, si manejamos nosotros proyectos, hay un gestor.
Entonces el gestor, en este caso del cliente es el que hacía la medición de los riesgos.
Ósea todo el plan de mitigación, si se plasmaba, si están documentados, ósea si hay
dentro de los entregables que se hacen, se expresa eso, pero el que controlaba si es
que se activaba o no se activaba es el gestor de proyecto.
¿Y en los proyectos con las privadas?
No hay eso, no hay. Los manejo en el acta de constitución en un momento sí, pero están
como de manera de plantilla. Ósea están en el documento de acta de constitución del
proyecto, donde todos me firman el alcance, están los riesgos, y más que nada riesgos
son en la parte de lo que nos demoran a nosotros. Que no tengamos acceso a los
servidores o a los repositorios de información, el tema de los usuarios finales que no
estén disponibles para las pruebas o reuniones. Ósea esos riesgos los coloco ahí, como
diciendo mira yo te dije que acá había este problema y esta es tu responsabilidad, y
cualquier atraso es lo que se maneja, voy contra el documento de constitución, porque
ahí están los riesgos. Ósea es la forma de yo estar con mi paz mental tranquila.
Y de estas actividades de gestionar alcance a través de las reuniones, propuestas,

los TDR, elaborar el cronograma que me dijiste manejan un Gant y luego en el
Trello, esa plantilla para lo que es el presupuesto, y esta plantilla para lo que son
213
riesgos. ¿Cuáles son las actividades que consideras le generan mayor valor al
negocio?
Ahorita, ósea valor en toda la definición, es la definición del alcance. En verdad sería el
control que hacemos con el Trello, porque si no tendríamos esa visibilidad no podríamos
en qué momento necesitamos que alguien se intervenga para que ayude un problema.
Entonces tengo una ficha que está demasiado tiempo, ya venció su problema y en el
estatus del trello tú puedes escribir comentarios. Entonces esa información que está
ahí si no tuviera el Trello no sabría qué cosa pasó con ese problema. Ósea mi ayuda
memoria está ahí.
¿Quién tiene acceso a ese Trello?
Yo el jefe de proyecto, que sería el jefe de desarrollo que es Otto, y el team de cada
proyecto
¿Ósea hay un tablero por cada proyecto?
Sí hay un tablero de cada proyecto. Ósea cada proyecto nace como un, es la réplica de
mi repo en el Dropbox, aquí, por ejemplo. Este es LA EMPRESA. Tengo aquí las
carpetas, tengo gestión comercial y tengo por año desde que se creó LA EMPRESA.
Ahorita 2019 no tengo ningún proyecto nuevo. Todos son 2018 y tengo Clientes.
Entonces yo tengo un espacio de trabajo en Trello por cliente y por cliente tengo
preventa y proyecto. Ese es mío, pero cuando se vuelve proyecto esto se refleja en el
Trello y hay tres proyectos con tres códigos. Este es un proyecto, este es un tablero,
este es otro tablero, este es otro tablero. Entonces y cada uno de ellos tienes sus
actividades y si te das cuenta ya cada uno tiene una estructura: La cotización, el
contrato, el proyecto, el informe. Es un estándar. Vas al otro que está atrás, tienes lo
mismo. Acá no hay informe y es preventa creo, no me acuerdo. Entonces eso es lo que
nos da un orden.
¿Entonces la empresa como utiliza esta información para saber el estado de los
proyectos, el estado actual?
El estado actual de los proyectos, yo lo tengo, ósea yo lo manejo consultando el Trello.

Porque tienes un progress de cantidad de actividades y ahí veo con que estado está y
actualizo el gant porque cuando hago las revisiones de control de avance del proyecto
corro una actualización del Gant. Entonces mi Gant es lo que finalmente está. Yo facturo
por hitos, entonces esa facturación por hitos es lo que a mí me ayuda bastante a hacer
el control pues. Y además es la que me da vida, porque si no controlo el hito no cobro.
214
Entonces si manejo el tema con el Gant correr las entregas semanales, en qué
porcentaje está y que tareas estamos trabajando, y ahí hago el tema de o parto la tarea
o muevo una actividad a otra previa coordinación con el cliente. Ósea se negocia
alcance, esto no va y esto va al otro lado.
¿Tienen alguna forma de ver los proyectos de forma global, es decir algún sitio
donde tengan todos los proyectos y el estado de cada uno?
Vamos a tener, que ese es otro hijo que tengo, pero si, si nos han pedido y si necesito
también. Ahorita no hay. Ósea si tú me preguntas, hay que entrar a las carpetas y ver.
La idea sería que tú tengas un dashboard que digas ya cuantos proyectos tengo en cola
y cuánto es el porcentaje de avance y cuál sería de mi atraso. Que si es lo que nos ha
pedido. Cuando lo tenga ahí te lo muestro.
¿y los empleados, bueno los desarrolladores, saben cómo su proyecto se alinea

con los objetivos de la empresa o mejor dicho saben cómo contribuyen a los
objetivos de la empresa?
No sé si será directamente, ósea si saben, pero el tema es que saben que, avanzando
las cosas, ósea están cumpliendo con los temas de investigación, saben que tienen que
investigar, saben que tienen que hacer algún tema en producto, entonces saben que
para tal fecha tienen que estar tal proyecto pues. Entonces supongo que se sabe
internamente si cumple o no cumple, porque cumplieron el hito en la fecha que se
planificó. Entonces si entregué mis cosas al tiempo. Porque si se tiene que hacer esta
semana, se tiene que entregar esta funcionalidad y lo hacen. Y si saben de qué no van
a allegar te lo dicen. Por lo menos mi equipo lo dice. Dicen Oye tengo problemas con
esto y ya van varios días y no la hago.
¿Y los responsables de la gestión de todos estos proyectos es la misma persona,

es otro en todos los casos?
Ahorita sí. No he llegado al caso. No, sí hubo antes, hubo dos personas más que
gestionaban, pero cuando los proyectos eran más y ya un poquito, ósea eran regulares
y más que nada porque el proyecto en sí te pedía el rol y no podíamos ser. Ósea yo
podía fácil decir, ya, yo hago de los tres proyectos yo, pero no, por clausula decía, no
tiene que ser una persona distinta por el contrato que está ahí y tiene que venir esa
persona. Entonces tenían que ser distintas. Mi experiencia trabajando con terceros es
que más o menos que fue bastante complicado conseguir esas dos personas más. ¿Por
qué? Experiencia y el tema de la forma de trabajo. Ósea, llegas a un punto, en que tú
215
simplemente llegas, te sientas, divagas y alguien te entiende y hay otras personas que
no pues, que tienes que explicarle más detalle las cosas y se hace más complicado.
¿El costo también era un inconveniente para conseguir a las personas?
El costo, normalmente para esas personas, como ya venía presupuestado en el

proyecto. Ósea el tema de cuanto costaba tenías un presupuesto. Un rol que le puedes
pagar a alguien es el de 3500 soles o 4000 soles y sobre tú buscabas a la gente y eso
te daba el costo. Si es que no hay ese proyecto, los contratos que yo manejaba también
eran por el proyecto, ósea, las que están en planilla en LA EMPRESA ahorita, son como
los fijos que son los que yo sé que son de horizontes de uno a dos años que te decía.
Ósea mis practicantes todos están en planilla. Ósea no hay ninguno por recibo.
¿Me dijiste que tenías 3 desarrolladores? ¿Los tres son practicantes?
No, ahorita no. Ósea hay solamente uno que es practicante
Dos profesionales y un practicante.
Sí, pero ellos que están, así como que ya tienen asegurado su continuidad. En cambio,
esos que estaban ahí si eran a demanda, porque decía, el proyecto dura tanto y es
tanto. Si sale algún proyecto nuevo, renovamos, sino hasta ahí nomás.
¿Y cómo defines éxito en tus proyectos entonces?
Éxito es para nosotros que se terminó el alcance que dimos, nos pagaron en la fecha
que esperábamos y te llaman para un siguiente proyecto. Eso es éxito para nosotros.
¿Bajo esa definición, que porcentaje de tus proyectos termina con éxito?
Yo diría que todos, porque no he tenido proyectos que han muerto, que han sido como
que pucha, lo hizo él y estaba mal. Se puede decir un tema de egocentrismo, pero no
me gusta que hablen mal de mí. El tema es que de alguna manera u otra si ya ves que
estás así con problemas, entonces lo que hemos hecho nosotros es salvaguardar
nuestro nombre. En proyectos que nos han tocado de ser terceros, muchas veces
nosotros hemos hecho cargo de cosas que no teníamos que hacernos cargo solamente
con el fin de que el proyecto sane.
¿Y qué porcentaje de proyectos termina retrasado entonces?
Retrasados, yo diría que un 105 y eso, pero no es un retraso de un mes pues, ósea tu
Gant se mueve máximo dos semanas.
¿Dos semanas para los proyectos de 3 meses?
216
Claro, en el de los otros no se puede porque cada mes es un hito y ese se cierra. Ahora
si es que hay un tema de cambio o algo así, son temas de adendas, pero ya es de mutuo
acuerdo, entonces no se puede decir de que está atrasado, sino es un cambio que se
pidió, se hizo un tema de tiempo y un tema de otra facturación. Ósea es una adenda de
contrato.
¿Han tenido proyectos que tengan que cancelar antes de ser terminados?
No, ninguno, no nos ha pasado, porque no sé qué pasaría, no sé si tendrías que devolver
la plata que te han dado, o no sé. No me ha pasado. De que estás así y te dicen, sabes
que ya no quiero que lo hagas, no. Es más, nos han dado proyectos que supuestamente
iban a cancelar con proveedores y decían que los contraten a nosotros para terminarlos.
Ósea a ese nivel han llegado en algún momento.
Muy pocos, ósea los soportes que hay, que haya temas de inconvenientes, ósea pueden
aparecer bugs o problemitas de validaciones o algo así, bastantes puntuales en los dos
primeros meses. Después de eso ya no hay. No hay temas de reportes de inestabilidad,
o de que no funciones, o de que se cayó el sistema de la nada. Muy poco. Aparte de
que manejamos proyectos que no son tanto volumen.
¿Manejan prioridades para sus proyectos?
Yo sí.
¿Cómo las manejan?
Cuál es el hito más… uno critico a cubrir o dependiendo de cuál es el hito que va a pagar
más. Me muevo por la caja. Ósea yo priorizo por eso. Si tengo un hito que es bastante
comprometedor a nivel económico, ósea trato de buscar que pues ese se cumpla y los
otros que están ahí como que en consecuencia trato de negociarlos, para poder hacer
un cambio de fecha o algo de entregas o hacer un delay.
¿Es una prioridad que se fija…?
En mi caso es facturación
Ya, ¿pero es una prioridad que se fija conforme va a avanzando el proyecto?
Correcto
¿No al inicio?
217
No, al inicio es llegan todos y el que llegó primero por calendario. Se respeta el gant.
Ese sí no hay tema de prioridad, pero si son dos a la vez que están empezando, los dos
empiezan. Ya que en el camino diga este no y otro sí, es ya otro tema.
En la encuesta respondías y ya me lo habías mencionado en la conversación que,

durante el año pasado, el rendimiento general del negocio está por debajo de sus
principales competidores.
Claro
Sin embargo, a la pregunta sobre si cumplió con las expectativas y que tan
satisfecha estuvo la gerencia con el rendimiento general del negocio tiene un
puntaje de 5 sobre 7 que es bastante bueno. ¿Puedes comentar un poquito más
de eso? Cómo es que están satisfechos, a pesar del rendimiento del negocio.
La idea es crecer cada año, pues. Y el punto es que lo que hemos logrado hacer es
dijimos vamos a hacer tales proyectos, vamos a hacer tales cosas, tanta dedicación, y
cumplimos con lo que se tenía que hacer. Ósea pero el hecho de decir mira este año
hicimos tantos proyectos, ahora tengo que hacer más volumen, porque antes si veía
eso. Si este año hice tanta facturación, este año tiene que ser por lo menos 50% más,
pero ya como venían las cosas desde el año antepasado, desde el 2017, ya se venía
medio complicado. Lo que se planteó para el 2018 fue mantener lo que tenemos
haciendo y hacer los proyectos que están ahí pues. De hecho, que hay otros
competidores que directamente que son Factory, otras mypes que son de desarrollo que
se dedicaron al rubro por ejemplo de cajas municipales. El año pasado ha habido
bastantes que han hecho muchos proyectos y yo por no irme a otro rubro no aproveché
eso pues no.
¿Y por qué decidiste eso?
Porque no tenía contactos en el tema de las cajas.
¿Y un poco resumiendo todo lo que hemos conversado, en tu perspectiva que

crees que necesita en temas de gestión para crecer la empresa?
En temas de gestión, que no dependan tanto de mí, para poder delegar cosas. Ósea lo
que mencionabas, la visibilidad, el tema de cómo se está haciendo la evolución del
proyecto. Más que nada para mí es el seguimiento por hitos, porque es el que mueve tu
economía para que como empresa sigas subsistiendo. Ósea si la empresa no facturar,
se cae. Y el otro sería a nivel de gestión, desligarme que dependan de mí. Eso sería
una herramienta que se tenga pues.
218
219
Ok, Raúl, cuéntame. ¿Qué tipo de proyectos realiza tu empresa?
Bueno, vemos todo lo que es proyectos de desarrollo de software para dos frentes. Uno
como proveedor, digamos de otras empresas de TI, que tercerizan con nosotros
proyectos. Estos proyectos digamos tienen un alcance ya definido por esta empresa, y
tercerizan, si bien tercerizan todo el ciclo, desde análisis, diseño. Pero digamos ellos si
se encargan de la comercialización del producto. Y el otro frente es con empresas
pymes, pequeñas empresas que no tienen digamos áreas de sistemas, de software y
se les brinda o se les hace un desarrollo personalizado.
¿Cuántos proyectos maneja al mismo tiempo la empresa en promedio?
Bueno, por lo general 2,3. Ahorita estamos en 4 por ejemplo. Estamos bien
¿Y cuánto es lo máximo que ha manejado?
Lo máximo es 3, 4. Felizmente si se ha mantenido. Se ha bajado hasta 1. A veces ha

sido 1 porque era muy muy grande y era en los inicios cuando no se tenía tanta gente
que apoye.
¿y cuáles son los objetivos de la empresa, los objetivos de negocio de la

empresa?
La visión que se tiene como empresa es llegara a las empresas pymes. Que se quiten
digamos o mejorar la idea que ellos tienen de la tecnología. Que ellos vean la tecnología
más como un aliado con ellos que los apoye en toda la parte de mejora, de
automatización de procesos y no sea tanto algo que le tenga que imponer a la empresa,
porque muchas veces las tecnologías o las mismas empresas venden productos muy
específicos o muy grandes y la pequeña empresa solamente necesita un módulo, por
ejemplo, un ERP. Un módulo del ERP que cuesta mucho y ellos solamente necesitan
un módulo, pero lo tienen que comprar porque no hay otras opciones. Entonces la idea
es que ellos vean más la tecnología como un aliado para ellos.
¿y cuántas personas trabajan en tu empresa? Según la encuesta están entre 1 y

5 personas.
Sí, nosotros somos, digamos como empresa, personal 2 y se trabaja con 2 proveedores
más. Ósea en total serían como 4 o 3, porque los proveedores son medio, medio, medio
tiempo.
220
Ah ok ¿cuándo dices proveedores son programadores contratados?
Claro, ajá.
¿Y de estas personas que trabajan en la empresa, quienes conocen ese objetivo

que acabas de decir?
Felizmente todos
¿Todos lo conocen?
Si bueno, somos ahorita dos nomás
¿Cómo se les comunica o cómo se enteran de esos objetivos?
Desde el inicio del proyecto, como la persona está mejor dicho desde el inicio que se
tiene, ósea desde que se inicia el proyecto. Ósea no de frente va a la parte de desarrollo,
sino cuando se está haciendo, por ejemplo, la propuesta o el trato con el cliente, ya se
le va explicando que puede salir un cliente, digamos con esta visión. Esto es lo quiere
para… no sé, lo que haya definido el cliente. “Yo quiero mejorar mis ventas”. Entonces
le estoy haciendo tal Sistema. Se le trata de explicar digamos todo ya el contexto, no
solamente la parte técnica.
Tu objetivo como empresa, si te entendí bien es llevar la tecnología a las pymes.

¿Este objetivo como tal, lo conocen las personas de tu empresa, ósea saben de
qué ese es el objetivo de la empresa? ¿Se sienten identificados con eso?
Si, si lo conocen. Como le digo, se trata que estén desde el inicio del proyecto, entonces
cuando se inicia la relación con el cliente nosotros nos preocupamos que si se satisfaga
digamos, no solo lo que el cliente quiera, sino lo que el cliente en verdad necesita.
Porque de repente nosotros o el cliente viene con una idea muy grande. Entonces en
las reuniones, las conversaciones que vamos teniendo, vamos formulando una... o
diseñando una solución, pero más acorde a lo que cliente, no solo necesite, sino también
esté a su alcance. Entonces ahí va conociendo digamos la persona que nos está
preocupando no tanto por vender solamente sino por satisfacer en verdad y que vaya
alineado a lo que el cliente quiera.
¿Quién definió ese objetivo de empresa?
Yo lo definí
¿Solo o con alguien más?
Sí solo.
221
¿Cómo evalúas si se ha cumplido ese objetivo entonces? El objetivo de la
empresa
Bueno, más que todo con el cliente. Con el resultado que al final tiene el cliente, porque
si se siente satisfecho con lo que ha conseguido y también desde mi perspectiva, en
toda la negociación, en las reuniones que se tienen, si yo siento que el cliente si llega a
sentirse digamos satisfecho con lo que se le está dando. Ya sea en las conversaciones,
en el trato, en la cordialidad.
Fuera de este objetivo, que como tú mismo lo dijiste es la visión de tu empresa.

Hay objetivos más específicos, sean formales o informales dentro de la empresa.
Ah bueno, hay objetivos, digamos que son anuales. Incrementar las ventas…
¿Cuáles son los objetivos de este año por ejemplo?
Los objetivos es este año, bueno, justo los tengo acá. Bueno los objetivos digamos de
esta empresa es incrementar cierta cantidad digamos las ventas, incrementar también
el personal, de ahí otro era sacar, bueno incrementar las ventas ofreciendo nuevos
servicios también nuevos servicios y nuevos productos. Ahorita que recuerde, digamos
también mejorar también la captación de clientes, relanzando la página web y algunas
redes sociales. Digamos mejorar la imagen de eso y bueno como decía ofrecer nuevos
servicios, ya sea por medio de algunos paquetes que se definan. Eso y bueno, algo más
físico, mejorar el espacio de trabajo amoblando un poco más la empresa.
¿Esos objetivos están escritos en alguna parte o solo en tu cabeza?
Sí están escritos. Esos son los objetivos que ahora son los SMART, que son específicos,
medibles.
¿Y cómo evalúas el cumplimiento de esos objetivos al final del año?
Bueno, al final del año, hay algunos que si son… Bueno algunos que van a ser a final
de año porque son a 12 meses, otros si son, por ejemplo, a lo de contratar a gente es
uno cada semestre. A mitad de año se tendría por lo menos una persona más y en el
otro semestre otra más. Bueno, así está definido, por trimestre y semestral.
¿Existen proyectos internos en la empresa? ¿Es decir desarrollan proyectos

planteados por ustedes mismos?
Bueno ahorita, si se puede llamar proyecto es una mejora, pero no es de tecnología, es

una mejora digamos de organización de la empresa. Esa está ahorita y bueno, al inicio
si había algunos productos que se tenían en mente, pero todavía han quedado ahí. No
222
se están desarrollando, pero la idea si es sacar algunos productos en base a lo que
lleguemos a obtener como información de nuestros clientes pymes. Llegar a tener como
que un producto que cumpla las necesidades básicas y poder venderlos. Algo estándar
digamos, porque ya sabemos que ellos necesitan esto. Porque las pymes, al menos las
pequeñas empresas siempre necesitan temas de tipo, similar a ERP, pero más
personalizado, stock, almacenes, facturación, compras, pero brindarle algo más acorde
a lo que en realidad necesita y más personalizado.
¿Cómo consigue proyectos la empresa?
Ahorita, ha sido por recomendaciones básicamente. Por recomendaciones y bueno

claro, recomendaciones ya sea por amistades o por otros clientes y por trabajos
anteriores. Y justo como le mencionaba uno de los objetivos de este año es ordenar
mejor la parte de los servicios y productos que se van a ofrecer y así captar, poder hacer
ya la captación de los clientes, ya sea por marketing digital, por e-mailing o buscar una
estrategia para poder captar clientes y poder crecer.
¿Quiénes participan en el proceso de conseguir los proyectos?
Ah, no ahorita yo básicamente. Yo y como le dijo, básicamente por referencias. Ósea

ahorita digamos en la parte de captación de clientes estoy yo, netamente yo.
¿Cómo decides que proyecto ejecutar? ¿Si hubiera dos posibilidades de

proyectos cómo decides cuál hacer?
Más es por el tema, digamos de…, bueno al menos lo que pasado es por temas de
alcance de proyecto, pero desde el lado un poco técnico. Porque algunas cosas cuando
es un proyecto muy grande, ya involucran… ósea el conocimiento digamos que, si se
tiene, pero armar digamos servidores, configuración de servidores, balanceadores.
Digamos eso es algo que se puede hacer, pero es un poco más complejo y hay otros
proyectos que digamos son más pequeños que en ese momento se pueden priorizar,
ya sea por temas de alcance del proyecto. No, no sería tanto por alcance, sino por
complejidad digamos del proyecto, se puede priorizar por complejidad o por temas
también a veces han salido por temas de recursos, porque recurso y/o tiempo porque
ellos querían a veces empezar… querían que la propuesta esté esta semana y la
siguiente semana ya empezar, pero tampoco no se puede tanto porque digamos ya hay
algunos proyectos en curso y el personal no se puede liberar. Al inicio sí, decía sí pues.
Pero luego no… ósea se comenzó a algunos descartar por esos temas. Ya que sea muy
complejo o por temas de inmediatez más que todo de la otra empresa, del cliente.
223
¿Entre proyectos pequeños o complejos, cuáles prefiere hacer la empresa?
Ahorita se han hecho. Ósea felizmente si se han hecho ambos, ósea yo si preferiría
hacer algo más complejo. Porque nutriría más al personal de conocimiento y de
expertise de algo más que sea de configuración, de complejidad, si nutriría más a la
empresa. Siempre que sea de todas maneras, más para una pyme.
¿La decisión de hacer o no el proyecto es directamente tuyo o alguien más

participa?
No, ahorita mía directamente.
¿y esos aspectos, esa evaluación, queda documentada en alguna parte? ¿o es

un proceso que simplemente se hace, se suele hacer así, pero no queda
registrado?
Cuál, la decisión de…
Ese análisis de complejidad por ejemplo que mencionabas.
Ah, no, ese sí no se tiene documentado. Se tiene digamos la propuesta, pero no digamos
porque se eligió tal...
¿Hay un registro de propuestas que no se han hecho?
Sí, si se tienen varias que no salieron
¿Pero hay un registro ordenado o formal?
Ah bueno, se tiene. Digamos ordenado por los clientes. Por los clientes si se tiene las
propuestas. Por cliente, proyecto, las propuestas.
¿Hay proyectos que te llegan y decides no hacer?
Si, han llegado por ejemplo temas de páginas web o cosas así. Se decide no hacerlo.
¿Hay proyectos de desarrollo de software que te hayan llegado y que decides no

hacer?
Si, bueno siempre se ha decidido hacerlo. Otra cosa es que no hayan salido, pero si se
ha decidido hacerlo.
¿En qué tecnología trabaja la empresa?
En Java, vemos en Java.
¿Si te llega un proyecto de otra tecnología que no sea java?
224
Si la hacemos hasta…hemos hecho… priorizamos digamos lo que es Java, pero
también hemos visto .NET y un poco de PHP, pero si es para hacer una propuesta, algo
desde cero, una solución desde cero, si se propone por ejemplo Java. Bueno la
tecnología que más conocemos, bueno que tenemos más experiencia.
¿Ósea si te viniera una propuesta de un proyecto desde cero, pero que no es en

Java, la hacen o no la hacen?
Si llegamos a tener un proveedor digamos de confianza, sí. Porque justo eso pasó para
hacer uno en .NET. No se tenía a la gente, pero si un proveedor digamos de confianza
que veía .NET y se hizo la propuesta, bueno al final no salió, pero si se iba a lanzar. Si
salía claro se hacía.
Me comentaste que no habían…, hasta ahora a nivel de proyectos internos solo

había ideas, no se habían hecho. ¿Entonces la empresa no ha realizado todavía
proyectos de innovación o sí?
De innovación, propio de innovación bueno, sí ósea, es que ahí depende que consideren
innovación.
¿Qué consideras tú proyectos de innovación?
Ah ya, digamos para empresas que no tenían, digamos ningún sistema, si se les ha
hecho y para ellos ya hemos hecho algo innovador, porque para ya es una manera
nueva digamos de trabajar. Ósea si se han hecho eso. Pero digamos que si… es que,
para pequeñas empresas, al menos nosotros tenemos ese concepto de innovación. No
tanto algo con una tecnología nueva o algo última tecnología. Por ejemplo, se han hecho
unos proyectos con manejo de puntos de venta y bueno para esa empresa claro fue
algo nuevo, novedoso que recién entraban con esa tecnología al mercado.
¿Y qué tan importante es la innovación para la empresa?
Sí, digamos es lo que nosotros tratamos de… no sé si inculcar o darles a entender que
es necesaria esa innovación a los clientes, porque no solamente es automatizar. Ósea
que no lo vean como una automatización de procesos, sino como una oportunidad para
hacer otras... ese tiempo digamos que no lo están involucrando en algo operativo poder
hacerlo en algo que sea más ventajoso para ellos, para aumentar las ventas o para
verificar que es lo que pueden mejorar. Ósea nosotros si consideramos que ese es
nuestro… ósea algo muy importante que lo tenemos en cuenta.
¿Y al momento de iniciar el proyecto o evaluar la propuesta para iniciar el

proyecto, se toma en cuenta los riesgos que implica hacer el proyecto?
225
Como riesgo se toma, ósea el riesgo que tomamos es si lo podemos cumplir en el plazo
que la empresa requiera. Más que todo, no en el plazo, sino en el inicio, fecha de inicio
que ellos tienen.
¿Algún otro tipo de riesgo que se considere?
Como le digo no, si la tecnología no es la de nuestro digamos expertise, ese sí, para
nosotros es un riesgo, porque si es algo, como no depende netamente de nosotros, sino
de un tercero, eso también sí lo consideramos. Lo consideramos como riesgo.
¿Dirías que todos los proyectos que están haciendo actualmente se alinean con
el objetivo de la empresa?
No, algunos no, porque son… Bueno, es que como que la visión de la empresa es más
enfocada a las pymes, pero también se tienen proyectos como tercero de otras
empresas de TI. Ósea estos proyectos, si bien es cierto, no están alineados digamos a
la misión, pero si nos generan caja, nos genera ingreso y nos genera que la gente,
digamos aprenda más, porque por lo general estos proyectos son un poco más
complejos. Entonces sirve como buena forma para seguir aprendiendo, seguir
mejorando digamos los skills. Pero claro, esos proyectos no están alineados a la visión,
pero si están alineados a lo que nosotros ofrecemos, porque son como que digamos
estos dos frentes. Por eso no sé si están o no.
¿Qué porcentajes de proyectos son actualmente para pymes y cuantos son con
terceros?
Ahorita para pymes será el 20% y el 80% es para TI. Y nosotros justo, para este año, lo
que se busca es captar clientes en pymes. Porque los que han llegado han sido más
que todo por referencias. Y no está mal, solamente que queremos nosotros enfocarnos
más a la visión. Igual los de TI siempre van a haber, eso es lo bueno, porque siempre
necesitan algo los de las otras empresas. Pero las pymes si hay que buscarlas más.
Y las personas responsables de la selección de proyectos, ósea tú. ¿Qué

conocimientos y experiencia o mejor dicho cuál es tu perfil, que conocimientos y
experiencia consideras que tienes que te ayudan en este proceso de conseguir
los proyectos y definir qué proyectos hacer?
Bueno, en sí, en verdad ahí ahorita digamos, ese es cualquier proyecto digamos que se
pueda desarrollar algo. Es casi, y bueno digamos, si te tendría que definir algo en
específico, si podría ser algo de por ejemplo de seguridad. Eso sí se podría ver o temas
226
transaccionales también. Digamos son ahorita, digamos lo que yo conozco, entonces
digamos en base a eso puedo generar o puedo hacer una propuesta.
Bueno, tú eres Ingeniero Informático
Sí, pero por ejemplo si vienen y necesitan cosas de BI por ejemplo o veo que necesitan.
No veo, sino al final ellos quieren algo de BI, explotar data. Como que eso no, porque
digamos, no, yo no lo conozco. De repente puedo tercerizarlo con alguien, pero para
elaborar una propuesta ahí no me sentiría bien.
¿Fuera de tus estudios como Ingeniero informático has tenido alguna formación
adicional que te ayude para la empresa?
Adicional, bueno los diplomados que he llevado.
¿De qué has llevado?
En el CIDE, digamos del Crea y crece. Eso sí me ha ayudado bastante para digamos
saber cómo manejar más la empresa. Digamos desde la parte más administrativa,
digamos organizacional de la empresa. Luego digamos, algunos talleres de liderazgo
que he llevado, es más para las habilidades blandas tanto con el equipo, bueno con el
personal, el cliente y los proveedores. Saber entenderlos, que tienen sus tiempos. Más
por el lado humano. Eso también si siento que me ha servido.
¿Y cómo gestionan los proyectos en la empresa? ¿Se basan en algún estándar,

una metodología, tienen una forma de trabajo común?
Sí, ahorita digamos se maneja, si bien es cierto en base al PMBOK, por digamos eso ha
sido también la como yo le visto cuando estaba trabajando para otras empresas.
Solamente que no se aplica exactamente todo lo que pide el PMBOK. Se ha tratado de
ver digamos que es lo que exactamente si le es más importante al cliente. Por ejemplo,
si manejamos documentos de requerimiento, por ejemplo. Para la parte digamos de
entregables si manejamos documentos de requerimientos, análisis, diseño sí, pero no
entrando mucho a… por ejemplo a casos de uso no trabajamos, pero si manejamos
diagramas de arquitectura, de componentes, de despliegue por ejemplo y manejamos
manuales de usuario en caso que haya una parte visual, de instalación sí un pequeño
documento de resultados de pruebas. Eso lo manejamos con el Project y para las
actividades digamos diarias utilizamos una herramienta que se llama Asana, que es
para ver un poco el seguimiento del equipo de trabajo. Básicamente usamos eso.
¿Hace cuánto tiempo lo hacen de esa forma? ¿Desde el inicio, han ido
cambiando?
227
No, eso habrá sido. Ósea desde el inicio se tenía la idea por ejemplo del ASANA, pero
habrá sido, desde el 2017, más formalmente desde el 2017, ósea hace 2 años. Al
segundo año. Y bueno lo del Project si... al inicio no eran tanto proyecto, ósea eran
proyectos, pero no necesariamente que tenía que ser un Project, no porque era
básicamente desarrollo. Ahí no se manejaba Project. Eso también desde finales del
2016, si mediados del 2016 ya se comenzó a usar el Project y luego se vio necesario,
cuando se empezó más que nada a trabajar con proveedores, se vio necesario lo del
ASANA.
¿A qué llamas proveedores?
Ah bueno, los freelance digamos. Los programadores que hacen sus cachuelos.
¿Cuánto tiempo suelen durar tus proyectos entonces diferenciando los de pymes
y los de TI?
En promedio serán unos 4 meses, 3, 4 meses.
¿Los dos tipos de proyectos o es diferente?
Claro, con las empresas de Ti, No si son, si en promedio son 3, 4 meses en promedio
los dos tipos de proyecto. Porque hay algunos que, si han durado como 10, casi un año
y hay otros que han sido… como le digo no eran tanto proyectos, sino eran algún
desarrollo así bien específico que duraban menos de un mes.
¿Ósea el máximo es 10 y el promedio entre 3 y 4?
Sí, ajá.
¿Cómo hacen para gestionar el alcance de sus proyectos? ¿Qué es lo que si se

incluye? ¿Qué es lo que no incluye? ¿la gestión de los requisitos? entre otras
cosas.
Bueno, eso lo manejamos desde el inicio de la propuesta. Ahí definimos, al inicio

tenemos una, dos reuniones por lo menos digamos con… cuando es un cliente nuevo
se tienen más reuniones para saber exactamente qué es lo que quiere y qué es lo que
necesita. Entonces se le plasma en la propuesta todos los requerimientos y el alcance
que va a tener en este caso la herramienta, el sistema. Ósea desde un inicio se plasma
el alcance que va a tener.
¿Y si hay variaciones en el camino?
228
Ah, bueno si está… Al inicio digamos la propuesta sale con un alcance, pero claro, si
cambia el alcance vamos a cambiar el… ósea se evalúa en el camino y se hace una
propuesta adicional.
¿Y esa propuesta queda documentada? ¿Hay un proceso o forma estándar de que

registren esos cambios?
Bueno se hace una nueva propuesta básicamente. Si es de la… Claro, si es del caso
de un mismo proyecto esa nueva propuesta, la manera de guardarlo, se guarda con el
Cliente.
¿Y el Cronograma como lo gestionan? ¿Cómo lo estiman para empezar? ¿Cómo

estimas los tiempos para el proyecto?
Bueno el…, uno es en base a algunos proyectos similares que se han tenido, más que
todo al inicio. Bueno felizmente al inicio si salieron varios tipos… bueno proyectos como
que tipo. Entonces esto… ósea tipo yo le digo a uno que tenía casi de todo. Porque
algunos solamente eran desarrollo y en los tipos digamos si tenían, eran completos.
Análisis de requerimientos hasta todo lo que es pruebas. Entonces como que ahí se
podía estimar un aproximado de cuanto… o mejor dicho eso es como que la base que
tenemos para más o menos estimar el tiempo que nos puede… cuando salen nuevos
proyectos. Eso básicamente es así por experiencias digamos pasadas que se tienen.
¿Y el cronograma lo manejan en alguna herramienta?
Ah bueno, el cronograma con el Project y como le digo las actividades se ponen en el...
bueno nosotros usamos el ASANA. Bueno ahí si se tiene que registrar mano a mano
cada actividad. Pero ahora hay otras herramientas. Jira también hay una, Peor Jira
personalmente, visualmente y operativamente no le… tiene muchas cosas, tiene mucho
para…
¿Y el tema del presupuesto cómo lo manejan? ¿Cómo estimas el presupuesto?
Ah bueno, eso ya felizmente ya se llegó a un… No se llegó… Bueno hay una… hay dos
maneras digamos de estimarlo. Una para las empresas de TI que tiene digamos un
presupuesto más…, si bien es hora hombre, pero es un poco mayor a las empresas
pymes. En las empresas pymes si llegamos a más detalle para tratar de cobrarle si lo
justo, más una ganancia. Ósea por horas hombre, por desarrollo... Bueno por horas
hombre de cada personal que tiene su... Digamos su sueldo mensual más sus
beneficios, todo, más los gastos de la empresa, todo, más un porcentaje de utilidad y
así digamos definimos para pymes. Para las empresas de TI si manejamos más un…
229
digamos un costo por empresa. Ósea tratamos de si conocer la empresa, porque
algunas empresas facturan más, entonces si se les puede cobrar más. Y no le vas a
cobrar lo mismo a las pymes, porque no te van a pagar pues.
¿Y hay modificaciones en el presupuesto en el camino?
Sí, al final se trata de, por ejemplo, para las pymes sí, manejamos un digamos un rango
de utilidad, cosa que si piden un ajuste, que cueste un poquito menos, ya ahí se va
midiendo, se va restando un poco de utilidad hasta llegar a un monto digamos que igual
si se gane para la empresa. Si ponemos que nuestra ganancia es 20% en verdad le
podemos bajar hasta cero y no perdemos, pero la idea si es mantener un margen, llegar
a 10, 15. Si piden un ajuste, ya se va bajando, pero ahí se trata de…
¿Qué prácticas de aseguramiento o control de calidad se aplican en la empresa

en los proyectos?
Bueno para la parte de proyectos, bueno de calidad, creo que no se… Bueno, la parte
propia de ¿proyectos como lo aplicaría de calidad?
En general, que actividades relacionadas con la calidad realizan en sus proyectos.

Puede estar relacionada tanto con el proceso como con el producto, que es lo
más común.
Claro, con el producto si tenemos digamos lo que… bueno manejamos la última fase
que es pruebas, pruebas unitarias, integrales y certificación o del cliente.
¿Qué porcentaje del cronograma son las pruebas?
El porcentaje le ponemos un 10, 15 por lo general. Y bueno en la parte de calidad

digamos del proyecto, bueno eso si es lo que yo considero, si se definen o si se entregan
los documentos como que ahí también se puede, de alguna manera validar que se está
entregando, o se está plasmando en algún documento lo que hace el sistema para
cerciorarse. Porque si tratamos, aunque sea una pyme, igual incluirle lo que es
documentación para… porque al final va a ser un ganar-ganar para ellos también y ósea
felizmente si lo entienden así. Cualquier cosita no van a estar llamándonos y de repente
pueden ver en el manual de usuario por ejemplo “Oye si este error que sale es por tal.
Ah ya entonces lo pueden modificar o puede hacer alguna corrección ahí. No tiene que
estar llamando.
¿Y los riesgos los gestionan durante el proyecto?
Los riesgos, si, bueno no hay una forma formal de gestionarlos. Eso si no.
230
¿No se dejan registrados en alguna parte?
No, esa parte no. De los riesgos no. Si hay digamos, si es la manera de que el riesgo
que a veces sí..., bueno lo que si se considera también como riesgo se le pone un
colchón de tiempo adicional por si acaso, pero no hay una manera formal, si se presenta
algún riesgo.
¿Y ese colchón como lo calculas?
No, ahorita le estamos poniendo un 10% adicional de orden. Porque si tratamos de

estimar el..., no tampoco lo justo sino siempre un poquito más, más el colchón si se llega
a tiempo.
Entre gestionar el alcance del proyecto, los requisitos, las variaciones que pueda
haber, el cronograma, el presupuesto, la calidad y los riesgos. ¿Cuál crees que
aporta mayor valor la negocio? ¿Cuál es más importante? ¿Todos son
importantes? ¿Alguno es más importante? ¿Alguno es menos importante?
Claro, en sí, dentro de la propuesta, al menos lo que yo considero bien importante es

haber definido los requisitos y que el cliente esté de acuerdo digamos con los requisitos
y con las consideraciones que se hacen. Eso y otro el cronograma con las actividades
y las horas. Eso también es bien importante. Porque ya eso conlleva al presupuesto,
pero el presupuesto como ya se tiene como que una plantilla entonces ya básicamente
depende de las actividades, del cronograma cuantas horas se han estimado.
¿Y esta plantilla te es útil? ¿Genera valor? La de presupuesto.
Sí, ahora sí. Ya se ha arreglado bien, porque antes a veces era solamente hora hombre,
pero no se veían otros gastos adicionales o no se tenía contemplado exactamente la
ganancia. Ahora si se ha definido mejor, más un colchón digamos de horas adicionales
por si acaso. Con eso digamos ya se tiene... ya se sabe también con eso nos ayuda,
sino lo ve digamos gente de la empresa y lo ve un tercero, un proveedor ya se sabe u
aproximado también cuanto se le podría pagar. Porque a veces los proveedores también
quieren ganar un montón pues. Porque claro a veces se aprovechan de esa necesidad
o esa premura y no pues, también es cuestión de aterrizarlos para… “yo puedo gastar
hasta esto nomás”. Eso sí ha servido.
Y este tema de los proveedores, el tema de los freeelance, tienes una lista de las
personas que trabajan continuamente contigo, los seleccionas por proyecto.
¿Cómo es?
231
Bueno, ha salido por necesidad y por disponibilidad de las otras personas. Lo bueno es
que ya, si me quedo con dos proveedores, que son lo que más cumplen digamos. Los
que hay más confianza y si se priorizan, serían con ellos primero y si ya no está
disponible se va con otros.
¿Y cómo sabe la empresa el estado de sus proyectos en curso entonces? De

estos 3, 4 proyectos. ¿Cómo sabes el estado de ellos?
Ah ya, uno es por el ASANA que dice, permite ver digamos que es lo que se ha hecho
y que no. Digamos es de la herramienta y bueno en la misma empresa manejamos...
tenemos ahí en la pared todos los proyectos y ver las actividades que están... siguiendo
el Kanban, el ToDo, in progress y hecho, bueno Done digamos, Si se tiene digamos
mapeado. Digamos ahí si se entra más a detalle para poder verificar.
Ya, pero eso es por cada proyecto. Tienes 4 tableros.
Bueno, uno grande y tiene los 4.
Ah, ¿es un solo tablero grande donde están los 4 proyectos?
Sí, dividido. Bueno eso sirve tanto para proyectos que están por salir. Si están en las
propuestas en conversaciones, y actividades propias de la empresa. Si eso sí, y con eso
se ve de manera más dinámica y más rápida que entrar a la herramienta. Si, ha apoyado
bastante.
¿Hay alguna forma de determinar el estado general del conjunto de proyectos? Es

decir, sabes que, mi cartera de proyecto todo está atrasado. Mi cartera de
proyectos como un todo va bien.
¿La de curso digamos?
Claro la de en curso.
No claro, como en general no se tiene alguna herramienta, ósea visualmente como se

podría…, Digamos como está en el Kanban. Están todos los proyectos, ósea vemos no,
que claro, no debería haber casi..., ósea si debería haber en ToDo varios, pero la
mayoría ya debería estar hecho.
¿Qué pasa si notas que un proyecto se está atrasando mucho?
Uno, al menos lo que se ha tratado, el tema es cuando se atrasado al menos los

proyectos, ha sido más por temas de coordinaciones con el cliente porque el cliente,
digamos se definía una duración del proyecto, digamos 2 meses, peor por x razones.
Ha sido más que nada con las empresas de TI, como su cliente final es otro por ejemplo
232
un banco, ellos ya no lo requerían con tanta premura, entonces el cliente tampoco ya no
nos… tampoco nos molestaba digamos a cada rato, ya no estaba así tan atrás de
nosotros. Entonces algunos se han atrasado por eso.
Pero eso es por qué se han atrasado, la pregunta es qué haces cuando se atrasan.
Ah bueno, ahí, por ejemplo, primero se detecta porque se está atrasando a identificar
digamos si es por temas, en este caso del cliente o por temas digamos de nosotros que
no estamos avanzando, Si es por temas de cliente, como le digo es ver, por lo general
ha sido porque ellos no han estado solicitando o no tienen premura, porque su cliente
final ya no les ha insistido mucho. Entonces por ahí se va atrasando. Atrasando por
temas de coordinaciones, que necesitamos algunas cosas y el otro cliente no las da,
pero porque no las da, porque no la han hecho y por qué no la han hecho, porque no le
están dando prioridad.
¿Y si detectas que el atraso es debido a su responsabilidad como empresa?
Claro, si es de nosotros lo que nosotros hacemos es ver digamos. Primero algo clave,
identificar si ha sido por temas de falta de información y si es por falta de información,
por lo general solicitamos al cliente, falta de digamos coordinación, o ya es por temas
digamos que se estimó, digamos hubo una mala estimación. En todo caso se hizo o se
plasmó horas menos de lo que está tomando.
¿Hay personas que están en más de un proyecto?
Si, ósea ven hasta 2 proyectos.
¿Cómo se dividen?
Bueno ahí si se trata de... o se prioriza, mejor dicho, según las fechas que se tiene que
entregar.
¿Los proyectos están priorizados en base a fecha o hay algún otro criterio?
No, ahorita en base a fecha de entrega.
¿Solo a fecha?
Sí ahorita sí
¿Y los empleados, en este caso más que nada los proveedores saben cómo su
proyecto se alinea con el objetivo de la empresa? mejor dicho ¿Saben cómo
aporta tal proyecto a los objetivos de la empresa?
233
Sí, como le digo. Si es para las empresas pyme sobre todo si se les explica digamos
desde un inicio que se están haciendo las conversaciones, de que trata el proyecto y
cómo va a beneficiar al cliente final.
¿Ósea, desde que estás haciendo la propuesta, ya tienes a los proveedores

seleccionados?
Sí, ósea se les va diciendo, por lo menos si ya los conoces. “¿Oye tú has visto esto?”
“¿Tienes disponibilidad?” Ahí se les va diciendo este proyecto, nosotros estamos viendo
este proyecto que puede salir, que es para tal empresa y vamos viendo disponibilidad
de tiempo.
¿Hay casos en que por ejemplo una persona esté asignada 50, 50 a dos proyectos,
y debido a que un proyecto se esté atrasando ese porcentaje cambie o no?
Sí, por lo general si cambia.
¿Quién decide eso?
Yo lo decido por prioridad digamos de fecha de entrega, o bueno ahorita digamos el

personal es un programador, yo y dos proveedores. Dos o uno dependiendo…Si yo
puedo, si tengo el conocimiento, yo meto también mano. Priorizo y las horas extra.
Dijiste el programador, yo y dos proveedores. ¿Qué es el programador en la

empresa? ¿Es un socio, un trabajador?
Un trabajador claro.
¿Y él está en todos los proyectos?
No, estará en dos máximo.
¿Cuántos programadores fijos tienes?
Ósea ahorita el programa, yo programo y un proveedor. Ósea tres, bueno dos son en
planilla, el programador y yo. Y el proveedor, pero un proveedor siempre está en lista
pues, y el otro es cuando ya se requiere más manos.
¿Y en gestión de proyectos tienes alguna formación adicional?
Bueno yo llevé un… en el Instituto para la calidad, pero hace bastante tiempo.
¿Tú gestionas todos los proyectos?
Si ahorita sí, claro la idea es que más adelante se tenga…
234
¿Y el programador ve básicamente la parte técnica entonces?
Sí, la parte técnica, y apoya en algunos documentos en su conocimiento y prueba.
¿Cómo defines éxito en tus proyectos? ¿Qué es para ti un proyecto exitoso?

(46:04)
Que se haya cumplido con lo... Si es para TI, si se ha cumplido con lo que en verdad
quería el cliente y en los tiempos, y si es para pymes, más que tiempo es que se haya
cumplido con lo que realmente necesitaban y eso se ve digamos al final, digamos
cuando ya está, entregado el producto y se ve que cumplió.
¿Qué porcentaje de proyectos entonces termina con éxito? Bajo esa definición
En general, bueno el tema de TI terminarán unos 80 por ahí. En las pymes sí, felizmente
todos han terminado en éxito. Es más, no sé si el término es fácil, coordinar con
digamos con pymes que con otras empresas de TI.
¿Qué porcentaje de proyectos termina retrasado entonces?
En ese caso el 20 sería.
¿Qué tanto se atrasa?
En porcentaje se atrasará…, es que no se atrasa mucho. Es que cuando se ha atrasado.

Es que han cambiado digamos de alcance, y claro de eso pasó todo y cuando ya
debíamos haber terminado, todavía no porque se han modificado los requerimientos,
pero de los nuevos será 15, 20%. La mayoría ha cambiado más que todo de alcance.
¿Y cómo evalúas la satisfacción de tu cliente?
A la empresa de TI se le manda una encuesta, al final que tan satisfactorio… bueno ahí
hay algunas preguntas, como encuesta de satisfacción. Si se ha cumplido en el plazo,
qué otros conocimientos, no recuerdo que ponemos al final que es como que otros
conocimientos quisiera que nosotros tengamos digamos para poder ofrecerle y para las
pymes también se les manda su encuesta. Ambas son con encuesta.
¿Por qué un proyecto podría ser cancelado antes de terminar? ¿Han habido
casos?
Si hubo un caso que se hizo con un proyecto que comenzó todo bien, se demo… como
era un tema de manejo también de unos POS entonces, nosotros teníamos que
comunicarnos con un proveedor de ellos. Bueno por lo general, los POS son…los
fabricantes son así de países así exóticos, por allá por la China, Tailandia. Entonces la
comunicación, lo que nosotros requeríamos por parte del fabricante, ellos tenían que
235
elaborarlo. Entonces ahí demoraron y ellos ya habían vendido la solución a un banco,
pero al final por esos temas que no lo podía hacer el fabricante, parece que el banco al
final canceló y al final canceló pues el proyecto, porque ya no iba. Ósea se hizo hasta
el desarrollo, pero no se hizo… faltó creo que pruebas, se hizo, que se habrá hecho
60% del desarrollo.
¿Es el único caso?
Sí, el único caso.
¿Y cuál es la tasa de errores reportadas post entrega?
Por ejemplo, con empresas de TI, el porcentaje ha sido poco. Habrá sido 10%, 15%.
¿De dónde sacas ese dato? ¿Cómo lo mides?
Ese si es al ojo la verdad, porque lo que ha sido con empresas de TI, por lo general ellos
tienen su área de certificación, entonces, lo que detectan más que nada son errores en
documentación, pero son cosas menores, porque ya se sabe, ya nosotros sabemos
cómo trabajan ellos, entonces ya sabemos que es lo que ellos piden o quisieran ver en
los documentos, por ejemplo. Y en cuanto a desarrollo, como básicamente el sistema
es parte de otro sistema o ellos propiamente lo tienen que probar con algunos
componentes de ellos, entonces ya también se sabe cómo trabajan. Entonces también
la tasa... Al inicio si era más grande, sería un 40%, algunos errores que se presentaban
y con las pymes. Tasa de errores, no es que con las pymes se maneja un poco diferente
porque con las pymes se van como que pequeños entregables se van validando con
ellos mismos. Entonces al final se entrega un producto caso probado por ellos, o
validado por ellos, mejor dicho. Y lo bueno es que también es menos complejo,
entonces por eso los fallos son formatos de algunos reportes o cositas de estilos,
visuales, son menores. Eso básicamente.
Con respecto a las preguntas que tenían que ver con el rendimiento de la empresa,
en general caso todo lo marcaste como 5. ¿Por qué consideras que los resultados
tanto de ventas, como de ganancias y crecimiento han sido buenos?
Si bueno, es que si se manejan los ingresos que tiene la empresa y el número de

proyectos que se han visto. Y si al menos el porcentaje de proyectos, y más que de
proyectos de ingreso por proyecto si ha sido mayor. Ósea ha habido menos proyectos,
pero han sido…, si han sido más largos y han sido mayor ganancia, han sido mayor
beneficio, pero si se podía haber incrementado más las ganancias, los proyectos.
¿Pero entonces como ha crecido el empleo?
236
Ah bueno, porque se ha contratado otro proveedor. Porque antes era... mejor dicho un
proveedor y otra persona a la empresa que antes eran solamente proveedores. Bueno
al menos yo lo veo así. Claro la idea ahí, si el objetivo de este año es crecer más todavía.
Y según esto el rendimiento general del negocio ha cumplido con tus expectativas
y ele rendimiento general del negocio marcas también 5 de 7 sobre si superó a tus
principales competidores. ¿Quiénes son tus principales competidores?
Ah bueno, algunos que yo tengo mapeado que son algunas empresas que... más que...
a ver. Algunos competidores que yo tengo mapeados son otras empresas que provee o
proveían a estas empresas pymes, o a estas empresas de TI, porque en empresas
digamos de propiamente de TI, solamente tengo mapeados a los que he conocido a
través de las otras empresas. Ósea propiamente yo, no he hecho digamos la
investigación a ver cuáles son los proveedores. Ósea hay, pero digamos son empresas
más grandes, pero no digamos, o al menos yo no he visto están también son pequeñas,
por conocidos.
Todo lo has marcado como 5, en general al menos excepto la última. “Durante el

último año la alta gerencia estuvo muy satisfecha con el desempeño general del
negocio”. Ahí marcas 4.
Es que ahí hay algunas cosas que, si se pudieron manejar de una mejor manera, más
que todo en algunos proyectos que se atrasaron por parte de los clientes porque eso
hizo que claro, nosotros ya estábamos comprometidos, no comprometidos, pero si ya
habíamos terminado, digamos por ejemplo la parte de desarrollo, de pruebas del lado
de nosotros. Entonces se le tenía que hacer pagos para el proveedor, pero nosotros
para no descuadrar tampoco la caja, debería venir todo digamos del proyecto, debería
cumplirse una línea, pero ahí sí descuadró, porque el cliente, bueno puso un poco de
peros, se puso muy exquisito en algunas certificaciones, no quería soltar digamos los
últimos pagos.
¿Cuánto ha sido entonces la rentabilidad financiera de la empresa en el último

año, aproximadamente?
Llegamos a cien mil máximos.
Eso es incluyendo tu sueldo o sin tu sueldo.
No con mi sueldo, Yo lo veo como ganancia anual, como ingreso que ha habido en la
empresa. Ese monto es ingreso, como el bruto. Esa es la facturación.
¿Y qué crees que necesitas para crecer entonces?
237
Ahorita necesito organizar mejor la parte de digamos de definición de los servicios y de
los nuevos productos que se puedan hacer. Porque ahí si necesito una asesoría para
moldear mejor la base de la empresa, Porque ahorita todos los proyectos han sido por
referencia, básicamente por referencia, y no va mal, pero digamos la idea es seguir
creciendo y ahí si se tiene que captar clientes entonces lo que falta es una mejora en la
parte de captura de clientes y poder vender un poco más la marca, mejorar la página. y
por eso digamos la parte del marketing digital y por eso la base es digamos definición
bien de los servicios de los proyectos hacia un público y también definir en las pymes
un público objetivo para atacar de frente, porque ahorita digamos en las pymes en
verdad se puede… todos pueden ser clientes porque al final el desarrollo como que se
puede hacer, pero ser digamos todos los clientes también es muy disperso. Entonces la
propuesta no es tan compacta, no tan vendible.
238
Anexo 13 – Análisis bibliométrico de los artículos
La tabla 1 muestra la lista completa de artículos incluidos en la revisión sistemática,

incluido el número de citas. La tabla 2 muestra el número de artículos por año y la tabla
3 muestra el número de artículos por revista ordenados por factor de impacto.
Autor/Año Título Citaciones
Cooper, R, Edgett, S,
Kleinschmidt, E (2004) Benchmarking Best Npd Practices-Ii 402
The influence of business strategy on project

portfolio management and its success - A
Meskendahl S. (2010) conceptual framework 365
Killen, C, Hunt, R, Project portfolio management for product

Kleinschmidt, E (2008) innovation 237
Empowering project portfolio managers: How

management involvement impacts project
Jonas D. (2010) portfolio management performance 213
Behavior of internal stakeholders in project

Beringer C.; Jonas D.; portfolio management and its impact on
Kock A. (2013) success 207
Project portfolio management in practice and

Martinsuo M. (2013) in context 188
The three roles of a project portfolio

Unger B.N.; Gemünden management office: Their impact on portfolio
H.G.; Aubry M. (2012) management execution and success 175
Advancing project and portfolio management

Killen C.P.; Jugdev K.; research: Applying strategic management
Drouin N.; Petit Y. (2012) theories 171
239
Formalization of project portfolio

Teller J.; Unger B.N.; Kock management: The moderating role of project
A.; Gemünden H.G. (2012) portfolio complexity 156
Unger B.N.; Kock A.; Enforcing strategic fit of project portfolios by

Gemünden H.G.; Jonas D. project termination: An empirical study on
(2012) senior management involvement 138
Absorptive; innovative and adaptive

Biedenbach T.; Müller R. capabilities and their impact on project and
(2012) project portfolio performance 122
Project portfolios in dynamic environments:

Sources of uncertainty and sensing
Petit Y.; Hobbs B. (2010) mechanisms 114
Successful project portfolio management

Kaiser M.G.; El Arbi F.; beyond project selection techniques:
Ahlemann F. (2015) Understanding the role of structural alignment 114
An empirical investigation on how portfolio

risk management influences project portfolio
Teller J.; Kock A. (2013) success 113
Agile portfolio management: An empirical

Stettina. CJ (2015) perspective on the practice in use 104
Sanchez, H, Benoit, R,
Bourgault, M, Pellerin, R Risk management applied to projects,
(2009) programs, and portfolios 99
Portfolio risk management and its contribution

to project portfolio success: An investigation
Teller J. (2013) of organization; process; and culture 90
240
Christiansen, J
Varnes, C From models to practice: decision making at
(2008) portfolio meetings 89
Understanding project interdependencies:

The role of visual representation; culture and
Killen C.P.; Kjaer C. (2012) process 89
Learning investments and organizational

capabilities: Case studies on the
Killen C.P.; Hunt R.A.; development of project portfolio management
Kleinschmidt E.J. (2008) capabilities 86
Risk management in project portfolios is more

Teller J.; Kock A.; than managing project risks: A contingency
Gemünden H.G. (2014) perspective on risk management 86
Impact of customer integration on project

portfolio management and its success-
Voss M. (2012) Developing a conceptual framework 84
Dynamic capability through project portfolio

Killen C.P.; Hunt R.A. management in service and manufacturing
(2010) industries 81
Dynamic capability through project portfolio

management in service and manufacturing
Killen, C, Hunt, R (2010) industries 81
Impact of relationship value on project

portfolio success - Investigating the
moderating effects of portfolio characteristics
Voss M.; Kock A. (2013) and external turbulence 81
241
Integrating sustainability into innovation

Brook, J. W., & Pagnanelli, project portfolio management – A strategic
F. (2014) perspective 79
Kock A.; Heising W.; How ideation portfolio management

Gemünden H.G. (2015) influences front-end success 78
Beringer C.; Jonas D.; Establishing project portfolio management:

Georg Gemünden H. An exploratory analysis of the influence of
(2012) internal stakeholders' interactions 72
Daniel E.M.; Ward J.M.; A dynamic capabilities perspective of IS

Franken A. (2014) project portfolio management 61
Key attributes of effectiveness in managing

Patanakul P. (2015) project portfolio 48
The role of top management involvement in

Hermano V.; Martín-Cruz firms performing projects: A dynamic
N. (2016) capabilities approach 43
Dealing with legitimacy: A key challenge for

Gutiérrez E.; Magnusson Project Portfolio Management decision
M. (2014) makers 42
Jerbrant, A., & Managing project portfolios: balancing

Gustavsson, T. K. (2013) flexibility and structure by improvising 41
Venture capitalists' decision to withdraw: The

role of portfolio configuration from a real
Li Y.; Chi T. (2013) options lens 39
A comprehensive framework for sustainable

Khalili-Damghani K.; project portfolio selection based on structural
Tavana M. (2014) equation modeling 37
242
Innovation portfolio management as a subset

Sicotte H.; Drouin N.; of dynamic capabilities: Measurement and
Delerue H. (2015) impact on innovative performance 33
Corporate innovation culture and dimensions

Unger B.N.; Rank J.; of project portfolio success: The moderating
Gemünden H.G. (2015) role of national culture 32
Risk In Information Technology Project

Drake, J, Byrd, T (2006) Portfolio Management 30
Buys A.J.; Stander M.J. Linking projects to business strategy through

(2010) project portfolio management 29
A Contingency Approach on the Impact of

Kock A.; Heising W.; Front-End Success on Project Portfolio
Gemünden H.G. (2016) Success 27
Governing the portfolio management process

for product innovation - A quantitative
analysis on the relationship between portfolio
Urhahn C.; Spieth P. management governance; portfolio
(2014) innovativeness; and firm performance 26
Innovation project portfolio management: A

Lerch M.; Spieth P. (2013) qualitative analysis 26
Kopmann J.; Kock A.; The role of project portfolio management in

Killen C.P.; Gemünden fostering both deliberate and emergent
H.G. (2017) strategy 25
Success rate and resource consumption from

Rungi M. (2010) project interdependencies 24
243
Roles of top management and organizational

project management in
the effective company strategy
Hyväri, I (2016) implementation 20
Vähäniitty J.; Rautiainen Small software organizations need explicit

K.; Lassenius C. (2010) project portfolio management 20
Costa, H. R., Barros, M. de

O., & Travassos, G. H. A risk based economical approach for
(2007) evaluating software project portfolio risks 11
A maturation model for project-based

organisations - with uncertainty management
as an ever-present multi-project management
Jerbrant A. (2014) focus 9
Whole of enterprise portfolio management: A

Young M.; Owen J.; case study of NSW Government and Sydney
Connor J. (2011) Water Corporation 9
How can the Trade off between Corporate

Sheykh, M. J., Azizi, M., & Business Strategy and Project Risk be
Sobhiyah, M. H. (2013) Optimized? 6
Ghasemi F.; Sari M.H.M.; Project portfolio risk identification and

Yousefi V.; Falsafi R.; analysis; considering project risk interactions
Tamošaitiene J. (2018) and using Bayesian Networks 6
P Eik-Andresen, A Controlling a multibillion project portfolio -

Johansen, AD Landmark milestones as key performance indicator for
(2016) project portfolio management 5
Investigating Association of Benefits and

Hadjinicolaou N.; Dumrak Barriers in Project Portfolio Management to
J. (2017) Project Success 5
244
De Souza, P, Carneiro, j
Bandeira-de-Mello, R Inquiry into the Conceptual Dimensions of
(2015) Project Portfolio Management 4
IT Project Selection: Politics, Experience and

Pedersen, K (2016) good Friends 3
A methodology for assessing the effect of

portfolio management on NPD performance
Yang Y.; Xu D.-L. (2017) based on Bayesian network scenarios 2
Sweetman R.; Conboy K. Portfolios of Agile Projects: A Complex

(2018) Adaptive Systems’ Agent Perspective 1
The viable system model for diagnosing and

Bathallath S.; Smedberg handling IT-project interdependencies in
Å.; Kjellin H. (2019) large portfolios 1
Efficient project portfolio management:

Ngqulunga B.; Walwyn D. Avoiding value destruction by promoting
(2018) social returns on RD -
Lerch, M , Spieth, P Innovation Project Portfolio Management - A

(2012) Quantitative Study -
Project Portfolio Optimization As A Part Of

Strategy Implementation Process In Small
And Medium-Sized Enterprises: A
Methodology Of The Selection Of Projects
Vacík, E, Špaček, M, Fotr, With The Aim To Balance Strategy, Risk And
J, Kracík, L (2018) Performance -
Strategic business areas as a mechanism for

coordinating stakeholder interests when
Ilyin, I, Teslya, A, (2016) managing a company's project portfolio -
Tabla 1: Lista completa de artículos
245
Los trabajos que tienen cero citas pertenecen en su mayoría a actas de conferencias.
La tabla 2 resume el número de artículos por número de citas.
# citaciones # artículos %
Más de 100 15 24%
Entre 50 y 99 14 23%
Entre 15 y 49 17 27%
Menos de 15 16 26%
Tabla 2: Artículos por número de citas
Esto significa que el 74% de los artículos revisados tienen más de 15 citas.
En la tabla 3 se presenta el número de trabajos por año.
Año # de artículos
Antes del 2010 7
2010 8
2011 1
2012 9
2013 9
2014 7
2015 7
2016 6
2017 3
2018 4
2019 1
Tabla 3: Artículos por año
246
Esta tabla parece sugerir un pequeño incremento en el número de documentos a partir
de 2010 y un promedio de 6 documentos por año, pero es interesante que la cantidad
de documentos disminuyó en 2017 y 2018.
Finalmente, la tabla 4 muestra el número de artículos seleccionados por journal

ordenados por factor de impacto.
# Factor de
Journal artículos impacto
Strategic Management Journal 1 8.835
Journal of Product Innovation Management 1 2.971
International Journal of Project Management 18 2.203

Journal of Business Research 1 1.684
Journal of Strategic Information Systems 1 1.432

Project Management Journal 9 1.266
Industrial Management and Data Systems 1 1.137
Journal of Engineering and Technology Management 1 0.940
IEEE Transactions on Engineering Management 2 0.833

International Journal of Managing Projects in
Business 6 0.702
Research Technology Management 1 0.620

International Journal of Quality & Reliability
Management 2 0.584
Journal of Systems and Software 1 0.550

Sustainability 1 0.549
Expert Systems 1 0.492
IBM Journal of Research and Development 1 0.454

Procedia Engineering 1 0.277
247
# Factor de
Journal artículos impacto
International Journal of Information Technology

Project Management 1 0.227
South African Journal of Industrial Engineering 1 0.223

South African Journal of Economic and Management
Sciences 1 0.219
Brazilian Business Review 1
Economics and Management. 1
Electronic Journal of Information Systems Evaluation 1

Iranian Journal of Science and Technology.
Transactions of Civil Engineering 1
Journal of Information Technology Theory and
Application 1
PICMET 2018 Proceedings- 1
Procedia - Social and Behavioral Sciences 3

St. Petersburg State Polytechnical University Journal.
Economics 1
Tabla 4: Artículos por Journal
La Figura 1 muestra gráficamente que más del 50% de los artículos son de tres journal
específicos:
 International Journal in Project Management

 Journal in Project Management
 International Journal in Managing Projects in Business
248
Figura 1: Artículos por Journal
249
Anexo 14 – Formatos entregados como parte de la
implementación
A. Formato de evaluación de propuestas
Propuesta
Cliente
Tipo de Proyecto
Objetivos de negocio
asociados
OBJ 1
OBJ 2
OBJ 3
Peso (1- Valor

Análisis 3) (0-3) Observaciones
Facturación/Rentabilidad
Tecnología
Disponibilidad de
recursos
Duración del proyecto
Conocimiento previo del

cliente
Nivel de riesgo del
proyecto
Conocimiento del área de
aplicación
250
B. Formato de análisis de resultados
Periodo
Meta Logro obtenido Comentarios
Objetivo 1
Objetivo 2
251
C. Registro de Proyectos
Fecha Ind. Ind. Ind.

Proyecto Tipo Cliente Estado Inicio Fecha Fin Alcance Tiempo Presupuesto Prioridad Comentarios
¿Está
balanceado? SI/NO
252
Anexo 15 – Detalle de la Implementación
Empresa E1
Datos Generales
Siglas para identificar a la empresa E1
Número de empleados Entre 5 y 15
Número de proyectos en el portafolio 4
Año de fundación 2007
Descripción General La empresa se dedica al desarrollo de

software y ha realizado productos propios.
Adicionalmente tiene otra línea de negocio
orientada a la instalación y configuración de
centrales IP.
Evaluación inicial fase exploratoria

Proyectos Portafolio (Max Financiero estratégico Total Y
E1 38 61 99 10 10 20
Porcentaje
obtenido 77.5% 72.6 74.4% 71.4% 35.7 47.6%
Entrevista inicial como parte del estudio
Fecha 10 de diciembre del 2018
253
Hora 4:00 pm
Lugar Starbucks Juan de Aliaga
Participantes Gerente General
Gerente de Proyectos
Evaluación previa a la implementación

E1 23 61 84 8 7 15
Porcentaje
obtenido 46.9% 72.6% 63.1% 57.1% 25% 35.7%
Registro de reuniones para implementación
Fecha Temas Tratados
9 de agosto de 2019 Reunión para presentar el marco de

trabajo y la estrategia de implementación
16 de agosto de 2019 Revisión de objetivos estratégicos
6 de septiembre de 2019 Revisión de tipos de proyectos
27 de setiembre de 2019 Definición de portafolio de proyectos
16 de octubre de 2019 Seguimiento de avances
12 de diciembre de 2019 Seguimiento de avances
17 de diciembre de 2019 Seguimiento de avances
22 de enero de 2020 Entrevista para evaluar la satisfacción

con el marco de trabajo
254
Acciones específicas realizadas como parte de la implementación
 La implementación del marco estuvo a cargo del Gerente General, en constante

comunicación con sus dos socios.
 Como parte de la implementación se hicieron ajustes en los objetivos de negocio
siguiendo las recomendaciones que sean SMART. Así mismo se planteó una
nueva tipificación de proyectos otorgándole mayor prioridad a los proyectos de
desarrollo de software.
 La empresa contaba con una lista de proyectos almacenada en un Spreadsheet
de Google Drive y otro para los proyectos de implementación de centrales IP.
Como parte de la mejora se modificó la estructura de este listado de proyectos y
se desarrolló un dashboard general que permita acceder a la información de
todos los proyectos de la empresa.
 Se desarrollaron nuevos formatos para evaluar las propuestas y el cumplimiento
de objetivos.
 La empresa venía utilizando métodos ágiles para la gestión, lo cual se mantuvo
durante la implementación.
Evaluación Final
Categoría Pregunta Max 7
La empresa controla el alcance de los proyectos realizados 7
La empresa control el cronograma de los proyectos realizados 6

Gestión de La empresa controla el presupuesto de los proyectos
Proyectos realizados 5
(1 Total Desacuerdo La empresa aplica prácticas de aseguramiento o control de

- 7 Completamente calidad en los proyectos 5
de acuerdo)
La empresa gestiona riesgos en los proyectos realizados 4
En general los proyectos terminan a tiempo 7
En general los clientes reportan pocos defectos tras la
entrega del proyecto 6
Porcentaje obtenido en Gestión de Proyectos

81.6%
Gestión de La empresa lleva un registro del portafolio de proyectos en
Portafolio ejecución 7
255
El portafolio de proyectos que maneja la empresa incluye
(1 Total Desacuerdo proyectos internos 7
- 7 Completamente
de acuerdo) El portafolio de proyecto incluye proyectos de innovación 7
Al momento de decidir realizar un proyecto se toma en
cuenta criterios definidos 7
Los proyectos realizados se alinean con los objetivos de
empresa 7
Al momento de decidir realizar un proyecto se analizan los
recursos requeridos 6
Al momento de decidir realizar un proyecto se consideran los
riesgos que genera 6
La empresa periódicamente revisa el estado del portafolio de
proyectos en ejecución 6
La empresa define distintas prioridades para los proyectos

que forman parte del portafolio 7
La empresa monitorea el desempeño del portafolio 6
Existe una buena comunicación entre la alta dirección y los

responsables del portafolio de proyectos 6
Existe una buena comunicación entre los responsables del

portafolio de proyectos y los responsables de cada proyecto 7
Porcentaje obtenido en Gestión de Portafolio 94.0%
Crecimiento de ventas fue en comparación con
nuestros competidores 5
Crecimiento de ganancias fue en comparación
con nuestros competidores 4
Rendimiento
Crecimiento de empleo fue en comparación con
(1 Total Desacuerdo
- 7 Completamente El desempeño general del negocio cumple con las
de acuerdo) expectativas 5
El rendimiento general del negocio supera al de nuestros
principales competidores 4
La alta gerencia está satisfecha con el desempeño general del
negocio 6
Porcentaje obtenido en Rendimiento de la empresa

66.6%
Evaluación de la mejora
256
Empresa
(máx. 49) (máx. 84) (Max 133)
E1 23 40 61 79 84 119
Porcentaje 46.9% 81.6% 72.6% 94.0% 63.1% 89.4%

Empresa
(máx. 14) (máx. 28) (Max 42)
E1 8 9 7 19 15 28
Porcentaje 57.1% 64.2% 25% 67.8% 35.7% 66.6%
Empresa E30:
Datos Generales
Siglas para identificar a la empresa E30
Número de empleados Entre 5 y 10
Número de proyectos en el portafolio Entre 2 y 5
Año de fundación 2018
Descripción General E30 es una pequeña empresa de desarrollo

de software con dos líneas de negocio
principales, desarrollo de software y mejora
de procesos, cada una con un responsable
asignado.
257
Evaluación previa a la implementación

E30 36 69 105 9 16 25
Porcentaje
obtenido 73.4% 82.1% 78.9% 64.2% 57.1% 59.5%
Registro de reuniones para implementación
Fecha Temas Tratados
14 de agosto de 2019 Reunión para presentar el marco de

trabajo y la estrategia de implementación
22 de agosto de 2019 Revisión de objetivos estratégicos
4 de septiembre de 2019 Revisión de tipos de proyectos
25 de setiembre de 2019 Definición de portafolio de proyectos
30 de enero de 2020 Entrevista para evaluar la satisfacción

con el marco de trabajo
Acciones específicas realizadas como parte de la implementación
 En todas las reuniones estuvo presente el gerente general junto con su socia,
quien era responsable de la línea de consultoría en mejora de procesos.
 Poco antes del inicio del proyecto de implementación del marco de trabajo se se
contrató a un gerente de proyectos que se hiciera responsable del portafolio de
proyectos de desarrollo de software.
258
 Como parte de la implementación se hicieron ajustes en los objetivos de negocio.
 Para la gestión de los proyectos específicos se utilizó Trello como herramienta
de trabajo colaborativo.
 Se desarrollaron nuevos formatos para evaluar las propuestas, el cumplimiento
de objetivos y para llevar registro del catálogo de proyectos de desarrollo de
software.
 Como parte de la implementación del proceso de priorización, se decidió dejar
de lado un proyecto de innovación que se venía desarrollando, pero no que no
había generado los resultados esperados.
 El esquema adoptado para la gestión de los proyectos de desarrollo se tomó
como base para adaptar también el esquema de gestión en los proyectos de
mejora de procesos.
Evaluación Final
La empresa controla el alcance de los proyectos realizados 7
La empresa control el cronograma de los proyectos realizados 6

Gestión de La empresa controla el presupuesto de los proyectos
Proyectos realizados 5
(1 Total Desacuerdo La empresa aplica prácticas de aseguramiento o control de

- 7 Completamente calidad en los proyectos 5
de acuerdo)
La empresa gestiona riesgos en los proyectos realizados 6
En general los proyectos terminan a tiempo 6
En general los clientes reportan pocos defectos tras la
entrega del proyecto 6
Porcentaje obtenido en Gestión de Proyectos
83.6%
La empresa lleva un registro del portafolio de proyectos en
7
Gestión de ejecución
Portafolio El portafolio de proyectos que maneja la empresa incluye
7
proyectos internos
(1 Total Desacuerdo
- 7 Completamente El portafolio de proyecto incluye proyectos de innovación 6
de acuerdo) Al momento de decidir realizar un proyecto se toma en
7
cuenta criterios definidos
259
Los proyectos realizados se alinean con los objetivos de
6
empresa
Al momento de decidir realizar un proyecto se analizan los
6
recursos requeridos
Al momento de decidir realizar un proyecto se consideran los
6
riesgos que genera
La empresa periódicamente revisa el estado del portafolio de
7
proyectos en ejecución
La empresa define distintas prioridades para los proyectos 7

que forman parte del portafolio
7
La empresa monitorea el desempeño del portafolio
Existe una buena comunicación entre la alta dirección y los 7

responsables del portafolio de proyectos
Existe una buena comunicación entre los responsables del 7

portafolio de proyectos y los responsables de cada proyecto
Porcentaje obtenido en Gestión de Portafolio 95.2%
Crecimiento de ventas fue en comparación con
Crecimiento de ganancias fue en comparación
con nuestros competidores 5
Rendimiento
Crecimiento de empleo fue en comparación con
(1 Total Desacuerdo
- 7 Completamente El desempeño general del negocio cumple con las
de acuerdo) expectativas 5
El rendimiento general del negocio supera al de nuestros
principales competidores 5
La alta gerencia está satisfecha con el desempeño general del
negocio 6
Porcentaje obtenido en Rendimiento de la empresa

73.8%
Evaluación de la mejora

Empresa
(máx. 49) (máx. 84) (Max 133)
E30 36 41 69 80 105 120
Porcentaje 73.4% 83.6% 82.1% 95.2% 78.9% 90.2%
260
Empresa
(máx. 14) (máx. 28) (Max 42)
E30 9 11 16 22 25 33
Porcentaje 64.2% 78.6% 57.1% 78.6% 59.5% 78.6%
261

Flores García Luis Alberto

Cargado por

Copyright:

Formatos disponibles

Flores García Luis Alberto

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Flores García Luis Alberto

Cargado por

Copyright:

Formatos disponibles

ESCUELA DE POSTGRADO

Impacto de la Gestión de Portafolio de Proyectos en el

TESIS PARA OPTAR EL GRADO ACADÉMICO DE DOCTOR EN

LUIS ALBERTO FLORES GARCÍA

JOSE ANTONIO POW SANG PORTILLO

Para la realización de este proyecto se utilizó un diseño de investigación mixto,

Los resultados de este proyecto contribuyen al campo de la investigación en la gestión

1.2 Pregunta de Investigación: ............................................................................14

1.3 Objetivos .......................................................................................................15

1.4 Justificación ..................................................................................................15

Capítulo 2. Marco Teórico ........................................................................................17

2.2 Rendimiento de las empresas .......................................................................19

2.3 Factores que afectan el rendimiento de una pequeña empresa ....................22

2.4 Portafolio de Proyectos .................................................................................24

2.5 Procesos de la gestión de portafolio..............................................................25

2.6 Gestión de múltiples proyectos (Multiple Project Management).....................27

Capítulo 3. Revisión de la literatura ..........................................................................29

3.1.1 Protocolo de la revisión ..........................................................................30

3.1.2 Preguntas de investigación ....................................................................30

3.1.3 Fuentes de datos ...................................................................................30

3.1.4 Cadenas de búsqueda ...........................................................................30

3.1.5 Criterios de inclusión ..............................................................................30

3.1.6 Criterios de exclusión .............................................................................31

3.2 Resultados de la revisión ..............................................................................31

3.3 Evaluación del éxito de la gestión de portafolio .............................................32

3.5 Factores de éxito de la gestión de portafolio .................................................38

3.6 Impacto de la gestión de portafolio en resultados de la empresa...................42

3.7 Conclusiones de la revisión ...........................................................................45

Capítulo 4. Diseño de investigación .........................................................................47

4.2 Fases y procedimientos ................................................................................48

4.3 Criterios de Selección ...................................................................................54

4.4 Matriz de Operacionalización ........................................................................55

4.5 Instrumentalización .......................................................................................60

Capítulo 5. Estudio Exploratorio ...............................................................................63

5.2 Identificación de respuestas válidas ..............................................................64

5.3 Análisis de respuestas ..................................................................................66

Capítulo 6. Estudio de Caso Múltiple........................................................................69

6.2 Descripción de las empresas participantes ...................................................69

6.3 Discusión del caso ........................................................................................72

6.3.1 Nivel estratégico.....................................................................................72

6.3.2 Portafolio de Proyectos ..........................................................................74

6.3.3 Gestión de Proyectos .............................................................................82

Capítulo 7. Propuesta de Marco de Trabajo .............................................................86

7.2 Esquema General .........................................................................................87

7.2.1 Bloque 1 (Estrategia) .............................................................................88

7.2.2 Bloque 2 (Propuestas de Proyecto o Portafolio de ideas).......................89

7.2.3 Bloque 3 (Definición y Gestión del Portafolio) ........................................90

7.3.1 Generación de propuestas para proyectos internos ...............................91

7.3.2 Elaboración de propuestas.....................................................................91

7.3.3 Evaluación de propuestas ......................................................................92

7.3.4 Gestión de Proyectos .............................................................................93

7.3.5 Gestión de Portafolio..............................................................................94

7.3.6 Evaluación de resultados .......................................................................94

Capítulo 8. Validación del Marco de Trabajo ............................................................95

8.1.1 Convocatoria a empresas ......................................................................95

8.1.2 Evaluación previa ...................................................................................96

8.1.3 Apoyo en la implementación ..................................................................98

8.1.4 Hechos relevantes .................................................................................99