Revista Tecnología y Ciencia - Universidad Tecnológica Nacional
DOI: https://doi.org/10.33414/rtyc.34.16-36.2019 -
ISSN 1666-6933 / Febrero-Mayo 2019 / Año 17 - Nº 34
Recepción 19/12/2017
Aprobación 11/06/2018
Patricia R. Cristaldo
Universidad Tecnológica Nacional, Facultad Regional Concepción del Uruguay - Argentina
cristaldop@frcu.utn.edu.ar
Luciana C. Ballejos
CIDISI – Universidad Tecnológica Nacional, Facultad Regional Santa Fe - Argentina
male@frsf.utn.edu.ar
Mariel A. Ale
CIDISI – Universidad Tecnológica Nacional, Facultad Regional Santa Fe - Argentina
male@frsf.utn.edu.ar
En el marco de un estudio, se realizó una propuesta metodológica para el seguimiento integral de proyectos de Tecnologías de la Información y la Comunicación (TICs) en un ámbito particular de la Administración Pública Argentina. Esta nueva propuesta considera aspectos relevantes de la gestión tradicional y ágil, y permite la alineación del proyecto con la estrategia y la gestión del gobierno, ya que por cada etapa se puntualizan una serie de requisitos considerados fundamentales para la gestión exitosa de proyectos de TICs en el sector público. Este trabajo presenta la implementación de dicha propuesta metodológica de enfoque “híbrido”, a un proyecto de TICs perteneciente al Departamento de Informática de una municipalidad, considerando el cumplimiento de los requisitos en cada etapa de la misma. Este nuevo escenario facilita una transferencia de conocimiento más receptiva y útil y favorece el acercamiento entre las partes interesadas.
Palabras Claves: gestión de proyectos, Administración Pública, metodologías, TICs.
Within the framework of a study, a methodological proposal was made for the comprehensive monitoring of Information and Communication Technology (ICT) projects in a particular area of the Argentine Public Administration. This new proposal considers relevant aspects of traditional and agile management, and allows the alignment of the project with the government's strategy and management, since for each stage a series of requirements considered fundamental for the successful management of ICT projects in the public sector. This paper presents the implementation of said methodological proposal of "hybrid" approach, to an ICT project belonging to the Department of Computing of a municipality, considering the fulfillment of the requirements in each stage of the same. This new scenario facilitates a more receptive and useful knowledge transfer and favors the rapprochement between the stakeholders.
Key words: project management, Public Administration, methodologies, ICTs.
Los proyectos TICs tienen singularidades propias dentro de la Administración Pública, que corresponden a problemáticas propias del sector gobierno, tecnología y gestión, y que condicionan fuertemente la ejecución de este tipo de proyectos. En el mercado existen varias metodologías y guías de buenas prácticas: PMBOK (PMBoK Guide, 2013), PRINCE2 (PRINCE2, 2009) y METRICAV3 (Metrica3, 2001), APM (Highsmith, 2010), ATERN y SCRUM (Sutherland, 2014), entre otras. Sin embargo, la gestión de proyectos sigue siendo un esfuerzo altamente problemático (Varajão, 2016) y en especial la gestión de proyectos de TICs siguen mostrando niveles menores de éxito (Colomo-Palacios et al., 2014; Varajão et al., 2014) debido a varias razones (Lehtinen et al., 2014; Ramos y Mota, 2014; Montequin et al., 2016; Chow y Chao, 2008; Elkadi, 2013; Elmam y Koru, 2008).
Teniendo como base las razones de fracaso y los factores críticos de éxito en la gestión de proyectos de TICs, se elaboró un conjunto de requisitos mínimos y necesarios para la gestión de proyectos de TICs en el sector público y que deberían ser satisfechos por una única metodología de gestión de proyectos. Los requisitos están contenidos en cuatro perspectivas: (1) formación y crecimiento: donde se incluyen los aspectos relacionados con la gestión de los recursos humanos necesarios para poder ejecutar un proyecto de TICS, habilidades, motivaciones, etc.; (2) procesos internos: que involucra los aspectos relacionados con la gestión de los procesos del proyecto que el gerente del mismo deberá acentuar de manera tal de lograr la satisfacción de los interesados; (3) interesados: donde se considera los aspectos vinculados con las problemáticas propias del sector de gobierno, en particular, la importancia del grado de compromiso de las autoridades para con el mismo; y (4) técnicas: donde se incluyen los aspectos relacionados con las técnicas de ingeniería vinculadas con el proyecto, tales como diseño, documentación, pruebas, tecnología, etc.
A partir de la fusión de las siguientes guías de buenas prácticas: PMBOK de enfoque tradicional y ATERN, de enfoque ágil; y las siguientes metodologías: PRINCE2 de enfoque tradicional y, SCRUM y APM, de enfoque ágil. Este fue el punto de partida para el diseño de una propuesta metodológica de enfoque “híbrido”.
El objetivo de este trabajo es presentar la verificación, validación y calibración de los requisitos planteados a partir de la aplicación de la propuesta metodológica de enfoque “híbrido” a un caso real. La Propuesta Metodológica se aplicó a un proyecto real de un Departamento de Informática de una Administración Pública y para que los diferentes interesados en la gestión del proyecto confíen en la aplicación de dicha propuesta se establecieron acciones de Verificación. Dicha verificación hace referencia a la correcta formulación de la Propuesta Metodológica, es decir si la lógica operativa de la propuesta se corresponde con la lógica de gestión de un proyecto TICs en la Administración Pública. Se pretende encontrar respuesta a interrogantes del tipo: ¿existen errores en la Propuesta Metodológica? ¿todos los documentos son suficientes y se representan correctamente? ¿la Propuesta Metodológica contiene todos los aspectos fundamentales de una metodología de gestión de proyectos? ¿La Propuesta Metodológica responde a todos los requisitos planteados como indispensables para la correcta gestión de proyectos TICs en la Administración Pública?
Por otro lado, se realizan acciones tendientes a la Validación, es decir, a la determinación de, si se construyó la metodología ajustada a las necesidades de este entorno particular. Esto implica las siguientes cuestiones: ¿quedaron consideraciones importantes sin incluir? ¿se incluyeron actividades o tareas redundantes y sin valor añadido? ¿La Propuesta Metodológica resulta creíble para las autoridades y demás interesados?
Finalmente, se tuvieron en cuenta acciones de Calibración, es decir, de ajuste continuo de comparar el comportamiento de la Propuesta Metodológica con el de la gestión de un proyecto en la Administración Pública, ajustando la propuesta en base a las diferencias que aparezcan. Este proceso se repite a lo largo de su implementación, hasta que se refinen y ajusten todas las discrepancias que se vayan encontrando.
En este trabajo se describe la verificación, validación y calibración de los requisitos que debe considerar la Propuesta Metodológica de enfoque híbrido para la gestión exitosa de los proyectos de TICs en la Administración Pública, sin la determinación de métricas para cada requisito, el cual se deriva como trabajo futuro.
METODOLOGÍA PROPUESTA: Implementación
La Propuesta Metodológica de enfoque “híbrido” (Cristaldo et al., 2014; Cristaldo et al., 2015), muestra la Figura 1, se desarrolla a partir de los requisitos segmentados en las cuatro perspectivas, que interactúan permanentemente con las tres fases: definición y planificación, ejecución y control y, evaluación final y cierre, basados en el ciclo de vida de PMI (PMBoK Guide, 2013). Permitiendo un equilibrio entre los objetivos y los resultados esperados del proyecto, logrando de esta forma estructurar la colaboración entre todos los interesados para eliminar problemas en el cumplimiento de las expectativas de cada uno de ellos.
Figura 1. Propuesta Metodológica de enfoque “híbrido”
La documentación generada y las actividades a realizar en cada una de las fases, se muestran en la Figura 2.
Figura 2. Actividades y Documentos incluidos en la Propuesta Metodológica de enfoque “híbrido”
En el marco de aplicación y posterior verificación de los requisitos afectados a la Propuesta Metodológica, se ha elegido el proyecto Implementación del Sistema de Administración Tributaria (ISAT), perteneciente al Departamento de Informática de la Municipalidad de Concepción del Uruguay, por las siguientes razones:
- El proyecto, conforme a la duración del mismo, es considerado medio de acuerdo a los demás proyectos que se gestionan en el Departamento de Informática.
- El proyecto presenta un carácter tecnológico multidisciplinar que exige la gestión de distintas especializaciones tecnológicas que incluyen tanto hardware, redes, comunicaciones y seguridad, como diversos lenguajes de software de programación.
- El compromiso general del proyecto para con las autoridades de la organización es considerado alto, ya que los objetivos del mismo redundan en mejoras sustanciales a los usuarios finales, en este caso a los ciudadanos.
- El ritmo del proyecto es considerado crítico en plazos ya que debía estar operativo para una fecha que no admitía posible demora. Esto debido a que las autoridades tienen interés por implementar el mismo en un período determinado. Esto implica una criticidad del plazo de realización del proyecto.
- Los procedimientos y reglamentos están estandarizados en distintos niveles. Esto se debe a la naturaleza misma de las organizaciones públicas, las cuales están altamente estructuradas.
- Las personas que integran el Departamento de Informática, son altamente especializadas en las actividades que tienen asignadas. Por tanto las personas afectadas al proyecto, cumplen dentro del período de trabajo diario, con otras actividades, además de las asignadas para implementar el proyecto ISAT. Por lo tanto se puede considerar que los miembros del equipo están parcialmente disponibles para llevar adelante las actividades asignadas en el proyecto.
- El tamaño y la disponibilidad el equipo están acotados a la cantidad de personas que integran el Departamento de Informática y el horario de trabajo de cada uno en la Municipalidad.
- El alcance del proyecto está claramente determinado desde el inicio por el Director del Proyecto.
- Se considera que de acuerdo al entorno del proyecto, el nivel de incertidumbre es impredecible. Es decir, el avance del mismo depende en gran medida del grado de apoyo de las autoridades.
Conforme a lo antes especificado se considera viable el proyecto y su entorno para la validación de la Propuesta Metodológica.
PROPUESTA METODOLÓGICA: Verificación de Requisitos
Equipo de Gestión
Los roles y responsabilidades para llevar adelante la propuesta metodológica aplicada a gestionar el proyecto ISAT que muestra la Figura 3, se elabora y se publica a todos los interesados, de forma tal que todos se informen y se involucren en el proyecto.
Las personas involucradas en la estructura de gestión del proyecto ISAT han sido seleccionadas por el Director de Proyecto conforme a los cargos, experiencia y conocimientos de cada una de las actividades o tareas en que fueron afectados.
Esta definición permitió que todos los interesados tuvieran un conocimiento exacto de a quién debían pedir qué tarea y, quién podía pedir a quien de acuerdo a sus responsabilidades.
Figura 3. Equipo de gestión
En cuanto a la formación, se han realizado unas sesiones intensivas de aplicación de la Propuesta Metodológica para gestionar el proyecto ISAT. Además, parte del Equipo de Gestión debió realizar reuniones de capacitación en aquellas tecnologías novedosas con la tutela de los expertos participantes en la gestión del proyecto. La Tabla 1 determina el cumplimiento de los requisitos implicados en la generación de la estructura del equipo de gestión.
|
Dimensión |
Requisitos |
Acción de verificación |
|
Formación y Crecimiento |
Alcanzar un elevado conocimiento de la organización, por parte del director del proyecto. |
Confirmación que el director del proyecto tenga la antigüedad mínima (19 años de antigüedad en la Administración Pública y 13 años como Director del Departamento de Informática). |
|
Alcanzar popularidad aceptable para con los pares. |
El director de proyecto por su antigüedad es respetado por los demás directores de departamentos. |
|
|
El director del proyecto debe alcanzar un alto grado de poder de convicción a las autoridades. |
Una reunión para informar del interés de gestionar el proyecto ISAT. Participaron el intendente, secretario de hacienda y director del Departamento de Informática. |
|
|
Lograr un alto grado de satisfacción de las autoridades, el equipo de proyecto, interesados y contratistas. |
Confirmación a partir de las reuniones efectuadas: participación de los interesados convocados, cantidad de consultas realizadas. |
|
|
El director de proyecto debe ser una persona con perfil técnicamente competente y experimentado. |
El Director de Proyecto ISAT es Ingeniero en Sistemas de Información. |
|
|
Tener métodos definidos para una correcta selección de personal. |
No se aplicó selección de personal. |
|
|
Brindar definiciones de responsabilidades del equipo/interesados. |
Aceptación de responsabilidades de cada interesado. |
|
|
Interesados |
Ofrecer mecanismos para lograr un alto grado de compromiso, involucramiento y participación de las autoridades con el proyecto. |
Confirmación a partir de un repositorio de documentos permitió que las autoridades se sientan involucradas en el proyecto. Cantidad de veces ingresado. |
|
Proveer el respaldo de las autoridades al equipo de trabajo. |
La dinámica de la comunicación permitió sentir el respaldo suficiente. |
|
|
Identificación de los principales interesados y apoyo a sus necesidades, intereses y capacidades. |
Confirmación, los miembros del Comité, se mostraron proactivos a aplicación de la Propuesta. |
Tabla 1. Estructura de Equipo de Gestión: Verificación de Requisitos
PRE-PROYECTO: El punto de inicio de la Propuesta Metodológica de Definición del Proyecto es cuando el Director de Departamento de Informática, en conjunto con el Director de Rentas, el Jefe de TGI (Tasa General Inmobiliaria) y el Jefe de OSM (Obras Sanitarias Municipales), arman una Propuesta del Proyecto, delimitando el contexto del proyecto. Dicha Propuesta del Proyecto es presentada al resto de los miembros del Comité de Proyecto, vía correo electrónico para su conocimiento y aprobación. Esta Propuesta es muy sencilla, puede ser expresada a través de un correo electrónico o una charla informal, entre el Director de Departamento de Informática y otros interesados claves, como el Secretario de Hacienda o el Director de Rentas. Si todos los miembros presentan su acuerdo mediante una respuesta afirmativa vía correo electrónico, se procede al siguiente paso que es la descripción detallada del Resumen o Carta del Proyecto. El Director de Proyecto, crea una sección Documentos donde allí se guardan todos los documentos vinculados al proyecto y tienen acceso al mismo todas las partes interesadas. De esta forma se logra una amplia difusión de la documentación.
VISIÓN/ DEFINICIÓN: En esta segunda etapa de la Fase 1, a partir de la documentación generada en el Pre-Proyecto, es necesario documentar todo lo relacionado con la definición, planificación, coordinación e integración de los planes de lanzamiento. Se confecciona el documento más importante del proyecto, el Plan de Administración del Proyecto o Plan de Gestión del Proyecto. Se define el trabajo a realizar (cómo se hará y cómo se controlará). En el caso del proyecto ISAT, este documento lo armó el Director de Proyecto en conjunto con el Experto Funcional Tributario mediante la técnica de Juicio de Expertos. En general, su contenido varía de acuerdo a la naturaleza de los proyectos y es elaborado progresivamente a través de actualizaciones y controles.
Al realizar las actividades incluidas en el Pre-Proyecto y Visión/Definición del proyecto ISAT, se ha comprobado la generación de los siguientes documentos: Acta del Proyecto, Lista de Interesados, Plan de Administración, Plan de Gestión de Interesados, Plan de Comunicaciones y Lecciones Aprendidas. Además de la verificación de los requisitos afectados en la fase de inicio de la Propuesta Metodológica.
La Tabla 2 determina el cumplimiento de los requisitos implicados en la Fase 1.
|
Dimensión |
Requisitos |
Acción de verificación |
|
Formación y Crecimiento |
Ofrecer mecanismos para permitir reuniones periódicas, claras y concisas. |
Confirmación a partir de la participación a las reuniones. Duración de las reuniones 30 minutos. |
|
Elaborar flujo de comunicación entre los miembros del equipo, el director de proyecto y los interesados. |
Cada interesado y miembro del equipo tenía bien determinado a quien dirigirse, la forma y el medio, lo que permitió un claro flujo de comunicación. |
|
|
Ofrecer mecanismos para generar espacios para el intercambio de experiencias. |
Confirmación a partir de las reuniones de retrospectiva. |
|
|
Tener métodos definidos para una correcta selección de personal. |
No se aplicó selección de personal. |
|
|
Lograr compenetración en el equipo/moral. |
El Director de Proyecto estaba atento al comportamiento de su equipo. |
|
|
Dimensión |
Requisitos |
Acción de verificación |
|
Procesos Internos |
Proveer componentes para lograr precisión y claridad en la definición del alcance y las responsabilidades. |
El Director de Proyecto hizo uso de experiencias anteriores. |
|
Proveer mecanismos para la elaboración de una estructura objetiva del proyecto, por prioridades. |
Se logró por medio de la subdivisión de entregables. |
|
|
Ofrecer mecanismos para la definición de políticas y procedimientos de gestión de proyectos. |
Confirmación a partir de las reuniones efectuadas: participación de los interesados convocados, cantidad de consultas realizadas. |
|
|
Permitir la creación jerárquica de las actividades o tareas. |
Confirmación a través del uso de software de gestión de proyectos. |
|
|
Ofrecer herramientas para cumplir con la calendarización, secuenciación y control de las actividades o tareas. |
Confirmación a través del uso de software de gestión de proyectos. |
|
|
Proveer mecanismos para la identificación de los procesos críticos. |
Confirmación a través del uso de software de gestión de proyectos. |
|
|
Permitir la flexibilidad en la implementación de los procesos. |
Provisto por la dinámica de los entregables. |
|
|
Promover prácticas ágiles en los procesos. |
Provisto por la dinámica de los entregables. |
|
|
Permitir la identificación y posterior evaluación de los riesgos del proyecto. |
Se listaron los riesgos y se evaluaron cualitativamente cada uno de ellos. |
|
|
Interesados |
Ofrecer mecanismos para lograr un alto grado de compromiso, involucramiento y participación de las autoridades con el proyecto. |
Confirmación a partir de un repositorio de documentos permitió que las autoridades se sientan involucradas en el proyecto. Cantidad de veces ingresado. Asistencia a las reuniones convocadas. Cantidad de soluciones a problemas presentados Tiempo de respuestas a las consultas realizadas utilizando distintos canales. |
|
Proveer el respaldo de las autoridades al equipo de trabajo. |
Asistencia a las reuniones convocadas. Cantidad de soluciones a problemas presentados Tiempo de respuestas a las consultas realizadas utilizando distintos canales. |
|
|
Lograr un alto grado de compromiso y participación de los interesados claves. |
Confirmación a partir del uso de checklist entre los interesados. |
|
|
Ofrecer mecanismos para lograr un grado aceptable de compromiso y participación de los interesados: usuarios y usuarios claves. |
El uso de repositorio de documentación y de herramientas de software y la experiencia de expertos y reuniones para intercambiar y analizar información acerca del compromiso y la participación de los interesados. |
|
|
Dimensión |
Requisitos |
Acción de verificación |
|
Interesados |
Proveer mecanismos para la lograr con precisión y claridad la definición del alcance y las responsabilidades. |
Confirmación a partir de las reuniones establecidas por el Director de proyecto y miembros del Comité. |
|
Ofrecer técnicas para obtener un flujo continuo de comunicación entre las autoridades y el director de proyecto. |
Utilización del correo interno de la organización y/o teléfono celular. |
|
|
Identificación de los principales interesados y apoyo a sus necesidades, intereses y capacidades. |
Se identificaron los miembros del Comité y los miembros del equipo de gestión. |
|
|
Realizar seguimiento permanente a cada una de las obligaciones contractuales, analizándolas de manera independiente, así como realizar un análisis integral de la ejecución de la orden o contrato, en su conjunto. |
El Director del Proyecto hacia el seguimiento necesario. |
|
|
Técnicas |
Proveer amplia cantidad de herramientas y técnicas de comunicación acordes a emisor/receptor. |
Confirmación a partir de las formas de comunicación conocidas por los interesados. |
|
Identificar tecnologías y herramientas aplicables y adaptadas a las necesidades del proyecto y la organización. |
El equipo técnico tuvo un tiempo suficiente para la identificación de las tecnologías. |
|
|
Brindar mecanismos que permitan el seguimiento del estado de los riesgos. |
Se realizó a través de la documentación del Repositorio. |
|
|
Lograr generar técnicas de difusión de políticas de documentación, organización y coordinación del equipo. |
Repositorio guardado en la herramienta RedMine, correos electrónicos, reuniones semanales. |
|
|
Lograr generar documentación justa, ni excesiva ni insuficiente a los interesados. |
Verificación permanentemente de la cantidad de documentación asociada. |
|
|
Ofrecer mecanismos para definir políticas que regulen la creación de la documentación y estimulen su consulta. |
Se plasmaron y distribuyeron los mismos. Se aprobaron y aceptaron los mismos, midiendo la cantidad de accesos a los mismos. |
Tabla 2. Fase 1: Verificación de Requisitos
PREPARACIÓN: Este paso toma como punto de partida los procesos críticos y sus respectivos requerimientos priorizados del Plan de Administración del Proyecto. Se prepara todo lo necesario para ejecutar el proyecto. En base al Plan de Administración del Proyecto, que contiene la Lista de Requerimientos, se arman los Planes de Lanzamiento de los Entregables. Para este proyecto el Director de Proyecto junto a los demás interesados, armaron ocho planes de lanzamiento, donde cada Plan de Lanzamiento debe estar aprobado y firmado por los miembros del Comité de Proyecto.
DESARROLLO COLABORATIVO: El Director de proyecto presenta el Plan de Lanzamiento a ser ejecutado (y que es resultado del componente anterior), a los miembros de su equipo de trabajo. El primer objetivo es que todos entiendan el trabajo al que están comprometidos a entregar, cómo lo van a ejecutar y el tiempo que estiman necesario. La implementación del Proyecto ISAT se efectúo en los horarios normales de trabajo de todos los interesados. Se destaca que el tiempo, en las primeras reuniones, fue superior, hasta que se logró que los miembros del equipo adquieran entrenamiento y así una mejor utilización del tiempo. En las reuniones los miembros del equipo hacen un chequeo del avance del Plan de Lanzamiento del entregable. Cada integrante informa el “qué” están ejecutando y el “cómo”, es decir, responde a las preguntas de Scrum: ¿cuál fue mi avance desde la última reunión?, ¿en cuáles tareas me comprometo a trabajar hasta la próxima reunión? y ¿qué problemas frenan o bloquean el avance? A partir de la puesta en marcha el Plan de Lanzamiento del primer entregable, los miembros van tomando las tareas y las resuelven. Cuando el Director de Proyecto lo cree necesario, en un tiempo no mayor a 2 semanas, se establece una reunión denominada Retrospectiva (Scrum), donde se demuestra concretamente el avance del entregable y se recibe la retroalimentación del Jefe de TGI y del Jefe de OSM. El objetivo de esta reunión es escuchar los distintos puntos de vista de los miembros del proyecto internos al Departamento de Informática, identificar colaborativamente las causas de los principales problemas del equipo durante la ejecución de las tareas e idear, consensuar y seleccionar acciones de mejora concretas que los miembros del equipo seleccionan para seguir avanzando. Como resultado de esta reunión se genera un documento (primero tipo borrador) denominado Lecciones Aprendidas. En esta etapa, el Director de Proyecto debe estar atento a la detección de cualquier problema o conflicto y/o necesidades de capacitación de los mismos. En caso que durante el desarrollo colaborativo los miembros del equipo, el Director de Proyecto, y/o alguno de los miembros del Comité de Proyecto, necesiten cambiar o modificar algún requerimiento prioritario, mediante la opción “Nueva petición” se procede a la misma.
ADAPTACIÓN, DIRECCIÓN, MONITOREO y CONTROL: Este componente debe integrar los anteriores. El Director del Proyecto se encarga de ir comunicando y aprobando los cambios y avances a los demás miembros del Comité de Proyecto. Además, debe monitorear el trabajo y el comportamiento de los miembros del equipo del proyecto. Esto lo hace luego de cada reunión de retrospectiva, donde completa el documento Desempeño del Equipo. Cada vez que el Director de Proyecto y el Equipo de Proyecto llevan a cabo reuniones para la revisión de seguimiento, en donde se evalúa lo que se ha realizado y lo que se va a realizar, el Director de Proyecto además completa el Formulario de Evaluación de Desempeño del Equipo. Esto le permite ir monitoreando el comportamiento de los miembros del Equipo de Proyecto. El Director del Proyecto va actualizando el estado del Plan de Administración del Proyecto hasta el paso a la próxima fase. Toda solicitud de cambio que pueda surgir deberá ser aprobada por los miembros del Comité de Proyecto o por el Director de Proyecto, dependiendo de la envergadura de la misma.
Al realizar las actividades incluidas en la Preparación, Desarrollo Colaborativo y, Adaptación Dirección, Monitoreo y Control del proyecto ISAT, se han comprobado la generación de los siguientes documentos: plan de lanzamiento, plan de administración, plan de gestión de interesados, plan de comunicaciones, entregables aceptados, desempeño del equipo y lecciones aprendidas. Además de la verificación de los requisitos afectados en la segunda fase de la Propuesta Metodológica.
Dada la criticidad del proyecto y el ajuste de tiempos, se puso énfasis en establecer un calendario de reuniones semanales de control y reuniones de coordinación en función de las necesidades del proyecto o para la toma de decisiones consensuadas. Por cada incidencia producida obligaba a convocar reuniones de carácter inmediato.
El estado del proyecto se iba actualizando dinámicamente en función de las desviaciones, incidencias y riesgos que se detectaban. Esto se vio favorecido por la dinámica de comunicación establecida y el grado de conocimiento del Director de Proyecto, lo cual permitía la toma de decisiones con rapidez.
La información generada en cada actividad o tarea, significó cambios en cuanto al formato y detalle de cada ítem establecido. Es decir, al inicio se manejaba solo por los nombre de cada documento según lo establecido por la Propuesta Metodológica y a medida que fue avanzando la gestión del proyecto, se fueron ajustando hasta la elaboración de plantillas para cada documento. La Tabla 3 determina el cumplimiento de los requisitos implicados en la Fase 2.
|
Dimensión |
Requisitos |
Acción de verificación |
|
Formación y Crecimiento |
Ofrecer mecanismos para la cooperación y el apoyo entre los miembros del equipo. |
Confirmación a partir de la generación de reuniones recreativas entre los miembros del equipo, permitiendo identificar situaciones problemáticas |
|
Ofrecer mecanismos para permitir reuniones periódicas, claras y concisas. |
Se realizaron de acuerdo a lo establecido en la Propuesta Metodológica y con toda la información que le corresponde |
|
|
Desarrollar la capacidad para trabajar en equipo, integrarse y colaborar de forma activa en la consecución de objetivos comunes. |
El Confirmación a partir de la generación de reuniones recreativas entre los miembros del equipo. |
|
|
Ofrecer mecanismos para desarrollar las habilidades de gestión del director del proyecto. |
Asistencia a tres cursos de desarrollo de habilidades de gestión de proyectos. |
|
|
El director del proyecto debe alcanzar un alto grado de poder de convicción a las autoridades. |
Confirmación a través de la aceptación del trabajo y constante apoyo al director de proyecto. |
|
|
Aplicar técnicas para lograr un alto grado de satisfacción de las autoridades, el equipo de proyecto, interesados y contratistas. |
Se logró a través de encuestas electrónicas. |
|
|
Ofrecer mecanismos para generar espacios para el intercambio de experiencias. |
Se realizaron de acuerdo a lo establecido en la Propuesta Metodológica y con toda la información correspondiente. |
|
|
Disponer acciones de logísticas ágiles. |
Cada miembro del equipo determinó el nuevo objetivo en cada reunión y asignó el tiempo a cada uno de ellos. Los objetivos debe ser alcanzables y el equipo sólo abordará un conjunto de tareas asumible. |
|
|
Ofrecer mecanismos para el desarrollo de habilidades en el equipo. |
Cada miembro del equipo realizó un curso de capacitación. |
|
|
Brindar definiciones de responsabilidades del equipo/interesados. |
Provistas por la estructura del equipo de gestión |
|
|
Lograr compenetración en el equipo/moral |
Se generaron reuniones no pautadas |
|
|
Procesos Internos |
Proveer componentes para lograr precisión y claridad en la definición del alcance y las responsabilidades. |
El Director de Proyecto y demás interesados proveyeron información sobre las actividades del proyecto basados en su experiencia, habilidades y conocimientos. |
|
Proveer mecanismos para definir los procesos para la integración del proyecto. |
Confirmación a través del uso de software de gestión de proyectos. |
|
|
Permitir la creación jerárquica de las actividades o tareas. |
Confirmación a través del uso de software de gestión de proyectos. |
|
|
Ofrecer herramientas para cumplir con la calendarización, secuenciación y control de las actividades o tareas. |
Confirmación a través del uso de software de gestión de proyectos. |
|
|
Proveer mecanismos para la identificación de los procesos críticos. |
Confirmación a través del uso de software de gestión de proyectos. |
|
|
Dimensión |
Requisitos |
Acción de verificación |
|
Procesos Internos |
Permitir la flexibilidad en la implementación de los procesos. |
Provisto por la dinámica de los entregables. |
|
Promover prácticas ágiles en los procesos. |
Provisto por la dinámica de los entregables. |
|
|
Permitir la identificación y posterior evaluación de los riesgos del proyecto. |
Se listaron los riesgos y se evaluaron cualitativamente cada uno de ellos. |
|
|
Interesados |
Proveer el respaldo de las autoridades al equipo de trabajo. |
La dinámica de la comunicación permitió sentir el respaldo suficiente. |
|
Lograr un alto grado de compromiso y participación de los interesados claves. |
El uso de repositorio de documentación y de herramientas de software permitió otorgar responsabilidades distribuidas en forma igualitaria |
|
|
Involucrar a los usuarios y usuarios claves |
A través de reuniones diarias programadas donde la estructura de equipo de gestión y el hacer uso de las experiencias de los usuarios claves permitió crear empatía entre los mismos. |
|
|
Ofrecer mecanismos para lograr un grado aceptable de compromiso y participación de los interesados: usuarios y usuarios claves. |
Confirmación a través de la cantidad de veces que se accedió al repositorio de documentación y la utilización de herramientas de software y posteriores reuniones. |
|
|
Suministrar técnicas para logar un grado de aceptación del producto final, entre los interesados y las autoridades. |
Se logró a través de encuestas electrónicas. |
|
|
Ofrecer técnicas para obtener un flujo continuo de comunicación entre las autoridades y el director de proyecto. |
Uso de correo interno de la organización y/o teléfono celular. |
|
|
Realizar seguimiento permanente a cada una de las obligaciones contractuales, analizándolas de manera independiente, así como realizar un análisis integral de la ejecución de la orden o contrato, en su conjunto. |
El Director del Proyecto realizó el seguimiento necesario, enumerando y describiendo la información necesaria para planificar las contrataciones, además de utilizar técnicas de negociación. |
|
|
Técnicas |
Proveer amplia cantidad de herramientas y técnicas de comunicación acordes a emisor/receptor. |
Uso de correo interno de la organización, chat o reuniones no previstas. |
|
Deber identificar tecnologías y herramientas aplicables y adaptadas a las necesidades del proyecto y la organización. |
El equipo técnico tuvo un tiempo suficiente para la identificación de las tecnologías |
|
|
Ofrecer técnicas estrictas de seguimiento y control del proyecto. |
Se utilizó software de gestión de proyectos |
|
|
Brindar mecanismos que permitan el seguimiento del estado de los riesgos. |
Se utilizó software de gestión de proyectos, y documentación |
|
|
Lograr generar técnicas de difusión de políticas de documentación, organización y coordinación del equipo. |
El uso de repositorio de documentación y de herramientas de software y la experiencia de expertos y reuniones para intercambiar y analizar información acerca del compromiso y la participación de los interesados. |
|
|
Lograr generar documentación justa, ni excesiva ni insuficiente a los interesados. |
Se verificó permanentemente la cantidad de documentación asociada. |
Tabla 3: Fase 2: Verificación de Requisitos
CIERRE: se apunta a efectuar un cierre claro y ordenado del proyecto en el que se ha implementado la Propuesta Metodológica. El Director de Proyecto junto con el Equipo de Proyecto, revisan que todos los Planes de Lanzamiento estén cerrados y revisa que las peticiones afectadas a cada plan estén en estado completo. Luego el Director de Proyecto se reúne con los miembros del Comité de Proyecto y a través de una presentación formal, se proyectaron a través de diapositivas partes de los planes y muestras del sistema funcionando, con la impresión de reportes, de consultas por pantallas, y de otras solicitudes realizadas durante la reunión. Finalmente se elabora un Acta de cierre del proyecto y todos los miembros Comité de Proyecto firman la aceptación del mismo. Este documento se adjunta a los restantes documentos del proyecto.
POS-PROYECTO, MANTENIMIENTO y MEJORA CONTINUA: Este paso refiere a las mejoras y mantenimiento a efectuarse en el proyecto, para lo que el usuario representativo genera una petición y la misma es evaluada por el Director de Proyecto y su Equipo y se procede a completar un documento denominado Plan de Mantenimiento y Mejora Continua. En este documento se describe la petición y el solicitante del mismo, y la correspondiente aprobación o rechazo de los miembros del Comité de Proyecto, a través de una reunión. En esta etapa se inicia todo lo relacionado al mantenimiento y la mejora continua.
Al realizar las actividades incluidas en el Cierre y Pos-Proyecto, Mantenimiento y Mejora Continua del proyecto ISAT, se ha comprobado la generación de los siguientes documentos plan de administración cerrado, desempeño del proyecto y lecciones aprendidas, además de la verificación de los requisitos afectados en la última fase de la Propuesta Metodológica.
La Tabla 4 determina el cumplimiento de los requisitos implicados en la Fase 3.
|
Dimensión |
Requisitos |
Acción de verificación |
|
Formación y Crecimiento |
Alcanzar popularidad aceptable para con los pares. |
Confirmación que el director del proyecto tenga la antigüedad mínima (19 años de antigüedad en la Administración Pública y 13 años como Director del Departamento de Informática). |
|
Aplicar técnicas para lograr un alto grado de satisfacción de las autoridades, el equipo de proyecto, interesados y contratistas. |
Confirmación a partir de las reuniones efectuadas: participación de los interesados convocados, cantidad de consultas realizadas. Realización de encuestas electrónicas. |
|
|
Ofrecer mecanismos para generar espacios para el intercambio de experiencias. |
Confirmación a partir de las reuniones previstas por la Propuesta. |
|
|
Procesos Internos |
Ofrecer mecanismos para la definición de políticas y procedimientos de gestión de proyectos. |
Confirmación a partir de las reuniones efectuadas: participación de los interesados convocados, cantidad de consultas realizadas. |
|
Dimensión |
Requisitos |
Acción de verificación |
|
Interesados |
Ofrecer mecanismos para lograr un grado aceptable de compromiso y participación de los interesados: usuarios y usuarios claves. |
El uso de repositorio de documentación y de herramientas de software |
|
Suministrar técnicas para lograr un grado de aceptación del producto final, entre los interesados y las autoridades |
Se logró a través de encuestas electrónicas |
|
|
Realizar seguimiento permanente a cada una de las obligaciones contractuales, analizándolas de manera independiente, así como realizar un análisis integral de la ejecución de la orden o contrato, en su conjunto. |
El Director del Proyecto hacia el seguimiento necesario y posterior cierre de los mismos. |
|
|
Técnicas |
Lograr generar técnicas de difusión de políticas de documentación, organización y coordinación del equipo. |
El uso de repositorio de documentación y de herramientas de software y la experiencia de expertos y reuniones para intercambiar y analizar información acerca del compromiso y la participación de los interesados. |
|
Lograr generar documentación justa, ni excesiva ni insuficiente a los interesados. |
Verificación permanentemente de la cantidad de documentación asociada. |
|
|
Ofrecer mecanismos para definir políticas que regulen la creación de la documentación y estimulen su consulta. |
Se plasmaron y distribuyeron los mismos. Se aprobaron y aceptaron los mismos, midiendo la cantidad de accesos a los mismos. |
Tabla 4: Fase 3: Verificación de Requisitos
La vigencia permanente de cada uno de los requisitos involucrados en cada fase de la Propuesta Metodológica de enfoque “híbrido”, permite mantener la dinámica entre equipo de proyecto y los interesados para con las actividades afectadas a cada uno. Además, a medida que se fue avanzando en la aplicación de la Propuesta Metodológica, todos los interesados se mostraban involucrados en el proyecto, con lo que permitió conseguir una mayor confianza y rendimiento en el trabajo diario. Esto permitió responder varios interrogantes planteados en la introducción de este trabajo, entre ellos los vinculados con la verificación y calibración de los requisitos asociados al tratamiento de la documentación, ya que inicialmente y siguiendo las propuestas de PRINCE2 y PMBok, la documentación era mayor, los interesados han revelado la necesidad de mejorar las mismas, por lo que se ha logrado disminuir la documentación generada. Por otro lado, se determinó que quedaron consideraciones sin incluir, tales como la gestión de riesgos. Por otra parte, a partir de la validación de la Propuesta Metodológica a un caso real, permitió demostrar la credibilidad de los interesados en la utilización de la misma, ya que se mostraron muy dispuestos a la utilización de la misma, en la gestión de sus proyectos.
Este artículo presentó la verificación, validación y calibración de los requisitos contenidos en la Propuesta Metodológica para la gestión de proyectos TICs en el ámbito de la Administración Pública, a partir de la implementación de la misma en un caso de estudio. El principal aporte de esta investigación surge a partir de mejorar la gestión de los proyectos de TICs. Esto logrado por la colaboración entre las partes interesadas, permitiendo integrar áreas vinculadas con el proyecto, por medio de la definición y ejecución en forma conjunta. Si bien se efectuaron las acciones de verificación de los requisitos planteados, es necesario establecer para cada uno un conjunto de métricas que permitan evaluar el cumplimiento de los requisitos en las distintas etapas del proyecto.
Se considera una mejora a incorporar como trabajo futuro, establecer métricas para cada requisito y la posibilidad de generar y aplicar una herramienta que permita cargar y monitorear los requisitos de éxito asociados a cada fase del proyecto.
MetricaV3. (2000). Metodología de planificación, desarrollo y mantenimiento de sistemas de información. Métrica Versión 3. Ministerio de Hacienda y Administraciones Públicas. Gobierno de España.
Chow, T.; Chao. D. (2008) A survey of critical success factors in agile software projects. Journal of systems and software, Jun. Available: Science Direct, 81(6):961–971.
ElEmam, K.; Koru, A.G. (2008). A replicated survey of IT software project failures Software. IEEE Software, vol. 25, pp. 84–90.
Böhm, A. (2009) Application of PRINCE2 and the Impact on Project Management. ISBN (eBook) 978-3-640-42634-8.
Highsmith, J. (2010). Agile project management: creating innovative products. 2nd ed. Boston, MA: Addison-Wesley. 432 p.
Schwaber, K.; Sutherland, J. (2011). The Scrum Guide, the Definitive Guide to scrum: The Rules of the Game.http://www.scrum.org/Portals/0/Documents/ScrumGuides/Scrum_Guide.pdf, (acceso 14.02.17).
Project Management Institute. (2013). A Guide to the Project Management Body of Knowledge. Fifth Edition (PMBOK Guide). Newtown Square, PE: Project Management Institute.
Elkadi, H. (2013). Success and failure factors for e-government projects: A case from Egypt. Egyptian Informatics Journal, 14, pp. 165–173.
Colomo-Palacios, R., Casado-Lumbreras, C. Soto-Acosta, P., García-Peñalvo, F.J., Tovar-Caro, E. (2014).Project managers in global software development teams: a study ofthe effects on productivity and performance, Software Quality. 22 (1)3–19.
Cristaldo P., Ballejos L., Ale M., (2014). Metodologías y Guías de Gestión de Proyectos de TICs en el Sector Público: Enfoque Tradicional vs. Enfoque Ágil. II Congreso Nacional de Ingeniería Informática y Sistemas de Información, CONAIISI, Universidad Nacional de San Luis, Argentina. ISSN: 2346-9927(2).
Lehtinen, T.; Mäntylä, M.; Vanhanen, J.; Itkonen, J.; Lassenius, C. (2014). Perceived causes of software project failures – An analysis of their relationships. Information and Software Technology 56, pp. 623–643.
Ramos, p.; Mota, c. (2014).Perceptions of success and failure factors in information technology projects: a study from Brazilian companies. Procedia - Social and Behavioral Sciences 119, pp. 349 – 357.
Ramos, p.; Mota, c. (2014).Perceptions of success and failure factors in information technology projects: a study from Brazilian companies. Procedia - Social and Behavioral Sciences 119, pp. 349 – 357.
Sutherland, J. (2014). Scrum: The art of doing twice the work in half the time. New York: Crown Business. 256 p. ISBN-10: 038534645X, ISBN-13: 978-0385346450.
Varajão, J. Dominguez, C. Ribeiro, P. Paiva, A. (2014). Critical success aspects in Project management: similarities and differences between the construction and softwareindustry, Tech. Gazette 21 (3) 583–589.
Cristaldo P., Ballejos L., Ale M.,(2015).Un enfoque híbrido de gestión de proyectos de TICs en el sector público; JAIIO 2015; 44 Jornadas Argentinas de Informática. Universidad Nacional de Rosario, Facultad de Ingeniería, Argentina,
Montequin, S.; Fernandez, C.; Fernandez, O.; Balsera, J.V. (2016) Analysis of the Success Factors and Failure Causes in Projects: Comparison of the Spanish Information y Communication Technology (ICT) Sector. Journal Information Technology Project Management, Vol. 7(1), pp. 18-31.
Varajão, J. (2016). Success Management as a PM knowledge area – work-in-progress. Procedia Computer Science. Vol. 100, pp.1095 – 1102.
ATERN. http://www.dsdm.org/dig-deeper/book/dsdm-atern-handbook
A la Municipalidad de Concepción del Uruguay, Entre Ríos y especialmente al Departamento de Informática.