Una guía al cuerpo de conocimientos de la Administración de Proyectos (página 2)

1. Hemos cambiado el título para enfatizar que este documento no es el PMBOK. El documento de 1987 definía al PMBOK como "todos los tópicos, áreas de materia y procesos intelectuales que están involucrados en las prácticas de principios administrativos sanos a los …proyectos". Claramente se observa que un solo documento nunca contendrá la totalidad del PMBOK.
2. Hemos reescrito completamente la sección del Marco Teórico. La nueva sección consiste de tres capítulos:

• Introducción, que fija el propósito del documento y define de manera extensa los términos "proyecto" y "administración de proyectos".
• El Contexto de la Administración de Proyectos, que cubre el contexto en el que operan los proyectos – el ciclo de vida del proyecto, las perspectivas de los partidos interesados, influencias externas, y habilidades claves de la administración general.
• Los Procesos Administrativos de los Proyectos, que describe como los elementos varios de la administración de proyectos se interelacionan.

1. Hemos desarrollado una definición revisada de "proyecto". Queríamos una definición que era tanto inclusiva (no debería ser posible identificar cualquier empresa generalmente considerada como un proyecto que no llene la definición) y exclusiva (no debería ser posible identificar cualquier empresa que satisfaga la definición y que generalmente no se piensa como proyecto). Se revisaron muchas de las definiciones de proyecto en la literatura existente y se encontraron todas insatisfactorias de alguna manera. La nueva definición es motivada por las características únicas de un proyecto: un proyecto es una tarea temporal desarrollada para crear un producto o servicio único.
2. Hemos desarrollado una nueva vista del ciclo de vida del proyecto. El documento de 1987 definía las fases de proyecto como subdivisiones del ciclo de vida del proyecto. Hemos reordenado estas relaciones y definido el ciclo de vida del proyecto como una colección de fases cuyos números y nombres están determinados por las necesidades de control de la organización ejecutora.
3. Hemos cambiado los nombres de las principales secciones de "función" a "área de conocimiento". El termino "función" ha sido frecuentemente malentendido como un elemento de la organización funcional. El cambio de nombre deberá de eliminar este malentendido.
4. Reconocemos formalmente la existencia de una novena área de conocimiento. Ha existido un consenso amplio durante algún tiempo de que la administración de proyectos es un proceso integrativo. El Capítulo 4, Administración de la Integración de Proyecto, reconoce la importancia de este tema.
5. Hemos agregado la palabra "proyecto" al título de cada área de conocimiento. Aunque esto pueda parecer redundante, ayuda a clarificar el alcance de este documento. Por ejemplo, La Administración de Recursos Humanos cubre solo esos aspectos de la administración de recursos humanos que son únicos o casi únicos al contexto de proyectos.
6. Hemos escogido describir las áreas de conocimiento en términos de sus componentes de proceso. La búsqueda de un método consistente de presentación nos ha llevado a reestructurar completamente el documento de 1987 en 37 "procesos administrativos de proyectos". Cada proceso esta descrito en términos de sus entradas, salidas, herramientas y técnicas. Las entradas y salidas son documentos (e.g., una declaración de alcance) o ítems documentables (e.g., dependencias de actividades). Las herramientas y técnicas son los mecanismos aplicados a las entradas para crear las salidas. Además de su simplicidad fundamental, esta aproximación ofrece otros beneficios, a saber:

• Enfatiza las interacciones entre las áreas de conocimiento. Las salidas de un proceso se convierten en entradas para otro.
• La estructura es flexible y robusta. Cambios en conocimientos y prácticas pueden ser acomodados agregando un nuevo proceso, cambiando las secuencias de procesos, subdividiendo un proceso, o al agregar material descriptivo dentro de un proceso.
• Los procesos están en el núcleo de otros standards. Por ejemplo, los standards de calidad de la Organización Internacional de Standards (serie ISO 9000) se basan en la identificación de los procesos de negocios.

1. Agregamos algunas ilustraciones. Cuando se trata de estructuras de desglose de trabajo, diagramas de red, y curvas S, una imagen vale más que mil palabras.

    

   Número y Nombre de 1987	Número y Nombre de 1996
   0. Standards PMBOK	B. Evolución de Una Guía al Cuerpo de Conocimientos de la Administración de Proyectos de PMI
   1. Marco Teórico: El Raciocinio	1. Introducción (definiciones básicas)
   	2. El Contexto del Proyecto (ciclos de vida)
   2. Marco Teórico: Una Reseña	1. Porciones varias
   	2. Porciones varias
   	3. Porciones varias
   3. Marco Teórico: Un Modelo Integrativo	3. Procesos Administrativos de Proyectos
   	4. Administración de Integración del Proyecto
   4. Glosario de Términos Generales	IV. Glosario
   A. Administración del Alcance	5. Administración del Alcance del Proyecto
   B. Administración de la Calidad	8. Administración de la Calidad del Proyecto
   C. Administración del Tiempo	6. Administración de Tiempo del Proyecto
   D. Administración de Costos	7. Administración de Costos del Proyecto
   E. Administración de Riesgos	11. Administración de Riesgos del Proyecto
   F. Administración del Recurso Humano	9. Administración del Recurso Humano del Proyecto
   G. Administración de Contratos/Procuración	12. Administración del Procuramiento del Proyecto
   H. Administración de Comunicaciones	10. Administración de las Comunicaciones del Proyecto

2. Hemos reorganizado el documento de manera significativa. La siguiente tabla provee una comparación entre los encabezados del documento de 1987 con este:
3. "clasificar a" ha sido removido de la lista de propósitos. Tanto este documento como la versión de 1987 proveen una estructura para organizar el conocimiento de la administración de proyectos, pero ninguna es particularmente útil como una herramienta de clasificación. Primero, los tópicos incluidos no están completos – no incluyen prácticas innovadoras o inusuales. Segundo, muchos elementos tienen relevancia en más de un área de conocimiento o proceso de tal manera que las categorías no son únicas.

El Marco de la Administración de Proyectos

INTRODUCCIÓN

El cuerpo de conocimiento de proyectos (PMBOK) es un término inclusivo que describe la suma de los conocimientos dentro de la profesión de administración de proyectos. Como en otras profesiones tales como: medicina, abogacía, contaduría, el cuerpo del conocimiento recae sobre profesionales y académicos que aplican ese conocimiento y lo avanzan. El PMBOK entero incluye conocimiento probado y prácticas tradicionales que se aplican ampliamente, además del conocimiento e innovaciones de prácticas avanzadas que han visto un uso más limitado.

Este capitulo define y explica varios términos claves y provee una vista general del resto del documento. Además incluye las siguientes secciones principales:

1.1 Propósito de este documento

1.2 Qué es un proyecto?

1.3 Qué es la administración de proyectos?

1.4 Relación con otras disciplinas de administración

1.5 Tareas relacionadas

Propósito de este Documento

El propósito primario de este documento es identificar y describir ese subjuego del PMBOK que es generalmente aceptado. Generalmente aceptado quiere decir que el conocimiento y las prácticas descritas son aplicables a la mayoría de los proyectos la mayoría de las veces, y que hay un consenso amplio sobre su valor y utilidad. Generalmente aceptado no quiere decir que las prácticas y el conocimiento son o deben ser aplicadas uniformemente a todos los proyectos; el equipo de administración de proyectos siempre será responsable de determinar que es apropiado para cualquier proyecto dado.

Este documento también intenta proveer un léxico común dentro de la profesión para poder hablar de la administración de proyectos. La administración de proyectos es una profesión relativamente joven, y mientras que hay un entendimiento común de que es lo que hace, hay poco conocimiento relativo de los términos que se usan.

Este documento provee una referencia básica para cualquiera que este interesado en la profesión de administración de proyectos. Esto incluye, pero no esta limitado a:

• Administradores de proyectos y otros miembros del equipo de administración del proyecto.
• Administradores de administradores de proyecto.
• Los dueños del proyecto y otros partidos interesados.
• Administradores funcionales y empleados asignados al equipo de proyectos.
• Educadores que enseñan administración de proyectos y materias relacionadas.
• Consultores y otros especialistas en administración de proyectos y campos relacionados.
• Entrenadores desarrollando proyectos educativos en administración de proyectos.

Como una referencia básica, este documento no es ni compresivo ni todo inclusivo. El apéndice E discute extensiones en áreas de aplicación mientras que el apéndice F lista fuentes de otra información en administración de proyectos.

Este documento también es usado por el instituto de administración de proyectos para proveer una estructura consistente para sus programas de desarrollo profesional que incluyen:

• Certificación de administradores de proyectos profesionales (PMP’s).
• Acreditación de institutos educativos que enseñan administración de proyectos.

¿Qué es un proyecto?

Las organizaciones trabajan. El trabajo generalmente involucra operaciones o proyectos, aunque las dos se puedan traslapar. Las operaciones y los proyectos comparten muchas características; por ejemplo, ellas son:

• Desarrolladas por personas.
• Limitadas por recursos escasos.
• Son planeadas, ejecutadas, y controladas.

Las operaciones y los proyectos difieren principalmente en que las operaciones son sucesivas y repetitivas mientras que los proyectos son temporales y únicos. Un proyecto por lo tanto puede ser definido en término de sus características distintivas— un proyecto es una tarea temporal desarrollada para crear un producto o servicio único. Temporal quiere decir que cada proyecto tiene un comienzo definitivo y una terminación definitiva. Único quiere decir que el producto o servicio es diferente de alguna manera distintiva de todos los proyectos o servicios similares.

Los proyectos son desarrollados en todos los niveles de la organización. Estos pueden involucrar a una sola persona o a muchas miles. Y pueden requerir menos de 100 horas para completarse o más de 10,000,000. Los proyectos pueden involucrar a una sola unidad de una organización o cruzar muchas fronteras organizacionales como en consorcios o sociedades de hecho. Los proyectos son muchas veces componentes críticos de la estrategia de negocios de la organización que los desarrolla. Ejemplos de proyectos pueden incluir:

• Desarrollar un nuevo producto o servicio.
• Efectuar un cambio de estructura, de personal, o de estilo en una organización.
• Desarrollar un nuevo vehículo de transporte.
• Desarrollar o adquirir un nuevo sistema de información.
• Construir o desarrollar una construcción.
• Administrar una campaña electoral.
• Implementar un nuevo procedimiento o proceso en un negocio.

Carácter Temporal

Temporal quiere decir que cada proyecto tiene un comienzo definitivo y una terminación definitiva. El fin es alcanzado cuando los objetivos del proyecto han sido alcanzados, o cuando se hace claro que todos los objetivos no pueden ser alcanzados y que el proyecto tiene que ser terminado. Temporal no quiere decir necesariamente corto en duración; muchos proyectos duran varios años. En cada caso, sin embargo, la duración del proyecto es finita; los proyectos no son esfuerzos sucesivos.

Adicionalmente, el término temporal no se aplica generalmente al producto o servicio creado por el producto. Muchos proyectos son desarrollados para crear un resultado duradero. Por ejemplo, un proyecto para crear un monumento nacional creará un resultado que se espera dure por varios siglos.

Muchos desarrollos son temporales en el sentido en que van a terminar en algún punto del tiempo. Por ejemplo, el trabajo de ensamble en una planta automotriz va hacer eventualmente discontinuado, y la planta en si abandonada. Los proyectos son fundamentalmente diferentes porque el proyecto cesa cuando sus objetivos declarados han sido obtenidos, mientras que los desarrollos de no proyectos adoptan una serie nueva de objetivos y continúan trabajando.

La naturaleza temporal de los proyectos se pueden aplicar a otros aspectos del desarrollo tales como:

• La oportunidad de la ventana de mercado es usualmente temporal — La mayoría de los proyectos tienen un marco de tiempo limitado en el que tiene que producir su producto o servicio.
• El equipo de proyecto, como un equipo, rara vez dura más que el proyecto— la mayoría de los proyectos son desarrollado por un equipo creado con el sólo propósito de desarrollar el proyecto, y el equipo es desmantelado y sus miembros reasignados cuando el proyecto se termine.

Producto o Servicio Único

Los proyectos involucran hacer algo que no se ha hecho antes, por lo tanto, es único. Un producto o un servicio puede ser único aunque la categoría a la que pertenezca sea grande. Por ejemplo, muchos miles de edificios de oficina han sido desarrollados, pero cada edificio en si es único — de distinto dueño, de distinto diseño, diferente locación, y diferentes contratistas, y así etc. La presencia de elementos repetitivos no cambia fundamentalmente la característica de ser único. Por ejemplo:

• Un proyecto para desarrollar una vía comercial puede requerir múltiples prototipos
• Un proyecto para introducir una nueva droga al mercado puede requerir de miles de dosis durante las pruebas clínicas.
• Un proyecto de desarrollo de bien raíz puede incluir cientos de unidades individuales.

Debido a que el producto de cada proyecto es único, las características que distinguen el producto o servicio deben ser elaboradas progresivamente. Progresivamente quiere decir "Procedimientos en pasos; avance continuo por incrementos" mientras que elaborados quiere decir "trabajado con cuidado al detalle; desarrollado enteramente" [1]. Las características distintivas serán definidas de manera amplia, temprano en el proyecto y serán cada vez más y más explícitas y detalladas a medida que el equipo del proyecto desarrolla un entendimiento mejor y más completo del producto.

La elaboración progresiva de las características de un producto debe ser cuidadosamente coordinada en concordancia con una apropiada definición del alcance del proyecto, particularmente si el proyecto es desarrollado bajo un contrato. Cuando definida propiamente, el alcance del proyecto – el trabajo a realizar – deberá mantenerse constante aún en la luz del cambio las características del producto que sea progresivamente elaborado. La relación entre el alcance del proyecto y el alcance del producto será discutido con más detalle en la introducción al capítulo 5.

Para mostrar dos ejemplos ilustrativos de elaboración progresiva en dos redes de aplicación distintas, tenemos:

Ejemplo 1. Una planta procesadora química empieza con un proceso de ingeniería para definir las características de un proceso. Estas características serán usadas para diseñar las unidades de procesamiento principales. Esta información se convierte en la base del diseño de ingeniería que definirá tanto el detalle de layout de la planta y de las características mecánicas de las unidades de proceso y facilidades auxiliares. Todo esto resulta en los dibujos de diseño que serán elaborados para producir dibujos de fabricación (isométricos de construcción) durante la construcción, habrán interpretaciones y adaptaciones que serán hechas a medida que se necesiten y estarán sujetas a una aprobación formal. Esta elaboración adicional de las características es capturada por un dibujo "as built". Durante los ensayos y entrega, un desarrollo adicional de las características es muchas veces hecho en la forma de ajustes operacionales finales.

Ejemplo 2. El producto de un proyecto de desarrollo biofarmaceútico puede ser inicialmente definido como "Pruebas clínicas de XYZ" debido a que el número de pruebas y el tamaño de cada una de ellas, es desconocido. A medida que el proyecto avanza, el producto puede ser descrito más explícitamente "Ensayos de la fase III, ensayo 4 de la fase II y ensayo 2 de la fase III". La siguiente ronda de elaboración progresiva puede enfocarse exclusivamente en el protocolo de los ensayos de la fase I – es decir que pacientes reciben que dosis y que tan frecuentemente. En las etapas finales del proyecto, los ensayos de la fase III serían explícitamente definidos con base en información recogida y analizada durante los ensayos de la fase I y fase II.

¿Qué es la Administración de Proyectos?

La administración de proyectos es la aplicación de conocimiento, habilidades, herramientas, y técnicas a actividades de proyectos de manera que cumplan o excedan las necesidades y expectativas de partidos interesados de un proyecto. Cumplir o exceder las necesidades o expectativas de los partidos interesados invariablemente involucran balancear demandas que compiten entre sí, tales como:

• Alcance, tiempo, costo y calidad.
• Partidos interesados con diferentes necesidades y expectativas.
• Requerimientos identificados (necesidades) y requerimientos no identificados (expectativas).

El término administración de proyectos es a veces usado para describir una aproximación organizacional a la administración de operaciones sucesivas. Esta aproximación, más propiamente llamada administración por proyectos, trata muchos aspectos de operaciones sucesivas como proyectos para poder aplicar la administración de proyectos a ellas. Aunque un entendimiento de la administración de proyectos es obviamente crítica para una organización que esta administrando por proyectos, una discusión detallada de esta aproximación esta fuera del alcance de este documento.

El conocimiento acerca de la administración de proyectos puede ser organizada de muchas maneras. Este documento tiene dos secciones principales y doce capítulos como se describe a continuación.

El Marco de la Administración de Proyectos

Parte I, el Marco de la Administración de Proyectos, provee la estructura básica para entender la administración de proyectos.

Capítulo 1, Introducción, define los elementos claves y provee una vista del resto del documento.

Capítulo 2, El Contexto de la Administración de Proyectos, describe el ambiente en el cual los proyectos operan. El equipo de administración de proyectos debe comprender este contexto más amplio — administrar las actividades día a día de un proyecto es necesario para su éxito pero no es suficiente.

Capítulo 3, Los Procesos de Administración de Proyectos, describe una vista generalizada de como los procesos varios de la administración de proyectos interactuan comúnmente. Entender estas interacciones es fundamental para entender el material que se presenta del Capítulo 4 al 12.

Las Áreas de Conocimiento de la Administración de Proyecto

Parte II, las Áreas de Conocimiento de la Administración de Proyecto, describen conocimiento y prácticas de la administración de proyectos en término de sus componentes de proceso. Estos procesos han sido organizados en nueve áreas de conocimiento, tal como se describen a continuación e ilustradas en la Figura 1-1.

Capítulo 4, Administración de la Integración de Proyectos, describe los procesos requeridos para asegurar que los elementos varios de un proyecto están

coordinados apropiadamente. Consiste del desarrollo de un plan de proyecto, ejecución del plan de proyecto, y el control de cambios en general.

Capítulo 5, Administración del Alcance del Proyecto, describe el proceso requerido para asegurar que el proyecto incluye todo trabajo requerido, y sólo el trabajo requerido, para completar el proyecto de manera exitosa. Consiste de la iniciación, planeación del alcance, definición del alcance, verificación del alcance, y control de cambio al alcance.

Capítulo 6, Administración del Tiempo del Proyecto, describe los procesos requeridos para asegurar la terminación a tiempo del proyecto. Consiste en la definición de las actividades, secuencia de las actividades, estimación de duración de las actividades, desarrollo del cronograma y control de la programación.

Capítulo 7, Administración de los Costos del Proyecto, describe los procesos requeridos para asegurar que el proyecto es completado dentro del presupuesto aprobado. Consiste en la planificación de recursos, estimación de costos, presupuestación de costos, y control de costos.

Capítulo 8, Administración de la Calidad del Proyecto, describe los procesos requeridos para asegurar que el proyecto satisfacerá las necesidades para lo cual fue desarrollado. Consiste en la planeación de la calidad, aseguranza de la calidad, y control de calidad.

Capítulo 9, Administración de los Recursos Humanos del Proyecto, describe los procesos requeridos para hacer el uso más eficiente de las personas involucradas en el proyecto. Consiste en la planeación organizacional, adquisición de staff, y desarrollo del equipo.

Capítulo 10, Administración de las Comunicaciones del Proyecto, describe los procesos requeridos para asegurar la generación apropiada y a tiempo, colección, diseminación, almacenamiento, y la disposición final de la información del proyecto. Consiste en la planeación de la comunicación, distribución de la información, reportes de desempeño, y el cierre administrativo.

Capítulo 11, Administración de Riesgo del Proyecto, describe los procesos concernientes con la identificación, análisis, y respuesta a el riesgo del proyecto. Consiste en la identificación del riesgo, cuantificación del riesgo, desarrollo de la respuesta al riesgo, y en el control de la respuesta al riesgo.

Capítulo 12, Administración de la Procuración del Proyecto, describe los procesos requeridos para adquirir bienes y servicios de fuera de la organización ejecutora. Consiste en la planeación de la gestión de la procuración, planear la solicitación, la solicitación, selección de proveedores, administración de contratos, y cierre de contratos.

Relación con Otras Disciplinas de Administración

Mucho del conocimiento requerido para administrar proyectos es único o casi único a la administración de proyectos (e.g. análisis de la ruta crítica y estructura de desglose de trabajo). Sin embargo, el PMBOK traslapa con otras disciplinas de administración tal como se ilustra en la Figura 1-2.

La Administración General, comprende planear, organizar, la consecución de recursos humanos, ejecutar, y controlar las operaciones de una empresa en funcionamiento continuo. La administración general también incluye disciplinas de soporte tales como: Programación de computadoras, abogacía, estadística y teorías de probabilidad, logística, y administración de personal. El PMBOK traslapa la administración general en muchas áreas — comportamiento organizacional, proyecciones financieras, y técnicas de planeación sólo para nombrar algunas pocas. La sección 2.4 provee una discusión más detallada de la administración general.

Las áreas de aplicación son categorías de proyectos que tienen elementos comunes significativos en tales proyectos pero que no son requeridos o presentes en todos los proyectos. Las áreas de aplicación usualmente están definidas en términos de:

• Elementos técnicos, tales como, desarrollo de software, drogas farmacéuticas, o ingeniería de construcción.
• Elementos de la administración, tales como, contratos con el gobierno o desarrollo de nuevos productos.
• Grupos de industria, tales como los de automóviles, químicos o de servicios financieros.

El apéndice E incluye una discusión más detallada de las áreas de aplicación de los proyectos.

Tareas Relacionadas

Ciertos tipos de eventos están ligados de manera muy cercana a los proyectos. Estos desarrollos relacionados se describen a continuación

Programas. Un programa es un grupo de proyectos administrado de una manera coordinada de tal manera que se obtienen beneficios que no se pueden obtener al administrar los proyectos individualmente [2]. Muchos programas incluyen también elementos de operaciones sucesivas. Por ejemplo:

• El "programa de avión XYZ" incluye tanto el proyecto o proyectos de diseño y desarrollo del avión como la manufactura y soporte del avión en el campo de pruebas.
• Muchas firmas electrónicas tienen "administradores de programa" que son responsables tanto por la entrega de productos individuales (proyectos) y de la coordinación de múltiples entregas sobre un período de tiempo (una operación en desarrollo).
• Los programas también involucran una serie de desarrollo cíclicos o repetitivos, por ejemplo:
• Las compañías de servicios públicos muchas veces hablan de "un programa de construcción" que es una operación sucesiva y regular que involucra muchos proyectos.
• Muchas organizaciones sin ánimo de lucro tienen un "programa de captación de fondos" que es un esfuerzo continúo para obtener apoyo financiero que muchas veces involucra una serie de proyectos discretos tales como funciones de beneficencia o remates.
• Publicar un periódico o una revista es también un programa — el periódico en si es un esfuerzo continúo, pero cada edición es en si un proyecto.

En algunas áreas de aplicación, la administración de programas y la administración de proyectos se tratan como sinónimos; en otras, la administración de proyectos es un subproyecto del programa de administración. Ocasionalmente, la administración de programas es considerada como un subproyecto de la administración de proyectos. Esta diversidad de definiciones hace que sea imperativa que cualquier discusión de la administración de programas versus administración de proyectos sea precedida por un acuerdo claro y consistente de la definición de cada término.

Subproyectos. Los proyectos frecuentemente están divididos en componentes más manejables o subproyectos los subproyectos son muchas veces contratados con una entidad externa o con otra unidad funcional de la organización ejecutora. Ejemplos de subproyectos pueden incluir:

• Una fase de proyecto (las fases del proyecto se describen en la Sección 2.1).
• La instalación de la plomería o electricidad en un proyecto de construcción.
• Pruebas automatizadas de programas de computadora en un proyecto de desarrollo de software.
• Manufactura de alto volumen para dar soporte a las pruebas clínicas de una nueva droga en un proyecto de desarrollo e investigación farmaceútica.

Sin embargo, desde la perspectiva de una organización ejecutora un subproyecto es muchas veces pensado más como un servicio que un producto, y este servicio es único. Por lo tanto los subproyectos serán referidos típicamente como proyectos y serán administrados como tal.

NOTAS:

El Contexto de la Administración de Proyectos

Los proyectos y la administración de proyectos operan en un ambiente más amplio que el del proyecto mismo. El equipo de administración de proyectos debe entender este contexto más amplio – administrar día a día la actividades del proyecto es necesario para el éxito de este, pero no suficiente. Este capítulo describe aspectos claves del contexto de la administración de proyectos, que no están descritos en otras partes de este documento. Los tópicos incluidos aquí son:

2.1 Fases del Proyecto y el Ciclo de Vida del Proyecto

2.2 Los Partidos Interesados del Proyecto

2.3 Influencias Organizacionales.

2.4 Habilidades Claves de Administración General

2.5 Influencia Socioeconómicas

Fases del Proyecto y Ciclo de Vida del Proyecto

Porque los proyectos son tareas únicas, involucraran cierto nivel de incertidumbre. Las organizaciones ejecutaras de proyectos generalmente dividirán cada proyecto en fases del proyecto para poder administrar mejor los enlaces apropiados con las operaciones de la organización ejecutara. De manera colectiva, estas fases se conocen como el ciclo de vida del proyecto.

Características de las Fases del Proyecto

Cada fase del proyecto es marcada por la terminación de una o más entregas. Una entrega es un tangible, un producto de trabajo verificable tal como un estudio de factibilidad, un detalle de diseño, o un prototipo que trabaje. Las entregas, y por tanto las fases, son parte generalmente de una secuencia lógica diseñada para asegurar una definición apropiada del producto del proyecto.

La conclusión de una fase de proyecto es generalmente marcada por la revisión de tanto las entregas como del desempeño del proyecto para poder (a) determinar si el proyecto debe continuar a su próxima fase y (b) detectar y corregir errores de manera eficiente. Estas revisiones de final de fase generalmente se llaman salidas de fase, puertas de fase o puntos muertos.

Cada fase de proyecto normalmente incluye una serie definida de productos de trabajo diseñados para establecer el nivel deseado de control administrativo. La mayoría de estos ítems están relacionados con la entrega de la fase primaria, y las fases típicamente toman sus nombres de estos ítems: requerimientos, diseño, construcción, texto, comienzo, entrega, y otros como sea apropiado. Varios ciclos de vida del proyecto representativos son descritos en la Sección 2.1.3.

Características del Ciclo de Vida del Proyecto

El ciclo de vida del proyecto sirve para definir el comienzo y el final de un proyecto. Por ejemplo, cuando una organización identifica una oportunidad a la que le gustaría responder, autorizará un estudio de factibilidad para determinar si debe adoptar el proyecto. La definición del ciclo de vida del proyecto determinará si el estudio de

factibilidad es tratado como la primer fase de vida del proyecto o como un proyecto independiente.

La definición de ciclo de vida del proyecto determinará también que acciones de transición se incluirán al final del proyecto y cuales no. De esta manera, la determinación del ciclo de vida del proyecto puede ser usado para enlazar el proyecto a operaciones sucesivas de la organización ejecutora.

La secuencia de fase definida por la mayoría de los ciclos de vida del proyecto generalmente involucran algún tipo de transferencia en tecnología o intercambios tales como los requerimientos para diseñar, construcción para operaciones o diseño para manufactura. Entregas de la fase precedente son usualmente aprobadas antes que comience el trabajo en la fase siguiente. Sin embargo, una fase subsiguiente es a veces comenzada antes de la aprobación de las entregas de la fase anterior cuando los riesgos involucrados se tornan aceptables. Esta táctica de traslapo de fases muchas veces es llamada "Fast Tracking".

Los ciclos de vida del proyecto generalmente definen:

• Qué trabajo técnico debe ser hecho en cada fase (e.g. ¿Es el trabajo del arquitecto parte de la fase de definición o de la fase de ejecución?).
• Quién debe estar involucrado en cada fase (e.g. ingeniería concurrente requiere que los implementores estén involucrados con los requerimientos y los diseños).

Las descripciones de los ciclos de vida del proyecto pueden ser o muy generales o muy detallados. Las descripciones altamente detalladas tienen muchas formas, tablas y lista de chequeo para proveer estructura y consistencia. Tales aproximaciones de detalle son llamadas a veces metodologías de administración de proyectos.

La mayoría de las descripciones de ciclo de vida del proyecto comparten un número de características comunes:

• Los niveles de empleados y costos son bajos al comienzo, más altos hacia el final, y caen rápidamente a medida que se llega a la finalización. Este patrón se ilustra en la Figura 2-1.

• La probabilidad de completar exitosamente el proyecto es más bajo, y por lo tanto el riesgo e incertidumbre son altos, al comienzo del proyecto. La probabilidad de completar exitosamente generalmente se vuelve progresivamente más grande a medida que el proyecto continua.
• La habilidad de los partidos interesados para influenciar las características finales del producto del proyecto y su costo final son más altas al comienzo y se vuelven progresivamente más bajas a medida que el proyecto continua. La contribución más grande de este fenómeno es que los costos de cambio y de corrección de errores generalmente se incrementan a medida que el proyecto continua.

Se debe tener cuidado para distinguir entre el ciclo de vida del proyecto y el ciclo de vida del producto. Por ejemplo, un proyecto desarrollado para introducir una nueva computadora al mercado es solo fase del ciclo de vida de un producto.

A pesar de que muchos ciclos de vida del proyecto tienen nombres de fases similares con trabajo similar requerido para los productos, muy pocos son idénticos. La mayoría tienen cuatro o cinco fases pero algunos tienen nueve o más. Aún dentro de una sola área de aplicación pueden haber variaciones significativas – un ciclo de vida de desarrollo de software de una organización puede tener una sola fase de diseño mientras que la de otra organización puede tener fases distintas para el diseño funcional y de detalle.

Los subproyectos dentro de proyectos pueden también tener ciclos de vida de proyectos distintos. Por ejemplo, una firma de arquitectura contratada para diseñar un nuevo edificio de oficinas está primero involucrada con la fase de definición del dueño cuando esta elaborando el diseño y en la fase de implementación del dueño mientras que da soporte al esfuerzo de construcción. El proyecto de diseño del arquitecto, sin embargo, tendrá su propias series de fases que van desde el desarrollo conceptual pasando por la definición, implementación y cierre. El arquitecto puede inclusive tratar el diseño y el soporte a la construcción como proyectos separados con sus propias fases distintas.

Ciclos de Vida de Proyecto Representativas

Los siguientes ciclos de vida del proyecto se han escogido para ilustrar la diversidad de aproximaciones en uso. Los ejemplos mostrados son típicos; no son ni recomendados ni preferidos. En cada caso, los nombres de fases y las entregas más grandes son las descritas por los autores.

/

Adquisiciones de Defensa La directiva 5000.2 del Departamento de Defensa de los Estados Unidos, tal como lo indica la revisión de febrero de 1993, describe una serie de hitos y fases de adquisición tal como se ilustran en la Figura 2-2 .

• Determinación de la Necesidad de la Misión — termina con la Aprobación de los Estudios Conceptuales.
• Exploración de Conceptos y Definiciones — termina con la Aprobación de la Demostración de Conceptos.
• Demostración y Validación — termina con la Aprobación de Desarrollo.
• Desarrollo de la Ingeniería y Manufactura — se traslapa con Operaciones y Soporte sucesivas.

Construcción. Morris [1] describe el ciclo de vida de un proyecto de construcción como se ilustra en la Figura 2-3.

• Factibilidad — formulación del proyecto, estudios de factibilidad, y diseños de estrategia y aprobación. Una decisión de seguir – no seguir es hecha a la terminación de esta fase.
• Planeación y Diseño — diseño de base, costos y cronogramas, términos del contrato y condiciones, y planeación detallada. Los contratos principales son adjudicados al final de esta fase.
• Producción — manufactura, entrega, obra civil, instalación, y pruebas. La factibilidad es terminada sustancialmente al completar esta fase.
• Entrega y Comienzo de Operaciones — ensayos finales y mantenimiento. La operación debe estar en pleno funcionamiento al terminar esta fase.

Farmaceúticas. Murphy [2] describe el ciclo de vida del proyecto para el desarrollo de un nuevo producto farmacéutico en los Estados Unidos como se ilustra en la Figura 2-4.

• Descubrimiento y Selección — incluye investigación básica y aplicada para identificar candidatos para los ensayos preclínicos.

• Desarrollo Preclínico — incluye ensayos de laboratorio y en animales para determinar su seguridad y eficacia así también para la preparación y formulación de una aplicación de Investigación de una Nueva Droga (IND).
• Trabajo para los Registros— incluye ensayos de Fase Clínica I, II, y III así como también la preparación y formulación para una Aplicación de una Nueva Droga (NDA).
• Actividades después de la Remisión—incluye trabajo adicional tal como se requiera para darle soporte a la revisión de la NDA que haga la Administración de Comidas y Drogas (FDA).

Desarrollo de Software. Muench, et.al. [3] Describe un modelo espiral para desarrollo de software con cuatro ciclos y cuatro cuadrantes como se ilustra en la Figura 2-5:

• Ciclo de prueba de concepto — captura los requerimientos del negocio, define metas para la prueba del concepto produce diseños conceptuales de sistema, diseño y construcción de la prueba del concepto, produce planos para el ensayo de la aceptación, conduce a análisis de riesgo y hace recomendaciones.
• Ciclo de la primera construcción — deriva requerimientos del sistema, define metas para la primera construcción, produce diseños de los sistemas lógicos, diseño y construcción del primer modelo, produce planos para los ensayos del sistema, evalúa la primera construcción y hace recomendaciones.
• Ciclo de la segunda construcción — deriva requerimientos del sistema, define metas para la segunda construcción, produce diseños físicos, construye el segundo modelo, produce planos para los ensayos del sistema, evalúa la segunda construcción y hace recomendaciones.
• Ciclo final — completa los requerimientos de la unidad, diseño final, construye el modelo final, hace ensayos de unidad, subsistema, sistema, y aceptación.

Partidos Interesados en el Proyecto

Los partidos interesados son individuos y organizaciones que están activamente interesados en el proyecto, o cuyos intereses pueden ser afectados positiva o negativamente como resultado de la ejecución del proyecto o de la terminación exitosa del proyecto. El equipo de administración del proyecto debe identificar a los partidos interesados en el proyecto, determinar cuales son sus necesidades y

expectativas, y administrar e influenciar esas expectativas para asegurar un proyecto exitoso. La identificación de los partidos interesados en el proyecto es a veces difícil.

Por ejemplo, ¿Es un obrero de una línea de ensamblaje cuyo futuro empleo depende del resultado de un nuevo proyecto de diseño, un partido interesado en el proyecto?

Los partidos claves en cada proyecto incluyen:

• Administradores de proyectos — el individuo responsable por administrar el proyecto.
• Cliente — el individuo u organización que usará el producto del proyecto. Puede haber múltiples capas de clientes. Por ejemplo, los clientes para un nuevo producto farmacéutico pueden incluir a los doctores que los prescriben, los pacientes que lo toman y a las compañías aseguradoras que pagan por el.
• La organización ejecutora — la organización cuyos empleados que están más directamente en el trabajo del proyecto.
• El patrocinador — el individuo o grupo dentro de la organización ejecutora que provee los recursos financieros en efectivo o en especie, para el proyecto.

Adicionalmente a estos hay muchos nombres y categorías distintas para los partidos interesados en el proyecto – interno y externo, dueños y fundadores, proveedores y contratistas, miembros del equipo y sus familias, agencias gubernamentales y compañías de medios de comunicación, ciudadanos individuales, organizaciones de lobby permanentes o temporales, y la sociedad en general. El nombramiento o agrupamiento de los partidos interesados en el proyecto es una ayuda principalmente para identificar que individuos u organizaciones se ven a ellos mismos como partidos interesados. Los roles de los partidos interesados y sus responsabilidades se pueden traslapar, así como cuando una firma de ingeniería provee financiación para una planta que esta diseñando.

Administrar las expectativas de los partidos interesados puede ser difícil porque los partidos interesados muchas veces tienen objetivos muy distintos, que pueden entrar en conflicto. Por ejemplo:

• El administrador de un departamento que ha pedido un nuevo sistema de manejo de información, puede desear un bajo costo, el arquitecto del diseño puede enfatizar el aspecto técnico, y el contratista de programación puede estar interesado en maximizar sus ganancias.
• El vicepresidente de investigación de una firma electrónica puede definir el éxito de un nuevo producto como estado del arte de la tecnología, el vicepresidente de manufactura puede definirlo como prácticas a nivel global y el vicepresidente de mercadeo puede estar preocupado principalmente con el número de nuevas innovaciones que traiga el producto.
• El dueño de un proyecto de desarrollo de bien raíz puede estar enfocado en una ejecución a tiempo, el cuerpo gobernante local puede desear maximizar sus impuestos prediales, y un grupo ambiental puede desear minimizar el impacto ambiental, y los residentes locales pueden desear la relocalización del proyecto.

En general, las diferencias entre los distintos partidos interesados se deben resolver en favor del cliente. Esto no quiere decir, sin embargo, que las necesidades y expectativas de otros partidos interesados sean o deban ser descartadas. Encontrar las respuestas apropiadas para estas diferencias debe ser uno de los mayores retos para el administrador de proyectos.

Influencias Organizacionales

Los proyectos son parte típicamente de una organización más grande que el proyecto mismo – corporaciones, agencias gubernamentales, instituciones de salud, cuerpos internacionales, asociaciones profesionales, y otros. Aún cuando el proyecto es la organización (consorcios, sociedades de hecho), el proyecto aún estará influenciado por la organización u organizaciones que lo conforman. La siguiente sección describe aspectos claves de estas estructuras organizacionales más grandes que con seguridad influenciaran el proyecto.

Sistemas Organizacionales

Las organizaciones basadas en proyectos son aquellas cuyas operaciones consistirán principalmente del proyecto. Estas organizaciones caen en dos categorías:

• Organizaciones que derivan sus entradas principalmente de ejecutar proyectos para otros – firmas de arquitectos, firmas de ingeniería, consultores, contratistas de construcción, contratistas para el gobierno, etc.
• Organizaciones que han adoptado la administración por proyectos (vea Sección 1.3).

Estas organizaciones tienden a tener sistemas administrativos para facilitar la administración de proyectos. Por ejemplo, sus sistemas financieros mucha veces están diseñados específicamente para contabilizar, controlar, y reportar sobre múltiples proyectos simultáneos.

Organizaciones no basadas en proyectos – compañías de manufactura, firmas de servicios financieros, etc. -rara vez tienen sistemas administrativos diseñados para soportar las necesidades de los proyectos eficiente y efectivamente. La ausencia de

sistemas orientados a proyectos, usualmente hace que la administración del proyecto sea más difícil. En algunos casos, organizaciones no basadas en proyectos tendrán departamentos u otras subunidades que operaran como organizaciones basadas en proyectos con sistemas para tales necesidades.

El equipo administrativo del proyecto debe estar agudamente consciente de como el sistema de la organización afectará al proyecto. Por ejemplo, si la organización premia a sus administradores funcionales por cargar tiempo de los empleados al proyecto, el equipo de administración del proyecto tendrá que implementar controles para asegurar que el personal asignado este siendo usado de manera efectiva en el proyecto.

Culturas Organizaciones y Estilo

La mayoría de las organizaciones han desarrollado culturas que son describibles y únicas. Estas culturas se reflejan en sus valores compartidos, normas, creencias, y expectativas; en sus procedimientos y políticas; en su vista particular de las relaciones de autoridad; y en otros factores numerosos. Las culturas organizacionales tienen muchas veces influencia directa en el proyecto. Por ejemplo:

• Un equipo que proponga una aproximación inusual o de alto riesgo es más seguro de encontrar aprobación en una organización agresiva o creativa.
• Un administrador de proyectos con un estilo altamente participativo seguramente encontrará problemas en una organización jerárquica rígida, mientras que un administrador de proyectos con estilo administrativo autoritario se verá enfrentado si trabaja en una organización participativa.

Estructura Organizacional

La estructura de la organización ejecutora a veces limita la disponibilidad de los términos bajo los cuales los recursos se hacen disponibles para el proyecto. Las estructuras organizacionales pueden ser caracterizadas como conformando un espectro que va desde funcional a proyectizado, con una variedad de matrices estructurales en el medio. La Figura 2-6 detalla características claves relacionadas con el proyecto, de los principales tipos de estructura organizacional. La organización de proyectos es discutida en la Sección 9.1, Planeación Organizacional.

La organización funcional clásica se muestra en la Figura 2-7, es una jerarquía donde cada empleado tiene un jefe inmediato claro. Los empleados están organizados por especialidad, tales como producción, mercadeo, ingeniería, y contabilidad en el nivel superior, con la ingeniería subdividida en mecánica y eléctrica. Las organizaciones funcionales tendrán todavía proyectos pero el alcance percibido del proyecto estará limitado a los límites de la función: El departamento de ingeniería en una organización funcional hará su trabajo independientemente de los departamentos de manufactura y mercadeo. Por ejemplo, si el desarrollo de un nuevo producto es desarrollado en una organización puramente funcional, su fase de diseño muchas veces se llamará "proyecto de diseño" e incluirá solamente al personal del departamento de ingeniería. Si surge una pregunta de manufactura, esta se llevará a la cabeza del departamento que consultará con el jefe del departamento de manufactura. La cabeza de el departamento de ingeniería pasará entonces su respuesta, descendiendo por la jerarquía hasta el administrador de ingeniería del proyecto.

En el lado opuesto del espectro está la organización proyectizada que se muestra en la Figura 2-8. En una organización proyectizada, los miembros del equipo son muchas veces colocados. La mayor parte de los recursos de la organización están involucrados en el proyecto, y los administradores del proyecto tienen una gran cantidad de independencia y autoridad. Las organizaciones proyectizadas muchas veces tienen unidades organizacionales llamadas departamentos, pero estos grupos o reportan directamente al administrador de proyectos o proveen servicios de soporte a proyectos varios.

Las organizaciones matriciales tal como se muestran en las Figuras 2-9 a 2-11 son una mezcla de características funcionales y proyectizadas. Las matrices débiles mantendrán muchas de las características de una organización funcional y el rol de administrador de proyectos es más el de un coordinador que el de un administrador. De manera similar, las matrices fuertes tendrán muchas de las características de la organización proyectizada – administradores de proyectos de tiempo completo con autoridad considerable y personal administrativo de proyecto de tiempo completo.

La mayoría de las organizaciones modernas involucran todas estas estructuras en varios niveles tales como se muestran en la Figura 2-12. Por ejemplo, aún una organización fundamentalmente funcional puede crear un equipo especial de proyectos para encargarse de un proyecto crítico. Tal equipo tendrá muchas de las características de un proyecto en una organización proyectizada: Puede incluir personal de tiempo completo de diferentes departamentos funcionales, y puede desarrollar su propio juego de procedimientos operativos, y puede operar fuera de la estructura estandarizada, formalizada de reportes.

Habilidades Claves de la Administración General

La Administración en General es un tema amplio que trata con todos los aspectos de la administración de una organización en producción. Entre otros temas incluye:

• Contabilidad y finanzas, ventas y mercadeo, investigación y desarrollo, manufactura y distribución.
• Planeación estratégica, planeación táctica, y planeación operacional.
• Estructuras organizacionales, comportamiento organizacional, administración de personal, prestaciones, beneficios, y caminos de ascensos.
• Administración de relaciones de trabajo a través de la motivación, la delegación, supervisión, construcción de equipos de trabajo, manejo de conflictos, y otras técnicas.
• Manejo de uno mismo por medio de técnicas de administración del tiempo, manejo de estrés, y otras técnicas.

Las habilidades de administración general proveen gran parte de los fundamentos para construir habilidades administrativas de proyecto. Son muchas veces esenciales para el administrador de proyectos. En cualquier proyecto dado, habilidades de un gran número de áreas de administración general pueden ser requeridas. Esta sección describe habilidades claves de administración general que muy probablemente afectarán la mayoría de proyectos y que no son contempladas en ningún otro lugar. Estas habilidades están bien documentadas en la literatura de administración general y su aplicación es fundamentalmente la misma en un proyecto.

Hay también muchas habilidades de administración general que son relevantes solo en algunos proyectos o áreas de aplicación. Por ejemplo la seguridad de los miembros del equipo es crítica en virtud todos los proyectos de construcción y de poca monta en la mayoría de los proyectos de desarrollo de software.

Liderazgo

Kotter [4] distingue entre liderazgo y administración mientras que enfatiza la necesidad de ambas: Una sin la otra probablemente producirá resultados pobres. El dice que administrar esta principalmente preocupada con "producir consistentemente

los resultados claves esperados por los partidos interesados," mientras que el liderazgo involucra:

• Establecer dirección — desarrollar tanto una visión del futuro como estrategias para producir los cambios necesarios para alcanzar esa visión.
• Alinear las personas — comunicar la visión por medio de palabras y actos a todos aquellos cuya cooperación podrá ser necesitada para alcanzar esa visión.
• Motivar e inspirar — es ayudar a las personas a energizarse para sobreponer barreras políticas, burocráticas y de recursos para lograr un cambio.

En un proyecto, y en particular un proyecto grande, se espera generalmente que el administrador del proyecto sea también el líder del proyecto. El liderazgo no esta, sin embargo, limitado al administrador del proyecto: Este podrá ser demostrado por muchos individuos diferente, en diferentes puntos del proyecto. El liderazgo debe ser demostrado a todos los niveles del proyecto (liderazgo del proyecto, liderazgo técnico, liderazgo de equipo).

Comunicación

La comunicación involucra el intercambio de información. El que envía es responsable por hacer la información clara, no ambigua, y completa para el que reciba pueda hacerlo de manera correcta. El que recibe es responsable por asegurarse de que la información se recibe de forma completa y se entiende en su totalidad. La comunicación tiene muchas dimensiones:

• Escrita y oral, escuchar y conversar.
• Interna (dentro del proyecto) y externa (al cliente, a los medios, al público, etc.).
• Formal (reportes, actas, etc.) e informal (memos, conversaciones ad hoc, etc.).
• Vertical (hacia arriba y abajo en la organización) y horizontal (con los compañeros de trabajo).

Las habilidades de administración general de las comunicaciones está relacionada a, pero no lo mismo que, la Administración de Comunicaciones en un Proyecto (descrito en el Capítulo 10). La comunicación es una materia amplia e involucra un cuerpo sustancial de conocimiento que no es único al contexto del proyecto, por ejemplo:

• Modelos de envío y recibo — ciclos de retroalimentación, barreras de comunicación, etc.
• Escoger el medio — cuando comunicarse por escrito, cuando comunicarse oralmente, cuando escribir un memo de información, cuando escribir un reporte formal, etc.
• Estilo de escritura — voz activa vs. pasiva, estructura de frase, escoger las palabras, etc.
• Técnicas de presentación — cuerpo de lenguaje, diseño de ayudas visuales, etc.
• Técnicas de administración de reuniones — preparar una agenda, administración de conflictos, etc.

La Administración de Comunicaciones del Proyecto es la aplicación de estos conceptos amplios a las necesidades especificas de un proyecto; por ejemplo, decidir cuando, como, en que forma, y a quien se el reporta los avances de ejecución del proyecto.

Negociación

La negociación involucra conferir con otros de manera que se llegue a términos o se llegue a un entendimiento. Los acuerdos pueden ser negociados directamente o asistidos; la mediación y el arbitramento son dos tipos de negociación asistida.

La negociación ocurre alrededor de muchos tópicos, muchas veces, y a muchos niveles del proyecto. Durante el curso típico de un proyecto, el personal del proyecto tendrá que probablemente negociar alguna o todas de las siguientes:

• Alcance, costo, y objetivos de la programación.
• Cambios al alcance, costo, y programación.
• Términos y condiciones del contrato.
• Asignaciones.
• Recursos.

Resolución de Problemas

La resolución de problemas involucra la combinación de la definición de problemas y la toma de decisiones. Se preocupa con problemas que ya han ocurrido (en oposición a la administración de riesgos que nombra problemas potenciales).

La definición del problema requiere distinguir entre causas y síntomas. Los problemas pueden ser internos (un empleado clave es reasignado a otro proyecto) o externos (un permiso requerido para comenzar el trabajo, se retrasa). Los problemas pueden ser técnicos (diferencias de opinión sobre la mejor manera de diseñar un producto), administrativos (un grupo funcional no esta produciendo de acuerdo al plan), o interpersonales (choques de personalidad o estilos).

La toma de decisiones incluye analizar el problema para identificar soluciones viables, y luego tomar una decisión de esas posibles soluciones. Las decisiones pueden ser hechas u obtenidas (del cliente, del equipo, o de un administrador funcional). Una vez hecha, la decisión debe ser implementada. Las decisiones también tiene un elemento de tiempo en ellas – la decisión "correcta" puede no ser la "mejor" decisión si se hace o muy temprano o muy tarde.

Influenciando la Organización

Influenciando la Organización involucra la habilidad "para hacer las cosas". Requiere un entendimiento de tanto las estructuras formales como informales de todas las organizaciones involucradas – la organización ejecutora, contratistas, y tantas otras como sea apropiado. Influenciar la organización también requiere un entendimiento de la mecánica del poder y la política.

Tanto el poder como la política son usados aquí en su sentido positivo. Pfeffer [5] define el poder como "la habilidad potencial para influenciar el comportamiento, cambiar el curso a los eventos, sobreponerse a la resistencia, y hacer que las personas hagan cosas que de otra manera no harían". De manera similar, Eccles [6] dice que "la política trata de conseguir acción colectiva de un grupo de personas que pueden tener intereses muy diferentes. Trata de estar dispuesto a utilizar el conflicto y el desorden de manera creativa. El sentido negativo, es claro, se deriva del hecho que trata de reconciliar estos intereses resultando en una lucha por el poder y juegos organizacionales que a veces pueden tener una vida propia poco productiva".

Influencias Socioeconómicas

De manera similar a la administración general, las influencias socioeconómicas incluyen un amplio rango de tópicos y temas. El equipo administrativo de proyectos debe entender que las condiciones actuales y tendencias en esta área pueden tener un efecto muy grande en su proyecto: Un pequeño cambio acá se puede traducir, usualmente con una holgura de tiempo, en efectos cataclísmicos en todo el proyecto. De todas las influencias socioeconómicas potenciales, las principales categorías que afectan los proyectos se describen brevemente a continuación.

Standards y Regulaciones

La Organización Internacional para la Estandarización (ISO) hace diferenciación entre standards y regulaciones como se muestra a continuación [7]:

• Un standard es un "documento aprobado por un cuerpo reconocido, que provee, para el uso común y repetido, reglas, marcos de referencia, o características para productos, procesos o servicios con los cuales el cumplimiento no es mandatorio". Hay numerosos standards en uso que cubren virtualmente todo desde la estabilidad térmica de líquidos hidraúlicos hasta el tamaño de diskettes para computadora.
• Una regulación es un "documento que describe procesos o características de servicios para productos, incluyendo las provisiones administrativas aplicables, con las cuales es obligación cumplir". Las normas de construcción son un ejemplo de regulaciones.

Se debe tener cuidado al discutir standards y regulaciones ya que hay una vasta área gris entre las dos, por ejemplo:

• Los standards muchas veces comienzan con marcos de referencia que describen una aproximación preferida, y luego, con su amplia adopción, se convierten en regulaciones de facto (e.g., el uso del Método de la Ruta Crítica para la programación de grandes obras de construcción).
• El cumplimiento puede ser mandatorio a diferentes niveles (e.g., por una agencia de gobierno, por la administración de la organización ejecutora, o por el equipo de administración de proyectos).

Para muchos proyectos, los standards y regulaciones (por cualquier definición) son bien conocidas y los planes de proyectos pueden reflejar sus efectos. En otros casos, la influencia no es conocida o poco conocida y se debe considerar bajo la Administración de Riesgo del Proyecto.

Internacionalización

A medida de que más y más organizaciones se involucran en trabajo que abarca varias fronteras nacionales, más y más proyectos cruzan fronteras también. Adicionalmente a las preocupaciones tradicionales por alcance, costo, tiempo, y calidad, el equipo de administración del proyecto debe también considerar los efectos de cambios de horario, fiestas religiosas y nacionales, requerimientos de viaje para reuniones cara a cara, la logísticas de teleconferencias, y las muchas veces diferencias políticas volátiles.

Influencias Culturales

La cultura es "la totalidad de los patrones de comportamiento transmitidos de la sociedad, arte, creencias, instituciones y todos los otros productos del esfuerzo del trabajo y pensamiento humano" [8]. Cada proyecto tiene que operar dentro de un contexto de una o más normas culturales. Esta área de influencia incluye aspectos políticos, económicos, demográficos, educativo, étnicos, religiosos, y otra áreas de práctica, creencias, y actitudes que pueden afectar la manera en que las personas y las organizaciones interactúan.

NOTAS

Procesos de Administración de Proyectos

La administración de proyectos es una tarea integrada – una acción, o falta de toma de acción, en un área usualmente afectará otras áreas. Las interacciones pueden ser directas y bien entendidas o pueden ser sutiles e inciertas. Por ejemplo, un cambio de alcance casi siempre afectará el costo del proyecto, pero puede afectar o no afectar la moral del equipo o la calidad del producto.

Estas interacciones muchas veces requieren canjes entre los objetivos del proyecto – la calidad de ejecución en un área puede ser mejorada únicamente al sacrificar la calidad de ejecución en otra. La administración de proyectos exitosa requiere administrar activamente estas interacciones.

Para ayudar a entender la naturaleza de estas interacciones de la administración de proyectos, y para enfatizar la importancia de la interacción, este documento describe la administración de proyectos en término de sus componentes procesales y sus interacciones. Este capítulo provee una introducción al concepto de la administración de proyectos, como un número de procesos encadenados y por lo tanto provee los fundamentos esenciales para el entendimiento de los procesos descritos de los Capítulos 4 y 12. Incluye las siguientes secciones:

3.1 Procesos de Proyecto

3.2 Grupos de Procesos

3.3 Interacciones de Procesos

3.4 La Personalización de las Interacciones de Procesos

Procesos de Proyecto

Los proyectos están compuestos de procesos. Un proceso es "una serie de acciones que tiene como consecuencia un resultado" [1]. Los procesos de proyecto son ejecutados por personas y generalmente caen en una de dos categorías:

• Los procesos de administración de proyectos se preocupan principalmente con describir y organizar el trabajo del proyecto. Los procesos de administración de proyectos que son aplicables a la mayoría de los proyectos, la mayoría del tiempo, se describen brevemente en este capítulo y en detalle en los Capítulos 4 al 12.
• Los procesos orientados al producto se preocupan principalmente con especificar y crear el producto del proyecto. Los procesos orientados al producto son típicamente definidos por el ciclo de vida del proyecto (discutido en la Sección 2.1) y varían de acuerdo con el área de aplicación (tal como se discute en el Apéndice F).

Los procesos de administración de proyectos y los procesos orientados al producto se traslapan e interactúan a través del proyecto. Por ejemplo, el alcance del proyecto no se puede definir en la ausencia de algún conocimiento básico de como crear el producto.

Procesos de Grupo

Los procesos de administración de proyecto se pueden organizar en cinco grupos de uno o más procesos cada uno:

• Procesos inicializadores — reconoce que un proyecto o fase deben comenzar y se comprometen a eso.
• Procesos de planeación — desarrollar y mantener un esquema trabajable para completar la necesidad del negocio para el cual el proyecto fue desarrollado.
• Procesos de ejecución — coordinar a las personas y otros recursos para desarrollar el plan.
• Procesos controladores — aseguran que los objetivos del proyecto sean cumplidos a través del monitoreo y medición de avance y tomar acción correctiva cuando sea necesario.
• Procesos de cierre — formalizan la aceptación del proyecto o fase y los llevan a una terminación ordenada.

Los grupos de proceso están encadenados por los resultados que producen – el resultado o producto de uno se convierte en la entrada "input" para otro. Entre los grupos de procesos centrales, los encadenamientos son iterativos – la planeación produce una ejecución con un plan de proyecto documentado en un principio y después provee actualizaciones documentadas al plan a medida que el proyecto progresa. Estas conexiones se ilustran en la Figura 3-1. Adicionalmente los grupos de procesos de administración de proyectos no son discretos, o eventos únicos; son actividades que traslapan que ocurren a varios niveles de intensidad a través de cada fase del proyecto. La Figura 3-2 ilustra como los grupos de procesos se traslapan y varían dentro de una fase.

Finalmente, las interacciones de los grupos de procesos pueden también atravesar fases de tal manera que la finalización de una fase provea entradas o input para la iniciación de otra. Por ejemplo, la terminación de una fase de diseño requiere la aceptación del cliente del documento de diseño. Simultáneamente el documento de diseño describe el producto para la fase subsiguiente de implementación. Esta interacción se describe en la Figura 3-3.

Repetir el proceso de iniciación al comienzo de cada fase ayuda a mantener el proyecto enfocado en el negocio para el cual fue desarrollado. Debe ayudar también a asegurar que si el negocio ya no existe o no se necesita el proyecto se suspenderá, también en el caso si el proyecto tiene pocas probabilidades de satisfacer las necesidades del negocio. Las necesidades del negocio serán discutidas en más detalle en la introducción a la Sección 5.1, de Iniciación.

A pesar de que la Figura 3-3 se dibuja con fases discretas y procesos discretos, en un proyecto real habrán muchos traslapos. El proceso de

planeación, por ejemplo, no solo debe proveer detalles que se necesitan para terminar exitosamente la fase en ejecución del proyecto sino que también debe proveer alguna descripción preliminar de trabajo que se hará en fases subsiguientes. Este detallamiento progresivo del plan de proyecto es muchas veces llamado planeación por olas.

Interacción de Procesos

Dentro de cada grupo de proceso, los procesos individuales están encadenados por sus salidas y entradas. Al enfocarse en estos encadenamientos, podemos describir cada proceso en término de:

• Input o entradas — documentos o ítems documentables sobre los que se actuará.
• Herramientas y técnicas — los mecanismos aplicados a las entradas para crear las salidas.
• Salidas — documentos o ítems documentables que son el resultado de un proceso.

Los procesos de administración de proyectos comunes a la mayoría de los proyectos en la mayoría de las áreas de aplicación, se listan aquí y se describen en detalle en los Capítulos 4 al 12. Los números en paréntesis después de los nombres de los procesos identifican al capítulo y sección donde se describen. Los procesos de interacción descritos aquí son también típicos para la mayoría de los proyectos en la mayoría de las áreas de aplicación. La Sección 3.4 discute como personalizar tanto los procesos descriptivos como sus interacciones.

Procesos de Inicialización

La Figura 3—4 ilustra el único proceso en este grupo de procesos.

• La inicialización (5.1) — es comprometer a la organización a ejecutar la siguiente fase del proyecto.

Proceso de Planificación

La planeación es de gran importancia para el proyecto porque el proyecto involucra hacer cosas que no se han hecho antes. Como resultado, hay relativamente más procesos en esta sección. Sin embargo, el número de procesos no quiere decir que la administración de proyectos consiste primordialmente de la planeación – la cantidad de planeación ejecutada debe conmesurarse con el alcance del proyecto y la utilidad de la información desarrollada.

Las relaciones entre los procesos de planeación del proyecto se muestra en la Figura 3-5 (esta gráfica es una explosión del elipse llamado "procesos de planeación" en la Figura 3-1). Los procesos están sujetos a una frecuente iteración antes de completarse el plan. Por ejemplo, si la fecha inicial de terminación es inaceptable, los recursos del proyecto, costos, o inclusive el alcance tendrá que ser redefinido. Adicionalmente, la planeación no es una ciencia exacta – dos equipos diferentes pueden generar dos planes muy diferentes para un mismo proyecto.