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:

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.

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.

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

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.

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.

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.

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

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.

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

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.

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.

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.

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.

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.

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

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.

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.

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

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.

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.

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.

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.

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.

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:

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.

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.

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.

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.

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.

Procesos de Núcleo. Algunos procesos de planeación tienen claras dependencias que requieren que sean ejecutados de la misma manera en la mayoría de los proyectos. Por ejemplo, las actividades deben ser definidas antes de que sean programadas o costeadas. Estos procesos de planeación de núcleo pueden ser iterados varias veces durante una o cualquier fase de un proyecto. Estos incluyen:

• Planeación de Alcance (5.2) — desarrollar un alcance escrito como la base para decisiones futuras del proyecto.
• Definición del Alcance (5.3) — subdividir los paquetes de entrega de un proyecto en componentes más pequeños y más manejables.
• Definición de Actividades (6.1) — identificar las actividades específicas que deben de ser ejecutadas para producir los diferentes paquetes del proyecto.
• Secuencias de Actividades (6.2) — identificar y documentar las dependencias entre actividades.
• Estimación de la Duración de la Actividad (6.3) — estimar el número de períodos de trabajo que se requieren para completar las actividades individuales.
• Desarrollo de la programación (6.4) — analizar las secuencias de actividades, duraciones de actividades, y requerimientos de recursos para crear la programación del proyecto.
• Planeación de Recursos (7.1) — determinar que recursos (personas, equipos, materiales) y en que cantidades se deben usar para ejecutar las actividades del proyecto.
• Estimación de Costos (7.2) — desarrollar una aproximación (estimación) de los costos de los recursos que se requieren para completar las actividades del proyecto.
• Presupuestación de Costos (7.3) — distribuir el estimativo de costos global a los ítems individuales de trabajo.
• Desarrollo de Plan de Proyecto (4.1) — tomar los resultados de otros procesos de planeación y colocarlos en un documento consistente y coherente.

Procesos Facilitadores. La interacciones entre los otros procesos de planeación dependen más de la naturaleza del proyecto. Por ejemplo, en algunos proyectos puede haber poco o ningún riesgo identificable hasta después que el equipo ha hecho la mayor parte de la planeación, y este reconoce que los costos y las fechas programadas son extremadamente agresivas y por lo tanto involucran un riesgo considerable. Aunque estos procesos facilitadores son ejecutados intermitentemente en la medida que lo necesite la planeación del proyecto, no son opcionales. Ellos incluyen:

• Planeación de la Calidad (8.1) — identificar cual es el standard de la calidad que es relevante al proyecto y determinar como satisfacerlo.
• Planeación Organizacional (9.1) — identificar, documentar, asignar roles de proyecto, responsabilidades, y relaciones para los reportes.
• Adquisición del Staff (9.2) — conseguir los recursos humanos y asignarlos al trabajo del proyecto.
• Planeación de las Comunicaciones (10.1) — determinar que información y comunicaciones se necesitan para los partidos interesados: Quien necesita que información, cuando la van a necesitar, y de que manera se les va a dar.
• Identificación del Riesgo (11.1) — determinar que riesgos tendrán posibilidad de afectar el proyecto y documentar las características de cada uno.
• Cuantificación del Riesgo (11.2) — evalúa el riesgo y las interacciones del riesgo para cuantificar el rango de posibles resultados del proyecto.
• Desarrollo de Respuesta al Riesgo (11.3) — definir pasos constructivos para dar respuesta a oportunidades o respuestas a amenazas.
• Planeación de la procuración (12.1) — determinar que comprar y cuanto.
• Planeación de Solicitación (12.2) — documentar requerimientos de producto e identificar posibles proveedores.

Los procesos de ejecución incluyen procesos de núcleo y procesos facilitadores tal como se describe en la Sección 3.3.2., Procesos de Planeación. La Figura 3-6 ilustra como los siguientes procesos interactúan:

• Plan de Ejecución del Proyecto (4.2) — llevar a cabo el plan del proyecto al ejecutar las actividades incluidas.
• Verificación del Alcance (5.4.) — formalizar la aceptación del alcance del proyecto.
• Aseguranza de la Calidad (8.2) — evaluar la totalidad de la ejecución del proyecto sobre una base regular para proveer la confianza de que el proyecto va a satisfacer los standard de calidad relevantes.
• Desarrollo del Equipo (9.3) — desarrollar habilidades individuales o de grupo para mejorar la ejecución del proyecto.
• Distribución de la información (10.2) — hacer que la información solicitada sea disponible para los partidos interesados de manera oportuna.
• Solicitación (12.3) — obtener cotizaciones, pliegos, ofertas, u ofertas de manera apropiada .
• Selección de Fuentes (12.4) — el proceso de escogencia entre proveedores potenciales.
• Administración del Contrato (12.5) — administrar la relación con el proveedor.

La ejecución del proyecto debe ser medida regularmente para identificar varianzas significativas con el plan. Estas varianzas son alimentadas a los procesos de control en las diferentes áreas del conocimiento. En la medida que estas varianzas significativas sean observadas (i.e., aquellos que pongan en jaque los objetivos del proyecto), ajustes al plan son hechos al repetir los procesos de planeación apropiados. Por ejemplo, una fecha de terminación de una actividad que no se cumpla puede requerir ajustes al plan de personal existente, depender de horas extras, o hacer un intercambio entre el presupuesto y los objetivos de la programación. Controlar también incluye tomar acción preventiva de forma anticipada a problemas posibles.

El grupo de procesos controladores contiene procesos de núcleo y procesos facilitadores tal como se describe en la Sección 3.3.2. Procesos Planificadores.

La Figura 3-7 ilustra como los siguientes procesos interactúan:

• Control de Cambios General (4.3) — coordinar los cambios a través de todo el proyecto.
• Control de Cambio del Alcance (5.5.) — controlar los cambios del alcance del proyecto.

La Figura 3-8 ilustra como los siguientes procesos interactúan:

• Cierre Administrativo (10.4) — generar, recoger, y diseminar información para formalizar el cierre de una fase o de terminación de un proyecto.
• Cierre del Contrato (12.6) — completar y negociar un contrato, incluyendo la resolución de cualquier ítem abierto.

Los procesos identificados y las interacciones ilustradas en la Sección 3.3 pasan el examen de la aceptación general - estos se aplican a la mayoría de los proyectos la mayoría de las veces. Sin embargo, no todos los procesos se necesitaran en todos los proyectos, y no todas las interacciones aplicaran a todos los proyectos. Por ejemplo:

• Una organización que haga uso extensivo de contratistas puede describir explícitamente en que lugar del proceso de planeación ocurren los procesos de procuración.
• La ausencia de un proceso no significa que este no deba ser ejecutado. El equipo de administración del proyecto debe identificar y administrar todos los procesos que se requieren para asegurar un proyecto exitoso.
• Los proyectos que son dependientes de recursos únicos (desarrollo comercial de software, biofarmacéuticos, etc.) pueden definir roles y responsabilidades previas a la definición del alcance, ya que lo que se puede ejecutar puede ser una función de quien esta disponible para hacerlo.
• Algunas salidas de procesos pueden ser predefinidas como restricciones. Por ejemplo, la administración puede especificar una fecha meta de terminación en vez de dejar que sea determinada por el proceso de planeación.
• Los proyectos grandes pueden necesitar relativamente más detalle. Por ejemplo, la identificación del riesgo puede ser subdividida para enfocarse separadamente sobre identificación de riesgos de costo, riesgos de programación, riesgos técnicos, o riesgos de calidad.
• En subproyectos o proyectos más pequeños puede haber relativamente menos esfuerzo en procesos cuyas salidas han sido determinadas a nivel del proyecto (e.g., un subcontratista puede ignorar riesgos explícitamente asumidos por el contratista general) o en procesos que proveen solamente una utilidad marginal (puede no haber un plan formal de comunicaciones para un proyecto de cuatro personas).
• Donde haya necesidad de hacer un cambio, el cambio debe ser claramente identificado, cuidadosamente evaluado y administrado de manera activa.

La Administración de La Integración del Proyecto incluye los procesos requeridos para asegurar que los elementos varios del proyecto están apropiadamente coordinados. Involucra hacer canjes entre los objetivos que compiten entre si y alternativas de manera que se puedan cumplir o exceder las necesidades y expectativas de los partidos interesados. Mientras que todos los procesos administrativos del proyecto son integrativos hasta cierto punto, los procesos descritos en este capítulo son primariamente integrativos. La Figura 4-1 muestra una vista general de los principales procesos.

Estos procesos interactúan entre ellos y con otros procesos de otras áreas de conocimiento. Estos procesos pueden involucrar el esfuerzo de uno o más individuos o de grupos de individuos basados en las necesidades del proyecto. Cada procesos ocurre al menos una vez en cada fase del proyecto.

Aunque los procesos presentados aquí se muestran como elementos discretos con interfaces bien definidas, en la práctica se pueden traslapar e interactuar en maneras que no se detallan aquí. Los procesos de interacción se discuten en detalle en el Capítulo 3.

Los procesos, herramientas, y técnicas usadas para integrar los procesos administrativos del proyecto son el enfoque de este capítulo. Por ejemplo, la administración de integración del proyecto entra a jugar cuando un estimativo de costos se necesita para un plan de contingencia o cuando se debe identificar el riesgo asociado a varias alternativas de asignación de personal al proyecto. Sin embargo, para que un proyecto se pueda completar exitosamente, la integración debe ocurrir en un número de otras áreas también. Por ejemplo:

• El trabajo del proyecto debe ser integrado con las operaciones sucesivas de la organización ejecutora.
• El alcance del proyecto y alcance del producto deben ser integrados (la diferencia entre el alcance del producto y el proyecto se discute en la introducción del Capítulo 5).
• Productos de diferentes especialidades funcionales (tales como dibujos civiles, eléctricos, y mecánicos que se necesitan para un proyecto de diseño de ingeniería) deben ser integrados.

• Ejecución guiada del proyecto
• Cosas que se asumen del documento de planeación del proyecto.
• Decisiones del documento de planeación del proyecto referentes a las alternativas que se toman.
• Facilitar la comunicación entre partidos interesados.
• Definir puntos de vista claves administrativos respecto al contenido, extensión, y tiempo.
• Proveer una línea de base para medir el progreso y control del proyecto.

• Administración de la calidad — procesos de auditoria y metas de mejoramiento continuo.
• Administración de personal — guías para contratación y despidos, y métodos para la evaluación de personal.

1. Restricciones. Las restricciones son factores que van a limitar las opciones del equipo administrativo del proyecto. Por ejemplo, un presupuesto predefinido es una restricción que muy probablemente limitará las opciones del equipo del proyecto en lo concerniente a alcance, asignación de personal, y programación.

Cuando un proyecto es ejecutado bajo un contrato, las provisiones contractuales generalmente serán restricciones a esta.

2. Suposiciones. Las suposiciones son factores que para los procesos de planeación serán consideras como verdaderas, reales, o ciertas. Por ejemplo, si la fecha en que una persona clave estará disponible es incierta, el equipo puede asumir una fecha de comienzo específica. Las suposiciones generalmente involucran algún grado de riesgo.

1. Metodología de planeación del proyecto. Una metodología para la planeación del proyecto es cualquier aproximación estructurada que se usa para guiar al equipo de administración del proyecto durante el desarrollo del plan del proyecto. Puede ser tan simple como formas standard o preimpresas (ya sean de papel o electrónicas formales o informales) o tan complejas como una serie de simulaciones requeridas (e.g., análisis de Montecarlo para riesgo). La mayoría de las metodologías para planeación de proyectos hacen uso de una combinación de herramientas "duras" tales como software de administración de proyectos y herramientas "blandas" tales como comités facilitadores e iniciadores.
2. Habilidades y conocimientos de los partidos interesados. Cada partido interesado tiene habilidades y conocimientos que pueden ser de uso en el desarrollo del plan del proyecto. El equipo administrador del proyecto debe crear un ambiente en el cual los partidos interesados puedan contribuir apropiadamente (véase también la Sección 9.3, Desarrollo del Equipo). Quien contribuye, y que contribuyen, y como puede variar. Por ejemplo:

• En un proyecto en construcción bajo un contrato de suma global, el ingeniero de costo profesional hará una contribución significativa a la meta de rentabilidad durante la preparación de la licitación cuando el valor del contrato este siendo determinado.
• En un proyecto donde la asignación de personal se define de antemano, los contribuyentes individuales pueden contribuir significativamente para alcanzar las metas de costos y programación al evaluar duraciones y esfuerzos para que los estimativos sean razonables.

1. Sistemas de información de administración de proyectos (PMIS). Un sistema de información para administración de proyectos consiste de las herramientas y técnicas usadas para recoger, integrar, y diseminar las salidas de los otros procesos de administración de proyectos. Se usa para darle soporte a todos los aspectos del proyecto desde su iniciación hasta su finalización y generalmente incluye tanto sistemas automáticos como manuales.

1. Plan del proyecto. El plan del proyecto es un documento formal, aprobado, usado para administrar y controlar la ejecución del proyecto. Debe ser distribuido como se define en el plan de comunicaciones del proyecto (e.g., la administración de la organización ejecutora puede requerir una cobertura amplia con poco detalle, mientras que un contratista puede requerir detalles completos de un solo tema). En algunas áreas de aplicación, el término plan de proyecto integrado se usa para referirse a este documento.

Se debe hacer una distinción clara entre el plan del proyecto y la línea de base para la medición de la ejecución del proyecto. El plan del proyecto es un documento o colección de documentos que se espera que cambie varias veces sobre el tiempo a medida que más información se hace disponible sobre el proyecto. La línea de base para la medición de la ejecución representa un control administrativo que generalmente solo cambia intermitentemente y generalmente solo en respuesta a un cambio aprobado del alcance del proyecto.

Hay muchas maneras para organizar y presentar el plan del proyecto, pero comúnmente incluye todos los siguientes (estos ítems se describen en más detalle en otro lugar del documento):

• Charter del proyecto.
• Una descripción de la aproximación o estrategia administrativa del proyecto (un resumen de los planes individuales de las otras áreas de conocimiento).
• Un documento de alcance, que incluye tanto los productos del proyecto como los objetivos de este.
• Una estructura de desglose de trabajo (WBS) hasta el nivel en el que el control será ejecutado.
• Estimativos de costos, fechas programadas de comienzo, y la asignación de responsabilidades hasta el nivel en el que se ejecutará el control al WBS.
• Líneas de base para la medición de la ejecución del cronograma y costos.
• Hitos principales y las fechas metas para estos.
• Personal clave o requerido.
• Riesgos claves, incluyendo restricciones y suposiciones, y las respuestas planeadas para cada una de ellas.
• Planes administrativos subsidiarios, incluyendo planes administrativos y de alcance, plan de administración del cronograma, etc.
• Decisiones pendientes y otros temas abiertos.
• Otras salidas de la planeación del proyecto deben ser incluidas en el plan formal basado en las necesidades individuales de cada proyecto. Por ejemplo, el plan de proyecto para un proyecto grande generalmente incluye un organigrama del proyecto.

1. Detalle de soporte. El detalle de soporte para el plan de proyecto incluye:

• Salidas de otros procesos de planeación que no están incluidos en el plan del proyecto.
• Información adicional o documentación generada durante el desarrollo del plan del proyecto (e.g., restricciones y suposiciones que no eran previamente conocidas).
• Documentación técnica tal como requerimientos, especificaciones, y diseños.
• Documentación de standards relevantes.

Este material debe ser organizado de tal manera que se facilite su uso durante la ejecución del plan del proyecto.

1. Ejecución del Plan del Proyecto

La ejecución del plan del proyecto es el proceso primario para llevar a cabo el plan del proyecto - la gran mayoría del presupuesto del proyecto será utilizado al ejecutar este proceso. En este proceso, el administrador de proyectos y el equipo de administración de proyectos deben coordinar y dirigir las varias interfaces técnicas y organizacionales que existan en el proyecto. Es el proceso del proyecto que más directamente se ve afectado por el área de aplicación del proyecto debido a que el producto del proyecto es creado directamente aquí.

2. Herramientas y Técnicas para la Ejecución del Plan del Proyecto

1. Habilidades de administración general. Habilidades de administración general tales como liderazgo, comunicación, y negociación son esenciales para la ejecución efectiva del plan del proyecto. Las Habilidades de administración general están descritas en la Sección 2.4.
2. Habilidades del producto y conocimiento. El equipo del proyecto debe tener acceso a unas habilidades y conocimiento del producto del proyecto que sean adecuadas. Las habilidades necesarias son definidas como parte de la planeación (especialmente en la planeación de recursos, Sección 7.1.) y se provee a través del proceso de adquisición de personal (tal como se describe en la Sección 9.2.)
3. Sistema de autorización de trabajo. Un sistema de autorización de trabajo es un procedimiento formal para sancionar el trabajo del proyecto para asegurar que un trabajo se hace en el momento adecuado y en una secuencia apropiada. El mecanismo primario es típicamente una autorización escrita para comenzar trabajo en una actividad específica o paquete de trabajo.

El diseño del sistema de autorización de trabajo deberá balancear el valor del control que provee con el costo de ese control. Por ejemplo, en proyectos pequeños las autorizaciones verbales serán adecuadas.

4. Reuniones para evaluación del status. Las reuniones para evaluación del status son reuniones programadas regularmente las cuales se sostienen para intercambiar información sobre el proyecto. En la mayoría de los proyectos estas reuniones se sostendrán a diferentes frecuencias a diferentes niveles (e.g., el equipo administrativo del proyecto sostendrá reuniones internas semanalmente, y mensualmente con el dueño).
5. Sistema de información de administración del proyecto. El sistema de información de administración del proyecto se describe en la Sección 4.1.2.3.
6. Procedimientos organizacionales. Todas y algunas de las organizaciones involucradas en el proyecto pueden tener procedimientos formales o informales de utilidad durante la ejecución del proyecto.

2. Salidas del Plan de Ejecución del Proyecto

1. Resultados del trabajo. Los resultados del trabajo son los resultados de las actividades ejecutadas para llevar a cabo el proyecto. La información sobre los resultados del trabajo - que metas han sido completadas y cuales no, y hasta que punto se cumplen las normas de calidad, y en que costos se ha incurrido o comprometido, etc. - se recolectan como parte del plan de ejecución del proyecto y se alimentan al proceso de reporte de avance (vea la Sección 10.3. para una discusión más detallada de los reportes de avance).
2. Ordenes de cambio. Las ordenes de cambio (e.g., para expandir o contraer el alcance del proyecto, para modificar costos o estimativos del cronograma, etc.) muchas veces se identifican mientras que se ejecuta el trabajo del proyecto.

3. Control de Cambios General

El control de cambios general se preocupa con (a) influenciar los factores que crean cambios para asegurar que los cambios son beneficiosos, (b) determinar que un cambio a ocurrido, y (c) administrar los cambios reales cuando y como ocurren. El control de cambios general requiere:

• Mantener la integridad de las líneas de base para la medición de avance - todos los cambios aprobados se deberán reflejar en el plan del proyecto, pero solo los cambios al alcance del proyecto deberán afectar la línea de base para la medición de avance.
• Asegurarse que los cambios al alcance del producto se reflejen en la definición del alcance del proyecto (la diferencia entre el alcance del proyecto y del producto se discute en la introducción al Capítulo 5).
• Coordinar los cambios a través de las áreas del conocimiento como se ilustra en la Figura 4-2. Por ejemplo, un cambio propuesto al cronograma muchas veces afectará al costo, riesgo, calidad y personal.

1. Técnicas y Herramientas para el Control de Cambios General

• Identificar y documentar las características físicas y funcionales de un ítem o sistema.
• Controlar cualquier cambio a tales características.
• Grabar y reportar el cambio y su status de implementación.
• Auditar los ítemes y sistemas para verificar su adhesión a los requerimientos [1].

En muchas áreas de aplicación la administración de la configuración es un subjuego del sistema de control de cambios y se usa para asegurar que la descripción del producto del proyecto está correcta y completa. Sin embargo, en algunas áreas de aplicación, el término administración de la configuración se usa para describir cualquier sistema de control de cambios riguroso.

1. Medición de la ejecución. Las técnicas para la medición de la ejecución tales como el valor ganado (tal como se describe en la Sección 10.3.2.4.) ayudan a averiguar si las varianzas del plan original requieren acción correctiva.
2. Planeación adicional. Los proyectos raras veces se ejecutan exactamente de acuerdo con el plan. Cambios posibles tal vez requieran de costos estimados nuevos o revisados, secuencias de actividad modificadas, análisis de respuesta de riesgos alternativas, u otros ajustes al plan del proyecto.
3. Sistema de información de administración de proyectos. Los sistemas de información de administración de proyectos se describen en la Sección 4.1.2.3.

1. Salidas del Control de Cambios General

1. Actualizaciones al plan de proyectos. Las actualizaciones al plan de proyectos son cualquier modificación al contenido del plan de proyectos al detalle de soporte (tal como se describe en las Secciones 4.1.3.1. y 4.1.3.2., respectivamente) los partidos interesados apropiados se notificaran en la medida que sean necesario.
2. Acción correctiva. La acción correctiva se describe en la Sección 4.2.1.4.
3. Lecciones aprendidas. Las causas de las varianzas, el raciocinio detrás de las acciones correctivas escogidas, y otros tipos de lecciones aprendidas deberán ser documentadas para que estas se vuelvan parte de la base de datos histórica tanto para este proyecto como para otros proyectos de la organización ejecutora

La administración del alcance del proyecto incluye los procesos requeridos para asegurar que el proyecto incluye todo trabajo requerido, y solo el trabajo requerido, para completar el proyecto exitosamente [1]. Se preocupa primariamente con definir y controlar que y que no se incluye en el proyecto. La Figura 5-1 provee una vista general de los principales procesos de la administración del alcance del proyecto:

Estos procesos interactuan entre ellos y con otros procesos de otras áreas de conocimiento. Cada proceso puede involucrar el esfuerzo de uno o más individuos, o grupos de individuos basado en las necesidades del proyecto. Cada proceso ocurre generalmente al menos una vez en cada fase del proyecto.

Aunque los procesos aquí se presentan como elementos discretos, con interfaces bien definidas, en la práctica ellos se pueden traslapa e interactúa de maneras que no se detallan aquí.

Los procesos de interacción se discuten en detalle en el Capítulo 3.

En el contexto del proyecto, el término "alcance" se refiere a:

• Alcance del producto - los rasgos distintivos y funciones que se deberán incluir en el producto servicio
• Alcance del proyecto - el trabajo que se deberá hacer para la entrega de un producto con ciertas especificaciones y funciones.

Los procesos, herramientas y técnicas usados para administrar el alcance del proyecto son del enfoque de este capítulo. Los procesos, herramientas, y técnicas usadas para administrar el alcance del producto varían de acuerdo con el área de aplicación y usualmente están definidos como parte del ciclo de vida del proyecto (el ciclo de vida del proyecto se discute en la Sección 2.1.).

Un proyecto consiste de un solo producto, pero ese producto puede incluir elementos subsidiarios, cada uno con su alcance del producto por separado pero interdependiente con los demás. Por ejemplo, un nuevo sistema telefónico generalmente incluiría cuatro elementos subsidiarios - Hardware, Software, entrenamiento e implementación del sistema.

La terminación del alcance del producto se mide contra sus requerimientos mientras que la terminación del alcance del proyecto se mide contra el plan. Ambos tipos de administración de alcance deben estar bien integrados para asegurar que el trabajo del proyecto resultará en la entrega del producto especificado.

La iniciación es el proceso de reconocer formalmente que un nuevo proyecto existe o que un proyecto existente debe continuar a su siguiente fase (Véase la Sección 2.1. para una discusión más detallada de las fases de un proyecto). Esta iniciación formal concatena el proyecto con el trabajo en marcha de la organización ejecutora. En algunas organizaciones, un proyecto no es formalmente iniciado hasta después de la terminación de un estudio de factibilidad, un plan preliminar, o algún otro tipo de análisis equivalente que en si fue iniciado por separado. Algunos tipos de proyectos, en especial proyectos de servicio interno y proyectos de desarrollo de nuevos productos, son iniciados de manera informal y una cantidad limitada de trabajo es ejecutada para asegurar los permisos necesarios para su iniciación formal. Los proyectos son autorizados típicamente como resultado de una o más de las siguientes:

• Una demanda del mercado (e.g., una compañía petrolera autoriza la construcción de una nueva refinería en respuesta a una escasez crónica de gasolina).
• Una necesidad del negocio (e.g., una compañía de entrenamiento autoriza crear un nuevo curso para poder incrementar sus entradas).
• Una demanda de un cliente (e.g., una empresa de servicios públicos autoriza construir una nueva subestación, para prestarle el servicio a un nuevo parque industrial).
• Un avance tecnológico (e.g., una firma electrónica autoriza un nuevo proyecto para desarrollar un nuevo juego de vídeo, después de la introducción de una grabadora de casetes de vídeo).
• Un requerimiento legal (e.g., un productor de pinturas autoriza un proyecto para establecer las guías para el manejo de sustancias tóxicas).

Estos estímulos también se pueden llamar problemas, oportunidades, o requerimientos del negocio. El tema central de todos estos términos es que la administración debe tomar una decisión acerca de como responder a ellos.

1. Métodos de selección de proyectos. Los métodos de selección de proyectos generalmente caen en una de dos categorías amplias [2]:

• Método de medición del beneficio — aproximaciones comparativas, modelos de puntaje, contribución del beneficio, o modelos económicos.
• Métodos de optimización restringidos — modelos matemáticos usando algoritmos de programación lineales, no lineales, dinámicos, de números enteros, y multiobjetivos.

Se refiere a estos métodos muchas veces como modelos de decisión. Los modelos de decisión incluyen técnicas generalizadas (arboles de decisión, escogencia forzada, y otros) como también otros especializados (Procesos Jerárquicos Analíticos, Análisis de Estructura Lógica, y otros) aplicar un criterio de selección de proyecto compleja, en un modelo sofisticado es mucha veces tratado como una fase por separado del proyecto.

1. Opinión experta. La Opinión experta será requerida muchas veces para acelerar las entradas a este proceso. Tal experiencia puede ser proveída por cualquier grupo o individuo con conocimiento o entrenamiento especializado y esta disponible de muchas otras fuentes que incluyen:

• Otras unidades dentro de la organización ejecutora.
• Consultores
• Profesionales y asociaciones técnicas.
• Grupos de industria

1. Charter del proyecto. Un charter del proyecto es un documento que reconoce formalmente la existencia de un proyecto. Este deberá incluir, directamente o por medio de referencias con otros documentos lo siguiente:

• La necesidad del negocio para la cual en proyecto fue creado.
• La descripción del producto (tal como se describe en la Sección 5.1.1.1.)

El charter del proyecto deberá ser generado por un administrador externo al proyecto y a un nivel apropiado para las necesidades del proyecto. El provee al administrador del proyecto con la autoridad para aplicar recursos organizacionales a las actividades del proyecto.

Cuando un proyecto es ejecutado bajo contrato, el contrato firmado generalmente servirá como charter del proyecto para el vendedor.

1. La identificación/asignación del administrador del proyecto. En general, el administrador del proyecto deberá ser identificado y asignado tan tempranamente como sea posible. El administrador del proyecto siempre deberá ser asignado con anterioridad al comienzo del plan de ejecución del proyecto (tal como se describe en la Sección 4.2.) y preferiblemente mucho antes que la planeación del proyecto se haya hecho (los procesos de planeación del proyecto se describen en la Sección 3.3.2.).
2. Restricciones. Las restricciones son factores que limitaran las opciones del equipo administrativo del proyecto. Por ejemplo, un presupuesto predefinido es una restricción que muy seguramente limitará las opciones que tiene el equipo administrador con respecto al alcance, personal, y programación.

Cuando un proyecto se ejecuta bajo un contrato, las provisiones contractuales generalmente serán restricciones.

3. Suposiciones. Las suposiciones son factores que, para propósitos de planeación, se consideraran como ciertas, reales, o seguras. Por ejemplo, si la fecha en que una persona clave se pueda hacer disponible es incierta, el equipo puede asumir una fecha específica de comienzo. Las suposiciones generalmente involucran un grado de riesgo. Estas se podrán identificar aquí o pueden ser el resultado de una identificación de riesgo (como se describe en la Sección 11.1).

La planeación del alcance es el proceso de desarrollar un documento escrito del alcance que sirva como base para la toma futura de decisiones, en particular, el criterio usado para determinar si el proyecto o fase ha sido completado exitosamente. Un documento escrito del alcance es necesario tanto para proyectos y subproyectos. Por ejemplo, una firma de ingeniería es contratada para diseñar una planta de procesamiento de petróleos que deberá tener un documento de alcance que describa las fronteras de trabajo de diseño de subproyecto. El documento de alcance forma una base de acuerdo entre el equipo del proyecto y el cliente del proyecto al identificar tanto los objetivos del proyecto como sus principales productos de entrega.

Si todos los elementos del documento del alcance están ya disponibles (e.g., un requerimiento para una propuesta puede identificar los principales productos de entrega, y el charter del proyecto puede definir los objetivos del proyecto), este proceso puede involucrar poco más que físicamente crear el documento escrito.