Gestión de proyectos

De Wikipedia, la enciclopedia libre
Saltar a navegación , búsqueda

La gestión de proyectos es la disciplina de la planificación, organización, motivación y control de los recursos para lograr objetivos específicos. Un proyecto es un esfuerzo temporal, con un principio y un final definidos (por lo general con limitaciones de tiempo y, a menudo limitadas por la financiación o entregas), [1] llevado a cabo para cumplir con las metas y objetivos únicos, [2] el valor general para lograr un cambio beneficioso o añadido . La naturaleza temporal de los proyectos está en contraste con lo de siempre (u operaciones) , [3] que son actividades repetitivas y funcionales permanentes o semi-permanentes para producir productos o servicios. En la práctica, la gestión de estos dos sistemas es a menudo bastante diferente, y como tal, requiere el desarrollo de distintas habilidades técnicas y estrategias de gestión.

El principal desafío de la gestión del proyecto es alcanzar todos los objetivos del proyecto [4] y los objetivos al tiempo que respeta las limitaciones preconcebidas. [5] Las limitaciones principales son el alcance , tiempo, calidad y presupuesto . [6] El ambicioso secundaria y más reto es optimizar la asignación de los insumos necesarios para integrarlos a satisfacer objetivos previamente definidos.

Contenido

[ editar ] Historia

Los soldados romanos construyen una fortaleza, la Columna de Trajano 113 dC

Hasta 1900 los proyectos de ingeniería civil fueron manejados generalmente por los arquitectos creativos, ingenieros y maestros de obras propias, por ejemplo Vitruvio (siglo I aC), Christopher Wren (1632-1723), Thomas Telford (1757-1834) y Isambard Kingdom Brunel (1806 - 1859). [7] Fue en la década de 1950 que las organizaciones comenzaron a aplicar sistemáticamente las herramientas de gestión de proyectos y técnicas para proyectos de ingeniería complejos. [8]

Henry Gantt (1861-1919), el padre de las técnicas de planificación y control

Como una disciplina de gestión de proyectos, desarrollados a partir de varios campos de aplicación, incluyendo la construcción civil, la ingeniería y la fuerte defensa actividad. [9] Dos antepasados ​​de gestión de proyectos son Henry Gantt , llamado el padre de técnicas de planificación y control, [10] que es famoso por su uso de la gráfica de Gantt como una herramienta de gestión de proyectos (como alternativa Harmonogram propuso por primera vez por Karol Adamiecki [11] ), y Henri Fayol por su creación de las cinco funciones de gestión que forman la base del conjunto de conocimientos asociados a los proyectos y programas gestión. [12] Ambos Gantt y Fayol eran estudiantes de Frederick Winslow Taylor 's teorías de la administración científica . Su trabajo es el precursor de las modernas herramientas de gestión de proyectos, incluyendo la estructura de desglose del trabajo (WBS) y la asignación de recursos .

La década de 1950 marcó el comienzo de la era moderna en la gestión de proyectos de ingeniería de campos básicos se unen para trabajar como uno solo. La gestión del proyecto se reconoció como una disciplina distinta derivada de la disciplina de gestión con el modelo de ingeniería. [13] En los Estados Unidos, antes de la década de 1950, los proyectos se gestionan sobre una base ad-hoc, que utiliza sobre todo los diagramas de Gantt y técnicas informales y herramientas. En ese momento, dos matemáticos de programación de proyectos modelos fueron desarrollados. El " Método del Camino Crítico "(CPM) se desarrolló como una joint venture entre DuPont Corporation y Remington Rand Corporation para la gestión de proyectos de mantenimiento de la planta. Y el " Programa de Evaluación y Revisión Técnica "o PERT, desarrollado por Booz Allen Hamilton como parte de la Marina de los Estados Unidos 's (en conjunto con la Corporación Lockheed ) Polaris misil submarino programa; [14] Estas técnicas matemáticas se extendió rápidamente en muchas empresas privadas.

PERT red para un proyecto de siete meses con cinco hitos

Al mismo tiempo, como la programación de proyectos, los modelos se están desarrollando tecnología para la estimación de costos del proyecto, gestión de costes, y la ingeniería económica fue evolucionando, con el trabajo pionero realizado por Hans Lang y otros. En 1956, la Asociación Americana de Ingenieros de gastos (ahora AACE Internacional , la Asociación para el Avance de la Ingeniería de Costos ) se formó en los primeros practicantes de la gestión de proyectos y las especialidades asociadas de planificación y programación, estimación de costos, control de costes y / plan (proyecto controlar). AACE continuó su trabajo pionero y en 2006 lanzó el primer proceso integrado para la cartera, gestión de programas y proyectos ( total Cost Management Framework).

El International Project Management Association (IPMA) fue fundada en Europa en 1967, [15] como una federación de varias asociaciones nacionales de gestión de proyectos. IPMA mantiene su estructura federal hoy y ahora incluye a las asociaciones miembros en todos los continentes excepto la Antártida. IPMA ofrece un programa de certificación de Nivel Cuatro basado en la base de competencia del IPMA (ICB). [16] El ICB cubre las competencias técnicas, contextuales y de comportamiento.

En 1969, el Project Management Institute (PMI) se formó en los EE.UU.. [17] PMI publica una guía para la Dirección de Proyectos del Conocimiento (PMBOK Guide), que describe las prácticas de gestión de proyectos que son comunes a la mayoría de los proyectos ", la mayoría de el tiempo ". PMI también ofrece múltiples certificaciones.

[ editar ] Enfoques

Hay una serie de enfoques para la gestión de las actividades del proyecto, incluidos los enfoques magras, Interative, incremental y por etapas.

Independientemente de la metodología empleada, la consideración cuidadosa se ​​debe dar a los objetivos generales del proyecto, cronograma y costo, así como las funciones y responsabilidades de todos los participantes y grupos de interés .

[ editar ] El enfoque tradicional

Un enfoque tradicional fases identifica una secuencia de pasos para ser completados. En el "enfoque tradicional", los cinco componentes de desarrollo de un proyecto se pueden distinguir (cuatro etapas más control):

Las fases típicas de desarrollo de un proyecto de ingeniería
  1. iniciación
  2. planificación y diseño
  3. ejecución y construcción
  4. vigilancia y control de los sistemas
  5. terminación

No todos los proyectos tendrán todas las etapas, los proyectos pueden ser terminados antes de llegar a su finalización. Algunos proyectos no siguen un proceso estructurado de planificación y / o proceso de seguimiento. Y algunos proyectos pasarán por las etapas 2, 3 y 4 varias veces.

Muchas industrias utilizan variaciones de estas etapas del proyecto. Por ejemplo, cuando se trabaja en un diseño de ladrillo-y-mortero y de la construcción, los proyectos normalmente se desarrollará en etapas como la pre-planificación, diseño conceptual, diseño esquemático, desarrollo de diseños, planos de construcción (o pliego de condiciones), y administración de la construcción. En el desarrollo de software , este enfoque es a menudo conocido como el modelo de cascada , [18] es decir, una serie de tareas después de otras en secuencia lineal. En el desarrollo de software, muchas organizaciones han adaptado el Rational Unified Process (RUP) para adaptarse a esta metodología, aunque RUP no requiere ni explícitamente recomienda esta práctica. Desarrollo Cascada funciona bien para proyectos pequeños, bien definidos, pero a menudo falla en los grandes proyectos de naturaleza indefinida y ambigua. El cono de incertidumbre explica algo de esto como la planificación hecha en la fase inicial del proyecto adolece de un alto grado de incertidumbre. Esto es especialmente cierto ya que el desarrollo de software es a menudo la realización de un producto nuevo o novedoso. En los proyectos en los requisitos no han sido finalizados y pueden cambiar, gestión de requisitos es utilizado para desarrollar una definición precisa y completa del comportamiento de software que puede servir como base para el desarrollo de software. [19] Aunque los términos pueden variar de una industria a otra , las etapas reales suelen seguir los pasos comunes para la resolución de problemas - "la definición del problema, que pesa opciones, elegir un camino, ejecución y evaluación".

[ edit ] PRINCE2

El PRINCE2 modelo de proceso

PRINCE2 es un enfoque estructurado para la gestión del proyecto, lanzado en 1996 como un método de gestión de proyectos genérico. [20] Se combina la metodología original PROMPT (que se convirtió en la metodología PRINCE) con MITP de IBM (gestión de la ejecución del proyecto total) metodología. PRINCE2 proporciona un método para la gestión de proyectos en un marco bien definido. PRINCE2 describe los procedimientos para coordinar personas y las actividades de un proyecto, la forma de diseñar y supervisar el proyecto, y qué hacer si el proyecto tiene que ser ajustado si no se desarrolla según lo previsto.

En el método, cada proceso se especifica con sus insumos y productos esenciales y con los objetivos específicos y las actividades que se llevarán a cabo. Esto permite un control automático de cualquier desviación del plan. Dividido en fases manejables, el método permite un control eficiente de los recursos. Sobre la base de una vigilancia estrecha, el proyecto puede llevarse a cabo de una manera controlada y organizada.

PRINCE2 proporciona un lenguaje común para todos los participantes del proyecto. Las funciones de gestión de responsabilidades y en un proyecto se describen con detalle y son adaptables para adaptarse a la complejidad del proyecto y las habilidades de la organización.

[ edit ] Prisma (Proyectos Integración de métodos sostenibles)

PRiSM [21] es un proceso basado en una metodología estructurada de gestión de proyectos que presenta áreas de sostenibilidad y los integra en cuatro fases principales del proyecto con el fin de maximizar las oportunidades para mejorar la sostenibilidad y el uso de recursos finitos.

El diagrama de flujo PRiSM

La metodología abarca la gestión, el control y la organización de un proyecto con la consideración y el énfasis más allá del proyecto de ciclo de vida y en los cinco aspectos de la sostenibilidad, People, Planet, Profit, Proceso y Producto. Se deriva del marco de la norma ISO: 21500 y ISO 14001, ISO 26000, ISO 9001 y PRiSM también se utiliza para referirse a la formación y acreditación de los profesionales autorizados de la metodología que debe realizar titulaciones homologadas basada en la competencia para obtener la certificación GPM . [22]

[ editar ] Crítica de la cadena de gestión de proyectos

Gestión Critical proyecto de cadena (CCPM) es un método de planificación y gestión de la ejecución del proyecto diseñado para hacer frente a las incertidumbres inherentes a la gestión de proyectos, teniendo en cuenta la disponibilidad limitada de recursos (habilidades físicas, humanas, así como la gestión y la capacidad de apoyo) necesario para ejecutar proyectos.

CCPM es una aplicación de la Teoría de Restricciones (TOC) a los proyectos. El objetivo es aumentar el flujo de proyectos en una organización ( rendimiento ). La aplicación de la primera de tres de los cinco pasos de enfoque de TOC, la restricción del sistema para todos los proyectos se identifica como son los recursos. Para explotar la restricción, las tareas de la cadena crítica se les da prioridad sobre todas las demás actividades. Finalmente, los proyectos se planifican y gestionan para asegurar que los recursos estén listos cuando las tareas fundamentales de la cadena debe comenzar, subordinando todos los demás recursos de la cadena crítica.

El plan del proyecto normalmente deben someterse a la nivelación de recursos , y la secuencia más larga de recursos limitados tareas deben ser identificados como la cadena crítica. En algunos casos, como en la gestión contratada sub-proyectos, es recomendable utilizar un método simplificado sin redistribución de recursos.

En entornos multi-proyecto, la nivelación de recursos se debe realizar a través de proyectos. Sin embargo, a menudo es suficiente para identificar (o simplemente seleccionar) un único "tambor". El tambor puede ser un recurso que actúa como una restricción a través de proyectos, que se escalonan sobre la base de la disponibilidad de ese único recurso.

También se puede utilizar un "tambor virtual" mediante la selección de una tarea o conjunto de tareas (normalmente puntos de integración ) y la limitación del número de proyectos en ejecución en ese momento.

[ editar ] La metodología de la cadena de eventos

Metodología cadena de eventos es otro método que complementa método del camino crítico y críticos de la cadena de metodologías de gestión de proyectos.

Metodología de eventos de la cadena es una técnica de modelado incertidumbre y la red del cronograma de análisis que se centra en la identificación y la gestión de eventos y cadenas de eventos que afectan a los programas del proyecto. Metodología cadena de eventos ayuda a mitigar el impacto negativo de la heurística y sesgos psicológicos, así como para permitir un fácil modelado de la incertidumbre en los programas de los proyectos. Metodología evento cadena se basa en los siguientes principios.

  • Momento probabilística del riesgo: Una actividad (tarea) en la mayoría de los procesos de la vida real no es un proceso uniforme y continua. Las tareas se ven afectados por los acontecimientos externos, que pueden ocurrir en algún punto en medio de la tarea.
  • Cadenas de eventos: Eventos pueden causar otros eventos, que van a crear cadenas de eventos. Estas cadenas de eventos puede afectar significativamente el curso del proyecto. El análisis cuantitativo se usa para determinar un efecto acumulativo de estas cadenas de eventos en el calendario del proyecto.
  • Los eventos críticos o cadenas de eventos: Los eventos individuales o las cadenas de eventos que tienen el mayor potencial para afectar los proyectos son los "eventos críticos" o "cadenas de eventos críticos." Ellos pueden ser determinados por el análisis.
  • Proyecto de seguimiento de los acontecimientos: Incluso si un proyecto está parcialmente terminado y los datos sobre la duración del proyecto, el costo y hechos ocurrieron está disponible, todavía es posible mejorar la información sobre futuros eventos potenciales y ayuda a pronosticar el desempeño futuro del proyecto.
  • Visualización de eventos de la cadena: Eventos y cadenas de eventos se pueden visualizar utilizando diagramas de eventos de la cadena en un diagrama de Gantt .

[ editar ] Proceso de gestión basada en los

También fomentar el concepto de control del proyecto es la incorporación de la gestión basada en procesos. Esta zona ha sido impulsado por el uso de modelos de madurez, como el CMMI (Capability Maturity Model Integration, véase el ejemplo de un predecesor) y ISO/IEC15504 (SPICE - mejora de procesos de software y estimación de capacidad).

[ edit ] ágil de gestión de proyectos

El ciclo de iteración en la gestión de proyectos ágil

Gestión de proyectos Agile enfoques basados ​​en los principios de la gestión de la interacción humana se basa en un proceso de vista de la colaboración humana. Se trata de "lo más típicamente usado en software, sitio web, la tecnología, las industrias creativas y de marketing". [23] Esto contrasta fuertemente con el enfoque tradicional. En el desarrollo ágil de software o desarrollo de productos flexibles enfoque, el proyecto es visto como una serie de tareas relativamente pequeñas concebidas y ejecutadas como la situación exige de manera adaptativa, y no como un proceso completamente pre-planificado.

[ editar ] Gestión de proyecto Lean

Gestión de proyectos magra utiliza principios de manufactura esbelta para centrarse en ofrecer valor con menos desperdicio.

[ editar ] Gestión del proyecto Extreme

Planificación y retroalimentación bucles en programación extrema (XP) con los marcos de tiempo de los lazos múltiples.

En los estudios críticos de la gestión del proyecto se ha observado que varios PERT modelos basados ​​no son muy adecuadas para el entorno del proyecto multi-empresa de hoy en día. [ cita requerida ] La mayoría de ellos están dirigidos a muy gran escala, de una sola vez, no proyectos de rutina, y en la actualidad todo tipo de gestión, están expresadas en términos de proyectos.

El uso de modelos complejos para "proyectos" (o más bien "tareas") que abarcan unas semanas se ha demostrado que causa gastos innecesarios y maniobrabilidad bajo en varios casos [ cita requerida ]. En su lugar, los expertos en gestión de proyectos tratan de identificar diferentes modelos "ligeros", como Extreme Programming y Scrum .

La generalización de la programación extrema a otros tipos de proyectos es la gestión de proyectos extrema , que puede ser utilizado en combinación con el proceso de modelado y los principios de gestión de la gestión de la interacción humana .

[ editar ] Beneficios manejo realización

Beneficios de la gestión de realización (BRM) mejora las técnicas habituales de gestión de proyectos a través de un enfoque en aceptar lo que los resultados deben cambiar (los beneficios) durante el proyecto y, a continuación, la medición para saber si lo que está sucediendo para ayudar a mantener un proyecto en marcha. Esto puede ayudar a reducir el riesgo de un proyecto terminado siendo un fracaso ya que en lugar de intentar entregar los requisitos acordados el objetivo es entregar el beneficio de esos requisitos.

Un ejemplo de la entrega de un proyecto para requisitos podrían ponerse de acuerdo sobre un proyecto para ofrecer un sistema informático para procesar los datos del personal de la obligación de administrar la nómina de personal, vacaciones y el personal de registros. Bajo el acuerdo BRM sería utilizar los proveedores sugirió el personal del sistema de datos para ver una reducción acordada en el procesamiento de las horas del personal y el mantenimiento de datos de personal (HR beneficiarse reducir plantilla).

[ editar ] Procesos

Las etapas de desarrollo del proyecto [24]

Tradicionalmente, la gestión de proyectos incluye una serie de elementos: de cuatro a cinco grupos de procesos, y un sistema de control. Independientemente de la metodología o la terminología utilizada, los mismos procesos básicos de gestión de proyectos se utilizará. Los principales grupos de procesos generalmente incluyen: [6]

  • iniciación
  • planificación o diseño
  • producción o ejecución
  • monitorear y controlar
  • cierre

En entornos de proyectos con un componente significativo de exploración (por ejemplo, investigación y desarrollo ), estas etapas pueden ser complementados con los puntos de decisión (go / no go decisiones) en el que se debate la continuación del proyecto y decidido. Un ejemplo es el modelo de eliminación de puerta .

[ editar ] Inicio de

Iniciar procesos de procesos de grupo [24]

Los procesos de iniciación determinar la naturaleza y el alcance del proyecto. [25] Si esta etapa no se realiza bien, es poco probable que el proyecto tenga éxito en satisfacer las necesidades del negocio. Los controles principales del proyecto son necesarios aquí una comprensión del entorno empresarial y de asegurarse de que todos los controles necesarios se incorporen al proyecto. Cualquier deficiencia debe ser reportado y que una recomendación se hace para solucionarlos.

La etapa de iniciación debe incluir un plan que abarca las siguientes áreas:

[ editar ] La planificación y el diseño

Después de la etapa inicial, el proyecto se prevé un nivel apropiado de detalle (ver ejemplo de un diagrama de flujo ). [24] El objetivo principal es planificar el tiempo, el costo y los recursos adecuadamente para estimar el trabajo necesario y eficaz para gestionar el riesgo durante la ejecución del proyecto. Al igual que el grupo de procesos de iniciación, una incapacidad para planificar adecuadamente reduce en gran medida las posibilidades del proyecto de éxito en el cumplimiento de sus objetivos.

La planificación del proyecto consiste generalmente en [26]

  • determinar la forma de planificar (por ejemplo, nivel de detalle o una onda de balance);
  • desarrollar el enunciado del alcance;
  • seleccionar el equipo de planificación;
  • la identificación de los entregables y la creación de la estructura de división del trabajo;
  • la identificación de las actividades necesarias para completar los entregables y trabajo en red de las actividades en su secuencia lógica;
  • la estimación de las necesidades de recursos para las actividades;
  • estimar el tiempo y el costo de las actividades;
  • el desarrollo de la programación;
  • la elaboración del presupuesto;
  • riesgo de planificación;
  • obtener la aprobación formal para comenzar a trabajar.

Los procesos adicionales, tales como la planificación de las comunicaciones y de gestión del alcance, la identificación de los roles y responsabilidades, la determinación de qué comprar para el proyecto y la celebración de una reunión inicial también son generalmente aconsejable.

Para el desarrollo de productos nuevos proyectos, el diseño conceptual del funcionamiento del producto final puede realizarse simultáneamente con las actividades de planificación de proyectos, y puede ayudar a informar al equipo de planificación de la hora de identificar los aportes y actividades de planificación.

[ editar ] Ejecución

Ejecución de procesos de procesos de grupo [24]

Ejecución se compone de los procesos utilizados para completar el trabajo definido en el plan del proyecto para cumplir con los requisitos del proyecto. Proceso de ejecución consiste en la coordinación de personas y recursos, así como integrar y realizar las actividades del proyecto de acuerdo con el plan de gestión del proyecto. Los entregables se producen como salidas de los procesos que se realizan tal como se define en el plan de gestión del proyecto y otros marcos que puedan ser aplicables al tipo de proyecto en cuestión.

Grupo Ejecución proceso incluyen:

  • Dirigir y Gestionar la Ejecución del Proyecto
  • Aseguramiento de la Calidad de los entregables
  • Adquirir, desarrollar y gestionar el equipo del proyecto
  • Distribuir la Información
  • Manejar las expectativas de interesados
  • Realizar adquisiciones

[ edit ] Supervisión y control

Supervisión y control de procesos de procesos de grupo [24]

Seguimiento y control consta de aquellos procesos realizados para observar la ejecución del proyecto de manera que los problemas potenciales se pueden identificar de una manera oportuna y acciones correctivas pueden ser tomadas, cuando sea necesario, para controlar la ejecución del proyecto. La principal ventaja es que el rendimiento del proyecto se observa y se mide regularmente para identificar las variaciones respecto del plan de gestión del proyecto.

Supervisión y control incluye: [27]

  • Medición de las actividades de los proyectos en curso ('dónde estamos');
  • Seguimiento de las variables del proyecto (costo, esfuerzo, alcance, etc) contra el plan de gestión del proyecto y la línea base de rendimiento del proyecto (donde deberíamos estar);
  • Identificar las acciones correctivas para hacer frente a problemas y riesgos correctamente (¿Cómo podemos conseguir en pista otra vez);
  • Influencia de los factores que podrían eludir el control integrado el cambio tan sólo cambios aprobados se apliquen.

En proyectos de fases múltiples, el proceso de seguimiento y control también proporciona retroalimentación entre las fases del proyecto, con el fin de implementar acciones correctivas o preventivas para que el proyecto cumpla con el plan de gestión del proyecto.

Mantenimiento del proyecto es un proceso continuo, e incluye: [6]

  • Continuando con el apoyo de los usuarios finales
  • Corrección de errores
  • Las actualizaciones del software a través del tiempo
Supervisión y control de ciclo

En esta etapa, los auditores deben prestar atención a la forma eficaz y rápida los problemas del usuario se resuelven.

En el transcurso de cualquier proyecto de construcción, el alcance de trabajo puede cambiar. El cambio es una parte normal y esperada del proceso de construcción. Los cambios pueden ser el resultado de las modificaciones de diseño necesarias, diferentes condiciones de la obra, disponibilidad de materiales, cambios solicitados contratista, la ingeniería de valor y los efectos de terceros, para nombrar unos pocos. Más allá de la ejecución del cambio en el campo, el cambio normalmente necesita ser documentada para mostrar lo que fue realmente construido. Esto se conoce como cambio de gestión. Por lo tanto, el propietario por lo general requiere un expediente final a todos los cambios o, más específicamente, cualquier cambio que modifique las partes tangibles de la obra terminada. El registro se hace en el pliego de condiciones - por lo general, pero no necesariamente se limitan a, los dibujos de diseño. El producto final de este esfuerzo es lo que en términos de as-built dibujos, o más simplemente, "as built". La exigencia de proporcionarlos es una norma en los contratos de construcción.

Cuando se introducen cambios al proyecto, la viabilidad del proyecto tiene que ser re-evaluado. Es importante no perder de vista los objetivos iniciales y los objetivos de los proyectos. Cuando los cambios se acumulan, el resultado previsto no puede justificar la inversión original propuesto en el proyecto.

[ editar ] Cierre

Cierre de procesos de procesos de grupo. [24]

Cierre incluye la aceptación formal del proyecto y el mismo fin. Actividades administrativas incluyen las lecciones de archivado de los archivos y la documentación aprendidas.

Esta fase consiste de: [6]

  • Cerrar Proyecto: Finalizar todas las actividades en todos los grupos de procesos para cerrar formalmente el proyecto o una fase del proyecto
  • Cierre del Contrato: completar y resolver cada contrato (incluyendo la resolución de cualquier ítem abierto) y cerrar cada contrato aplicable al proyecto o fase del proyecto.

[ editar ] El proyecto de control y los sistemas de control de proyectos

Proyecto de inspección deberá ser establecido como una función independiente en gestión de proyectos. Implementa la verificación y la función de control durante la tramitación de un proyecto con el fin de reforzar el desempeño definidos y metas formales. [28] Las tareas del proyecto de control son también:

  • la creación de infraestructura para el suministro de la información y su actualización
  • el establecimiento de una forma de comunicar las diferencias de los parámetros del proyecto
  • el desarrollo de la tecnología de la información del proyecto sobre la base de una intranet o de la resolución de un sistema de clave del proyecto índice de rendimiento (KPI)
  • análisis de la divergencia y la generación de propuestas de reglamentos potenciales del proyecto [29]
  • el establecimiento de métodos para llevar a cabo un adecuado la estructura del proyecto, el proyecto de organización del flujo de trabajo, el proyecto de control y gobierno
  • creación de la transparencia entre los parámetros del proyecto [30]

El cumplimiento y la ejecución de estas tareas se puede lograr mediante la aplicación de métodos e instrumentos específicos de control de proyecto. Los siguientes métodos de control del proyecto puede ser aplicado:

  • análisis de inversiones
  • análisis costo-beneficio
  • valor Análisis beneficio
  • encuestas a expertos
  • cálculos de simulación
  • perfil de riesgo-análisis
  • cálculos de recargos
  • hito análisis de tendencias
  • costo de análisis de tendencias
  • blanco / real de comparación [31]

El control del proyecto es que los elementos de un proyecto que se mantiene en la pista, a tiempo y dentro del presupuesto. [27] El control del proyecto se inicia al principio del proyecto con el planeamiento y termina al final del proyecto con revisión posterior a la implementación, teniendo una participación a fondo de cada paso en el proceso. Cada proyecto debe ser evaluado por el nivel de control necesario: demasiado control es demasiado lento, demasiado poco control es muy arriesgado. Si el control del proyecto no se realiza correctamente, el costo para la empresa debe ser aclarada en términos de errores, correcciones y adicionales de auditoría impuestos.

Los sistemas de control son necesarios para el costo, riesgo , calidad, comunicación, tiempo, cambio, adquisiciones y recursos humanos. Además, los auditores deben considerar la importancia de los proyectos son de los estados financieros , cómo dependen los grupos de interés están en los controles, y la forma de controles que existen. El auditor deberá revisar el proceso de desarrollo y procedimientos de cómo se implementan. El proceso de desarrollo y la calidad del producto final también se puede evaluar si es necesario o solicitado. Un negocio puede desear que la empresa de auditoría para participar en todo el proceso de detectar los problemas antes de modo que se puede fijar más fácilmente. Un auditor puede servir como consultor controles como parte del equipo de desarrollo o como un auditor independiente como parte de una auditoría.

Las empresas utilizan a veces los procesos formales de desarrollo de sistemas. Estos ayudan a asegurar que los sistemas se desarrollan con éxito. Un proceso formal es más eficaz en la creación de fuertes controles, y los auditores deben revisar este proceso para confirmar que está bien diseñado y es seguido en la práctica. Un buen plan formal de desarrollo de sistemas se describen:

  • Una estrategia de desarrollo para alinearse con los objetivos más amplios de la organización
  • Normas para los nuevos sistemas de
  • Las políticas de gestión de proyectos para el cronometraje y la presupuestación
  • Procedimientos que describen el proceso
  • Evaluación de la calidad de cambio

[ editar ] Temas

[ editar ] Los jefes de proyecto

Un gerente de proyecto es un profesional en el campo de la gestión de proyectos. Los gerentes de proyecto pueden tener la responsabilidad de la planificación, ejecución y cierre de cualquier proyecto, por lo general en relación con la industria de la construcción , la ingeniería, la arquitectura, informática y telecomunicaciones. Muchos otros campos de la ingeniería de producción ingeniería y el diseño industrial y pesado tener directores de proyectos.

Un gerente de proyecto es la persona responsable de llevar a cabo los objetivos del proyecto establecidos. Las principales responsabilidades de gestión de proyectos incluyen la creación de objetivos claros y alcanzables, la construcción de los requerimientos del proyecto y la gestión de la triple restricción de los proyectos, que es el costo, tiempo y alcance.

Un gerente de proyecto es a menudo un representante del cliente y debe determinar e implementar las necesidades exactas del cliente, basándose en el conocimiento de la empresa que representan. La capacidad de adaptarse a los distintos procedimientos internos de la parte contratante, y formar vínculos estrechos con los representantes designados, es esencial para asegurar que los temas clave de costo, tiempo, calidad y, sobre todo, la satisfacción del cliente, pueden ser realizados.

[ editar ] Gestión de proyectos triángulo

Como cualquier empresa humana, los proyectos necesitan ser realizados y entregados bajo ciertas restricciones. Tradicionalmente, estas restricciones han sido catalogados como "alcance", "tiempo" y "costos". [1] Estos son también conocidos como el " triángulo de la gestión de proyectos ", donde cada lado representa una restricción. Un lado del triángulo no puede cambiarse sin afectar a los demás. Un refinamiento posterior de las restricciones separa el producto de "calidad" o "rendimiento" de su alcance, y hace de la calidad en una cuarta restricción.

The time constraint refers to the amount of time available to complete a project. The cost constraint refers to the budgeted amount available for the project. The scope constraint refers to what must be done to produce the project's end result. These three constraints are often competing constraints: increased scope typically means increased time and increased cost, a tight time constraint could mean increased costs and reduced scope, and a tight budget could mean increased time and reduced scope.

The discipline of project management is about providing the tools and techniques that enable the project team (not just the project manager) to organize their work to meet these constraints.

[ edit ] Work breakdown structure

The work breakdown structure (WBS) is a tree structure that shows a subdivision of effort required to achieve an objective—for example a program, project, and contract. The WBS may be hardware-, product-, service-, or process -oriented (see an example in a NASA reporting structure (2001) ). [ 32 ]

A WBS can be developed by starting with the end objective and successively subdividing it into manageable components in terms of size, duration, and responsibility (eg, systems, subsystems, components, tasks, sub-tasks, and work packages), which include all steps necessary to achieve the objective. [ 19 ]

The work breakdown structure provides a common framework for the natural development of the overall planning and control of a contract and is the basis for dividing work into definable increments from which the statement of work can be developed and technical, schedule, cost, and labor hour reporting can be established. [ 32 ]

[ edit ] Project management framework

The Program (Investment) life cycle integrates the project management and system development life cycles with the activities directly associated with system deployment and operation. By design, system operation management and related activities occur after the project is complete and are not documented within this guide [ 24 ] (see an example of an IT project management framework ).

For example, see figure, in the US United States Department of Veterans Affairs (VA) the program management life cycle is depicted and describe in the overall VA IT Project Management Framework to address the integration of OMB Exhibit 300 project (investment) management activities and the overall project budgeting process. The VA IT Project Management Framework diagram illustrates Milestone 4 which occurs following the deployment of a system and the closing of the project. The project closing phase activities at the VA continues through system deployment and into system operation for the purpose of illustrating and describing the system activities the VA considers part of the project. The figure illustrates the actions and associated artifacts of the VA IT Project and Program Management process. [ 24 ]

[ editar ] Normas internacionales

There have been several attempts to develop project management standards, such as:

[ edit ] Project portfolio management

An increasing number of organizations are using, what is referred to as, project portfolio management (PPM) as a means of selecting the right projects and then using project management techniques [ 34 ] as the means for delivering the outcomes in the form of benefits to the performing private or not-for-profit organization.

[ editar ] Véase también

[ editar ] Referencias

  1. ^ a b Chatfield, Carl. "A short course in project management" . Microsoft.  
  2. ^ * The Definitive Guide to Project Management . Nokes, Sebastian. 2nd Ed.n. London (Financial Times / Prentice Hall): 2007. ISBN 978-0-273-71097-4
  3. ^ Paul C. Dinsmore et al (2005) The right projects done right! John Wiley and Sons, 2005. ISBN 0-7879-7113-8 . p.35 and further.
  4. ^ Lewis R. Ireland (2006) Project Management . McGraw-Hill Professional, 2006. ISBN 0-07-147160-X . p.110.
  5. ^ Joseph Phillips (2003). PMP Project Management Professional Study Guide . McGraw-Hill Professional, 2003. ISBN 0-07-223062-2 p.354.
  6. ^ a b c d PMI (2010). A Guide to the Project Management Body of Knowledge p.27-35
  7. ^ Dennis Lock (2007) Project Management (9th ed.) Gower Publishing, Ltd., 2007. ISBN 0-566-08772-3
  8. ^ Young-Hoon Kwak (2005). "A brief History of Project Management". In: The story of managing projects . Elias G. Carayannis et al. (9 eds), Greenwood Publishing Group, 2005. ISBN 1-56720-506-2
  9. ^ David I. Cleland , Roland Gareis (2006). Global Project Management Handbook . "Chapter 1: "The evolution of project management". McGraw-Hill Professional, 2006. ISBN 0-07-146045-4
  10. ^ Martin Stevens (2002). Project Management Pathways . Association for Project Management. APM Publishing Limited, 2002 ISBN 1-903494-01-X p.xxii
  11. ^ Edward R. Marsh (1975). "The Harmonogram of Karol Adamiecki". In: The Academy of Management Journal . Vol. 18, No. 2 (Jun., 1975), p. 358. ( online )
  12. ^ Morgen Witzel (2003). Fifty key figures in management . Routledge, 2003. ISBN 0-415-36977-0 . p. 96-101.
  13. ^ David I. Cleland , Roland Gareis (2006). Global Project Management Handbook . McGraw-Hill Professional, 2006. ISBN 0-07-146045-4 . p.1-4 states: " It was in the 1950s when project management was formally recognized as a distinct contribution arising from the management discipline. "
  14. ^ Booz Allen Hamilton – History of Booz Allen 1950s
  15. ^ Bjarne Kousholt (2007). Project Management –. Theory and practice. . Nyt Teknisk Forlag. ISBN 87-571-2603-8 . p.59.
  16. ^ ipma.ch
  17. ^ FL Harrison, Dennis Lock (2004). Advanced project management: a structured approach . Gower Publishing, Ltd., 2004. ISBN 0-566-07822-8 . p.34.
  18. ^ Winston W. Royce (1970). "Managing the Development of Large Software Systems" in: Technical Papers of Western Electronic Show and Convention (WesCon) August 25–28, 1970, Los Angeles, USA.
  19. ^ a b Stellman, Andrew; Greene, Jennifer (2005). Applied Software Project Management . O'Reilly Media. ISBN 978-0-596-00948-9 .  
  20. ^ OGC – PRINCE2 – Background
  21. ^ http://greenprojectmanagement.org
  22. ^ http://greenprojectmanagement.org/certification  
  23. ^ "What is Agile Project Management?" . Planbox.  
  24. ^ a b c d e f g h "Project Management Guide" . VA Office of Information and Technology . March 3, 2005.  
  25. ^ Peter Nathan, Gerald Everett Jones (2003). PMP certification for dummies . p.63.
  26. ^ Harold Kerzner (2003). Project Management: A Systems Approach to Planning, Scheduling, and Controlling (8th Ed. ed.). Wiley. ISBN 0-471-22577-0 .  
  27. ^ a b James P. Lewis (2000). The project manager's desk reference: : a comprehensive guide to project planning, scheduling, evaluation, and systems. p.185
  28. ^ Jörg Becker, Martin Kugeler, Michael Rosemann (2003). Process management: a guide for the design of business processes. ISBN 978-3-540-43499-3 . p.27.
  29. ^ Bernhard Schlagheck (2000). Objektorientierte Referenzmodelle für das Prozess- und Projektcontrolling. Grundlagen – Konstruktionen – Anwendungsmöglichkeiten. ISBN 978-3-8244-7162-1 . p.131.
  30. ^ Josef E. Riedl (1990). Projekt – Controlling in Forschung und Entwicklung. ISBN 978-3-540-51963-8 . p.99.
  31. ^ Steinle, Bruch, Lawa (1995). Projektmanagement. FAZ Verlagsbereich Wirtschaftsbücher. p.136–143
  32. ^ a b NASA NPR 9501.2D . May 23, 2001.
  33. ^ Body of Knowledge 5th edition, Association for Project Management, 2006, ISBN 1-903494-13-3
  34. ^ Albert Hamilton (2004). Handbook of Project Management Procedures. TTL Publishing, Ltd. ISBN 0-7277-3258-7

[ editar ] Enlaces externos