UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI)

Transcripción

1 UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI) PROPUESTA DE ESTANDARIZACION DE PROCESOS EN LA UNIDAD DE TECNOLOGIAS DE INFORMACION DE LA OFICINA DE ADMINISTRACION FINANCIERA DE LA UNIVERSIDAD DE COSTA RICA JOSE ABEL BARBOZA VILLALTA PROYECTO FINAL DE GRADUACION PRESENTADO COMO REQUISITO PARCIAL PARA OPTAR POR EL TITULO DE MASTER EN ADMINISTRACION DE PROYECTOS. San José, Costa Rica Mayo, 2006

2 ii Índice de contenido Resumen Ejecutivo...viii Capítulo 1. Introducción Antecedentes de la UTI Problemática u oportunidad de desarrollo de trabajo Justificación del proyecto: Objetivo general: Objetivos específicos:...4 Capítulo 2. Marco teórico Antecedentes Misión de la Oficina de Administración Financiera Visión de la organización Administración de proyectos según la guía del PMBoK Proyectos y planificación estratégica Dirección de proyectos Ciclo de Vida del proyecto Características del ciclo de vida del proyecto Aspectos generales de la Administración de proyectos Áreas del conocimiento de la Dirección de proyectos según la guía del PMBoK Gestión de la Integración del Proyecto Gestión del Alcance del Proyecto Gestión del Tiempo del Proyecto Gestión de los Costes del Proyecto Gestión de la Calidad del Proyecto Gestión de los Recursos Humanos del Proyecto Gestión de las Comunicaciones del Proyecto...20

3 iii 2.9.8Gestión de los Riesgos del Proyecto Gestión de las Adquisiciones del Proyecto Grupo de procesos en la dirección de proyectos Niveles de madurez en Administración de Proyectos...27 Capitulo 3 Marco Metodológico Procedimiento Metodológico Definición de actividades Inventario y análisis de metodologías y estándares existentes relacionados con Administración de Proyectos Capítulo 4 Propuesta para la estandarización Hallazgos Desarrollo de la propuesta Propuesta para la Administración del Tiempo Definir el alcance del proyecto Creación de la estructura detallada de trabajo (EDT) Secuenciación de actividades Estimación de las duraciones: Juicio de expertos Estimación por analogía Estimación paramétrica Estimaciones por tres valores Análisis de reserva Desarrollo de cronograma Cronograma del Proyecto Control del cronograma Informe del Avance Sistema de Control de Cambios del Cronograma Software de Gestión de Proyectos... 64

4 iv Diagramas de Barras Comparativos del Cronograma Buenas prácticas en la administración del tiempo: Propuesta para la administración de las comunicaciones Planificación de las comunicaciones Propuesta para la administración de la calidad Planificación de la calidad Plan de gestión de calidad Métricas de Calidad Listas de Control de Calidad Plan de Mejoras del Proceso Línea Base de Calidad Plan de Gestión del Proyecto Aseguramiento de la calidad Implementación de la propuesta...87 Capítulo 5. Conclusiones...89 Capítulo 6 Recomendaciones...91 Capítulo 7 Bibliografía Capítulo 8 Anexos...97

5 v Índice de Figuras Figura 1: Estructura organizativa de la Oficina de Administración Financiera (OAF) de la Universidad de Costa Rica (UCR). (OAF, 2001)...7 Figura 2: Áreas de experiencia que ocupa el equipo de Dirección de proyectos. (PMI, 2004) Figura 3 Fases del ciclo de vida de un proyecto. (PMI, 2004)...14 Figura 4: Influencia de los interesados a lo largo del tiempo. (PMI, 2004) Figura 5: Secuencia de fases típicas de un proyecto (PMI, 2004) Figura 6: Áreas del conocimiento, de la dirección de proyectos (PMI, 2004) Figura 7: Vínculos entre los grupos de procesos del proyecto o de una fase (PMI, 2004) Figura 8: Correspondencia de los grupos de procesos y las áreas de conocimiento del PMBoK...27 Figura 9: Planeación básica estratégica (Kerzner, 2001) Figura 10: Los cinco niveles del Modelo de madurez (Kerzner, 2001).30 Figura 11: EDT descomposición del primer nivel, entregables en segundo nivel. (PMI, 2004)...51 Figura 12: Ejemplo del método de diagramación por precedencia (PDM) en el que se reflejan 12 actividades lógicas y 2 ficticias. (PMI, 2004)...53 Figura 13: Cronograma detallado con relaciones graficas de un proyecto (PMI, 2004)...60

6 vi Índice de Plantillas Plantilla 1: Declaración del alcance del proyecto Plantilla 2: Charter del proyecto Plantilla 3: Descripción de los paquetes de trabajo...50 Plantilla 4: Plantilla para la descripción de cada actividad de la estructura detallada de trabajo Plantilla 5: Plantilla para informe de avance del proyecto y el estado actual Plantilla 6: Plantilla para el control de cambios en el alcance del proyecto Plantilla 7: Plantilla de responsabilidades dentro del proyecto Plantilla 8: Plantilla de comunicación interna del proyecto Plantilla 9: Estado de las acciones consignadas del proyecto Plantilla 10: Plantilla de convocatoria a reunión del proyecto Plantilla 11: Plantilla de minuta de reunión del proyecto Plantilla 12: Plantilla de lista de verificación de criterios de calidad de un proyecto Plantilla 13: Plantilla de identificación de riesgos del proyecto Plantilla 14: Plantilla de evaluación de riesgos o plan de manejo del riesgo del proyecto... 87

7 vii UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI) Este Proyecto Final de Graduación fue aprobado por la Universidad como Requisito parcial para optar al grado de Master en Administración de Proyectos MBA Luis Diego Villalobos Yock Director del Proyecto M.Sc. Miguel Vallejo S Director del Programa MAP Ing. José Abel Barboza Villalta Sustentante

8 viii Resumen Ejecutivo La Universidad de Costa Rica (UCR) es una de las cuatro Universidades estatales del país y esta dividida en cinco grandes áreas sustantivas Investigación, Docencia, Vida Estudiantil, Acción Social y Administración. Esta última área se compone de diferentes oficinas, dentro de ellas esta la Oficina de Administración Financiera (OAF) la cual contempla a la Unidad de Tecnologías de la Información (UTI). Tanto en la UTI como en toda la OAF, la relación actual del trabajo diario con la práctica de administración de proyectos, es escasa ya que nunca se han seguido metodologías de gestión de proyectos, ni se cuenta con estándares de esta disciplina. Los estimados de las duraciones de los proyectos tienden a ser poco realistas ya que no se dispone de datos históricos que permitan tener una buena idea de los tiempos de las actividades. Asimismo no existe un procedimiento científico de estimación de las duraciones. Para los proyectos de sistemas desarrollados internamente se llevan cronogramas de trabajo, sin embargo cuesta conocer el estado real de cada proyecto en un momento determinado. El desarrollo de la gestión de proyectos en la UTI se ha realizado de una forma tradicional sin ningún estándar, ni metodología de trabajo, por lo que en algunos casos los proyectos son realizados con desfases en los tiempos de entrega con problemas en la calidad de entrega. Esto por la falta de establecimiento de límites para los proveedores o para la misma oficina. Cabe destacar que esta falta de estándares no significa que el proyecto no sea exitoso, sin embargo el equilibrio entre calidad tiempo costo no es el óptimo. Por ello este trabajo trata de plantear una metodología de desarrollo de proyectos para poder estandarizar los mismos y mejorar los resultados de los proyectos. Así mismo se desea realizar un diagnóstico de evaluación para determinar el conocimiento general de la OAF en administración de proyectos, basado en el modelo de madurez de Kerzner, y a su vez se pretende dictar un estándar para documentar las lecciones aprendidas de los proyectos, con el fin de que esta información sirva de base para futuros proyectos de igual lineamiento. Con estos objetivos el trabajo deberá de brindar a la OAF y específicamente a la UTI una guía metodológica de procesos y estándares, para garantizar que la

9 ix gestión de proyectos de todos los sistemas automatizados cumple con los estándares establecidos en el presente trabajo, y de esta forma poder garantizar el éxito de los mismos. Este trabajo servirá como guía para dirigir y administrar los proyectos que se llevan en la OAF, así como en otras oficinas en las cuales la OAF tiene relación, así mismo este trabajo servirá para poder empezar a crear la cultura de proyectos que tanto se necesita en la OAF.

10

11 1 Capítulo 1. Introducción La Universidad de Costa Rica (UCR) es una de las cuatro Universidades estatales del país y esta dividida en cinco grandes áreas sustantivas (cada una dirigida por un Vicerrector): Investigación, Docencia, Vida Estudiantil, Acción Social y Administración. Esta última área se compone de diferentes oficinas a saber: Oficina de Servicios Generales (OSG), Oficina de Suministros (OSUM), Oficina de Recursos Humanos (ORH) y Oficina de Administración Financiera (OAF) la cual contempla a la Unidad de Tecnologías de la Información (UTI). 1.1 Antecedentes de la UTI. Actualmente la UTI está destinada al mantenimiento y soporte de la infraestructura informática de la OAF, es ahí donde destaca el Sistema de Información de Administración Financiera (SIAF) uno de los sistemas institucionales más completos con que cuenta la institución. El sistema está desarrollado en una base de datos Oracle, la cual almacena aproximadamente 275 tablas que se encuentran ubicadas en varios servidores de alto rendimiento que corren sobre el sistema Operativo Unix, específicamente en equipos de la marca SUN y sistema operativo Solaris. La aplicación general del sistema está desarrollado en Oracle, en arquitectura cliente/servidor en la herramienta de desarrollo de Oracle, Developer Suite. En la actualidad se están implementando los módulos desarrollados en Internet Aplication Server, estos no son cliente servidor, sino que se desarrollaron en el esquema de n-capas. El SIAF se ha desarrollado por módulos desde el año 1997 cuando se inició con el módulo de Contabilidad. Paralelamente en 1998 se desarrolló el

12 2 módulo de Presupuesto, el cual también se desarrolló y se implementó por una empresa externa a la Universidad, esta implantación del sistema se realizó a finales del año Posterior a esto el sistema fue entregado a la OAF, la cual a través de la UTI, ha tenido a cargo el mantenimiento y desarrollo de los nuevos requerimientos así como ajustes y cambios en el mismo. En la actualidad se están desarrollando el módulo de Tesorería, el cual está integrado por submódulos como son Cuentas por Cobrar (CxC) y Cuentas por Pagar (CxP), Cobros Estudiantiles, Facturación, Inversiones, Custodia de Documentos, Auditoria, así como la actualización y modificación de los submódulos de Bancos y Conciliaciones que pertenecen al módulo de Contabilidad. Por otra parte se está desarrollando el submódulo de la unidad de Activos Fijos y Seguros el cual es parte del Módulo de Contabilidad. La UTI cuenta en la actualidad con dos funcionarios de planta y uno del Centro de Informática (CI) de la Universidad, destacado al apoyo de los sistemas. Además se utiliza la modalidad de contratación de empresas por medio de outsourcing, las cuales son coordinadas desde la Jefatura de la UTI. 1.2 Problemática u oportunidad de desarrollo de trabajo La relación actual del trabajo diario con la práctica de administración de proyectos es escasa ya que nunca se han seguido metodologías de gestión de proyectos ni se cuenta con estándares de esta disciplina.

13 3 Los datos históricos sobre la duración de los proyectos tienden a ser poco realistas ya que no se dispone de datos que permitan tener una buena idea de los tiempos de las actividades. Asimismo, no existe un procedimiento científico de estimación de las duraciones. Para los proyectos de sistemas desarrollados internamente, se llevan cronogramas de trabajo, sin embargo éstos no son elaborados ni controlados con la rigurosidad debida. Esto dificulta conocer el estado real de cada proyecto en un momento determinado. Al ejecutar proyectos por outsourcing, las empresas externas aportan cronogramas que no son estudiados ni cuestionados. Esto causa que en repetidas ocasiones los proyectos se retrasen con respecto al cronograma presentado o no lleguen a buen término. Esto se debe principalmente a algunos factores: La falta de información histórica de otros proyectos ejecutados anteriormente bajo este mismo esquema. Ausencia de personal capacitado que ejerza mecanismos de control en el proceso de contratación y definición de estándares para proyectos de outsourcing. Ausencia de documentos guías, que se puedan utilizar para verificar las entregas y la calidad de las mismas. 1.3 Justificación del proyecto: La gestión de proyectos en la UTI se ha realizado de una forma tradicional, sin ningún estándar, ni metodología de trabajo, por lo que en algunos casos los proyectos se completan con desfases en los tiempos de entrega y con problemas en la calidad. Esto, debido a la falta de seguimiento al proyecto

14 4 con los mismos proveedores o en la misma oficina. Cabe destacar que esta falta de estándares no significa que el proyecto no sea exitoso, sin embargo el equilibrio entre calidad tiempo costo no es el óptimo. Debido a esto se presenta la necesidad de plantear una metodología de desarrollo de proyectos, para poder estandarizar los mismos y mejorar los resultados, que hasta ahora se han tenido. 1.4 Objetivo general: Elaborar una propuesta para estandarizar los procesos de los proyectos de la Unidad de Tecnologías de Información según el PMI. 1.5 Objetivos específicos: Realizar un diagnóstico de evaluación para determinar el conocimiento general del personal de la OAF en administración de proyectos. Desarrollar la propuesta de estandarización en las áreas de calidad, tiempo y comunicaciones. Diseñar un estándar para documentar las lecciones aprendidas durante el desarrollo de los proyectos. Limitaciones: Una de las grandes limitaciones de este proyecto es poder crear una cultura de proyectos en una área, en la que la necesidad de administrar por proyectos no es algo viable.

15 5 Apoyo de los niveles estratégicos de la organización para poder recolectar y recopilar la información necesaria para un buen resultado del proyecto. No se comprara ni hardware ni software adicionales a los que tiene la unidad de Tecnologías de Información de la OAF. No se va a modificar la estructura de la organización con que cuenta la Unidad de Tecnologías de Información de la OAF.

16 6 Capítulo 2. Marco teórico 2.1 Antecedentes En el año 1940 se estableció la Unidad de Contabilidad dentro de la Universidad de Costa Rica. Esta tenía como principal función llevar la contabilidad de la institución y era vista como la oficina mecanizada de la UCR. Posteriormente, en 1956, el señor Rector cambió la función de la oficina y le asignó funciones adicionales a la contabilidad como son el control y ejecución del presupuesto universitario. Ya en el año 1974, el Consejo Universitario que es el órgano rector de la UCR, decretó el cambio de Unidad de Contabilidad y la nombró como la Oficina de Administración Financiera (OAF). Está oficina está subdividida en cuatro secciones: Contabilidad, Presupuesto, Tesorería y Administración. Las funciones de estas secciones están distribuidas por unidades; a saber la Sección de Contabilidad cuenta con la Unidad de Archivo, la Unidad de Activos Fijos y Seguros y la Unidad de Contabilidad. Por su parte la Sección de Presupuesto cuenta con la Unidad de Presupuesto Ordinario y la Unidad de Vínculo Externo. Por otro lado la Sección de Tesorería cuenta con la Unidad de Pagos, Unidad de Cajas, Unidad de Cobros Estudiantiles y la Unidad de Control de Ingresos. Hay que destacar que en la Sección Administrativa se encuentran el Director de la Oficina y su asistente ejecutivo, así como las Unidades de Control Interno, y la Unidad de Tecnologías de la Información (UTI), y la Unidad Administrativa.

17 7 La Unidad de Tecnologías de Información (UTI) opera como staff dentro de la organización de la Oficina de Administración Financiera, es decir, es un recurso compartido. Para una mejor visualización de la ubicación de esta unidad, se presenta el siguiente organigrama. (Ver figura No 1). Dirección Oficina de Administración Financiera Unidad de Tecnologías de la Información Unidad de Control Interno Unidad Administrativa Asistente de la dirección Sección de Contabilidad Sección de Presupuesto Sección de Tesorería Unidad de Archivo Presupuesto Ordinario Cuentas por pagar Unidad de Contabilidad Vinculo externo Cajas Unidad de Activos Fijos Cobros estudiantiles Control de Ingresos Figura 1: Estructura organizativa de la Oficina de Administración Financiera (OAF) de la Universidad de Costa Rica (UCR). (OAF, 2001) Una vez contextualizada la UTI se presenta la misión y la visión de la Oficina de Administración Financiera, ya que todas las unidades que la componen

18 8 (incluyendo la Unidad en donde se desarrolla la presente investigación) deben estar orientadas al alcance de las mismas. 2.2 Misión de la Oficina de Administración Financiera Brindar a estudiantes, profesores, administrativos y usuarios externos de la Universidad, servicios eficientes, oportunos y de calidad, desarrollando y aprovechando de la mejor manera el talento humano del que dispone. (OAF, 2001) 2.3 Visión de la organización Ser una oficina líder, que informa y orienta a la comunidad universitaria sobre los servicios que brinda, promoviendo a la vez un adecuado uso de los recursos financieros de la Institución. Esto mediante una plataforma tecnológica integrada, el conocimiento humano y clima organizacional positivo que permitan ofrecer servicios de calidad. (OAF, 2001) 2.4 Administración de proyectos según la guía del PMBoK Un proyecto es una tarea temporal desarrollada para crear un producto, servicio o resultado único. El término temporal significa que cada proyecto tiene un comienzo definido y un final definido, mientras que el término único indica que el producto o servicio es diferente, de alguna manera distintiva, de otros proyectos o servicios similares.

19 9 Debido a que los proyectos son tareas únicas, involucran cierto nivel de incertidumbre. Las organizaciones ejecutoras de proyectos generalmente dividirán cada proyecto en fases del proyecto, para poder administrar mejor los enlaces apropiados con las operaciones de la organización ejecutora (PMI, 2004). Es importante mencionar que las organizaciones ejecutoras de proyectos deben conocer bien las habilidades de cada uno de sus miembros así como tener conocimiento sobre normas, leyes y regulaciones en el campo donde se ejecutan los proyectos, se debe conocer el ambiente de trabajo donde se desarrollan los proyectos, sus fortalezas, debilidades así como las amenazas y oportunidades de este entorno de trabajo. Con estos aspectos se puede decir que el proyecto tiene además, que tener una guía o metodología de dirección de proyectos como se nota en la figura No2. (PMI, 2004)

20 10 Figura 2: Áreas de experiencia que ocupa el equipo de Dirección de proyectos. (PMI, 2004) Un proyecto crea productos, servicios o resultados entregables únicos. Los proyectos pueden crear (Gido y Clements, 2003): Un producto o artículo producido, que es cuantificable, y que puede ser un elemento terminado o un componente La capacidad de prestar un servicio como, por ejemplo, las funciones del negocio que respaldan la producción o la distribución Un resultado como, por ejemplo, salidas o documentos. La singularidad es una característica importante de los productos entregables de un proyecto. Por ejemplo, se han construido muchos miles de edificios de oficinas, pero cada edificio individual es único: diferente propietario, diferente diseño, diferente ubicación, diferente contratista, etc. La presencia de elementos repetitivos no cambia la condición fundamental de único del trabajo de un proyecto. Los proyectos se llevan a cabo en todos los niveles de la organización y pueden involucrar a una sola persona o a varios miles. Pueden durar entre unas pocas semanas y varios años. Los proyectos pueden incluir una o varias unidades organizativas (PMI, 2004) 2.5 Proyectos y planificación estratégica Los proyectos son una forma de organizar actividades que no pueden ser tratadas dentro de los límites operativos normales de la organización, estos se usan a menudo como un medio de lograr el plan estratégico de la organización, ya sea empleando el equipo del proyecto de la organización,

21 11 llamando también insourcing o por medio de un proveedor de servicios contratado, lo que llamamos comúnmente outsourcing. (PMI, 2004)

22 Dirección de proyectos La dirección de proyectos es la aplicación de conocimientos, habilidades, herramientas y técnicas a las actividades de un proyecto para satisfacer los requisitos del proyecto. La dirección de proyectos se logra mediante la aplicación e integración de los procesos de dirección de proyectos de inicio, planificación, ejecución, seguimiento, control, y cierre. El director del proyecto es la persona responsable de alcanzar los objetivos del proyecto. (PMI, 2004) La dirección de un proyecto incluye: Identificar los requisitos Establecer unos objetivos claros y posibles de realizar Mantener el equilibro de las demandas concurrentes de calidad, alcance, tiempo y costes Adaptar las especificaciones, los planes y el enfoque a las diversas inquietudes y expectativas de los diferentes interesados, y sobre todo de acorde a los lineamientos de la organización. La relación entre los factores alcance, tiempos y costes del proyecto es tal que si cambia cualquiera de ellos, se ve afectado por lo menos otro de los factores. Los directores de proyectos también gestionan los proyectos en respuesta a la incertidumbre. El riesgo de un proyecto es un evento o condición inciertos que, si ocurre, tiene un efecto positivo o negativo al menos en uno de los objetivos de dicho proyecto. (PMI, 2004)

23 13 El equipo de dirección del proyecto tiene una responsabilidad profesional ante sus interesados, incluidos los clientes, la organización ejecutante y el público. Es importante destacar que muchos de los procesos incluidos en la dirección de proyectos son repetitivos debido a la existencia o a la necesidad de elaborar gradualmente el proyecto durante el ciclo de vida del mismo. Esto significa que, a medida que un equipo de dirección del proyecto conoce más en profundidad un proyecto, el equipo puede luego dirigirlo con un mayor nivel de detalle. (PMI, 2004) El término dirección de proyectos se usa a veces para describir un enfoque de la organización o de dirección respecto a la gestión de los proyectos y de algunas operaciones continuas, que pueden ser redefinidas como proyectos, que también se denomina dirección por proyectos. (PMI, 2004) 2.7 Ciclo de Vida del proyecto Para facilitar la gestión, los directores de proyectos o la organización pueden dividir los proyectos en fases, con los enlaces correspondientes a las operaciones de la organización ejecutante. El conjunto de estas fases se conoce como ciclo de vida del proyecto. Muchas organizaciones identifican un conjunto de ciclos de vida específico para usarlo en todos sus proyectos (PMI, 2004). Los proyectos nacen cuando una necesidad es descubierta por el cliente, es decir, las personas o la empresa dispuesta a aportar los fondos para que sea atendida. Lo primero que hay que hacer es identificar la necesidad o el problema, algunas veces son obvias; sin embargo, algunas otras se tarda meses, en recopilar la información (Gido y Clements, 2003).

24 Características del ciclo de vida del proyecto El ciclo de vida del proyecto define las fases que conectan el inicio de un proyecto con su fin, ver figura No. 3. Figura 3 Fases del ciclo de vida de un proyecto. (PMI, 2004) La transición de una fase a otra dentro del ciclo de vida de un proyecto generalmente implica y por lo general, está definida por alguna forma de transferencia técnica. Generalmente, los productos entregables de una fase se revisan para verificar si están completos, si son exactos y se aprueban antes de iniciar el trabajo de la siguiente fase. No obstante, no es inusual que una fase comience antes de la aprobación de los productos entregables de la fase previa, cuando los riesgos involucrados se consideran aceptables (PMI, 2004). La mayoría de los ciclos de vida de proyectos comparten determinadas características comunes:

25 15 En términos generales, las fases son secuenciales y, normalmente, están definidas por alguna forma de transferencia de información técnica o transferencia de componentes técnicos. El nivel de costo y de personal es bajo al comienzo, alcanza su nivel máximo en las fases intermedias y cae rápidamente cuando el proyecto se aproxima a su conclusión. Se dice que normalmente los ciclos de vida de un proyecto se dividen en cuatro fases, a saber: (Gido y Clements, 2003) Identificar una necesidad: En esta fase se identifica o se descubre la necesidad, problema o una oportunidad, es aquí donde el cliente suele anotar la necesidad y los requisitos en un documento llamado Solicitud de Propuesta. Desarrollar una propuesta: Es aquí donde se trata de dar una posible solución a la necesidad o problema del cliente. En algunos casos al cliente se le presenta una propuesta la cual reúne todos y cada uno de los puntos a seguir para poder dar solución al problema o necesidad. Realizar el proyecto: Es en esta fase donde se implementa o se pone en práctica la solución propuesta. Esta fase es conocida también como ejecución del proyecto, se planea detalladamente el proyecto y luego se implementa para conseguir su objetivo. Terminar el proyecto: Esta fase es donde una vez hecho el proyecto, se efectúan algunas actividades de cierre como confirmar que se haya realizado todo lo solicitado y que el cliente lo haya aceptado, que se haya cobrado todo y que se hayan pagado las facturas. Un aspecto importante es evaluar la ejecución del proyecto a fin de averiguar qué podría mejorarse si otro proyecto similar se llevará a cabo en el futuro. Este tipo de información es lo

26 16 que comúnmente se llaman las lecciones aprendidas, y es de suma importancia que estén documentadas para poder crear un banco de datos de lecciones aprendidas para que sean utilizadas en proyectos futuros. 2.8 Aspectos generales de la Administración de proyectos El esfuerzo principal en la administración de un proyecto tiene que estar centrado en establecer un plan de línea base, que proporcione un plan de ruta para indicar cómo se logrará el alcance del proyecto a tiempo dentro del presupuesto. Este esfuerzo de planeación incluye los siguientes pasos. Definir con claridad los objetivos del proyecto: La definición tiene que ser aceptada por el cliente y la persona u organización que realizará el proyecto. Dividir y subdividir el alcance del proyecto en piezas importantes o paquetes de trabajo. Aunque los proyectos trascendentes quizás parezcan abrumadores cuando se contemplan como un conjunto, una forma de resolverlos es dividirlos en partes. Una estructura detallada del trabajo (EDT) es un árbol jerárquico de elementos o partidas de trabajo logradas o producidas por el equipo de proyecto, comúnmente llamados paquetes de trabajo. Definir las actividades específicas que son necesarias para realizar cada paquete de trabajo con el fin de lograr el objetivo del proyecto. Presentar gráficamente las actividades bajo la forma de un diagrama de red, el cual muestra el orden necesario y las interdependencias de las actividades. Hacer un estimado de tiempo de la duración que tendrá que completar cada actividad. También es necesario identificar qué tipos de recursos y cuánto de cada recurso se necesita para terminar la actividad.

27 17 Hacer un estimado de costos para cada actividad. Calcular el programa y el presupuesto de un proyecto, para determinar si el mismo se puede terminar dentro del tiempo requerido, con los fondos asignados y con los recursos disponibles. Si no es así se deben hacer ajustes al alcance del proyecto, a los tiempos estimados de las actividades o a las asignaciones de recursos hasta que se pueda establecer un plan de línea base (Gido y Clements, 2003). El nivel de incertidumbre en un proyecto, es el más alto y por lo tanto, el riesgo de no cumplir con los objetivos es más elevado al inicio del proyecto. La certeza de terminar con éxito aumenta gradualmente a medida que avanza el proyecto (PMI, 2004). El poder que tienen los interesados en el proyecto para influir en las características finales del producto del proyecto y en el costo final del proyecto es más alto al comienzo y decrece gradualmente a medida que avanza el proyecto. La figura No 4 ilustra este hecho. Una de las principales causas de este fenómeno es que el costo de los cambios y de la corrección de errores generalmente aumenta a medida que avanza el proyecto. (PMI, 2004)

28 18 Figura 4: Influencia de los interesados a lo largo del tiempo. (PMI, 2004) Aún cuando muchos ciclos de vida de proyectos tienen nombres de fases similares y requieren productos entregables similares, pocos ciclos de vida son idénticos. Como se puede observar en la figura No.5. Algunos tienen cuatro o cinco fases, pero otros pueden tener nueve o más. En una misma área de aplicación pueden darse variaciones significativas. El ciclo de vida del desarrollo de software de una organización puede tener una única fase de diseño, mientras que otro puede tener fases separadas para el diseño arquitectónico y el detallado. Los subproyectos también pueden tener distintos ciclos de vida de proyectos. (PMI, 2004)

29 19 Figura 5: Secuencia de fases típicas de un proyecto (PMI, 2004) 2.9 Áreas del conocimiento de la Dirección de proyectos según la guía del PMBoK Gestión de la Integración del Proyecto Describe los procesos y actividades que forman parte de los diversos elementos de la dirección de proyectos, que se identifican, definen, combinan, unen y coordinan dentro de los grupos de procesos de dirección de proyectos. (PMI, 2004) Gestión del Alcance del Proyecto Describe los procesos necesarios para asegurarse de que el proyecto incluye todo el trabajo requerido, para completar el proyecto satisfactoriamente. (PMI, 2004)

30 Gestión del Tiempo del Proyecto Describe los procesos relativos a la puntualidad en la conclusión del proyecto. Se compone de los procesos de dirección de proyectos definición, establecimiento de la secuencia, estimación de recursos, estimación de la duración, desarrollo del cronograma y control del cronograma de cada una de las actividades. (PMI, 2004) Gestión de los Costes del Proyecto Describe los procesos involucrados en la planificación, estimación, presupuesto y control de costos de forma que el proyecto se complete dentro del presupuesto aprobado. (PMI, 2004) Gestión de la Calidad del Proyecto Describe los procesos necesarios para asegurarse de que el proyecto cumpla con los objetivos por los cuales ha sido emprendido. Se compone de los procesos de dirección de proyectos, planificación de calidad, aseguramiento de calidad y control de Calidad. (PMI, 2004) Gestión de los Recursos Humanos del Proyecto Describe los procesos que organizan y dirigen el equipo del proyecto. Se compone de los procesos de dirección de proyectos planificación de los recursos humanos, adquirir, desarrollar y gestionar el equipo del proyecto. (PMI, 2004) Gestión de las Comunicaciones del Proyecto

31 21 Describe los procesos relacionados con la generación, recogida, distribución, almacenamiento y destino final de la información del proyecto en tiempo y forma. Se compone de los procesos de dirección de proyectos, planificación de las comunicaciones, distribución de la información, informar el rendimiento y gestionar a los interesados. (PMI, 2004) Gestión de los Riesgos del Proyecto Describe los procesos relacionados con el desarrollo de la gestión de riesgos de un proyecto.(pmi, 2004) Gestión de las Adquisiciones del Proyecto Describe los procesos para comprar o adquirir productos, servicios o resultados, así como para contratar procesos de dirección. (PMI, 2004) Se puede decir que la Dirección de proyectos, debería como mínimo abarcar los aspectos básicos de cada una de las áreas del conocimiento como se puede ver en la figura No.6 donde se encuentran las nueve áreas del conocimiento según la guía del PMBoK :

32 22

33 23 Figura 6: Áreas del conocimiento, de la dirección de proyectos (PMI, 2004)

34 Grupo de procesos en la dirección de proyectos Los procesos de dirección del proyecto pueden ser organizados en cinco o más procesos cada uno: (PMI, 2004). Procesos de iniciación: esta se da cuando se autoriza el proyecto o una fase del mismo Procesos de planificación: definición y refinamiento de objetivos, selección de la mejor alternativa entre diferentes acciones para poder lograr alcanzar los objetivos del proyecto. Procesos de ejecución: Todo lo referente a la coordinación entre el equipo y recursos de trabajo para poder llevar a cabo el plan anteriormente definido. Procesos de seguimiento y control: Todo lo relacionado con el aseguramiento de que se están cumpliendo los objetivos del proyecto esto mediante la supervisión y la medición del avance regular y así poder identificar las variaciones al plan inicial y poder tomar las acciones correctivas cuando estas sean necesarias. Procesos de cierre: formalización de la aceptación del proyecto o de una fase del mismo En la figura 7 se puede tener una idea más general de la interacción de los procesos, en la dirección de proyecto.

35 25 Figura 7: Vínculos entre los grupos de procesos del proyecto o de una fase (PMI, 2004). Todos estos procesos están vinculados con todas las áreas del conocimiento según el PMBoK de los procesos como lo podemos ver en el figura No.8

36 26

37 27 Figura 8: Correspondencia de los grupos de procesos y las áreas de conocimiento del PMBoK 2.11 Niveles de madurez en Administración de Proyectos Harold Kerzner en su libro sobre planeación estratégica de administración de proyectos nos habla sobre como la planeación estratégica básica nos puede ayudar a formular e implementar decisiones acerca de la dirección a futuro de la organización, véase la figura 9.

38 28 Análisis Externo Oportunidades y amenazas del Ambiente Recopilación de información Análisis Interno Fuerzas Organizacionales y debilidades Responsabilidad social de la empresa Evaluación de Información Valores directivos de administración Evaluación estratégica Selección estratégica Implementación estratégica

39 29 Figura 9: Planeación básica estratégica (Kerzner, 2001) Este proceso es vital para cualquier organización, pero estos mismos deben ser adaptados a la misma empresa y deben de aplicarse a todos los niveles y tipos de organización. La madurez es una consecuencia de la planeación estratégica, no se logra la madurez en gerencia de proyectos si no es parte de la estrategia corporativa. La madurez se concentra en los aspectos estratégicos y tácticos más que en los operacionales El adoptar un modelo de madurez no genera ventaja competitiva para una organización. Generará una ventaja inicial, a las primeras en adoptarlo. A mediano plazo, será apenas una ventaja comparativa, sin la cual una organización no sobrevivirá. El modelo de madurez de Kerzner presenta cinco niveles y estos tienen algunos traslapes en los niveles, por ejemplo entre nivel 1 y 2 podría ocurrir porque la organizacional empieza a desarrollar la administración de proyectos y a su vez refina y comienza a crear una lenguaje común durante el desarrollo. Los niveles 3 y 4, podrían traslaparse cuando la organización comienza a desarrollar una metodología singular, planea y empieza a hacer los procesos con una metodología de mejora. Los niveles 2 y 3 generalmente no se traslapan.

40 30 Conocimiento Básico Definición de Procesos Nivel 2 Procesos Comunes Control de Procesos Nivel 3 Metodología Singular Mejoramiento de Procesos Nivel 4 Evaluación Nivel 5 Mejora Continua Nivel 1 Lenguaje Común Figura 10: Los cinco niveles del Modelo de madurez (Kerzner, 2001) El Project Management Madurity Model (PMMM) esta compuesto por cinco niveles como puede verse en la figura 10, cada nivel representa un diferente grado de madurez en la administración de proyectos estos son: (Kerzner, 2001) Nivel 1 Lenguaje común: En este nivel la organización reconoce la importancia de administrar proyectos y la necesidad de tener un buen entendimiento de los conceptos básicos de administración de proyectos y de acoplar lenguaje y/o terminología. Algunas características de este nivel son: (Kerzner, 2001)

41 31 La Gerencia de Proyectos es de interés personal antes que corporativo Prácticamente no hay soporte a nivel gerencial No se intenta reconocer los beneficios de la gerencia de proyectos No hay inversión en entrenamiento y educación en gerencia de proyectos Se puede decir que en este nivel hay reconocimiento de la existencia de procesos de gerencia de proyectos y que no hay prácticas o estándares establecidos y los proyectos individuales no rinden cuentas de ningún proceso estándar Nivel 2 Procesos comunes: En este nivel la organización reconoce que los procesos comunes son necesarios y deben ser definidos y desarrollados con mucho detalle en un proyecto para que este pueda ser repetido en otros proyectos. Algunas características adicionales de este nivel son: (Kerzner, 2001). Se reconocen los beneficios de la Gerencia de Proyectos Apoyo organizacional a todos los niveles Reconocimiento de la necesidad de procesos y metodologías Reconocimiento de la necesidad de control de costos Desarrollo de un programa de entrenamiento También incluye en este nivel es el reconocimiento y la aplicación y soporte de los principios de administración de proyectos y otras metodologías empleadas por la compañía. En este nivel existen muchos procesos de gerencia de proyectos, pero no se consideran un estándar, existe documentación para estos procesos básicos y la gerencia apoya la implementación de la gerencia de proyectos, sin embargo, no hay uniformidad a lo largo de los distintos proyectos

42 32 Nivel 3 Metodología Singular: En este nivel, la organización reconoce el efecto sinérgico de combinar todas las metodologías dentro de la organización en una metodología singular, el centro es la administración de proyecto. Algunas características de este nivel son: (Kerzner, 2001). Procesos integrados Apoyo cultural Apoyo gerencial a todos los niveles Gerencia de Proyectos informal Se reconoce cuantitativa y cualitativamente el ROI en entrenamiento de Gerencia de Proyectos Se reconocen las mejoras debido a la Gerencia de Proyectos En este nivel todos los procesos de gerencia de proyectos están establecidos como estándares de la organización, todos los proyectos utilizan los procesos, con mínimas excepciones, la gerencia está activamente involucrada existen muchos procesos que están automatizados y cada proyecto es evaluado y administrado a la luz de otros proyectos Nivel 4 Evaluación o BenchMarking : Este nivel contiene el reconocimiento que impone cada proceso si es necesario de mantener como una ventaja competitiva. La Evaluación puede resultar y una continua básica, la compañía decide como evaluar y que evaluar. Algunas características de este nivel son: (Kerzner, 2001). Existe una oficina de proyectos (OP) o un centro de excelencia Énfasis de la OP en la mejora de los procesos Benchmarking con industrias similares y distintas

43 33 Benchmarking cuantitativo en procesos y metodologías Benchmarking cualitativo en la aplicación de la Gerencia de Proyectos Nivel 5: Mejora continua: En este nivel, la organización evalúa la información obtenida del nivel anterior y decide como esta información retroalimenta su metodología singular para mejorar el proceso continuamente. Adicionalmente se tienen algunas características como son: (Kerzner, 2001). Registro de las lecciones aprendidas Transferencia de conocimiento Programa de mentores a través de la OP Planeación estratégica para la Gerencia de Proyectos

44 34 Capitulo 3 Marco Metodológico Este trabajo es una guía metodológica, que pretende establecer una serie de pasos fácilmente reproducibles, que darán autenticidad, integridad y credibilidad a los procesos que se realizan, en la Oficina de Administración Financiera en lo que corresponde a la administración de proyectos. En el se desea plantear la posible solución a un problema latente en la UTI, se anexa el resultado del diagnostico que se aplicó a los profesionales de la OAF que se relacionan directamente con los proyectos que allí se ejecutan. Al igual que la metodología dada por el PMBoK se pretende dar una guía metodológica aplicada a la realidad universitaria y sobre todo a la realidad de la OAF, esto con el fin de mejorar los procesos de toma de decisiones en lo que se refiere a proyectos, para este fin se utilizan las técnicas y herramientas como la EDT, formularios para el seguimiento y control de cambios, técnicas para medir el rendimiento que ayuden a evaluar la magnitud de cualquier variación que se produzca, esto con el propósito de saber si esta variación proviene de la referencia del plan inicial o si esta variación requiere alguna acción correctiva. Se utilizaran diferentes tipos de plantillas entre ellas algunas para ver los tiempos requeridos, así como poder destinar recursos al proyecto, plantillas que permitan identificar los riesgos del proyecto y las acciones para tener controlados estos, de forma que los proyectos nunca pasen a un estado mayor, plantillas para la estimación de tiempos de reserva o contingencia, utilizando desde luego la secuenciación de actividades de acuerdo al diagrama de red.

45 35 El trabajo realizado en este proyecto final de graduación es de tipo documental para la elaboración de una guía de trabajo con el fin de estandarizar los procesos y procedimientos en la UTI. Para ello se tomaron en cuenta la Unidad de Tecnologías de Información y las secciones de Tesorería, Presupuesto, y Contabilidad. 3.1 Procedimiento Metodológico Se realizará un análisis documental de procesos con respecto a la administración de proyectos, y se elaborará un diagnóstico de evaluación del grado de madurez de la organización de acuerdo con el modelo de PMMM de Harold Kerzner, en lo que a administración de proyectos se refiere, siendo este un punto de partida para elaborar las guías y planes de estandarización dentro de la UTI, basados en la metodología establecida en la guía de fundamentos de dirección de proyectos (PMBoK ) del Project Management Institute (PMI) 3.2 Definición de actividades Se identificarán y documentarán las actividades específicas que deben ser ejecutadas para generar los entregables y sub-entregables identificados en la estructura detallada de trabajo (EDT). Está implícita la necesidad de definir las actividades de modo que los objetivos del proyecto se cumplan.

46 Inventario y análisis de metodologías y estándares existentes relacionados con Administración de Proyectos. Realizar en la UTI un inventario de metodologías y estándares establecidos solo en desarrollo de proyectos y en estándares de documentación de los manuales, al igual que la documentación interna del software así mismo verificar si se tienen estándares de nomenclatura a nivel de base de datos y de variables.

47 37 Capítulo 4 Propuesta para la estandarización 4.1 Hallazgos Se realizó un análisis documental de los procesos y se encontró que los documentos relacionados con el desarrollo de proyectos no presentan un formato definido estandarizado, sino que tienen un formato personalizado de la unidad, sección o personal que lo creo, además se encontró que la documentación no esta centralizada para que esta pueda ser consultada. Se halló que la única practica en administración de proyectos, es la documentación técnica y de usuario a nivel de sistema, así como la documentación de requerimientos de sistemas, sin embargo en estos documentos no se sabe quien o quienes son los responsables. Se sabe que hay muchas experiencias en proyectos que no están documentadas, ya que son tomadas como experiencias vividas por un funcionario. Cuando un proyecto es manejado conjuntamente mediante Outsourcing, este tiene documentación incompleta, documentación faltante, o no tiene del todo documentación. Se halló que el alcance de los proyectos no está bien definido a la hora de iniciar, no se tienen claros los objetivos del mismo, y estos van apareciendo conforme el proyecto avanza. Además no se tiene documentado a los responsables de las diferentes etapas de cada proyecto.

48 38 Después de aplicar el cuestionario del primer nivel del PMMM que mide por medio de 80 preguntas el nivel en cada una de ocho áreas del conocimiento según la guía de PMBoK, a saber Alcance, tiempo, costo, calidad, recursos humanos, adquisiciones, riesgo y comunicaciones. Este cuestionario da puntajes dependiendo de las respuestas obtenidas y según el modelo de Kerzner en su libro Strategic planning for project management using a project management maturity model, si obtengo valores de 60 o más en cada área, puedo decir que tengo un conocimiento de los principios básicos de administración de proyectos, en esa área, si recibo un puntaje de 60 o mas excepto en una o dos áreas es posible que la organización tenga los conocimientos básicos de administración de proyectos sin embargo esa área o esas áreas no aplican directamente por las circunstancias. Por ejemplo si muchos de los proyectos son internos de la organización el área de abastecimiento o adquisiciones no es aplicable. Si su puntaje es menor a 60 en todas las categorías, existe una deficiencia. Para puntajes menores a 30 en todas las categorías, es necesario un programa de enseñanza riguroso sobre los principios básicos de administración de proyectos aparentemente necesarios, la organización muestra un alto grado de inmadures en administración de proyectos. Si en total la sumatoria de los puntajes en todas las categorías son mayores o igual a 600 podría indicar que la organización podría estar posicionada o comenzando a trabajar en el nivel 2 del PMMM. Para tener un poco más claros los resultados del diagnóstico, tenemos que cuando se aplicó el cuestionario que medía el nivel 1 de madurez del modelo de Kerzner, el cual nos refleja el conocimiento de proyectos a nivel de la empresa se obtuvieron los siguientes datos. A nivel general el puntaje en cada área es:

49 39 Área Puntaje con base a 100 Área integración y Alcance 13,33 Área Administración del tiempo 15,00 Área Administración del costo 16,67 Área Administración del recurso humano 33,33 Área Administración de adquisiciones 16,67 Área Administración de la calidad 21,67 Área Administración del riesgo 23,33 Área Administración de las comunicaciones 13,33 Como podemos ver los puntajes obtenidos nos indican que la organización debería de invertir más en capacitación básica de conceptos de administración de proyectos, es por ello que esta propuesta pretende ser una guía para la iniciación de manejo de gestión de proyectos, basada en el estándar del PMI. El cuestionario tiene 10 preguntas para cada área, por lo que al realizar un análisis por área se encontró lo siguiente: En el área de alcance e integración 6 respuestas nunca tuvieron una respuesta buena, en el área de tiempo 2 preguntas nunca tuvieron una respuesta buena, en el área de costo 5 preguntas nunca tuvieron una respuesta buena, en el área de recurso humano 2 preguntas nunca tuvieron una respuesta buena, en el área de adquisiciones 3 preguntas nunca tuvieron una respuesta buena, en el área de calidad 3 preguntas nunca tuvieron una respuesta buena, en el área de comunicaciones 4 preguntas nunca tuvieron una respuesta buena, pero en el área de riesgo todas las preguntas aunque sea una sola vez fue respondida en forma satisfactoria. Estas preguntas son la 1, 10, 11, 13, 16, 18, 20, 22, 26, 27, 30, 31, 32, 34, 38, 46, 47, 48, 54, 61, 62, 66, 69, 73, 75, en el anexo 1 se tiene una copia del cuestionario, para una mejor ubicación de las preguntas.

50 40 A las preguntas 9, 28 que pertenecen al área de recurso Humano asi como la 36 que pertenece al área de calidad, fueron respondidas bien al menos por el 50%, de los encuestados.

51 Desarrollo de la propuesta La siguiente propuesta esta basada, en una estandarización, además contempla una propuesta para la administración del tiempo, la administración de las comunicaciones y de la administración de la calidad Propuesta para la Administración del Tiempo La siguiente propuesta pretende estandarizar la administración del tiempo en los proyectos en la UTI de forma que estos puedan seguir un estándar bien definido. Para poder concretar la propuesta es importante aclarar algunos aspectos antes de entrar en materia de administración del tiempo, estos aspectos son Alcance del proyecto, generar el Charter del proyecto, creación de la EDT, secuenciación de actividades, estimación de la duración de cada actividad, Para posteriormente entrar en la parte de manejo del tiempo por medio del desarrollo del cronograma Definir el alcance del proyecto. Para definir el alcance del proyecto es importante utilizar los siguientes conceptos: El enunciado del alcance del proyecto describe, en detalle, los productos entregables del proyecto y el trabajo necesario para crear tales productos entregables. El enunciado del alcance del proyecto también proporciona un entendimiento común del alcance del proyecto entre los interesados del proyecto, y describe los principales objetivos del mismo. También permite al equipo del proyecto realizar una planificación más detallada; guía el trabajo del equipo del proyecto durante la ejecución y proporciona la línea base para

52 42 evaluar si las solicitudes de cambio o trabajo adicional están comprendidas dentro o fuera de los límites del proyecto. A su vez gestionar el alcance del proyecto puede determinar el nivel de éxito con que el equipo de dirección del proyecto podrá planificar, gestionar y controlar la ejecución del proyecto. Para documentar el alcance del proyecto podemos utilizar la siguiente plantilla:

53 43 Declaración del alcance del proyecto Nombre del proyecto: Nombre del proyecto Fecha última revisión: <día mes año> Versión: <Nº> Entregable Detalle Criterios de aceptación Fase <Entregable 1> <Detalle o Descripción> <Criterio de aceptación> <Fase> <Entregable 2> <Detalle o Descripción> <Criterio de aceptación> <Fase> <Entregable 3> <Detalle o Descripción> <Criterio de aceptación> <Fase> <Entregable 4> <Detalle o Descripción> <Criterio de aceptación> <Fase> <Entregable n> <Detalle o Descripción> <Criterio de aceptación> <Fase> Plantilla 1: Declaración del alcance del proyecto

54 44 El enunciado del alcance del proyecto detallado incluye, ya sea de forma directa o mediante referencia a otros documentos, lo siguiente: Objetivos del proyecto: Los objetivos del proyecto incluyen los criterios medibles del éxito del proyecto. Los proyectos pueden tener una amplia variedad de objetivos de cronograma, técnicos y de calidad. Los objetivos también pueden incluir metas relativas a costos, cronograma y calidad. Cada objetivo del proyecto tiene atributos, como costo; una métrica. Descripción del alcance del producto: Describe las características del producto, servicio o resultado para el cual se creó el proyecto. Generalmente, estas características serán menos detalladas en las fases iniciales y más detalladas en las fases posteriores, a medida que las características del producto se van elaborando gradualmente. Si bien la forma y el contenido de las características pueden variar, la descripción del alcance deberá ser siempre lo suficientemente detallada como para que sirva de apoyo a la planificación posterior del alcance del proyecto. Requisitos del proyecto: Describen las condiciones que deben cumplir o las capacidades que deben tener los productos entregables del proyecto para satisfacer, una norma, una especificación o cualquier otro documento formalmente impuesto. El análisis de los interesados que incluyen la totalidad de sus necesidades, deseos y expectativas se traducen en requisitos priorizados. Límites del proyecto: Identifica generalmente qué está incluido dentro del proyecto. Establece explícitamente qué está excluido del proyecto, si un interesado podría suponer que un producto, servicio o resultado en particular podrían ser un componente del proyecto.

55 45 Productos entregables del proyecto: Los productos entregables incluyen tanto las salidas que comprenden el producto o servicio, como los resultados secundarios, tales como informes y documentación de la dirección del proyecto. De acuerdo con el enunciado del alcance del proyecto, los productos entregables pueden describirse en forma resumida o muy detallada. Criterios de aceptación del producto: Definen el proceso y los criterios para aceptar los productos completados. Restricciones del proyecto: Enumeran y describen las restricciones específicas del proyecto asociadas con el alcance que limitan las opciones del equipo del proyecto. Por ejemplo, se incluyen un presupuesto predefinido o cualesquiera fechas impuestas (hitos del cronograma) emitidos por la administración. Cuando un proyecto se realiza bajo un contrato o bajo la modalidad outsourcing, generalmente las disposiciones contractuales actuarán como restricciones. Las restricciones enumeradas en el enunciado del alcance del proyecto detallado, por lo general, son más numerosas y detalladas que las restricciones enumeradas en el acta de constitución del mismo. Asunciones del proyecto: Enumeran y describen las asunciones específicas del proyecto asociadas con el alcance y el potencial impacto de tales asunciones si resultan ser falsas. Los equipos del proyecto frecuentemente identifican, documentan y validan las asunciones como parte de su proceso de planificación. Las asunciones enumeradas en el enunciado del alcance del proyecto detallado, por lo general, son más numerosas y detalladas que las asunciones enumeradas en el acta de constitución del proyecto.

56 46 Organización inicial del proyecto: Se identifica a los miembros del equipo por parte de la Universidad, así como a los interesados ya sean internos o externos al proyecto. También se documenta la organización del proyecto. Riesgos iniciales definidos: Identifica la mayor cantidad de riesgos conocidos. Hitos del cronograma: La UTI debería de poder identificar hitos y pueden colocar fechas en dichos hitos del cronograma. Estas fechas pueden tratarse como restricciones del cronograma. Limitación de fondos: Describe cualquier limitación aplicada al financiamiento del proyecto, ya sea en cuanto al valor total o durante períodos específicos. Estimación del costo: La estimación del costo del proyecto calcula el costo total esperado del proyecto, y generalmente está precedida por un modificador que proporciona alguna indicación acerca de su exactitud, como conceptual o definitiva. Requisitos de gestión de la configuración del proyecto: Describe el nivel de gestión de la configuración y de control de cambios que debe implementarse en el proyecto. Especificaciones del proyecto: Identifica aquellos documentos de especificaciones con los que debería cumplir el proyecto. Requisitos de aprobación: Identifica los requisitos de aprobación que pueden aplicarse a aspectos tales como objetivos, productos entregables, documentos y trabajo del proyecto.

57 47 Para efectos prácticos podemos ver la siguiente plantilla de Charter del proyecto, el contiene todos y cada uno de los elementos antes mencionados: Nombre del proyecto: Nombre del proyecto Fecha ultima revisión: <día mes año> Preparado por: <Nombre(s) apellido(s)> Fecha constitutiva: <día mes año> Fecha final estimada <día mes año> Justificación del proyecto <Detalle de justificación del proyecto> Objetivos del proyecto General <Descripción del Objetivo General> Específicos <1. Descripción del Objetivo General> <2. Descripción del Objetivo General> <3. Descripción del Objetivo General> Entregables del proyecto <1. Descripción de cada entregable del proyecto> <2. Descripción de cada entregable del proyecto > <3. Descripción de cada entregable del proyecto > Supuestos del proyecto <1. Descripción de supuesto del proyecto> <2. Descripción de supuesto del proyecto > <3. Descripción de supuesto del proyecto > Productos del proyecto <1. Descripción del producto del proyecto> Restricciones del proyecto <1. Descripción de restricciones del proyecto> <2. Descripción de restricciones del proyecto > <3. Descripción de restricciones del proyecto > Involucrados del proyecto (Stakeholders) <1. Descripción de involucrados del proyecto>

58 48 <2. Descripción de involucrados del proyecto > <3. Descripción de involucrados del proyecto > Observaciones importantes del proyecto <Observaciones del proyecto > Aprobado por <Firma> Director de Proyecto <Firma> Subdirector de Proyecto <Firma> Director de Oficina Plantilla 2: Charter del proyecto Creación de la estructura detallada de trabajo (EDT) La EDT es una descomposición jerárquica, orientada al producto entregable, del trabajo que será ejecutado por el equipo del proyecto, para lograr los objetivos y crear los productos entregables requeridos. La EDT organiza y define el alcance total del proyecto. La EDT subdivide el trabajo del proyecto en porciones de trabajo más pequeñas y fáciles de manejar, donde cada nivel descendente de la EDT representa una definición cada vez más detallada del trabajo del proyecto. El trabajo planificado comprendido dentro de los componentes de la EDT del nivel más bajo, denominados paquetes de trabajo, puede programarse, supervisarse, controlarse y sirve para poder estimar los costos Los componentes que comprenden la EDT ayudan a los interesados a ver los productos entregables del proyecto. La descomposición es la subdivisión de los productos entregables de un proyecto en componentes más pequeños y fáciles de manejar, hasta que el trabajo y los productos entregables se definen al nivel del paquete de trabajo. El nivel del paquete de trabajo es el nivel más bajo de la EDT y es el punto en el que los costos y el cronograma para el trabajo pueden estimarse

59 49 de forma fiable. El nivel de detalle para los paquetes de trabajo variará según el tamaño y la complejidad del proyecto. Puede que no sea posible la descomposición de un producto entregable o subproyecto que se logrará a muy largo plazo. Generalmente, el equipo de dirección del proyecto espera hasta que se aclare el producto entregable o subproyecto, de modo que puedan desarrollarse los detalles de la EDT. Esta técnica a veces se denomina planificación gradual. Distintos productos entregables pueden tener diferentes niveles de descomposición. Para llegar a un esfuerzo de trabajo fácil de manejar (es decir, un paquete de trabajo), para algunos productos entregables el trabajo sólo debe descomponerse hasta el nivel siguiente, mientras que otros requieren niveles mayores de descomposición. A medida que el trabajo se descompone hasta niveles inferiores de detalle, mejora la capacidad de planificar, dirigir y controlar el trabajo. Sin embargo, la descomposición excesiva puede conducir a un esfuerzo de gestión no productiva, un uso ineficiente de los recursos y una menor eficiencia en la realización del trabajo. El equipo del proyecto debe buscar un equilibrio entre niveles de planificación de la EDT demasiado detallados o sin el suficiente detalle. La descomposición de todo el trabajo del proyecto generalmente implica las siguientes actividades: Identificar los productos entregables y el trabajo relacionado Estructurar y organizar la EDT Descomponer los niveles superiores de la EDT en componentes detallados de nivel inferior Desarrollar y asignar códigos de identificación a los componentes de la EDT Verificar que el grado de descomposición del trabajo es necesario y suficiente. Para hacer la descripción de los paquetes de la estructura detallada de trabajo podemos utilizar la siguiente plantilla:

60 50 Descripción de los paquetes de trabajo NOMBRE DEL PROYECTO Pág. 1 de n Referencia : Edición : Fecha : <día mes año> PAQUETE DE TRABAJO : <Nº> <Nombre de paquete> RESPONSABLE : <Nombre> ESFUERZO : <Esfuerzo> COMIENZO : <día mes año> FINAL : <día mes año> ENTRADAS : <Describir las entradas necesarias> SALIDAS : <Describir las Salidas después de realizado el paquete de trabajo> TAREAS : <Describir las Tareas a realizar del paquete de trabajo> RESULTADOS : <Describir los resultados esperados del paquete de trabajo> OTROS COMENTARIOS : <Describir comentarios > Plantilla 3: Descripción de los paquetes de trabajo La identificación de los principales productos entregables del proyecto y el trabajo necesario para producir tales productos entregables exige analizar el enunciado del alcance del proyecto detallado. Estructurar y organizar los productos entregables y el trabajo del proyecto relacionado en una EDT que pueda cumplir con los requisitos de control y gestión del equipo de dirección del proyecto, es una técnica analítica que puede realizarse mediante el uso de una plantilla de EDT (ver plantilla 3). La estructura resultante puede adoptar varias formas, pero sin embargo la que

61 51 mas se adapta a la oficina es la de fases del proyecto, en esta se usa las fases del ciclo de vida del proyecto como el primer nivel de descomposición, insertando los productos entregables del proyecto en el segundo nivel, tal y como se muestra en la siguiente figura Figura 11: EDT descomposición del primer nivel, entregables en segundo nivel. (PMI, 2004) Es importante aclarar que cada uno de los paquetes de trabajo identificados en el EDT es lo que llamaremos actividades a desarrollar Secuenciación de actividades