Prefacio El Marco de la Administración de Proyectos



Descargar 0.9 Mb.
Página2/17
Fecha de conversión11.01.2017
Tamaño0.9 Mb.
1   2   3   4   5   6   7   8   9   ...   17

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.
1   2   3   4   5   6   7   8   9   ...   17


La base de datos está protegida por derechos de autor ©bazica.org 2016
enviar mensaje

    Página principal