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

Texto completo

(1)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.

(2) 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..

(3) ÍNDICE. I.. INTRODUCCIÓN A. B. C. D.. II.. Resumen Objetivo general Objetivos específicos 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 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. B. C. D. E.. Antecedentes Definición de Gerencia de Proyectos Razones para la Gerencia de Proyectos Elementos básicos en la Gerencia de Proyectos La Gerencia de Proyectos según el PMI.

(4) 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.

(5) 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.. 1.

(6) 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.. 2.

(7) -. 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. 3.

(8) 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.. 4.

(9) 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 Transmilenio 3. 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. 5.

(10) -. 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. 6.

(11) menor escala o alcance, los cuales están interrelacionados y cuyos objetivos y actividades están alineados con el objetivo principal del programa [1]. En el campo militar, programa ha sido utilizado para referirse a algo excepcionalmente grande, equivalente a proyectos de. 7.

(12) 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 un proyecto consiste en:. 8.

(13) 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 9.

(14) 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 10.

(15) 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 11.

(16) 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. 6. Conjunto 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.. 12.

(17) 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).. 13.

(18) 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. 14.

(19) 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.. 15.

(20) 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. 16.

(21) 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.. 17.

(22) 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 18.

(23) 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.. 19.

(24) 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. 20.

(25) 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.. 21.

(26) 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.. 22.

(27) 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.. 23.

(28) -. -. -. 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. 24.

(29) 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.. 25.

(30) 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 26.

(31) 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. 27.