Introducción
Las pymes en general tienen un papel muy importante en la economía y en la generación de empleo; inmersas en este gran conjunto de empresas, se encuentran las de consultoría informática, de las cuales, las de tecnologías de información (TI) en Colombia, de acuerdo con el informe de caracterización de 2015, generaron las mayores ventas del sector (Ministerio de las Tecnologías de la Información y las Comunicaciones de Colombia [MinTIC], 2015). Las de consultoría informática desarrollan proyectos tecnológicos que apoyan las actividades elementales de las organizaciones. Con los nuevos avances, para las organizaciones se hace indispensable implementar tecnologías que soporten sus procesos, y que mejoren su rendimiento, productividad y eficiencia. Sin embargo, la literatura indica que una gran cantidad de proyectos propios de dicha naturaleza fallan por incumplimiento en alguna de las restricciones básicas, como el tiempo, el costo o el alcance (Whitney y Daniels, 2013; Gallo et al., 2022).
Algunos informes como CHAOS Report (The Standish Group, 2020) indican que, si bien son muchos los proyectos que no fueron exitosos en el área de TI, aquellos que aplican un método ágil tienen más probabilidad de éxito, que los que utilizan metodologías tradicionales. Para los proyectos de TI, se identifica que los marcos de trabajo ágiles tienen mayor compatibilidad, esto partiendo de las características propias de los desarrollos tecnológicos, dado que son complejos, adaptables en los requerimientos del usuario, y el producto generado debe cumplir con las especificaciones solicitadas por los usuarios (Peña Abreu et al., 2016). Se identifica que el fracaso de muchos de estos proyectos se debe a la gerencia de proyectos, específicamente a los métodos utilizados y sobre todo a su adaptación (Ardila Albarracín et al., 2014). El modelo planteado ayuda a incrementar las posibilidades de éxito en los proyectos ejecutados por las empresas del estudio, siguiendo su naturaleza propia.
Metodología
El tipo de estudio seleccionado para la investigación fue correlacional, pues asocia los factores que inciden en los proyectos de consultoría informática y las metodologías ágiles adaptadas a la naturaleza de la empresa. Los participantes que participan en el estudio son las pequeñas y mediana empresas de consultoría informática en Bogotá, así como los gerentes de proyectos o personas que lideran los proyectos de dichas empresas. Para el progreso del objetivo general se desarrollaron varias fases, enfocadas en los objetivos específicos, como se muestra en la figura 1. El desarrollo de la metodología consta de cuatro fases (A, B, C y D), cada una constituida por uno o más procesos secuenciados, cuyo fin es contribuir al avance del objetivo general.
Técnicas e instrumentos de recolección de información
Se diseñaron y aplicaron dos encuestas: la primera, dirigida a totas las empresas de consultoría informática de la muestra representativa; y la segunda, aplicada al conjunto de empresas que indicaron utilizar alguna metodología para gerenciar sus proyectos.
Resultados
Siguiendo la metodología planteada en la figura 1, se obtuvieron los resultados correspondientes a las fases ilustradas. Se inició con la caracterización de los aspectos críticos comunes sobre los proyectos gestionados en la muestra representativa, para luego correlacionarlos con los marcos ágiles más afines para su gestión y así proyectar un diseño de modelo ágil en gerencia de proyectos orientado a las pymes objeto de estudio, y finalmente ejecutar su validación en un sujeto de la muestra.
Caracterización y definición los aspectos críticos comunes sobre los proyectos gestionados
Para esta investigación se tomó como población 82 empresas, las cuales fueron el resultado del proceso de análisis a partir de la herramienta, base de datos en línea de la Cámara de Comercio de Bogotá (CCB), entidad privada sin ánimo de lucro que registra y administra la información de las empresas constituidas en la ciudad de Bogotá (CCB, 2020); para obtener dicha población, se establecieron y aplicaron los siguientes filtros de análisis:
Cámara de Comercio y ubicación Bogotá, Colombia.
Actividad económica CIIU J6202.
Tamaño de empresas: medianas y pequeñas.
Renovadas en 2019 (pues el estudio se realizó a corte de 2020).
Rango de empleados 11-200.
Fecha de matrícula vigente mínimo desde 2015.
Por otra parte, también se tomó en cuenta la garantía de los campos e-mail, teléfono y dirección dentro de la base de datos generada, con el fin de contactar a las empresas por dichos medios. El proceso se realizó en dos partes: la primera, enfocada en las pequeñas empresas y, segundo, en las medianas. Unificando los resultados, se obtuvo un universo de 82 empresas de categoría pyme cuya actividad económica se asocia con la consultoría informática; luego se aplicó el muestreo aleatorio simple para poblaciones finitas para establecer la muestra, de la cual se obtuvieron 45 empresas, donde N corresponde al universo de estudio conocido, Z asociado a un nivel de confianza del 95 % y usando un margen de error máximo del 10 % para e, como se muestra en la ecuación (1).
Como resultado para esta fase, se determinó que los proyectos de las empresas de consultoría informática:
Suelen ser de consultoría informática o integran esta actividad con administración de instalaciones informáticas.
Se ejecutan en cronogramas menores a un mes y no mayores a doce meses.
Se ejecutan con costos entre COP 1 000 000 y hasta COP 2 000 000 000.
Se presupuestan con valores menores o iguales a COP 3 000 000 y hasta COP 3 000 000 000.
Los proyectos de consultoría informática normalmente se desarrollan bajo enfoques de gestión de proyectos ágiles y combinadas. Esta clase de proyectos se desfasan en su mayoría en un 48 % en el alcance, un 28 % en el tiempo y en un 12 % en el tiempo y costo, y debido a este incumplimiento pueden fallar con una probabilidad de hasta un 80 %. Parte del 71 % de las empresas indicaron que no se están aplicando las lecciones aprendidas que pueden ser adquiridas de otros proyectos desarrollados. Luego se aplicó un análisis para seleccionar los principales aspectos en los proyectos de consultoría informática por medio del principio de Pareto, el cual indica que, como regla, el 80 % de los impactos o resultados son provocados por solo el 20 % de las fuentes o causas (Muhammad Khan y Ramzan, 2018). En la figura 2, se muestran los resultados, donde el eje vertical izquierdo corresponde a los porcentajes individuales y el eje vertical derecho a los porcentajes acumulados.
De acuerdo con la figura 2, y con el principio de Pareto, se identificaron ocho aspectos críticos. En los proyectos de consultoría informática en orden descendente, de acuerdo con su importancia, corresponden a la planeación, identificación y control de riesgos, control del cronograma, gestión de comunicaciones, liderazgo, conocimiento, gestión de interesados, lecciones aprendidas.
Correlación de los aspectos críticos comunes identificados, con marcos ágiles en gerencia de proyectos
Para determinar los marcos ágiles afines a la investigación, se realizó inicialmente una revisión de literatura, sobre investigaciones de los últimos cinco años, sobre metodologías que suelen ser utilizadas en los proyectos de tecnología (tabla 1).
Autor | Año de publicación | Artículo | Metodología o marco trabajo utilizado |
---|---|---|---|
Higuchi y Nakano (2017) | 2017 | Agile design: A combined model based on design thinking and agile methodologies for digital games projects |
|
Tarwani y Chug (2016) | 2016 | Agile methodologies in software maintenance: A systematic review |
|
Shama y Shivamanth (2015) | 2015 | A review of agile software development methodologies |
|
Stoica et al. (2016) | 2016 | Analyzing agile development - from waterfall style to scrumban | Scrumban |
Mircea (2019) | 2019 | Project management using agile frameworks |
|
Imandi et al. (2015) | 2015 | A critical analysis of project management models and its potential risks in software development |
|
Singh y Dhirendra (2017) | 2017 | Implementation of requirement engineering in extreme programing and SCRUM | XP |
Shabbir et al. (2018) | 2018 | A hybrid approach for mapping scrum to capability maturity model integration key process areas for web environment applications | Scrum, Feature Driven Development (FDD), Dynamic System, Development Method (DSDM), Adaptive Software Development (ASD) |
Muñoz-Mata et al. (2015) | 2015 | Helping organizations to address their effort toward the implementation of improvements in their software process | Scrum |
Qureshi (2017) | 2017 | Evaluating the Quality of Proposed Agile XScrum Model | Xscrum, XP, Scrum |
Andrei et al. (2019) | 2019 | A study on using waterfall and agile methods in software project management | Scrum, Kanban |
Ozieranska et al. (2016) | 2016 | The critical factors of Scrum implementation in IT project - The case study | Scrum |
Williams et al. (2017) | 2017 | Business intelligence-success through agile implementation | Scrum |
Banica et al. (2017) | 2017 | Is DevOps another project management methodology? | Desarrollo y operaciones (DevOps) |
Vargas (2016) | 2016 | Project Agile Management For Software Development: A Comparative Study On The Applicability Of Scrum Together With Pmbok And / Or Prince2 | PMBOK, Prince2, scrum |
Kotaiah y Khalil (2017) | 2017 | Approaches for development of software projects: Agile methodology |
|
Hamad et al. (2018) | 2018 | IT Project Management Techniques for Development Professionals | Prince2 |
A partir de dichos resultados, se analizó la frecuencia para determinar las metodologías con mayor uso, según los artículos revisados. En la tabla 2 se registran los valores resultantes.
Metodología | Frecuencia absoluta | Frecuencia acumulada | Frecuencia relativa | Frecuencia relativa acumulada |
---|---|---|---|---|
Scrum | 13 | 13 | 0,351351351 | 0,351351351 |
XP | 5 | 18 | 0,135135135 | 0,486486486 |
Kanban | 3 | 21 | 0,081081081 | 0,567567568 |
FDD | 3 | 24 | 0,081081081 | 0,648648649 |
Scrumban | 2 | 26 | 0,054054054 | 0,702702703 |
Crystal | 2 | 28 | 0,054054054 | 0,756756757 |
Prince2 | 2 | 30 | 0,054054054 | 0,810810811 |
PMBOK | 1 | 31 | 0,027027027 | 0,837837838 |
Design thinking | 1 | 32 | 0,027027027 | 0,864864865 |
TDD | 1 | 33 | 0,027027027 | 0,891891892 |
DSDM | 1 | 34 | 0,027027027 | 0,918918919 |
ASD | 1 | 35 | 0,027027027 | 0,945945946 |
DevOps | 1 | 36 | 0,027027027 | 0,972972973 |
SDLC | 1 | 37 | 0,027027027 | 1 |
Total | 37 | 1 |
Aplicando el análisis de estadística descriptiva, sobre la frecuencia relativa acumulada, para determinar la mediana como medida centralizada de los datos, se obtuvieron las siguientes metodologías o marcos candidatas a usarse en el contexto de estudio en orden descendente:
Posteriormente se utilizó la matriz de decisión ponderada, como herramienta para calificar los marcos ágiles candidatos respecto a los aspectos críticos identificados y su desglose. Este último fue sometido a criterio de expertos, quienes calificaron su porcentaje en importancia dentro del aspecto según su experiencia; a cada aspecto se le dio un porcentaje del 100 %. Para el análisis de experto fue necesario un profesional con amplia experiencia en gerencia de proyectos, preferiblemente con certificación Scrum, PMI o Prince2, con al menos diez años de trabajo en proyectos de tecnología informática, para la implementación de proyectos transaccionales, de bodegas de datos o digitales. También fue necesario un rol complementario de especialista con experiencia de entre diez y veinte años en desarrollo de proyectos de tecnología informática, en calidad de gerente, director o consultor, con manejo de metodologías tradicionales de gestión de proyectos y metodologías ágiles. De los roles descritos se pudo contactar a tres expertos que cumplían con las características descritas. De acuerdo con la tabla 3, para establecer el puntaje o peso definitivo de los ítems, se usó la media aritmética como medida para integrar los puntajes establecidos por los diferentes expertos, siguiendo lo evaluado por Vinogradova et al. (2018), quienes indican que, al utilizar métodos de evaluación de criterio múltiples, se puede trabajar la media aritmética o la media geométrica como integrador.
Una vez obtenidos los pesos o puntajes para cada desglose del aspecto crítico, se realizó la calificación por marcos ágiles candidatos, los expertos calificaron según el conocimiento y experiencia con un puntaje de 1 a 5, donde 1 indica que la metodología o marco no es adaptable al criterio, y 5 es muy adaptable; las calificaciones por metodología y experto fueron organizadas según la tabla 4.
Posteriormente se obtuvo la matriz de decisión ponderada, mostrada en la tabla 5.
Al obtener los resultados de la matriz de decisión ponderada, mostrada en la tabla 5, se realizó una agrupación primaria, y se revisó la distancia entre estos, para identificar los marcos clasificados; sin embargo, el marco Scrum resultó ser el más afín a los criterios, según los puntajes, por lo cual se procedió con una segunda clasificación para no sesgar los resultados a un solo marco. En este segundo análisis se revisaron los puntajes por aspectos, y su afinidad con estos; el resultado fue la metodología Prince2 para los aspectos de identificación y control de riesgo y lecciones aprendidas, tomando un enfoque ágil.
Diseño de modelo ágil en gerencia de proyectos, para pymes de consultoría informática en Bogotá
El modelo en gestión de proyectos para pymes de consultoría informática, basado en marcos ágiles de trabajo, se estructuró en cuatro fases: inicio, planeación y diseño, desarrollo y cierre, las cuales buscan ser aplicables a la naturaleza de los proyectos de empresas de consultoría informática en Bogotá caracterizados, previamente, en proyectos de corta duración y de una duración de hasta 12 meses. Aquí el alcance suele ser un producto de consultoría informática, desarrollado para clientes de diferentes sectores, entre los que destaca el sector financiero, de servicio, y de tecnología y comunicaciones. El modelo se basa en el marco Scrum y en aspectos de la metodología Prince2. En la figura 3 se describe cada fase del modelo mostrado.
Inicio
Involucra la apropiación del proyecto tanto por parte del cliente como de la empresa desarrolladora, aun cuando se busca simplificar la gestión de los proyectos de consultoría informática. En esta fase se hace hincapié en la formalidad y la documentación. El primer proceso que se plantea es describir y establecer claramente la visión del proyecto, y se crea el acta de constitución del mismo proyecto.
Luego se identifican a los interesados y líderes de proyecto; proceso en el cual se debe incluir a la empresa de consultoría informática, cuando es establecida la empresa de consultoría informática que participará en el proyecto o dará soporte al mismo. El líder por parte de la empresa de consultoría informática debe hacer un levantamiento de requerimiento, definir el alcance del proyecto y asegurar la socialización y aceptación por parte del cliente, lo cual debe generar un acta de aceptación antes de pasar a la siguiente fase. Aquí, se recomienda tener una comunicación mayormente formal, para que así que el proceso quede debidamente respaldado. Se sugiere asignar el 5 % del tiempo total del proyecto.
Planeación y diseño
Se integran los riesgos y las lecciones aprendidas, a partir de la metodología Prince2, dada la importancia que confiere a estas dos dimensiones, las cuales deben ser integradas de manera temprana para incluir sus análisis en el planteamiento y diseño del producto. Por otra parte, se tiene en cuenta el marco Scrum, que puntualiza la importancia del equipo de trabajo y los roles a establecer. El primer proceso de la fase consiste en identificar y diseñar el flujo de procesos para el desarrollo del producto de consultoría informática, o el flujo para el subproducto o entregable, dependiendo de la magnitud del proyecto; para esto se debe organizar un diagrama general para el desarrollo del producto. A partir de este diagrama, se debe conformar el equipo de trabajo del proyecto. Es importante que el equipo tenga claridad del alcance y requerimientos del proyecto; punto en el que se recomienda socializar entre el equipo de trabajo las lecciones aprendidas de proyectos similares, recabar entre la documentación disponible de los proyectos culminados, o sobre la experiencia o anécdotas recopiladas. Las lecciones aprendidas deben manejarse en todo el proceso, y ser documentadas gradualmente o al finalizar cada entregable.
El siguiente paso sería la identificación, por parte del equipo, del insumo que debe obtenerse de los usuarios o cliente, como la fuente para desarrollar el producto de consultoría informática. Estos insumos se pueden traducir en documentos, planos, conexiones a bases de datos para extraer información o transformarla, consultas de código fuente, o simplemente el detalle paso a paso de las actividades o procesos que realizan los usuarios para generar un resultado o valor. Por otra parte, se deben identificar los posibles riesgos que puedan generarse por parte del usuario, o de la información o insumo que este debe entregar, y que pueden impactar de forma directa el desarrollo del producto. Se sugiere indagar con los usuarios sobre las experiencias o lecciones aprendidas de proyectos similares que puedan ser de utilidad para el proyecto iniciado.
Esta fase debe tener documentado el proceso del insumo o del que ejecutan los usuarios para obtener información, o el análisis también debe ser socializado con los mismos y aceptado para seguir a la siguiente fase.
Se recomienda tener identificados los riesgos que pudieran generarse por parte de los usuarios directos. En el caso de que el requerimiento detallado que se recopiló no sea aceptado por el usuario, se debe revisar y validar nuevamente el proceso para la identificación del insumo. La comunicación en este proceso debe ser formal con el cliente o usuario; mientras que entre los grupos del equipo se sugiere una comunicación directa e informal, en busca de facilitar la comprensión y el trabajo en equipo. Para esta fase se recomienda asignar el 35 % del tiempo total del proyecto
Desarrollo
Aquí, se siguen contemplando los riesgos y las lecciones aprendidas de la metodología Prince2, y se integra el proceso de incremento basado en el marco Scrum. Esta fase busca detallar las actividades a seguir, y otorgarle un papel activo al equipo de trabajo en la identificación de las tareas a ejecutar: ¿cómo realizarlas y en cuánto tiempo? También busca garantizar la satisfacción del cliente y minimizar la repetición de trabajos, que hayan provocado los ajustes y cambios.
Se debe elaborar un desglose de las actividades por los procesos identificados en la fase de planeación y diseño; dicho desglose debe estar a cargo del equipo de trabajo. Posteriormente se deben asignar las actividades según los conocimientos necesarios requeridos para su desarrollo. Se establecen los entregables o subproductos, el cronograma y se tienen en cuenta los riesgos previamente identificados; también, es pertinente hacerles seguimiento constante a estos para un control eficiente.
En esta fase se desarrollan los subproductos o entregables establecidos, para lo cual se debe tener un control de las actividades identificadas, y socializar el cronograma para garantizar entregas sin retraso. También ajustar el cronograma con los retrasos que se presenten, y mantener al equipo de trabajo, usuarios y cliente, informados al respecto.
En el desarrollo se debe hacer un seguimiento continuo al avance de las actividades, para detectar problemas, retrasos, riesgos y demás variables que puedan impactar las fechas de entrega, o el alcance de estas. Es importante contar con los usuarios directos, para hacer aclaraciones y pruebas, y así garantizar que las entregas cumplan con lo requerido, y que los ajustes puedan impactar el tiempo y los costos del proyecto.
Una vez realizada la entrega, si el usuario o cliente no aprueba, se debe proceder con los ajustes pertinentes y validar nuevamente con el usuario directamente implicado; sin embargo, se espera que los cambios sean menores por el hecho de incluir al usuario en todo el proceso antes de la entrega. Si esta última es aceptada, debe quedar formalizada mediante un acta o canal formal de información; igualmente, se debe garantizar que el documento de lecciones aprendidas se encuentre actualizado, y socializarlas con el equipo de trabajo para no incurrir en los mismos errores o repetir las acciones que fueron favorables. Si el producto final no está terminado con la entrega, es necesario iniciar nuevamente la fase de desarrollo.
Al igual que en las otras fases, la comunicación con el cliente o usuarios debe ser formal; entre integrantes del equipo de trabajo, directa e informal. Para esta fase, se recomienda asignar el 50 % del tiempo total del proyecto.
Fase cierre
Contempla la integración de los entregables o subproductos del marco Scrum, de ser necesario, con la garantía de que el producto final se encuentre en armonía en todos sus componentes. En esta fase se debe realizar la integración del producto, y tener la aceptación general del cliente, también se deben elaborar y entregar algunos documentos como manuales de usuario, manuales técnicos, el documento final de las lecciones aprendidas en el proyecto y, por último, el acta de cierre de terminación del proyecto. Para esta fase, se recomienda asignar el 10 % del tiempo total del proyecto.
Validación del modelo desarrollado
El modelo desarrollado fue aplicado en un proyecto de una de las empresas de consultoría informática, de la muestra representativa con las características estudiadas, denominada “A”, dado el carácter de confidencialidad establecido con la empresa y con el cliente para el cual se desarrolló el proyecto. En la validación, se evidenciaron diferentes aportes del modelo diseñado sobre el proyecto B; en la planeación se detallaron los requerimientos, lo que se tradujo en ajustes o cambios mínimos. Por su parte, la integración y socialización de las tareas aprendidas de proyectos similares permitieron al equipo de trabajo prevenir o mitigar riesgos como inconsistencias en las estructuras y planos suministrados por el cliente, o información inconsistente en la creación de los reportes y tableros; riesgos que podían repercutir en el alcance, tiempo y costo del proyecto. Por su parte la comunicación directa entre el equipo de trabajo ayudó a crear compañerismo, lo que se tradujo en la solución problemas con mayor prontitud. Algunos de los inconvenientes se presentaron en los procesos de ETL (extract, transform y load), los cuales causaron que las cadenas de textos mostradas en los reportes se visualizaran incompletas; el inconveniente fue detectado por uno de los diseñadores de reportes antes de realizar las pruebas con el usuario, y se solucionó con la intervención conjunta del consultor BI (business intelligence) y del diseñador de ETL; el tiempo reportado para estos ajustes fue de dos días.
Uno de los beneficios que se logró al integrar al equipo de trabajo en las estimaciones de las actividades fue tener unos tiempos realistas para los entregables; antes de las pruebas con el usuario, esto se tradujo en entregas en los tiempos establecidos con desviaciones mínimas, reportadas en máximo un día de diferencia con la aprobación del cliente. Por otra parte, dado que en todo el proceso se mantuvo una comunicación con los usuarios y funcionales por canales formales, todos los ajustes, requerimientos y modificaciones quedaron debidamente soportados, lo que fue de ayuda para evitar inconvenientes con los usuarios y el cliente en general. Teniendo en cuenta lo anterior y lo indicado por el equipo, el proyecto concluyó con una desviación mínima en el tiempo de 0,7, es decir una semana de diferencia respecto a lo estimado, sin mayores costos, y una desviación de 3,5, es decir con COP 5 000 000 de diferencia respecto a los costos estimados y con la satisfacción del cliente, dado que se entregaron y aceptaron los cuatro entregables propuestos en el proyecto. Así, el modelo diseñado evidenció mejoras positivas en el desarrollo del proyecto y mostró a la empresa “A” un modelo simple que puede ser adaptado por parte de la empresa de consultoría, sin generar grandes esfuerzos, pero ayudando a obtener buenos resultados en el desarrollo de sus proyectos.
Para medir el desempeño del proyecto B con la aplicación del modelo propuesto, se realizó un análisis de la desviación del proyecto, respecto a otros similares desarrollados en el último año, dentro de la empresa de consultoría, respecto al tiempo, costo y alcance. En la tabla 6, se muestran los resultados.
Como se muestra en la tabla 6, en el proyecto B las desviaciones fueron menores, en cuanto al tiempo y costo, respecto a los proyectos C y D, aun cuando el alcance del proyecto en los tres casos no fue impactado, pues se dio la aceptación de todos los entregables. Se mostraron mayores desviaciones en los otros aspectos. En la tabla 7, se detallan los porcentajes de mejora del proyecto B respecto a los proyectos C y D, se evidencia mejora de un 77 % para el tiempo y un 57 % para el costo.
Estos resultados indican que el modelo diseñado puede ayudar a generar un buen despeño en los proyectos de consultoría informática desarrollados por las empresas pequeñas y medias de la ciudad de Bogotá.
Conclusiones
El objetivo principal de la investigación fue desarrollar un modelo en gerencia de proyectos para pymes de consultoría informática en Bogotá, basado en marcos de trabajo ágil. Por su parte, la hipótesis a comprobar fue que las pymes de consultoría informática, en Bogotá, pueden llegar a aplicar una gerencia de proyectos positiva, al adaptar los marcos te trabajos ágiles a la naturaleza propia de este tipo de empresas, a partir de los factores de mayor relevancia, como planeación, comunicación y lecciones aprendidas, por medio del cumplimiento de las tolerancias en tiempo, costo y alcance. Dicha hipótesis fue comprobada con el cumplimiento del objetivo y los resultados de la validación del modelo, los cuales arrojaron una mejora de un 77 % para el tiempo, un 57 % para el costo y el alcance no sufrió ajustes y fue aceptado por el cliente.