Capítulo 1.- Introducción a la gestión de proyectos

O B J E T I V O S

- Conocer los aspectos esenciales que definen una Teoría de Proyectos, reconociendo los tipos de proyectos existentes.

- Adquirir un enfoque general, para entender de forma rápida y sencilla los pasos a seguir en la realización de un proyecto.

1.1. Introducción A lo largo de la historia, la preocupación del hombre por la naturaleza de todo lo que le rodea, ha pasado por distintas etapas y sufrido importantes cambios.

Figura 1.1: Evolución del hombre.

Con la llegada del Renacimiento, surge la inquietud de profundizar en diversos temas para comprenderlos mediante unos esquemas muy simplistas.

A grandes rasgos, se podría señalar que en los comienzos del Renacimiento nace el método del análisis, el cual permite trabajar actuando en tres etapas sucesivas:

a) se separa el todo en las partes que lo constituyen,

b) se estudia el comportamiento de cada parte y

c) se ensamblan dichas partes, que aisladamente ya se han entendido, tratando de comprender el conjunto.

El análisis ha sido el método de trabajo típico y esencial de la Edad Moderna y de la revolución Industrial, la adopción de ese método frente a los problemas del universo ha llevado en la filosofía la teoría del reduccionismo que plantea:"Todo puede reducirse a partes fundamentales, que no pueden reducirse más".

Con el tiempo, esta necesidad de resolver un problema por partes -exponiendo un proceso racional y científico llevó a definir etapas cada vez más establecidas y definidas; dando lugar a metodologías y procesos de trabajo. Todo esto, de forma natural, llevó a identificar pasos de resolución de problemas, cuyo cumplimiento frente a las necesidades sociales y las limitaciones tecnológicas requería un esfuerzo de organización; de esta manera, se llega a la idea de un proyecto.

1.2. Concepto Entendemos como proyecto el conjunto de actividades planificadas, ejecutadas y supervisadas que, con recursos finitos, tiene como objetivo crear un producto o servicio único.

En términos más formales: "Un proyecto es 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 tal vez también con la colaboración de terceros".

Otras definiciones y características, dadas por diversos autores son:

Los proyectos involucran una gran cantidad de tiempo y costo, que es necesario el involucramiento del control de la administración para ser cumplido dentro del tiempo y los límites de costo... las técnicas dirigidas hacia el control de los costos, tiempo, recursos y financiación del proyecto durante el proceso.

"Operación científica que lleva a conseguir un objetivo material predeterminado por modificaciones de la realidad exterior mediante unas acciones humanas que han sido seleccionadas y ordenadas con anticipación, de acuerdo a unos criterios". (Serer, 2001).

"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". (RAE, 2001).

"Conjunto de documentos que a partir de una situación concreta permiten transformar una realidad en un período de tiempo determinado". (De Cos, 2003).

Estos conceptos emergen de observar que las tareas humanas se organizan bajo ciertas condiciones, cuyo manejo y aprovechamiento prefiguran las cualidades que afectan todo proyecto. A continuación se listan y describen las cualidades principales:

1. La persecución de uno o varios objetivos.

2. Actividades planificadas, ejecutadas y supervisadas.

3. Disponibilidad limitada de recursos.

4. Limitación de Tiempo.

1.2.1. 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.

1.2.2. 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 una 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.

1.2.3. 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 fueran ilimitados, desaparecería el concepto de eficiencia y con él la naturaleza proyectual de las actividades.

1.2.4. Limitación de tiempo

Un proyecto debe estar acotado en términos de principio y fin del mismo. El final de un proyecto se alcanza cuando se cumplen los objetivos prefijados, o cuando se hace evidente que dichos objetivos no pueden alcanzarse (fracaso del proyecto). Por otro lado, aunque el proyecto tenga que estar acotado en el tiempo, no sucede lo mismo con sus resultados, que pueden perdurar con carácter indefinido (por ejemplo, una catedral). Con esto, los proyectos, se caracterizan por:

- Tener objetivos específicos;

- Completarse dentro de un periodo determinado;

- Tener un inicio y un fin bien determinados;

- Completarse dentro de las restricciones de un presupuesto;

- Ser ejecutados por un equipo; y,

- Ser únicos.

1.3. Clases de proyectos El concepto de Proyecto puede presentar concepciones diferentes según mentalidades y modos de hacer en los distintos ámbitos profesionales. Existen dos ramas estrechamente vinculadas al mundo de los proyectos y a los procesos de decisión: los técnicos y los empresarios (promotores, evaluadores y gerentes); que pertenecen a campos profesionales distintos.

Clasificar un proyecto concreto no es sencillo, pues la variedad y diversidad es elevada. Sin embargo, es preciso recordar que al abordar un proyecto, se debe tener en cuenta que éste presenta diferentes aspectos en función de sus objetivos, recursos disponibles, contexto, etc.

Frente a dicha complejidad operativa, surge la necesidad de disponer de una amplia gama de conocimientos técnicos que permitan alcanzar una visión global de la realidad; no sesgada ni restringida a un único campo disciplinario.

1.3.1. Criterios de proyectos

Teniendo en cuenta lo precedente, es posible sugerir una tipología general utilizando las siguientes criterios de distinción:

1. Por objeto al cual hace referencia el proyecto.

2. Por actividad o alcance.

3. Por rol de usuario o contexto en el cual se desarrolla el proyecto.

4. Por sector, ciencia y/o técnica que predomina en el proyecto.

5. Por finalidad.

Nota: Debe aclararse que estos criterios ni reúnen todos los existentes ni son determinantes.

1.3.2. Por objeto

1.3.2.1. Proyecto clásico

En el proyecto clásico se realiza una serie de documentos que definen 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 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.

Estos proyectos tienen características comunes que se citan a continuación:

Complejidad

Como consecuencia de las múltiples variables que forman parte de los proyectos, así como las numerosas relaciones existentes entre ellas se puede decir que el proyecto es un sistema organizado, generalmente complejo.

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. 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 expertos en diferentes disciplinas. Por ello, una tercera característica para proyectos de ingeniería complejos e integrales es la disponibilidad de conocimientos multidisciplinarios.

Globalidad del sistema

Un proyecto no puede ser considerado como una mera yuxtaposición de sus cuatro documentos formales básicos (memoria, planos, pliego de condiciones y presupuesto), sino que deben de contemplarse desde una visión de conjunto de las relaciones entre los distintos elementos que lo constituyen.

Los proyectos guardan un intercambio con su medio exterior o entorno, del que consumen recursos (naturales, sociales, económicos,...) y al cual emiten bienes y servicios. En este sentido la estimación de los efectos de los proyectos y de las actividades empresariales con relación al medio ambiente (evaluaciones de impacto ambiental, diagnósticos ambientales y ecoauditorías) y al medio humano (impacto social), son aspectos prioritarios hoy en día.

Necesidad de un plan

Para el empleo de recursos involucrados, el proyecto deberá dotarse de un programa de actividades específicas que permitan alcanzar los objetivos concretos del sistema, dentro de unos plazos establecidos; además, necesitará un plan de gestión económico y financiero.

Flexibilidad y capacidad de adaptación

Un proyecto deberá mantener un cierto equilibrio y estabilidad internos a pesar de las perturbaciones que recibe por los cambios en las variables del entorno: factores ambientales, políticos, tecnológicos, legales, etc. En ocasiones, la dificultad de poder prever si los efectos de los cambios serán beneficiosos o contrarios a los intereses del proyecto, hacen necesaria esta flexibilidad o capacidad de adaptación del proyecto.

1.3.2.2. Proyecto de investigación

El objetivo de los proyectos de investigación, 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, cuya finalidad es que otros se vean beneficiados, ya 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.

1.3.2.3. Proyecto industrial

Los proyectos industriales se diferencian de los otros por la mayor importancia que se atribuye a las características de localización desde el punto de vista técnico, además se exige una definición precisa de toda la tecnología que compone el sistema de producción. En este tipo de proyectos la fase documental se puede desarrollar independientemente de la tecnología hasta un determinado momento, pero a partir de un punto es imprescindible la definición y selección de éstos.

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.

El diseño, la construcción, los ensayos, la puesta en marcha y la cesión de un proyecto industrial, constituyen una secuencia de actividades que se extienden a lo largo de un prolongado período de tiempo -en ocasiones del orden de varios años- y que representa una considerable inmovilización de capitales, recursos inmateriales y humanos. Por consiguiente, el seguimiento de dichas actividades mediante un adecuado procedimiento de planificación y control no sólo puede proporcionar reducciones de tiempo -tanto directamente como indirectamente, solucionando situaciones que producirán retrasos antes de que aparezcan- sino que dichas reducciones son fácilmente objetivables en una serie de valores económicos que justifica los recursos destinados a dicha planificación. Una clasificación bastante representativa de los proyectos industriales con independencia de su origen podría ser:

Grandes proyectos de inversión

Estrictamente esta clasificación 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 clasificación industrial.

En la construcción de un proyecto industrial intervienen frecuentemente numerosas empresas desarrollando trabajos muy diferentes entre sí pero que mantienen una estrecha coordinación para alcanzar los objetivos parciales y globales. Dicha coordinación se inicia a través de un lenguaje común y una clara visión de cuáles son los objetivos y las responsabilidades de cada uno -no solamente técnicos y económicos sino temporales- que asimismo se encuentran involucrados entre sí. Cada trabajo tendrá normalmente su programación individual, pero todas ellas deben combinarse y entrar en el marco de la programación global.

Los sectores, instalaciones y plantas más típicos son los que se enumeran a continuación: 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, pasta, papel y cartón, cemento, centrales eléctricas (hidráulicas, térmicas, nucleares), siderurgia y metalurgia, industria aeronáutica y espacial, industria naval, y 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 un proyectos en si mismo; en muchas ocasiones están interconectados.

Maquinarias, equipos y componentes

El estudio de las maquinarias y equipos que forman parte de cualquier instalación industrial -e incluso algunos componentes de éstos- también constituyen un proyecto en si mismo.

1.3.3. Por actividad o alcance

1.3.3.1. Análisis de información

En ocasiones el alcance de un trabajo concreto se limita a analizar 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).

1.3.3.2. Estudios de viabilidad

Los estudios de viabilidad deben proporcionar la base-técnica, económica y social para la decisión de realizar un proyecto. En estos estudios se deben definir y analizar los elementos críticos relacionados con la fabricación de un producto (bien o servicio) 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 o beneficio social (ver anexo).

1.3.4. Por rol del usuario

1.3.4.1. Proyecto externo

Los proyectos externos a la organización son aquellos en los cuales el interesado en realizarlos es ajeno a la institución o consultora, que hace los trabajos. Se rige fundamentalmente por criterios de mercado, incluyendo competitividad y eficacia.

1.3.4.2. Proyecto interno

Los proyectos internos a la organización, son aquellos en los que el cliente pertenece a la misma institución o consultora que desarrolla los trabajos.

1.3.5. Por sector, ciencia y/o técnica

1.3.5.1. Productos naturales o sector primario

La obtención de productos naturales requiere proyectos en contacto con el medio que se va a tratar, con mucho trabajo de campo y la necesidad de un gran soporte documental. Sin

embargo, requiere una 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.

1.3.5.2. Infraestructuras y edificaciones

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.

1.3.5.3. Productos manufacturados

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

1.3.5.4. Servicios/sistemas de 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.

1.3.6. Por finalidad

Esta última clasificación establece una división respecto a las anteriores. En términos generales un proyecto puede ser evaluado siguiendo una serie de pasos comunes -desde un punto de vista técnico- sin detenerse específicamente en conocer el objeto, el tipo de actividad, el rol del usuario o el sector que el mismo representa.

Algo distinto ocurre en la valoración de las variables determinantes, cuando se trata de proyectos de inversión privada, social o pública.

1.3.6.1. Proyectos de inversión privada

En este tipo de proyectos la finalidad es lograr una rentabilidad económica financiera; permitiendo recuperar la inversión de capital realizada por la empresa -a través del financiamiento propio o por endeudamiento- durante la ejecución del proyecto.

1.3.6.2. Proyectos de inversión social

El fin último de este tipo de proyectos consiste en generar un impacto sobre el bienestar social. Generalmente en estos proyectos no es la prioridad una rentabilidad económica -como en el caso anterior-, aunque sin embargo resulta importante medir la sostenibilidad futura del proyecto aún cuando acabe el período de ejecución del proyecto.

1.3.6.3. Proyectos de inversión pública

En este caso la particularidad corresponde al sujeto en quien recaen las decisiones asociadas al proyecto; siendo el Estado el inversionista que compromete recursos para su ejecución. Los proyectos tienen como fin el bienestar social, por tal motivo importa la rentabilidad social y no sólo la económica. El inversor tendrá en cuenta el impacto que el proyecto genera en la mejora de la comunidad beneficiaria o bien el territorio donde corresponde la ejecución.

1.3.6.4. Otro criterio de distinción

Al interior de cada una de las clasificaciones existen ciertos razgos a tener en cuenta, como ser: el volumen o tamaño de la inversión (pequeña, mediana o grande), la finalidad (nueva instalación, mejora económica, social y/o ambiental, mantenimiento, traslado) la naturaleza del proceso (mecánico, físico, químico) y el origen (propio, de terceros), entre otros.

Capítulo 2 .- Fases genéricas de un proyecto

O B J E T I V O S

- Identificar y definir las fases de un proyecto.

- Conocer acerca de las herramientas de planificación y programación de proyectos.

En el capítulo anterior se observó que los proyectos pueden ser de diferentes tipos, éstos varían según al área de aplicación encargada de su desarrollo. No obstante, muchos autores con experiencia en proyectos de diversa índole, coinciden en que existen ciertos componentes comunes a todo proyecto. Todos ellos siguen prácticamente las mismas pautas en su desarrollo o forma de realización, por lo que el proyecto evoluciona de forma natural. Así, su ciclo de vida, con el que nace, se desarrolla y muere un proyecto puede dividirse en fases generales que a la vez pueden superponerse en el tiempo. Por tal motivo, dependiendo del tipo de proyecto, no es necesario la finalización de una de ellas para comenzar la siguiente; sino que pueden realizarse de forma paralela.

El equipo encargado de llevarlo a la práctica es el que decidirá el tiempo empleado para cada una de las fases y si éstas pueden o no coincidir.

A continuación se presentan las fases de un proyecto, sus rasgos generales y su evolución temporal:

Figura 2.1: Fases genéricas de un proyecto.

1. Fase de definición:

- Definición del proyecto.

- Detección de una necesidad, un problema, o una oportunidad.

- Estudios de prefactibilidad o previabilidad.

2. Fase de concepción:

- Concepción.

- Estudio previos (anteproyecto).

- Selección del proyecto.

- Aprobación del proyecto.

- Estructura de descomposición del proyecto.

3. Fase de construcción.

- Planificación de actividades y recursos.

- Programación y planificación del proyecto.

- Control y seguimiento del proyecto.

4. Fase de puesta en marcha.

- Ejecución del proyecto.

- Alternativas para la ejecución del proyecto.

5. Fase de cesión.

2.1. Fase de definición Todo proyecto surge para satisfacer una necesidad. Como consecuencia, aparecerán una serie de ideas que intentarán proponer la solución a ésta. De todas formas, hay que incidir en un aspecto: la idea normalmente es una proposición que se pone de manifiesto para solucionar una necesidad pero puede ocurrir que aparezca antes de que se haya planteado el problema.

2.1.1. Definición del proyecto

La idea central del sistema a construir a través del proyecto, puede provenir de diferentes fuentes: resultar a partir de otro desarrollo, de problemas existentes en la organización, o de la observación de posibilidades existentes. La fase de definición es aquella en la que la idea se concreta y se realizan los estudios y evaluaciones preliminares.

Durante esta fase se analiza el entorno, se preparan previsiones, se evalúan objetivos y alternativas, y se realiza un primer examen de la misión, objetivos, costos y programa de desarrollo del sistema. Es también en esta etapa inicial que se llega al estudio de factibilidad, que permitirá posteriormente una evaluación más detallada si, como consecuencia del mismo, se decide seguir adelante.

Si la fase de definición se enfoca adecuadamente permitirá eliminar aquellos proyectos que no tienen posibilidad de supervivencia. Las tasa de frustración de los proyectos potenciales durante la fase de definición es alta. Debe ser así, puesto que los estudios realizados durante esta fase deben identificar aquellos proyectos que poseen un elevado riesgo y son técnica y económicamente -o en relación al entorno- irrealizables.

Resulta adecuado mencionar que en todo proyecto debe especificarse qué es lo que desea hacer, en qué consiste, cuándo queremos hacerlo, cómo realizarlo y a qué costo. En muchos casos el cliente tiene una idea, unos objetivos más o menos definidos, un problema o una necesidad y valora de forma más o menos precisa según se fíe en su intuición o realice estudios de apoyo (oportunidad, viabilidad, rentabilidad, costo, beneficio, financiación, etc.) si decide llevarla a término.

Esta definición no debe ser de larga duración ni costosa, pero lo fundamental para el resto de las fases, si tienen lugar, es que se encuentren orientadas a maximizar la probabilidad de éxito. La incógnita que desea aclararse es que debe de realizar el sistema una vez construido o para qué debe de servir, no cómo lo hará ni cómo se llegará a realizarlo, aun cuando la separación de estos aspectos no sea demasiado fácil en general. Al final de la fase

debe de estimarse si la definición es lo suficientemente interesante como para proseguir investigando el tema.

2.1.2. Detección de una necesidad, problema o área de oportunidad

Ésta representa la fase de detección de necesidades, dentro de un contexto limitado por el analista. Aquí se define de manera clara y específica, las situaciones reales y actuales del sistema, dando oportunidad a hacer ciertas predicciones del posible comportamiento futuro del área con necesidad, pero sin establecer jerarquía dentro del análisis.

Para poder identificar estas situaciones, es preciso también cuantificar las necesidades del cliente, interno y externo, en un contexto cultural que en cierta medida responde a factores sociológicos y psicológicos.

PARA IDENTIFICAR PROBLEMAS BUSQUE ESTOS SIGNOS ESPECÍFICOS

Revise las salidas contra los criterios de desempeño

Demasiados errores. Trabajo terminado lentamente. Trabajo hecho incorrectamente. Trabajo hecho en forma incompleta.

Observe el comportamiento de los empleados

Alto ausentismo. Alta insatisfacción en el trabajo. Alta rotación de personal.

Escuche retroalimentación externa de: vendedores, clientes, proveedores, etc.

Quejas. Sugerencias de mejoras. Pérdida o reducción de ventas.

Tabla 2.1. Lista de acciones.

Las mejoras a los sistemas pueden ser definidas como cambios que darán como resultado, beneficios aumentados y que valen la pena. Existen muchas posibilidades de mejoras, incluyendo:

a) Agilización de un proceso mediante la eliminación de pasos innecesarios o duplicados.

b) Combinación de procesos.

c) Reducción de los errores en la entrada por medio de cambios.

d) Reducción de salida redundante.

e) Mejora en la integración de sistemas y subsistemas.

f) Mejora en la satisfacción del trabajador con el sistema.

g) Mejora de la facilidad de interacción de los clientes, proveedores y vendedores, con el sistema.

Se encuentra dentro de las capacidades del proyectista, el darse cuenta de las oportunidades para mejoras. Sin embargo, las personas que están en contacto diario con el sistema, pueden ser mejores fuentes de información acerca de las mejoras que deben de ser hechas. Si las mejoras ya han sido sugeridas, se necesita la experiencia propia para que ayude a determinar si valen la pena y la forma en que pueden ser implementadas.

Aunque la lista de mejoras dada anteriormente es amplia, no es exhaustiva. La parte difícil de sugerir o implementar mejoras, es que deben de valer el desconcierto y costo del cambio.

La metodología más útil para llegar a conocer cuál es la razón por la cual el cliente desea obtener la unidad de actuación, pasa por tratar de obtener un conjunto de respuestas para que el gestor consiga tres avances substanciales: en primer lugar centrar a su cliente, ayudándole a definir mejor sus propios deseos; en segundo, conocer la sintonía por la que se ha de mover la gestión de proyectos únicos; y en tercer lugar, acercarse al conocimiento que el cliente tiene de sus propios deseos y/o necesidades. Las respuestas se deberán tener de las siguientes preguntas: qué y para qué, a quién, por qué, dónde, cuándo, cómo, cuántas veces, cuánto tiempo y a qué costo.

Cuando los requerimientos del sistema son definidos inicialmente en respuesta a una necesidad identificada del consumidor, el objetivo es desarrollar y producir (o construir) una configuración que llevará a cabo las funciones tal y como se definieron.

Dicho proceso de traducir estos requerimientos especificados inicialmente a una entidad funcional, debe de contemplarse no sólo de manera oportuna, sino también debe de llevarse a cabo efectiva y eficientemente.

En otras palabras, dada una necesidad definida, se debe desarrollar un sistema e incorporar las características esenciales de desempeño, efectividad y calidad. Esto se lleva a cabo mediante la aplicación adecuada de métodos de diseño con el estado del arte, la integración oportuna de disciplinas de diseño adecuadas, etc.

2.1.3. Estudios de prefactibilidad o previabilidad

Previo al estudio de factibilidad, deben estar claros los siguientes puntos:

a) Interés y prioridad de la idea del proyecto.

b) Diagnóstico racional del área del proyecto.

c) Viabilidad técnica del futuro proyecto: estudio de alternativas estratégicas para determinar las metas y su selección.

d) Viabilidad económica y política.

e) Viabilidad legal.

f) Viabilidad social.

g) Identificación de problemas y obstáculos derivados de la puesta en marcha del proyecto.

h) Estudio de las fuentes de financiación.

i) Beneficiarios del proyecto.

El resultado de esto puede ser, el archivo del proyecto para una consideración futura, rechazo en forma definitiva o pasar a la fase de estudio de factibilidad.

2.2. Fase de concepción En esta fase los aspectos más relevantes mencionados anteriormente se han de profundizar, es decir, se tienen que identificar con más precisión los recursos necesarios, especialmente los recursos humanos, que juegan un papel muy importante en la elaboración de un proyecto. En relación con el coste del proyecto, también se intentará dar cifras más exactas. Asimismo hay que acotar exactamente lo que se va a hacer, definiendo de forma muy concreta el problema que se pretende resolver.

Se determinarán todos los objetivos del proyecto, cada uno de los cuales trata de cubrir alguno de los problemas específicos que pueden incidir decisivamente en el resultado global. Estos objetivos varían de un proyecto a otro, pero hay algunos que son comunes en todos los proyectos: calidad, plazo y precio.

Es en este momento cuando debe hacerse una buena planificación para el desarrollo del proyecto, establecer las fechas de inicio y finalización de cada una de las actividades. También se elabora la documentación: normativas, manuales, procedimientos, descripción de actividades, presupuestos, impresos, etc., que ayuda a llevar un control más estricto y saber en cada momento qué es lo que se ha realizado y qué es lo que falta para llegar al final. Los documentos del proyecto son el instrumento de comunicación más importante del proyecto y permite un buen entendimiento entre todos los grupos que intervienen en él.

Es una fase de creación de lo que hay que hacer y de cómo se hará, considerando los estudios previos, concepción del proyecto, concepción de los objetivos y con la idealización de la estructura de la descomposición del proyecto.

2.2.1. Concepción

Representa la fase de generación de las ideas y su enmarcado, delimitación y la naturaleza de los objetivos, las necesidades, los usuarios, la filosofía la viabilidad técnica, económica o

social, así como los riesgos predecibles. El nacimiento de un proyecto se corresponde con una idea, en un principio, poco definida. En esta fase, se requerirá un esfuerzo creativo importante, que permita identificar las posibilidades que constituyen un proyecto potencial.

El equipo que desarrolla esta fase no es necesariamente el que continuará con las fases posteriores, sin embargo, es recomendable que el gestor del proyecto se mantenga desde un principio y sea no solamente quien más conoce el proceso en su forma y en su fondo sino quien, además, servirá de nexo de continuidad con el resto del equipo, el cual se ampliará y cambiará de acuerdo a las necesidades.

La definición de los objetivos de los proyectos, no es siempre una tarea exclusiva del cliente, pues puede contar para eso, con el asesoramiento y las sugerencias de los técnicos que lo van a ejecutar, pero es quien debe de explicar lo que quiere, adoptar las decisiones que permitan precisar el contenido y finalmente, aprobar los objetivos que se hayan establecido en el proceso de negociación con los encargados de desarrollar el proyecto.

Durante la ejecución del proyecto, el cliente debe de realizar un seguimiento lo suficientemente cercano de la evolución del mismo, de su grado de avance y del nivel de consecución de los objetivos.

La contratación de una empresa externa o el encargo a otro departamento interno, no permite que el cliente se desentienda de la marcha del proyecto, y se limita a cumplir sus obligaciones financieras y espere que el desenlace final sea satisfactorio. Debe de seguir de cerca la evolución del proyecto y los plazos de control, velando que se alcancen los niveles de calidad establecidos; tomando las decisiones que pudiesen ser de su competencia para facilitar el avance y estimulando con su interés y atención a los técnicos para evitar una relajación que redundaría en pérdida de eficacia.

2.2.1.1. Concepción general

Puesto que el proyecto se considera realizable, hay que definirlo desde el punto de vista técnico y realizar un estudio detallado de cada una de las soluciones posibles, que todavía estén en consideración, con ensayos, maquetas, etc., si es necesario a fin de elegir la solución a adoptar o por lo menos restringir el abanico de posibilidades.

El documento final presenta una proposición completa y coherente, con las características técnicas principales, calendario, estimación de costos (más precisa que la anterior), recursos necesarios, plan financiero probable, y recomendaciones para la fase siguiente. Puede adoptarse la decisión de abandonar el proyecto o seguir.

ASPECTOS A CONSIDERAR EN LA CONCEPCIÓN GENERAL

DEFINICIÓN TÉCNICA

Misión Precisarla - Mantenerla.

Objetivos Concretarlos. establecer jerarquía. Preservarlos.

Actuación regular Funcionamiento normal y detallado.

Actuación degradada Funcionamiento detallado del sistema en caso de incidente.

Actuación inicial Funcionamiento detallado del sistema durante la puesta.

Prestaciones Resultados según los modos.

Descripción Exhaustividad en la descomposición del sistema en niveles y del proyecto en actividades.

Tecnologías Precisar las incógnitas y el riesgo. Aceptar cambios.

Calidad / fiabilidad Estudio de conjunto y de detalle.

Ensayos Definición precisa de las pruebas parciales y de conjunto, previas para dar de alta elementos, subsistemas y el sistema.

DEFINICIÓN DE MEDIOS

Financieros Costos, presupuestos, plan de financiación.

Mano de obra Tipos, equipos de gestión y dirección del proyecto. Limitaciones en especialidades raras.

Materiales Prever: alquiler, construcción, compra.

DEFINICIÓN DE CALENDARIO

Exigencias externas Puntos fijos obligados. Interfaces.

Duración de actividad Ciertas, aleatorias. optimistas.

Restricciones Potenciales, acumulativas, incompatibles.

ORGANIZACIÓN DEL PROYECTO

Organización Estructura tipo "proyecto", convencer, decidir.

Plantilla Disponibilidad de recursos humanos.

Soporte Disponibilidad de los recursos de soporte.

Contratos Descomposición de unidades, tipo.

Sistemas de información Circuitos adaptados al proyecto. Cuadro.

Relación información / decisión Formalizar líneas de autoridad.

Tabla 2.2. Concepción general del proyecto.

2.2.1.2. Concepción detallada

Se realiza la descomposición del proyecto en subproyectos o macroactividades, realizando el análisis de las mismas, a fin de poder proceder a su asignación a los entes que las van a realizar (en su caso deberán de preparar las modalidades de contratación). Se establece la organización básica de la realización: especificaciones técnicas, costos, calendario, formas de gestión y control, ensayos previos a la recepción, etc.

2.2.2. Estudios previos

2.2.2.1. Estudios de factibilidad y viabilidad

La factibilidad, significa determinar si el proyecto propuesto ayuda a que la organización logre sus objetivos generales; así como también si es posible de lograr con los recursos actuales de la organización, desde el punto de vista: técnico, económico y operacional.

El estudio de viabilidad es estrictamente detallado y requiere un mayor consumo de recursos, lleva consigo una reducción del grado de incertidumbre y una mayor cuantificación y definición de los costos y beneficios del proyecto a lo largo del tiempo.

El análisis de viabilidad requiere de información primaria; además de los aspectos antes mencionados, debe incluir los siguientes puntos:

Análisis de los condicionantes que incidirán en el proyecto. Localización y tamaño. Diseño del ante-proyecto. Definición y detalle del plan de explotación. Selección de alternativas estratégicas. Definición concreta de los objetivos del proyecto. Tecnologías de producción o transformación con diseño casi definitivo del proceso. Identificación y cuantificación de los costos y beneficios del proyecto, desde las siguientes

perspectivas: económica, social y ambiental. Identificación, organización y análisis de agentes y beneficiarios. Posibilidades de mercado y canales de comercialización. Propuesta de organización, administración y gestión del proyecto. Posibilidades de financiación: comunitaria, nacional, autonómica, local. Estudio a fondo del marco legal. Evaluación multicriterio del proyecto. Calendario de ejecución. Puesta en marcha.

Los resultados del estudio de viabilidad, llevarán a:

Archivarse para una reconsideración futura. Modificarse en su formulación. Rechazarse en forma definitiva. Aprobarse definitivamente.

Ya hemos visto anteriormente que una de las fases del proyecto es la que se refiere a la realización de diversos estudios previos antes de decidir definitivamente acometer el proyecto.

Los estudios previos se reducen muchas veces a un estudio de la viabilidad del proyecto solamente desde tres puntos de vista:

Técnico. Económico. Financiero.

Un estudio serio de viabilidad abarca mayor diversidad y exige la realización de una serie de estudios parciales de distinto tipo como son:

Estudio de mercado. Tamaño del proyecto. Tecnología. Localización. Emplazamiento. Impacto ambiental. Estimación de la inversión. Financiación. Presupuesto de ingresos y gastos: flujo de carga, evaluación y análisis.

No obstante, es posible suprimir algunos de ellos, ya que el entorno general donde se va a situar el posible proyecto permite efectuar simplificaciones. Por ejemplo, un estudio de viabilidad puede caracterizarse de la siguiente manera:

Figura 2.2: Secuencia de estudios.

Durante esta subfase puede concretarse el organigrama técnico del proyecto (WBS- Work Breakdown Structure), establecido seguramente con anterioridad. Un organigrama técnico es la descomposición funcional de las tareas del proyecto, una lista de las tareas organizada en forma jerárquica o de árbol. El trabajo puede subdividirse en tantos niveles como sea necesario para alcanzar el tamaño de tareas deseado. El nivel más bajo de la división debe ser lo suficientemente fino como para permitir visibilidad y control adecuados sin crear un volumen tal de tareas que sea inmanejable administrativamente.

2.2.2.2. Estudios de mercado

Otro campo que frecuentemente requiere de estudios previos es el referente al mercado, o la demanda existente y potencial. El proyecto requiere de estudios previos referentes a la demanda o a las condiciones de comercialización de los mismos. Como la demanda está en función del precio, será necesario efectuar estimaciones de la misma para distintos precios y de igual modo limitarla geográficamente porque la localización del nuevo proyecto depende en gran medida del tamaño del mercado y de la distribución de los posibles consumidores.

La investigación de esta demanda exigirá el estudio de todos los antecedentes existentes y muy especialmente de las series estadísticas disponibles sobre el bien en cuestión: de producción, comercio exterior y consumo, así como series de precios e índices de los mismos y series de ingresos nacionales y de crecimiento de la población.

Antes de lanzar un nuevo producto podremos estar interesados en conocer si existe o no demanda para el mismo y en qué condiciones. Por ejemplo, antes de construir una nueva

planta de fabricación será necesario saber qué cantidades de los productos a fabricar puede absorber el mercado; o bien antes de construir una autopista habrá que prever el volumen de tráfico esperado y las tarifas de peaje que podrán ser percibidas.

2.2.2.3. Tamaño del proyecto y tecnología

El estudio de mercado proporciona una información fundamental para poder determinar el tamaño del proyecto, es decir, la capacidad de producción durante un período de tiempo de funcionamiento que se considera normal.

La elección del tamaño presenta como límite superior la demanda insatisfecha que se va a cubrir y como límite inferior la unidad mínima de producción rentable. Esta cantidad mínima no es universal, sino que depende del entorno socioeconómico del proyecto y de las características del mercado que debe abastecer.

En la mayoría de los casos la futura política de ventas de la sociedad promotora es poco reconocida pero tiene gran importancia, ya que puede influir en la fijación del tamaño, la organización de las ventas, la fijación de precios, la política de distribución, las comisiones y descuentos, la necesidad de servicios postventa, entre otros; lo anterior debe materializarse en un programa de ventas y consecuentemente en un programa de producción.

Otros factores importantes a tener en cuenta a la hora de fijar el tamaño son los costes de producción y distribución, el proceso tecnológico, el volumen de la inversión y el financiamiento disponible, los costes de operación, los de las materias primas y las cargas financieras de la inversión total.

La selección de la tecnología a utilizar también juega un papel muy importante. Se tendrá en cuenta los costes de la propia tecnología, de la inversión que supone y los futuros costes de producción, así como el desarrollo de tecnologías competitivas de próxima o posible aparición.

2.2.2.4. Localización, emplazamiento e impacto ambiental

La localización y emplazamiento adecuados serán aquellos que nos proporcionen mejores resultados económicos. Para ello será necesario analizar las variables conocidas como fuerzas o factores de localización, esto es: coste de transporte de materias primas y productos, disponibilidad y coste relativo de los recursos (costes de mano de obra y servicios de energía, agua, etc.) y los factores políticos, sociales, administrativos y legales. Estos últimos factores son cada vez más decisivos al momento de evaluar un proyecto y pueden llegar a ser vitales. Por ejemplo, esto ocurre cuando las facilidades fiscales, las subvenciones y en general las ayudas estatales (regionales o municipales), otorgadas habitualmente por razones políticas, alcanzan cuantías importantes.

Posibles localizaciones serán aquellas en las que resulta mínima la suma de los costes de transporte de las materias primas hasta la planta y de los productos hasta el mercado.

El factor predominante para elegir el área de localización en el caso de que existan diversas soluciones rentables será el coste de los terrenos en función de sus características (calidad del suelo, infraestructura disponible, ordenanzas existentes, etc.).

El estudio del impacto ambiental es cada vez más importante en el momento de determinar la localización y emplazamiento del proyecto.

Se considera que hay impacto ambiental cuando la realización de un determinado proyecto altera el medio ambiente incidiendo en alguno de sus componentes, prestando especial importancia cuando se altera la salud o el bienestar de la comunidad, del hombre.

Para determinar los efectos que un determinado proyecto puede tener sobre el medio ambiente se realizan los estudios de impacto ambiental (EIA), que permiten identificar, predecir, interpretar y comunicar estos efectos. Las posibles alteraciones se valoran tanto en su magnitud como en el tiempo.

Estas evaluaciones exigen seleccionar unas magnitudes significativas y unas unidades de medida; en este caso las magnitudes que se han de elegir son los denominados indicadores de impacto, definidos como aquellos parámetros que mejor definen los efectos del proyecto en el medio ambiente por ser exclusivos, medibles y representativos. De todas estas magnitudes se hará un estudio de tres situaciones distintas: estado cero, estado futuro sin proyecto y estado futuro con proyecto.

El estado cero define las condiciones ambientales actuales y las características físicas, biológicas, sociales y económicas del entorno; el estado futuro sin proyecto extrapola la situación anterior en el tiempo, mientras que el estado futuro con proyecto sería precisamente el estado cero más el impacto ambiental que el proyecto ocasione.

2.2.2.5. Estimación de la inversión

Los distintos estudios mencionados anteriormente son de carácter técnico y es necesario completarlos con otros de carácter económico y financiero.

Es preciso que la estimación de la inversión requerida por el proyecto se realice de la forma más exacta posible. Debe estudiarse anticipadamente el presupuesto, la distribución en el tiempo, y qué recursos van a utilizarse para financiar la inversión. Así mismo, analizar las posibles fuentes de financiamiento a emplear, el costo de las mismas según el tipo de recurso empleado y las condiciones requeridas, para tener acceso a una u otra fuente. En ésta se deberá diferenciar entre el capital necesario para el proyecto desde su consideración como centro de transformación de recursos, es decir, el capital fijo o inmovilizado y el capital requerido para el posterior funcionamiento normal y la puesta en marcha de las instalaciones, es decir, el capital de trabajo o capital circulante.

El capital fijo está constituido por el valor monetario de los activos fijos, que comprenden todo el conjunto de bienes que se adquieren una sola vez durante la ejecución del proyecto y se

utilizan a lo largo de su vida útil. El capital fijo viene condicionado por diversos factores, que pueden variar de un proyecto a otro.

Sin embargo, en términos generales pueden encontrarse los siguientes:

Ensayos, investigaciones y estudios previos. Constitución y organización de la institución que realice el proyecto. Terrenos y recursos naturales. Instalaciones de la actividad principal, provisionales y auxiliares. Puesta en servicio. Intereses durante el período de construcción. Varios e imprevistos.

Lógicamente la importancia de cada uno de ellos será variable y distinto de uno a otro tipo de proyecto. Lo mismo ocurre con el capital circulante; el cual toma valores cercanos (proyectos de edificación para arrendamiento) hasta valores muy elevados (proyectos agroindustriales con financiación de cosecha). Éste depende de la política financiera, de los sistemas de distribución y comercialización y de los niveles de stocks fijados.

La inversión requerida supondrá el análisis de diferentes fuentes de financiamiento. Es aconsejable asegurar estas fuentes incluso antes del estudio de viabilidad para evitar cualquier tipo de estudio en vano si desde un principio no se dispone de medios suficientes. Las fuentes de financiamiento en una primera clasificación se pueden dividir en internas y externas. Las internas son las que utilizan los propios fondos generados por la empresa en su actividad anterior al nuevo proyecto (autofinanciación), y las externas son las distintas modalidades del mercado de capitales: acciones, obligaciones, bonos y préstamos. Los préstamos a su vez pueden ser créditos bancarios (comerciales y a corto, medio y largo plazo), créditos a la exportación y crédito de proveedores.

Es necesario que el proyecto sea solvente para garantizar financiamiento externo y así, ofrecer garantías a las entidades financieras. De todos modos, en la actualidad es frecuente utilizar los propios fondos generados por el proyecto, es decir, el flujo de caja que sea capaz de generar, como principal garantía para conseguir las facilidades financieras necesarias. Ello forma parte importante de lo que se conoce como ingeniería financiera.

2.2.2.6. Presupuesto de gastos e ingresos: flujo de caja

La tendencia actual es estudiar por separado el flujo de caja de los proyectos (y a partir de ese estudio establecer su rentabilidad) y la financiación necesaria. Con ello se consigue un mejor conocimiento de las características del proyecto.

El cash-flow o flujo de caja operativo del proyecto corresponde a la diferencia entre los fondos generados cada año y las inversiones realizadas durante el mismo, y ello a todo lo largo de la vida del proyecto.

Los fondos que el proyecto genera cada año son el resultado de sumar el beneficio después de impuestos y las cantidades destinadas a amortización. La diferencia entre los ingresos y

los gastos del proyecto a lo largo de su vida útil independientemente de las inversiones genera un beneficio bruto. Si descontamos los impuestos correspondientes obtenemos el beneficio neto.

Los gastos del proyecto se dividen en los propios costes de producción y la amortización de la inversión.

Los costes de producción son diversos y dependen de la naturaleza del proyecto, pero los que mencionamos a continuación son frecuentemente comunes en la mayoría de proyectos:

Materias primas y otros materiales. Servicios auxiliares. Mano de obra. Coste de las ventas. Seguros, impuestos y alquileres. Varios e imprevistos.

La amortización del inmovilizado, que no incluye los terrenos, tiene por objeto hacer frente a la depreciación y obsolescencia de las instalaciones, creando un fondo contable para permitir reponer en su momento las instalaciones amortizadas.

Todos los costes expuestos anteriormente son directos y evolucionan en forma inversamente proporcional al plazo de ejecución del proyecto; acortar el plazo supone incrementar los costes y viceversa, aunque sólo se produce esto para ciertos límites de coste y plazo.

Existen también otros costes que, aunque resulten poco significativos en la mayoría de proyectos es conveniente mencionarlos, debido a que su aumento se comporta en relación directa al aumento del plazo. Por ejemplo, el alquiler de las instalaciones en las que se realiza el proyecto, además de los gastos generales como electricidad, teléfono, etc.

Una demora en el proyecto somete al cliente a unos perjuicios que podrían evaluarse, es más, en ciertos casos se habrá pactado una indemnización al cliente por cada día o cada semana de demora, con lo que resulta evidente que este tipo de coste es proporcional al plazo.

2.2.2.7. Evaluación y análisis de proyectos

Finalmente la última serie de estudios previos corresponde a la evaluación y análisis de la información técnica, y especialmente económica, que proporcionan los estudios anteriormente descritos.

Quien decide acometer un proyecto normalmente espera obtener un resultado rentable, o bien cierto beneficio social, salvo ciertos casos especiales como inversiones de carácter estratégico o inversiones "obligadas" por razones legales o de otro tipo. Frecuentemente, sin embargo, incluso agentes que presumen de una gestión muy profesional, toman decisiones sobre proyectos sin que exista un estudio siquiera somero de la rentabilidad esperada.

La limitación de los recursos disponibles tanto en el sector público como en el privado, obliga a realizar una evaluación y por ello deben administrarse de la forma más eficaz posible.

El proyecto deberá ser rentable, tanto en valores absolutos como relativos, siendo ésta una condición previa para que se decida llevar a cabo un proyecto. En el caso de instituciones sin fines de lucro, la rentabilidad económica no será una meta pero no significa que la inversión deba realizarse sin la debida reflexión y sin conocerse el costo-beneficio que se preve lograr en una sociedad y territorio determinado.

Existen dos tipos distintos de evaluación del beneficio, el social, que trata de conseguir el mejor beneficio para la comunidad, y el empresarial, que trata de obtenerlo para la organización promotora e inversora.

El criterio más utilizado para la evaluación de proyectos industriales es el empresarial, ya que en economías de mercado suelen ser acometidos de esta forma. Sin embargo, es posible trasladar estos criterios a la evaluación social utilizando precios sociales y teniendo en cuenta los efectos indirectos.

Los criterios de rentabilidad se enuncian a continuación:

Tasa de rentabilidad

Definida como beneficio por unidad de capital empleado, distinguiendo si se trata sólo de capitales propios o se incluyen también los créditos utilizados.

Lógicamente, resulta claro que un proyecto será interesante si su tasa de rentabilidad prevista no sólo es positiva sino que es superior a la que se podría obtener depositando el dinero en un banco o invirtiéndolo en deuda del estado.

Este cálculo en forma tan simple como se ha expuesto permitiría comparar proyectos diferentes siempre que su duración no fuese superior a un año, lo que representa un caso bastante especial. Si el proyecto tiene una duración mayor, como es normal, el cálculo queda desvirtuado por el distinto valor que tienen los importes monetarios pagados o recibidos en diversos momentos de tiempo.

Período de recuperación del capital

Es el tiempo necesario para recuperar el capital que se ha invertido y, por tanto, indica a partir de qué momento los ingresos derivados del proyecto representarán ya beneficios y no mera recuperación de lo anteriormente invertido.

Teniendo en cuenta este período sólo será válido comparar proyectos que tienen una duración similar y cuyo comportamiento de gastos e ingresos es homogéneo y relativamente estable en el tiempo.

Velocidad de rotación del capital

Definida como cociente entre el valor bruto de la producción anual (ventas) y el capital.

Todos los criterios anteriores para comparar proyectos tienen el inconveniente de operar (sumar, restar, etc.) con unidades monetarias de años diferentes, cuyo valor es también diferente. Si se suman unidades monetarias de años distintos se comete un grave error. Ello es particularmente importante si se comparan proyectos con una gran extensión en el tiempo o cuyas inversiones o ingresos se producen en períodos de tiempo muy diferentes.

En general, lo que se hace es actualizar todas las cifras de gastos e ingresos a unidades del año inicial, para lo que se aplican dos criterios, el valor actual neto y la tasa interna de retorno.

Valor actual neto (VAN)

Definido como la suma de los distintos flujos de caja generados por el proyecto, descontados a un determinado tipo de interés, será:

Donde:

Ct = flujos de caja.

I0 = inversión inicial.

k = tasa de actualización.

t = años de duración del proyecto.

El flujo de caja al comienzo del proyecto, habitualmente, será negativo, ya que en ese primer período la inversión será previsiblemente alta y todavía no se habrá generado ningún beneficio. Por esa razón en la ecuación anterior los primeros términos suelen tener signo negativo.

Subsiste, sin embargo, un problema práctico importante: ¿qué tasa de actualización debemos aplicar para efectuar los cálculos? Es evidente que el hecho de aplicar una tasa mayor o menor altera los cálculos y puede modificar notablemente las conclusiones. Si se aplica una tasa más baja, el grado de actualización es menos acusado y, por tanto, se ven menos afectados los proyectos de mayor duración; si por el contrario se aplica una tasa más alta, las cantidades más alejadas en el tiempo resultan reducidas en una mayor proporción.

Por lo tanto, como estamos estimando resultados futuros previsibles siempre se podrán encontrar argumentos para aplicar una tasa de actualización mayor o menor. De todas formas, esta dificultad se evita si aplicamos el criterio de la tasa interna de retorno.

Tasa interna de retorno (TIR)

Está definida como la tasa de actualización para la cual el VAN será igual a cero, es decir, que el valor actual de los flujos de ingresos iguala al valor actual de los flujos de egresos de un proyecto. La misma, indica la rentabilidad promedio periódica generada por los fondos que permanecen invertidos en el proyecto.

El interés de la TIR radica en la comodidad que supone, al tratarse de una tasa de interés, el poder compararla con el coste real del dinero en el momento del estudio. Si la TIR del proyecto es similar al coste del dinero en el mercado, el proyecto tendrá muy escaso interés, ya que será más cómodo y menos arriesgado invertir en productos financieros con tasas de interés fijas y con escaso o nulo riesgo. Cuanto más alta sea la TIR, mejores perspectivas de rentabilidad ofrecerá el proyecto.

Antiguamente el cálculo del TIR resultaba muy laborioso al tener que realizarse por tanteo, probando con la ayuda de tablas auxiliares creadas para este fin, qué valor del beneficio neto actualizado se obtenía para diversas tasas de actualización hasta dar con aquella para la que el beneficio era nulo. En la actualidad el empleo de las calculadoras electrónicas financieras y los ordenadores personales facilitan este cálculo.

La TIR resulta muy útil, no sólo para comparar proyectos con inversiones diferentes sino también para decidir sobre el interés de un único proyecto aislado. Un proyecto será rentable por sí mismo siempre que su TIR sea superior al coste financiero de los recursos que vayan a ser empleados para su financiación.

Todos estos criterios anteriores pueden ayudar a la evaluación de un proyecto, pero hay que tener en cuenta que algunos de los datos utilizados, principalmente los del estudio del mercado, son a veces poco fiables y por lo tanto en el caso de que varíen las cifras estimadas las consecuencias pueden ser más o menos importantes. Por ello, es por lo que se deben estudiar otros factores: el punto de nivelación del proyecto, análisis de sensibilidad y análisis de riesgo.

Punto de nivelación (umbral de rentabilidad)

Llamado también punto muerto o de equilibrio, es aquel volumen de producción donde se igualan los ingresos y los costes. Suele expresarse en porcentaje de la producción, en ese punto, sobre la producción total prevista y se obtiene gráficamente por la intersección de las curvas de ingresos y costes totales, que se convierten en rectas realizando ciertas simplificaciones.

Figura 2.3: Punto de nivelación.

Análisis de sensibilidad

Mediante este análisis se mide la influencia de la variación de determinados elementos en el resultado económico de un proyecto. Los principales elementos a estudiar son el precio de venta, volumen de la producción, los costes fijos, etc.

El resultado económico no depende por igual de todos estos elementos, será más sensible a unos que a otros y es por ello que se estudiarán y revisarán con mayor atención aquellos que sean más influyentes.

En la figura 2.4 se representan diversas curvas donde en abscisas se indican valores de factores importantes para establecer la rentabilidad como inversión, precios de venta, precios de materias primas, etc. y en ordenadas los valores que indican la rentabilidad en aplicación de los distintos criterios estudiados: VAN, TIR, período de recuperación del capital, etc. Así, observamos la variación de las rentabilidades en función de los valores de los factores elegidos como de mayor importancia para el resultado económico del proyecto.

Figura 2.4: Análisis de sensibilidad.

Análisis de riesgo

Se define como riesgo de un proyecto la gama de posibles rentabilidades que se pueden obtener de dicho proyecto. Si la rentabilidad se conociese con certeza, no existiría riesgo; mientras que si la gama fuese infinita, la incertidumbre sería total.

Para estudiarlo se aconseja seleccionar detenidamente los elementos más importantes para este análisis. Éste es el paso más complejo, aunque la utilización de medios informáticos que existen en la actualidad facilita extraordinariamente esta tarea y es por ello que existen programas comerciales que permiten hacer este estudio con gran rapidez.

Establecido un modelo informatizado del proyecto en estudio, es muy fácil modificar los valores de los elementos considerados y obtener inmediatamente las variaciones de la posible rentabilidad según todos y cada uno de los criterios que se quieran aplicar.

La dificultad no radica en el aspecto técnico, pues es posible conocer la rentabilidad de cualquier inversión, sino en la conducta real de los consumidores que es imposible de predecir. Se puede haber realizado un importante estudio de mercado y resultar posteriormente totalmente erróneos los datos utilizados.

El éxito de muchos proyectos está ligado a la intuición, a la visión personal, la dedicación y el profesionalismo de los responsables que han liderado la idea y la han puesto en práctica.

2.2.3. Selección de proyecto

Los proyectos vienen de muchas fuentes diferentes y por muchas razones. No todos deben ser seleccionados para un estudio posterior. Por tal motivo, luego de obtener los resultados de los estudios previos, es necesario examinar los proyectos prospectivos desde una perspectiva de sistemas, de tal manera que se esté considerando el impacto del cambio propuesto sobre la organización compleja. Los criterios para la selección de proyectos (de sistemas) son:

- Respaldo de la administración.

- Temporización adecuada para comprometerse con el proyecto.

- Posibilidad de logro de mejoras de los objetivos de la organización.

- Practicidad en términos de recursos para los analistas y la organización.

- Relevancia en comparación con otras formas en que la organización puede invertir los recursos.

2.2.4. Aprobación del proyecto

Finalizados los estudios previos, la organización promotora del nuevo proyecto debe proceder a su estudio y análisis antes de tomar una decisión. Se trata de una difícil y trascendente determinación por lo que suele tomarse a un nivel muy elevado de la estructura empresarial o de la organización administrativa.

Si la decisión es negativa no procederá continuar ningún tipo de acción. En ocasiones los estudios previos no son suficientemente claros y contundentes, y es necesario profundizarlos

más o incluso complementarlos en algunos aspectos. En estos casos la decisión se aplaza hasta disponer de la nueva información requerida. Finalmente, cuando la información es suficiente y la conclusión positiva, se puede tomar la decisión de aprobar el proyecto y acometerlo a corto plazo. Sin embargo, incluso en estos casos suelen detectarse algunos posibles puntos débiles de la nueva inversión, y es necesario efectuar estudios adicionales para consolidar la decisión.

En la mayor parte de las ocasiones siempre habrá determinados aspectos en los que el proyecto sea más vulnerable y será necesario tenerlos en cuenta a lo largo del desarrollo, para conseguir los mejores resultados finales. Una vez tomada la decisión de acometer el proyecto, debemos resguardarnos cuidadosamente de la tentación consistente en querer empezar a toda prisa intentando hacer gala de un gran dinamismo y preocupación por el cumplimiento de los plazos establecidos. En este momento es necesario desarrollar una de las etapas esenciales para la buena gestión y marcha posterior, la etapa de preparación y organización del proyecto.

Uno de los errores más importantes y graves en gestión de proyectos es querer arrancar con excesiva premura la obra, sin haber prestado la atención debida a una serie de tareas previas de preparación, organización y planificación que son imprescindibles para garantizar la calidad de la gestión y el éxito posterior de toda la operación.

En la definición del proyecto, se elabora una declaración sobre el problema que se pretende resolver, en la cual éste se define de forma muy concreta con sus diversos grados de necesidad, con las diversas opciones técnicas existentes, contemplando si se dispone de los recursos financieros y humanos precisos para seleccionar la mejor y más adecuada alternativa. Naturalmente ésta es la forma ideal de hacerlo, pero hay situaciones en las que la definición del proyecto evoluciona a medida que avanza el trabajo, simplemente porque ni el "cliente" ni el equipo del proyecto son capaces de definir en su totalidad las necesidades a cubrir.

2.2.4.1. Definición del proyecto. Alcance y contenido

Definir el alcance y contenido del proyecto significa establecer definitivamente el tamaño, los procesos, la localización y el impacto ambiental y social. El tamaño, fijado inicialmente en función del mercado previsto, habrá de ajustarse al tipo de proceso seleccionado y las tecnologías disponibles. En ocasiones estos factores, aparentemente secundarios, imponen serias limitaciones al tamaño previsto para una nueva instalación.

Pueden existir alternativas para el emplazamiento definitivo, que se dilucidará durante la ejecución de la ingeniería básica, pero es preferible decidir este punto en este momento del proyecto. De hecho, la anterior definición del alcance y contenido del proyecto no significa que todo esté resuelto. Se conoce perfectamente la situación y los márgenes de seguridad de todos los factores fundamentales, y de ellos se parte para las etapas posteriores.

2.2.4.2. Definición del presupuesto. Estimación de la inversión

La estimación del presupuesto debe estar ya fijada, aunque con márgenes de tolerancia suficientes para compensar las indefiniciones de esta etapa del proyecto.

2.2.4.3. Definición del proyecto en el tiempo. Planificación

Se efectuará una primera planificación, muy general, de las distintas etapas del proyecto. Para ello se deberán analizar y corregir los datos de los estudios previos. También se introducirán ya una serie de plazos parciales, importantes, que pueden condicionar el cumplimiento de la planificación general establecida.

2.2.4.4. Definición del proyecto en cuanto a su forma de ejecución

Existirán, probablemente, diferentes alternativas disponibles para la realización del proyecto. Se deberá tomar la decisión de quién va a realizar ese estudio, directamente la organización promotora del proyecto o si se va a solicitar colaboración exterior, los servicios de un consultor o institución.

Si se decide por la segunda opción el grado de colaboración puede ir desde una mera asistencia en puntos específicos a través de una empresa consultora, hasta un contrato "llave en mano" y a precio fijo, que llevará a cabo un contratista general.

2.2.4.5. Definición del proyecto en cuanto al equipo responsable

También, y de acuerdo con la forma de ejecución seleccionada, habrá que decidir cuál va a ser el equipo responsable de la ejecución del proyecto, quiénes lo van a formar, cuáles van a ser sus responsabilidades, cómo se van a organizar y quién lo va a dirigir. La elección del director del proyecto es fundamental, ya que su figura es un elemento clave para el buen desarrollo del trabajo y acertar en su designación es la mejor forma de asegurar el éxito del proyecto.

El director del proyecto es el mediador y punto de contacto (referencia) para los diferentes agentes del sistema, ya sean internos (sus superiores, su equipo de trabajo, etc.) o externos (cliente, proveedores, subcontrastistas, etc.). Sus objetivos son:

- Conseguir que el equipo de trabajo funcione adecuadamente.

- Conseguir que el cliente esté satisfecho.

- Obtener buenos resultados para la empresa.

2.2.4.6. Objetivos del proyecto

Para conseguir los objetivos y el resultado que el proyecto pretende alcanzar es preciso poner en juego determinados recursos y desarrollar un conjunto de actividades que

contribuyan a acercarse gradualmente al final previsto. Por lo tanto, el tener definidos los objetivos y haber nombrado un director de proyecto es importante, pero no suficiente, aunque éste quiera alcanzar la meta con toda su voluntad.

El camino que conduce a dicha meta es normalmente largo y plagado de dificultades y obstáculos, por lo que será necesario desplegar toda clase de esfuerzos y habilidades. Pero, antes, es preciso elegir y trazar ese camino.

Es aconsejable poner todos los objetivos del proyecto por escrito como mínimo por las siguientes razones:

El proceso de redactar los objetivos obliga a clarificarlos. Es frecuente que, cuando tenemos un objetivo sólo en la cabeza, no esté siquiera muy claro para nosotros, y por lo tanto mucho menos lo estará para los demás.

Al poner los objetivos por escrito, todos los miembros del equipo del proyecto pueden tener acceso a ellos, de forma que no se olvide nada.

Es más probable que haya unidad de acción cuando se persigue un objetivo común. Para alcanzar la máxima efectividad como director, es útil que el lector piense que su trabajo consiste en alcanzar los objetivos del proyecto y ayudar simultáneamente a los miembros del equipo del proyecto a alcanzar sus propios objetivos. De esta forma, se crea un compromiso con el esfuerzo del proyecto, lo que en definitiva dará lugar al alineamiento de los miembros del equipo con la orientación general que sigue el proyecto, condición necesaria para el éxito.

Cuanto mayor sea la participación en el establecimiento de objetivos válidos de trabajo, con responsabilidad sobre los resultados, mayor será la motivación para alcanzarlos. Esto no significa que sea necesaria una participación total para la gestión de un proyecto, sino que, cuando es factible, los miembros del equipo estarán más comprometidos con los objetivos si han tenido algo que ver con su fijación.

Por último, sólo se pueden medir los progresos con respecto a aquello hacia lo que se progresa. Por tanto, los objetivos constituyen una meta hacia la que avanzar, y permiten medir los progresos realizados en el proceso. Recordemos: si no sabemos adónde vamos, ¿cómo vamos a saber que hemos llegado?

La declaración de los objetivos se deberá de hacer de la forma más clara posible para los cuales se prepararán los pasos específicos de implantación. Así, se podrá saber cuándo se están alcanzando los resultados deseados. A continuación se ofrecen unas orientaciones que pueden servir de ayuda:

Una declaración de objetivos debe ser específica; es decir, no puede ser una declaración vaga y borrosa, del tipo "quiero lo mejor".

Los objetivos deben ser mesurables, siempre que sea posible. Si bien esto puede ser muy difícil de conseguir, existen unidades de medida para cuantificar los objetivos:

Unidades de tiempo, tasas de frecuencia, ratios, números índice, porcentajes, promedios, agregados numéricos, grados, fases, percentiles, cuartiles, deciles, desviaciones medias, correlaciones, volúmenes, unidades de producción.

En el caso de que el objetivo sea no cuantificable, debe utilizarse una prueba cualitativa, es decir, no podemos saber si se ha alcanzado un objetivo si no disponemos de pruebas o criterios para utilizar.

Deben encajar con los objetivos de máximo nivel de la organización. Por lo que se refiere a los proyectos, esto significa que los objetivos establecidos por los grupos funcionales deben respaldar la consecución de los objetivos generales del proyecto. A su vez, los proyectos se eligen de forma que permitan alcanzar los objetivos generales de la organización.

Los objetivos deben traducirse, si es posible, en elementos tangibles, que pueden ser constituidos por informes de evaluación, recomendaciones escritas, etc., es decir, algo material que resulte de utilidad como medida o demuestre que se ha alcanzado un hito.

Los objetivos deben ser comprensibles, es decir, deben estar formulados para que otras personas entiendan lo que se pretende lograr. Este hecho es a menudo causa de problemas importantes en las organizaciones.

Deben estar limitados en el tiempo, si es posible. Resulta útil establecer un orden de prioridades cuando es necesario alcanzar algunos

objetivos para llegar a otro. Cuando sea oportuno, debe asignarse un factor de riesgo a los objetivos, de forma que las

demás personas de la organización sean conscientes de ese riesgo. En la declaración de los objetivos, se debe decir qué se va a conseguir, no cómo conseguirlo. El objetivo debe ser alcanzable. La gente no se comprometerá con objetivos poco realistas. Se debe especificar asimismo un único resultado final. Cuando se combinan varios objetivos

en la misma declaración, resulta difícil comprender bien lo que se está diciendo.

Los problemas de cada proyecto son muy particulares, tanto en su número como en su naturaleza, de ahí que los objetivos puedan variar mucho de uno a otro proyecto. Sin embargo hay una serie de aspectos del proyecto que habitualmente se convierten en críticos y alrededor de los cuales suelen establecerse siempre los objetivos principales. Éstos son:

- Calidad del producto.

- Costes de producción.

- Plazos de ejecución.

- Presupuesto de la inversión.

- Capacidad de producción.

Los tres primeros se refieren claramente a la calidad global del proyecto, por lo que es habitual establecer como objetivos principales de cualquier proyecto los de calidad, plazo y precio. A continuación se desarrollan cada uno de los objetivos mencionados:

Calidad del producto

En algunos casos es imprescindible cumplir exactamente las especificaciones de calidad del producto o servicio en cuestión. Los usos y aplicaciones del producto, las exigencias de un mercado de exportación, la calidad ofrecida por la competencia, etc., pueden fijar esta necesidad.

Costes de producción

Determinados proyectos son muy delicados, y resulta imprescindible realizar un desarrollo de ingeniería cuidadoso con el fin de respetar totalmente las características del proceso. Los costes de producción pueden llegar a ser muy elevados como consecuencia de la existencia de un funcionamiento deficiente.

Plazos de ejecución

El tiempo es el elemento principal en toda planificación, que consiste ante todo en organizar todas las tareas a realizar en período determinado, ¿cómo sabe un director de proyectos cuánto tiempo va a llevar un proyecto, aun suponiendo que sepa cuántos recursos humanos hay disponibles para elaborarlo? La respuesta, naturalmente, la da la experiencia. En un proyecto si una tarea se ha realizado un número elevado de veces se conoce la duración media, y ésta se puede utilizar como base para la realización de una estimación.

Una de las hipótesis de partida en la estimación del tiempo en un proyecto, si no se especifica lo contrario, es que se utilizan duraciones medias. Así, si un proyecto se compone de un número elevado de actividades, la realización de algunas de éstas llevará más de la duración media estimada, y por el contrario otras se realizarán en un plazo por debajo de esa media. Esta forma de trabajar nos asegura que el proyecto se realizará en torno al plazo medio previsto.

Existe la posibilidad de aumentar el plazo de finalización del proyecto para aumentar la probabilidad de finalización en la fecha programada. Consecuencia de ello sería un aumento del coste presupuestado del proyecto, tal vez hasta el punto de que el trabajo se quede sin financiación. Es por ello que se utiliza la hipótesis mencionada anteriormente. Sólo puede elaborarse una duración media prevista para una actividad si se supone que el trabajo va a ser casi idéntico a otro hecho anteriormente, y que la persona o personas a quienes se asigne sean aptas. Así, se realizarán los ajustes teniendo en cuenta la experiencia o habilidad de las personas a quienes se asigna la tarea.

Otro factor a tener en cuenta es cuánto tiempo productivo va a dedicar cada día a la tarea la persona de que se trate. Hay que tener en cuenta el tiempo que no se dedica al proyecto, y en éste hay que incluir la asistencia a las reuniones, atender el teléfono, esperar a proveedores y otras actividades que reducen el tiempo disponible para dedicar al trabajo en el proyecto.

Si prácticamente no existen personas con experiencia que se pueda utilizar como base para la estimación, tal vez sea adecuado emplear técnicas PERT, método DELPHI o algún otro método de estimación.

Sólo para determinados tipos de proyectos existen manuales con tablas de promedios que contienen las duraciones medias previstas para actividades típicas, así como factores de ajuste para compensar la localización geográfica, las condiciones meteorológicas y otras variables, por ejemplo, en los proyectos de construcción.

En cambio, en los proyectos en los que no existen este tipo de tablas, se recurre a datos históricos de proyectos anteriores.

Los retrasos no previstos pueden demorar la entrada de ingresos procedentes del proyecto, y en consecuencia retrasar los plazos de amortización de los créditos bancarios con los que se financió el proyecto.

Presupuesto de la inversión

Una de las preocupaciones importantes en cualquier proyecto es la limitación económica. En ocasiones es imprescindible mantener el proyecto dentro de los presupuestos asignados, cuando existen limitaciones de recursos, créditos caros, poca capacidad de endeudamiento o simplemente rentabilidades no demasiado claras.

Capacidad de producción

Un objetivo principal prioritario será alcanzar la capacidad de producción dentro de los plazos establecidos, subordinándose a esta situación, si es necesario, otros aspectos importantes del proyecto.

Se deberá asegurar desde el momento inicial el volumen establecido para la capacidad de producción porque algunos proyectos son muy sensibles a las variaciones de ésta.

2.2.5. Estructura de descomposición del proyecto (EDP)

Al hablar de la estimación, debe quedar claro que estimar la duración de una tarea es mucho más sencillo que estimar la duración de un proyecto, que está formado de multitud de tareas.

En el caso que se deba realizar una estimación rápida para decidir si debe llevarse a cabo un proyecto, es suficiente compararlo con otro anterior introduciendo los ajustes necesarios en las diferencias más evidentes.

Si interesa un mayor grado de exactitud es conveniente realizar una descomposición minuciosa de todos los incrementos o tareas que va a ser necesario realizar, ello permitirá profundizar más en los aspectos más problemáticos y realizar una estimación con una exactitud relativamente buena. Este desglose facilitará estimar los recursos necesarios para el proyecto, su posible coste y el tiempo preciso para su ejecución.

La estructura de descomposición de un proyecto debe iniciarse con un organigrama, en forma de árbol o pirámide, y en el que aparezcan los distintos niveles en que pueden organizarse todas las actividades necesarias para la total ejecución del proyecto, escalonándose desde el nivel superior a los más inferiores.

La descomposición del proyecto exige dividirlo en tareas y éstas a su vez en subtareas para descomponerlas finalmente en paquetes de trabajo, es decir, al nivel de detalle requerido.

Los paquetes de trabajo se definen como aquellas partes del proyecto que pueden ser desarrolladas por una persona u organización con plena responsabilidad sobre las mismas.

La división más pequeña de un proyecto se considerará un paquete de trabajo si cumple las siguientes características:

El trabajo que representan es una subdivisión natural del trabajo total del proyecto. Su alcance y contenido es único y no está duplicado. Puede ser desarrollado por una persona u organización con plena responsabilidad. Ha de ejecutarse con un período de tiempo determinado, con fechas programadas de

comienzo y terminación. Puede asignársele un presupuesto para su realización susceptible de expresarse en unidades

monetarias, horas de trabajo u otras unidades.

Para realizar la estimación del coste total del proyecto, primero se determinará el coste de cada paquete de trabajo, luego se sumarán los costes de los paquetes de trabajo que formen parte de una subtarea para obtener el coste de ésta, y así sucesivamente hasta calcular el coste total del proyecto.

2.3. Fase de construcción Una vez superada la fase de concepción, se decide continuar adelante con el proyecto o no. Si se decide la primera opción, entonces se pasa a la siguiente fase, que es la fase de construcción.

El proyecto es ahora, cuando toma forma, se materializa. Es posible que ésta sea la fase más larga y costosa. No es una fase de estudio, por lo tanto se debe prestar especial atención a la planificación, seguimiento y control del proyecto, así como una buena gestión de los recursos. En síntesis esta fase es una corporificación de lo ya definido y concebido, en algo concreto y material.

2.3.1. Planificación de actividades y recursos

Planificación equivale, en su concepto, a configuración del futuro. Planificar es seguir un proceso encaminado a fijar y desarrollar objetivos y/o medidas que conduzcan a alcanzar la totalidad o bien, una determinada parte de estos objetivos.Durante la planeación se determina:

La misión, objetivos, metas y estrategias del proyecto La estructura de desagregación de trabajo. Los diagramas de precedencia de actividades. La programación en el tiempo basada en los diagramas de precedencia. El plan para el soporte de recursos del proyecto.

Los proyectos tienen en general un desarrollo sucesivo en fases o etapas íntimamente relacionadas. Se puede decir que la actividad de proyectar cumple un ciclo que encuentra su origen en una realidad existente y finaliza en la misma realidad, transformándola con arreglo a unos objetivos y unos ciertos criterios propuestos. En este ciclo, integrado por una serie de actividades pueden distinguirse algunas etapas claramente diferenciadas por sus medios y fines y que frecuentemente, se llevan a cabo de forma competa y sucesiva.

A principios de la década de los 80's, la disciplina denominada "Dirección de Proyectos" recibió un gran impulso con la creación de software especializado que corría en los ordenadores personales. Sobre todo, la creación del software Harvard Project Manager, en 1983, concentró el interés del management en la confección de presupuestos, organigramas y metodologías de manejo de recursos para los proyectos.

El Harvard Project Manager generó diagramas PERT / CAM, diagramas de Gantt, curvas de costos acumulados, diagramas de cantidad de recursos y numerosas tablas. Se trataba, en efecto, de un paquete que integraba software para planificación y control de proyectos. Desde entonces, el software para dirección de proyectos se ha convertido en una herramienta de trabajo verdaderamente eficiente. Y a medida que se hacía cada vez más sofisticado, también se tornaba más difícil aprender y usar. Un paquete de software como el Harvard Project Manager podía ser aprendido en un día. Ahora bien, el software actual requiere por lo menos cinco días de aprendizaje. Con la creciente demanda de entrenamiento en software de dirección de proyecto, surge una pregunta obvia: ¿quién debe ser entrenado? Inicialmente se suponía que los managers de proyecto serían los usuarios naturales del software. Pero la existencia demostró que si se seguía ese camino, los directores de proyectos dedicarían la mayor parte del tiempo a trabajar con el software y poco tiempo a ocuparse del proyecto en sí.

Hoy en día la mayoría de las organizaciones que emplea software para dirección de proyectos ha establecido consultores internos o grupos de apoyo que son los expertos en software. Esas personas tienen la responsabilidad de mantenerse actualizadas respecto de los desarrollos más recientes en el software de planificación, confección de presupuesto y asignación de recursos. También deben traducir esos desarrollos en aplicaciones prácticas que pueden ser usadas por los miembros del equipo de proyecto.

En general, se puede decir que el software para dirección de proyectos es beneficioso y útil para los profesionales, porque impone pautas para la dirección de proyectos que son aceptadas luego por muchas organizaciones. Por otra parte, si todos los empleados de una organización utilizan el mismo software para trabajar en diversos proyectos, los datos de planificación y control llegan a ser comparables. Además, la dirección sistematizada sensibiliza a la gente para valorar la dimensión del proyecto. Mientras planifican y realizan las actividades de sus proyectos por medio del software de dirección, acumulan datos históricos que después pueden ser usados para orientarse en el manejo de proyectos futuros. Actualmente, cuando alguien pregunta: "¿Cuánto tiempo se demora en verificar cincuenta líneas de código?", los miembros del equipo pueden responder revisando las cifras del trabajo anterior, que han sido archivadas por el software de dirección del proyecto. Pero el software también tiene algunas desventajas. En primer lugar, impone al equipo de proyecto una carga administrativa mayor, que no siempre se ve justificada por los beneficios derivados

de la utilización del software. En segundo lugar, este instrumento de trabajo es bastante rígido, de modo que muchos de los diagramas que crea tienen una importancia relativa en ciertas organizaciones. Y, por último, este software contribuye a perpetuar la idea de que el management del proyecto se ocupa principalmente de las técnicas conocidas, como los diagramas de PERT / CPM y las curvas de costo acumulado, cuando en realidad el management de proyecto debe concentrarse también en cuestiones "blandas" como, por ejemplo, la política de los proyectos, el manejo de los recursos y la definición de las necesidades.

2.3.2. Programación y planificación del proyecto

Durante esta etapa se establece una organización, identificando a los individuos que van a participar en el proyecto, decidiendo de quién van a depender y definiendo los límites de su autoridad, obligaciones y responsabilidades.

No obstante, también es muy conveniente que la formulación del proyecto, una vez adoptadas las necesidades previas, se refleje en un documento, que puede ser simple y breve, pero que ha de recoger con claridad los objetivos básicos del proyecto. Se trata de un seudo-contrato entre el "cliente" y el director de proyecto que sirva de marco de referencia al desarrollo posterior del proyecto. Este documento es un mecanismo de organización muy útil para la dirección de proyectos y así llevar un control del proyecto a lo largo de la vida de éste, puede estar constituido en realidad por varios cuadernos en el caso de proyectos muy grandes.

Técnicas de planificación

Planificar es buscar la mejor combinación posible entre los objetivos del proyecto y los recursos de que se dispone o a los que se puede recurrir, con sus correspondientes limitaciones, costes y rigideces.

La experiencia muestra que muchos directores de proyecto planifican poco o nada, o que los planes que crean resultan inadecuados. Trabajar sin un plan es la esencia del planteamiento desordenado. Si se trabaja en estas circunstancias el director de proyectos no tiene el control, que es uno de los requisitos más importantes del director, o sea, que es muy probable que el proyecto sea un fracaso.

Cuando se habla de control se refiere comparar dónde estamos con dónde se supone que deberíamos estar, y la única manera de saber dónde deberíamos estar es compararlo con un plan. Así, se observarán mejor los progresos. Cuando se analice esta situación si se detectan posibles desviaciones con respecto al objetivo se emprenderán acciones correctoras.

El problema de muchos directores de proyectos es que no planifican porque según ellos no tienen tiempo. Esta actitud es probable que desencadene una crisis en el proyecto.

No obstante, aún cuando se planifica se cometen errores. De éstos el más frecuente es no implicar en el proceso de planificación a la gente que debe ejecutar el plan. Si el director del

proyecto planifica el trabajo de otras personas sin contar con ellas es muy probable que estime un tiempo de realización menor del que realmente les llevará. Además, estas personas no trabajan a tiempo completo en la actividad del proyecto.

Es frecuente encontrarse con la necesidad de afrontar varios proyectos al mismo tiempo, por lo que habrá diversos directores de proyectos. En este caso hay un director de función que se encargará de distribuir los limitados recursos de la forma más conveniente. Ello crea problemas: por un lado el director del proyecto, deseoso de alcanzar los objetivos del proyecto querrá disponer de los recursos que considere necesarios en el momento oportuno, pero es posible que el director de función no le proporcione lo que desea porque éste debe atender los requerimientos de los distintos directores de proyecto.

Habitualmente se representa la planificación de un proyecto en un diagrama de Gantt, situando en el eje de ordenadas la relación de actividades a realizar y en el eje de abscisas la escala de tiempos. Una adecuada planificación de proyectos debe producir siempre dos Gantt diferentes: el Gantt de actividades que se ha descrito anteriormente, y el Gantt de recursos, que sitúa en el eje de abscisas los diversos recursos disponibles.

La necesidad de hacer coherentes ambos diagramas de Gantt es mayor cuantos más proyectos deban planificarse y mayor cantidad de recursos se ponga en juego, ello a su vez dificulta conseguir una combinación óptima de objetivos y recursos.

Las características más importantes para la planificación de proyectos son las siguientes:

Se refleja en dos diagramas de Gantt: Gantt de actividades y Gantt de recursos. Es el resultado de probar diversas combinaciones posibles de actividades y recursos. Ha de ser constantemente seguida y frecuentemente actualizada. En general, no será posible efectuar una buena planificación ni mantenerla actualizada si no

se dispone de apoyo informático para su tratamiento, como veremos más adelante.

En la mayor parte de los proyectos no hay un único planteamiento que se pueda aplicar a la resolución del problema. Cuando esto ocurre se denominan problemas abiertos. Sólo un número reducido de proyectos se pueden considerar problemas cerrados, como por ejemplo, la revisión de un generador de energía averiado, donde una vez se ha diagnosticado el defecto del generador, el planteamiento para la reparación del aparato está bastante definido.

Tratar de planificar un proyecto a largo plazo de forma detallada a veces no es conveniente porque en muchos casos cuando finaliza una fase del proyecto se toman decisiones que afectan al trabajo posterior. Una forma útil de afrontar un proyecto para evitar este tipo de problemas es planificar por fases, es decir, planificar únicamente hasta el nivel de detalle que se conoce hasta ese momento. Esta forma de planificar no resulta conveniente en casos en los cuales existe una fecha límite que condiciona el proyecto antes de iniciar; como por ejemplo si éste es un libro que tenga que estar publicado y entregado en la fecha que se estrenará la película, para obtener beneficios a costa del éxito de ésta. No obstante, hay casos con fecha límite en los que es útil la planificación por fases.

Si se utiliza este planteamiento al finalizar cada una de las fases se deberán tener dos documentos de planificación: un plan de fase y un plan de proyecto. El plan de fase se prepara a nivel de tarea o de paquete de trabajo, y proporciona el trabajo detallado que va a realizarse en la siguiente fase. El plan del proyecto es el plan general para la parte restante del proyecto, y en él se especifica la fecha de terminación, la estimación de recursos necesarios y el coste hasta la finalización del proyecto.

Los grafos

Existen diversas técnicas de planificación de proyectos basadas en el empleo de grafos (PERT, CPM, etc.), que son las representaciones gráficas en las que los diferentes puntos de un conjunto se relacionan entre sí mediante enlaces que, generalmente están orientados en una dirección.

La técnica de los grafos es idónea para observar mejor las tareas que forman el proyecto, que en el dibujo se identifican con letras, cómo están relacionadas y en qué orden se deben ejecutar, es decir, facilitan la comprensión para personas que no son técnicas en la materia (clientes, etcétera). Las actividades precedidas inmediatamente por más de una, o sea, que llegan a ellas dos o más arcos no se pueden iniciar hasta que no estén las anteriores finalizadas.

En el grafo se pueden incluir actividades de tiempo de duración cero, conocidas como actividades ficticias, que normalmente no existen en la realidad como tal, pero se incluyen por una de las dos razones siguientes:

Para indicar la existencia de una relación de precedencia que de otra forma sería difícil de representar gráficamente.

Para llamar la atención en el momento de la planificación o del seguimiento, sobre un acontecimiento previsto, como una reunión a celebrar en cierta fecha o diferentes puntos de control que el director del proyecto quiere establecer para un mejor seguimiento de la obra.

El camino crítico

Estas técnicas tienen especial interés cuando al grafo se le añade el plazo de tiempo previsto para cada una de las actividades. El tiempo es el elemento principal en toda planificación.

Se conoce como camino una secuencia de arcos tal que el extremo final de cada arco coincide con el extremo inicial del siguiente. La longitud o plazo de duración de un camino es la suma de las longitudes o tiempos de los arcos que componen dicho camino.

Normalmente existen diferentes caminos para desplazarse de un vértice a otro, y pueden tener o no la misma longitud. La duración total del proyecto viene dada por el camino más largo que además determina la fecha más temprana en que puede estar terminado el trabajo que recibe el nombre de camino crítico:

El camino crítico permite comprobar si la planificación efectuada coincide con los objetivos del proyecto, sino habrá que buscar nuevas alternativas.

Las actividades que componen el camino crítico reciben el nombre de críticas. Un cambio en el tiempo de duración de una actividad crítica también cambia la duración total del proyecto. Si una actividad crítica se retrasa también lo hará la duración del proyecto, y viceversa, si una actividad crítica se acorta también supondrá una reducción del tiempo total del proyecto.

Los cambios en el periodo de duración de una actividad no crítica no influyen en el proyecto, a no ser que la tarea sea tan grande que se haya vuelto por tal motivo crítica.

El camino crítico permite controlar mejor las actividades críticas o las que podrían hacerse críticas con facilidad, que son las que más preocupan porque pueden afectar negativamente en la duración del proyecto.

El camino crítico puede llegar a ser muy difícil de realizar en proyectos de tamaño importante y es por ello que se recomienda la ayuda de un ordenador. Cuando haya más de un camino crítico se debe intentar que sólo quede uno, así reducimos el riesgo total del proyecto.

Las holguras

Ya se ha dicho anteriormente que existen tareas en las que un cambio en su periodo de duración no influye en la duración total del proyecto. Se dice que son actividades que tienen holgura, es decir, que su tiempo de inicio y finalización se puede desplazar, siempre dentro de unos límites, sin afectar a la duración del proyecto.

Fecha final forzada

La mayor parte de las veces se impone una fecha final al proyecto. Esta fecha final puede ser anterior a la fecha más temprana de finalización del proyecto. Cuando esto ocurre, ¿qué opciones tenemos? Una sería adelantar la fecha de inicio del proyecto, pero ésta queda descartada porque la fecha de comienzo viene a menudo dictada por la disponibilidad de recursos o algún otro factor. La otra opción es acortar el programa, ¿y cómo? acortando el camino crítico, es decir, reducir la duración de algunas de las tareas que lo componen.

Los métodos CPM / PERT de programación del proyecto

Existen diversos métodos que utilizan como soporte los grafos o redes, de los que destacan los sistemas CPM y PERT, semejantes en sus aspectos generales. Ambos utilizan los sucesos o acontecimientos como vértices o nodos de la red, y los arcos o flechas que los unen son las tareas o actividades, orientados en el sentido del desarrollo del proyecto. El CPM utiliza, para fijar la duración de las actividades, tiempos estimados establecidos en función de experiencias anteriores y de los resultados de proyectos similares. El PERT, al principio estaba destinado a programar proyectos con partes importantes de los mismos en fases de investigación y desarrollo (I+D), y por lo tanto, no se podían basar en estadísticas anteriores disponibles.

Para resolver este problema, en el método PERT se utilizaron conceptos y métodos de cálculo probabilístico. El resultado de este estudio fue establecer una fórmula aproximada para el cálculo del tiempo previsto más probable de las distintas tareas. En el caso concreto de proyectos I+D el tiempo de duración de las tareas tiene un carácter claramente aleatorio.

2.3.2.1. Control y seguimiento del proyecto

Una de las responsabilidades del director del proyecto y de otras instancias jerárquicas involucradas en la operación, es el seguimiento y control de los resultados. Es por ello, que una vez estudiados los resultados se podrán adoptar acciones correctoras si fuese necesario. El control del proyecto, puede decirse que empieza en el momento en que se inicia el proceso de definir los objetivos mediante contactos y negociaciones con el cliente. Los objetivos son múltiples: resultado o calidad, coste y plazo. El objetivo de resultado se reflejará en las correspondientes especificaciones técnicas; el objetivo de coste se desglosará en un presupuesto por actividades y por recursos; el objetivo de plazo se concretará en una adecuada planificación del proyecto.

Un buen director de proyectos deberá ser capaz de adoptar las medidas necesarias que crea conveniente para corregir posibles desviaciones con respecto a lo que se había previsto anteriormente a medida que avanza el proyecto, por lo tanto, deberá dominar en todo momento su evolución. Es conveniente, pues, una definición clara y concisa de los objetivos antes de empezar a trabajar. Cuanto mejor definidos estén, mejor encaminado irá el equipo del proyecto y se evitarán desviaciones innecesarias que corregir.

El fin principal de la planificación no es hacerla correctamente para "acertar", para que se cumpla exactamente lo que habíamos previsto, como creen muchas personas, sino que es un instrumento de gestión que define el marco de referencia en que nos queremos mover.

Modificación de los límites

A veces, se deberán reconsiderar de una forma más o menos profunda los objetivos inicialmente establecidos, ya sea por nuevas circunstancias o a petición del cliente. Ello se denomina "modificación de los límites". Cuando se lleva a cabo esta actuación no significa que se hayan producido desviaciones respecto las previsiones iniciales y haya que emprender acciones correctoras, sino que simplemente aparezcan hechos nuevos que aconsejen replantearse los objetivos iniciales.

Estas reconsideraciones son a veces la causa de conflictos e insatisfacciones, tanto para el cliente como para el equipo del proyecto. Además, quejas comunes de técnicos que trabajan en los proyectos son las continuas peticiones por parte de los clientes para añadir cosas que no habían sido previstas con anterioridad o cambiar algunas de ellas. Además, estas peticiones de los clientes, en muchos casos son poco claras, y consecuentemente se las responde con vaguedad. Los clientes no dan importancia a los cambios que piden y piensan que no van a repercutir en el proyecto, pero para el equipo del proyecto supone un gran esfuerzo. Ésta conducta por parte del cliente puede perjudicar seriamente el proyecto, causando retrasos. No obstante, el director del proyecto no debe sentirse ofendido, sino mantener una actitud de profesionalismo y objetividad estudiando las consecuencias que pueden tener estos cambios en el desarrollo del proyecto e incorporarlas siempre que sea oportuno y una vez finalizada esta labor presentar al cliente los nuevos objetivos propuestos.

Se deberá levantar acta para dejar constancia en todas las reuniones, así como de las conversaciones en las que se traten temas de especial interés, porque es imposible acordarse de todo transcurridos unos meses y ello llevará a incomprensiones, desacuerdos, etc.

Los objetivos deben ser compartidos por cliente y equipo del proyecto para evitar futuras interpretaciones divergentes que pueden llevar a conflictos. Desde un punto de vista formal, la definición inicial de los objetivos debe considerarse como un contrato formal entre cliente y director de proyecto. Cualquier alteración de los límites supone una modificación de algunos de los aspectos sustanciales de dicho contrato, es por ello que debe realizarse entre las mismas partes y con el mismo grado de rigor y solemnidad.

En la práctica todo esto puede resultar pesado y formalista pero no tiene por qué ser así. No debe pensarse un acuerdo como algo laborioso, simplemente podría ser una carta o la firma de un acta en una reunión. Cuanto mayor sea la buena relación entre ambas partes más rápido se realizará el acuerdo.

No es necesario revisar el acuerdo cuando la modificación es pequeña, es aconsejable recopilar algunas de éstas para tener un conjunto de dimensión significativa.

Control de la calidad

Aunque hemos destacado en todo momento la importancia de los objetivos de coste y plazo para el éxito del proyecto, no puede olvidarse que el objetivo más importante de los tres es el de resultado o calidad porque es el que refleja el deseo original del cliente.

El control de la calidad sólo es posible si se parte de unas especificaciones claras, previamente definidas, conocidas y compartidas por ambas partes. El mismo consiste en comparar el trabajo que se está ejecutando con las especificaciones y comprobar si se están respetando o si existen diferencias significativas, todo ello mediante la realización de análisis y estudios periódicos, aplicando las técnicas pertinentes en cada tipo de proyecto y en cada una de sus etapas. Este control requiere conocimientos técnicos profundos en la materia que se trate, mediante análisis, mediciones y muestreos. En muchos casos, por la importancia y la labor de esta tarea, será preferible encomendarla a personas o empresas especializadas con el fin de garantizar la objetividad y eficacia del control.

La responsabilidad del control de la calidad incumbe tanto al cliente como al director de proyecto. Para el cliente un seguimiento del desarrollo del proyecto es de sumo interés si quiere comprobar que las especificaciones establecidas se van cumpliendo, sino al final se puede encontrar con la sorpresa de un resultado insatisfactorio sin posibilidad de corregir. Para el director del proyecto, significa la obligación de crear la obra con las especificaciones establecidas para mantener el compromiso que tiene con el cliente.

La calidad ha de contemplarse como calidad funcional y no como calidad intrínseca o en abstracto. Para entender esta idea un ejemplo podría ser el de un automóvil. Éste no tiene mayor calidad por el material de que está hecha su carrocería sino por su nivel de funcionamiento y prestaciones. Muchos conflictos se producen por los diferentes puntos de

vista del técnico que realiza el proyecto y el cliente. A veces el técnico intenta buscar una calidad más elevada para hacer una obra más interesante profesionalmente alejándose de las especificaciones del cliente.

El control de calidad debe ser preventivo y no realizarlo una vez finalizada la obra. El control de calidad "a posteriori" únicamente servirá para comprobar que no se ha alcanzado el nivel de calidad deseado. Si se detectan defectos a posteriori será normalmente imposible o inviable corregirlos por elevados costes de reparación. Por ello debe efectuarse a lo largo de toda la obra con tiempo para ir corrigiendo posibles deficiencias que no suponen costes añadidos importantes. Para garantizar la calidad de un proyecto son necesarias una serie de acciones por parte del director del proyecto, que son selección, formación y motivación:

Selección

El primer paso necesario para garantizar la calidad del trabajo es seleccionar adecuadamente al equipo que va a colaborar en el proyecto. El director del proyecto deberá formar un equipo adecuado en cantidad y capacidad a las exigencias del proyecto. Si se trabaja con personas inadecuadas es improbable que se consiga una calidad satisfactoria aunque se establezcan medidas de control.

El director del proyecto, no obstante, deberá tener en cuenta la preparación de su equipo, no podrá exigir objetivos muy difíciles si el equipo con el que trabaja no está suficientemente capacitado. También en gran medida el éxito del proyecto dependerá de los subcontratistas y colaboradores externos que se seleccionen.

Formación

El equipo de un proyecto no siempre está formado por personas con experiencia, es posible que algunos jóvenes formen parte de éste, por lo que una de las responsabilidades del director del proyecto y los más experimentados es formar a estos jóvenes, imponiendo una metodología eficaz de gestión de proyectos que garantice el cumplimiento de los objetivos, para el éxito del proyecto.

Si el ambiente de trabajo no es demasiado profesional, influirá negativamente en la formación de estos jóvenes, donde aprenderán toda clase de trucos y prácticas negativas.

Motivación

La motivación de los miembros es fundamental para garantizar la calidad del trabajo. Para ello se deberá llevar una constante actividad de control y de gestión. En este control se incluye desde felicitar a un técnico que ha realizado muy bien su labor hasta obligar a repetir un trabajo que se ha efectuado incorrectamente.

La calidad no se consigue mediante discursos y prédicas realizadas muy de vez en cuando, sino con decisiones concretas, mejorando día a día los procedimientos y corrigiendo errores, que sirvan de estímulo permanente al trabajo serio y profesional.

Control de los plazos

La gestión del proyecto en cuanto al seguimiento y control de los plazos consiste en una buena planificación previa donde se han especificado las actividades a realizar, los recursos a emplear, los plazos de cada actividad y la situación en el tiempo de dichas actividades. No obstante, siempre se producen desviaciones, pero si la planificación ha sido realizada con detalle estas desviaciones no supondrán un gran problema y será relativamente fácil corregirlas. Lo importante es saber exactamente qué desviaciones se están produciendo en cada momento para actuar en consecuencia para tomar medidas correctoras que permitan acortar los plazos o recuperar el tiempo perdido, aportando mayores recursos, incrementando la productividad, subcontratando ciertas tareas, realizando horas suplementarias, etc. Así, la planificación nunca está acabada, sino que está constantemente realizándose y actualizándose según los acontecimientos que van produciéndose día a día, podríamos definirla como "planificación dinámica".

Antes de contar con el apoyo de los ordenadores esta planificación era muy costosa o imposible. Éstos efectúan simulaciones y ajustan los datos de un modelo existente, cambiando alguna de sus variables independientes. La realización de simulaciones o la replanificación a la vista de los datos reales resulta ser una tarea simple y casi instantánea que podemos efectuar cuantas veces sea necesario.

Una de las causas principales que producen retrasos en los proyectos y que hacen perder el control sobre su evolución es la existencia de tareas o actividades de larga duración o aquellas que no producen resultados visibles hasta su ejecución. Un ejemplo de proyecto que se puede observar su evolución y apreciar si lo hace de forma rápida o lenta es la construcción de un edificio.

Pero hay otros casos en los que es más difícil observar esto, por ejemplo, en la fabricación de un elemento complejo puede ocurrir que no dispongamos de información sobre si el proveedor que se encarga de realizar este proyecto está avanzando al ritmo previsto para finalizar en la fecha establecida o si se están produciendo retrasos graves. Lo mismo ocurre cuando se trata de obras de contenido más inmaterial como puede ser el desarrollo de aplicaciones informáticas o la realización de estudios de consultoría.

En las tareas de corta duración y contenido material su evolución es fácilmente observable, pero en las actividades de larga duración o naturaleza inmaterial, la única solución es el establecimiento de puntos de control suficientemente cercanos en el tiempo para garantizar que en todo momento sepamos dónde estamos. Estos hitos de control hacen la misma función que los tradicionales mojones que encontramos en las carreteras y que nos indican nuestra situación y nuestra distancia desde el origen o hasta el destino.

Los hitos de control es una de las ayudas más importantes para el éxito del proyecto. Se deberán establecer cuantos sean necesarios para tener todas las actividades controladas y así detectar posibles desviaciones pronto. Un periodo de tiempo recomendable para efectuar un control eficaz sería un mes o a lo sumo dos; ya que si fueran más elevados podrían ser peligrosos en el sentido que harían perder el control sobre la actividad.

La identificación de los hitos de control puede efectuarse dividiendo una actividad de larga duración en varias tareas más cortas o bien creando actividades específicas de control, frecuentemente llamadas actividades ficticias, como efectuar una visita al proveedor, celebrar una reunión, presentar un informe de avance, realizar una prueba parcial, etc.

El control de los plazos del proyecto se realizará de forma que para cada tarea se especifiquen las fechas siguientes:

- Fecha "early": lo más pronto que la actividad puede ser realizada.

- Fecha "late": lo más tarde que la actividad puede ser realizada sin alargar el camino crítico.

- Fecha inicialmente prevista para la realización de la tarea.

- Fecha que actualmente está prevista para realizar la tarea, una vez conocidas ya las fechas reales de las actividades realizadas.

- Fechas en que realmente se ha ejecutado una actividad.

También es importante conocer la diferencia entre el tiempo de trabajo y el plazo transcurrido. Cuando se planifica un proyecto se tiene en cuenta el número de horas, días o semanas y el número de unidades de los recursos que vamos a utilizar para realizar la tarea. Por ejemplo, se supone que para realizar una tarea se necesitan 1.200horas/hombre y que vamos a disponer de tres personas a pleno tiempo, que dedicarán 400 horas a la tarea. Si el número de horas de trabajo por semana es el normal, 40 horas, entonces cada persona estará trabajando 10 semanas.

Pero el plazo de realización de la tarea no tiene que coincidir con las 10 semanas, puede ser muy diferente, bien mayor o bien menor, por diversos motivos: en primer lugar puede ser mayor porque en ese plazo puede haber días festivos, vacaciones, ausencias de algunas personas que se encargan de la tarea, etc.; en segundo lugar, en ocasiones, el plazo es bastante independiente de las horas de trabajo que exige, por ejemplo, al pedir una licencia a una administración: una vez pedido el permiso es necesario esperar el plazo de respuesta sin que ello suponga dedicar horas/hombre a la tarea. En el caso contrario, que el plazo de la tarea sea menor que la suma de horas de dedicación necesarias. En el ejemplo expuesto, si se realiza el trabajo con tres personas pero con dos turnos, el plazo total podría reducirse a cinco semanas.

Control de costes

La metodología a seguir es análoga a la indicada en los casos anteriores: se hace una valoración económica de los recursos que se preveía utilizar en cada una de las tareas que se compara con la información real de los costes para realizar acciones correctoras si fuese necesario. La dificultad del control de costes es no disponer de una información de suficiente calidad sobre los costes reales. Este estudio normalmente se realiza con una contabilidad

analítica, herramienta temida en muchas empresas por su pesadez, complejidad y desconfianza de la calidad de su contenido.

En la gestión de un proyecto hay que tener en cuenta el conjunto de conceptos de coste diferentes que existe, normalmente unos pocos conceptos representan el 80 o 90 por 100 de los costes totales. Para dominar el 90 por 100 del coste total del proyecto tal vez sea suficiente controlar tres o cuatro conceptos, que varían de un proyecto a otro, pero generalmente serán algunos de los siguientes:

- Mano de obra propia.

- Maquinaria propia o ajena.

- Subcontratación.

- Compras.

Estos costes, que representan la mayor parte del presupuesto del proyecto, son los costes directos. En algunos casos, pueden darse otros conceptos importantes, como amortizaciones, gastos de viaje, etc.

Es muy frecuente creer que el proyecto va muy bien hasta que al finalizar la obra, se comprueba que el resultado económico ha sido insatisfactorio. Para evitar este tipo de problemas se recurre a un sistema de contabilidad analítica que permita conocer pronto y con suficiente exactitud los costes producidos, si es posible a nivel de las tareas para llevar un control eficaz de los costes del proyecto. Algunas empresas, al no disponer de un sistema de contabilidad analítica lo suficientemente bueno montan su propio sistema más simple y barato pero capaz de darles la información necesaria.

Costes internos

Estos costes son más difíciles de controlar por no existir una factura normal y un pago al exterior. Normalmente los costes internos más importantes son los correspondientes a la mano de obra, aunque también se puede aplicar a otros recursos como la maquinaria. Los costes internos suelen incluirse en algunas instituciones como gastos generales y fijos incluidos en la nómina de la compañía e incluso en otras se considera que el coste de estos recursos es cero a efectos del proyecto. Consecuencia de ello: no poder controlar estos costes. Este problema tiene fácil solución: crear un documento que permita facturar a los proyectos los tiempos que dedican los diversos técnicos empleados, pero en algunos casos no se implanta por temor a su rechazo.

Una buena gestión del proyecto es saber si el coste real de una determinada tarea ha sido el que inicialmente se había previsto y si estamos consumiendo recursos en una cantidad menor, igual o superior a lo planificado. Se debe comprobar si existen diferencias significativas entre el coste que habíamos previsto y el real. Si existen desviaciones se adoptarán medidas correctoras.

Lo que nos interesa para un buen control de los costes de un proyecto es el seguimiento de los costes directamente producidos por el mismo. Estos costes directos no son sólo los que forman la mayor parte del presupuesto del proyecto, sino que son los que pueden ser gobernados y gestionados en el ámbito del proyecto; que difieren de los costos indirectos que se tratan de gastos cuya gestión es ajena al ámbito del proyecto.

2.4. Fase de puesta en marcha Es en esta fase donde se realizan los ensayos para comprobar que el proyecto cumple con todas sus especificaciones y detectar posibles desajustes. Si la información recogida no proporciona la suficiente confianza para aprobarlo se deberá estudiar minuciosamente cuales son los errores cometidos, posibles desviaciones respecto de las especificaciones fijadas para rectificar y llegar a la solución deseada.

Este tipo de rectificaciones ayuda a las personas encargadas de llevar a cabo el proyecto a adquirir más conocimientos y aplicarlos en posibles proyectos futuros.

En síntesis, es la fase en la cual se inicia, observa y corrigen los detalles y problemas que surgen.

2.4.1. Ejecución del proyecto

La ingeniería básica, ingeniería de detalle e ingeniería de desarrollo son tres fases distintas pero consecutivas, que persiguen un mismo objetivo final: dar un soporte documental al proyecto.

La ejecución del proyecto incluye todas las actividades de ingeniería, gestión de compras, construcción, montaje y puesta en servicio del proyecto, hasta iniciar su operación normal.

2.4.1.1. Ingeniería básica

La ingeniería básica se pone en práctica una vez se han actualizado los estudios previos, tras los correspondientes estudios sobre el correcto seguimiento del proyecto. Se puede definir ésta como los documentos que definen inequívocamente el proyecto, su alcance y su coste. También cabe mencionar que esta ingeniería básica puede realizarla quien plantea la necesidad del proyecto o bien alguien externo, como ser una consultora. Es importante, en particular para el último caso, que sea definido de la forma mas precisa posible para evitar confusiones.

En esta fase se debe obtener cierta información que será el punto de partida para la ingeniería de detalle, que es la siguiente fase. La información requerida de la que se ha hablado es la implantación general, clara, y materializada en diversos y concretos documentos, ofreciendo de forma clara su situación.

También deben incluirse los datos para el proyecto de las áreas de servicios generales y auxiliares, es decir, superficies, alturas y la situación de infraestructura auxiliar.

Se deberá conocer la reglamentación oficial de los locales destinados a áreas sociales, pero no es suficiente con ello, sino que se deberá hacer un minucioso estudio de los turnos de los trabajadores, sexo, política social, etc. para adaptarlos a sus costumbres y proporcionarles comodidad.

Es ahora el momento de incidir en los aspectos que se han ido considerando durante todo este capítulo, la importancia del cálculo del presupuesto y la planificación eficiente, tratando de mantener las fechas programadas o incluso ajustarlas en la medida de lo posible. Es por ello que se debe actualizar el presupuesto que se consideró en los estudios previos. Antes se permitió un error considerable a la hora de estimar el presupuesto pero ahora se recalculará y se dará la estimación definitiva.

Antes de proseguir con la siguiente etapa es necesario la aprobación de la ingeniería básica, eso sí, una vez estudiados y discutidos todos los detalles, caracterizados por básicos y "casi" inamovibles de cara al futuro, y como es normal en estos casos, reflejarla por escrito, darle un soporte documental.

2.4.1.2. Ingeniería de detalle

La ingeniería de detalle utiliza la información recogida en la etapa anterior, ingeniería básica, para proceder a su fabricación. De ahí destacar la importancia de la fase anterior, porque la exactitud del procedimiento llevado a cabo en ella para estimar todos los factores dependerá del éxito del proyecto. Todos estos departamentos deberán trabajar de una forma coordinada, el resultado del trabajo de unos departamentos es el punto de partida para otros. Si no hay coordinación entonces empezarán a producirse fallos, con el consecuente retraso y encarecimiento del proyecto.

Es necesario al final de esta fase tener toda la información necesaria para llevar a cabo la compra de los equipos y materiales así como la construcción y montaje de las instalaciones o infraestructuras complementarias.

Gestión de compras

Después de haberse facilitado la información necesaria puede llevarse a cabo la gestión de compras, es decir, para la realización del proyecto es necesario abastecerse con los materiales y equipos convenientes que una vez adquiridos serán entregados en el destino indicado. De ello se encarga un equipo que recibe el nombre de servicio, aunque también se designa con los nombres departamento o división. La gestión de compras será más eficiente cuanto menor sea el coste de estos materiales y equipos, eso sí, siempre cumpliendo la calidad fijada y realizándolas en plazos de tiempo considerables.

Construcción y montaje

Ahora suponemos ya que todas las actividades de estudio, organización y planificación han sido completadas de forma satisfactoria y que, por tanto, el proyecto está listo para recibir la orden de comienzo y pasar a la fase de construcción y montaje. El desarrollo del proyecto a partir de este momento estará en gran medida condicionado a que las etapas preparatorias se hayan realizado correctamente pues, de lo contrario, pronto empezarán a presentarse problemas de toda índole: técnicos, humanos y de gestión. Sin embargo, si los objetivos del proyecto están claramente definidos, si se dispone de un director de proyecto idóneo y de un equipo adecuado, si se ha realizado una planificación coherente, etcétera, el proyecto está ya encarrilado por el buen camino y las cosas serán notablemente más fáciles.

En esta fase es posible probar los productos y servicios terminados para ver si se alcanzan todas las metas de rendimiento. En el caso del desarrollo de un nuevo producto, es el momento en que suelen comenzar las campañas de venta. Una vez lanzada la campaña de venta siempre se corre el riesgo de descubrir fallos técnicos que impidan realizar las entregas prometidas.

En la fase de construcción y montaje el proyecto se materializa, se le da forma física al proyecto. De todas formas con la fase anterior, gestión de compras, se inicia lo que se denomina la ejecución del proyecto. Si se han producido errores en las anteriores fases ahora es cuando surgirán los problemas, porque corregir el proyecto, una vez materializado, supone un elevado coste.

Hay varias alternativas en cuanto se refiere a la realización del proyecto, pero lo más frecuente es que el mismo se deje en manos de un contratista general o varios contratistas especializados distintos, siempre supervisado por un tercero, normalmente la institución, que realiza el anteproyecto y todos los estudios mencionados para la toma de decisiones.

Puesta en servicio

Por último, la puesta en servicio. Para evitar posibles resultados negativos, es conveniente realizar pruebas con los productos antes de enviárselos a los clientes. Las compañías de desarrollo de software generalmente piden a algunos clientes que prueben sus productos, para comprobar el buen funcionamiento de éstos antes de que empiece la campaña de publicidad para el público en general.

Una vez materializado el proyecto es hora de ponerlo en funcionamiento, es ahora cuando empieza la última de las fases del proyecto, la puesta en servicio. Ésta a su vez se divide en tres etapas: pruebas, puesta en marcha y puesta en operación, que suelen coincidir a la hora de ejecutarse y normalmente se realizan de forma simultánea.

En esta fase hay una única persona que dirige y coordina todos los movimientos, el jefe de operación.

2.4.1.3. Ingeniería de desarrollo

El conjunto de las etapas que pertenece a la fase ingeniería de detalle (gestión de compras, construcción y montaje, además de la puesta en servicio) constituye "la ingeniería de desarrollo. Es ahora cuando el proyecto empieza a materializar, primero a través de documentos y posteriormente de forma física.

La Teoría General del Proyecto terminará su cometido cuando las instalaciones queden en funcionamiento, a pesar de que el proyecto como sistema siga vivo y en desarrollo.

Sin embargo, la Teoría General del Proyecto no puede reducirse solamente a los aspectos técnicos, y tiene que incorporar elementos esenciales para el proyecto moderno como son los económicos y de planificación, y sobre todo los de control de los mismos. La calidad técnica también deberá controlarse, estableciendo los programas adecuados de aseguramiento de la calidad.

La Teoría General del Proyecto no va a suministrar las técnicas específicas que el proyecto requiere; esta Teoría presupone el conocimiento y dominio de esas tecnologías por parte de las personas que integran el equipo del proyecto. Los integrantes del equipo deberán utilizar estas técnicas con la mayor eficacia y rapidez.

El proyecto es una entidad con vida propia que se va desarrollando en el tiempo y las fases que lo constituyen se van sucediendo unas a otras, y con frecuencia mantienen solapamientos importantes.

En el campo industrial hay que distinguir los ciclos de vida del producto y del proyecto que lo origina. Éstos son semejantes pero difieren en algunos aspectos. El del producto se extiende mucho más en el tiempo, y su estudio es importante desde el punto de vista estratégico, ya que la empresa productora debe prever con tiempo suficiente el momento que el producto dejará de funcionar en el mercado para así retirarlo o actualizarlo para convertirse en otro producto diferente que lo sustituya.

Los ciclos de vida de los proyectos, con independencia de los sectores a que pertenezcan, son semejantes, y todos ellos tienen características comunes.

Figura 2.5: Ciclo de vida de un proyecto.

2.4.2. Alternativas para la ejecución del proyecto

Existen diferentes alternativas para la ejecución material del proyecto, ¿qué alternativa elegir? Los objetivos fijados en el proyecto nos ayudarán a elegir esta alternativa, decisión muy importante, porque el éxito o fracaso del proyecto dependen en cierto modo de esta elección.

Los protagonistas principales en la ejecución material del proyecto son tres: la propiedad, el proyectista y el contratista, que siempre participan, aunque a veces su situación en el proyecto no sea muy clara y aparezca enmascarada ante un observador no profesional. Las alternativas tradicionales son tres, en función de los tres protagonistas de la ejecución material del proyecto: utilizar como proyectista al propio personal de la propiedad, los servicios de un consultor ya sea persona física o jurídica o como tercera opción una consultora en gestión de proyectos. Estas tres soluciones tienen infinidad de variantes e incluso combinaciones entre ellas. A continuación se enumeran:

2.4.2.1. Alternativa proyectista - profesional de la propiedad

Normalmente se entiende por propiedad, en sentido genérico, la entidad que está desarrollando el proyecto y que va a ser su operadora y usuaria. Podrá ser:

- Una empresa ya existente lanzada por un grupo promotor.

- Una filial o subsidiaria de una empresa ya existente.

- Ampliación de una empresa ya existente.

Esta alternativa sigue siendo muy utilizada, principalmente para la ejecución de proyectos pequeños o medianos, de tecnología conocida y desarrollados por empresas con suficiente experiencia. Si la empresa no dispone de la tecnología necesaria se la suministra otra empresa, normalmente extranjera.

La persona clave de esta alternativa es el proyectista, quien realiza la transferencia de tecnología y a veces también se encarga de preparar toda la documentación del proyecto. Realiza diferentes acciones, desde redactor del proyecto hasta firmante y responsable del mismo. Esta persona actúa en estrecha colaboración con el director del proyecto, que puede ser el director técnico de la empresa, y si ésta es pequeña el propio director general.

Habitualmente, se contrata a una empresa constructora que, actuando como contratista general, realiza desde la ingeniería de detalle hasta la puesta en marcha de las instalaciones.

Pero hay empresas que tienen sus propios departamentos de ingeniería, capaces de desarrollar totalmente los nuevos proyectos de la empresa, aunque esta forma directa de ejecución del proyecto tiene más inconvenientes que ventajas:

Ventajas: en las ejecuciones directas de un proyecto por parte de la empresa las ventajas son mínimas, salvo en casos muy concretos que enumeramos a continuación:

- Las empresas que se pueden permitir la ejecución directa de un proyecto son suficientemente grandes con una tasa de inversión importante para mantener un departamento de ingeniería.

- El personal técnico del departamento de ingeniería puede ser suficiente para ejecutar el proyecto cuando éste sea sencillo o muy repetitivo. La repetición le permite conocer a suministradores y contratistas, y a éstos familiarizarse con un tema que fácilmente pueden repetir.

- En los proyectos donde las máquinas constituyen la mayor parte de la inversión y se tienen que poner obligatoriamente en contacto con los suministradores (trenes de laminación, plantas de embotellado, máquinas de papel).

Inconvenientes: los inconvenientes son generalmente grandes, y habitualmente el proyecto termina con un coste mayor:

- El personal técnico propio, habitualmente de producción, presta menor atención a su cometido principal, producir, y ello provoca una disminución de la producción.

- Salvo en los departamentos de ingeniería propios, los técnicos de producción no son los mejores proyectistas, ya que su experiencia es muy distinta y les es más difícil diseñar soluciones técnicamente acertadas que a la vez sean económicas.

2.4.2.2. Alternativa proyectista-consultor

La propiedad utiliza los servicios de uno o varios técnicos, proyectistas profesionales, habitualmente en calidad de consultores, que redactan la documentación técnica del proyecto y supervisan técnicamente la construcción y los montajes. No necesariamente se tiene que recurrir a consultores independientes, sino también a una empresa de consultoría.

La diferencia entre consultores individuales y consultoras en gestión de proyectos es que los primeros son expertos en uno o varios campos muy concretos y limitados, en cambio los segundos son un grupo de profesionales capaces de abarcar coordinadamente todos los múltiples aspectos técnicos, económicos, administrativos y de gestión que un proyecto lleva consigo.

2.4.2.3. Alternativa proyectista - empresa de ingeniería

La propiedad utiliza como proyectista una empresa de ingeniería, quien no sólo redacta la documentación técnica del proyecto tanto de la ingeniería básica como de detalle, sino que también prepara y gestiona la compra de todos los equipos y la contratación de obras civiles y montajes, supervisa estos trabajos durante la construcción y colabora también en la puesta en marcha de las instalaciones. A continuación se mencionan algunas ventajas e inconvenientes de la presente alternativa:

- Habitualmente, si se utilizan los servicios de una empresa de ingeniería, a pesar de su coste, se ve reducido el coste total del proyecto.

- El uso de contratistas individuales supone una reducción de costes, porque si se utilizan los servicios de un contratista general, éste contrata a subcontratistas y ello puede suponer un incremento de porcentaje del 15% como mínimo en concepto de gastos generales, administración y beneficio del contratista general.

- El hecho de utilizar los servicios de diferentes contratistas individuales supone que cada uno realizará la parte del proyecto de la que sea experto.

- La empresa de ingeniería puede conseguir mejores precios para sus clientes, ya que conoce el mercado muy bien y tiene buenas relaciones con suministradores. Ello reduce la inversión en equipos y materiales del proyecto.

2.5. Fase de cesión En esta última fase, se da por acabado el proyecto y se produce la transferencia de responsabilidades, de recursos y de tecnología. Se realiza una reflexión sobre los conocimientos adquiridos durante la realización del proyecto para no volver a cometer los mismos errores en futuros proyectos, es decir, un análisis a posteriori del proyecto, preguntándose qué se ha hecho bien y qué se ha hecho mal. Si no se realiza esto, es probable que se repitan los errores pasados. Lo ideal sería realizar este análisis en cada paso del proyecto. Esta reflexión debe quedar archivada en una base de datos.

La cesión, es una fase que incluye la entrega del resultado del proyecto a quienes lo usarán y de una reflexión del trabajo realizado.

2.5.1. Transferencia de la unidad de actuación (o proyecto) al cliente / usuario

La labor de recopilación de la documentación generada por el equipo gestor se debe testear su bondad en lo que se refiere a la utilidad en general, como así también a la precisión y amplitud mínima necesaria. La transferencia de la unidad de actuación al usuario, no debe limitarse, por tanto, a una entrega de la documentación. Lo indicado es una entrega personal que lleve incorporada las explicaciones necesarias para lo usuarios más próximos a cada uno de los sistemas que conforman la unidad de actuación. Por lo general hay tres tipos de entregas:

- Entregas económico-financieras.

- Entregas de relaciones contractuales y oficiales.

- Entregas técnicas.

Cada una de ellas suele tener diferentes receptores, aunque se recomienda que la documentación generada se prepare en un solo bloque con un índice conjunto. El explotador, en todo caso, decide después si le interesa hacer separatas para archivar temas distintos en diferentes departamentos. La experiencia muestra que, por lo general, todos los documentos se tienen que relacionar entre sí, así que es recomendable que puedan estar todos controlados y contemplados en forma conjunta.

De hecho, entre los documentos recopilados, de acuerdo a la siguiente figura, ya se ve que algunos documentos "técnicos", como puede ser una recepción provisional, también pueden generar disposiciones económicas por parte de uno u otro actor, así que éstos deberán ser transferidos también al responsable económico-financiero de la unidad de actuación.

2.5.1.1. Transferencias internas de la gestión de proyectos de carácter único

La evaluación tiene una finalidad más amplia que la de sacar consecuencias para el futuro. Sirve también para evaluar técnicamente al equipo que ha intervenido. Por ello algunos de

los aspectos rebasan el espíritu de simple transferencia tecnológica. En todo caso, son datos de los que se pueden sacar conclusiones para el siguiente proyecto a gestionar. Se realiza a través de una evaluación interna y otra externa.

Evaluación interna del equipo gestor

Está hecha por el gestor del proyecto, ayudado en algún caso, por un auditor, y tiene como misión, determinar si los servicios desarrollados por la gestión, se han llevado a cabo con las previsiones realizadas. El receptor de la evaluación es, en primer lugar, la gerencia de la organización que lleva a cabo la gestión. Pero fundamentalmente está pensada para producir el aprendizaje del resto de los técnicos. Por tanto, sus conclusiones son para ellos.

Desde estas premisas, deberán comprobarse:

Si se han cumplido los objetivos internos de la misión del proyecto, evaluando y buscando la clave en:

- Desviaciones del plazo.

- Desviaciones del costo (interno y externo).

- Desviaciones en la calidad.

- Desviaciones en los honorarios.

- Dedicación total.

- Errores detectados por el cliente.

- Medios extraordinarios y no previstos, empleados.

- Reclamaciones u opiniones, en general, del cliente sobre el servicio prestado.

- Desviaciones en el procedimiento.

- Fallos durante el encargo.

- Posibilidades de mejora.

- Funcionamiento del equipo.

- Observaciones del gestor o su jefe inmediato.

Si se han cumplido los objetivos externos de la misión del proyecto, buscando claves en:

- Desviaciones en el plazo.

- Desviaciones en el presupuesto.

- Desviaciones en los medios previstos por los contratistas.

- Desviaciones en la calidad de materiales, equipos, instalaciones o acabados.

- Medios extraordinarios y no previstos, empleados.

- Efectividad de los procedimientos y documentación utilizados: utilidad o inutilidad. Mejoras a introducir en el futuro.

- Problemas de seguridad.

- Problemas en la gestión del medio ambiente.

- Problemas y soluciones técnicas extraordinarias en un proyecto.

- Problemas y soluciones extraordinarias en contratación.

- Problemas y soluciones técnicas extraordinarias en corporificación.

- Errores no detectados por la gestión.

- Fallos en la coordinación de todos los actores.

- Problemas en la obtención de permisos oficiales.

- Costos de acometidas de servicios, administraciones públicas y otros ajenos a la unidad de actuación.

- Observaciones del gestor.

Se levantará un acta de la evaluación que quedará archivada en el apartado de calidad, si es que hay un sistema homologado, o simplemente en la documentación del encargo.

Evaluación externa del equipo gestor

Tiene como objeto determinar el grado de adecuación de servicio desarrollado por la gestión de proyectos a las necesidades del cliente, y por su conducto llegan a conocer aspectos impensables de la gestión que podrían pasar desapercibidos en el caso que no se hiciera. Esta evaluación la lleva a cabo una persona ajena al desarrollo del encargo a propuesta del gestor, en función de la disponibilidad y el nivel de cercanía a la persona del cliente mediante un cambio de impresiones (reunión, conversación, etc.) con el cliente en cuestión para conocer su opinión y comentarios sobre:

- Grado de satisfacción del cliente.

- Cumplimiento de plazos.

- Cumplimiento de costos.

- Capacidad de respuesta transmitida.

- Capacidad de coordinación.

- Capacidad de motivación.

- Cumplimento del contrato.

A cada una de estas preguntas, la respuesta del cliente ha de ser fácil, por lo que se aconseja que se amolde, de más positivo a menos, al esquema de: MB (muy bien), B (bien), R (regular), M (mal o malo) o MM (muy mal o malo). El receptor de la evaluación es el gerente de la organización que lleva a cabo la gestión.

Capítulo 3 .- Gestión de proyectos

O B J E T I V O S

- Comprender la noción de proyectos y el rol que ocupa el PMBOK en la constitución de un cuerpo doctrinal internacional de gestión de proyectos.

- Conocer algunas de las principales herramientas y técnicas empleadas en la gestión de proyectos.

- Conocer el rol de los modelos de madurez de gestión de proyectos y comprender la importancia.

3.1. Introducción La Gestión de Proyectos es una dimensión dentro de un proyecto y no es el proyecto en si, es decir, por una parte se muestra la dependencia de la gestión de proyecto al tipo de proyecto dentro del cual participa. Por otra parte, una serie de limitaciones debidas a la existencia y oportunidad de determinados recursos, imposiciones, condiciones del medio, 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 e-business.

En particular, la gestión de proyectos se enfoca en buscar un marco estructurado para la gestión exitosa, buscando aportar un completo conjunto de herramientas y técnicas. Motivo por el cual el presente capítulo parte de la gestión de proyectos según los diversos tipos de proyectos para después introducirse en la Guía de Fundamentos de la Dirección de proyectos conocida como Guía del PMBOK.

Por último, se revisan una serie de modelos de madurez de gestión de proyectos, los cuales permiten tener un marco de referencia que ayuda a superar la falta de habilidades y competencia, además de ser un medio para mejorar la calidad en gestión de proyectos.

3.2. Gestión de proyectos Como ya se mencionó, la Gestión de Proyectos es una dimensión dentro de un proyecto, por esta razón es conveniente revisar de qué manera el proyecto influye en la visión 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. 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.

3.2.1. Noción de gestión de proyectos

El concepto de proyecto admite varias definiciones por su amplio significado e integración en múltiples disciplinas. El 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. Por gestión se entiende la programación de actividades y ver que se cumplan.

Proyecto como consecución de objetivos. 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. 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 conocer qué conseguir y para ello busca y se nutre de varios cómo, cuándo, quién y cuánto;

- En el último caso, el gestor de proyectos debe ayudar a buscar el qué se desea, para lo cual dispone de varios cómo 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), existen autores que sugieren 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, otros autores señalan 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.

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.

3.2.2. La gestión de proyectos según el PMBOK

La forma de organizar los esfuerzos y experiencia de gestión de proyectos se han llevado adelante mediante el arte de las personas en el rol de gestor de un proyecto o varios (programa). Organizar todo aquello en un cuerpo doctrinal formal se ha visto dificultado por dos razones:

No se ha manifestado un cuerpo o núcleo central al cual ceñirse los gestores para recabar experiencias y tener un dominio común de discusión.

La gestión de proyectos es cultural, pues depende de las características y singularidades del grupo de personas que constituye y se relaciona con el proyecto.

Estas razones han hecho que hoy en día existan diversas asociaciones dedicadas al estudio de proyectos tales como:

IPMA. International Project Management Association. PMI. Project Management Institute.

Project Management Institute. El Project Management Institute (PMI) es una organización internacional orientada a la difusión y determinación de las mejores prácticas de gestión de proyectos. En este afán, produce documentos que describen prácticas generalmente aceptadas de gestión de proyectos.

PMBOK. El más importante de los documentos publicados en la actualidad por el PMI es el PMBOK, A Guide to the Project Management Body of Knowledge.

El propósito de esta guía es describir el conocimiento y las prácticas usadas en varios tipos de proyectos. Durante veinte años se han estado revisando y discutiendo cuáles son los proyectos cuyo conocimiento y estudio aporta valor y utilidad a la práctica de proyectos. Este esfuerzo se ha traducido en identificar prácticas de gestión de proyectos aplicables a cualquier proyecto. La importancia del PMBOK, por sobre toda compilación y mejora de prácticas, es que provee una base formal para fundar proyectos, guiando y orientando a gestores de proyectos sobre la forma de llevar adelante la construcción de resultados. Para ello, no obstante, es menester adaptar los contenidos del PMBOK al dominio técnico de cada proyecto en particular.

La utilidad del PMBOK se refleja en ser actualmente el estándar ANSI/PMI 99-001-2004 (PMI, 2004) y por cumplir, según Welch, con gran detalle el estándar ISO 10006 de gestión de proyectos. Además, por su propia concepción, homogeneiza el conocimiento sobre la profesión de gestión de proyectos, siendo considerado pilar o base de sistemas internacionales de certificación para Directores de Proyecto promovidos por el PMI y el IPMA, ambos en asociación con muchas otras asociaciones de Proyectos locales.

Gestión de proyectos según el PMBOK. Según el PMBOK, la gestión de proyectos es la aplicación de conocimiento, herramientas y técnicas a actividades de un proyecto en orden a satisfacer los requerimientos del proyecto, Todo este conocimiento, habilidades,

herramientas y técnicas se distribuyen y usan a lo largo de varios procesos de gestión de proyectos.

Cada proceso de Gestión de Proyectos pertenece a un Área de Conocimiento de Gestión de Procesos y se asocia a un Grupo de Procesos de Gestión (figura 3.1).

Figura 3.1: Componentes del PMBOK y sus relaciones.

3.2.2.1. Áreas de conocimiento de gestión de proyectos

Las nueve áreas de conocimiento (The Project Management Knowledge Areas), se describen en la tabla 3.1.

ÁREAS DE CONOCIMIENTO

DESCRIPCIÓN

#4. Gestión de la Integración

Incluye los procesos requeridos para asegurar que todos los elementos del proyecto son coordinados adecuadamente.

#5. Gestión del Alcance Incluye los procesos requeridos para asegurar que el proyecto incluye y considera solamente el trabajo requeridos para completar el proyecto satisfactoriamente.

#6. Gestión del Tiempo Incluye los procesos requeridos para asegurar el término temporal preciso y adecuado del proyecto.

#7. Gestión del Coste Incluye los procesos requeridos para asegurar que el proyecto se concluye dentro del presupuesto aprobado.

#8. Gestión de la Calidad

Incluye los procesos requeridos para asegurar que el proyecto satisface la necesidades para las cuales fue definido.

#9. Gestión de Recursos Humanos

Incluye los procesos requeridos para hacer un uso más efectivo de las personas involucradas en el proyecto.

#10. Gestión de las Comunicaciones

Incluye los procesos requeridos para asegurar una generación, recolección, diseminación, almacenamiento y disposición final en tiempo y de forma apropiada, de la información del proyecto.

#11. Gestión del Riesgo Es el proceso sistemático de identificar, analizar y responder a los riesgos del proyecto.

#12. Gestión de las Adquisiciones

Incluye los procesos requeridos para adquirir los bienes y servicios que el proyecto requiere para su funcionamiento desde fuera de su desempeño y funcionamiento.

Tabla 3.1. Áreas de conocimiento de gestión de proyectos.

a. Gestión de la Integración

La gestión de integración del proyecto incluye los procesos requeridos, para asegurar que los diferentes elementos del proyecto sean coordinados adecuadamente. Se ocupa de encontrar el equilibrio entre los objetivos posibles y sus alternativas, con el fin de satisfacer o colmar las necesidades y expectativas de las entidades involucradas en el proyecto. Mientras que todos los procesos de dirección de proyectos son de alguna forma integradores, los de esta área lo son de manera fundamental. La Gestión de la Integración del proyecto se utiliza cuando se necesita estimar un coste para un plan de imprevistos, o cuando se deben identificar los riesgos asociados con diferentes alternativas de personal. Sin embargo, para que un proyecto sea completado con éxito, también debe producirse la integración de otras muchas áreas. Por ejemplo:

El trabajo del proyecto debe ser integrado con las operaciones en curso de la organización ejecutora, la metodología e-business, por ejemplo.

Deben integrarse el alcance del producto y del proyecto (área 5). Deben integrarse los resultados de las distintas especialidades funcionales (como pueden ser

las especificaciones de la arquitectura e-business o los planos eléctricos, mecánicos y civiles en un proyecto de ingeniería).

b. Gestión del Alcance

La Gestión del Alcance del proyecto comprende los procesos requeridos para asegurar que el proyecto contiene todo el trabajo necesario y solamente el trabajo necesario, para completar el proyecto con éxito.

Esta área está relacionada principalmente con la definición y control de lo que está o no está incluido en el proyecto.

En el contexto del proyecto, la palabra 'alcance' puede referirse a lo siguiente:

Alcance del producto: Son las características y funciones que deben incluirse en la iniciativa o solución e-business.

Alcance del proyecto: Es el trabajo que debe llevarse a cabo para entregar una aplicación e-business con las características y funciones especificadas.

La integración debe considerar lo siguiente:

Los procesos, herramientas y técnicas empleados para dirigir el alcance del producto, son diferentes según sea el área de aplicación y normalmente son definidos como parte del ciclo de vida del proyecto, el cual puede ser la metodología e-business y/o el modelo de desarrollo en un proyecto informático.

Lo que debe tenerse cuidado, es que un proyecto consta de un único producto, pero este producto puede tener elementos auxiliares, cada uno de ellos con su propio alcance del producto, separado pero interdependiente. Por ejemplo, un nuevo sistema telefónico generalmente incluirá cuatro elementos auxiliares: hardware, software, formación e instalación. En el caso de una iniciativa e-business, cuya solución es una aplicación e-business, ella constará de una serie de hardware, software y procedimientos de trabajo vinculados a la manutención de la arquitectura e-business y de un conjunto de aplicaciones de software específicas y procedimientos de operación ligados que permiten la operación de la aplicación e-business.

La comprobación de que se ha completado el alcance del producto se realiza según los requerimientos del mismo, mientras que el alcance del proyecto se realiza según el plan del proyecto. Estos dos tipos de gestión del alcance deben estar perfectamente integrados para asegurar que los trabajos del proyecto darán como resultado el producto especificado.

c. Gestión del Tiempo

La Gestión del Tiempo incluye los procesos necesarios para asegurar la conclusión del proyecto en los tiempos establecidos. En algunos proyectos, especialmente en los mas pequeños, la secuencia de actividades, la estimación de la duración de las actividades y el desarrollo del programa están tan íntimamente ligados que se consideran como un único proceso (por ejemplo, pueden desarrollarse por una sola persona en un período de tiempo relativamente corto). No obstante el PMBOK presenta estos procesos separados y distintos porque las herramientas y técnicas para cada uno son diferentes. Respecto de esta área, la única consideración es que no existe consenso entre los profesionales de la gestión de proyectos sobre la relación entre actividades y tareas, pues:

En muchas áreas de aplicación, se considera a las actividades compuestas por tareas. Esto es lo más normal y lo más utilizado.

En otras áreas, se considera a las tareas compuestas por actividades.

Sin embargo, la consideración más importante no es el termino que se utilice, sino si el trabajo a realizar es descrito de forma precisa y si es comprendido por las personas que deben realizarlo, distinguiendo claramente cuando algo se compone de otra cosa. Esta consideración es muy importante en un proyecto e-business, donde el trabajo interdisciplinario de diversos profesionales, informáticos, economistas, administradores de empresa, electrónicos, etc., pueden manejar distintas acepciones de lo mismo. En este caso, lo prioritario es fijar el glosario de términos oficiales del proyecto.

d. Gestión del Coste

La Gestión de Coste del proyecto incluye los procesos necesarios para asegurar que el proyecto se finaliza dentro del presupuesto aprobado. La Gestión de Costes del proyecto está relacionada con el coste de los recursos necesarios para completar las actividades del proyecto. Sin embargo, la gestión de costes del proyecto debería considerar también el

efecto que tiene la toma de decisiones del proyecto sobre los costes de utilizar el producto del proyecto. Por ejemplo, la limitación del número de revisiones del diseño puede reducir los costes del proyecto, a expensas de un aumento en los costes operativos del cliente. Esta visión más global de la gestión de costes del proyecto se suele llamar coste del ciclo de vida. Este tema es especialmente relevante, por ejemplo, en un proyecto e-business, pues, por una parte, la iniciativa e-business es un cambio cultural respecto de cómo enfrentar la gestión de un negocio y en cómo plantearse una organización de fronteras virtuales y, por otra parte, la aplicación e-business final es en sí misma la incorporación a una organización de un tipo de tecnología en muchas ocasiones nueva, además, de hardware y software cuya gestión requiere tratamiento especial y de gran cuidado, con los costes que ello significa.

Estos costes involucran, por ejemplo, conseguir profesionales adecuados para construir la aplicación e-business y profesionales que luego puedan responder a las contingencias de la operación de la aplicación e-business. Como parte de la Gestión del Coste:

En muchas áreas de aplicación, la predicción y análisis del futuro rendimiento financiero del producto del proyecto se realiza fuera del proyecto. Cuando se incluyen estas predicciones y análisis, la Gestión de Costes incluirá procesos adicionales y numerosas técnicas de dirección general como la tasa interna de retorno (TIR), el valor actual neto (VAN), período de recuperación del capital y otros.

Esta gestión debería de considerar las necesidades de información de las entidades involucradas en el proyecto: diferentes entidades pueden medir los costes del proyecto de diferentes maneras y en distintos momentos. Por ejemplo, el coste de un artículo de un proveedor puede ser medido cuando se ha autorizado su compra, cuando se ha pedido, cuando se ha pagado o cuando se ha contabilizado.

Cuando los costes del proyecto se utilizan como un componente de un sistema de recompensa y reconocimiento, deberían estimarse y presupuestarse separadamente los costes controlables y los incontrolables, para asegurar que las recompensas reflejan el desarrollo real del proyecto.

En algunos proyectos, especialmente en los mas pequeños, la planificación de recursos, la estimación de costes y el presupuesto de costes están tan íntimamente ligadas que se ven como un solo proceso (por ejemplo, puede desarrollarlas una sola persona en un período de tiempo relativamente corto). No obstante el PMBOK presenta estos procesos separados y distintos porque las herramientas y técnicas para cada uno son diferentes.

e. Gestión de la Calidad

La Gestión de la Calidad del proyecto incluye los procesos necesarios para asegurar que el proyecto satisfará las necesidades para las que se ha llevado a cabo. Con esto se incluyen todas las actividades de la dirección que determinan la política de la calidad, objetivos y responsabilidades, así como su desarrollo por medios tales como planificación de la calidad, control de la calidad, aseguramiento de la calidad y mejora de la calidad, dentro del sistema de la calidad.

El método básico de gestión de calidad a seguir debe ser compatible con el que la Organización Internacional de Normalización (ISO) ha detallado en las series de normas ISO 9000 y 10000. Este método generalizado también debería ser compatible con métodos de

gestión de la calidad vinculados a Deming, Juran, Crosby y otros, y otros como la gestión de la Calidad Total (TQM) o la mejora continua.

La calidad es el conjunto de características de una entidad que constituyen su capacidad para satisfacer necesidades implícitas o evidentes.

La Gestión de la Calidad debe dirigirse tanto a la dirección del proyecto como al producto del proyecto. Un fallo en el cumplimiento de las exigencias de la calidad en alguna dimensión puede tener consecuencias negativas serias para alguna o todas las entidades involucradas en el proyecto. Por ejemplo:

Cumplir los requerimientos del cliente mediante un trabajo excesivo del equipo del proyecto puede producir consecuencias negativas como un incremento en la rotación de personal.

Cumplir los objetivos de programación del proyecto, acelerando las revisiones de la calidad planificadas, puede producir consecuencias negativas cuando existan errores que no sean detectados.

Un aspecto crítico de la Gestión de la Calidad en el contexto del proyecto es la necesidad de convertir las necesidades implícitas en necesidades evidentes a través de la Gestión del Alcance del proyecto.

El equipo de dirección del proyecto debe tener cuidado de no confundir calidad con grado. Grado es una categoría o rango dado a entidades que, teniendo el mismo uso funcional, tienen diferentes requerimientos de calidad. La baja calidad es siempre un problema; el bajo grado puede no serlo. Por ejemplo, un producto de software puede ser de alta calidad (sin errores, manual fácilmente legible) y bajo grado (pequeño número de aplicaciones), o de baja calidad (muchos errores, documentación del usuario mal organizada) y alto grado (numerosas aplicaciones).

Determinar y conseguir los niveles adecuados de calidad y grado son las responsabilidades del gestor del proyecto y del equipo de dirección del proyecto.

El equipo de dirección del proyecto debe saber también que la gestión de la calidad moderna complementa a la dirección de proyectos moderna. Por ejemplo, ambas disciplinas reconocen la importancia de:

La satisfacción del cliente: tratar de cumplir o exceder las expectativas del cliente. Esto requiere tanto la conformidad con las especificaciones (el proyecto debe producir lo que se dijo iba a producir), como la adecuación para su uso (el producto o servicio producido debe satisfacer las necesidades reales).

La prevención sobre la inspección: el coste de evitar los errores siempre es mucho menor que el de corregirlos.

Responsabilidad de la gestión: el éxito requiere la participación de todos los miembros del equipo, pero permanece la responsabilidad de la dirección de suministrar los recursos necesarios para lograrlo.

Procesos dentro de fases del ciclo reiterativo planificar-ejecutar-comprobar-actuar.

Además, las iniciativas de mejora de la calidad llevadas a cabo por la organización ejecutora (por ejemplo, la gestión de la calidad total, TQM), la mejora continua, y otros) pueden y deben mejorar la calidad de la dirección del proyecto, así como la calidad del producto del proyecto.

Sin embargo, hay una diferencia importante sobre la que el equipo de dirección del proyecto debe estar muy precavido: la naturaleza temporal de los proyectos implica que las inversiones en mejora de la calidad del producto, especialmente la prevención de defectos y las pruebas, deben frecuentemente soportarse por parte de la organización ejecutora dado que el proyecto puede no durar lo suficiente para recoger la recompensa.

f. Gestión de Recursos Humanos

La Gestión de Recursos Humanos del proyecto incluye los procesos necesarios para aprovechar más efectivamente al personal relacionado con el proyecto, incluyendo a todas las entidades involucradas en el proyecto (patrocinadores, clientes, contribuyentes individuales y otros). Hay gran cantidad de literatura sobre las relaciones interpersonales en un contexto operativo continuo. Algunas de las muchas ideas extendidas son:

Liderazgo, comunicación, negociación y otras más aptitudes clave en la dirección general. Delegación, motivación, enseñanza, apadrinamiento y otros temas relacionados con el trato

personal. Creación de equipos, resolución de conflictos y otros temas relacionados con el trato en

grupo. Análisis del grado de preparación., reclutamiento, retención, relaciones laborales, seguridad e

higiene en el trabajo y otras elementos relacionados con la función de administración de recursos humanos.

La mayor parte de este material es aplicable al liderazgo y a la dirección de personas en proyectos y el gestor del proyecto y el equipo de dirección del proyecto deben estar familiarizados con estos conceptos.

Sin embargo, deben ser también sensibles a la aplicación de estos conceptos en el proyecto. Por ejemplo:

Sin embargo, deben ser también sensibles a la aplicación de estos conceptos en el proyecto. Por ejemplo:

La naturaleza temporal de los proyectos supone que las relaciones personales y de la organización serán, generalmente, temporales y nuevas. El equipo de dirección del proyecto debe tener cuidado a la hora de seleccionar técnicas que sean apropiadas para estas relaciones temporales.

La naturaleza y el número de entidades involucradas en el proyecto cambiarán a menudo según el proyecto va pasando por las distintas fases de su cielo de vida. Como consecuencia de esto, técnicas que son aptas en una fase determinada, pueden no ser efectivas en otra

fase. El equipo de dirección del proyecto debe prestar especial atención en utilizar las técnicas apropiadas a las necesidades actuales del proyecto.

Las actividades administrativas de los recursos humanos son rara vez una responsabilidad directa del equipo de dirección del proyecto. Sin embargo, el equipo debe conocer suficientemente los requerimientos administrativos para asegurar su cumplimiento.

g. Gestión de las Comunicaciones

La Gestión de Comunicaciones del proyecto comprende los procesos necesarios para, en el momento y manera adecuados, asegurar la elaboración, recopilación, distribución, archivo y disposición definitiva de la información del proyecto. Proporciona las conexiones clave entre personas, ideas e información, que son necesarias para el éxito del proyecto. Esto se hace para que cualquier persona implicada en el proyecto debe estar preparada para enviar y recibir comunicaciones en el lenguaje del proyecto, y debe comprender que las comunicaciones que se realizan entre personas afectan al proyecto en su conjunto.

La aptitud de la dirección general para la comunicación está relacionada, pero no es lo mismo, que la Gestión de Comunicaciones del proyecto. Comunicación es un término general y comprende una gran cantidad de aspectos que no se circunscriben solamente al contexto del proyecto. Por ejemplo:

Modelos emisor-receptor (lazos de realimentación, obstáculos a las comunicaciones, etc.). Elección del medio (cuándo comunicar por escrito y cuándo hacerlo verbalmente, cuándo

escribir un memorando informal y cuando hacer un informe formal, etc.). Estilo de escritura (voz activa frente a voz pasiva, estructura de las oraciones, elección de

vocabulario, etc.). Técnicas de presentación (lenguaje del cuerpo, diseño de ayudas visuales, etc.). Técnicas de dirección de reuniones (preparación de una agenda, tratamiento de conflictos,

etc.).

Esta área es de importancia ya que muchos proyectos fallan por problemas de comunicación. Por esta razón, es responsabilidad del gestor de proyectos crear un ambiente dentro del proyecto propicio para una efectiva comunicación intra e intergrupal que permita que todas las partes estén informadas de manera fluida. Lo importante es no dar sorpresas, menos al cliente. Por esto, las comunicaciones no deben depender de informes aislados, sino que es bueno aprovechar las reuniones para comunicar. No hay que olvidar que una buena frase puede ser mejor que un cuidado informe de estado.

h. Gestión del Riesgo

La gestión de riesgos del proyecto incluye los procesos relacionados con la identificación, análisis y respuesta a los riesgos de un proyecto. Incluye maximizar los efectos positivos de los distintos eventos y minimizar las consecuencias de sus efectos negativos. Las diferentes áreas de aplicación utilizan, con frecuencia, diferentes nombres para los procesos aquí descritos. Por ejemplo:

La identificación y cuantificación de riesgos se tratan, en algunas ocasiones, como un solo proceso y el proceso combinado puede llamarse análisis o evaluación de riesgos.

Al desarrollo de respuestas a riesgos se le denomina algunas veces Planificación de respuestas o mitigación de riesgos.

El desarrollo y el control de las respuestas ante el riesgo se tratan algunas veces como un solo proceso, pudiendo ser denominarse dicho proceso combinado gestión de riesgos.

Esta área, en muchos casos definida como función, es una de las más importantes hoy en día debido al entorno cambiante en que se desenvuelven los proyectos e-business en particular, y cualquier proyecto en general. Durante la fase de planificación, el gestor de proyecto necesita realizar una valoración realista de riesgos y desarrollar un plan para controlarles. Para ello debe considerar como factores de riesgo:

- El tamaño del proyecto;

- La estructura del proyecto; y,

- La experiencia con las técnicas utilizadas.

Debe tenerse presente que los riesgos de un proyecto aumentan conforme crece, es poco estructurado (es decir, los requerimientos no se definen bien y probablemente cambien durante el proyecto) y hay menos experiencia del equipo en la tecnología a usar. En estos casos adoptar un enfoque de contingencia es una estrategia adecuada de gestión de los diversos tipos de riesgo, para las cuales existen diversos tipos de herramientas de integración externa, interna y de control y planificación (figura 3.2).

Figura 3.2: Enfoque de contingencia de Gestión de Riesgo.

Proyectos con una estructura pequeña se pueden beneficiar de herramientas de integración externa para crear relaciones efectivas entre el equipo del proyecto y los clientes de la organización. Por ejemplo:

- Seleccionar al gestor del proyecto y a los miembros del equipo del proyecto desde la misma organización que recibirá el producto;

- Mantener una representación de clientes en todas, o casi todas, las reuniones de revisión del proyecto; y/o,

- Mantener una amplia difusión y distribución de los informes de estado del proyecto dentro de la organización.

Proyectos que involucran el uso de nueva tecnología deberían confiar más en herramientas de integración interna, las cuales han sido diseñadas para mejorar la competencia y operación técnica del equipo como una unidad integrada. Por ejemplo:

- Seleccionar o disponer de miembros experimentados;

- Contar con un gestor del proyecto con gran dominio técnico y experiencia probada en gestión de proyectos;

- Mantener frecuentes reuniones de estado del proyecto con los miembros.

Grandes proyectos, con una gran estructura deberían ser gestionados con profusión de herramientas de gestión y de control. Estas herramientas, representan un esfuerzo sistemático y disciplinado de planificación y control. Por ejemplo, WBS, presupuestos, planes y procedimientos de seguimiento. Mientras la elección de un enfoque adecuado para gestionar el proyecto es de gran importancia, es importante una valoración de los riesgos, lo cual incluye:

- El propósito de la identificación de riesgos es desarrollar una lista de los riesgos que pueden afectar el proyecto y su producto.

- El análisis de riesgos consiste de valorizar la exposición al riesgo, la probabilidad e impacto de cada uno de ellos.

- La priorización de los riesgos produce una lista de riesgos priorizados según el impacto que un riesgo tiene en el proyecto y el producto.

Con esto se puede planificar según los riesgos de mayor impacto e incidencia, planteando planes de contingencia para hacerles frente y monitorearles. Es importante que los riesgos sean valorizados continuamente cuando se monitorean para mantener actualizada una lista de, por ejemplo, los 10 riesgos de mayor prioridad e incidencia.

i. Gestión de las Adquisiciones

La Gestión de las adquisiciones del proyecto incluye los procesos requeridos para la adquisición de bienes y servicios, producto en general, en el exterior de la organización ejecutora. Esta gestión requiere una perspectiva de comprador como parte de una relación comprador-proveedor. Esta relación se puede dar a muchos niveles en un mismo proyecto. Dependiendo del área de aplicación, al proveedor se le puede llamar contratista, vendedor o suministrador. El proveedor dirigirá normalmente su trabajo como un proyecto. En tales casos:

El comprador se convierte en cliente y es así, una entidad involucrada en el proyecto clave para el proveedor.

El equipo de dirección de proyectos del proveedor debe estar interesado en todos los procesos de dirección de proyectos, no sólo en aquellos de este área de conocimiento.

Los términos y condiciones del contrato se convierten en un dato clave para muchos de los procesos del proveedor. El contrato puede contener realmente los datos (por ejemplo,

entregas principales, hitos clave, objetivos de coste) o puede limitar las opciones del equipo del proyecto (por ejemplo, en los proyectos de diseño se requiere frecuentemente la aprobación del comprador de las decisiones de asignación de personal).

3.2.2.2. Grupos de procesos de gestión

Los grupos de procesos de gestión (Management Processes Groups), son agrupaciones de procesos de gestión de proyectos, relacionados con las cinco fases de un proyecto: Iniciación (IP), Planificación (Pl), Ejecución (EP), Seguimiento y Control (CoP), y Cierre (ClP).

La figura 3.3 muestra la relación entre estos grupos y la tabla 3.2 presenta su descripción.

Figura 3.3: Grupos de procesos de gestión.

El nivel de actividad de estos grupos de procesos durante el proyecto varía en el tiempo tal como ilustra la figura 3.4.

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

CÓDIGO GRUPO DE PROCESOS

DESCRIPCIÓN

IP Procesos de Iniciación

Autorizar el proyecto o fase.

PP Procesos de Planificación

Definir y refinar objetivos y seleccionar el mejor curso alternativo de acción para conseguir los objetivos que el proyecto persigue alcanzar.

EP Procesos de Ejecución

Coordinar personas y otros recursos para llevar adelante el plan.

CoP Procesos de Control

Asegurar que los objetivos del proyecto son conseguidos midiendo y monitoreando el progreso regularmente a través de identificar variaciones respecto del plan, para así tomar acciones correctivas cuando sea necesario.

ClP Procesos de Cierre

Formalizar la aceptación del proyecto fase y colocar todo en un orden coherente.

Tabla 3.2. Grupos de procesos de gestión.

3.2.2.3. Procesos de gestión de proyectos

Los Procesos de Gestión de Proyectos son el eje de toda la propuesta del PMBOK (tabla 3.3), 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, salidas, 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.

NUM. PROCESOS DE GESTIÓN DE PROYECTOS

DESCRIPCIÓN

4. GESTIÓN DE LA INTEGRACIÓN DEL PROYECTO

4.1 Desarrollar el Acta de Constitución del Proyecto

Desarrolla el acta de constitución del proyecto que autoriza formalmente un proyecto.

4.2 Desarrollar el Enunciado del Alcance del Proyecto Preliminar

Desarrolla el enunciado del alcance del proyecto preliminar que ofrece una descripción del alcance a alto nivel.

4.3 Desarrollar el Plan de Gestión del Proyecto

Documenta las acciones necesarias para definir, preparar, integrar y coordinar todos los planes subsidiarios en un plan de gestión del proyecto.

4.4 Dirigir y Gestionar la Ejecución del Proyecto

Ejecuta el trabajo definido en el plan de gestión del proyecto para lograr los requisitos del proyecto definidos en el enunciado del alcance del proyecto.

4.5 Supervisar y Controlar el Trabajo del Proyecto

Supervisa y controla los procesos requeridos para iniciar, planificar, ejecutar y cerrar un proyecto, a fin de cumplir con los objetivos de rendimiento definidos en el plan de gestión del proyecto.

4.6 Control Integrado de Cambios

Revisa todas las solicitudes de cambio, aprueba los cambios y controla los cambios en los productos entregables y en los activos de los procesos de la organización.

4.7 Cerrar Proyecto Finaliza todas las actividades en todos los Grupos de Procesos del Proyecto para cerrar formalmente el proyecto.

5. GESTIÓN DEL ALCANCE DEL PROYECTO

5.1 Planificación del Alcance

Crea un plan de gestión del alcance del proyecto que documenta cómo se definirá, verificará y controlará el alcance del proyecto, y cómo se creará y definirá la estructura de desglose del trabajo (EDT).

5.2 Definición del Alcance Desarrolla un enunciado detallado del alcance del proyecto como base para futuras decisiones del proyecto.

5.3 Crear EDT Subdivide los principales productos entregables del proyecto y el trabajo del proyecto en componentes más pequeños y más fáciles de gestionar.

5.4 Verificación del Alcance Formaliza la aceptación de los productos entregables completados del proyecto.

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

6. GESTIÓN DEL TIEMPO DEL PROYECTO

6.1 Definición de las Identifica las actividades específicas del cronograma que deben ser

Actividades realizadas para producir los diferentes productos entregables del proyecto.

6.2 Establecimiento de la Secuencia de las Actividades

Identifica y documenta las dependencias entre las actividades del cronograma.

6.3 Estimación de Recursos de las Actividades

Estima el tipo y las cantidades de recursos necesarios para realizar cada actividad del cronograma.

6.4 Estimación de la Duración de las Actividades

Estima el número de períodos laborables que se necesitarán para completar actividades individuales del cronograma.

6.5 Desarrollo del Cronograma

Analiza las secuencias de las actividades, su duración, los requisitos de recursos y las restricciones del cronograma para crear el cronograma del proyecto.

6.6 Control del Cronograma Controla los cambios en el cronograma del proyecto.

7. GESTIÓN DE LOS COSTES DEL PROYECTO

7.1 Estimación de Costes Desarrolla una aproximación de los costes de los recursos necesarios para completar las actividades del proyecto.

7.2 Preparación del Presupuesto de Costes

Suma los costes estimados de actividades individuales o paquetes de trabajo a fin de establecer una línea base de coste.

7.3 Control de Costes Ejerce influencia sobre los factores que crean variaciones del coste y controla los cambios en el presupuesto del proyecto.

8. GESTIÓN DE LA CALIDAD DEL PROYECTO

8.1 Planificación de Calidad Identifica qué normas de calidad son relevantes para el proyecto y determina cómo satisfacerlas.

8.2 Realizar Aseguramiento de Calidad

Aplica las actividades planificadas y sistemáticas relativas a la calidad, para asegurar que el proyecto emplee todos los procesos necesarios para cumplir con los requisitos.

8.3 Realizar Control de Calidad

Supervisa los resultados específicos del proyecto, para determinar si cumplen con las normas de calidad pertinentes e identifica modos de eliminar las

causas de un rendimiento insatisfactorio.

9. GESTIÓN DE LOS RECURSOS HUMANOS DEL PROYECTO

9.1 Planificación de los Recursos Humanos

Identifica y documenta los roles del proyecto, las responsabilidades y las relaciones de informe, y también crea el plan de gestión de personal.

9.2 Adquirir el Equipo del Proyecto Obtiene los recursos humanos necesarios para completar el proyecto.

9.3 Desarrollar el Equipo del Proyecto

Mejora las competencias y la interacción de los miembros del equipo para lograr un mejor rendimiento del proyecto.

9.4 Gestionar el Equipo del Proyecto

Hace un seguimiento del rendimiento de los miembros del equipo, proporciona retroalimentación, resuelve polémicas y coordina cambios a fin de mejorar el rendimiento del proyecto.

10. GESTIÓN DE LAS COMUNICACIONES DEL PROYECTO

10.1 10.1 Planificación de las Comunicaciones

Determina las necesidades de información y comunicación de los interesados en el proyecto.

10.2 10.2 Distribución de la Información

Hace que la información necesaria esté disponible para las personas interesadas en el proyecto en el momento oportuno.

10.3 10.3 Informar el Rendimiento

Recopila y distribuye información sobre el rendimiento, incluido el informe de estado de la situación, la medición del avance y las proyecciones.

10.4 10.4 Gestionar a los Interesados

Gestiona las comunicaciones a fin de satisfacer los requisitos de los interesados en el proyecto y resolver polémicas con ellos.

11. GESTIÓN DE LOS RIESGOS DEL PROYECTO

11.1 Planificación de la Gestión de Riesgos

Decide cómo enfocar, planificar y ejecutar las actividades de gestión de riesgos para un proyecto.

11.2 Identificación de Riesgos

Determina qué riesgos pueden afectar al proyecto y documenta sus características.

11.3 Análisis Cualitativo de Riesgos

Prioriza los riesgos para otros análisis o acciones posteriores, evaluando y combinando su probabilidad de ocurrencia y su impacto.

11.4 Análisis Cuantitativo de Riesgos

Analiza numéricamente el efecto de los riesgos identificados en los objetivos generales del proyecto.

11.5 Planificación de la Respuesta a los Riesgos

Desarrolla opciones y acciones para mejorar las oportunidades y reducir las amenazas a los objetivos del proyecto.

11.6 Seguimiento y Control de Riesgos

Realiza el seguimiento de los riesgos identificados, supervisa los riesgos residuales, identifica nuevos riesgos, ejecuta planes de respuesta a los riesgos y evalúa su efectividad durante todo el ciclo de vida del proyecto.

12. GESTIÓN DE LAS ADQUISICIONES DEL PROYECTO

12.1 Planificar las Compras y Adquisiciones Determina qué comprar o adquirir, y cuándo y cómo hacerlo.

12.2 Planificar la Contratación

Documenta los requisitos de los productos, servicios y resultados, e identifica los posibles vendedores.

12.3 Solicitar Respuestas de Vendedores

Obtiene información, presupuestos, licitaciones, ofertas o propuestas, según corresponda.

12.4 Selección de Vendedores

Revisa ofertas, selecciona entre posibles vendedores y negocia un contrato por escrito con un vendedor.

12.5 Administración del Contrato

Gestiona el contrato y la relación entre el comprador y el vendedor, revisa y documenta cuál es o ha sido el rendimiento de un vendedor a fin de establecer las acciones correctivas necesarias y proporcionar una base para relaciones futuras con el vendedor, gestiona cambios relacionados con el contrato y, cuando corresponda, gestiona la relación contractual con el comprador externo del proyecto.

12.6 Cierre del Contrato Completa y aprueba cada contrato, incluida la resolución de cualquier tema abierto, y cierra cada contrato.

Tabla 3.3. Procesos de gestión de proyectos (PMI, 2004).

3.2.2.4. Relación entre grupos, áreas y procesos

La relación entre grupos, áreas y procesos se presenta en la tabla 3.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 se 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.

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 x

Gestión de las Comunicaciones x x x

Gestión del Riesgo x x

Gestión del Abastecimiento x x x

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

Cada uno de los procesos de dirección de proyectos requeridos se muestra en el Grupo de Procesos en el cual se lleva a cabo la mayor parte de la actividad, estas relaciones se muestran en la tabla 3.5. A modo de ejemplo, la figura 3.5 ilustra el Grupo de Procesos de Seguimiento y Control (CoP).

Figura 3.5: Grupo de Procesos de Seguimiento y Control (PMI, 2004).

Correspondencia de los procesos de Dirección de Proyectos

La tabla 3.5 muestra la correspondencia de los 44 procesos de dirección de proyectos en los cinco Grupos de Procesos de Dirección de Proyectos y las nueve Áreas de Conocimiento de la Dirección de Proyectos. En esta tabla se observa la actividad que se realiza en cada proceso de dirección de proyectos.

PROCESOS DE UN ÁREA DE CONOCIMIENTO

GRUPO DE PROCESOS DE DIRECCIÓN DE PROYECTOS

GRUPO DE PROCESOS DE INICIACIÓN

GRUPO DE PROCESOS DE PLANIFICACIÓN

GRUPO DE PROCESOS DE EJECUCIÓN

GRUPO DE PROCESOS SEGUIMIENTO Y CONTROL

GRUPO DE PROCESOS DE CIERRE

4. Gestión de la Integración del Proyecto

Desarrollar el Acta de Constitución del Proyecto

3.2.1.1 (4.1)

Desarrollar el Enunciado del Proyecto Preliminar

3.2.1.2 (4.2)

Desarrollar el Plan de Gestión del Proyecto

3.2.1.1 (4.3)

Dirigir y Gestionar la Ejecución del Proyecto

3.2.3.1 (4.4)

Supervisar y Controlar el Trabajo del Proyecto

3.2.4.1 (4.5)

Control Integrado de Cambios

3.2.4.2 (4.6)

Cerrar Proyecto

3.2.5.1 (4.7)

5. Gestión del Alcance del Proyecto

Planificación del Alcance

3.2.2.2 (5.1)

Definición del Alcance

3.2.2.3 (5.2)

Crear EDT

3.2.2.4 (5.3)

Verificación del Alcance

3.2.4.3 (5.4)

Control del Alcance

3.2.4.4 (5.5)

6. Gestión del Tiempo del Proyecto

Definición de las Actividades

3.2.2.5 (6.1)

Establecimiento de la Secuencia de las Actividades

3.2.2.6 (6.2)

Estimación de Recursos de las

Control del Cronograma

3.2.4.5 (6.6)

Actividades

3.2.2.7 (6.3)

Estimación de la duración de las Actividades

3.2.2.8 (6.4)

Desarrollo del Cronograma

3.2.29 (6.5)

7. Gestión de los Costes del Proyecto

Estimación de Costes

3.2.2.10 (7.1)

Preparación del Presupuesto de Costes

3.2.2.11 (7.2)

Control de Costes 3.2.4.6 (7.3)

8. Gestión de la Calidad del Proyecto

Planificación de la Calidad 3.2.2.12 (8.1)

Realizar Aseguramiento de la Calidad

3.2.3.2 (8.2)

Realizar Control de Calidad 3.2.4.7 (8.3)

9. Gestión de los Recursos Humanos del Proyecto

Planificación de los Recursos Humanos 3.2.2.13 (9.1)

Adquirir el Equipo del Proyecto 3.2.3.3 (9.2)

Desarrollar el Equipo del Proyecto 3.2.3.4 (9.3)

Gestionar el equipo del Proyecto 3.2.4.8 (9.4)

10. Gestión de las Comunicaciones del Proyecto

Planificación de las Comunicaciones 3.2.2.14 (10.1)

Distribución de la Información

3.2.3.5 (10.2)

Informar el Rendimiento

3.2.4.9 (10.3)

Gestionar a los Interesados 3.2.4.10 (10.4)

7.4. Administrative Closure (p)

11. Gestión de los Planificación de la Seguimiento y

Riesgos del Proyecto

Gestión de Riesgos 3.2.2.15 (11.1)

Identificación de Riesgos

3.2.2.16 (11.2)

Análisis Cualitativo de Riesgos 3.2.2.17 (11.3)

Análisis Cuantitativo de Riesgos 3.2.2.18 (11.4)

Planificación de la Respuesta a los Riesgos 3.2.2.19 (11.5)

Control de riesgos 3.2.4.11 (11.6)

12. Gestión de las Adquisiciones del Proyecto

Planificar las Compras y Adquisiciones 3.2.2.20 (21.1)

Planificar la Contratación 3.2.2.21 (12.2)

Solicitar Respuestas de Vendedores 3.2.3.6 (12.3)

Selección de Vendedores 3.2.3.7 (12.4)

Administración del Contrato 3.2.4.12 (12.5)

Cierre del Contrato

3.2.5.2

(12.6)

Tabla 3.5.

Relación entre grupos de procesos, áreas de conocimiento y procesos de gestión de proyectos. p: principal; f: facilitador.

Problemas de Gestión

En la siguiente tabla se describen algunos problemas que diferentes autores han encontrado durante el proceso de dirección de un proyecto.

TIPO DE PROBLEMA DE GESTIÓN McCONNELL GLASS PURBA REDMILL

GESTIÓN DE INTEGRACIÓN

Planificación

Exceso de requerimientos (producto)

Usuarios se

Incapacidad de los usuarios en

Poca claridad en los

resisten comunicar requerimientos (elemento humano)

requerimientos

Abandono de tiempo en el inicio (proceso)

Promotor está perdido

Pérdida de tiempo en el inicio (proceso)

Ejecución 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)

Ejecución

Añadir más personal a un proyecto retrasado (personas)

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)

Más 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)

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 necesidades de los usuarios

Incapacidad de los usarios en comprender las 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 porco realistas (elemento humano)

Síndrome de la panacea tecnológica

Estrategia de implementación débil (elemento humano)

Mejoras prácticas y lecciones son olvidadas

Sobreestimación de las ventajas del empleo o de nuevas herramientas o métodos (tecnología)

Ejecución

Limitaciones 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)

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

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 Planificación

Se carece del

CALIDAD personal con las habilidades adecuadas

Ejecución Oficinas repletas y ruidosas (personas)

Control Escatimar en el control de la calidad (proceso)

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 dientes y los desarrolladores (personas)

Falta de participación de los implicados (personas)

GESTIÓN DE COMUNICACIONES

Planificación

Insuficientes habilidades 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 habilidades adecuadas

Cierre

Tiras y aflojas en la negociación (personas)

Falta de participación de los usuarios (personas)

GESTIÓN DEL RIESGO

Planificación Gestión de riesgo insuficiente (proceso)

Control Tiras y aflojas en la negociación (personas)

GESTIÓN DE LAS ADQUISICIONES

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 habilidades adecuadas

Tabla 3.6. Diversos tipos de problemas de gestión clasificados según el PMBOK.

3.2.3. Estados de una mala gestión de proyectos

Los errores cometidos durante la gestión, mostrados en la tabla 3.6 y muchos otros más, ocurren y han sido reportados profusamente en la literatura. No obstante, se han podido determinar algunos estados que indican una gestión de proyectos inefectiva o de que es prudente plantearse usarla. Estos estados de un proyecto son:

Modo ajustado (crunch mode); Marcha mortal (death march); y, Fuera de control (runaway).

3.2.3.1. Modo ajustado

Para Glass, el modo ajustado describe un proyecto que se encuentra extremadamente ajustado a la programación. Se habla que existen fuertes presiones que sienten los participantes del proyecto. Es el estado cuando el proyecto anda por los límites del programa de trabajo, más bien superándolo. En este estado, dentro del proyecto informático comienza a notarse que:

- Las semanas tienen siete días y los días 24 horas";

- Los días son cortos y las noches largas";

- Empiezan las primeras fugas;

- Hay una 'ralentización' de la motivación;

- Se suceden las re-planificaciones de forma frecuente;

- Etc.

3.2.3.2. Marcha mortal

Según Glass, la marcha mortal describe un estado en que el proyecto tiene una programación difícil de conseguir. Se habla que "hay olor a fracaso" ("esto huele mal") entre los participantes. Para Yourdon, un proyecto en marcha mortal posee una valoración de riesgo de falla sobre el 50 por ciento (incluyendo riesgos técnicos, del personal, legales, políticos, etc.). Según Ribera este estado es un Modo Imposible de trabajo debido a que:

El plazo es inferior a la mitad de lo que racionalmente se precisa"; El personal asignado es inferior a la mitad que habitualmente se asignaría a un proyecto de

estas características"; El presupuesto se ha recortado a la mitad", y, La funcionalidad, requisitos, y otros aspectos técnicos son superiores al doble de lo normal".

El mismo Ribera acota, que en estas situaciones surgen preguntas como: "¿Qué hace un chico como yo en un proyecto como éste" o "¿Cómo puedo sobrevivir a este proyecto sin perder mi salud física y mental y mi dignidad?".

3.2.3.3. Fuera de control y escalada

Un proyecto fuera de control, o "Runaway", describe un estado o un estado de cosas manifestadas cuando un proyecto está cerca o después de su término. Sencillamente, el proyecto está fuera de sus límites o ya no tiene límites, según Glass, el proyecto falló o está pronto a fracasar.

Cuando se está fuera de control, se puede decir que estamos ante una bola de nieve, la cual resulta de una escalada de errores por motivos, que según Keil y Mixon, se deben a factores psicológicos, sociales y organizacionales. Estos errores son consecuencia de una gestión inadecuada, fallida o nula, que pone al personal y especialmente a gestores, ante una variedad de problemas que supera sus capacidades de gestión y de resolución de problemas. Esta situación hace que un error lleve a otro, produciéndose una cadena creciente, una escalada de problemas de gestión, debido al cansancio, fatiga y desorientación que supone la tensión de la situación.

Lo anterior es lo que se llama escalada y romperla requiere una alta capacidad de superar el estrés físico y mental que supone un rescate, hundimiento o salvamento parcial del proyecto.

3.2.4. Razón de la gestión de proyectos

Se ha dicho que la gestión de proyectos es una manera de hacer frente a problemas y retos. También hemos añadido los estados de un proyecto que presenta problemas de gestión.

Ahora se presentan razones más concretas que justifican la gestión de proyectos en un proyecto en general y en un proyecto de base tecnológica. Ellas son:

- Actuación predictiva y,

- Recuperación.

3.2.4.1. Actuación predictiva

Para varios autores, una forma de actuar predictivamente en los problemas de gestión, es anticiparse a ellos con una completa y adecuada gestión de proyectos, la cual puede medirse si con la gestión se garantizan alcanzar los siguientes Factores Críticos de Éxito (planteados por Jurison):

Objetivos claramente definidos. Apoyo claro y total de la dirección. Presupuesto adecuado y realista. Programa coherente, racional y realista. Participación y confianza real del cliente y usuarios. Buen liderazgo del proyecto. Revisiones continuas, constructivas y positivas del proyecto. Gestión y control eficiente y eficaz del cambio. Buenas comunicaciones entre integrantes del proyecto. Anticiparse y solucionar los problemas que surjan con una gestión de contingencias.

3.2.4.2. Recuperación

Otros autores señalan que la gestión de proyectos permite determinar el momento y las acciones de recuperación de un proyecto, igualmente de que estas acciones se lleven delante de manera adecuada. En este caso se habla de una de-escalación y/o la convocación de un caballero blanco.

a. De-escalar

En una de-escalación se toman acciones que permitan superar los diversos problemas de gestión ante una escalada. Para Ribera recuperarse de una escalada puede ser:

- Recortar la envergadura del proyecto;

- Aumentar la productividad mediante mejoras a corto plazo; y/o,

- Asumir que el proyecto no terminará a tiempo, atrasar el plan y adoptar medidas de control de daños.

Lo que para Glass se traduce en tomar acciones en el siguiente orden de preferencia:

- Extender las fechas;

- Usar mejores procedimientos de gestión;

- Más personal;

- Más fondos;

- Reducción en alcance del proyecto; -Mejores metodologías de desarrollo;

- Cambiar tecnología; y,

- Abandonar el proyecto.

Acciones que, para Montealegre y Keil, no tendrían ningún efecto si no se apela a la colaboración y cooperación de los participantes involucrados en el proyecto o, sencillamente, des-institucionalizar el proyecto, dejando la de-escalación como un problema interno de gestión a superar internamente.

b. El caballero blanco

Una forma posible de superar los problemas de gestión es contratar a un experto en salvar proyectos, aquella persona milagrosa que viene a salvar todo mal funcionamiento y a intentar recuperar el proyecto: el caballero blanco (knight white). En este tipo de solución debe considerarse la asesoría y la consultoría en proyectos como un medio válido de conseguir algún caballero blanco.

3.3. Herramientas y técnicas de gestión Para completar este capítulo de gestión de proyectos no se deben olvidar una serie de herramientas y técnicas de gestión. Estas herramientas y técnicas se presentan a continuación vinculadas a los distintos grupos de procesos y son de aplicabilidad a un solo grupo. Igualmente, muchas de ellas se encuentra soportadas por diversas herramientas informáticas.

3.3.1. Iniciación

La iniciación es el proceso de reconocimiento formal que va a desarrollar y construir de forma material y tangible, una solución de negocio compuesta de componentes humanos, de hardware y software. El compromiso aborda el desarrollo de un nuevo proyecto o de un proyecto ya existente que se va a continuar en la siguiente fase.

Este comienzo formal conecta el proyecto con las operaciones en curso de la organización ejecutora. En algunas organizaciones, un proyecto no está formalmente iniciado hasta tener completo un estudio de viabilidad, un plan preliminar o alguna forma equivalente de análisis.

Esto involucra trabajar con el cliente para identificar las entidades clave en la organización para luego ser entrevistados.

En particular, algunos tipos de proyectos, especialmente aquellos de servicio interno y los de desarrollo de nuevos productos (de ingeniería), inician informalmente y se les realiza una pequeña parte del trabajo para asegurar los requisitos necesarios para el comienzo formal del proyecto.

3.3.1.1. Motivaciones del proyecto

En la iniciación es importante determinar con claridad el motivo por el cual el proyecto se inicia, el cual puede deberse a alguna o varias de las siguientes causas:

Una demanda del mercado (por ejemplo, una compañía petrolífera comienza un proyecto para construir una nueva refinería en respuesta a la continua escasez de gasolina).

Una necesidad de negocio (por ejemplo, una compañía de formación comienza un proyecto para crear un nuevo curso y aumentar sus ingresos).

La demanda de un cliente (por ejemplo, un suministrador eléctrico comienza un proyecto para construir una nueva subestación para abastecer a un nuevo parque industrial).

Un avance tecnológico (por ejemplo, una empresa electrónica comienza un nuevo proyecto para desarrollar un videojuego, después de la generalización del videocassette).

Una necesidad legal (por ejemplo, un fabricante de pinturas comienza un proyecto para fijar las directrices del manejo de materiales tóxicos).

Estas causas también pueden llamarse problemas, oportunidades o requerimientos del negocio. Lo fundamental de todos estos términos es que la dirección suele tener que tomar una decisión sobre cómo responder a ellos.

3.3.1.2. Selección del gestor del proyecto

El gestor del proyecto es habitualmente seleccionado al final de la conceptualización del proyecto, una vez aprobado. El gestor del proyecto debe ser una persona responsable a fin de dirigir, gestionar y administrar todo el proyecto.

Su responsabilidad central es coordinar todas las actividades para satisfacer los objetivos del proyecto en tiempo y presupuesto. Su rol es diferente de un líder técnico o un desarrollador, cuyas responsabilidades se relacionan con la integridad técnica del producto.

Entre sus diversas responsabilidades se puede destacar:

- ser el canal de comunicación entre el proyecto y la dirección;

- comunicar a los usuarios;

- planificar y programar;

- coordinar actividades y tareas;

- controlar el presupuesto, programa, riesgo y calidad;

- gestionar el personal; y,

- presentar a la dirección los documentos, entregables, informes de rendimiento y actas de constitución y aceptación.

La tarea del gestor es dar visibilidad y gestionar compromisos. Encontrar una persona para esta tarea no es sencillo, pues pocas personas cumplen con todas las cualificaciones para proyectos complejos, menos aún que tenga experiencia y esté disponible. Por este motivo, muchas empresas crean una Oficina de Proyectos para gestionar mejor los proyectos y crear un pool de futuros gestores.

Los gestores efectivos deberían tener habilidades de: comunicación, organización, construcción de equipo, liderazgo, negociación, actuación por objetivos, capacidad de trabajo bajo presión y competencia técnica.

Se recalca que la competencia técnica es útil y sirve bastante, pero habilidades de gestión e interpersonales son más importantes para un gestor de proyectos, de hecho, tener 'roce' en el trato de personas, puede ser determinante al momento de escoger el gestor de un proyecto, más que sus cualificaciones y experiencia técnica.

Los gestores exitosos son generalistas, no especialistas técnicos. Aún más, en muchas ocasiones provienen de muchas áreas de la organización y no necesariamente del mundo de la informática.

3.3.2. Planificación

La planificación requiere un fuerte esfuerzo de estimación para preparar las acciones conducentes a conseguir el producto y cumplir con los objetivos, y de selección de personal para cumplir con las tareas y actividades definidas. Todo esto da lugar a un informe de alcance y al plan del proyecto.

Esta es una etapa de comprensión del proyecto que implica:

Entrevistar directivos para conseguir comprender el modelo de negocios, la situación de mercado actual los objetivos y metas de negocio e intenciones iniciales.

Revisar procesos de negocios claves y la infraestructura que les soporta. Revisar y analizar la situación actual frente al potencial uso de entrar en Internet (presencia de

un sitio web con respecto a la visibilidad actual, efectividad como medio de comunicación, facilidad de uso/navegación, desempeño completo, solidez de la arquitectura técnica, etc.).

Revisar y analizar el actual uso de redes informáticas para promover la comunicación interna y compartir datos.

Revisar políticas y procedimientos establecidos en los procesos operacionales asociados o con relación a los potenciales objetivos.

Todos estos elementos han de aparecer detallados en el Plan del Proyecto y en el Informe del Alcance.

3.3.2.1. Estimación 3.3.2.1.1. Estimación del trabajo

La definición del alcance comprende la subdivisión de las principales entregas del proyecto (identificadas en el informe del alcance) en componentes más pequeños y manejables con el fin de:

Mejorar la precisión de las estimaciones de costes, programa y recursos. Definir las bases para la medida y control de la realización del proyecto. Facilitar una clara asignación de responsabilidades.

La adecuada definición del alcance del proyecto es crítica para el éxito de un proyecto. Cuando hay una pobre definición del alcance, se puede esperar que se eleven los costes finales del proyecto debido a los inevitables cambios que interrumpen el ritmo del proyecto, causan repeticiones de tareas, aumentan los plazos de entrega, y disminuyen la productividad y las expectativas respecto de la obtención de los objetivos.

Una herramienta útil para estimar el trabajo a realizar lo constituye la Estructura de Descomposición del Proyecto (WorkBreakdown Structure, WBS).

a. WBS

La base de las actividades de planificación lo constituye el WBS. Un WBS descompone el proyecto en una estructura jerárquica bien definida de tareas o actividades gestionables, cuya representación puede ser una tabla o un árbol.

El número de niveles depende principalmente del tamaño del proyecto y las preferencias del gestor del proyecto. Es importante que se expliquen todas las actividades necesarias para completar el proyecto y que sean asignadas a una entidad (persona u organización) de manera clara y precisa, anulando toda posibilidad de ambigüedad.

Un WBS es una agrupación de elementos del proyecto orientada a las entregas del mismo que organiza y define su alcance completo: trabajos que no estén en la EDP quedan fuera del alcance del proyecto. Así, el WBS provee un marco fundacional para programar, presupuestar y controlar el proyecto y comienza una vez definido, el proceso de estimación.

La descomposición comprende la subdivisión de las principales entregas del proyecto en otros componentes más pequeños y manejables de forma que las entregas sean definidas con suficiente detalle para responder a las futuras actividades de] proyecto. La descomposición comprende los siguientes pasos principales:

1. Identificar los principales elementos del proyecto. En general, los principales elementos serán las entregas del proyecto y su dirección. Sin embargo, siempre se deben definir los principales elementos en función de cómo el proyecto será realmente dirigido. Por

ejemplo, las fases del ciclo de vida pueden constituir un primer nivel de descomposición, con un segundo nivel determinado por las entregas (figura 3.6) o por algún otro criterio organizativo (figura 3.7).

Esta EDP es únicamente ilustrativa. No trata de representar el alcance completo del proyecto de cualquier proyecto específico, ni supone que sea este el único modo de organizar la EDP para este tipo de proyecto.

Figura 3.6: WBS de una estructura de descomposición por fases.

Esta EDP es únicamente ilustrativa. No trata de representar el alcance completo del proyecto de cualquier proyecto específico, ni supone que sea este el único modo de organizar la EDP para este tipo de proyecto.

Figura 3.7: WBS de una planta de tratamiento de aguas residuales.

2. Decidir si se pueden realizar las adecuadas estimaciones de duración y costes al nivel de detalle para cada elemento. El significado de adecuadas puede variar en el curso del proyecto (la descomposición de una entrega que se ha de producir en un tiempo lejano puede que no sea posible). Para cada elemento, hay que pasar al Punto 4 si se ha logrado el detalle adecuado y al Punto 3 si no es así (esto quiere decir que los diferentes elementos pueden tener diferentes niveles de descomposición).

3. Identificar los elementos constituyentes de una entrega. Los elementos constituyentes se deberían describir en términos de resultados verificables y tangibles, para facilitar la medida de la realización. Los elementos componentes- del proyecto deben definirse, como se hace con los elementos principales, en la misma forma como se terminará realmente el trabajo del proyecto. Resultados tangibles y verificables pueden incluir tanto servicios como productos (por ejemplo, el informe de situación se puede describir como informe de situación semanal; para un elemento manufacturado, los elementos constituyentes podrían incluir varios componentes individuales más el montaje final). Repetir el punto 2 para cada elemento constituyente.

4. Verificar si se ha realizado la descomposición correcta:

- ¿Son necesarios y suficientes los elementos en el nivel inferior para completar el elemento descompuesto? Si no es así, se deben modificar los elementos constituyentes (añadir, eliminar o redefinir).

- ¿Está cada elemento clara y completamente definido? Si no es así, se deben revisar o ampliar las descripciones.

- ¿Se puede programar correctamente cada elemento?, ¿presupuestar?, ¿asignar a una unidad específica de la organización (por ejemplo, un departamento, equipo o persona) que aceptará la responsabilidad de concluir satisfactoriamente el elemento? Si no es así, se requieren revisiones que proporcionen un adecuado control.

b. Work packages

Cada nivel descendente representa una descripción cada vez más detallada de los elementos del proyecto. Cada elemento en la EDP es asignado a un único identificador; el conjunto de estos identificadores a menudo se denomina código de cuentas. Los elementos de los niveles más bajos de la EDP se suelen denominar paquetes de trabajo (work packages). Estos paquetes de trabajo pueden ser descompuestos aún más.

Las descripciones de los elementos de trabajo se reúnen frecuentemente en un diccionario de la WBS. Este diccionario incluye generalmente descripciones de paquetes de trabajo así como otra información de planificación como fechas del programa, presupuestos de costes y asignaciones de personal.

c. Otros tipos de WBS

No se debe confundir una WBS con otros tipos de estructuras de descomposición utilizadas para presentar información del proyecto.

Otras estructuras comúnmente utilizadas en algunas áreas de aplicación son:

Estructura de descomposición contractual, que se utiliza para definir el nivel de información que el proveedor suministrará al comprador. La WBS contractual tiene normalmente menos detalle que una WBS utilizada por el proveedor para dirigir su propio trabajo.

Estructura de descomposición organizativa, que muestra qué elementos de trabajo han sido asignados a qué unidades de la organización. Un organigrama.

Estructura de descomposición de recursos, que es una variación de la estructura de descomposición organizativa, y se utiliza normalmente cuando se asignan los elementos de trabajo a personas individuales.

Lista de materiales, que representa una relación jerárquica de los montajes, submontajes y componentes necesarios para fabricar un producto manufacturado.

Estructura de descomposición de tareas, que es prácticamente lo mismo que una WBS correctamente realizada. La estructura de descomposición de tareas se utiliza ampliamente en áreas en las que el término WBS es incorrectamente utilizado para referirse a una lista de materiales.

3.3.2.1.2. Estimación de coste y programación

Los enfoques esenciales para estimar el coste y la programación necesaria de un proyecto son dos.

a. Enfoque arriba-a-abajo y abajo-a-arriba

1. Enfoque arriba-a-abajo. Esta es una estimación por analogías que significa utilizar el coste real de anteriores proyectos similares como base para la estimación del coste del proyecto actual. Se usa frecuentemente para estimar los costes totales del proyecto cuando la información detallada sobre el proyecto es escasa (por ejemplo, en las fases iniciales de un proyecto). La estimación por analogías es una forma de juicio experto. La estimación por analogías es generalmente más barata que otras técnicas, pero también suele ser menos precisa. Es más fiable, cuando los proyectos anteriores son realmente similares y no sólo en apariencia, y las personas o grupos de personas que realizan las estimaciones tienen la experiencia necesaria.

2. Estimación abajo-a-arriba. Esta técnica comprende la estimación de costes de tareas individuales: sumando las estimaciones individuales se consigue el coste total del proyecto. El coste y la precisión de la estimación de abajo-a-arriba depende del tamaño de las tareas individuales: cuanto más pequeñas son las tareas tanto más se incrementa el coste como la precisión. El equipo de dirección del proyecto debe sopesar si la precisión adicional justifica el mayor coste.

Ambos métodos o enfoques se usan en conjunto y se requieren varias iteraciones hasta alcanzar resultados que puedan considerarse satisfactorios.

b. GANTT, PERT y CPM

Conseguir una buena programación es un reto, no obstante es razonable y alcanzable. Ella debe tener el compromiso del equipo al completo, para lo cual se recomienda que cada miembro o grupo del equipo determine las tareas a realizar y el tiempo para cumplirlas. La programación para grandes proyectos usualmente comprende un programa master, mostrando principales actividades e hitos y dejando el detalle en sub-programas.

La forma más común de presentar un programa es una carta GANTT que muestra las actividades contra una escala de tiempo horizontal (figura 3.8). Las cartas GANTT son herramientas populares para comprender y facilitar la creación y revisión del programa. Esto da lugar a una red de programa que muestra las relaciones internas.

Figura 3.8: Carta GANTT1.

Estas relaciones se muestran habitualmente como redes PERT (Program Evaluation Review Technique, figura 3.9) y CPM (critical path method). Ambos métodos son bastante similares en el uso de flujogramas, grafos o redes de dependencia.

Figura 3.9: PERT2.

Otra ventaja de las redes de programación (schedule networks) es que pueden usarse para identificar y seguir el camino crítico del proyecto. Todas estas técnicas de representación, son instancias de un diagrama de precedencias.

c. Diagramas de representación

Método del diagrama de precedencias. Este es un método de elaborar un diagrama en red del proyecto usando nodos, que representan las actividades, conectados mediante flechas, que muestran las dependencias (figura 3.10). Esta técnica se denomina también actividades en los nodos y es el método utilizado en la mayoría de los programas de software para la gestión de proyectos. El método del diagrama de precedencias se puede realizar manualmente o mediante ordenador.

Figura 3.10: Diagrama de precedencias.

El método incluye cuatro tipos de dependencias o relaciones de precedencia:

Terminación-a-comienzo: la actividad inicial debe terminar antes de que la actividad final pueda comenzar;

Terminación-a-terminación: la actividad inicial debe terminar antes de que la actividad final pueda terminar;

Comienzo-a-comienzo: la actividad inicial debe comenzar antes de que la actividad final pueda comenzar; y,

Comienzo-a-terminación: la actividad inicial debe comenzar antes de que la actividad final pueda terminar.

En el método del diagrama de precedencias, el tipo más habitual de relación lógica es el terminación-a-comienzo. Las relaciones comienzo-a-terminación se utilizan rara vez y cuando se utilizan, es únicamente por ingenieros de programación profesionales. Usar las relaciones comienzo-a-comienzo, terminación-a-terminación o comienzo-a-terminación con el software para gestión de proyectos puede producir resultados no esperados, ya que estos tipos de relaciones no han sido suficientemente probados. Otros métodos similares son:

Método del diagrama de flechas. Este es un método de elaboración de un diagrama en red del proyecto que utiliza flechas para representar las actividades y las conecta a nodos que muestran las dependencias (figura 3.11). Esta técnica también se denomina actividades en las flechas y, aunque menos corriente que el método del diagrama de precedencias, es la técnica que se elige en algunas áreas de aplicación. El método del diagrama de flechas utiliza solamente dependencias terminación-a-comienzo y puede necesitar el uso de actividades ficticias para definir correctamente todas las relaciones lógicas. El método del diagrama de flechas se puede realizar manualmente o mediante ordenador.

Figura 3.11: Diagrama de flechas.

Métodos de diagramas condicionales. Las técnicas de diagramas tales como los modelos GERT (Técnica de Revisión y Evaluación Gráfica) y sistemas dinámicos, permiten tratar actividades no secuenciales tales como lazos (por ejemplo una prueba que se debe repetir más de una vez) o condicionadas (por ejemplo, una actualización del diseño que sea solamente necesaria si la inspección detecta errores). Ni el método del diagrama de precedencias ni el método del diagrama de flechas permiten tratar lazos o actividades condicionadas.

Redes patrón. Se pueden utilizar redes normalizadas para facilitar la preparación de los diagramas en red del proyecto. Pueden incluir un proyecto completo o solamente una parte de él. A las partes de una red se las suele denominar subredes o fragmentos de redes. Las subredes son especialmente útiles cuando un proyecto incluye varias partes idénticas o casi idénticas, como las plantas de un edificio alto de oficinas, los ensayos clínicos en un proyecto de investigación farmacéutica, o los módulos del programa en un proyecto de software.

d. Camino crítico

El camino crítico del proyecto es el conjunto de actividades que toma mayor tiempo completarlo. En esencia, el camino crítico determina cuándo el proyecto terminará. Las tareas en el camino crítico requieren atención especial de la gestión debido a que no dejan espacios libres u holguras en la programación, de hecho no puede atrasarse bajo ningún concepto.

Debe hacerse notar que un proyecto puede tener muchos caminos críticos y que las variaciones en la duración de las tareas puede ir de un camino a otro. El camino crítico resulta también de utilidad para identificar programaciones de riesgo.

El camino crítico es una técnica matemática que comprende el cálculo teórico para el comienzo y terminación, con mayor antelación y mayor retraso, de todas las actividades del proyecto sin tener en cuenta las limitaciones del conjunto de recursos. Las fechas resultantes no son el programa, sino que indican los períodos de tiempo dentro de los que la actividad debe ser programada, dadas las limitaciones de los recursos y otras restricciones conocidas.

En esencia, el Método del Camino Crítico es un método de optimización que calcula una fecha de comienzo y terminación -la de mayor adelanto y la de mayor retraso para cada actividad, basándose en la secuencia de relaciones lógicas ya especificada y en la simple estimación de duraciones. El objetivo del método del camino crítico es calcular el margen con el fin de determinar qué actividades tienen la menor flexibilidad de programación. Los algoritmos del método del camino crítico se utilizan a menudo en otros tipos de análisis matemático.

Algunas variaciones ocurren respecto de un GERT y un PERT.

GERT. Permite el tratamiento probabilístico tanto de las relaciones lógicas como de las estimaciones de la duración de las actividades (por ejemplo, algunas actividades pueden no desarrollarse, otras se pueden desarrollar solamente en parte, y otras pueden desarrollarse más de una vez).

PERT. Utiliza las relaciones lógicas secuenciales y una media ponderada de la estimación de duraciones para calcular la duración del proyecto. Aunque hay diferencias superficiales, el PERT difiere del GERT principalmente en que utiliza el concepto de distribución (valor esperado) en lugar de la estimación más probable originalmente utilizada en este último (figura 3.12). El PERT en sí mismo apenas se usa hoy en día, aunque las estimaciones realizadas para el PERT se usan frecuentemente en los cálculos del CPM.

Figura 3.12: Cálculo de la duración de un proyecto mediante PERT.

Un caso especial de análisis matemático es la reducción de plazos, que busca la manera de reducir el programa del proyecto sin alterar su alcance (por ejemplo, lograr las fechas impuestas u otros objetivos del programa).

La reducción de plazos incluye técnicas tales como:

Crashing. Es una técnica en la que se analizan el coste y los cambios del programa para determinar cómo obtener la mayor reducción de plazos posible con el menor incremento de costes. El crashing no siempre produce una alternativa viable y da lugar, frecuentemente, a un incremento de los costes.

Camino acelerado. Consiste en realizar actividades en paralelo que normalmente se realizarían en serie (por ejemplo, empezar a codificar en un programa de software antes de completar su diseño, comenzar a construir las cimentaciones para una refinería de petróleo antes dé realizar el 25 por ciento de la labor de ingeniería, o empezar a comprar hardware sin tener definida la infraestructura e-business). Normalmente esta técnica conduce a repetir tareas y frecuentemente incrementa el riesgo.

e. Programa del proyecto

El programa del proyecto3 incluye al menos las fechas planeadas de comienzo y las previstas de terminación para cada actividad.

El programa del proyecto se puede presentar en forma de resumen (el "programa básico") o en detalle. Aunque puede presentarse en forma de tabla, es más frecuente presentarlo gráficamente, utilizando uno o más de los siguientes formatos:

Diagramas en red del proyecto con información añadida sobre fechas. Estos diagramas normalmente muestran la lógica del proyecto y las actividades del camino crítico del proyecto.

Diagramas de barras, también llamados diagramas de GANTT. Muestran las fechas -de comienzo y terminación de las actividades así como las duraciones esperadas, pero normalmente no muestran las dependencias. Son relativamente fáciles de interpretar y se usan frecuentemente en los informes de dirección.

Diagramas de hitos. Son similares a los diagramas de barras (figura 3.13), pero identifican el comienzo o la terminación programados de las principales entregas y las conexiones externas clave.

Figura 3.13: Diagrama de hitos.

Red dimensionada. Es una mezcla de diagramas en red del proyecto y de diagramas de GANTT en la que se muestra la lógica del proyecto, la duración de las actividades y la información del programa (figura 3.14).

Figura 3.14: Red dimensionada.

3.3.2.1.3. Estimación de coste y presupuesto

Otras tareas de estimación son las de coste y presupuesto. En un proyecto, el coste del presupuesto puede medirse en función de las horas de esfuerzo dedicadas a las tareas. La

estimación es un análisis histórico ajustado a las capacidades y habilidades de cada miembro.

La estimación cubre todas las actividades del WBS, incluyendo la propia gestión del proyecto y sus funciones de apoyo, como el aseguramiento de la calidad y el seguimiento de los planes de riesgo, por ejemplo. La estimación debe incluir costes directos no labores, y los costes indirectos o de overhead. Los costes directos se calculan de las horas-hombre multiplicadas por su valor de mercado o acordado. Los costes directos no laborales incluyen outsourcing, consultores, viajes, cenas, etc.

El presupuesto total del proyecto es determinado agregando todos los costes directos e indirectos. Es buena práctica incluir salvaguardas de gestión para contingencias y problemas no anticipados. Una reserva del 5 al 10% no es extraña y puede ser más elevada en proyectos mayores o de alto riesgo.

El presupuesto debe asignarse a individuos u organizaciones siguiendo el WBS. El presupuesto marca la línea base (baseline) sobre la cual medir el desempeño del proyecto. Una herramienta adecuada es la curva que muestra los costes acumulados, la cual provee la representación gráfica del presupuesto en función del tiempo según la programación del proyecto.

Figura 3.15: Curva de coste acumulado.

3.3.2.1.4. Selección de los miembros del equipo

La ejecución de un proyecto es como los deportes, la diferencia entre el miembro más productivo y el menos productivo puede ser amplia; no obstante se deberían seleccionar los mejores. Por este motivo es importante tener en consideración que las habilidades a buscar no son solamente técnicas, sino habilidades para solucionar problemas e interpersonales. Aún más, debe recordarse siempre que un buen miembro tiene una alta auto-estima y un fuerte compromiso hacia el éxito de un proyecto.

Cualquier test a realizar debe crear equipos con una mezcla equilibrada de habilidades y personalidades. Muchos programadores o personas del ámbito técnico son personas introvertidas y pensativas que basan sus decisiones en hechos en lugar de sentimientos y valores personales. Ellos tienden a encontrar dificultades en construir relaciones y observar el proyecto desde el punto de vista del usuario. Por ello, formar un equipo equilibrado no es una labor sencilla.

1 Fuente: Barceló. M. La gestió d'un projecte informàtic. UOC. Pp. 15-16. 2 Fuente: Barceló. M. La gestió d'un projecte informàtic. UOC. pp. 9-10. 3 El programa del proyecto se considera preliminar hasta que la asignación de recursos ha sido confirmada. Esto normalmente ocurre antes de la terminación del desarrollo del plan del proyecto.

3.3.2.2. Plan de proyecto

La planificación culmina con el plan del proyecto. Es un documento que informa a la gestión, a los miembros del equipo y al cliente. Es como un mapa que sirve para guiar al proyecto y sus involucrados.

El plan del proyecto es un documento formal y aprobado que se utiliza para dirigir y controlar la ejecución del proyecto. Debería ser distribuido según defina el plan de Gestión de Comunicaciones (por ejemplo, la dirección de la organización ejecutora puede necesitar un plan general con pocos detalles, mientras que un contratista puede necesitar muchos detalles de un solo tema). En algunas áreas de aplicación, se usa el término plan integrado del proyecto para referirse a este documento.

Debe establecerse una clara distinción entre el plan del proyecto y las bases para medir la realización del proyecto. El plan del proyecto es un documento o conjunto de documentos que debería esperarse que cambien a medida que haya más información disponible sobre el proyecto. Las bases para la evaluación de la realización del proyecto representa un control de dirección que normalmente sólo cambiará intermitentemente y en estos casos, los cambios serán realizados únicamente como respuesta a un cambio autorizado del alcance del proyecto. En este documento se especifican aspectos de desarrollo, los subproductos a entregar, requerimientos de recursos, programación, responsabilidades organizacionales y presupuestos y el proceso de gestión. Además, incluye factores de riesgo y estrategias de gestión del riesgo y describe de que manera se gestiona y asegura la calidad. Establece el coste y las bases de la programación para gestionar y controlar el proyecto. Además en sí mismo es parte efectiva del sistema de control del proyecto.

Hay muchas maneras de organizar y presentar el plan del proyecto, pero normalmente incluye lo siguiente (estos puntos se describirán con más detalle más adelante):

Justificación del proyecto. Descripción de los puntos de vista o estrategia de la dirección del proyecto (un resumen de los

planes de dirección para cada una de las otras áreas). Establecimiento del alcance, que incluye las entregas y objetivos del proyecto. WBS al nivel al que se realizará el control. Estimación de costes, fechas programadas de inicio de actividades y asignación de

responsabilidades al nivel de la EDP, en el que será ejercido el control. Bases para la evaluación de la realización del proyecto en cuanto a programa y costes. Principales hitos y fechas objetivo para cada uno. Personal requerido o clave. Riesgos clave, incluyendo las restricciones y supuestos y las respuestas previstas para cada

uno. Planes auxiliares de dirección, incluyendo el plan de gestión del alcance del proyecto, el plan

de dirección del programa, etc.

Temas abiertos y decisiones pendientes.

Se deberían incluir otros resultados de la planificación del proyecto en el plan formal, basándose en las necesidades de cada proyecto en particular. Por ejemplo, el plan del proyecto para un gran proyecto incluirá, normalmente, un organigrama del proyecto. Para probar la adecuación del plan, el gestor del proyecto debe preguntarse:

¿El plan permite gestionar el proyecto de forma adecuada? ¿El plan provee información suficiente para que los miembros del equipo planifiquen y

ejecuten su trabajo? ¿Se cuenta con el compromiso de la dirección y del equipo del proyecto?

3.3.2.3. Informe de alcance

El Informe de Alcance constituye una base documentada para la adopción de las futuras decisiones del proyecto y para confirmar o desarrollar entre las entidades involucradas en el proyecto aportando un entendimiento común del alcance del mismo. Según progresa el proyecto, puede ser necesario revisar o depurar el informe, para reflejar los cambios en el mismo. Éste debe incluir, bien directamente o por referencia a otros documentos, lo siguiente:

Justificación del proyecto: la necesidad del negocio que debe ser resuelta por el proyecto. La justificación del proyecto constituye la base para la evaluación de futuros compromisos.

Producto del proyecto: un breve resumen de la descripción del producto. Entregas del proyecto: una lista a modo de resumen de los subproductos cuya completa y

satisfactoria entrega marca la finalización del proyecto. Objetivos del proyecto: los criterios cuantificables que deben cumplirse para que el proyecto

se considere un éxito. Los objetivos del proyecto deben incluir, al menos, medidas de costes, programa y calidad. Los objetivos del proyecto debe tener un atributo (por ejemplo, coste), un patrón o unidad fundamental (por ejemplo, dólares USA) y un valor absoluto o relativo (por ejemplo, menos de 1,5 millones). Los objetivos no cuantificables (por ejemplo, la satisfacción del cliente) constituyen un riesgo elevado.

En algunas áreas de aplicación, las entregas del proyecto son llamadas objetivos del proyecto mientras que los objetivos del proyecto son llamados factores críticos de éxito.

3.3.3. Control y seguimiento

El control es una etapa de valoración del trabajo realizado que pretende aprovechar buenas prácticas y analizar las debilidades del proyecto tomando de referencia los datos recogidos durante el seguimiento.

3.3.3.1. Aseguramiento de la calidad

El aseguramiento de la calidad (Quality Assurance, QA) certifica que el producto cumple con los requerimientos y provee la funcionalidad y calidad deseada.

La calidad, asi como los requerimientos de desempeño técnico, deben ser especificada en términos cuantitativos claramente comprensibles por el cliente y los miembros del equipo. Además, mientras el equipo se compromete a construir la calidad en el producto, una práctica frecuente es contar con alguien dedicado y separado del equipo cumpliendo funciones de asegurador de calidad. El principal propósito del aseguramiento de la calidad es detectar errores y corregirles rápidamente. La detección y corrección temprana puede resultar en beneficios de coste y tiempo significativos.

De hecho, el coste de corregir errores en la etapa de diseño es un 10% de corregirle en la etapa de prueba.

Las herramientas básicas para el aseguramiento de la calidad son las revisiones técnicas. Las revisiones técnicas son efectivas ante la aparición temprana de diferentes tipos de errores a probar. Las prácticas más comunes de aseguramiento de calidad son los walkthroughs, las inspecciones y las pruebas.

Ambos tipos de revisiones son efectivas para la detección temprana de errores en requerimientos, interfaces, diseño, codificación o manufactura, y documentación. El seguimiento del proceso de calidad, requiere métricas precisas.

Walkthroughs

Un walkthrough son reuniones informales en las cuales los miembros del equipo revisan el diseño o código para identificar mejoras y problemas.

Inspección

Las inspecciones son revisiones más formales donde revisores usan listas de chequeo (checklists) para estimular la revisión y recurren a registros de control y retroalimentación sistemática para mejorar el proceso de desarrollo.

Prueba

La prueba es el medio más común de asegurar la calidad. Es el ejercicio sistemático de buscar y detectar defectos donde fueron hallados anteriormente. Conducidos al nivel de unidad y de sistema, sirven para verificar la funcionalidad y calidad del sistema.

3.3.3.2. Tiempo y coste

a. Proceso de control del proyecto

El propósito del control del proyecto es:

- Mantener el proyecto en curso y cercano al plan de trabajo;

- Identificar problemas antes de que ocurran e

- Implementar planes de recuperación antes que los daños sean irreparables.

El proceso involucra comparar el progreso con el plan y tomar acciones correctivas conforme existan desviaciones que afecten el desempeño y/o el plan; y proveer retroalimentación (figura 3.16).

Figura 3.16: Control del proyecto.

Para un control a tiempo y efectivo, el gestor del proyecto debe tener completa visibilidad del avance del proyecto. Para ello, se debe efectuar un monitoreo y seguimiento sistemático. El grado de formalidad y frecuencia de monitoreo depende del tipo de proyecto, aunque siempre debe enfocarse en el coste, programación y desempeño técnico.

b. Control del coste y del programa

El seguimiento del coste y de la programación involucra comparar el estado actual contra lo presupuestado en cuanto coste, tiempo y etapas.

Desviaciones significativas del plan requieren atención prioritaria del gestor del proyecto para tomar una acción correctiva a tiempo. Conocer la desviación no es suficiente, hay que identificar la causa del problema. Si la desviación del plan es grande, se debe decidir si se replanifica.

Para tener visibilidad de estas decisiones, el coste y la programación son analizados de forma integrada. Estar dentro del presupuesto no es suficiente si las tareas no se completan a tiempo. Similarmente, completar tareas de acuerdo al programa no basta si los costes "se han disparado". En este análisis, disponer de la WBS provee la base fundamental para comparar coste y programa contra el plan.

c. Valor ganado

Aunque las cartas GANTT y los informes de acumulación de reportes proveen indicadores útiles del estado del proyecto, presentan limitaciones. La limitación primaria es que son complejos y difíciles de analizar, particularmente para grandes proyectos con muchas tareas.

Esta complejidad puede conducir a una percepción distorsionada del estado del proyecto. Una técnica para proveer una mejor, más holística visión del progreso del proyecto es la técnica del valor ganado (Earned Value Technique). Originalmente creada para un mejor seguimiento de proyectos gubernamentales a gran escala, es hoy en día herramienta habitual en los proyectos informáticos.

La técnica mide el valor del trabajo realizado en términos del presupuesto asignado al trabajo. Permite separar las variaciones de coste y programación en términos monetarios.

La variación en coste se debe a la variación en el precio del trabajo realizado mientras la variación en la programación se debe al trabajo realizado fuera de los tiempos programados.

El valor ganado y las variaciones son calculadas para una actividad simple, un grupo de actividades o el proyecto completo. De las variaciones de coste y programación es posible determinar indicadores de desempeño de coste y programación del proyecto.

Estos índices proveen visibilidad instantánea sobre el desempeño del proyecto. Esto ayuda al gestor del proyecto a estimar el coste para terminar y el coste actual a la fecha, basado en el desempeño a la fecha.

La técnica se basa en tres parámetros básicos:

Presupuesto planeado (planned budget): coste presupuestado de trabajo planificado (budgeted cost of work scheduled, BCWS).

Coste actual: coste actual de trabajo realizado (actual cost for work performed, ACWP). Valor ganado (earned value): Coste presupuestado de trabajo realizado (budgeted cost for

work performed, BCWP).

Variación del coste (cost variance, CV) se calcula de la siguiente manera:

CV = BCWP - ACWP

Una variante negativa indica un coste excesivo.

Variación de la programación (schedule variance, CV) se calcula de la siguiente manera:

SV = BCWP - BCWS

Una variación negativa indica que el proyecto esta fuera de programación. Ambas son expresadas en términos monetarios, pero también pueden expresarse en porcentajes de la siguiente manera:

% CV = CV / BCWP

% SV = SV / BCWP

El índice de desempeño de coste (cost performance index, CPI) está calculado como:

CPI = BCWP / ACWP

El CPI puede usarse para calcular el coste del proyecto o el coste estimado al completarlo (estimate at completion, EAC). Una fórmula simplificada para EAC es:

EAC = BAC / CPI

Donde BAC (budgeted cost at completion) es el coste básico o presupuestado para terminar el proyecto.

Similarmente, es posible calcular el índice de desempeño de la programación (schedule performance index, SPI) de la siguiente manera:

SPI = BCWP / BCWS

Por último, una versión simplificada para estimar la duración del proyecto o tiempo estimado para terminar el proyecto (estimated time to completion, ETC) se puede calcular de la siguiente manera:

ETC = OD / SPI

Donde OD es la duración original (original duration, OD).

d. Revisión

1. Encuentros de revisión. Los encuentros de revisión son instrumentos vitales en el control del proyecto. El propósito es valorizar el progreso e identificar áreas de desviación desde el plan para proponer acciones correctivas. Los mismos son el mecanismo para discutir abiertamente problemas presentes y futuros y proveer un marco de comunicación habitual, si se desea. Estos encuentros:

- Proveen visibilidad a los planes y su progreso, y crean oportunidades para obtener y reforzar compromisos con los participantes.

- Son más efectivos cuando ellos son programados a intervalos regulares (semanalmente es lo habitual) y siguiendo una agenda establecida y acordada por los involucrados.

- Deberían contar con la presencia de personas representativas de las áreas involucradas para tener respuestas adecuadas, negociar soluciones y hacer compromisos.

- Son diferentes de una revisión técnica y/o de calidad, donde se dedica especial atención a detectar y corregir problemas más que revisar el progreso.

- Son diferentes de una reunión de gestión o de dirección, donde el gestor de proyecto se reúne con un directivo o un comité de dirección, para informar del proyecto y su integración en la estrategia organizacional.

2. Informes de estado. Los informes de estado son preparados y enviados de forma regular para informar a las personas externas a la organización. Ellos deben ser cortos y oportunos.

3. Agenda del proyecto. Una agenda típica incluye:

- Detalle del progreso programado (principales hitos, programa y costes);

- Avance de actividades específicas;

- Estado de determinados ítems y/o recursos;

- Planificación futura; y,

- Estado de las áreas de alto riesgo.

4. Informe de alcance e informe de realización. Es conveniente mantener actualizado el informe del alcance con el fin de mostrar los cambios al plan del proyecto. Las nuevas versiones del informe de alcance deben ser mantenidas en la biblioteca del proyecto y los cambios y alteraciones ser gestionadas de manera adecuada e informadas a las personas pertinentes afectadas.

Asimismo, vinculados al informe de alcance, se encuentran los Informes de Realización, los cuales organizan y resumen la información reunida a lo largo del proyecto y presentar resultados de cualquier análisis. Estos informes deben proporcionar los tipos de información y nivel de detalle requerido por las distintas entidades involucradas, tal y como establece el Plan de Comunicaciones.

3.3.3.4. Recursos humanos

a. Motivación y construcción del equipo

El desarrollo y construcción del equipo es una labor cubierta por literatura de ciencias y gestión del comportamiento (comportamiento organizacional, psicología social) pero a menudo es ignorada en otras areas.

Muchos gestores de proyectos tienden a enfocar su atención en los detalles técnicos, ignorando que son personas las que diseñan y también son personas las que usarán estas aplicaciones.

Pensar así hoy en día es un gran riesgo, pues muchos proyectos fallan por mal funcionamiento del equipo y no por problemas técnicos.

La construcción del equipo es el proceso de transformar un grupo de individuos de diferentes orígenes y formaciones en un grupo cohesivo de alto desempeño, con una alta motivación y enfocados al logro de objetivos.

Es un proceso que requiere habilidades de liderazgo y una comprensión de los diversos factores organizacionales que influyen en el trabajo en equipo y en las relaciones humanas.

Así es necesario:

Compartir la visión y el objetivo. Una visión compartida es esencial para el éxito del proyecto, de hecho se le considera un factor de éxito. Estar de acuerdo en la visión y en los objetivos ayuda a mantener el equipo centrado y productivo. En estos casos, la toma de decisiones es más efectiva y se evitan debates efímeros y que sólo consumen tiempo.

Compromiso con el proyecto. El compromiso puede definirse como el sentido de lealtad y dedicación al proyecto. Miembros comprometidos desean dedicar su tiempo y energía y hacer sacrificios personales por el proyecto. La visión compartida es la base del compromiso. Sólo cuando las personas comprenden y comparten una visión del proyecto, desean comprometerse con el proyecto. Gestores efectivos, trabajan duro para construir y afianzar el compromiso. Buscan vías de crear posibilidades excitantes de conseguir un proyecto exitoso. Crean ambientes de trabajo estimulantes, generando retos de trabajo interesantes con oportunidades de crecimiento personal. Involucran a las personas en la toma de decisiones. Hacen visible el esfuerzo de cada persona informando del progreso a cada miembro. Convierten a cada miembro en un activo del proyecto.

Fuerte sentido de identidad. Los miembros de equipos efectivos son aquellos que se sienten que son especiales, diferentes de otros. Este sentimiento de identidad el gestor de proyectos debe reforzarlo por todos sus medios a mano. Una práctica común es usar símbolos visibles para mostrar la identidad (distintivos en la ropa, las tazas de café, etc.) Probablemente la mejor manera es crear un sitio donde los miembros compartan su trabajo. Hitos de celebración para comunicar y compartir experiencias, son momentos para reforzar el espíritu. Gestores exitosos crear y definen culturas en sus proyectos, distintas del resto de la organización.

Confianza mutua. Un equipo efectivo requiere colaboración entre los miembros. La colaboración existe en climas de confianza. A mayor confianza, el equipo compartirá mayor información, informará problemas y tomará decisiones efectivas. Buenos gestores de proyecto crean y nutren una atmósfera de confianza que a su vez construye y refuerza la confidencialidad y el compromiso. La confianza solamente existe en equipos donde hay valores de honestidad y franqueza, donde las personas son tratadas con imparcialidad, respecto y dignidad.

Miembros competentes. Los gestores de proyecto efectivos reclutan personas idoneas según las competencias que requiera el proyecto; las habilidades de colaboración para el

trabajo efectivo con otras personas son tan importantes como las habilidades y destrezas técnicas. Un gestor efectivo continuamente evalúa a su equipo y siempre está dispuesto a cambiar o reasignar personas con un desempeño inadecuado. Los gestores de proyecto gestionan relaciones con el resto de la organización y remueven obstáculos. Los miembros se motivan cuando ellos saben que la dirección está comprometida con el proyecto y busca y provee los recursos necesarios. Todo esto requiere habilidades de gestión superiores a las técnicas, que incluso pueden carecer y/o desarrollar con el tiempo.

Entre las habilidades para construir un equipo, se cuenta:

- Evitar comprometer los objetivos del equipo con otros tipos de intereses personales.

- Exhibir un compromiso personal a los objetivos del equipo.

- No diluir el esfuerzo del equipo con muchas prioridades.

- Ser equitativo e imparcial con todos los miembros.

- Estar predispuesto a enfrentar y resolver problemas asociados con el desempeño inadecuado de miembros del equipo.

- Estar abierto a nuevas ideas e información proveniente de los miembros del equipo.

b. Resolución de conflictos

Los conflictos son parte de la vida diaria del proyecto. Ellos surgen desde cualquier sujeto involucrado en el proyecto, tanto puede ser de un miembro del equipo como de un cliente o promotor. De hecho, la fuente de conflictos es abundante. La más común es la competencia por los recursos escasos, las diferencias respecto de los objetivos y los medios para conseguirlos, y desacuerdos en costes, programación y tecnicismos. Por supuesto deben añadirse los conflictos que surgen de las relaciones interpersonales. Independiente de las causas, todo conflicto debe tratarse, identificando sus motivos y orígenes, comprender sus causas y resolverlos de manera rápida. Fallar al hacer esto puede seriamente alterar el proyecto y generar atrasos y gastos excesivos.

3.3.4. Cierre

El cierre comprende dos procesos y, según el tamaño del proyecto, el volumen de información manejado y/o el grado de desorden sostenido, el cierre puede ser tan complejo y extensivo que puede considerarse un proyecto. Además, en el proyecto cobra importancia el hecho que el cierre es una etapa de recomendación y evaluación de lo aprendido.

3.3.4.1. Cierre administrativo

El proyecto o fase, después de lograr sus objetivos o estar terminado por otras razones, requiere su cierre. El cierre administrativo consiste en la verificación y documentación de los resultados del proyecto para formalizar la aceptación del producto del proyecto por parte de los patrocinadores o clientes.

El cierre incluye la recopilación de todos los registros del proyecto, asegurando que reflejan las especificaciones finales, así como el análisis del éxito y la efectividad del proyecto y el archivo de esta información para su uso futuro. De hecho es importante aprovechar esta información para promover un aprendizaje. Esto último no puede hacerse sin una reflexión del trabajo realizado para ver cuánto se ha aprendido, qué se pudo haber aprendido, el porqué de los errores, etc. Además es importante conseguir las aprobaciones finales del trabajo realizado y del producto entregado.

Es importante hacer notar que las actividades de cierre administrativo no deben retrasarse hasta la terminación del proyecto. Cada fase del proyecto debe ser apropiadamente cerrada para asegurar que no se pierde información útil e importante.

3.3.4.2. Cierre de contratos

Es similar al cierre administrativo. Comprende la verificación del producto (¿estaba todo el trabajo realizado de forma completa, correcta y satisfactoria?) y el cierre administrativo (actualización de registros para reflejar los resultados finales y el archivo de dicha información para su disponibilidad futura).

Los términos y condiciones del contrato pueden establecer unos procedimientos específicos para el cierre del contrato. Una terminación temprana del contrato es un caso especial de cierre del contrato.

3.4. Modelos de madurez de gestión de proyectos La gestión de proyectos habitualmente se espera sea aplicada a cabalidad luego de leer un manual o sencillamente asistir a un curso. No obstante, en este sentido, desde el área de gestión de proyectos, se ha planteado que las prácticas de gestión han de usarse según las competencias que requiera un proyectista conforme madura en su experiencia en gestión de proyectos. En este sentido se han presentado en la literatura modelos llamados modelos de madurez de gestión de proyectos, cuyo fin es proveer un marco que permita reconocer qué tipo de competencia se requiere en diferentes estados de madurez en gestión de proyectos.

Un modelo de madurez de gestión de proyectos aglutina y organiza en niveles de madurez un conjunto de criterios de gestión con el fin de orientar las actuaciones de los proyectistas. Estos niveles, aparte de regular las competencias necesarias conforme el gestor de proyectos aprende y asimila, actúan en sí mismos como metas a conseguir por las organizaciones desde el punto de vista de la calidad de su gestión de proyectos.

La literatura muestra que todos estos modelos de madurez han surgido o se basan directamente en el Capability Maturity Model del Software Engineering Institute (SEI) en Estados Unidos.

A continuación se presentará el CMM para luego pasar a revisar algunos modelos de madurez en gestión de proyectos.

3.4.1. Capability Maturity Model

El CMM es un modelo de capacidad y madurez para la evaluación de procesos en una organización. Fue desarrollado inicialmente para los procesos relativos al desarrollo e implementación de software y de éste se derivan varios modelos con otros fines; como ser: ingenieria de seguridad de sistemas, recursos humanos, mantenimiento y adquisición de software y desarrollo integrado de productos, entre otros. El CMM describe las prácticas de ingeniería de software y de gestión que caracterizan a las organizaciones conforme mejora (madura) su proceso para desarrollar y mantener software.

Se añade en particular que un proceso de software se puede definir como un conjunto de actividades, métodos, prácticas, y transformaciones que las personas usan para desarrollar y mantener software y los productos asociados.

3.4.1.1. Niveles de madurez

La mencionada madurez se valoriza en función de cinco niveles.

Un nivel de madurez es una plataforma en el camino de conseguir una mejora en un proceso de software. Cada nivel de madurez considera un conjunto de objetivos de procesos que una vez satisfechos estabilizan una componente del proceso de software. A continuación se describe cada uno de los niveles de madurez del CMM.

Inicial. En este nivel el proceso de software es ad-hoc y ocasionalmente caótico. Pocos procesos son definidos y el éxito depende del esfuerzo y heroicidad de los individuos.

Repetible. En este nivel se establecen procesos de gestión de proyectos básicos para hacer seguimiento del coste, la programación y la funcionalidad.

Definido. En este nivel las actividades de gestión e ingeniería del proceso de software son estandarizadas y documentadas en uno o varios procesos de software estándar para la organización.

Gestionado. Mediciones detalladas del proceso de software y calidad del producto son registradas. En este nivel, el proceso y el producto de software son cuantitativamente comprendidos y controlados.

Optimizante. En este nivel se habilita la mejora continua del proceso.

3.4.1.2. Arquitectura por niveles

A su vez, los niveles de madurez se componen de áreas de proceso claves (Key Process Areas), que contienen prácticas clave (Key Practices) organizadas a su vez en rasgos comunes (Common Features).

Las Key Practices Areas (KPA) indican las áreas en que una organización debería concentrarse para mejorar su proceso de software.

Las Common Features (CF) son un conjunto de prácticas agrupadas dentro de un área clave o necesidad.

Las Key Practices (KP) son las actividades e infraestructura que contribuye de manera más efectiva a la implementación e institucionalización de cada área clave.

3.4.1.3. La madurez por temas

El carácter organizador del CMM da lugar a toda una serie de variaciones ligadas al desarrollo de software como un producto.

No obstante el CMM presenta una peculiaridad que requiere ser mejorada según el contexto de este trabajo. El CMM describe la madurez por niveles y plantea un camino para conseguirlas. Sin embargo, como modelo es un patrón que plantea lo que hay que medir por nivel, no distinguiendo si existen mejoras parciales. Como instrumento de medición posee un carácter excesivamente evaluativo más que formativo y, además, deja a las organizaciones sin capacidad de mejoras parciales por temas, por procesos críticos o más robustos.

SPICE es un modelo de madurez de origen europeo similar al CMM, pero con la diferencia que las mejoras de capacidad del proceso se pueden conseguir por temas o áreas. Por ejemplo, se puede alcanzar un nivel dos en documentación y un nivel tres en el uso de métricas. Esta última cualidad es considerada en muchos de los modelos de madurez de proyectos que a continuación se presentan.

3.4.1.4. Modelos de madurez

Del área de gestión de proyectos se han considerado en este estudio los siguientes modelos de madurez de proyectos, por su relevancia, impacto y presencia:

Trillium model, Project Management Assessment, Management Maturity Model, y Innovation Maturity Model.

3.4.1.5. Trillium model

El modelo Trillium es un producto efectuado y utilizado por una Organización (Bell Canadá) para dar valor al desarrollo de un producto y apoyar las capacidades de proveedores de telecomunicaciones o productos basados en tecnologías de la información existentes o

futuros. El modelo ha sido diseñado para ser aplicado a sistemas de software 'empotrados' tales como sistemas de telecomunicaciones, no obstante buena parte del modelo puede ser aplicado a otros segmentos de la industria del software como sería el área de Management Information Systems. Con respecto al CMM, el modelo Trillium, se distingue en que:

- Define roadmaps en lugar de áreas clave.

- Tiene una perspectiva orientada al producto, haciéndolo más general y de amplio uso;

- Da amplia cobertura a los aspectos que inciden o impactan en la capacidad del proceso; y,

- Se enfoca al cliente en lugar del desarrollo mismo.

Esto consigue que se definan prácticas que guían al proyectista sobre cómo conseguir lo que desea un usuario/cliente donde, en lugar de señalar determinadas metas que se deben alcanzar con ciertas prácticas de diseño, se buscan aquellas prácticas que habiliten la consecución de lo que desea el usuario.

a. Niveles de madurez

A semejanza del modelo CMM, el modelo Trillium presenta una escala de cinco niveles de madurez:

1. Nivel 1 Desestructurado. En este nivel el proceso de desarrollo es ad-hoc. Los proyectos frecuentemente no pueden satisfacer objetivos de calidad o de programación. El éxito posible se basa más en el trabajo de los individuos que en la propia estructura e infraestructura organizacional.

2. Nivel 2 Repetible y orientado al proyecto. El éxito individual del proyecto se consigue a través de una férrea planificación y control de gestión del proyecto, dando especial énfasis a los requerimientos de gestión, técnicas de estimación y configuración del cambio.

3. Nivel 3 Definido y orientado al proceso. Aquí los procesos son definidos y utilizados al nivel organizacional, no obstante se acepta que el proyecto sea adaptado a las circunstancias. Los procesos son controlados y mejorados. Se incorporan requerimientos ISO 9001, como procesos de entrenamiento y auditoría interna.

4. Nivel 4 Gestionado e integrado. La monitorización y análisis del proceso son usados como mecanismos clave en la mejora. Procesos de gestión del cambio y programas de prevención de defectos son integrados. Las herramientas CASE se integran dentro del proceso.

5. Nivel 5 Completamente integrado. Metodologías formales son extensivamente usadas. Repositorios organizacionales son usados para soportar y mantener la historia del proceso de desarrollo.

b. Arquitectura del modelo

La arquitectura de Trillium igualmente plantea una descomposición pero con una diferencia sustancial con el CMM: no se comienza la descomposición desde los niveles de madurez, sino desde ocho áreas de capacidad (Capability Áreas), cada una de las cuales contiene varias roadmaps y estos últimos a su vez contienen prácticas (Practices), usados paulatinamente por niveles de madurez (figura 3.18)1.

Figura 3.18: Arquitectura del modelo Trillium.

De esta forma, la arquitectura de Trillium se caracteriza por poseer:

Capability Areas: ocho áreas centrales de preocupación o prioritarias para el modelo Trillium, cada una de las cuales se encuentra contenida por prácticas;

Roadmaps: conjunto de prácticas relacionadas, enfocadas sobre un área o necesidad organizacional, o un elemento específico, dentro del proceso de desarrollo del producto; y,

Practices: acciones a desarrollar para conseguir una mejor capacidad del proceso, cada una de las cuales se vincula a un nivel de madurez.

La tabla 3.7 detalla y permite cuantificar la relación entre los elementos de la arquitectura del modelo2.

TRILLIUM CAPABILITY AREAS ROADMAPS

# OF PRACTICES BY LEVEL TOTAL

2 3 4 5

Organizational Process Quality

Quality Management

Business Process Engineering

10 20 5 0 35

Human Resource Development and Management

Human Resource Development and Management 9 42 1 0 52

Process

Process Definition

Technology Management Process Improvement & Engineering

Measurements

16 55 24 4 99

Management

Project Management

Subcontractor Management Customer-Supplier Relationship Requirements Management

Estimation

74 29 4 0 107

Quality Systems Quality System 14 15 2 2 33

Development practices

Development Process

Development Techniques Internal Documentation Verification & ValidationConfiguration Management Re-Use

Reliability Management

41 49 15 5 110

Development Environment Development Environment 4 6 1 1 12

Customer Support

Problem Response System

Usability Engineering Life-Cycle Cost Modelling User Documentation Customer Engineering

User Training

25 30 5 0 60

Total 193 246 57 12 508

Tabla 3.7. Arquitectura del modelo Trillium.

1 Fuente: Recurso público de Trillium, Model Description. Enlace web: http://www.sqi.gu.edu.au/trillium/t3modc3.html [Leído: 30 de octubre de 2008]. 2 Fuente: Recurso público de Trillium, Model Description. Enlace web: http://www.sqi.gu.edu.au/trillium/t3modc3.html [Leído: 30 de octubre de 2008].

3.4.1.6. Project Management Assessment

El Project Management Assessment (PMA) es una metodología holística y una herramienta de software para la mejora de procesos de gestión en un medio ambiente de gestión de proyectos. Se ofrece para dar soluciones a problemas de inflexibilidad, de tiempo, de "no saber hacer" y, de falta de una mejora incremental.

En este modelo deben integrarse prácticas genéricas (herramientas, procedimientos y estándares comunes al ámbito de gestión de proyectos tomados del PMBOK) y específicas de la propia organización, para lo cual se cuenta con un software.

El software es un producto orientado a definir y especificar prácticas genéricas tomadas del PMBOK y otras específicas de cada problema y unirlas siguiendo el esquema de prácticas que ofrece el mismo PMBOK.

3.4.1.7. Management Maturity Model

El Management Maturity Model (PMM) se orienta a mejorar prácticas de gestión de proyectos. Es un esfuerzo derivado de considerar la gestión de proyectos un proceso crítico de la misión organizacional y de competencia vital a la organización.

El modelo se ha construido a partir de encuestas a organizaciones que han llevado, obviamente, proyectos, buscando definir las prácticas de gestión que aplicaban. Según la última información disponible, el modelo se ha modificado hasta alcanzar unas 300 lecciones sobre gestión de proyectos en el ámbito corporativo.

Estas prácticas se han organizado en niveles de madurez. De estos niveles: ad-hoc, abreviado, organizado, gestionado y adaptativo; se conocen 51 preguntas que permiten saber el nivel de una organización.

3.4.1.8. Innovation Maturity Model

El Innovation Maturity Model (IMM) no es un modelo como tal, sino una propuesta para el desarrollo de productos. Es una visión sobre cinco niveles de innovación: superficial (Superficial), mejoras en rasgos (Feature Enhancements), mejoras en soluciones (Solution Enhancements), soluciones impactantes (Breakthrough Solutions) y 'rompedora' (disruptive).

3.4.2. Implantación de la madurez

Todos los modelos previos de una u otra manera buscan medir o alcanzar un determinado nivel de competencia en gestión de proyectos. Conseguir esta competencia requiere algunas precisiones de mayor detalle.

Niveles de madurez

En cuanto a detalle, se ha propuesto un modelo de madurez basado directamente en el PMBOK de ocho niveles de madurez, cuya cantidad solamente se justifica en la medida de conseguir una competencia paulatina incremental y más gradual.

A grandes rasgos, tales niveles se caracterizan por lo siguiente:

Nivel I No conocedor (non-awareness). No existe conocimiento alguno sobre gestión de proyectos.

Nivel II Inicial. Se comienzan a introducir prácticas de gestión de proyectos. Nivel III Básico. Comienzan algunas tareas de gestión como asignación de

responsabilidades, documentación, hitos y manejo formal de información. Nivel IV Repetible. Se establecen algunos procesos de gestión y se formaliza el uso de

determinadas herramientas. Ya existe algún plan de entrenamiento en gestión de proyectos y se llevan algunas auditorías.

Nivel V Avanzado. El entrenamiento y, las auditorías o seguimientos, son totales, igualmente algunos procesos y herramientas son incorporados en su totalidad.

Nivel VI Bien-definido. Los niveles de autoridad y experiencia son completos, el entrenamiento es avanzado y los procesos se integran introduciendo la documentación y el uso de métricas.

Nivel VII Gestionado. Se promueven los incentivos, se introduce la certificación en gestión de proyectos. Se persigue un buen desempeño y mejorar la eficiencia y efectividad.

Nivel VIII Optimizante. La mejora es continuada y sostenible.

Lo importante de esta propuesta es el Nivel VIII, al dejar explícito que alcanzar los niveles de madurez no es un fin en sí mismo, sino un medio para garantizar una mejora adaptativa y sostenida a lo largo del tiempo.

Implantación

Respecto de la consecución de la competencia, una manera de introducir técnicas de gestión que satisfagan los niveles de madurez del CMM es siguiendo ciclos iterativos.

En este sentido, existen mecanismos por medio de los cuales es posible sensibilizar a los proyectistas en la conveniencia de aprender a mejorar.

Para ello se deberían seguir ciclos de mejora de forma paulatina, por ejemplo, comenzar con un ciclo inicial donde se presentan las primeras prácticas de gestión, pasando luego a un ciclo de actualización de procesos e infraestructura para alcanzar un nivel 2 y así, ejecutar un tercer ciclo orientado a conseguir el nivel 3 del CMM (figura 3.19).

Figura 3.19: Implantación gradual.

Bibliografía [1] BARCELÓ GARCÍA, M. (1999). "La gestió d'un projecte informàtic". Universitat Oberta de Catalunya (UOC). Pp. 15-16. Barcelona.

[2] BACA URBINA, G. (2001). "Evaluación de proyectos. Análisis y administración del riesgo". 4ª edición. Editorial Mc-Graw-Hill. México.

[3] BURTON, C.; MICHAEL, N. (1995). Guía práctica para la gestión por proyecto. 1º edición. Editorial Paidos. Barcelona, España.

[4] LEWIS, J., P. (1995). "Planificación, programación y control de proyectos". Ediciones S. Barcelona.

[5] PEREÑA BRAND, J. (1996). "Dirección y gestión de proyectos". Editorial Díaz de Santos. Madrid.

[6] DE COS CASTILLO, M. (2003). "Teoría General del Proyecto". Editorial Síntesis. Madrid.

[7] GÓMEZ-SENENT MARTÍNEZ, E. (1992). "Introducción al proyecto". Edita el Servicio de Publicaciones de la Universidad Politécnica de Valencia. Valencia.

[8] ASIMOV, MORRIS. (1976). "Introducción al proyecto". Editorial Herreros Hermanos. México.

[9] DOMINGO AJENJO, A. (2005). "Dirección y gestión de proyectos". Editorial ALFAOMEGA. Grupo Editor Argentino S.A. Argentina.

[10] DRUDIS, A. (1992). "Planificación, organización y gestión de proyectos". Ediciones Gestión 2000. Barcelona.

[11] FRAME DAVIDSON, J. (2005). "La dirección de proyectos en las organizaciones". Ediciones Granica. Argentina.

[12] OCHOA LABURU, C. (1996). "Economía y organización de empresas". Editorial Donastiarra. España.

[13] SALGUEIRO, A. (1998). "Planificación: el arte de establecer objetivos". Editorial Aenor. España.

[14] BLANCHARD BENJAMIN, S. (1993). "Administración e Ingeniería de Sistemas". Primera edición, Editorial Limusa, Noriega. México D.F.

[15] COMPANYS PASCUAL, R. & COROMINAS SUBIAS, A. (1988). "Planificación y rentabilidad de Proyectos Industriales". Primera edición, Marcombo S. A. Barcelona, España.

[16] SERER FIGUEROA, M. (2001). "Gestión Integrada de Proyectos". Primera Edición. Editorial de la Universidad Politécnica de Cataluña. Barcelona, España.

[17] MACCONNELL S. (1997). "Desarrollo y Gestión de Proyectos Informáticos", Primera edición, Editorial Mac Graw Hill/Interamericana de España. Madrid, España.

[18] TRUEBA, I.; CAZORLA MONTERO, A.; DE GARCÍA, J. (1995). "Proyectos Empresariales: formulación, evaluación". Primera edición. Ediciones Mundi-Prensa. Madrid.

[19] SALVARREDY, J.; GARCIA FRONTI, V.; GARCIA FRONTI, J. (2004). Gerenciamiento de proyectos con Microsoft Excel y Microsoft Project. Omicron system. Argentina.

[20] PMI. (2004). "Guía de Fundamentos de la Dirección de Proyectos". Guía del PMBOK. Pennsylvania, Project Management Institute. Tercera edición.

PÁGINAS WEB

[1] "Project Management Institute". Enlace web: http://www.pmi.org/info/default.asp [Leído: 31 de octubre de 2008].

[2] "Recurso público de Trillium, Model Description". Enlace web: http://www.sqi.gu.edu.au/trillium/t3modc3.html [Leído: 31 de octubre de 2008].

[3] "Software Acquisition Capability Maturity Model". Enlace web: http://www.sei.cmu.edu/arm/SA-CMM.html [Leído: 31 de octubre de 2008].

[4] "Real Academia Española". Enlace web: http://www.rae.es [Leido: 26 de enero de 2009]