UNIVERSIDAD ALAS PERUANAS FACULTAD DE INGENIERAS Y ARQUITECTURA ESCUELA PROFESIONAL DE INGENIERA DE SISTEMAS E INFORMTICA CURSO: DISEO Y EVALUACIN DE PROYECTOS

Ing. Flix Richar Mendoza Pumacahua Docente Semana 03: Administracin de Proyectos de Ingeniera de Sistemas. Su Importancia en el desarrollo de Sistemas de Informacin Empresariales. La Administracin de Proyectos de Ingeniera de Sistemas propiamente dichos. Ciclo de vida de un Proyecto de Ingeniera de Sistemas de Software. Variables en la administracin de Proyectos de Ingeniera de Sistemas. Introduccin Los proyectos no son nuevos. Las pirmides egipcias, el Partenn griego, la gran muralla china, son ejemplos de la empresa humana ejecutadas en la forma de proyectos. An ms, la Creacin del Mundo es un proyecto ejecutado en 6 das, medido en das, con recursos supuestamente ilimitados y con un resultado dejado en manos y juicio de los usuarios... Adn y Eva. La lista anterior puede aumentarse con cosas ms cotidianas. Terminar el material de estudio de esta semana, terminar el mes dentro de ciertos gastos, un estudio de doctorado. Por supuesto estn los llamados formalmente proyectos de ingeniera, proyectos de arte, proyectos educativos, y muchos otros tipos, de entre los cuales los proyectos de Ingeniera de Sistemas son de inters debido a que permiten hacer un anlisis de negocios y tecnolgico para un proyecto tecnolgico. Se quiere hacer ver que conceptualmente un proyecto de Ingeniera de Sistemas permite distinguir los dos elementos centrales a cualquier proyecto tecnolgico: la dimensin de negocio y la dimensin tecnolgica.

1.

Proyectos: una visin terica

Para llegar a entender lo que es un proyecto cualquiera, resulta conveniente empezar conociendo lo que se entiende por un proyecto, por tratarse de un trmino que, pese a ser de uso comn, puede tomar significados diferentes y no siempre se emplea en el mismo sentido o con la precisin conveniente. Proyecto, desde una perspectiva general y terica, se puede definir como la accin intencionada de hombres y/o mujeres hacia la consecucin de un resultado o, el medio o la accin organizacional mediante la cual una organizacin, empresa o negocio, busca respuesta a un problema o conflicto. Tal accin da lugar a una solucin instrumental, en la forma de un producto o servicio.

Otra definicin de proyecto puede ser "... un conjunto planificado de acciones tendientes a resolver exitosamente -mediante una cantidad de recursos humanos y materiales, un presupuesto y un tiempo para su realizacin- una situacin problemtica o una demanda planteada". Completar con el xito del proyecto significa cumplir con los objetivos, dentro de las especificaciones tcnicas, de costo y de plazo de terminacin.

Un proyecto siempre da lugar a una solucin. Esta solucin tiene varias particularidades: Es habitualmente injertada en la misma organizacin que la requiri, por lo cual la solucin ha de ser coherente con la organizacin, tanto en el mbito tecnolgico como en el humano. Surge instrumentalmente por un acuerdo entre proyectistas y clientes en razn de tiempo, costo, ganas y satisfaccin en resolver un conflicto. En s misma requiere de una empata y un equilibrio entre lo que se pide, desea o anhela, y lo que se puede con los medios humanos y tecnolgicos. Proyecto, desde un punto de vista ms concreto, se concibe como una operacin de envergadura y complejidad notables, singular, con unas fechas definidas de inicio y finalizacin. Es un trabajo no repetitivo, que ha de planificarse y realizarse segn unas especificaciones tcnicas determinadas, con un presupuesto preestablecido y una organizacin temporal con la participacin de varios departamentos de la empresa que se desmantela cuando termina el proyecto, y que incluye, tal vez, la colaboracin de terceros. Este concepto emerge de observar que las tareas humanas se organizan bajo ciertas condiciones, cuyo manejo y aprovechamiento pre-figuran las cualidades que afectan todo proyecto. Persecucin de uno o varios objetivos. Las actividades aisladas no constituyen por s solas, un proyecto. Para que exista un proyecto, debe existir una coordinacin de actos orientados a la consecucin de uno o varios objetivos, integrados entre s y estructurados, tanto de ndole tcnica como econmica. En general, el objetivo general de un proyecto es satisfacer un conjunto de requisitos a un coste dado en las condiciones ms eficientes. Actividades planificadas, ejecutadas y supervisadas. La coordinacin de actividades es condicin sine-qua-non para que a las mismas, en su conjunto, se les pueda calificar de proyecto. De hecho, un proyecto exige que exista vinculacin entre las actividades, puesto que persiguen un objetivo comn. Esa vinculacin debe plasmarse en forma de planificacin (tcnica, temporal y econmica) cuya correcta ejecucin supervisada es clave para el xito o fracaso del proyecto. Disponibilidad limitada de recursos. El proceso proyectual implica la bsqueda de la eficiencia en el uso de los recursos para obtener el resultado perseguido. Si los recursos son ilimitados, desaparece el concepto de eficiencia y con l la naturaleza proyectual de las actividades. Limitacin de tiempo. Un proyecto debe estar acotado en trminos del principio y el fin mismo. El final de un proyecto se alcanza cuando se cumplen los objetivos pre- fijados, o cuando se hace evidente que dichos objetivos no pueden alcanzarse (fracaso del proyecto). Por otro lado, aunque el proyecto tenga que
2

estar acotado en el tiempo, no sucede lo mismo con sus resultados, que pueden perdurar con carcter indefinido (por ejemplo, una catedral). As, se puede llegar a decir que los proyectos se caracterizan en general por: Tener objetivos especficos; Deben completarse dentro de un periodo determinado; Tener inicios y trminos bien definidos; Deben completarse dentro de las restricciones de un presupuesto; Ser ejecutados por un equipo; y, Ser nicos.

1.1.

Definicin

Las acepciones previas pueden considerarse extremas dentro de un amplio abanico de definiciones de 'proyecto'. Por tanto, la pregunta es: qu es un proyecto? Esta pregunta ha llevado a diversas definiciones, o ms bien, formas en que se entiende un proyecto, todas ellas vlidas, cuyo conocimiento permite mostrar visiones sesgadas de un mismo fenmeno. - Es un esfuerzo conjunto de muchas personas -hombres y mujeres- que buscan el mximo beneficio en conseguir una solucin razonable a un problema que se espera tenga la solucin ideal. - El proyecto es una operacin que se expresa como una experiencia prctica cooperativa y colaborativa en la cual: - se usan conceptos abstractos (por estar en dominios de conocimiento transversales) junto a conceptos tcnicos (por estar en dominios aplicados concretos) que se manifiestan en documentos (por ser medio de expresin natural y persistente de las personas). - Es el conjunto de acciones destinadas a resolver o vulnerar un problema ya identificado, priorizado y explicado en el momento de investigacin de problemas crticos. - Es un conjunto autnomo de inversiones, polticas y medidas institucionales y de otra ndole, diseadas para lograr un objetivo especfico (o serie de objetivos). Se puede definir como un modelo para las asignaciones de recursos, que tienen un tiempo de ejecucin y se logran resultados medibles. Tambin se identifica, como la menor unidad de actividades, que puede ser planificada y ejecutada aisladamente de la planificacin de operacin y sostenimiento de los servicios de Salud. Constituye la unidad operativa ms pequea que desde el punto de vista lgico, se presta para la planificacin, el financiamiento y la ejecucin como unidad independiente dentro de un plan o programa de desarrollo local. - Es un proceso para obtener recursos, destinado a convertir una idea surgida de los planes nacionales, de las necesidades locales e institucionales y de las situaciones de

emergencia, con el fin de frenar el deterioro o continuar el desarrollo de los servicios sociales. - Es un conjunto especfico de actividades en las que se invierten escasos recursos con la esperanza de obtener beneficios. - Es el conjunto de acciones o actividades que se realiza a partir de una situacin actual para obtener una situacin futura o esperada. - Es la unidad operativa ms pequea que puede ser ejecutada en forma independiente o autnoma, constituida por un conjunto de actividades o tareas encadenadas en un orden lgico, destinadas a cumplir un fin especfico a incidir en la magnitud de una o ms variables, determinada por la realidad a la que se orienta. - Es una informacin estructurada con valor agregado que permite la articulacin de recursos humanos de diferentes estructuras de la organizacin y de diferentes disciplinas y funciones. - Es una empresa planificada con un conjunto de actividades para alcanzar un objetivo, con un presupuesto y un tiempo previamente determinado, que como la mayora de los procesos humanos tiene carcter cclico, y la clave de su dinmica es la transformacin de la realidad y el avanzar hacia un estadio superior del desarrollo. - Es un proceso cuyo objetivo es transformar una idea en un producto terminado, constituido por bienes o servicios que sern los medios para producir otros bienes o servicios, y consta de 3 caractersticas fundamentales: - Es un proceso finito, es decir, que se cuenta con un perodo de tiempo determinado para alcanzar el objetivo. - Cuenta con un presupuesto preestablecido para alcanzar el objetivo. - Es un proceso nico (no repetitivo) en que las actividades van ligadas por requerimientos de secuencias y por tanto en cada etapa las actividades son diferentes. - Es un conjunto no vaco de tareas estructuradas, que se desarrollan en un plazo de tiempo finito y acotado, con objetivos bien definidos acordes con su misin y que se alcanzan con la integracin de las soluciones parciales de las tareas, a partir de un diseo con enfoque sistmico y en funcin de la visin, en el que se combinan los recursos con criterios de optimizacin, de acuerdo con sus requerimientos y restricciones, tomando en cuenta y evaluando los riesgos. - Es un proceso nico, consistente en un conjunto de actividades controladas, con fecha de inicio y finalizacin, llevadas a cabo para lograr un objetivo conforme con requisitos especficos, incluidas las limitaciones de tiempo, costo y recursos. - El proyecto es una operacin de ingeniera que involucra pasar de un sistema deseado a un sistema a ofrecer (ver figura 2), lo cual implica:

- ir de una idea inmaterial y difusa proveniente de un problema o necesidad a un ordenamiento tcnico formal y estructurado de tareas que regulan las acciones de hombres y mujeres para conseguir objetivos predeterminados. Estas definiciones incluyen varios atributos (ver figura 1) pero es mejor agrupar estas definiciones en dos grupos: Proyecto como produccin de artefactos; y, Proyecto de accin.

Figura 1: Atributos principales asociados a la definicin de proyecto.

Figura 2: Generalizacin del concepto de Proyecto.

a. Produccin de artefactos Un proyecto se comprende habitualmente como un medio para obtener un artefacto, un resultado material concreto. De entre las mltiples definiciones que plantea el proyecto en estos trminos, es posible distinguir dos acepciones, ambas similares, pero apuntando a distintas finalidades segn quien tiene la misin de dirigirles. As se puede hablar de: - Proyecto como programa a seguir. En este caso el 'proyecto' es equivalente a cumplir plazos y fechas, y entregar documentacin. - Proyecto (segn el Diccionario de la Lengua Espaola de la Real Academia Espaola): "Planta y disposicin que se forma para un tratado, o para la ejecucin de una cosa de importancia, anotando y extendiendo todas las circunstancias principales que deben concurrir para su logro". - Projecte, segn el Diccionari de la Llengua Catalana del Intitut d'Estudis Catalans, es: "All que hom pensa portar a acompliment; pla propossat per a realitzar-ho; estudi detallat d'una cosa realitzar". - Project (segn el Diccionario Oxford): "Hacer planes para ('Make plans for')". - Proyecto como consecucin de objetivos. En este caso el 'proyecto' es equivalente a alcanzar objetivos. - Para Ribera: "Un proyecto es una secuencia nica de actividades complejas e interconectadas que tienen un objetivo o propsito que debe ser alcanzado en un plazo establecido, dentro de un presupuesto y de acuerdo con unas especificaciones". - Segn el Project Management Institute: "Un proyecto es un esfuerzo temporario realizado para crear un producto, servicio o resultado nico." ('A Project is a temporary endeavor undertaken to create a unique product, service, or result'.) - Segn Jurison: "Ensamblaje de recursos para solucionar un problema de un determinado tipo ('Assemblage of resources to solve a one-of-a-kind problem')". b. Proyecto de accin En un proyecto de accin el fin no es producir un artefacto, sino encontrarlo y definirlo. En este caso, existe una componente de aprendizaje para, 'aprender' a resolver problemas.
6

- Proyecto, para Blasco, es: "La operacin de ingeniera que nos lleva a conseguir un objetivo material predeterminado por modificacin de la realidad exterior mediante unas acciones humanas que han sido seleccionadas y ordenadas con anticipacin de acuerdo con unos criterios". - Para Dahlbom y Mathiassen, proyecto es una accin donde se: - se interviene, debido al cambio en el entorno que se produce por la propia existencia del proyecto como por el resultado que se genera y se pone en el medio; - se evoluciona, debido a buscar la solucin de un problema que no es fijo ni estable, sino que se va dando conforme el proyecto est en ejecucin; y, - se construye, por desarrollar una solucin tcnica que es la respuesta a un problema.

1.2.

Tipologa de proyectos

Las visiones previas muestran que un proyecto involucra dos proyectos de enunciado terico: proyecto para construccin de artefactos y proyecto de accin, cada uno de los cuales, segn su relevancia y su grado integracin mutuo, han llevado a que clasificar un proyecto no sea una labor sencilla. Ms bien es una labor compleja, pues su variedad y diversidad es alta. Sin embargo, es posible sugerir una tipologa general dependiendo de algunos criterios. La tipologa general aqu presentada utiliza criterios de distincin: Por objeto, o por el objeto que est tratando el proyecto; Por actividad, o dependiendo de alguna fase en el ciclo de vida de un producto; Por rol del usuario, por el contexto en el cual se desarrolla el proyecto; Por campo de ingeniera, o por la disciplina, ciencia y/o tcnica que predomina en el proyecto; Por naturaleza del resultado, o por el tipo de producto a obtener.

1.2.1 Taxonoma de proyectos Debe aclararse que estos criterios ni son todos ni son determinantes. a. Por objeto - Proyecto clsico. Se aborda la realizacin de una serie de documentos que define la obra o trabajo a realizar para su ejecucin en un futuro. El alcance comprende la identificacin, evaluacin, organizacin y valoracin de las actividades que faltan para conseguir o culminar el resultado perseguido, pero en su alcance no est comprometida la

realizacin de las mismas. El resultado es una memoria, unos planos, un pliego de condiciones y un presupuesto y, a lo sumo, un prototipo o maqueta del objeto en cuestin. - Proyecto de investigacin. Su objetivo es aportar en su conclusin un conjunto de conocimientos nuevos en una disciplina y materia concreta, a menudo desconocida al comienzo de los trabajos. Su fin es que otros se vean beneficiados, sea en entornos industriales o acadmicos. El resultado es una memoria de investigacin donde, aparte del planteamiento del problema a resolver y la descripcin del estado del arte, se resean los trabajos realizados, los resultados de los mismos y las conclusiones pertinentes, junto con las lneas de investigacin futuras propuestas en esa disciplina concreta. b. Por actividad - Estudios y anlisis. En ocasiones el alcance de un trabajo concreto se limita a analizar o estudiar la informacin disponible acerca de los aspectos tcnicos, econmicos, ambientales y sociales de un determinado problema. En este caso el proyecto recibe el nombre de estudio (comprensin o conocimiento del problema o anlisis (examen del problema para comprender los principios del mismo). - Estudios de viabilidad. Los estudios de viabilidad deben proporcionar la base- tcnica, econmica y comercial para la decisin de invertir en un proyecto industrial. En estos estudios se deben definir y analizar los elementos crticos relacionados con la fabricacin de un producto dado, junto con otros enfoques posibles a tal produccin. Un estudio de este tipo debe dar por resultado un proyecto con capacidad de produccin definida en un emplazamiento seleccionado, utilizando una o varias tecnologas determinadas en relacin con materiales e insumos especficos con costes de inversin y produccin identificados, e ingresos por concepto de ventas que produzcan un rendimiento determinado respecto de la inversin. c. Por rol del usuario - Proyecto externo. Los proyectos externos a la organizacin son aquellos en los que el cliente es ajeno a la empresa, que hace los trabajos. Se rige fundamentalmente por criterios de mercado, incluyendo competitividad y eficacia. - Proyecto interno. Los proyectos internos a la organizacin, son aquellos en los que el cliente es de la misma empresa que desarrolla los trabajos. d. Por campo de ingeniera Por campo de ingeniera, se tienen proyectos diversos: - Productos naturales. Ingeniera agronmica, oceanogrfica, forestal y minera. La obtencin de productos naturales requiere unos proyectos muy en contacto con el medio que se va a tratar, con mucho trabajo de campo y la necesidad de un gran soporte documental, pero con escasa interrelacin entre los equipos y mquinas necesarios, lo que evita la necesidad de una definicin minuciosa de los mismos que condicione las fases posteriores del trabajo.

- Infraestructuras y edificaciones. Ingeniera civil, construccin. La construccin de infraestructuras y edificaciones de todo tipo se apoya en disciplinas fundamentales como topografa, geotecnia y resistencia de materiales, y exige proyectos detallados con profusin de clculos y planos, pero cuya ejecucin es prcticamente independiente, en el tiempo, de los documentos que configuran el proyecto. - Productos manufacturados. Ingeniera industrial, mecnica, electrnica, automtica, qumica, aeronutica, naval. Los productos manufacturados exigen unos proyectos muy complejos, con muchas disciplinas implicadas y numerosos equipos, mquinas y aparatos interconectados, que exigen gran atencin y abundantes especificaciones. - Servicios/sistemas ligados a ingeniera elctrica, energa, telecomunicacin, informtica. En este caso hablamos de productos cuya esencia es intangible, por su naturaleza inmaterial que dificulta su manipulacin corprea. e. Por naturaleza del resultado - Proyecto de ingeniera. En este caso estamos ante un proyecto de accin, donde esencialmente se persigue resolver un conflicto definiendo cual sera el potencial sistema solucin. - Proyecto industrial. A diferencia de los proyectos clsicos, los proyectos industriales comienzan y terminan en s mismos, dando lugar a un producto o servicio terminado (sin que ello sea obstculo para que otros proyectos comincen posteriormente desde los resultados del primero). Involucra una planificacin en la ejecucin de actividades orientadas a un fin concreto (el bien o servicio) por lo que una vez finalizado el mismo, la replicacin de los resultados no constituira un proyecto en s mismo. Este tipo de proyectos, por su relevancia y generalidad se detallan a continuacin.

1.2.1.1

Proyectos a destacar

a.- Proyecto de ingeniera Por su relevancia, en este apartado se profundiza en los proyectos de ingeniera. Los Proyectos de Ingeniera tienen una serie de caractersticas comunes que se citan a continuacin: Complejidad. Una serie de factores, como el trabajo requerido para su realizacin, el tamao de la inversin, todo el tiempo necesario para llevarlo a cabo ms las importantes responsabilidades que van asociadas a ello hacen complejo un proyecto de ingeniera. Por su enorme complejidad es preferible dividirlo en partes mucho ms pequeas que pueden ser estudiadas ms profundamente. Integrabilidad. La mayora de los proyectos que se realizan en la actualidad se caracterizan por la necesidad de cubrir todas las etapas desde el principio (proyectos completos o integrales), cuando slo existe una idea de algo que queremos materializar hasta el final, cuando se ha transformado en una realidad.
9

No obstante, a veces se tiene la impresin que se suprimen algunas etapas intermedias. Esto no es del todo cierto, lo que ocurre simplemente es que se utilizan otras vas, recurriendo a informaciones ya existentes o simplificaciones. Multidisciplinariedad. Los proyectos que a veces se llevan a cabo son de tal envergadura que se necesita un amplio equipo de profesionales cada uno de ellos expertos en una disciplina, con amplios conocimientos tcnicos. Por ello, una tercera caracterstica para proyectos de ingeniera complejos e integrales es la disponibilidad de conocimientos multidisciplinares. b.- Proyecto industrial Los proyectos industriales se diferencian de los otros en la menor importancia que se atribuye a las caractersticas del terreno donde se localiza desde el punto de vista tcnico, adems se exige una definicin precisa de todos los equipos y mquinas que componen el sistema de produccin. En este tipo de proyectos la fase documental se puede desarrollar independientemente de equipos y mquinas hasta un determinado momento, pero a partir del cual es imprescindible la definicin y seleccin de stos. Los equipos y mquinas pueden quedar obsoletos o sufrir variaciones importantes en sus costes o prestaciones. Una clasificacin bastante representativa de los proyectos industriales, con independencia de su origen, podra ser: - Grandes proyectos de inversin. Realmente este tipo no se puede considerar un proyecto, sino ms bien es un estudio econmico que lo acompaa, tanto desde el punto de vista de la demanda prevista como de los costes de produccin y de sus consecuencias sociales y polticas: creacin de empleo, desarrollo regional, etctera. Dependiendo de sus resultados indica si el proyecto tiene o no futuro en el mercado. Si sus resultados son negativos, los proyectos suelen morir sin ver la luz y si son positivos, se utilizan como base para las posteriores etapas del proyecto, que habitualmente implica grandes inversiones. - Instalaciones y plantas industriales. La realizacin de estos proyectos constituye el captulo ms amplio e importante dentro de la ingeniera industrial y para ello es necesario la construccin de plantas e instalaciones, que constituye un proyecto completo con todas sus fases y aspectos. Los sectores, instalaciones y plantas ms tpicos son los que se enumeran a continuacin: - Industria electrnica. - Robtica y automtica. - Industria de transformacin. - Plantas de proceso (refineras, petroqumicas, fertilizantes, qumica inorgnica). - Industria de la alimentacin. - Farmacia.
10

- Pasta, papel y cartn. - Cemento. - Centrales elctricas (hidrulicas, trmicas, nucleares). - Siderurgia y metalurgia. - Industria aeronutica y espacial. - Industria naval. - Lneas y unidades de produccin. - Unidades y lneas de produccin. El estudio y diseo de las unidades y lneas de produccin de los edificios e instalaciones que forman las grandes plantas industriales constituyen por s mismos proyectos independientes que, en muchas ocasiones estn interconectados. - Mquinas, equipos y sus elementos. El estudio de las mquinas y equipos que forman parte de cualquier instalacin industrial, e incluso algunos elementos de stos constituyen tambin por s mismos un proyecto. Otra clasificacin de los proyectos industriales podra ser: segn la naturaleza del proyecto (especialidad), el volumen de la inversin, el objeto del proyecto y el proceso que utiliza. - Por la naturaleza del proyecto. Por su naturaleza o especialidad, hay que recurrir a la clasificacin de los distintos sectores industriales. Esta clasificacin coincide con la lista enumerada anteriormente en el punto "instalaciones y plantas industriales". - Por el volumen de la inversin. - Pequeo. - Mediano. - Grande. - Por el objeto del proyecto. - Nueva instalacin. - Ampliacin (Modificaciones de proceso, Nuevas lneas, Nuevos productos, Cuellos de botella). - Mejora: - Econmica: Aumento de calidad, Reduccin de costes.
11

- Social: Seguridad, Proteccin ambiental. - Mantenimiento. - Traslado. - Por el proceso que utiliza. - Su naturaleza (mecnico, fsico, fsico-qumico). - Su origen (propio, de terceros). - Propietario del proceso. - Empresa de ingeniera licenciada. - Suministradores de equipos principales.

2.

Su Importancia en el desarrollo de Sistemas de Informacin Empresariales.

Teora del proyecto tecnolgico Tericamente, un proyecto tecnolgico no es distinto de cualquier otro, salvo en su objeto: un cambio organizacional que afecta el mbito de negocios por la influencia y uso conveniente y oportuno de las tecnologas de la informacin. Y, como tal, la operacin de un proyecto de SI comprende la ejecucin de una serie de actividades de gestin y de construccin tendientes a proveer una determinada solucin tecnolgica a una estrategia de negocios. Este planteamiento terico y operacional de un proyecto e-Business muestra la multidimensionalidad de este tipo de proyectos, reflejado en la figura 3. En un proyecto de SI distinguimos la concurrencia de: Dos dimensiones: la dimensin de gestin y la dimensin de construccin. Dos visiones: visin de negocios y la visin tecnolgica.

12

Figura 3: Elementos en un proyecto e-Business. Segn esto ltimo, en el proyecto de SI concurren una serie de conocimientos. La figura 4 destaca los tipos de conocimientos a considerar:

Figura 4: El proyecto e-Business.

13

De esta manera, las dimensiones permiten construir la iniciativa o solucin tecnolgica en una organizacin (figura 5) como un conjunto de aplicaciones de base tecnolgica (figura 6), operando dentro de los sistemas de trabajo bajo una ptica de negocios y tecnolgica.

Figura 5: La solucin e-Business.

Figura 6: Alcance de aplicaciones e-Business.

14

Visin de negocios y tecnolgica De una u otra manera, un proyecto de SI comprende una visin de manejo integrado de la informacin organizacional, cuya puesta en escena puede abordarse como un proyecto de sistemas de informacin. En este caso se distingue la visin de negocios y la visin tecnolgica. La visin de negocios aporta e introduce el marco organizacional y estratgico dentro del cual se enmarca todo el proyecto de SI, vale decir, es la visin que sostiene la iniciativa o solucin tecnolgica. La implantacin de esta visin se traduce en un proyecto de negocios, entendido como todo el proceso gracias al cual una idea de negocios se concreta. La visin tecnolgica aporta al proyecto tecnolgico un habilitador y un facilitador tecnolgico. Por ejemplo, en un proyecto e-Business, la visin tecnolgica aporta elementos, tanto para el propio proyecto (por ejemplo, herramientas para un eProject donde usar desarrollos RAD cuya gestin se sustenta en un software MS project) como para la solucin e-Business (Internet, redes WAN, etc.).

Dimensiones de gestin y de construccin Como todo proyecto, un proyecto de SI requiere identificar una dimensin de gestin y otra de construccin. La gestin del proyecto aporta un conjunto de instrumentos que permiten conseguir los objetivos de un proyecto cualquiera. Como parte de la gestin, se debe considerar la visin de negocios y la utilizacin de tecnologa. La construccin del proyecto, expresada de mejor manera como la metodologa de un proyecto de SI, permite conducir el proyecto integrando la visin de negocios que lidera la idea organizacional y la visin tecnolgica que sustenta la estrategia de negocios.

3.

La Administracin de Proyectos de Ingeniera de Sistemas propiamente dichos.

Gestin de Proyectos es una dimensin dentro de un proyecto y no es en s el proyecto (figura 7). Esto muestra, por una parte, la dependencia de la gestin de proyecto al tipo de proyecto dentro del cual participa y, por otra parte, la existencia de una serie de limitaciones debidas a la existencia y oportunidad de determinados recursos, imposiciones y condiciones del medio, y compromisos y restricciones organizacionales. Todo en su conjunto produce un paquete de documentacin, el cual contiene y refleja la historia del proyecto en todas las reas en que se haya desenvuelto, y la evolucin del resultado finalmente obtenido con la metodologa de SI.

15

Imposiciones y condiciones del medio Composicin y restricciones organizacin

Recursos humanos, materiales y econmico financieros

Documentacin del proyecto Iniciativa de SI

Gestin de proyectos

Aplicacin de SI
Metodologa

Proyecto de SI Figura 7: La gestin de proyectos en un proyecto. En particular, la gestin de proyectos para un proyecto de SI se enfoca en buscar un marco estructurado para la gestin exitosa, buscando aportar un completo conjunto de herramientas y tcnicas para integrar la propia filosofa de SI, la gestin de proyectos, la calidad y el desarrollo de sistemas informticos en un todo coherente.

3.1

Nocin de gestin de proyectos

Gestin de Proyectos es una dimensin dentro de un proyecto y no es en s el proyecto. Por ello es conveniente revisar de qu manera el proyecto englobador cambia la visin a tener respecto de cmo usar la gestin de proyectos. La gestin de proyectos intenta conseguir una planificacin coherente con los objetivos de una organizacin y del propio proyecto, igualmente que el desarrollo del proyecto se acerque a lo planificado y supere las vicisitudes del medio y del da a da.

16

Se encarga de planificar, dirigir y controlar el desarrollo de un sistema aceptable con un costo mnimo y dentro de un perodo de tiempo especifico. Como una manera de proveer un lenguaje universal y comn entre los profesionales de proyectos, el Project Management Institute ha desarrollado el PMBOK, un documento con el cual se espera que la prctica de gestin de proyectos se convierta en un cuerpo doctrinal y referencial para los profesionales del rea. Por esta razn se presenta la gestin de proyectos desde el punto de vista del PMBOK. En la seccin 1 se plante que el concepto de proyectos difiere segn diversas visiones, adems que un proyecto es un sistema dentro del cual coexisten dos dimensiones, la de gestin y la de construccin. Segn esto, la gestin de proyectos es un sistema que debe construirse y ser adaptado al punto de vista de proyecto que se maneje. Proyecto como produccin de artefactos. Aqu por gestin se entiende la programacin de actividades y ver que se cumplan. Proyecto como consecucin de objetivos. Aqu el proyecto es un conjunto de actividades concretas para un determinado resultado, y la gestin intenta que tales actividades cumplan con las necesidades presupuestas de antemano, siendo en esencia una anticipacin a un objetivo o a un estado de realidades predefinidas. Proyecto de accin. Aqu el proyecto persigue finalidades, sin necesidad de seguir un plan de trabajo. El proyecto es actuar siguiendo finalidades o fines y la gestin es poder anticiparse a las transformaciones o cambios de estado del proyecto y del entorno que se producen conforme la finalidad se va alcanzando o alejando. Para ilustrar las diferencias entre el tipo de gestin de proyectos que uno u otro tipo de proyecto requiera, se puede decir lo siguiente: en los primeros dos casos, el gestor de proyectos parte de que conoce qu conseguir y para ello busca y se nutre de varios cmos, cundos, quines y cuntos; y,

17

en el ltimo caso, el gestor de proyectos debe ayudar a buscar el qu se desea, para lo cual dispone de varios cmos que le ayudan a conseguir el qu. Sin embargo, aceptando cierto grado de formalizacin respecto de la gestin de proyectos asociada al proyecto como productor de artefactos, debido a que es ms sencillo controlar y regular recursos respecto cuando hay una meta clara, que cuando ella no existe (en este caso la meta es conseguir una meta), Kerzner sugiere que gestin de proyectos es la planificacin, organizacin, direccin y control de los recursos de una empresa para un objetivo de relativo corto plazo que ha sido establecido para completar y conseguir metas y objetivos especficos. Siguiendo con esta primera acepcin, Kirsch seala que gestin de proyectos es la aplicacin de tcnicas, mtodos, herramientas y heursticas formales e informales, las cuales emplea un gestor de proyectos en la motivacin y gua de un equipo de personas para llevar un proyecto dentro de un conjunto dado de restricciones. Visto as, la gestin de proyectos pone a disposicin de los gestores de proyectos un conjunto de instrumentos de trabajo que le permiten asumir un proyecto y superar sus vicisitudes tal que: se anticipe a los problemas, mejore el hacer futuro, y acte de forma adecuada ante eventos no presupuestados. En todo caso, debe tenerse claro que la gestin de proyectos es un medio a disposicin del gestor para construir una solucin dentro de las mejores condiciones para quienes estn dentro del proyecto y para quienes se beneficiarn del uso del producto o servicio resultante. Por este motivo, el gestor de proyectos es una persona cuyo fin es hacer uso armonioso de una serie de recursos intelectuales (conocimiento, creatividad) y corpreos (trabajo fsico, esfuerzo mental), con especial cuidado y atencin a las personas. Es una labor donde especialistas actan con libertad como parte de un todo (figura 8).

Figura 8: El fin de la gestin del proyecto.

18

El gestor de proyectos se destaca como la figura clave en la planificacin, ejecucin y control del proyecto y es el motor que ha de impulsar el avance del mismo mediante la toma de decisiones tendentes a la consecucin de los objetivos. El gestor de proyectos es un verdadero jefe, es decir, tiene poder ejecutivo y autoridad para mandar y tomar decisiones dentro del mbito y objetivos del proyecto. No es un mero coordinador o animador, como en algunas ocasiones se piensa. De la misma forma, tampoco sera correcto pensar que el gestor de proyectos tiene un poder absoluto y dictatorial sobre el mismo, ya que se encuentra inmerso en la estructura y organizacin de la empresa. Las relaciones bsicas del gestor de proyectos con otras unidades o personas dependen, en gran medida, de la estructura organizativa que posea la organizacin (figura 9).

Figura 9: El fin de la gestin del proyecto. Generalizando un poco, la gestin de proyectos se debe entender como un cmulo de informacin sobre instrumentos y prcticas que se pone a disposicin de personas para hacer un uso ptimo y robusto de recursos bajo su responsabilidad frente a restricciones y contingencias para el cumplimiento de metas trazadas de antemano. Todo lo anterior relacionado con tres parmetros clsicos de gestin: tiempo, coste y desempeo, para mejorar la calidad y conseguir un riesgo cero. No obstante, el valor agregado de esta informacin depender de la utilidad que le otorgue el gestor del proyecto: conseguir lo que se le pide, resolver un conflicto, aprender del hacer haciendo y, salir airoso de las vicisitudes diarias. Esto depender de la habilidad que adquiera, tanto por capacidad personal como resultado de un proceso de formacin. Por ltimo, existe el caso de una gestin orientada a dar un valor especial al gestor como evaluador de opciones futuras, tal como se ilustra en la figura 10, ante vicisitudes.
19

Figura 10: La gestin y sus vicisitudes. 3.2 Gestin de Proyectos de Software En el prefacio de su libro sobre gestin de proyectos de software, Meiler Page-Jones [PAG85] dice una frase que pueden corroborar muchos asesores de ingeniera del software: He visitado docenas de empresas, buenas y malas, y he observado a muchos administradores de proceso de datos, tambin buenos y malos. Frecuentemente, he visto con horror cmo estos administradores luchaban intilmente contra proyectos de pesadilla, sufriendo por fechas lmite imposibles de cumplir, o que entregaban sistemas que decepcionaban a sus usuarios y que devoraban ingentes cantidades de horas de mantenimiento. Lo que describe Page-Jones son sntomas que resultan de una serie de problemas tcnicos y de gestin. Sin embargo, si se hiciera una autopsia de cada proyecto, es muy probable que se encontrara un denominador comn constante: una dbil gestin.

20

Roger Pressman en la 1uinta edicin de su publicacin Ingeniera del Software, un enfoque prctico, define: La gestin eficaz de un proyecto de software se centra en las cuatro Ps: personal, producto, proceso y proyecto. El orden no es arbitrario. El gestor que se olvida de que el trabajo de ingeniera del software es un esfuerzo humano intenso nunca tendr xito en la gestin de proyectos. Un gestor que no fomenta una minuciosa comunicacin con el cliente al principio de la evolucin del proyecto se arriesga a construir una elegante solucin para un problema equivocado. El administrador que presta poca atencin al proceso corre el riesgo de arrojar mtodos tcnicos y herramientas eficaces al vaco. El gestor que emprende un proyecto sin un plan slido arriesga el xito del producto. 3.2.1. Personal La necesidad de contar con personal para el desarrollo del software altamente preparado y motivado se viene discutiendo desde los aos 60 (por ejemplo, [COUSO,WT94, DEM981]). De hecho, el factor humano es tan importante que el Instituto de Ingeniera del Software ha desarrollado un Modelo de madurez de la capacidad de gestin de personal (MMCGP) para aumentar la preparacin de organizaciones del software para llevar a cabo las cada vez ms complicadas aplicaciones ayudando a atraer, aumentar, motivar, desplegar y retener el talento necesario para mejorar su capacidad de desarrollo de software [CUR94]. El modelo de madurez de gestin de personal define las siguientes reas clave prcticas para el personal que desarrolla software: reclutamiento, seleccin, gestin de rendimiento, entrenamiento, retribucin, desarrollo de la carrera, diseo de la organizacin y del trabajo y desarrollo cultural y de espritu de equipo. El MMCGP es compaero del modelo de madurez de la capacidad software (CMMI), que gua a las organizaciones en la creacin de un proceso de software maduro. Los participantes Gestores superiores Gestores (tcnicos) del proyecto Profesionales Clientes Usuarios finales Para ser eficaz, el equipo del proyecto debe organizarse de manera que maximice las habilidades y capacidades de cada persona. Y este es el trabajo del jefe del equipo. Los jefes de equipo El equipo de software Aspectos sobre la coordinacin y comunicacin Informal Comunicacin electrnica Red interpersonal

3.2.2. Producto

21

Antes de poder planificar un proyecto, se deberan establecer los objetivos y el mbito del producto1, se deberan considerar soluciones alternativas e identificar las dificultades tcnicas y de gestin. Sin esta informacin, es imposible definir unas estimaciones razonables (y exactas) del coste; una valoracin efectiva del riesgo, una subdivisin realista de las tareas del proyecto o una planificacin del proyecto asequible que proporcione una indicacin fiable del progreso. El desarrollador de software y el cliente deben reunirse para definir los objetivos del producto y su mbito. En muchos casos, esta actividad empieza como parte del proceso de ingeniera del sistema o del negocio y contina como el primer paso en el anlisis de los requisitos del software. Los objetivos identifican las metas generales del proyecto sin considerar cmo se conseguirn (desde el punto de vista del cliente). El mbito identifica los datos primarios, funciones y comportamientos que caracterizan al producto, y, ms importante, intenta abordar estas caractersticas de una manera cuantitativa. Una vez que se han entendido los objetivos y el mbito del producto, se consideran soluciones alternativas. mbito del software El mbito se define respondiendo a las siguientes cuestiones: Contexto Objetivos de informacin Funcin y rendimiento Descomposicin del problema La descomposicin del problema, denominado a veces particionado o elaboracin del problema, es una actividad que se asienta en el ncleo del anlisis de requisitos del software. Durante la actividad de exposicin del mbito no se intenta descomponer el problema totalmente. Ms bien, la descomposicin se aplica en dos reas principales: (1) la funcionalidad que debe entregarse y (2) el proceso que se emplear para entregarlo. 3.2.3. Proceso Un proceso de software proporciona la estructura desde la que se puede establecer un detallado plan para el desarrollo del software. Un pequeo nmero de actividades estructurales se puede aplicar a todos los proyectos de software, sin tener en cuenta su tamao o complejidad. Diferentes conjuntos de tareas-tareas, hitos, productos del trabajo y puntos de garanta de calidad- permiten a las actividades estructurales adaptarse a las caractersticas del proyecto de software y a los requisitos del equipo del proyecto. Finalmente, las actividades protectoras -tales como garanta de calidad del software, gestin de la configuracin del software y medicin- cubren el modelo de proceso.
1

En este contexto, el trmino producto es usado para abarcar cualquier software que ser construido a peticin de otros. Esto incluye no slo productos de software, sino tambin sistemas basados en computadora, software empotrado y software de resolucin de problemas (por ejemplo, programas para la resolucin de problemas cientficos/de ingeniera).

22

Las actividades protectoras son independientes de las estructurales y tienen lugar a lo largo del proceso. Las fases genricas que caracterizan el proceso de software definicin, desarrollo y soporte- son aplicables a todo software. El problema es seleccionar el modelo de proceso apropiado para la ingeniera del software que debe aplicar el equipo del proyecto. Maduracin del producto y del proceso La planificacin de un proyecto empieza con la maduracin del producto y del proceso. Todas las funciones que se deben tratar dentro de un proceso de ingeniera por el equipo de software deben pasar por el conjunto de actividades estructurales que se han definido para una organizacin de software. Asuma que la organizacin ha adoptado el siguiente conjunto de actividades estructurales:

Comunicacin con el cliente- tareas requeridas para establecer la obtencin de requisitos eficiente entre el desarrollador y el cliente. Planificacin- tareas requeridas para definir los recursos, la planificacin temporal del proyecto y cualquier informacin relativa a l. Anlisis del riesgo- tareas requeridas para valorar los riesgos tcnicos y de gestin. Ingeniera- tareas requeridas para construir una o ms representaciones de la aplicacin. Construccin y entrega- tareas requeridas para construir, probar, instalar y proporcionar asistencia al usuario (por ejemplo: documentacin y formacin). Evaluacin del cliente- tareas requeridas para obtener informacin de la opinin del cliente basadas en la evaluacin de las representaciones de software creadas durante la fase de ingeniera e implementadas durante la fase de instalacin. Los miembros del equipo que trabajan en cada funcin aplicarn todas las actividades estructurales. En esencia, se crea una matriz similar a la que se muestra en la figura
23

anterior. Cada funcin principal del problema (la figura contiene las funciones para el software procesador de textos) se lista en la columna de la izquierda. Las actividades estructurales se listan en la fila. Descomposicin del proceso Un equipo de software debera tener un grado significativo de flexibilidad en la eleccin del paradigma de ingeniera del software que resulte mejor para el proyecto y de las tareas de ingeniera del software que conforman el modelo de proceso una vez elegido. Un proyecto relativamente pequeo similar a otros que se hayan hecho anteriormente se debera realizar con el enfoque secuencial lineal. Si hay lmites de tiempo muy severos y el problema se puede compartimentar mucho, el modelo apropiado es el DRA (en ingls RAD rapid application development). Si la fecha lmite est tan prxima que no va a ser posible entregar toda la funcionalidad, una estrategia incremental puede ser lo mejor. Similarmente, proyectos con otras caractersticas (p. ej.: requisitos inciertos, nuevas tecnologas, clientes difciles, potencialidad de reutilizacin) llevarn a la seleccin de otros modelos de proceso. 3.2.4. Proyecto Dirigimos los proyectos de software planificados y controlados por una razn principal -es la nica manera conocida de gestionar la complejidad-. Y todava seguimos esforzndonos. En 1998, los datos de la industria del software indicaron que el 26 por 100 de proyectos de software fallaron completamente y que el 46 por 100 experimentaron un desbordamiento en la planificacin y en el coste [REE99]. Aunque la proporcin de xito para los proyectos de software ha mejorado un poco, nuestra proporcin de fracaso de proyecto permanece ms alto del que debera ser2. Para evitar el fracaso del proyecto, un gestor de proyectos de software y los ingenieros de software que construyeron el producto deben eludir un conjunto de seales de peligro comunes; comprender los factores del xito crticos que conducen a la gestin correcta del proyecto y desarrollar un enfoque de sentido comn para planificar, supervisar y controlar el proyecto. Para gestionar un proyecto de software con xito, debemos comprender qu puede ir mal (para evitar esos problemas) y cmo hacerlo bien. En un excelente documento sobre proyectos de software, John Reel [REE99] define diez seales que indican que un proyecto de sistemas de informacin est en peligro: 1. 2. 3. 4. 5.
2

La gente del software no comprende las necesidades de los clientes. El mbito del producto est definido pobremente. Los cambios estn mal realizados. La tecnologa elegida cambia. Las necesidades del negocio cambian [o estn mal definidas].

Dadas estas estadsticas, es razonable preguntarse cmo el impacto de las computadoras contina creciendo exponencialmente y la industria del software contina anunciando el crecimiento de ventas al doble. Parte de la respuesta, pienso, es que un importante nmero de estos proyectos (fallidos) estn mal concebidos desde el primer momento. Los clientes pierden el inters rpidamente (puesto que lo que ellos pidieron realmente no era tan importante como ellos haban pensado), y los proyectos son cancelados.
24

6. Las fechas de entrega no son realistas. 7. Los usuarios se resisten. 8. Se pierden los patrocinadores [o nunca se obtuvieron adecuadamente]. 9. El equipo del proyecto carece del personal con las habilidades apropiadas. 10. Los gestores [y los desarrolladores] evitan buenas prcticas y sabias lecciones. Cmo acta un gestor para evitar los problemas sealados anteriormente? Reel [REE99] sugiere una aproximacin de sentido comn a los proyectos de software dividida en cinco partes: Empezar con el pie derecho. Mantenerse Seguimiento del progreso Tomar Decisiones Inteligentes Realizar un Anlisis Postmortem (despus de finalizar el proyecto). 3.3 Prcticas Crticas Gestin formal del riesgo. Coste emprico y estimacin de la planificacin. Gestin de proyectos basada en mtricas Seguimiento del valor ganado. Seguimiento de defectos frente a objetivos de calidad. Gestin del programa del personal.

4.

Ciclo de vida de un Proyecto de Ingeniera de Sistemas de Software.

Qu es? La planificacin implica la estimacin -su intento por determinar cunto dinero, esfuerzo, recursos, y tiempo supondr construir un sistema o producto especfico de software-. Quin lo hace? Los gestores del software -utilizando la informacin solicitada a los clientes y a los ingenieros de software y los datos de mtricas de software obtenidos de proyectos anteriores-. Por qu es importante? Podra construir una casa sin saber cunto estara dispuesto a gastar?. Por supuesto que no, y puesto que la mayora de los sistemas y productos basados en computadora cuestan considerablemente ms que construir una casa grande, podra ser razonable desarrollar y estima antes de empezar a construir el software. Cules son los pasos? La estimacin comienza con una descripcin del mbito del producto. Hasta que no se delimite el mbito no es posible realizar una estimacin con sentido. El problema es entonces descompuesto en un conjunto de problemas de menor tamao y cada uno de stos se estima guindose con datos histricos y con la experiencia. Es aconsejable realizar las estimaciones utilizando al menos dos mtodos diferentes (como comprobacin). La complejidad y el riesgo del problema se considera antes de realizar una estimacin final.

25

Cul es el producto obtenido? Se obtiene una tabla que indica las tareas a desarrollar, las funciones a implementar, y el coste, esfuerzo y tiempo necesario para la realizacin de cada una. Tambin se obtiene una lista de recursos necesarios para el proyecto. Cmo puedo estar seguro de que lo he hecho correctamente? Esto es difcil, puesto que realmente no lo sabr hasta que el proyecto haya finalizado. Sin embargo, si tiene experiencia y sigue un enfoque sistemtico, realiza estimaciones utilizando datos histricos slidos, crea puntos de estimacin mediante al menos dos mtodos diferentes y descompone la complejidad y riesgo, puede estar seguro de haber acedado plenamente. 4.1 Procesos de gestin de proyectos

Los Procesos de Gestin de Proyectos son el eje de toda la propuesta del PMBOK (tabla 2.2), constituyendo el centro de las mejores prcticas de gestin de proyectos. En la codificacin X.Y de cada proceso, la X indica el nmero de rea de conocimiento a la cual pertenece, mientras la Y es un correlativo. A cada proceso se le asocian entradas y salidas y un conjunto de herramientas y tcnicas de gestin. Esta representacin de la gestin de proyectos, ha sido una de las principales aportaciones del PMBOK al mundo de la investigacin y de la profesin de proyectos, al mostrar de manera clara que existen, por una parte, procesos de gestin y, por otra parte, herramientas y tcnicas donde, los primeros usan las segundas a conveniencia segn necesidades y habilidades del gestor y de los participantes. Los procesos de gestin de proyectos son presentados como elementos que contienen interfaces definidas. Sin embargo, en la prctica los procesos interactan de diferentes maneras, lo que nos lleva a reconocer que hay ms de una manera de administrar un proyecto. La aplicacin de estos procesos a un proyecto es iterativa y muchos de los procesos son repetidos y revisados durante el proyecto. Un concepto importante para definir la interaccin entre los procesos de gestin de proyectos es el ciclo de plan-do-check-act(planificar-hacer-chequear-actuar). En donde el resultado de una parte del ciclo se convierte en la entrada de la siguiente parte. El ciclo se muestra en la figura 2.17.

26

Figura 2.17: Ciclo plan-do-check-act. El ciclo mencionado anteriormente es muy sencillo para definir la naturaleza integradora de los grupos de procesos, sin embargo puede aplicarse a las interrelaciones entre los grupos, de forma extendida, como muestra la figura 2.18.

Figura 2.18: Ciclo plan-do-check-act aplicado a grupos de procesos. PROCESO DE GESTIN DE PROYECTOS

DESCRIPCIN

Gestin de la Integracin Desarrollo del cuadro Desarrollar un plan de proyecto que autorice formalmente de proyecto (p charter) al proyecto o una fase del proyecto.

4.1

27

4.2

Desarrollo de alcance de proyecto preliminar

Desarrollar el alcance del proyecto en una narrativa de alto nivel. Documentar las acciones necesarias para definir, preparar, integrar y coordinar todos los planes subsidiarios en un plan de gestin de proyecto.

4.3

Desarrollo del plan de gestin de proyecto

4.4

Direccin y Gestin de Ejecutar las tareas definidas en el plan de gestin de la ejecucin del proyecto. proyecto Controlar los procesos usados para iniciar, planificar, ejecutar y cerrar el proyecto de manera que coincidan con los objetivos descritos en el plan. Revisar todos los cambios solicitados, aprobados y realizados. Finalizar las actividades de todos los grupos de proceso, para cerrar formalmente el proyecto o la fase de proyecto.

4.5

Monitoreo y control de tareas del proyecto

4.6

Control de Cambios Integrado

4.7

Cierre del proyecto

Gestin del Alcance Desarrollar un plan de gestin del alcance que indique cmo ser definido, verificado y controlado, y cmo ser creada la WBS. Desarrollar un informe escrito del alcance que sirva de base para las futuras decisiones del proyecto.

5.1

Planificacin del alcance

5.2

Definicin del alcance

5.3

Creacin de un WBS (Work Breakdown Structure) Verificacin del alcance Control del Alcance

Subdividir las principales entregas del proyecto en componentes ms pequeos y manejables.

5.4

Aceptar formalmente que los entregables del proyecto han sido completados. Controlar los cambios en el alcance del proyecto.

5.5

Gestin del tiempo

28

6.1

Definicin de actividades

Identificar las actividades especficas que se deben desarrollar para cumplir con las principales entregas del proyecto. Identificar y documentar las distintas interrelaciones entre actividades.

6.2

Secuenciacin de las actividades Estimacin de los recursos de las actividades Estimacin de la duracin de las actividades

6.3

Estimar el tipo y cantidad de recursos necesarios para desarrollar cada actividad.

6.4

Estimar el nmero de jornadas laborales que se necesitarn para terminar cada actividad.

6.5

Desarrollo del programa

Analizar la secuencia de actividades, duraciones, requerimientos de recursos y restricciones para elaborar el programa del proyecto. Controlar los cambios del programa del proyecto.

6.6

Control del programa

Gestin del Coste Desarrollar una aproximacin (estimacin) de los costes de los recursos necesarios para completar las actividades del proyecto. Asignar la estimacin general de costes a cada uno de los elementos de trabajo para establecer un coste base. Identificar los factores que generan variaciones de costes y controlar los cambios que se produzcan en el presupuesto del proyecto.

7.1

Estimacin de costes

7.2

Presupuesto de costes

7.3

Control de costes

Gestin de la Calidad Planificacin de la calidad Identificar qu normas de la calidad son relevantes al proyecto y determinar cmo cumplirlas.

8.1

8.2

Ejecucin del

Aplicar las actividades planificadas para asegurar que el

29

Aseguramiento de la calidad

proyecto emplea todos los procesos necesarios para cumplir con los requerimientos de las normas. Realizar un seguimiento de los resultados especficos del proyecto para determinar si cumplen las normas ms importantes sobre la calidad e identificar la manera de eliminar las causas de un desarrollo no satisfactorio.

8.3

Ejecucin del Control de la calidad

PROCESO DE GESTIN DE PROYECTOS

DESCRIPCIN

Gestin de Recursos Humanos Identificar, documentar y asignar las funciones, responsabilidades y relaciones jerrquicas del proyecto, y crear el plan de gestin de personal. Reunir los recursos humanos que sea necesario asignar al trabajo del proyecto. Desarrollar las aptitudes individuales y de grupo para mejorar el desarrollo del proyecto. Hacer seguimiento del rendimiento de cada miembro del equipo, cambiando y mejorando factores que mejoren el desarrollo del proyecto.

9.1

Planificacin de los Recursos Humanos

9.2

Adquisicin de equipo de proyecto Desarrollo del equipo de proyecto

9.3

9.4

Gestin del equipo de proyecto

Gestin de las Comunicaciones Determinar las necesidades de informacin y comunicaciones de las entidades involucradas en el proyecto. Poner a disposicin de las entidades involucradas en el proyecto la informacin necesaria en el momento adecuado.

Planificacin de 10.1 comunicaciones

10.2

Distribucin de informacin

30

10.3 Informe de realizacin

Recopilar y distribuir la informacin sobre el desarrollo del proyecto. Esto incluye el informe de situacin, la evaluacin del progreso y las previsiones. Manejar las comunicaciones para satisfacer los requerimientos y resolver los factores relacionados con las entidades involucradas en el proyecto.

Gestin de las 10.4 Entidades

Gestin del Riesgo Planificacin de la gestin de riegos Decidir el enfoque, plan y ejecucin de las actividades de gestin del riesgo del proyecto. Determinar qu tipo de riesgos es probable que afecten al proyecto y documentar las caractersticas de cada uno de ellos. Evaluar la probabilidad de ocurrencia e impacto de los riesgos y priorizar los riesgos para su anlisis o accin futura.

11.1

Identificacin de 11.2 riesgos

11.3

Anlisis cualitativo de riesgos

11.4

Anlisis cuantitativo de Analizar numricamente el efecto de los riesgos riesgos identificados sobre los objetivos del proyecto. Desarrollar procedimientos y tcnicas para mejorar las oportunidades y reducir las amenazas respecto de los objetivos del proyecto. Monitorear los riesgos residuales, identificar nuevos riesgos, ejecutar planes de reduccin de riesgos y evaluar su efectividad a lo largo del ciclo de vida del proyecto.

Planificacin de las 11.5 respuestas a riesgos

11.6

Monitoreo y control de riesgos

Gestin del Abastecimiento Planificacin de 12.1 Compras y Adquisiciones Planificacin de la contratacin

Determinar qu aprovisionar y cundo.

12.2

Documentar los productos y servicios requeridos e identificar los potenciales suministradores.

31

12.3

Peticin de respuestas Obtener presupuestos, ofertas y propuestas adecuadas. de proveedores Seleccin de proveedores Administracin del contrato Revisar las ofertas, escoger a los posibles proveedores y negociar un contrato escrito con cada uno de ellos. Manejar el contrato y la relacin entre el comprador y el vendedor. Completar y establecer cada contrato, incluyendo la resolucin de cualquier tema abierto, y finalizar la relacin contractual.

12.4

12.5

12.6 Cierre del contrato

Tabla 2.2. Procesos de gestin de proyectos.

4.2

Grupos de procesos de gestin

Los grupos de procesos de gestin, Project Management Process Groups, son agrupaciones de procesos de gestin de proyectos relacionados con las cinco fases de un proyecto: Iniciacin (IP), Planificacin (Pl), Control (CoP), Ejecucin (EP) y Cierre (ClP). Los grupos de procesos son independientes al rea de aplicacin o enfoque de la industria en donde se desarrolle el proyecto; sin embargo, tienen claras dependencias y se ejecutan en la misma secuencia para cada proyecto. El nivel de actividad de estos grupos de procesos durante el proyecto vara en el tiempo tal como ilustra la figura 2.19.

Figura 2.19: La interaccin de los grupos de procesos de gestin a lo largo del proyecto.
32

CDIGO

GRUPO DE PROCESOS Iniciacin

DESCRIPCIN

IP

Define y autoriza el proyecto o una fase del proyecto. Define y refina objetivos, y planifica las acciones necesarias para conseguir los objetivos y el alcance bajo el cual el proyecto fue concebido. Integra personal y dems recursos para llevar a cabo el plan de gestin del proyecto en cuestin. Ejecuta mediciones y monitoreos regulares del progreso, identificando las variaciones con respecto al plan, para as tomar acciones correctivas cuando sea necesario con el fin de lograr los objetivos del proyecto. Formaliza la aceptacin del producto, servicio o resultado, y conduce al proyecto o fase de proyecto hacia un trmino ordenado.

PP

Planificacin

EP

Ejecucin

CoP

Control

ClP

Cierre

Tabla 2.3. Grupos de procesos de gestin.

4.3

Relacin entre grupos, reas y procesos

La relacin entre grupos, reas y procesos se presenta en la tabla 2.4. En esta tabla, cada "x" indica la pertenencia de procesos de rea de conocimiento en un grupo de procesos. Aunque los procesos en cada rea pueden aparecer como elementos aislados con conexiones bien definidas, en la prctica pueden solaparse e interaccionar de una manera no detallada aqu. Estos procesos interaccionan entre ellos, as como con los procesos en las otras reas de desarrollo. Cada proceso puede requerir esfuerzos de una o ms personas o grupos de personas, segn sean las necesidades del proyecto. Generalmente, cada proceso ocurre al menos una vez en cada fase del proyecto.

33

IP PP EP CoP ClP Gestin de la Integracin Gestin del Alcance Gestin del Tiempo Gestin del Coste Gestin de la Calidad Gestin de Recursos Humanos Gestin de las Comunicaciones Gestin del Riesgo Gestin del Abastecimiento X X X X X X X X X X X X X X X X X X X X X X X X

Tabla 2.4. Relaciones entre grupos, reas y procesos.

5.

Variables en la administracin de Proyectos de Ingeniera de Sistemas.

Variable Gestin de proyectos en informtica Sin ser una bala de plata, la gestin de proyectos en informtica ha cobrado relevancia frente al reto del cambio de siglo (problema conocido como Y2K), el cambio al euro o la simple globalizacin. Ante ello se exige que un gestor de proyectos sea capaz de abordar cualquier tipo de proyecto informtico, manejando equipos multidisiciplinarios en su pluralidad curricular, cultural, social y psicolgica. No obstante, la gestin de proyectos desde la perspectiva formal del PMBOK es una desconocida en la Informtica. A pesar de esto ltimo, la Ingeniera de Software intenta proveer mtodos, tcnicas y herramientas de desarrollo, dentro de las cuales se incluyen algunas orientadas o consideradas de la gestin. En tal sentido, este apartado presenta el significado que adquiere la gestin de proyectos en informtica.

34

5.1

Los problemas comunes en Informtica

Para entender el rol de la gestin de proyectos en la Informtica es conveniente comenzar comprendiendo los problemas que existen en los proyectos informticos. a.- Tipos de problemas comunes Podemos decir que hay tres 'problemas comunes', dos de ellos habituales y, un tercero, de ndole social. a.1.- Necesidades no satisfechas o no identificadas En el caso de las necesidades no satisfechas o no identificadas, el error puede aparecer debido a que se omiten datos durante el desarrollo del proyecto, es por esto que es muy importante no saltar ninguna etapa del ciclo de vida del desarrollo de sistemas. Otra causa de insatisfaccin de necesidades es la mala definicin de las expectativas de un proyecto en sus orgenes, ya que si no estn bien definidos los requerimientos mximos y mnimos que el proyecto debe satisfacer desde el comienzo, los desarrolladores vern afectado su trabajo por el "sndrome de las necesidades que crecen" el cual les dejara hacer cambios en el proyecto en cualquier momento sin detenerse a pensar si esos cambios sern buenos para el proyecto como un todo (por supuesto todos estas modificaciones acarrearan alteraciones en los costos y en los tiempos de entrega). a.2.- Los habituales: atrasos y costes Uno de los rasgos caractersticos y sntoma de "normalidad informtica" es que los proyectos informticos se atrasan y se exceden en los presupuestos econmicos. Decir que el tiempo y dinero se duplican, triplican o cuadruplican ya no tiene sentido, es un hecho y tradicin del vulgo. Esto sucede debido a que un proyecto generalmente exige un estudio de viabilidad en el cual muchas veces no se incluyen datos completamente precisos de la cantidad de recursos que cada tarea consumir, y es en base a este estudio que se hacen estimaciones de los recursos totales que el proyecto va a necesitar. En cuanto al atraso, generalmente se debe a que los gestores del proyecto no son buenos gestionando los tiempos de entrega de cada una de las diferentes tareas que el proyecto involucra, es as que cuando tienen un retraso no son capaces de alterar los plazos de entrega finales creyendo que podrn recuperar el tiempo perdido. En general esta es una muy mala poltica de trabajo porque no siempre es posible acelerar otras tareas para ahorrar tiempo en la entrega final. Por ejemplo, Glass seala que el 40% de los proyectos informticos son cancelados por estos excesos; mientras, un 33% se enfrentan a cambios de tiempo, costes y alcance. Sin embargo, esta imagen no es propia de la informtica, por ejemplo Ribera, nos muestra algunos ejemplos dignos de mencin: El proyecto del Opera House de Sidney pas de 7 millones de dlares a 107 millones de dlares.
35

El proyecto de desarrollo del avin F-22 Raptor que ha superado un coste del billn de dlares. El proyecto del tnel del Canal de la Mancha, cuyo coste inicial de 7,5 billones a llegado a los 17,5 billones de dlares, y se termin en 1994 en lugar de 1992. Pero no es necesario pensar en esas grandes empresas humanas, cuya complejidad puede justificar cualquier superacin de estimaciones. Se puede pensar en el simple atraso en la construccin de un edificio, algo tan habitual y corriente que se nos pasa desapercibido. Lo que queremos decir es que fuera de la Informtica los proyectos tambin se atrasan y cuestan ms caros por motivos tan diversos y variopintos como los que se escuchan en informtica. Lo que es preocupante es que dentro de la Informtica estos problemas se manifiestan tanto a gran escala (como los ejemplos dados por Ribera) como a escala "casera", vindose afectado por tanto todo el tejido socio-econmico, incluyendo aspectos como el crecimiento organizacional, los planes de empresa, o el presupuesto de una PyME. a.3.- El social: la imposicin de los resultados Aparte de esos comunes problemas de tiempo y coste, est en lo que podra llamarse el problema de 'adopcin por decreto'. En muchas ocasiones los productos informticos son impuestos por las jerarquas administrativas sin una asimilacin y/o aceptacin del personal o los trabajadores. Segn ciertas culturas este tema resulta conflictivo y un problema a ser resuelto. Un caso de cultura que rechaza esta situacin es la escandinava, as, Iivari y Lyytinen destacan que los productos informticos son artefactos surgidos y definidos por quienes les usarn, los trabajadores. El problema es bsicamente de los principios ligados a la historia de la ingeniera, donde ella busca ser generadora de soluciones a las necesidades de la humanidad, aportando artefactos con un valor agregado y mrgenes de ganancia social siempre positivos para el 'hombre de la calle'. Esta visin se contradice con la costumbre informtica de imponer soluciones segn el ltimo avance en el rea, la ltima tendencia o lo que sencillamente hay que tener. Al final, ocurren ajustes de trabajo de ndole tayloristas que imponen aparentes mejores niveles de eficiencia, confundiendo: procesos de negocios ms eficientes con aumento de velocidad computacional, y/o mejoras de la eficacia en base a nuevas prcticas laborales con simples automatizaciones de prcticas de trabajo. En una sociedad del conocimiento este tipo de actitudes no son permitidas, pues es necesaria la participacin libre y colaborativa de todas las personas involucradas en un proceso de construccin de productos informticos, sean tanto diseadores de sistemas como usuarios finales. b.- Las consecuencias de los 'problemas comunes' Hoy en da los proyectos informticos se asumen que son un riesgo a correr, lo cual no evita que al final de un proyecto informtico se puedan plantear tres consecuencias:
36

b.1.- Desconfianza en el producto Una aparente desconfianza en el producto se nota en expresiones tales como: "al final se hizo a la ligera", "sencillamente... se remat", "apgalo, funcionar cuando lo prendas", o sencillamente "bueno, al final en software siempre salen cosas que algo hacen en pantalla". Si bien pueden ser sencillamente comentarios de paso, si es cierto que en los resultados informticos en la forma de software, infraestructuras y/o sistemas de informacin, todava no es posible erradicar el oscurantismo de una profesin que entrega productos con funcionamientos en ocasiones misteriosos y plenos de 'bugs'. b.2.- Desconfianza en la profesin La desconfianza en la profesin la sufren los practicantes de la informtica cuando se les pide evaluar un producto, calcular un coste o sencillamente dimensionar algn resultado. No se le puede pedir a un ingeniero informtico calcular o estimar un producto cuando las actuales herramientas no son seguras ni fiables. Esto ocurre en otras disciplinas, pero sencillamente la informtica est, diramos an en paales, llevando a justificar como vlido el multiplicar por dos, al menos, los costes y los tiempos planificados. En extenso, la consultora informtica puede llegar a ser un factor negativo al momento de la promocin profesional. b.3.- La crisis del usuario Pero hay otra consecuencia relevante. No es una desconfianza en lo que resulta del trabajo informtico o en lo que produce la formacin informtica, es la crisis del usuario. Se debe aceptar que la sociedad occidental postmoderna es una sociedad del riesgo. No una sociedad que vive experiencias al lmite, sino una sociedad que acepta en situaciones concretas mrgenes de riesgo como algo cotidiano y ticamente aceptable. Esta concepcin del mundo es ideal para la Informtica, donde an los proyectos son empresas de riesgo. No solamente en el mbito de desarrollo (por ejemplo un software) o de adaptacin (por ejemplo aplicaciones ERP), sino en el mbito de negocios (por ejemplo en e-Business). Es ms, puede resultar incluso curioso que frente a los problemas comunes de atrasos, sobre costes y productos no aceptados, los clientes aceptan este fenmeno. Pero no por estar en una sociedad que tolera el riesgo, la profesin informtica deba encaminarse hacia caminos donde la falla, el error y la incerteza sean aceptables y an ms, rasgo distintivo de la profesin. Hablamos de una crisis del usuario en analoga a la crisis del software1 (segn Gibbs). Mientras la ltima pregonaba los problemas de construir software, la primera alude a los problemas de quien debe soportar usar los resultados de los proyectos informticos. Esta crisis se debe a que quien recibe y usa el producto informtico, que debera estar mejor que antes, a veces no lo est tanto, al pasar, por ejemplo, un proceso manual robusto y probado, por un software con fallas y un sistema de mantenimiento deficiente.

37

Lo importante es que la visin escandinava de pensar en el trabajador debe estar presente. Pero si a alguien no le gusta esta concepcin del trabajo profesional, se puede tomar la lnea clsica de gestin de la calidad, la cual seala que es importante dar prioridad al sistema requirente. En una consultora informtica esto requiere el fuerte compromiso de resolver problemas, sensibilizndose el profesional de los problemas del usuario y atendiendo siempre a que su misin es resolver un problema sin aadir otros. c.- Las causas de los 'problemas comunes' Entre posibles causas de los problemas "comunes", se pueden sealar (Jurison): - naturaleza del producto; y, - problemas de gestin. c.1.- La naturaleza del producto Segn Jurisson y Pressman, el principal producto informtico, el software, se caracteriza por ser: - intangible; - invisible; - complejo; - voltil de requerimientos; - socio-tcnico; y, - difcil de medir. A continuacin hablaremos de cada uno de ellos. - Intangible. Pues claramente el resultado es un software el cual no se puede moldear manualmente, sino mentalmente, sin restricciones de leyes fsicas o lmites del proceso de manufactura. Lo cual, adems, produce que sea difcil detectar y prevenir errores. - Invisible. Pues la solucin que se provee es bsicamente un funcionamiento que toma prestadas funcionalidades de un hardware, sin que el hardware sea componente del sistema software. De hecho el hardware, incluso otro software o persona, solamente en tiempo real, y segn sus presentes condiciones de operacin garantizan o no prestar lo que el software les pida. - Complejo. Pues un desarrollo involucra muchas acciones y el producto comprende tambin muchas tareas, cuya comprensin supera las capacidades humanas.

38

- Volatilidad de requerimientos. Lo cual es sencillo de detectar por cuanto el desarrollo est siempre sujeto a presiones de cambio y que por ser software, el cambio es un estilo de vida. - Socio-tcnico. Un producto informtico no tiene sus fronteras en la pantalla ni en un usuario que teclea, o incluso un cliente que paga. Un sistema de informacin involucra varias piezas relacionadas conformando un sistema de trabajo donde encontramos que operadores manteniendo el sistema, software siguiendo algoritmos y hardware aportando infraestructura, interactan con otras personas, software y hardware. En este sentido, pensar que un producto informtico es slo hardware y software es un error, salvo excepciones muy concretas, pero la generalidad no muestra esta realidad, menos cuando se desean sistemas que soporten una solucin e-Business. - Difcil de medir. Por las otras cualidades sealadas y por la juventud de la Informtica, se hace difcil tener hoy en da tener tcnicas efectivas que permitan medir, y las que existen estn an en calibracin. c.2.- Problemas de gestin Entre los problemas de gestin aparecen mencionados entre otras cosas: objetivos y especificaciones pobremente definidas; falta de un plan de proyecto; presupuestos y plazos poco realistas; e inhabilidades de relaciones sociales. Haciendo una revisin de la literatura encontramos diversos problemas de gestin, los que se muestran comparativamente en latabla 3.3. Los problemas de gestin se presentan clasificados segn las reas de conocimiento de gestin de proyectos del PMBOK y paralelizados segn ciertas similitudes entre ellos. Para la lista de McConnell y Purba et al., entre parntesis se indica la categora en que estos autores clasifican sus problemas. Debemos recalcar que lo mostrado en la tabla es meramente referencial y no comprende todo el dominio de problemas existentes.
TIPO DE PROBLEMA DE GESTIN McCONNELL GLASS PURBA et al. REDMILL

Exceso de requerimientos (producto) GESTIN DE Planificacin INTEGRACIN Usuarios que resisten Incapacidad de los usuarios en comunicar requerimientos (elemento

Poca claridad en los requerimientos

39

humano) Abandono de tiempo en el inicio (proceso) Prdida de tiempo en el inicio Poltica organizacional (aspectos polticos)

Promotor est perdido

Poltica antes que desarrollo (personas)

Cambiar de herramientas a mitad del proyecto (tecnologa) Diseo inadecuado (proceso) Ejecucin Convergencia prematura o excesivamente frecuente (proceso)

Cambios tecnolgicos elegidos

Falla en el uso de metodologas del desarrollo

Falta de participacin del usuario (personas)

Equip. polticos (aspec. polticos) Poltica indiv. (aspec. polticos)

Aadir ms personal a un proyecto retrasado personas)

40

Tiras y aflojas en la negociacin (producto)

Mejores prcticas y lecciones son olvidadas

Mala gestin de las fases de desarrollo (elemento humano) Pruebas insuficientes (error humano)

Mala especificacin

Falta de control automtico del cdigo fuente (tecnologa) Cambios son pobremente gestionados Cambios en las prestaciones (producto) Incapacidad de acomodar cambios a requerimientos de negocios (elemento humano) Falta de control de cambios

Control

Cambios en las necesidades de negocio

TIPO DE PROBLEMA DE GESTIN

McCONNELL

GLASS

PURBA et al.

REDMILL

Desarrollo orientado a la investigacin (producto) Iniciacin GESTIN DEL ALCANCE Falta de un proyecto efectivo del proyecto (personas) Gestores no comprenden las Incapacidad de los usuarios en comprender las

Planificacin

41

necesidades implicaciones de de los los usuarios requerimientos de negocios (elemento humano) Mala planificacin (elemento humano) Expectativas poco realistas (elemento humano)

Planificacin insuficiente (proceso)

Alcance mal definido

Expectativas poco realistas (personas)

Sndrome de la panacea (tecnologa) Estrategia de implementacin dbil (elemento humano) Mejoras prcticas y lecciones son olvidadas Sobreestimacin de las ventajas del empleo de nuevas herramientas o mtodos (tecnologa) Ejecucin

Limitaciones

42

tcnicas Polticas de la unidad informtica de la organizacin (aspectos polticos) Mejoras prcticas y lecciones son olvidadas Control insuficiente de la directiva (proceso)

Control

TIPO DE PROBLEMA DE GESTIN

McCONNELL

GLASS

PURBA et al.

REDMILL

Omitir tareas necesarias en la estimacin (proceso) Estimaciones erradas Planificacin

Tiempo y presupuesto inadecuado

GESTIN DE COSTES

Estimaciones erradas No se hace estimacin

Escatimar en las actividades iniciales (proceso)

43

Control

Recursos insuficientes (elemento humano) Tiempo y presupuesto inadecuado. Estimaciones erradas No se hace estimacin Planificar ponindose al da ms adelante (proceso) Programa a destajo (proceso) Se carece del personal con las habilidades adecuadas Oficinas repletas y ruidosas (personas) Escatimar en el control de calidad (proceso)

Planificacin

Omitir tareas necesarias en la estimacin (proceso)

Plazos irreales

GESTIN DEL TIEMPO

Control

Planificacin

GESTIN DE LA CALIDAD

Ejecucin

Control

44

Ilusiones (personas) Motivacin dbil (personas) Personal mediocre (personas) Empleados problemticos incontrolados (personas) GESTIN DE RECURSOS HUMANOS Se carece de personal con habilidades adecuadas

Planificacin

Insuficientes habilidades tcnicas (elemento humano)

Pobres desarrolladores (elemento humano) Poltica individual (aspectos polticos)

Desarrolladores meticulosos (producto)

Ejecucin

Hazaas (personas) Fricciones entre los clientes y los desarrolladores (personas) Falta de participacin de los implicados (personas)

TIPO DE PROBLEMA DE GESTIN

McCONNEL L

GLASS

PURBA et al.

REDMIL L

GESTIN DE

Planificaci

Insuficientes habilidades

45

COMUNICACIONES

tcnicas (elemento humano) Estrategia de implementaci n dbil (elemento humano) Mejores prcticas y lecciones son olvidadas Se carece del personal con las habilidade s adecuada s Tiras y aflojas en la negociacin (personas) Falta de participacin del usuario (personas) Gestin de riesgo insuficiente (proceso) Tiras y aflojas en la negociacin

Ejecucin

Control

Cierre

Planificaci n GESTIN DEL RIESGO Control

46

(personas) Incapacidad para tratar con contratistas y vendedores (elemento humano) Incapacidad para tratar con contratistas y vendedores (elemento humano) Recursos insuficientes (elemento humano) Se carece del personal con las habilidade s adecuada s

Planificaci n

Fallos en los contratados (proceso)

Ejecucin GESTIN DEL APROVISIONAMIEN TO

Control

Cierre

5.2

Formas de evitar estos problemas

Para evitar todos estos posibles problemas, se debe tener al mando del proyecto un buen gestor que conozca muy bien las herramientas de diseo y anlisis de sistemas adems de una buena formacin en las funciones bsicas de direccin.

47

El director de proyectos no es simplemente un analista experimentado que se hace cargo del proyecto, sino ms bien debe aplicar un conjunto de tcnicas y conocimientos diferentes de los que aplica un analista. Las funciones bsicas de un gestor de proyectos han sido analizadas y diseccionadas por tericos de la gestin durante muchos aos. Entre estas funciones, se incluyen la planificacin, la seleccin de personal, la organizacin, la definicin de calendarios, la direccin y el control. a.- Planificacin de las tareas de proyecto y seleccin del equipo de proyectos Un buen director siempre tiene un plan. El director evala las necesidades de recursos y formula un plan para llegar al sistema objeto. Ello se basa en el conocimiento que tiene el director de los requisitos del sistema objeto en cada momento del desarrollo. Un plan bsico para el desarrollo de un sistema de informacin es el suministrado por el ciclo de vida del desarrollo de sistemas. Muchas empresas tienen su propio ciclo de vida estndar, y algunas de ellas tienen tambin normas sobre mtodos y herramientas que han de usarse. As ha de planificarse cada una de las tareas requeridas para completar el proyecto: Cunto tiempo se requerir? Cuntas personas sern necesarias? Cunto costara la tarea? Qu tareas deben terminarse antes de empezar otras? Pueden solaparse algunas de ellas? Estas son cuestiones propias de la planificacin. Algunas de ellas pueden resolverse con ayuda de un grfico PERT (Proyect Evaluation and Rewiev Technique) que fue desarrollado a finales de la dcada de 1950 - 1959 para planear y controlar los grandes proyectos de desarrollo armamentstico del ejrcito estadounidense. Fue desarrollado para evidenciar la interdependencia de las tareas de los proyectos cuando se realiza la planificacin de los mismos. En esencia, PERT es una tcnica de modelos grficos interrelacionados. Los gestores de los proyectos son, frecuentemente, los encargados de seleccionar a los analistas y los programadores de un equipo de proyecto. El gestor debera tener muy en cuenta los conocimientos tcnicos y de empresa que pueden ser necesarios para terminar un proyecto con xito. La clave de esta misin es saber elegir adecuadamente a las personas que habran de desarrollar las tareas requeridas e identificada como parte de la planificacin de proyecto. b.- Organizacin y definicin de calendarios para el proyecto Dados el plan y el equipo de proyecto, el gestor de proyectos es el responsable de la organizacin y la definicin del calendario del mismo. Los miembros del equipo de proyecto debern conocer su cometido y sus responsabilidades concretas, as como su relacin de dependencia con el respecto al gestor del proyecto.

48

El calendario de proyecto debera desarrollarse con un conocimiento preciso de los requisitos de tiempo, las asignaciones de personal y las dependencias de unas tareas con otras. Muchos proyectos tienen un lmite a la fecha de entrega solicitada. El gestor debe determinar si puede elaborarse un calendario factible basado en dicha fecha. Si no fuera as, debera retrasarse el lmite o reajustarse el mbito del proyecto. c.- Direccin y control del proyecto Una vez iniciado el proyecto, el gestor del proyecto se convierte en su mximo responsable. Como tal, dirige las actividades del equipo y hace evaluaciones del avance del proyecto. Por consiguiente, todo gestor de proyectos debe demostrar ante su equipo cualidades de direccin, como son saber motivar, recompensar, asesorar, coordinar, delegar funciones y reconocer el trabajo de los miembros de su equipo. Adems, el gestor debe informar frecuentemente del avance del proyecto ante sus superiores. Tal vez, la funcin ms difcil e importante del gestor sea controlar el proyecto. Pocos planes hay que puedan llevarse a la prctica sin problemas y retrasos. La labor del gestor de proyectos es hacer un seguimiento de las tareas, los plazos, los costes y las expectativas, con el fin de controlar todos los estos elementos. Si el mbito del proyecto tiende a crecer, el gestor del mismo debe tomar una decisin: habra que reducir el mbito del proyecto para respetar el presupuesto y los plazos, o revisar dicho presupuesto y dichos plazos? El gestor del proyecto debera ser capaz de presentar alternativas, y sus implicaciones, a los plazos y presupuestos para saber responder a las expectativas.

49