1

UNIVERSIDAD ALAS PERUANAS FACULTAD DE INGENIERÍAS Y ARQUITECTURA

ESCUELA PROFESIONAL DE INGENIERÍA DE SISTEMAS E INFORMÁTICA

CURSO: DISEÑO Y EVALUACIÓN DE PROYECTOS

Ing. Félix Richar Mendoza Pumacahua Docente

Semana 03: Administración de Proyectos de Ingeniería de Sistemas. Su Importancia en el desarrollo de Sistemas de Información Empresariales. La Administración de Proyectos de Ingeniería de Sistemas propiamente dichos. Ciclo de vida de un Proyecto de Ingeniería de Sistemas de Software. Variables en la administración de Proyectos de Ingeniería de Sistemas. Introducción Los proyectos no son nuevos. Las pirámides egipcias, el Partenón griego, la gran muralla china, son ejemplos de la empresa humana ejecutadas en la forma de proyectos. Aún más, la Creación del Mundo es un proyecto ejecutado en 6 días, medido en días, con recursos supuestamente ilimitados y con un resultado dejado en manos y juicio de los usuarios... Adán y Eva. La lista anterior puede aumentarse con cosas más cotidianas. Terminar el material de estudio de esta semana, terminar el mes dentro de ciertos gastos, un estudio de doctorado. Por supuesto están los llamados formalmente proyectos de ingeniería, proyectos de arte, proyectos educativos, y muchos otros tipos, de entre los cuales los proyectos de Ingeniería de Sistemas son de interés debido a que permiten hacer un análisis de negocios y tecnológico para un proyecto tecnológico. Se quiere hacer ver que conceptualmente un proyecto de Ingeniería de Sistemas permite distinguir los dos elementos centrales a cualquier proyecto tecnológico: la dimensión de negocio y la dimensión tecnológica.

1. Proyectos: una visión teórica

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 término que, pese a ser de uso común, puede tomar significados diferentes y no siempre se emplea en el mismo sentido o con la precisión conveniente.

Proyecto, desde una perspectiva general y teórica, se puede definir como la acción

intencionada de hombres y/o mujeres hacia la consecución de un resultado o, el medio o

la acción organizacional mediante la cual una organización, empresa o negocio, busca

respuesta a un problema o conflicto. Tal acción da lugar a una solución instrumental, en la

forma de un producto o servicio.

2

Otra definición 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 realización- una situación problemática o una demanda

planteada". Completar con el éxito del proyecto significa cumplir con los objetivos, dentro

de las especificaciones técnicas, de costo y de plazo de terminación.

Un proyecto siempre da lugar a una solución. Esta solución tiene varias particularidades:

Es habitualmente injertada en la misma organización que la requirió, por lo cual la solución ha de ser coherente con la organización, tanto en el ámbito tecnológico como en el humano.

Surge instrumentalmente por un acuerdo entre proyectistas y clientes en razón de tiempo, costo, ganas y satisfacción en resolver un conflicto.

En sí misma requiere de una empatía y un equilibrio entre lo que se pide, desea o anhela, y lo que se puede con los medios humanos y tecnológicos.

Proyecto, desde un punto de vista más concreto, se concibe como una operación de envergadura y complejidad notables, singular, con unas fechas definidas de inicio y finalización. Es un trabajo no repetitivo, que ha de planificarse y realizarse según unas especificaciones técnicas determinadas, con un presupuesto preestablecido y una organización temporal con la participación de varios departamentos de la empresa que se desmantela cuando termina el proyecto, y que incluye, tal vez, la colaboración 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.

Persecución de uno o varios objetivos. Las actividades aisladas no constituyen por sí solas, un proyecto. Para que exista un proyecto, debe existir una coordinación de actos orientados a la consecución de uno o varios objetivos, integrados entre sí y estructurados, tanto de índole técnica como económica. En general, el objetivo general de un proyecto es satisfacer un conjunto de requisitos a un coste dado en las condiciones más eficientes.

Actividades planificadas, ejecutadas y supervisadas. La coordinación de actividades es condición sine-qua-non para que a las mismas, en su conjunto, se les pueda calificar de proyecto. De hecho, un proyecto exige que exista vinculación entre las actividades, puesto que persiguen un objetivo común. Esa vinculación debe plasmarse en forma de planificación (técnica, temporal y económica) cuya correcta ejecución supervisada es clave para el éxito o fracaso del proyecto.

Disponibilidad limitada de recursos. El proceso proyectual implica la búsqueda 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.

Limitación de tiempo. Un proyecto debe estar acotado en términos 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

3

estar acotado en el tiempo, no sucede lo mismo con sus resultados, que pueden perdurar con carácter indefinido (por ejemplo, una catedral).

Así, se puede llegar a decir que los proyectos se caracterizan en general por:

Tener objetivos específicos; Deben completarse dentro de un periodo determinado; Tener inicios y términos bien definidos; Deben completarse dentro de las restricciones de un presupuesto; Ser ejecutados por un equipo; y, Ser únicos.

1.1. Definición

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 más bien, formas en que se entiende un proyecto, todas ellas válidas, cuyo conocimiento permite mostrar visiones sesgadas de un mismo fenómeno.

- Es un esfuerzo conjunto de muchas personas -hombres y mujeres- que buscan el máximo beneficio en conseguir una solución razonable a un problema que se espera tenga la solución ideal.

- El proyecto es una operación que se expresa como una experiencia práctica cooperativa y colaborativa en la cual:

- se usan conceptos abstractos (por estar en dominios de conocimiento transversales) junto a conceptos técnicos (por estar en dominios aplicados concretos) que se manifiestan en documentos (por ser medio de expresión 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 investigación de problemas críticos.

- Es un conjunto autónomo de inversiones, políticas y medidas institucionales y de otra índole, diseñadas para lograr un objetivo específico (o serie de objetivos). Se puede definir como un modelo para las asignaciones de recursos, que tienen un tiempo de ejecución y se logran resultados medibles. También se identifica, como la menor unidad de actividades, que puede ser planificada y ejecutada aisladamente de la planificación de operación y sostenimiento de los servicios de Salud. Constituye la unidad operativa más pequeña que desde el punto de vista lógico, se presta para la planificación, el financiamiento y la ejecución 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

4

emergencia, con el fin de frenar el deterioro o continuar el desarrollo de los servicios sociales.

- Es un conjunto específico 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 situación actual para obtener una situación futura o esperada.

- Es la unidad operativa más pequeña que puede ser ejecutada en forma independiente o autónoma, constituida por un conjunto de actividades o tareas encadenadas en un orden lógico, destinadas a cumplir un fin específico a incidir en la magnitud de una o más variables, determinada por la realidad a la que se orienta.

- Es una información estructurada con valor agregado que permite la articulación de recursos humanos de diferentes estructuras de la organización 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 mayoría de los procesos humanos tiene carácter cíclico, y la clave de su dinámica es la transformación 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 serán los medios para producir otros bienes o servicios, y consta de 3 características fundamentales:

- Es un proceso finito, es decir, que se cuenta con un período 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 vacío de tareas estructuradas, que se desarrollan en un plazo de tiempo finito y acotado, con objetivos bien definidos acordes con su misión y que se alcanzan con la integración de las soluciones parciales de las tareas, a partir de un diseño con enfoque sistémico y en función de la visión, en el que se combinan los recursos con criterios de optimización, 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 finalización, llevadas a cabo para lograr un objetivo conforme con requisitos específicos, incluidas las limitaciones de tiempo, costo y recursos.

- El proyecto es una operación de ingeniería que involucra pasar de un sistema deseado a un sistema a ofrecer (ver figura 2), lo cual implica:

5

- ir de una idea inmaterial y difusa proveniente de un problema o necesidad a un ordenamiento técnico 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 producción de artefactos; y, Proyecto de acción.

Figura 1: Atributos principales asociados a la definición de proyecto.

Figura 2: Generalización del concepto de Proyecto.

6

a. Producción de artefactos

Un proyecto se comprende habitualmente como un medio para obtener un artefacto, un resultado material concreto. De entre las múltiples definiciones que plantea el proyecto en estos términos, es posible distinguir dos acepciones, ambas similares, pero apuntando a distintas finalidades según quien tiene la misión 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 documentación.

- Proyecto (según el Diccionario de la Lengua Española de la Real Academia Española):

"Planta y disposición que se forma para un tratado, o para la ejecución de una cosa de importancia, anotando y extendiendo todas las circunstancias principales que deben concurrir para su logro".

- Projecte, según 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 (según el Diccionario Oxford):

"Hacer planes para ('Make plans for')".

- Proyecto como consecución 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 propósito que debe ser alcanzado en un plazo establecido, dentro de un presupuesto y de acuerdo con unas especificaciones".

- Según 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'.)

- Según 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 acción

En un proyecto de acción el fin no es producir un artefacto, sino encontrarlo y definirlo. En este caso, existe una componente de aprendizaje para, 'aprender' a resolver problemas.

7

- Proyecto, para Blasco, es:

"La operación de ingeniería que nos lleva a conseguir un objetivo material predeterminado por modificación de la realidad exterior mediante unas acciones humanas que han sido seleccionadas y ordenadas con anticipación de acuerdo con unos criterios".

- Para Dahlbom y Mathiassen, proyecto es una acción 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 solución de un problema que no es fijo ni estable, sino que se va dando conforme el proyecto está en ejecución; y,

- se construye, por desarrollar una solución técnica que es la respuesta a un problema.

1.2. Tipología de proyectos

Las visiones previas muestran que un proyecto involucra dos proyectos de enunciado teórico: proyecto para construcción de artefactos y proyecto de acción, cada uno de los cuales, según su relevancia y su grado integración mutuo, han llevado a que clasificar un proyecto no sea una labor sencilla. Más bien es una labor compleja, pues su variedad y diversidad es alta. Sin embargo, es posible sugerir una tipología general dependiendo de algunos criterios.

La tipología general aquí presentada utiliza criterios de distinción:

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 ingeniería, o por la disciplina, ciencia y/o técnica que predomina en

el proyecto; Por naturaleza del resultado, o por el tipo de producto a obtener.

1.2.1 Taxonomía de proyectos

Debe aclararse que estos criterios ni son todos ni son determinantes.

a. Por objeto

- Proyecto clásico. Se aborda la realización de una serie de documentos que define la obra o trabajo a realizar para su ejecución en un futuro. El alcance comprende la identificación, evaluación, organización y valoración de las actividades que faltan para conseguir o culminar el resultado perseguido, pero en su alcance no está comprometida la

8

realización 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 cuestión.

- Proyecto de investigación. Su objetivo es aportar en su conclusión 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 académicos. El resultado es una memoria de investigación donde, aparte del planteamiento del problema a resolver y la descripción del estado del arte, se reseñan los trabajos realizados, los resultados de los mismos y las conclusiones pertinentes, junto con las líneas de investigación futuras propuestas en esa disciplina concreta.

b. Por actividad

- Estudios y análisis. En ocasiones el alcance de un trabajo concreto se limita a analizar o estudiar la información disponible acerca de los aspectos técnicos, económicos, ambientales y sociales de un determinado problema. En este caso el proyecto recibe el nombre de estudio (comprensión o conocimiento del problema o análisis (examen del problema para comprender los principios del mismo).

- Estudios de viabilidad. Los estudios de viabilidad deben proporcionar la base- técnica, económica y comercial para la decisión de invertir en un proyecto industrial. En estos estudios se deben definir y analizar los elementos críticos relacionados con la fabricación de un producto dado, junto con otros enfoques posibles a tal producción. Un estudio de este tipo debe dar por resultado un proyecto con capacidad de producción definida en un emplazamiento seleccionado, utilizando una o varias tecnologías determinadas en relación con materiales e insumos específicos con costes de inversión y producción identificados, e ingresos por concepto de ventas que produzcan un rendimiento determinado respecto de la inversión.

c. Por rol del usuario

- Proyecto externo. Los proyectos externos a la organización 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 organización, son aquellos en los que el cliente es de la misma empresa que desarrolla los trabajos.

d. Por campo de ingeniería

Por campo de ingeniería, se tienen proyectos diversos:

- Productos naturales. Ingeniería agronómica, oceanográfica, forestal y minera. La obtención 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 interrelación entre los equipos y máquinas necesarios, lo que evita la necesidad de una definición minuciosa de los mismos que condicione las fases posteriores del trabajo.

9

- Infraestructuras y edificaciones. Ingeniería civil, construcción. La construcción de infraestructuras y edificaciones de todo tipo se apoya en disciplinas fundamentales como topografía, geotecnia y resistencia de materiales, y exige proyectos detallados con profusión de cálculos y planos, pero cuya ejecución es prácticamente independiente, en el tiempo, de los documentos que configuran el proyecto.

- Productos manufacturados. Ingeniería industrial, mecánica, electrónica, automática, química, aeronáutica, naval. Los productos manufacturados exigen unos proyectos muy complejos, con muchas disciplinas implicadas y numerosos equipos, máquinas y aparatos interconectados, que exigen gran atención y abundantes especificaciones.

- Servicios/sistemas ligados a ingeniería eléctrica, energía, telecomunicación, informática. En este caso hablamos de productos cuya esencia es intangible, por su naturaleza inmaterial que dificulta su manipulación corpórea.

e. Por naturaleza del resultado

- Proyecto de ingeniería. En este caso estamos ante un proyecto de acción, donde esencialmente se persigue resolver un conflicto definiendo cual sería el potencial sistema solución.

- Proyecto industrial. A diferencia de los proyectos clásicos, los proyectos industriales comienzan y terminan en sí mismos, dando lugar a un producto o servicio terminado (sin que ello sea obstáculo para que otros proyectos comiéncen posteriormente desde los resultados del primero). Involucra una planificación en la ejecución de actividades orientadas a un fin concreto (el bien o servicio) por lo que una vez finalizado el mismo, la replicación de los resultados no constituiría un proyecto en sí mismo.

Este tipo de proyectos, por su relevancia y generalidad se detallan a continuación.

1.2.1.1 Proyectos a destacar

a.- Proyecto de ingeniería

Por su relevancia, en este apartado se profundiza en los proyectos de ingeniería. Los Proyectos de Ingeniería tienen una serie de características comunes que se citan a continuación:

Complejidad. Una serie de factores, como el trabajo requerido para su realización, el tamaño de la inversión, todo el tiempo necesario para llevarlo a cabo más las importantes responsabilidades que van asociadas a ello hacen complejo un proyecto de ingeniería. Por su enorme complejidad es preferible dividirlo en partes mucho más pequeñas que pueden ser estudiadas más profundamente.

Integrabilidad. La mayoría 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 sólo existe una idea de algo que queremos materializar hasta el final, cuando se ha transformado en una realidad.

10

No obstante, a veces se tiene la impresión que se suprimen algunas etapas intermedias. Esto no es del todo cierto, lo que ocurre simplemente es que se utilizan otras vías, 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 técnicos. Por ello, una tercera característica para proyectos de ingeniería 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 características del terreno donde se localiza desde el punto de vista técnico, además se exige una definición precisa de todos los equipos y máquinas que componen el sistema de producción. En este tipo de proyectos la fase documental se puede desarrollar independientemente de equipos y máquinas hasta un determinado momento, pero a partir del cual es imprescindible la definición y selección de éstos. Los equipos y máquinas pueden quedar obsoletos o sufrir variaciones importantes en sus costes o prestaciones.

Una clasificación bastante representativa de los proyectos industriales, con independencia de su origen, podría ser:

- Grandes proyectos de inversión. Realmente este tipo no se puede considerar un proyecto, sino más bien es un estudio económico que lo acompaña, tanto desde el punto de vista de la demanda prevista como de los costes de producción y de sus consecuencias sociales y políticas: creación de empleo, desarrollo regional, etcétera. 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 realización de estos proyectos constituye el capítulo más amplio e importante dentro de la ingeniería industrial y para ello es necesario la construcción de plantas e instalaciones, que constituye un proyecto completo con todas sus fases y aspectos.

Los sectores, instalaciones y plantas más típicos son los que se enumeran a continuación:

- Industria electrónica.

- Robótica y automática.

- Industria de transformación.

- Plantas de proceso (refinerías, petroquímicas, fertilizantes, química inorgánica).

- Industria de la alimentación.

- Farmacia.

11

- Pasta, papel y cartón.

- Cemento.

- Centrales eléctricas (hidráulicas, térmicas, nucleares).

- Siderurgia y metalurgia.

- Industria aeronáutica y espacial.

- Industria naval.

- Líneas y unidades de producción.

- Unidades y líneas de producción. El estudio y diseño de las unidades y líneas de producción de los edificios e instalaciones que forman las grandes plantas industriales constituyen por sí mismos proyectos independientes que, en muchas ocasiones están interconectados.

- Máquinas, equipos y sus elementos. El estudio de las máquinas y equipos que forman parte de cualquier instalación industrial, e incluso algunos elementos de éstos constituyen también por sí mismos un proyecto.

Otra clasificación de los proyectos industriales podría ser: según la naturaleza del proyecto (especialidad), el volumen de la inversión, el objeto del proyecto y el proceso que utiliza.

- Por la naturaleza del proyecto. Por su naturaleza o especialidad, hay que recurrir a la clasificación de los distintos sectores industriales. Esta clasificación coincide con la lista enumerada anteriormente en el punto "instalaciones y plantas industriales".

- Por el volumen de la inversión.

- Pequeño.

- Mediano.

- Grande.

- Por el objeto del proyecto.

- Nueva instalación.

- Ampliación (Modificaciones de proceso, Nuevas líneas, Nuevos productos, Cuellos de botella).

- Mejora:

- Económica: Aumento de calidad, Reducción de costes.

12

- Social: Seguridad, Protección ambiental.

- Mantenimiento.

- Traslado.

- Por el proceso que utiliza.

- Su naturaleza (mecánico, físico, físico-químico).

- Su origen (propio, de terceros).

- Propietario del proceso.

- Empresa de ingeniería licenciada.

- Suministradores de equipos principales.

2. Su Importancia en el desarrollo de Sistemas de Información Empresariales.

Teoría del proyecto tecnológico

Teóricamente, un proyecto tecnológico 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 tecnologías de la información.

Y, como tal, la operación de un proyecto de SI comprende la ejecución de una serie de actividades de gestión y de construcción tendientes a proveer una determinada solución tecnológica a una estrategia de negocios.

Este planteamiento teórico y operacional de un proyecto e-Business muestra la multi- dimensionalidad de este tipo de proyectos, reflejado en la figura 3. En un proyecto de SI distinguimos la concurrencia de:

Dos dimensiones: la dimensión de gestión y la dimensión de construcción. Dos visiones: visión de negocios y la visión tecnológica.

13

Figura 3: Elementos en un proyecto e-Business.

Según 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.

14

De esta manera, las dimensiones permiten construir la iniciativa o solución tecnológica en una organización (figura 5) como un conjunto de aplicaciones de base tecnológica (figura 6), operando dentro de los sistemas de trabajo bajo una óptica de negocios y tecnológica.

Figura 5: La solución e-Business.

Figura 6: Alcance de aplicaciones e-Business.

15

Visión de negocios y tecnológica

De una u otra manera, un proyecto de SI comprende una visión de manejo integrado de la información organizacional, cuya puesta en escena puede abordarse como un proyecto de sistemas de información. En este caso se distingue la visión de negocios y la visión tecnológica.

La visión de negocios aporta e introduce el marco organizacional y estratégico dentro del cual se enmarca todo el proyecto de SI, vale decir, es la visión que sostiene la iniciativa o solución tecnológica. La implantación de esta visión se traduce en un proyecto de negocios, entendido como todo el proceso gracias al cual una idea de negocios se concreta.

La visión tecnológica aporta al proyecto tecnológico un habilitador y un facilitador tecnológico. Por ejemplo, en un proyecto e-Business, la visión tecnológica aporta elementos, tanto para el propio proyecto (por ejemplo, herramientas para un e-Project donde usar desarrollos RAD cuya gestión se sustenta en un software MS project) como para la solución e-Business (Internet, redes WAN, etc.).

Dimensiones de gestión y de construcción

Como todo proyecto, un proyecto de SI requiere identificar una dimensión de gestión y otra de construcción.

La gestión del proyecto aporta un conjunto de instrumentos que permiten conseguir los objetivos de un proyecto cualquiera. Como parte de la gestión, se debe considerar la visión de negocios y la utilización de tecnología.

La construcción del proyecto, expresada de mejor manera como la metodología de un proyecto de SI, permite conducir el proyecto integrando la visión de negocios que lidera la idea organizacional y la visión tecnológica que sustenta la estrategia de negocios.

3. La Administración de Proyectos de Ingeniería de Sistemas propiamente

dichos.

Gestión de Proyectos es una dimensión dentro de un proyecto y no es en sí el proyecto (figura 7). Esto muestra, por una parte, la dependencia de la gestión 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 documentación, el cual contiene y refleja la historia del proyecto en todas las áreas en que se haya desenvuelto, y la evolución del resultado finalmente obtenido con la metodología de SI.

16

Proyecto de SI

Figura 7: La gestión de proyectos en un proyecto.

En particular, la gestión de proyectos para un proyecto de SI se enfoca en buscar un marco estructurado para la gestión exitosa, buscando aportar un completo conjunto de herramientas y técnicas para integrar la propia filosofía de SI, la gestión de proyectos, la calidad y el desarrollo de sistemas informáticos en un todo coherente.

3.1 Noción de gestión de proyectos

Gestión de Proyectos es una dimensión dentro de un proyecto y no es en sí el proyecto. Por ello es conveniente revisar de qué manera el proyecto englobador cambia la visión a tener respecto de cómo usar la gestión de proyectos.

La gestión de proyectos intenta conseguir una planificación coherente con los objetivos de una organización y del propio proyecto, igualmente que el desarrollo del proyecto se acerque a lo planificado y supere las vicisitudes del medio y del día a día.

Aplicación de SI

Gestión de proyectos

Metodología

Iniciativa de SI

Documentación del proyecto

Recursos humanos,

materiales y económico

financieros

Imposiciones y

condiciones del medio

Composición y

restricciones organización

17

Se encarga de planificar, dirigir y controlar el desarrollo de un sistema aceptable con un costo mínimo y dentro de un período de tiempo especifico.

Como una manera de proveer un lenguaje universal y común entre los profesionales de proyectos, el Project Management Institute ha desarrollado el PMBOK, un documento con el cual se espera que la práctica de gestión de proyectos se convierta en un cuerpo doctrinal y referencial para los profesionales del área. Por esta razón se presenta la gestión de proyectos desde el punto de vista del PMBOK.

En la sección 1 se planteó que el concepto de proyectos difiere según diversas visiones, además que un proyecto es un sistema dentro del cual coexisten dos dimensiones, la de gestión y la de construcción. Según esto, la gestión de proyectos es un sistema que debe construirse y ser adaptado al punto de vista de proyecto que se maneje.

Proyecto como producción de artefactos. Aquí por gestión se entiende la programación de actividades y ver que se cumplan.

Proyecto como consecución de objetivos. Aquí el proyecto es un conjunto de actividades concretas para un determinado resultado, y la gestión intenta que tales actividades cumplan con las necesidades presupuestas de antemano, siendo en esencia una anticipación a un objetivo o a un estado de realidades predefinidas.

Proyecto de acción. Aquí el proyecto persigue finalidades, sin necesidad de seguir un plan de trabajo. El proyecto es actuar siguiendo finalidades o fines y la gestión 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 gestión 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 cómos, cuándos, quiénes y cuántos; y,

18

en el último caso, el gestor de proyectos debe ayudar a buscar el qué se desea, para lo cual dispone de varios cómos que le ayudan a conseguir el qué.

Sin embargo, aceptando cierto grado de formalización respecto de la gestión de proyectos asociada al proyecto como productor de artefactos, debido a que es más 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 gestión de proyectos es “la planificación, organización, dirección 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 específicos”.

Siguiendo con esta primera acepción, Kirsch señala que gestión de proyectos es la aplicación de técnicas, métodos, herramientas y heurísticas formales e informales, las cuales emplea un gestor de proyectos en la motivación y guía de un equipo de personas para llevar un proyecto dentro de un conjunto dado de restricciones.

Visto así, la gestión de proyectos pone a disposición 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 actúe de forma adecuada ante eventos no presupuestados.

En todo caso, debe tenerse claro que la gestión de proyectos es un medio a disposición del gestor para construir una solución dentro de las mejores condiciones para quienes están dentro del proyecto y para quienes se beneficiarán 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 corpóreos (trabajo físico, esfuerzo mental), con especial cuidado y atención a las personas. Es una labor donde especialistas actúan con libertad como parte de un todo (figura 8).

Figura 8: El fin de la gestión del proyecto.

19

El gestor de proyectos se destaca como la figura clave en la planificación, ejecución y control del proyecto y es el motor que ha de impulsar el avance del mismo mediante la toma de decisiones tendentes a la consecución 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 sería 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 organización de la empresa.

Las relaciones básicas del gestor de proyectos con otras unidades o personas dependen, en gran medida, de la estructura organizativa que posea la organización (figura 9).

Figura 9: El fin de la gestión del proyecto.

Generalizando un poco, la gestión de proyectos se debe entender como un cúmulo de información sobre instrumentos y prácticas que se pone a disposición 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 parámetros clásicos de gestión: tiempo, coste y desempeño, para mejorar la calidad y conseguir un riesgo cero.

No obstante, el valor agregado de esta información 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 formación.

Por último, existe el caso de una gestión orientada a dar un valor especial al gestor como evaluador de opciones futuras, tal como se ilustra en la figura 10, ante vicisitudes.

20

Figura 10: La gestión y sus vicisitudes.

3.2 Gestión de Proyectos de Software En el prefacio de su libro sobre gestión de proyectos de software, Meiler Page-Jones [PAG85] dice una frase que pueden corroborar muchos asesores de ingeniería del software: He visitado docenas de empresas, buenas y malas, y he observado a muchos administradores de proceso de datos, también buenos y malos. Frecuentemente, he visto con horror cómo estos administradores luchaban inútilmente contra proyectos de pesadilla, sufriendo por fechas límite 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 síntomas que resultan de una serie de problemas técnicos y de gestión. Sin embargo, si se hiciera una autopsia de cada proyecto, es muy probable que se encontrara un denominador común constante: una débil gestión.

21

Roger Pressman en la 1uinta edición de su publicación “Ingeniería del Software, un enfoque práctico”, define: “La gestión eficaz de un proyecto de software se centra en las cuatro P’s: personal, producto, proceso y proyecto. El orden no es arbitrario. El gestor que se olvida de que el trabajo de ingeniería del software es un esfuerzo humano intenso nunca tendrá éxito en la gestión de proyectos. Un gestor que no fomenta una minuciosa comunicación con el cliente al principio de la evolución del proyecto se arriesga a construir una elegante solución para un problema equivocado. El administrador que presta poca atención al proceso corre el riesgo de arrojar métodos técnicos y herramientas eficaces al vacío. El gestor que emprende un proyecto sin un plan sólido 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 años 60 (por ejemplo, [COUSO,WíT94, DEM981]). De hecho, el “factor humano” es tan importante que el Instituto de Ingeniería del Software ha desarrollado un Modelo de madurez de la capacidad de gestión de personal (MMCGP) “para aumentar la preparación de organizaciones del software para llevar a cabo las cada vez más 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 gestión de personal define las siguientes áreas clave prácticas para el personal que desarrolla software: reclutamiento, selección, gestión de rendimiento, entrenamiento, retribución, desarrollo de la carrera, diseño de la organización y del trabajo y desarrollo cultural y de espíritu de equipo. El MMCGP es compañero del modelo de madurez de la capacidad software (CMMI), que guía a las organizaciones en la creación de un proceso de software maduro. Los participantes

Gestores superiores

Gestores (técnicos) 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 coordinación y comunicación

Informal

Comunicación electrónica

Red interpersonal 3.2.2. Producto

22

Antes de poder planificar un proyecto, se deberían establecer los objetivos y el ámbito del producto1, se deberían considerar soluciones alternativas e identificar las dificultades técnicas y de gestión. Sin esta información, es imposible definir unas estimaciones razonables (y exactas) del coste; una valoración efectiva del riesgo, una subdivisión realista de las tareas del proyecto o una planificación del proyecto asequible que proporcione una indicación 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 ingeniería del sistema o del negocio y continúa como el primer paso en el análisis de los requisitos del software. Los objetivos identifican las metas generales del proyecto sin considerar cómo se conseguirán (desde el punto de vista del cliente). El ámbito identifica los datos primarios, funciones y comportamientos que caracterizan al producto, y, más importante, intenta abordar estas características 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 información

Función y rendimiento Descomposición del problema La descomposición del problema, denominado a veces particionado o elaboración del problema, es una actividad que se asienta en el núcleo del análisis de requisitos del software. Durante la actividad de exposición del ámbito no se intenta descomponer el problema totalmente. Más bien, la descomposición 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 pequeño número de actividades estructurales se puede aplicar a todos los proyectos de software, sin tener en cuenta su tamaño o complejidad. Diferentes conjuntos de tareas-tareas, hitos, productos del trabajo y puntos de garantía de calidad- permiten a las actividades estructurales adaptarse a las características del proyecto de software y a los requisitos del equipo del proyecto. Finalmente, las actividades protectoras -tales como garantía de calidad del software, gestión de la configuración del software y medición- cubren el modelo de proceso.

1 En este contexto, el término “producto” es usado para abarcar cualquier software que

será construido a petición de otros. Esto incluye no sólo productos de software, sino también sistemas basados en computadora, software empotrado y software de resolución de problemas (por ejemplo, programas para la resolución de problemas científicos/de ingeniería).

23

Las actividades protectoras son independientes de las estructurales y tienen lugar a lo largo del proceso. Las fases genéricas que caracterizan el proceso de software definición, desarrollo y soporte- son aplicables a todo software. El problema es seleccionar el modelo de proceso apropiado para la ingeniería del software que debe aplicar el equipo del proyecto. Maduración del producto y del proceso La planificación de un proyecto empieza con la maduración del producto y del proceso. Todas las funciones que se deben tratar dentro de un proceso de ingeniería por el equipo de software deben pasar por el conjunto de actividades estructurales que se han definido para una organización de software. Asuma que la organización ha adoptado el siguiente conjunto de actividades estructurales:

Comunicación con el cliente- tareas requeridas para establecer la obtención de requisitos eficiente entre el desarrollador y el cliente. Planificación- tareas requeridas para definir los recursos, la planificación temporal del proyecto y cualquier información relativa a él. Análisis del riesgo- tareas requeridas para valorar los riesgos técnicos y de gestión. Ingeniería- tareas requeridas para construir una o más representaciones de la aplicación. Construcción y entrega- tareas requeridas para construir, probar, instalar y proporcionar asistencia al usuario (por ejemplo: documentación y formación). Evaluación del cliente- tareas requeridas para obtener información de la opinión del cliente basadas en la evaluación de las representaciones de software creadas durante la fase de ingeniería e implementadas durante la fase de instalación. Los miembros del equipo que trabajan en cada función aplicarán todas las actividades estructurales. En esencia, se crea una matriz similar a la que se muestra en la figura

24

anterior. Cada función 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. Descomposición del proceso Un equipo de software debería tener un grado significativo de flexibilidad en la elección del paradigma de ingeniería del software que resulte mejor para el proyecto y de las tareas de ingeniería del software que conforman el modelo de proceso una vez elegido. Un proyecto relativamente pequeño similar a otros que se hayan hecho anteriormente se debería realizar con el enfoque secuencial lineal. Si hay límites de tiempo muy severos y el problema se puede compartimentar mucho, el modelo apropiado es el DRA (en inglés RAD rapid application development). Si la fecha límite está tan próxima que no va a ser posible entregar toda la funcionalidad, una estrategia incremental puede ser lo mejor. Similarmente, proyectos con otras características (p. ej.: requisitos inciertos, nuevas tecnologías, clientes difíciles, potencialidad de reutilización) llevarán a la selección de otros modelos de proceso. 3.2.4. Proyecto Dirigimos los proyectos de software planificados y controlados por una razón principal -es la Única manera conocida de gestionar la complejidad-. Y todavía seguimos esforzándonos. 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 planificación y en el coste [REE99]. Aunque la proporción de éxito para los proyectos de software ha mejorado un poco, nuestra proporción de fracaso de proyecto permanece más alto del que debería 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 señales de peligro comunes; comprender los factores del éxito críticos que conducen a la gestión correcta del proyecto y desarrollar un enfoque de sentido común 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 cómo hacerlo bien. En un excelente documento sobre proyectos de software, John Reel [REE99] define diez señales que indican que un proyecto de sistemas de información está en peligro:

1. La gente del software no comprende las necesidades de los clientes. 2. El ámbito del producto está definido pobremente. 3. Los cambios están mal realizados. 4. La tecnología elegida cambia. 5. Las necesidades del negocio cambian [o están mal definidas].

2 Dadas estas estadísticas, es razonable preguntarse cómo el impacto de las

computadoras continúa creciendo exponencialmente y la industria del software continúa anunciando el crecimiento de ventas al doble. Parte de la respuesta, pienso, es que un importante número de estos proyectos (fallidos) están mal concebidos desde el primer momento. Los clientes pierden el interés rápidamente (puesto que lo que ellos pidieron realmente no era tan importante como ellos habían pensado), y los proyectos son cancelados.

25

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 prácticas y sabias

lecciones. ¿Cómo actúa un gestor para evitar los problemas señalados anteriormente? Reel [REE99] sugiere una aproximación de sentido común a los proyectos de software dividida en cinco partes:

Empezar con el pie derecho.

Mantenerse

Seguimiento del progreso

Tomar Decisiones Inteligentes

Realizar un Análisis “Postmortem” (después de finalizar el proyecto). 3.3 Prácticas Críticas

Gestión formal del riesgo.

Coste empírico y estimación de la planificación.

Gestión de proyectos basada en métricas

Seguimiento del valor ganado.

Seguimiento de defectos frente a objetivos de calidad.

Gestión del programa del personal. 4. Ciclo de vida de un Proyecto de Ingeniería de Sistemas de Software. ¿Qué es? La planificación implica la estimación -su intento por determinar cuánto dinero, esfuerzo, recursos, y tiempo supondrá construir un sistema o producto específico de software-. ¿Quién lo hace? Los gestores del software -utilizando la información solicitada a los clientes y a los ingenieros de software y los datos de métricas de software obtenidos de proyectos anteriores-. ¿Por qué es importante? ¿Podría construir una casa sin saber cuánto estaría dispuesto a gastar?. Por supuesto que no, y puesto que la mayoría de los sistemas y productos basados en computadora cuestan considerablemente más que construir una casa grande, podría ser razonable desarrollar y estima antes de empezar a construir el software. ¿Cuáles son los pasos? La estimación comienza con una descripción del ámbito del producto. Hasta que no se delimite el ámbito no es posible realizar una estimación con sentido. El problema es entonces descompuesto en un conjunto de problemas de menor tamaño y cada uno de éstos se estima guiándose con datos históricos y con la experiencia. Es aconsejable realizar las estimaciones utilizando al menos dos métodos diferentes (como comprobación). La complejidad y el riesgo del problema se considera antes de realizar una estimación final.

26

¿Cuál 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 realización de cada una. También se obtiene una lista de recursos necesarios para el proyecto. ¿Cómo puedo estar seguro de que lo he hecho correctamente? Esto es difícil, puesto que realmente no lo sabrá hasta que el proyecto haya finalizado. Sin embargo, si tiene experiencia y sigue un enfoque sistemático, realiza estimaciones utilizando datos históricos sólidos, crea puntos de estimación mediante al menos dos métodos diferentes y descompone la complejidad y riesgo, puede estar seguro de haber acedado plenamente. 4.1 Procesos de gestión de proyectos

Los Procesos de Gestión de Proyectos son el eje de toda la propuesta del PMBOK (tabla 2.2), constituyendo el centro de las mejores prácticas de gestión de proyectos. En la codificación X.Y de cada proceso, la X indica el número 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 técnicas de gestión. Esta representación de la gestión de proyectos, ha sido una de las principales aportaciones del PMBOK al mundo de la investigación y de la profesión de proyectos, al mostrar de manera clara que existen, por una parte, procesos de gestión y, por otra parte, herramientas y técnicas donde, los primeros usan las segundas a conveniencia según necesidades y habilidades del gestor y de los participantes.

Los procesos de gestión de proyectos son presentados como elementos que contienen interfaces definidas. Sin embargo, en la práctica los procesos interactúan de diferentes maneras, lo que nos lleva a reconocer que hay más de una manera de administrar un proyecto. La aplicación 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 interacción entre los procesos de gestión 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.

27

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

GESTIÓN DE

PROYECTOS

DESCRIPCIÓN

Gestión de la Integración

4.1 Desarrollo del cuadro

de proyecto (p charter)

Desarrollar un plan de proyecto que autorice formalmente

al proyecto o una fase del proyecto.

28

4.2 Desarrollo de alcance

de proyecto preliminar

Desarrollar el alcance del proyecto en una narrativa de alto

nivel.

4.3 Desarrollo del plan de

gestión de proyecto

Documentar las acciones necesarias para definir, preparar,

integrar y coordinar todos los planes subsidiarios en un

plan de gestión de proyecto.

4.4

Dirección y Gestión de

la ejecución del

proyecto

Ejecutar las tareas definidas en el plan de gestión de

proyecto.

4.5 Monitoreo y control de

tareas del proyecto

Controlar los procesos usados para iniciar, planificar,

ejecutar y cerrar el proyecto de manera que coincidan con

los objetivos descritos en el plan.

4.6 Control de Cambios

Integrado

Revisar todos los cambios solicitados, aprobados y

realizados.

4.7 Cierre del proyecto Finalizar las actividades de todos los grupos de proceso,

para cerrar formalmente el proyecto o la fase de proyecto.

Gestión del Alcance

5.1 Planificación del

alcance

Desarrollar un plan de gestión del alcance que indique

cómo será definido, verificado y controlado, y cómo será

creada la WBS.

5.2 Definición del alcance Desarrollar un informe escrito del alcance que sirva de

base para las futuras decisiones del proyecto.

5.3

Creación de un WBS

(Work Breakdown

Structure)

Subdividir las principales entregas del proyecto en

componentes más pequeños y manejables.

5.4 Verificación del

alcance

Aceptar formalmente que los entregables del proyecto han

sido completados.

5.5 Control del Alcance Controlar los cambios en el alcance del proyecto.

Gestión del tiempo

29

6.1 Definición de

actividades

Identificar las actividades específicas que se deben

desarrollar para cumplir con las principales entregas del

proyecto.

6.2 Secuenciación de las

actividades

Identificar y documentar las distintas interrelaciones entre

actividades.

6.3

Estimación de los

recursos de las

actividades

Estimar el tipo y cantidad de recursos necesarios para

desarrollar cada actividad.

6.4

Estimación de la

duración de las

actividades

Estimar el número de jornadas laborales que se

necesitarán 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.

6.6 Control del programa Controlar los cambios del programa del proyecto.

Gestión del Coste

7.1 Estimación de costes

Desarrollar una aproximación (estimación) de los costes de

los recursos necesarios para completar las actividades del

proyecto.

7.2 Presupuesto de costes Asignar la estimación general de costes a cada uno de los

elementos de trabajo para establecer un coste base.

7.3 Control de costes

Identificar los factores que generan variaciones de costes y

controlar los cambios que se produzcan en el presupuesto

del proyecto.

Gestión de la Calidad

8.1 Planificación de la

calidad

Identificar qué normas de la calidad son relevantes al

proyecto y determinar cómo cumplirlas.

8.2 Ejecución del Aplicar las actividades planificadas para asegurar que el

30

Aseguramiento de la

calidad

proyecto emplea todos los procesos necesarios para

cumplir con los requerimientos de las normas.

8.3 Ejecución del Control

de la calidad

Realizar un seguimiento de los resultados específicos del

proyecto para determinar si cumplen las normas más

importantes sobre la calidad e identificar la manera de

eliminar las causas de un desarrollo no satisfactorio.

#

PROCESO DE

GESTIÓN DE

PROYECTOS

DESCRIPCIÓN

Gestión de Recursos Humanos

9.1 Planificación de los

Recursos Humanos

Identificar, documentar y asignar las funciones,

responsabilidades y relaciones jerárquicas del proyecto, y

crear el plan de gestión de personal.

9.2 Adquisición de equipo

de proyecto

Reunir los recursos humanos que sea necesario asignar al

trabajo del proyecto.

9.3 Desarrollo del equipo

de proyecto

Desarrollar las aptitudes individuales y de grupo para

mejorar el desarrollo del proyecto.

9.4 Gestión del equipo de

proyecto

Hacer seguimiento del rendimiento de cada miembro del

equipo, cambiando y mejorando factores que mejoren el

desarrollo del proyecto.

Gestión de las Comunicaciones

10.1 Planificación de

comunicaciones

Determinar las necesidades de información y

comunicaciones de las entidades involucradas en el

proyecto.

10.2 Distribución de

información

Poner a disposición de las entidades involucradas en el

proyecto la información necesaria en el momento

adecuado.

31

10.3 Informe de realización

Recopilar y distribuir la información sobre el desarrollo del

proyecto. Esto incluye el informe de situación, la

evaluación del progreso y las previsiones.

10.4 Gestión de las

Entidades

Manejar las comunicaciones para satisfacer los

requerimientos y resolver los factores relacionados con las

entidades involucradas en el proyecto.

Gestión del Riesgo

11.1 Planificación de la

gestión de riegos

Decidir el enfoque, plan y ejecución de las actividades de

gestión del riesgo del proyecto.

11.2 Identificación de

riesgos

Determinar qué tipo de riesgos es probable que afecten al

proyecto y documentar las características de cada uno de

ellos.

11.3 Análisis cualitativo de

riesgos

Evaluar la probabilidad de ocurrencia e impacto de los

riesgos y priorizar los riesgos para su análisis o acción

futura.

11.4 Análisis cuantitativo de

riesgos

Analizar numéricamente el efecto de los riesgos

identificados sobre los objetivos del proyecto.

11.5 Planificación de las

respuestas a riesgos

Desarrollar procedimientos y técnicas para mejorar las

oportunidades y reducir las amenazas respecto de los

objetivos del proyecto.

11.6 Monitoreo y control de

riesgos

Monitorear los riesgos residuales, identificar nuevos

riesgos, ejecutar planes de reducción de riesgos y evaluar

su efectividad a lo largo del ciclo de vida del proyecto.

Gestión del Abastecimiento

12.1

Planificación de

Compras y

Adquisiciones

Determinar qué aprovisionar y cuándo.

12.2 Planificación de la

contratación

Documentar los productos y servicios requeridos e

identificar los potenciales suministradores.

32

12.3 Petición de respuestas

de proveedores Obtener presupuestos, ofertas y propuestas adecuadas.

12.4 Selección de

proveedores

Revisar las ofertas, escoger a los posibles proveedores y

negociar un contrato escrito con cada uno de ellos.

12.5 Administración del

contrato

Manejar el contrato y la relación entre el comprador y el

vendedor.

12.6 Cierre del contrato

Completar y establecer cada contrato, incluyendo la

resolución de cualquier tema abierto, y finalizar la relación

contractual.

Tabla 2.2. Procesos de gestión de proyectos.

4.2 Grupos de procesos de gestión

Los grupos de procesos de gestión, Project Management Process Groups, son agrupaciones de procesos de gestión de proyectos relacionados con las cinco fases de un proyecto: Iniciación (IP), Planificación (Pl), Control (CoP), Ejecución (EP) y Cierre (ClP). Los grupos de procesos son independientes al área de aplicación 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 varía en el tiempo tal como ilustra la figura 2.19.

Figura 2.19: La interacción de los grupos de procesos de gestión a lo largo del proyecto.

33

CÓDIGO GRUPO DE

PROCESOS DESCRIPCIÓN

IP Iniciación Define y autoriza el proyecto o una fase del proyecto.

PP Planificación

Define y refina objetivos, y planifica las acciones necesarias

para conseguir los objetivos y el alcance bajo el cual el

proyecto fue concebido.

EP Ejecución Integra personal y demás recursos para llevar a cabo el plan

de gestión del proyecto en cuestión.

CoP Control

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.

ClP Cierre

Formaliza la aceptación del producto, servicio o resultado, y

conduce al proyecto o fase de proyecto hacia un término

ordenado.

Tabla 2.3. Grupos de procesos de gestión.

4.3 Relación entre grupos, áreas y procesos

La relación 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 práctica 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 más personas o grupos de personas, según sean las necesidades del proyecto. Generalmente, cada proceso ocurre al menos una vez en cada fase del proyecto.

34

IP PP EP CoP ClP

Gestión de la Integración X X X X X

Gestión del Alcance

X

X

Gestión del Tiempo

X

X

Gestión del Coste

X X

Gestión de la Calidad

X X X

Gestión de Recursos Humanos

X X

Gestión de las Comunicaciones

X X X

Gestión del Riesgo

X

X

Gestión del Abastecimiento

X X X

Tabla 2.4. Relaciones entre grupos, áreas y procesos.

5. Variables en la administración de Proyectos de Ingeniería de Sistemas.

Variable Gestión de proyectos en informática

Sin ser una bala de plata, la gestión de proyectos en informática ha cobrado relevancia frente al reto del cambio de siglo (problema conocido como Y2K), el cambio al euro o la simple globalización. Ante ello se exige que un gestor de proyectos sea capaz de abordar cualquier tipo de proyecto informático, manejando equipos multidisiciplinarios en su pluralidad curricular, cultural, social y psicológica.

No obstante, la gestión de proyectos desde la perspectiva formal del PMBOK es una desconocida en la Informática. A pesar de esto último, la Ingeniería de Software intenta proveer métodos, técnicas y herramientas de desarrollo, dentro de las cuales se incluyen algunas orientadas o consideradas de la gestión. En tal sentido, este apartado presenta el significado que adquiere la gestión de proyectos en informática.

35

5.1 Los problemas comunes en Informática

Para entender el rol de la gestión de proyectos en la Informática es conveniente comenzar comprendiendo los problemas que existen en los proyectos informáticos.

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 insatisfacción de necesidades es la mala definición de las expectativas de un proyecto en sus orígenes, ya que si no están bien definidos los requerimientos máximos y mínimos que el proyecto debe satisfacer desde el comienzo, los desarrolladores verán afectado su trabajo por el "síndrome de las necesidades que crecen" el cual les dejara hacer cambios en el proyecto en cualquier momento sin detenerse a pensar si esos cambios serán 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 característicos y síntoma de "normalidad informática" es que los proyectos informáticos se atrasan y se exceden en los presupuestos económicos. Decir que el tiempo y dinero se duplican, triplican o cuadruplican ya no tiene sentido, es un hecho y tradición 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 podrán recuperar el tiempo perdido. En general esta es una muy mala política de trabajo porque no siempre es posible acelerar otras tareas para ahorrar tiempo en la entrega final.

Por ejemplo, Glass señala que el 40% de los proyectos informáticos 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 informática, por ejemplo Ribera, nos muestra algunos ejemplos dignos de mención:

El proyecto del Opera House de Sidney pasó de 7 millones de dólares a 107 millones de dólares.

36

El proyecto de desarrollo del avión F-22 Raptor que ha superado un coste del billón de dólares.

El proyecto del túnel del Canal de la Mancha, cuyo coste inicial de 7,5 billones a llegado a los 17,5 billones de dólares, y se terminó en 1994 en lugar de 1992.

Pero no es necesario pensar en esas grandes empresas humanas, cuya complejidad puede justificar cualquier superación de estimaciones. Se puede pensar en el simple atraso en la construcción de un edificio, algo tan habitual y corriente que se nos pasa desapercibido. Lo que queremos decir es que fuera de la Informática los proyectos también se atrasan y cuestan más caros por motivos tan diversos y variopintos como los que se escuchan en informática.

Lo que es preocupante es que dentro de la Informática estos problemas se manifiestan tanto a gran escala (como los ejemplos dados por Ribera) como a escala "casera", viéndose afectado por tanto todo el tejido socio-económico, incluyendo aspectos como el crecimiento organizacional, los planes de empresa, o el presupuesto de una PyME.

a.3.- El social: la imposición de los resultados

Aparte de esos comunes problemas de tiempo y coste, está en lo que podría llamarse el problema de 'adopción por decreto'.

En muchas ocasiones los productos informáticos son impuestos por las jerarquías administrativas sin una asimilación y/o aceptación del personal o los trabajadores. Según ciertas culturas este tema resulta conflictivo y un problema a ser resuelto. Un caso de cultura que rechaza esta situación es la escandinava, así, Iivari y Lyytinen destacan que los productos informáticos son artefactos surgidos y definidos por quienes les usarán, los trabajadores.

El problema es básicamente de los principios ligados a la historia de la ingeniería, donde ella busca ser generadora de soluciones a las necesidades de la humanidad, aportando artefactos con un valor agregado y márgenes de ganancia social siempre positivos para el 'hombre de la calle'.

Esta visión se contradice con la costumbre informática de imponer soluciones según 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 más eficientes con aumento de velocidad computacional, y/o mejoras de la eficacia en base a nuevas prácticas laborales con simples automatizaciones de prácticas de trabajo.

En una sociedad del conocimiento este tipo de actitudes no son permitidas, pues es necesaria la participación libre y colaborativa de todas las personas involucradas en un proceso de construcción de productos informáticos, sean tanto diseñadores de sistemas como usuarios finales.

b.- Las consecuencias de los 'problemas comunes'

Hoy en día los proyectos informáticos se asumen que son un riesgo a correr, lo cual no evita que al final de un proyecto informático se puedan plantear tres consecuencias:

37

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ó", "apágalo, 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 informáticos en la forma de software, infraestructuras y/o sistemas de información, todavía no es posible erradicar el oscurantismo de una profesión que entrega productos con funcionamientos en ocasiones misteriosos y plenos de 'bugs'.

b.2.- Desconfianza en la profesión

La desconfianza en la profesión la sufren los practicantes de la informática cuando se les pide evaluar un producto, calcular un coste o sencillamente dimensionar algún resultado. No se le puede pedir a un ingeniero informático calcular o estimar un producto cuando las actuales herramientas no son seguras ni fiables. Esto ocurre en otras disciplinas, pero sencillamente la informática está, diríamos aún en pañales, llevando a justificar como válido el multiplicar por dos, al menos, los costes y los tiempos planificados. En extenso, la consultoría informática puede llegar a ser un factor negativo al momento de la promoción profesional.

b.3.- La crisis del usuario

Pero hay otra consecuencia relevante. No es una desconfianza en lo que resulta del trabajo informático o en lo que produce la formación informática, 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 límite, sino una sociedad que acepta en situaciones concretas márgenes de riesgo como algo cotidiano y éticamente aceptable.

Esta concepción del mundo es ideal para la Informática, donde aún los proyectos son empresas de riesgo. No solamente en el ámbito de desarrollo (por ejemplo un software) o de adaptación (por ejemplo aplicaciones ERP), sino en el ámbito de negocios (por ejemplo en e-Business). Es más, puede resultar incluso curioso que frente a los problemas comunes de atrasos, sobre costes y productos no aceptados, los clientes aceptan este fenómeno.

Pero no por estar en una sociedad que tolera el riesgo, la profesión informática deba encaminarse hacia caminos donde la falla, el error y la incerteza sean aceptables y aún más, rasgo distintivo de la profesión.

Hablamos de una crisis del usuario en analogía a la crisis del software1 (según 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 informáticos. Esta crisis se debe a que quien recibe y usa el producto informático, que debería 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.

38

Lo importante es que la visión escandinava de pensar en el trabajador debe estar presente. Pero si a alguien no le gusta esta concepción del trabajo profesional, se puede tomar la línea clásica de gestión de la calidad, la cual señala que es importante dar prioridad al sistema requirente.

En una consultoría informática esto requiere el fuerte compromiso de resolver problemas, sensibilizándose el profesional de los problemas del usuario y atendiendo siempre a que su misión es resolver un problema sin añadir otros.

c.- Las causas de los 'problemas comunes'

Entre posibles causas de los problemas "comunes", se pueden señalar (Jurison):

- naturaleza del producto; y,

- problemas de gestión.

c.1.- La naturaleza del producto

Según Jurisson y Pressman, el principal producto informático, el software, se caracteriza por ser:

- intangible;

- invisible;

- complejo;

- volátil de requerimientos;

- socio-técnico; y,

- difícil de medir.

A continuación 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 físicas o límites del proceso de manufactura. Lo cual, además, produce que sea difícil detectar y prevenir errores.

- Invisible. Pues la solución que se provee es básicamente 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 según sus presentes condiciones de operación garantizan o no prestar lo que el software les pida.

- Complejo. Pues un desarrollo involucra muchas acciones y el producto comprende también muchas tareas, cuya comprensión supera las capacidades humanas.

39

- 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-técnico. Un producto informático no tiene sus fronteras en la pantalla ni en un usuario que teclea, o incluso un cliente que paga. Un sistema de información involucra varias piezas relacionadas conformando un sistema de trabajo donde encontramos que operadores manteniendo el sistema, software siguiendo algoritmos y hardware aportando infraestructura, interactúan con otras personas, software y hardware. En este sentido, pensar que un producto informático es sólo 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 solución e-Business.

- Difícil de medir. Por las otras cualidades señaladas y por la juventud de la Informática, se hace difícil tener hoy en día tener técnicas efectivas que permitan medir, y las que existen están aún en calibración.

c.2.- Problemas de gestión

Entre los problemas de gestión 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 revisión de la literatura encontramos diversos problemas de gestión, los que se muestran comparativamente en latabla 3.3. Los problemas de gestión se presentan clasificados según las áreas de conocimiento de gestión de proyectos del PMBOK y paralelizados según ciertas similitudes entre ellos.

Para la lista de McConnell y Purba et al., entre paréntesis se indica la categoría 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

GESTIÓN McCONNELL GLASS PURBA et al. REDMILL

GESTIÓN DE

INTEGRACIÓN Planificación

Exceso de

requerimientos

(producto)

Usuarios que

resisten

Incapacidad de

los usuarios en

comunicar

requerimientos

(elemento

Poca claridad

en los

requerimientos

40

humano)

Abandono de

tiempo en el

inicio (proceso)

Promotor

está perdido

Ejecución

Pérdida de

tiempo en el

inicio

Política antes

que desarrollo

(personas)

Política

organizacional

(aspectos

políticos)

Cambiar de

herramientas a

mitad del

proyecto

(tecnología)

Cambios

tecnológicos

elegidos

Falla en el uso

de

metodologías

del desarrollo

Diseño

inadecuado

(proceso)

Convergencia

prematura o

excesivamente

frecuente

(proceso)

Falta de

participación

del usuario

(personas)

Equip. políticos

(aspec.

políticos)

Política indiv. (aspec.

políticos)

Añadir más

personal a un

proyecto

retrasado

personas)

41

Tiras y aflojas

en la

negociación

(producto)

Mejores

prácticas y

lecciones

son

olvidadas

Mala gestión de

las fases de

desarrollo

(elemento

humano)

Mala

especificación

Pruebas

insuficientes

(error humano)

Control

Falta de control

automático del

código fuente

(tecnología)

Cambios son

pobremente

gestionados

Cambios en las

prestaciones

(producto)

Falta de

control de

cambios

Cambios

en las

necesidades

de negocio

Incapacidad de

acomodar

cambios a

requerimientos

de negocios

(elemento

humano)

TIPO DE PROBLEMA

DE GESTIÓN McCONNELL GLASS PURBA et al. REDMILL

GESTIÓN

DEL

ALCANCE

Iniciación

Desarrollo

orientado a la

investigación

(producto)

Falta de un

proyecto efectivo

del proyecto

(personas)

Planificación

Gestores no

comprenden

las

Incapacidad de

los usuarios en

comprender las

42

necesidades

de los

usuarios

implicaciones de

los

requerimientos

de negocios

(elemento

humano)

Planificación

insuficiente

(proceso)

Alcance mal

definido

Mala

planificación

(elemento

humano)

Expectativas

poco realistas

(personas)

Expectativas

poco realistas

(elemento

humano)

Síndrome de la

panacea

(tecnología)

Estrategia de

implementación

débil (elemento

humano)

Mejoras

prácticas y

lecciones

son

olvidadas

Sobreestimación

de las ventajas

del empleo de

nuevas

herramientas o

métodos

(tecnología)

Ejecución Limitaciones

43

técnicas

Políticas de la

unidad

informática de la

organización

(aspectos

políticos)

Control

Mejoras

prácticas y

lecciones

son

olvidadas

Control

insuficiente de la

directiva

(proceso)

TIPO DE PROBLEMA DE

GESTIÓN McCONNELL GLASS PURBA et al. REDMILL

GESTIÓN

DE

COSTES

Planificación

Omitir tareas

necesarias en

la estimación

(proceso)

Tiempo y

presupuesto

inadecuado

Estimaciones

erradas

Estimaciones

erradas

No se hace

estimación

Escatimar en

las actividades

iniciales

(proceso)

44

Control

Recursos

insuficientes

(elemento

humano)

GESTIÓN

DEL

TIEMPO

Planificación

Omitir tareas

necesarias en

la estimación

(proceso)

Plazos

irreales

Tiempo y

presupuesto

inadecuado.

Estimaciones

erradas

No se hace

estimación

Control

Planificar

poniéndose al

día más

adelante

(proceso)

Programa a

destajo

(proceso)

GESTIÓN

DE LA

CALIDAD

Planificación

Se carece

del

personal

con las

habilidades

adecuadas

Ejecución

Oficinas

repletas y

ruidosas

(personas)

Control

Escatimar en el

control de

calidad

(proceso)

45

GESTIÓN

DE

RECURSOS

HUMANOS

Planificación

Ilusiones

(personas)

Motivación

débil

(personas)

Personal

mediocre

(personas)

Se carece

de

personal

con

habilidades

adecuadas

Insuficientes

habilidades

técnicas

(elemento

humano)

Ejecución

Empleados

problemáticos

incontrolados

(personas)

Pobres

desarrolladores

(elemento

humano)

Desarrolladores

meticulosos

(producto)

Política

individual

(aspectos

políticos)

Hazañas

(personas)

Fricciones

entre los

clientes y los

desarrolladores

(personas)

Falta de

participación de

los implicados

(personas)

TIPO DE PROBLEMA DE

GESTIÓN

McCONNEL

L GLASS PURBA et al.

REDMIL

L

GESTIÓN DE Planificació Insuficientes

habilidades

46

COMUNICACIONES n técnicas

(elemento

humano)

Estrategia de

implementació

n débil

(elemento

humano)

Ejecución

Mejores

prácticas

y

lecciones

son

olvidadas

Control

Se carece

del

personal

con las

habilidade

s

adecuada

s

Cierre

Tiras y

aflojas en la

negociación

(personas)

Falta de

participación

del usuario

(personas)

GESTIÓN DEL

RIESGO

Planificació

n

Gestión de

riesgo

insuficiente

(proceso)

Control Tiras y

aflojas en la

negociación

47

(personas)

GESTIÓN DEL

APROVISIONAMIEN

TO

Planificació

n

Fallos en los

contratados

(proceso)

Incapacidad

para tratar

con

contratistas y

vendedores

(elemento

humano)

Ejecución

Incapacidad

para tratar

con

contratistas y

vendedores

(elemento

humano)

Control

Recursos

insuficientes

(elemento

humano)

Cierre

Se carece

del

personal

con las

habilidade

s

adecuada

s

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 diseño y análisis de sistemas además de una buena formación en las funciones básicas de dirección.

48

El director de proyectos no es simplemente un analista experimentado que se hace cargo del proyecto, sino más bien debe aplicar un conjunto de técnicas y conocimientos diferentes de los que aplica un analista.

Las funciones básicas de un gestor de proyectos han sido analizadas y diseccionadas por teóricos de la gestión durante muchos años. Entre estas funciones, se incluyen la planificación, la selección de personal, la organización, la definición de calendarios, la dirección y el control.

a.- Planificación de las tareas de proyecto y selección del equipo de proyectos

Un buen director siempre tiene un plan. El director evalúa 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 básico para el desarrollo de un sistema de información es el suministrado por el ciclo de vida del desarrollo de sistemas. Muchas empresas tienen su propio ciclo de vida estándar, y algunas de ellas tienen también normas sobre métodos y herramientas que han de usarse.

Así ha de planificarse cada una de las tareas requeridas para completar el proyecto:

¿Cuánto tiempo se requerirá? ¿Cuántas personas serán necesarias? ¿Cuánto costara la tarea? ¿Qué tareas deben terminarse antes de empezar otras? ¿Pueden solaparse algunas de ellas?

Estas son cuestiones propias de la planificación. Algunas de ellas pueden resolverse con ayuda de un gráfico PERT (Proyect Evaluation and Rewiev Technique) que fue desarrollado a finales de la década de 1950 - 1959 para planear y controlar los grandes proyectos de desarrollo armamentístico del ejército estadounidense. Fue desarrollado para evidenciar la interdependencia de las tareas de los proyectos cuando se realiza la planificación de los mismos. En esencia, PERT es una técnica de modelos gráficos 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 debería tener muy en cuenta los conocimientos técnicos y de empresa que pueden ser necesarios para terminar un proyecto con éxito. La clave de esta misión es saber elegir adecuadamente a las personas que habrían de desarrollar las tareas requeridas e identificada como parte de la planificación de proyecto.

b.- Organización y definición de calendarios para el proyecto

Dados el plan y el equipo de proyecto, el gestor de proyectos es el responsable de la organización y la definición del calendario del mismo. Los miembros del equipo de proyecto deberán conocer su cometido y sus responsabilidades concretas, así como su relación de dependencia con el respecto al gestor del proyecto.

49

El calendario de proyecto debería 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 límite a la fecha de entrega solicitada. El gestor debe determinar si puede elaborarse un calendario factible basado en dicha fecha. Si no fuera así, debería retrasarse el límite o reajustarse el ámbito del proyecto.

c.- Dirección y control del proyecto

Una vez iniciado el proyecto, el gestor del proyecto se convierte en su máximo 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 dirección, como son saber motivar, recompensar, asesorar, coordinar, delegar funciones y reconocer el trabajo de los miembros de su equipo. Además, el gestor debe informar frecuentemente del avance del proyecto ante sus superiores.

Tal vez, la función más difícil e importante del gestor sea controlar el proyecto. Pocos planes hay que puedan llevarse a la práctica 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 decisión: ¿habría que reducir el ámbito del proyecto para respetar el presupuesto y los plazos, o revisar dicho presupuesto y dichos plazos? El gestor del proyecto debería ser capaz de presentar alternativas, y sus implicaciones, a los plazos y presupuestos para saber responder a las expectativas.