MARTÍN EDUARDO AYALA GUTIÉRREZ

UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN

PROGRAMA DE MAGISTER

Diseño y adaptación de la función de aseguramiento de proyectos informáticos

Caso: Gerencia de Proyectos en el Banco de la República MISC – 3 – 1 – 3

Enero de 2004

AGRADECIMIENTOS Doy gracias a DIOS y a la vida por brindarme la oportunidad de vivir esta hermosa experiencia; definitivamente el camino por recorrer es largo y son muchos los grandes momentos que aún nos quedan por vivir. Quiero también agradecer a todas aquellas personas que estuvieron presentes durante el desarrollo de este trabajo, quienes me brindaron su apoyo y compartieron conmigo sus valiosas opiniones. En particular, quiero expresar mi más profundo agradecimiento a mis hijos Sebastián y Valentina, motores de mi vida y para quienes dedico este esfuerzo; a mi preciada y amada esposa María Oti por su apoyo y paciencia; a mis padres, hermanos y sobrinos por toda esa gran energía. Gracias a la Universidad de los Andes; a mis asesoras, las profesoras Olga Lucía Giraldo y Ángela Carrillo, así como a los demás profesores por compartir su valioso conocimiento y amistad; a mis compañeros de clase y amigos, a Fabio Ortega y Freddy Reyes por sus críticas constructivas. Muchas gracias a mis compañeros de trabajo y amigos en el Banco de la República, me siento privilegiado de hacer parte de ese gran equipo. Especiales gracias a Jorge Gil y Rocío Villegas por propiciar esto; a Alberto Cueto por sus sabias o oportunas opiniones; a Fernando Ferrer por sacrificar parte de su valioso tiempo y compartir su igualmente valioso conocimiento, a todo el Departamento de Control Interno, pues son un gran equipo.

ÍNDICE

I. INTRODUCCIÓN

A. Resumen B. Objetivo general C. Objetivos específicos D. Etapas del trabajo de investigación

D.1. Investigación bibliográfica D.2. Entorno de aplicación de la función de aseguramiento del proyecto D.3. Estructuración de la propuesta D.4. Validación y ajustes a la propuesta

II. MARCO TEÓRICO

A. Reseña histórica B. Definición de proyecto

B.1. Términos relacionados con el concepto proyecto B.2. El concepto proyecto B.3. Características generales de un proyecto B.4. Restricciones básicas de un proyecto

C. Una clasificación de proyectos C.1. Definición de proyectos informáticos

D. Una clasificación de proyectos informáticos D.1. Definición de proyectos de desarrollo de software a la medida

E. Actores en un proyecto de desarrollo de software a la medida E.1. Grupo cliente E.2. Grupo de usuarios E.3. Grupo proveedor

F. Una estructura para un proyecto de desarrollo de software a la medida F.1. Identificación de problemas, oportunidades y objetivos de la organización F.2. Determinación o definición de los requerimientos de información F.3. Análisis de las necesidades del nuevo sistema de información F.4. Diseño del sistema de información recomendado F.5. Desarrollo y documentación del software F.6. Pruebas de aceptación del software F.7. Implantación del sistema F.8. Mantenimiento del sistema en operación

III. GERENCIA DE PROYECTOS

A. Antecedentes B. Definición de Gerencia de Proyectos C. Razones para la Gerencia de Proyectos D. Elementos básicos en la Gerencia de Proyectos E. La Gerencia de Proyectos según el PMI

F. La Gerencia de Proyectos según PRINCE2 G. Definición de la función de aseguramiento del proyecto

IV. ANÁLISIS Y DIAGNÓSTICO DEL PROBLEMA

A. Aspectos de la Gerencia de Proyectos en Colombia B. Situación de la Gerencia de Proyectos en el Banco de la República

B.1. Contexto del Banco de la República B.2. Estructura organizacional del Banco de la República B.3. La gerencia de proyectos en el Banco de la República

V. IMPLEMENTACIÓN DE LA PROPUESTA

A. Terminología B. Estructuración de la propuesta

B.1. Componentes de la gerencia de proyectos en la función AP C.2. Estructura organizacional del modelo C.3. Roles y/o responsabilidades asociadas con el aseguramiento del proyecto C.4. Productos o entregables en el aseguramiento del proyecto

C. Aplicación al caso de estudio D. Conclusiones

VI. BIBLIOGRAFÍA

1

I. INTRODUCCIÓN

A. Resumen La historia de los proyectos informáticos, específicamente de aquellos relacionados con el desarrollo de sistemas de información a la medida, está inundada de estadísticas desalentadoras. Desafortunadamente, es significativo el porcentaje de proyectos que no culminan y aquellos que lo hacen, no cumplen las expectativas de quienes tienen allí representados o invertidos sus intereses. Algunos estudios realizados [5] sustentan que casi dos tercios de todos los proyectos informáticos superan ampliamente las estimaciones iniciales; existen datos de proyectos complejos que sufren retrasos con respecto a su finalización entre un 25% y 50% de su duración proyectada; y en la medida que el tamaño de estos se incrementa, el retraso promedio muestra un comportamiento en tendencia similar hacia el alza. Igualmente conocido es el número de metodologías que inundan el mercado y proponen soluciones casi inmediatas a los problemas relacionados con el manejo y control de proyectos, garantizando la completa satisfacción de las partes. Es allí donde muchas organizaciones caen cuando se aventuran a aplicarlas bajo la promesa de que las soluciones están a la vuelta de la esquina y sólo es cuestión de ir y tomarlas, desconociendo las condiciones o el contexto bajo el cual se garantizan los resultados de dichas metodologías. Los riesgos y, en especial, el alcance real de las consecuencias no deseadas que pueden derivarse de proyectos no exitosos, ha creado conciencia en muchas organizaciones sobre la necesidad de apoyar sus acciones en un esquema confiable de gerencia de proyectos; así como, del especial cuidado que debe tenerse en la selección y adaptación del tipo de metodología que debería apoyar dicho esquema. En el contexto de las organizaciones colombianas, puede tomarse el ejemplo del Banco de la República, que definió dentro de sus metas tácticas incrementar el nivel de eficiencia en el desarrollo de los proyectos informáticos sin disminuir los niveles de servicio. Para ello, buscó, seleccionó y adaptó una metodología para la planeación y gerencia de proyectos1 informáticos, la cual para su realización, se descompuso en dos fases principales: una fase de planeación, selección y adecuación de la solución; y otra de implantación, configuración, control y mantenimiento. Parte del alcance del presente trabajo de investigación fue proporcionar al Banco de la República una propuesta de definición e implementación de un componente de la gerencia de proyectos informáticos. En términos generales, en cualquier programa de gerencia de proyectos convergen diversos aspectos del campo de la administración como la planeación, organización, coordinación y control [3]. Mediante el apoyo de un recurso humano calificado se busca predecir o determinar un comportamiento general de resultados basados en la satisfacción de todos los equipos de personas involucrados en un proyecto. Sin embargo, el desarrollo de la humanidad, caracterizado por una demanda creciente de nuevos productos y servicios cada vez más complejos y eficientes, ha requerido mejorar las percepciones iniciales de la

1 En lo sucesivo de este documento los términos Gerencia de Proyectos y Administración de Proyectos se utilizarán indistintamente.

2

gerencia de proyectos mediante el planteamiento y ajuste de procesos y otras alternativas que permitan una evolución integral para responder adecuadamente a las nuevas exigencias. Es así, que con el presente estudio se busca suministrar una alternativa de solución que apoye el programa de Gerencia de Proyectos para realizar proyectos con mayores posibilidades de éxito en el logro satisfactorio de las metas y objetivos. Ésta comprende la adaptación e implantación de la función de aseguramiento del proyecto, del término original “project assurance”, como parte de la metodología que el Banco de la República ha trazado para diseñar e implantar su programa de Gerencia de Proyectos Informáticos. La función de aseguramiento del proyecto es un componente de la Gerencia de Proyectos cuyos objetivos son apoyar a la alta gerencia para facilitar la adecuada y oportuna toma de decisiones relacionadas con las condiciones de desempeño de los proyectos que adelanta la organización; y asesorar a los gerentes de proyecto en las mejores prácticas, incluidos estándares, procedimientos y controles, que propendan por un desarrollo eficiente y confiable de las actividades tendientes al logro de los objetivos de cada proyecto.

B. Objetivo General El objetivo general del presente trabajo de investigación comprende estudiar y evaluar algunos estándares de gerencia de proyectos para diseñar y/o modelar una propuesta de la función de aseguramiento del proyecto, como parte de una solución a un programa de estructuración de una metodología de gerencia de proyectos informáticos, adaptada, como caso de estudio, en el Banco de la República. Mediante el trabajo se intenta contribuir con una herramienta que sirva de alternativa para resolver parte de los problemas que se presentan en el desarrollo o ejecución de proyectos informáticos, en especial los relacionados con la adquisición de soluciones de software a la medida. La mayoría de estos problemas se relacionan con la insatisfacción o desconcierto que los interesados en un proyecto – Stakeholders, experimentan ante los productos finales o servicios generados.

C. Objetivos específicos - Definir el concepto de gerencia de proyectos para determinar los principales beneficios

de su aplicación en los proyectos informáticos; en particular, aquellos relacionados con el desarrollo de software a la medida.

- Identificar en algunos estándares de gerencia de proyectos, formas de estructuración o

configuración de la función de aseguramiento del proyecto. - Modelar, mediante un análisis comparativo, una propuesta de la función da

aseguramiento del proyecto que pueda ser aplicada en los proyectos de desarrollo de software a la medida.

3

- Generar una propuesta de adaptación e implantación de la función modelada y aplicarla, como caso de estudio, al programa de gerencia de proyectos informáticos en el Banco de la República.

D. Etapas del trabajo de investigación

Para la consecución del objetivo general y de los correspondientes objetivos específicos, fue necesario descomponer el trabajo en cuatro actividades o etapas específicas, a saber: D.1. Investigación Bibliográfica Comprende la recolección de información relacionada con gerencia de proyectos, selección de los estándares representativos y análisis comparativo de las actividades asociadas a la función de aseguramiento del proyecto. El análisis está circunscrito a los siguientes estándares:

- Guía PRINCE2 – PRoject IN Controlled Environments, metodología definida como estándar de facto para programas de gerencia de proyectos en entidades estatales del Reino Unido, la cual es administrada por la Oficina de Comercio Gubernamental del Reino Unido OGC – Office of Government Commerce.

- Guía PMBOK2000 – Project Management Body Of Knowlegde, modelo establecido y mantenido por el Instituto de Gerencia de Proyectos – PMI2, Project Management Institute.

Es importante destacar que la selección de estos estándares no implica la descalificación en importancia y validez de otras soluciones que apoyan la función de Gerencia de Proyectos. Las principales intenciones para limitar el trabajo a estas dos alternativas se justifican en lo siguiente:

- La metodología PRINCE2 hace referencia explícita a la función de aseguramiento del proyecto. Aunque los antecedentes en su aplicación cubren todo tipo de proyectos, un porcentaje significativo de resultados exitosos, abarca los proyectos informáticos.

- La guía PMBOK2000 del PMI es un modelo de amplia difusión y aplicación en el mundo con antecedentes altamente exitosos. Se le cataloga en muchas organizaciones, entre ellas el Banco de la República, como una herramienta base para apoyar la función de gerencia de proyectos y en especial de proyectos de desarrollo de software a la medida.

D.2. Entorno de aplicación de la función de aseguramiento de proyecto Tiene por finalidad conocer la metodología de gerencia de proyectos informáticos adoptada y utilizada por el Banco de la República, así como, identificar los aspectos relacionados con la función de aseguramiento del proyecto que se aplican en dicha organización y/o que se tienen proyectados en el futuro.

2 www.pmi.org, agosto de 2002

4

D.3. Estructuración de la propuesta Modelar una propuesta de la función de Aseguramiento del Proyecto personalizada a los proyectos de desarrollo de software a la medida. Adaptarla a las condiciones y necesidades de la gerencia de proyectos informáticos en el Banco de la República, para evaluar su aplicación en dicho contexto. D.4. Validación y ajustes a la propuesta Con base en los resultados de la tercera etapa, plantear observaciones y recomendaciones orientadas a facilitar la adaptación e implantación de la propuesta de la función de aseguramiento del proyecto en cualquier organización que esté adelantando o decida adelantar un programa de gerencia de proyectos informáticos.

5

II. MARCO TEÓRICO

A. Reseña histórica Antes de aventurar en dar una definición formal del término proyecto, es necesario observar en la historia de la humanidad algunos posibles visos relacionados con su origen y uso, así como, su evolución a lo que hoy día se entiende por gerencia o administración del proyectos – Project Management. Existe una amplia variedad de proyectos que pueden encontrarse en la historia de la humanidad; se argumenta que la torre de Babel o las pirámides de Egipto fueron los primeros proyectos conocidos. También se dice que la construcción del Empire State y la invención del bombillo por Edison fueron proyectos. Sobre la gerencia de proyectos moderna se afirma que comenzó con el proyecto Manhattan [1], que desarrolló la bomba atómica; por esos días la administración de proyectos se utilizaba principalmente para el desarrollo e investigación de proyectos grandes y complejos como fueron el desarrollo del ICBM (misil balístico internacional) y el sistema de armamento militar. Actividades como la construcción de represas, barcos, refinerías y autopistas; así como, la construcción masiva de programas han sido organizadas como proyectos. Las técnicas de administración de proyectos fueron desarrolladas en su gran mayoría a través de casos relacionados con la industria militar, lo cual facultó posteriormente su expansión mundial para la organización de proyectos. Las firmas de construcción privadas encontraron que la organización de proyectos era útil y aplicable en tareas más pequeñas como la construcción de una bodega o un conjunto de apartamentos. Las compañías automotrices comenzaron a usar la organización de proyectos para desarrollar nuevos modelos de automóviles. Hoy día, la gerencia de proyectos ha sido empleada para desarrollar nuevos modelos de zapatos tenis, incluso para enmarcar actividades individuales planeadas como un proyecto de vida. Las campañas publicitarias, los consorcios y las adquisiciones de capital son frecuentemente manejados como proyectos; esto se extiende a sectores no comerciales en actividades como bodas, campañas de elecciones, fiestas, recitales, etc. En Colombia, un ejemplo exitoso en la aplicación de la gerencia de proyectos es el sistema de transporte urbano Transmilenio3. Todo el sistema puede verse como un megaproyecto compuesto de proyectos más pequeños donde el propósito y los objetivos de éstos últimos se orientan a posibilitar y/o alcanzar gradualmente el propósito y objetivos del megaproyecto Transmilenio. La mayoría de los proyectos componentes en Transmilenio se han manejado bajo el esquema de contratación con el estado mediante licitación, de los cuales se destacan los siguientes:

3 Fuente: www.transmilenio.gov.co, agosto de 2002

6

- El proyecto para la operación del subsistema de transporte que se encuentra en manos de los transportadores particulares con alguna participación del estado.

- El proyecto para la construcción del subsistema de estaciones cabeceras e intermedias, de exclusividad del estado donde cada estación es a su vez definida como un proyecto más pequeño.

- Otros proyectos de menor complejidad y envergadura, pero de igual importancia, son: el subsistema de recaudo; el subsistema de servicio de aseo; el subsistema de mantenimiento de estaciones y vías; el subsistema de vigilancia; el subsistema de seguros; el subsistema de señalización, etc.

Esta descomposición del megaproyecto Transmilenio en proyectos componentes más pequeños, ha facilitado su administración y control bajo dos perspectivas: una parcial que permite conocer la evolución de los proyectos componentes de manera individual y otra integral donde se puede conocer el porcentaje de avance todo el megaproyecto. Otros beneficios se reflejan a través de la planeación que ha permitido un menor trauma durante su desarrollo en la ciudad; no es lo mismo construir todas las estaciones de simultáneamente que hacerlo de manera gradual. Aunque la descomposición en pequeños proyectos puede implicar más tiempo; por lo general, los costos, así como, la disponibilidad de maquinaria, de personal y de otros recursos, representan mejores posibilidades y beneficios en relación a la opción de emprender todo en una acción.

B. Definición de proyecto B.1. Términos relacionados con el concepto proyecto Forsberg [11] afirma que la terminología varía de un proyecto a otro. Dicha variación no depende sólo del tipo de proyecto, sino de las múltiples definiciones e interpretaciones que pueden existir de términos relacionados con la gerencia de proyectos. Lo que en un contexto determinado puede ser aplicado como sinónimo, en otro puede tener un significado técnico particular. Una encuesta realizada por el autor en el segundo semestre de 2002 a 19 miembros de ACIS4 arrojó la siguiente información: el 26% de las personas relacionó el concepto proyecto con un plan y lo definió como un conjunto de actividades lógicamente ordenadas; el 57% consideró sinónimos los términos tarea y actividad y el 68% dio igual tratamiento a etapa y fase; el 26% definió etapa como un conjunto de tareas. Vale la pena aclarar que ninguno de los entrevistados asoció proyecto a un conjunto de fases o de etapas, como se percibe en mucha de la literatura relacionada [3]. Con base en lo anterior, se puede argumentar que resulta difícil encontrar una definición de proyecto que sea de aceptación general. En tal sentido, y buscando evitar interpretaciones confusas, se hace una distinción del concepto “proyecto” en relación con otros términos de uso frecuente, mediante el esquema de ordenamiento mostrado en la figura 1. Un programa, megaproyecto o multiproyecto se puede definir como una empresa de gran tamaño y complejidad que, para su desarrollo, requiere ser descompuesta en proyectos de 4 Asociación Colombiana de Ingenieros de Sistemas

7

menor escala o alcance, los cuales están interrelacionados y cuyos objetivos y actividades

8

La metodología PRINCE25 define un proyecto como: “El entorno de administración de unas condiciones establecidas con recursos finitos asignados para adelantar una línea particular de investigación o la generación y entrega de uno o más productos o servicios dentro de un periodo de tiempo limitado.” Según Academic Press Dictionary of Science and Technology

9

proyecto y de cómo su actividad individual o grupal apoya la consecución del producto o servicio final.

- Los productos o servicios de cada proyecto son únicos; es decir, por más que se

semejen las condiciones y objetivos de un proyecto, el desarrollo y resultado siempre serán particulares. Un proceso de una línea de fabricación de autos no puede considerar cada auto como un proyecto, sino como una operación de fabricación de carros; lo que si puede ser considerado un proyecto, es el diseño del modelo del carro para un determinado año, el cual no es el mismo de los años predecesores ni posteriores. Lo que se busca repetir de un proyecto a otro es el éxito, basado en el nivel de satisfacción del beneficiario acerca del producto o del servicio final.

Adicional a las características mencionadas anteriormente, un proyecto debe contener los siguientes elementos [1]: - Un propósito: relacionado con la razón del ser del proyecto; en él se fundamentan los

deseos o intereses de quienes lo patrocinan o de quienes son sus directos beneficiarios. El nivel de incertidumbre que enmarca el inicio de un proyecto con respecto al producto final no puede definirse con exactitud y siempre tiende a ser alto. En tal sentido, el propósito busca atacar y disminuir ese nivel de incertidumbre. Entre mejor se describan el propósito y las características esperadas del producto, menor será la incertidumbre y por ende las posibilidades de resultados inesperados.

- Interdependencias o interrelaciones: pocos proyectos pueden ser concebidos como una actividad aislada, normalmente su desarrollo es afectado por la información y las acciones que se generan desde el contexto donde se ubica. De igual manera, la información y las acciones generadas por el proyecto afectarán su contexto de manera similar. Un proyecto puede ser parte de un proyecto más grande – megaproyecto, y a su vez estar compuesto de pequeños proyectos [2]. En tal sentido, la gerencia de un proyecto implica la administración de los pequeños proyectos o subproyectos que lo conforman y la administración de las formas de interrelación surgidas entre estos últimos, así como, entre el proyecto y el contexto donde se localiza.

- El conflicto: De todo el universo de administradores, los gerentes de proyectos son los que más viven en un mundo influenciado por los conflictos. Los proyectos compiten permanentemente con las unidades organizacionales por recursos, entre ellos, por personal; los miembros del equipo del proyecto están casi siempre luchando por los recursos del proyecto y por los roles de liderazgo en la solución de los problemas del proyecto; el cliente desea cambios y la organización desea utilidades o grandes resultados, los cuales pueden llegar a reducirse con la realización de los cambios; los individuos que trabajan en los proyectos por lo general responden a dos jefes al mismo tiempo, jefes con diferentes prioridades y objetivos. Por lo anterior, la gerencia de proyectos no puede considerarse un lugar para tímidos e introvertidos. Adaptado de Meredith y Mantel [1].

- El ciclo de vida: Un esquema de ciclo de vida de un proyecto puede equipararse con las entidades orgánicas; ambos están compuestos de etapas que van desde un inicio o concepción, pasando por una etapa de evolución o progreso hasta llegar a un

10

determinado tamaño, llamado por algunos pico; posteriormente enfrentan una etapa de decline hasta, finalmente, terminar. En este contexto, declinar no significa que el proyecto esté en problemas, sino que la intensidad o la cantidad de trabajo y esfuerzo asociados con las tareas comienzan a disminuir. Pero, así como los proyectos pueden reflejar comportamientos similares a las entidades orgánicas, también pueden llegar a adoptar otros comportamientos negativos como la resistencia a su terminación. Esta situación es frecuente en proyectos de desarrollo de software a la medida; donde los usuarios finales o clientes buscan, en las pruebas, que el nuevo producto o software funcione en la realidad de manera precisa en todas las situaciones; sin embargo, muchas veces la percepción de ese funcionamiento perfecto no es unificado entre el proveedor y el mismo usuario final o cliente, con lo cual se termina por caer en ciclo de prueba y corrección del que resulta difícil salir, pues siempre habrán cosas por arreglar o ajustar. La evolución de un proyecto, en relación con el tipo de administración que predomina en las diferentes actividades del proyecto, puede verse de la siguiente manera: el inicio es de naturaleza institucional, asociado con la percepción de una idea incipiente donde la continuidad del proyecto depende del impacto que tenga en la alta gerencia un estudio de factibilidad o viabilidad; la fase posterior, donde el desarrollo del proyecto es más visible, es de naturaleza operativa y táctica en relación con la planeación de las actividades y con la forma como éstas se adelantan; el siguiente momento del proyecto involucra una mezcla de la parte institucional, estratégica y táctica cuando se decide si se acepta o rechaza el producto final, así como, en la decisión de cuándo y cómo ponerlo en funcionamiento [2].

B.4. Restricciones básicas de un proyecto

Figura 2. Restricciones de un proyecto [1]

Meredith [1] afirma que el logro de los objetivos de cualquier proyecto está supeditado a tres variables que pueden variar en cualquier momento. La figura 2 permite ubicar el

11

objetivo del proyecto sobre un plano tridimensional donde cada eje representa una restricción. La modificación de cualesquiera de las tres restricciones necesariamente implica modificar el cubo resultante de la integración y por ende del objetivo del proyecto. Vg. un mayor alcance del proyecto puede implicar mayores tiempos y costos; el recorte en los tiempos puede requerir mayores recursos y esfuerzos en el desempeño requerido; finalmente, la liberación anticipada de personal del proyecto incide en el desempeño requerido, los tiempos presupuestados y, por ende, en el objetivo del proyecto.

C. Una clasificación de proyectos No existe una clasificación precisa y explícita de los tipos de proyectos. Algunos autores dejan entrever que los proyectos pueden clasificarse de acuerdo al campo o disciplina donde se desarrolle; en tal sentido pueden existir proyectos de obras civiles, informáticas, financieras, de seguridad, de investigación, de diseño, sociales, personales; esta lista puede continuar sin conocerse un final. Cuevas [6] clasifica dos grandes grupos de proyectos para definir el contexto de los contratos informáticos: por un lado, ubica los contratos relacionados con la adquisición, construcción y mantenimiento de bienes informáticos (hardware); en el segundo grupo localiza los contratos de prestación de servicios informáticos, haciendo distinción entre los contratos de desarrollo, adquisición y mantenimiento de software y los contratos de estudios de diagnóstico y de factibilidad de proyectos informáticos. Extrapolando esta clasificación a los proyectos en general, se podría decir que existen proyectos orientados a la generación de productos y proyectos orientados a la prestación de servicios. Los proyectos orientados a productos se caracterizan por suministrar un bien tangible como la construcción de un puente, la configuración de una red de computadores o la creación de una nueva vacuna. Los proyectos orientados a los servicios se caracterizan por proveer beneficios como los proyectos de consultoría o asesoría. No obstante lo anterior, Cuevas menciona que pueden encontrarse proyectos que producen simultáneamente bienes y servicios, en los cuales se localizarían los relacionados con el diseño y desarrollo de sistemas de información, donde el bien como tal es la plataforma de funcionamiento del sistema (hardware y software) y el servicio es la capacitación e información que apoya el proceso de toma de decisiones de la organización. C.1. Definición de proyectos informáticos Las organizaciones han reconocido con el tiempo, la importancia de administrar adecuadamente sus principales recursos, entre ellos el recurso humano. Recientemente, la información, más aún, el conocimiento, se ha colocado dentro de estos recursos importantes, en especial porque se ha convertido en una herramienta de apoyo para el proceso de toma de decisiones, aspecto éste es fundamental para la supervivencia, éxito o fracaso, de las empresas. Datos estadísticos del Departamento de Comercio de Estados Unidos muestra una tendencia creciente del uso de la información reflejada en la distribución de la fuerza de trabajo en cuatro sectores de la economía, a saber: agricultura, industria, servicios e

12

información. Hacia 1880 la fuerza de trabajo se concentraba en la agricultura e industria, abarcando casi el 80% de toda la fuerza laboral, con una participación del sector información no superior al 10%. Hacia 1940 la participación del sector información había igualado al sector industria con un 37% y recientemente este porcentaje se ha disparado a niveles superiores al 60%. Esto último, debido en gran parte al cúmulo de alternativas que ha incorporado Internet, así como, a la creciente dependencia de las organizaciones por planear y adelantar sus actividades basados en la información. Entonces, la posibilidad que se abre con la información ha dado lugar a nuevos problemas o retos relacionados con su administración, conservación y disponibilidad; lo cual se agudiza cuando se trata de grandes volúmenes de información. La evolución tecnológica en el campo de la informática6 ha facilitado el logro de estos retos, pero ha requerido, para la mayoría de las organizaciones, encontrar soluciones individuales debido a las características de éstas que hacen también de la información un elemento particular, diferente de la información manejada por otras empresas. Con base en lo anterior y teniendo en cuenta las definiciones que, sobre el término proyecto, hacen el PMBOK2000 y PRINCE2, un proyecto informático es considerado: “un conjunto de actividades adelantadas por un equipo de trabajo de una empresa, con el objetivo de suministrar servicios relacionados con la administración y control de la información de acuerdo con unos requerimientos o necesidades específicas de la organización.”

D. Una clasificación de proyectos informáticos

Figura 3. Clasificación de los proyectos informáticos

6Conjunto de conocimientos científicos y técnicas que hacen posible el tratamiento automático de la

información por medio de equipos de cómputo. Diccionario de la Real Academia Española.

13

Apoyado en el planteamiento de Cuevas [6] se propone una clasificación de los proyectos informáticos como se muestra en la figura 3. En los proyectos de servicios informáticos intangibles se localizan los servicios de consultoría como los proyectos de estudios de diagnóstico, evaluaciones y revisiones de código, capacitación, estudios de prefactibilidad y de factibilidad. Por otro lado, los proyectos de servicios informáticos tangibles abarcan la construcción, adecuación, adquisición y arriendo de bienes como computadores, impresoras, centro de procesamiento, así como, de aplicaciones y paquetes de software. Dentro de los proyectos de servicios informáticos tangibles puede realizarse una nueva clasificación según el producto, bien hardware o software (ver figura 3). En ambos casos la consecución de los productos finales puede realizarse mediante la adquisición, compra o arriendo del hardware o software disponible en el mercado; pero también puede hacerse mediante su construcción. En el caso del hardware, este tipo de proyectos es típico de las grandes casas especializadas como Compaq, IBM, Cisco, entre otras. En relación con los proyectos de servicios informáticos de software, es importante aclarar que éstos varían dependiendo de la complejidad y del tamaño de la información a manejar, en cuyo caso se identifican dos tipos de proyectos7: - Los proyectos de servicios informáticos para la adquisición de paquetes de software,

donde el producto seleccionado ha sido concebido previamente como una solución estándar para organizaciones con necesidades de información similares. En este tipo de proyectos se busca adaptar las necesidades de la organización a las condiciones generales del producto.

- Los proyectos de construcción o desarrollo de sistemas de información, donde el producto no ha sido generado y éste debe ser resultado de un diseño previo de acuerdo a las necesidades particulares de la organización. El presente trabajo de investigación se enfoca principalmente en este tipo de proyectos, también conocidos como proyectos de desarrollo de software a la medida.

D.1. Definición de proyectos de desarrollo de software a la medida A pesar de la clasificación realizada sobre los proyectos de software, surge un interrogante: ¿Cómo tratar o clasificar los proyectos en donde se adquiere un paquete de software para adecuar un alto porcentaje de éste a las necesidades de la organización? Aunque en las fuentes consultadas no existe una definición o criterios explícitos acerca de cómo clasificar este tipo de proyectos, algunos datos en las organizaciones permiten entrever que su clasificación depende del grado de modificación o cambio que se realice en el software. Algunas fuentes afirman que el porcentaje límite es del 20%; es decir, un porcentaje superior puede catalogar el proyecto como un desarrollo de software a la medida y uno inferior, puede ser considerado como una adquisición y adecuación de un paquete. Se puede pensar también en términos de las fases o etapas que comprenden el proyecto; en tal sentido, en los proyectos de adquisición de paquetes de software las etapas de diseño y construcción no requieren tiempo ni recursos significativos en comparación con los

7 Fuente: Metodología para la administración de proyectos en ambientes controlados – PRINCE2, www.spoce.com (agosto, 2002).

14

proyectos de desarrollos a la medida, donde se da gran importancia a dichas etapas. Existen otros aspectos adicionales que pueden incidir, como la inmediatez del producto solución o el grado de adaptación de los procesos de la organización a las condiciones del paquete. En el caso de los paquetes de software, hay mayor inmediatez que en los proyectos de desarrollo de software a la medida. En lo que respecta a la adaptación, se percibe la idea de que la organización se ajusta a las ventajas y desventajas de un tipo de paquete; en tanto que en el desarrollo a la medida, aunque existan modificaciones de los procesos de la organización, estos se orientan más a mejorar en el futuro las condiciones de la organización en lugar de adaptarse a una condiciones impuestas [5]. Debe tenerse en cuenta que el software a la medida muy pocas veces coincide con la visión mental que se tiene del software ideal; esto debido a que dentro de la misma organización existen diferentes formas de concebir el software ideal, a que los intereses y experiencias de los involucrados son diferentes y a que es especialmente difícil obtener un conocimiento único y uniforme en el ciento por ciento.

E. Actores en un proyecto de desarrollo de software a la medida Como ya se mencionó, uno de los tres elementos principales para adelantar un proyecto son los recursos, donde se ubica el recurso humano. Kerzner [9] al igual que Meredith y Mantel [1] definen a los stakeholders como personas o grupos de personas que tienen intereses representados en el proyecto y están en capacidad de afectar su desarrollo y resultados. Los stakeholders, dependiendo de sus intereses particulares, actúan o desempeñan diferentes roles. A continuación se relacionan tres de los grupos de personas relevantes en un cualquier proyecto de desarrollo de software: E.1. Grupo cliente Conformado por personas comisionadas por la organización para garantizar la consecución del resultado final y que serán los beneficiarios directos. Por lo general, el grupo cliente se encuentra apoyado por otras áreas de la organización para facilitarle la adopción de estrategias y acciones durante el desarrollo del proyecto; se destacan las siguientes: los entes de control que asesoran en la identificación de potenciales amenazas y en las formas de reducir su impacto; el área de recursos humanos que facilita el personal requerido; el área de recursos físicos; el área jurídica para la estructuración de las responsabilidades mediante un contrato, entre otras. E.2. Grupo de usuarios Integrado por las personas que operarán el producto final. Cuando los beneficiarios directos del producto final se encargan además del manejo de dicho producto, los grupos de usuarios y de clientes son uno solo. E.3. Grupo proveedor Tienen la responsabilidad y capacidad de diseñar y construir el producto final, así como, de capacitar en el manejo del producto a los usuarios y de informar al grupo cliente de los beneficios que se obtienen. En muchas organizaciones, este grupo puede estar conformado por personal técnico especializado de la organización o puede formar parte de una organización diferente especializada en proveer soluciones informáticas.

15

F. Una estructura para un proyecto de desarrollo de software a la medida

La realización de proyectos de desarrollo de software según las necesidades de la organización, hoy día, está soportada por una gran cantidad de metodologías, métodos y marcos de referencia, que buscan garantizar la generación de un producto que maneje la información de manera eficiente, económica, segura y oportuna. La mayoría de estas recomendaciones plantean un conjunto de etapas interconectadas que en forma incremental buscan el logro del objetivo final, en este caso, de una herramienta informática o sistema que facilite el manejo de la información de la empresa.

Figura 4.Ciclo de vida para un proyecto de desarrollo de software a la medida [12]

Aunque las etapas, por lo general, son definidas en forma discreta, en la vida real ninguna de estas se realiza de manera independiente, puesto que cada una está integrada por actividades que posibilitan el logro de los objetivos particulares de la misma y gradualmente, con su alcance, permiten acceder o iniciar actividades de la etapa siguiente [11]. En este sentido, es importante el éxito de las etapas predecesoras, las cuales se constituyen, con el desarrollo del proyecto, en los cimientos para las etapas posteriores y por ende para el producto final. La figura 4 muestra un punto de vista relacionado con las etapas que conforman el desarrollo de un sistema de información a la medida, las cuales se amplían a continuación y se apoyan fundamentalmente en el planteamiento de Kendall y Kendall [12]. F.1. Identificación de problemas, oportunidades y objetivos de la organización Busca que los esfuerzos y recursos invertidos desde el principio y a lo largo del proyecto estén bien orientados y evitar la posibilidad de resolver un problema en forma equivocada o inexistente. En esta etapa, cliente, usuario y proveedor, operan como un solo equipo para facultar al último en el conocimiento acerca de las actividades y del tipo de información que debería cubrir la solución definitiva.

16

Es frecuente identificar problemas en las actividades de esta etapa o en el manejo de la información que requieran ajustarse para facilitar la consecución del producto final. En tal sentido, el proveedor debe conocer el ambiente donde operará el producto final y posteriormente, desde su perspectiva de experto en el suministro de soluciones para el manejo de la información, definir cómo garantizar el logro de los objetivos del cliente aprovechando oportunidades y atacando los problemas identificados. La innovación juega un papel fundamental aquí, pues propuestas o planteamientos, de nuevas formas de realizar estas actividades que aprovechen al máximo la tecnología disponible, pueden propiciar mejores y más eficientes resultados. Las principales actividades que componen esta etapa son: recolección de información por parte del proveedor para conocimiento del funcionamiento general del negocio; estimación del alcance del proyecto y del producto final, es decir, qué se cubrirá y qué no se atenderá; y documentación de los resultados de la etapa. El principal producto resultante de esta etapa es un estudio de factibilidad que contiene la definición del problema, la compilación de los objetivos del proyecto y la estimación de los recursos financieros, de personal y del tiempo requerido. La aprobación del estudio por parte del grupo cliente es la condición para acceder a la segunda etapa de proyecto o en su defecto la culminación en forma anticipada.

F.2. Determinación o definición de los requerimientos de información Es importante que el proveedor sepa interpretar con precisión los deseos y/o necesidades del cliente y además que éste último quede seguro de que sus intenciones fueron bien entendidas por el proveedor. El principal reto del proveedor es esforzarse por comprender qué información necesita el cliente para su proceso de toma de decisiones y demás actividades de apoyo. El proveedor debe conocer, además, el detalle de las funciones actuales del negocio, independiente de si se apoya en un sistema de información o no; es decir, qué actividades se hacen, quién las hace, dónde las hacen, cuándo las hacen y cómo se hacen. Dentro de esto proceso de conocimiento, deben hacerse explícitas las justificaciones de porqué las actividades se realizan de una forma determinada, para evitar supuestos posteriormente se degeneren en riesgos y para plantear mejoras fundamentadas. Al término de esta etapa, el proveedor debe estar en capacidad de entender el porqué de las funciones del negocio y contar con información completa sobre las personas, objetivos, datos y procedimientos involucrados.

F.3. Análisis de las necesidades del nuevo sistema de información Con base en la información recolectada a través de las etapas anteriores, el proveedor

17

Adicionalmente se realiza un análisis de las decisiones estructuradas; es decir, aquellas para las cuales se les puede determinar o definir las condiciones como alternativas de condición, acciones y reglas de acción. El lenguaje estructurado, las tablas de decisión y los árboles de decisión son ejemplo de técnicas que facilitan el análisis de estas decisiones estructuradas. Es importante que el proveedor tenga presente que no todas las decisiones en la organización son estructuradas, pues estaría concibiendo la organización como un ente rígido y poco dinámico. También existen decisiones semiestructuradas, tomadas bajo condiciones de riesgo y que se nutren de sistemas como el de apoyo de decisiones. En el análisis de estas decisiones semiestructuradas se tiene en cuenta el grado de habilidad requerido para la toma de decisiones, el grado de complejidad de las situaciones problema y la cantidad de criterios considerados en la toma de decisiones. El análisis, en últimas, debe extenderse a las decisiones de criterios múltiples, que implican balanceos entre diversos factores, las cuales se apoyan en técnicas como los métodos ponderados [12]. El producto de la etapa es una propuesta elaborada por el proveedor que compendia lo encontrado en ésta y en las etapas anteriores; proporciona un análisis de costo-beneficio de las alternativas del proyecto; y contiene recomendaciones acerca de lo que debería hacerse para hacer realidad el proyecto. Cada situación problema es particular para la organización y es casi imposible que exista una solución única. El éxito de las etapas posteriores se fundamenta en la formulación de la solución o recomendación; una propuesta muy arriesgada puede ser remota para alcanzar y una propuesta muy conservadora puede generar insatisfacción.

F.4. Diseño del sistema de información recomendado En la medida que se avanza entre las etapas hacia el producto final, las necesidades de cambios que se identifiquen y que no se atendieron en las etapas predecesoras se tornan mucho más difíciles y costosas de implementar. El proveedor lidera el diseño lógico del nuevo sistema de información apoyado en la información recolectada y en el conocimiento adquirido; diseña procedimientos para la captura de datos, buscando garantizar la integridad de los mismos; y diseña también formas y pantallas de interacción con el sistema, para lo cual puede apoyarse en el esquema de prototipos. La fase también incluye el diseño de archivos o de las bases de datos que almacenarán los datos necesarios para apoyar el proceso de toma de decisiones; así como, el diseño de las salidas de información que satisfagan las necesidades de la organización. Los productos finales se apoyan en un proceso de negociación entre el cliente y el usuario. Nuevamente el reto es la comunicación efectiva de las partes para transmitir y entender los significados. El grupo conformado entre el cliente, el usuario y el proveedor debe, por último, diseñar los procedimientos de control y respaldo para proteger el sistema y los datos en él contenidos. Para ello producirá paquetes de especificaciones de programa que contengan diseños de entrada y salida, especificaciones de los archivos, detalles del procesamiento de datos, árboles o tablas de decisión, diagramas de flujo de datos y de flujo del sistema, entre otros.

18

F.5. Desarrollo y documentación del software Tradicionalmente en esta etapa la interacción entre proveedor, cliente y usuario se reduce de forma significativa; sin embargo, los antecedentes han demostrado la necesidad de lo contrario, de una permanente participación para evitar productos mal enfocados, generados como consecuencias de supuestos y malentendidos. Se busca obtener una primera versión del producto con una documentación base del mismo, incluyendo manuales de procedimientos que indiquen al usuario la manera de utilizar el producto final y las acciones a seguir en caso de problemas. Por lo general las funciones de diseño y de desarrollo se segregan en dos subgrupos diferentes y especializados; un subgrupo de diseño que comunica a un grupo de desarrollo la idea del producto que se desea construir, por medio de técnicas estructuradas como los diagramas de flujo o el seudocódigo.

F.6. Pruebas de aceptación del software Es conducida principalmente por un subgrupo de pruebas conformado por integrantes del grupo cliente y del grupo usuario. Se busca determinar el grado de confiabilidad que brinda la versión en prueba para operarla después en producción o en la vida real de la organización. Las pruebas buscan determinar el correcto funcionamiento del sistema tanto en condiciones normales como en condiciones de excepción; así como, establecer si se incorporaron adecuadamente todos los requerimientos de información planteados en las etapas precedentes. La culminación exitosa de esta etapa constituye en gran parte la aceptación a satisfacción del cliente y del usuario, con base en el diagnóstico o concepto generado por el subgrupo de pruebas.

F.7. Implantación del sistema Comprende un plan detallado de la forma como el nuevo producto entrará en operación, por ejemplo: si la entrada será incremental o por partes, si se realizará un piloto o cubrirá a toda la organización en un mismo instante, si se migrará la información existente en otros sistemas o habrá digitación directa, cómo se realizará la capacitación a los grupos usuario y cliente, qué acciones alternas o de contingencia deben adoptarse en el caso que se presenten fallas no identificadas previamente durante la entrada en operación del nuevo sistema. La etapa exige de un trabajo coordinado entre los tres grupos para preparar a la organización para que la entrada en operación del nuevo producto sea lo menos traumática posible. De acuerdo con la complejidad del proyecto, es posible que en la implantación del sistema se identifiquen situaciones o requerimientos que no se tuvieron en cuenta en las etapas anteriores; en tal sentido, el grupo cliente deberá acordar con el grupo proveedor la alternativa de solución, la cual puede variar desde no hacer modificaciones hasta implementar el requerimiento en el sistema en una versión posterior. F.8. Mantenimiento del sistema en operación Una de las limitaciones del hombre es su incapacidad para manejar en forma simultánea toda la información de una situación compleja; de ahí, la necesidad de apoyarse en los sistemas de información; y por ende la posibilidad de que todo sistema en su entrada pueda

19

ya tener incorporado necesidades de ajustes que no fueron identificados durante las etapas previas del proyecto [12]. Además, la dinámica del entorno donde se desenvuelven las organizaciones obliga a permanentes cambios o ajustes de los requerimientos iniciales de información. Lo anterior refleja las principales causales o justificaciones de esta etapa de mantenimiento que junto con la etapa de implantación se constituyen, después de la entrada en operación de la primera versión del sistema, en las etapas donde más permanece el sistema durante el tiempo de vida.

20

III. GERENCIA DE PROYECTOS

A. Antecedentes El concepto de gerencia o administración de proyectos es relativamente nuevo, su desarrollo se ha producido principalmente en los últimos quince años [7]. En los sesentas, el éxito en la realización de un proyecto dependía del nivel de calidad incorporado en el documento del estudio de factibilidad técnica, económica y financiera. A esto se sumaba el nivel de interacción e integración que debía existir entre el equipo coordinador y los especialistas de las distintas disciplinas involucradas en el proyecto. Los aspectos operativos de tipo técnico eran considerados los más relevantes del proyecto; mientras que los aspectos administrativos se relegaban a un plano de menor importancia, por lo cual era normal que se asignaran bajo el supuesto de que cualquier persona podía hacerlo. Hoy día, estos dos componentes, uno técnico y otro administrativo, revisten la misma importancia para el éxito del proyecto. R. Max Wideman, miembro del PMI, en su ensayo “Principios básicos de la gerencia de proyectos” – First Principles of Project Management, hace referencia de ellos cuando aplica la gerencia de proyectos; por un lado está la gerencia o administración del componente técnico del proyecto, cuya orientación es el manejo de la parte tecnológica del mismo; y por el otro lado está la gerencia o administración del proyecto que busca manejar los esfuerzos invertidos en el proyecto a través de su ciclo de vida. El éxito de los proyectos depende de la completa y adecuada integración que se logre entre estos dos componentes; lo cual, necesariamente es particular y/o diferente para cada proyecto. Se afirma que la gerencia de proyectos [1] surgió como respuesta a un número de fuerzas en la sociedad que requerían nuevos métodos de administración. De estas fuerzas involucradas han predominado las siguientes:

- La creciente demanda de nuevos productos y servicios caracterizados por ser cada vez más complejos, sofisticados y personalizados.

- La expansión del conocimiento ha facilitado que cada vez más disciplinas académicas contribuyan al desarrollo de nuevos servicios y productos. Esto ha demandado mayor coordinación y cooperación entre grupos de personas acostumbradas a la producción en masa de cosas simples sobre estructuras tradicionales de organizaciones y de sistemas de administración no adecuados para estas nuevas formas de adelantar las tareas.

- La intensa competencia entre instituciones, originada en gran parte por la naturaleza de los sistemas económicos, ha presionado a las organizaciones para generar resultados complejos y personalizados en el menor tiempo posible y con cantidades limitadas de recursos. La encrucijada que se vislumbra muestra que la información y el conocimiento está creciendo de manera explosiva; sin embargo, el tiempo disponible para hacer uso adecuado de dicho conocimiento está decreciendo en un ritmo similar.

Existen antecedentes [1] de organizaciones que al aplicar la gerencia de proyectos experimentan un mejor control o dominio de su contexto, tales como mejoras en las relaciones con sus clientes, que por lo general ayudan a incrementar el retorno del proyecto respecto de la inversión realizada. Una proporción significativa de usuarios reportan

21

tiempos de desarrollo más cortos, costos más bajos, mayor calidad y confiabilidad con altos márgenes de utilidad. Otras ventajas incluyen una clara orientación hacia los resultados; una mejor coordinación entre dependencias, es decir, un equilibrio entre cohesión y autonomía; y una alta moral o motivación entre los participantes. Sin embargo, no todo es color de rosa, pues los antecedentes también permiten vislumbrar algunos aspectos negativos. Muchas organizaciones reportan que la gerencia de proyectos solo es eficiente y aplicable en organizaciones grandes y complejas. También se dice que la organización del proyecto incrementa la posibilidad de que las políticas organizacionales se violen; en parte, justificado en el nivel de autonomía que se asigna a la gerencia de proyectos. La creación de un proyecto puede ser tomada como una forma de escapatoria para el grupo gerencial o directivo cuando se busca disimular a través de éste, su incapacidad para alcanzar los resultados u objetivos en el desempeño funcional de la organización. El conflicto parece ser un efecto secundario, inherente al desarrollo del proyecto. Pero, volviendo a las fuerzas que inciden en la sociedad y que posibilitaron el desarrollo de la gerencia de proyectos, se ha generado el supuesto que la tecnología puede hacerlo todo. Sin embargo, la fuente del problema no radica tanto en este supuesto; sino más bien, en el supuesto concurrente en el cual la sociedad ignora los costos, de cualquier tipo, asociados con el progreso tecnológico hasta cuando algún evento dramático los obliga a poner su atención en ellos – adaptado de Meredit [1]. Al respecto, existen variados ejemplos: - El desastre del Titanic muestra como se desconoció el costo de salvar vidas humanas

frente a la posibilidad de su hundimiento; lo que condujo a utilizar un reducido número de botes salvavidas, menor al establecido por las normas o estándares y que se constituyó en una de las causas para el alto número de muertos por hipotermia y ahogamiento.

- Un caso más reciente es el de Argentina, que con su plan de gobierno terminó en crisis y en altos índices de pobreza. De esta forma se refleja que la capacidad del gasto está limitada en función de los saldos o depósitos más los ingresos, lo cual al parecer no fue tenido en cuenta.

- En Colombia se puede mencionar el caso del proyecto de la termoeléctrica del Guavio. Independiente del aspecto de corrupción por el cual es más conocido, gran parte del no cumplimiento de las expectativas se centró en la gran cantidad de interesados (diferentes sectores del gobierno y de empresas privadas nacionales e internacionales), así como, en el manejo de un mega proyecto sin la posibilidad de descomponerlo en proyectos más pequeños de alcance gradual [13], que posibilitaran un mejor control y manejo.

Los anteriores pro y contra sustentan la necesidad de delimitar la función de gerencia de proyectos, o más precisamente, de complementarla para brindar, a quienes la emplean, herramientas adecuadas que posibiliten los resultados esperados y una mejor percepción de los beneficios de su aplicación. En tal sentido, la función de aseguramiento de proyecto, objetivo de este trabajo de investigación, busca apoyar o aportar para construir este camino para estructurar mejor la función de gerencia de proyectos.

22

B. Definición de Gerencia de Proyectos La definición de gerencia de proyectos encierra diversas percepciones y significados, unas acertadas, otras no tanto. De manera similar a como ocurre con el fenómeno donde las personas, sin ser profesionales médicos, recetan fórmulas o medicamentos apoyados en experiencias pasadas, se presentan aspectos donde participantes o espectadores de proyectos definen de manera poca acertada o confusa la gerencia de proyectos. Kerzner [9] plantea de forma casi jocosa la siguiente definición de gerencia de proyectos basado en el anterior supuesto: “Es el arte de crear la ilusión de que cualquier producto o salida es el resultado de una serie actos predeterminados y deliberados, cuando de hecho, fue producto de una suerte loca o de la mera causalidad.” En una definición más formal, Kerzner describe la gerencia de proyectos como la planeación, organización, dirección y control de los recursos de la organización por un tiempo relativamente corto cuya finalidad ha sido establecida para la realización o terminación de unas metas u objetivos específicos. Aunque Kerzner no define con mayor detalle el concepto “relativamente corto”, es importante aclarar que éste puede tomar diferentes proporciones dependiendo de la perspectiva desde donde se le mire, pues para algunos, un proyecto que dure cinco años puede no ser relativamente corto. En el contexto de los proyectos de software, Kirsch [14] plantea la siguiente definición de gerencia de proyectos: “Consiste en la aplicación formal e informal de técnicas, herramientas, métodos y heurísticas, llamadas colectivamente prácticas de gerencia de proyectos, las cuales son usadas para motivar y guiar a los integrantes de un equipo de un proyecto para adelantar un proyecto de software dentro de un conjunto de restricciones.” De acuerdo con lo anterior se puede concluir lo siguiente: la gerencia de proyectos se apoya, para su aplicación, en estándares y herramientas que, aunque pueden ser comunes, requieren ser personalizadas dependiendo del campo o disciplina que predomine para el desarrollo o generación del producto final. Por ejemplo, la gerencia de un proyecto de obra civil y la gerencia un proyecto de desarrollo de software a la medida pueden emplear la misma herramienta y procedimientos para el proceso de administración de la calidad; sin embargo, es necesario una personalización según el campo o disciplina para tratar de obtener los mejores resultados y desempeño. Basado en el planteamiento de Kerzner, los proyectos en general cumplen condiciones comunes como son: tener objetivos, fechas de inicio y terminación, recursos y el empleo de diferentes líneas funcionales de la organización. La gerencia de proyectos, además de contener los anteriores aspectos, contempla la planeación de elementos del proyecto – requerimientos, calidad, actividades y recursos – y el monitoreo a la evolución, gestión realizada y manejo de los cambios. Finalmente la gerencia de proyectos exitosa contiene las dos anteriores y condiciona el realizar el proyecto dentro de los tiempos estimados, con los costos presupuestados y atendiendo en alto porcentaje las expectativas de los principales interesados. La figura 5, resume esta nueva forma de ver los proyectos y su administración.

23

Figura 5. Gerencia de Proyectos Exitosos. Adaptado de Kerzner [9]

C. Razones para la Gerencia de Proyectos

El propósito básico para iniciar un proyecto es el alcance o cumplimiento de unas metas. La razón de organizar tareas en un proyecto es enfocar la responsabilidad y la autoridad para la consecución de las metas sobre un individuo o un grupo; es decir, las metas grandes se dividen en metas pequeñas que aportan a las metas grandes y que son asignadas a grupos pequeños o individuos. Es necesario observar la gerencia de proyectos desde la perspectiva de la administración y no sólo desde enfoques matemáticos o de ingeniería; pues, se corre el riesgo de ignorar problemas relacionados con la selección e inicio del proyecto, con su operación y control, y con los retos que enfrentan los grupos participantes en el desarrollo del proyecto y la interacción con el resto de la organización – adaptado de King y Cleland [2]. La administración en general trata aspectos relacionados con el funcionamiento adecuado de las organizaciones. Equiparando la vida del proyecto a la de una organización se encuentran aspectos claves de la administración que aplican adecuadamente sobre el manejo de proyectos, a saber: - Todo proyecto requiere un manejo financiero y contable para conocer y controlar su

estado en relación con los recursos financieros. - Desde el punto de vista de investigación y desarrollo el proyecto es fuente de

generación de nuevas y mejores formas de realizar las actividades. - El producto o servicio final del proyecto obedece siempre a un proceso o conjunto de

actividades que una vez culminadas deben garantizar a la población destino el acceso al producto o servicio.

24

- Debido a la misma complejidad del proyecto, éste requiere de una planeación detallada de cada una de las etapas que lo componen. Dicha planeación debe cubrir aspectos estratégicos, tácticos y operativos.

- La conformación de una estructura organizacional posibilita la adecuada coordinación y control de las diferentes actividades realizadas en el proyecto entre los individuos o grupos involucrados, posibilitando un esquema de comportamiento, de manejo del propio recurso humano y de asignación clara de responsabilidades y derechos.

- El factor humano de la administración facilita el manejo de los anteriores aspectos; por ello, es necesario manejar adecuadamente las relaciones entre los diferentes actores involucrados en el proyecto a través de aspectos como motivación, delegación, supervisión, manejo de conflictos y situaciones estresantes fomentando el diálogo y el trabajo en equipo.

D. Elementos básicos en la Gerencia de Proyectos

Figura 6. Elementos principales de la gerencia de proyectos Existen tres elementos principales que son comunes en la estructura de cualquier estándar de gerencia de proyectos. - Los recursos: apoyan o son el resultado de la ejecución de las actividades que

componen el proyecto. Existen dos clases de recursos: los insumos y los productos.

Los insumos son requisitos para ejecutar actividades del proyecto, hacen parte de estos el recurso humano y los recursos físicos. Los últimos apoyan al recurso humano para adelantar actividades. Vg. equipo de cómputo, aplicaciones, herramientas de software, locaciones, recursos financieros, tiempo, etc.

25

Los productos se caracterizan por ser salidas o resultados de las actividades realizadas del proyecto. Existen productos intermedios; apoyan otras actividades del proyecto como por ejemplo: reportes de gestión, documento de requerimientos, cronograma de actividades, prototipos, entre otros. También existe el producto final; es el resultado de la gestión del proyecto y mediante el que se valida el nivel de cumplimiento de los objetivos del proyecto y de las expectativas de los principales interesados.

- Los proyectos están compuestos de actividades que se organizan y agrupan de acuerdo a unos criterios definidos. A esto recurren los estándares de gerencia de proyectos para organizar y agrupar sus tareas en etapas o fases, o en grupos de procesos compuestos por procedimientos y finalmente por aspectos más granulados como paquetes de trabajo, actividades o tareas. Esto facilita el manejo de la complejidad del proyecto y el control al desarrollo de sus actividades, lo cual se traduce en mayor certidumbre con respecto a su avance y expectativas sobre los resultados finales.

- La base teórica o de conocimiento en un proyecto permite articular la interacción entre

los recursos y las actividades. En algunos estándares de gerencia de proyectos se denominan componentes [8], en otros, áreas de conocimiento [3] o campos de investigación. Su objetivo es permitir el conocimiento y uso de herramientas que faciliten el desarrollo de las actividades y la aplicación de los recursos disponibles.

E. La Gerencia de Proyectos según el PMI

El PMI es una asociación de profesionales, fundada en 1969, con el fin de impulsar la evolución del estado de arte de la gerencia de proyectos en general. En 1996 generó la guía Project Management Body of knowledge – PMBOK, que recopiló estándares y herramientas generadas hasta ese momento por miembros del PMI y profesionales en gerencia de proyectos. En el año 2000 liberó una versión ajustada, PMBOK2000. Definido por American National Standards Institute – ANSI como un estándar americano, es considerado un documento de referencia para profesionales en el campo de la gerencia de proyectos.

El propósito de la guía es recopilar prácticas generalmente aceptadas relacionadas con la gerencia de proyectos, donde generalmente aceptadas significa, que se aplican en la mayoría de proyectos; la mayor parte del tiempo de duración de un proyecto; y hay consenso de la comunidad en general, acerca de su utilidad. Generalmente aceptadas no implica utilizarlas de manera uniforme o única en cualquier organización [3]; en tal sentido, la guía encierra la necesidad de conocer previamente la organización donde se aplicarán estas prácticas, de tener claro los objetivos y beneficios de aplicarlas, así como, ajustarlas según las necesidades y restricciones de la organización. Además, mediante la guía se busca suministrar una terminología estándar que facilite la adecuada interpretación, adaptación y aplicación de las prácticas para generar un lenguaje común entre los profesionales de gerencia de proyectos, equivalente al léxico que se emplea en el derecho, la informática o la medicina.

26

PMBOK2000 es una guía orientada a procesos, donde el concepto proceso es definido como una serie o conjunto de acciones que permiten alcanzar un resultado definido explícita o implícitamente en el proceso en si. Según el PMI, la gerencia de proyectos es una actividad compleja con múltiples dimensiones que suministra a las organizaciones herramientas para facilitar la planeación, organización, implementación y control de las actividades de un proyecto, así como, el uso eficiente y adecuado de los recursos, incluido el recurso humano. La gerencia de proyectos busca aplicar conocimiento, habilidades, herramientas y técnicas para que las actividades de un proyecto alcancen o cumplan los requerimientos del mismo. Para el logro de estas metas, el PMI, define treinta y nueve procesos, los cuales están ordenados en cinco grupos de procesos, dependiendo de su naturaleza, a saber: inicio, planeación, ejecución, control y cierre [3]. El desarrollo de los proyectos no es uniforme ni está exento de dificultades o variaciones imprevistas; por ello, es necesario determinar los cambios que enfrenta y adaptarlos de la mejor forma. En tal sentido, la guía define nueve áreas de conocimiento o gerencias locales que, en forma integrada, constituyen la gerencia de proyectos; ellas son: Gerencia de Alcance, Gerencia del Tiempo, Gerencia de Costos, Gerencia de Calidad, Gerencia de Recurso Humano, Gerencia de Comunicaciones; Gerencia de Riesgos; Gerencia de Adquisiciones y Gerencia de Integración. Cualquier evento o situación presentada en una de las nueve gerencias, afecta necesariamente al resto. La Tabla 1 muestra cómo se distribuyen las gerencias locales en los cinco grupos de procesos y qué áreas de conocimiento apoyan cada uno. Es importante aclarar que un proceso pertenece a un solo grupo de procesos y apoya una sola área de conocimiento. Los siguientes ejemplos relacionan algunos grupos de procesos con áreas de conocimiento, según la Tabla 1: - Planear Recursos, Estimar Costos y Presupuestar Costos hacen parte del grupo de

procesos de Planeación cuyo fin principal es apoyar a la Gerencia de Costos del proyecto;

- El proceso de Asegurar la Calidad pertenece al grupo de Ejecución y es un proceso principal de la Gerencia de la Calidad; Controlar y Monitorear el riesgo pertenece al grupo de procesos de Control e interactúa con la Gerencia de Riesgos;

- El proceso de Realizar el Cierre Administrativo, del grupo Cierre, se relaciona con la Gerencia de Comunicaciones.

Los treinta y nueve procesos se orientan a la consecución de los objetivos del proyecto [3]; en tal sentido, la guía los distingue de los procesos orientados a la consecución del producto. Estos últimos, dependen de la naturaleza del producto y del ciclo de vida del proyecto para alcanzar el producto final y el alcance de la guía nos los cubre. Retomando los procesos orientados al proyecto, por cada área de conocimiento se distinguen procesos centrales o core y procesos de apoyo o facilitating. Los primeros están

27

ordenados según una secuencia lógica para alcanzar un resultado determinado; los segundos, ayudan en la coordinación y ejecución de los procesos centrales y no necesariamente deben seguir una secuencia para su ejecución. Cada uno de los treinta y nueve procesos tiene definidas condiciones mínimas de iniciación o entradas, que se apoyan en herramientas para facilitar su ejecución y como resultado generan salidas que son entradas de otros procesos. Vg. Una de las salidas del proceso de Definición del Alcance es el Documento de Descomposición de Trabajo, el cual es una entrada para los procesos de Definición de Actividades y de Planeación de Recursos que pertenecen al Grupo de Procesos de Planeación. Dentro de éste último grupo, las salidas que genera el proceso de Desarrollo del Plan del Proyecto se constituyen en entradas para los procesos del Grupo de Procesos Ejecución.

Tabla 1: Estructuración de la Gerencia de Proyectos en el PMBOOK2000

28

F. La Gerencia de Proyectos según PRINCE2 PRINCE2 es una metodología de gerencia de proyectos basada en procesos, propietaria y mantenida por Office Governmental Comerse – OGC [8]. Resume las mejores prácticas y experiencias de diferentes sectores de la industria en el Reino Unido. Está definida como un estándar de facto por National Health Services – NHS y es un requisito de contratación para las entidades públicas del Reino Unido. Fue conocida hasta 1998 como PRINCE, cuando se generó una nueva versión. Se alimenta de las contribuciones de profesionales certificados y de la experiencia de su aplicación en organizaciones que la han adoptado. Su enfoque inicial fue los proyectos de tecnología de información, pero los buenos resultados han permitido aplicarla en otro tipo de proyectos. Es considerada una metodología con fuerte énfasis en el control del proyecto. La metodología hace énfasis en los siguientes cuatro aspectos para adelantar un proyecto con éxito:

- Si un proyecto es controlable, mayor es su probabilidad de éxito. Entre más grande sea algo, más difícil es de controlar; por esta razón propone descomponer los proyectos en etapas menos complejas y más fáciles de manejar. Esencialmente descompone un proyecto grande en trozos de tamaño fáciles de digerir o trabajar.

- La calidad incrementa las probabilidades de alcanzar los objetivos del proyecto y en consecuencia, los productos generados satisfacen en mayor proporción las expectativas de los stakeholders. Para asegurar esto, los productos o servicios generados por el proyecto deben ser definidos y acordados en el momento de la planeación del proyecto. En un proyecto PRINCE2, el trabajo se monitorea continuamente para asegurar que los estándares de calidad se cumplan.

- La planeación no termina una vez el proyecto ha comenzado. Una de las razones para descomponer los proyectos en etapas más pequeñas, es que dichas etapas son mucho más fáciles de manejar y por lo tanto deben ser planeadas y sincronizadas con el plan general del proyecto. De los ocho procesos, todos involucran la planeación; incluso el proceso final de cierre del proyecto requiere la planeación de la revisión pos-proyecto.

- Con cada proyecto ejecutado siempre hay posibilidad de aprender algo nuevo; casi siempre se presentan errores, pero lo más importante es no repetir esos errores. Cuando los proyectos en las organizaciones fallan o contienen errores, están las organizaciones aprendiendo de ello? En tal sentido, hace énfasis en generar y documentar las lecciones aprendidas en cada proyecto para brindar herramientas y disminuir la probabilidad de fracaso en futuros proyectos.

Existen cuatros aspectos principales sobre los cuales se estructura la metodología, a saber: - Ocho procesos que suministran una plataforma para manejar el proyecto; - Ocho componentes que son utilizados por los procesos para la consecución de productos

intermedios y finales;

29

- Tres técnicas que apoyan los procesos, a saber: la planeación basada en productos, las revisiones periódicas de calidad y el control de cambios; y

- Un conjunto de definiciones que son base para el control del proyecto e incluyen la descripción del producto final.

Los procesos se encuentran interrelacionados y están definidos de acuerdo con unas entradas y salidas mínimas, así como, con unos objetivos específicos y unas actividades a realizar para cada uno [15], ver Figura 7. Cinco de los ocho procesos son estrictamente secuenciales y constituyen la columna vertebral sobre la que se mueve un proyecto. Ellos son: Arrancar el proyecto (Starting Up), Iniciar el proyecto (Initiating), Controlar Etapa, Manejar Límites de Etapa y Cerrar el Proyecto. Unido a los anteriores procesos se aplican los procesos de Dirigir y Planear el Proyecto. El primero apoya los procesos de Iniciar el Proyecto y de Controlar Etapa; para ello se nutre de la información que le suministran los cinco procesos que conforman la columna vertebral de la metodología. Este proceso, a su vez, debe apoyar y estar alineado con el programa corporativo de proyectos o planeación estratégica de la organización. El proceso de Planear se desarrolla a lo largo de todo el ciclo de vida del proyecto y apoya especialmente los procesos de Arrancar el proyecto, Iniciar el proyecto y de Manejar Límites de Etapa. El último proceso es Manejar Entregables (productos intermedios y finales), el cual interactúa permanentemente con el proceso de Controlar Etapa para garantizar el cumplimiento de los requisitos y de las expectativas por cada producto intermedio o final generado.

30

Figura 7: Modelo de interacción de procesos de PRINCE2 [15] El mandato del proyecto no es un proceso, pero es el equivalente a lo que se conoce en el PMI como la carta de constitución del proyecto. Es insumo para el proceso de Starting Up y contiene, además de las condiciones generales de operación de proyecto, la aprobación manifiesta de los principales interesados en el mismo – Stakeholders. Los componentes de PRINCE2 facilitan y orientan la ejecución de los procesos. La figura 8 muestra la interacción de los componentes con los procesos en la metodología. El componente Business Case, traducido por el autor como Caso de Negocio, se interpreta como la justificación detallada de las razones que tiene la organización para realizar el proyecto y que apoyan las decisiones tomadas en el desarrollo del mismo. El componente Organización del Proyecto sugiere una estructura organizacional mínima compuesta de tres niveles para garantizar el desarrollo exitoso del proyecto. A estos niveles les define, en forma detallada, los roles y responsabilidades principales. El nivel superior lo conforma el grupo directivo del proyecto que representa a los stakeholders y tiene conocimiento del plan de gerencia corporativa. El nivel intermedio está compuesto por un equipo de gerencia del proyecto con dos roles principales: uno técnico y otro administrativo. El nivel más bajo es el equipo de trabajo, compuesto por un grupo de usuarios del proyecto y un grupo proveedores que generan los entregables finales. El componente de Planeación cubre todos los tipos de planes que deben generarse para el desarrollo del proyecto como: planes de productos, de actividades, de recursos, de costos, etc. En PRINCE2, la planeación de un proyecto está basada en los productos intermedios y finales. Los planes se enfocan más a los resultados que a la organización, el presupuesto y secuenciación de actividades; de allí, su fuerte enfoque hacia el control [15].

Figura 8: Interacción de componentes y de procesos en PRINCE2 [15]

31

El componente de Controles del Proyecto reúne todos los controles requeridos para que la gerencia corporativa y los stakeholders tengan información íntegra y oportuna que apoye la toma de decisiones. El componente de Control de Cambios busca, mediante un procedimiento definido, identificar, evaluar y tratar el impacto de cualquier cambio que enfrente el proyecto durante su desarrollo. Tiene un estrecho vínculo con el componente de Administración del Riesgo, pues le brinda información para valorar e identificar las potenciales amenazas que puedan afectar negativamente al proyecto, así como, para determinar las acciones de control que protejan al proyecto de estas. “Un riesgo es un evento que si ocurre, tendrá un efecto positivo o negativo sobre el proyecto” [15]; en tal sentido, la metodología suministra un número de pasos para posibilitar la identificación, medición y tratamiento de riesgos, los cuales hacen parte del componente de Gerencia del Riesgo. El componente de Administración de la Configuración, busca identificar y hacer seguimiento a la evolución de las actividades del proyecto que apoyan la generación de los productos esperados. En relación con esto, en el componente se controlan cambios a las condiciones del proyecto como: recursos asignados, tiempos y costos estimados o características de los productos requeridos, entre otros. El último componente es Administración de la Calidad; se apoya en la definición del estándar ISO 8402 (ISO 9000-2000) y busca asegurar que las expectativas de calidad de los stakeholders y de los usuarios sean cumplidas. En la metodología, la gerencia de calidad de un proyecto incluye los siguientes aspectos: - Planeación de la calidad: los diferentes planes generados en el proyecto deben tener en

cuenta los requerimientos de recursos y de actividades relacionadas con la administración de la calidad.

- Aseguramiento de la calidad: propende por que se documenten los procedimientos y sistemas, y que a su vez sean atendidos o cumplidos.

- Control de Calidad: la calidad deber ser revisada formalmente en los paquetes de trabajo y/o productos para asegurar que los criterios de calidad se estén cumpliendo.

G. Definición de la función de aseguramiento del proyecto

En el campo de la gerencia de proyectos, el término “Aseguramiento” es más conocido cuando se relaciona con el concepto de calidad. La norma técnica NTC-ISO 9000-2000 define el aseguramiento de la calidad como un elemento de la gestión de la calidad cuya finalidad principal es proporcionar confianza en que se cumplirán los requisitos de la calidad del producto y del proyecto. Pero, el aseguramiento ha tenido, también, aplicación en otras disciplinas. El TCSEC – The Trusted Computer System Evaluation Criteria8, instituto que emite políticas y estándares de 8 www.radium.ncsc.mil/tpep/process/faq-sect4.html, octubre de 2003

32

seguridad para equipos de cómputo, lo aplica y define como una evaluación que provee una medida de confianza acerca de si las características de seguridad y arquitectura de un sistema de cómputo interpretan y aplican exactamente las políticas y estándares definidos por el ente. El Instituto de Auditores Internos del Reino Unido e Irlanda9 lo define como una actividad de evaluación que se hace a los reportes, sistemas, procesos y competencias de quienes suministran información de desempeño de una organización con respecto a unos principios y estándares definidos como prácticas ampliamente aceptadas. Dicha evaluación busca suministrar confianza a los principales interesados de la organización acerca de la totalidad, exactitud, relevancia y balance de la gestión realizada por la organización. Es importante aclarar que la certificación que emite la auditoria externa sobre los estados financieros de una organización, involucra aspectos del concepto de aseguramiento, pero no los cubre en su totalidad. En la literatura consultada sobre gerencia de proyectos, sólo la metodología PRINCE2 hace referencia explícita al aseguramiento del proyecto. En tal sentido lo define como el conjunto de actividades que apoyan los programas de gerencia de proyectos, tendientes a asegurar el desarrollo exitoso de las actividades de un proyecto. Su principal objetivo es brindar, de manera independiente, certidumbre y confianza al grupo directivo del proyecto y a los demás interesados “stakeholders” acerca del estado real del proyecto [8]. Con base en lo anterior, se puede concluir que el aseguramiento contempla cuatro elementos principales, a saber: Es una evaluación que se hace a la gestión de algo, en este caso a la gestión de un proyecto, con el fin de emitir un parte de confianza o certidumbre a los stakeholders relevantes para apoyar su proceso de toma de decisiones. Vale la pena aclarar que el aseguramiento del proyecto como función, no solo involucra actividades de evaluación, sino, asesorías y acompañamientos permanentes durante el desarrollo del proyecto para tener un alto nivel de certidumbre acerca del real estado del mismo.

9 www.iia.org.uk/knowlegdecentre/keyissues, octubre de 2003

33

IV. ANÁLISIS Y DIAGNÓSTICO DEL PROBLEMA

A. Aspectos de la Gerencia de Proyectos en Colombia Poca literatura puede encontrarse y poco se puede decir acerca del inicio y evolución de la gerencia de proyectos en Colombia. La Asociación Colombiana de Ingenieros de Sistemas – ACIS coordinó y adelantó, durante el año 2003, la realización de la primera jornada de gerencia de proyectos en la que pudo observarse un auge en organizaciones que funcionan en el país para adoptar y aplicar estándares internaciones que apoyen la gerencia de proyectos. Se destaca la guía PMBOK2000 del PMI que cuenta con un capítulo en Bogotá10 cuyo principal objetivo es promover los principios y mejores prácticas de la gerencia de proyectos del PMI. En un porcentaje menor están el Modelo de Capacidad de Madurez – Capability Maturity Model – CMM y la Metodología de Proyectos en Ambientes Controlados – PRoject IN Controlled Environments – PRINCE2. Esta primera jornada de gerencia de proyectos se puede interpretar como una respuesta a la necesidad sentida de incrementar la probabilidad de éxito en los diferentes tipos de proyectos que adelantan las empresas en Colombia; es decir, a realizar proyectos dentro del desempeño exigido, donde se cumplan los tiempos estimados, los costos presupuestados y los objetivos planteados; esto último, evidenciado en un alto grado de satisfacción de las expectativas de los stakeholders. En la práctica se identifican resultados significativos asociados con una adecuada aplicación de la gerencia de proyectos. Ejemplos de ello son: el megaproyecto Transmilenio, la certificación en nivel 5 de CMM de una empresa colombiana desarrolladora de software o la naciente empresa Alianza Colombiana de Software –ASCOLSA, que busca competir nacional e internacionalmente en el campo de desarrollo de software. Todos los anteriores son ejemplos de los avances que involucran la gerencia de proyectos en Colombia. Pero, a pesar de las acciones emprendidas y de los éxitos alcanzados, es claro que la gerencia de proyectos es una disciplina en formación en el mundo y que las organizaciones en Colombia no son ajenas a los beneficios y problemas que traen consigo este proceso de formación de la gerencia de proyectos. En tal sentido, aportes como el modelo planteado en el presente trabajo de investigación buscan colaborar en la evolución de la gerencia de proyectos y proponer una herramienta de apoyo a las organizaciones para incrementar las probabilidades de éxito en los proyectos informáticos que se adelanten.

B. Situación de la Gerencia de Proyectos en el Banco de la República B.1. Contexto del Banco de la República El Banco de la República es el Banco Central11 de Colombia, creado mediante la ley 25 de julio de 1923. Está organizado como una persona jurídica de derecho público con

10 www.pmicolombia.org, noviembre de 2003 11 Institución que ejerce la soberanía monetaria, en nombre y representación del estado. Formula e implementa la política monetaria, dirigida a mantener la estabilidad del nivel general de precios, a fin de

34

autonomía administrativa, patrimonial y técnica, sujeto a un régimen legal propio, según lo expresado en la Constitución Política de Colombia de 1991. Es un ente autónomo e independiente, pues no forma parte de las ramas del Poder Público – Ejecutivo, Legislativo y Jurisdiccional –, ni de organismos de control, fiscalización o del poder electoral. Es una entidad del estado, de naturaleza única, dotada de una organización propia adaptada a las funciones que debe desempeñar. En la actualidad las funciones del Banco de la República se concentran principalmente en:

- Mantener la estabilidad de la moneda; es decir, conservar su capacidad adquisitiva. Para ello controla y monitorea la evolución de la inflación y fija metas de inflación anuales.

- Emitir la moneda nacional. Función exclusiva e indelegable del Banco y por la cual es conocido como “El Emisor”.

- Ser banquero de bancos. Esto significa, ser depositario de los dineros que los bancos comerciales le consignan en cumplimiento del requisito de la reserva bancaria y de respaldo a la liquidez del sistema financiero. También actúa como prestamista de última instancia de los establecimientos de crédito, en casos de iliquidez transitoria.

- Brindar crédito al gobierno bajo condiciones muy específicas en situaciones de extrema necesidad y bajo aprobación unánime de todos los miembros de la Junta Directiva.

- Ejercer seguimiento de toda la operación bancaria con base en información obtenida de las actividades de entidades del sistema financiero, y en su permanente contacto con la Superintendencia Bancaria. Ello le permite ejercer permanente evaluación de las operaciones del sector, ampliar su capacidad para establecer las políticas de control y orientar la actividad de intermediación financiera.

- Participar en el diseño y definición de la política en materia de tasa de cambio y movimiento de capitales internacionales. En tal sentido, organiza y regula el mercado cambiario e interviene en éste con el propósito de defender la tasa de cambio y de reglamentar las condiciones de endeudamiento externo del país.

- Administrar las reservas internacionales12 del país que incluye el manejo, inversión, depósito de custodia y disposición de los activos de reserva. La inversión se efectúa con base en criterios de seguridad y liquidez, para facilitar los pagos del país en el exterior.

- Ser promotor del desarrollo científico, cultural y social. El Banco ha creado fundaciones

35

Luis Ángel Arango, hacen parte del Banco de la República y tienen amplio reconocimiento nacional e internacional por la labor que desarrollan.

B.2. Estructura organizacional del Banco de la República El Banco de la República cuenta con tres organismos para ejercer la dirección, administración y ejecución de las diferentes actividades orientadas al cumplimiento de sus funciones. El organismo de dirección es la Junta Directiva, revestida de autoridad en materia monetaria, cambiaria y crediticia. Está conformada por siete miembros que deben reunir ciertas calidades y requisitos, con el fin de garantizar una elevada idoneidad profesional y ética, pues representan exclusivamente el interés general de la Nación. Cinco miembros son de dedicación exclusiva, el sexto es el ministro de Hacienda y Crédito Público y el séptimo es el gerente general, nombrado por los restantes miembros. El organismo de administración del Banco es el Consejo de Administración, delegado por la Junta Directiva. Ejerce funciones administrativas y operativas relacionadas con la organización y funcionamiento interno del Banco y propende por su buen funcionamiento. La ejecución en el Banco está a cargo de la Gerencia General, la Gerencia Técnica y la Gerencia Ejecutiva. Implementan y aplican las políticas definidas por la Junta Directiva y el Consejo de administración.

Figura 9. Organigrama Banco de la República13

El gerente general, además de las funciones que cumple como miembro de la Junta Directiva, es el administrador del Banco y ejerce la representación legal del Banco ante organismos financieros internacionales y nacionales.

13 www.banrep.gov.co, octubre de 2002

36

La Gerencia Técnica aplica políticas institucionales sobre inversión de las reservas internacionales; así como, metodologías de intervención en los mercados cambiario y monetario nacionales, que deben proponer ante la Gerencia General y los organismos de dirección del Banco. También, define estrategias a corto plazo para el logro de los objetivos y cumplimiento de las políticas generales trazadas por los comités de reservas y de intervención monetaria y cambiaria. Orienta la elaboración de estudios o investigaciones que solicite la Junta Directiva o el Gerente General como soporte idóneo para la toma de decisiones en asuntos de política económica. Cuenta con el apoyo de las siguientes subgerencias: - La Subgerencia de Estudios Económicos que dirige y ejecuta la política encaminada a

producir estudios, estadísticas e información en general, relacionada con aspectos monetarios, cambiarios y crediticios de la economía.

- La Subgerencia Monetaria y de Reservas, ejecuta políticas de intervención monetaria y de seguimiento al sector financiero definidas por la Junta Directiva, el Comité de Reservas y el Comité de Intervención Monetaria y Cambiaria. Administra el portafolio de las reservas internacionales, las operaciones de mercado abierto.

La Gerencia Ejecutiva tiene a cargo la dirección y ejecución de políticas relacionadas con administración de personal, seguridad, protección de sus recursos físicos y el patrimonio, control interno de la institución, manejo de la operación bancaria y el área industrial del Banco, desarrollo y fomento de actividades culturales. Se apoya en las siguientes áreas: - La Subgerencia de Operación Bancaria: implementa y aplica políticas, procedimientos y

actividades derivadas de las funciones sustantivas del Banco en materia de operación bancaria, como por ejemplo: atender operaciones de cambio internacional; administrar títulos valores emitidos por el Banco o el gobierno nacional; suministrar información cuantitativa, oportuna y confiable, de los estados financieros del Banco; servir de prestamista de última instancia; administrar la cuentas corrientes y de pagos, entre otros.

- La Subgerencia Industrial y de Tesorería: aplica políticas y orienta procesos de producción para la fabricación y distribución de billetes y moneda metálica.

- La Subgerencia de Seguridad: tiene a cargo la aplicación y desarrollo de políticas relacionadas con la protección integral del patrimonio del Banco y de su recurso humano; así como, la dirección, coordinación, planeación y supervisión de los recursos físicos, monetarios y humanos que le han sido asignados.

- La Subgerencia Administrativa: maneja los recursos del Banco y el mantenimiento de su estructura organizacional. También administra, coordina y brinda soporte del factor humano para el suministro oportuno del talento requerido para llevar adelante los objetivos institucionales y busca el mejoramiento de la calidad de vida de los empleados.

- La Subgerencia Cultural: orienta y dirige la política cultural patrocinada por el Banco y prevista por la ley. Administra la Biblioteca Luis Ángel Arango; conserva y divulga el patrimonio cultural precolombino; y fomenta y apoya las artes plásticas y musicales.

- La Subgerencia de Informática: define e implementa políticas de modernización y adecuación de la infraestructura técnica del Banco, mediante el suministro de servicios y

37

soluciones informáticas integrales, efectivas, seguras, oportunas y confiables que apoyen y faciliten el cumplimiento eficaz de su misión. Para ello cultiva un conocimiento profundo del Banco, de la tecnología y la metodología informática.

En el Banco de la República el área responsable de implementar y apoyar la aplicación de la función de Gerencia de Proyectos es la Subgerencia de Informática. A continuación se describe en mayor detalle su funcionamiento y estructura organizacional. Los principales valores de la subgerencia se apoyan en el compromiso con el cliente interno y externo, la excelencia en productos y servicios, el mejoramiento continuo y el trabajo en equipo. Los lineamientos estratégicos de la subgerencia son:

- Agregar valor permanente a todos los productos y servicios generados; así como, adicionar beneficios significativos y diferenciadores.

- Adoptar un modelo de gestión integral que permita administrar tres elementos interrelacionados: la dirección estratégica, la gerencia de procesos (día a día) y el proceso de transformación cultural. Esta función de gerencia se basa en el ciclo de las actividades de planear, hacer, verificar y actuar.

- Gestionar de manera integral el recurso humano, buscando el bienestar y desarrollo personal y profesional de quienes hacen parte de la Subgerencia.

- Fortalecer de manera continua la cultura de servicio al cliente en todas las áreas de la subgerencia Informática: Específicamente, el conjunto de creencias básicas, costumbres, manifestaciones y verdades, compartidas y aceptadas por todos los miembros de la Subgerencia que determinan la forma de pensar, sentir y actuar frente a los clientes internos y externos, en procura de satisfacer sus requerimientos.

Para el cumplimiento de sus objetivos, subgerencia se apoya en las siguientes áreas: El Departamento de Tecnología Informática que mantiene actualizada, operativa y tecnológicamente, la plataforma de cómputo y de telecomunicaciones, de acuerdo a las necesidades del Banco. El Departamento de Gestión Informática, asesora en materia informática a sus clientes y lidera desde el punto de vista tecnológico los proyectos emprendidos para dar soluciones que apoyen la operación y gestión de todas las dependencias y sucursales en el Banco de la República. La Unidad de Seguridad Informática vela por la seguridad de la información. Apoya su marco de acción en los siguientes fundamentos de seguridad informática: confidencialidad, integridad, disponibilidad, autenticación, autorización, no-repudiación y auditabilidad. La Unidad de Protección y Continuidad de la Información, diseña y pone en funcionamiento soluciones efectivas que respondan a cualquier incidente que se presente en la infraestructura tecnológica, estructural u organizacional del Banco y que afecte el funcionamiento normal de sus operaciones.

38

El Grupo de Organización de la Calidad – GOC, grupo de apoyo o soporte cuya principal responsabilidad es determinar e implementar la política, los objetivos, los procedimientos y las responsabilidades de la calidad utilizando medios tales como la planeación, el control, el aseguramiento y el mejoramiento. Específicamente el GOC es responsable por: - Planear, mantener y mejorar el sistema de calidad de la Subgerencia de Informática,

compuesto por objetivos, estructura organizacional, procesos, procedimientos, recursos y sus interrelaciones, necesarios para implementar la gestión de la calidad.

- Mejorar, de manera continua, los procesos de la Subgerencia de Informática, en relación con la ingeniería de software y con los servicios y la función de soporte.

- Analizar y planear la gestión en la Subgerencia de Informática. Para ello, genera y promueve el pensamiento estratégico a nivel de la Subgerencia de Informática y busca

39

disminuir sus niveles de servicio; para ello, una de las acciones trazadas consistió en seleccionar y adaptar una metodología para la planeación y gerencia de proyectos. En tal sentido, durante el año 2003, el Grupo de Organización de la Calidad – GOC lideró un proyecto para construir y poner en funcionamiento una metodología de gerencia de proyectos informáticos, la cual se apoyó en las mejores prácticas del PMI y tuvo en cuenta las necesidades particulares de la subgerencia de Informática. Durante la planeación del proyecto para construir la metodología, se identificaron proyectos complementarios como la biblioteca de proyectos, la función de aseguramiento del proyecto y la gerencia del portafolio de proyectos. La finalidad de estos proyectos fue incrementar las probabilidades de éxito de los proyectos informáticos y crear las condiciones para, en una etapa posterior, configurar y operar una oficina de control de proyectos. En tal sentido se acordó que, de manera paralela a la estructuración de la metodología, se diera prioridad para modelar y personalizar, en el contexto de los proyectos informáticos del Banco, la función de aseguramiento del proyecto. Es en este punto donde el presente trabajo de investigación encuentra una oportunidad de validar el modelo propuesto de aseguramiento de proyectos informáticos y el Banco de la República, tiene la oportunidad de atener una necesidad identificada.

40

V. IMPLEMENTACIÓN DE LA PROPUESTA A continuación se describen los principales lineamientos para estructurar y aplicar el modelo propuesto de la función de aseguramiento de proyectos informáticos – AP, el cual se apoya en el término original project assurance [8]. La aplicación del modelo parte del supuesto de que la organización cuenta con un programa de gerencia de proyectos que apoya la planeación y ejecución de proyectos orientados al desarrollo de sistemas de información a la medida, independiente de la metodología o procedimientos particulares a cada programa de gerencia de proyectos. En otro caso puede suceder que la organización tenga planeado personalizar e implantar un estándar de gerencia de proyectos, cuyo alcance cubra el esquema de aseguramiento de proyectos informáticos. El modelo propuesto tiene en cuenta aspectos contenidos en la guía PMBOK2000 y se apoya en la función de aseguramiento del proyecto [8] contenida en la metodología PRINCE2. En muchos estándares de gerencia de proyectos, la administración de la calidad y de los riesgos son elementos que, aunque no garantizan el éxito total de la realización del proyecto, incrementan significativamente sus probabilidades. Apoyados en este supuesto, el modelo que se propone busca asegurar gradualmente cada uno de los componentes de la gerencia del proyecto para alcanzar los objetivos del proyecto, generar un producto final que satisfaga las expectativas de los stakeholders y cumplir las restricciones de tiempo y recursos. Específicamente el aseguramiento del proyecto propende por:

- Incrementar los niveles de probabilidad para que los proyectos de desarrollo de software a la medida estén orientados a suministrar productos o servicios dentro los tiempos y recursos presupuestados y para que los beneficiarios finales vean altamente satisfechas sus expectativas y necesidades iniciales.

- Mantener un equipo de trabajo independiente que suministre la información necesaria y oportuna para apoyar a la alta gerencia o al equipo directivo del proyecto, en el proceso de toma de decisiones en relación con su viabilidad.

- Asegurar que los proyectos sean planificados y controlados por el propio equipo de trabajo del proyecto. De igual manera, asesorar a los integrantes del proyecto en relación con la mejor forma de interpretar y aplicar los diferentes estándares definidos por la organización para apoyar el desarrollo de cualquier proyecto.

A. Terminología

La terminología empleada en la descripción y estructuración del modelo de aseguramiento del proyecto tiene en cuenta lo contenido en la norma NTC – ISO 8402 publicada por el Instituto Colombiano de Normas Técnicas y Certificación – ICONTEC, actualizada en la norma ISO 9000-2 del estándar internacional ISO – International Organization for Standardization. El Aseguramiento del Proyecto se apoya principalmente en los siguientes términos:

41

Interesados del proyecto (stakeholders): Individuos u organizaciones que están activamente involucrados en el proyecto o que tienen intereses que pueden ser afectados positiva o negativamente con la ejecución del proyecto. Tienen capacidad para influenciar, decidir, en las acciones del proyecto y en los resultados de éste. Cliente: Persona, grupo de personas u organización receptora de un producto o servicio suministrado por un proveedor. Futuros usuarios del producto final, bien o servicio, que se genere con el proyecto. En algunos proyectos el cliente y el usuario son definidos con roles y personas diferentes, en tanto que en otros pueden ser uno mismo. Proveedor: Persona, grupo de personas u organización que suministra un producto o presta un servicio al cliente. Puede pertenecer o no a la misma organización del cliente. Estructura organizacional: Conjunto de responsabilidades, autoridades y relaciones dispuestas en un modelo, a través del cual una organización o empresa realiza sus funciones. Producto, entregable, salida: Resultado de la ejecución de un proceso, procedimiento o actividad. Algo que representa o significa la terminación de una actividad o trabajo. En un proyecto existen entregables intermedios que apoyan el desarrollo del proyecto y productos finales que son generados como consecuencia de la ejecución del proyecto. Las principales salidas de un proyecto de desarrollo de software son: el sistema de información y la documentación que lo apoya. La documentación puede estar en papel o ubicada en medios magnéticos. Ejemplos de ella son: manuales técnicos, de usuario o de funciones; el código de los programas, incluida su documentación; los diagramas entidad – relación y de flujo; actas de reuniones de avance del proyecto; contratos y memorandos; pliegos de peticiones y de requerimientos, etc. El software o sistema de información es el principal producto final de un proyecto de desarrollo de software a la medida. Es un medio para medir el nivel de cumplimiento de las expectativas, deseos o intereses de quienes dieron origen y/o aprobaron la ejecución del proyecto. Servicio: Beneficios generados por actividades ejecutadas en la interrelación entre el proveedor y el cliente o por acciones del proveedor para atender las necesidades del cliente. Un servicio puede estar ligado con la manufactura y el suministro de un producto tangible, por ejemplo, un sistema de información financiera es un producto para el área de financiera que brinda servicios a las demás áreas de la organización. Paquetes de trabajo: Información relevante para la elaboración de uno o más entregables. Contiene la descripción del producto, restricciones para su generación, tiempos y costos asociados y criterios de aceptación. Puede involucrar otros paquetes de trabajo o un grupo de productos o entregables intermedios. Proyecto: Conjunto de acciones para administrar unas condiciones establecidas, con unos recursos finitos asignados, para adelantar una línea particular de investigación o la entrega

42

de uno o más productos o servicios en un periodo de tiempo limitado. Además de los resultados de una investigación, o de los productos o servicios finales; el proyecto también genera productos orientados a la administración que facilitan su adecuada dirección. Proyectos de desarrollo de software a la medida: Encierra todos los aspectos que cubre la definición genérica de un proyecto; sin embargo, el producto final de la ejecución de este tipo de proyectos es un software o sistema de información personalizado según las condiciones y/o necesidades específicas de una organización, grupo o persona. Gerencia de proyectos: Coordinación o integración adecuada de un conocimiento que involucra un vocabulario común, de un grupo de personas que actúan como un equipo de trabajo, de un ciclo de actividades propias del proyecto y de un conjunto de elementos de administración para el manejo del proyecto. Calidad: La totalidad de características de una entidad, ítem o producto que le otorgan su aptitud (capacidad) para satisfacer necesidades establecidas e implícitas en un periodo de tiempo. Es conveniente no utilizar el término calidad de manera aislada para expresar un grado de excelencia o en sentido cuantitativo para evaluaciones técnicas. Su uso debe complementarse con adjetivos calificativos como: “nivel de calidad” en el sentido cualitativo o medida de calidad cuando se traten de evaluaciones técnicas precisas. En algunos casos se hace referencia a la calidad como una característica de ser apto para el uso, apto para el propósito, de satisfacción del cliente o de conformidad de los requisitos. Sistema de calidad: Compuesto por la estructura organizacional, los procedimientos, los procesos y los recursos necesarios para implementar el proceso de administración de la calidad. Aseguramiento de la calidad: parte de la gestión de calidad cuyas actividades componentes están planificadas y sistemáticamente implementadas dentro de un sistema de calidad cuyo fin principal es brindar adecuada confianza de que una entidad o persona está cumpliendo los requisitos de calidad en el logro de un producto o prestación de un servicio. Línea base: Equivale a una foto instantánea tomada al proyecto en un momento específico en relación con una situación que ha sido registrada. La situación registrada puede variar con el tiempo y actualizarse mediante otra foto; sin embargo, la línea base permanece y está disponible como un instrumento de validación y control cuando se confronta la situación en diferentes instantes de tiempo. Permite identificar problemas y actuar con anticipación para mantener la viabilidad del proyecto. Caso de Negocio: En inglés Business Case. Información que describe la justificación para implementar y continuar el proyecto. Suministra razones; es decir, responde al porqué debe iniciarse, ejecutarse, continuarse o terminarse el proyecto. Se evalúa en puntos o momentos críticos definidos para el proyecto. Valoración de finalización de etapa: Acción de revisión que adelanta el grupo directivo del proyecto previo a la finalización de una etapa con el fin de tener certidumbre acerca la

43

gestión en la etapa que termina y del estado real del proyecto para apoyar el proceso de toma de decisiones. Excepción: Situación en la cual se puede prever que habrá una desviación fuera de los límites de tolerancia que se han acordado para el desarrollo del proyecto. Un informe de excepción, suministra un análisis de la excepción, las opciones para su tratamiento y la acción recomendada.

B. Estructuración de la propuesta El modelo de la función de aseguramiento de proyectos informáticos que se propone, figura 11, está integrado por cuatro elementos, a saber: - Los componentes mínimos requeridos en un programa de gerencia de proyectos para

posibilitar la adecuada aplicación del modelo de aseguramiento del proyecto. - La estructura organizacional mínima requerida para aplicar adecuadamente la función

de aseguramiento del proyecto. - Las principales responsabilidades asociadas a cada uno de los cargos o roles que apoyan

el aseguramiento de proyectos informáticos. - Los productos o entregables que deben generarse en el cumplimiento de las diferentes

responsabilidades asociadas con el modelo de aseguramiento del proyecto.

Figura 11. Elementos de la propuesta de la función de AP

B.1. Componentes del aseguramiento del proyecto

La estructuración y aplicación del modelo AP en un proyecto de desarrollo de software a la medida exige en forma previa la configuración y funcionamiento de un programa de gerencia de proyectos. El aseguramiento del proyecto debe incorporarse como una función de apoyo a la gerencia o administración de proyectos. Independiente de las condiciones o características que definan un proyecto, así como, de la forma como se configure el programa de gerencia de proyectos en una organización, el

44

aseguramiento del proyecto debe contemplar los siguientes componentes mínimos para garantizar su adecuada aplicación: Organización: Este componente de la gerencia de proyectos debe involucrar los lineamientos generales que permitan conformar una estructura organizacional para posibilitar la administración y ejecución exitosa de todo proyecto. La estructura debe contemplar que el contexto donde se desarrolle el proyecto se apoye principalmente en las interacciones de dos grupos o unidades organizaciones: el usuario o cliente, y el proveedor. Las partes mencionadas pueden pertenecer a la misma organización o funcionar como entes independientes [8]. Todo proyecto requiere dirección, para mantenerlo orientado hacia el producto final; administración, para utilizar y aprovechar de manera eficiente los recursos disponibles; control, para regular el desarrollo del proyecto, manejando adecuada y oportunamente amenazas y riesgos; y comunicación, para facilitar la interacción de todos y cada uno de los componentes del proyecto. La organización flexible del proyecto posibilita que los requerimientos antes mencionados se cumplan y se alcancen los objetivos del mismo. La flexibilidad se logra mediante una adecuada definición de roles con responsabilidades bien delimitadas. La distribución o asignación de dichos roles depende de las características propias de cada proyecto, por ejemplo: la complejidad del mismo proyecto, la propia estructura funcional de la organización y el contexto en el cual se suministran los productos requeridos en el proyecto. Planeación: Este componente es vital para el éxito de cualquier proyecto. Los planes y/o cronogramas de actividades son los principales productos que contienen información para confirmar si los objetivos del proyecto y los mismos planes son alcanzables. Un plan se define como el trabajo que debe realizarse con el desarrollo del proyecto, que especifica quién desempeña las tareas y cuáles son sus costos en términos del tiempo y recursos requeridos. Los planes constituyen la base de un compromiso para realizar el proyecto y suministran un medio de comunicación de información acerca de su estado [8]. Específicamente, los planes deben tener en cuenta cuáles son los paquetes de trabajo, los productos intermedios y finales que debe generar el proyecto; las actividades necesarias para producirlos y la forma cómo están organizadas; las actividades necesarias para validar la calidad del producto final; las dependencias entre actividades y con otros elementos externos al proyecto; los medios y servicios requeridos para el desarrollo del proyecto; los riesgos identificados y las medidas propuestas para su control. Los planes pueden variar de acuerdo con su alcance, contenido y nivel de detalle. Se pueden definir planes globales que cubran el desarrollo de todas las etapas del proyecto desde su configuración hasta la entrega y puesta en marcha de la solución final. También pueden definirse planes más específicos por etapa, por productos o paquetes de trabajo y hasta por los componentes del proyecto, dependiendo de su complejidad. Administración de Riesgos: Los proyectos usualmente son factores generadores de cambio en las organizaciones. Dichos cambios buscan llevarlas a estados eficientes de

45

desempeño; sin embargo, está dinámica posibilita la exposición a consecuencias adversas, lo cual es identificado como el riesgo inherente que conlleva el cambio [8]. Con base en lo anterior, el riesgo, dentro de sus muchas definiciones, puede ser considerado como la posibilidad que tiene una organización para exponerse en el futuro a situaciones no deseadas o que atenten contra su viabilidad. La administración del riesgo en un proyecto es fundamental para su desarrollo exitoso; dicha administración debe mínimo contemplar dos aspectos:

- Un análisis del riesgo, que incluye actividades como: identificación; valoración, estimar la capacidad de impacto del riesgo; y evaluación del riesgo, determinar el impacto real causado.

- Una administración del riesgo, con actividades como: planeación, asignación de recursos, control y monitoreo.

Las posibles acciones que se buscan adelantar para administrar el riesgo, se pueden clasificar, según su naturaleza, de la siguiente manera:

- Prevenir el riesgo: medidas y contramedidas para evitar la ocurrencia o disminuir la probabilidad de ocurrencia del riesgo en el proyecto.

- Reducir el riesgo: son acciones para reducir o limitar el impacto del riesgo y conducirlo a niveles aceptables.

- Transferir el riesgo: endosar o pasar el riesgo a terceros. - Aceptar el riesgo: cuando las medidas y contramedidas son desproporcionadamente

costosas o existen dudas acerca de que el riesgo se presente, una posible salida es ser consciente, identificar y asumir las consecuencias cuando el riesgo se haga realidad.

- Contingencia del riesgo: comprende el diseño, implementación y prueba de planes acción para aplicar cuando un riesgo se tipifique.

Control del Proyecto: Toda decisión que se tome durante el desarrollo del proyecto debe adelantarse de manera oportuna, por la persona o equipo de personas más apropiado, con autoridad y conocimiento, y apoyada en información precisa y confiable. Esto asegura una apropiada comunicación, control y monitoreo del contexto donde opera el proyecto [8]. Mediante los controles se busca administrar y brindar aceptables niveles de confiabilidad a los posibles cambios que enfrente el proyecto; así como, manejar las posibles amenazas y riesgos que éste enfrente. Según el nivel donde se localicen dentro del proyecto, los controles pueden ser de tipo operativo, administrativo y estratégico; según su objetivo los controles pueden ser de tipo correctivo, detectivo o preventivo. Manejo de las etapas del proyecto: Las etapas son subdivisiones del proyecto con propósitos administrativos y de control. El nivel de trabajo se define con base en el plazo y recursos que se autorizan para cada etapa y tienen en cuenta los objetivos particulares de la etapa. Hay una oportunidad al final de cada etapa para revisar formalmente el proyecto y confirmar (o cancelar) la viabilidad de continuar antes de adquirir el compromiso de las

46

etapas subsecuentes. La descomposición del proyecto en etapas posibilita desagregar los niveles de complejidad para facilitar su control y manejo [1]. Todo proyecto está compuesto de mínimo dos etapas: una de iniciación o configuración y otra de desarrollo [3]. Sin embargo, las necesidades específicas del proyecto pueden incidir en la definición y organización del número de etapas requeridas. En los proyectos de desarrollo de software a la medida, esta segunda etapa se descompone en actividades de menor complejidad conocidas como el ciclo de vida de desarrollo de software. Administración de la calidad: Componente mediante el cual se busca asegurar que las expectativas del usuario y/o beneficiario con respecto al producto final se cumplan [8]. El manejo de la calidad para un proyecto debe comprender mínimo los siguientes aspectos:

- Una planeación de la calidad; que tenga en cuenta las actividades y requerimientos de los recursos asociados con la administración integral de la calidad.

- Un aseguramiento de la calidad; es decir, certificar un nivel aceptable de confianza en relación a la existencia de sistemas y procedimientos documentados que sean seguidos de manera correcta.

- Un control de calidad; donde la calidad sea evaluada o chequeada mediante revisiones formales de los paquetes de trabajo o de los productos para asegurar que los criterios de calidad se cumplan y que estos se adapten a sus propósitos.

Administración de la configuración: Este componente busca facilitar la identificación, el seguimiento o reconstrucción, así como, la protección de todos los paquetes de trabajo y productos definidos para el proyecto [8]. La configuración del proyecto es equivalente a la gerencia de alcance en la guía PMBOK2000 del PMI [3]. Algunas acciones orientadas a mantener una adecuada configuración del proyecto son:

- Identificar los ítems o elementos que hacen parte de la configuración del proyecto y actualizar la descripción de cada ítem con base en los ajustes generados.

- Controlar los ítems de configuración, específicamente las formas como se diligencian, almacenan y distribuyen.

- Manejar cualquier tipo de cambio necesario o requerido que incida sobre la configuración vigente del proyecto.

- Registrar y/o justificar los ítems de la configuración; así como, monitorear y hacer seguimiento a los cambios de estados en dichos ítems.

El proceso de control de cambios sobre el proyecto combinado con una adecuada capacidad para identificar y controlar las diferentes versiones de un ítem de configuración, constituyen un aspecto vital para mantener la viabilidad y rumbo del proyecto. El control de cambios involucra valoraciones acerca del impacto del cambio, de los costos asociados, de las responsabilidades y niveles de autoridad involucrados. Hoy día el mercado está inundado de diversos modelos, metodologías, métodos y marcos de referencia, entre otros; que apoyan la mayoría de los componentes anteriores. Sin embargo, es importante aclarar que el éxito de la Gerencia de Proyectos y del Aseguramiento del Proyecto no radica en el tipo de modelo, metodología o método

47

empleado; sino en la adecuada definición, implementación y aplicación de dichos componentes al contexto de la organización.

B.2. Estructura organizacional del modelo de aseguramiento del proyecto La estructura planteada es una base para facilitar la configuración y aplicación de la función de aseguramiento de proyectos informáticos, en una organización que tenga implementado y aplique un programa de gerencia de proyectos. Esta propuesta no puede aplicarse como una camisa de fuerza, porque la estructura de cada organización es particular y está influenciada por otros aspectos del contexto donde desenvuelve como son legislación, momento en el tiempo, región, personas, etc. La participación en un proyecto implica adoptar comportamientos de trabajo en equipo y la conformación de cualquier equipo de trabajo tiene por finalidad alcanzar mejores resultados de los que se pudiesen lograr de manera individual. En tal sentido, los participantes en un proyecto deben identificar las metas comunes respecto del proyecto y saber cómo interactuar con los demás miembros del proyecto, pues son responsables solidarios de los éxitos o fracasos del proyecto [16]. Los principales actores en un proyecto de desarrollo de software a la medida son el usuario, definido como el dueño del proyecto, quien maneja el producto final y se beneficia de sus resultados, en este caso del nuevo sistema de información y el proveedor, quien suministra el producto final de acuerdo con las especificaciones definidas por el usuario.

Figura 12. Estructura organizacional sugerida para aplicar AP de manera independiente.

Adaptado de The Project Assurance Function – Companion [8] Cuando el dueño del proyecto, el administrador del producto final y el beneficiario de los servicios del producto final son diferentes, se identifican tres roles, a saber: el patrocinador

48

o dueño del proyecto, quien suministra los recursos para la realización del proyecto; el usuario, responsable del manejo y administración del producto; y el beneficiario de los resultados que genera el producto. Una posible estructura para el desarrollo de un programa de gerencia de proyectos que cuente con la función de aseguramiento del proyecto se muestra en la figura 12. Aunque se aprecia un equipo de AP que funciona a nivel de staff como apoyo al equipo directivo, es importante precisar que éste puede variar por aspectos como el tamaño del proyecto, restricciones de presupuesto o falta de personal con experiencia en la función de AP, entre otros. A continuación se explican los entes que conforman una estructura básica de gerencia de proyectos y se hace énfasis en los de AP: Equipo Directivo del Proyecto: Considerado el dueño del proyecto, está revestido de autoridad para aprobar o rechazar la etapa de iniciación, así como, para tomar decisiones que impacten significativamente el desarrollo del proyecto. Es el primer responsable por el éxito o fracaso del mismo. Está conformado por miembros de la media o alta gerencia de la organización dueña del proyecto; en especial, de las áreas que tienen intereses o son afectados con la realización del proyecto. El grupo representa los intereses más relevantes del proyecto. Está integrado por un representante de los usuarios, quien tiene la visión general de la situación que se busca atender o solucionar con el suministro del sistema de información; un representante del equipo proveedor, que puede pertenecer o no a la organización dueña del proyecto y es responsable de suministrar todos los recursos necesarios para adelantar el proyecto y generar el producto final; un representante de la alta gerencia, con autoridad limitada al alcance del proyecto, busca garantizar el suministro de los diferentes recursos para que el proyecto marche y atienda las necesidades relacionadas con el aspecto funcional de la organización. A este grupo, eventualmente, se pueden integrar representantes de áreas de apoyo como seguridad, auditoría interna, jurídica o planeación. El Equipo Directivo está activamente involucrado desde el inicio del proyecto, incluyendo su progreso y el cierre formal del mismo. Son responsables del proceso de dirección del proyecto que se encarga de manejar el detalle de sus actividades y tareas.

Equipo de Gerencia del Proyecto: Es quien recibe autoridad para manejar el proyecto del Equipo Directivo. Es responsable del desarrollo diario del proyecto dentro de los lineamientos y/o restricciones definidos por el Equipo Directivo y de reportar a éste con oportunidad y suficiencia, los aspectos relevantes del proyecto. Interpreta e implementa las decisiones tomadas por el Equipo Directivo. Generalmente se distinguen dos líderes, a saber: el gerente técnico, quien tiene conocimiento y experiencia del aspecto funcional que se beneficiará del producto final; y el gerente administrativo, quien planifica la adecuada distribución de los recursos asignados al proyecto.

49

Puede suceder que el proveedor no haga parte de la organización dueña del proyecto; en cuyo caso, se distinguen tres líderes: el gerente administrativo; el gerente técnico, representado por el proveedor; y el gerente funcional, quien conoce la función de negocio. Las organizaciones que cuentan con una oficina de soporte o control de proyectos tienen interacción permanente con el Equipo de Gerencia del proyecto, cuya función principal es asesorar en la aplicación de las mejores prácticas o estándares para desarrollar las actividades propias del proyecto. Equipo de Trabajo del Proyecto: Es un grupo de apoyo directo para el Equipo de Gerencia del proyecto. Adelanta acciones tendientes a hacer realidad las decisiones tomadas en relación con el proyecto. Está conformado por usuarios del producto final que tienen un conocimiento profundo de la funcionalidad o aspecto de negocio que se cubrirá total o parcialmente con el sistema de información. También lo integra un grupo del proveedor que tiene conocimiento detallado y habilidades para interpretar e implementar la solución a las necesidades de los usuarios. Este equipo de trabajo detalla o especifica los requerimientos sobre el nuevo producto, desarrolla o construye el producto, lo prueba y en general adelanta la actividad del día a día del proyecto. Equipo de Aseguramiento del Proyecto: en los casos donde es un grupo independiente del Equipo Directivo del Proyecto, no está revestido de poder de decisión. Su razón de ser está en suministrar confianza y certidumbre al Equipo Directivo que el proyecto está siendo manejado de acuerdo con las estrategias y planes definidos. Existen casos de empresas en el Reino Unido, que aplican la metodología PRINCE2, donde el equipo de Aseguramiento del Proyecto existe de manera independiente y pertenece a una organización diferente de aquella dueña del proyecto [8]. Sin embargo, independiente de la forma como se estructure la función en cada proyecto, lo más importante es que esta responsabilidad debe aplicarse siempre en todos los proyectos y es una responsabilidad que recae en el Equipo Directivo. El aseguramiento del proyecto busca garantizar el éxito del proyecto desde tres aspectos principales, a saber: - Asegurar el aspecto funcional: es decir, que se mantenga durante toda la existencia del

proyecto la línea base de proveer una solución acorde con la función de negocio definida en el inicio del mismo.

- Asegurar el proveedor: asesorar acerca de estándares y/o de las mejores formas de adelantar el proyecto; así como, validar el cumplimiento de la adecuada ejecución de las actividades del proveedor y la generación de productos en las condiciones acordadas, incluyendo tiempo, estándares y recursos.

- Asegurar el usuario – cliente: buscar que éstos hagan explícitos su intereses, mediante la delimitación de los problemas, expresados en términos de los requerimientos que deben cumplir los resultados del proyecto; así como, facultar a los usuarios para determinar con precisión los productos que cumplen las expectativas y condiciones establecidas [8]. Las principales razones para configurar un equipo de Aseguramiento del Proyecto independiente del Equipo Directivo son:

50

- Limitaciones de tiempo y conocimiento técnico específico por parte de los miembros del Equipo Directivo, lo cual genera riesgos en la interacción efectiva entre éste y el equipo de gerencia del proyecto.

- Necesidad del Equipo Directivo del proyecto de contar con una fuente fidedigna e independiente para evaluar la validez de la información entregada por el Equipo de Gerencia para tomar decisiones bajo condiciones aceptables de certidumbre.

- Necesidad de generar un clima de confianza cuando el proyecto esté siguiendo en forma adecuada las directrices y estándares aprobados por la organización. En caso contrario, posibilitar la reacción proactiva y adecuada de los participantes en el proyecto, ante las posibles amenazas o situaciones de riesgo que enfrente el proyecto en su realización [8].

B.3. Roles y/o responsabilidades asociadas con el aseguramiento del proyecto

Con base en la estructura organizacional planteada, a continuación se relacionan las principales responsabilidades de cada uno de los actores involucrados en un programa de gerencia de proyectos de desarrollo de software a la medida que aplica el aseguramiento del proyecto. Responsabilidades del Equipo Directivo del Proyecto - Aprobar los planes de acción relevantes del proyecto como son el plan global y el plan

de cada etapa. Autorizar cualquier desviación o modificación sobre estos planes. - Aprobar y garantizar la asignación de los recursos requeridos en el desarrollo del

proyecto. - Dirimir o decidir sobre conflictos presentados dentro del proyecto, negociar la solución

de problemas producidos en la interacción del proyecto dentro del entorno donde se desarrolla.

- Aprobar los niveles de tolerancia o desviación del proyecto respecto de tiempos, recursos y condiciones de aceptación de los entregables.

- Determinar las principales restricciones del proyecto, por ejemplo: metodologías que apoyarán los procesos de calidad, de administración de riesgos y controles, el ciclo de vida del proyecto, el proceso de pruebas, entre otros.

- Liderar y aprobar el proceso de administración de riesgos, que incluye evaluar el nivel de exposición al riesgo del proyecto y aprobar las acciones definidas para disminuir o controlar el impacto en su realización.

- Asegurar que todos los productos intermedios y finales se generen y entreguen satisfactoriamente y cumplan, en gran porcentaje, el tiempo y los costos estimados, así como, las expectativas definidas sobre dichos entregables.

- Aprobar el informe de lecciones aprendidas del proyecto y las acciones de mejora a seguir generadas con base en la experiencia adquirida en el desarrollo del proyecto.

- Acordar actividades de inspección o evaluación post implantación del producto final.

Responsabilidades asociadas directamente con el aseguramiento del proyecto - Otorgar visto bueno de aceptación para la terminación de cada etapa del proyecto y el

inicio de la siguiente, con base en la información suministrada por el Equipo de Gerencia del Proyecto y el Equipo de Aseguramiento del Proyecto.

51

- Aprobar la configuración y designación de responsabilidades del Equipo de Gerencia y del Equipo de Aseguramiento del Proyecto. Este último en el caso, cuando el Equipo Directivo decida delegar la función.

- Aprobar los principales productos intermedios o de administración del proyecto, entre ellos: el Documento de Iniciación del Proyecto – DIP, el Plan global del proyecto, los planes de etapa del proyecto, el plan de acciones de excepción, el documento de especificación general de requerimientos, etc.

- Suministrar permanentemente la dirección del proyecto para asegurar la viabilidad del mismo dentro de las restricciones existentes. Para ello se apoya en la información suministrada por el Equipo Gerencial del Proyecto y en el diagnóstico que genere el Equipo de Aseguramiento del Proyecto.

- Requerir al Equipo de Aseguramiento del proyecto, cuando sea necesario, asesoría e información acerca de la gestión del proyecto y de las recomendaciones o acciones acordadas con otros grupos del proyecto.

Responsabilidades del Equipo de Gerencia del Proyecto - Posibilitar en el proyecto la generación de un resultado final que brinde los beneficios

establecidos según el aspecto funcional. - Coordinar la asignación y administración de los recursos requeridos para el desarrollo

del proyecto. - Dirigir y motivar el equipo de trabajo de proyecto. - Preparar y definir, en conjunto con el equipo de trabajo, el plan general del proyecto,

los planes de acción por etapa y el plan de excepción para evaluación y aprobación por parte del Equipo Directivo.

- Generar periódicamente, con destino al Equipo Directivo, un informe de los aspectos más relevantes de la gestión realizada en cada etapa y de las expectativas esperadas.

- Monitorear el desarrollo global del proyecto y constatar el cumplimiento en el desarrollo de los planes.

- Estructurar y generar el documento de iniciación del proyecto – DIP. - Interactuar permanentemente con el proveedor. Ser el primer elemento de resolución

de conflictos en la relación usuario – proveedor. - Estructurar y adelantar el proceso de administración de riesgos, incluyendo la

configuración del plan de contingencia del proyecto. Dicho plan de contingencia se limita al proyecto y no cubre el plan de contingencia para la continuidad del negocio o del aspecto funcional que cubrirá con el producto final.

- Coordinar y plantear acciones de solución cuando se presenten problemas de disponibilidad de recursos compartidos entre proyectos en paralelo o entre grupo del mismo proyecto.

- Monitorear el desarrollo del proyecto y reportar oportunamente las novedades al Equipo Directivo y demás entes que lo requieran.

- Definir, coordinar y monitorear el desarrollo de tareas específicas del Equipo de Trabajo del Proyecto.

- Liderar el proceso de control de cambios y la administración de la configuración del proyecto.

- Preparar el informe de reporte de lecciones aprendidas y el informe de las recomendaciones de acciones a seguir, requeridas pre y post proyecto.

- Preparar el informe de cierre del proyecto.

52

Responsabilidades asociadas directamente con el aseguramiento del proyecto

- Asegurar que el proyecto genere los productos intermedios y finales requeridos, de acuerdo con los estándares de calidad y dentro de las restricciones de tiempo y costos establecidos.

- Interactuar con el equipo de Aseguramiento del Proyecto facilitando la atención de cualquier requerimiento y solicitando la asesoría necesaria tendiente al adecuado desarrollo del proyecto.

- Identificar y obtener el soporte o asesoría requerido para la adecuada administración, planeación y control del proyecto.

- Atender cualquier solicitud generada, en relación con el proyecto, por entes de control y el equipo de Aseguramiento del Proyecto.

Responsabilidades del Equipo de Trabajo del Proyecto - Adelantar las actividades designadas por el Equipo de Gerencia del Proyecto

relacionadas con el desarrollo del proyecto - Elaborar los planes de actividades específicas y negociarlas con el Equipo de Gerencia

del Proyecto. - Obtener aprobación del Equipo Gerencial del Proyecto para la creación de productos o

de paquetes de trabajo. - Utilizar de manera oportuna y eficiente los recursos destinados para apoyar las

diferentes actividades del proyecto, teniendo en cuenta las recomendaciones y directrices comunicadas por el Grupo Directivo.

- Informar oportunamente, al Equipo de Gerencia del Proyecto, cualquier desviación respecto del plan general del proyecto o de los planes de etapa, sugerir posibles acciones que ayuden a configurar un apropiado plan de excepción.

- Informar o presentar, para revisión y/o aprobación por parte del Equipo de Gerencia del Proyecto, los entregables terminados – productos o paquetes de trabajo.

- Estar capacitado y aplicar eficientemente en el proyecto las metodologías, estándares, lineamientos, procedimientos y controles relacionados con aspectos como el control de calidad, pruebas a productos, congelación de versiones de productos, liberación de recursos, cierre de etapas, entre otros.

- Identificar e informar cualquier riesgo que amenace el éxito del proyecto y sugerir posibles acciones de control para disminuir su impacto.

Responsabilidades asociadas directamente con el aseguramiento del proyecto

- Atender o clarificar los requerimientos generados por el equipo de aseguramiento del proyecto y canalizados a través del Equipo de Gerencia del Proyecto.

Responsabilidades del Equipo de Aseguramiento del Proyecto Cuando el Equipo Directivo delega la función en un grupo independiente, es necesario responder inicialmente la siguiente pregunta: “Qué es lo que se busca asegurar?”. En tal sentido, los posibles aspectos que debe buscar el equipo para el aseguramiento del proyecto son: - Que exista o se mantenga una relación estrecha entre el proveedor y el usuario-cliente a

lo largo del proyecto.

53

- Las necesidades y expectativas de los usuarios y en general de todos los interesados en el proyecto se estén manejando de manera efectiva y se cumplan con la realización del proyecto.

- Los riesgos del proyecto se identifiquen, controlen, limiten en su impacto u probabilidad, y se reduzcan, de ser posible, de manera oportuna y adecuada.

- El proyecto se mantenga permanentemente alineado o enfocado en la solución funcional. Es decir, que la alineación entre los objetivos del proyecto y los objetivos estratégicos de la organización se mantengan.

- Que se valore permanentemente la relación costo beneficio del producto final solución. - Las personas correctas estén involucradas en el proyecto en el momento preciso y con

la dedicación mínima necesaria. - La solución desarrollada o implementada sea aceptable y aplicable. - El proyecto se mantenga viable y el alcance del mismo no se tergiverse. - Los protocolos de comunicación definidos hacía el interior del proyecto y con el

entorno donde se desarrolla, estén funcionando adecuadamente. - El impacto de cualquier solicitud o requerimiento de cambio sea valorada, entendida y

aceptada por los beneficiarios del producto final. - Los estándares definidos para procesos como el control de calidad, pruebas o

administración de riesgos se estén aplicando de acuerdo con los lineamientos y las restricciones definidas por el Equipo Directivo del Proyecto.

- Se estén cubriendo o trabajando requerimientos técnicos particulares como la seguridad o las acciones de contingencia.

- El proveedor esté aplicando de forma apropiada los estándares y métodos bajo los cuales se acordó o contrató el proyecto.

- Los requerimientos específicos como aspectos de seguridad, recuperación, continuidad del negocio y/o normas gubernamentales se identifiquen con plenitud y se adecuen para su cumplimiento.

- Los productos generados se adhieran a los estándares de aseguramiento de la calidad definidos para el proyecto.

Con base en lo anterior el equipo responsable de la función de Aseguramiento del Proyecto debe cumplir con: - Asesorar e informar de manera permanente al equipo directivo y al equipo gerencial

acerca de la integridad técnica y funcional del proyecto. - Asistir o ayudar a otros miembros de la organización en la configuración y desarrollo

de otros proyectos. - Suministrar información oportuna a los interesados del proyecto – stakeholders acerca

de la evolución y estado actual del mismo, brindar un parte de confianza sobre su normalidad, así como, alertar y recomendar acciones de mejora ante posibles amenazas sobre el proyecto.

- Representar los intereses de los principales dolientes del proyecto, incluido el equipo directivo, en relación al cumplimiento de los requerimientos y expectativas definidas con respecto a los resultados del proyecto.

- Suministrar o facilitar el aseguramiento de la funcionalidad del proyecto. Es decir, validar si el producto final beneficiará satisfactoriamente las necesidades de la función de negocio que cubre el alcance del proyecto.

54

- Asesorar y supervisar cualquier ajuste o actualización del aspecto funcional del proyecto, así como, evaluar y confirmar su viabilidad frente a los cambios incorporados.

- Asesorar y monitorear el desempeño del Equipo de Gerencia y del Equipo de Trabajo en relación a la aplicación adecuada de estándares, códigos de actuación, herramientas y técnicas establecidos por la organización para el proyecto.

- Asegurar que los productos finales sigan durante su generación y cumplan en últimas los requerimientos y expectativas definidas sobre ellos.

B.4. Productos o entregables en el aseguramiento del proyecto

El desarrollo de todo proyecto genera dos tipos de entregables: los administrativos que apoyan las actividades del proyecto, por ejemplo: planes, documentos de requerimientos o informes de avance o de estado del proyecto; y los productos funcionales que buscan satisfacer las expectativas del usuario y son particulares a cada proyecto. En el desempeño del Equipo de Aseguramiento del Proyecto se generan solamente productos o entregables de naturaleza administrativa; específicamente informes que especifican la gestión realizada por el Equipo de AP y diagnostican acerca de la gestión del proyecto. Dichos informes pueden estar anexos a los presentados por el Equipo de Gerencia del Proyecto o pueden estar generados en un documento independiente. Los informes generados por el Equipo de Aseguramiento del Proyecto tienen tres aspectos principales a saber: - El objetivo de la participación del Equipo de AP en la etapa, proceso, actividad o

proyecto, según sea el alcance que se esté informando. - La gestión realizada por el Equipo AP. Es decir, qué acciones se adelantaron; qué

aspectos, positivos y negativos, fueron observados; qué acuerdos se lograron, en las asesorías o recomendaciones realizadas.

- El concepto o diagnóstico del Equipo de AP. Incluye una valoración a los informes de gestión generados por el Equipo de Gerencia del Proyecto, la cual puede abarcar informes de gestión de otros equipos de apoyo del proyecto. También incluye recomendaciones justificadas de aspectos no acordados y que deben ser evaluados y respondidos posteriormente por el Equipo Directivo del Proyecto. Adicionalmente debe existir un pronóstico de lo que se espera en las etapas futuras del proyecto en relación con las expectativas definidas sobre éste último.

El anexo A contiene una plantilla modelo para estructurar las informes del Equipo de Aseguramiento del Proyecto adjunto a los informes de gestión que genere el Equipo de Gerencia del Proyecto. La estructura de la plantilla sugerida se apoya en los siguientes aspectos: - Un informe o reporte de gestión del proyecto debe contener como mínimo dos partes:

la identificación o información básica del informe y el contenido del informe. - La identificación contiene información básica del proyecto que se reporta. Además

relaciona datos del informe como quien lo genera, dónde se almacena, qué versiones se han generado, quienes lo han aprobado y a quienes se ha distribuido.

55

- El contenido del informe contiene la gestión realizada del proyecto, la cual tiene un alcance y temas diferentes dependiendo del tipo de informe. Por ejemplo: Un informe de administración de riesgos, limita su contenido solo al tema de riesgos. Adicionalmente el contenido del informe puede comprender una parte para el informe de gestión del Equipo de Aseguramiento del Proyecto como se muestra en la figura a continuación.

Figura 13. Estructura para integrar informes de la función de AP.

C. Aplicación al caso de estudio Mediante un acuerdo de aprendizaje mutuo con el Banco de la República, se buscó aplicar el modelo de la función propuesta en un proyecto piloto, que cumpliera con apoyarse en la metodología de gerencia de proyectos informáticos de éste último y comprendiera el desarrollo de un software a la medida. Esta acción permitió observar el desempeño de la función AP propuesta en un proyecto real, evaluar sus beneficios e identificar posibles ajustes; así como, proporcionar al Banco la posibilidad de experimentar con una herramienta adicional que apoyara y facilitara la aplicación del proceso de gerencia de proyectos informáticos y ver sus beneficios.

56

C.2. Gestión realizada El modelo de la función de AP se aplicó cuando el proyecto ya estaba en marcha, por lo cual fue necesario precisar los siguientes aspectos: - Conocer el estado del proyecto, que comprendía identificar los planes y expectativas

sobre el proyecto; establecer el avance del mismo en cuanto a las etapas gestionadas y por realizar; los recursos involucrados y los posibles síntomas que permitieran deducir aspectos negativos y positivos.

- Identificar los estándares definidos por la organización dueña del proyecto para apoyar el proceso de gerencia de proyectos; lo cual incluyó conocer, además, la gestión realizada por el Banco en su calidad de asesor, previo a la implantación de la función de AP.

- Conocer y evaluar la metodología de gerencia de proyectos definida para el proyecto piloto con el fin de validar si contenía o hacía referencia a aspectos relacionados con las función de aseguramiento del proyecto.

Para poder obtener parte esta información se estructuraron tres tipos de cuestionarios, los cuales fueron diligenciados por integrantes del grupo directivo, del grupo de gerencia del proyecto y del grupo de trabajo. La información recolectada se validó con entrevistas selectivas y se complementó con lecturas a los estándares como la metodología de gerencia de proyectos, el plan de administración de riesgos y el plan de administración de la calidad, entre otros. Adicionalmente se adelantó una presentación del modelo de la función de AP a la entidad dueña del proyecto, específicamente, a los integrantes del grupo directivo y del grupo de gerencia del proyecto con el fin de capacitarlos en los aspectos básicos y validar las expectativas en torno a la función de AP. Como producto de las acciones iniciales realizadas se identificaron aspectos en el ambiente del proyecto, de los cuales se destacan los siguientes: - Las expectativas con respecto a la función de aseguramiento de proyecto no

coincidieron inicialmente con los beneficios que esta brinda. Esto obedeció en parte a que el proyecto presentaba atrasos en algunas actividades y existían tensiones entre el dueño del proyecto y el proveedor que hacían que las actividades y reuniones realizadas estuvieran marcadas por procesos de negociación apoyados en posiciones opuestas y conflictos aparentemente irreconciliables. Por ello, la mayoría de los integrantes del proyecto esperaban que la alternativa de la función de AP permitiese hacer una recuperación del proyecto en cuanto a tiempos y establecer responsabilidades por los resultados positivos y negativos en el proyecto.

- El conocimiento acerca del real estado del proyecto era parcializado y predominaban los supuestos sin confirmar. Por ejemplo: para el dueño del proyecto la responsabilidad del diseño, construcción e implantación del producto final era casi en su totalidad del proveedor. Por otro lado, éste último tenía definido un esquema incremental para entregar en dos etapas los módulos del software, mientras que el dueño del proyecto

57

pensaba que las dos etapas eran para la construcción del software y para conocer el producto final, hacer pruebas y validar su correcto funcionamiento.

- La metodología de gerencia de proyectos seleccionada se apoyaba en el modelo PMBOK2000; sin embargo, su conocimiento nivel de personalización con respecto al proyecto era limitado. Por ejemplo: aunque estaban identificados los integrantes del equipo directivo, del equipo de gerencia del proyecto y del equipo de trabajo; las responsabilidades, los tiempos de dedicación, los esquemas de las reuniones y las frecuencias de realización no estaba explícitamente definidas en la documentación de la metodología. Estos aspectos no eran claros para todos los involucrados en el proyecto y posibilitaban problemas de coordinación y conflictos. De igual manera sucedía con la aplicación de otros estándares como el de administración de riesgos y de calidad, puesto que eran interpretados y aplicados de diferentes maneras tanto por el dueño del proyecto como por el proveedor.

En consecuencia se acordó como primer paso conformar un grupo de trabajo para definir un plan de acción que permitiera configurar y aplicar la función de AP en el proyecto con el requisito de no afectar, en alto grado, el desarrollo normal de las actividades que ya se venían adelantando. El grupo fue conformado por empleados de la entidad dueña del proyecto y del Banco de la República que tenían conocimiento del proyecto y fundamentos teóricos en gerencia de proyectos. A continuación se relacionan los aspectos más relevantes definidos para el plan de acción:

- Se estableció como reto para el grupo responsable definir el plan de acción, así como manejar simultáneamente esta responsabilidad con aquellas asignadas previamente que ya venían desempeñando en el proyecto.

- Se definieron tres actividades para adelantar en forma paralela el desarrollo del proyecto. Una para estructurar y presentar, para aprobación, la propuesta de implantación; otra, que dependiendo del resultado de la anterior, consistía en aplicar la función según la propuesta aprobada; y la tercera, era observar resultados en el proyecto e identificar aquellos en los cuales había influenciado la función AP.

- Se establecieron condiciones o lineamientos a tener en cuenta en la configuración de la función con respecto al recurso humano y el proyecto, tales como: no incrementar el número de personas asignadas al proyecto; propender por segregar en personas diferentes la función de AP y la función de gerencia del proyecto; procurar ajustar o modificar lo menos posible los estándares, herramientas y procedimientos que se venían aplicando para disminuir el impacto en el proyecto; mejorar el clima organizacional dentro del proyecto, en especial aspectos relacionados con el flujo de la información y las comunicaciones, generación de evidencia en las decisiones, manejo de conflictos, entre otros.

Debido a que la duración del proyecto abarcaba un plazo mayor en relación con la disponibilidad de tiempo para verificar el desempeño y los resultados de la función de AP, se acordó hacer un monitoreo periódico al desarrollo del proyecto para determinar el efecto producido por la aplicación de la función de AP en los resultados intermedios generados. Como producto de ello se identificaron las siguientes mejoras:

58

- El clima de tensión reinante en el proyecto inicialmente era de dos grupos polarizados (cliente y proveedor) que buscaban más establecer culpabilidades en aspectos negativos del proyecto que en destacar los logros alcanzados. Con la aplicación se observó un acercamiento entre los dos grupos reflejado en la participación activa de sesiones de trabajo en equipo, evidenciadas en las reuniones de grupo de gerencia del proyecto y de grupo de trabajo.

- Se fomentó la necesidad de que los integrantes del proyecto conocieran, entendieran y aplicaran adecuadamente los estándares y procedimientos que apoyaban las funciones que cada uno tenía asignadas, para lo cual se fomentaron reuniones de trabajo en equipo del grupo de AP con los diferentes integrantes para precisar conceptos y aclarar dudas.

- Se definieron tres tipos de reuniones formales en el proyecto, las reuniones de grupo directivo, las de grupo de gerencia del proyecto y las de grupo de trabajo. Para cada una se estableció su periodicidad, los participantes, el moderador y relator, los tipos de temas y problemáticas a discutir en cada una y un esquema de memorias que permitiera conocer la historia de los aspectos tratados, acuerdos y decisiones tomadas en cada reunión.

- El grupo de AP, además de la función de asesoría que prestó a los integrantes del proyecto, generó un documento de lecciones aprendidas que contenía un descripción de los problemas más relevantes en el proyecto, complementada con las acciones tomadas y los efectos observados.

D. Conclusiones

Las conclusiones respecto de la utilidad que el modelo propuesto puede brindar a las organizaciones que tienen implementada una metodología de gerencia de proyectos informáticos, están expresadas en términos de las consideraciones a tener en cuenta en su aplicación y de los beneficios que puede brindar. Éstas se apoyan en los resultados positivos observados como consecuencia de la aplicación de la función de AP en un proyecto piloto y que permiten concluir a nivel general que es posible incrementar la certidumbre y las probabilidades de éxito en los proyectos de desarrollo de software a la medida; es decir, que se cumplan con los tiempos estimados, los costos presupuestados y, en especial, se satisfaga en alto grado las expectativas de los principales interesados – stakeholders. La propuesta se constituye en una herramienta de apoyo para los programas de gerencia de proyectos informáticos que tienen implementadas las organizaciones. Al igual de como sucede en los proyectos en general, no están definidos métodos formales que garanticen la efectividad de la función AP propuesta para mejorar la gerencia de los proyecto; sin embargo, la aplicación como caso de estudio en un proyecto real, de desarrollo de software a la medida, refleja que, por lo menos, es viable en una metodología de gerencia de proyectos y abre las puertas a la posibilidad de aplicarse con igual o mayor éxito en otros contextos o experiencias similares.

59

El modelo propuesto de la función de aseguramiento del proyecto no contempla dentro de su alcance la estructuración de nuevas etapas en el ciclo de vida de proyectos de desarrollo de sistemas de información a la medida. Esto obedece a que estándares como el modelo en cascada o el modelo en V están orientados a definir el mejor camino para generar el producto final, específicamente, el desarrollo de un software a la medida; en tanto que la función de AP se orienta más a crear o configurar la mejores condiciones de naturaleza administrativa para las construcción de dicho producto final. La implementación y aplicación del modelo de la función de AP, busca asegurar o incrementar las probabilidades para la terminación exitosa de los proyectos de desarrollo de software a la medida; sin embargo, su no aplicación dentro de un programa de gerencia de proyectos no implica concluir que los proyectos que se adelanten bajo estas condiciones no puedan ser exitosos. El aseguramiento del proyecto no trata exclusivamente del aseguramiento de la calidad de los productos de un proyecto; tampoco los rechaza. Más específicamente el aseguramiento del proyecto es un aseguramiento gradual o simultáneo de los componentes que hacen parte de la gerencia del proyecto, independiente de la forma como está estructurada y es aplicada por la organización. Algunos programas de Gerencia de Proyectos hacen referencia a oficinas de control o apoyo de proyectos que tienen a cargo la función de aseguramiento del proyecto. El modelo no tiene por finalidad la configuración y funcionamiento de un área de control de proyectos. La función de aseguramiento del proyecto no es viable en una organización cuando se aplica de forma independiente de un programa de gerencia de proyectos. Lo anterior, en razón a que su propia estructura se apoya en la estructura básica de la gerencia de proyectos y a que su razón de ser es evaluarla y apoyarla en su gestión. La responsabilidad de la función de aseguramiento del proyecto recae siempre en el grupo directivo del proyecto; aunque puede ser delegada con el fin de facilitar su aplicación efectiva. Sin embargo, esta acción de delegar la función no puede hacerse sobre los equipos de gerencia del proyecto ni de trabajo pues estaría posibilitando un conflicto de intereses al ser juez y parte en el reporte y evaluación de la gestión del proyecto. Surge hacia el futuro la necesidad de precisar, mediante la experiencia y el aporte de la investigación, distinciones y similitudes con otras funciones y actividades que apoyan o aportan a la gerencia de proyectos. Tal es el caso de la función de auditoría y la interventoría que coinciden con la finalidad general de aportar a la adecuada aplicación de la gerencia de proyectos, pero difieren en la forma como se aplican y en sus intereses particulares; pues la función de AP además de emitir conceptos y certificar la gestión del proyecto, asesora y si es necesario trabaja hombro a hombro con los integrantes del proyecto en busca de interpretar y aplicar estándares y herramientas que beneficien de la mejor forma posible al proyecto en particular.

60

La propuesta no tiene dentro de sus principales intereses generar un nivel adicional en la jerarquía de la estructura organizacional de un proyecto; más precisamente, se busca posibilitar un nuevo punto de vista del proyecto para apoyar el proceso de toma de decisiones y, en tal sentido, la conformación de un grupo exclusivo para aplicar esta función dependerá de diferentes factores, tales como: el tamaño del proyecto, los lineamientos y procedimientos que cubran al proyecto y el manejo de recurso humano dentro de la organización. No es suficiente confiar o creer que los estándares y procedimientos se están cumpliendo; tampoco lo es, asegurar o garantizar que el proyecto está bien configurado y justificado. Se necesita que aspectos como los riesgos, la calidad, los cambios, la gestión o los estándares aplicados sean revisados y validados a lo largo del proyecto como parte del cumplimiento de la función de aseguramiento. Esto, para determinar aquello que permanece consistente y que sigue cumpliendo los requerimientos funcionales iniciales, así como, que ningún cambio en el entorno donde se desarrolla el proyecto lo afecte en su integridad y viabilidad.

61

VI. BIBLIOGRAFÍA 1. Meredith, J. & Mantel, S., Project Management, a managerial approach. Cuarta

edición. John Wiley & Sons, 1989 2. King, W. R. & Cleland D., Manual para la administración de proyectos. CECSA.

1999 3. Project Management Institute – PMI, A guide to the project management body of

knowledge. PMBOK2000 Guide, edition 2000 4. Senn, J. A., Análisis y diseño de sistemas de información. Segunda edición. Mc Graw

Hill, 1991 5. McConnell, S., Desarrollo y gestión de proyectos informáticos. Mc Graw Hill, 1996 6. Cuevas, O., Guía para la contratación de servicios informáticos. Asociación

Colombiana de Ingenieros de Sistemas – ACIS, 1996 7. Ruiz, S., Gerencia de proyectos. Instituto Centroamericano de Administración Pública

– ICAP, Costa Rica, 1988 8. Marsh, D., The project assurance function – Companion. PRINCE2. Londrés, 1998. 9. Kerzner, H., Project Management, a systems approach to planning, schedulling and

controlling. Séptima edición. John Wiley & Sons, 2000 10. Subgerencia de Informática – Banco de la República, Cartilla de Dirección Estratégica.

Abril, 2001 11. Forsberg, K., Visualizing Project Management: A model for business and technical

success. Segunda edición. John Wiley & Sons, 2000 12. Kendall, K. & Kendall, J., Análisis y diseño de sistemas. Tercera edición. Prentice

Hall Hispanoamericana, 1997 13. Rodríguez, G., El apagón de 1992 y el escándalo del Guavio. Editorial Oveja Negra,

Octubre de 1992 14. Kirsch, L.J., Software Project Management: an integrated perspective for an emerging

paradigm” Zmud R.W. & Price, M.F. eds. Pinnaflex Educational Resources, Cincinnati, OH, 2000.

15. CCTA, Managing successful projects with PRINCE2. Electronic Manual.

www.ogc.gov.ok, septiembre de 2002.

62

16. www.soc.ston.ac.uk/ITG/PRINCE, agosto de 2002

a. Project Management Overview b. Project Management Initiation Guide c. Project Management Standard Job Descriptions

63

INFORMACIÓN BÁSICA Organización: Nombre del proyecto: Área(s) dueña(s):

DATOS DEL DOCUMENTO Nombre del archivo: Ubicación: Autor (es): Dueño (s): Cliente (s):

HISTORIA DEL DOCUMENTO

Versiones generadas Número de

versión Fecha de

modificación Resumen de cambios realizados Autor

Aprobaciones

Nombre Firma Cargo Fecha de aprobación

Número de versión

Distribuciones del documento

Nombre Cargo Fecha de distribución

Número de versión

CONTENIDO DEL DOCUMENTO O PLANTILLA

64

EJEMPLO DEL CONTENIDO DE UN DOCUMENTO

REPORTE DE TERMINACIÓN DE ETAPA

NOMBRE DE LA ETAPA: ______________________________________________

RESUMEN: Resume que tan bien se desempeñó el proyecto en la etapa que termina, en comparación con el plan de inicio de la etapa.

CONTENIDO:

Item Descripción PáginaObjetivos de la Etapa Estado previo Gestión realizada Perspectivas Concepto de AP

Objetivos de la Etapa: Estado previo: Condiciones generales del proyecto previo al inicio de la etapa que se está cerrando. Un insumo para redactar este estado previo es la gestión realizada y las expectativas, contenidas en el mismo reporte pero de la etapa inmediatamente anterior. Gestión realizada: Acciones y logros alcanzados en la etapa que se está cerrando. Cambios realizados; productos generados; recuperaciones, problemas presentados y gestionados, (retrasos y sobrecostos) Perspectivas Aspectos pendientes y acciones planeadas para la siguiente etapa. Supuestos, restricciones, riesgos y problemas potenciales a tratar, compromisos para cumplir en las etapas posteriores Concepto Grupo Aseguramiento del Proyecto: Objetivo de la participación en la Etapa: Gestión realizada por AP: Acciones adelantadas. Aspectos observados. Acuerdos generados. Resultados de seguimientos. Concepto de AP: Valoración del informe de gestión del proyecto presentado. Recomendaciones y justificaciones. Pronóstico o expectativas. Conclusiones para el grupo directivo.